From internet-drafts@ietf.org Sun Sep 9 19:41:18 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 CD9A021F8593; Sun, 9 Sep 2012 19:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wts-y5Nv7M74; Sun, 9 Sep 2012 19:41:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7B21F8496; Sun, 9 Sep 2012 19:41:18 -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-vpls-macflush-ld-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910024118.15877.64193.idtracker@ietfa.amsl.com> Date: Sun, 09 Sep 2012 19:41:18 -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: Mon, 10 Sep 2012 02:41:19 -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 : MAC Flush Loop Detection in VPLS Author(s) : Paul Kwok Pranjal Kumar Dutta Filename : draft-ietf-l2vpn-vpls-macflush-ld-02.txt Pages : 14 Date : 2012-09-09 Abstract: MAC Address Withdrawal is a mechanism described in [RFC4762] to remove or unlearn MAC addresses that have been dynamically learned in a VPLS instance, for faster convergence on topology change. Failure of mechanisms that control loop free connectivity among VPLS PE-rs nodes may cause MAC Address Withdrawal Messages looping among those nodes, leading to Denial of Service (DoS) or complete failure of control plane in the PE-rs nodes. This document describes a mechanism to detect and prevent loops of MAC Address Withdrawal messages in a VPLS PE-rs node on such failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-macflush-ld There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-macflush-ld-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-vpls-macflush-ld-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Sep 9 21:34: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 9660321F84D6; Sun, 9 Sep 2012 21:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1xk3Z5p45qt; Sun, 9 Sep 2012 21:34:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E6221E8039; Sun, 9 Sep 2012 21:34:03 -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-vpls-ldp-mac-opt-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910043403.534.6908.idtracker@ietfa.amsl.com> Date: Sun, 09 Sep 2012 21:34:03 -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: Mon, 10 Sep 2012 04:34:27 -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 : LDP Extensions for Optimized MAC Address Withdrawal in H= -VPLS Author(s) : Pranjal Kumar Dutta Florin Balus Olen Stokes Geraldine Calvinac Filename : draft-ietf-l2vpn-vpls-ldp-mac-opt-07.txt Pages : 21 Date : 2012-09-09 Abstract: [RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to [RFC4762] MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in [I-D.ietf-l2vpn-pbb-vpls-pe-model] . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-ldp-mac-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-vpls-ldp-mac-opt-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From olivier.dornon@alcatel-lucent.com Mon Sep 10 01: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 6D4C321F853B for ; Mon, 10 Sep 2012 01:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chgp2P1qX2Kl for ; Mon, 10 Sep 2012 01:31:27 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1B021F852B for ; Mon, 10 Sep 2012 01:31:27 -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 q8A8MFMg019741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 Sep 2012 10:31:22 +0200 Received: from [138.203.14.185] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Sep 2012 10:31:16 +0200 Message-ID: <504DA554.1030508@alcatel-lucent.com> Date: Mon, 10 Sep 2012 10:31:16 +0200 From: Olivier Dornon User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 CentOS/3.1.16-2.el6.centos Thunderbird/3.1.16 MIME-Version: 1.0 To: Subject: Re: I-D Action: draft-ietf-l2vpn-vpls-pim-snooping-02.txt References: <20120716151254.26553.97170.idtracker@ietfa.amsl.com> In-Reply-To: <20120716151254.26553.97170.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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, 10 Sep 2012 08:31:28 -0000 This draft describes the procedures for pim snooping and introduces pim proxying in a vpls. Amongst other things, both modes handle Join/Prune messages in a different way. In a nutshell, when running in snooping mode the J/P messages remain untouched, while they're consumed and proxied to relevant upstream ports on proxy mode. I refer to the draft for a detailed description. Running in snooping mode has some drawbacks, as J/P messages are just flooded, it's not very network efficient and it forces the peers to disable join suppression. To counter this we could only forward the J/P messages to relevant upstream ports in snooping mode too, this would save on network resources and allow peers to maintain join suppression. We can imagine there might be objections to this, we know from past experiences that some operators are reluctant to process/forward control messages instead of just snooping and transparently forward them. I raised the question during my presentation in Vancouver (http://www.ietf.org/proceedings/84/slides/slides-84-l2vpn-1.ppt) but didn't get any feedback. Hence this posting, we'd love to hear some feedback on this, especially from operators/service providers. Thanks, Olivier. On 07/16/2012 05:12 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. > > Title : PIM Snooping over VPLS > Author(s) : Olivier Dornon > Jayant Kotalwar > Jeffrey Zhang > Venu Hemige > Filename : draft-ietf-l2vpn-vpls-pim-snooping-02.txt > Pages : 39 > Date : 2012-07-16 > > Abstract: > In Virtual Private LAN Service (VPLS), as also in IEEE Bridged > Networks, the switches simply flood multicast traffic on all ports in > the LAN by default. IGMP Snooping is commonly deployed to ensure > multicast traffic is not forwarded on ports without IGMP receivers. > The procedures and recommendations for IGMP Snooping are defined in > [IGMP-SNOOP]. But when any protocol other than IGMP is used, the > common practice is to simply flood multicast traffic to all ports. > PIM-SM, PIM-SSM, PIM-BIDIR are widely deployed routing protocols. > PIM Snooping procedures are important to restrict multicast traffic > to only the routers interested in receiving such traffic. > > While most of the PIM Snooping procedures defined here also apply to > IEEE Bridged Networks, VPLS demands certain special procedures due to > the split-horizon rules that require the Provider Edge (PE) devices > to co-operate. This document describes the procedures and > recommendations for PIM-Snooping in VPLS to facilitate replication to > only those ports behind which there are interested PIM routers and/or > IGMP hosts. This document also describes procedures for PIM Proxy. > PIM Proxy is required on PEs for VPLS Multicast to work correctly > when Join suppression is enabled in the VPLS. PIM Proxy also helps > scale VPLS Multicast much better than just PIM Snooping. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-pim-snooping > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pim-snooping-02 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-vpls-pim-snooping-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From giles.heron@gmail.com Mon Sep 10 06:12: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 0D33F21F85BB for ; Mon, 10 Sep 2012 06:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No10BIwtjhSL for ; Mon, 10 Sep 2012 06:12:46 -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 4EC2321F859B for ; Mon, 10 Sep 2012 06:12:46 -0700 (PDT) Received: by eekb45 with SMTP id b45so1152389eek.31 for ; Mon, 10 Sep 2012 06:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wAnVyINsEhB/yvibhaBWoL2tfoeE16bc1aygvqwkV2o=; b=0XIBNnLDMcfomeOixTJz9nxvzRWD1oYrv4bHHCHZ9Knx3yZjEgk4SOlGvRuVrT0B+t jjznyYHXEBaixOLTeX6aL6JzYandl95zB1ImVKxKRc1GQDAB2HWia1CQUgKd3RZcoFa7 1NsdpYfN1lSqfwCV+dXTmuiys5PQtMkyZs3dFGhnmho01YQnfaShMB+6xpJSsNxRfHwb GktHum4u8ewpRkMCwBl7R+PpjN0bU8kEuvP1+o2QX8DkML1MfdSBJJ89wpybKTCKRnLW ZYr9ac1QNMRh6o2+suf8OdqZ4fEwB0bUrlwEMOBCKJMBt2NbgCuwKbUKQdtom6/cyLFT ZCVg== Received: by 10.14.218.134 with SMTP id k6mr19779199eep.14.1347282765477; Mon, 10 Sep 2012 06:12:45 -0700 (PDT) Received: from dhcp-bdlk10-vlan254-10-147-56-181.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 45sm38032685eed.17.2012.09.10.06.12.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Sep 2012 06:12:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Subject: Re: WG adoption call for VPLS PE Model for E-Tree Support From: Giles Heron In-Reply-To: <4C315ACB-5B01-4B20-B622-179665B787D9@gmail.com> Date: Mon, 10 Sep 2012 14:12:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FE34245-12F1-41BE-AAF8-ECB8CF902C89@gmail.com> References: <4C315ACB-5B01-4B20-B622-179665B787D9@gmail.com> To: l2vpn@ietf.org X-Mailer: Apple Mail (2.1486) 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, 10 Sep 2012 13:12:47 -0000 There seems to be strong consensus to adopt this draft as a WG doc. Would the authors please re-issue the draft as: draft-ietf-l2vpn-vpls-pe-etree-00. thanks! Nabil & Giles. On 23 Aug 2012, at 17:03, Giles Heron wrote: > This is a request to gauge consensus as to whether: >=20 > http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-06 >=20 > should be accepted as an L2VPN WG draft. >=20 > We discussed adoption of this draft in Vancouver, and the consensus of = the room seemed to be to adopt it, but of course the list is where we = make decisions :) >=20 > Note that we also discussed adoption of the other VPLS E-Tree drafts = in Vancouver and there was very little support. If multiple people = email me asking to adopt one or other of those drafts I'll poll that one = also. >=20 > Please review the draft and respond to the list by Thursday September = 6th with comments as to its suitability for WG adoption. >=20 > Giles From internet-drafts@ietf.org Wed Sep 12 02:13:20 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 0975821F8643; Wed, 12 Sep 2012 02:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bN1F44L9R-b; Wed, 12 Sep 2012 02:13:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849A721F8611; Wed, 12 Sep 2012 02:13:19 -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-vpls-pe-etree-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120912091319.8579.20075.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 02:13:19 -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, 12 Sep 2012 09:13:20 -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 : VPLS PE Model for E-Tree Support Author(s) : Yuanlong Jiang Lucy Yong Manuel Paul Frederic Jounay Florin Balus Wim Henderickx Ali Sajassi Filename : draft-ietf-l2vpn-vpls-pe-etree-00.txt Pages : 23 Date : 2012-09-11 Abstract: A generic VPLS solution for E-Tree services is proposed which uses VLANs to indicate root/leaf traffic. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E- Tree VPLS PEs are interconnected by PWs which carry the VLAN indicating the E-Tree attribute, the MAC address based Ethernet forwarding engine and the PW work in the same way as before. A signaling mechanism for E-Tree capability and VLAN mapping negotiation is further described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-pe-etree There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jiangyuanlong@huawei.com Fri Sep 21 02:16:57 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 4E0D421F8742 for ; Fri, 21 Sep 2012 02:16: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKTeSfpl1JX4 for ; Fri, 21 Sep 2012 02:16:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 611A421F873C for ; Fri, 21 Sep 2012 02:16:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKX29577; Fri, 21 Sep 2012 09:16:55 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 10:16:13 +0100 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 10:16:40 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 17:16:27 +0800 From: Jiangyuanlong To: "l2vpn@ietf.org" Subject: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNl9bO5vMHP1fUbUG3AEjOw2TsF5eUffmw Date: Fri, 21 Sep 2012 09:16:25 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@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: [10.66.77.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 21 Sep 2012 09:16:57 -0000 SGkgYWxsLA0KDQpEdXJpbmcgdGhlIDg0dGggSUVURiBtZWV0aW5nLCB0aGUgZ3JvdXAgZGlzY3Vz c2VkIHRoZSBpc3N1ZSBvZiBFLVRyZWUgaW4gRS1WUE4sIGFuZCBpdCB3YXMgc2hvd24gdGhhdCBh IHNpbmdsZSBzb2x1dGlvbiB3YXMgbW9yZSBwcmVmZXJyZWQgdGhhbiB0d28gZGlmZmVyZW50IGFw cHJvYWNoZXMgZm9yIFZQTFMgYW5kIEUtVlBOLg0KVGhpcyBJLUQgcHJvYmVzIGhvdyB0aGUgMlZM QU4gYXBwcm9hY2ggY2FuIGJlIHVzZWQgdG8gc3VwcG9ydCBFLVRyZWUgaW4gRS1WUE4gYW5kIGl0 IHNlZW1zIG5vdCBhIGJpZyBpc3N1ZS4NCkFueSBjb21tZW50cyBmcm9tIHlvdSBhcmUgZ3JlYXRs eSBhcHByZWNpYXRlZC4NCg0KQmVzdCByZWdhcmRzLA0KWXVhbmxvbmcNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAyMSwgMjAx MiA0OjU1IFBNDQpUbzogSmlhbmd5dWFubG9uZw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1qaWFuZy1sMnZwbi1ldnBuLWV0cmVlLTJ2bGFuLTAwLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qaWFuZy1sMnZwbi1ldnBuLWV0cmVlLTJ2bGFu LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBZdWFubG9uZyBKaWFu ZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0 LWppYW5nLWwydnBuLWV2cG4tZXRyZWUtMnZsYW4NClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEUt VHJlZSBTdXBwb3J0IHdpdGggMlZMQU4gaW4gRS1WUE4NCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA5 LTIxDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNg0K VVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1qaWFuZy1sMnZwbi1ldnBuLWV0cmVlLTJ2bGFuLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWppYW5nLWwydnBuLWV2cG4tZXRy ZWUtMnZsYW4NCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtamlhbmctbDJ2cG4tZXZwbi1ldHJlZS0ydmxhbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhp cyBkb2N1bWVudCBkaXNjdXNzZXMgaG93IHRoZSBEdWFsLVZMQU4gYXBwcm9hY2ggYXMgZGVzY3Jp YmVkIGluDQogICBbRXRyZWUtdmxhbl0gY2FuIGJlIHVzZWQgdG8gc3VwcG9ydCB0aGUgdHJhbnNw b3J0IG9mIEUtVHJlZSBzZXJ2aWNlDQogICBpbiBFLVZQTi4gVGh1cyBhIHNpbmdsZSBjb252ZXJn ZW50IHNvbHV0aW9uIGlzIHBvc3NpYmxlIGZvciBib3RoIFZQTFMNCiAgIGFuZCBFLVZQTi4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From giles.heron@gmail.com Fri Sep 21 06:04: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 D87B921F877F for ; Fri, 21 Sep 2012 06:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHuzK1eAE4OV for ; Fri, 21 Sep 2012 06:04:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC26121F8575 for ; Fri, 21 Sep 2012 06:04:50 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5212273pbb.31 for ; Fri, 21 Sep 2012 06:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=aU7pe5fQUJTFVExwI9cmkvDiRaeQwJKFgvmzZp7U+KQ=; b=VlIGEyDDwJ2B5CK9jx78fqlrTsQDml4ozAEESCAOWDIOyPHF4AjLvLT9aDK/A2Jqvg bpfZlFMrZI+FG4i8p1UXmtDzk6ZM+s/AoVntDRi1spSErHy0ZQREmQDkiU535R/0fCoY qbcd/IxI5QQaQytHeNW5tyJ+6R7t2tK/ooGZpCt0EraD7zFAE4sL51WQJg2GwjgrDK6j I0C1xuouZsFcqzox9dk9WJAnFlRVPx6HeLe3xm6/MI8RK/RFsAVGfUDQTzr5UcyZzokd 6LqpcJVVg1uZsUkbBluvRSddCRWOTtCfX3Y/tMa2XbwsRPLjZx1FpF7euWe91BiJ8y5u 6jNg== Received: by 10.68.130.201 with SMTP id og9mr15538774pbb.12.1348232690486; Fri, 21 Sep 2012 06:04:50 -0700 (PDT) Received: from sjc-vpn2-476.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id tw5sm5115588pbc.48.2012.09.21.06.04.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 06:04:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Subject: Re: WG adoption call for VPLS PE Model for E-Tree Support From: Giles Heron In-Reply-To: <3FE34245-12F1-41BE-AAF8-ECB8CF902C89@gmail.com> Date: Fri, 21 Sep 2012 14:04:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <45114B37-7059-4FA4-8A4A-C945BDF0E210@gmail.com> References: <4C315ACB-5B01-4B20-B622-179665B787D9@gmail.com> <3FE34245-12F1-41BE-AAF8-ECB8CF902C89@gmail.com> To: l2vpn@ietf.org X-Mailer: Apple Mail (2.1498) 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, 21 Sep 2012 13:04:52 -0000 Further to this email, only one person requested adoption of an alternative VPLS-based E-Tree = solution, so we won't be progressing any other VPLS-based solutions. however we do intend to progress an E-VPN solution also. As discussed = in the IETF 84 meeting we only intend to standardise one E-VPN approach. please respond to the WG if you have any concerns with our planned = approach. Nabil & Giles On 10 Sep 2012, at 14:12, Giles Heron wrote: > There seems to be strong consensus to adopt this draft as a WG doc. >=20 > Would the authors please re-issue the draft as: >=20 > draft-ietf-l2vpn-vpls-pe-etree-00. >=20 > thanks! >=20 > Nabil & Giles. >=20 > On 23 Aug 2012, at 17:03, Giles Heron wrote: >=20 >> This is a request to gauge consensus as to whether: >>=20 >> http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-06 >>=20 >> should be accepted as an L2VPN WG draft. >>=20 >> We discussed adoption of this draft in Vancouver, and the consensus = of the room seemed to be to adopt it, but of course the list is where we = make decisions :) >>=20 >> Note that we also discussed adoption of the other VPLS E-Tree drafts = in Vancouver and there was very little support. If multiple people = email me asking to adopt one or other of those drafts I'll poll that one = also. >>=20 >> Please review the draft and respond to the list by Thursday September = 6th with comments as to its suitability for WG adoption. >>=20 >> Giles >=20 From giles.heron@gmail.com Fri Sep 21 06:09:26 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 3D95F21F878B for ; Fri, 21 Sep 2012 06:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bgt0k0aNXefD for ; Fri, 21 Sep 2012 06:09:25 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 752CA21F878A for ; Fri, 21 Sep 2012 06:09:25 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so5220657pbb.31 for ; Fri, 21 Sep 2012 06:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=z0zmMrCxjL1ZTvx2NDVTS7jBmrXKMZbAJlqk7e+C5cg=; b=i0UgKd8CBZmO+mw24Xlx7HONPoQ+YTeHa/SoaboSmeqw9JJpi+silt0ghtQ9sZlPtj VwtxzOtCe1HVo0RehNCi7UZrD1VTxvS0ENmsTp9HvTF/z8ZjCuYh+W/Tq0NXiwux4l5g bLUyhYsL3r0rT2CXHeRo6zhjTZVY4Jv8tt62FUh22cdSRq9+AXxL+dNLqFGTZROEilPz q2KSWrjRdgyM/OCh+HCl3S6Y4gfEE1nWf7XyRPyWrwDMF5SaLd5oRK2I04ApngBRgmKh E6/eGwX16/kxTu6jORWKHIWmi5JbqfANVBPSFNTCQUMNSw3P99EMm4+e71N9EvbPqCog lk3Q== Received: by 10.66.81.201 with SMTP id c9mr13034804pay.80.1348232965259; Fri, 21 Sep 2012 06:09:25 -0700 (PDT) Received: from sjc-vpn2-476.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id sj5sm5125301pbc.30.2012.09.21.06.09.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 06:09:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt From: Giles Heron In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> Date: Fri, 21 Sep 2012 14:09:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> To: Jiangyuanlong X-Mailer: Apple Mail (2.1498) 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: Fri, 21 Sep 2012 13:09:26 -0000 Thanks Yuanlong, however I must say that your memory of the IETF 84 L2VPN meeting differs = from mine (and from what is noted in the minutes). Whilst Himanshu said = that it was better to have the same solution for VPLS and E-VPN, Ali = stated that there was no benefit in the E-VPN case in using an = additional tag (such as a VLAN). No consensus was reached in the = meeting. Giles On 21 Sep 2012, at 10:16, Jiangyuanlong = wrote: > Hi all, >=20 > During the 84th IETF meeting, the group discussed the issue of E-Tree = in E-VPN, and it was shown that a single solution was more preferred = than two different approaches for VPLS and E-VPN. > This I-D probes how the 2VLAN approach can be used to support E-Tree = in E-VPN and it seems not a big issue. > Any comments from you are greatly appreciated. >=20 > Best regards, > Yuanlong >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Friday, September 21, 2012 4:55 PM > To: Jiangyuanlong > Subject: New Version Notification for = draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >=20 >=20 > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > has been successfully submitted by Yuanlong Jiang and posted to the > IETF repository. >=20 > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > Revision: 00 > Title: E-Tree Support with 2VLAN in E-VPN > Creation date: 2012-09-21 > WG ID: Individual Submission > Number of pages: 6 > URL: = http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00.= txt > Status: = http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan > Htmlized: = http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >=20 >=20 > Abstract: > This document discusses how the Dual-VLAN approach as described in > [Etree-vlan] can be used to support the transport of E-Tree service > in E-VPN. Thus a single convergent solution is possible for both = VPLS > and E-VPN. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From jiangyuanlong@huawei.com Fri Sep 21 19:34:02 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 06A8B21E80A3 for ; Fri, 21 Sep 2012 19:34:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEB44c8MZ6S7 for ; Fri, 21 Sep 2012 19:34:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D704F21E8050 for ; Fri, 21 Sep 2012 19:34:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJX22233; Sat, 22 Sep 2012 02:34:00 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 03:31:31 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 03:32:00 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Sat, 22 Sep 2012 10:31:56 +0800 From: Jiangyuanlong To: Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNl9bO5vMHP1fUbUG3AEjOw2TsF5eUffmw///A2YCAAVUrAA== Date: Sat, 22 Sep 2012 02:31:55 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> In-Reply-To: <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.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.95] 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: Sat, 22 Sep 2012 02:34:02 -0000 Hi Giles, Perhaps the gauge of the consensus in the minutes was not so clear for me: " Giles - are we agreed we want to get to one solution for VPLS and= E-VPN. Not many people. But even fewer who want multiple. Checked to s= ee if people want one solution only for E-VPN and VPLS - only a couple = of hands." Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus to = decide which way to take.=20 Thanks, Yuanlong -----Original Message----- From: Giles Heron [mailto:giles.heron@gmail.com]=20 Sent: Friday, September 21, 2012 9:09 PM To: Jiangyuanlong Cc: l2vpn@ietf.org Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Thanks Yuanlong, however I must say that your memory of the IETF 84 L2VPN meeting differs fr= om mine (and from what is noted in the minutes). Whilst Himanshu said that= it was better to have the same solution for VPLS and E-VPN, Ali stated tha= t there was no benefit in the E-VPN case in using an additional tag (such a= s a VLAN). No consensus was reached in the meeting. Giles On 21 Sep 2012, at 10:16, Jiangyuanlong wrote: > Hi all, >=20 > During the 84th IETF meeting, the group discussed the issue of E-Tree in = E-VPN, and it was shown that a single solution was more preferred than two = different approaches for VPLS and E-VPN. > This I-D probes how the 2VLAN approach can be used to support E-Tree in E= -VPN and it seems not a big issue. > Any comments from you are greatly appreciated. >=20 > Best regards, > Yuanlong >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Friday, September 21, 2012 4:55 PM > To: Jiangyuanlong > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-= 00.txt >=20 >=20 > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > has been successfully submitted by Yuanlong Jiang and posted to the > IETF repository. >=20 > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > Revision: 00 > Title: E-Tree Support with 2VLAN in E-VPN > Creation date: 2012-09-21 > WG ID: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-ev= pn-etree-2vlan-00.txt > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-e= tree-2vlan > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-= 2vlan-00 >=20 >=20 > Abstract: > This document discusses how the Dual-VLAN approach as described in > [Etree-vlan] can be used to support the transport of E-Tree service > in E-VPN. Thus a single convergent solution is possible for both VPLS > and E-VPN. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From aldrin.isaac@gmail.com Sat Sep 22 08:30: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 9437D21F86CB for ; Sat, 22 Sep 2012 08:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+QMYYs1ZiGX for ; Sat, 22 Sep 2012 08:30:15 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9021F86DE for ; Sat, 22 Sep 2012 08:30:15 -0700 (PDT) Received: by qcac10 with SMTP id c10so3879255qca.31 for ; Sat, 22 Sep 2012 08:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=o8S+zwbQl054rRx81wsx+ElN1Q6T0QtTAgxoT6/WVE8=; b=E1/GPMTbvXffNrXwA3d8yyQUCZGunU12OutMwouszH5smPfiH15DbjCzWXHu4uBkCG ZL/kFjuMk/AcMDqi1a4AfT+ymmC/dlITziRoY/PONCHirIF1/WjLXCCqoYBOpsPgU9Ir +SsNw5J8EWcweKhn0nWFQa7LNym3j4Zvr3kBtvCL0n+Gf31996t1IlkvRdGl9MqUw3QA KE44Fmjw30ai4RFLMl3cxfbcA0t9H4PMrSQbTxnp8tJ4JUv2RFr6ka7r8z3/mSJVvXMB 1ZP/ZjznTh2ug16d9Zj/adGQhlUn8ojMHncNCW/VBeMEoUXLEVFHjGgwUFRCzPHG10OL 3z4Q== Received: by 10.229.137.147 with SMTP id w19mr5378790qct.58.1348327815094; Sat, 22 Sep 2012 08:30:15 -0700 (PDT) Received: from [192.168.1.106] (ool-435183d3.dyn.optonline.net. [67.81.131.211]) by mx.google.com with ESMTPS id fy1sm17206761qab.10.2012.09.22.08.30.13 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Sep 2012 08:30:14 -0700 (PDT) Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Aldrin Isaac In-Reply-To: <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> Date: Sat, 22 Sep 2012 11:28:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C71D41E-7859-4073-A699-BCD1739151AE@gmail.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> To: Giles Heron X-Mailer: Apple Mail (2.1278) Cc: "l2vpn@ietf.org" , Jiangyuanlong 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: Sat, 22 Sep 2012 15:30:16 -0000 In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as = in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB = export RTA at spokes) with filtering to enforce downstream data flow if = desired. The tree could be built using PIM, mLDP, RSVP, etc. On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: > Thanks Yuanlong, >=20 > however I must say that your memory of the IETF 84 L2VPN meeting = differs from mine (and from what is noted in the minutes). Whilst = Himanshu said that it was better to have the same solution for VPLS and = E-VPN, Ali stated that there was no benefit in the E-VPN case in using = an additional tag (such as a VLAN). No consensus was reached in the = meeting. >=20 > Giles >=20 > On 21 Sep 2012, at 10:16, Jiangyuanlong = wrote: >=20 >> Hi all, >>=20 >> During the 84th IETF meeting, the group discussed the issue of E-Tree = in E-VPN, and it was shown that a single solution was more preferred = than two different approaches for VPLS and E-VPN. >> This I-D probes how the 2VLAN approach can be used to support E-Tree = in E-VPN and it seems not a big issue. >> Any comments from you are greatly appreciated. >>=20 >> Best regards, >> Yuanlong >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Friday, September 21, 2012 4:55 PM >> To: Jiangyuanlong >> Subject: New Version Notification for = draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>=20 >>=20 >> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> has been successfully submitted by Yuanlong Jiang and posted to the >> IETF repository. >>=20 >> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >> Revision: 00 >> Title: E-Tree Support with 2VLAN in E-VPN >> Creation date: 2012-09-21 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: = http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00.= txt >> Status: = http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >> Htmlized: = http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>=20 >>=20 >> Abstract: >> This document discusses how the Dual-VLAN approach as described in >> [Etree-vlan] can be used to support the transport of E-Tree service >> in E-VPN. Thus a single convergent solution is possible for both = VPLS >> and E-VPN. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 From josh.rogers@twcable.com Sat Sep 22 09:48:48 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 A7B8F21F8622 for ; Sat, 22 Sep 2012 09:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6Dp-B7-zpG8 for ; Sat, 22 Sep 2012 09:48:48 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D975D21F861E for ; Sat, 22 Sep 2012 09:48:47 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,467,1344225600"; d="scan'208";a="424397955" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Sep 2012 12:47:55 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Sat, 22 Sep 2012 12:48:44 -0400 From: "Rogers, Josh" To: Aldrin Isaac , Giles Heron Date: Sat, 22 Sep 2012 12:48:43 -0400 Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: Ac2Y4iB3/+SU1xE+QrOivbsGgYI1tg== Message-ID: In-Reply-To: <5C71D41E-7859-4073-A699-BCD1739151AE@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Jiangyuanlong 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: Sat, 22 Sep 2012 16:48:48 -0000 So, this same sort of 'import/export' of targets is possible using BGP-VPLS today, but it faces limitations outlined in draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 may import RTA, while AC2 on PE2 may import RTB? Its occurred to me that EVPN would be able to use other mechanisms that have not yet been discussed yet due to sharing a mac table over BGP. Thanks for the response, Josh On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB >export RTA at spokes) with filtering to enforce downstream data flow if >desired. The tree could be built using PIM, mLDP, RSVP, etc. > > > >On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: > >> Thanks Yuanlong, >> >> however I must say that your memory of the IETF 84 L2VPN meeting >>differs from mine (and from what is noted in the minutes). Whilst >>Himanshu said that it was better to have the same solution for VPLS and >>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>an additional tag (such as a VLAN). No consensus was reached in the >>meeting. >> >> Giles >> >> On 21 Sep 2012, at 10:16, Jiangyuanlong >>wrote: >> >>> Hi all, >>> >>> During the 84th IETF meeting, the group discussed the issue of E-Tree >>>in E-VPN, and it was shown that a single solution was more preferred >>>than two different approaches for VPLS and E-VPN. >>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>in E-VPN and it seems not a big issue. >>> Any comments from you are greatly appreciated. >>> >>> Best regards, >>> Yuanlong >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Friday, September 21, 2012 4:55 PM >>> To: Jiangyuanlong >>> Subject: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>> >>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> has been successfully submitted by Yuanlong Jiang and posted to the >>> IETF repository. >>> >>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>> Revision: 00 >>> Title: E-Tree Support with 2VLAN in E-VPN >>> Creation date: 2012-09-21 >>> WG ID: Individual Submission >>> Number of pages: 6 >>> URL: >>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-0 >>>0.txt >>> Status: >>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>> Htmlized: >>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>> >>> >>> Abstract: >>> This document discusses how the Dual-VLAN approach as described in >>> [Etree-vlan] can be used to support the transport of E-Tree service >>> in E-VPN. Thus a single convergent solution is possible for both VPLS >>> and E-VPN. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> > 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 aldrin.isaac@gmail.com Sat Sep 22 12:48:24 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 66B4D21F869E for ; Sat, 22 Sep 2012 12:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmIbrV7YX3R7 for ; Sat, 22 Sep 2012 12:48:23 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECB9D21F8575 for ; Sat, 22 Sep 2012 12:48:22 -0700 (PDT) Received: by bkty12 with SMTP id y12so2232651bkt.31 for ; Sat, 22 Sep 2012 12:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VGfx9o7FTVXrL1XIqZzlyqEPmKrpHbTRM8W+5s8ymiU=; b=PYaVef+JqsftDcxr/3+4RlmljnNgumBFkpOvvEdVsOuemfKv1yBUBi/ZDW0VzoTQ9u tC9fb7p1HQ/lYeHLo2wQTc0IGa11AMIVEj/CXS/EHrEmjuFKM6bVtFpobeINNVofE1ym x4GvNgM8mHxlWDPlGsVRTwtwcvWNr+JwA1wGcibZqnzI90X464fnmBTgOlqz+vVez0hr 1fzyY7SlBUP3wgtFAnHBx+JqWit95zueTnoSGFD+B3Flbv8/SYFl55LfA8HuTqS/rGLO NTso5zcRzd5Ur+4qsgnX5RENl/ASKUCddcTUZWW6keocYvWar3qjB/j/IgdDg6ZslXyy mr7g== MIME-Version: 1.0 Received: by 10.204.147.1 with SMTP id j1mr3390544bkv.110.1348343301796; Sat, 22 Sep 2012 12:48:21 -0700 (PDT) Received: by 10.204.37.7 with HTTP; Sat, 22 Sep 2012 12:48:21 -0700 (PDT) In-Reply-To: References: <5C71D41E-7859-4073-A699-BCD1739151AE@gmail.com> Date: Sat, 22 Sep 2012 15:48:21 -0400 Message-ID: Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt From: Aldrin Isaac To: "Rogers, Josh" Content-Type: multipart/alternative; boundary=0015174be97489f56404ca4fa317 Cc: "l2vpn@ietf.org" , Jiangyuanlong 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: Sat, 22 Sep 2012 19:48:24 -0000 --0015174be97489f56404ca4fa317 Content-Type: text/plain; charset=ISO-8859-1 Yes, as long as the leaf and root AC or MAC can have different local contexts against which different RT can be associated. Implementations may support RT import/export at a virtual switch level, VLAN level, port level, or even down to MAC level. The fact that EVPN can advertise a label for MAC routes down to individual MAC makes it possible to create topologies at MAC level. MAC routes can even have more than one RT. I suppose you can even run in a VPLS mode with dataplane MAC learning at edges with topologies possible at an ESI+tag granularity. On Saturday, September 22, 2012, Rogers, Josh wrote: > So, this same sort of 'import/export' of targets is possible using > BGP-VPLS today, but it faces limitations outlined in > draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to > import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 > may import RTA, while AC2 on PE2 may import RTB? > > Its occurred to me that EVPN would be able to use other mechanisms that > have not yet been discussed yet due to sharing a mac table over BGP. > > Thanks for the response, > Josh > > > On 9/22/12 10:28 AM, "Aldrin Isaac" > > wrote: > > >In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as > >in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB > >export RTA at spokes) with filtering to enforce downstream data flow if > >desired. The tree could be built using PIM, mLDP, RSVP, etc. > > > > > > > >On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: > > > >> Thanks Yuanlong, > >> > >> however I must say that your memory of the IETF 84 L2VPN meeting > >>differs from mine (and from what is noted in the minutes). Whilst > >>Himanshu said that it was better to have the same solution for VPLS and > >>E-VPN, Ali stated that there was no benefit in the E-VPN case in using > >>an additional tag (such as a VLAN). No consensus was reached in the > >>meeting. > >> > >> Giles > >> > >> On 21 Sep 2012, at 10:16, Jiangyuanlong > > > >>wrote: > >> > >>> Hi all, > >>> > >>> During the 84th IETF meeting, the group discussed the issue of E-Tree > >>>in E-VPN, and it was shown that a single solution was more preferred > >>>than two different approaches for VPLS and E-VPN. > >>> This I-D probes how the 2VLAN approach can be used to support E-Tree > >>>in E-VPN and it seems not a big issue. > >>> Any comments from you are greatly appreciated. > >>> > >>> Best regards, > >>> Yuanlong > >>> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto: > internet-drafts@ietf.org ] > >>> Sent: Friday, September 21, 2012 4:55 PM > >>> To: Jiangyuanlong > >>> Subject: New Version Notification for > >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >>> > >>> > >>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >>> has been successfully submitted by Yuanlong Jiang and posted to the > >>> IETF repository. > >>> > >>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan > >>> Revision: 00 > >>> Title: E-Tree Support with 2VLAN in E-VPN > >>> Creation date: 2012-09-21 > >>> WG ID: Individual Submission > >>> Number of pages: 6 > >>> URL: > >>> > http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-0 > >>>0.txt > >>> Status: > >>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan > >>> Htmlized: > >>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 > >>> > >>> > >>> Abstract: > >>> This document discusses how the Dual-VLAN approach as described in > >>> [Etree-vlan] can be used to support the transport of E-Tree service > >>> in E-VPN. Thus a single convergent solution is possible for both VPLS > >>> and E-VPN. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >>> > >> > > > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use 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 dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > --0015174be97489f56404ca4fa317 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, as long as the leaf and root AC or MAC can have different local contex= ts against which different RT can be associated.=A0

Implementations may support RT import/export at a virtual switch level, = VLAN level, port level, or even down to MAC level. =A0The fact that EVPN ca= n advertise a label for MAC routes down to individual MAC makes it possible= to create topologies at MAC level. =A0MAC routes can even =A0have more tha= n one RT. =A0I suppose you can even run in a VPLS mode with dataplane MAC l= earning at edges with topologies possible at an ESI+tag granularity.=A0

On Saturday, September 22, 2012, Rogers, Josh wrote:
So, this same sort of 'import/export' of targets i= s possible using
BGP-VPLS today, but it faces limitations outlined in
draft-ietf-l2vpn-etree-frwk, in section 2. =A0E-VPN would be able to
import/export by attachment circuit, and not by PE? =A0Meaning, AC1 one PE1=
may import RTA, while AC2 on PE2 may import RTB?

Its occurred to me that EVPN would be able to use other mechanisms that
have not yet been discussed yet due to sharing a mac table over BGP.

Thanks for the response,
Josh


On 9/22/12 10:28 AM, "Aldrin Isaac" <ald= rin.isaac@gmail.com> wrote:

>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as=
>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RT= B
>export RTA at spokes) with filtering to enforce downstream data flow if=
>desired. =A0The tree could be built using PIM, mLDP, RSVP, etc.
>
>
>
>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote:
>
>> Thanks Yuanlong,
>>
>> however I must say that your memory of the IETF 84 L2VPN meeting >>differs from mine (and from what is noted in the minutes). =A0Whils= t
>>Himanshu said that it was better to have the same solution for VPLS= and
>>E-VPN, Ali stated that there was no benefit in the E-VPN case in us= ing
>>an additional tag (such as a VLAN). =A0No consensus was reached in = the
>>meeting.
>>
>> Giles
>>
>> On 21 Sep 2012, at 10:16, Jiangyuanlong <internet-drafts@ietf.org [ma= ilto:internet-drafts@ietf.org]
>>> Sent: Friday, September 21, 2012 4:55 PM
>>> To: Jiangyuanlong
>>> Subject: New Version Notification for
>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
>>>
>>>
>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.tx= t
>>> has been successfully submitted by Yuanlong Jiang and posted t= o the
>>> IETF repository.
>>>
>>> Filename: =A0 =A0draft-jiang-l2vpn-evpn-etree-2vlan
>>> Revision: =A0 =A000
>>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 E-Tree Support with 2VLAN i= n E-VPN
>>> Creation date: =A0 =A0 =A0 2012-09-21
>>> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
>>> Number of pages: 6
>>> URL:
>>>http://www.ietf.org/internet-drafts= /draft-jiang-l2vpn-evpn-etree-2vlan-0
>>>0.txt
>>> Status:
>>>http://datatracker.ietf.org/doc/draft-jia= ng-l2vpn-evpn-etree-2vlan
>>> Htmlized:
>>>http://tools.ietf.org/html/draft-jiang-l2vp= n-evpn-etree-2vlan-00
>>>
>>>
>>> Abstract:
>>> =A0This document discusses how the Dual-VLAN approach as descr= ibed in
>>> =A0[Etree-vlan] can be used to support the transport of E-Tree= service
>>> =A0in E-VPN. Thus a single convergent solution is possible for= both VPLS
>>> =A0and E-VPN.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>
>


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.
--0015174be97489f56404ca4fa317-- From josh.rogers@twcable.com Sat Sep 22 14:31: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 C77A921F8557 for ; Sat, 22 Sep 2012 14:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G-hIlG3waz3 for ; Sat, 22 Sep 2012 14:31:01 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 276BD21F8555 for ; Sat, 22 Sep 2012 14:31:00 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,468,1344225600"; d="scan'208";a="424459218" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Sep 2012 17:30:09 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Sat, 22 Sep 2012 17:30:59 -0400 From: "Rogers, Josh" To: Aldrin Isaac , Giles Heron Date: Sat, 22 Sep 2012 17:30:59 -0400 Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: Ac2ZCY7eviTIka4ATBaVr6Scvj7B/w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Jiangyuanlong 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: Sat, 22 Sep 2012 21:31:01 -0000 Sorry, allow me to re-type correctly this statement: Meaning, AC1 on PE1 may import RTA, while AC2 on PE1 may import RTB? Thank you for the explanation Aldrin. -Josh On 9/22/12 11:48 AM, "Rogers, Josh" wrote: >So, this same sort of 'import/export' of targets is possible using >BGP-VPLS today, but it faces limitations outlined in >draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 >may import RTA, while AC2 on PE2 may import RTB? > >Its occurred to me that EVPN would be able to use other mechanisms that >have not yet been discussed yet due to sharing a mac table over BGP. > >Thanks for the response, >Josh > > >On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: > >>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB >>export RTA at spokes) with filtering to enforce downstream data flow if >>desired. The tree could be built using PIM, mLDP, RSVP, etc. >> >> >> >>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >> >>> Thanks Yuanlong, >>> >>> however I must say that your memory of the IETF 84 L2VPN meeting >>>differs from mine (and from what is noted in the minutes). Whilst >>>Himanshu said that it was better to have the same solution for VPLS and >>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>an additional tag (such as a VLAN). No consensus was reached in the >>>meeting. >>> >>> Giles >>> >>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>wrote: >>> >>>> Hi all, >>>> >>>> During the 84th IETF meeting, the group discussed the issue of E-Tree >>>>in E-VPN, and it was shown that a single solution was more preferred >>>>than two different approaches for VPLS and E-VPN. >>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>in E-VPN and it seems not a big issue. >>>> Any comments from you are greatly appreciated. >>>> >>>> Best regards, >>>> Yuanlong >>>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Friday, September 21, 2012 4:55 PM >>>> To: Jiangyuanlong >>>> Subject: New Version Notification for >>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> >>>> >>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>> Revision: 00 >>>> Title: E-Tree Support with 2VLAN in E-VPN >>>> Creation date: 2012-09-21 >>>> WG ID: Individual Submission >>>> Number of pages: 6 >>>> URL: >>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan- >>>>0 >>>>0.txt >>>> Status: >>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>> Htmlized: >>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>> >>>> >>>> Abstract: >>>> This document discusses how the Dual-VLAN approach as described in >>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>> in E-VPN. Thus a single convergent solution is possible for both VPLS >>>> and E-VPN. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >> > 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 ju1738@att.com Sat Sep 22 14:57: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 4C7A421F8618 for ; Sat, 22 Sep 2012 14:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyYZHN3YC9P1 for ; Sat, 22 Sep 2012 14:57:37 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 44A7321F8617 for ; Sat, 22 Sep 2012 14:57:37 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id 1543e505.2aaad160e940.2385768.00-563.6666654.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 22 Sep 2012 21:57:37 +0000 (UTC) X-MXL-Hash: 505e34510c9bdd20-73f4ff18f7584e22646f70ff2ba9293d6932c2b5 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 8443e505.0.2385733.00-327.6666557.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 22 Sep 2012 21:57:30 +0000 (UTC) X-MXL-Hash: 505e344a0d7ea847-51fe2a1f77d02067cf900da9a684ba73ec44c36c Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8MLvSqw028810; Sat, 22 Sep 2012 17:57:28 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8MLvGo7028751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Sep 2012 17:57:16 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint02.pst.cso.att.com (RSA Interceptor); Sat, 22 Sep 2012 17:56:57 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0318.001; Sat, 22 Sep 2012 17:56:57 -0400 From: "UTTARO, JAMES" To: "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmNbd5vMHP1fUbUG3AEjOw2TsF5eW1aCAgAASjrA= Date: Sat, 22 Sep 2012 21:56:56 +0000 Message-ID: References: <5C71D41E-7859-4073-A699-BCD1739151AE@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.36.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=H51sNZki c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=LLtwuZJXmZIA:10 a=BbnZtKN_HuwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=SqYf66d-MNQA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8] X-AnalysisOut: [ a=i0EeH86SAAAA:8 a=aMuzPGL9AmlEYYLmxpEA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=MSl-tDqOz04A:10 a=hPjdaMEvmhQA:10 a] X-AnalysisOut: [=eCkFXicr0sz2JFnB:21 a=q_nHHS8GrvKTZBS1:21] Cc: "l2vpn@ietf.org" , Jiangyuanlong 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: Sat, 22 Sep 2012 21:57:38 -0000 EVPN is intended to maximize the flexibility of multiple routing contexts w= ith arbitrary topologies.. As I have stated in the past, EVPN allows for E-= Tree to be constructed in the control plane, other solutions require some m= ethod to interrogate data and infer topology. IMO this is not desirable. Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: Saturday, September 22, 2012 12:49 PM To: Aldrin Isaac; Giles Heron Cc: l2vpn@ietf.org; Jiangyuanlong Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt So, this same sort of 'import/export' of targets is possible using BGP-VPLS today, but it faces limitations outlined in draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 may import RTA, while AC2 on PE2 may import RTB? Its occurred to me that EVPN would be able to use other mechanisms that have not yet been discussed yet due to sharing a mac table over BGP. Thanks for the response, Josh On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB >export RTA at spokes) with filtering to enforce downstream data flow if >desired. The tree could be built using PIM, mLDP, RSVP, etc. > > > >On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: > >> Thanks Yuanlong, >> >> however I must say that your memory of the IETF 84 L2VPN meeting >>differs from mine (and from what is noted in the minutes). Whilst >>Himanshu said that it was better to have the same solution for VPLS and >>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>an additional tag (such as a VLAN). No consensus was reached in the >>meeting. >> >> Giles >> >> On 21 Sep 2012, at 10:16, Jiangyuanlong >>wrote: >> >>> Hi all, >>> >>> During the 84th IETF meeting, the group discussed the issue of E-Tree >>>in E-VPN, and it was shown that a single solution was more preferred >>>than two different approaches for VPLS and E-VPN. >>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>in E-VPN and it seems not a big issue. >>> Any comments from you are greatly appreciated. >>> >>> Best regards, >>> Yuanlong >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Friday, September 21, 2012 4:55 PM >>> To: Jiangyuanlong >>> Subject: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>> >>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> has been successfully submitted by Yuanlong Jiang and posted to the >>> IETF repository. >>> >>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>> Revision: 00 >>> Title: E-Tree Support with 2VLAN in E-VPN >>> Creation date: 2012-09-21 >>> WG ID: Individual Submission >>> Number of pages: 6 >>> URL: >>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-0 >>>0.txt >>> Status: >>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>> Htmlized: >>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>> >>> >>> Abstract: >>> This document discusses how the Dual-VLAN approach as described in >>> [Etree-vlan] can be used to support the transport of E-Tree service >>> in E-VPN. Thus a single convergent solution is possible for both VPLS >>> and E-VPN. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> > 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 josh.rogers@twcable.com Sat Sep 22 16:03:24 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 7288921F8559 for ; Sat, 22 Sep 2012 16:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJW4ttgeJsTK for ; Sat, 22 Sep 2012 16:03:23 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8D81421F852A for ; Sat, 22 Sep 2012 16:03:23 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,468,1344225600"; d="scan'208";a="442749318" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Sep 2012 19:02:53 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Sat, 22 Sep 2012 19:03:22 -0400 From: "Rogers, Josh" To: "UTTARO, JAMES" , Aldrin Isaac , Giles Heron Date: Sat, 22 Sep 2012 19:03:22 -0400 Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: Ac2ZFnZfQ14nxGVHQG6wtDALYQb4LQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Jiangyuanlong 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: Sat, 22 Sep 2012 23:03:24 -0000 I agree. Would it be safe to state that VPLS has a need for a 'etree solution', but EVPN does not, because it is inherently supported? The previously discussed effort of having a 'single etree solution' for both VPLS and EVPN may not really be valid due to this. In fact, I do not think it is valid to ask for a single solution, EVPN doesn't have a problem that needs to be fixed here, I don't believe it factors into this discussion. -Josh On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >EVPN is intended to maximize the flexibility of multiple routing contexts >with arbitrary topologies.. As I have stated in the past, EVPN allows for >E-Tree to be constructed in the control plane, other solutions require >some method to interrogate data and infer topology. IMO this is not >desirable. > >Jim Uttaro > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Saturday, September 22, 2012 12:49 PM >To: Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >So, this same sort of 'import/export' of targets is possible using >BGP-VPLS today, but it faces limitations outlined in >draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 >may import RTA, while AC2 on PE2 may import RTB? > >Its occurred to me that EVPN would be able to use other mechanisms that >have not yet been discussed yet due to sharing a mac table over BGP. > >Thanks for the response, >Josh > > >On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: > >>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB >>export RTA at spokes) with filtering to enforce downstream data flow if >>desired. The tree could be built using PIM, mLDP, RSVP, etc. >> >> >> >>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >> >>> Thanks Yuanlong, >>> >>> however I must say that your memory of the IETF 84 L2VPN meeting >>>differs from mine (and from what is noted in the minutes). Whilst >>>Himanshu said that it was better to have the same solution for VPLS and >>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>an additional tag (such as a VLAN). No consensus was reached in the >>>meeting. >>> >>> Giles >>> >>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>wrote: >>> >>>> Hi all, >>>> >>>> During the 84th IETF meeting, the group discussed the issue of E-Tree >>>>in E-VPN, and it was shown that a single solution was more preferred >>>>than two different approaches for VPLS and E-VPN. >>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>in E-VPN and it seems not a big issue. >>>> Any comments from you are greatly appreciated. >>>> >>>> Best regards, >>>> Yuanlong >>>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Friday, September 21, 2012 4:55 PM >>>> To: Jiangyuanlong >>>> Subject: New Version Notification for >>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> >>>> >>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>> Revision: 00 >>>> Title: E-Tree Support with 2VLAN in E-VPN >>>> Creation date: 2012-09-21 >>>> WG ID: Individual Submission >>>> Number of pages: 6 >>>> URL: >>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan- >>>>0 >>>>0.txt >>>> Status: >>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>> Htmlized: >>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>> >>>> >>>> Abstract: >>>> This document discusses how the Dual-VLAN approach as described in >>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>> in E-VPN. Thus a single convergent solution is possible for both VPLS >>>> and E-VPN. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use 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 dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. 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 ju1738@att.com Sat Sep 22 16:35:21 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 8A6C321F85F9 for ; Sat, 22 Sep 2012 16:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-Qjn-fezMHe for ; Sat, 22 Sep 2012 16:35:20 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9DE21F85F4 for ; Sat, 22 Sep 2012 16:35:19 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id 73b4e505.55054940.1365521.00-567.3829028.nbfkord-smmo04.seg.att.com (envelope-from ); Sat, 22 Sep 2012 23:35:19 +0000 (UTC) X-MXL-Hash: 505e4b373cb9eda9-5d6ba160ab19a722c430e94e5c310bc1e26bd6af Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id d2b4e505.0.1365477.00-241.3828927.nbfkord-smmo04.seg.att.com (envelope-from ); Sat, 22 Sep 2012 23:35:10 +0000 (UTC) X-MXL-Hash: 505e4b2e1692ac9f-0ccfe5ecbeaf12cf99c9fef06950ee906fa3aeaa Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8MNZ8l6004405; Sat, 22 Sep 2012 16:35:08 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8MNYvml004312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Sep 2012 16:34:59 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint04.pst.cso.att.com (RSA Interceptor); Sat, 22 Sep 2012 16:34:29 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0318.001; Sat, 22 Sep 2012 19:34:28 -0400 From: "UTTARO, JAMES" To: "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmNbd5vMHP1fUbUG3AEjOw2TsF5eW1aCAgAASjrCAAFYfAP//xDpA Date: Sat, 22 Sep 2012 23:34:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.36.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=NLBiDTGg c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=LLtwuZJXmZIA:10 a=BbnZtKN_HuwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=SqYf66d-MNQA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8] X-AnalysisOut: [ a=i0EeH86SAAAA:8 a=fibGOYt6Ot700gJy01oA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=MSl-tDqOz04A:10 a] X-AnalysisOut: [=hPjdaMEvmhQA:10 a=1l0fqOYyzzkDnF9A:21 a=_vWtb1C05cmShFLt:] X-AnalysisOut: [21] Cc: "l2vpn@ietf.org" , Jiangyuanlong 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: Sat, 22 Sep 2012 23:35:21 -0000 Josh, Yes.. I think that is the reality of it.. VPLS either the LDP or BGP varie= ty uses data plane learning as the mechanism to "learn".. The fact that we = extend the L2 footprint via these "tunnels" does not change that fact.. SO = in VPLS the only hammer you have is the data plane, so one must manipulate = bits on the wire to infer topology ( Limited set of topology ).. Another challenge is when roots and leafs "land" on the same PE. EVPN is intended to use contexts and associated import/export to manage the= topology.. So here there is a set of tools to create the desired topologie= s, along with that there other mechanisms realized i.e active/active... Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: Saturday, September 22, 2012 7:03 PM To: UTTARO, JAMES; Aldrin Isaac; Giles Heron Cc: l2vpn@ietf.org; Jiangyuanlong Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt I agree. Would it be safe to state that VPLS has a need for a 'etree solution', but EVPN does not, because it is inherently supported? The previously discussed effort of having a 'single etree solution' for both VPLS and EVPN may not really be valid due to this. In fact, I do not think it is valid to ask for a single solution, EVPN doesn't have a problem that needs to be fixed here, I don't believe it factors into this discussion. -Josh On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >EVPN is intended to maximize the flexibility of multiple routing contexts >with arbitrary topologies.. As I have stated in the past, EVPN allows for >E-Tree to be constructed in the control plane, other solutions require >some method to interrogate data and infer topology. IMO this is not >desirable. > >Jim Uttaro > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Saturday, September 22, 2012 12:49 PM >To: Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >So, this same sort of 'import/export' of targets is possible using >BGP-VPLS today, but it faces limitations outlined in >draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 >may import RTA, while AC2 on PE2 may import RTB? > >Its occurred to me that EVPN would be able to use other mechanisms that >have not yet been discussed yet due to sharing a mac table over BGP. > >Thanks for the response, >Josh > > >On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: > >>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB >>export RTA at spokes) with filtering to enforce downstream data flow if >>desired. The tree could be built using PIM, mLDP, RSVP, etc. >> >> >> >>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >> >>> Thanks Yuanlong, >>> >>> however I must say that your memory of the IETF 84 L2VPN meeting >>>differs from mine (and from what is noted in the minutes). Whilst >>>Himanshu said that it was better to have the same solution for VPLS and >>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>an additional tag (such as a VLAN). No consensus was reached in the >>>meeting. >>> >>> Giles >>> >>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>wrote: >>> >>>> Hi all, >>>> >>>> During the 84th IETF meeting, the group discussed the issue of E-Tree >>>>in E-VPN, and it was shown that a single solution was more preferred >>>>than two different approaches for VPLS and E-VPN. >>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>in E-VPN and it seems not a big issue. >>>> Any comments from you are greatly appreciated. >>>> >>>> Best regards, >>>> Yuanlong >>>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Friday, September 21, 2012 4:55 PM >>>> To: Jiangyuanlong >>>> Subject: New Version Notification for >>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> >>>> >>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>> Revision: 00 >>>> Title: E-Tree Support with 2VLAN in E-VPN >>>> Creation date: 2012-09-21 >>>> WG ID: Individual Submission >>>> Number of pages: 6 >>>> URL: >>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan- >>>>0 >>>>0.txt >>>> Status: >>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>> Htmlized: >>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>> >>>> >>>> Abstract: >>>> This document discusses how the Dual-VLAN approach as described in >>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>> in E-VPN. Thus a single convergent solution is possible for both VPLS >>>> and E-VPN. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use 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 dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. 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 Alexander.Vainshtein@ecitele.com Sun Sep 23 01:25:07 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 BAD5E21F847D for ; Sun, 23 Sep 2012 01:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otr18rGxQdBr for ; Sun, 23 Sep 2012 01:25:05 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32621F847C for ; Sun, 23 Sep 2012 01:25:03 -0700 (PDT) Received: from [85.158.139.211:36280] by server-3.bemta-5.messagelabs.com id 6A/AD-21836-E57CE505; Sun, 23 Sep 2012 08:25:02 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1348388701!19596373!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 14576 invoked from network); 23 Sep 2012 08:25:02 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-2.tower-206.messagelabs.com with SMTP; 23 Sep 2012 08:25:02 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-90-505ec2bbdd96 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id F5.07.06426.BB2CE505; Sun, 23 Sep 2012 10:05:15 +0200 (IST) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Sun, 23 Sep 2012 10:25:01 +0200 Received: from ILPTWPVEXMB03.ecitele.com ([fe80::91b4:8f74:ce44:f190]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.01.0379.000; Sun, 23 Sep 2012 10:25:00 +0200 From: Alexander Vainshtein To: Jiangyuanlong , Giles Heron , Himanshu Shah , Ali Sajassi Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNl9bO5vMHP1fUbUG3AEjOw2TsF5eUffmwgAAUqoCAAOBBgIACI93w Date: Sun, 23 Sep 2012 08:24:59 +0000 Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020BA7CA63ILPTWPVEXMB03ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa2wUVRTOndnZnT4Gp9uWXjaETK6iEV3sWgmLdhtIgKwxgRUfJAaBYfey M3F3Zp2ZVqo/qNCk6UKgpYB0NaGNC0iLGpqoNTStrjzXNvCjvi0CLbZdhJJKbKzWemfHlv7x z813zvm+8517cy5LOy84XKysGFhTxAiy59qaMuP33GdSmwOlEz8h781zR4C37ttG2vvN3Tq7 d/CPlMN7p2+3bSXjP/jXacafGB21+z9PDDj8tWdvM/5k8k8qwLxSA8pFRVEN0cBCCOtBHwpo cpUYrEaCHPIhDxJiETGIo1gxfEiMxbASQhW55SQpKwJWgmpIVsI+9OwL691e77IVbg+qePhB T9kzuS9Ksi5gd1SUI0IU67oYxgLJmPMrIRwStquaYEhY0LY20VJ/y1Uq1l8PdnQMd9I14NPK OGBZyD8Fe3p3xkEOgfPhlasf2+Mgl3XyPQD2NI8AK+gEMHX4GG0F5wBs7+kDpsTO+2BH+0BW UsS3Alj7zmC2QPOLYW1HdxYX8i/BgZNTDhMX8S/Du+nrtIXXwq5fd1EmthH+VONvjIk5PgAb brQ7LLd+AMd2t2UFOURcd2XMbmJAhp1In6IssxL449BRyroED5Ndl2kLF8PRwX8YCy+Cu072 O8w707wKv2pyWF4F8FLzkM3ETt4N0xfj/7VZAL/84HtbA4CJOQ6J++rEHLVFeRy2nBm3W/gx eLz1Fj2De78YpObmW4CjDRTLkZixLRou9SzFQdnAEbw0qEY7gLVzw51g8uhDKcCzAOVzDSs2 B5yMWKVXR1NgAUuhYu67z0hq3jY1VC2JurRFq4xgPQUgS6MibvmlVwNOLiRWv4k1daa0hjxy I+3KC6rmdhhbykpL/z9AJdyJmo3rnXyY7OxrGMewNtNnIcsiyN05T+wLNBzGO7bLEeN+mWJz zDHyyRhTJofTY2JUl8NWPQ3K2HcPJq8B9sYAOZ02RVWwq4RLmlTepEqVymw38//tnJ6ezoAS 8gyFXK/JyifbPdsvQ6woYvVAV9aK/LDZkqsGPMHvORXfl3/273vJ1z/Mq1PXtW39JTK0IVFe sM+f03RxUxV6dHVn/XDr5Pyht8cPdb///Mi1JcVrV95+i/mou/Dp56SvKbx3/6YfJh/JOz+2 0fNzL1518/K6N05fh5lyiTlW8eQnsYo9B96bOJEW+MWa2xlYNfJ784Vbaw7HF7oy4t76PmTT JdGzhNZ08V9YTaoSWgQAAA== 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: Sun, 23 Sep 2012 08:25:07 -0000 --_000_F9336571731ADE42A5397FC831CEAA020BA7CA63ILPTWPVEXMB03ec_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in t= he E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (o= r more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must so= mehow identify the source AC of the Ethernet frame in this packet, and, in t= he case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s= ) while allowing forwarding to local Root AC(s). This equally applies to reg= ular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame is= a broadcast one (so that no learning is associated with it). And I strongly= doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vl= an- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me: > " Giles - are we agreed we want to get to one solution for VPLS an= d E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a couple= of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus to > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vl= an- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali state= d > that there was no benefit in the E-VPN case in using an additional tag (su= ch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree in= E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= - > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-e= vpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-= etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree= - > 2vlan-00 > > > > > > Abstract: > > This document discusses how the Dual-VLAN approach as described in > > [Etree-vlan] can be used to support the transport of E-Tree service > > in E-VPN. Thus a single convergent solution is possible for both VPLS > > and E-VPN. > > > > > > > > > > The IETF Secretariat > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020BA7CA63ILPTWPVEXMB03ec_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Yuanlong, Giles, Himanshu, Ali and all,=

I have probably missed something important (not be= ing present at the latest IETF meeting).

But I think something is wrong with the statement= "there was no benefit in the E-VPN case in using an additional tag= (such as a VLAN)".

 

IMHO and FWIW the real E-Tree problem is the situa= tion when there are two (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from a= nother such PE, it must somehow identify the source AC of the Ethernet frame= in this packet, and, in the case of it being a leaf AC, prevent its forward= ing to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular VP= LS and E-VPN, e.g., in the case when the contained Ethernet frame is a broad= cast one (so that no learning is associated with it). And I strongly doubt t= his can be achieved without some “tags” in the encapsulation.

 

My 2c,

     Sasha

 

> -----Original Message-----

> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bo= unces@ietf.org] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version Notification for dra= ft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the min= utes was not so clear for me:

> "      &nb= sp;  Giles - are we agreed we want to get to one solution for VPLS and= E-

> VPN.

>        &nb= sp;  Not many people.  But even fewer who want multiple. = ; Checked to see

> if

>        &nb= sp;  people want one solution only for E-VPN and VPLS - only a cou= ple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution= and it is the WG consensus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:giles.heron@gmail.c= om]

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org

> Subject: Re: New Version Notification for dra= ft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Thanks Yuanlong,

>

> however I must say that your memory of the IE= TF 84 L2VPN meeting differs

> from mine (and from what is noted in the minu= tes).  Whilst Himanshu said

> that it was better to have the same solution= for VPLS and E-VPN, Ali stated

> that there was no benefit in the E-VPN case i= n using an additional tag (such as

> a VLAN).  No consensus was reached in th= e meeting.

>

> Giles

>

> On 21 Sep 2012, at 10:16, Jiangyuanlong <<= a href=3D"mailto:jiangyuanlong@huawei.com">jiangyuanlong@huawei.com>

> wrote:

>

> > Hi all,

> >

> > During the 84th IETF meeting, the group= discussed the issue of E-Tree in E-

> VPN, and it was shown that a single solution= was more preferred than two

> different approaches for VPLS and E-VPN.

> > This I-D probes how the 2VLAN approach c= an be used to support E-Tree in

> E-VPN and it seems not a big issue.

> > Any comments from you are greatly apprec= iated.

> >

> > Best regards,

> > Yuanlong

> >

> > -----Original Message-----

> > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org]

> > Sent: Friday, September 21, 2012 4:55 PM=

> > To: Jiangyuanlong

> > Subject: New Version Notification for dr= aft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

> >

> >

> > A new version of I-D, draft-jiang-l2vpn-= evpn-etree-2vlan-00.txt

> > has been successfully submitted by Yuanl= ong Jiang and posted to the

> > IETF repository.

> >

> > Filename:     draft-= jiang-l2vpn-evpn-etree-2vlan

> > Revision:     = 00

> > Title:     &nbs= p;            &n= bsp;            E-Tre= e Support with 2VLAN in E-VPN

> > Creation date:    &n= bsp;       2012-09-21

> > WG ID:     &nbs= p;            &n= bsp;        Individual Submission

> > Number of pages: 6

> > URL:      =        http://www.ietf.org/in= ternet-drafts/draft-jiang-l2vpn-evpn-

> etree-2vlan-00.txt

> > Status:     &nb= sp;    http://datatracker.iet= f.org/doc/draft-jiang-l2vpn-evpn-etree-

> 2vlan

> > Htmlized:     &= nbsp;  http://tools.ietf.org/= html/draft-jiang-l2vpn-evpn-etree-

> 2vlan-00

> >

> >

> > Abstract:

> >   This document discusses how= the Dual-VLAN approach as described in

> >   [Etree-vlan] can be used to= support the transport of E-Tree service

> >   in E-VPN. Thus a single conv= ergent solution is possible for both VPLS

> >   and E-VPN.

> >

> >

> >

> >

> > The IETF Secretariat

> >

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020BA7CA63ILPTWPVEXMB03ec_-- From aldrin.isaac@gmail.com Sun Sep 23 06:21:12 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 7326C21F84C9 for ; Sun, 23 Sep 2012 06:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K6LCcpL1RPr for ; Sun, 23 Sep 2012 06:21:11 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA6DE21F8498 for ; Sun, 23 Sep 2012 06:21:10 -0700 (PDT) Received: by bkty12 with SMTP id y12so2418874bkt.31 for ; Sun, 23 Sep 2012 06:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8SfdlzKWYbX0P8EBW2pso6kX9f6+G6LmDxSFLW5AAbs=; b=d4421uqgmMzKK3wHoancZQQ20g0eyu13YbyKjs7dKqHYzd/dogcfh1hktrOkKyiaQ5 FlHoQLSicXzZDiox4JFc9F3aMcuGC7Lxs5uuppMdPtbK+vuEOm3pU3fS6CzHvCE7gyB0 Llbo3dzK2jf8gY/juGLCIqHlFTxx6hSUO/s8B3EcVh4TrijW64PWt53goObmf/ZhTmD8 Z9yZ7DoG7uu/g0Vs4ZhjQAF9hsI4kQ83HX4myfdadw65GxYa4EPz/0G8ODyWPfwZ+w+d Hyq7avf86K57PTCReUWa1PtI1ZDA+hmNi6r9z8ObaSQCrkIHiN6oBovTodVUKeV8Uxtk hYkw== MIME-Version: 1.0 Received: by 10.204.147.1 with SMTP id j1mr3755272bkv.110.1348406469694; Sun, 23 Sep 2012 06:21:09 -0700 (PDT) Received: by 10.204.37.7 with HTTP; Sun, 23 Sep 2012 06:21:09 -0700 (PDT) In-Reply-To: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> Date: Sun, 23 Sep 2012 09:21:09 -0400 Message-ID: Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt From: Aldrin Isaac To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=0015174be974a394cc04ca5e5841 Cc: "l2vpn@ietf.org" , Jiangyuanlong , Ali Sajassi , Himanshu Shah 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, 23 Sep 2012 13:21:12 -0000 --0015174be974a394cc04ca5e5841 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable With EVPN, leaf AC should have different context and associated label from root AC. A leaf AC forwarding context (say EVI) on an ingress PE would not import the RT for other leaf AC and hence not have forwarding vectors to any leaf AC. The packet would have nowhere to go and hence be dropped on ingress. In the case of BUM ingress replication, the leaf AC forwarding context on the ingress PE would not have imported the Inclusive Tag route of egress leaf AC and hence have no vectors to local replication context IDs of other leaf AC . In the case of BUM tree, the leaf EVI would not have imported the Inclusive Tag route of other leaf EVI and hence not form a tree to other leaf EVI. On Sunday, September 23, 2012, Alexander Vainshtein wrote: > Yuanlong, Giles, Himanshu, Ali and all,**** > > I have probably missed something important (not being present at the > latest IETF meeting).**** > > But I think something is wrong with the statement "*there was no benefit > in the E-VPN case in using an additional tag (such as a VLAN)"*.**** > > ** ** > > IMHO and FWIW the real E-Tree problem is the situation when there are two > (or more) PEs with both Root and Leaf ACs.**** > > When one of such PEs receives a VPLS packet from another such PE, it must > somehow identify the source AC of the Ethernet frame in this packet, and, > in the case of it being a leaf AC, prevent its forwarding to the local Le= af > AC(s) while allowing forwarding to local Root AC(s). This equally applies > to regular VPLS and E-VPN, e.g., in the case when the contained Ethernet > frame is a broadcast one (so that no learning is associated with it). And= I > strongly doubt this can be achieved without some =93tags=94 in the > encapsulation. **** > > ** ** > > My 2c,**** > > Sasha**** > > ** ** > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org 'l2vpn-bounces@ietf.org');> [mailto:l2vpn-bounces@ietf.org] > On Behalf > > > Of Jiangyuanlong > > > Sent: Saturday, September 22, 2012 5:32 AM > > > To: Giles Heron > > > Cc: l2vpn@ietf.org > > > Subject: RE: New Version Notification for > draft-jiang-l2vpn-evpn-etree-2vlan- > > > 00.txt > > > > > > Hi Giles, > > > > > > Perhaps the gauge of the consensus in the minutes was not so clear for > me: > > > " Giles - are we agreed we want to get to one solution for VPLS > and E- > > > VPN. > > > Not many people. But even fewer who want multiple. Checked > to see > > > if > > > people want one solution only for E-VPN and VPLS - only a > couple of > > > hands." > > > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus > to > > > decide which way to take. > > > > > > Thanks, > > > Yuanlong > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles.heron@gmail.com] > > > Sent: Friday, September 21, 2012 9:09 PM > > > To: Jiangyuanlong > > > Cc: l2vpn@ietf.org > > > Subject: Re: New Version Notification for > draft-jiang-l2vpn-evpn-etree-2vlan- > > > 00.txt > > > > > > Thanks Yuanlong, > > > > > > however I must say that your memory of the IETF 84 L2VPN meeting differ= s > > > from mine (and from what is noted in the minutes). Whilst Himanshu sai= d > > > that it was better to have the same solution for VPLS and E-VPN, Ali > stated > > > that there was no benefit in the E-VPN case in using an additional tag > (such as > > > a VLAN). No consensus was reached in the meeting. > > > > > > Giles > > > > > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > > wrote: > > > > > > > Hi all, > > > > > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree > in E- > > > VPN, and it was shown that a single solution was more preferred than tw= o > > > different approaches for VPLS and E-VPN. > > > > This I-D probes how the 2VLAN approach can be used to support E-Tree = in > > > E-VPN and it seems not a big issue. > > > > Any comments from you are greatly appreciated. > > > > > > > > Best regards, > > > > Yuanlong > > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Friday, September 21, 2012 4:55 PM > > > > To: Jiangyuanlong > > > > Subject: New Version Notification for > draft-jiang-l2vpn-evpn-etree-2vlan- > > > 00.txt > > > > > > > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > > > has been successfully submitted by Yuanlong Jiang and posted to the > > > > IETF repository. > > > > > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > > > Revision: 00 > > > > Title: E-Tree Support with 2VLAN in E-V= PN > > > > Creation date: 2012-09-21 > > > > WG ID: Individual Submission > > > > Number of pages: 6 > > > > URL: > http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn- > > > etree-2vlan-00.txt > > > > Status: > http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree- > > > 2vlan > > > > Htmlized: > http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree- > > > 2vlan-00 > > > > > > > > > > > > Abstract: > > > > This document discusses h > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --0015174be974a394cc04ca5e5841 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable With EVPN, leaf AC should have different context and associated label from = root AC. =A0A leaf AC forwarding context (say EVI) on an ingress PE would n= ot import the RT for other leaf AC and hence not have forwarding vectors to= any leaf AC. =A0The packet would have nowhere to go and hence be dropped o= n ingress. =A0In the case of BUM ingress replication, the leaf AC forwardin= g context on the ingress PE would not have imported the Inclusive Tag route= of egress leaf AC and hence have no vectors to local replication context I= Ds of other leaf AC . =A0In the case of BUM tree, the leaf EVI would not ha= ve imported the Inclusive Tag route of other leaf EVI and hence not form a = tree to other leaf EVI.=A0



On Sunday, September 23, 2012, Alexander Vainsht= ein wrote:

Yuanlong, Giles, Himanshu, Ali and all,

I have probably missed something important (not being present at the lat= est IETF meeting).

But I think something is wrong with the statement "there was no = benefit in the E-VPN case in using an additional tag (such as a VLAN)"= .

=A0

IMHO and FWIW the real E-Tree problem is the situation when there are tw= o (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from another such PE, it mus= t somehow identify the source AC of the Ethernet frame in this packet, and,= in the case of it being a leaf AC, prevent its forwarding to the local Lea= f AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular V= PLS and E-VPN, e.g., in the case when the contained Ethernet frame is a bro= adcast one (so that no learning is associated with it). And I strongly doub= t this can be achieved without some =93tags=94 in the encapsulation.

=A0

My 2c,

=A0=A0=A0=A0 Sasha

=A0

> -----Original Message-----

> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-et= ree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minutes was not so clear = for me:

> "=A0=A0=A0=A0=A0=A0=A0=A0 Giles - are we agreed we want to get= to one solution for VPLS and E-

> VPN.

> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Not many people.=A0 But even fewer wh= o want multiple.=A0 Checked to see

> if

> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0people want one solution only for E-V= PN and VPLS - only a couple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution and it is the WG conse= nsus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:giles.heron@gmail.com]

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org

> Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-et= ree-2vlan-

> 00.txt

>

> Thanks Yuanlong,

>

> however I must say that your memory of the IETF 84 L2VPN meeting di= ffers

> from mine (and from what is noted in the minutes).=A0 Whilst Himans= hu said

> that it was better to have the same solution for VPLS and E-VPN, Al= i stated

> that there was no benefit in the E-VPN case in using an additional = tag (such as

> a VLAN).=A0 No consensus was reached in the meeting.

>

> Giles

>

> On 21 Sep 2012, at 10:16, Jiangyuanlong <jiangyuanlong@huawei.com>

> wrote:

>

> > Hi all,

> >

> > During the 84th IETF meeting, the group discussed the issue of= E-Tree in E-

> VPN, and it was shown that a single solution was more preferred tha= n two

> different approaches for VPLS and E-VPN.

> > This I-D probes how the 2VLAN approach can be used to support = E-Tree in

> E-VPN and it seems not a big issue.

> > Any comments from you are greatly appreciated.

> >

> > Best regards,

> > Yuanlong

> >

> > -----Original Message-----

> > From: internet-drafts@ietf.org [mailto:internet-draf= ts@ietf.org]

> > Sent: Friday, September 21, 2012 4:55 PM

> > To: Jiangyuanlong

> > Subject: New Version Notification for draft-jiang-l2vpn-evpn-e= tree-2vlan-

> 00.txt

> >

> >

> > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.tx= t

> > has been successfully submitted by Yuanlong Jiang and posted t= o the

> > IETF repository.

> >

> > Filename:=A0=A0=A0=A0 draft-jiang-l2vpn-evpn-etree-2vlan

> > Revision:=A0=A0=A0=A0=A0 00

> > Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 E-Tree Support with 2VLAN in E-VPN

> > Creation date:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2012-09-21

> > WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Individual Submission

> > Number of pages: 6

> > URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/i= nternet-drafts/draft-jiang-l2vpn-evpn-

> etree-2vlan-00.txt

> > Status:=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://datatracker.ie= tf.org/doc/draft-jiang-l2vpn-evpn-etree-

> 2vlan

> > Htmlized:=A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org= /html/draft-jiang-l2vpn-evpn-etree-

> 2vlan-00

> >

> >

> > Abstract:

> >=A0=A0 This document discusses h

This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--0015174be974a394cc04ca5e5841-- From jiangyuanlong@huawei.com Sun Sep 23 19:23:08 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 09DE321F853E for ; Sun, 23 Sep 2012 19:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hylusgaw+2sr for ; Sun, 23 Sep 2012 19:23:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1F221F8525 for ; Sun, 23 Sep 2012 19:23:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKY95542; Mon, 24 Sep 2012 02:23:01 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 03:22:26 +0100 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 03:23:00 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 10:22:56 +0800 From: Jiangyuanlong To: Alexander Vainshtein , Giles Heron , Himanshu Shah , Ali Sajassi Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmWUGAR1X+eyYskOHru3ESKxPQZeYsQVw Date: Mon, 24 Sep 2012 02:22:56 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE08@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> 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.95] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE08szxeml546mbschi_" 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: Mon, 24 Sep 2012 02:23:08 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE08szxeml546mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, >From Ali's I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS lab= els per Ethernet segment are used for E-Tree. So one is used for root traff= ic and another is used for leaf traffic, just like in the 2PW approach. But it has the same problem as 2PW IMHO and OAM will be a challenge. Besides, manipulation of those labels and import/export of their associated= RT attributes may not be easy. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, September 23, 2012 4:25 PM To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in = the E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (= or more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must s= omehow identify the source AC of the Ethernet frame in this packet, and, in= the case of it being a leaf AC, prevent its forwarding to the local Leaf A= C(s) while allowing forwarding to local Root AC(s). This equally applies to= regular VPLS and E-VPN, e.g., in the case when the contained Ethernet fram= e is a broadcast one (so that no learning is associated with it). And I str= ongly doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me= : > " Giles - are we agreed we want to get to one solution for VPLS a= nd E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a coupl= e of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus t= o > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali stat= ed > that there was no benefit in the E-VPN case in using an additional tag (s= uch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree i= n E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n- > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-= evpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn= -etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etre= e- > 2vlan-00 > > > > > > Abstract: > > This document discusses how the Dual-VLAN approach as described in > > [Etree-vlan] can be used to support the transport of E-Tree service > > in E-VPN. Thus a single convergent solution is possible for both VPLS > > and E-VPN. > > > > > > > > > > The IETF Secretariat > > This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE08szxeml546mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha,

 

From Ali’s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems = two ESI MPLS labels per Ethernet segment are used for E-Tree. So one is use= d for root traffic and another is used for leaf traffic, just like in the 2PW approach.

But it has the same problem as 2PW IMHO and OAM will be a challen= ge.

Besides, manipulation of those labels and import/export of their = associated RT attributes may not be easy.

 

Thanks,

Yuanlong

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@eci= tele.com]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Yuanlong, Giles, Himanshu, A= li and all,

I have probably missed somet= hing important (not being present at the latest IETF meeting).

But I think something is wro= ng with the statement "there was no benefit in the E-VPN case in us= ing an additional tag (such as a VLAN)".

 

IMHO and FWIW the real E-Tre= e problem is the situation when there are two (or more) PEs with both Root = and Leaf ACs.

When one of such PEs receive= s a VPLS packet from another such PE, it must somehow identify the source A= C of the Ethernet frame in this packet, and, in the case of it being a leaf= AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally app= lies to regular VPLS and E-VPN, e.g., in the case when the contained Ethern= et frame is a broadcast one (so that no learning is associated with it). An= d I strongly doubt this can be achieved without some “tags” in the encapsulation.

 

My 2c,

     Sas= ha

 

> -----Original Message--= ---

> From: l2vpn-bounces@iet= f.org [mailto:l2vpn-bounces@ietf.org] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, Septemb= er 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org=

> Subject: RE: New Versio= n Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of th= e consensus in the minutes was not so clear for me:

> "   = ;      Giles - are we agreed we want to get to one= solution for VPLS and E-

> VPN.<= /p>

>     = ;      Not many people.  But even fewer = who want multiple.  Checked to see

> if

>     = ;      people want one solution only for E-VP= N and VPLS - only a couple of

> hands."=

> Nevertheless, E-VPN nee= ds an E-Tree solution and it is the WG consensus to

> decide which way to tak= e.

>

> Thanks,

> Yuanlong

>

> -----Original Message--= ---

> From: Giles Heron [mail= to:giles.heron@gmail.com]

> Sent: Friday, September= 21, 2012 9:09 PM

> To: Jiangyuanlong<= /o:p>

> Cc: l2vpn@ietf.org=

> Subject: Re: New Versio= n Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Thanks Yuanlong,

>

> however I must say that= your memory of the IETF 84 L2VPN meeting differs

> from mine (and from wha= t is noted in the minutes).  Whilst Himanshu said

> that it was better to h= ave the same solution for VPLS and E-VPN, Ali stated

> that there was no benef= it in the E-VPN case in using an additional tag (such as<= /p>

> a VLAN).  No conse= nsus was reached in the meeting.

>

> Giles=

>

> On 21 Sep 2012, at 10:1= 6, Jiangyuanlong <jiangyuanlong@huawei.com= >

> wrote:

>

> > Hi all,=

> ><= /p>

> > During the 84th IE= TF meeting, the group discussed the issue of E-Tree in E-=

> VPN, and it was shown t= hat a single solution was more preferred than two

> different approaches fo= r VPLS and E-VPN.

> > This I-D probes ho= w the 2VLAN approach can be used to support E-Tree in

> E-VPN and it seems not = a big issue.

> > Any comments from = you are greatly appreciated.

> ><= /p>

> > Best regards,=

> > Yuanlong

> ><= /p>

> > -----Original Mess= age-----

> > From: internet-dra= fts@ietf.org [mailto:internet-drafts@ietf.org]

> > Sent: Friday, Sept= ember 21, 2012 4:55 PM

> > To: Jiangyuanlong<= o:p>

> > Subject: New Versi= on Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

> ><= /p>

> ><= /p>

> > A new version of I= -D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

> > has been successfu= lly submitted by Yuanlong Jiang and posted to the

> > IETF repository.

> ><= /p>

> > Filename: &nb= sp;   draft-jiang-l2vpn-evpn-etree-2vlan

> > Revision: &nb= sp;    00

> > Title:  =             &nb= sp;            =     E-Tree Support with 2VLAN in E-VPN

> > Creation date:&nbs= p;           2012-09-21

> > WG ID:  =             &nb= sp;            Indiv= idual Submission

> > Number of pages: 6=

> > URL:  &n= bsp;          http://www.ietf.org/i= nternet-drafts/draft-jiang-l2vpn-evpn-

> etree-2vlan-00.txt

> > Status:  = ;        http://datatracker.ie= tf.org/doc/draft-jiang-l2vpn-evpn-etree-

> 2vlan

> > Htmlized: &nb= sp;      http://tools.ietf.org= /html/draft-jiang-l2vpn-evpn-etree-

> 2vlan-00

> ><= /p>

> ><= /p>

> > Abstract:

> >   This d= ocument discusses how the Dual-VLAN approach as described in

> >   [Etree= -vlan] can be used to support the transport of E-Tree service

> >   in E-V= PN. Thus a single convergent solution is possible for both VPLS<= /span>

> >   and E-= VPN.

> ><= /p>

> ><= /p>

> ><= /p>

> ><= /p>

> > The IETF Secretari= at

> ><= /p>

 

This e-mail message is intended for the recipient o= nly and contains information which is CONFIDENTIAL and which may be proprie= tary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE08szxeml546mbschi_-- From jiangyuanlong@huawei.com Sun Sep 23 19:46:20 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 E395D21F84F3 for ; Sun, 23 Sep 2012 19:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfQrJkCqYGb3 for ; Sun, 23 Sep 2012 19:46:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C61E021F845B for ; Sun, 23 Sep 2012 19:46:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKY96862; Mon, 24 Sep 2012 02:46:15 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 03:45:40 +0100 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 03:46:13 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 10:46:08 +0800 From: Jiangyuanlong To: Aldrin Isaac , Alexander Vainshtein Subject: RE: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmY5PXxacLEvPy023O8araW2PqZeYxY1A Date: Mon, 24 Sep 2012 02:46:08 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> 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.95] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31szxeml546mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , Ali Sajassi , Himanshu Shah 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, 24 Sep 2012 02:46:21 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31szxeml546mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Aldrin, I agree with you that using different labels for root/leaf AC can work, but= not sure using 2 forwarding contexts (EVI) is a good thing - that means fo= rwarding plane for E-Tree will be very different from other services in E-V= PN. Regards, Yuanlong From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] Sent: Sunday, September 23, 2012 9:21 PM To: Alexander Vainshtein Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ietf.org Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-= 2vlan-00.txt With EVPN, leaf AC should have different context and associated label from = root AC. A leaf AC forwarding context (say EVI) on an ingress PE would not= import the RT for other leaf AC and hence not have forwarding vectors to a= ny leaf AC. The packet would have nowhere to go and hence be dropped on in= gress. In the case of BUM ingress replication, the leaf AC forwarding cont= ext on the ingress PE would not have imported the Inclusive Tag route of eg= ress leaf AC and hence have no vectors to local replication context IDs of = other leaf AC . In the case of BUM tree, the leaf EVI would not have impor= ted the Inclusive Tag route of other leaf EVI and hence not form a tree to = other leaf EVI. On Sunday, September 23, 2012, Alexander Vainshtein wrote: Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in = the E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (= or more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must s= omehow identify the source AC of the Ethernet frame in this packet, and, in= the case of it being a leaf AC, prevent its forwarding to the local Leaf A= C(s) while allowing forwarding to local Root AC(s). This equally applies to= regular VPLS and E-VPN, e.g., in the case when the contained Ethernet fram= e is a broadcast one (so that no learning is associated with it). And I str= ongly doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me= : > " Giles - are we agreed we want to get to one solution for VPLS a= nd E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a coupl= e of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus t= o > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali stat= ed > that there was no benefit in the E-VPN case in using an additional tag (s= uch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree i= n E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n- > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-= evpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn= -etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etre= e- > 2vlan-00 > > > > > > Abstract: > > This document discusses h This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31szxeml546mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Aldrin,=

 = ;

I agree wi= th you that using different labels for root/leaf AC can work, but not sure = using 2 forwarding contexts (EVI) is a good thing – that means forwarding plane for E-Tree will be very different from other services in = E-VPN.

 = ;

Regards,

Yuanlong

 = ;

From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]
Sent: Sunday, September 23, 2012 9:21 PM
To: Alexander Vainshtein
Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ie= tf.org
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn= -etree-2vlan-00.txt

 

With EVPN, leaf AC should have = different context and associated label from root AC.  A leaf AC forwar= ding context (say EVI) on an ingress PE would not import the RT for other l= eaf AC and hence not have forwarding vectors to any leaf AC.  The packet would have nowhere to go and hence be dro= pped on ingress.  In the case of BUM ingress replication, the leaf AC = forwarding context on the ingress PE would not have imported the Inclusive = Tag route of egress leaf AC and hence have no vectors to local replication context IDs of other leaf AC .  In th= e case of BUM tree, the leaf EVI would not have imported the Inclusive Tag = route of other leaf EVI and hence not form a tree to other leaf EVI. <= o:p>

 



On Sunday, September 23, 2012, Alexander Vainshtein wrote:

Yuanlong, Giles, Himanshu, Ali and all,<= /span>

I have probably missed something important (not bei= ng present at the latest IETF meeting).

But I think something is wrong with the statement &= quot;there was no benefit in the E-VPN case in using an additional tag (= such as a VLAN)".

 

IMHO and FWIW the real E-Tree problem is the situat= ion when there are two (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from an= other such PE, it must somehow identify the source AC of the Ethernet frame= in this packet, and, in the case of it being a leaf AC, prevent its forwar= ding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular V= PLS and E-VPN, e.g., in the case when the contained Ethernet frame is a bro= adcast one (so that no learning is associated with it). And I strongly doub= t this can be achieved without some “tags” in the encapsulation.

 

My 2c,

     Sasha

 

> -----Original Message-----

> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version Notification for draf= t-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minu= tes was not so clear for me:

> "      &nbs= p;  Giles - are we agreed we want to get to one solution for VPLS and = E-

> VPN.

>        &nbs= p;  Not many people.  But even fewer who want multiple. = ; Checked to see

> if

>        &nbs= p;  people want one solution only for E-VPN and VPLS - only a cou= ple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution a= nd it is the WG consensus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:giles.heron@gmail.co= m]

> Sent: Friday, September 21, 2012 9:09 PM<= /o:p>

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org

> Subject: Re: New Version Notification for draf= t-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Thanks Yuanlong,

>

> however I must say that your memory of the IET= F 84 L2VPN meeting differs

> from mine (and from what is noted in the minut= es).  Whilst Himanshu said

> that it was better to have the same solution f= or VPLS and E-VPN, Ali stated

> that there was no benefit in the E-VPN case in= using an additional tag (such as

> a VLAN).  No consensus was reached in the= meeting.

>

> Giles

>

> On 21 Sep 2012, at 10:16, Jiangyuanlong <ji= angyuanlong@huawei.com>

> wrote:

>

> > Hi all,

> >

> > During the 84th IETF meeting, the group d= iscussed the issue of E-Tree in E-

> VPN, and it was shown that a single solution w= as more preferred than two

> different approaches for VPLS and E-VPN.<= /o:p>

> > This I-D probes how the 2VLAN approach ca= n be used to support E-Tree in

> E-VPN and it seems not a big issue.=

> > Any comments from you are greatly appreci= ated.

> >

> > Best regards,

> > Yuanlong

> >

> > -----Original Message-----

> > From: internet-drafts@ietf.org [mailto:in= ternet-drafts@ietf.org]

> > Sent: Friday, September 21, 2012 4:55 PM<= o:p>

> > To: Jiangyuanlong

> > Subject: New Version Notification for dra= ft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

> >

> >

> > A new version of I-D, draft-jiang-l2vpn-e= vpn-etree-2vlan-00.txt

> > has been successfully submitted by Yuanlo= ng Jiang and posted to the

> > IETF repository.

> >

> > Filename:     draft-j= iang-l2vpn-evpn-etree-2vlan

> > Revision:      0= 0

> > Title:      = ;            &n= bsp;            E-Tr= ee Support with 2VLAN in E-VPN

> > Creation date:    &nb= sp;       2012-09-21

> > WG ID:      = ;            &n= bsp;        Individual Submission

> > Number of pages: 6

> > URL:      &= nbsp;      http://www.ietf.org/i= nternet-drafts/draft-jiang-l2vpn-evpn-

> etree-2vlan-00.txt=

> > Status:     &nbs= p;    http://datatracker.ie= tf.org/doc/draft-jiang-l2vpn-evpn-etree-

> 2vlan

> > Htmlized:     &n= bsp;  http://tools.ietf.org= /html/draft-jiang-l2vpn-evpn-etree-

> 2vlan-00

> >

> >

> > Abstract:

> >   This document discusses h

This e-mail message is intended for the recipient o= nly and contains information which is CONFIDENTIAL and which may be proprie= tary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31szxeml546mbschi_-- From aldrin.isaac@gmail.com Sun Sep 23 21:27: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 26D8E21F8557 for ; Sun, 23 Sep 2012 21:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW0SSyqdWXDg for ; Sun, 23 Sep 2012 21:27:55 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A03AA21F853F for ; Sun, 23 Sep 2012 21:27:54 -0700 (PDT) Received: by bkty12 with SMTP id y12so2601034bkt.31 for ; Sun, 23 Sep 2012 21:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yB2ai0V5UBTlYGt74QL+CCxpKSj60/tDfXqonGuGBk8=; b=KWP1ap2h03KmhJsOUjd7fLeR5FmFOlusJu0RAFdFiG58GsEDyOAz86KZqrUrmwHRBF AqEXDxK2bFv9sjFk5Hhizj09sPO2i66pFXCY67dMhz4J76wwicuL3bih7/ML5v1XtzOr f7snVSOPcjIXM0vwWcncbZAWLvdIp1MrJvbErhYeE8iTsasZNy1ye6EbUBi7TyZvV9Af Y+oATiF2LMOrdId+PU0fzUI1smRdfXLY/FntMQvnWviF52YA21njps+4RO8xruluLO/J q4zvhJdRZQCSsqYisQvI+wEIH0XN+QYL//IUEGbQSazcYw/tKSlLkd/eCj9knJYSbi0J HFnA== MIME-Version: 1.0 Received: by 10.204.152.152 with SMTP id g24mr4009896bkw.104.1348460873392; Sun, 23 Sep 2012 21:27:53 -0700 (PDT) Received: by 10.204.37.7 with HTTP; Sun, 23 Sep 2012 21:27:53 -0700 (PDT) In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31@szxeml546-mbs.china.huawei.com> Date: Mon, 24 Sep 2012 00:27:53 -0400 Message-ID: Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt From: Aldrin Isaac To: Jiangyuanlong Content-Type: multipart/alternative; boundary=0015175d03365a212304ca6b03d8 Cc: "l2vpn@ietf.org" , Ali Sajassi , Himanshu Shah 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, 24 Sep 2012 04:27:56 -0000 --0015175d03365a212304ca6b03d8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yuanlong, I'm not clear as to why different forwarding contexts for root and leaf is less than good -- can you elaborate? Also I'm not clear as to why you see that ETREE using EVPN is any different from other topologies that can be created with EVPN. EVPN's ability to create any topology is fundamental to it. In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in different VRF. In some cases we even overlap one or more hub-and-spoke RT pairs with one or more mesh RT. EVPN was purposefully designed to bring this flexibility to Ethernet. Best regards -- aldrin On Sunday, September 23, 2012, Jiangyuanlong wrote: > Hi Aldrin,**** > > ** ** > > I agree with you that using different labels for root/leaf AC can work, > but not sure using 2 forwarding contexts (EVI) is a good thing =96 that m= eans > forwarding plane for E-Tree will be very different from other services in > E-VPN. **** > > ** ** > > Regards,**** > > Yuanlong**** > > ** ** > > *From:* Aldrin Isaac [mailto:aldrin.isaac@gmail.com 'cvml', 'aldrin.isaac@gmail.com');>] > *Sent:* Sunday, September 23, 2012 9:21 PM > *To:* Alexander Vainshtein > *Cc:* Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; > l2vpn@ietf.org > *Subject:* Re: FW: New Version Notification for > draft-jiang-l2vpn-evpn-etree-2vlan-00.txt**** > > ** ** > > With EVPN, leaf AC should have different context and associated label fro= m > root AC. A leaf AC forwarding context (say EVI) on an ingress PE would n= ot > import the RT for other leaf AC and hence not have forwarding vectors to > any leaf AC. The packet would have nowhere to go and hence be dropped on > ingress. In the case of BUM ingress replication, the leaf AC forwarding > context on the ingress PE would not have imported the Inclusive Tag route > of egress leaf AC and hence have no vectors to local replication context > IDs of other leaf AC . In the case of BUM tree, the leaf EVI would not > have imported the Inclusive Tag route of other leaf EVI and hence not for= m > a tree to other leaf EVI. **** > > ** ** > > > > On Sunday, September 23, 2012, Alexander Vainshtein wrote:**** > > Yuanlong, Giles, Himanshu, Ali and all,**** > > I have probably missed something important (not being present at the > latest IETF meeting).**** > > But I think something is wrong with the statement "*there was no benefit > in the E-VPN case in using an additional tag (such as a VLAN)"*.**** > > **** > > IMHO and FWIW the real E-Tree problem is the situation when there are two > (or more) PEs with both Root and Leaf ACs.**** > > When one of such PEs receives a VPLS packet from another such PE, it must > somehow identify the source AC of the Ethernet frame in this packet, and, > in the case of it being a leaf AC, prevent its forwarding to the local Le= af > AC(s) while allowing forwarding to local Root AC(s). This equally applies > to regular VPLS and E-VPN, e.g., in the case when the contained Ethernet > frame is a broadcast one (so that no learning is associated with it). And= I > strongly doubt this can be achieved without some =93tags=94 in the > encapsulation. **** > > **** > > My 2c,**** > > Sasha**** > > **** > > > -----Original Message-----**** > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf*= * > ** > > > Of Jiangyuanlong**** > > > Sent: Saturday, September 22, 2012 5:32 AM**** > > > To: Giles Heron**** > > > Cc: l2vpn@ietf.org**** > > > Subject: RE: New Version Notification for > draft-jiang-l2vpn-evpn-etree-2vlan-**** > > > 00.txt**** > > > **** > > > Hi Giles,**** > > > **** > > > Perhaps the gauge of the consensus in the minutes was not so clear for > me:**** > > > " Giles - are we agreed we want to get to one solution for VPLS > and E-**** > > > VPN.**** > > > Not many people. But even fewer who want multiple. Checked > to see**** > > > if**** > > > people want one solution only for E-VPN and VPLS - only a > couple of**** > > > hands."**** > > > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus > to**** > > > decide which way to take.**** > > > **** > > > Thanks,**** > > > Yuanlong**** > > > **** > > > -----Original Message-----**** > > > From: Giles Heron [mailto:giles.heron@gmail.com]**** > > > Sent: Friday, September 21, 2012 9:09 PM**** > > > To: Jiangyuanlong**** > > > Cc: l2vpn@ietf.org**** > > --0015175d03365a212304ca6b03d8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yuanlong,=A0

I'm not clear as to why different fo= rwarding contexts for root and leaf is less than good -- can you elaborate?= =A0Also I'm not clear as to why you see that ETREE using EVPN is any d= ifferent from other topologies that can be created with EVPN. =A0EVPN's= ability to create any topology is fundamental to it. =A0In IPVPN we common= ly create hub-and-spoke VPN with hubs and spokes in different VRF. In some = cases we even overlap one or more hub-and-spoke RT pairs with one or more m= esh RT. =A0EVPN was purposefully designed to bring this flexibility to Ethe= rnet.=A0

Best regards -- aldrin


On Sunday, September 23, = 2012, Jiangyuanlong wrote:

Hi Aldrin,=

=A0=

I agree wi= th you that using different labels for root/leaf AC can work, but not sure = using 2 forwarding contexts (EVI) is a good thing =96 that means forwarding plane for E-Tree will be very different from other services in = E-VPN.

=A0=

Regards,

Yuanlong

=A0=

From: Aldrin Isaac [mailto:aldrin.i= saac@gmail.com]
Sent: Sunday, September 23, 2012 9:21 PM
To: Alexander Vainshtein
Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ietf.org
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn= -etree-2vlan-00.txt

=A0

With EVPN, leaf AC should have different context an= d associated label from root AC. =A0A leaf AC forwarding context (say EVI) = on an ingress PE would not import the RT for other leaf AC and hence not ha= ve forwarding vectors to any leaf AC. =A0The packet would have nowhere to go and hence be droppe= d on ingress. =A0In the case of BUM ingress replication, the leaf AC forwar= ding context on the ingress PE would not have imported the Inclusive Tag ro= ute of egress leaf AC and hence have no vectors to local replication context IDs of other leaf AC . =A0In the c= ase of BUM tree, the leaf EVI would not have imported the Inclusive Tag rou= te of other leaf EVI and hence not form a tree to other leaf EVI.=A0=

=A0



On Sunday, September 23, 2012, Alexander Vainshtein wrote:

Yuanlong, Giles, Himanshu, Ali and all,

I have probably missed something important (not bei= ng present at the latest IETF meeting).

But I think something is wrong with the statement &= quot;there was no benefit in the E-VPN case in using an additional tag (= such as a VLAN)".

=A0

IMHO and FWIW the real E-Tree problem is the situat= ion when there are two (or more) PEs with both Root and Leaf ACs.=

When one of such PEs receives a VPLS packet from an= other such PE, it must somehow identify the source AC of the Ethernet frame= in this packet, and, in the case of it being a leaf AC, prevent its forwar= ding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular V= PLS and E-VPN, e.g., in the case when the contained Ethernet frame is a bro= adcast one (so that no learning is associated with it). And I strongly doub= t this can be achieved without some =93tags=94 in the encapsulation.

=A0

My 2c,

=A0=A0=A0=A0 Sasha

=A0

> -----Original Message-----

> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf=

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM<= /u>

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version Notification for draf= t-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minu= tes was not so clear for me:

> "=A0=A0=A0=A0=A0=A0=A0=A0 Giles - are we = agreed we want to get to one solution for VPLS and E-<= /p>

> VPN.

> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Not many people.= =A0 But even fewer who want multiple.=A0 Checked to see

> if

> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0people want one = solution only for E-VPN and VPLS - only a couple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution a= nd it is the WG consensus to

> decide which way to take.=

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:giles.heron@gmail= .com]

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org=

--0015175d03365a212304ca6b03d8-- From Alexander.Vainshtein@ecitele.com Sun Sep 23 23:25:11 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 5828D21F853F for ; Sun, 23 Sep 2012 23:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrFMce7q2esG for ; Sun, 23 Sep 2012 23:25:10 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4C021F84F5 for ; Sun, 23 Sep 2012 23:25:09 -0700 (PDT) Received: from [85.158.139.211:24862] by server-1.bemta-5.messagelabs.com id 44/65-09825-4CCFF505; Mon, 24 Sep 2012 06:25:08 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1348467904!19686149!3 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 19231 invoked from network); 24 Sep 2012 06:25:07 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-11.tower-206.messagelabs.com with SMTP; 24 Sep 2012 06:25:07 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-2d-505ff8197e90 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id BB.91.06426.918FF505; Mon, 24 Sep 2012 08:05:13 +0200 (IST) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 24 Sep 2012 08:25:05 +0200 Received: from ILPTWPVEXMB03.ecitele.com ([fe80::91b4:8f74:ce44:f190]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.01.0379.000; Mon, 24 Sep 2012 08:25:05 +0200 From: Alexander Vainshtein To: Jiangyuanlong , Giles Heron , Ali Sajassi Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNl9bO5vMHP1fUbUG3AEjOw2TsF5eUffmwgAAUqoCAAOBBgIACI93wgAEPDgCAAGFU/Q== Date: Mon, 24 Sep 2012 06:25:05 +0000 Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> , <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE08@szxeml546-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE08@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020BA7FCDCILPTWPVEXMB03ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTb0wTZxjPe3dtj8rpUUBemyVeTqfJoNoGNTVYt2WawJfZROeMH4SzfWkv tnfN3UFAl0gmccjmogGNFhlqmomDxVDd0pnGP8QSaQSJBqMsJVMUFKcj4p+JQ3bXQ+SLX978 nt/ze57f8755XhK3XDFZSV5QkCRwAdZoJhpGnz23Wf8tddsHemnng8QR4Owf+87oHHrZaXI+ 7dlDfEYUN77pMBT/EU6ZimuvPDEURyKvMTextQas4QRBVDgFMV4ke1ysW+IrOU81y/BeF+tg mVCA86AgEhQXy4VCSPCya81rVJIXGCR4RC8v+FxsycYNNqdz5Wqbg127ZJGjsMi8yc/LDLIF OT7ABJEscz7EqIw2teBFXqZclBjFjxiprAH3J868wkO1I6Aq8X27qQZEu0A9yCAhvQLW7b1p 0PF82Dd4xlgPzKSFvghg18lmoAcxAMeP92N6kADw/IXD6XIj7YLRtpRRwzm0Am/djWEaxumP YW30QlqTTX8FU6cnTbpmMxxL3sXrAZnGh/+TNZrQ5K11hEZTtBueGpyrWz3AYPxQU7p9hiq/ uL85PSlQJ32VbJ+2yoMD91sw/QY0jMSv4zrOhY+G3k7fbCE8+9uQQdeLcPLcQULDFJ0Fu4/e T2MLbYPJq/XTfRbAy623iQMAhmdZhGeVh2eV67wd/tPbgus4H/584vE0Xg47nveA2fxxYPoF 5PKBkLI96LM7liEPr6AAWuYRg1Ggr9pIDEy0LO4ENAnYTOphtNRtMXCVcnWwEywgMTaXKphQ qbnbRW+1n5P9pVJFAMmdAJI4m0NtGVZzlJer3okk8V1qvfrKB3HrHI+orYdSWmi3fzhg86hT NV9vsNA+dWl3IBRC0rs+H5EkC6lDb1SLLAn5UFU5H1DepzEyQxsjUx0D0zSUHOKCMu/T80mw mmxqjPwFyPZm7byXUk8LIYgCsuZRQa2A1gr8FcJMT+3z7Z6amhoFeepjZFONmipTXfKZrqOq IaYazotv0wzVjzaTstaA+JcNN7JPt/YdKwlttJYMpi51tHRbug3Nt6tS2Obhqq4vzHRk1WRR Tjjr855t1/qv761QfjhQZHM5fi3peNp0NpJ/69Nv/971Z3L/WPn4UM554t7Lgn35uZ6J2Jw7 BZuetH0T37elbF3vicRPl0ZiSvx344u24bq+VWXjP15euoOTrZUsIfs5xye4JHP/A2S4wfdX BAAA 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: Mon, 24 Sep 2012 06:25:11 -0000 --_000_F9336571731ADE42A5397FC831CEAA020BA7FCDCILPTWPVEXMB03ec_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Yuanlong. Lots of thanks for a prompt response and clarification. I have always considered the CW-based proposal for E-tree as the simplest (a= nd, by implication, the most clean) approach: - No need to distribute the types of ACs a given PE supports (and to re-dist= ribute it when the set of ACs is changed). It is a purely local matter - No OAM issues - No need to allocate special VLAN tags to mark Leaf and Root- originated tr= affic and to propagate these allocations - hence no problem with preservatio= n of C-VLANs if/when it is needed (or VLAN manipulation) etc. Unfortunately the WG has decided to drop this approach - presumably, because= it mandated the use of CW in the Ethernet PW encapsulation which is not sup= ported by some implementations. So now we have a good chance to end with two different solutions (one for E-= VPN and one for regular VPLS), and, most probably, with some additional mech= anism for their interworking... But is probably spilled milk now. Regards. Sasha. ________________________________ From: Jiangyuanlong [jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 4:22 AM To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Sasha, >From Ali=92s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS la= bels per Ethernet segment are used for E-Tree. So one is used for root traff= ic and another is used for leaf traffic, just like in the 2PW approach. But it has the same problem as 2PW IMHO and OAM will be a challenge. Besides, manipulation of those labels and import/export of their associated= RT attributes may not be easy. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, September 23, 2012 4:25 PM To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in t= he E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (o= r more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must so= mehow identify the source AC of the Ethernet frame in this packet, and, in t= he case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s= ) while allowing forwarding to local Root AC(s). This equally applies to reg= ular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame is= a broadcast one (so that no learning is associated with it). And I strongly= doubt this can be achieved without some =93tags=94 in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vl= an- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me: > " Giles - are we agreed we want to get to one solution for VPLS an= d E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a couple= of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus to > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vl= an- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali state= d > that there was no benefit in the E-VPN case in using an additional tag (su= ch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree in= E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= - > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-e= vpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-= etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree= - > 2vlan-00 > > > > > > Abstract: > > This document discusses how the Dual-VLAN approach as described in > > [Etree-vlan] can be used to support the transport of E-Tree service > > in E-VPN. Thus a single convergent solution is possible for both VPLS > > and E-VPN. > > > > > > > > > > The IETF Secretariat > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020BA7FCDCILPTWPVEXMB03ec_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

<= span style=3D"COLOR: #1f497d; FONT-SIZE: 10.5pt" lang=3D"EN-US">Yuanlong<= /a>.

Lots of= thanks for a prompt response and clarification.

&= nbsp;

I have a= lways considered the CW-based proposal for E-tree as the simplest (and, by i= mplication, the most clean) approach:

- No nee= d to distribute the types of ACs a given PE supports (and to re-distribute i= t when the set of ACs is changed). It is a purely local matter

- No OAM= issues

- No nee= d to allocate special VLAN tags to mark Leaf and Root- originated traffic an= d to propagate these allocations - hence no problem with preservation of&nbs= p; C-VLANs if/when it is needed (or VLAN manipulation) etc.

&= nbsp;

Unfortun= ately the WG has decided to drop this approach - presumably, becau= se it mandated the use of CW in the Ethernet PW encapsulation which is not s= upported by some implementations.

&= nbsp;

So now w= e have a good chance to end with two different solutions (one for E-VPN and one for regular VPLS), and, most probably, with some a= dditional mechanism for their interworking...

&= nbsp;

But is&n= bsp;probably spilled milk now.

&= nbsp;

Regards.=

Sasha.

    
From: Jiangyuanlon= g [jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

Sasha,

 

From Ali=92s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two= ESI MPLS labels per Ethernet segment are used for E-Tree. So one is used fo= r root traffic and another is used for leaf traffic, just like in the 2PW approach.

But it has the same problem as 2PW IMHO and OAM will be a challe= nge.

Besides, manipulation of those labels and import/export of their= associated RT attributes may not be easy.

 

Thanks,

Yuanlong

 

From: Alexander Vainshtei= n [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

 

Yuanlong, Giles, Himanshu, Al= i and all,

I have probably missed someth= ing important (not being present at the latest IETF meeting).

But I think something is wron= g with the statement "there was no benefit in the E-VPN case in usin= g an additional tag (such as a VLAN)".

 

IMHO and FWIW the real E-Tree= problem is the situation when there are two (or more) PEs with both Root an= d Leaf ACs.

When one of such PEs receives= a VPLS packet from another such PE, it must somehow identify the source AC= of the Ethernet frame in this packet, and, in the case of it being a leaf A= C, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally appl= ies to regular VPLS and E-VPN, e.g., in the case when the contained Ethernet= frame is a broadcast one (so that no learning is associated with it). And I= strongly doubt this can be achieved without some =93tags=94 in the encapsulation.

 

My 2c,

     Sash= a

 

> -----Original Message---= --

> From: l2vpn-bounces@ietf= .org [mailto:l2vpn-bounces@ietf.org] On Behalf

> Of Jiangyuanlong<= /p>

> Sent: Saturday, Septembe= r 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version= Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the= consensus in the minutes was not so clear for me:

> "   =       Giles - are we agreed we want to get to one s= olution for VPLS and E-

> VPN.

>     =       Not many people.  But even fewer wh= o want multiple.  Checked to see

> if

>     =       people want one solution only for E-VPN= and VPLS - only a couple of

> hands."

> Nevertheless, E-VPN need= s an E-Tree solution and it is the WG consensus to

> decide which way to take= .

>

> Thanks,

> Yuanlong

>

> -----Original Message---= --

> From: Giles Heron [mailt= o:giles.heron@gmail.com]

> Sent: Friday, September= 21, 2012 9:09 PM

> To: Jiangyuanlong=

> Cc: l2vpn@ietf.org

> Subject: Re: New Version= Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Thanks Yuanlong,<= /p>

>

> however I must say that= your memory of the IETF 84 L2VPN meeting differs

> from mine (and from what= is noted in the minutes).  Whilst Himanshu said

> that it was better to ha= ve the same solution for VPLS and E-VPN, Ali stated

> that there was no benefi= t in the E-VPN case in using an additional tag (such as

> a VLAN).  No consen= sus was reached in the meeting.

>

> Giles

>

> On 21 Sep 2012, at 10:16= , Jiangyuanlong <jiangyuanlong= @huawei.com>

> wrote:

>

> > Hi all,

> >

> > During the 84th IET= F meeting, the group discussed the issue of E-Tree in E-

> VPN, and it was shown th= at a single solution was more preferred than two

> different approaches for= VPLS and E-VPN.

> > This I-D probes how= the 2VLAN approach can be used to support E-Tree in

> E-VPN and it seems not a= big issue.

> > Any comments from y= ou are greatly appreciated.

> >

> > Best regards,

> > Yuanlong

> >

> > -----Original Messa= ge-----

> > From: internet-draf= ts@ietf.org [mailto:internet-drafts@ietf.org]

> > Sent: Friday, Septe= mber 21, 2012 4:55 PM

> > To: Jiangyuanlong

> > Subject: New Versio= n Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

> >

> >

> > A new version of I-= D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

> > has been successful= ly submitted by Yuanlong Jiang and posted to the

> > IETF repository.

> >

> > Filename: &nbs= p;   draft-jiang-l2vpn-evpn-etree-2vlan

> > Revision: &nbs= p;    00

> > Title:  &= nbsp;            = ;            &nb= sp;   E-Tree Support with 2VLAN in E-VPN

> > Creation date: = ;           2012-09-21

> > WG ID:  &= nbsp;            = ;            Individu= al Submission

> > Number of pages: 6<= /span>

> > URL:  &nb= sp;          http://www.ietf.org= /internet-drafts/draft-jiang-l2vpn-evpn-

> etree-2vlan= -00.txt

> > Status:  =         http://datatracker.= ietf.org/doc/draft-jiang-l2vpn-evpn-etree-

> 2vlan

> > Htmlized: &nbs= p;      http://tools.ietf.o= rg/html/draft-jiang-l2vpn-evpn-etree-

> 2vlan-00

> >

> >

> > Abstract:

> >   This do= cument discusses how the Dual-VLAN approach as described in

> >   [Etree-= vlan] can be used to support the transport of E-Tree service

> >   in E-VP= N. Thus a single convergent solution is possible for both VPLS

> >   and E-V= PN.

> >

> >

> >

> >

> > The IETF Secretaria= t

> >

 

This e-mail message is intended for the recipient on= ly and contains information which is CONFIDENTIAL and which may be proprieta= ry to ECI Telecom. If you have received this transmission in error, please i= nform us by e-mail, phone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020BA7FCDCILPTWPVEXMB03ec_-- From jiangyuanlong@huawei.com Mon Sep 24 00:29: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 638FD21F84DD for ; Mon, 24 Sep 2012 00:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRNci+8YSpdQ for ; Mon, 24 Sep 2012 00:29:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4721F84D7 for ; Mon, 24 Sep 2012 00:29:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJY51779; Mon, 24 Sep 2012 07:29:24 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 08:28:46 +0100 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 15:29:20 +0800 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 15:29:14 +0800 From: Jiangyuanlong To: Aldrin Isaac Subject: RE: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmY5PXxacLEvPy023O8araW2PqZeYxY1A//+bJ4CAALNIkA== Date: Mon, 24 Sep 2012 07:29:14 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE97@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31@szxeml546-mbs.china.huawei.com> 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.95] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE97szxeml546mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , Ali Sajassi , Himanshu Shah 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, 24 Sep 2012 07:29:29 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE97szxeml546mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Aldrin, I used to believe that the same MAC based forwarding will be used in E-VPN = as in VPLS, but the difference is FIB is populated with the help of BGP. Using the terminology of VPLS, E-Tree service seems to need two VSIs (EVI i= n the previous email?) as you proposed rather than only a single VSI is nee= ded for other services. That is my take of the problem, but perhaps my understanding of your propos= al is wrong:) Thanks, Yuanlong From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] Sent: Monday, September 24, 2012 12:28 PM To: Jiangyuanlong Cc: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ie= tf.org Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-= 2vlan-00.txt Hi Yuanlong, I'm not clear as to why different forwarding contexts for root and leaf is = less than good -- can you elaborate? Also I'm not clear as to why you see = that ETREE using EVPN is any different from other topologies that can be cr= eated with EVPN. EVPN's ability to create any topology is fundamental to i= t. In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in d= ifferent VRF. In some cases we even overlap one or more hub-and-spoke RT pa= irs with one or more mesh RT. EVPN was purposefully designed to bring this= flexibility to Ethernet. Best regards -- aldrin On Sunday, September 23, 2012, Jiangyuanlong wrote: Hi Aldrin, I agree with you that using different labels for root/leaf AC can work, but= not sure using 2 forwarding contexts (EVI) is a good thing - that means fo= rwarding plane for E-Tree will be very different from other services in E-V= PN. Regards, Yuanlong From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] Sent: Sunday, September 23, 2012 9:21 PM To: Alexander Vainshtein Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ietf.org<= javascript:_e(%7b%7d,%20'cvml',%20'l2vpn@ietf.org');> Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-= 2vlan-00.txt With EVPN, leaf AC should have different context and associated label from = root AC. A leaf AC forwarding context (say EVI) on an ingress PE would not= import the RT for other leaf AC and hence not have forwarding vectors to a= ny leaf AC. The packet would have nowhere to go and hence be dropped on in= gress. In the case of BUM ingress replication, the leaf AC forwarding cont= ext on the ingress PE would not have imported the Inclusive Tag route of eg= ress leaf AC and hence have no vectors to local replication context IDs of = other leaf AC . In the case of BUM tree, the leaf EVI would not have impor= ted the Inclusive Tag route of other leaf EVI and hence not form a tree to = other leaf EVI. On Sunday, September 23, 2012, Alexander Vainshtein wrote: Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in = the E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (= or more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must s= omehow identify the source AC of the Ethernet frame in this packet, and, in= the case of it being a leaf AC, prevent its forwarding to the local Leaf A= C(s) while allowing forwarding to local Root AC(s). This equally applies to= regular VPLS and E-VPN, e.g., in the case when the contained Ethernet fram= e is a broadcast one (so that no learning is associated with it). And I str= ongly doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me= : > " Giles - are we agreed we want to get to one solution for VPLS a= nd E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a coupl= e of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus t= o > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE97szxeml546mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Aldrin,

 = ;

I used to = believe that the same MAC based forwarding will be used in E-VPN as in VPLS= , but the difference is FIB is populated with the help of BGP.

Using the = terminology of VPLS, E-Tree service seems to need two VSIs (EVI in the prev= ious email?) as you proposed rather than only a single VSI is needed for other services.

That is my= take of the problem, but perhaps my understanding of your proposal is wron= gJ

 = ;

Thanks,

Yuanlong

 = ;

From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]
Sent: Monday, September 24, 2012 12:28 PM
To: Jiangyuanlong
Cc: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi; l= 2vpn@ietf.org
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn= -etree-2vlan-00.txt

 

Hi Yuanlong, 

 

I'm not clear as to why differe= nt forwarding contexts for root and leaf is less than good -- can you elabo= rate?  Also I'm not clear as to why you see that ETREE using EVPN is a= ny different from other topologies that can be created with EVPN.  EVPN's ability to create any topology is funda= mental to it.  In IPVPN we commonly create hub-and-spoke VPN with hubs= and spokes in different VRF. In some cases we even overlap one or more hub= -and-spoke RT pairs with one or more mesh RT.  EVPN was purposefully designed to bring this flexibility to Ethe= rnet. 

Best regards -- aldrin

 


On Sunday, September 23, 2012, Jiangyuanlong wrote:

Hi Aldrin,

 

I agree with you that us= ing different labels for root/leaf AC can work, but not sure using 2 forwarding contexts (EVI) is a good thing – that means forwa= rding plane for E-Tree will be very different from other services in E-VPN.

 

Regards,

Yuanlong

 

From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com]
Sent: Sunday, September 23, 2012 9:21 PM
To: Alexander Vainshtein
Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ietf.org
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn= -etree-2vlan-00.txt

 

With EVPN, leaf AC should have different context an= d associated label from root AC.  A leaf AC forwarding context (say EV= I) on an ingress PE would not import the RT for other leaf AC and hence not= have forwarding vectors to any leaf AC.  The packet would have nowhere to go and hence be dropped on ingress.=  In the case of BUM ingress replication, the leaf AC forwarding conte= xt on the ingress PE would not have imported the Inclusive Tag route of egr= ess leaf AC and hence have no vectors to local replication context IDs of other leaf AC .  In the case of BUM tree, = the leaf EVI would not have imported the Inclusive Tag route of other leaf = EVI and hence not form a tree to other leaf EVI. 

 



On Sunday, September 23, 2012, Alexander Vainshtein wrote:

Yuanlong, Giles, Himanshu, Ali and all,<= /span>

I have probably missed something important (not bei= ng present at the latest IETF meeting).

But I think something is wrong with the statement &= quot;there was no benefit in the E-VPN case in using an additional tag (= such as a VLAN)".

 

IMHO and FWIW the real E-Tree problem is the situat= ion when there are two (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from an= other such PE, it must somehow identify the source AC of the Ethernet frame= in this packet, and, in the case of it being a leaf AC, prevent its forwar= ding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular V= PLS and E-VPN, e.g., in the case when the contained Ethernet frame is a bro= adcast one (so that no learning is associated with it). And I strongly doub= t this can be achieved without some “tags” in the encapsulation.

 

My 2c,

     Sasha

 

> -----Original Message-----

> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bou= nces@ietf.org] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version Notification for draf= t-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minu= tes was not so clear for me:

> "      &nbs= p;  Giles - are we agreed we want to get to one solution for VPLS and = E-

> VPN.

>        &nbs= p;  Not many people.  But even fewer who want multiple. = ; Checked to see

> if

>        &nbs= p;  people want one solution only for E-VPN and VPLS - only a cou= ple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution a= nd it is the WG consensus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:giles.heron@gmail.co= m]

> Sent: Friday, September 21, 2012 9:09 PM<= /o:p>

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE97szxeml546mbschi_-- From jiangyuanlong@huawei.com Mon Sep 24 00:46: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 A34E221F84A1 for ; Mon, 24 Sep 2012 00:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwsk2gW7YPOo for ; Mon, 24 Sep 2012 00:46:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED04B21F849C for ; Mon, 24 Sep 2012 00:46:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKZ17923; Mon, 24 Sep 2012 07:46:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 08:45:14 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 08:45:57 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 15:44:31 +0800 From: Jiangyuanlong To: Alexander Vainshtein , Giles Heron , Ali Sajassi Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmWUGAR1X+eyYskOHru3ESKxPQZeYsQVw///QwICAAJf40A== Date: Mon, 24 Sep 2012 07:44:30 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DEB3@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> , <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE08@szxeml546-mbs.china.huawei.com> 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.95] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DEB3szxeml546mbschi_" 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: Mon, 24 Sep 2012 07:46:06 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DEB3szxeml546mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, You are aiming 2 birds with a single stone;) But please see my comments in line. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, September 24, 2012 2:25 PM To: Jiangyuanlong; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong. Lots of thanks for a prompt response and clarification. I have always considered the CW-based proposal for E-tree as the simplest (= and, by implication, the most clean) approach: - No need to distribute the types of ACs a given PE supports (and to re-dis= tribute it when the set of ACs is changed). It is a purely local matter - No OAM issues [JY] it seems neither issue is with 2VLAN, right? - No need to allocate special VLAN tags to mark Leaf and Root- originated t= raffic and to propagate these allocations - hence no problem with preservat= ion of C-VLANs if/when it is needed (or VLAN manipulation) etc. [JY] It may be commensurate with the negotiation of E-Tree bit in the contr= ol word (if using CW), but save the work of redesigning a new forwarding pl= ane;) BTW, not sure what is the problem with preservation of C-VLAN, can yo= u give some more hints? Unfortunately the WG has decided to drop this approach - presumably, becaus= e it mandated the use of CW in the Ethernet PW encapsulation which is not s= upported by some implementations. So now we have a good chance to end with two different solutions (one for E= -VPN and one for regular VPLS), and, most probably, with some additional me= chanism for their interworking... But is probably spilled milk now. Regards. Sasha. ________________________________ From: Jiangyuanlong [jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 4:22 AM To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Sasha, >From Ali's I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS lab= els per Ethernet segment are used for E-Tree. So one is used for root traff= ic and another is used for leaf traffic, just like in the 2PW approach. But it has the same problem as 2PW IMHO and OAM will be a challenge. Besides, manipulation of those labels and import/export of their associated= RT attributes may not be easy. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, September 23, 2012 4:25 PM To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in = the E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (= or more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must s= omehow identify the source AC of the Ethernet frame in this packet, and, in= the case of it being a leaf AC, prevent its forwarding to the local Leaf A= C(s) while allowing forwarding to local Root AC(s). This equally applies to= regular VPLS and E-VPN, e.g., in the case when the contained Ethernet fram= e is a broadcast one (so that no learning is associated with it). And I str= ongly doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me= : > " Giles - are we agreed we want to get to one solution for VPLS a= nd E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a coupl= e of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus t= o > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali stat= ed > that there was no benefit in the E-VPN case in using an additional tag (s= uch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree i= n E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n- > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-= evpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn= -etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etre= e- > 2vlan-00 > > > > > > Abstract: > > This document discusses how the Dual-VLAN approach as described in > > [Etree-vlan] can be used to support the transport of E-Tree service > > in E-VPN. Thus a single convergent solution is possible for both VPLS > > and E-VPN. > > > > > > > > > > The IETF Secretariat > > This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DEB3szxeml546mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,

 

You are aiming 2 birds with a single stone;)

But please see my comments in line.

 

Thanks,

Yuanlong

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@eci= tele.com]
Sent: Monday, September 24, 2012 2:25 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Yuanlong.<= /span>

Lots of th= anks for a prompt response and clarification.

 

I have alw= ays considered the CW-based proposal for E-tree as the simplest (and, by im= plication, the most clean) approach:

- No need = to distribute the types of ACs a given PE supports (and to re-distribute it= when the set of ACs is changed). It is a purely local matter

- No OAM i= ssues

[JY] it seems neither issue is= with 2VLAN, right?

 

- No need = to allocate special VLAN tags to mark Leaf and Root- originated traffic and= to propagate these allocations - hence no problem with preservation of&nbs= p; C-VLANs if/when it is needed (or VLAN manipulation) etc.

[JY] It may be commensurate wi= th the negotiation of E-Tree bit in the control word (if using CW), but sav= e the work of redesigning a new forwarding plane;) BTW, not sure what is the problem with preservation of C-VLAN, can you give som= e more hints?

 

 

Unfortunat= ely the WG has decided to drop this approach - presumably, becaus= e it mandated the use of CW in the Ethernet PW encapsulation which is not s= upported by some implementations.

 

So now we&= nbsp;have a good chance to end with two different solutions (one = for E-VPN and one for regular VPLS), and, most probably, with some addition= al mechanism for their interworking...

 

But is&nbs= p;probably spilled milk now.

 

Regards.

Sasha.

 &nb= sp;  

From: Jiangyuanlong [jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

Sasha,

 

From Ali’s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems = two ESI MPLS labels per Ethernet segment are used for E-Tree. So one is use= d for root traffic and another is used for leaf traffic, just like in the 2PW approach.

But it has the same problem as 2PW IMHO and OAM will be a challen= ge.

Besides, manipulation of those labels and import/export of their = associated RT attributes may not be easy.

 

Thanks,

Yuanlong

 

From: Alexander Vainshtein [mailto:= Alexander.Vainshtein@ecitele.com]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Yuanlo= ng, Giles, Himanshu, Ali and all,

I have= probably missed something important (not being present at the latest IETF = meeting).

But I = think something is wrong with the statement "there was no benefit i= n the E-VPN case in using an additional tag (such as a VLAN)".

 =

IMHO a= nd FWIW the real E-Tree problem is the situation when there are two (or mor= e) PEs with both Root and Leaf ACs.

When o= ne of such PEs receives a VPLS packet from another such PE, it must somehow= identify the source AC of the Ethernet frame in this packet, and, in the c= ase of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root= AC(s). This equally applies to regular VPLS and E-VPN, e.g., in the case w= hen the contained Ethernet frame is a broadcast one (so that no learning is= associated with it). And I strongly doubt this can be achieved without some “tags” in the encapsul= ation.

 =

My 2c,=

 =     Sasha

 =

> -= ----Original Message-----

> F= rom: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf<= /o:p>

> O= f Jiangyuanlong

> S= ent: Saturday, September 22, 2012 5:32 AM

> T= o: Giles Heron

> C= c: l2vpn@ietf.org

> S= ubject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -

> 0= 0.txt

> <= o:p>

> H= i Giles,

> <= o:p>

> P= erhaps the gauge of the consensus in the minutes was not so clear for me:

> &= quot;         Giles - are we agreed= we want to get to one solution for VPLS and E-

> V= PN.

> &= nbsp;         Not many people.=   But even fewer who want multiple.  Checked to see

> i= f

> &= nbsp;         people want one = solution only for E-VPN and VPLS - only a couple of

> h= ands."

> N= evertheless, E-VPN needs an E-Tree solution and it is the WG consensus to

> d= ecide which way to take.

> <= o:p>

> T= hanks,

> Y= uanlong

> <= o:p>

> -= ----Original Message-----

> F= rom: Giles Heron [mailto:giles.heron@gmail.com]

> S= ent: Friday, September 21, 2012 9:09 PM

> T= o: Jiangyuanlong

> C= c: l2vpn@ietf.org

> S= ubject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -

> 0= 0.txt

> <= o:p>

> T= hanks Yuanlong,

> <= o:p>

> h= owever I must say that your memory of the IETF 84 L2VPN meeting differs

> f= rom mine (and from what is noted in the minutes).  Whilst Himanshu sai= d

> t= hat it was better to have the same solution for VPLS and E-VPN, Ali stated<= o:p>

> t= hat there was no benefit in the E-VPN case in using an additional tag (such= as

> a= VLAN).  No consensus was reached in the meeting.

> <= o:p>

> G= iles

> <= o:p>

> O= n 21 Sep 2012, at 10:16, Jiangyuanlong <jiangyuanlong@huawei.com>

> w= rote:

> <= o:p>

> &= gt; Hi all,

> &= gt;

> &= gt; During the 84th IETF meeting, the group discussed the issue of E-Tree i= n E-

> V= PN, and it was shown that a single solution was more preferred than two

> d= ifferent approaches for VPLS and E-VPN.

> &= gt; This I-D probes how the 2VLAN approach can be used to support E-Tree in=

> E= -VPN and it seems not a big issue.

> &= gt; Any comments from you are greatly appreciated.

> &= gt;

> &= gt; Best regards,

> &= gt; Yuanlong

> &= gt;

> &= gt; -----Original Message-----

> &= gt; From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

> &= gt; Sent: Friday, September 21, 2012 4:55 PM

> &= gt; To: Jiangyuanlong

> &= gt; Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-

> 0= 0.txt

> &= gt;

> &= gt;

> &= gt; A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

> &= gt; has been successfully submitted by Yuanlong Jiang and posted to the

> &= gt; IETF repository.

> &= gt;

> &= gt; Filename:     draft-jiang-l2vpn-evpn-etree-2vlan

> &= gt; Revision:      00

> &= gt; Title:           = ;            &n= bsp;       E-Tree Support with 2VLAN in E-VPN=

> &= gt; Creation date:         &nb= sp;  2012-09-21

> &= gt; WG ID:           = ;            &n= bsp;   Individual Submission

> &= gt; Number of pages: 6

> &= gt; URL:           &= nbsp; http://www.ietf.org/i= nternet-drafts/draft-jiang-l2vpn-evpn-

> etree-2vlan-00.txt

> &= gt; Status:          http://datatracker.ie= tf.org/doc/draft-jiang-l2vpn-evpn-etree-

> = 2vlan

> &= gt; Htmlized:        http://tools.ietf.org= /html/draft-jiang-l2vpn-evpn-etree-

> 2v= lan-00

> &= gt;

> &= gt;

> &= gt; Abstract:

> &= gt;   This document discusses how the Dual-VLAN approach as descr= ibed in

> &= gt;   [Etree-vlan] can be used to support the transport of E-Tree= service

> &= gt;   in E-VPN. Thus a single convergent solution is possible for= both VPLS

> &= gt;   and E-VPN.

> &= gt;

> &= gt;

> &= gt;

> &= gt;

> &= gt; The IETF Secretariat

> &= gt;

 =

This e-mail message is intend= ed for the recipient only and contains information which is CONFIDENTIAL an= d which may be proprietary to ECI Telecom. If you have received this transm= ission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=

This e-mail message is intended for the recipient o= nly and contains information which is CONFIDENTIAL and which may be proprie= tary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DEB3szxeml546mbschi_-- From Alexander.Vainshtein@ecitele.com Mon Sep 24 01:13:33 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 93B7921F8527 for ; Mon, 24 Sep 2012 01:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7-7kMrcu3ry for ; Mon, 24 Sep 2012 01:13:28 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 767BA21F8518 for ; Mon, 24 Sep 2012 01:13:27 -0700 (PDT) Received: from [85.158.139.211:36447] by server-1.bemta-5.messagelabs.com id 38/F4-09825-62610605; Mon, 24 Sep 2012 08:13:26 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1348474405!19673738!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 9434 invoked from network); 24 Sep 2012 08:13:26 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-8.tower-206.messagelabs.com with SMTP; 24 Sep 2012 08:13:26 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-a2-50601155413c Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 53.D6.06426.55110605; Mon, 24 Sep 2012 09:52:54 +0200 (IST) Received: from ILPTWPVEXCA02.ecitele.com (172.31.244.232) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 24 Sep 2012 10:12:46 +0200 Received: from ILPTWPVEXMB03.ecitele.com ([fe80::91b4:8f74:ce44:f190]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.01.0379.000; Mon, 24 Sep 2012 10:12:46 +0200 From: Alexander Vainshtein To: Jiangyuanlong , Giles Heron , Ali Sajassi Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: Ac2aLGAdRS8tXuhBSbG0BUc+K0zeAw== Date: Mon, 24 Sep 2012 08:12:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020BA7FDACILPTWPVEXMB03ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLsWRmVeSWpSXmKPExsUy+dWnL7o1ggkBBicmM1k8PTqD0eLqh3Y2 i8ffDrFbvDvbzOLA4jHl90ZWj52z7rJ7tBx5y+qxZMlPpgCWqAZGm8S8vPySxJJUhZTU4mRb pYCizLLE5EolhcwUWyVDJYWCnMTk1NzUvBJbpcSCgtS8FCU7LhugYGaeQmpecn5KZl66rZJn sL+uhYWppa6hkp2asqGxNVdIRmaxQqpubmJmjkJuanFxYnqqAlAE5Oq8lNQUhbT8IoWSjFSF ooTJzBlbWlewF7xuZK44cbmVpYHxzFWmLkZODgkBE4nuI/9ZIWwxiQv31rN1MXJxCAnsZZT4 0NDGCuFsY5TY+KuBHcI5yiixbPt2sBY2AVuJTavvsoHYIgIlEtce7gAbyyygKtGyaR8jiC0s ECpxd+VfdoiaMIkPpx4yQ9h6Em+OTAOzWYDq986fCmbzCgRI7H7TCNbLCHTS91NroGaKS9x6 Mh/qbAGJJXvOM0PYohIvH/+DekFOomnlFXaI+nyJ9v5HLBAzBSVOznwCZgsJ6EqcOtEFNUdS 4uCKGywTGMVmIVkxC0n7LCTtEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaGZOQUlS brqBoV5qcmZJak6qXnJ+7iZGSJp6voPx13yVQ4wCHIxKPLwvNsUHCLEmlhVX5h5ilORgUhLl nSCcECDEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhDfiGVA5b0piZVVqUT5MyhUYmhOZpbiT80Hp oCTe2MAAN0dJnHd5Q7i/kEA6MHVmp6YWpBbBzJHh4FCS4C0RBVovWJSanlqRlplTgpBm4uAE OYMH6IzLIkA1vMUFibnFmekQ+VOMlhyzpyx5wMixZi6IfHQXSAqx5OXnpUqJ8waBDBUAacgo zYObCcpl9f///3/FKA4MDGHeApAqHmBqhpv6CmghE9BC/j1xIAuBOQouJdXAeF3wXcHPrS93 z255F9vZ4xD6b+UHC3+zh6KeYVMVZ9aqcqR0ssi53r+qftlX6+LyuCV5l1cs9T7OcSVfefa2 iRLqufVHZFV757Zfzdl8rcDnzbLJKloMRsJxUzxjKpcLlDm6s749xPLxxKn8L5NT59lxbeVx z7HZJbjlfeqCntVhHA5awZsTlViKMxINtZiLihMBmRC3tUAEAAA= 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: Mon, 24 Sep 2012 08:13:33 -0000 --_000_F9336571731ADE42A5397FC831CEAA020BA7FDACILPTWPVEXMB03ec_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Yuanlong hi! Lots of thanks for a prompt response. Please see some responses in line below. Regards, Sasha From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 9:44 AM To: Alexander Vainshtein; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Hi Sasha, You are aiming 2 birds with a single stone;) But please see my comments in line. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, September 24, 2012 2:25 PM To: Jiangyuanlong; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Yuanlong. Lots of thanks for a prompt response and clarification. I have always considered the CW-based proposal for E-tree as the simplest (a= nd, by implication, the most clean) approach: - No need to distribute the types of ACs a given PE supports (and to re-dist= ribute it when the set of ACs is changed). It is a purely local matter - No OAM issues [JY] it seems neither issue is with 2VLAN, right? - No need to allocate special VLAN tags to mark Leaf and Root- originated tr= affic and to propagate these allocations - hence no problem with preservatio= n of C-VLANs if/when it is needed (or VLAN manipulation) etc. [JY] It may be commensurate with the negotiation of E-Tree bit in the contro= l word (if using CW), but save the work of redesigning a new forwarding plan= e;) BTW, not sure what is the problem with preservation of C-VLAN, can you g= ive some more hints? [[[Sasha]]] You do not really have to negotiate usage of the Leaf flag in t= he CW. At most you have to negotiate usage of the CW, which is well defined= (including the latest standard for changes in the preferred CW usage:-). An= d you would locally configure your VPLS instance to be an E-Tree on and henc= e setting the Leaf flag on Tx to peers and respecting the value of this flag= received from your peers. A regular VPLS instance (equivalent to Root only)= would never set this flag on Tx and ignore it on Rx - so you would have com= plete backward compatibility at no cost. As for the new forwarding plane: IMHO you need some modifications in the for= warding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-Lea= f traffic regardless of how you identify it. I do not see how you can avoid= it taking into account that E-Tree forwarding behavior is different from a= plain old Layer 2 switch. Regarding preservation of C-VLANs - would you not need to push the Root/Leaf= VLAN tag on top of the C-tag you are going to preserve? This may result in= backward compatibility issues when you have Root-only PEs that now have to= be aware of these additional VLAN tags (push them on Tx and pop them on Rx)= . Unfortunately the WG has decided to drop this approach - presumably, because= it mandated the use of CW in the Ethernet PW encapsulation which is not sup= ported by some implementations. So now we have a good chance to end with two different solutions (one for E-= VPN and one for regular VPLS), and, most probably, with some additional mech= anism for their interworking... But is probably spilled milk now. Regards. Sasha. ________________________________ From: Jiangyuanlong [jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 4:22 AM To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Sasha, >From Ali's I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS labe= ls per Ethernet segment are used for E-Tree. So one is used for root traffic= and another is used for leaf traffic, just like in the 2PW approach. But it has the same problem as 2PW IMHO and OAM will be a challenge. Besides, manipulation of those labels and import/export of their associated= RT attributes may not be easy. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, September 23, 2012 4:25 PM To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in t= he E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (o= r more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must so= mehow identify the source AC of the Ethernet frame in this packet, and, in t= he case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s= ) while allowing forwarding to local Root AC(s). This equally applies to reg= ular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame is= a broadcast one (so that no learning is associated with it). And I strongly= doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vl= an- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me: > " Giles - are we agreed we want to get to one solution for VPLS an= d E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a couple= of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus to > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vl= an- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali state= d > that there was no benefit in the E-VPN case in using an additional tag (su= ch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree in= E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= - > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-e= vpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-= etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree= - > 2vlan-00 > > > > > > Abstract: > > This document discusses how the Dual-VLAN approach as described in > > [Etree-vlan] can be used to support the transport of E-Tree service > > in E-VPN. Thus a single convergent solution is possible for both VPLS > > and E-VPN. > > > > > > > > > > The IETF Secretariat > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020BA7FDACILPTWPVEXMB03ec_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Yuanlong hi!

Lots of thanks for a prompt response.=

Please see some responses in line below.

 

Regards,

    = ; Sasha

 

From: Jiangyuanlo= ng [mailto:jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 9:44 AM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

 

Hi Sasha,

 

You are aiming 2 birds with a single stone;)=

But please see my comments in line.

 

Thanks,

Yuanlong

 

From:= Alexander Vainshtein [mailto:Alex= ander.Vainshtein@ecitele.com]
Sent: Monday, September 24, 2012 2:25 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

 = ;

Yuanlong.

Lots of thanks for a prompt response and clarification.

 <= /span>

I have always considered the CW-based proposal for E-tree as the simplest (= and, by implication, the most clean) approach:

- No need to distribute the types of ACs a given PE supports (and to re-dis= tribute it when the set of ACs is changed). It is a purely local matter=

- No OAM issues

[JY] it seems neithe= r issue is with 2VLAN, right?

 

- No need to allocate special VLAN tags to mark Leaf and Root- originated t= raffic and to propagate these allocations - hence no problem with preservati= on of  C-VLANs if/when it is needed (or VLAN manipulation) etc.

[JY] It may be comme= nsurate with the negotiation of E-Tree bit in the control word (if using CW)= , but save the work of redesigning a new forwarding plane;) BTW, not sure what is the problem with preservation of C-VLAN, can= you give some more hints?

[[[Sasha]]] Yo= u do not really have to negotiate usage= of the Leaf  flag in the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standard for changes in the pre= ferred CW usage:-). And you would locally configure your VPLS instance to be= an E-Tree on and hence setting the Leaf flag on Tx to peers and respecting= the value of this flag received from your peers. A regular VPLS instance (equivalent to Root only) would ne= ver set this flag on Tx and ignore it on Rx – so you would have comple= te backward compatibility at no cost.

 

As for the new= forwarding plane: IMHO you need some modifications in the forwarding plane= to mark Leaf-originated traffic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how yo= u can avoid it taking into account that E-Tree forwarding behavior is differ= ent from a plain old Layer 2 switch.

Regarding pres= ervation of C-VLANs – would you not need to push the Root/Leaf VLAN ta= g on top of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that no= w have to be aware of these additional VLAN tags (push them on Tx and pop th= em on Rx).

 

 <= /span>

Unfortunately the WG has decided to drop this approach - presumab= ly, because it mandated the use of CW in the Ethernet PW encapsulation which= is not supported by some implementations.

 <= /span>

So now we have a good chance to end with two different solut= ions (one for E-VPN and one for regular VPLS), and, most probably, with some= additional mechanism for their interworking...

 <= /span>

But is probably spilled milk now.

 <= /span>

Regards.=

Sasha.

    

From: Jiangyuanlong [jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt<= o:p>

Sasha,

 

From Ali’s I-D draft-sajassi-l2vpn-evpn-etree-00,= it seems two ESI MPLS labels per Ethernet segment are used for E-Tree. So o= ne is used for root traffic and another is used for leaf traffic, just like in the 2PW approach.

But it has the same problem as 2PW IMHO and OAM will be= a challenge.<= o:p>

Besides, manipulation of those labels and import/export= of their associated RT attributes may not be easy.

 

Thanks,

Yuanlong

 

= From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt=

 

Yuanlong, Giles, Himanshu, Ali and all,

I have probably missed something important (not being present at the la= test IETF meeting).

But I think something is wrong with the statement "there was no= benefit in the E-VPN case in using an additional tag (such as a VLAN)"= .

 

IMHO and FWIW the real E-Tree problem is the situation when there are t= wo (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from another such PE, it mu= st somehow identify the source AC of the Ethernet frame in this packet, and,= in the case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to= local Root AC(s). This equally applies to regular VPLS and E-VPN, e.g., in= the case when the contained Ethernet frame is a broadcast one (so that no l= earning is associated with it). And I strongly doubt this can be achieved without some “tags” i= n the encapsulation.

 

My 2c,

     Sasha

 

> -----Original Message-----

> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-e= tree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minutes was not so clear= for me:

> "         Giles - are= we agreed we want to get to one solution for VPLS and E-<= /p>

> VPN.

>           Not ma= ny people.  But even fewer who want multiple.  Checked to see=

> if

>           people= want one solution only for E-VPN and VPLS - only a couple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution and it is the WG cons= ensus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:giles.heron@gmail.com]=

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org

> Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-e= tree-2vlan-

> 00.txt

>

> Thanks Yuanlong,

>

> however I must say that your memory of the IETF 84 L2VPN meeting d= iffers

> from mine (and from what is noted in the minutes).  Whilst Hi= manshu said

> that it was better to have the same solution for VPLS and E-VPN, A= li stated

> that there was no benefit in the E-VPN case in using an additional= tag (such as

> a VLAN).  No consensus was reached in the meeting.=

>

> Giles

>

> On 21 Sep 2012, at 10:16, Jiangyuanlong <jiangyuanlong@huawei.com= ><= /o:p>

> wrote:

>

> > Hi all,

> >

> > During the 84th IETF meeting, the group discussed the issue o= f E-Tree in E-

> VPN, and it was shown that a single solution was more preferred th= an two

> different approaches for VPLS and E-VPN.

> > This I-D probes how the 2VLAN approach can be used to support= E-Tree in

> E-VPN and it seems not a big issue.

> > Any comments from you are greatly appreciated.

> >

> > Best regards,

> > Yuanlong

> >

> > -----Original Message-----

> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.o= rg]

> > Sent: Friday, September 21, 2012 4:55 PM

> > To: Jiangyuanlong

> > Subject: New Version Notification for draft-jiang-l2vpn-evpn-= etree-2vlan-

> 00.txt

> >

> >

> > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.t= xt

> > has been successfully submitted by Yuanlong Jiang and posted= to the

> > IETF repository.

> >

> > Filename:     draft-jiang-l2vpn-evpn-etre= e-2vlan

> > Revision:      00<= /p>

> > Title:         &= nbsp;            = ;         E-Tree Support with 2VLAN= in E-VPN

> > Creation date:        = ;    2012-09-21

> > WG ID:         &= nbsp;            = ;     Individual Submission

> > Number of pages: 6

> > URL:         &nb= sp;   http://www.ietf.org/internet-dra= fts/draft-jiang-l2vpn-evpn-

> etree-2v= lan-00.txt=

> > Status:          http://datatracker.ietf.org/doc/draft-jiang= -l2vpn-evpn-etree-

> 2vlan

> > Htmlized:        http://tools.ietf.org/html/draft-jiang-l2vpn-= evpn-etree-

> 2vlan-00

> >

> >

> > Abstract:

> >   This document discusses how the Dual-VLAN approac= h as described in

> >   [Etree-vlan] can be used to support the transport= of E-Tree service

> >   in E-VPN. Thus a single convergent solution is po= ssible for both VPLS

> >   and E-VPN.

> >

> >

> >

> >

> > The IETF Secretariat

> >

 

This e-mail messag= e is intended for the recipient only and contains information which is CONFI= DENTIAL and which may be proprietary to ECI Telecom. If you have received th= is transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all cop= ies thereof.

This e-mail message is intende= d for the recipient only and contains information which is CONFIDENTIAL and= which may be proprietary to ECI Telecom. If you have received this transmis= sion in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereo= f.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020BA7FDACILPTWPVEXMB03ec_-- From jiangyuanlong@huawei.com Mon Sep 24 04:39:23 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 B3CB921F85AC for ; Mon, 24 Sep 2012 04:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYmmvz0G6vmK for ; Mon, 24 Sep 2012 04:39:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D85721F851A for ; Mon, 24 Sep 2012 04:39:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKZ40216; Mon, 24 Sep 2012 11:39:14 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 12:38:27 +0100 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 12:38:47 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 19:38:39 +0800 From: Jiangyuanlong To: Alexander Vainshtein , Giles Heron , Ali Sajassi Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: Ac2aLGAdAR1X+eyYskOHru3ESKxPQQAF4Pbg Date: Mon, 24 Sep 2012 11:38:39 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11@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.66.77.95] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11szxeml546mbschi_" 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: Mon, 24 Sep 2012 11:39:23 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11szxeml546mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, Just snips of it: [[[Sasha]]] You do not really have to negotiate usage of the Leaf flag in = the CW. At most you have to negotiate usage of the CW, which is well define= d (including the latest standard for changes in the preferred CW usage:-). = And you would locally configure your VPLS instance to be an E-Tree on and h= ence setting the Leaf flag on Tx to peers and respecting the value of this = flag received from your peers. A regular VPLS instance (equivalent to Root = only) would never set this flag on Tx and ignore it on Rx - so you would ha= ve complete backward compatibility at no cost. [JY] Yes, you are right that only CW negotiation is needed. Though I am not= sure if a PE has no capability of CW support, how can this approach be bac= kward compatible? As for the new forwarding plane: IMHO you need some modifications in the fo= rwarding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-L= eaf traffic regardless of how you identify it. I do not see how you can avo= id it taking into account that E-Tree forwarding behavior is different from= a plain old Layer 2 switch. [JY] Consider the access may well be an Ethernet network, 2VLAN should be s= upported there or in the bridge module, thus there is no need to introduce = new forwarding paradigms in the VSI. For the same reason, if CW solution is adopted, except the new modification= s in VSI, 2VLAN may still be needed on the bridge module side. Regarding preservation of C-VLANs - would you not need to push the Root/Lea= f VLAN tag on top of the C-tag you are going to preserve? This may result i= n backward compatibility issues when you have Root-only PEs that now have t= o be aware of these additional VLAN tags (push them on Tx and pop them on R= x). [JY] That is not the case. You can have a look at Section 5.3.2 of draft-ie= tf-l2vpn-vpls-pe-etree-00, it says raw PW should be used, thus no root or l= eaf VLAN tag is needed on the PW. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, September 24, 2012 4:13 PM To: Jiangyuanlong; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong hi! Lots of thanks for a prompt response. Please see some responses in line below. Regards, Sasha From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 9:44 AM To: Alexander Vainshtein; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Hi Sasha, You are aiming 2 birds with a single stone;) But please see my comments in line. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, September 24, 2012 2:25 PM To: Jiangyuanlong; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong. Lots of thanks for a prompt response and clarification. I have always considered the CW-based proposal for E-tree as the simplest (= and, by implication, the most clean) approach: - No need to distribute the types of ACs a given PE supports (and to re-dis= tribute it when the set of ACs is changed). It is a purely local matter - No OAM issues [JY] it seems neither issue is with 2VLAN, right? - No need to allocate special VLAN tags to mark Leaf and Root- originated t= raffic and to propagate these allocations - hence no problem with preservat= ion of C-VLANs if/when it is needed (or VLAN manipulation) etc. [JY] It may be commensurate with the negotiation of E-Tree bit in the contr= ol word (if using CW), but save the work of redesigning a new forwarding pl= ane;) BTW, not sure what is the problem with preservation of C-VLAN, can yo= u give some more hints? [[[Sasha]]] You do not really have to negotiate usage of the Leaf flag in = the CW. At most you have to negotiate usage of the CW, which is well define= d (including the latest standard for changes in the preferred CW usage:-). = And you would locally configure your VPLS instance to be an E-Tree on and h= ence setting the Leaf flag on Tx to peers and respecting the value of this = flag received from your peers. A regular VPLS instance (equivalent to Root = only) would never set this flag on Tx and ignore it on Rx - so you would ha= ve complete backward compatibility at no cost. As for the new forwarding plane: IMHO you need some modifications in the fo= rwarding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-L= eaf traffic regardless of how you identify it. I do not see how you can avo= id it taking into account that E-Tree forwarding behavior is different from= a plain old Layer 2 switch. Regarding preservation of C-VLANs - would you not need to push the Root/Lea= f VLAN tag on top of the C-tag you are going to preserve? This may result i= n backward compatibility issues when you have Root-only PEs that now have t= o be aware of these additional VLAN tags (push them on Tx and pop them on R= x). Unfortunately the WG has decided to drop this approach - presumably, becaus= e it mandated the use of CW in the Ethernet PW encapsulation which is not s= upported by some implementations. So now we have a good chance to end with two different solutions (one for E= -VPN and one for regular VPLS), and, most probably, with some additional me= chanism for their interworking... But is probably spilled milk now. Regards. Sasha. ________________________________ From: Jiangyuanlong [jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 4:22 AM To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Sasha, >From Ali's I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS lab= els per Ethernet segment are used for E-Tree. So one is used for root traff= ic and another is used for leaf traffic, just like in the 2PW approach. But it has the same problem as 2PW IMHO and OAM will be a challenge. Besides, manipulation of those labels and import/export of their associated= RT attributes may not be easy. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, September 23, 2012 4:25 PM To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in = the E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (= or more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must s= omehow identify the source AC of the Ethernet frame in this packet, and, in= the case of it being a leaf AC, prevent its forwarding to the local Leaf A= C(s) while allowing forwarding to local Root AC(s). This equally applies to= regular VPLS and E-VPN, e.g., in the case when the contained Ethernet fram= e is a broadcast one (so that no learning is associated with it). And I str= ongly doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me= : > " Giles - are we agreed we want to get to one solution for VPLS a= nd E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a coupl= e of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus t= o > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali stat= ed > that there was no benefit in the E-VPN case in using an additional tag (s= uch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree i= n E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n- > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-= evpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn= -etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etre= e- > 2vlan-00 > > > > > > Abstract: > > This document discusses how the Dual-VLAN approach as described in > > [Etree-vlan] can be used to support the transport of E-Tree service > > in E-VPN. Thus a single convergent solution is possible for both VPLS > > and E-VPN. > > > > > > > > > > The IETF Secretariat > > This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11szxeml546mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,

 =

Just snips of it:

[[[Sasha]]] You do not r= eally have to negotiate usage of the Le= af  flag in the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standar= d for changes in the preferred CW usage:-). And you would locally configure= your VPLS instance to be an E-Tree on and hence setting the Leaf flag on T= x to peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent= to Root only) would never set this flag on Tx and ignore it on Rx – = so you would have complete backward compatibility at no cost.

[JY] Yes, you are right = that only CW negotiation is needed. Though I am not sure if a PE has no cap= ability of CW support, how can this approach be backward compatible?

 =

As for the new forwardin= g plane: IMHO you need some modifications in the forwarding plane to mark L= eaf-originated traffic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how you can avoid it takin= g into account that E-Tree forwarding behavior is different from a plain ol= d Layer 2 switch.

[JY] Consider the access= may well be an Ethernet network, 2VLAN should be supported there or in the= bridge module, thus there is no need to introduce new forwarding paradigms in the VSI.

For the same reason, if = CW solution is adopted, except the new modifications in VSI, 2VLAN may stil= l be needed on the bridge module side.

 

Regarding preservation o= f C-VLANs – would you not need to push the Root/Leaf VLAN tag on top = of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to be aware= of these additional VLAN tags (push them on Tx and pop them on Rx).

[JY] That is not the cas= e. You can have a look at Section 5.3.2 of draft-ietf-l2vpn-vpls-pe-etree-0= 0, it says raw PW should be used, thus no root or leaf VLAN tag is needed on the PW.

 

Thanks,

Yuanlong



<= /o:p>

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@eci= tele.com]
Sent: Monday, September 24, 2012 4:13 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Yuanlong hi!

Lots of thanks for a prompt response.

Please see some responses in line below.

&n= bsp;

Regards= ,

 &= nbsp;   Sasha

&n= bsp;

From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 9:44 AM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Hi Sasha,

 

You are aiming 2 birds with a single stone;)

But please see my comments in line.

 

Thanks,

Yuanlong

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@eci= tele.com]
Sent: Monday, September 24, 2012 2:25 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Yuanlong.<= /span>

Lots of th= anks for a prompt response and clarification.

 

I have alw= ays considered the CW-based proposal for E-tree as the simplest (and, by im= plication, the most clean) approach:

- No need = to distribute the types of ACs a given PE supports (and to re-distribute it= when the set of ACs is changed). It is a purely local matter

- No OAM i= ssues

[JY] it seems neither issue is= with 2VLAN, right?

 

- No need = to allocate special VLAN tags to mark Leaf and Root- originated traffic and= to propagate these allocations - hence no problem with preservation of&nbs= p; C-VLANs if/when it is needed (or VLAN manipulation) etc.

[JY] It may be commensurate wi= th the negotiation of E-Tree bit in the control word (if using CW), but sav= e the work of redesigning a new forwarding plane;) BTW, not sure what is the problem with preservation of C-VLAN, can you give som= e more hints?

[[[Sasha]]] You do not r= eally have to negotiate usage of the Le= af  flag in the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standar= d for changes in the preferred CW usage:-). And you would locally configure= your VPLS instance to be an E-Tree on and hence setting the Leaf flag on T= x to peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent= to Root only) would never set this flag on Tx and ignore it on Rx – = so you would have complete backward compatibility at no cost.

 =

As for the new forwardin= g plane: IMHO you need some modifications in the forwarding plane to mark L= eaf-originated traffic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how you can avoid it takin= g into account that E-Tree forwarding behavior is different from a plain ol= d Layer 2 switch. =

Regarding preservation o= f C-VLANs – would you not need to push the Root/Leaf VLAN tag on top = of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to be aware= of these additional VLAN tags (push them on Tx and pop them on Rx).

 

 

Unfortunat= ely the WG has decided to drop this approach - presumably, becaus= e it mandated the use of CW in the Ethernet PW encapsulation which is not s= upported by some implementations.

 

So now we&= nbsp;have a good chance to end with two different solutions (one = for E-VPN and one for regular VPLS), and, most probably, with some addition= al mechanism for their interworking...

 

But is&nbs= p;probably spilled milk now.

 

Regards.

Sasha.

 &nb= sp;  

From: Jiangyuanlong [jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

Sasha,

 

From Ali’s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems = two ESI MPLS labels per Ethernet segment are used for E-Tree. So one is use= d for root traffic and another is used for leaf traffic, just like in the 2PW approach.

But it has the same problem as 2PW IMHO and OAM will be a challen= ge.

Besides, manipulation of those labels and import/export of their = associated RT attributes may not be easy.

 

Thanks,

Yuanlong

 

From: Alexander Vainshtein [mailto:= Alexander.Vainshtein@ecitele.com]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Yuanlo= ng, Giles, Himanshu, Ali and all,

I have= probably missed something important (not being present at the latest IETF = meeting).

But I = think something is wrong with the statement "there was no benefit i= n the E-VPN case in using an additional tag (such as a VLAN)".

 =

IMHO a= nd FWIW the real E-Tree problem is the situation when there are two (or mor= e) PEs with both Root and Leaf ACs.

When o= ne of such PEs receives a VPLS packet from another such PE, it must somehow= identify the source AC of the Ethernet frame in this packet, and, in the c= ase of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root= AC(s). This equally applies to regular VPLS and E-VPN, e.g., in the case w= hen the contained Ethernet frame is a broadcast one (so that no learning is= associated with it). And I strongly doubt this can be achieved without some “tags” in the encapsul= ation.

 =

My 2c,=

 =     Sasha

 =

> -= ----Original Message-----

> F= rom: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf<= /o:p>

> O= f Jiangyuanlong

> S= ent: Saturday, September 22, 2012 5:32 AM

> T= o: Giles Heron

> C= c: l2vpn@ietf.org

> S= ubject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -

> 0= 0.txt

> <= o:p>

> H= i Giles,

> <= o:p>

> P= erhaps the gauge of the consensus in the minutes was not so clear for me:

> &= quot;         Giles - are we agreed= we want to get to one solution for VPLS and E-

> V= PN.

> &= nbsp;         Not many people.=   But even fewer who want multiple.  Checked to see

> i= f

> &= nbsp;         people want one = solution only for E-VPN and VPLS - only a couple of

> h= ands."

> N= evertheless, E-VPN needs an E-Tree solution and it is the WG consensus to

> d= ecide which way to take.

> <= o:p>

> T= hanks,

> Y= uanlong

> <= o:p>

> -= ----Original Message-----

> F= rom: Giles Heron [mailto:giles.heron@gmail.com]

> S= ent: Friday, September 21, 2012 9:09 PM

> T= o: Jiangyuanlong

> C= c: l2vpn@ietf.org

> S= ubject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -

> 0= 0.txt

> <= o:p>

> T= hanks Yuanlong,

> <= o:p>

> h= owever I must say that your memory of the IETF 84 L2VPN meeting differs

> f= rom mine (and from what is noted in the minutes).  Whilst Himanshu sai= d

> t= hat it was better to have the same solution for VPLS and E-VPN, Ali stated<= o:p>

> t= hat there was no benefit in the E-VPN case in using an additional tag (such= as

> a= VLAN).  No consensus was reached in the meeting.

> <= o:p>

> G= iles

> <= o:p>

> O= n 21 Sep 2012, at 10:16, Jiangyuanlong <jiangyuanlong@huawei.com>

> w= rote:

> <= o:p>

> &= gt; Hi all,

> &= gt;

> &= gt; During the 84th IETF meeting, the group discussed the issue of E-Tree i= n E-

> V= PN, and it was shown that a single solution was more preferred than two

> d= ifferent approaches for VPLS and E-VPN.

> &= gt; This I-D probes how the 2VLAN approach can be used to support E-Tree in=

> E= -VPN and it seems not a big issue.

> &= gt; Any comments from you are greatly appreciated.

> &= gt;

> &= gt; Best regards,

> &= gt; Yuanlong

> &= gt;

> &= gt; -----Original Message-----

> &= gt; From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

> &= gt; Sent: Friday, September 21, 2012 4:55 PM

> &= gt; To: Jiangyuanlong

> &= gt; Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-

> 0= 0.txt

> &= gt;

> &= gt;

> &= gt; A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

> &= gt; has been successfully submitted by Yuanlong Jiang and posted to the

> &= gt; IETF repository.

> &= gt;

> &= gt; Filename:     draft-jiang-l2vpn-evpn-etree-2vlan

> &= gt; Revision:      00

> &= gt; Title:           = ;            &n= bsp;       E-Tree Support with 2VLAN in E-VPN=

> &= gt; Creation date:         &nb= sp;  2012-09-21

> &= gt; WG ID:           = ;            &n= bsp;   Individual Submission

> &= gt; Number of pages: 6

> &= gt; URL:           &= nbsp; http://www.ietf.org/internet-drafts= /draft-jiang-l2vpn-evpn-<= /span>

> etree-2vlan= -00.txt

> &= gt; Status:          http://datatracker.ietf.org/doc/draft-jiang-l2= vpn-evpn-etree-

> 2vlan

> &= gt; Htmlized:        http://tools.ietf.org/html/draft-jiang-l2vpn-evp= n-etree-

> 2vlan-00

> &= gt;

> &= gt;

> &= gt; Abstract:

> &= gt;   This document discusses how the Dual-VLAN approach as descr= ibed in

> &= gt;   [Etree-vlan] can be used to support the transport of E-Tree= service

> &= gt;   in E-VPN. Thus a single convergent solution is possible for= both VPLS

> &= gt;   and E-VPN.

> &= gt;

> &= gt;

> &= gt;

> &= gt;

> &= gt; The IETF Secretariat

> &= gt;

 =

This e-mail message is intend= ed for the recipient only and contains information which is CONFIDENTIAL an= d which may be proprietary to ECI Telecom. If you have received this transm= ission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=

This e-mail message is intended for the recipient o= nly and contains information which is CONFIDENTIAL and which may be proprie= tary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient o= nly and contains information which is CONFIDENTIAL and which may be proprie= tary to ECI Telecom. If you have received this transmission in error, pleas= e inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11szxeml546mbschi_-- From Alexander.Vainshtein@ecitele.com Mon Sep 24 05:07: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 F225E21F862A for ; Mon, 24 Sep 2012 05:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.076 X-Spam-Level: X-Spam-Status: No, score=-4.076 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMbCq4hwSZGs for ; Mon, 24 Sep 2012 05:07:43 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5857521F8628 for ; Mon, 24 Sep 2012 05:07:42 -0700 (PDT) Received: from [85.158.137.99:24414] by server-14.bemta-3.messagelabs.com id 87/04-21431-D0D40605; Mon, 24 Sep 2012 12:07:41 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1348488459!16528029!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 735 invoked from network); 24 Sep 2012 12:07:40 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-15.tower-217.messagelabs.com with SMTP; 24 Sep 2012 12:07:40 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-75-506048603f52 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 29.E2.06426.06840605; Mon, 24 Sep 2012 13:47:44 +0200 (IST) Received: from ILPTWPVEXCA02.ecitele.com (172.31.244.232) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 24 Sep 2012 14:07:36 +0200 Received: from ILPTWPVEXMB03.ecitele.com ([fe80::91b4:8f74:ce44:f190]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.01.0379.000; Mon, 24 Sep 2012 14:07:36 +0200 From: Alexander Vainshtein To: Jiangyuanlong , Giles Heron , Ali Sajassi Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: Ac2aLGAdRS8tXuhBSbG0BUc+K0zeAwADABOAAATzWPU= Date: Mon, 24 Sep 2012 12:07:34 +0000 Message-ID: References: , <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11@szxeml546-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020BA7FF25ILPTWPVEXMB03ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTW2zTVhjeiZ3ELfUwgdJDhDTPjD6AAok6ppQRmCahZRuXcB0CicZJThOL xM5sB7V72MooKvCydnRaSTWFSeHSUcYaoamIcIuGYEFcxU2IroVSrXTallHK1FVNdxyX0hde rM//9/3f95+j/1CEJWO2UoKoIlnkw5ypmNw38PSZjXd7PfaOR0XOvgstwHk712By9j7PmJ1/ XdlJvke6m0c6jO6T8S6zu/6XP43uZHLY4CE314ElvChKKq8iNoAUv4vzyMJ23l/LsULAxTk4 Nhrm/SiCRNXF8dEoEgPc0uIluCiILBL9UkAQgy7uw3WrbU7nokqbg1taPsdR8W7x+pCgsMgW 4YUwG0GKwgcRiyva1GIABdhqSWbVEGJl7z4idHJwQzR/mqg5kc2b68DxvGEvKKIg8zZMdT4w 6XgmvP7bcYyLKQtzFsDBttYCYWE6ARyOe3XiAoDf7D9FaoSJccHU0a6CaAajwjsPOwuuBDMX 1qfOAA1PZzbArrZRs67ZCHPZh4SOF8PnI0cKdRLrDzy5WMA044E30xmgh8UBvN/9bYEows2J L38qmAI86r/Z9vGwMnj/cWL8OAxMpq8ROi6FT3rzRh2/AW/kerCGwnoJHht9U8+aBn/d/5jU D2mD2Ut7x21mwfNH7pGNAMYnJcRfdscndesSO/z7aoLQ8Xx46Ps/xvFC2PHsCphcPwDMP4BS IRxVfZGg3bEA+QUVhdECvxRJAX3Rfu8E/yXeygCGAlwJ3Z+q8liM/HalNpIBsygDV0o/WO71 WF73SYHaEK+EquRYGCkZACmCm0E3OTBHB/jaz5AsvaCW40tuIqxT/JK2HGpVhd3+6h+ujD5c 98lqCxPEK7sNoSiSX/jMpigO0sQKHDFNRkFUUy2E1Ze0gSrSxijBYxg1Da1E+YgiBHU+Cyqp 1uZkD6Dav9O+j7rw10KKkoisZfQirYHRGkIxccJTe3pfjI2NDYAyfBnTabumKsErPuE6gAMN OHBqeqsWiJ/ZBGWtA75DwjnP8AdziPU+pv1i+d2QrfX9lqF7n+7oHcqv6u9fs7Jl9pR0vql+ z7rLvT+OXvJt2ZM9UykcHfnn8583n0tbNq2duSzWvOvgyr7uHa8NlUe+rnFeJz/6OGm91fdO g3Vkm5Lo252tHmzc7f0qdqO7EXUcbBu9asoNnG89FqvI1fc0cKQS4h3zCFnh/weXs0LzVQQA AA== 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: Mon, 24 Sep 2012 12:07:47 -0000 --_000_F9336571731ADE42A5397FC831CEAA020BA7FF25ILPTWPVEXMB03ec_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Hi Yuanlong, Please see some answers inline below (bold magenta italics). Regards, Sasha ________________________________ From: Jiangyuanlong [jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 1:38 PM To: Alexander Vainshtein; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Hi Sasha, Just snips of it: [[[Sasha]]] You do not really have to negotiate usage of the Leaf flag in t= he CW. At most you have to negotiate usage of the CW, which is well defined= (including the latest standard for changes in the preferred CW usage:-). An= d you would locally configure your VPLS instance to be an E-Tree on and henc= e setting the Leaf flag on Tx to peers and respecting the value of this flag= received from your peers. A regular VPLS instance (equivalent to Root only)= would never set this flag on Tx and ignore it on Rx =96 so you would have c= omplete backward compatibility at no cost. [JY] Yes, you are right that only CW negotiation is needed. Though I am not= sure if a PE has no capability of CW support, how can this approach be back= ward compatible? [[Sasha]] If PE does not support the CW, it can only act as a Root-only PE,= and treated as scuh by its peers. (I assume that a given PE either supports= CW vs. any peer, or does not support CW at all, so there should not be any= contradiction.) As for the new forwarding plane: IMHO you need some modifications in the for= warding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-Lea= f traffic regardless of how you identify it. I do not see how you can avoid= it taking into account that E-Tree forwarding behavior is different from a= plain old Layer 2 switch. [JY] Consider the access may well be an Ethernet network, 2VLAN should be su= pported there or in the bridge module, thus there is no need to introduce ne= w forwarding paradigms in the VSI. For the same reason, if CW solution is adopted, except the new modifications= in VSI, 2VLAN may still be needed on the bridge module side. [[Sasha]] I see it a bit differently: if your access is Ethernet, you need t= wo ACs between your PE and its adjacent access device, one for Root and one= for Leaf. No need to involve the bridge module of the PE into access behavi= or, especially if you want to run xSTP in your access network IMO. Regarding preservation of C-VLANs =96 would you not need to push the Root/Le= af VLAN tag on top of the C-tag you are going to preserve? This may result i= n backward compatibility issues when you have Root-only PEs that now have to= be aware of these additional VLAN tags (push them on Tx and pop them on Rx)= . [JY] That is not the case. You can have a look at Section 5.3.2 of draft-iet= f-l2vpn-vpls-pe-etree-00, it says raw PW should be used, thus no root or lea= f VLAN tag is needed on the PW. [[Sasha]] I am not sure I understand, will look up the draft and respond. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, September 24, 2012 4:13 PM To: Jiangyuanlong; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Yuanlong hi! Lots of thanks for a prompt response. Please see some responses in line below. Regards, Sasha From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 9:44 AM To: Alexander Vainshtein; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Hi Sasha, You are aiming 2 birds with a single stone;) But please see my comments in line. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, September 24, 2012 2:25 PM To: Jiangyuanlong; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Yuanlong. Lots of thanks for a prompt response and clarification. I have always considered the CW-based proposal for E-tree as the simplest (a= nd, by implication, the most clean) approach: - No need to distribute the types of ACs a given PE supports (and to re-dist= ribute it when the set of ACs is changed). It is a purely local matter - No OAM issues [JY] it seems neither issue is with 2VLAN, right? - No need to allocate special VLAN tags to mark Leaf and Root- originated tr= affic and to propagate these allocations - hence no problem with preservatio= n of C-VLANs if/when it is needed (or VLAN manipulation) etc. [JY] It may be commensurate with the negotiation of E-Tree bit in the contro= l word (if using CW), but save the work of redesigning a new forwarding plan= e;) BTW, not sure what is the problem with preservation of C-VLAN, can you g= ive some more hints? [[[Sasha]]] You do not really have to negotiate usage of the Leaf flag in t= he CW. At most you have to negotiate usage of the CW, which is well defined= (including the latest standard for changes in the preferred CW usage:-). An= d you would locally configure your VPLS instance to be an E-Tree on and henc= e setting the Leaf flag on Tx to peers and respecting the value of this flag= received from your peers. A regular VPLS instance (equivalent to Root only)= would never set this flag on Tx and ignore it on Rx =96 so you would have c= omplete backward compatibility at no cost. As for the new forwarding plane: IMHO you need some modifications in the for= warding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-Lea= f traffic regardless of how you identify it. I do not see how you can avoid= it taking into account that E-Tree forwarding behavior is different from a= plain old Layer 2 switch. Regarding preservation of C-VLANs =96 would you not need to push the Root/Le= af VLAN tag on top of the C-tag you are going to preserve? This may result i= n backward compatibility issues when you have Root-only PEs that now have to= be aware of these additional VLAN tags (push them on Tx and pop them on Rx)= . Unfortunately the WG has decided to drop this approach - presumably, because= it mandated the use of CW in the Ethernet PW encapsulation which is not sup= ported by some implementations. So now we have a good chance to end with two different solutions (one for E-= VPN and one for regular VPLS), and, most probably, with some additional mech= anism for their interworking... But is probably spilled milk now. Regards. Sasha. ________________________________ From: Jiangyuanlong [jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 4:22 AM To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Sasha, >From Ali=92s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS la= bels per Ethernet segment are used for E-Tree. So one is used for root traff= ic and another is used for leaf traffic, just like in the 2PW approach. But it has the same problem as 2PW IMHO and OAM will be a challenge. Besides, manipulation of those labels and import/export of their associated= RT attributes may not be easy. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, September 23, 2012 4:25 PM To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in t= he E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (o= r more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must so= mehow identify the source AC of the Ethernet frame in this packet, and, in t= he case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s= ) while allowing forwarding to local Root AC(s). This equally applies to reg= ular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame is= a broadcast one (so that no learning is associated with it). And I strongly= doubt this can be achieved without some =93tags=94 in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vl= an- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me: > " Giles - are we agreed we want to get to one solution for VPLS an= d E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a couple= of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus to > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vl= an- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali state= d > that there was no benefit in the E-VPN case in using an additional tag (su= ch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree in= E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= - > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-e= vpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-= etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree= - > 2vlan-00 > > > > > > Abstract: > > This document discusses how the Dual-VLAN approach as described in > > [Etree-vlan] can be used to support the transport of E-Tree service > > in E-VPN. Thus a single convergent solution is possible for both VPLS > > and E-VPN. > > > > > > > > > > The IETF Secretariat > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020BA7FF25ILPTWPVEXMB03ec_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

Hi Yuanlong,

Please see some answers inline below= (bold magenta italics).=

 

Regards,

     Sasha

 

 

From: Jiangyuanlong [jiangyuanlong@huawei.co= m]
Sent: Monday, September 24, 2012 1:38 PM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

Hi Sasha,

 

Just snips of it:

[[[Sasha]]] You do not really have to negot= iate usage of the Leaf  flag in= the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standard= for changes in the preferred CW usage:-). And you would locally configure y= our VPLS instance to be an E-Tree on and hence setting the Leaf flag on Tx t= o peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent= to Root only) would never set this flag on Tx and ignore it on Rx =96 so yo= u would have complete backward compatibility at no cost.

[JY] Yes, you are right that only CW negoti= ation is needed. Though I am not sure if a PE has no capability of CW suppor= t, how can this approach be backward compatible?

[[Sasha]] If PE doe= s not support the CW, it can only act as a Root-only PE, and treated as scuh= by its peers. (I assume that a given PE either supports CW vs. any peer, or does not support CW at all, so there= should not be any contradiction.)

 

As for the new forwarding plane: IMHO you n= eed some modifications in the forwarding plane to mark Leaf-originated traff= ic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how you can avoid i= t taking into account that E-Tree forwarding behavior is different from a pl= ain old Layer 2 switch.

[JY] Consider the access may well be an Eth= ernet network, 2VLAN should be supported there or in the bridge module, thus= there is no need to introduce new forwarding paradigms in the VSI.

For the same reason, if CW solution is adop= ted, except the new modifications in VSI, 2VLAN may still be needed on the b= ridge module side.

[[Sasha]] I see it a bit differently: if your access is Ethernet, you need two ACs between your PE and its adjace= nt access device, one for Root and one for Leaf. No need to involve the brid= ge module of the PE into access behavior, especially if you want to run xSTP= in your access network IMO.

 

Regarding preservation of C-VLANs =96 would= you not need to push the Root/Leaf VLAN tag on top of the C-tag you are goi= ng to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to= be aware of these additional VLAN tags (push them on Tx and pop them on Rx)= .

[JY] That is not the case. You can have a l= ook at Section 5.3.2 of draft-ietf-l2vpn-vpls-pe-etree-00, it says raw PW sh= ould be used, thus no root or leaf VLAN tag is needed on the PW.

[[Sasha]] I am not sure I understand, will look up the draft and respond.

 

Thanks,

Yuanlong



 

From: Alexander Vainshtei= n [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, September 24, 2012 4:13 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

 

Yuanlong hi!

Lots of thanks for a prompt response.

Please see some responses in line below.

=  

Regards= ,

 &= nbsp;   Sasha

=  

From: Jiangyuanlong [mail= to:jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 9:44 AM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

 

Hi Sasha,

 

You are aiming 2 birds with a single stone;)

But please see my comments in line.

 

Thanks,

Yuanlong

 

From: Alexander Vainshtei= n [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, September 24, 2012 2:25 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

 

Yuanlong= .

Lots of= thanks for a prompt response and clarification.

 

I have a= lways considered the CW-based proposal for E-tree as the simplest (and, by i= mplication, the most clean) approach:

- No nee= d to distribute the types of ACs a given PE supports (and to re-distribute i= t when the set of ACs is changed). It is a purely local matter

- No OAM= issues

[JY] it seems neither issue is with 2VLAN, righ= t?

 

- No nee= d to allocate special VLAN tags to mark Leaf and Root- originated traffic an= d to propagate these allocations - hence no problem with preservation of&nbs= p; C-VLANs if/when it is needed (or VLAN manipulation) etc.

[JY] It may be commensurate with the negotiatio= n of E-Tree bit in the control word (if using CW), but save the work of rede= signing a new forwarding plane;) BTW, not sure what is the problem with preservation of C-VLAN, can you give= some more hints?

[[[Sasha]]] You do not really have to negot= iate usage of the Leaf  flag in= the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standard= for changes in the preferred CW usage:-). And you would locally configure y= our VPLS instance to be an E-Tree on and hence setting the Leaf flag on Tx t= o peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent= to Root only) would never set this flag on Tx and ignore it on Rx =96 so yo= u would have complete backward compatibility at no cost.

 

As for the new forwarding plane: IMHO you n= eed some modifications in the forwarding plane to mark Leaf-originated traff= ic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how you can avoid i= t taking into account that E-Tree forwarding behavior is different from a pl= ain old Layer 2 switch.

Regarding preservation of C-VLANs =96 would= you not need to push the Root/Leaf VLAN tag on top of the C-tag you are goi= ng to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to= be aware of these additional VLAN tags (push them on Tx and pop them on Rx)= .

 

 

Unfortun= ately the WG has decided to drop this approach - presumably, becau= se it mandated the use of CW in the Ethernet PW encapsulation which is not s= upported by some implementations.

 

So now w= e have a good chance to end with two different solutions (one= for E-VPN and one for regular VPLS), and, most probably, with some addition= al mechanism for their interworking...

 

But is&n= bsp;probably spilled milk now.

 

Regards.=

Sasha.

    

From: Jiangyuanlong [jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

Sasha,=

&n= bsp;

From Ali=92s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two= ESI MPLS labels per Ethernet segment are used for E-Tree. So one is used fo= r root traffic and another is used for leaf traffic, just like in the 2PW approach.

But it has the same problem as 2PW IMHO and OAM will be a challe= nge.

Besides, manipulation of those labels and import/export of their= associated RT attributes may not be easy.

&n= bsp;

Thanks,

Yuanlong

&n= bsp;

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

&n= bsp;

Yuanlo= ng, Giles, Himanshu, Ali and all,

I have= probably missed something important (not being present at the latest IETF m= eeting).

But I= think something is wrong with the statement "there was no benefit i= n the E-VPN case in using an additional tag (such as a VLAN)".

 

IMHO a= nd FWIW the real E-Tree problem is the situation when there are two (or more= ) PEs with both Root and Leaf ACs.

When o= ne of such PEs receives a VPLS packet from another such PE, it must somehow= identify the source AC of the Ethernet frame in this packet, and, in the ca= se of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root= AC(s). This equally applies to regular VPLS and E-VPN, e.g., in the case wh= en the contained Ethernet frame is a broadcast one (so that no learning is a= ssociated with it). And I strongly doubt this can be achieved without some =93tags=94 in the encapsulation.

 

My 2c,=

 =     Sasha

 

> -= ----Original Message-----

> F= rom: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf=

> O= f Jiangyuanlong

> S= ent: Saturday, September 22, 2012 5:32 AM

> T= o: Giles Heron

> C= c: l2vpn@ietf.org

> S= ubject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-=

> 0= 0.txt

> <= /span>

> H= i Giles,

> <= /span>

> P= erhaps the gauge of the consensus in the minutes was not so clear for me:

> &= quot;         Giles - are we agreed= we want to get to one solution for VPLS and E-

> V= PN.

> &= nbsp;         Not many people.&= nbsp; But even fewer who want multiple.  Checked to see

> i= f

> &= nbsp;         people want one s= olution only for E-VPN and VPLS - only a couple of

> h= ands."

> N= evertheless, E-VPN needs an E-Tree solution and it is the WG consensus to

> d= ecide which way to take.

> <= /span>

> T= hanks,

> Y= uanlong

> <= /span>

> -= ----Original Message-----

> F= rom: Giles Heron [mailto:giles.heron@gmail.com]

> S= ent: Friday, September 21, 2012 9:09 PM

> T= o: Jiangyuanlong

> C= c: l2vpn@ietf.org

> S= ubject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-=

> 0= 0.txt

> <= /span>

> T= hanks Yuanlong,

> <= /span>

> h= owever I must say that your memory of the IETF 84 L2VPN meeting differs

> f= rom mine (and from what is noted in the minutes).  Whilst Himanshu said=

> t= hat it was better to have the same solution for VPLS and E-VPN, Ali stated

> t= hat there was no benefit in the E-VPN case in using an additional tag (such= as

> a= VLAN).  No consensus was reached in the meeting.

> <= /span>

> G= iles

> <= /span>

> O= n 21 Sep 2012, at 10:16, Jiangyuanlong <jiangyuanlong@huawei.com>

> w= rote:

> <= /span>

> &= gt; Hi all,

> &= gt;

> &= gt; During the 84th IETF meeting, the group discussed the issue of E-Tree in= E-

> V= PN, and it was shown that a single solution was more preferred than two

> d= ifferent approaches for VPLS and E-VPN.

> &= gt; This I-D probes how the 2VLAN approach can be used to support E-Tree in<= /span>

> E= -VPN and it seems not a big issue.

> &= gt; Any comments from you are greatly appreciated.

> &= gt;

> &= gt; Best regards,

> &= gt; Yuanlong

> &= gt;

> &= gt; -----Original Message-----

> &= gt; From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]<= /p>

> &= gt; Sent: Friday, September 21, 2012 4:55 PM

> &= gt; To: Jiangyuanlong

> &= gt; Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -

> 0= 0.txt

> &= gt;

> &= gt;

> &= gt; A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

> &= gt; has been successfully submitted by Yuanlong Jiang and posted to the

> &= gt; IETF repository.

> &= gt;

> &= gt; Filename:     draft-jiang-l2vpn-evpn-etree-2vlan

> &= gt; Revision:      00

> &= gt; Title:           =             &nbs= p;       E-Tree Support with 2VLAN in E-VPN

> &= gt; Creation date:         &nbs= p;  2012-09-21

> &= gt; WG ID:           =             &nbs= p;   Individual Submission

> &= gt; Number of pages: 6

> &= gt; URL:           &n= bsp; http://www.ietf.org/internet-drafts= /draft-jiang-l2vpn-evpn-

> etree-2vlan= -00.txt

> &= gt; Status:          http://datatracker.ietf.org/doc/draft-jiang-l2= vpn-evpn-etree-

> 2vlan

> &= gt; Htmlized:        http://tools.ietf.org/html/draft-jiang-l2vpn-evp= n-etree-

> 2vlan-00

> &= gt;

> &= gt;

> &= gt; Abstract:

> &= gt;   This document discusses how the Dual-VLAN approach as descri= bed in

> &= gt;   [Etree-vlan] can be used to support the transport of E-Tree= service

> &= gt;   in E-VPN. Thus a single convergent solution is possible for= both VPLS

> &= gt;   and E-VPN.

> &= gt;

> &= gt;

> &= gt;

> &= gt;

> &= gt; The IETF Secretariat

> &= gt;

 

This e-mail message is intend= ed for the recipient only and contains information which is CONFIDENTIAL and= which may be proprietary to ECI Telecom. If you have received this transmis= sion in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.=

This e-mail message is intended for the recipient on= ly and contains information which is CONFIDENTIAL and which may be proprieta= ry to ECI Telecom. If you have received this transmission in error, please i= nform us by e-mail, phone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient on= ly and contains information which is CONFIDENTIAL and which may be proprieta= ry to ECI Telecom. If you have received this transmission in error, please i= nform us by e-mail, phone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020BA7FF25ILPTWPVEXMB03ec_-- From jiangyuanlong@huawei.com Mon Sep 24 05:36: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 222CE21F8610 for ; Mon, 24 Sep 2012 05:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYmGZsVc3Tjd for ; Mon, 24 Sep 2012 05:36:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C919521F8605 for ; Mon, 24 Sep 2012 05:36:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKZ45088; Mon, 24 Sep 2012 12:36:47 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 13:36:02 +0100 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 13:36:46 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 20:36:42 +0800 From: Jiangyuanlong To: Alexander Vainshtein , Giles Heron , Ali Sajassi Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: Ac2aLGAdAR1X+eyYskOHru3ESKxPQQAF4Pbg//+MdwD//3eTcA== Date: Mon, 24 Sep 2012 12:36:41 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF48@szxeml546-mbs.china.huawei.com> References: , <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11@szxeml546-mbs.china.huawei.com> 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.95] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF48szxeml546mbschi_" 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: Mon, 24 Sep 2012 12:36:51 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF48szxeml546mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, Just snips of it: As for the new forwarding plane: IMHO you need some modifications in the fo= rwarding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-L= eaf traffic regardless of how you identify it. I do not see how you can avo= id it taking into account that E-Tree forwarding behavior is different from= a plain old Layer 2 switch. [JY] Consider the access may well be an Ethernet network, 2VLAN should be s= upported there or in the bridge module, thus there is no need to introduce = new forwarding paradigms in the VSI. For the same reason, if CW solution is adopted, except the new modification= s in VSI, 2VLAN may still be needed on the bridge module side. [[Sasha]] I see it a bit differently: if your access is Ethernet, you need = two ACs between your PE and its adjacent access device, one for Root and on= e for Leaf. No need to involve the bridge module of the PE into access beha= vior, especially if you want to run xSTP in your access network IMO. [JY] The group have discussed quite a lot in the last few months around the= scenarios of E-Tree and I don't think it is that simple (except in a pure = MPLS network of course). BTW, Appendix of draft-ietf-l2vpn-vpls-pe-etree-00= have a brief discussion on the support of them. Just as an example, how ca= n H-VPLS with QinQ spoke be supported? How can E-NNI be supported? Regarding preservation of C-VLANs - would you not need to push the Root/Lea= f VLAN tag on top of the C-tag you are going to preserve? This may result i= n backward compatibility issues when you have Root-only PEs that now have t= o be aware of these additional VLAN tags (push them on Tx and pop them on R= x). [JY] That is not the case. You can have a look at Section 5.3.2 of draft-ie= tf-l2vpn-vpls-pe-etree-00, it says raw PW should be used, thus no root or l= eaf VLAN tag is needed on the PW. [[Sasha]] I am not sure I understand, will look up the draft and respond. Thanks, Yuanlong --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF48szxeml546mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,=

 

Just snips of it:=

 =

As for the new forwardin= g plane: IMHO you need some modifications in the forwarding plane to mark L= eaf-originated traffic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how you can avoid it takin= g into account that E-Tree forwarding behavior is different from a plain ol= d Layer 2 switch.

[JY] Consider the access= may well be an Ethernet network, 2VLAN should be supported there or in the= bridge module, thus there is no need to introduce new forwarding paradigms in the VSI.

For the same reason, if = CW solution is adopted, except the new modifications in VSI, 2VLAN may stil= l be needed on the bridge module side.

[[Sasha]] I see it a bit= differently: if your access is Ethernet, you need two ACs between your PE = and its adjacent access device, one for Root and one for Leaf. No need to involve the bridge module of the PE into access behavior,= especially if you want to run xSTP in your access network IMO.<= /b>=

[JY] The group have discussed quite a lot in th= e last few months around the scenarios of E-Tree and I don’t think it= is that simple (except in a pure MPLS network of course). BTW, Appendix of draft-ietf-l2vpn-vpls-pe-etree-00 have a brief discussion on t= he support of them. Just as an example, how can H-VPLS with QinQ spoke be s= upported? How can E-NNI be supported?

 

Regarding preservation o= f C-VLANs – would you not need to push the Root/Leaf VLAN tag on top = of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to be aware= of these additional VLAN tags (push them on Tx and pop them on Rx).=

[JY] That is not the cas= e. You can have a look at Section 5.3.2 of draft-ietf-l2vpn-vpls-pe-etree-0= 0, it says raw PW should be used, thus no root or leaf VLAN tag is needed on the PW.

[[Sasha]] I am not sure = I understand, will look up the draft and respond.

 

Thanks,

Yuanlong<= span lang=3D"EN-US" style=3D"color:black">

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF48szxeml546mbschi_-- From Alexander.Vainshtein@ecitele.com Mon Sep 24 07:21: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 2624021F878E for ; Mon, 24 Sep 2012 07:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HasFA8SgEusV for ; Mon, 24 Sep 2012 07:21:38 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id E434D21F86A8 for ; Mon, 24 Sep 2012 07:21:37 -0700 (PDT) Received: from [85.158.143.99:52035] by server-2.bemta-4.messagelabs.com id DC/90-06610-07C60605; Mon, 24 Sep 2012 14:21:36 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1348496490!31552088!11 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 17268 invoked from network); 24 Sep 2012 14:21:35 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-15.tower-216.messagelabs.com with SMTP; 24 Sep 2012 14:21:35 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-fc-5060671dbdff Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id AC.4A.06426.D1760605; Mon, 24 Sep 2012 15:58:53 +0200 (IST) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 24 Sep 2012 16:16:50 +0200 Received: from ILPTWPVEXMB03.ecitele.com ([fe80::91b4:8f74:ce44:f190]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.01.0379.000; Mon, 24 Sep 2012 16:09:59 +0200 From: Alexander Vainshtein To: Jiangyuanlong Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: Ac2aLGAdRS8tXuhBSbG0BUc+K0zeAwADABOAAATzWPX//+icgP//xuCA Date: Mon, 24 Sep 2012 14:09:58 +0000 Message-ID: References: , <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF11@szxeml546-mbs.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF48@szxeml546-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DF48@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020BA7FF9EILPTWPVEXMB03ec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLsWRmVeSWpSXmKPExsUy+dWnL7qH0xMCDNbPNLR4enQGo8XVD+1s Fo+/HWK3eHe2mcWBxWPK742sHjtn3WX3aDnyltVjyZKfTAEsUQ2MNol5efkliSWpCimpxcm2 SgFFmWWJyZVKCpkptkqGSgoFOYnJqbmpeSW2SokFBal5KUp2XDZAwcw8hdS85PyUzLx0WyXP YH9dCwtTS11DJTs1ZUNja66QjMxihVTd3MTMHIXc1OLixPRUBaAIyNV5KakpCmn5RQolGakK RQmTmTP2P37GVLCwj7Hi55ej7A2Ma2u6GDk5JARMJFYdvMMEYYtJXLi3ng3EFhLYzyjRO0G7 i5ELyN7BKPF070UWCOcoo8Sjo71gHWwCthKbVt8F6xAR0JH4uucSM4jNLJArMX3re1YQW1gg VOLuyr/sEDVhEh9OPWSGsN0kNl7tAKthEVCVWPzpOpjNKxAgsaj7LyPEsrVMEgsmzQVr4ARq Xr9tNlgRI9Cp30+tYYJYJi5x68l8qBcEJJbsOc8MYYtKvHz8jxXClpNoWnmFHaI+X2Lp/y2M EMsEJU7OfMIC8bKuxKkTXVBzJCUOrrjBMoFRYhaSFbOQtM9C0g4R15FYsPsTG4StLbFs4Wtm GPvMgcdMyOILGNlXMYpm5hSUJOWmGxjqpSZnlqTmpOol5+duYoQktec7GH/NVznEKMDBqMTD +2JTfIAQa2JZcWXuIUZJDiYlUd7cjIQAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8RxOBcrwp iZVVqUX5MClXYDBPZJbiTs4HJY+SeGMDA9wcJXHe5Q3h/kIC6cBEm52aWpBaBDNHhoNDSYK3 PhtohWBRanpqRVpmTglCmomDE+QMHqAz6kBqeIsLEnOLM9Mh8qcYdTke3V3ygFGIJS8/L1VK nDcXpEgApCijNA9uDijD1f////8VozgwAIR5y0GqeIAJG27SK6AlTEBL+PfEgSwBZi64lFQD 47XT3U/WXH+pYO15zq/1tgdzN1d+2BmpH92csn/WRi5z1jDZtt1O5vy2fX8M4l/8CQ9gt1xZ lz33tRqLVttlhp9aWiGCHh/myBhvD84WVTpx6vMR1y8bvztfsXm90ynA0S/JY0JAVMHRpb3v 1PzOf+NVO/n5Bddiscigy97HZ2kUyjMo7o2arMRSnJFoqMVcVJwIAPDlTtBLBAAA Cc: "l2vpn@ietf.org" , Ali Sajassi 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, 24 Sep 2012 14:21:41 -0000 --_000_F9336571731ADE42A5397FC831CEAA020BA7FF9EILPTWPVEXMB03ec_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Yuanlong, Lots of thanks for a prompt response. I did not perform complete analysis of all the interworking MPLS vs. Etherne= t network) cases for E-Tree. My gut feeling is that it can be always reduced to the trivial case of two A= Cs between a VPLS PE and its adjacent Ethernet network PE (which is a CE fro= m the VPLS point of view), these ACs being represented either as two VLANs o= n the same port or by two C-VLANs in the QinQ case (with the same S-VLAN). I= am aware3 of some VPLS implementations that can treat any given pair of VLA= N tags (for QinQ) as a separate AC, not sure how common this functionality i= s. The Ethernet side may be more problematic. E.g., it is not quite clear to= me what are the expectations of the Ethernet edge device in your example of= QinQ for H-VPLS in order to support E-Tree; nor am I sure that IEEE has a= ready answer for that. Do I miss something? Regards, Sasha From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 2:37 PM To: Alexander Vainshtein; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Hi Sasha, Just snips of it: As for the new forwarding plane: IMHO you need some modifications in the for= warding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-Lea= f traffic regardless of how you identify it. I do not see how you can avoid= it taking into account that E-Tree forwarding behavior is different from a= plain old Layer 2 switch. [JY] Consider the access may well be an Ethernet network, 2VLAN should be su= pported there or in the bridge module, thus there is no need to introduce ne= w forwarding paradigms in the VSI. For the same reason, if CW solution is adopted, except the new modifications= in VSI, 2VLAN may still be needed on the bridge module side. [[Sasha]] I see it a bit differently: if your access is Ethernet, you need t= wo ACs between your PE and its adjacent access device, one for Root and one= for Leaf. No need to involve the bridge module of the PE into access behavi= or, especially if you want to run xSTP in your access network IMO. [JY] The group have discussed quite a lot in the last few months around the= scenarios of E-Tree and I don't think it is that simple (except in a pure M= PLS network of course). BTW, Appendix of draft-ietf-l2vpn-vpls-pe-etree-00 h= ave a brief discussion on the support of them. Just as an example, how can H= -VPLS with QinQ spoke be supported? How can E-NNI be supported? Regarding preservation of C-VLANs - would you not need to push the Root/Leaf= VLAN tag on top of the C-tag you are going to preserve? This may result in= backward compatibility issues when you have Root-only PEs that now have to= be aware of these additional VLAN tags (push them on Tx and pop them on Rx)= . [JY] That is not the case. You can have a look at Section 5.3.2 of draft-iet= f-l2vpn-vpls-pe-etree-00, it says raw PW should be used, thus no root or lea= f VLAN tag is needed on the PW. [[Sasha]] I am not sure I understand, will look up the draft and respond. Thanks, Yuanlong This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020BA7FF9EILPTWPVEXMB03ec_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Yuanlong,=

Lots of thanks= for a prompt response.

 

I did not perf= orm complete analysis of all the interworking MPLS vs. Ethernet network) cas= es for E-Tree.

My gut feeling= is that it can be always reduced to the trivial case of two ACs between a V= PLS PE and its adjacent Ethernet network PE (which is a CE from the VPLS point of view), these ACs being represented either as= two VLANs on the same port or by two C-VLANs in the QinQ case (with the sam= e S-VLAN). I am aware3 of some VPLS implementations that can treat any given= pair of VLAN tags (for QinQ) as a separate AC, not sure how common this functionality is. The Ethernet s= ide may be more problematic. E.g., it is not quite clear to me what are the= expectations of the Ethernet edge device in your example of QinQ  for= H-VPLS in order to support E-Tree; nor am I sure that IEEE has a ready answer for that.<= /b>

 

Do I miss some= thing?

 

Regards,

    = ; Sasha

 

From: Jiangyuanlo= ng [mailto:jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 2:37 PM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etre= e-2vlan-00.txt

 

Hi Sasha,=

 <= /span>

Just snips of= it:

 

As for the new= forwarding plane: IMHO you need some modifications in the forwarding plane= to mark Leaf-originated traffic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how yo= u can avoid it taking into account that E-Tree forwarding behavior is differ= ent from a plain old Layer 2 switch. <= /o:p>

[JY] Consider= the access may well be an Ethernet network, 2VLAN should be supported there= or in the bridge module, thus there is no need to introduce new forwarding paradigms in the VSI.

For the same r= eason, if CW solution is adopted, except the new modifications in VSI, 2VLAN= may still be needed on the bridge module side.

[[Sasha]] I se= e it a bit differently: if your access is Ethernet, you need two ACs between= your PE and its adjacent access device, one for Root and one for Leaf. No need to involve the bridge module of the PE into acces= s behavior, especially if you want to run xSTP in your access network IMO.<= /o:p>

[JY] The group have discussed quite a= lot in the last few months around the scenarios of E-Tree and I don’t= think it is that simple (except in a pure MPLS network of course). BTW, Appendix of draft-ietf-l2vpn-vpls-pe-etree-00 have a brief di= scussion on the support of them. Just as an example, how can H-VPLS with Qin= Q spoke be supported? How can E-NNI be supported?

 <= /span>

Regarding pres= ervation of C-VLANs – would you not need to push the Root/Leaf VLAN ta= g on top of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that no= w have to be aware of these additional VLAN tags (push them on Tx and pop th= em on Rx).

[JY] That is n= ot the case. You can have a look at Section 5.3.2 of draft-ietf-l2vpn-vpls-p= e-etree-00, it says raw PW should be used, thus no root or leaf VLAN tag is needed on the PW.

[[Sasha]] I am= not sure I understand, will look up the draft and respond.

 <= /span>

Thanks,=

Yuanlong<= /span>

 =

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020BA7FF9EILPTWPVEXMB03ec_-- From ju1738@att.com Mon Sep 24 07:32: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 6619421F87A9 for ; Mon, 24 Sep 2012 07:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrPsktmS43dw for ; Mon, 24 Sep 2012 07:32:51 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 229A221F8787 for ; Mon, 24 Sep 2012 07:32:51 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 31f60605.2aaadd421940.260449.00-562.716320.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 24 Sep 2012 14:32:51 +0000 (UTC) X-MXL-Hash: 50606f136dbc4849-b82706e7c86553cd9882404db95908469b8374c8 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id efe60605.0.260138.00-334.715393.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 24 Sep 2012 14:32:31 +0000 (UTC) X-MXL-Hash: 50606eff4a9ae5ad-1c88c4b7ee8c882339081445ad3575408779f0d9 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8OEWTwq017324; Mon, 24 Sep 2012 10:32:30 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8OEWM7N017264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2012 10:32:24 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 24 Sep 2012 10:32:08 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0318.001; Mon, 24 Sep 2012 10:32:08 -0400 From: "UTTARO, JAMES" To: "'Aldrin Isaac'" , Jiangyuanlong Subject: RE: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmY5PXxacLEvPy023O8araW2PqZeYxY1AgABkUYCAAGW8IA== Date: Mon, 24 Sep 2012 14:32:07 +0000 Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DAC7@szxeml546-mbs.china.huawei.com> <99FEF6BC-2F96-4F85-BF74-B1CCC84F5762@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DE31@szxeml546-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB8A6A2MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=g8Qva45Ca7EA:10 a=J2Vbl3tn3xcA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=ZGL3M7cMNNvo5dJb82IA:9 a=C] X-AnalysisOut: [juIK1q_8ugA:10 a=lZB815dzVvQA:10 a=MSl-tDqOz04A:10 a=VoFdV] X-AnalysisOut: [tO4Zh8pUFhG:21 a=z6OVhWwbMu7veibq:21 a=yMhMjlubAAAA:8 a=SS] X-AnalysisOut: [mOFEACAAAA:8 a=OE8dijOsa_V_ASBdUsAA:9 a=gKO2Hq4RSVkA:10 a=] X-AnalysisOut: [UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsn] X-AnalysisOut: [liwV7b4A:10 a=UBzO5rIaD1cl0UIF:21 a=jYhiiormMYBrbmZx:21] Cc: "l2vpn@ietf.org" , Ali Sajassi , Himanshu Shah 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, 24 Sep 2012 14:32:54 -0000 --_000_B17A6910EEDD1F45980687268941550FB8A6A2MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= ldrin Isaac Sent: Monday, September 24, 2012 12:28 AM To: Jiangyuanlong Cc: l2vpn@ietf.org; Ali Sajassi; Himanshu Shah Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-= 2vlan-00.txt Hi Yuanlong, I'm not clear as to why different forwarding contexts for root and leaf is = less than good -- can you elaborate? Also I'm not clear as to why you see = that ETREE using EVPN is any different from other topologies that can be cr= eated with EVPN. EVPN's ability to create any topology is fundamental to i= t. In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in d= ifferent VRF. In some cases we even overlap one or more hub-and-spoke RT pa= irs with one or more mesh RT. EVPN was purposefully designed to bring this= flexibility to Ethernet. Best regards -- aldrin On Sunday, September 23, 2012, Jiangyuanlong wrote: Hi Aldrin, I agree with you that using different labels for root/leaf AC can work, but= not sure using 2 forwarding contexts (EVI) is a good thing - that means fo= rwarding plane for E-Tree will be very different from other services in E-V= PN. Regards, Yuanlong From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] Sent: Sunday, September 23, 2012 9:21 PM To: Alexander Vainshtein Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ietf.org<= javascript:_e(%7b%7d,%20'cvml',%20'l2vpn@ietf.org');> Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-= 2vlan-00.txt With EVPN, leaf AC should have different context and associated label from = root AC. A leaf AC forwarding context (say EVI) on an ingress PE would not= import the RT for other leaf AC and hence not have forwarding vectors to a= ny leaf AC. The packet would have nowhere to go and hence be dropped on in= gress. In the case of BUM ingress replication, the leaf AC forwarding cont= ext on the ingress PE would not have imported the Inclusive Tag route of eg= ress leaf AC and hence have no vectors to local replication context IDs of = other leaf AC . In the case of BUM tree, the leaf EVI would not have impor= ted the Inclusive Tag route of other leaf EVI and hence not form a tree to = other leaf EVI. On Sunday, September 23, 2012, Alexander Vainshtein wrote: Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in = the E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (= or more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must s= omehow identify the source AC of the Ethernet frame in this packet, and, in= the case of it being a leaf AC, prevent its forwarding to the local Leaf A= C(s) while allowing forwarding to local Root AC(s). This equally applies to= regular VPLS and E-VPN, e.g., in the case when the contained Ethernet fram= e is a broadcast one (so that no learning is associated with it). And I str= ongly doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn= -bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me= : > " Giles - are we agreed we want to get to one solution for VPLS a= nd E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a coupl= e of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus t= o > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org --_000_B17A6910EEDD1F45980687268941550FB8A6A2MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Aldrin Isaac
Sent: Monday, September 24, 2012 12:28 AM
To: Jiangyuanlong
Cc: l2vpn@ietf.org; Ali Sajassi; Himanshu Shah
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn= -etree-2vlan-00.txt

 

Hi Yuanlong, 

 

I'm not clear as to why different forwarding context= s for root and leaf is less than good -- can you elaborate?  Also I'm = not clear as to why you see that ETREE using EVPN is any different from oth= er topologies that can be created with EVPN.  EVPN's ability to create any topology is fundamental to it. &n= bsp;In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in d= ifferent VRF. In some cases we even overlap one or more hub-and-spoke RT pa= irs with one or more mesh RT.  EVPN was purposefully designed to bring this flexibility to Ethernet. 

Best regards -- aldrin

 


On Sunday, September 23, 2012, Jiangyuanlong wrote:

Hi Aldrin,

 

I agree with you that using different l= abels for root/leaf AC can work, but not sure using 2 forwarding contexts (EVI) is a good thing – that means forwarding plane for E-T= ree will be very different from other services in E-VPN.

 

Regards,

Yuanlong

 

From: Aldrin Isaac [mailto:<= a href=3D"javascript:_e(%7b%7d,%20'cvml',%20'aldrin.isaac@gmail.com');" tar= get=3D"_blank">aldrin.isaac@gmail.com]
Sent: Sunday, September 23, 2012 9:21 PM
To: Alexander Vainshtein
Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ietf.org
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn= -etree-2vlan-00.txt

 

With EVPN, leaf AC should have different context and associated label fr= om root AC.  A leaf AC forwarding context (say EVI) on an ingress PE w= ould not import the RT for other leaf AC and hence not have forwarding vect= ors to any leaf AC.  The packet would have nowhere to go and hence be dropped on ingress.  In the case of B= UM ingress replication, the leaf AC forwarding context on the ingress PE wo= uld not have imported the Inclusive Tag route of egress leaf AC and hence h= ave no vectors to local replication context IDs of other leaf AC .  In the case of BUM tree, the leaf EVI would n= ot have imported the Inclusive Tag route of other leaf EVI and hence not fo= rm a tree to other leaf EVI. 

 



On Sunday, September 23, 2012, Alexander Vainshtein wrote:

Yuanlong, Giles, Himanshu, Ali and all,

I have probably missed something important (not being present at the lat= est IETF meeting).

But I think something is wrong with the statement "there was no = benefit in the E-VPN case in using an additional tag (such as a VLAN)"= .

 

IMHO and FWIW the real E-Tree problem is the situation when there are tw= o (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from another such PE, it mus= t somehow identify the source AC of the Ethernet frame in this packet, and,= in the case of it being a leaf AC, prevent its forwarding to the local Lea= f AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular VPLS and E-VPN, e.g.,= in the case when the contained Ethernet frame is a broadcast one (so that = no learning is associated with it). And I strongly doubt this can be achiev= ed without some “tags” in the encapsulation= .

 

My 2c,

     Sasha

 

> -----Original Message-----

> From: l2vpn-bounces@ietf.= org [mailto:l2vpn-bounces@iet= f.org] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org=

> Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-et= ree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minutes was not so clear = for me:

> "         Giles - are = we agreed we want to get to one solution for VPLS and E-

> VPN.

>           Not man= y people.  But even fewer who want multiple.  Checked to see=

> if

>           people = want one solution only for E-VPN and VPLS - only a couple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution and it is the WG conse= nsus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:= giles.heron@gmail.com]

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org=

--_000_B17A6910EEDD1F45980687268941550FB8A6A2MISOUT7MSGUSR9IIT_-- From sajassi@cisco.com Mon Sep 24 16:41: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 0478D1F0C51 for ; Mon, 24 Sep 2012 16:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em4kJlw6NLn5 for ; Mon, 24 Sep 2012 16:41:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D00321F041D for ; Mon, 24 Sep 2012 16:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7373; q=dns/txt; s=iport; t=1348530100; x=1349739700; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bmEpXrenu5+QfX5iF17DkixhfdPsYlqCWRVQEArMKSs=; b=P3JRW5Qpl34kS0vBbF1DE0xf7hM9yMxrFx9Zna/e9KNIyuTqsHu39xVx pvOoZOJ2zMZ81yw6h7cc2A2NNgCqCIwK0h4wnD7ePeE1dnZDmO/rRaU6t cZpvDYyCIxyDOu8yWT66dAOli87zXOz6RIcg5XjldYU3srNhoKVjcblv9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFbuYFCtJXHB/2dsb2JhbABFgm67dYEIgiABAQEEEgEnMwUFAgwGAQgRBAEBAR4JKBEUCQgCBAENBQkSB4dRAw8BCphYlkoNiVOKOWIUBoNPglkDlBCBVYEVigSDIYFpgloNgVoJNA X-IronPort-AV: E=Sophos;i="4.80,478,1344211200"; d="scan'208";a="124854941" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 24 Sep 2012 23:41:40 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8ONfeCo000459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Sep 2012 23:41:40 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 24 Sep 2012 18:41:39 -0500 From: "Ali Sajassi (sajassi)" To: "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmq4kKmxshSf6b0C29EixUyPjyg== Date: Mon, 24 Sep 2012 23:41:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.64.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19206.004 x-tm-as-result: No--65.292700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <2B9B3B657FEEDD4C89165CDC63635535@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Jiangyuanlong 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, 24 Sep 2012 23:41:42 -0000 Jim, Aldrin, Josh: You guys are spot on. E-VPN solution doesn't have the limitation of data-plane forwarding that VPLS has and as such it doesn't need addition vlan-tag to solve root/leaf indication issue as it can be supported inherently by the solution. Cheers, Ali On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: >Josh, > > Yes.. I think that is the reality of it.. VPLS either the LDP or BGP >variety uses data plane learning as the mechanism to "learn".. The fact >that we extend the L2 footprint via these "tunnels" does not change that >fact.. SO in VPLS the only hammer you have is the data plane, so one must >manipulate bits on the wire to infer topology ( Limited set of topology >).. > >Another challenge is when roots and leafs "land" on the same PE. > >EVPN is intended to use contexts and associated import/export to manage >the topology.. So here there is a set of tools to create the desired >topologies, along with that there other mechanisms realized i.e >active/active... > >Jim Uttaro > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Saturday, September 22, 2012 7:03 PM >To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >I agree. > >Would it be safe to state that VPLS has a need for a 'etree solution', but >EVPN does not, because it is inherently supported? > >The previously discussed effort of having a 'single etree solution' for >both VPLS and EVPN may not really be valid due to this. > >In fact, I do not think it is valid to ask for a single solution, EVPN >doesn't have a problem that needs to be fixed here, I don't believe it >factors into this discussion. > >-Josh > > >On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: > >>EVPN is intended to maximize the flexibility of multiple routing contexts >>with arbitrary topologies.. As I have stated in the past, EVPN allows for >>E-Tree to be constructed in the control plane, other solutions require >>some method to interrogate data and infer topology. IMO this is not >>desirable. >> >>Jim Uttaro >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Rogers, Josh >>Sent: Saturday, September 22, 2012 12:49 PM >>To: Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >>So, this same sort of 'import/export' of targets is possible using >>BGP-VPLS today, but it faces limitations outlined in >>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 >>may import RTA, while AC2 on PE2 may import RTB? >> >>Its occurred to me that EVPN would be able to use other mechanisms that >>have not yet been discussed yet due to sharing a mac table over BGP. >> >>Thanks for the response, >>Josh >> >> >>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >> >>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB >>>export RTA at spokes) with filtering to enforce downstream data flow if >>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>> >>> >>> >>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>> >>>> Thanks Yuanlong, >>>> >>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>differs from mine (and from what is noted in the minutes). Whilst >>>>Himanshu said that it was better to have the same solution for VPLS and >>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>meeting. >>>> >>>> Giles >>>> >>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>wrote: >>>> >>>>> Hi all, >>>>> >>>>> During the 84th IETF meeting, the group discussed the issue of E-Tree >>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>than two different approaches for VPLS and E-VPN. >>>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>>in E-VPN and it seems not a big issue. >>>>> Any comments from you are greatly appreciated. >>>>> >>>>> Best regards, >>>>> Yuanlong >>>>> >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>> To: Jiangyuanlong >>>>> Subject: New Version Notification for >>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>> >>>>> >>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>> IETF repository. >>>>> >>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>> Revision: 00 >>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>> Creation date: 2012-09-21 >>>>> WG ID: Individual Submission >>>>> Number of pages: 6 >>>>> URL: >>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>- >>>>>0 >>>>>0.txt >>>>> Status: >>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>> Htmlized: >>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>> >>>>> >>>>> Abstract: >>>>> This document discusses how the Dual-VLAN approach as described in >>>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>VPLS >>>>> and E-VPN. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use 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 dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use 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 dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. From sajassi@cisco.com Mon Sep 24 16:41:44 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 36E311F0C9E for ; Mon, 24 Sep 2012 16:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruJmgMVWeO5G for ; Mon, 24 Sep 2012 16:41:42 -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 A4FCF1F042B for ; Mon, 24 Sep 2012 16:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53859; q=dns/txt; s=iport; t=1348530101; x=1349739701; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=7mv2uL4HzmwdV7aUVak7K6E4bJz+sDpAOiSWadkHcxM=; b=j59KqSyk1sbcwlgVyzA19+e1g0eLnH9b1cC/6ydFmY/Nk4sq3ca+P74l 1vvjq75BkG0qJqnvtfCz+/s0Nevqw+tSCwvey4g15LzRW+HX67al40YEZ jmQOyHI2d9vLjfNEUC1ub/KIC0qckXOvxJlQWFoUK9E8RpyDOAT6BpDk4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAMDuYFCtJV2d/2dsb2JhbAA7CoJLI6odiGcBiHCBCIIgAQEBAwESAQcTQAoCBQcGAQgRAwEBARYLAQYoERQJCAIEAQ0FCRIHh1EDCQYBCphclkoNiVOKOWIQCoJ8U4JZA5QQgVWBFYoEgyGBaYJaDYFjNA X-IronPort-AV: E=Sophos;i="4.80,478,1344211200"; d="scan'208,217";a="124888912" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 24 Sep 2012 23:41:41 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8ONfehW010327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Sep 2012 23:41:40 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Mon, 24 Sep 2012 18:41:40 -0500 From: "Ali Sajassi (sajassi)" To: Alexander Vainshtein , Jiangyuanlong , Giles Heron Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmq4l6o7ZhqLsEEWL4TSrLq7YNA== Date: Mon, 24 Sep 2012 23:41:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.64.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19206.004 x-tm-as-result: No--43.617300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC8600D81A73Asajassiciscocom_" 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: Mon, 24 Sep 2012 23:41:44 -0000 --_000_CC8600D81A73Asajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sasha, As the co-author of vlan-tag solution for VPLS, I must admit that I sympath= ize with your concern regarding vlan-tag solution; however, among the three= proposals (vlan-tags, control word, and PWs), IMO, vlan-tag is less of an = evil (although it is subjective :-). As you mention, we need to modify data= -forwarding behavior regardless of which of these three models we go with a= nd all three models break the model described in bridge-interop RFC. With E-VPN, the ETREE service can inherently be supported with the existing= forwarding model without introducing any new mechanism !! And that's why i= t doesn't make sense to add any other mechanism on top of E-VPN. As the co-author of vlan-tag solution for VPLS, I think this drat needs cle= aning and we will do that in subsequent revisions. Cheers, Ali From: Alexander Vainshtein > Date: Monday, September 24, 2012 1:12 AM To: Jiangyuanlong >, Giles Heron >, Cisc= o Employee > Cc: "l2vpn@ietf.org" > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong hi! Lots of thanks for a prompt response. Please see some responses in line below. Regards, Sasha From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 9:44 AM To: Alexander Vainshtein; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Hi Sasha, You are aiming 2 birds with a single stone;) But please see my comments in line. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, September 24, 2012 2:25 PM To: Jiangyuanlong; Giles Heron; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong. Lots of thanks for a prompt response and clarification. I have always considered the CW-based proposal for E-tree as the simplest (= and, by implication, the most clean) approach: - No need to distribute the types of ACs a given PE supports (and to re-dis= tribute it when the set of ACs is changed). It is a purely local matter - No OAM issues [JY] it seems neither issue is with 2VLAN, right? - No need to allocate special VLAN tags to mark Leaf and Root- originated t= raffic and to propagate these allocations - hence no problem with preservat= ion of C-VLANs if/when it is needed (or VLAN manipulation) etc. [JY] It may be commensurate with the negotiation of E-Tree bit in the contr= ol word (if using CW), but save the work of redesigning a new forwarding pl= ane;) BTW, not sure what is the problem with preservation of C-VLAN, can yo= u give some more hints? [[[Sasha]]] You do not really have to negotiate usage of the Leaf flag in = the CW. At most you have to negotiate usage of the CW, which is well define= d (including the latest standard for changes in the preferred CW usage:-). = And you would locally configure your VPLS instance to be an E-Tree on and h= ence setting the Leaf flag on Tx to peers and respecting the value of this = flag received from your peers. A regular VPLS instance (equivalent to Root = only) would never set this flag on Tx and ignore it on Rx =96 so you would = have complete backward compatibility at no cost. As for the new forwarding plane: IMHO you need some modifications in the fo= rwarding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-L= eaf traffic regardless of how you identify it. I do not see how you can avo= id it taking into account that E-Tree forwarding behavior is different from= a plain old Layer 2 switch. Regarding preservation of C-VLANs =96 would you not need to push the Root/L= eaf VLAN tag on top of the C-tag you are going to preserve? This may result= in backward compatibility issues when you have Root-only PEs that now have= to be aware of these additional VLAN tags (push them on Tx and pop them on= Rx). Unfortunately the WG has decided to drop this approach - presumably, becaus= e it mandated the use of CW in the Ethernet PW encapsulation which is not s= upported by some implementations. So now we have a good chance to end with two different solutions (one for E= -VPN and one for regular VPLS), and, most probably, with some additional me= chanism for their interworking... But is probably spilled milk now. Regards. Sasha. ________________________________ From: Jiangyuanlong [jiangyuanlong@huawei.com] Sent: Monday, September 24, 2012 4:22 AM To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Sasha, >From Ali=92s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS l= abels per Ethernet segment are used for E-Tree. So one is used for root tra= ffic and another is used for leaf traffic, just like in the 2PW approach. But it has the same problem as 2PW IMHO and OAM will be a challenge. Besides, manipulation of those labels and import/export of their associated= RT attributes may not be easy. Thanks, Yuanlong From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Sunday, September 23, 2012 4:25 PM To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest= IETF meeting). But I think something is wrong with the statement "there was no benefit in = the E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (= or more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must s= omehow identify the source AC of the Ethernet frame in this packet, and, in= the case of it being a leaf AC, prevent its forwarding to the local Leaf A= C(s) while allowing forwarding to local Root AC(s). This equally applies to= regular VPLS and E-VPN, e.g., in the case when the contained Ethernet fram= e is a broadcast one (so that no learning is associated with it). And I str= ongly doubt this can be achieved without some =93tags=94 in the encapsulati= on. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn= -bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me= : > " Giles - are we agreed we want to get to one solution for VPLS a= nd E- > VPN. > Not many people. But even fewer who want multiple. Checked to= see > if > people want one solution only for E-VPN and VPLS - only a coupl= e of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus t= o > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org > Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2v= lan- > 00.txt > > Thanks Yuanlong, > > however I must say that your memory of the IETF 84 L2VPN meeting differs > from mine (and from what is noted in the minutes). Whilst Himanshu said > that it was better to have the same solution for VPLS and E-VPN, Ali stat= ed > that there was no benefit in the E-VPN case in using an additional tag (s= uch as > a VLAN). No consensus was reached in the meeting. > > Giles > > On 21 Sep 2012, at 10:16, Jiangyuanlong > > wrote: > > > Hi all, > > > > During the 84th IETF meeting, the group discussed the issue of E-Tree i= n E- > VPN, and it was shown that a single solution was more preferred than two > different approaches for VPLS and E-VPN. > > This I-D probes how the 2VLAN approach can be used to support E-Tree in > E-VPN and it seems not a big issue. > > Any comments from you are greatly appreciated. > > > > Best regards, > > Yuanlong > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto= :internet-drafts@ietf.org] > > Sent: Friday, September 21, 2012 4:55 PM > > To: Jiangyuanlong > > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n- > 00.txt > > > > > > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > has been successfully submitted by Yuanlong Jiang and posted to the > > IETF repository. > > > > Filename: draft-jiang-l2vpn-evpn-etree-2vlan > > Revision: 00 > > Title: E-Tree Support with 2VLAN in E-VPN > > Creation date: 2012-09-21 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-= evpn- > etree-2vlan-00.txt > > Status: http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn= -etree- > 2vlan > > Htmlized: http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etre= e- > 2vlan-00 > > > > > > Abstract: > > This document discusses how the Dual-VLAN approach as described in > > [Etree-vlan] can be used to support the transport of E-Tree service > > in E-VPN. Thus a single convergent solution is possible for both VPLS > > and E-VPN. > > > > > > > > > > The IETF Secretariat > > This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_CC8600D81A73Asajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6A37FDB00969AF47BC129989C1D0E3CB@cisco.com> Content-Transfer-Encoding: quoted-printable

Sasha,

As the co-author of vlan-tag solution for VPLS, I must admit that I sy= mpathize with your concern regarding vlan-tag solution; however, among the = three proposals (vlan-tags, control word, and PWs), IMO, vlan-tag is less o= f an evil (although it is subjective :-). As you mention, we need to modify data-forwarding behavior regardless= of which of these three models we go with and all three models break the m= odel described in bridge-interop RFC. 

With E-VPN, the ETREE service can inherently be supported with the exi= sting forwarding model without introducing any new mechanism !! And that's = why it doesn't make sense to add any other mechanism on top of E-VPN. =

As the co-author of vlan-tag solution for VPLS, I think this drat need= s cleaning and we will do that in subsequent revisions.

Cheers,
Ali

From: Alexander Vainshtein <Alexander.Vainshtein@ecitel= e.com>
Date: Monday, September 24, 2012 1:= 12 AM
To: Jiangyuanlong <jiangyuanlong@huawei.com>, Giles Hero= n <giles.heron@gmail.com>= ;, Cisco Employee <sajassi@cisco.co= m>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: RE: New Version Notificati= on for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Yuanlong hi!

Lots of thanks for a prompt response.

Please see some responses in line below.

 

Regards,

   &nbs= p; Sasha

 

From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]
Sent: Monday, September 24, 2012 9:44 AM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Hi Sasha,

 

You are aiming 2 birds with a single stone;)

But please see my comments in line.=

 

Thanks,

Yuanlong

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, September 24, 2012 2:25 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

&nbs= p;

Yuanlong.

Lots of thanks for a prompt response and clarification.

 =

I have always considered the CW-based proposal for E-tree as the simplest= (and, by implication, the most clean) approach:

- No need to distribute the types of ACs a given PE supports (and to re-d= istribute it when the set of ACs is changed). It is a purely local mat= ter

- No OAM issues

[JY] it seems neither issue is with 2VLAN, right?

 

- No need to allocate special VLAN tags to mark Leaf and Root- originated= traffic and to propagate these allocations - hence no problem with preserv= ation of  C-VLANs if/when it is needed (or VLAN manipulation) etc.

[JY] It may be commensurate with the negotiation of = E-Tree bit in the control word (if using CW), but save the work of redesign= ing a new forwarding plane;) BTW, not sure what is the problem with preservation of C-VLAN, can you give som= e more hints?

[[[Sasha]]] You do not really have to negotiate usage of the Leaf  flag= in the CW. At most you have to negotiate usage of the CW<= /span>, which is well defined (including the latest standard for changes in the pr= eferred CW usage:-). And you would locally configure your VPLS instance to = be an E-Tree on and hence setting the Leaf flag on Tx to peers and respecti= ng the value of this flag received from your peers. A regular VPLS instance (equivalent to Root only) would n= ever set this flag on Tx and ignore it on Rx =96 so you would have complete= backward compatibility at no cost.

 

As for the new forwarding plane: IMHO you need s= ome modifications in the forwarding plane to mark Leaf-originated traffic o= n Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how you can avoid it takin= g into account that E-Tree forwarding behavior is different from a plain ol= d Layer 2 switch.

Regarding preservation of C-VLANs =96 would you = not need to push the Root/Leaf VLAN tag on top of the C-tag you are going t= o preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to be aware= of these additional VLAN tags (push them on Tx and pop them on Rx).

 

 =

Unfortunately the WG has decided to drop this approach - presum= ably, because it mandated the use of CW in the Ethernet PW encapsulation wh= ich is not supported by some implementations.

 =

So now we have a good chance to end with two different sol= utions (one for E-VPN and one for regular VPLS), and, most probably, with s= ome additional mechanism for their interworking...

 =

But is probably spilled milk now.

 =

Regards.

Sasha.=

    

From:= Jiangyuanlong [jiang= yuanlong@huawei.com]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

Sasha,

 

From Ali=92s I-D draft-sajassi-l2vpn-evpn-etree-00, i= t seems two ESI MPLS labels per Ethernet segment are used for E-Tree. So on= e is used for root traffic and another is used for leaf traffic, just like in the 2PW approach.

But it has the same problem as 2PW IMHO and OAM will = be a challenge.

Besides, manipulation of those labels and import/expo= rt of their associated RT attributes may not be easy.

 

Thanks,

Yuanlong

 

From: Alexander Vainshtein= [mailto:Alexander.Vain= shtein@ecitele.com]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: l2vpn@ietf.org
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etr= ee-2vlan-00.txt

 

Yuanlong, Giles, Himanshu, Ali and all,

I have probably missed something important (not being present at the = latest IETF meeting).

But I think something is wrong with the statement "there was = no benefit in the E-VPN case in using an additional tag (such as a VLAN)&qu= ot;.

 

IMHO and FWIW the real E-Tree problem is the situation when there are= two (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from another such PE, it = must somehow identify the source AC of the Ethernet frame in this packet, a= nd, in the case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding t= o local Root AC(s). This equally applies to regular VPLS and E-VPN, e.g., i= n the case when the contained Ethernet frame is a broadcast one (so that no= learning is associated with it). And I strongly doubt this can be achieved without some =93tags=94 in the e= ncapsulation.

 

My 2c,

     Sasha

 

> -----Original Message-----

> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: l2vpn@ietf.org

> Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn= -etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minutes was not so cle= ar for me:

> "         Giles - a= re we agreed we want to get to one solution for VPLS and E-

> VPN.

>           Not = many people.  But even fewer who want multiple.  Checked to see

> if

>           peop= le want one solution only for E-VPN and VPLS - only a couple of<= /span>

> hands."

> Nevertheless, E-VPN needs an E-Tree solution and it is the WG co= nsensus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mail= to:giles.heron@gmail.com]

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: l2vpn@ietf.org

> Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn= -etree-2vlan-

> 00.txt

>

> Thanks Yuanlong,

>

> however I must say that your memory of the IETF 84 L2VPN meeting= differs

> from mine (and from what is noted in the minutes).  Whilst = Himanshu said

> that it was better to have the same solution for VPLS and E-VPN,= Ali stated

> that there was no benefit in the E-VPN case in using an addition= al tag (such as

> a VLAN).  No consensus was reached in the meeting.

>

> Giles

>

> On 21 Sep 2012, at 10:16, Jiangyuanlong <jiangyuanlong@huawei= .com><= o:p>

> wrote:

>

> > Hi all,

> >

> > During the 84th IETF meeting, the group discussed the issue= of E-Tree in E-

> VPN, and it was shown that a single solution was more preferred = than two

> different approaches for VPLS and E-VPN.

> > This I-D probes how the 2VLAN approach can be used to suppo= rt E-Tree in

> E-VPN and it seems not a big issue.

> > Any comments from you are greatly appreciated.

> >

> > Best regards,

> > Yuanlong

> >

> > -----Original Message-----

> > From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> > Sent: Friday, September 21, 2012 4:55 PM<= /p>

> > To: Jiangyuanlong

> > Subject: New Version Notification for draft-jiang-l2vpn-evp= n-etree-2vlan-

> 00.txt

> >

> >

> > A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00= .txt

> > has been successfully submitted by Yuanlong Jiang and poste= d to the

> > IETF repository.

> >

> > Filename:     draft-jiang-l2vpn-evpn-et= ree-2vlan

> > Revision:      00

> > Title:         = ;            &n= bsp;         E-Tree Support with 2V= LAN in E-VPN

> > Creation date:       &nb= sp;    2012-09-21

> > WG ID:         = ;            &n= bsp;     Individual Submission

> > Number of pages: 6

> > URL:         &= nbsp;   http://www.ietf.org/internet-= drafts/draft-jiang-l2vpn-evpn-

> etree= -2vlan-00.txt

> > Status:        &nbs= p; http://datatracker.ietf.org/doc/draft-ji= ang-l2vpn-evpn-etree-

> 2vlan=

> > Htmlized:        http://tools.ietf.org/html/draft-jiang-l2v= pn-evpn-etree-

> 2vlan-00<= /p>

> >

> >

> > Abstract:

> >   This document discusses how the Dual-VLAN appro= ach as described in

> >   [Etree-vlan] can be used to support the transpo= rt of E-Tree service

> >   in E-VPN. Thus a single convergent solution is = possible for both VPLS

> >   and E-VPN.

> >

> >

> >

> >

> > The IETF Secretariat

> >

 

This e-mail messa= ge is intended for the recipient only and contains information which is CON= FIDENTIAL and which may be proprietary to ECI Telecom. If you have received= this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all co= pies thereof.

This e-mail message is intend= ed for the recipient only and contains information which is CONFIDENTIAL an= d which may be proprietary to ECI Telecom. If you have received this transm= ission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies there= of.

This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof.

--_000_CC8600D81A73Asajassiciscocom_-- From sajassi@cisco.com Mon Sep 24 16:41:45 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 4AB0D1F0C9E for ; Mon, 24 Sep 2012 16:41:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlasbSMG-YJY for ; Mon, 24 Sep 2012 16:41:44 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7C03B1F042B for ; Mon, 24 Sep 2012 16:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3996; q=dns/txt; s=iport; t=1348530104; x=1349739704; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FxganMMXmxnKganNmv6dhg7WoBJC+cdyuG7TuTGEjsc=; b=Kg6EbVWPOEjjMLxSSZHtO6mxQTYlBGibH/sxWRMifH++o5/WdfaRAcez zc+ktZlpfNkpUpli8L224QXBVT12xGW7jz4SdIJVnfj5ObPO1oe4kFazz iY3Rq+RTg+LGckdGHaBkyXt+IqeK1c/5s+7Ew4uCqEMaQm/AVo5fbiZmI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPTuYFCtJV2a/2dsb2JhbABFgm67dYEIgiABAQEEEgEnLRACDAYBCBEEAQEBHgkoERQJCAIEAQ0FCRIHh1EDDwEKmF2WSg2JU4o5YoNpglkDlBCBVYEVigSDIYFpgloNghc X-IronPort-AV: E=Sophos;i="4.80,478,1344211200"; d="scan'208";a="124897166" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 24 Sep 2012 23:41:38 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8ONfcR4016888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Sep 2012 23:41:38 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Mon, 24 Sep 2012 18:41:38 -0500 From: "Ali Sajassi (sajassi)" To: Jiangyuanlong , Giles Heron Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmq4jwiPKE60TckqkD+4iKjRz4Q== Date: Mon, 24 Sep 2012 23:41:37 +0000 Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.64.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19206.004 x-tm-as-result: No--46.185900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Mon, 24 Sep 2012 23:41:45 -0000 Jiangyuanlong, Your proposal of applying vlan-tags (as done for VPLS) to E-VPN solution is broken and doesn't work properly for E-VPN for the following reasons: 1) It breaks MPLS forwarding for egress PE - E-VPN allows for pure MPLS forwarding at the egress PE 2) Even in scenarios where MAC lookup is used on egress PE, it creates unnecessary overhead that is absolutely NOT needed. E-VPN multicast packets already carries SH label (which as describe in etree-evpn draft) is also used for root/leaf indication. EVPN is the next gen solution which doesn't have the limitation of existing vpls solution. It is extreemly flexible as it allows for pure MPLS forwarding to a given AC without any MAC lookup (in either direction). It allows for asymmetric MAC lookup operation (lookup in the ingress PE but no lookup on the egress PE). Or it allows for lookup in both directions. We don't want to contamiate such solution with the kludge that we used for VPLS. Cheers, Ali=20 On 9/21/12 7:31 PM, "Jiangyuanlong" wrote: >Hi Giles, > >Perhaps the gauge of the consensus in the minutes was not so clear for me: >" Giles - are we agreed we want to get to one solution for VPLS >and E-VPN. > Not many people. But even fewer who want multiple. Checked to >see if > people want one solution only for E-VPN and VPLS - only a >couple of hands." >Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus >to decide which way to take. > >Thanks, >Yuanlong > >-----Original Message----- >From: Giles Heron [mailto:giles.heron@gmail.com] >Sent: Friday, September 21, 2012 9:09 PM >To: Jiangyuanlong >Cc: l2vpn@ietf.org >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >Thanks Yuanlong, > >however I must say that your memory of the IETF 84 L2VPN meeting differs >from mine (and from what is noted in the minutes). Whilst Himanshu said >that it was better to have the same solution for VPLS and E-VPN, Ali >stated that there was no benefit in the E-VPN case in using an additional >tag (such as a VLAN). No consensus was reached in the meeting. > >Giles > >On 21 Sep 2012, at 10:16, Jiangyuanlong wrote: > >> Hi all, >>=20 >> During the 84th IETF meeting, the group discussed the issue of E-Tree >>in E-VPN, and it was shown that a single solution was more preferred >>than two different approaches for VPLS and E-VPN. >> This I-D probes how the 2VLAN approach can be used to support E-Tree in >>E-VPN and it seems not a big issue. >> Any comments from you are greatly appreciated. >>=20 >> Best regards, >> Yuanlong >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, September 21, 2012 4:55 PM >> To: Jiangyuanlong >> Subject: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>=20 >>=20 >> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> has been successfully submitted by Yuanlong Jiang and posted to the >> IETF repository. >>=20 >> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >> Revision: 00 >> Title: E-Tree Support with 2VLAN in E-VPN >> Creation date: 2012-09-21 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>.txt >> Status: =20 >>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >> Htmlized: =20 >>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>=20 >>=20 >> Abstract: >> This document discusses how the Dual-VLAN approach as described in >> [Etree-vlan] can be used to support the transport of E-Tree service >> in E-VPN. Thus a single convergent solution is possible for both VPLS >> and E-VPN. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 > From jiangyuanlong@huawei.com Mon Sep 24 23:43:43 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 0CDC121F8893 for ; Mon, 24 Sep 2012 23:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2YxSim7A5vl for ; Mon, 24 Sep 2012 23:43:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 256BB21F84F2 for ; Mon, 24 Sep 2012 23:43:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALA09861; Tue, 25 Sep 2012 06:43:38 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 07:42:59 +0100 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 07:43:37 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Tue, 25 Sep 2012 14:43:29 +0800 From: Jiangyuanlong To: "Ali Sajassi (sajassi)" , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNl9bO5vMHP1fUbUG3AEjOw2TsF5eUffmw///A2YCAAVUrAIAEEn+AgADugbA= Date: Tue, 25 Sep 2012 06:43:28 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E157@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46DCCD@szxeml546-mbs.china.huawei.com> 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.95] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E157szxeml546mbschi_" 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: Tue, 25 Sep 2012 06:43:43 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E157szxeml546mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ali, I am not sure whether "pure MPLS forwarding at the egress PE" is something = we are pursuing or something true enough, but it seems to me the forwarding= of EVPN is not so different from VPLS/VPWS in the description of EVPN docu= ment: " Per EVI label assignment requires the least number of E-VPN labels, but requires a MAC lookup in addition to an MPLS lookup on an egress PE for forwarding. On the other hand, a unique label per or a unique label per MAC allows an egress PE to forward a packet that it receives from another PE, to the connected CE, after looking up only the MPLS labels without having to perform a MAC lookup. This includes the capability to perform appropriate VLAN ID translation on egress to the CE. " That is, if label per EVI is allocated, forwarding is based on MAC lookup (= like VPLS), otherwise, if label per Ethernet segment or per MAC is allocate= d, the forwarding is like in VPWS, and VLAN translation is allowed further.= Why an extra VLAN translation operation breaks? For the 2nd question, I could not find SH label in the etree-evpn draft, we= re you referring to ESI MPLS label? Thanks, Yuanlong -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, September 25, 2012 7:42 AM To: Jiangyuanlong; Giles Heron Cc: l2vpn@ietf.org Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Jiangyuanlong, Your proposal of applying vlan-tags (as done for VPLS) to E-VPN solution is broken and doesn't work properly for E-VPN for the following reasons: 1) It breaks MPLS forwarding for egress PE - E-VPN allows for pure MPLS forwarding at the egress PE 2) Even in scenarios where MAC lookup is used on egress PE, it creates unnecessary overhead that is absolutely NOT needed. E-VPN multicast packets already carries SH label (which as describe in etree-evpn draft) is also used for root/leaf indication. EVPN is the next gen solution which doesn't have the limitation of existing vpls solution. It is extreemly flexible as it allows for pure MPLS forwarding to a given AC without any MAC lookup (in either direction). It allows for asymmetric MAC lookup operation (lookup in the ingress PE but no lookup on the egress PE). Or it allows for lookup in both directions. We don't want to contamiate such solution with the kludge that we used for VPLS. Cheers, Ali On 9/21/12 7:31 PM, "Jiangyuanlong" wrote: >Hi Giles, > >Perhaps the gauge of the consensus in the minutes was not so clear for me: >" Giles - are we agreed we want to get to one solution for VPLS >and E-VPN. > Not many people. But even fewer who want multiple. Checked to >see if > people want one solution only for E-VPN and VPLS - only a >couple of hands." >Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus >to decide which way to take. > >Thanks, >Yuanlong > >-----Original Message----- >From: Giles Heron [mailto:giles.heron@gmail.com] >Sent: Friday, September 21, 2012 9:09 PM >To: Jiangyuanlong >Cc: l2vpn@ietf.org >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >Thanks Yuanlong, > >however I must say that your memory of the IETF 84 L2VPN meeting differs >from mine (and from what is noted in the minutes). Whilst Himanshu said >that it was better to have the same solution for VPLS and E-VPN, Ali >stated that there was no benefit in the E-VPN case in using an additional >tag (such as a VLAN). No consensus was reached in the meeting. > >Giles > >On 21 Sep 2012, at 10:16, Jiangyuanlong wrote: > >> Hi all, >> >> During the 84th IETF meeting, the group discussed the issue of E-Tree >>in E-VPN, and it was shown that a single solution was more preferred >>than two different approaches for VPLS and E-VPN. >> This I-D probes how the 2VLAN approach can be used to support E-Tree in >>E-VPN and it seems not a big issue. >> Any comments from you are greatly appreciated. >> >> Best regards, >> Yuanlong >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, September 21, 2012 4:55 PM >> To: Jiangyuanlong >> Subject: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >> >> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> has been successfully submitted by Yuanlong Jiang and posted to the >> IETF repository. >> >> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >> Revision: 00 >> Title: E-Tree Support with 2VLAN in E-VPN >> Creation date: 2012-09-21 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: >>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>.txt >> Status: >>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >> Htmlized: >>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >> >> >> Abstract: >> This document discusses how the Dual-VLAN approach as described in >> [Etree-vlan] can be used to support the transport of E-Tree service >> in E-VPN. Thus a single convergent solution is possible for both VPLS >> and E-VPN. >> >> >> >> >> The IETF Secretariat >> > --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E157szxeml546mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ali,

 

I am not sure whether "= pure MPLS forwarding at the egress PE” is = something we are pursuing or something true enough, but it seems to me the forwarding of EVPN is not so different from VPLS/VPWS in the des= cription of EVPN document:

"

   Per EVI label a= ssignment requires the least number of E-VPN labels,

   but requires a = MAC lookup in addition to an MPLS lookup on an egress

   PE for forwardi= ng. On the other hand, a unique label per <ESI,

   Ethernet Tag>= ; or a unique label per MAC allows an egress PE to

   forward a packe= t that it receives from another PE, to the connected

   CE, after= looking up only the MPLS labels without having to perform a=

   MAC looku= p. This includes the capability to perform appropriate VLAN

   ID transl= ation on egress to the CE.

"

That is, if label per EVI is= allocated, forwarding is based on MAC lookup (like VPLS), otherwise, if la= bel per Ethernet segment or per MAC is allocated, the forwarding is like in= VPWS, and VLAN translation is allowed further. Why an extra VLAN translation operation breaks?=

 

For the 2nd quest= ion, I could not find SH label in the etree-evpn draft, were you referring = to ESI MPLS label?

 

Thanks,

Yuanlong

 

 

-----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, September 25, 2012 7:42 AM
To: Jiangyuanlong; Giles Heron
Cc: l2vpn@ietf.org
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt

 

 

Jiangyuanlong,

 

 

Your proposal of applying vl= an-tags (as done for VPLS) to E-VPN solution

is broken and doesn't work p= roperly for E-VPN for the following reasons:

 

1) It breaks MPLS forwarding= for egress PE - E-VPN allows for pure MPLS

forwarding at the egress PE<= o:p>

 

2) Even in scenarios where M= AC lookup is used on egress PE, it creates

unnecessary overhead that is= absolutely NOT needed. E-VPN multicast

packets already carries SH l= abel (which as describe in etree-evpn draft)

is also used for root/leaf i= ndication.

 

 

EVPN is the next gen solutio= n which doesn't have the limitation of

existing vpls solution. It i= s extreemly flexible as it allows for pure

MPLS forwarding to a given A= C without any MAC lookup (in either

direction). It allows for as= ymmetric MAC lookup operation (lookup in the

ingress PE but no lookup on = the egress PE). Or it allows for lookup in

both directions. We don't wa= nt to contamiate such solution with the kludge

that we used for VPLS.<= /o:p>

 

Cheers,

Ali

 

 

 

On 9/21/12 7:31 PM, "Ji= angyuanlong" <jiangyuanlong@huawei.com> wrote:=

 

>Hi Giles,

> =

>Perhaps the gauge of the= consensus in the minutes was not so clear for me:

>"   =       Giles - are we agreed we want to get to one = solution for VPLS

>and E-VPN.

>    =       Not many people.  But even fewer who wa= nt multiple.  Checked to

>see if=

>    =       people want one solution only for E-VPN and = VPLS - only a

>couple of hands."

>Nevertheless, E-VPN need= s an E-Tree solution and it is the WG consensus

>to decide which way to t= ake.

> =

>Thanks,

>Yuanlong

> =

>-----Original Message---= --

>From: Giles Heron [mailt= o:giles.heron@gmail.com]

>Sent: Friday, September = 21, 2012 9:09 PM

>To: Jiangyuanlong

>Cc: l2vpn@ietf.org<= /o:p>

>Subject: Re: New Version= Notification for

>draft-jiang-l2vpn-evpn-e= tree-2vlan-00.txt

> =

>Thanks Yuanlong,

> =

>however I must say that = your memory of the IETF 84 L2VPN meeting differs

>from mine (and from what= is noted in the minutes).  Whilst Himanshu said

>that it was better to ha= ve the same solution for VPLS and E-VPN, Ali

>stated that there was no= benefit in the E-VPN case in using an additional

>tag (such as a VLAN).&nb= sp; No consensus was reached in the meeting.

> =

>Giles<= /p>

> =

>On 21 Sep 2012, at 10:16= , Jiangyuanlong <jiangyuanlong@huawei.com> wrote:

> =

>> Hi all,<= /span>

>> <= /p>

>> During the 84th IET= F meeting, the group discussed the issue of E-Tree

>>in E-VPN, and it was= shown that a single solution was more preferred

>>than two different a= pproaches for VPLS and E-VPN.

>> This I-D probes how= the 2VLAN approach can be used to support E-Tree in

>>E-VPN and it seems n= ot a big issue.

>> Any comments from y= ou are greatly appreciated.

>> <= /p>

>> Best regards,<= /o:p>

>> Yuanlong=

>> <= /p>

>> -----Original Messa= ge-----

>> From: internet-draf= ts@ietf.org [mailto:internet-drafts@ietf.org]

>> Sent: Friday, Septe= mber 21, 2012 4:55 PM

>> To: Jiangyuanlong

>> Subject: New Versio= n Notification for

>>draft-jiang-l2vpn-ev= pn-etree-2vlan-00.txt

>> <= /p>

>> <= /p>

>> A new version of I-= D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

>> has been successful= ly submitted by Yuanlong Jiang and posted to the

>> IETF repository.

>> <= /p>

>> Filename: &nbs= p;  draft-jiang-l2vpn-evpn-etree-2vlan

>> Revision: &nbs= p;   00

>> Title:  &= nbsp;          E-Tree Support = with 2VLAN in E-VPN

>> Creation date: = ;   2012-09-21

>> WG ID:  &= nbsp;           &nbs= p;   Individual Submission

>> Number of pages: 6<= o:p>

>> URL:  &nb= sp;        

>>http://www.ietf.org/= internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00

>>.txt

>> Status:  =       

>>http://datatracker.i= etf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan

>> Htmlized: &nbs= p;    

>>http://tools.ietf.or= g/html/draft-jiang-l2vpn-evpn-etree-2vlan-00

>> <= /p>

>> <= /p>

>> Abstract:

>>   This do= cument discusses how the Dual-VLAN approach as described in

>>   [Etree-= vlan] can be used to support the transport of E-Tree service

>>   in E-VP= N. Thus a single convergent solution is possible for both VPLS

>>   and E-V= PN.

>> <= /p>

>> <= /p>

>> <= /p>

>> <= /p>

>> The IETF Secretaria= t

>> <= /p>

> =

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E157szxeml546mbschi_-- From jiangyuanlong@huawei.com Tue Sep 25 00:02: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 067DF21F8938 for ; Tue, 25 Sep 2012 00:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zi5qpu25GRt for ; Tue, 25 Sep 2012 00:02:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 730E421F892F for ; Tue, 25 Sep 2012 00:02:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJZ45094; Tue, 25 Sep 2012 07:02:31 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 08:01:47 +0100 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 08:02:25 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Tue, 25 Sep 2012 15:02:17 +0800 From: Jiangyuanlong To: "Ali Sajassi (sajassi)" , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmq4pFVANLlv0RU6/0DirrqUYkJeanNRA Date: Tue, 25 Sep 2012 07:02:17 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E172@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.66.77.95] 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: Tue, 25 Sep 2012 07:02:37 -0000 Hi all, I don't think E-VPN control plane can solve all the problem of E-Tree. For the following two scenarios data plane indication of E-Tree is needed: 1. Per EVI label is assigned, and there are multiple PEs with both Leaf AND= Root sites; 2. Per label is assigned, and there are multiple Ethern= et segments with both Leaf AND Root sites; Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an option= , but maybe OAM is a challenge. Assigning label per MAC for E-Tree will not need this indication, but at ex= pense of scalability. Regards, Yuanlong -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]=20 Sent: Tuesday, September 25, 2012 7:42 AM To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron Cc: l2vpn@ietf.org; Jiangyuanlong Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Jim, Aldrin, Josh: You guys are spot on. E-VPN solution doesn't have the limitation of data-plane forwarding that VPLS has and as such it doesn't need addition vlan-tag to solve root/leaf indication issue as it can be supported inherently by the solution. Cheers, Ali On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: >Josh, > > Yes.. I think that is the reality of it.. VPLS either the LDP or BGP >variety uses data plane learning as the mechanism to "learn".. The fact >that we extend the L2 footprint via these "tunnels" does not change that >fact.. SO in VPLS the only hammer you have is the data plane, so one must >manipulate bits on the wire to infer topology ( Limited set of topology >).. > >Another challenge is when roots and leafs "land" on the same PE. > >EVPN is intended to use contexts and associated import/export to manage >the topology.. So here there is a set of tools to create the desired >topologies, along with that there other mechanisms realized i.e >active/active... > >Jim Uttaro > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Saturday, September 22, 2012 7:03 PM >To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >I agree. > >Would it be safe to state that VPLS has a need for a 'etree solution', but >EVPN does not, because it is inherently supported? > >The previously discussed effort of having a 'single etree solution' for >both VPLS and EVPN may not really be valid due to this. > >In fact, I do not think it is valid to ask for a single solution, EVPN >doesn't have a problem that needs to be fixed here, I don't believe it >factors into this discussion. > >-Josh > > >On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: > >>EVPN is intended to maximize the flexibility of multiple routing contexts >>with arbitrary topologies.. As I have stated in the past, EVPN allows for >>E-Tree to be constructed in the control plane, other solutions require >>some method to interrogate data and infer topology. IMO this is not >>desirable. >> >>Jim Uttaro >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Rogers, Josh >>Sent: Saturday, September 22, 2012 12:49 PM >>To: Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >>So, this same sort of 'import/export' of targets is possible using >>BGP-VPLS today, but it faces limitations outlined in >>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 >>may import RTA, while AC2 on PE2 may import RTB? >> >>Its occurred to me that EVPN would be able to use other mechanisms that >>have not yet been discussed yet due to sharing a mac table over BGP. >> >>Thanks for the response, >>Josh >> >> >>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >> >>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB >>>export RTA at spokes) with filtering to enforce downstream data flow if >>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>> >>> >>> >>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>> >>>> Thanks Yuanlong, >>>> >>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>differs from mine (and from what is noted in the minutes). Whilst >>>>Himanshu said that it was better to have the same solution for VPLS and >>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>meeting. >>>> >>>> Giles >>>> >>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>wrote: >>>> >>>>> Hi all, >>>>> >>>>> During the 84th IETF meeting, the group discussed the issue of E-Tree >>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>than two different approaches for VPLS and E-VPN. >>>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>>in E-VPN and it seems not a big issue. >>>>> Any comments from you are greatly appreciated. >>>>> >>>>> Best regards, >>>>> Yuanlong >>>>> >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>> To: Jiangyuanlong >>>>> Subject: New Version Notification for >>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>> >>>>> >>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>> IETF repository. >>>>> >>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>> Revision: 00 >>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>> Creation date: 2012-09-21 >>>>> WG ID: Individual Submission >>>>> Number of pages: 6 >>>>> URL: >>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>- >>>>>0 >>>>>0.txt >>>>> Status: >>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>> Htmlized: >>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>> >>>>> >>>>> Abstract: >>>>> This document discusses how the Dual-VLAN approach as described in >>>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>VPLS >>>>> and E-VPN. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use 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 dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use 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 dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. From Alexander.Vainshtein@ecitele.com Tue Sep 25 01:08: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 523AD21F8585 for ; Tue, 25 Sep 2012 01:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.452 X-Spam-Level: X-Spam-Status: No, score=-4.452 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0GR3DBWnlAR for ; Tue, 25 Sep 2012 01:08:49 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBD821F853F for ; Tue, 25 Sep 2012 01:08:48 -0700 (PDT) Received: from [85.158.138.51:56002] by server-14.bemta-3.messagelabs.com id 89/E6-21431-09661605; Tue, 25 Sep 2012 08:08:48 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1348560517!31350415!10 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 21339 invoked from network); 25 Sep 2012 08:08:47 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-4.tower-174.messagelabs.com with SMTP; 25 Sep 2012 08:08:47 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-81-506161dea06a Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id EC.84.06426.ED161605; Tue, 25 Sep 2012 09:48:46 +0200 (IST) Received: from ILPTWPVEXCA02.ecitele.com (172.31.244.232) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server (TLS) id 8.3.264.0; Tue, 25 Sep 2012 10:08:46 +0200 Received: from ILPTWPVEXMB03.ecitele.com ([fe80::91b4:8f74:ce44:f190]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.01.0379.000; Tue, 25 Sep 2012 10:08:46 +0200 From: Alexander Vainshtein To: "Ali Sajassi (sajassi)" , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmq4kRS8tXuhBSbG0BUc+K0zeA5easrCJ Date: Tue, 25 Sep 2012 08:08:45 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA1VTf2gTVxzn5S7JNfbcmbTLswi7nXWMaTRZLZzaOKX7I4NN47TKJlPP5Jkc S+7C3SlGCkad2ygM3VqYSR1VDHZaZVpXu5J2uGDZLHQWYSrDumqrpXE/Sv1Rt0bruxzW7p/H 532/n+/n877vfR9F2I9ZyyhR0pAiCRHOYiPrc2M5101B8Lvbzzn4ZGY/yd/pPgT430Y/s/Df HMuT/HDqgpkffJS18n/37iNXWH0jBw4DX8PEWbOvI9Vv9X1y8S+zL53+1+RrOZUj/ZYPE6BK kCRZEzTEBpEa8HJ+RdwhBOIcKwa9nIdjYxEhgKJI0rycEIshKcgtt1XhoCixSArIQVEKebl3 1q528XzlEpeHW/7aXE/FMtu6sKiyyBUVxAgbRaoqhBCLI3o7UhAF2W2ywmphxCpb6olw/cML 1tjDlTu7GrwJ8LiyDhRRkFkMr351CRj4Zdh38zuLju1MF4D5y6vqgA3j8wDe+rEVGJtuAPd/ +rNVZ1kYL2xt6S9UlDC9ALZ0+HVMMGtg/chAIe5gamD/iSdWg7MejvbcIgz8Jsx/kS84k8w8 OP64vcChGT+81tgJjFPsgifGDpA6LmIWwetNEwVNgE863nPKZHg54e9DTSajAwamOy8TBi6F I4NPzQZ+BZ5rGzQb/AXwSGbMYuD58PjRe4ThOwteSg6Rhq8L9vxSZzoIYGqaRWpaeWpaeWpa +RFAngSlYiSmbY2G3J6FKCBqKIIWBuRoKzCGa/gH8F9TeRYwFOCK6TOnt/jtZmGHGo9mwWzK xJXSF/Hs2WdulYPxsKCGNyvbI0jNAkgRXAmdmYNzdFCI70KK/DzF4xv8kiibEZD1d9c2V7jd /9twTro5sWG1nQnhAfwYoRhSnpfOoSgO0tcQVp2loBDauU2MaC/SJqpIdy7GzjU6h1ZjQlQV Q0a+B1RQjQ3pAUDd7sernZRkCZU56YkApjI6NbxdmlLT/9buycnJHHDizh10my5YjEd1Si+H rUzY6qXOTboV/i5TqbIEKLmC+PsrHbXjXR0/dW/4dijZXrSKfqsvU7NvzwPHvevnh5dW9h1/ tXppRq5dg+YenP1P6vPw6XyCp3vjh6rf3phzcrYli9/9oG19xVVpbbnX8/4fxbl5K9wfvZ6+ 8WtLVTJt2ttcfpRkZv45+l7267vJJrFkoLm60aJ0p8dvsLUPvudINSx43iAUVXgG+J/z1jYE AAA= Cc: "l2vpn@ietf.org" , Jiangyuanlong 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, 25 Sep 2012 08:08:51 -0000 Ali, Sorry for a naive question - but your response seems to imply that E-VPN use= s a separate application label per DMAC per VSI per remote PE (similar to th= e what BGP/MPLS VPN can do in one of its flavors where application label is= allocated and distributed for each locally reachable prefix). This would be indeed very different from VPLS where (regardless of the label= distribution method) uses one application label per VSI per remote peer. If this is the case, you indeed need any tagging to support E-Tree. But you can easily run into scalability problems (what if you need more than= 1M of MACs?) not to mention OAM problems. ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Ali Sajas= si (sajassi) [sajassi@cisco.com] Sent: Tuesday, September 25, 2012 1:41 AM To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron Cc: l2vpn@ietf.org; Jiangyuanlong Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree= -2vlan-00.txt Jim, Aldrin, Josh: You guys are spot on. E-VPN solution doesn't have the limitation of data-plane forwarding that VPLS has and as such it doesn't need addition vlan-tag to solve root/leaf indication issue as it can be supported inherently by the solution. Cheers, Ali On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: >Josh, > > Yes.. I think that is the reality of it.. VPLS either the LDP or BGP >variety uses data plane learning as the mechanism to "learn".. The fact >that we extend the L2 footprint via these "tunnels" does not change that >fact.. SO in VPLS the only hammer you have is the data plane, so one must >manipulate bits on the wire to infer topology ( Limited set of topology >).. > >Another challenge is when roots and leafs "land" on the same PE. > >EVPN is intended to use contexts and associated import/export to manage >the topology.. So here there is a set of tools to create the desired >topologies, along with that there other mechanisms realized i.e >active/active... > >Jim Uttaro > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Saturday, September 22, 2012 7:03 PM >To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >I agree. > >Would it be safe to state that VPLS has a need for a 'etree solution', but >EVPN does not, because it is inherently supported? > >The previously discussed effort of having a 'single etree solution' for >both VPLS and EVPN may not really be valid due to this. > >In fact, I do not think it is valid to ask for a single solution, EVPN >doesn't have a problem that needs to be fixed here, I don't believe it >factors into this discussion. > >-Josh > > >On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: > >>EVPN is intended to maximize the flexibility of multiple routing contexts >>with arbitrary topologies.. As I have stated in the past, EVPN allows for >>E-Tree to be constructed in the control plane, other solutions require >>some method to interrogate data and infer topology. IMO this is not >>desirable. >> >>Jim Uttaro >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Rogers, Josh >>Sent: Saturday, September 22, 2012 12:49 PM >>To: Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >>So, this same sort of 'import/export' of targets is possible using >>BGP-VPLS today, but it faces limitations outlined in >>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>import/export by attachment circuit, and not by PE? Meaning, AC1 one PE1 >>may import RTA, while AC2 on PE2 may import RTB? >> >>Its occurred to me that EVPN would be able to use other mechanisms that >>have not yet been discussed yet due to sharing a mac table over BGP. >> >>Thanks for the response, >>Josh >> >> >>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >> >>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB >>>export RTA at spokes) with filtering to enforce downstream data flow if >>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>> >>> >>> >>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>> >>>> Thanks Yuanlong, >>>> >>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>differs from mine (and from what is noted in the minutes). Whilst >>>>Himanshu said that it was better to have the same solution for VPLS and >>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>meeting. >>>> >>>> Giles >>>> >>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>wrote: >>>> >>>>> Hi all, >>>>> >>>>> During the 84th IETF meeting, the group discussed the issue of E-Tree >>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>than two different approaches for VPLS and E-VPN. >>>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>>in E-VPN and it seems not a big issue. >>>>> Any comments from you are greatly appreciated. >>>>> >>>>> Best regards, >>>>> Yuanlong >>>>> >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>> To: Jiangyuanlong >>>>> Subject: New Version Notification for >>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>> >>>>> >>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>> IETF repository. >>>>> >>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>> Revision: 00 >>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>> Creation date: 2012-09-21 >>>>> WG ID: Individual Submission >>>>> Number of pages: 6 >>>>> URL: >>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>- >>>>>0 >>>>>0.txt >>>>> Status: >>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>> Htmlized: >>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>> >>>>> >>>>> Abstract: >>>>> This document discusses how the Dual-VLAN approach as described in >>>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>VPLS >>>>> and E-VPN. >>>>> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>> >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use 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 dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use 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 dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From yuqun.cao@gmail.com Tue Sep 25 01:32:31 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 EF86721F8904 for ; Tue, 25 Sep 2012 01:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs0-95CYnAxn for ; Tue, 25 Sep 2012 01:32:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFF3A21F88D2 for ; Tue, 25 Sep 2012 01:32:30 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so3211331pbb.31 for ; Tue, 25 Sep 2012 01:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=C1/c9iA0M2QIj5Gq/4yrgdSLV3atvFwd+ej5JtJ1NJA=; b=gElmUx4TesZpr2Dv8xO0+evk7QD16J/4ZR04jnhuUEZf6sWqCu2bP+wre8Pz5YO5Kq SGiYTi+1WXeEwEv2qwKjWaiWHNMst2lxe20YboBYwNzaX+1MyBzyWKDiA8c6i/lj5A3B +ZniRdz629+DdHDr/jskiEC5yokYiK4GDox03fLw9pTXX5J76JRuGDp+PxPlglAsiAKX QGZF+ISWn1DTKDb3+QO22NocENHt/XmL2+xHpJyLDlETynoJZsLFyMQYFi/e/mxAL2qM m0qRRVAQDFmwS5Vhx6lUcScgDBMtVtmij/rlwpApTsKthAMQYDjcld7UQnWnXgsS0JzK rVRQ== Received: by 10.66.78.73 with SMTP id z9mr39306848paw.9.1348561950432; Tue, 25 Sep 2012 01:32:30 -0700 (PDT) Received: from Sam ([211.97.107.8]) by mx.google.com with ESMTPS id sr3sm11014928pbc.44.2012.09.25.01.32.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 01:32:29 -0700 (PDT) From: "Sam Cao" To: References: In-Reply-To: Subject: RE: L2vpn Digest, Vol 100, Issue 15 Date: Tue, 25 Sep 2012 16:32:15 +0800 Message-ID: <011101cd9af8$4b4b37c0$e1e1a740$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJbrrsYUIawA22BRfIoUh/hbEsW5JZ+kqMg Content-Language: zh-cn 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, 25 Sep 2012 08:32:32 -0000 +1. Sam -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Tuesday, September 25, 2012 3:00 AM To: l2vpn@ietf.org Subject: L2vpn Digest, Vol 100, Issue 15 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/l2vpn Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. RE: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt (UTTARO, JAMES) ---------------------------------------------------------------------- Message: 1 Date: Mon, 24 Sep 2012 14:32:07 +0000 From: "UTTARO, JAMES" To: "'Aldrin Isaac'" , Jiangyuanlong Cc: "l2vpn@ietf.org" , Ali Sajassi , Himanshu Shah Subject: RE: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Message-ID: Content-Type: text/plain; charset="us-ascii" +1 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Aldrin Isaac Sent: Monday, September 24, 2012 12:28 AM To: Jiangyuanlong Cc: l2vpn@ietf.org; Ali Sajassi; Himanshu Shah Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Hi Yuanlong, I'm not clear as to why different forwarding contexts for root and leaf is less than good -- can you elaborate? Also I'm not clear as to why you see that ETREE using EVPN is any different from other topologies that can be created with EVPN. EVPN's ability to create any topology is fundamental to it. In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in different VRF. In some cases we even overlap one or more hub-and-spoke RT pairs with one or more mesh RT. EVPN was purposefully designed to bring this flexibility to Ethernet. Best regards -- aldrin On Sunday, September 23, 2012, Jiangyuanlong wrote: Hi Aldrin, I agree with you that using different labels for root/leaf AC can work, but not sure using 2 forwarding contexts (EVI) is a good thing - that means forwarding plane for E-Tree will be very different from other services in E-VPN. Regards, Yuanlong From: Aldrin Isaac [mailto:aldrin.isaac@gmail.com] Sent: Sunday, September 23, 2012 9:21 PM To: Alexander Vainshtein Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; l2vpn@ietf.org Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt With EVPN, leaf AC should have different context and associated label from root AC. A leaf AC forwarding context (say EVI) on an ingress PE would not import the RT for other leaf AC and hence not have forwarding vectors to any leaf AC. The packet would have nowhere to go and hence be dropped on ingress. In the case of BUM ingress replication, the leaf AC forwarding context on the ingress PE would not have imported the Inclusive Tag route of egress leaf AC and hence have no vectors to local replication context IDs of other leaf AC . In the case of BUM tree, the leaf EVI would not have imported the Inclusive Tag route of other leaf EVI and hence not form a tree to other leaf EVI. On Sunday, September 23, 2012, Alexander Vainshtein wrote: Yuanlong, Giles, Himanshu, Ali and all, I have probably missed something important (not being present at the latest IETF meeting). But I think something is wrong with the statement "there was no benefit in the E-VPN case in using an additional tag (such as a VLAN)". IMHO and FWIW the real E-Tree problem is the situation when there are two (or more) PEs with both Root and Leaf ACs. When one of such PEs receives a VPLS packet from another such PE, it must somehow identify the source AC of the Ethernet frame in this packet, and, in the case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame is a broadcast one (so that no learning is associated with it). And I strongly doubt this can be achieved without some "tags" in the encapsulation. My 2c, Sasha > -----Original Message----- > From: l2vpn-bounces@ietf.org > [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Jiangyuanlong > Sent: Saturday, September 22, 2012 5:32 AM > To: Giles Heron > Cc: l2vpn@ietf.org > Subject: RE: New Version Notification for > draft-jiang-l2vpn-evpn-etree-2vlan- > 00.txt > > Hi Giles, > > Perhaps the gauge of the consensus in the minutes was not so clear for me: > " Giles - are we agreed we want to get to one solution for VPLS and E- > VPN. > Not many people. But even fewer who want multiple. Checked > to see > if > people want one solution only for E-VPN and VPLS - only a > couple of > hands." > Nevertheless, E-VPN needs an E-Tree solution and it is the WG > consensus to > decide which way to take. > > Thanks, > Yuanlong > > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Friday, September 21, 2012 9:09 PM > To: Jiangyuanlong > Cc: l2vpn@ietf.org -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 100, Issue 15 ************************************** From sajassi@cisco.com Tue Sep 25 22:55:17 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 D87F621F8826 for ; Tue, 25 Sep 2012 22:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89xaVG-01PnF for ; Tue, 25 Sep 2012 22:55:16 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23E21F87BD for ; Tue, 25 Sep 2012 22:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29469; q=dns/txt; s=iport; t=1348638916; x=1349848516; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=wbBzvxqu5VDRxocabkH/apHd9zWh5wx8T/r5HMyVSUg=; b=G4jgFTLN+42n1zWuGczGUfrvvbHeR6J/TV9LDwkveOvpzXk3gCGAMgFn jf3BZm9BU9woizt/aFclqZukeVVd+a46iRSKAvafzcIdQk+DmC2Jg76IW 3o2OwcsT5wnNFnQIzt85kZ4/hYvSludDqyta6/DV00ROq2JFwWuQi7GKv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAE+YYlCtJXG//2dsb2JhbABFgksjqyGIagGIZYEIgiABAQEDARIBGjoQAgUHBgEIEQMBAQEhAQYoERQJCAIEAQ0FCRIHh1EDCQYBCplRlj0NiVSKOGKGCQOUEYFVgRWKCYMhgWmCZ4FjNA X-IronPort-AV: E=Sophos;i="4.80,488,1344211200"; d="scan'208,217";a="125372461" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 26 Sep 2012 05:55:15 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8Q5tF6H017653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Sep 2012 05:55:15 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Wed, 26 Sep 2012 00:55:14 -0500 From: "Ali Sajassi (sajassi)" To: Jiangyuanlong , Giles Heron Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNm6t/BSBgWtJE/UGEFPctAcjr7g== Date: Wed, 26 Sep 2012 05:55:14 +0000 Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E157@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.91.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19210.004 x-tm-as-result: No--53.554200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC87E3691AF4Dsajassiciscocom_" 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: Wed, 26 Sep 2012 05:55:18 -0000 --_000_CC87E3691AF4Dsajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Yuanlong, MPLS forwarding is one of the forwarding mode in E-VPN that cannot be compr= omised. I would highly suggest that you read E-VPN drat again before making= any suggestions. The reasons that I gave you previously regarding why the = use of vlan-tag doesn't make sense for E-VPN still holds and if needed I ca= n go over the E-VPN solution the next time we meet. But I won't be able to = provide a tutorial over the email. As I mentioned before the E-VPN forwardi= ng plane already supports E-TREE without any changes to the forwarding beha= vior. And changing the E-VPN forwarding behavior to do something that it al= ready supports, doesn't make any sense. But you have heard that from multip= le people already. Cheers, Ali From: Jiangyuanlong > Date: Monday, September 24, 2012 11:43 PM To: Cisco Employee >, Giles Her= on > Cc: "l2vpn@ietf.org" > Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Hi Ali, I am not sure whether "pure MPLS forwarding at the egress PE=94 is somethin= g we are pursuing or something true enough, but it seems to me the forwardi= ng of EVPN is not so different from VPLS/VPWS in the description of EVPN do= cument: " Per EVI label assignment requires the least number of E-VPN labels, but requires a MAC lookup in addition to an MPLS lookup on an egress PE for forwarding. On the other hand, a unique label per or a unique label per MAC allows an egress PE to forward a packet that it receives from another PE, to the connected CE, after looking up only the MPLS labels without having to perform a MAC lookup. This includes the capability to perform appropriate VLAN ID translation on egress to the CE. " That is, if label per EVI is allocated, forwarding is based on MAC lookup (= like VPLS), otherwise, if label per Ethernet segment or per MAC is allocate= d, the forwarding is like in VPWS, and VLAN translation is allowed further.= Why an extra VLAN translation operation breaks? For the 2nd question, I could not find SH label in the etree-evpn draft, we= re you referring to ESI MPLS label? Thanks, Yuanlong -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, September 25, 2012 7:42 AM To: Jiangyuanlong; Giles Heron Cc: l2vpn@ietf.org Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Jiangyuanlong, Your proposal of applying vlan-tags (as done for VPLS) to E-VPN solution is broken and doesn't work properly for E-VPN for the following reasons: 1) It breaks MPLS forwarding for egress PE - E-VPN allows for pure MPLS forwarding at the egress PE 2) Even in scenarios where MAC lookup is used on egress PE, it creates unnecessary overhead that is absolutely NOT needed. E-VPN multicast packets already carries SH label (which as describe in etree-evpn draft) is also used for root/leaf indication. EVPN is the next gen solution which doesn't have the limitation of existing vpls solution. It is extreemly flexible as it allows for pure MPLS forwarding to a given AC without any MAC lookup (in either direction). It allows for asymmetric MAC lookup operation (lookup in the ingress PE but no lookup on the egress PE). Or it allows for lookup in both directions. We don't want to contamiate such solution with the kludge that we used for VPLS. Cheers, Ali On 9/21/12 7:31 PM, "Jiangyuanlong" > wrote: >Hi Giles, > >Perhaps the gauge of the consensus in the minutes was not so clear for me: >" Giles - are we agreed we want to get to one solution for VPLS >and E-VPN. > Not many people. But even fewer who want multiple. Checked to >see if > people want one solution only for E-VPN and VPLS - only a >couple of hands." >Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus >to decide which way to take. > >Thanks, >Yuanlong > >-----Original Message----- >From: Giles Heron [mailto:giles.heron@gmail.com] >Sent: Friday, September 21, 2012 9:09 PM >To: Jiangyuanlong >Cc: l2vpn@ietf.org >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >Thanks Yuanlong, > >however I must say that your memory of the IETF 84 L2VPN meeting differs >from mine (and from what is noted in the minutes). Whilst Himanshu said >that it was better to have the same solution for VPLS and E-VPN, Ali >stated that there was no benefit in the E-VPN case in using an additional >tag (such as a VLAN). No consensus was reached in the meeting. > >Giles > >On 21 Sep 2012, at 10:16, Jiangyuanlong > wrote: > >> Hi all, >> >> During the 84th IETF meeting, the group discussed the issue of E-Tree >>in E-VPN, and it was shown that a single solution was more preferred >>than two different approaches for VPLS and E-VPN. >> This I-D probes how the 2VLAN approach can be used to support E-Tree in >>E-VPN and it seems not a big issue. >> Any comments from you are greatly appreciated. >> >> Best regards, >> Yuanlong >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:= internet-drafts@ietf.org] >> Sent: Friday, September 21, 2012 4:55 PM >> To: Jiangyuanlong >> Subject: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >> >> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> has been successfully submitted by Yuanlong Jiang and posted to the >> IETF repository. >> >> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >> Revision: 00 >> Title: E-Tree Support with 2VLAN in E-VPN >> Creation date: 2012-09-21 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: >>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>.txt >> Status: >>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >> Htmlized: >>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >> >> >> Abstract: >> This document discusses how the Dual-VLAN approach as described in >> [Etree-vlan] can be used to support the transport of E-Tree service >> in E-VPN. Thus a single convergent solution is possible for both VPLS >> and E-VPN. >> >> >> >> >> The IETF Secretariat >> > --_000_CC87E3691AF4Dsajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Yuanlong,

MPLS forwarding is one of the forwarding mode in E-VPN that cannot be = compromised. I would highly suggest that you read E-VPN drat again before m= aking any suggestions. The reasons that I gave you previously regarding why= the use of vlan-tag doesn't make sense for E-VPN still holds and if needed I can go over the E-VPN solution= the next time we meet. But I won't be able to provide a tutorial over the = email. As I mentioned before the E-VPN forwarding plane already supports E-= TREE without any changes to the forwarding behavior. And changing the E-VPN forwarding behavior to do some= thing that it already supports, doesn't make any sense. But you have heard = that from multiple people already. 

Cheers,
Ali

From: Jiangyuanlong <jiangyuanlong@huawei.com>
Date: Monday, September 24, 2012 11= :43 PM
To: Cisco Employee <sajassi@cisco.com>, Giles Heron <giles.heron@gmail.com>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: RE: New Version Notificati= on for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Ali,

 

I am not sure whether "= pure MPLS forwarding at the egress PE=94 is something w= e are pursuing or something true enough, but it seems to me the forwarding of EVPN is not so different from VPLS/VPWS in the des= cription of EVPN document:

"

   Per EVI label a= ssignment requires the least number of E-VPN labels,

   but requires a = MAC lookup in addition to an MPLS lookup on an egress

   PE for forwardi= ng. On the other hand, a unique label per <ESI,

   Ethernet Tag>= ; or a unique label per MAC allows an egress PE to

   forward a packe= t that it receives from another PE, to the connected

   CE, after= looking up only the MPLS labels without having to perform a=

   MAC looku= p. This includes the capability to perform appropriate VLAN

   ID transl= ation on egress to the CE.

"

That is, if label per EVI is= allocated, forwarding is based on MAC lookup (like VPLS), otherwise, if la= bel per Ethernet segment or per MAC is allocated, the forwarding is like in= VPWS, and VLAN translation is allowed further. Why an extra VLAN translation operation breaks?=

 

For the 2nd quest= ion, I could not find SH label in the etree-evpn draft, were you referring = to ESI MPLS label?

 

Thanks,

Yuanlong

 

 

-----Original Message----- From: Ali Sajassi (sajassi) [mailto:sa= jassi@cisco.com]
Sent: Tuesday, September 25, 2012 7:42 AM
To: Jiangyuanlong; Giles Heron
Cc: l2vpn@ietf.org
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt

 

 

Jiangyuanlong,

 

 

Your proposal of applying vl= an-tags (as done for VPLS) to E-VPN solution

is broken and doesn't work p= roperly for E-VPN for the following reasons:

 

1) It breaks MPLS forwarding= for egress PE - E-VPN allows for pure MPLS

forwarding at the egress PE<= o:p>

 

2) Even in scenarios where M= AC lookup is used on egress PE, it creates

unnecessary overhead that is= absolutely NOT needed. E-VPN multicast

packets already carries SH l= abel (which as describe in etree-evpn draft)

is also used for root/leaf i= ndication.

 

 

EVPN is the next gen solutio= n which doesn't have the limitation of

existing vpls solution. It i= s extreemly flexible as it allows for pure

MPLS forwarding to a given A= C without any MAC lookup (in either

direction). It allows for as= ymmetric MAC lookup operation (lookup in the

ingress PE but no lookup on = the egress PE). Or it allows for lookup in

both directions. We don't wa= nt to contamiate such solution with the kludge

that we used for VPLS.<= /o:p>

 

Cheers,

Ali

 

 

 

On 9/21/12 7:31 PM, "Ji= angyuanlong" <jiangyuan= long@huawei.com> wrote:

 

>Hi Giles,

> =

>Perhaps the gauge of the= consensus in the minutes was not so clear for me:

>"   =       Giles - are we agreed we want to get to one = solution for VPLS

>and E-VPN.

>    =       Not many people.  But even fewer who wa= nt multiple.  Checked to

>see if=

>    =       people want one solution only for E-VPN and = VPLS - only a

>couple of hands."

>Nevertheless, E-VPN need= s an E-Tree solution and it is the WG consensus

>to decide which way to t= ake.

> =

>Thanks,

>Yuanlong

> =

>-----Original Message---= --

>From: Giles Heron [mailto:giles.heron@gmail.com]<= /o:p>

>Sent: Friday, September = 21, 2012 9:09 PM

>To: Jiangyuanlong

>Cc: l2vpn@ietf.org

>Subject: Re: New Version= Notification for

>draft-jiang-l2vpn-evpn-e= tree-2vlan-00.txt

> =

>Thanks Yuanlong,

> =

>however I must say that = your memory of the IETF 84 L2VPN meeting differs

>from mine (and from what= is noted in the minutes).  Whilst Himanshu said

>that it was better to ha= ve the same solution for VPLS and E-VPN, Ali

>stated that there was no= benefit in the E-VPN case in using an additional

>tag (such as a VLAN).&nb= sp; No consensus was reached in the meeting.

> =

>Giles<= /p>

> =

>On 21 Sep 2012, at 10:16= , Jiangyuanlong <jiangyuanlo= ng@huawei.com> wrote:

> =

>> Hi all,<= /span>

>> <= /p>

>> During the 84th IET= F meeting, the group discussed the issue of E-Tree

>>in E-VPN, and it was= shown that a single solution was more preferred

>>than two different a= pproaches for VPLS and E-VPN.

>> This I-D probes how= the 2VLAN approach can be used to support E-Tree in

>>E-VPN and it seems n= ot a big issue.

>> Any comments from y= ou are greatly appreciated.

>> <= /p>

>> Best regards,<= /o:p>

>> Yuanlong=

>> <= /p>

>> -----Original Messa= ge-----

>> From: internet-drafts@ietf.org [m= ailto:internet-drafts@ietf.org]

>> Sent: Friday, Septe= mber 21, 2012 4:55 PM

>> To: Jiangyuanlong

>> Subject: New Versio= n Notification for

>>draft-jiang-l2vpn-ev= pn-etree-2vlan-00.txt

>> <= /p>

>> <= /p>

>> A new version of I-= D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

>> has been successful= ly submitted by Yuanlong Jiang and posted to the

>> IETF repository.

>> <= /p>

>> Filename: &nbs= p;  draft-jiang-l2vpn-evpn-etree-2vlan

>> Revision: &nbs= p;   00

>> Title:  &= nbsp;          E-Tree Support = with 2VLAN in E-VPN

>> Creation date: = ;   2012-09-21

>> WG ID:  &= nbsp;           &nbs= p;   Individual Submission

>> Number of pages: 6<= o:p>

>> URL:  &nb= sp;        

>>http://ww= w.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00

>>.txt

>> Status:  =       

>>http://datatrack= er.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan

>> Htmlized: &nbs= p;    

>>http://tools.ietf.= org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00

>> <= /p>

>> <= /p>

>> Abstract:

>>   This do= cument discusses how the Dual-VLAN approach as described in

>>   [Etree-= vlan] can be used to support the transport of E-Tree service

>>   in E-VP= N. Thus a single convergent solution is possible for both VPLS

>>   and E-V= PN.

>> <= /p>

>> <= /p>

>> <= /p>

>> <= /p>

>> The IETF Secretaria= t

>> <= /p>

> =

 

--_000_CC87E3691AF4Dsajassiciscocom_-- From sajassi@cisco.com Tue Sep 25 23:14:35 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 7B41121F87F2 for ; Tue, 25 Sep 2012 23:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0si4U-Lj5t0s for ; Tue, 25 Sep 2012 23:14:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA2221F868A for ; Tue, 25 Sep 2012 23:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8994; q=dns/txt; s=iport; t=1348640074; x=1349849674; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6LVNrm/9sQyxsfOQCgBI346bW4eRqZloS8MBMIzK0l4=; b=M0GVrXZ/7psK3zTQD5Bpqtq4remUhEg1Yon5xdE78bDSDLUNRCmpP1KH nmblpeuK+FsYzReIpmCfMhU0nkAShRh/T5ypitJqxlWE/CisdSdgH3PVG BGCTIRyAd/L010YTPmjX0166fLbyGn7EuRYNLB+32at20TVxQqamy5AIt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGicYlCtJV2d/2dsb2JhbABFgm68cYEIgiABAQEEEgEnMwUFAgwGAQgRBAEBAR4JKBEUCQgCBAENBQkSB4dRAw8BCplklj0NiVSKOGIUBoVvA5QRgVWBFYoJgyGBaYJngVoJNA X-IronPort-AV: E=Sophos;i="4.80,488,1344211200"; d="scan'208";a="125381989" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2012 06:14:33 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8Q6EXP3032235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Sep 2012 06:14:33 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 26 Sep 2012 01:14:32 -0500 From: "Ali Sajassi (sajassi)" To: Jiangyuanlong , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNm64xbo0oHH521U6V/eXF9+wqyA== Date: Wed, 26 Sep 2012 06:14:31 +0000 Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E172@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.91.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19210.004 x-tm-as-result: No--72.458200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Wed, 26 Sep 2012 06:14:35 -0000 Hi Yuanlong,=20 If one understood the operation of SH filtering in E-VPN, he would have seen that it exactly covers both of these cases that are mentioned below. Also, E-VPN allows for policy-based forwarding on a per MAC basis without scale issue. As I said previously, I won't be able to provide E-VPN tutorial over the email. Cheers, Ali On 9/25/12 12:02 AM, "Jiangyuanlong" wrote: >Hi all, > >I don't think E-VPN control plane can solve all the problem of E-Tree. >For the following two scenarios data plane indication of E-Tree is needed: >1. Per EVI label is assigned, and there are multiple PEs with both Leaf >AND Root sites; >2. Per label is assigned, and there are multiple >Ethernet segments with both Leaf AND Root sites; >Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an >option, but maybe OAM is a challenge. > >Assigning label per MAC for E-Tree will not need this indication, but at >expense of scalability. > >Regards, >Yuanlong > > >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Tuesday, September 25, 2012 7:42 AM >To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > >Jim, Aldrin, Josh: > >You guys are spot on. E-VPN solution doesn't have the limitation of >data-plane forwarding that VPLS has and as such it doesn't need addition >vlan-tag to solve root/leaf indication issue as it can be supported >inherently by the solution. > >Cheers, >Ali > >On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: > >>Josh, >> >> Yes.. I think that is the reality of it.. VPLS either the LDP or BGP >>variety uses data plane learning as the mechanism to "learn".. The fact >>that we extend the L2 footprint via these "tunnels" does not change that >>fact.. SO in VPLS the only hammer you have is the data plane, so one must >>manipulate bits on the wire to infer topology ( Limited set of topology >>).. >> >>Another challenge is when roots and leafs "land" on the same PE. >> >>EVPN is intended to use contexts and associated import/export to manage >>the topology.. So here there is a set of tools to create the desired >>topologies, along with that there other mechanisms realized i.e >>active/active... >> >>Jim Uttaro >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Rogers, Josh >>Sent: Saturday, September 22, 2012 7:03 PM >>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >>I agree. >> >>Would it be safe to state that VPLS has a need for a 'etree solution', >>but >>EVPN does not, because it is inherently supported? >> >>The previously discussed effort of having a 'single etree solution' for >>both VPLS and EVPN may not really be valid due to this. >> >>In fact, I do not think it is valid to ask for a single solution, EVPN >>doesn't have a problem that needs to be fixed here, I don't believe it >>factors into this discussion. >> >>-Josh >> >> >>On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >> >>>EVPN is intended to maximize the flexibility of multiple routing >>>contexts >>>with arbitrary topologies.. As I have stated in the past, EVPN allows >>>for >>>E-Tree to be constructed in the control plane, other solutions require >>>some method to interrogate data and infer topology. IMO this is not >>>desirable. >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of >>>Rogers, Josh >>>Sent: Saturday, September 22, 2012 12:49 PM >>>To: Aldrin Isaac; Giles Heron >>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>Subject: Re: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>>So, this same sort of 'import/export' of targets is possible using >>>BGP-VPLS today, but it faces limitations outlined in >>>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>>import/export by attachment circuit, and not by PE? Meaning, AC1 one >>>PE1 >>>may import RTA, while AC2 on PE2 may import RTB? >>> >>>Its occurred to me that EVPN would be able to use other mechanisms that >>>have not yet been discussed yet due to sharing a mac table over BGP. >>> >>>Thanks for the response, >>>Josh >>> >>> >>>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >>> >>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import >>>>RTB >>>>export RTA at spokes) with filtering to enforce downstream data flow if >>>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>>> >>>> >>>> >>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>>> >>>>> Thanks Yuanlong, >>>>> >>>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>>differs from mine (and from what is noted in the minutes). Whilst >>>>>Himanshu said that it was better to have the same solution for VPLS >>>>>and >>>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>>meeting. >>>>> >>>>> Giles >>>>> >>>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>>wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> During the 84th IETF meeting, the group discussed the issue of >>>>>>E-Tree >>>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>>than two different approaches for VPLS and E-VPN. >>>>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>>>in E-VPN and it seems not a big issue. >>>>>> Any comments from you are greatly appreciated. >>>>>> >>>>>> Best regards, >>>>>> Yuanlong >>>>>> >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>>> To: Jiangyuanlong >>>>>> Subject: New Version Notification for >>>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>> >>>>>> >>>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>>> Revision: 00 >>>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>>> Creation date: 2012-09-21 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 6 >>>>>> URL: >>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vla >>>>>>n >>>>>>- >>>>>>0 >>>>>>0.txt >>>>>> Status: >>>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>> Htmlized: >>>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This document discusses how the Dual-VLAN approach as described in >>>>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>>VPLS >>>>>> and E-VPN. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use 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 dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this E-mail in >>>error, please notify the sender immediately and permanently delete the >>>original and any copy of this E-mail and any printout. >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use 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 dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > From sajassi@cisco.com Tue Sep 25 23:28: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 813E321F853E for ; Tue, 25 Sep 2012 23:28:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4wnQnt2D2Eo for ; Tue, 25 Sep 2012 23:28:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 68EC421F846D for ; Tue, 25 Sep 2012 23:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9574; q=dns/txt; s=iport; t=1348640907; x=1349850507; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1VlOownNn4vV6xZSosy8sLuCo6bNKiYZpfF0lVprt8M=; b=WKpyeg60mZiVPhefVKICSXD665B0/CoSpHg/HyzaoY0SlSkC8piaUa/V IquNBXMjbRjcVgl3iqbLjcdUgbzmWsW7fapJYgljtJzPXLo6kxHZCrXJ/ pZZkcWsmjg0XEkF3TFlLYKIjSi9DP1FmcLC0mObsrmaNK2/oFhdKfxhQn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAH+fYlCtJXG//2dsb2JhbABFgm68coEIgiABAQEEEgEnMwUFAgwGAQgRBAEBAR4JKBEUCQgCBAENBQkSB4dRAw8BCplmlj8NiVSKOGIUBoVvA5QRgVWBFYoJgyGBaYJngVoJNA X-IronPort-AV: E=Sophos;i="4.80,488,1344211200"; d="scan'208";a="125377197" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2012 06:28:26 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8Q6SQIf006354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Sep 2012 06:28:26 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 26 Sep 2012 01:28:26 -0500 From: "Ali Sajassi (sajassi)" To: Alexander Vainshtein , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNm7AioQ4WAgO/Xk68/mrrDBiV/g== Date: Wed, 26 Sep 2012 06:28:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.91.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19210.004 x-tm-as-result: No--75.667100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <73446E056E90CE48918867C4EEC58ACC@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Jiangyuanlong 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, 26 Sep 2012 06:28:28 -0000 Hi Alex, E-VPN operation is very similar to IP-VPN and it can basically support the modes that are in IP-VPN; however, for E-TREE we don't need to use such modes and we don't need to assign label per prefix (MAC in here) since E-VPN uses the notion of a label per site (per ESI) for its SH filtering. And for E-TREE we simply color the site (ESI) with two labels (one to indicate root and another to indicate leaf) and we basically use the same SH filtering logic here. Cheers, Ali On 9/25/12 1:08 AM, "Alexander Vainshtein" wrote: >Ali, >Sorry for a naive question - but your response seems to imply that E-VPN >uses a separate application label per DMAC per VSI per remote PE (similar >to the what BGP/MPLS VPN can do in one of its flavors where application >label is allocated and distributed for each locally reachable prefix). > >This would be indeed very different from VPLS where (regardless of the >label distribution method) uses one application label per VSI per remote >peer. > >If this is the case, you indeed need any tagging to support E-Tree. >But you can easily run into scalability problems (what if you need more >than 1M of MACs?) not to mention OAM problems. > > > >________________________________________ >From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Ali >Sajassi (sajassi) [sajassi@cisco.com] >Sent: Tuesday, September 25, 2012 1:41 AM >To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >Jim, Aldrin, Josh: > >You guys are spot on. E-VPN solution doesn't have the limitation of >data-plane forwarding that VPLS has and as such it doesn't need addition >vlan-tag to solve root/leaf indication issue as it can be supported >inherently by the solution. > >Cheers, >Ali > >On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: > >>Josh, >> >> Yes.. I think that is the reality of it.. VPLS either the LDP or >>BGP >>variety uses data plane learning as the mechanism to "learn".. The fact >>that we extend the L2 footprint via these "tunnels" does not change that >>fact.. SO in VPLS the only hammer you have is the data plane, so one must >>manipulate bits on the wire to infer topology ( Limited set of topology >>).. >> >>Another challenge is when roots and leafs "land" on the same PE. >> >>EVPN is intended to use contexts and associated import/export to manage >>the topology.. So here there is a set of tools to create the desired >>topologies, along with that there other mechanisms realized i.e >>active/active... >> >>Jim Uttaro >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Rogers, Josh >>Sent: Saturday, September 22, 2012 7:03 PM >>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >>I agree. >> >>Would it be safe to state that VPLS has a need for a 'etree solution', >>but >>EVPN does not, because it is inherently supported? >> >>The previously discussed effort of having a 'single etree solution' for >>both VPLS and EVPN may not really be valid due to this. >> >>In fact, I do not think it is valid to ask for a single solution, EVPN >>doesn't have a problem that needs to be fixed here, I don't believe it >>factors into this discussion. >> >>-Josh >> >> >>On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >> >>>EVPN is intended to maximize the flexibility of multiple routing >>>contexts >>>with arbitrary topologies.. As I have stated in the past, EVPN allows >>>for >>>E-Tree to be constructed in the control plane, other solutions require >>>some method to interrogate data and infer topology. IMO this is not >>>desirable. >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of >>>Rogers, Josh >>>Sent: Saturday, September 22, 2012 12:49 PM >>>To: Aldrin Isaac; Giles Heron >>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>Subject: Re: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>>So, this same sort of 'import/export' of targets is possible using >>>BGP-VPLS today, but it faces limitations outlined in >>>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>>import/export by attachment circuit, and not by PE? Meaning, AC1 one >>>PE1 >>>may import RTA, while AC2 on PE2 may import RTB? >>> >>>Its occurred to me that EVPN would be able to use other mechanisms that >>>have not yet been discussed yet due to sharing a mac table over BGP. >>> >>>Thanks for the response, >>>Josh >>> >>> >>>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >>> >>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import >>>>RTB >>>>export RTA at spokes) with filtering to enforce downstream data flow if >>>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>>> >>>> >>>> >>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>>> >>>>> Thanks Yuanlong, >>>>> >>>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>>differs from mine (and from what is noted in the minutes). Whilst >>>>>Himanshu said that it was better to have the same solution for VPLS >>>>>and >>>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>>meeting. >>>>> >>>>> Giles >>>>> >>>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>>wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> During the 84th IETF meeting, the group discussed the issue of >>>>>>E-Tree >>>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>>than two different approaches for VPLS and E-VPN. >>>>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>>>in E-VPN and it seems not a big issue. >>>>>> Any comments from you are greatly appreciated. >>>>>> >>>>>> Best regards, >>>>>> Yuanlong >>>>>> >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>>> To: Jiangyuanlong >>>>>> Subject: New Version Notification for >>>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>> >>>>>> >>>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>>> Revision: 00 >>>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>>> Creation date: 2012-09-21 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 6 >>>>>> URL: >>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vla >>>>>>n >>>>>>- >>>>>>0 >>>>>>0.txt >>>>>> Status: >>>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>> Htmlized: >>>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This document discusses how the Dual-VLAN approach as described in >>>>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>>VPLS >>>>>> and E-VPN. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use 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 dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this E-mail in >>>error, please notify the sender immediately and permanently delete the >>>original and any copy of this E-mail and any printout. >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use 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 dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > >This e-mail message is intended for the recipient only and contains >information which is CONFIDENTIAL and which may be proprietary to ECI >Telecom. If you have received this transmission in error, please inform >us by e-mail, phone or fax, and then delete the original and all copies >thereof. > From jiangyuanlong@huawei.com Wed Sep 26 02:32: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 3A70C21F87CC for ; Wed, 26 Sep 2012 02:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3JZO+hzt+p8 for ; Wed, 26 Sep 2012 02:32:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 285D721F87C4 for ; Wed, 26 Sep 2012 02:32:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALB24035; Wed, 26 Sep 2012 09:32:35 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Sep 2012 10:31:26 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Sep 2012 10:32:16 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Wed, 26 Sep 2012 17:31:00 +0800 From: Jiangyuanlong To: "Ali Sajassi (sajassi)" , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmq4pFVANLlv0RU6/0DirrqUYkJeanNRAgAEEFYCAALLAoA== Date: Wed, 26 Sep 2012 09:31:00 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E3C4@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E172@szxeml546-mbs.china.huawei.com> 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.95] 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, 26 Sep 2012 09:32:38 -0000 Ali, On the one hand, you said E-VPN solution doesn't have the limitation of dat= a-plane forwarding and inherently support E-Tree, on the other hand, you ag= reed that 2 labels are introduced specially for E-Tree for these two cases.= Furthermore, forwarding behaviors for these two labels are different (for = root label, split horizon + forward to both root & leaf ports; for leaf lab= el, split horizon + forward only to leaf ports) from the E-VPN itself (spli= t horizon only). But my main concern is whether OAM is needed for E-VPN, if yes, how it can = be implemented in practical? Regards, Yuanlong -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]=20 Sent: Wednesday, September 26, 2012 2:15 PM To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron Cc: l2vpn@ietf.org Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Hi Yuanlong,=20 If one understood the operation of SH filtering in E-VPN, he would have seen that it exactly covers both of these cases that are mentioned below. Also, E-VPN allows for policy-based forwarding on a per MAC basis without scale issue. As I said previously, I won't be able to provide E-VPN tutorial over the email. Cheers, Ali On 9/25/12 12:02 AM, "Jiangyuanlong" wrote: >Hi all, > >I don't think E-VPN control plane can solve all the problem of E-Tree. >For the following two scenarios data plane indication of E-Tree is needed: >1. Per EVI label is assigned, and there are multiple PEs with both Leaf >AND Root sites; >2. Per label is assigned, and there are multiple >Ethernet segments with both Leaf AND Root sites; >Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an >option, but maybe OAM is a challenge. > >Assigning label per MAC for E-Tree will not need this indication, but at >expense of scalability. > >Regards, >Yuanlong > > >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Tuesday, September 25, 2012 7:42 AM >To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > >Jim, Aldrin, Josh: > >You guys are spot on. E-VPN solution doesn't have the limitation of >data-plane forwarding that VPLS has and as such it doesn't need addition >vlan-tag to solve root/leaf indication issue as it can be supported >inherently by the solution. > >Cheers, >Ali > >On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: > >>Josh, >> >> Yes.. I think that is the reality of it.. VPLS either the LDP or BGP >>variety uses data plane learning as the mechanism to "learn".. The fact >>that we extend the L2 footprint via these "tunnels" does not change that >>fact.. SO in VPLS the only hammer you have is the data plane, so one must >>manipulate bits on the wire to infer topology ( Limited set of topology >>).. >> >>Another challenge is when roots and leafs "land" on the same PE. >> >>EVPN is intended to use contexts and associated import/export to manage >>the topology.. So here there is a set of tools to create the desired >>topologies, along with that there other mechanisms realized i.e >>active/active... >> >>Jim Uttaro >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Rogers, Josh >>Sent: Saturday, September 22, 2012 7:03 PM >>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >>I agree. >> >>Would it be safe to state that VPLS has a need for a 'etree solution', >>but >>EVPN does not, because it is inherently supported? >> >>The previously discussed effort of having a 'single etree solution' for >>both VPLS and EVPN may not really be valid due to this. >> >>In fact, I do not think it is valid to ask for a single solution, EVPN >>doesn't have a problem that needs to be fixed here, I don't believe it >>factors into this discussion. >> >>-Josh >> >> >>On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >> >>>EVPN is intended to maximize the flexibility of multiple routing >>>contexts >>>with arbitrary topologies.. As I have stated in the past, EVPN allows >>>for >>>E-Tree to be constructed in the control plane, other solutions require >>>some method to interrogate data and infer topology. IMO this is not >>>desirable. >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of >>>Rogers, Josh >>>Sent: Saturday, September 22, 2012 12:49 PM >>>To: Aldrin Isaac; Giles Heron >>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>Subject: Re: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>>So, this same sort of 'import/export' of targets is possible using >>>BGP-VPLS today, but it faces limitations outlined in >>>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>>import/export by attachment circuit, and not by PE? Meaning, AC1 one >>>PE1 >>>may import RTA, while AC2 on PE2 may import RTB? >>> >>>Its occurred to me that EVPN would be able to use other mechanisms that >>>have not yet been discussed yet due to sharing a mac table over BGP. >>> >>>Thanks for the response, >>>Josh >>> >>> >>>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >>> >>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import >>>>RTB >>>>export RTA at spokes) with filtering to enforce downstream data flow if >>>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>>> >>>> >>>> >>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>>> >>>>> Thanks Yuanlong, >>>>> >>>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>>differs from mine (and from what is noted in the minutes). Whilst >>>>>Himanshu said that it was better to have the same solution for VPLS >>>>>and >>>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>>meeting. >>>>> >>>>> Giles >>>>> >>>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>>wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> During the 84th IETF meeting, the group discussed the issue of >>>>>>E-Tree >>>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>>than two different approaches for VPLS and E-VPN. >>>>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>>>in E-VPN and it seems not a big issue. >>>>>> Any comments from you are greatly appreciated. >>>>>> >>>>>> Best regards, >>>>>> Yuanlong >>>>>> >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>>> To: Jiangyuanlong >>>>>> Subject: New Version Notification for >>>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>> >>>>>> >>>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>>> Revision: 00 >>>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>>> Creation date: 2012-09-21 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 6 >>>>>> URL: >>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vla >>>>>>n >>>>>>- >>>>>>0 >>>>>>0.txt >>>>>> Status: >>>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>> Htmlized: >>>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This document discusses how the Dual-VLAN approach as described in >>>>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>>VPLS >>>>>> and E-VPN. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use 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 dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this E-mail in >>>error, please notify the sender immediately and permanently delete the >>>original and any copy of this E-mail and any printout. >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use 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 dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > From Alexander.Vainshtein@ecitele.com Wed Sep 26 07:47: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 0C36421F86E5 for ; Wed, 26 Sep 2012 07:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.559 X-Spam-Level: X-Spam-Status: No, score=-4.559 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNOelBdNGVqD for ; Wed, 26 Sep 2012 07:47:27 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 59C0421F86D8 for ; Wed, 26 Sep 2012 07:47:26 -0700 (PDT) Received: from [85.158.138.51:35168] by server-15.bemta-3.messagelabs.com id A4/81-18313-D7513605; Wed, 26 Sep 2012 14:47:25 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1348670844!32024762!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.6.1.3; banners=-,-,- Received: (qmail 29505 invoked from network); 26 Sep 2012 14:47:24 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-8.tower-174.messagelabs.com with SMTP; 26 Sep 2012 14:47:24 -0000 X-AuditID: 93eaf2e7-b7fcf6d00000191a-00-5063103e27a8 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 70.6B.06426.E3013605; Wed, 26 Sep 2012 16:25:02 +0200 (IST) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 26 Sep 2012 16:45:12 +0200 Received: from ILPTWPVEXMB03.ecitele.com ([fe80::91b4:8f74:ce44:f190]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.01.0379.000; Wed, 26 Sep 2012 16:45:12 +0200 From: Alexander Vainshtein To: Jiangyuanlong , "Ali Sajassi (sajassi)" , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmq4kRS8tXuhBSbG0BUc+K0zeA5eagIKAgAGE/ICAADblAIAAdvHB Date: Wed, 26 Sep 2012 14:45:11 +0000 Message-ID: References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E172@szxeml546-mbs.china.huawei.com> , <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E3C4@szxeml546-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E3C4@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA1VTf2wTVRzP613b69iR47ax50LCeSIxSOeaYXJGCsQoKYnJqoILRDJvd2/t 6fVa747BFhYLjBjxxyAjkXUQNjcg/EimQ93IjI46klqDGMAYkZJp0bGSLRPCrwGOdz0Y85+X z/t+P5/v533f+z6KYLvcZZSimUjXRJV3FZCtuWs570lGCla0bn1OaBvYTgp/n9oDhF8nPnAJ +7rukcJIYtApZG8m3cL46W3kCndgtGUvCOy++6UzcCKRcQeah8acge7uO47A0WM5MuhaFwdL RU2LmqKJOBkZkp8P6kq9KDXwnCL7eR/PxVRRQhGkmX5ejMWQJvPLCpbioKJxSJOisqKF/Pyq N6q8gvD8C14fv2zhU77KFwtWhxWDQ96IqKhcBBmGGEIcjljtaDKSubqozplhxOlvtxLh4T4Y 27NmU9vYWSIO/nhlB/BQkFkCT6RyLhvPhb9c6sG4gGKZ7wH86nDcbW/6Aeyc/JOwWCxzCsB4 +3ILuxg/7D2aySuKmTsA7ruSyZcimKdhc+93wMJFzBqYOXzfbeFi5k04kbYKURivhKlx1QqT mP7h1gFghWkmCCdGHvoOAZj9/Yu81IOlP49l8hjgk95KH3PYVqXwwuX9DrsDBnZ/e4awcQkc zf7ntPF8ePzrrNPmL4YdA9ceHvNZeLDzap5PM3Pgj22XSbtHL0yndjh2ApiYYZGYIU/MkCdm yDsAeQSUKGrMrI2EKnzlSFJMpKJyKRrpBfZwjfSDyf0LkoChAF9Ic/+KQdYp1hsNkSR4gnLw JfRPrBRkZ9dG5YawaIRr9A0qMpIAUgRfTP/zTm2QpWWxoRHp0UcpAd/gLqJslhS13t2sqayo +N+GL6UPxaurWCaEB/BdhGJIfySdR1E8pJuKseMcHYXQpjpFNR+nHZTHci7EzmstDm3ExIih hOx8GlRS7bu7hwH1VwavLKlFNVRWSn9mURmLGt6gTVez/tb7U1NTOVCKOy+iN1qsQjyq0/Vy 2MqBrQ70Wk0a+LtMp8ri4HTT2vOpRVOf3zjwQ+Pk3J5Q5WCaLX85ld0yGDx0ss6kq/uGxl9a vVhLDXzqO7szvKLp4MezX3/myZaut7gL7b/1nyuq8p5vvK6uW3B75ebOc99MdMyftb751T7P e9XNu9DCmo3b77bcihg1x1eduVjvOTKS7rn+2sVOmfxoSE5+IgyPrudJIyz6FhG6IT4AHPn1 aTYEAAA= 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, 26 Sep 2012 14:47:28 -0000 Yuanlong, Ali, and all, I think that we have really 3 aspects of E-Tree that should be explicitly pr= esented for each solution approach: 1. Change of the PE Type: - Root-only to Mixed and vice versa - Leaf-only to Mixed and vice versa - Root-only to Leaf-only and vice versa 2. OAM - how it is supposed to work and how the defects it detects are handl= ed. This becomes non-trivial in the 2PW solution and its analogs if one of t= he two PWsfails IMHO 3. Interworking with Ethernet-only E-Tree. My 2c, Sasha ________________________________________ From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Jiangyuan= long [jiangyuanlong@huawei.com] Sent: Wednesday, September 26, 2012 11:31 AM To: Ali Sajassi (sajassi); UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Gile= s Heron Cc: l2vpn@ietf.org Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree= -2vlan-00.txt Ali, On the one hand, you said E-VPN solution doesn't have the limitation of data= -plane forwarding and inherently support E-Tree, on the other hand, you agre= ed that 2 labels are introduced specially for E-Tree for these two cases. Fu= rthermore, forwarding behaviors for these two labels are different (for root= label, split horizon + forward to both root & leaf ports; for leaf label, s= plit horizon + forward only to leaf ports) from the E-VPN itself (split hori= zon only). But my main concern is whether OAM is needed for E-VPN, if yes, how it can b= e implemented in practical? Regards, Yuanlong -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Wednesday, September 26, 2012 2:15 PM To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron Cc: l2vpn@ietf.org Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan= -00.txt Hi Yuanlong, If one understood the operation of SH filtering in E-VPN, he would have seen that it exactly covers both of these cases that are mentioned below. Also, E-VPN allows for policy-based forwarding on a per MAC basis without scale issue. As I said previously, I won't be able to provide E-VPN tutorial over the email. Cheers, Ali On 9/25/12 12:02 AM, "Jiangyuanlong" wrote: >Hi all, > >I don't think E-VPN control plane can solve all the problem of E-Tree. >For the following two scenarios data plane indication of E-Tree is needed: >1. Per EVI label is assigned, and there are multiple PEs with both Leaf >AND Root sites; >2. Per label is assigned, and there are multiple >Ethernet segments with both Leaf AND Root sites; >Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an >option, but maybe OAM is a challenge. > >Assigning label per MAC for E-Tree will not need this indication, but at >expense of scalability. > >Regards, >Yuanlong > > >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Tuesday, September 25, 2012 7:42 AM >To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron >Cc: l2vpn@ietf.org; Jiangyuanlong >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > >Jim, Aldrin, Josh: > >You guys are spot on. E-VPN solution doesn't have the limitation of >data-plane forwarding that VPLS has and as such it doesn't need addition >vlan-tag to solve root/leaf indication issue as it can be supported >inherently by the solution. > >Cheers, >Ali > >On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: > >>Josh, >> >> Yes.. I think that is the reality of it.. VPLS either the LDP or BGP >>variety uses data plane learning as the mechanism to "learn".. The fact >>that we extend the L2 footprint via these "tunnels" does not change that >>fact.. SO in VPLS the only hammer you have is the data plane, so one must >>manipulate bits on the wire to infer topology ( Limited set of topology >>).. >> >>Another challenge is when roots and leafs "land" on the same PE. >> >>EVPN is intended to use contexts and associated import/export to manage >>the topology.. So here there is a set of tools to create the desired >>topologies, along with that there other mechanisms realized i.e >>active/active... >> >>Jim Uttaro >> >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >>Rogers, Josh >>Sent: Saturday, September 22, 2012 7:03 PM >>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >>I agree. >> >>Would it be safe to state that VPLS has a need for a 'etree solution', >>but >>EVPN does not, because it is inherently supported? >> >>The previously discussed effort of having a 'single etree solution' for >>both VPLS and EVPN may not really be valid due to this. >> >>In fact, I do not think it is valid to ask for a single solution, EVPN >>doesn't have a problem that needs to be fixed here, I don't believe it >>factors into this discussion. >> >>-Josh >> >> >>On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >> >>>EVPN is intended to maximize the flexibility of multiple routing >>>contexts >>>with arbitrary topologies.. As I have stated in the past, EVPN allows >>>for >>>E-Tree to be constructed in the control plane, other solutions require >>>some method to interrogate data and infer topology. IMO this is not >>>desirable. >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of >>>Rogers, Josh >>>Sent: Saturday, September 22, 2012 12:49 PM >>>To: Aldrin Isaac; Giles Heron >>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>Subject: Re: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>>So, this same sort of 'import/export' of targets is possible using >>>BGP-VPLS today, but it faces limitations outlined in >>>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>>import/export by attachment circuit, and not by PE? Meaning, AC1 one >>>PE1 >>>may import RTA, while AC2 on PE2 may import RTB? >>> >>>Its occurred to me that EVPN would be able to use other mechanisms that >>>have not yet been discussed yet due to sharing a mac table over BGP. >>> >>>Thanks for the response, >>>Josh >>> >>> >>>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >>> >>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as >>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import >>>>RTB >>>>export RTA at spokes) with filtering to enforce downstream data flow if >>>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>>> >>>> >>>> >>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>>> >>>>> Thanks Yuanlong, >>>>> >>>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>>differs from mine (and from what is noted in the minutes). Whilst >>>>>Himanshu said that it was better to have the same solution for VPLS >>>>>and >>>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using >>>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>>meeting. >>>>> >>>>> Giles >>>>> >>>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>>wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> During the 84th IETF meeting, the group discussed the issue of >>>>>>E-Tree >>>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>>than two different approaches for VPLS and E-VPN. >>>>>> This I-D probes how the 2VLAN approach can be used to support E-Tree >>>>>>in E-VPN and it seems not a big issue. >>>>>> Any comments from you are greatly appreciated. >>>>>> >>>>>> Best regards, >>>>>> Yuanlong >>>>>> >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>>> To: Jiangyuanlong >>>>>> Subject: New Version Notification for >>>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>> >>>>>> >>>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>>> Revision: 00 >>>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>>> Creation date: 2012-09-21 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 6 >>>>>> URL: >>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vla >>>>>>n >>>>>>- >>>>>>0 >>>>>>0.txt >>>>>> Status: >>>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>> Htmlized: >>>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This document discusses how the Dual-VLAN approach as described in >>>>>> [Etree-vlan] can be used to support the transport of E-Tree service >>>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>>VPLS >>>>>> and E-VPN. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>> >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use 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 dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this E-mail in >>>error, please notify the sender immediately and permanently delete the >>>original and any copy of this E-mail and any printout. >> >> >>This E-mail and any of its attachments may contain Time Warner Cable >>proprietary information, which is privileged, confidential, or subject to >>copyright belonging to Time Warner Cable. This E-mail is intended solely >>for the use 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 dissemination, distribution, copying, or action taken in >>relation to the contents of and attachments to this E-mail is strictly >>prohibited and may be unlawful. If you have received this E-mail in >>error, please notify the sender immediately and permanently delete the >>original and any copy of this E-mail and any printout. > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From sajassi@cisco.com Thu Sep 27 11:39:57 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 647C621F865F for ; Thu, 27 Sep 2012 11:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+pQ4BBQdD6f for ; Thu, 27 Sep 2012 11:39:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EF1CC21F8658 for ; Thu, 27 Sep 2012 11:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11644; q=dns/txt; s=iport; t=1348771196; x=1349980796; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CkRP0IsWoyI/Hly3TyQyVNM9MeqK08qotxRa2ftf9Tg=; b=IA8aXU4uqymMRbFEWFY9eeCSQ8xVCrDdgTXDGToIvf+Kt1jvJVPt9vLf jmnRyv2YUgEC1ADJN6/za+l5Idio35d6Fr5mFkRaK7CqXWxMS2QDPCpgB SwLQ+U+Vts0uo+kK2PWYQU6DQNmzM4SCj3Ad6oWs3y56PDaL4pVG6+dWr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPibZFCtJV2a/2dsb2JhbABFgm67G4EIgiABAQEEEgEnMwUFAgwGAQgRBAEBAR4JKBEUCQgCBAENBQkSB4dRAw8BCphtlisNiVSKNmIUBoYDA5QUgVWBFYoLgyKBaYJngVoJNA X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="125844863" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 27 Sep 2012 18:39:55 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8RIdt6D012601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Sep 2012 18:39:55 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Thu, 27 Sep 2012 13:39:53 -0500 From: "Ali Sajassi (sajassi)" To: Jiangyuanlong , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNm64xbo0oHH521U6V/eXF9+wqyJecr7wAgAG2VgA= Date: Thu, 27 Sep 2012 18:39:53 +0000 Message-ID: In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E3C4@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.128.2.115] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19214.004 x-tm-as-result: No--69.000100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Thu, 27 Sep 2012 18:39:57 -0000 Sigh!=20 When split-horizon label is used in E-VPN, the stack consists of three labels (tunnel label,vpn label, and SH label). For E-TREE application, the same three labels are used and the SH label is used for SH filtering and/or root/leaf filtering. In E-VPN, the SH label is used for filtering of packets on the egress interface of the egress PE based on the site of origin. In E-TREE application, we use SH label for exactly the same purpose - filtering on the egress interface of the egress PE based on the site of origin (that can also represent leaf/root). That is why I have been saying in every email on this thread that the forwarding behavior of the E-VPN remains unchanged and that's why it doesn't make sense to add vlan-tag kluge (and as the result change the forwarding behavior) for something that is already supported. Regarding OAM aspects, we have always treated OAM work independently and we don't want to tie it with a single application of E-VPN. E-VPN has many applications such as VPLS, VPWS, E-TREE, DCI, DCN/cloud and the OAM MUST apply to all of them. We have started on OAM work for E-VPN and one draft was published before last IETF meeting and more will be coming; however, E-VPN OAM work will be done independent. Cheers, Ali =20 =20 On 9/26/12 2:31 AM, "Jiangyuanlong" wrote: >Ali, > >On the one hand, you said E-VPN solution doesn't have the limitation of >data-plane forwarding and inherently support E-Tree, on the other hand, >you agreed that 2 labels are introduced specially for E-Tree for these >two cases. Furthermore, forwarding behaviors for these two labels are >different (for root label, split horizon + forward to both root & leaf >ports; for leaf label, split horizon + forward only to leaf ports) from >the E-VPN itself (split horizon only). >But my main concern is whether OAM is needed for E-VPN, if yes, how it >can be implemented in practical? > >Regards, >Yuanlong > > > >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Wednesday, September 26, 2012 2:15 PM >To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles >Heron >Cc: l2vpn@ietf.org >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > > >Hi Yuanlong,=20 > >If one understood the operation of SH filtering in E-VPN, he would have >seen that it exactly covers both of these cases that are mentioned below. > >Also, E-VPN allows for policy-based forwarding on a per MAC basis without >scale issue. As I said previously, I won't be able to provide E-VPN >tutorial over the email. > >Cheers, >Ali > >On 9/25/12 12:02 AM, "Jiangyuanlong" wrote: > >>Hi all, >> >>I don't think E-VPN control plane can solve all the problem of E-Tree. >>For the following two scenarios data plane indication of E-Tree is >>needed: >>1. Per EVI label is assigned, and there are multiple PEs with both Leaf >>AND Root sites; >>2. Per label is assigned, and there are multiple >>Ethernet segments with both Leaf AND Root sites; >>Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an >>option, but maybe OAM is a challenge. >> >>Assigning label per MAC for E-Tree will not need this indication, but at >>expense of scalability. >> >>Regards, >>Yuanlong >> >> >>-----Original Message----- >>From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>Sent: Tuesday, September 25, 2012 7:42 AM >>To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >> >>Jim, Aldrin, Josh: >> >>You guys are spot on. E-VPN solution doesn't have the limitation of >>data-plane forwarding that VPLS has and as such it doesn't need addition >>vlan-tag to solve root/leaf indication issue as it can be supported >>inherently by the solution. >> >>Cheers, >>Ali >> >>On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: >> >>>Josh, >>> >>> Yes.. I think that is the reality of it.. VPLS either the LDP or BGP >>>variety uses data plane learning as the mechanism to "learn".. The fact >>>that we extend the L2 footprint via these "tunnels" does not change that >>>fact.. SO in VPLS the only hammer you have is the data plane, so one >>>must >>>manipulate bits on the wire to infer topology ( Limited set of topology >>>).. >>> >>>Another challenge is when roots and leafs "land" on the same PE. >>> >>>EVPN is intended to use contexts and associated import/export to manage >>>the topology.. So here there is a set of tools to create the desired >>>topologies, along with that there other mechanisms realized i.e >>>active/active... >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of >>>Rogers, Josh >>>Sent: Saturday, September 22, 2012 7:03 PM >>>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>Subject: Re: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>>I agree. >>> >>>Would it be safe to state that VPLS has a need for a 'etree solution', >>>but >>>EVPN does not, because it is inherently supported? >>> >>>The previously discussed effort of having a 'single etree solution' for >>>both VPLS and EVPN may not really be valid due to this. >>> >>>In fact, I do not think it is valid to ask for a single solution, EVPN >>>doesn't have a problem that needs to be fixed here, I don't believe it >>>factors into this discussion. >>> >>>-Josh >>> >>> >>>On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >>> >>>>EVPN is intended to maximize the flexibility of multiple routing >>>>contexts >>>>with arbitrary topologies.. As I have stated in the past, EVPN allows >>>>for >>>>E-Tree to be constructed in the control plane, other solutions require >>>>some method to interrogate data and infer topology. IMO this is not >>>>desirable. >>>> >>>>Jim Uttaro >>>> >>>>-----Original Message----- >>>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>>Of >>>>Rogers, Josh >>>>Sent: Saturday, September 22, 2012 12:49 PM >>>>To: Aldrin Isaac; Giles Heron >>>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>>Subject: Re: New Version Notification for >>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> >>>>So, this same sort of 'import/export' of targets is possible using >>>>BGP-VPLS today, but it faces limitations outlined in >>>>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>>>import/export by attachment circuit, and not by PE? Meaning, AC1 one >>>>PE1 >>>>may import RTA, while AC2 on PE2 may import RTB? >>>> >>>>Its occurred to me that EVPN would be able to use other mechanisms that >>>>have not yet been discussed yet due to sharing a mac table over BGP. >>>> >>>>Thanks for the response, >>>>Josh >>>> >>>> >>>>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >>>> >>>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like >>>>>as >>>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import >>>>>RTB >>>>>export RTA at spokes) with filtering to enforce downstream data flow >>>>>if >>>>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>>>> >>>>> >>>>> >>>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>>>> >>>>>> Thanks Yuanlong, >>>>>> >>>>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>>>differs from mine (and from what is noted in the minutes). Whilst >>>>>>Himanshu said that it was better to have the same solution for VPLS >>>>>>and >>>>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in >>>>>>using >>>>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>>>meeting. >>>>>> >>>>>> Giles >>>>>> >>>>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>>>wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> During the 84th IETF meeting, the group discussed the issue of >>>>>>>E-Tree >>>>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>>>than two different approaches for VPLS and E-VPN. >>>>>>> This I-D probes how the 2VLAN approach can be used to support >>>>>>>E-Tree >>>>>>>in E-VPN and it seems not a big issue. >>>>>>> Any comments from you are greatly appreciated. >>>>>>> >>>>>>> Best regards, >>>>>>> Yuanlong >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>>>> To: Jiangyuanlong >>>>>>> Subject: New Version Notification for >>>>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>>>> Revision: 00 >>>>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>>>> Creation date: 2012-09-21 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 6 >>>>>>> URL: >>>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vl >>>>>>>a >>>>>>>n >>>>>>>- >>>>>>>0 >>>>>>>0.txt >>>>>>> Status: >>>>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>>> Htmlized: >>>>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> This document discusses how the Dual-VLAN approach as described in >>>>>>> [Etree-vlan] can be used to support the transport of E-Tree >>>>>>>service >>>>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>>>VPLS >>>>>>> and E-VPN. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>> >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use 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 dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this E-mail in >>>>error, please notify the sender immediately and permanently delete the >>>>original and any copy of this E-mail and any printout. >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use 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 dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this E-mail in >>>error, please notify the sender immediately and permanently delete the >>>original and any copy of this E-mail and any printout. >> > From sajassi@cisco.com Thu Sep 27 11:45:55 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 7C39C21F86A2 for ; Thu, 27 Sep 2012 11:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5GHc8c-zE7z for ; Thu, 27 Sep 2012 11:45:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABED21F8698 for ; Thu, 27 Sep 2012 11:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11982; q=dns/txt; s=iport; t=1348771554; x=1349981154; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hkfwxgvOYMzLdrHTp46JZTgRLXZSro2iLQiZHwFmWmo=; b=VBnfxlu/WPCso41Jg2fIjtNMHFeJ/rLK3x+djBsgo6mUmtYpuKMhJ8T9 KUeCy7yURXxqwIG6x94diAqptFzdRkWmCczA/RP5j5HnoTcwq4iI/reCm XR+5Op+amD00iMzxk4juI7cJ3mfRDvoCg4qtaZXDsoPdJuS28+j9pNvt5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABKeZFCtJV2Z/2dsb2JhbABFgm67HIEIgiABAQEEEgEnMwUFAgwGAQgRBAEBAR4JKBEUCQgCBAENBQkSB4dRAw8BCphyli4NiVSKNmIUBoYDA5QUgVWBFYoLgyKBaYJngVoJNA X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="126066147" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 27 Sep 2012 18:45:53 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8RIjq7B013728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Sep 2012 18:45:53 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 27 Sep 2012 13:45:52 -0500 From: "Ali Sajassi (sajassi)" To: Alexander Vainshtein , Jiangyuanlong , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNnOBR9sc2i81O+0epLnx+Dd1A3Q== Date: Thu, 27 Sep 2012 18:45:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.128.2.115] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19214.004 x-tm-as-result: No--74.256400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0921DD14F780734CA2C39A90B3587D8F@cisco.com> 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: Thu, 27 Sep 2012 18:45:55 -0000 Sasha, There is no notion of PWs E-VPN. E-VPN operation is analogous to IP-VPN. Regarding the OAM aspects, the work has already started and it will be covered separately. Since E-VPN covers many applications such as VPLS, VPWS, E-TREE/VPMS, DCI, DCN/cloud, its corresponding OAM MUST cover all these applications well. Cheers, Ali On 9/26/12 7:45 AM, "Alexander Vainshtein" wrote: >Yuanlong, Ali, and all, > >I think that we have really 3 aspects of E-Tree that should be explicitly >presented for each solution approach: > >1. Change of the PE Type: > - Root-only to Mixed and vice versa > - Leaf-only to Mixed and vice versa > - Root-only to Leaf-only and vice versa >2. OAM - how it is supposed to work and how the defects it detects are >handled. > This becomes non-trivial in the 2PW solution and its analogs if one >of the two PWsfails IMHO >3. Interworking with Ethernet-only E-Tree. > >My 2c, > Sasha > > >________________________________________ >From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of >Jiangyuanlong [jiangyuanlong@huawei.com] >Sent: Wednesday, September 26, 2012 11:31 AM >To: Ali Sajassi (sajassi); UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; >Giles Heron >Cc: l2vpn@ietf.org >Subject: RE: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >Ali, > >On the one hand, you said E-VPN solution doesn't have the limitation of >data-plane forwarding and inherently support E-Tree, on the other hand, >you agreed that 2 labels are introduced specially for E-Tree for these >two cases. Furthermore, forwarding behaviors for these two labels are >different (for root label, split horizon + forward to both root & leaf >ports; for leaf label, split horizon + forward only to leaf ports) from >the E-VPN itself (split horizon only). >But my main concern is whether OAM is needed for E-VPN, if yes, how it >can be implemented in practical? > >Regards, >Yuanlong > > > >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Wednesday, September 26, 2012 2:15 PM >To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles >Heron >Cc: l2vpn@ietf.org >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > > >Hi Yuanlong, > >If one understood the operation of SH filtering in E-VPN, he would have >seen that it exactly covers both of these cases that are mentioned below. > >Also, E-VPN allows for policy-based forwarding on a per MAC basis without >scale issue. As I said previously, I won't be able to provide E-VPN >tutorial over the email. > >Cheers, >Ali > >On 9/25/12 12:02 AM, "Jiangyuanlong" wrote: > >>Hi all, >> >>I don't think E-VPN control plane can solve all the problem of E-Tree. >>For the following two scenarios data plane indication of E-Tree is >>needed: >>1. Per EVI label is assigned, and there are multiple PEs with both Leaf >>AND Root sites; >>2. Per label is assigned, and there are multiple >>Ethernet segments with both Leaf AND Root sites; >>Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an >>option, but maybe OAM is a challenge. >> >>Assigning label per MAC for E-Tree will not need this indication, but at >>expense of scalability. >> >>Regards, >>Yuanlong >> >> >>-----Original Message----- >>From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>Sent: Tuesday, September 25, 2012 7:42 AM >>To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >> >>Jim, Aldrin, Josh: >> >>You guys are spot on. E-VPN solution doesn't have the limitation of >>data-plane forwarding that VPLS has and as such it doesn't need addition >>vlan-tag to solve root/leaf indication issue as it can be supported >>inherently by the solution. >> >>Cheers, >>Ali >> >>On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: >> >>>Josh, >>> >>> Yes.. I think that is the reality of it.. VPLS either the LDP or >>>BGP >>>variety uses data plane learning as the mechanism to "learn".. The fact >>>that we extend the L2 footprint via these "tunnels" does not change that >>>fact.. SO in VPLS the only hammer you have is the data plane, so one >>>must >>>manipulate bits on the wire to infer topology ( Limited set of topology >>>).. >>> >>>Another challenge is when roots and leafs "land" on the same PE. >>> >>>EVPN is intended to use contexts and associated import/export to manage >>>the topology.. So here there is a set of tools to create the desired >>>topologies, along with that there other mechanisms realized i.e >>>active/active... >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of >>>Rogers, Josh >>>Sent: Saturday, September 22, 2012 7:03 PM >>>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>Subject: Re: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>>I agree. >>> >>>Would it be safe to state that VPLS has a need for a 'etree solution', >>>but >>>EVPN does not, because it is inherently supported? >>> >>>The previously discussed effort of having a 'single etree solution' for >>>both VPLS and EVPN may not really be valid due to this. >>> >>>In fact, I do not think it is valid to ask for a single solution, EVPN >>>doesn't have a problem that needs to be fixed here, I don't believe it >>>factors into this discussion. >>> >>>-Josh >>> >>> >>>On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >>> >>>>EVPN is intended to maximize the flexibility of multiple routing >>>>contexts >>>>with arbitrary topologies.. As I have stated in the past, EVPN allows >>>>for >>>>E-Tree to be constructed in the control plane, other solutions require >>>>some method to interrogate data and infer topology. IMO this is not >>>>desirable. >>>> >>>>Jim Uttaro >>>> >>>>-----Original Message----- >>>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>>Of >>>>Rogers, Josh >>>>Sent: Saturday, September 22, 2012 12:49 PM >>>>To: Aldrin Isaac; Giles Heron >>>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>>Subject: Re: New Version Notification for >>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> >>>>So, this same sort of 'import/export' of targets is possible using >>>>BGP-VPLS today, but it faces limitations outlined in >>>>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>>>import/export by attachment circuit, and not by PE? Meaning, AC1 one >>>>PE1 >>>>may import RTA, while AC2 on PE2 may import RTB? >>>> >>>>Its occurred to me that EVPN would be able to use other mechanisms that >>>>have not yet been discussed yet due to sharing a mac table over BGP. >>>> >>>>Thanks for the response, >>>>Josh >>>> >>>> >>>>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >>>> >>>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like >>>>>as >>>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import >>>>>RTB >>>>>export RTA at spokes) with filtering to enforce downstream data flow >>>>>if >>>>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>>>> >>>>> >>>>> >>>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>>>> >>>>>> Thanks Yuanlong, >>>>>> >>>>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>>>differs from mine (and from what is noted in the minutes). Whilst >>>>>>Himanshu said that it was better to have the same solution for VPLS >>>>>>and >>>>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in >>>>>>using >>>>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>>>meeting. >>>>>> >>>>>> Giles >>>>>> >>>>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>>>wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> During the 84th IETF meeting, the group discussed the issue of >>>>>>>E-Tree >>>>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>>>than two different approaches for VPLS and E-VPN. >>>>>>> This I-D probes how the 2VLAN approach can be used to support >>>>>>>E-Tree >>>>>>>in E-VPN and it seems not a big issue. >>>>>>> Any comments from you are greatly appreciated. >>>>>>> >>>>>>> Best regards, >>>>>>> Yuanlong >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>>>> To: Jiangyuanlong >>>>>>> Subject: New Version Notification for >>>>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>>>> Revision: 00 >>>>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>>>> Creation date: 2012-09-21 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 6 >>>>>>> URL: >>>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vl >>>>>>>a >>>>>>>n >>>>>>>- >>>>>>>0 >>>>>>>0.txt >>>>>>> Status: >>>>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>>> Htmlized: >>>>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> This document discusses how the Dual-VLAN approach as described in >>>>>>> [Etree-vlan] can be used to support the transport of E-Tree >>>>>>>service >>>>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>>>VPLS >>>>>>> and E-VPN. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>> >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use 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 dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this E-mail in >>>>error, please notify the sender immediately and permanently delete the >>>>original and any copy of this E-mail and any printout. >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use 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 dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this E-mail in >>>error, please notify the sender immediately and permanently delete the >>>original and any copy of this E-mail and any printout. >> > >This e-mail message is intended for the recipient only and contains >information which is CONFIDENTIAL and which may be proprietary to ECI >Telecom. If you have received this transmission in error, please inform >us by e-mail, phone or fax, and then delete the original and all copies >thereof. > From ju1738@att.com Thu Sep 27 11:50: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 91ABC21F86D4 for ; Thu, 27 Sep 2012 11:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiy3q+RWaR+N for ; Thu, 27 Sep 2012 11:50:05 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id F24A421F86D1 for ; Thu, 27 Sep 2012 11:50:04 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) with ESMTP id cdf94605.2aaaf3244940.255632.00-581.718028.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 27 Sep 2012 18:50:04 +0000 (UTC) X-MXL-Hash: 50649fdc2ff54e94-0412c8ae410524a2e9b2e909fa1dc9d62adfbf49 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 5cf94605.0.255449.00-462.717489.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 27 Sep 2012 18:49:44 +0000 (UTC) X-MXL-Hash: 50649fc80319b947-b8e2ca5ea27000a23d7e3b1389653b5ae3569c20 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8RInegQ021113; Thu, 27 Sep 2012 11:49:41 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8RInTQY020712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2012 11:49:34 -0700 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by fflint04.pst.cso.att.com (RSA Interceptor); Thu, 27 Sep 2012 11:49:00 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0318.001; Thu, 27 Sep 2012 14:49:00 -0400 From: "UTTARO, JAMES" To: "'Ali Sajassi (sajassi)'" , Alexander Vainshtein , Jiangyuanlong , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNnOBR9sc2i81O+0epLnx+Dd1A3Zeeh2ww Date: Thu, 27 Sep 2012 18:49:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.154.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=UJNq6ljy c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=UlfSfl3cGAEA:10 a=BbnZtKN_HuwA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=SqYf66d-MNQA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=IRDgFnn-AAAA:8 a=i0EeH86SAAAA:8 a=pGLkceISAAAA:8 a=wN6s] X-AnalysisOut: [-WsGmC8QqbMJ-fQA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA:10 a=l] X-AnalysisOut: [ZB815dzVvQA:10 a=1QW4SJF8ptEA:10 a=hPjdaMEvmhQA:10 a=Hz7Ir] X-AnalysisOut: [DYlS0cA:10 a=MSl-tDqOz04A:10 a=2tlq3imbh8L5mu9y:21 a=ymlRG] X-AnalysisOut: [h8OnSmSmbjA:21] 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, 27 Sep 2012 18:50:06 -0000 That is another benefit of E-VPN that is overlooked.. The fact that the tra= nsport across the core is the same as in L3VPN is very desirable from a con= sistency point of view across all of our services.. Jim Uttaro -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]=20 Sent: Thursday, September 27, 2012 2:46 PM To: Alexander Vainshtein; Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Ald= rin Isaac; Giles Heron Cc: l2vpn@ietf.org Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Sasha, There is no notion of PWs E-VPN. E-VPN operation is analogous to IP-VPN. Regarding the OAM aspects, the work has already started and it will be covered separately. Since E-VPN covers many applications such as VPLS, VPWS, E-TREE/VPMS, DCI, DCN/cloud, its corresponding OAM MUST cover all these applications well. Cheers, Ali On 9/26/12 7:45 AM, "Alexander Vainshtein" wrote: >Yuanlong, Ali, and all, > >I think that we have really 3 aspects of E-Tree that should be explicitly >presented for each solution approach: > >1. Change of the PE Type: > - Root-only to Mixed and vice versa > - Leaf-only to Mixed and vice versa > - Root-only to Leaf-only and vice versa >2. OAM - how it is supposed to work and how the defects it detects are >handled. > This becomes non-trivial in the 2PW solution and its analogs if one >of the two PWsfails IMHO >3. Interworking with Ethernet-only E-Tree. > >My 2c, > Sasha > > >________________________________________ >From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of >Jiangyuanlong [jiangyuanlong@huawei.com] >Sent: Wednesday, September 26, 2012 11:31 AM >To: Ali Sajassi (sajassi); UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; >Giles Heron >Cc: l2vpn@ietf.org >Subject: RE: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > >Ali, > >On the one hand, you said E-VPN solution doesn't have the limitation of >data-plane forwarding and inherently support E-Tree, on the other hand, >you agreed that 2 labels are introduced specially for E-Tree for these >two cases. Furthermore, forwarding behaviors for these two labels are >different (for root label, split horizon + forward to both root & leaf >ports; for leaf label, split horizon + forward only to leaf ports) from >the E-VPN itself (split horizon only). >But my main concern is whether OAM is needed for E-VPN, if yes, how it >can be implemented in practical? > >Regards, >Yuanlong > > > >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Wednesday, September 26, 2012 2:15 PM >To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles >Heron >Cc: l2vpn@ietf.org >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > > >Hi Yuanlong, > >If one understood the operation of SH filtering in E-VPN, he would have >seen that it exactly covers both of these cases that are mentioned below. > >Also, E-VPN allows for policy-based forwarding on a per MAC basis without >scale issue. As I said previously, I won't be able to provide E-VPN >tutorial over the email. > >Cheers, >Ali > >On 9/25/12 12:02 AM, "Jiangyuanlong" wrote: > >>Hi all, >> >>I don't think E-VPN control plane can solve all the problem of E-Tree. >>For the following two scenarios data plane indication of E-Tree is >>needed: >>1. Per EVI label is assigned, and there are multiple PEs with both Leaf >>AND Root sites; >>2. Per label is assigned, and there are multiple >>Ethernet segments with both Leaf AND Root sites; >>Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an >>option, but maybe OAM is a challenge. >> >>Assigning label per MAC for E-Tree will not need this indication, but at >>expense of scalability. >> >>Regards, >>Yuanlong >> >> >>-----Original Message----- >>From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>Sent: Tuesday, September 25, 2012 7:42 AM >>To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >> >>Jim, Aldrin, Josh: >> >>You guys are spot on. E-VPN solution doesn't have the limitation of >>data-plane forwarding that VPLS has and as such it doesn't need addition >>vlan-tag to solve root/leaf indication issue as it can be supported >>inherently by the solution. >> >>Cheers, >>Ali >> >>On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: >> >>>Josh, >>> >>> Yes.. I think that is the reality of it.. VPLS either the LDP or >>>BGP >>>variety uses data plane learning as the mechanism to "learn".. The fact >>>that we extend the L2 footprint via these "tunnels" does not change that >>>fact.. SO in VPLS the only hammer you have is the data plane, so one >>>must >>>manipulate bits on the wire to infer topology ( Limited set of topology >>>).. >>> >>>Another challenge is when roots and leafs "land" on the same PE. >>> >>>EVPN is intended to use contexts and associated import/export to manage >>>the topology.. So here there is a set of tools to create the desired >>>topologies, along with that there other mechanisms realized i.e >>>active/active... >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of >>>Rogers, Josh >>>Sent: Saturday, September 22, 2012 7:03 PM >>>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>Subject: Re: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>>I agree. >>> >>>Would it be safe to state that VPLS has a need for a 'etree solution', >>>but >>>EVPN does not, because it is inherently supported? >>> >>>The previously discussed effort of having a 'single etree solution' for >>>both VPLS and EVPN may not really be valid due to this. >>> >>>In fact, I do not think it is valid to ask for a single solution, EVPN >>>doesn't have a problem that needs to be fixed here, I don't believe it >>>factors into this discussion. >>> >>>-Josh >>> >>> >>>On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >>> >>>>EVPN is intended to maximize the flexibility of multiple routing >>>>contexts >>>>with arbitrary topologies.. As I have stated in the past, EVPN allows >>>>for >>>>E-Tree to be constructed in the control plane, other solutions require >>>>some method to interrogate data and infer topology. IMO this is not >>>>desirable. >>>> >>>>Jim Uttaro >>>> >>>>-----Original Message----- >>>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>>Of >>>>Rogers, Josh >>>>Sent: Saturday, September 22, 2012 12:49 PM >>>>To: Aldrin Isaac; Giles Heron >>>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>>Subject: Re: New Version Notification for >>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> >>>>So, this same sort of 'import/export' of targets is possible using >>>>BGP-VPLS today, but it faces limitations outlined in >>>>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>>>import/export by attachment circuit, and not by PE? Meaning, AC1 one >>>>PE1 >>>>may import RTA, while AC2 on PE2 may import RTB? >>>> >>>>Its occurred to me that EVPN would be able to use other mechanisms that >>>>have not yet been discussed yet due to sharing a mac table over BGP. >>>> >>>>Thanks for the response, >>>>Josh >>>> >>>> >>>>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >>>> >>>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like >>>>>as >>>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import >>>>>RTB >>>>>export RTA at spokes) with filtering to enforce downstream data flow >>>>>if >>>>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>>>> >>>>> >>>>> >>>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>>>> >>>>>> Thanks Yuanlong, >>>>>> >>>>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>>>differs from mine (and from what is noted in the minutes). Whilst >>>>>>Himanshu said that it was better to have the same solution for VPLS >>>>>>and >>>>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in >>>>>>using >>>>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>>>meeting. >>>>>> >>>>>> Giles >>>>>> >>>>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>>>wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> During the 84th IETF meeting, the group discussed the issue of >>>>>>>E-Tree >>>>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>>>than two different approaches for VPLS and E-VPN. >>>>>>> This I-D probes how the 2VLAN approach can be used to support >>>>>>>E-Tree >>>>>>>in E-VPN and it seems not a big issue. >>>>>>> Any comments from you are greatly appreciated. >>>>>>> >>>>>>> Best regards, >>>>>>> Yuanlong >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>>>> To: Jiangyuanlong >>>>>>> Subject: New Version Notification for >>>>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>>>> Revision: 00 >>>>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>>>> Creation date: 2012-09-21 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 6 >>>>>>> URL: >>>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vl >>>>>>>a >>>>>>>n >>>>>>>- >>>>>>>0 >>>>>>>0.txt >>>>>>> Status: >>>>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>>> Htmlized: >>>>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> This document discusses how the Dual-VLAN approach as described in >>>>>>> [Etree-vlan] can be used to support the transport of E-Tree >>>>>>>service >>>>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>>>VPLS >>>>>>> and E-VPN. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>> >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use 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 dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this E-mail in >>>>error, please notify the sender immediately and permanently delete the >>>>original and any copy of this E-mail and any printout. >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use 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 dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this E-mail in >>>error, please notify the sender immediately and permanently delete the >>>original and any copy of this E-mail and any printout. >> > >This e-mail message is intended for the recipient only and contains >information which is CONFIDENTIAL and which may be proprietary to ECI >Telecom. If you have received this transmission in error, please inform >us by e-mail, phone or fax, and then delete the original and all copies >thereof. > From jiangyuanlong@huawei.com Sat Sep 29 01:01:59 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 3E42121F8620 for ; Sat, 29 Sep 2012 01:01:59 -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, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhW-kIkSk2g4 for ; Sat, 29 Sep 2012 01:01:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A782621F854C for ; Sat, 29 Sep 2012 01:01:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKD15782; Sat, 29 Sep 2012 08:01:55 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 09:00:14 +0100 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 09:01:12 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.97]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 16:01:04 +0800 From: Jiangyuanlong To: "Ali Sajassi (sajassi)" , "UTTARO, JAMES" , "'Rogers, Josh'" , Aldrin Isaac , Giles Heron Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt Thread-Index: AQHNmq4pFVANLlv0RU6/0DirrqUYkJeanNRAgAEEFYCAALLAoIABr9WAgAGTolA= Date: Sat, 29 Sep 2012 08:01:02 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46EA2A@szxeml546-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D46E3C4@szxeml546-mbs.china.huawei.com> 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.95] 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: Sat, 29 Sep 2012 08:01:59 -0000 Ali, Thank you for the reply, I got your idea. Maybe "split-horizon label" can b= e clearly defined in the next version of E-VPN draft, so that it can be und= erstood better. Especially how it is constructed for E-Tree service. =20 Regards, Yuanlong -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]=20 Sent: Friday, September 28, 2012 2:40 AM To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron Cc: l2vpn@ietf.org Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vla= n-00.txt Sigh!=20 When split-horizon label is used in E-VPN, the stack consists of three labels (tunnel label,vpn label, and SH label). For E-TREE application, the same three labels are used and the SH label is used for SH filtering and/or root/leaf filtering. In E-VPN, the SH label is used for filtering of packets on the egress interface of the egress PE based on the site of origin. In E-TREE application, we use SH label for exactly the same purpose - filtering on the egress interface of the egress PE based on the site of origin (that can also represent leaf/root). That is why I have been saying in every email on this thread that the forwarding behavior of the E-VPN remains unchanged and that's why it doesn't make sense to add vlan-tag kluge (and as the result change the forwarding behavior) for something that is already supported. Regarding OAM aspects, we have always treated OAM work independently and we don't want to tie it with a single application of E-VPN. E-VPN has many applications such as VPLS, VPWS, E-TREE, DCI, DCN/cloud and the OAM MUST apply to all of them. We have started on OAM work for E-VPN and one draft was published before last IETF meeting and more will be coming; however, E-VPN OAM work will be done independent. Cheers, Ali =20 =20 On 9/26/12 2:31 AM, "Jiangyuanlong" wrote: >Ali, > >On the one hand, you said E-VPN solution doesn't have the limitation of >data-plane forwarding and inherently support E-Tree, on the other hand, >you agreed that 2 labels are introduced specially for E-Tree for these >two cases. Furthermore, forwarding behaviors for these two labels are >different (for root label, split horizon + forward to both root & leaf >ports; for leaf label, split horizon + forward only to leaf ports) from >the E-VPN itself (split horizon only). >But my main concern is whether OAM is needed for E-VPN, if yes, how it >can be implemented in practical? > >Regards, >Yuanlong > > > >-----Original Message----- >From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >Sent: Wednesday, September 26, 2012 2:15 PM >To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles >Heron >Cc: l2vpn@ietf.org >Subject: Re: New Version Notification for >draft-jiang-l2vpn-evpn-etree-2vlan-00.txt > > > >Hi Yuanlong,=20 > >If one understood the operation of SH filtering in E-VPN, he would have >seen that it exactly covers both of these cases that are mentioned below. > >Also, E-VPN allows for policy-based forwarding on a per MAC basis without >scale issue. As I said previously, I won't be able to provide E-VPN >tutorial over the email. > >Cheers, >Ali > >On 9/25/12 12:02 AM, "Jiangyuanlong" wrote: > >>Hi all, >> >>I don't think E-VPN control plane can solve all the problem of E-Tree. >>For the following two scenarios data plane indication of E-Tree is >>needed: >>1. Per EVI label is assigned, and there are multiple PEs with both Leaf >>AND Root sites; >>2. Per label is assigned, and there are multiple >>Ethernet segments with both Leaf AND Root sites; >>Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an >>option, but maybe OAM is a challenge. >> >>Assigning label per MAC for E-Tree will not need this indication, but at >>expense of scalability. >> >>Regards, >>Yuanlong >> >> >>-----Original Message----- >>From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>Sent: Tuesday, September 25, 2012 7:42 AM >>To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron >>Cc: l2vpn@ietf.org; Jiangyuanlong >>Subject: Re: New Version Notification for >>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >> >> >>Jim, Aldrin, Josh: >> >>You guys are spot on. E-VPN solution doesn't have the limitation of >>data-plane forwarding that VPLS has and as such it doesn't need addition >>vlan-tag to solve root/leaf indication issue as it can be supported >>inherently by the solution. >> >>Cheers, >>Ali >> >>On 9/22/12 4:34 PM, "UTTARO, JAMES" wrote: >> >>>Josh, >>> >>> Yes.. I think that is the reality of it.. VPLS either the LDP or BGP >>>variety uses data plane learning as the mechanism to "learn".. The fact >>>that we extend the L2 footprint via these "tunnels" does not change that >>>fact.. SO in VPLS the only hammer you have is the data plane, so one >>>must >>>manipulate bits on the wire to infer topology ( Limited set of topology >>>).. >>> >>>Another challenge is when roots and leafs "land" on the same PE. >>> >>>EVPN is intended to use contexts and associated import/export to manage >>>the topology.. So here there is a set of tools to create the desired >>>topologies, along with that there other mechanisms realized i.e >>>active/active... >>> >>>Jim Uttaro >>> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>Of >>>Rogers, Josh >>>Sent: Saturday, September 22, 2012 7:03 PM >>>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron >>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>Subject: Re: New Version Notification for >>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>> >>>I agree. >>> >>>Would it be safe to state that VPLS has a need for a 'etree solution', >>>but >>>EVPN does not, because it is inherently supported? >>> >>>The previously discussed effort of having a 'single etree solution' for >>>both VPLS and EVPN may not really be valid due to this. >>> >>>In fact, I do not think it is valid to ask for a single solution, EVPN >>>doesn't have a problem that needs to be fixed here, I don't believe it >>>factors into this discussion. >>> >>>-Josh >>> >>> >>>On 9/22/12 4:56 PM, "UTTARO, JAMES" wrote: >>> >>>>EVPN is intended to maximize the flexibility of multiple routing >>>>contexts >>>>with arbitrary topologies.. As I have stated in the past, EVPN allows >>>>for >>>>E-Tree to be constructed in the control plane, other solutions require >>>>some method to interrogate data and infer topology. IMO this is not >>>>desirable. >>>> >>>>Jim Uttaro >>>> >>>>-----Original Message----- >>>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>>Of >>>>Rogers, Josh >>>>Sent: Saturday, September 22, 2012 12:49 PM >>>>To: Aldrin Isaac; Giles Heron >>>>Cc: l2vpn@ietf.org; Jiangyuanlong >>>>Subject: Re: New Version Notification for >>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>> >>>>So, this same sort of 'import/export' of targets is possible using >>>>BGP-VPLS today, but it faces limitations outlined in >>>>draft-ietf-l2vpn-etree-frwk, in section 2. E-VPN would be able to >>>>import/export by attachment circuit, and not by PE? Meaning, AC1 one >>>>PE1 >>>>may import RTA, while AC2 on PE2 may import RTB? >>>> >>>>Its occurred to me that EVPN would be able to use other mechanisms that >>>>have not yet been discussed yet due to sharing a mac table over BGP. >>>> >>>>Thanks for the response, >>>>Josh >>>> >>>> >>>>On 9/22/12 10:28 AM, "Aldrin Isaac" wrote: >>>> >>>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like >>>>>as >>>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import >>>>>RTB >>>>>export RTA at spokes) with filtering to enforce downstream data flow >>>>>if >>>>>desired. The tree could be built using PIM, mLDP, RSVP, etc. >>>>> >>>>> >>>>> >>>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote: >>>>> >>>>>> Thanks Yuanlong, >>>>>> >>>>>> however I must say that your memory of the IETF 84 L2VPN meeting >>>>>>differs from mine (and from what is noted in the minutes). Whilst >>>>>>Himanshu said that it was better to have the same solution for VPLS >>>>>>and >>>>>>E-VPN, Ali stated that there was no benefit in the E-VPN case in >>>>>>using >>>>>>an additional tag (such as a VLAN). No consensus was reached in the >>>>>>meeting. >>>>>> >>>>>> Giles >>>>>> >>>>>> On 21 Sep 2012, at 10:16, Jiangyuanlong >>>>>>wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> During the 84th IETF meeting, the group discussed the issue of >>>>>>>E-Tree >>>>>>>in E-VPN, and it was shown that a single solution was more preferred >>>>>>>than two different approaches for VPLS and E-VPN. >>>>>>> This I-D probes how the 2VLAN approach can be used to support >>>>>>>E-Tree >>>>>>>in E-VPN and it seems not a big issue. >>>>>>> Any comments from you are greatly appreciated. >>>>>>> >>>>>>> Best regards, >>>>>>> Yuanlong >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>>> Sent: Friday, September 21, 2012 4:55 PM >>>>>>> To: Jiangyuanlong >>>>>>> Subject: New Version Notification for >>>>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt >>>>>>> has been successfully submitted by Yuanlong Jiang and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Filename: draft-jiang-l2vpn-evpn-etree-2vlan >>>>>>> Revision: 00 >>>>>>> Title: E-Tree Support with 2VLAN in E-VPN >>>>>>> Creation date: 2012-09-21 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 6 >>>>>>> URL: >>>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vl >>>>>>>a >>>>>>>n >>>>>>>- >>>>>>>0 >>>>>>>0.txt >>>>>>> Status: >>>>>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan >>>>>>> Htmlized: >>>>>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00 >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> This document discusses how the Dual-VLAN approach as described in >>>>>>> [Etree-vlan] can be used to support the transport of E-Tree >>>>>>>service >>>>>>> in E-VPN. Thus a single convergent solution is possible for both >>>>>>>VPLS >>>>>>> and E-VPN. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>> >>>>> >>>> >>>> >>>>This E-mail and any of its attachments may contain Time Warner Cable >>>>proprietary information, which is privileged, confidential, or subject >>>>to >>>>copyright belonging to Time Warner Cable. This E-mail is intended >>>>solely >>>>for the use 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 dissemination, distribution, copying, or action taken in >>>>relation to the contents of and attachments to this E-mail is strictly >>>>prohibited and may be unlawful. If you have received this E-mail in >>>>error, please notify the sender immediately and permanently delete the >>>>original and any copy of this E-mail and any printout. >>> >>> >>>This E-mail and any of its attachments may contain Time Warner Cable >>>proprietary information, which is privileged, confidential, or subject >>>to >>>copyright belonging to Time Warner Cable. This E-mail is intended solely >>>for the use 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 dissemination, distribution, copying, or action taken in >>>relation to the contents of and attachments to this E-mail is strictly >>>prohibited and may be unlawful. If you have received this E-mail in >>>error, please notify the sender immediately and permanently delete the >>>original and any copy of this E-mail and any printout. >> > From internet-drafts@ietf.org Sat Sep 29 22:47: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 67FF421F863B; Sat, 29 Sep 2012 22:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PdLhdjpsdPM; Sat, 29 Sep 2012 22:47:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E909421F8618; Sat, 29 Sep 2012 22:47:36 -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-vpls-mib-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120930054736.12328.50110.idtracker@ietfa.amsl.com> Date: Sat, 29 Sep 2012 22:47:36 -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: Sun, 30 Sep 2012 05:47: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 : Virtual Private Lan Services (VPLS) Management Informati= on Base Author(s) : Thomas D. Nadeau A S Kiran Koushik Rohit Mediratta Filename : draft-ietf-l2vpn-vpls-mib-07.txt Pages : 46 Date : 2012-09-29 Abstract: This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pseudowire (PW) Management Information Base [RFC5601]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-vpls-mib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nabil.n.bitar@verizon.com Sun Sep 30 18:32: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 37C3C21F84F8 for ; Sun, 30 Sep 2012 18:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6liOmaIsK+Wq for ; Sun, 30 Sep 2012 18:32:02 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 684F821F84F1 for ; Sun, 30 Sep 2012 18:32:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 01 Oct 2012 01:32:01 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208,217";a="342534883" Received: from fldp1lumxc7hb05.verizon.com (HELO FLDP1LUMXC7HB05.us.one.verizon.com) ([166.68.75.87]) by fldsmtpi01.verizon.com with ESMTP; 01 Oct 2012 01:32:01 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Sun, 30 Sep 2012 21:32:01 -0400 To: "l2vpn@ietf.org" Date: Sun, 30 Sep 2012 21:31:54 -0400 Subject: [l2vpn] L2VPN Agenda Slot Call for IETF 85 - Atlanta Thread-Topic: [l2vpn] L2VPN Agenda Slot Call for IETF 85 - Atlanta Thread-Index: Ac2fdI04/1v+aR15SyaDSPy5NE+o6A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC8E672959A88nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Giles Heron 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, 01 Oct 2012 01:32:03 -0000 --_000_CC8E672959A88nabilnbitarverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi L2VPN WG. Please let us know if you have a time-slot request for the L2VPN session at= IETF 85=96Atlanta. Please, email us your request by Sunday October 21, 20= 12 along with the following information: 1) Draft title 2) Presenter name 3) Requested duration Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter. Additional key dates to remember are: 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) subm= ission by UTC 24:00 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00 Thanks, Nabil and Giles --_000_CC8E672959A88nabilnbitarverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi L2VPN WG.
Please let us know if you have a time-slot request for the L2VPN session at= IETF 85=96Atlanta. Please,  email us your request by Sunday October 2= 1, 2012 along with the following information:
1) Draft title
2) Presenter name
3) Requested duration

Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter.

Additional key dates to remember are:
20= 12-10-15 (Monday): Internet Draft Cut-off for initial document (-0= 0) submission by UTC 24:00
2012-10-22 (Monday): Internet Draft fin= al submission cut-off by UTC 24:00
=

Thanks,
Nabil and Giles
=
--_000_CC8E672959A88nabilnbitarverizoncom_--