From giles.heron@gmail.com Fri Nov 2 05:35:53 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908F821F8624 for ; Fri, 2 Nov 2012 05:35:53 -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 ZClAV7LCk63t for ; Fri, 2 Nov 2012 05:35:53 -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 40D7C21F85ED for ; Fri, 2 Nov 2012 05:35:51 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so2086983eek.31 for ; Fri, 02 Nov 2012 05:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=hN4MGvf/25sV8092J5dNhDeEuh1fD3wcwA9jxWJKSYQ=; b=yFamRBusgcmUKLwBgpVHMhDNVcHJB+8ZlKFUNwnzGQBoFE/B7PAtCY1mMIEtf81lI0 cRc5pFZszuKOUBhcHPYoAXR+LQZylADcpaM27+iinC2mvkk2ksdoZ+JUgELUkr+NZCBX H+vYHzmK/rmpOs2Za44ChmSNagnJ2fQD/OA2TB2bCIoO95Nkja/wuQS+tJSbPLqyua5Z 2sAUXFwcqzfXvHQH1NI8dslAMpTHN5SS8EOpxfLwfEQTALZyf5hHp4Sd4rTsMcI58EnH 6xbvGVjWssJk01b8pJQpCoSBGGaZEY6V2zY/tMsmOIhBV90JMNH0hCvnjObytEvypsQZ wumA== Received: by 10.14.216.193 with SMTP id g41mr6148623eep.37.1351859750445; Fri, 02 Nov 2012 05:35:50 -0700 (PDT) Received: from dhcp-10-61-101-103.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id c6sm22733497eep.17.2012.11.02.05.35.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 05:35:49 -0700 (PDT) From: Giles Heron Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Forwarded message re NomCom Date: Fri, 2 Nov 2012 12:35:43 +0000 Message-Id: <50D8203C-C232-4A41-9EE6-60EC0003F41A@gmail.com> To: "l2vpn@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) 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, 02 Nov 2012 12:35:53 -0000 The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org From nabil.n.bitar@verizon.com Fri Nov 2 05:43: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 83D3021F8439 for ; Fri, 2 Nov 2012 05:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52QIxnMLHwN5 for ; Fri, 2 Nov 2012 05:43:56 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id B38D821F842B for ; Fri, 2 Nov 2012 05:43:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 02 Nov 2012 12:43:54 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.80,699,1344211200"; d="scan'208,217";a="356699403" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi03.verizon.com with ESMTP; 02 Nov 2012 12:43:54 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB01.us.one.verizon.com ([166.68.45.78]) with mapi; Fri, 2 Nov 2012 08:43:54 -0400 To: "l2vpn@ietf.org" Date: Fri, 2 Nov 2012 08:43:53 -0400 Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 Thread-Index: Ac2497ct31BrrSMoReW+bGGDA94enw== 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: multipart/alternative; boundary="_000_CCB9348466BF5nabilnbitarverizoncom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 02 Nov 2012 08:39:55 -0700 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: Fri, 02 Nov 2012 12:43:56 -0000 --_000_CCB9348466BF5nabilnbitarverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, This is the start of a two-week working group last call on the draft =93Req= uirements for MEF E-Tree Support in L2VPN=94. The draft can be found at h= ttp://tools.ietf.org/html/draft-ietf-l2vpn-etree-reqt-03 Please, review the draft and send any comments to the L2VPN working group e= mail list. You are encouraged to send extensive comments as you see fit. This WG last call will close on Friday November 16th, 2012. Regards, Giles & Nabil --_000_CCB9348466BF5nabilnbitarverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

[l2vpn]  WG last call for draft-= ietf-l2vpn-vpls-macflush-ld-01
<= font class=3D"Apple-style-span" face=3D"Calibri,sans-serif" style=3D"font-s= ize: 12pt; ">Hi,
This is the start of a two-week working group last call on the draft =93Requirements for MEF E-Tree Support in L2VPN=94.  The draft can be found at  http://tools.= ietf.org/html/draft-ietf-l2vpn-etree-reqt-03=
=
Please, review the draft and send any comments to the L2VPN working group e= mail list. You are encouraged to send extensive comments as you see fit.
This WG last call will close on Friday November 16th, 2012.
 
Regards,
Giles & Nabil


--_000_CCB9348466BF5nabilnbitarverizoncom_-- From lucy.yong@huawei.com Sun Nov 4 11:41: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 BD12F21F85E3 for ; Sun, 4 Nov 2012 11:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 7wr3d2AFMisy for ; Sun, 4 Nov 2012 11:41:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D33DB21F85D6 for ; Sun, 4 Nov 2012 11:41:05 -0800 (PST) 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 AMK38065; Sun, 04 Nov 2012 19:41:04 +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; Sun, 4 Nov 2012 19:41:01 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 4 Nov 2012 19:41:03 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Sun, 4 Nov 2012 11:41:00 -0800 From: Lucy yong To: "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQ Date: Sun, 4 Nov 2012 19:40:59 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482C408@dfweml505-mbx> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D482286@szxeml546-mbx.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D482286@szxeml546-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Sun, 04 Nov 2012 19:41:06 -0000 I support this draft but have some comments. 1) in section 4.3, Text: The latter scenario often means that requiring a d= edicated link between the PEs, for the operation of the multi-homing mechanism, i= s not appealing from cost standpoint. Comment: a dedicated link between PEs. will this link is in IGP link too? o= r private link. May PE nodes that are multi-homed to a same CE be different ASes? If yes, s= tate it out. 2) in section 4.6, the last paragraph should state a requirement for flow b= ased load balance. 3) It should add one requirement in supporting Ethernet L2VPN across multi-= ASes 4) As the draft mentioned, the new service interfaces are required for DC i= nterconnection. If DC uses NVo3 in future, will these service interfaces ar= e still necessary? Suggest giving some use cases where the new service inte= rfaces are necessary in an appendix. Cheers, Lucy > ------------------------------ > Date: Fri, 19 Oct 2012 23:34:53 +0100 > From: Giles Heron > To: "l2vpn@ietf.org" > Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> > Content-Type: text/plain; charset=3Dus-ascii >=20 > This email initiates an L2VPN WG Last Call for: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >=20 > please comment to the list as to the suitability of this draft for > publication as a Standards Track RFC from the L2VPN WG. >=20 > this last call will close on Friday 2nd November. >=20 > Nabil & Giles From giles.heron@gmail.com Sun Nov 4 13:02:52 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 0324521F882A for ; Sun, 4 Nov 2012 13:02:52 -0800 (PST) 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 8RsxAD8gu4IN for ; Sun, 4 Nov 2012 13:02:51 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2995E21F87F7 for ; Sun, 4 Nov 2012 13:02:51 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2370892dan.31 for ; Sun, 04 Nov 2012 13:02:51 -0800 (PST) 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=O89wUQVlfWSlIe60SEitRmqc+vQKx9EAK3l7byZKOv8=; b=a4J5kkDrterLEjqb9lSBwHTCB42ZQhlFESPn3Bu57XUZ9ewkafatyY0VEnjTaTuhEv 6lii9DxNdC2EQc0S0pkewklU1TYT1dF1mz9RaaCN0L3Ru/AwPYyCZdrGn/S4oBKAUKiD xEVKujj9hTDLJyk7OW72OmnsWfbLAZLDkhuKH0Hig/27bBIE8s2apA3b/DsLNnBPEnCM aJmauTjat0tzIXSO2mTew1pe2hlC0yhFCxq9REoFHfjCb51YfMk4xQcKLtXMZNmdBoj6 hKMR/pyZKoNUPnk5x0WA8O9PwzLrBBaL3jAGwMRcRfjU42/UlPuaBGnVSg2GRZWDPo1k oY0w== Received: by 10.68.189.102 with SMTP id gh6mr24758987pbc.37.1352062970980; Sun, 04 Nov 2012 13:02:50 -0800 (PST) Received: from sjc-vpn5-1300.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id ay5sm9421110pab.1.2012.11.04.13.02.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Nov 2012 13:02:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req From: Giles Heron In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482C408@dfweml505-mbx> Date: Sun, 4 Nov 2012 21:02:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7FCECE66-0834-4836-81CF-44BA48DA84B3@gmail.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D482286@szxeml546-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D4482C408@dfweml505-mbx> To: Lucy yong X-Mailer: Apple Mail (2.1499) 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, 04 Nov 2012 21:02:52 -0000 Thanks Lucy, authors - I'd like to see you address Yuanlong and Lucy's comments. = Perhaps you can discuss face-to-face this week? Once the comments have been addressed we can progress the draft further. thanks. Giles On 4 Nov 2012, at 19:40, Lucy yong wrote: > I support this draft but have some comments. >=20 > 1) in section 4.3, Text: The latter scenario often means that = requiring a dedicated > link between the PEs, for the operation of the multi-homing = mechanism, is not appealing from cost standpoint. >=20 > Comment: a dedicated link between PEs. will this link is in IGP link = too? or private link. > May PE nodes that are multi-homed to a same CE be different ASes? If = yes, state it out. >=20 > 2) in section 4.6, the last paragraph should state a requirement for = flow based load balance. >=20 > 3) It should add one requirement in supporting Ethernet L2VPN across = multi-ASes >=20 > 4) As the draft mentioned, the new service interfaces are required for = DC interconnection. If DC uses NVo3 in future, will these service = interfaces are still necessary? Suggest giving some use cases where the = new service interfaces are necessary in an appendix. >=20 > Cheers, > Lucy >=20 >> ------------------------------ >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >> From: Giles Heron >> To: "l2vpn@ietf.org" >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >> This email initiates an L2VPN WG Last Call for: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >>=20 >> please comment to the list as to the suitability of this draft for >> publication as a Standards Track RFC from the L2VPN WG. >>=20 >> this last call will close on Friday 2nd November. >>=20 >> Nabil & Giles >=20 From wim.henderickx@alcatel-lucent.com Sun Nov 4 13:53: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 EB85C21F8698 for ; Sun, 4 Nov 2012 13:53:35 -0800 (PST) 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 EZY6ow35bcrY for ; Sun, 4 Nov 2012 13:53:35 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id B15EA21F8679 for ; Sun, 4 Nov 2012 13:53:34 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA4LrVUS003673 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 4 Nov 2012 22:53:31 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 4 Nov 2012 22:53:31 +0100 From: "Henderickx, Wim (Wim)" To: Lucy yong , "l2vpn@ietf.org" Date: Sun, 4 Nov 2012 22:53:30 +0100 Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: Ac261tQoElzYbnIcQXiufsqkM4PulA== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482C408@dfweml505-mbx> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 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, 04 Nov 2012 21:53:36 -0000 On 04/11/12 20:40, "Lucy yong" wrote: >I support this draft but have some comments. > >1) in section 4.3, Text: The latter scenario often means that requiring a >dedicated > link between the PEs, for the operation of the multi-homing mechanism, >is not appealing from cost standpoint. > >Comment: a dedicated link between PEs. will this link is in IGP link too? >or private link. >May PE nodes that are multi-homed to a same CE be different ASes? If yes, >state it out. WH> the dedicated link is not necessary but it depends on the design. We better take it out > >2) in section 4.6, the last paragraph should state a requirement for flow >based load balance. WH> are you saying the Mac based load-balancing is a MUST or are you saying the MAC based load-balancing should be flow based > >3) It should add one requirement in supporting Ethernet L2VPN across >multi-Ases WH> agreed > >4) As the draft mentioned, the new service interfaces are required for DC >interconnection. If DC uses NVo3 in future, will these service interfaces >are still necessary? Suggest giving some use cases where the new service >interfaces are necessary in an appendix. WH> it depends on what use case we have in NVO3: is the NVE collocated with the VM or is the NVE located at a TOR connected to a server. Depending on the connectivity different solutions might be required and as such we made the requirement general and not specific since there is multiple solutions to this and this is a requirements draft rather than solution draft. Use case should be covered in a separate doc. > >Cheers, >Lucy > >> ------------------------------ >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >> From: Giles Heron >> To: "l2vpn@ietf.org" >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >> This email initiates an L2VPN WG Last Call for: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >>=20 >> please comment to the list as to the suitability of this draft for >> publication as a Standards Track RFC from the L2VPN WG. >>=20 >> this last call will close on Friday 2nd November. >>=20 >> Nabil & Giles > From lucy.yong@huawei.com Sun Nov 4 18:39:32 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9998C21F88D2 for ; Sun, 4 Nov 2012 18:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 KeTJTXdp8SEY for ; Sun, 4 Nov 2012 18:39:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 317A721F88C1 for ; Sun, 4 Nov 2012 18:39:30 -0800 (PST) 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 AMK54153; Mon, 05 Nov 2012 02:39:28 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 02:39:23 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 02:39:26 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Sun, 4 Nov 2012 18:39:15 -0800 From: Lucy yong To: "Henderickx, Wim (Wim)" , Lucy yong , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoA== Date: Mon, 5 Nov 2012 02:39:14 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482C493@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482C408@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.91.188] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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: Mon, 05 Nov 2012 02:39:32 -0000 Hi Wim, Please see inline. > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Sunday, November 04, 2012 3:54 PM > To: Lucy yong; l2vpn@ietf.org > Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 >=20 >=20 > On 04/11/12 20:40, "Lucy yong" wrote: >=20 > >I support this draft but have some comments. > > > >1) in section 4.3, Text: The latter scenario often means that > requiring a > >dedicated > > link between the PEs, for the operation of the multi-homing > mechanism, > >is not appealing from cost standpoint. > > > >Comment: a dedicated link between PEs. will this link is in IGP link > too? > >or private link. > >May PE nodes that are multi-homed to a same CE be different ASes? If > yes, > >state it out. >=20 > WH> the dedicated link is not necessary but it depends on the design. > We > better take it out [Lucy] My second question is if PE nodes that are multi-homed to a same CE = may be in different ASes in latter case? Whether yes, or no, it should stat= e it out. > > > >2) in section 4.6, the last paragraph should state a requirement for > flow > >based load balance. >=20 > WH> are you saying the Mac based load-balancing is a MUST or are you > saying the MAC based load-balancing should be flow based [Lucy] Text: A solution MAY support multi-homed network with active/activ= e MAC- based load balancing (i.e. different MAC addresses on a VLAN are reachable via different PEs). In section 4.1, it describes options for flow-based load balancing, that sh= ould apply to here, right? That means the same MAC address may occur on the different PEs too. > > > >3) It should add one requirement in supporting Ethernet L2VPN across > >multi-Ases >=20 > WH> agreed > > > >4) As the draft mentioned, the new service interfaces are required for > DC > >interconnection. If DC uses NVo3 in future, will these service > interfaces > >are still necessary? Suggest giving some use cases where the new > service > >interfaces are necessary in an appendix. > WH> it depends on what use case we have in NVO3: is the NVE collocated > with the VM or is the NVE located at a TOR connected to a server. > Depending on the connectivity different solutions might be required and > as > such we made the requirement general and not specific since there is > multiple solutions to this and this is a requirements draft rather than > solution draft. Use case should be covered in a separate doc. [Lucy] It, I think, is more about cases between DC GW and WAN PE. For examp= le, if NVO3 is used in DC, when we need VLAN aware bundle service interface= ? Could you give a example? I don't have a problem to make a general requir= ement, just want know where is the requirement coming from. =20 Lucy > > > >Cheers, > >Lucy > > > >> ------------------------------ > >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > >> From: Giles Heron > >> To: "l2vpn@ietf.org" > >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> > >> Content-Type: text/plain; charset=3Dus-ascii > >> > >> This email initiates an L2VPN WG Last Call for: > >> > >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 > >> > >> please comment to the list as to the suitability of this draft for > >> publication as a Standards Track RFC from the L2VPN WG. > >> > >> this last call will close on Friday 2nd November. > >> > >> Nabil & Giles > > From wim.henderickx@alcatel-lucent.com Mon Nov 5 02:04:36 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 E0E2921F865B for ; Mon, 5 Nov 2012 02:04:36 -0800 (PST) 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 skLU1WlCEbzu for ; Mon, 5 Nov 2012 02:04:36 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0191621F85FF for ; Mon, 5 Nov 2012 02:04:35 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA59qj9d015330 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Nov 2012 11:04:24 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 5 Nov 2012 11:04:19 +0100 From: "Henderickx, Wim (Wim)" To: Lucy yong , "l2vpn@ietf.org" Date: Mon, 5 Nov 2012 11:04:18 +0100 Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: Ac27POtSx3WVidxtQtCCZmG8LJ56VA== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482C493@dfweml505-mbx> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 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, 05 Nov 2012 10:04:37 -0000 Lucy, in-line On 05/11/12 03:39, "Lucy yong" wrote: >Hi Wim, > >Please see inline. > >> -----Original Message----- >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >> Sent: Sunday, November 04, 2012 3:54 PM >> To: Lucy yong; l2vpn@ietf.org >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >>=20 >>=20 >>=20 >> On 04/11/12 20:40, "Lucy yong" wrote: >>=20 >> >I support this draft but have some comments. >> > >> >1) in section 4.3, Text: The latter scenario often means that >> requiring a >> >dedicated >> > link between the PEs, for the operation of the multi-homing >> mechanism, >> >is not appealing from cost standpoint. >> > >> >Comment: a dedicated link between PEs. will this link is in IGP link >> too? >> >or private link. >> >May PE nodes that are multi-homed to a same CE be different ASes? If >> yes, >> >state it out. >>=20 >> WH> the dedicated link is not necessary but it depends on the design. >> We >> better take it out >[Lucy] My second question is if PE nodes that are multi-homed to a same >CE may be in different ASes in latter case? Whether yes, or no, it should >state it out. WH2> this seems like an odd scenario > >> > >> >2) in section 4.6, the last paragraph should state a requirement for >> flow >> >based load balance. >>=20 >> WH> are you saying the Mac based load-balancing is a MUST or are you >> saying the MAC based load-balancing should be flow based >[Lucy] Text: A solution MAY support multi-homed network with >active/active MAC- > based load balancing (i.e. different MAC addresses on a VLAN are > reachable via different PEs). > >In section 4.1, it describes options for flow-based load balancing, that >should apply to here, right? >That means the same MAC address may occur on the different PEs too. WH2> yes > >> > >> >3) It should add one requirement in supporting Ethernet L2VPN across >> >multi-Ases >>=20 >> WH> agreed >> > >> >4) As the draft mentioned, the new service interfaces are required for >> DC >> >interconnection. If DC uses NVo3 in future, will these service >> interfaces >> >are still necessary? Suggest giving some use cases where the new >> service >> >interfaces are necessary in an appendix. >> WH> it depends on what use case we have in NVO3: is the NVE collocated >> with the VM or is the NVE located at a TOR connected to a server. >> Depending on the connectivity different solutions might be required and >> as >> such we made the requirement general and not specific since there is >> multiple solutions to this and this is a requirements draft rather than >> solution draft. Use case should be covered in a separate doc. >[Lucy] It, I think, is more about cases between DC GW and WAN PE. For >example, if NVO3 is used in DC, when we need VLAN aware bundle service >interface? Could you give a example? I don't have a problem to make a >general requirement, just want know where is the requirement coming from. >=20 >Lucy WH2> the service interface we are talking about here is how the EVPN service is modelled on the DC GW/WAN PE. There are multiple scenarios which should be supported. The service interface here is an internal modelling of the EVPN on the PE >> > >> >Cheers, >> >Lucy >> > >> >> ------------------------------ >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >> >> From: Giles Heron >> >> To: "l2vpn@ietf.org" >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >> >> Content-Type: text/plain; charset=3Dus-ascii >> >> >> >> This email initiates an L2VPN WG Last Call for: >> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >> >> >> >> please comment to the list as to the suitability of this draft for >> >> publication as a Standards Track RFC from the L2VPN WG. >> >> >> >> this last call will close on Friday 2nd November. >> >> >> >> Nabil & Giles >> > > From lucy.yong@huawei.com Mon Nov 5 08:09: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 93AAF21F88C5 for ; Mon, 5 Nov 2012 08:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 Nux0oPj1eFPM for ; Mon, 5 Nov 2012 08:09:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 71D3221F87CE for ; Mon, 5 Nov 2012 08:09:28 -0800 (PST) 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 ALF94317; Mon, 05 Nov 2012 16:09:27 +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, 5 Nov 2012 16:09:22 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 5 Nov 2012 16:09:26 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 5 Nov 2012 08:09:23 -0800 From: Lucy yong To: "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3A= Date: Mon, 5 Nov 2012 16:09:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482C632@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482C493@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Mon, 05 Nov 2012 16:09:29 -0000 snip > >[Lucy] My second question is if PE nodes that are multi-homed to a > same > >CE may be in different ASes in latter case? Whether yes, or no, it > should > >state it out. >=20 > WH2> this seems like an odd scenario [Lucy] agree.=20 > > > >> > > >> >2) in section 4.6, the last paragraph should state a requirement > for > >> flow > >> >based load balance. > >> > >> WH> are you saying the Mac based load-balancing is a MUST or are you > >> saying the MAC based load-balancing should be flow based > >[Lucy] Text: A solution MAY support multi-homed network with > >active/active MAC- > > based load balancing (i.e. different MAC addresses on a VLAN are > > reachable via different PEs). > > > >In section 4.1, it describes options for flow-based load balancing, > that > >should apply to here, right? > >That means the same MAC address may occur on the different PEs too. > WH2> yes > > > >> > > >> >3) It should add one requirement in supporting Ethernet L2VPN > across > >> >multi-Ases > >> > >> WH> agreed > >> > > >> >4) As the draft mentioned, the new service interfaces are required > for > >> DC > >> >interconnection. If DC uses NVo3 in future, will these service > >> interfaces > >> >are still necessary? Suggest giving some use cases where the new > >> service > >> >interfaces are necessary in an appendix. > >> WH> it depends on what use case we have in NVO3: is the NVE > collocated > >> with the VM or is the NVE located at a TOR connected to a server. > >> Depending on the connectivity different solutions might be required > and > >> as > >> such we made the requirement general and not specific since there is > >> multiple solutions to this and this is a requirements draft rather > than > >> solution draft. Use case should be covered in a separate doc. > >[Lucy] It, I think, is more about cases between DC GW and WAN PE. For > >example, if NVO3 is used in DC, when we need VLAN aware bundle service > >interface? Could you give a example? I don't have a problem to make a > >general requirement, just want know where is the requirement coming > from. > > > >Lucy >=20 > WH2> the service interface we are talking about here is how the EVPN > service is modelled on the DC GW/WAN PE. There are multiple scenarios > which should be supported. The service interface here is an internal > modelling of the EVPN on the PE [Lucy] OK. Maybe I did not follow the early requirement discussions. Where = was this requirement coming from. MEF Services do not support such service = interface. Was this from some operators in IETF? I just like to know a use = case if possible. Lucy > >> > > >> >Cheers, > >> >Lucy > >> > > >> >> ------------------------------ > >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > >> >> From: Giles Heron > >> >> To: "l2vpn@ietf.org" > >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> > >> >> Content-Type: text/plain; charset=3Dus-ascii > >> >> > >> >> This email initiates an L2VPN WG Last Call for: > >> >> > >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 > >> >> > >> >> please comment to the list as to the suitability of this draft > for > >> >> publication as a Standards Track RFC from the L2VPN WG. > >> >> > >> >> this last call will close on Friday 2nd November. > >> >> > >> >> Nabil & Giles > >> > > > From wim.henderickx@alcatel-lucent.com Mon Nov 5 08:14: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 E4BE221F89B0 for ; Mon, 5 Nov 2012 08:14:47 -0800 (PST) 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 WzK3zcjzQ4li for ; Mon, 5 Nov 2012 08:14:47 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id EED1E21F88F0 for ; Mon, 5 Nov 2012 08:14:46 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA5GE8db002911 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Nov 2012 17:14:43 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 5 Nov 2012 17:14:34 +0100 From: "Henderickx, Wim (Wim)" To: Lucy yong , "l2vpn@ietf.org" Date: Mon, 5 Nov 2012 17:14:32 +0100 Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: Ac27cKQvMxW8jLW8Q6S/qmcFTejztQ== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482C632@dfweml505-mbx> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 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, 05 Nov 2012 16:14:48 -0000 -- Snip -- [Lucy] OK. Maybe I did not follow the early requirement discussions. Where was this requirement coming from. MEF Services do not support such service interface. Was this from some operators in IETF? I just like to know a use case if possible. WH> yes this is from operators of which some are on the co-author list. The driver for this is more optimised and scalable implementations. MEF might adopt this going fwd, so we should not make ourselves dependent on MEF -- Snip -- On 05/11/12 11:09, "Lucy yong" wrote: > > >snip >> >[Lucy] My second question is if PE nodes that are multi-homed to a >> same >> >CE may be in different ASes in latter case? Whether yes, or no, it >> should >> >state it out. >>=20 >> WH2> this seems like an odd scenario >[Lucy] agree.=20 >> > >> >> > >> >> >2) in section 4.6, the last paragraph should state a requirement >> for >> >> flow >> >> >based load balance. >> >> >> >> WH> are you saying the Mac based load-balancing is a MUST or are you >> >> saying the MAC based load-balancing should be flow based >> >[Lucy] Text: A solution MAY support multi-homed network with >> >active/active MAC- >> > based load balancing (i.e. different MAC addresses on a VLAN are >> > reachable via different PEs). >> > >> >In section 4.1, it describes options for flow-based load balancing, >> that >> >should apply to here, right? >> >That means the same MAC address may occur on the different PEs too. >> WH2> yes >> > >> >> > >> >> >3) It should add one requirement in supporting Ethernet L2VPN >> across >> >> >multi-Ases >> >> >> >> WH> agreed >> >> > >> >> >4) As the draft mentioned, the new service interfaces are required >> for >> >> DC >> >> >interconnection. If DC uses NVo3 in future, will these service >> >> interfaces >> >> >are still necessary? Suggest giving some use cases where the new >> >> service >> >> >interfaces are necessary in an appendix. >> >> WH> it depends on what use case we have in NVO3: is the NVE >> collocated >> >> with the VM or is the NVE located at a TOR connected to a server. >> >> Depending on the connectivity different solutions might be required >> and >> >> as >> >> such we made the requirement general and not specific since there is >> >> multiple solutions to this and this is a requirements draft rather >> than >> >> solution draft. Use case should be covered in a separate doc. >> >[Lucy] It, I think, is more about cases between DC GW and WAN PE. For >> >example, if NVO3 is used in DC, when we need VLAN aware bundle service >> >interface? Could you give a example? I don't have a problem to make a >> >general requirement, just want know where is the requirement coming >> from. >> > >> >Lucy >>=20 >> WH2> the service interface we are talking about here is how the EVPN >> service is modelled on the DC GW/WAN PE. There are multiple scenarios >> which should be supported. The service interface here is an internal >> modelling of the EVPN on the PE >[Lucy] OK. Maybe I did not follow the early requirement discussions. >Where was this requirement coming from. MEF Services do not support such >service interface. Was this from some operators in IETF? I just like to >know a use case if possible. > >Lucy >> >> > >> >> >Cheers, >> >> >Lucy >> >> > >> >> >> ------------------------------ >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >> >> >> From: Giles Heron >> >> >> To: "l2vpn@ietf.org" >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >> >> >> Content-Type: text/plain; charset=3Dus-ascii >> >> >> >> >> >> This email initiates an L2VPN WG Last Call for: >> >> >> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >> >> >> >> >> >> please comment to the list as to the suitability of this draft >> for >> >> >> publication as a Standards Track RFC from the L2VPN WG. >> >> >> >> >> >> this last call will close on Friday 2nd November. >> >> >> >> >> >> Nabil & Giles >> >> > >> > > From lucy.yong@huawei.com Mon Nov 5 13:00:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90ABD21F8555 for ; Mon, 5 Nov 2012 13:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 sjbXl6aLfpI1 for ; Mon, 5 Nov 2012 13:00:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B900F21F850A for ; Mon, 5 Nov 2012 13:00:01 -0800 (PST) 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 AML31915; Mon, 05 Nov 2012 21:00:00 +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, 5 Nov 2012 20:58:27 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Nov 2012 04:58:31 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 5 Nov 2012 12:58:28 -0800 From: Lucy yong To: "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoA Date: Mon, 5 Nov 2012 20:58:27 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482C7AB@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482C632@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.91.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Mon, 05 Nov 2012 21:00:05 -0000 Wim, I agree that we (IETF) don't have make ourselves dependent on MEF. However,= there are a lot of service providers in MEF to specify Ethernet services a= nd service interfaces. Such service interface has not yet to bring on the t= able there. This may be because the people in two SDOs may be from differen= t orgs.. Thanks, Lucy > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Monday, November 05, 2012 10:15 AM > To: Lucy yong; l2vpn@ietf.org > Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 > -- Snip -- >=20 > [Lucy] OK. Maybe I did not follow the early requirement discussions. > Where > was this requirement coming from. MEF Services do not support such > service > interface. Was this from some operators in IETF? I just like to know a > use > case if possible. >=20 >=20 > WH> yes this is from operators of which some are on the co-author list. > The driver for this is more optimised and scalable implementations. MEF > might adopt this going fwd, so we should not make ourselves dependent > on > MEF >=20 > -- Snip -- >=20 > On 05/11/12 11:09, "Lucy yong" wrote: >=20 > > > > > >snip > >> >[Lucy] My second question is if PE nodes that are multi-homed to a > >> same > >> >CE may be in different ASes in latter case? Whether yes, or no, it > >> should > >> >state it out. > >> > >> WH2> this seems like an odd scenario > >[Lucy] agree. > >> > > >> >> > > >> >> >2) in section 4.6, the last paragraph should state a requirement > >> for > >> >> flow > >> >> >based load balance. > >> >> > >> >> WH> are you saying the Mac based load-balancing is a MUST or are > you > >> >> saying the MAC based load-balancing should be flow based > >> >[Lucy] Text: A solution MAY support multi-homed network with > >> >active/active MAC- > >> > based load balancing (i.e. different MAC addresses on a VLAN are > >> > reachable via different PEs). > >> > > >> >In section 4.1, it describes options for flow-based load balancing, > >> that > >> >should apply to here, right? > >> >That means the same MAC address may occur on the different PEs too. > >> WH2> yes > >> > > >> >> > > >> >> >3) It should add one requirement in supporting Ethernet L2VPN > >> across > >> >> >multi-Ases > >> >> > >> >> WH> agreed > >> >> > > >> >> >4) As the draft mentioned, the new service interfaces are > required > >> for > >> >> DC > >> >> >interconnection. If DC uses NVo3 in future, will these service > >> >> interfaces > >> >> >are still necessary? Suggest giving some use cases where the new > >> >> service > >> >> >interfaces are necessary in an appendix. > >> >> WH> it depends on what use case we have in NVO3: is the NVE > >> collocated > >> >> with the VM or is the NVE located at a TOR connected to a server. > >> >> Depending on the connectivity different solutions might be > required > >> and > >> >> as > >> >> such we made the requirement general and not specific since there > is > >> >> multiple solutions to this and this is a requirements draft > rather > >> than > >> >> solution draft. Use case should be covered in a separate doc. > >> >[Lucy] It, I think, is more about cases between DC GW and WAN PE. > For > >> >example, if NVO3 is used in DC, when we need VLAN aware bundle > service > >> >interface? Could you give a example? I don't have a problem to make > a > >> >general requirement, just want know where is the requirement coming > >> from. > >> > > >> >Lucy > >> > >> WH2> the service interface we are talking about here is how the EVPN > >> service is modelled on the DC GW/WAN PE. There are multiple > scenarios > >> which should be supported. The service interface here is an internal > >> modelling of the EVPN on the PE > >[Lucy] OK. Maybe I did not follow the early requirement discussions. > >Where was this requirement coming from. MEF Services do not support > such > >service interface. Was this from some operators in IETF? I just like > to > >know a use case if possible. > > > >Lucy > >> >> > > >> >> >Cheers, > >> >> >Lucy > >> >> > > >> >> >> ------------------------------ > >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > >> >> >> From: Giles Heron > >> >> >> To: "l2vpn@ietf.org" > >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> > >> >> >> Content-Type: text/plain; charset=3Dus-ascii > >> >> >> > >> >> >> This email initiates an L2VPN WG Last Call for: > >> >> >> > >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 > >> >> >> > >> >> >> please comment to the list as to the suitability of this draft > >> for > >> >> >> publication as a Standards Track RFC from the L2VPN WG. > >> >> >> > >> >> >> this last call will close on Friday 2nd November. > >> >> >> > >> >> >> Nabil & Giles > >> >> > > >> > > > From wim.henderickx@alcatel-lucent.com Mon Nov 5 13:00: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 81BDA21F85B1 for ; Mon, 5 Nov 2012 13:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 icN6yyb9Dnlr for ; Mon, 5 Nov 2012 13:00:26 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5F56421F85AC for ; Mon, 5 Nov 2012 13:00:26 -0800 (PST) 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 qA5KxtVF020221 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Nov 2012 22:00:21 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 5 Nov 2012 22:00:12 +0100 From: "Henderickx, Wim (Wim)" To: Lucy yong , "l2vpn@ietf.org" Date: Mon, 5 Nov 2012 22:00:11 +0100 Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: Ac27mIu1KPc5o7WpQrOFCUe/R+2ceA== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482C7AB@dfweml505-mbx> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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, 05 Nov 2012 21:00:27 -0000 Lucy, sure and this evolution into MEF is most likely to come, but I believe it is a clear req for EVPN, so I believe we can close this point On 05/11/12 15:58, "Lucy yong" wrote: >Wim, > >I agree that we (IETF) don't have make ourselves dependent on MEF. >However, there are a lot of service providers in MEF to specify Ethernet >services and service interfaces. Such service interface has not yet to >bring on the table there. This may be because the people in two SDOs may >be from different orgs.. > >Thanks, >Lucy > >> -----Original Message----- >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >> Sent: Monday, November 05, 2012 10:15 AM >> To: Lucy yong; l2vpn@ietf.org >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >>=20 >> -- Snip -- >>=20 >> [Lucy] OK. Maybe I did not follow the early requirement discussions. >> Where >> was this requirement coming from. MEF Services do not support such >> service >> interface. Was this from some operators in IETF? I just like to know a >> use >> case if possible. >>=20 >>=20 >> WH> yes this is from operators of which some are on the co-author list. >> The driver for this is more optimised and scalable implementations. MEF >> might adopt this going fwd, so we should not make ourselves dependent >> on >> MEF >>=20 >> -- Snip -- >>=20 >> On 05/11/12 11:09, "Lucy yong" wrote: >>=20 >> > >> > >> >snip >> >> >[Lucy] My second question is if PE nodes that are multi-homed to a >> >> same >> >> >CE may be in different ASes in latter case? Whether yes, or no, it >> >> should >> >> >state it out. >> >> >> >> WH2> this seems like an odd scenario >> >[Lucy] agree. >> >> > >> >> >> > >> >> >> >2) in section 4.6, the last paragraph should state a requirement >> >> for >> >> >> flow >> >> >> >based load balance. >> >> >> >> >> >> WH> are you saying the Mac based load-balancing is a MUST or are >> you >> >> >> saying the MAC based load-balancing should be flow based >> >> >[Lucy] Text: A solution MAY support multi-homed network with >> >> >active/active MAC- >> >> > based load balancing (i.e. different MAC addresses on a VLAN are >> >> > reachable via different PEs). >> >> > >> >> >In section 4.1, it describes options for flow-based load balancing, >> >> that >> >> >should apply to here, right? >> >> >That means the same MAC address may occur on the different PEs too. >> >> WH2> yes >> >> > >> >> >> > >> >> >> >3) It should add one requirement in supporting Ethernet L2VPN >> >> across >> >> >> >multi-Ases >> >> >> >> >> >> WH> agreed >> >> >> > >> >> >> >4) As the draft mentioned, the new service interfaces are >> required >> >> for >> >> >> DC >> >> >> >interconnection. If DC uses NVo3 in future, will these service >> >> >> interfaces >> >> >> >are still necessary? Suggest giving some use cases where the new >> >> >> service >> >> >> >interfaces are necessary in an appendix. >> >> >> WH> it depends on what use case we have in NVO3: is the NVE >> >> collocated >> >> >> with the VM or is the NVE located at a TOR connected to a server. >> >> >> Depending on the connectivity different solutions might be >> required >> >> and >> >> >> as >> >> >> such we made the requirement general and not specific since there >> is >> >> >> multiple solutions to this and this is a requirements draft >> rather >> >> than >> >> >> solution draft. Use case should be covered in a separate doc. >> >> >[Lucy] It, I think, is more about cases between DC GW and WAN PE. >> For >> >> >example, if NVO3 is used in DC, when we need VLAN aware bundle >> service >> >> >interface? Could you give a example? I don't have a problem to make >> a >> >> >general requirement, just want know where is the requirement coming >> >> from. >> >> > >> >> >Lucy >> >> >> >> WH2> the service interface we are talking about here is how the EVPN >> >> service is modelled on the DC GW/WAN PE. There are multiple >> scenarios >> >> which should be supported. The service interface here is an internal >> >> modelling of the EVPN on the PE >> >[Lucy] OK. Maybe I did not follow the early requirement discussions. >> >Where was this requirement coming from. MEF Services do not support >> such >> >service interface. Was this from some operators in IETF? I just like >> to >> >know a use case if possible. >> > >> >Lucy >> >> >> > >> >> >> >Cheers, >> >> >> >Lucy >> >> >> > >> >> >> >> ------------------------------ >> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >> >> >> >> From: Giles Heron >> >> >> >> To: "l2vpn@ietf.org" >> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >> >> >> >> Content-Type: text/plain; charset=3Dus-ascii >> >> >> >> >> >> >> >> This email initiates an L2VPN WG Last Call for: >> >> >> >> >> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >> >> >> >> >> >> >> >> please comment to the list as to the suitability of this draft >> >> for >> >> >> >> publication as a Standards Track RFC from the L2VPN WG. >> >> >> >> >> >> >> >> this last call will close on Friday 2nd November. >> >> >> >> >> >> >> >> Nabil & Giles >> >> >> > >> >> > >> > > From internet-drafts@ietf.org Tue Nov 6 07:25: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 AB4E521F8914; Tue, 6 Nov 2012 07:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 nISxtQxArz0R; Tue, 6 Nov 2012 07:25:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9CF21F8958; Tue, 6 Nov 2012 07:25:54 -0800 (PST) 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-inter-domain-redundancy-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106152554.18257.20920.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 07:25:54 -0800 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, 06 Nov 2012 15:25:59 -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 : Redundancy provisioning for VPLS Inter-domain Author(s) : Zhihua Liu Lizhong Jin Ran Chen Dennis Cai Samer Salam Filename : draft-ietf-l2vpn-vpls-inter-domain-redundancy-00.txt Pages : 10 Date : 2012-11-05 Abstract: In many VPLS deployments based on [RFC4762], inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC4762 with node and link redundancy in both domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redunda= ncy There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf-ipr@ietf.org Tue Nov 6 08:28: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 CC66D21F8B09; Tue, 6 Nov 2012 08:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 q3XdbK88P72x; Tue, 6 Nov 2012 08:28:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3799221F8ABF; Tue, 6 Nov 2012 08:28:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: sajassi@cisco.com, ssalam@cisco.com, sboutros@cisco.com, nabil.n.bitar@verizon.com, sam.aldrin@gmail.com Subject: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-l2vpn-trill-evpn-00 X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106162827.987.14764.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 08:28:27 -0800 X-Mailman-Approved-At: Tue, 06 Nov 2012 08:43:16 -0800 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:28:28 -0000 Dear Ali Sajassi, Samer Salam, Sami Boutros, Dr. Nabil N. Bitar, Sam Aldrin: An IPR disclosure that pertains to your Internet-Draft entitled "TRILL-EVP= N" (draft-ietf-l2vpn-trill-evpn) was submitted to the IETF Secretariat on 2012-11-05 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1909/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-l2vpn-trill- evpn-00.""); The IETF Secretariat From ietf-ipr@ietf.org Tue Nov 6 08:43: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 D898B21F879B; Tue, 6 Nov 2012 08:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 qEomaJm6gf2F; Tue, 6 Nov 2012 08:43:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158DB21F8688; Tue, 6 Nov 2012 08:43:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: raggarwa_1@yahoo.com, florin.balus@alcatel-lucent.com, sajassi@cisco.com, wim.henderickx@alcatel-lucent.com, aisaac71@bloomberg.net, uttaro@att.com Subject: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-l2vpn-evpn-02 X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106164324.22481.53590.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 08:43:24 -0800 X-Mailman-Approved-At: Tue, 06 Nov 2012 08:44:01 -0800 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:43:25 -0000 Dear Rahul Aggarwal, Florin Balus, Ali Sajassi, Wim Henderickx, Aldrin Isaa= c, James Uttaro: An IPR disclosure that pertains to your Internet-Draft entitled "BGP MPLS = Based Ethernet VPN" (draft-ietf-l2vpn-evpn) was submitted to the IETF Secretariat= on 2012-11-05 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1910/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-l2vpn-evpn-02= .""); The IETF Secretariat From prvs=6657787dbb=hshah@ciena.com Tue Nov 6 12:04: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 DB12321F8AF3 for ; Tue, 6 Nov 2012 12:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIuHrNLvFrw1 for ; Tue, 6 Nov 2012 12:04:06 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 136A521F8AE5 for ; Tue, 6 Nov 2012 12:04:05 -0800 (PST) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id qA6K0MIR008022 for ; Tue, 6 Nov 2012 15:04:05 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 18f920g1f8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 06 Nov 2012 15:04:04 -0500 Received: from MDWVEXCHHT02.ciena.com (10.4.156.176) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.279.5; Tue, 6 Nov 2012 15:04:05 -0500 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWVEXCHHT02.ciena.com ([10.4.156.176]) with mapi; Tue, 6 Nov 2012 15:04:05 -0500 From: "Shah, Himanshu" To: "l2vpn@ietf.org" Date: Tue, 6 Nov 2012 15:04:03 -0500 Subject: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQ== Message-ID: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-19346.001 X-TM-AS-Result: No--5.710000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-11-06_04:2012-11-05, 2012-11-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211060211 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, 06 Nov 2012 20:04:07 -0000 clarification question: If vlan is the tag used for demux over single PW = and if that vlan needs to be advertised then what is the saving? Is this ju= st saving of the PW label? Himanshu Sent from my iPad= From lucy.yong@huawei.com Wed Nov 7 06:14: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 0BB3921F87DE for ; Wed, 7 Nov 2012 06:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 NFZcfJf90DIY for ; Wed, 7 Nov 2012 06:14:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E72C21F87EA for ; Wed, 7 Nov 2012 06:14:10 -0800 (PST) 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 AMM93732; Wed, 07 Nov 2012 14:14:08 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 14:13:45 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 14:13:56 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 06:13:53 -0800 From: Lucy yong To: "Shah, Himanshu" , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwA Date: Wed, 7 Nov 2012 14:13:52 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> In-Reply-To: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.91.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 07 Nov 2012 14:14:12 -0000 There is a trade-off on the solution. individual BD may have different QoS = requirement, multiplxing them together in a single PW may lose some QoS and= OAM capability. For example, when congestion happens, some BD may work and= some may not, PW status is not able to reflex that properly.=20 Lucy > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Shah, Himanshu > Sent: Tuesday, November 06, 2012 2:04 PM > To: l2vpn@ietf.org > Subject: Vlan-aware bundling over VPLS >=20 > clarification question: If vlan is the tag used for demux over single > PW and if that vlan needs to be advertised then what is the saving? Is > this just saving of the PW label? > Himanshu >=20 > Sent from my iPad From giles.heron@gmail.com Wed Nov 7 06:55: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 3EA2021F880A for ; Wed, 7 Nov 2012 06:55:11 -0800 (PST) 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 DkbZ55+hmMZv for ; Wed, 7 Nov 2012 06:55:10 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88E6B21F87DF for ; Wed, 7 Nov 2012 06:55:10 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1270803pad.31 for ; Wed, 07 Nov 2012 06:55:10 -0800 (PST) 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=TPmgirQkZdvhVI3XMaRTo0TN9gYV5BnDMeQpC7HSj98=; b=gYCdmEhkIMKG+uQcxoxA8pAWWPVRdqdmeI5QWf87geZ5a1lvM0GXFMiqSWt3iIqqee 1lK/QEAf6KSu7YHxLSamcxt4e9IT+fDTNOS8n2Hp6uboOpV+E2bd1jIsgLErEGHZRnRd NyH3kCwk9yGA4YpKOgU1lJUqviic098NTdtZzyEffO1xqTg/5E/UFcuqJEaeiKZqacsa 2ShJ9Xstx7tKA+xaKEU4c+X/SaR+EVlZHPbuiC4smj8gFy4d+lFDKK5hUlrOBasjdnUG d5exlbKJxhBJkKsLxNFp+s/GXY9kjV8KKkO3L3INtZNs3+gWtzzIbng2Ma44bqDWLVlY qn+A== Received: by 10.68.137.198 with SMTP id qk6mr14415272pbb.60.1352300110378; Wed, 07 Nov 2012 06:55:10 -0800 (PST) Received: from sjc-vpn6-941.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id gv9sm14245958pbc.21.2012.11.07.06.55.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:55:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Vlan-aware bundling over VPLS From: Giles Heron In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> Date: Wed, 7 Nov 2012 14:55:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> To: "l2vpn@ietf.org" X-Mailer: Apple Mail (2.1499) 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, 07 Nov 2012 14:55:11 -0000 I'll leave the draft authors to comment on the points raised by Himanshu = and Lucy But I would like SPs to comment as to: 1) whether VLAN-aware bundling is a requirement 2) whether they require VLAN-aware bundling both for VPLS and E-VPN Giles (chair hat firmly on). On 7 Nov 2012, at 14:13, Lucy yong wrote: > There is a trade-off on the solution. individual BD may have different = QoS requirement, multiplxing them together in a single PW may lose some = QoS and OAM capability. For example, when congestion happens, some BD = may work and some may not, PW status is not able to reflex that = properly.=20 >=20 > Lucy >=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >> Of Shah, Himanshu >> Sent: Tuesday, November 06, 2012 2:04 PM >> To: l2vpn@ietf.org >> Subject: Vlan-aware bundling over VPLS >>=20 >> clarification question: If vlan is the tag used for demux over = single >> PW and if that vlan needs to be advertised then what is the saving? = Is >> this just saving of the PW label? >> Himanshu >>=20 >> Sent from my iPad From lucy.yong@huawei.com Wed Nov 7 07:00: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 E678721F8BD4 for ; Wed, 7 Nov 2012 07:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 4AQFGmABsDZH for ; Wed, 7 Nov 2012 07:00:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 329BF21F87B8 for ; Wed, 7 Nov 2012 07:00:23 -0800 (PST) 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 ALH78450; Wed, 07 Nov 2012 15:00:20 +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; Wed, 7 Nov 2012 14:59:10 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 22:59:20 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 06:59:16 -0800 From: Lucy yong To: Giles Heron , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABJ1ZIAAELeVsA== Date: Wed, 7 Nov 2012 14:59:15 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482CEA7@dfweml505-mbx> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com> In-Reply-To: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.91.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 07 Nov 2012 15:00:25 -0000 Hi Giles, Thank you to raise this question.=20 In fact, I raised this question in the E-VPN req. last call. I like see som= e answer from SPs and a use case. Lucy=20 > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Wednesday, November 07, 2012 8:55 AM > To: l2vpn@ietf.org > Cc: Himanshu Shah; Lucy yong; Nabil Bitar > Subject: Re: Vlan-aware bundling over VPLS >=20 > I'll leave the draft authors to comment on the points raised by > Himanshu and Lucy >=20 > But I would like SPs to comment as to: > 1) whether VLAN-aware bundling is a requirement > 2) whether they require VLAN-aware bundling both for VPLS and E-VPN >=20 > Giles (chair hat firmly on). >=20 > On 7 Nov 2012, at 14:13, Lucy yong wrote: >=20 > > There is a trade-off on the solution. individual BD may have > different QoS requirement, multiplxing them together in a single PW may > lose some QoS and OAM capability. For example, when congestion happens, > some BD may work and some may not, PW status is not able to reflex that > properly. > > > > Lucy > > > >> -----Original Message----- > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >> Of Shah, Himanshu > >> Sent: Tuesday, November 06, 2012 2:04 PM > >> To: l2vpn@ietf.org > >> Subject: Vlan-aware bundling over VPLS > >> > >> clarification question: If vlan is the tag used for demux over > single > >> PW and if that vlan needs to be advertised then what is the saving? > Is > >> this just saving of the PW label? > >> Himanshu > >> > >> Sent from my iPad From josh.rogers@twcable.com Wed Nov 7 07:09: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 6840D21F8B14 for ; Wed, 7 Nov 2012 07:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[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 CPl2fn07wai7 for ; Wed, 7 Nov 2012 07:09:23 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6980521F89F5 for ; Wed, 7 Nov 2012 07:09:23 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,730,1344225600"; d="scan'208";a="466428168" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Nov 2012 10:05:54 -0500 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 7 Nov 2012 10:06:35 -0500 From: "Rogers, Josh" To: Giles Heron , "l2vpn@ietf.org" Date: Wed, 7 Nov 2012 10:06:35 -0500 Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28+Xpr7Sgs3hovR7GIPNgA4k1V6A== Message-ID: In-Reply-To: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 07 Nov 2012 15:09:24 -0000 1) for us, not currently. However, I understand the proposed benefit and how it could be leveraged, and believe it _may_ become a needed feature in the future. We don't see use cases that would benefit from this approach _today_ though. 2) I would be inclined to say that if it is available in VPLS, I'd like to see it in E-VPN (although the converse is not necessarily true) -Josh On 11/7/12 8:55 AM, "Giles Heron" wrote: >I'll leave the draft authors to comment on the points raised by Himanshu >and Lucy > >But I would like SPs to comment as to: >1) whether VLAN-aware bundling is a requirement >2) whether they require VLAN-aware bundling both for VPLS and E-VPN > >Giles (chair hat firmly on). > >On 7 Nov 2012, at 14:13, Lucy yong wrote: > >> There is a trade-off on the solution. individual BD may have different >>QoS requirement, multiplxing them together in a single PW may lose some >>QoS and OAM capability. For example, when congestion happens, some BD >>may work and some may not, PW status is not able to reflex that >>properly. >> >> Lucy >> >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Shah, Himanshu >>> Sent: Tuesday, November 06, 2012 2:04 PM >>> To: l2vpn@ietf.org >>> Subject: Vlan-aware bundling over VPLS >>> >>> clarification question: If vlan is the tag used for demux over single >>> PW and if that vlan needs to be advertised then what is the saving? Is >>> this just saving of the PW label? >>> Himanshu >>> >>> Sent from my iPad > 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 sajassi@cisco.com Wed Nov 7 08:12: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 9CFA821F8C8C for ; Wed, 7 Nov 2012 08:12:06 -0800 (PST) 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 LA1AXKfbUnXN for ; Wed, 7 Nov 2012 08:12:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D754F21F8C8B for ; Wed, 7 Nov 2012 08:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3300; q=dns/txt; s=iport; t=1352304725; x=1353514325; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=A+CIcxBCo5L7gByrY536zUAaA1liHloZesS8cYVdHOY=; b=HjMaNMIUVDj3FCZSKVvrU32n6Mmj38hxexU2LnAfnng6CB4aNow6BacS pZK3ZzoIz8SA89W/xRp/2pTBWeVp6NpGJpDJVrEqI1hic8Jra61hiLqLF hJmCusZz71e25aVhvD+xdcnTjfnqWeBtt8YV3e53xBS0NApDR73+ECy4g I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPeHmlCtJV2d/2dsb2JhbABEgmzAdIEIgh4BAQEEEgFfEwYBCBEEAQEBCh0oERQJCAEBBAESCBMHh1YDDwGcLZZEDYlUiyRpGoVMYQOUJo0IgyaBa4JvgWQXHg X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="139816755" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2012 16:11:58 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA7GBvoF024027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 16:11:57 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 10:11:57 -0600 From: "Ali Sajassi (sajassi)" To: "Rogers, Josh" , Giles Heron , "l2vpn@ietf.org" Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAAA5EgoAAAGbRgP//rbKA Date: Wed, 7 Nov 2012 16:11:57 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7A022D@xmb-aln-x13.cisco.com> 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.118.42] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--45.641700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 07 Nov 2012 16:12:06 -0000 I am not a co-author of this draft but let me give you my 2 cents =8A Currently VPLS supports only VLAN-based and VLAN bundle service per RFC 4762 sec. 7.2 (that I helped with its writeup). In E-VPN, we introduce a new service called VLAN-aware bundle service which allows to have multiple bridge domains within the same VPN instance (e.g., EVI in EVPN). I think the primary purpose of this draft is to allow for such service which I believe many of the existing switches (from different vendors) support already. This helps with PW scale and avoids having a full-mesh of PWs per VLAN. The secondary purpose of it (I believe) is to provide VLAN pruning using LDP signaling and that's why during the meeting I made the comment that this needs to be a "SHOULD" or "MAY" as opposed to a "MUST". Cheers, Ali =20 On 11/7/12 10:06 AM, "Rogers, Josh" wrote: >1) for us, not currently. However, I understand the proposed benefit and >how it could be leveraged, and believe it _may_ become a needed feature in >the future. We don't see use cases that would benefit from this approach >_today_ though. >2) I would be inclined to say that if it is available in VPLS, I'd like to >see it in E-VPN (although the converse is not necessarily true) > >-Josh > > >On 11/7/12 8:55 AM, "Giles Heron" wrote: > >>I'll leave the draft authors to comment on the points raised by Himanshu >>and Lucy >> >>But I would like SPs to comment as to: >>1) whether VLAN-aware bundling is a requirement >>2) whether they require VLAN-aware bundling both for VPLS and E-VPN >> >>Giles (chair hat firmly on). >> >>On 7 Nov 2012, at 14:13, Lucy yong wrote: >> >>> There is a trade-off on the solution. individual BD may have different >>>QoS requirement, multiplxing them together in a single PW may lose some >>>QoS and OAM capability. For example, when congestion happens, some BD >>>may work and some may not, PW status is not able to reflex that >>>properly. >>> >>> Lucy >>> >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>> Of Shah, Himanshu >>>> Sent: Tuesday, November 06, 2012 2:04 PM >>>> To: l2vpn@ietf.org >>>> Subject: Vlan-aware bundling over VPLS >>>> >>>> clarification question: If vlan is the tag used for demux over >>>>single >>>> PW and if that vlan needs to be advertised then what is the saving? Is >>>> this just saving of the PW label? >>>> Himanshu >>>> >>>> Sent from my iPad >> > > >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 xuxiaohu@huawei.com Wed Nov 7 08:30:36 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 3120E21F8BCE for ; Wed, 7 Nov 2012 08:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 t5clMd3EWNtU for ; Wed, 7 Nov 2012 08:30:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D32C521F8B4D for ; Wed, 7 Nov 2012 08:30:34 -0800 (PST) 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 ALH84799; Wed, 07 Nov 2012 16:30:33 +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; Wed, 7 Nov 2012 16:29:40 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 16:29:49 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.161]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 00:29:46 +0800 From: Xuxiaohu To: "Rogers, Josh" , Giles Heron , "l2vpn@ietf.org" Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwA//+HcoCAAAM3gIAAmXbW Date: Wed, 7 Nov 2012 16:29:46 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FD76@szxeml525-mbx.china.huawei.com> References: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.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.47.128.213] Content-Type: text/plain; charset="gb2312" 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: Wed, 07 Nov 2012 16:30:36 -0000 V2hlbiBtdWx0aXBsZSBjdXN0b21lciBWTEFOcyBhcmUgYm91bmRsZWQgdG8gYSBzaW5nbGUgVlBM UyBpbnN0YW5jZSBvciBFVlBOIGluc3RhbmNlLCBpdCdkIGJldHRlciB0byBrZWVwIHRoZSBicm9h ZGNhc3QgZG9tYWluIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGN1c3RvbWVyIFZMQU4gc2VwYXJhdGVk IGZyb20gZWFjaCBvdGhlci4gVGhlIG9idmlvdXMgYmVuZWZpdHMgb2Ygc3VjaCBjaG9pY2UgaW5j bHVkZTogMSkgc3VwcG9ydCBvdmVybGFwcGluZyBNQUMgYWRkcmVzcyBzcGFjZXMgYWNyb3NzIGRp ZmZlcmVudCBjdXN0b21lciBWTEFOcyBhbmQgYXZvaWQgdW5uZWNjZXNzYXJ5IE1BQyB3aXRoZHJh d2FsIGluIHN1Y2ggY2FzZTsgMikgYXZvaWQgdGhlIHVubmVjY2Vzc2FyeSBmbG9vZCBvZiBCVU0g dHJhZmZpYyBvZiBhIGdpdmVuIGN1c3RvbWVyIFZMQU4gdG8gdGhvc2UgUEVzIHdoaWNoIGFyZSBu b3QgYXR0YWNoZWQgd2l0aCB0aGF0IGN1c3RvbWVyIFZMQU4geWV0Lg0KDQpPbmUgcG9zc2libGUg dXNlIGNhc2UgaXMgdGhlIENTQyBzY2VuYXJpby4NCg0KWGlhb2h1DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb2dlcnMsIEpvc2ggW2pvc2gucm9nZXJz QHR3Y2FibGUuY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jEx1MI3yNUgMjM6MDYNCrW9OiBHaWxlcyBI ZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCtb3zOI6IFJlOiBWbGFuLWF3YXJlIGJ1bmRsaW5nIG92ZXIg VlBMUw0KDQoxKSBmb3IgdXMsIG5vdCBjdXJyZW50bHkuICBIb3dldmVyLCBJIHVuZGVyc3RhbmQg dGhlIHByb3Bvc2VkIGJlbmVmaXQgYW5kDQpob3cgaXQgY291bGQgYmUgbGV2ZXJhZ2VkLCBhbmQg YmVsaWV2ZSBpdCBfbWF5XyBiZWNvbWUgYSBuZWVkZWQgZmVhdHVyZSBpbg0KdGhlIGZ1dHVyZS4g IFdlIGRvbid0IHNlZSB1c2UgY2FzZXMgdGhhdCB3b3VsZCBiZW5lZml0IGZyb20gdGhpcyBhcHBy b2FjaA0KX3RvZGF5XyB0aG91Z2guDQoyKSBJIHdvdWxkIGJlIGluY2xpbmVkIHRvIHNheSB0aGF0 IGlmIGl0IGlzIGF2YWlsYWJsZSBpbiBWUExTLCBJJ2QgbGlrZSB0bw0Kc2VlIGl0IGluIEUtVlBO IChhbHRob3VnaCB0aGUgY29udmVyc2UgaXMgbm90IG5lY2Vzc2FyaWx5IHRydWUpDQoNCi1Kb3No DQoNCg0KT24gMTEvNy8xMiA4OjU1IEFNLCAiR2lsZXMgSGVyb24iIDxnaWxlcy5oZXJvbkBnbWFp bC5jb20+IHdyb3RlOg0KDQo+SSdsbCBsZWF2ZSB0aGUgZHJhZnQgYXV0aG9ycyB0byBjb21tZW50 IG9uIHRoZSBwb2ludHMgcmFpc2VkIGJ5IEhpbWFuc2h1DQo+YW5kIEx1Y3kNCj4NCj5CdXQgSSB3 b3VsZCBsaWtlIFNQcyB0byBjb21tZW50IGFzIHRvOg0KPjEpIHdoZXRoZXIgVkxBTi1hd2FyZSBi dW5kbGluZyBpcyBhIHJlcXVpcmVtZW50DQo+Mikgd2hldGhlciB0aGV5IHJlcXVpcmUgVkxBTi1h d2FyZSBidW5kbGluZyBib3RoIGZvciBWUExTIGFuZCBFLVZQTg0KPg0KPkdpbGVzIChjaGFpciBo YXQgZmlybWx5IG9uKS4NCj4NCj5PbiA3IE5vdiAyMDEyLCBhdCAxNDoxMywgTHVjeSB5b25nIDxs dWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+PiBUaGVyZSBpcyBhIHRyYWRlLW9mZiBv biB0aGUgc29sdXRpb24uIGluZGl2aWR1YWwgQkQgbWF5IGhhdmUgZGlmZmVyZW50DQo+PlFvUyBy ZXF1aXJlbWVudCwgbXVsdGlwbHhpbmcgdGhlbSB0b2dldGhlciBpbiBhIHNpbmdsZSBQVyBtYXkg bG9zZSBzb21lDQo+PlFvUyBhbmQgT0FNIGNhcGFiaWxpdHkuIEZvciBleGFtcGxlLCB3aGVuIGNv bmdlc3Rpb24gaGFwcGVucywgc29tZSBCRA0KPj5tYXkgd29yayBhbmQgc29tZSBtYXkgbm90LCBQ VyBzdGF0dXMgaXMgbm90IGFibGUgdG8gcmVmbGV4IHRoYXQNCj4+cHJvcGVybHkuDQo+Pg0KPj4g THVjeQ0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IGwydnBu LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYNCj4+PiBPZiBTaGFoLCBIaW1hbnNodQ0KPj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA2 LCAyMDEyIDI6MDQgUE0NCj4+PiBUbzogbDJ2cG5AaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBWbGFu LWF3YXJlIGJ1bmRsaW5nIG92ZXIgVlBMUw0KPj4+DQo+Pj4gY2xhcmlmaWNhdGlvbiBxdWVzdGlv bjogICBJZiB2bGFuIGlzIHRoZSB0YWcgdXNlZCBmb3IgZGVtdXggb3ZlciBzaW5nbGUNCj4+PiBQ VyBhbmQgaWYgdGhhdCB2bGFuIG5lZWRzIHRvIGJlIGFkdmVydGlzZWQgdGhlbiB3aGF0IGlzIHRo ZSBzYXZpbmc/IElzDQo+Pj4gdGhpcyBqdXN0IHNhdmluZyBvZiB0aGUgUFcgbGFiZWw/DQo+Pj4g SGltYW5zaHUNCj4+Pg0KPj4+IFNlbnQgZnJvbSBteSBpUGFkDQo+DQoNCg0KVGhpcyBFLW1haWwg YW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUg cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlh bCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxl LiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBh Y3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50 cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3Jp Z2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQu From giles.heron@gmail.com Wed Nov 7 09:45: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 27DF021F8C56 for ; Wed, 7 Nov 2012 09:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 E1IN0X8fAr2G for ; Wed, 7 Nov 2012 09:45:20 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63CFE21F8B6C for ; Wed, 7 Nov 2012 09:45:20 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1385143pad.31 for ; Wed, 07 Nov 2012 09:45:20 -0800 (PST) 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=mrKDxRcQFMV4k/e8Kw8EKHbiTI4qByvbxx5+I0j0h6o=; b=Uu69edg+AWOQJVDFnPJuGsNhX9zCwdvMjmpnBk981EEZLDjdSQWos+v6lB0nYCr4SE 10Ro21ljEw5aBkc2Lh/Bk7NYndgO2Lef2zr9nfPHut56lihIwZNBxARNYGk5OhXN6YMm yWpejRxzaz9cm5dANR2gUwyIPTYvem6WqxwBfY63pHBfLn/WOg4OJH3mm/jJUHO8E/Vm 8ICIMhh7NbjuzRoNTWYj5PIp/uU3qBQie1sZibH+Bgh7cj2antqH91pQQ2Oq2KgVl0+1 iZHU6VYkvqDjIV4RbzwaDmkHyljlSM/pJi0/0b/Ct2dClDkgPAhbuTmk7nlT+X6Midyc 7eFg== Received: by 10.68.252.133 with SMTP id zs5mr15656483pbc.152.1352310320226; Wed, 07 Nov 2012 09:45:20 -0800 (PST) Received: from sjc-vpn6-1672.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id is6sm14437412pbc.55.2012.11.07.09.45.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 09:45:19 -0800 (PST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Vlan-aware bundling over VPLS From: Giles Heron In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FD76@szxeml525-mbx.china.huawei.com> Date: Wed, 7 Nov 2012 17:45:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7370AA55-0673-4F03-B4C2-783553C6387F@gmail.com> References: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FD76@szxeml525-mbx.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1499) 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, 07 Nov 2012 17:45:21 -0000 Hi Xiaohu, I think we all understand the potential benefits of VLAN-aware bundling. = But of course nothing comes for free ;) And it still remains for SPs to give more feedback on my questions... What's your thinking on CSC? Giles On 7 Nov 2012, at 16:29, Xuxiaohu wrote: > When multiple customer VLANs are boundled to a single VPLS instance or = EVPN instance, it'd better to keep the broadcast domain associated with = each customer VLAN separated from each other. The obvious benefits of = such choice include: 1) support overlapping MAC address spaces across = different customer VLANs and avoid unneccessary MAC withdrawal in such = case; 2) avoid the unneccessary flood of BUM traffic of a given customer = VLAN to those PEs which are not attached with that customer VLAN yet. >=20 > One possible use case is the CSC scenario. >=20 > Xiaohu >=20 > ________________________________________ > =B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = =B4=FA=B1=ED Rogers, Josh [josh.rogers@twcable.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C27=C8=D5 23:06 > =B5=BD: Giles Heron; l2vpn@ietf.org > =D6=F7=CC=E2: Re: Vlan-aware bundling over VPLS >=20 > 1) for us, not currently. However, I understand the proposed benefit = and > how it could be leveraged, and believe it _may_ become a needed = feature in > the future. We don't see use cases that would benefit from this = approach > _today_ though. > 2) I would be inclined to say that if it is available in VPLS, I'd = like to > see it in E-VPN (although the converse is not necessarily true) >=20 > -Josh >=20 >=20 > On 11/7/12 8:55 AM, "Giles Heron" wrote: >=20 >> I'll leave the draft authors to comment on the points raised by = Himanshu >> and Lucy >>=20 >> But I would like SPs to comment as to: >> 1) whether VLAN-aware bundling is a requirement >> 2) whether they require VLAN-aware bundling both for VPLS and E-VPN >>=20 >> Giles (chair hat firmly on). >>=20 >> On 7 Nov 2012, at 14:13, Lucy yong wrote: >>=20 >>> There is a trade-off on the solution. individual BD may have = different >>> QoS requirement, multiplxing them together in a single PW may lose = some >>> QoS and OAM capability. For example, when congestion happens, some = BD >>> may work and some may not, PW status is not able to reflex that >>> properly. >>>=20 >>> Lucy >>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >>>> Of Shah, Himanshu >>>> Sent: Tuesday, November 06, 2012 2:04 PM >>>> To: l2vpn@ietf.org >>>> Subject: Vlan-aware bundling over VPLS >>>>=20 >>>> clarification question: If vlan is the tag used for demux over = single >>>> PW and if that vlan needs to be advertised then what is the saving? = Is >>>> this just saving of the PW label? >>>> Himanshu >>>>=20 >>>> Sent from my iPad >>=20 >=20 >=20 > 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 sboutros@cisco.com Wed Nov 7 10:21: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 C05E721F8C41 for ; Wed, 7 Nov 2012 10:21:24 -0800 (PST) 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 I9fhDE12mkNI for ; Wed, 7 Nov 2012 10:21:24 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CA76B21F8C3D for ; Wed, 7 Nov 2012 10:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=592; q=dns/txt; s=iport; t=1352312483; x=1353522083; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e/krXwIRdth+U50ecTng3c3oZwEO2aFNKGSY3MtFoZA=; b=h8RI1qsnJ4N7+DmMSdBZ3vwe6QjXsu/7mNugfhp1EA82O3Oouenc4s6C 3oax//paKOeWVpV60FCcUq4lUHkoYOYTJq/Pmpg50ssN1EVsQSz9j554K BLhxwa8leR+osdRWGYdWTXU5vQNQ3t7zVDp/B9cU6NGqeyv+nqkD/jZZt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEilmlCtJV2c/2dsb2JhbABEw2OBCIIeAQEBAwESASc/BQsCAQgiFBAyJQEBBA4NGodiBpxBoDGMDYVmYQOkVIFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,731,1344211200"; d="scan'208";a="139833100" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2012 18:21:22 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA7ILMwI006947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 18:21:22 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 12:21:21 -0600 From: "Sami Boutros (sboutros)" To: "Shah, Himanshu" Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQA7RrMA Date: Wed, 7 Nov 2012 18:21:21 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F10E7601AD@xmb-rcd-x08.cisco.com> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> In-Reply-To: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.218.131] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--31.610000-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: <27613105295028429813D543C509D8B9@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: Wed, 07 Nov 2012 18:21:24 -0000 As discussed Himanshu We have only one binding that we advertise regardless of the # of Vlans, th= e Vlans are signaled using the vector TLV, in which each Vlan is presented = by a bit.=20 So the saving is not only a label, but as well in control plane we have one= message binding. Thanks, Sami On Nov 6, 2012, at 12:04 PM, Shah, Himanshu wrote: > clarification question: If vlan is the tag used for demux over single P= W and if that vlan needs to be advertised then what is the saving? Is this = just saving of the PW label? > Himanshu >=20 > Sent from my iPad From xuxiaohu@huawei.com Wed Nov 7 10:21:40 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 000BD21F8C21 for ; Wed, 7 Nov 2012 10:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 w-Dfh7pQ-G6G for ; Wed, 7 Nov 2012 10:21:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAEC21F8B99 for ; Wed, 7 Nov 2012 10:21:37 -0800 (PST) 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 ALH90750; Wed, 07 Nov 2012 18:21:35 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 18:21:24 +0000 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 18:21:34 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.161]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 02:21:28 +0800 From: Xuxiaohu To: Giles Heron Subject: re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwA//+HcoCAAAM3gIAAmXbW//+S4ACAAIpvsQ== Date: Wed, 7 Nov 2012 18:21:28 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FE41@szxeml525-mbx.china.huawei.com> References: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FD76@szxeml525-mbx.china.huawei.com>, <7370AA55-0673-4F03-B4C2-783553C6387F@gmail.com> In-Reply-To: <7370AA55-0673-4F03-B4C2-783553C6387F@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.224] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 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, 07 Nov 2012 18:21:40 -0000 SW4gdGhlIENTQyBjYXNlLCB0aGUgdGllci0xIGNhcnJpZXIgKFZQTFMgU1ApIGFzc2lnbnMgYSBz aW5nbGUgVlBMUyBpbnN0YW5jZSB0byBhIGdpdmVuIHRpZXItMiBjYXJyaWVyIChlLmcuLCBjbG91 ZCBkYXRhIGNlbnRlciBTUCB3aGljaCB1c2VzIFRSSUxMIHdpdGhpbiBpdHMgZGF0YSBjZW50ZXJz KSB3aGljaCBpbiB0dXJuIHVzZSBWTEFOcyB0byBpZGVudGlmeSBpdHMgZGlmZmVyZW50IGN1c3Rv bWVycywgZm9yIHRoZSBwdXJwb3NlIG9mIGRhdGEgY2VudGVyIGludGVyY29ubmVjdC4gSW4gdGhp cyBjYXNlLCBpdCBtYXkgYmUgaGFyZCBmb3IgdGhlIHRpZXItMiBjYXJyaWVyIHRvIGVuc3VyZSB0 aGVyZSBpcyBubyBNQUMgYWRkcmVzcyBvdmVybGFwcGluZyBhY3Jvc3MgbXVsdGlwbGUgY3VzdG9t ZXIgVkxBTnMgb2YgaXRzIGRpZmZlcmVudCBjdXN0b21lcnMvdGVuYW50cy4gSW4gYWRkaXRpb24s IHRoZSB2aXJ0dWFsIG5ldHdvcmsgdG9wb2xvZ2llcyAoaS5lLiwgUEUgcm91dGVycyB0byB3aGlj aCBhIGdpdmVuIGN1c3RvbWVyL3RlbmFudCBWTEFOIGlzIGF0dGFjaGVkKSBvZiBkaWZmZXJlbnQg Y3VzdG9tZXJzL3RlbmFudHMgb2YgdGhlIGdpdmVuIHRpZXItMiBjYXJyaWVyIGFyZSB1c3VhbGx5 IGRpZmZlcmVudC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogR2lsZXMgSGVyb24gW2dpbGVzLmhlcm9u QGdtYWlsLmNvbV0NCreiy83KsbzkOiAyMDEyxOoxMdTCOMjVIDE6NDUNCrW9OiBYdXhpYW9odQ0K Q2M6IFJvZ2VycywgSm9zaDsgbDJ2cG5AaWV0Zi5vcmcNCtb3zOI6IFJlOiBWbGFuLWF3YXJlIGJ1 bmRsaW5nIG92ZXIgVlBMUw0KDQpIaSBYaWFvaHUsDQoNCkkgdGhpbmsgd2UgYWxsIHVuZGVyc3Rh bmQgdGhlIHBvdGVudGlhbCBiZW5lZml0cyBvZiBWTEFOLWF3YXJlIGJ1bmRsaW5nLiAgQnV0IG9m IGNvdXJzZSBub3RoaW5nIGNvbWVzIGZvciBmcmVlIDspDQoNCkFuZCBpdCBzdGlsbCByZW1haW5z IGZvciBTUHMgdG8gZ2l2ZSBtb3JlIGZlZWRiYWNrIG9uIG15IHF1ZXN0aW9ucy4uLg0KDQpXaGF0 J3MgeW91ciB0aGlua2luZyBvbiBDU0M/DQoNCkdpbGVzDQoNCk9uIDcgTm92IDIwMTIsIGF0IDE2 OjI5LCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj4gV2hlbiBtdWx0 aXBsZSBjdXN0b21lciBWTEFOcyBhcmUgYm91bmRsZWQgdG8gYSBzaW5nbGUgVlBMUyBpbnN0YW5j ZSBvciBFVlBOIGluc3RhbmNlLCBpdCdkIGJldHRlciB0byBrZWVwIHRoZSBicm9hZGNhc3QgZG9t YWluIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGN1c3RvbWVyIFZMQU4gc2VwYXJhdGVkIGZyb20gZWFj aCBvdGhlci4gVGhlIG9idmlvdXMgYmVuZWZpdHMgb2Ygc3VjaCBjaG9pY2UgaW5jbHVkZTogMSkg c3VwcG9ydCBvdmVybGFwcGluZyBNQUMgYWRkcmVzcyBzcGFjZXMgYWNyb3NzIGRpZmZlcmVudCBj dXN0b21lciBWTEFOcyBhbmQgYXZvaWQgdW5uZWNjZXNzYXJ5IE1BQyB3aXRoZHJhd2FsIGluIHN1 Y2ggY2FzZTsgMikgYXZvaWQgdGhlIHVubmVjY2Vzc2FyeSBmbG9vZCBvZiBCVU0gdHJhZmZpYyBv ZiBhIGdpdmVuIGN1c3RvbWVyIFZMQU4gdG8gdGhvc2UgUEVzIHdoaWNoIGFyZSBub3QgYXR0YWNo ZWQgd2l0aCB0aGF0IGN1c3RvbWVyIFZMQU4geWV0Lg0KPg0KPiBPbmUgcG9zc2libGUgdXNlIGNh c2UgaXMgdGhlIENTQyBzY2VuYXJpby4NCj4NCj4gWGlhb2h1DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYu b3JnIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvZ2VycywgSm9zaCBbam9zaC5yb2dl cnNAdHdjYWJsZS5jb21dDQo+ILeiy83KsbzkOiAyMDEyxOoxMdTCN8jVIDIzOjA2DQo+ILW9OiBH aWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFZsYW4tYXdhcmUgYnVuZGxp bmcgb3ZlciBWUExTDQo+DQo+IDEpIGZvciB1cywgbm90IGN1cnJlbnRseS4gIEhvd2V2ZXIsIEkg dW5kZXJzdGFuZCB0aGUgcHJvcG9zZWQgYmVuZWZpdCBhbmQNCj4gaG93IGl0IGNvdWxkIGJlIGxl dmVyYWdlZCwgYW5kIGJlbGlldmUgaXQgX21heV8gYmVjb21lIGEgbmVlZGVkIGZlYXR1cmUgaW4N Cj4gdGhlIGZ1dHVyZS4gIFdlIGRvbid0IHNlZSB1c2UgY2FzZXMgdGhhdCB3b3VsZCBiZW5lZml0 IGZyb20gdGhpcyBhcHByb2FjaA0KPiBfdG9kYXlfIHRob3VnaC4NCj4gMikgSSB3b3VsZCBiZSBp bmNsaW5lZCB0byBzYXkgdGhhdCBpZiBpdCBpcyBhdmFpbGFibGUgaW4gVlBMUywgSSdkIGxpa2Ug dG8NCj4gc2VlIGl0IGluIEUtVlBOIChhbHRob3VnaCB0aGUgY29udmVyc2UgaXMgbm90IG5lY2Vz c2FyaWx5IHRydWUpDQo+DQo+IC1Kb3NoDQo+DQo+DQo+IE9uIDExLzcvMTIgODo1NSBBTSwgIkdp bGVzIEhlcm9uIiA8Z2lsZXMuaGVyb25AZ21haWwuY29tPiB3cm90ZToNCj4NCj4+IEknbGwgbGVh dmUgdGhlIGRyYWZ0IGF1dGhvcnMgdG8gY29tbWVudCBvbiB0aGUgcG9pbnRzIHJhaXNlZCBieSBI aW1hbnNodQ0KPj4gYW5kIEx1Y3kNCj4+DQo+PiBCdXQgSSB3b3VsZCBsaWtlIFNQcyB0byBjb21t ZW50IGFzIHRvOg0KPj4gMSkgd2hldGhlciBWTEFOLWF3YXJlIGJ1bmRsaW5nIGlzIGEgcmVxdWly ZW1lbnQNCj4+IDIpIHdoZXRoZXIgdGhleSByZXF1aXJlIFZMQU4tYXdhcmUgYnVuZGxpbmcgYm90 aCBmb3IgVlBMUyBhbmQgRS1WUE4NCj4+DQo+PiBHaWxlcyAoY2hhaXIgaGF0IGZpcm1seSBvbiku DQo+Pg0KPj4gT24gNyBOb3YgMjAxMiwgYXQgMTQ6MTMsIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1 YXdlaS5jb20+IHdyb3RlOg0KPj4NCj4+PiBUaGVyZSBpcyBhIHRyYWRlLW9mZiBvbiB0aGUgc29s dXRpb24uIGluZGl2aWR1YWwgQkQgbWF5IGhhdmUgZGlmZmVyZW50DQo+Pj4gUW9TIHJlcXVpcmVt ZW50LCBtdWx0aXBseGluZyB0aGVtIHRvZ2V0aGVyIGluIGEgc2luZ2xlIFBXIG1heSBsb3NlIHNv bWUNCj4+PiBRb1MgYW5kIE9BTSBjYXBhYmlsaXR5LiBGb3IgZXhhbXBsZSwgd2hlbiBjb25nZXN0 aW9uIGhhcHBlbnMsIHNvbWUgQkQNCj4+PiBtYXkgd29yayBhbmQgc29tZSBtYXkgbm90LCBQVyBz dGF0dXMgaXMgbm90IGFibGUgdG8gcmVmbGV4IHRoYXQNCj4+PiBwcm9wZXJseS4NCj4+Pg0KPj4+ IEx1Y3kNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBs MnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQo+Pj4+IE9mIFNoYWgsIEhpbWFuc2h1DQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDA2LCAyMDEyIDI6MDQgUE0NCj4+Pj4gVG86IGwydnBuQGlldGYub3JnDQo+Pj4+IFN1Ympl Y3Q6IFZsYW4tYXdhcmUgYnVuZGxpbmcgb3ZlciBWUExTDQo+Pj4+DQo+Pj4+IGNsYXJpZmljYXRp b24gcXVlc3Rpb246ICAgSWYgdmxhbiBpcyB0aGUgdGFnIHVzZWQgZm9yIGRlbXV4IG92ZXIgc2lu Z2xlDQo+Pj4+IFBXIGFuZCBpZiB0aGF0IHZsYW4gbmVlZHMgdG8gYmUgYWR2ZXJ0aXNlZCB0aGVu IHdoYXQgaXMgdGhlIHNhdmluZz8gSXMNCj4+Pj4gdGhpcyBqdXN0IHNhdmluZyBvZiB0aGUgUFcg bGFiZWw/DQo+Pj4+IEhpbWFuc2h1DQo+Pj4+DQo+Pj4+IFNlbnQgZnJvbSBteSBpUGFkDQo+Pg0K Pg0KPg0KPiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJp dmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcg dG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmli dXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVu dHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFu ZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5k IGFueSBwcmludG91dC4= From giles.heron@gmail.com Wed Nov 7 10:25: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 D0EFC21F8BDA for ; Wed, 7 Nov 2012 10:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 oPeyJhO0gdRf for ; Wed, 7 Nov 2012 10:25:28 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 308A021F8BC7 for ; Wed, 7 Nov 2012 10:25:28 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1411271pad.31 for ; Wed, 07 Nov 2012 10:25:28 -0800 (PST) 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=9mdRGvp/sO5Igv4L7ieNMawQIcluvONb/Xve4Q3YMf8=; b=029dilvQHWCXXx5kKScDVNLQA92ibgKtGBCujveo59Fx34sAB2lzOUipdSCSWhCZGv xYFan+kExVQBiuop3ctBIw21ommt3GyMBrihKgo75358EMVw9aLO4VhWUCLEZZqtu7TM xkl+hpn3UdzqOgcK62VEHAn/IxnIs0OwTfVZTGsh2bvItzJSJH5VPV2WvNMT3oEHW2Qq e2bmp6Sc1U3Jm7zXmfXyF6mONbSfQrN2ihWXo6OveKP46DAFScoYLl6qvEwsZoiiCfY0 YPS6sJ/ptLAxeH9abadvOmlqJHE5ktYOyFbA6emx9pjRMfYWrFhZzQk7d7OXc8lnAC8+ fYxQ== Received: by 10.68.189.5 with SMTP id ge5mr16243476pbc.1.1352312727879; Wed, 07 Nov 2012 10:25:27 -0800 (PST) Received: from sjc-vpn6-1054.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id k9sm14645359paz.22.2012.11.07.10.25.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 10:25:27 -0800 (PST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Vlan-aware bundling over VPLS From: Giles Heron In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FE41@szxeml525-mbx.china.huawei.com> Date: Wed, 7 Nov 2012 18:25:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <349ECC79-A599-46FC-9FF6-6C8AC2996459@gmail.com> References: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FD76@szxeml525-mbx.china.huawei.com>, <7370AA55-0673-4F03-B4C2-783553C6387F@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FE41@szxeml525-mbx.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1499) 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, 07 Nov 2012 18:25:28 -0000 I can't really see the "tier-1" carrier being happy to be exposed to the = C-MACs of the "tier-2" carrier. But I'll leave SPs to comment on that. On 7 Nov 2012, at 18:21, Xuxiaohu wrote: > In the CSC case, the tier-1 carrier (VPLS SP) assigns a single VPLS = instance to a given tier-2 carrier (e.g., cloud data center SP which = uses TRILL within its data centers) which in turn use VLANs to identify = its different customers, for the purpose of data center interconnect. In = this case, it may be hard for the tier-2 carrier to ensure there is no = MAC address overlapping across multiple customer VLANs of its different = customers/tenants. In addition, the virtual network topologies (i.e., PE = routers to which a given customer/tenant VLAN is attached) of different = customers/tenants of the given tier-2 carrier are usually different. >=20 > Best regards, > Xiaohu >=20 > ________________________________________ > =B7=A2=BC=FE=C8=CB: Giles Heron [giles.heron@gmail.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C28=C8=D5 1:45 > =B5=BD: Xuxiaohu > Cc: Rogers, Josh; l2vpn@ietf.org > =D6=F7=CC=E2: Re: Vlan-aware bundling over VPLS >=20 > Hi Xiaohu, >=20 > I think we all understand the potential benefits of VLAN-aware = bundling. But of course nothing comes for free ;) >=20 > And it still remains for SPs to give more feedback on my questions... >=20 > What's your thinking on CSC? >=20 > Giles >=20 > On 7 Nov 2012, at 16:29, Xuxiaohu wrote: >=20 >> When multiple customer VLANs are boundled to a single VPLS instance = or EVPN instance, it'd better to keep the broadcast domain associated = with each customer VLAN separated from each other. The obvious benefits = of such choice include: 1) support overlapping MAC address spaces across = different customer VLANs and avoid unneccessary MAC withdrawal in such = case; 2) avoid the unneccessary flood of BUM traffic of a given customer = VLAN to those PEs which are not attached with that customer VLAN yet. >>=20 >> One possible use case is the CSC scenario. >>=20 >> Xiaohu >>=20 >> ________________________________________ >> =B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] = =B4=FA=B1=ED Rogers, Josh [josh.rogers@twcable.com] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C27=C8=D5 23:06 >> =B5=BD: Giles Heron; l2vpn@ietf.org >> =D6=F7=CC=E2: Re: Vlan-aware bundling over VPLS >>=20 >> 1) for us, not currently. However, I understand the proposed benefit = and >> how it could be leveraged, and believe it _may_ become a needed = feature in >> the future. We don't see use cases that would benefit from this = approach >> _today_ though. >> 2) I would be inclined to say that if it is available in VPLS, I'd = like to >> see it in E-VPN (although the converse is not necessarily true) >>=20 >> -Josh >>=20 >>=20 >> On 11/7/12 8:55 AM, "Giles Heron" wrote: >>=20 >>> I'll leave the draft authors to comment on the points raised by = Himanshu >>> and Lucy >>>=20 >>> But I would like SPs to comment as to: >>> 1) whether VLAN-aware bundling is a requirement >>> 2) whether they require VLAN-aware bundling both for VPLS and E-VPN >>>=20 >>> Giles (chair hat firmly on). >>>=20 >>> On 7 Nov 2012, at 14:13, Lucy yong wrote: >>>=20 >>>> There is a trade-off on the solution. individual BD may have = different >>>> QoS requirement, multiplxing them together in a single PW may lose = some >>>> QoS and OAM capability. For example, when congestion happens, some = BD >>>> may work and some may not, PW status is not able to reflex that >>>> properly. >>>>=20 >>>> Lucy >>>>=20 >>>>> -----Original Message----- >>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf >>>>> Of Shah, Himanshu >>>>> Sent: Tuesday, November 06, 2012 2:04 PM >>>>> To: l2vpn@ietf.org >>>>> Subject: Vlan-aware bundling over VPLS >>>>>=20 >>>>> clarification question: If vlan is the tag used for demux over = single >>>>> PW and if that vlan needs to be advertised then what is the = saving? Is >>>>> this just saving of the PW label? >>>>> Himanshu >>>>>=20 >>>>> Sent from my iPad >>>=20 >>=20 >>=20 >> 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 sboutros@cisco.com Wed Nov 7 10:25:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2729F21F8B74 for ; Wed, 7 Nov 2012 10:25:49 -0800 (PST) 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 ASQ8364QVr2g for ; Wed, 7 Nov 2012 10:25:48 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC2D21F88DE for ; Wed, 7 Nov 2012 10:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1326; q=dns/txt; s=iport; t=1352312748; x=1353522348; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aN6K5iOWP2fvBX62MR5ppYlmSO/6MjY0uyUGxmBuedM=; b=e4SpI3DdeVJPXmU8l9ljWYAK71mJnIo6/2duOpBlnuGBIqQC0Hux9756 4zg4nJezb0Lc5C87m6ymNIY92pj7o4TGwzEiAUcnPVwtN3mkz7J0Oi0Ak OB1WrbNlGVRohZ6Hjf0WE3LRE1EiU24Sw8kQLqeQdKchPHTkvggrjSCGd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEemmlCtJXG//2dsb2JhbABEw2OBCIIeAQEBAwESASc/BQcEAgEIEQQBAQsUCQcyFAkIAQEEDgUIEweHYgacRaAxjA2FZmEDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,731,1344211200"; d="scan'208";a="139880623" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 07 Nov 2012 18:25:47 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA7IPllZ011233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 18:25:47 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 12:25:47 -0600 From: "Sami Boutros (sboutros)" To: Lucy yong Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABWgKgA= Date: Wed, 7 Nov 2012 18:25:46 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F10E761210@xmb-rcd-x08.cisco.com> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.218.131] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--38.954600-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: <7E3A3E62D14CDF4C8AFB85D1A230DBA4@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: Wed, 07 Nov 2012 18:25:49 -0000 Which Qos aspect would we loose here? Actually in the core you have only MPLS Qos, which is in the MPLS label, ma= pping some service Qos to the MPLS label doesn't change with this at all. As for OAM capability, why is that lost? in the next rev we would describe = how LSP Ping will be extended to do per service on the PW connectivity chec= k. If we need to communicate per service status via the PW status message, the= same TLV can be used. Thanks, Sami On Nov 7, 2012, at 6:13 AM, Lucy yong wrote: > There is a trade-off on the solution. individual BD may have different Qo= S requirement, multiplxing them together in a single PW may lose some QoS a= nd OAM capability. For example, when congestion happens, some BD may work a= nd some may not, PW status is not able to reflex that properly.=20 >=20 > Lucy >=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Shah, Himanshu >> Sent: Tuesday, November 06, 2012 2:04 PM >> To: l2vpn@ietf.org >> Subject: Vlan-aware bundling over VPLS >>=20 >> clarification question: If vlan is the tag used for demux over single >> PW and if that vlan needs to be advertised then what is the saving? Is >> this just saving of the PW label? >> Himanshu >>=20 >> Sent from my iPad From lucy.yong@huawei.com Wed Nov 7 10:38: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 DD8BE21F8B54 for ; Wed, 7 Nov 2012 10:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 z5cHJiC0U3qA for ; Wed, 7 Nov 2012 10:38:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C400F21F8B3A for ; Wed, 7 Nov 2012 10:38:54 -0800 (PST) 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 ALH91547; Wed, 07 Nov 2012 18:38:53 +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; Wed, 7 Nov 2012 18:38:43 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 18:38:52 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 10:38:50 -0800 From: Lucy yong To: "Sami Boutros (sboutros)" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABWgKgAADG/MsA== Date: Wed, 7 Nov 2012 18:38:49 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482D0AA@dfweml505-mbx> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> <473DA00BC97EE04A9B4EE875F48CE5F10E761210@xmb-rcd-x08.cisco.com> In-Reply-To: <473DA00BC97EE04A9B4EE875F48CE5F10E761210@xmb-rcd-x08.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.4] 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, 07 Nov 2012 18:38:56 -0000 Hi Sami, >=20 > Which Qos aspect would we loose here? >=20 > Actually in the core you have only MPLS Qos, which is in the MPLS label, > mapping some service Qos to the MPLS label doesn't change with this at > all. [Lucy] But SPs have a choice to construct multiple LSP TE tunnels where eac= h support a particular CoS, Current mechanism allow the PW to carry custome= r CoS to be mapped into a proper LSP with the same CoS. When you multiplex = them together, you loose such nature, right? >=20 > As for OAM capability, why is that lost? in the next rev we would > describe how LSP Ping will be extended to do per service on the PW > connectivity check. [Lucy] You typically have SOAM map to a PW status in one-to-one for VPLS se= rvice. You lost that nature here, which require some new way to correlate i= f you get a customer complain on the service. Current draft does not addres= s these.=20 Regards, Lucy >=20 > If we need to communicate per service status via the PW status message, > the same TLV can be used. >=20 > Thanks, >=20 > Sami > On Nov 7, 2012, at 6:13 AM, Lucy yong wrote: >=20 > > There is a trade-off on the solution. individual BD may have > different QoS requirement, multiplxing them together in a single PW may > lose some QoS and OAM capability. For example, when congestion happens, > some BD may work and some may not, PW status is not able to reflex that > properly. > > > > Lucy > > > >> -----Original Message----- > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >> Of Shah, Himanshu > >> Sent: Tuesday, November 06, 2012 2:04 PM > >> To: l2vpn@ietf.org > >> Subject: Vlan-aware bundling over VPLS > >> > >> clarification question: If vlan is the tag used for demux over > single > >> PW and if that vlan needs to be advertised then what is the saving? > Is > >> this just saving of the PW label? > >> Himanshu > >> > >> Sent from my iPad From sboutros@cisco.com Wed Nov 7 10:50:52 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 5ED5121F8C4F for ; Wed, 7 Nov 2012 10:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=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 840K8dyK-FAF for ; Wed, 7 Nov 2012 10:50:51 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5188821F8C55 for ; Wed, 7 Nov 2012 10:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2289; q=dns/txt; s=iport; t=1352314251; x=1353523851; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AbMDjG357cR7OFSGb7Nn2O6tKAJFB+4aUGcISJAwsSE=; b=DvJTFPqcUfw0B0y/jG98isKn0UEa3opF7aoe7MypLoWFAlGFxlesuORp osoCpvs3AiPgDW7vn1l+SiSPa/lFtnhpuFFgDYlDdDStB+E6K7ADi0YLP SemlQsaEN21Y4yOZwCtOXZ/V2HlF99Nk8oLpYwHerAzUzrsormj7pJBU9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGismlCtJV2a/2dsb2JhbABEw2OBCIIeAQEBAwESASc/DAQCAQgRBAEBAQoUCQcyFAkIAQEEDgUIEweHYgacPaA2jA2FZmEDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,731,1344211200"; d="scan'208";a="139879064" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2012 18:50:50 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA7IooQO011514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 18:50:50 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 12:50:50 -0600 From: "Sami Boutros (sboutros)" To: Lucy yong Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABWgKgAADG/MsP//o4IA Date: Wed, 7 Nov 2012 18:50:50 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F10E761351@xmb-rcd-x08.cisco.com> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> <473DA00BC97EE04A9B4EE875F48CE5F10E761210@xmb-rcd-x08.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4482D0AA@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482D0AA@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.218.131] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--43.574600-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: <8C0C882D730AB24E9F24E6E8E3D18383@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: Wed, 07 Nov 2012 18:50:52 -0000 Hi Lucy, >> Which Qos aspect would we loose here? >>=20 >> Actually in the core you have only MPLS Qos, which is in the MPLS label, >> mapping some service Qos to the MPLS label doesn't change with this at >> all. > [Lucy] But SPs have a choice to construct multiple LSP TE tunnels where e= ach support a particular CoS,Current mechanism allow the PW to carry custom= er CoS to be mapped into a proper LSP with the same CoS. When you multiplex= them together, you loose such nature, right? Sami: Mapping a per service traffic on the PW to a given TE tunnel, this is= a local implementation matter. >>=20 >> As for OAM capability, why is that lost? in the next rev we would >> describe how LSP Ping will be extended to do per service on the PW >> connectivity check. > [Lucy] You typically have SOAM map to a PW status in one-to-one for VPLS = service. You lost that nature here, which require some new way to correlate= if you get a customer complain on the service. Current draft does not addr= ess these.=20 Sami: This is not true because the TLV we are proposing that encodes the VL= ans impacted can be used with the PW status, MAC WD, etc.. Thanks, Sami >=20 > Regards, > Lucy >>=20 >> If we need to communicate per service status via the PW status message, >> the same TLV can be used. >>=20 >> Thanks, >>=20 >> Sami >> On Nov 7, 2012, at 6:13 AM, Lucy yong wrote: >>=20 >>> There is a trade-off on the solution. individual BD may have >> different QoS requirement, multiplxing them together in a single PW may >> lose some QoS and OAM capability. For example, when congestion happens, >> some BD may work and some may not, PW status is not able to reflex that >> properly. >>>=20 >>> Lucy >>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >>>> Of Shah, Himanshu >>>> Sent: Tuesday, November 06, 2012 2:04 PM >>>> To: l2vpn@ietf.org >>>> Subject: Vlan-aware bundling over VPLS >>>>=20 >>>> clarification question: If vlan is the tag used for demux over >> single >>>> PW and if that vlan needs to be advertised then what is the saving? >> Is >>>> this just saving of the PW label? >>>> Himanshu >>>>=20 >>>> Sent from my iPad >=20 From josh.rogers@twcable.com Wed Nov 7 11:00: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 3F2A321F8B4D for ; Wed, 7 Nov 2012 11:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.139 X-Spam-Level: * X-Spam-Status: No, score=1.139 tagged_above=-999 required=5 tests=[AWL=-2.602, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 PqWvlaCvuiWX for ; Wed, 7 Nov 2012 11:00:34 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5544D21F8B34 for ; Wed, 7 Nov 2012 11:00:24 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,731,1344225600"; d="scan'208";a="447682510" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Nov 2012 13:59:42 -0500 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 7 Nov 2012 14:00:22 -0500 From: "Rogers, Josh" To: Giles Heron , Xuxiaohu Date: Wed, 7 Nov 2012 14:00:21 -0500 Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac29GiMDsiwWiG2kT+K2mHk7eLeSxg== Message-ID: In-Reply-To: <349ECC79-A599-46FC-9FF6-6C8AC2996459@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 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, 07 Nov 2012 19:00:35 -0000 VGhpcyBzb3J0IG9mIHVzZSBjYXNlIGhhcyBjb21lIHVwIGJlZm9yZSAod2hlcmUgYSBvcGVyYXRv ciBBIHB1cmNoYXNlcyBhDQonYW55IHRvIGFueScgdHlwZSBJSSBzZXJ2aWNlIGZyb20gb3BlcmF0 b3IgQikgd2hlcmUgdGhlIGJ1eWVyIHdhbnRzIHRvIHVzZQ0KdGhlIHNlcnZpY2UgdG8gZGVsaXZl ciBtdWx0aXBsZSBzZXJ2aWNlcyBmb3IgbXVsdGlwbGUgZW5kIHVzZXJzIG9uIHRoZQ0Kc2Vjb25k IG9wZXJhdG9yJ3MgbmV0d29yay4gIElmIFZQTFMgaXMgdXNlZCwgdGhlIEMtTWFjJ3Mgb24gb3Bl cmF0b3IgQSdzDQpuZXR3b3JrIHdpbGwgYmUgc2VlbiBvbiBvcGVyYXRvciBCJ3MgbmV0d29yay4N Cg0KSSBzZWUgdGhlIHZhbHVlIG9mIHRoZSBjYXNlIHRoYXQgWGlhb2h1IG91dGxpbmVkLCBob3dl dmVyIGl0cyByZWxhdGl2ZWx5DQp1bmNvbW1vbiBmb3IgdXMgKG5ldmVyIGRvbmUgaXQgYWN0dWFs bHksIG9ubHkgZGlzY3Vzc2VkIGl0IGEgY291cGxlDQp0aW1lcyksIGFuZCB3ZSB3b3VsZCBiZSBo YXBweSB0byB3YWl0IGFuZCBpbXBsZW1lbnQgdGhlIHNhbWUgc29ydCBvZiB0aGluZw0KdXNpbmcg RS1WUE4gYXQgYSBtdWNoIGxhdGVyIGRhdGUuDQoNCi1Kb3NoDQoNCg0KT24gMTEvNy8xMiAxMjoy NSBQTSwgIkdpbGVzIEhlcm9uIiA8Z2lsZXMuaGVyb25AZ21haWwuY29tPiB3cm90ZToNCg0KPkkg Y2FuJ3QgcmVhbGx5IHNlZSB0aGUgInRpZXItMSIgY2FycmllciBiZWluZyBoYXBweSB0byBiZSBl eHBvc2VkIHRvIHRoZQ0KPkMtTUFDcyBvZiB0aGUgInRpZXItMiIgY2Fycmllci4gIEJ1dCBJJ2xs IGxlYXZlIFNQcyB0byBjb21tZW50IG9uIHRoYXQuDQo+DQo+T24gNyBOb3YgMjAxMiwgYXQgMTg6 MjEsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4NCj4+IEluIHRoZSBD U0MgY2FzZSwgdGhlIHRpZXItMSBjYXJyaWVyIChWUExTIFNQKSBhc3NpZ25zIGEgc2luZ2xlIFZQ TFMNCj4+aW5zdGFuY2UgdG8gYSBnaXZlbiB0aWVyLTIgY2FycmllciAoZS5nLiwgY2xvdWQgZGF0 YSBjZW50ZXIgU1Agd2hpY2gNCj4+dXNlcyBUUklMTCB3aXRoaW4gaXRzIGRhdGEgY2VudGVycykg d2hpY2ggaW4gdHVybiB1c2UgVkxBTnMgdG8gaWRlbnRpZnkNCj4+aXRzIGRpZmZlcmVudCBjdXN0 b21lcnMsIGZvciB0aGUgcHVycG9zZSBvZiBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3QuIEluDQo+ PnRoaXMgY2FzZSwgaXQgbWF5IGJlIGhhcmQgZm9yIHRoZSB0aWVyLTIgY2FycmllciB0byBlbnN1 cmUgdGhlcmUgaXMgbm8NCj4+TUFDIGFkZHJlc3Mgb3ZlcmxhcHBpbmcgYWNyb3NzIG11bHRpcGxl IGN1c3RvbWVyIFZMQU5zIG9mIGl0cyBkaWZmZXJlbnQNCj4+Y3VzdG9tZXJzL3RlbmFudHMuIElu IGFkZGl0aW9uLCB0aGUgdmlydHVhbCBuZXR3b3JrIHRvcG9sb2dpZXMgKGkuZS4sIFBFDQo+PnJv dXRlcnMgdG8gd2hpY2ggYSBnaXZlbiBjdXN0b21lci90ZW5hbnQgVkxBTiBpcyBhdHRhY2hlZCkg b2YgZGlmZmVyZW50DQo+PmN1c3RvbWVycy90ZW5hbnRzIG9mIHRoZSBnaXZlbiB0aWVyLTIgY2Fy cmllciBhcmUgdXN1YWxseSBkaWZmZXJlbnQuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gWGlh b2h1DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g t6K8/sjLOiBHaWxlcyBIZXJvbiBbZ2lsZXMuaGVyb25AZ21haWwuY29tXQ0KPj4gt6LLzcqxvOQ6 IDIwMTLE6jEx1MI4yNUgMTo0NQ0KPj4gtb06IFh1eGlhb2h1DQo+PiBDYzogUm9nZXJzLCBKb3No OyBsMnZwbkBpZXRmLm9yZw0KPj4g1vfM4jogUmU6IFZsYW4tYXdhcmUgYnVuZGxpbmcgb3ZlciBW UExTDQo+Pg0KPj4gSGkgWGlhb2h1LA0KPj4NCj4+IEkgdGhpbmsgd2UgYWxsIHVuZGVyc3RhbmQg dGhlIHBvdGVudGlhbCBiZW5lZml0cyBvZiBWTEFOLWF3YXJlDQo+PmJ1bmRsaW5nLiAgQnV0IG9m IGNvdXJzZSBub3RoaW5nIGNvbWVzIGZvciBmcmVlIDspDQo+Pg0KPj4gQW5kIGl0IHN0aWxsIHJl bWFpbnMgZm9yIFNQcyB0byBnaXZlIG1vcmUgZmVlZGJhY2sgb24gbXkgcXVlc3Rpb25zLi4uDQo+ Pg0KPj4gV2hhdCdzIHlvdXIgdGhpbmtpbmcgb24gQ1NDPw0KPj4NCj4+IEdpbGVzDQo+Pg0KPj4g T24gNyBOb3YgMjAxMiwgYXQgMTY6MjksIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3 cm90ZToNCj4+DQo+Pj4gV2hlbiBtdWx0aXBsZSBjdXN0b21lciBWTEFOcyBhcmUgYm91bmRsZWQg dG8gYSBzaW5nbGUgVlBMUyBpbnN0YW5jZSBvcg0KPj4+RVZQTiBpbnN0YW5jZSwgaXQnZCBiZXR0 ZXIgdG8ga2VlcCB0aGUgYnJvYWRjYXN0IGRvbWFpbiBhc3NvY2lhdGVkIHdpdGgNCj4+PmVhY2gg Y3VzdG9tZXIgVkxBTiBzZXBhcmF0ZWQgZnJvbSBlYWNoIG90aGVyLiBUaGUgb2J2aW91cyBiZW5l Zml0cyBvZg0KPj4+c3VjaCBjaG9pY2UgaW5jbHVkZTogMSkgc3VwcG9ydCBvdmVybGFwcGluZyBN QUMgYWRkcmVzcyBzcGFjZXMgYWNyb3NzDQo+Pj5kaWZmZXJlbnQgY3VzdG9tZXIgVkxBTnMgYW5k IGF2b2lkIHVubmVjY2Vzc2FyeSBNQUMgd2l0aGRyYXdhbCBpbiBzdWNoDQo+Pj5jYXNlOyAyKSBh dm9pZCB0aGUgdW5uZWNjZXNzYXJ5IGZsb29kIG9mIEJVTSB0cmFmZmljIG9mIGEgZ2l2ZW4NCj4+ PmN1c3RvbWVyIFZMQU4gdG8gdGhvc2UgUEVzIHdoaWNoIGFyZSBub3QgYXR0YWNoZWQgd2l0aCB0 aGF0IGN1c3RvbWVyDQo+Pj5WTEFOIHlldC4NCj4+Pg0KPj4+IE9uZSBwb3NzaWJsZSB1c2UgY2Fz ZSBpcyB0aGUgQ1NDIHNjZW5hcmlvLg0KPj4+DQo+Pj4gWGlhb2h1DQo+Pj4NCj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gt6K8/sjLOiBsMnZwbi1ib3Vu Y2VzQGlldGYub3JnIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvZ2VycywgSm9zaA0K Pj4+W2pvc2gucm9nZXJzQHR3Y2FibGUuY29tXQ0KPj4+ILeiy83KsbzkOiAyMDEyxOoxMdTCN8jV IDIzOjA2DQo+Pj4gtb06IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPj4+INb3zOI6IFJl OiBWbGFuLWF3YXJlIGJ1bmRsaW5nIG92ZXIgVlBMUw0KPj4+DQo+Pj4gMSkgZm9yIHVzLCBub3Qg Y3VycmVudGx5LiAgSG93ZXZlciwgSSB1bmRlcnN0YW5kIHRoZSBwcm9wb3NlZCBiZW5lZml0DQo+ Pj5hbmQNCj4+PiBob3cgaXQgY291bGQgYmUgbGV2ZXJhZ2VkLCBhbmQgYmVsaWV2ZSBpdCBfbWF5 XyBiZWNvbWUgYSBuZWVkZWQNCj4+PmZlYXR1cmUgaW4NCj4+PiB0aGUgZnV0dXJlLiAgV2UgZG9u J3Qgc2VlIHVzZSBjYXNlcyB0aGF0IHdvdWxkIGJlbmVmaXQgZnJvbSB0aGlzDQo+Pj5hcHByb2Fj aA0KPj4+IF90b2RheV8gdGhvdWdoLg0KPj4+IDIpIEkgd291bGQgYmUgaW5jbGluZWQgdG8gc2F5 IHRoYXQgaWYgaXQgaXMgYXZhaWxhYmxlIGluIFZQTFMsIEknZA0KPj4+bGlrZSB0bw0KPj4+IHNl ZSBpdCBpbiBFLVZQTiAoYWx0aG91Z2ggdGhlIGNvbnZlcnNlIGlzIG5vdCBuZWNlc3NhcmlseSB0 cnVlKQ0KPj4+DQo+Pj4gLUpvc2gNCj4+Pg0KPj4+DQo+Pj4gT24gMTEvNy8xMiA4OjU1IEFNLCAi R2lsZXMgSGVyb24iIDxnaWxlcy5oZXJvbkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+DQo+Pj4+IEkn bGwgbGVhdmUgdGhlIGRyYWZ0IGF1dGhvcnMgdG8gY29tbWVudCBvbiB0aGUgcG9pbnRzIHJhaXNl ZCBieQ0KPj4+PkhpbWFuc2h1DQo+Pj4+IGFuZCBMdWN5DQo+Pj4+DQo+Pj4+IEJ1dCBJIHdvdWxk IGxpa2UgU1BzIHRvIGNvbW1lbnQgYXMgdG86DQo+Pj4+IDEpIHdoZXRoZXIgVkxBTi1hd2FyZSBi dW5kbGluZyBpcyBhIHJlcXVpcmVtZW50DQo+Pj4+IDIpIHdoZXRoZXIgdGhleSByZXF1aXJlIFZM QU4tYXdhcmUgYnVuZGxpbmcgYm90aCBmb3IgVlBMUyBhbmQgRS1WUE4NCj4+Pj4NCj4+Pj4gR2ls ZXMgKGNoYWlyIGhhdCBmaXJtbHkgb24pLg0KPj4+Pg0KPj4+PiBPbiA3IE5vdiAyMDEyLCBhdCAx NDoxMywgTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4+DQo+Pj4+ PiBUaGVyZSBpcyBhIHRyYWRlLW9mZiBvbiB0aGUgc29sdXRpb24uIGluZGl2aWR1YWwgQkQgbWF5 IGhhdmUNCj4+Pj4+ZGlmZmVyZW50DQo+Pj4+PiBRb1MgcmVxdWlyZW1lbnQsIG11bHRpcGx4aW5n IHRoZW0gdG9nZXRoZXIgaW4gYSBzaW5nbGUgUFcgbWF5IGxvc2UNCj4+Pj4+c29tZQ0KPj4+Pj4g UW9TIGFuZCBPQU0gY2FwYWJpbGl0eS4gRm9yIGV4YW1wbGUsIHdoZW4gY29uZ2VzdGlvbiBoYXBw ZW5zLCBzb21lIEJEDQo+Pj4+PiBtYXkgd29yayBhbmQgc29tZSBtYXkgbm90LCBQVyBzdGF0dXMg aXMgbm90IGFibGUgdG8gcmVmbGV4IHRoYXQNCj4+Pj4+IHByb3Blcmx5Lg0KPj4+Pj4NCj4+Pj4+ IEx1Y3kNCj4+Pj4+DQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBG cm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10gT24NCj4+Pj4+PkJlaGFsZg0KPj4+Pj4+IE9mIFNoYWgsIEhpbWFuc2h1DQo+Pj4+Pj4gU2Vu dDogVHVlc2RheSwgTm92ZW1iZXIgMDYsIDIwMTIgMjowNCBQTQ0KPj4+Pj4+IFRvOiBsMnZwbkBp ZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IFZsYW4tYXdhcmUgYnVuZGxpbmcgb3ZlciBWUExTDQo+ Pj4+Pj4NCj4+Pj4+PiBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uOiAgIElmIHZsYW4gaXMgdGhlIHRh ZyB1c2VkIGZvciBkZW11eCBvdmVyDQo+Pj4+Pj5zaW5nbGUNCj4+Pj4+PiBQVyBhbmQgaWYgdGhh dCB2bGFuIG5lZWRzIHRvIGJlIGFkdmVydGlzZWQgdGhlbiB3aGF0IGlzIHRoZSBzYXZpbmc/DQo+ Pj4+Pj5Jcw0KPj4+Pj4+IHRoaXMganVzdCBzYXZpbmcgb2YgdGhlIFBXIGxhYmVsPw0KPj4+Pj4+ IEhpbWFuc2h1DQo+Pj4+Pj4NCj4+Pj4+PiBTZW50IGZyb20gbXkgaVBhZA0KPj4+Pg0KPj4+DQo+ Pj4NCj4+PiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBUaW1lIFdhcm5lciBDYWJsZQ0KPj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlz IHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdA0KPj4+dG8gY29weXJpZ2h0IGJl bG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+ PnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gg aXQgaXMNCj4+PmFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzIEUtbWFpbCwgeW91DQo+Pj5hcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRp c3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3INCj4+PmFjdGlvbiB0YWtlbiBp biByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMNCj4+ PkUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBoYXZlIHJlY2VpdmVkDQo+Pj50aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4+cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmln aW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueQ0KPj4+cHJpbnRvdXQuDQo+ DQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g VGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRv IFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRz IG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVu dGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBh bnkgcHJpbnRvdXQuDQo= From lucy.yong@huawei.com Wed Nov 7 11:02: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 572B421F8C9B for ; Wed, 7 Nov 2012 11:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_37=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 9kHwMLZ6sVeg for ; Wed, 7 Nov 2012 11:02:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B71EC21F8C6B for ; Wed, 7 Nov 2012 11:02:16 -0800 (PST) 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 ALH92527; Wed, 07 Nov 2012 19:02:13 +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; Wed, 7 Nov 2012 19:02:03 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 19:02:12 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 11:02:10 -0800 From: Lucy yong To: "Sami Boutros (sboutros)" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABWgKgAADG/MsP//o4IAgABjyFA= Date: Wed, 7 Nov 2012 19:02:09 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482D112@dfweml505-mbx> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> <473DA00BC97EE04A9B4EE875F48CE5F10E761210@xmb-rcd-x08.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4482D0AA@dfweml505-mbx> <473DA00BC97EE04A9B4EE875F48CE5F10E761351@xmb-rcd-x08.cisco.com> In-Reply-To: <473DA00BC97EE04A9B4EE875F48CE5F10E761351@xmb-rcd-x08.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.4] 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, 07 Nov 2012 19:02:24 -0000 See below. > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sami Boutros (sboutros) > Sent: Wednesday, November 07, 2012 12:51 PM > To: Lucy yong > Cc: l2vpn@ietf.org > Subject: Re: Vlan-aware bundling over VPLS >=20 > Hi Lucy, >=20 > >> Which Qos aspect would we loose here? > >> > >> Actually in the core you have only MPLS Qos, which is in the MPLS > label, > >> mapping some service Qos to the MPLS label doesn't change with this > at > >> all. > > [Lucy] But SPs have a choice to construct multiple LSP TE tunnels > where each support a particular CoS,Current mechanism allow the PW to > carry customer CoS to be mapped into a proper LSP with the same CoS. > When you multiplex them together, you loose such nature, right? >=20 >=20 > Sami: Mapping a per service traffic on the PW to a given TE tunnel, > this is a local implementation matter. [Lucy] Yes, it is local implementation. But, this approach may impact a lot= of existing devices to do it. This pushes the mapping a per service traffi= c from a PW to a LSP to a VLAN to a LSP directly. >=20 >=20 > >> > >> As for OAM capability, why is that lost? in the next rev we would > >> describe how LSP Ping will be extended to do per service on the PW > >> connectivity check. > > [Lucy] You typically have SOAM map to a PW status in one-to-one for > VPLS service. You lost that nature here, which require some new way to > correlate if you get a customer complain on the service. Current draft > does not address these. >=20 > Sami: This is not true because the TLV we are proposing that encodes > the VLans impacted can be used with the PW status, MAC WD, etc.. [Lucy] I do not catch this. Could you elaborate how it works if SOAM indica= tes a PM problem on a particular VLAN in the VLAN aware bundle, how does SP= figure out where the problem is. Lucy >=20 > Thanks, >=20 > Sami >=20 > > > > Regards, > > Lucy > >> > >> If we need to communicate per service status via the PW status > message, > >> the same TLV can be used. > >> > >> Thanks, > >> > >> Sami > >> On Nov 7, 2012, at 6:13 AM, Lucy yong wrote: > >> > >>> There is a trade-off on the solution. individual BD may have > >> different QoS requirement, multiplxing them together in a single PW > may > >> lose some QoS and OAM capability. For example, when congestion > happens, > >> some BD may work and some may not, PW status is not able to reflex > that > >> properly. > >>> > >>> Lucy > >>> > >>>> -----Original Message----- > >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> Behalf > >>>> Of Shah, Himanshu > >>>> Sent: Tuesday, November 06, 2012 2:04 PM > >>>> To: l2vpn@ietf.org > >>>> Subject: Vlan-aware bundling over VPLS > >>>> > >>>> clarification question: If vlan is the tag used for demux over > >> single > >>>> PW and if that vlan needs to be advertised then what is the saving? > >> Is > >>>> this just saving of the PW label? > >>>> Himanshu > >>>> > >>>> Sent from my iPad > > From sboutros@cisco.com Wed Nov 7 11:20: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 61A8721F8C65 for ; Wed, 7 Nov 2012 11:20:37 -0800 (PST) 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_37=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 3FJl53cLATZh for ; Wed, 7 Nov 2012 11:20:36 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 75FDC21F8BAB for ; Wed, 7 Nov 2012 11:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3319; q=dns/txt; s=iport; t=1352316036; x=1353525636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Tnur0rE89pSfOndqQHNjX+t6/l5mI+lszn1g3l20C9E=; b=EgBp05Rq38igVwfTSBS0yK9GbVce6LnntdfTjxDgbY83M3Hsg0NT7CjD /ZUVSN4Q4S4aDx7yngv91dhfAWAOv2S9hPjzQI+ZJ7zk3cro0xJ5f4V6K vpzPmPd67tkr5G7UGw2GS4i35X4niP9ZwoLOu+sHfLB77yCrpg0yuA35v I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKyzmlCtJV2d/2dsb2JhbABEw2qBCIIeAQEBAwESASc/BQcEAgEIEQQBAQEKFAkHMhQJCAIEDgUIEweHYgacO6A4jA2FZmEDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,731,1344211200"; d="scan'208";a="139854849" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 07 Nov 2012 19:20:35 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA7JKZK8018570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 19:20:35 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.234]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 13:20:35 -0600 From: "Sami Boutros (sboutros)" To: Lucy yong Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABWgKgAADG/MsP//o4IAgABjyFD//6SGgA== Date: Wed, 7 Nov 2012 19:20:34 +0000 Message-ID: <473DA00BC97EE04A9B4EE875F48CE5F10E76159B@xmb-rcd-x08.cisco.com> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> <473DA00BC97EE04A9B4EE875F48CE5F10E761210@xmb-rcd-x08.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4482D0AA@dfweml505-mbx> <473DA00BC97EE04A9B4EE875F48CE5F10E761351@xmb-rcd-x08.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4482D112@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482D112@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.218.131] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--43.115800-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: <1371022F15B5DE45BD93C236CEDB6573@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: Wed, 07 Nov 2012 19:20:37 -0000 >>=20 >>>> Which Qos aspect would we loose here? >>>>=20 >>>> Actually in the core you have only MPLS Qos, which is in the MPLS >> label, >>>> mapping some service Qos to the MPLS label doesn't change with this >> at >>>> all. >>> [Lucy] But SPs have a choice to construct multiple LSP TE tunnels >> where each support a particular CoS,Current mechanism allow the PW to >> carry customer CoS to be mapped into a proper LSP with the same CoS. >> When you multiplex them together, you loose such nature, right? >>=20 >>=20 >> Sami: Mapping a per service traffic on the PW to a given TE tunnel, >> this is a local implementation matter. > [Lucy] Yes, it is local implementation. But, this approach may impact a l= ot of existing devices to do it. This pushes the mapping a per service traf= fic from a PW to a LSP to a VLAN to a LSP directly. >>=20 Sami: I really don't get your comment, Vlan aware support is going to impa= ct devices operation anyway. The PW here is servicing multiple services so = the PW MUST be aware of the services, we din't claim anything different her= e. >>=20 >>>>=20 >>>> As for OAM capability, why is that lost? in the next rev we would >>>> describe how LSP Ping will be extended to do per service on the PW >>>> connectivity check. >>> [Lucy] You typically have SOAM map to a PW status in one-to-one for >> VPLS service. You lost that nature here, which require some new way to >> correlate if you get a customer complain on the service. Current draft >> does not address these. >>=20 >> Sami: This is not true because the TLV we are proposing that encodes >> the VLans impacted can be used with the PW status, MAC WD, etc.. > [Lucy] I do not catch this. Could you elaborate how it works if SOAM indi= cates a PM problem on a particular VLAN in the VLAN aware bundle, how does = SP figure out where the problem is. >=20 Sami: In the OAM/ PW message or whatever you call it, we include the servic= e one/many VLans (in the new TLV we are proposing), this is what the draft = is about. Thanks, Sami > Lucy >>=20 >> Thanks, >>=20 >> Sami >>=20 >>>=20 >>> Regards, >>> Lucy >>>>=20 >>>> If we need to communicate per service status via the PW status >> message, >>>> the same TLV can be used. >>>>=20 >>>> Thanks, >>>>=20 >>>> Sami >>>> On Nov 7, 2012, at 6:13 AM, Lucy yong wrote: >>>>=20 >>>>> There is a trade-off on the solution. individual BD may have >>>> different QoS requirement, multiplxing them together in a single PW >> may >>>> lose some QoS and OAM capability. For example, when congestion >> happens, >>>> some BD may work and some may not, PW status is not able to reflex >> that >>>> properly. >>>>>=20 >>>>> Lucy >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>>> Behalf >>>>>> Of Shah, Himanshu >>>>>> Sent: Tuesday, November 06, 2012 2:04 PM >>>>>> To: l2vpn@ietf.org >>>>>> Subject: Vlan-aware bundling over VPLS >>>>>>=20 >>>>>> clarification question: If vlan is the tag used for demux over >>>> single >>>>>> PW and if that vlan needs to be advertised then what is the saving? >>>> Is >>>>>> this just saving of the PW label? >>>>>> Himanshu >>>>>>=20 >>>>>> Sent from my iPad >>>=20 >=20 From xuxiaohu@huawei.com Wed Nov 7 11:22: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 2180D21F8B7A for ; Wed, 7 Nov 2012 11:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 cTavotu2jKM3 for ; Wed, 7 Nov 2012 11:22:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD5921F8BAB for ; Wed, 7 Nov 2012 11:22:52 -0800 (PST) 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 AMN11869; Wed, 07 Nov 2012 19:22:51 +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; Wed, 7 Nov 2012 19:22:38 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 03:22:48 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.161]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 03:22:45 +0800 From: Xuxiaohu To: "Rogers, Josh" , Giles Heron Subject: re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwA//+HcoCAAAM3gIAAmXbW//+S4ACAAIpvsf//gMUAgAAJxoCAAIfEZQ== Date: Wed, 7 Nov 2012 19:22:44 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0756FEB5@szxeml525-mbx.china.huawei.com> References: <349ECC79-A599-46FC-9FF6-6C8AC2996459@gmail.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.47.145.224] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 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, 07 Nov 2012 19:22:54 -0000 RnVsbHkgYWdyZWUgd2l0aCBHaWxlJ3MgYW5kIFJvZ2VycydzIHBvaW50IHRoYXQgaXQgd291ZCBi ZSBiZXR0ZXIgdG8gYXZvaWQgZGVwbG95IGhldGVyb2dlbm91cyBuZXR3b3JrIHRlY2hub2xvZ2ll cyBvbiBkaWZmZXJlbnQgc2l0ZXMgb2YgYSB0aWVyLTIgY2FycmllciBhdCB0aGUgYmVnaW5uaW5n LiBJbiB0aGlzIHdheSwgdGhlcmUgaXMgbm8gbmVlZCB0byBleHBsb3JlIHRoZSBDLU1BQyBvZiB0 aWVyLTIgY2FycmllciB0byB0aWVyLTEnIGNhcnJpZXIncyBWUExTIFBFIGRldmljZXMuIEhvd2V2 ZXIsIHRoZXJlIG1heSBiZSBzb21lIHVuY29tbW9uIGNhc2VzIHdoZXJlIGhldGVyZ2Vub3VzIHNp dGUgbmV0d29ya3MgYXJlIGFscmVhZHkgdGhlcmUuIEZvciBleGFtcGxlLCB0aWVyLTIgY2Fycmll cnMgbWF5IHdhbnQgdG8gaW50ZXJjb25uZWN0IHRoZWlyIGV4aXN0aW5nIHNwYW5uaW5nLXRyZWUg YmFzZWQgZGF0YSBjZW50ZXIgbmV0d29yayBzaXRlcyB0byBzb21lIG5ldyBkYXRhIGNlbnRlciBu ZXR3b3JrIHNpdGVzIHdoZXJlIFRSSUxMIG9yIHNvbWUgb3RoZXIgb3ZlcmxheSBuZXR3b3JrIHRl Y2hub2xvZ2llcyBhcmUgdXNlZC4NCg0KT2YgY291cnNlLCBvcGVyYXRvcnMnIHZpZXdzIGFyZSBt b3JlIGRlc2lyYWJsZS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogUm9nZXJzLCBKb3NoIFtqb3NoLnJv Z2Vyc0B0d2NhYmxlLmNvbV0NCreiy83KsbzkOiAyMDEyxOoxMdTCOMjVIDM6MDANCrW9OiBHaWxl cyBIZXJvbjsgWHV4aWFvaHUNCkNjOiBsMnZwbkBpZXRmLm9yZw0K1vfM4jogUmU6IFZsYW4tYXdh cmUgYnVuZGxpbmcgb3ZlciBWUExTDQoNClRoaXMgc29ydCBvZiB1c2UgY2FzZSBoYXMgY29tZSB1 cCBiZWZvcmUgKHdoZXJlIGEgb3BlcmF0b3IgQSBwdXJjaGFzZXMgYQ0KJ2FueSB0byBhbnknIHR5 cGUgSUkgc2VydmljZSBmcm9tIG9wZXJhdG9yIEIpIHdoZXJlIHRoZSBidXllciB3YW50cyB0byB1 c2UNCnRoZSBzZXJ2aWNlIHRvIGRlbGl2ZXIgbXVsdGlwbGUgc2VydmljZXMgZm9yIG11bHRpcGxl IGVuZCB1c2VycyBvbiB0aGUNCnNlY29uZCBvcGVyYXRvcidzIG5ldHdvcmsuICBJZiBWUExTIGlz IHVzZWQsIHRoZSBDLU1hYydzIG9uIG9wZXJhdG9yIEEncw0KbmV0d29yayB3aWxsIGJlIHNlZW4g b24gb3BlcmF0b3IgQidzIG5ldHdvcmsuDQoNCkkgc2VlIHRoZSB2YWx1ZSBvZiB0aGUgY2FzZSB0 aGF0IFhpYW9odSBvdXRsaW5lZCwgaG93ZXZlciBpdHMgcmVsYXRpdmVseQ0KdW5jb21tb24gZm9y IHVzIChuZXZlciBkb25lIGl0IGFjdHVhbGx5LCBvbmx5IGRpc2N1c3NlZCBpdCBhIGNvdXBsZQ0K dGltZXMpLCBhbmQgd2Ugd291bGQgYmUgaGFwcHkgdG8gd2FpdCBhbmQgaW1wbGVtZW50IHRoZSBz YW1lIHNvcnQgb2YgdGhpbmcNCnVzaW5nIEUtVlBOIGF0IGEgbXVjaCBsYXRlciBkYXRlLg0KDQot Sm9zaA0KDQoNCk9uIDExLzcvMTIgMTI6MjUgUE0sICJHaWxlcyBIZXJvbiIgPGdpbGVzLmhlcm9u QGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5JIGNhbid0IHJlYWxseSBzZWUgdGhlICJ0aWVyLTEiIGNh cnJpZXIgYmVpbmcgaGFwcHkgdG8gYmUgZXhwb3NlZCB0byB0aGUNCj5DLU1BQ3Mgb2YgdGhlICJ0 aWVyLTIiIGNhcnJpZXIuICBCdXQgSSdsbCBsZWF2ZSBTUHMgdG8gY29tbWVudCBvbiB0aGF0Lg0K Pg0KPk9uIDcgTm92IDIwMTIsIGF0IDE4OjIxLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNv bT4gd3JvdGU6DQo+DQo+PiBJbiB0aGUgQ1NDIGNhc2UsIHRoZSB0aWVyLTEgY2FycmllciAoVlBM UyBTUCkgYXNzaWducyBhIHNpbmdsZSBWUExTDQo+Pmluc3RhbmNlIHRvIGEgZ2l2ZW4gdGllci0y IGNhcnJpZXIgKGUuZy4sIGNsb3VkIGRhdGEgY2VudGVyIFNQIHdoaWNoDQo+PnVzZXMgVFJJTEwg d2l0aGluIGl0cyBkYXRhIGNlbnRlcnMpIHdoaWNoIGluIHR1cm4gdXNlIFZMQU5zIHRvIGlkZW50 aWZ5DQo+Pml0cyBkaWZmZXJlbnQgY3VzdG9tZXJzLCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGF0YSBj ZW50ZXIgaW50ZXJjb25uZWN0LiBJbg0KPj50aGlzIGNhc2UsIGl0IG1heSBiZSBoYXJkIGZvciB0 aGUgdGllci0yIGNhcnJpZXIgdG8gZW5zdXJlIHRoZXJlIGlzIG5vDQo+Pk1BQyBhZGRyZXNzIG92 ZXJsYXBwaW5nIGFjcm9zcyBtdWx0aXBsZSBjdXN0b21lciBWTEFOcyBvZiBpdHMgZGlmZmVyZW50 DQo+PmN1c3RvbWVycy90ZW5hbnRzLiBJbiBhZGRpdGlvbiwgdGhlIHZpcnR1YWwgbmV0d29yayB0 b3BvbG9naWVzIChpLmUuLCBQRQ0KPj5yb3V0ZXJzIHRvIHdoaWNoIGEgZ2l2ZW4gY3VzdG9tZXIv dGVuYW50IFZMQU4gaXMgYXR0YWNoZWQpIG9mIGRpZmZlcmVudA0KPj5jdXN0b21lcnMvdGVuYW50 cyBvZiB0aGUgZ2l2ZW4gdGllci0yIGNhcnJpZXIgYXJlIHVzdWFsbHkgZGlmZmVyZW50Lg0KPj4N Cj4+IEJlc3QgcmVnYXJkcywNCj4+IFhpYW9odQ0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ILeivP7IyzogR2lsZXMgSGVyb24gW2dpbGVzLmhlcm9u QGdtYWlsLmNvbV0NCj4+ILeiy83KsbzkOiAyMDEyxOoxMdTCOMjVIDE6NDUNCj4+ILW9OiBYdXhp YW9odQ0KPj4gQ2M6IFJvZ2VycywgSm9zaDsgbDJ2cG5AaWV0Zi5vcmcNCj4+INb3zOI6IFJlOiBW bGFuLWF3YXJlIGJ1bmRsaW5nIG92ZXIgVlBMUw0KPj4NCj4+IEhpIFhpYW9odSwNCj4+DQo+PiBJ IHRoaW5rIHdlIGFsbCB1bmRlcnN0YW5kIHRoZSBwb3RlbnRpYWwgYmVuZWZpdHMgb2YgVkxBTi1h d2FyZQ0KPj5idW5kbGluZy4gIEJ1dCBvZiBjb3Vyc2Ugbm90aGluZyBjb21lcyBmb3IgZnJlZSA7 KQ0KPj4NCj4+IEFuZCBpdCBzdGlsbCByZW1haW5zIGZvciBTUHMgdG8gZ2l2ZSBtb3JlIGZlZWRi YWNrIG9uIG15IHF1ZXN0aW9ucy4uLg0KPj4NCj4+IFdoYXQncyB5b3VyIHRoaW5raW5nIG9uIENT Qz8NCj4+DQo+PiBHaWxlcw0KPj4NCj4+IE9uIDcgTm92IDIwMTIsIGF0IDE2OjI5LCBYdXhpYW9o dSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pg0KPj4+IFdoZW4gbXVsdGlwbGUgY3Vz dG9tZXIgVkxBTnMgYXJlIGJvdW5kbGVkIHRvIGEgc2luZ2xlIFZQTFMgaW5zdGFuY2Ugb3INCj4+ PkVWUE4gaW5zdGFuY2UsIGl0J2QgYmV0dGVyIHRvIGtlZXAgdGhlIGJyb2FkY2FzdCBkb21haW4g YXNzb2NpYXRlZCB3aXRoDQo+Pj5lYWNoIGN1c3RvbWVyIFZMQU4gc2VwYXJhdGVkIGZyb20gZWFj aCBvdGhlci4gVGhlIG9idmlvdXMgYmVuZWZpdHMgb2YNCj4+PnN1Y2ggY2hvaWNlIGluY2x1ZGU6 IDEpIHN1cHBvcnQgb3ZlcmxhcHBpbmcgTUFDIGFkZHJlc3Mgc3BhY2VzIGFjcm9zcw0KPj4+ZGlm ZmVyZW50IGN1c3RvbWVyIFZMQU5zIGFuZCBhdm9pZCB1bm5lY2Nlc3NhcnkgTUFDIHdpdGhkcmF3 YWwgaW4gc3VjaA0KPj4+Y2FzZTsgMikgYXZvaWQgdGhlIHVubmVjY2Vzc2FyeSBmbG9vZCBvZiBC VU0gdHJhZmZpYyBvZiBhIGdpdmVuDQo+Pj5jdXN0b21lciBWTEFOIHRvIHRob3NlIFBFcyB3aGlj aCBhcmUgbm90IGF0dGFjaGVkIHdpdGggdGhhdCBjdXN0b21lcg0KPj4+VkxBTiB5ZXQuDQo+Pj4N Cj4+PiBPbmUgcG9zc2libGUgdXNlIGNhc2UgaXMgdGhlIENTQyBzY2VuYXJpby4NCj4+Pg0KPj4+ IFhpYW9odQ0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+ILeivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbDJ2cG4tYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBSb2dlcnMsIEpvc2gNCj4+Pltqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbV0NCj4+ PiC3osvNyrG85DogMjAxMsTqMTHUwjfI1SAyMzowNg0KPj4+ILW9OiBHaWxlcyBIZXJvbjsgbDJ2 cG5AaWV0Zi5vcmcNCj4+PiDW98ziOiBSZTogVmxhbi1hd2FyZSBidW5kbGluZyBvdmVyIFZQTFMN Cj4+Pg0KPj4+IDEpIGZvciB1cywgbm90IGN1cnJlbnRseS4gIEhvd2V2ZXIsIEkgdW5kZXJzdGFu ZCB0aGUgcHJvcG9zZWQgYmVuZWZpdA0KPj4+YW5kDQo+Pj4gaG93IGl0IGNvdWxkIGJlIGxldmVy YWdlZCwgYW5kIGJlbGlldmUgaXQgX21heV8gYmVjb21lIGEgbmVlZGVkDQo+Pj5mZWF0dXJlIGlu DQo+Pj4gdGhlIGZ1dHVyZS4gIFdlIGRvbid0IHNlZSB1c2UgY2FzZXMgdGhhdCB3b3VsZCBiZW5l Zml0IGZyb20gdGhpcw0KPj4+YXBwcm9hY2gNCj4+PiBfdG9kYXlfIHRob3VnaC4NCj4+PiAyKSBJ IHdvdWxkIGJlIGluY2xpbmVkIHRvIHNheSB0aGF0IGlmIGl0IGlzIGF2YWlsYWJsZSBpbiBWUExT LCBJJ2QNCj4+Pmxpa2UgdG8NCj4+PiBzZWUgaXQgaW4gRS1WUE4gKGFsdGhvdWdoIHRoZSBjb252 ZXJzZSBpcyBub3QgbmVjZXNzYXJpbHkgdHJ1ZSkNCj4+Pg0KPj4+IC1Kb3NoDQo+Pj4NCj4+Pg0K Pj4+IE9uIDExLzcvMTIgODo1NSBBTSwgIkdpbGVzIEhlcm9uIiA8Z2lsZXMuaGVyb25AZ21haWwu Y29tPiB3cm90ZToNCj4+Pg0KPj4+PiBJJ2xsIGxlYXZlIHRoZSBkcmFmdCBhdXRob3JzIHRvIGNv bW1lbnQgb24gdGhlIHBvaW50cyByYWlzZWQgYnkNCj4+Pj5IaW1hbnNodQ0KPj4+PiBhbmQgTHVj eQ0KPj4+Pg0KPj4+PiBCdXQgSSB3b3VsZCBsaWtlIFNQcyB0byBjb21tZW50IGFzIHRvOg0KPj4+ PiAxKSB3aGV0aGVyIFZMQU4tYXdhcmUgYnVuZGxpbmcgaXMgYSByZXF1aXJlbWVudA0KPj4+PiAy KSB3aGV0aGVyIHRoZXkgcmVxdWlyZSBWTEFOLWF3YXJlIGJ1bmRsaW5nIGJvdGggZm9yIFZQTFMg YW5kIEUtVlBODQo+Pj4+DQo+Pj4+IEdpbGVzIChjaGFpciBoYXQgZmlybWx5IG9uKS4NCj4+Pj4N Cj4+Pj4gT24gNyBOb3YgMjAxMiwgYXQgMTQ6MTMsIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdl aS5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+Pj4gVGhlcmUgaXMgYSB0cmFkZS1vZmYgb24gdGhlIHNv bHV0aW9uLiBpbmRpdmlkdWFsIEJEIG1heSBoYXZlDQo+Pj4+PmRpZmZlcmVudA0KPj4+Pj4gUW9T IHJlcXVpcmVtZW50LCBtdWx0aXBseGluZyB0aGVtIHRvZ2V0aGVyIGluIGEgc2luZ2xlIFBXIG1h eSBsb3NlDQo+Pj4+PnNvbWUNCj4+Pj4+IFFvUyBhbmQgT0FNIGNhcGFiaWxpdHkuIEZvciBleGFt cGxlLCB3aGVuIGNvbmdlc3Rpb24gaGFwcGVucywgc29tZSBCRA0KPj4+Pj4gbWF5IHdvcmsgYW5k IHNvbWUgbWF5IG5vdCwgUFcgc3RhdHVzIGlzIG5vdCBhYmxlIHRvIHJlZmxleCB0aGF0DQo+Pj4+ PiBwcm9wZXJseS4NCj4+Pj4+DQo+Pj4+PiBMdWN5DQo+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4+Pj5CZWhhbGYNCj4+Pj4+PiBPZiBT aGFoLCBIaW1hbnNodQ0KPj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA2LCAyMDEyIDI6 MDQgUE0NCj4+Pj4+PiBUbzogbDJ2cG5AaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBWbGFuLWF3 YXJlIGJ1bmRsaW5nIG92ZXIgVlBMUw0KPj4+Pj4+DQo+Pj4+Pj4gY2xhcmlmaWNhdGlvbiBxdWVz dGlvbjogICBJZiB2bGFuIGlzIHRoZSB0YWcgdXNlZCBmb3IgZGVtdXggb3Zlcg0KPj4+Pj4+c2lu Z2xlDQo+Pj4+Pj4gUFcgYW5kIGlmIHRoYXQgdmxhbiBuZWVkcyB0byBiZSBhZHZlcnRpc2VkIHRo ZW4gd2hhdCBpcyB0aGUgc2F2aW5nPw0KPj4+Pj4+SXMNCj4+Pj4+PiB0aGlzIGp1c3Qgc2F2aW5n IG9mIHRoZSBQVyBsYWJlbD8NCj4+Pj4+PiBIaW1hbnNodQ0KPj4+Pj4+DQo+Pj4+Pj4gU2VudCBm cm9tIG15IGlQYWQNCj4+Pj4NCj4+Pg0KPj4+DQo+Pj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+PnByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1 YmplY3QNCj4+PnRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRo aXMgRS1tYWlsIGlzIGludGVuZGVkDQo+Pj5zb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzDQo+Pj5hZGRyZXNzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdQ0KPj4+YXJlIGhl cmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlp bmcsIG9yDQo+Pj5hY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFu ZCBhdHRhY2htZW50cyB0byB0aGlzDQo+Pj5FLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPj4+dGhpcyBFLW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQNCj4+PnBl cm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWls IGFuZCBhbnkNCj4+PnByaW50b3V0Lg0KPg0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGlu Zm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3Qg dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwg aXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGlu IHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1h aWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkg Y29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg== From lucy.yong@huawei.com Wed Nov 7 11:32:30 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 47AE221F8831 for ; Wed, 7 Nov 2012 11:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 RlheZrgg0r98 for ; Wed, 7 Nov 2012 11:32:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC8B221F8825 for ; Wed, 7 Nov 2012 11:32:26 -0800 (PST) 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 AMN12267; Wed, 07 Nov 2012 19:32:25 +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; Wed, 7 Nov 2012 19:32:14 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 19:32:24 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 11:32:22 -0800 From: Lucy yong To: Giles Heron , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABJ1ZIAABzxhsA== Date: Wed, 7 Nov 2012 19:32:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482D178@dfweml505-mbx> References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com> In-Reply-To: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 07 Nov 2012 19:32:30 -0000 I would like to add one more question to SP beside Giles's 3) Does this service aspect mean whenever customer want to add a new VLAN (= a BD) into the VPLS service, it has to inform the SP and SP has to provisio= n this on PE? Thanks, Lucy > -----Original Message----- > From: Giles Heron [mailto:giles.heron@gmail.com] > Sent: Wednesday, November 07, 2012 8:55 AM > To: l2vpn@ietf.org > Cc: Himanshu Shah; Lucy yong; Nabil Bitar > Subject: Re: Vlan-aware bundling over VPLS >=20 > I'll leave the draft authors to comment on the points raised by > Himanshu and Lucy >=20 > But I would like SPs to comment as to: > 1) whether VLAN-aware bundling is a requirement > 2) whether they require VLAN-aware bundling both for VPLS and E-VPN >=20 > Giles (chair hat firmly on). >=20 > On 7 Nov 2012, at 14:13, Lucy yong wrote: >=20 > > There is a trade-off on the solution. individual BD may have > different QoS requirement, multiplxing them together in a single PW may > lose some QoS and OAM capability. For example, when congestion happens, > some BD may work and some may not, PW status is not able to reflex that > properly. > > > > Lucy > > > >> -----Original Message----- > >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > >> Of Shah, Himanshu > >> Sent: Tuesday, November 06, 2012 2:04 PM > >> To: l2vpn@ietf.org > >> Subject: Vlan-aware bundling over VPLS > >> > >> clarification question: If vlan is the tag used for demux over > single > >> PW and if that vlan needs to be advertised then what is the saving? > Is > >> this just saving of the PW label? > >> Himanshu > >> > >> Sent from my iPad From josh.rogers@twcable.com Wed Nov 7 11:36: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 A4D6E21F8B34 for ; Wed, 7 Nov 2012 11:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[AWL=0.801, 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 T+g0DnXAvh73 for ; Wed, 7 Nov 2012 11:36:47 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id F0A3521F8831 for ; Wed, 7 Nov 2012 11:36:46 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,732,1344225600"; d="scan'208";a="447707460" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Nov 2012 14:36:06 -0500 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 7 Nov 2012 14:36:45 -0500 From: "Rogers, Josh" To: Lucy yong , Giles Heron , "l2vpn@ietf.org" Date: Wed, 7 Nov 2012 14:36:45 -0500 Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac29HziO4hM7AUR/TtO/mUZdEgsQDw== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482D178@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 07 Nov 2012 19:36:47 -0000 Regarding the trans-AS service scenario? What we had previously discussed/envisioned, and I've seen one other SP do, is buy a ELAN type service from another operator (who delivered via VPLS). This allowed them to put any VLAN they like on the ENNI, and deliver it to any endpoint on the VPLS instance. Since they own the equipment (CPE) at each end, they simply allowed the vlan(s) they wanted to deliver to that end point. Since the VPLS instance is mac-learning, the only traffic that is delivered that may be dropped by the CPE is BUM traffic. I'm not certain I understand the question well. Does that answer it? -Josh On 11/7/12 1:32 PM, "Lucy yong" wrote: >I would like to add one more question to SP beside Giles's > >3) Does this service aspect mean whenever customer want to add a new VLAN >(a BD) into the VPLS service, it has to inform the SP and SP has to >provision this on PE? > >Thanks, >Lucy > >> -----Original Message----- >> From: Giles Heron [mailto:giles.heron@gmail.com] >> Sent: Wednesday, November 07, 2012 8:55 AM >> To: l2vpn@ietf.org >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar >> Subject: Re: Vlan-aware bundling over VPLS >> >> I'll leave the draft authors to comment on the points raised by >> Himanshu and Lucy >> >> But I would like SPs to comment as to: >> 1) whether VLAN-aware bundling is a requirement >> 2) whether they require VLAN-aware bundling both for VPLS and E-VPN >> >> Giles (chair hat firmly on). >> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: >> >> > There is a trade-off on the solution. individual BD may have >> different QoS requirement, multiplxing them together in a single PW may >> lose some QoS and OAM capability. For example, when congestion happens, >> some BD may work and some may not, PW status is not able to reflex that >> properly. >> > >> > Lucy >> > >> >> -----Original Message----- >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> >> Of Shah, Himanshu >> >> Sent: Tuesday, November 06, 2012 2:04 PM >> >> To: l2vpn@ietf.org >> >> Subject: Vlan-aware bundling over VPLS >> >> >> >> clarification question: If vlan is the tag used for demux over >> single >> >> PW and if that vlan needs to be advertised then what is the saving? >> Is >> >> this just saving of the PW label? >> >> Himanshu >> >> >> >> Sent from my iPad > 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 lucy.yong@huawei.com Wed Nov 7 12:03:14 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D21F21F8CCC for ; Wed, 7 Nov 2012 12:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 SzMkCyv4E+Vr for ; Wed, 7 Nov 2012 12:03:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BB0BF21F8CC9 for ; Wed, 7 Nov 2012 12:03:11 -0800 (PST) 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 AMN13497; Wed, 07 Nov 2012 20:03:10 +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; Wed, 7 Nov 2012 20:02:59 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 20:03:08 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 12:02:59 -0800 From: Lucy yong To: "Rogers, Josh" , Giles Heron , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABJ1ZIAABzxhsAACmeuAABATZ6A= Date: Wed, 7 Nov 2012 20:02:59 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482D1D5@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482D178@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 07 Nov 2012 20:03:14 -0000 Hi Josh, Thank you for the reply first. > -----Original Message----- > From: Rogers, Josh [mailto:josh.rogers@twcable.com] > Sent: Wednesday, November 07, 2012 1:37 PM > To: Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: Re: Vlan-aware bundling over VPLS >=20 > Regarding the trans-AS service scenario?=20 [Lucy] I don't know, I post the question to know where it will be used. What we had previously > discussed/envisioned, and I've seen one other SP do, is buy a ELAN type > service from another operator (who delivered via VPLS). This allowed > them > to put any VLAN they like on the ENNI, and deliver it to any endpoint > on > the VPLS instance. Since they own the equipment (CPE) at each end, > they > simply allowed the vlan(s) they wanted to deliver to that end point. > Since the VPLS instance is mac-learning, the only traffic that is > delivered that may be dropped by the CPE is BUM traffic. [Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter. = The critical question for this scenario is if each VLAN has its own MAC spa= ce or not?=20 Lucy >=20 > I'm not certain I understand the question well. Does that answer it? >=20 > -Josh >=20 >=20 >=20 > On 11/7/12 1:32 PM, "Lucy yong" wrote: >=20 > >I would like to add one more question to SP beside Giles's > > > >3) Does this service aspect mean whenever customer want to add a new > VLAN > >(a BD) into the VPLS service, it has to inform the SP and SP has to > >provision this on PE? > > > >Thanks, > >Lucy > > > >> -----Original Message----- > >> From: Giles Heron [mailto:giles.heron@gmail.com] > >> Sent: Wednesday, November 07, 2012 8:55 AM > >> To: l2vpn@ietf.org > >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > >> Subject: Re: Vlan-aware bundling over VPLS > >> > >> I'll leave the draft authors to comment on the points raised by > >> Himanshu and Lucy > >> > >> But I would like SPs to comment as to: > >> 1) whether VLAN-aware bundling is a requirement > >> 2) whether they require VLAN-aware bundling both for VPLS and E-VPN > >> > >> Giles (chair hat firmly on). > >> > >> On 7 Nov 2012, at 14:13, Lucy yong wrote: > >> > >> > There is a trade-off on the solution. individual BD may have > >> different QoS requirement, multiplxing them together in a single PW > may > >> lose some QoS and OAM capability. For example, when congestion > happens, > >> some BD may work and some may not, PW status is not able to reflex > that > >> properly. > >> > > >> > Lucy > >> > > >> >> -----Original Message----- > >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> Behalf > >> >> Of Shah, Himanshu > >> >> Sent: Tuesday, November 06, 2012 2:04 PM > >> >> To: l2vpn@ietf.org > >> >> Subject: Vlan-aware bundling over VPLS > >> >> > >> >> clarification question: If vlan is the tag used for demux over > >> single > >> >> PW and if that vlan needs to be advertised then what is the > saving? > >> Is > >> >> this just saving of the PW label? > >> >> Himanshu > >> >> > >> >> Sent from my iPad > > >=20 >=20 > 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 josh.rogers@twcable.com Wed Nov 7 12:09:13 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 D1AD021F8C7B for ; Wed, 7 Nov 2012 12:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.52 X-Spam-Level: * X-Spam-Status: No, score=1.52 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 yxBVVrzFUmZF for ; Wed, 7 Nov 2012 12:09:13 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id C42A021F8BC2 for ; Wed, 7 Nov 2012 12:09:02 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,732,1344225600"; d="scan'208";a="466683698" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Nov 2012 15:08:17 -0500 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 7 Nov 2012 15:08:58 -0500 From: "Rogers, Josh" To: Lucy yong , Giles Heron , "l2vpn@ietf.org" Date: Wed, 7 Nov 2012 15:08:58 -0500 Subject: Re: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac29I7kJFI1msrFjS/Cwhx87BN7UnA== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482D1D5@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 07 Nov 2012 20:09:13 -0000 [Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter. The critical question for this scenario is if each VLAN has its own MAC space or not? Under the currently available VPLS method, the MAC table is shared for the entire VPLS instance. This method is no different than a native ethernet network using 802.1ad, I'm not concerned with 'isolating' the mac table between vlans, but if I was I'd be inclined to use something available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) -Josh On 11/7/12 2:02 PM, "Lucy yong" wrote: >Hi Josh, > >Thank you for the reply first. > >> -----Original Message----- >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> Sent: Wednesday, November 07, 2012 1:37 PM >> To: Lucy yong; Giles Heron; l2vpn@ietf.org >> Subject: Re: Vlan-aware bundling over VPLS >> >> Regarding the trans-AS service scenario? >[Lucy] I don't know, I post the question to know where it will be used. > What we had previously >> discussed/envisioned, and I've seen one other SP do, is buy a ELAN type >> service from another operator (who delivered via VPLS). This allowed >> them >> to put any VLAN they like on the ENNI, and deliver it to any endpoint >> on >> the VPLS instance. Since they own the equipment (CPE) at each end, >> they >> simply allowed the vlan(s) they wanted to deliver to that end point. >> Since the VPLS instance is mac-learning, the only traffic that is >> delivered that may be dropped by the CPE is BUM traffic. >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the >filter. The critical question for this scenario is if each VLAN has its >own MAC space or not? > >Lucy >> >> I'm not certain I understand the question well. Does that answer it? >> >> -Josh >> >> >> >> On 11/7/12 1:32 PM, "Lucy yong" wrote: >> >> >I would like to add one more question to SP beside Giles's >> > >> >3) Does this service aspect mean whenever customer want to add a new >> VLAN >> >(a BD) into the VPLS service, it has to inform the SP and SP has to >> >provision this on PE? >> > >> >Thanks, >> >Lucy >> > >> >> -----Original Message----- >> >> From: Giles Heron [mailto:giles.heron@gmail.com] >> >> Sent: Wednesday, November 07, 2012 8:55 AM >> >> To: l2vpn@ietf.org >> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar >> >> Subject: Re: Vlan-aware bundling over VPLS >> >> >> >> I'll leave the draft authors to comment on the points raised by >> >> Himanshu and Lucy >> >> >> >> But I would like SPs to comment as to: >> >> 1) whether VLAN-aware bundling is a requirement >> >> 2) whether they require VLAN-aware bundling both for VPLS and E-VPN >> >> >> >> Giles (chair hat firmly on). >> >> >> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: >> >> >> >> > There is a trade-off on the solution. individual BD may have >> >> different QoS requirement, multiplxing them together in a single PW >> may >> >> lose some QoS and OAM capability. For example, when congestion >> happens, >> >> some BD may work and some may not, PW status is not able to reflex >> that >> >> properly. >> >> > >> >> > Lucy >> >> > >> >> >> -----Original Message----- >> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> >> Behalf >> >> >> Of Shah, Himanshu >> >> >> Sent: Tuesday, November 06, 2012 2:04 PM >> >> >> To: l2vpn@ietf.org >> >> >> Subject: Vlan-aware bundling over VPLS >> >> >> >> >> >> clarification question: If vlan is the tag used for demux over >> >> single >> >> >> PW and if that vlan needs to be advertised then what is the >> saving? >> >> Is >> >> >> this just saving of the PW label? >> >> >> Himanshu >> >> >> >> >> >> Sent from my iPad >> > >> >> >> 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 lucy.yong@huawei.com Wed Nov 7 12:13: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 39C7421F8878 for ; Wed, 7 Nov 2012 12:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=-1.849, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 meG9EGOzx-G8 for ; Wed, 7 Nov 2012 12:13:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E83D321F87D0 for ; Wed, 7 Nov 2012 12:13:25 -0800 (PST) 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 AMN13904; Wed, 07 Nov 2012 20:13:25 +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; Wed, 7 Nov 2012 20:13:12 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 20:13:21 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 12:13:16 -0800 From: Lucy yong To: "Rogers, Josh" , Giles Heron , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAABJ1ZIAABzxhsAACmeuAABATZ6D//4hlAIAAhc+Q Date: Wed, 7 Nov 2012 20:13:16 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482D1EA@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4482D1D5@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 07 Nov 2012 20:13:27 -0000 Hi Josh, Thank you for the clarification. This means that all-to-one bundles service= interface can do this scenarios. Highly appreciate in sharing your insight as a Service Provider. Lucy > -----Original Message----- > From: Rogers, Josh [mailto:josh.rogers@twcable.com] > Sent: Wednesday, November 07, 2012 2:09 PM > To: Lucy yong; Giles Heron; l2vpn@ietf.org > Subject: Re: Vlan-aware bundling over VPLS >=20 > [Lucy] IMO: this is what all-to-one bundle offer. CPE performs the > filter. > The critical question for this scenario is if each VLAN has its own MAC > space or not? >=20 > Under the currently available VPLS method, the MAC table is shared for > the > entire VPLS instance. This method is no different than a native > ethernet > network using 802.1ad, I'm not concerned with 'isolating' the mac table > between vlans, but if I was I'd be inclined to use something available > (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) >=20 >=20 > -Josh >=20 >=20 > On 11/7/12 2:02 PM, "Lucy yong" wrote: >=20 > >Hi Josh, > > > >Thank you for the reply first. > > > >> -----Original Message----- > >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >> Sent: Wednesday, November 07, 2012 1:37 PM > >> To: Lucy yong; Giles Heron; l2vpn@ietf.org > >> Subject: Re: Vlan-aware bundling over VPLS > >> > >> Regarding the trans-AS service scenario? > >[Lucy] I don't know, I post the question to know where it will be used. > > What we had previously > >> discussed/envisioned, and I've seen one other SP do, is buy a ELAN > type > >> service from another operator (who delivered via VPLS). This > allowed > >> them > >> to put any VLAN they like on the ENNI, and deliver it to any > endpoint > >> on > >> the VPLS instance. Since they own the equipment (CPE) at each end, > >> they > >> simply allowed the vlan(s) they wanted to deliver to that end point. > >> Since the VPLS instance is mac-learning, the only traffic that is > >> delivered that may be dropped by the CPE is BUM traffic. > >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the > >filter. The critical question for this scenario is if each VLAN has > its > >own MAC space or not? > > > >Lucy > >> > >> I'm not certain I understand the question well. Does that answer it? > >> > >> -Josh > >> > >> > >> > >> On 11/7/12 1:32 PM, "Lucy yong" wrote: > >> > >> >I would like to add one more question to SP beside Giles's > >> > > >> >3) Does this service aspect mean whenever customer want to add a > new > >> VLAN > >> >(a BD) into the VPLS service, it has to inform the SP and SP has to > >> >provision this on PE? > >> > > >> >Thanks, > >> >Lucy > >> > > >> >> -----Original Message----- > >> >> From: Giles Heron [mailto:giles.heron@gmail.com] > >> >> Sent: Wednesday, November 07, 2012 8:55 AM > >> >> To: l2vpn@ietf.org > >> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > >> >> Subject: Re: Vlan-aware bundling over VPLS > >> >> > >> >> I'll leave the draft authors to comment on the points raised by > >> >> Himanshu and Lucy > >> >> > >> >> But I would like SPs to comment as to: > >> >> 1) whether VLAN-aware bundling is a requirement > >> >> 2) whether they require VLAN-aware bundling both for VPLS and E- > VPN > >> >> > >> >> Giles (chair hat firmly on). > >> >> > >> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: > >> >> > >> >> > There is a trade-off on the solution. individual BD may have > >> >> different QoS requirement, multiplxing them together in a single > PW > >> may > >> >> lose some QoS and OAM capability. For example, when congestion > >> happens, > >> >> some BD may work and some may not, PW status is not able to > reflex > >> that > >> >> properly. > >> >> > > >> >> > Lucy > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] > On > >> >> Behalf > >> >> >> Of Shah, Himanshu > >> >> >> Sent: Tuesday, November 06, 2012 2:04 PM > >> >> >> To: l2vpn@ietf.org > >> >> >> Subject: Vlan-aware bundling over VPLS > >> >> >> > >> >> >> clarification question: If vlan is the tag used for demux > over > >> >> single > >> >> >> PW and if that vlan needs to be advertised then what is the > >> saving? > >> >> Is > >> >> >> this just saving of the PW label? > >> >> >> Himanshu > >> >> >> > >> >> >> Sent from my iPad > >> > > >> > >> > >> 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. >=20 >=20 > 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 bedard.phil@gmail.com Wed Nov 7 12:27:30 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 31DB621F8BAE for ; Wed, 7 Nov 2012 12:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEGRBkcJ8v0Q for ; Wed, 7 Nov 2012 12:27:29 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5421F8AB5 for ; Wed, 7 Nov 2012 12:27:29 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id i4so436841ggn.31 for ; Wed, 07 Nov 2012 12:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=Zr2QK2cOqa0qiw1tgQHSwlhKzw9CmnMcnc1aEuU1xHs=; b=enTw+O31RKhp5qzhgHwehjBxa3AFBE6MefkA2At0hYADFdS+3oRWKCi8kirUag+3Yf dIlGPcMPxBFrsBi7uWWn5ZCELpml252ictRglk/xKC99IknzCqJpATWYeArezVp0j75d tLNwC48euMI6fb7Ze6rZ0nM47l8EYJ/hfyT9LhX0SFiy8b8d03xZ6oWBCVrXSkMUoN+7 HEepNKe6qXqOhGtl9NG0I0JN5A5/QpzDlQlap6595IHQNdpUFQ4tpM+1Ovb4u8Sy4yJd Dbq/jIocA4jC2SboufurGJx6RvKoop5HtfkHQ0ZJWUxOW3HcvODZA6Cyd7RypVX6C/vj 27dg== Received: by 10.101.73.2 with SMTP id a2mr1714720anl.82.1352320048817; Wed, 07 Nov 2012 12:27:28 -0800 (PST) Received: from [192.168.1.103] (71-90-205-142.dhcp.stls.mo.charter.com. [71.90.205.142]) by mx.google.com with ESMTPS id i26sm14174397yhc.10.2012.11.07.12.27.27 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 12:27:28 -0800 (PST) References: <6C8C4742-F540-4E2A-BF5C-D1FFB5C71D54@ciena.com> <2691CE0099834E4A9C5044EEC662BB9D4482CE65@dfweml505-mbx> <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com> In-Reply-To: <4F67B0CF-339C-46F3-81D4-CEB7CBE629B7@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3B75D12D-4D4F-4A7B-997C-BCC056231653@gmail.com> X-Mailer: iPad Mail (10A523) From: Phil Bedard Subject: Re: Vlan-aware bundling over VPLS Date: Wed, 7 Nov 2012 15:27:28 -0500 To: Giles Heron 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, 07 Nov 2012 20:27:30 -0000 1) I have not seen this specific use case come up but I can understand the b= enefits and can't say it wouldn't be useful in some service scenarios but se= e my additional comments. We've been deploying VPLS for years now without i= t so I wouldn't state it as a "requirement" but would certainly ease configu= ration in specific use cases. =20 2) No, I see EVPN as a step forward from the current LDP VPLS, I don't think= we need to back port every new feature in EVPN into VPLS.=20 I have some additional comments. Some vendors do bundling already where multiple VLANs can be used within t= he same service as delimiters, the new part is maintaining a separate bridge= domain. I'm not sure why the VLANs need to be communicated, maintaining a s= eparate BD per VLAN seems like a local decision, if the VLAN is always prese= nt either from the AC or via PW the device should be able to learn and store= the VLAN/MAC combo as a separate entity like any other modern switch. If t= he far end receives a frame for a VLAN not defined in the egress AC it shoul= d discard it. =20 The draft says port or raw mode must be used, maybe a reference to RFC 4448 s= hould be included. Also the VLANs bing bundled would be locally defined and= constitute a service delimiter. According to that specific RFC raw mode i= s supposed to strip the VLAN in a service delimiting mode.=20 I do not see any QoS concerns, traffic will be classified on ingress and use= the same MPLS mechanisms whether it was one service or 10 services. =20 Phil=20 On Nov 7, 2012, at 9:55 AM, Giles Heron wrote: > I'll leave the draft authors to comment on the points raised by Himanshu a= nd Lucy >=20 > But I would like SPs to comment as to: > 1) whether VLAN-aware bundling is a requirement > 2) whether they require VLAN-aware bundling both for VPLS and E-VPN >=20 > Giles (chair hat firmly on). >=20 > On 7 Nov 2012, at 14:13, Lucy yong wrote: >=20 >> There is a trade-off on the solution. individual BD may have different Qo= S requirement, multiplxing them together in a single PW may lose some QoS an= d OAM capability. For example, when congestion happens, some BD may work and= some may not, PW status is not able to reflex that properly.=20 >>=20 >> Lucy >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Shah, Himanshu >>> Sent: Tuesday, November 06, 2012 2:04 PM >>> To: l2vpn@ietf.org >>> Subject: Vlan-aware bundling over VPLS >>>=20 >>> clarification question: If vlan is the tag used for demux over single >>> PW and if that vlan needs to be advertised then what is the saving? Is >>> this just saving of the PW label? >>> Himanshu >>>=20 >>> Sent from my iPad >=20 From ju1738@att.com Wed Nov 7 13:23:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DA121F8C5B for ; Wed, 7 Nov 2012 13:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 FX6lcOUf9A-f for ; Wed, 7 Nov 2012 13:23:04 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 83D0E21F8C2B for ; Wed, 7 Nov 2012 13:23:01 -0800 (PST) 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 531da905.507c7940.1322614.00-580.3638707.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 07 Nov 2012 21:23:01 +0000 (UTC) X-MXL-Hash: 509ad13578a8cb41-86267b0e77140ad56ec4130af86db309262d3f14 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 d21da905.0.1322570.00-413.3638574.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 07 Nov 2012 21:22:54 +0000 (UTC) X-MXL-Hash: 509ad12e3043b929-f30678222aaf68db3411116df9ef0478259ad1db 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 qA7LMrZW031836; Wed, 7 Nov 2012 16:22:53 -0500 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 qA7LMn0S031802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2012 16:22:50 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint02.pst.cso.att.com (RSA Interceptor); Wed, 7 Nov 2012 16:22:32 -0500 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; Wed, 7 Nov 2012 16:22:32 -0500 From: "UTTARO, JAMES" To: "'Rogers, Josh'" , Lucy yong , Giles Heron , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac29I7kJFI1msrFjS/Cwhx87BN7UnAACjeDA Date: Wed, 7 Nov 2012 21:22:32 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D4482D1D5@dfweml505-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.34.104] 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=a66HAzuF c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=bioNPC6pb8UA:10 a=O1JkpWTQeKAA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=e4zrjMI_K6IA:10 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8] X-AnalysisOut: [ a=ahv8dbORAAAA:8 a=pGLkceISAAAA:8 a=slXdvz-nXN_O7W9zF74A:] X-AnalysisOut: [9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=] X-AnalysisOut: [BDsChg1p1CEA:10 a=MSl-tDqOz04A:10 a=1dxmnwy_sBso_oW4:21 a=] X-AnalysisOut: [JRxVsTVYG8oO9xzD:21] 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, 07 Nov 2012 21:23:05 -0000 +1..=20 Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: Wednesday, November 07, 2012 3:09 PM To: Lucy yong; Giles Heron; l2vpn@ietf.org Subject: Re: Vlan-aware bundling over VPLS [Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter. The critical question for this scenario is if each VLAN has its own MAC space or not? Under the currently available VPLS method, the MAC table is shared for the entire VPLS instance. This method is no different than a native ethernet network using 802.1ad, I'm not concerned with 'isolating' the mac table between vlans, but if I was I'd be inclined to use something available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) -Josh On 11/7/12 2:02 PM, "Lucy yong" wrote: >Hi Josh, > >Thank you for the reply first. > >> -----Original Message----- >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> Sent: Wednesday, November 07, 2012 1:37 PM >> To: Lucy yong; Giles Heron; l2vpn@ietf.org >> Subject: Re: Vlan-aware bundling over VPLS >> >> Regarding the trans-AS service scenario? >[Lucy] I don't know, I post the question to know where it will be used. > What we had previously >> discussed/envisioned, and I've seen one other SP do, is buy a ELAN type >> service from another operator (who delivered via VPLS). This allowed >> them >> to put any VLAN they like on the ENNI, and deliver it to any endpoint >> on >> the VPLS instance. Since they own the equipment (CPE) at each end, >> they >> simply allowed the vlan(s) they wanted to deliver to that end point. >> Since the VPLS instance is mac-learning, the only traffic that is >> delivered that may be dropped by the CPE is BUM traffic. >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the >filter. The critical question for this scenario is if each VLAN has its >own MAC space or not? > >Lucy >> >> I'm not certain I understand the question well. Does that answer it? >> >> -Josh >> >> >> >> On 11/7/12 1:32 PM, "Lucy yong" wrote: >> >> >I would like to add one more question to SP beside Giles's >> > >> >3) Does this service aspect mean whenever customer want to add a new >> VLAN >> >(a BD) into the VPLS service, it has to inform the SP and SP has to >> >provision this on PE? >> > >> >Thanks, >> >Lucy >> > >> >> -----Original Message----- >> >> From: Giles Heron [mailto:giles.heron@gmail.com] >> >> Sent: Wednesday, November 07, 2012 8:55 AM >> >> To: l2vpn@ietf.org >> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar >> >> Subject: Re: Vlan-aware bundling over VPLS >> >> >> >> I'll leave the draft authors to comment on the points raised by >> >> Himanshu and Lucy >> >> >> >> But I would like SPs to comment as to: >> >> 1) whether VLAN-aware bundling is a requirement >> >> 2) whether they require VLAN-aware bundling both for VPLS and E-VPN >> >> >> >> Giles (chair hat firmly on). >> >> >> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: >> >> >> >> > There is a trade-off on the solution. individual BD may have >> >> different QoS requirement, multiplxing them together in a single PW >> may >> >> lose some QoS and OAM capability. For example, when congestion >> happens, >> >> some BD may work and some may not, PW status is not able to reflex >> that >> >> properly. >> >> > >> >> > Lucy >> >> > >> >> >> -----Original Message----- >> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> >> Behalf >> >> >> Of Shah, Himanshu >> >> >> Sent: Tuesday, November 06, 2012 2:04 PM >> >> >> To: l2vpn@ietf.org >> >> >> Subject: Vlan-aware bundling over VPLS >> >> >> >> >> >> clarification question: If vlan is the tag used for demux over >> >> single >> >> >> PW and if that vlan needs to be advertised then what is the >> saving? >> >> Is >> >> >> this just saving of the PW label? >> >> >> Himanshu >> >> >> >> >> >> Sent from my iPad >> > >> >> >> 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 david.i.allan@ericsson.com Wed Nov 7 13:40:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A16921F8C45 for ; Wed, 7 Nov 2012 13:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 JGzSwVHcRU2d for ; Wed, 7 Nov 2012 13:39:59 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3654B21F8C90 for ; Wed, 7 Nov 2012 13:39:59 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA7LixdL004168; Wed, 7 Nov 2012 15:45:00 -0600 Received: from EUSAAHC004.ericsson.se (147.117.188.84) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 7 Nov 2012 16:39:45 -0500 Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 16:39:44 -0500 From: David Allan I To: "UTTARO, JAMES" , "'Rogers, Josh'" , Lucy yong , Giles Heron , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAAAwsEYAACa8bAAAAJzCAAADqjIAAADV/AAACkbwAAAoxEfA= Date: Wed, 7 Nov 2012 21:39:43 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D4482D1D5@dfweml505-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 07 Nov 2012 21:40:00 -0000 Given in 802.1 standards there is IVL (independent VLAN learning) and SVL (= shared VLAN learning), whether a MAC table exists per VID, per group of VID= s, or for all VIDs in a bundle in theory is an implementation/operational c= hoice. Or should be. SVL does permit MAC information gleaned from one VID's traffic to be used b= y another, which reduces the number of unknowns. OTOH if the VIDs identify = completely disjoint sets of endpoints there is no shared information of con= sequence. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of U= TTARO, JAMES Sent: Wednesday, November 07, 2012 1:23 PM To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org Subject: RE: Vlan-aware bundling over VPLS +1..=20 Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: Wednesday, November 07, 2012 3:09 PM To: Lucy yong; Giles Heron; l2vpn@ietf.org Subject: Re: Vlan-aware bundling over VPLS [Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter. The critical question for this scenario is if each VLAN has its own MAC spa= ce or not? Under the currently available VPLS method, the MAC table is shared for the = entire VPLS instance. This method is no different than a native ethernet n= etwork using 802.1ad, I'm not concerned with 'isolating' the mac table betw= een vlans, but if I was I'd be inclined to use something available (ie, mul= tiple VPLS instances/multiple PW's, or PBB/PBT) -Josh On 11/7/12 2:02 PM, "Lucy yong" wrote: >Hi Josh, > >Thank you for the reply first. > >> -----Original Message----- >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> Sent: Wednesday, November 07, 2012 1:37 PM >> To: Lucy yong; Giles Heron; l2vpn@ietf.org >> Subject: Re: Vlan-aware bundling over VPLS >> >> Regarding the trans-AS service scenario? >[Lucy] I don't know, I post the question to know where it will be used. > What we had previously >> discussed/envisioned, and I've seen one other SP do, is buy a ELAN=20 >> type service from another operator (who delivered via VPLS). This=20 >> allowed them to put any VLAN they like on the ENNI, and deliver it to=20 >> any endpoint on the VPLS instance. Since they own the equipment=20 >> (CPE) at each end, they simply allowed the vlan(s) they wanted to=20 >> deliver to that end point. >> Since the VPLS instance is mac-learning, the only traffic that is=20 >> delivered that may be dropped by the CPE is BUM traffic. >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the=20 >filter. The critical question for this scenario is if each VLAN has its=20 >own MAC space or not? > >Lucy >> >> I'm not certain I understand the question well. Does that answer it? >> >> -Josh >> >> >> >> On 11/7/12 1:32 PM, "Lucy yong" wrote: >> >> >I would like to add one more question to SP beside Giles's >> > >> >3) Does this service aspect mean whenever customer want to add a new >> VLAN >> >(a BD) into the VPLS service, it has to inform the SP and SP has to=20 >> >provision this on PE? >> > >> >Thanks, >> >Lucy >> > >> >> -----Original Message----- >> >> From: Giles Heron [mailto:giles.heron@gmail.com] >> >> Sent: Wednesday, November 07, 2012 8:55 AM >> >> To: l2vpn@ietf.org >> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar >> >> Subject: Re: Vlan-aware bundling over VPLS >> >> >> >> I'll leave the draft authors to comment on the points raised by=20 >> >> Himanshu and Lucy >> >> >> >> But I would like SPs to comment as to: >> >> 1) whether VLAN-aware bundling is a requirement >> >> 2) whether they require VLAN-aware bundling both for VPLS and=20 >> >> E-VPN >> >> >> >> Giles (chair hat firmly on). >> >> >> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: >> >> >> >> > There is a trade-off on the solution. individual BD may have >> >> different QoS requirement, multiplxing them together in a single=20 >> >> PW >> may >> >> lose some QoS and OAM capability. For example, when congestion >> happens, >> >> some BD may work and some may not, PW status is not able to reflex >> that >> >> properly. >> >> > >> >> > Lucy >> >> > >> >> >> -----Original Message----- >> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> >> Behalf >> >> >> Of Shah, Himanshu >> >> >> Sent: Tuesday, November 06, 2012 2:04 PM >> >> >> To: l2vpn@ietf.org >> >> >> Subject: Vlan-aware bundling over VPLS >> >> >> >> >> >> clarification question: If vlan is the tag used for demux over >> >> single >> >> >> PW and if that vlan needs to be advertised then what is the >> saving? >> >> Is >> >> >> this just saving of the PW label? >> >> >> Himanshu >> >> >> >> >> >> Sent from my iPad >> > >> >> >> This E-mail and any of its attachments may contain Time Warner Cable=20 >> proprietary information, which is privileged, confidential, or=20 >> subject to copyright belonging to Time Warner Cable. This E-mail is=20 >> intended solely for the use of the individual or entity to which it is a= ddressed. >> If you are not the intended recipient of this E-mail, you are hereby=20 >> notified that any dissemination, distribution, copying, or action=20 >> taken in relation to the contents of and attachments to this E-mail=20 >> is strictly prohibited and may be unlawful. If you have received this=20 >> E- mail in error, please notify the sender immediately and=20 >> permanently delete the original and any copy of this E-mail and any prin= tout. 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 donald.fedyk@alcatel-lucent.com Wed Nov 7 16:06: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 8D76E21F8901 for ; Wed, 7 Nov 2012 16:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 d7v8arKH3FlW for ; Wed, 7 Nov 2012 16:06:44 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id EE0BF21F8B82 for ; Wed, 7 Nov 2012 16:06:41 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA806OCK019756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 01:06:25 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 01:06:25 +0100 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.198]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 7 Nov 2012 19:06:22 -0500 From: "Fedyk, Donald (Don)" To: David Allan I , "UTTARO, JAMES" , "'Rogers, Josh'" , Lucy yong , Giles Heron , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAAAwsEYAACa8bAAAAJzCAAADqjIAAADV/AAACkbwAAAoxEfAAEC/FoA== Date: Thu, 8 Nov 2012 00:06:21 +0000 Message-ID: <59E40B2663705C47B8C0A107CBFBA988044865@US70TWXCHMBA09.zam.alcatel-lucent.com> References: <2691CE0099834E4A9C5044EEC662BB9D4482D1D5@dfweml505-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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, 08 Nov 2012 00:06:45 -0000 Hi I know Giles as for SP input and I'm not an SP but reading this thread I'm = also not sure I that people are on the same page.=20 When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN wher= e the S-VLAN can multiplex C-VLANs and the B-LAN encapsulates and multiple= xes S-VLANs (or also allowed C-VLANs). =20 When we look at VPLS the MPLS Label can carry any one of the above as a sin= gle VLAN (unaware). This inherently includes the above multiplex. To allow = multiplexing at this layer we are saying we allow carrying multiple VLANs (= C-VLAN, S-VLAN, or B-VLAN) with a single label. =20 While a label multiplex makes some sense for C-VLANs. (This is analogous to= the S-VLAN model). I'm struggling with a label multiplex of VLAN multiple= xors or in other words beyond C-VLAN. (I don't think people are suggesting = we multiplex B-VLANs this way so I guess the questions is how far should we= take this and why is this needed given the service level already supports = multiplexers ? =20 Regards, Don =20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= avid Allan I Sent: Wednesday, November 07, 2012 4:40 PM To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org Subject: RE: Vlan-aware bundling over VPLS Given in 802.1 standards there is IVL (independent VLAN learning) and SVL (= shared VLAN learning), whether a MAC table exists per VID, per group of VID= s, or for all VIDs in a bundle in theory is an implementation/operational c= hoice. Or should be. SVL does permit MAC information gleaned from one VID's traffic to be used b= y another, which reduces the number of unknowns. OTOH if the VIDs identify = completely disjoint sets of endpoints there is no shared information of con= sequence. Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of U= TTARO, JAMES Sent: Wednesday, November 07, 2012 1:23 PM To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org Subject: RE: Vlan-aware bundling over VPLS +1..=20 Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: Wednesday, November 07, 2012 3:09 PM To: Lucy yong; Giles Heron; l2vpn@ietf.org Subject: Re: Vlan-aware bundling over VPLS [Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter. The critical question for this scenario is if each VLAN has its own MAC spa= ce or not? Under the currently available VPLS method, the MAC table is shared for the = entire VPLS instance. This method is no different than a native ethernet n= etwork using 802.1ad, I'm not concerned with 'isolating' the mac table betw= een vlans, but if I was I'd be inclined to use something available (ie, mul= tiple VPLS instances/multiple PW's, or PBB/PBT) -Josh On 11/7/12 2:02 PM, "Lucy yong" wrote: >Hi Josh, > >Thank you for the reply first. > >> -----Original Message----- >> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >> Sent: Wednesday, November 07, 2012 1:37 PM >> To: Lucy yong; Giles Heron; l2vpn@ietf.org >> Subject: Re: Vlan-aware bundling over VPLS >> >> Regarding the trans-AS service scenario? >[Lucy] I don't know, I post the question to know where it will be used. > What we had previously >> discussed/envisioned, and I've seen one other SP do, is buy a ELAN=20 >> type service from another operator (who delivered via VPLS). This=20 >> allowed them to put any VLAN they like on the ENNI, and deliver it to=20 >> any endpoint on the VPLS instance. Since they own the equipment=20 >> (CPE) at each end, they simply allowed the vlan(s) they wanted to=20 >> deliver to that end point. >> Since the VPLS instance is mac-learning, the only traffic that is=20 >> delivered that may be dropped by the CPE is BUM traffic. >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the=20 >filter. The critical question for this scenario is if each VLAN has its=20 >own MAC space or not? > >Lucy >> >> I'm not certain I understand the question well. Does that answer it? >> >> -Josh >> >> >> >> On 11/7/12 1:32 PM, "Lucy yong" wrote: >> >> >I would like to add one more question to SP beside Giles's >> > >> >3) Does this service aspect mean whenever customer want to add a new >> VLAN >> >(a BD) into the VPLS service, it has to inform the SP and SP has to=20 >> >provision this on PE? >> > >> >Thanks, >> >Lucy >> > >> >> -----Original Message----- >> >> From: Giles Heron [mailto:giles.heron@gmail.com] >> >> Sent: Wednesday, November 07, 2012 8:55 AM >> >> To: l2vpn@ietf.org >> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar >> >> Subject: Re: Vlan-aware bundling over VPLS >> >> >> >> I'll leave the draft authors to comment on the points raised by=20 >> >> Himanshu and Lucy >> >> >> >> But I would like SPs to comment as to: >> >> 1) whether VLAN-aware bundling is a requirement >> >> 2) whether they require VLAN-aware bundling both for VPLS and=20 >> >> E-VPN >> >> >> >> Giles (chair hat firmly on). >> >> >> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: >> >> >> >> > There is a trade-off on the solution. individual BD may have >> >> different QoS requirement, multiplxing them together in a single=20 >> >> PW >> may >> >> lose some QoS and OAM capability. For example, when congestion >> happens, >> >> some BD may work and some may not, PW status is not able to reflex >> that >> >> properly. >> >> > >> >> > Lucy >> >> > >> >> >> -----Original Message----- >> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> >> Behalf >> >> >> Of Shah, Himanshu >> >> >> Sent: Tuesday, November 06, 2012 2:04 PM >> >> >> To: l2vpn@ietf.org >> >> >> Subject: Vlan-aware bundling over VPLS >> >> >> >> >> >> clarification question: If vlan is the tag used for demux over >> >> single >> >> >> PW and if that vlan needs to be advertised then what is the >> saving? >> >> Is >> >> >> this just saving of the PW label? >> >> >> Himanshu >> >> >> >> >> >> Sent from my iPad >> > >> >> >> This E-mail and any of its attachments may contain Time Warner Cable=20 >> proprietary information, which is privileged, confidential, or=20 >> subject to copyright belonging to Time Warner Cable. This E-mail is=20 >> intended solely for the use of the individual or entity to which it is a= ddressed. >> If you are not the intended recipient of this E-mail, you are hereby=20 >> notified that any dissemination, distribution, copying, or action=20 >> taken in relation to the contents of and attachments to this E-mail=20 >> is strictly prohibited and may be unlawful. If you have received this=20 >> E- mail in error, please notify the sender immediately and=20 >> permanently delete the original and any copy of this E-mail and any prin= tout. 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 bedard.phil@gmail.com Wed Nov 7 19:04: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 C61C721F8A62 for ; Wed, 7 Nov 2012 19:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=-1.251, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 25eJ3YuK2mU1 for ; Wed, 7 Nov 2012 19:04:53 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF621F88C3 for ; Wed, 7 Nov 2012 19:04:53 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id g10so526748ghb.31 for ; Wed, 07 Nov 2012 19:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=tSMBcWlsmHeAZ2gfiluExOvoyT2QS+DegKYc3rwT4MA=; b=ALp7N6N/MBzMaBNj0k+oKrK7VgIdObT9H2qeud7gXM1hACdd+qM1tZtD8xOCTQX2iL /jgzKROrTIyLfu77qvv9ejl+FlLZ7uq90wE9B9/PCQHQJWGhaE1fgQjQpumMe0UDYeSt 0vQMeizdFIAev5oYvyWGwUhT6Bgpc8DGga37hA7+NIksx+joWCb2oK3MY04i/GHV0L0G xXPi4dBEeDMFfJuN6r56a+MstnmMDvTR1EZyjgJrFBG5bMAAB5D1xn8ZIWgq4Kkiibvo dYAyIKyhgd9BzioDvmpPlOCqDCHrqYvqLhn0UcSf0DbYc1lztukD1HZ3oLy0JrjfFFhY /lBg== Received: by 10.236.85.78 with SMTP id t54mr6958936yhe.48.1352343891556; Wed, 07 Nov 2012 19:04:51 -0800 (PST) Received: from [192.168.1.107] (71-90-205-142.dhcp.stls.mo.charter.com. [71.90.205.142]) by mx.google.com with ESMTPS id u49sm25754004yhd.18.2012.11.07.19.04.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 19:04:51 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 07 Nov 2012 22:04:46 -0500 Subject: Re: Vlan-aware bundling over VPLS From: Phil Bedard To: "Fedyk, Donald (Don)" , "l2vpn@ietf.org" Message-ID: Thread-Topic: Vlan-aware bundling over VPLS In-Reply-To: <59E40B2663705C47B8C0A107CBFBA988044865@US70TWXCHMBA09.zam.alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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, 08 Nov 2012 03:04:54 -0000 Part of the draft is the multiplexing, the other part is dynamically creating bridge domains for each bundled VLAN and pruning the unnecessary VLANs from remote PEs. I thought a bit more and here is a use case where this draft may have been useful. We have a cell backhaul service delivered over VPLS for a mobile provider. Each cell site (hundreds) are delivered to a single aggregation UNI, however there is a requirement for each cell site to belong to its own bridge domain. This required creating a separate service for each cell site so the configuration on the aggregation node is substantial since each service requires its own PW configuration (no A-D in use.) With the mechanisms in this draft it would have required only creating a single service network-wide. There may have been some OAM implications to this but I'd have to think that through. In some other instances it would not have worked because we use H-VPLS w/an MPLS U-PE. The upstream N-PE would need a mechanism to relay the U-PE VLANs to other N-PEs, and potentially aggregate those from multiple U-PEs belonging to the same service. The N-PE would also have to maintain separate bridge domains itself. There is nothing in the draft covering an H-VPLS scenario which is fairly common. We also create VLAN-unaware VPLS quite often since we do not want to be involved with adding/deleting customer VLANs and most customers do not have an explicit requirement for their VLANs to be in separate bridge domains across the VPLS. In reality most of them assume the VPLS works that way since most L2 switches do, but we haven't run into issues using a shared MAC table. Phil On 11/7/12 7:06 PM, "Fedyk, Donald (Don)" wrote: >Hi > >I know Giles as for SP input and I'm not an SP but reading this thread >I'm also not sure I that people are on the same page. > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN >where the S-VLAN can multiplex C-VLANs and the B-LAN encapsulates and >multiplexes S-VLANs (or also allowed C-VLANs). > >When we look at VPLS the MPLS Label can carry any one of the above as a >single VLAN (unaware). This inherently includes the above multiplex. To >allow multiplexing at this layer we are saying we allow carrying multiple >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label. > >While a label multiplex makes some sense for C-VLANs. (This is analogous >to the S-VLAN model). I'm struggling with a label multiplex of VLAN >multiplexors or in other words beyond C-VLAN. (I don't think people are >suggesting we multiplex B-VLANs this way so I guess the questions is how >far should we take this and why is this needed given the service level >already supports multiplexers ? > >Regards, >Don > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Wednesday, November 07, 2012 4:40 PM >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org >Subject: RE: Vlan-aware bundling over VPLS > >Given in 802.1 standards there is IVL (independent VLAN learning) and SVL >(shared VLAN learning), whether a MAC table exists per VID, per group of >VIDs, or for all VIDs in a bundle in theory is an >implementation/operational choice. Or should be. > >SVL does permit MAC information gleaned from one VID's traffic to be used >by another, which reduces the number of unknowns. OTOH if the VIDs >identify completely disjoint sets of endpoints there is no shared >information of consequence. > >Cheers >Dave > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >UTTARO, JAMES >Sent: Wednesday, November 07, 2012 1:23 PM >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org >Subject: RE: Vlan-aware bundling over VPLS > >+1.. > >Jim Uttaro > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Wednesday, November 07, 2012 3:09 PM >To: Lucy yong; Giles Heron; l2vpn@ietf.org >Subject: Re: Vlan-aware bundling over VPLS > >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter. >The critical question for this scenario is if each VLAN has its own MAC >space or not? > >Under the currently available VPLS method, the MAC table is shared for >the entire VPLS instance. This method is no different than a native >ethernet network using 802.1ad, I'm not concerned with 'isolating' the >mac table between vlans, but if I was I'd be inclined to use something >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) > > >-Josh > > >On 11/7/12 2:02 PM, "Lucy yong" wrote: > >>Hi Josh, >> >>Thank you for the reply first. >> >>> -----Original Message----- >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>> Sent: Wednesday, November 07, 2012 1:37 PM >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org >>> Subject: Re: Vlan-aware bundling over VPLS >>> >>> Regarding the trans-AS service scenario? >>[Lucy] I don't know, I post the question to know where it will be used. >> What we had previously >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN >>> type service from another operator (who delivered via VPLS). This >>> allowed them to put any VLAN they like on the ENNI, and deliver it to >>> any endpoint on the VPLS instance. Since they own the equipment >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to >>> deliver to that end point. >>> Since the VPLS instance is mac-learning, the only traffic that is >>> delivered that may be dropped by the CPE is BUM traffic. >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the >>filter. The critical question for this scenario is if each VLAN has its >>own MAC space or not? >> >>Lucy >>> >>> I'm not certain I understand the question well. Does that answer it? >>> >>> -Josh >>> >>> >>> >>> On 11/7/12 1:32 PM, "Lucy yong" wrote: >>> >>> >I would like to add one more question to SP beside Giles's >>> > >>> >3) Does this service aspect mean whenever customer want to add a new >>> VLAN >>> >(a BD) into the VPLS service, it has to inform the SP and SP has to >>> >provision this on PE? >>> > >>> >Thanks, >>> >Lucy >>> > >>> >> -----Original Message----- >>> >> From: Giles Heron [mailto:giles.heron@gmail.com] >>> >> Sent: Wednesday, November 07, 2012 8:55 AM >>> >> To: l2vpn@ietf.org >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar >>> >> Subject: Re: Vlan-aware bundling over VPLS >>> >> >>> >> I'll leave the draft authors to comment on the points raised by >>> >> Himanshu and Lucy >>> >> >>> >> But I would like SPs to comment as to: >>> >> 1) whether VLAN-aware bundling is a requirement >>> >> 2) whether they require VLAN-aware bundling both for VPLS and >>> >> E-VPN >>> >> >>> >> Giles (chair hat firmly on). >>> >> >>> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: >>> >> >>> >> > There is a trade-off on the solution. individual BD may have >>> >> different QoS requirement, multiplxing them together in a single >>> >> PW >>> may >>> >> lose some QoS and OAM capability. For example, when congestion >>> happens, >>> >> some BD may work and some may not, PW status is not able to reflex >>> that >>> >> properly. >>> >> > >>> >> > Lucy >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> >> Behalf >>> >> >> Of Shah, Himanshu >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM >>> >> >> To: l2vpn@ietf.org >>> >> >> Subject: Vlan-aware bundling over VPLS >>> >> >> >>> >> >> clarification question: If vlan is the tag used for demux over >>> >> single >>> >> >> PW and if that vlan needs to be advertised then what is the >>> saving? >>> >> Is >>> >> >> this just saving of the PW label? >>> >> >> Himanshu >>> >> >> >>> >> >> Sent from my iPad >>> > >>> >>> >>> 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 lizhong.jin@zte.com.cn Thu Nov 8 03:27:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9541D21F8654 for ; Thu, 8 Nov 2012 03:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.648 X-Spam-Level: X-Spam-Status: No, score=-100.648 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, HTML_MESSAGE=0.001, 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 7O4catRmjgWN for ; Thu, 8 Nov 2012 03:26:59 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id AD39121F867E for ; Thu, 8 Nov 2012 03:26:57 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id A8A6B1937AD4 for ; Thu, 8 Nov 2012 19:26:50 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id EF2F8712D7F; Thu, 8 Nov 2012 19:24:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qA8BQgBj090481; Thu, 8 Nov 2012 19:26:42 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: l2vpn@ietf.org, bedard.phil@gmail.com, donald.fedyk@alcatel-lucent.com Subject: Re: Vlan-aware bundling over VPLS MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 8 Nov 2012 19:25:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-08 19:26:39, Serialize complete at 2012-11-08 19:26:39 Content-Type: multipart/alternative; boundary="=_alternative 003EDFDC48257AB0_=" X-MAIL: mse02.zte.com.cn qA8BQgBj090481 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, 08 Nov 2012 11:27:00 -0000 This is a multipart message in MIME format. --=_alternative 003EDFDC48257AB0_= Content-Type: text/plain; charset="US-ASCII" It would be potentially useful for VLAN-aware bundling in datacenter (related with NVO3). If the virtualized L2 network could provide VLAN-aware bundling, the customer could manage its own VLAN domain, otherwise one virtual network could only provide one broadcast domain. And the VM moving would be easier in a VLAN-aware virtualized L2 network if the packet VLAN is added by VM. Lizhong > > ------------------------------ > > Message: 3 > Date: Wed, 07 Nov 2012 22:04:46 -0500 > From: Phil Bedard > To: "Fedyk, Donald (Don)" , > "l2vpn@ietf.org" > Subject: Re: Vlan-aware bundling over VPLS > Message-ID: > Content-Type: text/plain; charset="US-ASCII" > > Part of the draft is the multiplexing, the other part is dynamically > creating bridge domains for each bundled VLAN and pruning the unnecessary > VLANs from remote PEs. > > > I thought a bit more and here is a use case where this draft may have been > useful. We have a cell backhaul service delivered over VPLS for a mobile > provider. Each cell site (hundreds) are delivered to a single aggregation > UNI, however there is a requirement for each cell site to belong to its > own bridge domain. This required creating a separate service for each > cell site so the configuration on the aggregation node is substantial > since each service requires its own PW configuration (no A-D in use.) > With the mechanisms in this draft it would have required only creating a > single service network-wide. There may have been some OAM implications to > this but I'd have to think that through. > > In some other instances it would not have worked because we use H-VPLS > w/an MPLS U-PE. The upstream N-PE would need a mechanism to relay the > U-PE VLANs to other N-PEs, and potentially aggregate those from multiple > U-PEs belonging to the same service. The N-PE would also have to maintain > separate bridge domains itself. There is nothing in the draft covering an > H-VPLS scenario which is fairly common. > > We also create VLAN-unaware VPLS quite often since we do not want to be > involved with adding/deleting customer VLANs and most customers do not > have an explicit requirement for their VLANs to be in separate bridge > domains across the VPLS. In reality most of them assume the VPLS works > that way since most L2 switches do, but we haven't run into issues using a > shared MAC table. > > Phil > > > > On 11/7/12 7:06 PM, "Fedyk, Donald (Don)" > wrote: > > >Hi > > > >I know Giles as for SP input and I'm not an SP but reading this thread > >I'm also not sure I that people are on the same page. > > > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN > >where the S-VLAN can multiplex C-VLANs and the B-LAN encapsulates and > >multiplexes S-VLANs (or also allowed C-VLANs). > > > >When we look at VPLS the MPLS Label can carry any one of the above as a > >single VLAN (unaware). This inherently includes the above multiplex. To > >allow multiplexing at this layer we are saying we allow carrying multiple > >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label. > > > >While a label multiplex makes some sense for C-VLANs. (This is analogous > >to the S-VLAN model). I'm struggling with a label multiplex of VLAN > >multiplexors or in other words beyond C-VLAN. (I don't think people are > >suggesting we multiplex B-VLANs this way so I guess the questions is how > >far should we take this and why is this needed given the service level > >already supports multiplexers ? > > > >Regards, > >Don > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > >David Allan I > >Sent: Wednesday, November 07, 2012 4:40 PM > >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org > >Subject: RE: Vlan-aware bundling over VPLS > > > >Given in 802.1 standards there is IVL (independent VLAN learning) and SVL > >(shared VLAN learning), whether a MAC table exists per VID, per group of > >VIDs, or for all VIDs in a bundle in theory is an > >implementation/operational choice. Or should be. > > > >SVL does permit MAC information gleaned from one VID's traffic to be used > >by another, which reduces the number of unknowns. OTOH if the VIDs > >identify completely disjoint sets of endpoints there is no shared > >information of consequence. > > > >Cheers > >Dave > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > >UTTARO, JAMES > >Sent: Wednesday, November 07, 2012 1:23 PM > >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org > >Subject: RE: Vlan-aware bundling over VPLS > > > >+1.. > > > >Jim Uttaro > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > >Rogers, Josh > >Sent: Wednesday, November 07, 2012 3:09 PM > >To: Lucy yong; Giles Heron; l2vpn@ietf.org > >Subject: Re: Vlan-aware bundling over VPLS > > > >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter. > >The critical question for this scenario is if each VLAN has its own MAC > >space or not? > > > >Under the currently available VPLS method, the MAC table is shared for > >the entire VPLS instance. This method is no different than a native > >ethernet network using 802.1ad, I'm not concerned with 'isolating' the > >mac table between vlans, but if I was I'd be inclined to use something > >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) > > > > > >-Josh > > > > > >On 11/7/12 2:02 PM, "Lucy yong" wrote: > > > >>Hi Josh, > >> > >>Thank you for the reply first. > >> > >>> -----Original Message----- > >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >>> Sent: Wednesday, November 07, 2012 1:37 PM > >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org > >>> Subject: Re: Vlan-aware bundling over VPLS > >>> > >>> Regarding the trans-AS service scenario? > >>[Lucy] I don't know, I post the question to know where it will be used. > >> What we had previously > >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN > >>> type service from another operator (who delivered via VPLS). This > >>> allowed them to put any VLAN they like on the ENNI, and deliver it to > >>> any endpoint on the VPLS instance. Since they own the equipment > >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to > >>> deliver to that end point. > >>> Since the VPLS instance is mac-learning, the only traffic that is > >>> delivered that may be dropped by the CPE is BUM traffic. > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the > >>filter. The critical question for this scenario is if each VLAN has its > >>own MAC space or not? > >> > >>Lucy > >>> > >>> I'm not certain I understand the question well. Does that answer it? > >>> > >>> -Josh > >>> > >>> > >>> > >>> On 11/7/12 1:32 PM, "Lucy yong" wrote: > >>> > >>> >I would like to add one more question to SP beside Giles's > >>> > > >>> >3) Does this service aspect mean whenever customer want to add a new > >>> VLAN > >>> >(a BD) into the VPLS service, it has to inform the SP and SP has to > >>> >provision this on PE? > >>> > > >>> >Thanks, > >>> >Lucy > >>> > > >>> >> -----Original Message----- > >>> >> From: Giles Heron [mailto:giles.heron@gmail.com] > >>> >> Sent: Wednesday, November 07, 2012 8:55 AM > >>> >> To: l2vpn@ietf.org > >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > >>> >> Subject: Re: Vlan-aware bundling over VPLS > >>> >> > >>> >> I'll leave the draft authors to comment on the points raised by > >>> >> Himanshu and Lucy > >>> >> > >>> >> But I would like SPs to comment as to: > >>> >> 1) whether VLAN-aware bundling is a requirement > >>> >> 2) whether they require VLAN-aware bundling both for VPLS and > >>> >> E-VPN > >>> >> > >>> >> Giles (chair hat firmly on). > >>> >> > >>> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: > >>> >> > >>> >> > There is a trade-off on the solution. individual BD may have > >>> >> different QoS requirement, multiplxing them together in a single > >>> >> PW > >>> may > >>> >> lose some QoS and OAM capability. For example, when congestion > >>> happens, > >>> >> some BD may work and some may not, PW status is not able to reflex > >>> that > >>> >> properly. > >>> >> > > >>> >> > Lucy > >>> >> > > >>> >> >> -----Original Message----- > >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >>> >> Behalf > >>> >> >> Of Shah, Himanshu > >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM > >>> >> >> To: l2vpn@ietf.org > >>> >> >> Subject: Vlan-aware bundling over VPLS > >>> >> >> > >>> >> >> clarification question: If vlan is the tag used for demux over > >>> >> single > >>> >> >> PW and if that vlan needs to be advertised then what is the > >>> saving? > >>> >> Is > >>> >> >> this just saving of the PW label? > >>> >> >> Himanshu > >>> >> >> > >>> >> >> Sent from my iPad > >>> > > >>> > >>> --=_alternative 003EDFDC48257AB0_= Content-Type: text/html; charset="US-ASCII"
It would be potentially useful for VLAN-aware bundling in datacenter (related with NVO3). If the virtualized L2 network could provide VLAN-aware bundling, the customer could manage its own VLAN domain, otherwise one virtual network could only provide one broadcast domain. And the VM moving would be easier in a VLAN-aware virtualized L2 network if the packet VLAN is added by VM.

Lizhong


>
> ------------------------------
>
> Message: 3
> Date: Wed, 07 Nov 2012 22:04:46 -0500
> From: Phil Bedard <bedard.phil@gmail.com>
> To: "Fedyk, Donald (Don)" <donald.fedyk@alcatel-lucent.com>,
>    "l2vpn@ietf.org" <l2vpn@ietf.org>
> Subject: Re: Vlan-aware bundling over VPLS
> Message-ID: <CCC066E0.64B29%bedard.phil@gmail.com>
> Content-Type: text/plain;   charset="US-ASCII"
>
> Part of the draft is the multiplexing, the other part is dynamically
> creating bridge domains for each bundled VLAN and pruning the unnecessary
> VLANs from remote PEs.
>  
>
> I thought a bit more and here is a use case where this draft may have been
> useful.  We have a cell backhaul service delivered over VPLS for a mobile
> provider.  Each cell site (hundreds) are delivered to a single aggregation
> UNI, however there is a requirement for each cell site to belong to its
> own bridge domain.  This required creating a separate service for each
> cell site so the configuration on the aggregation node is substantial
> since each service requires its own PW configuration (no A-D in use.)
> With the mechanisms in this draft it would have required only creating a
> single service network-wide.  There may have been some OAM implications to
> this but I'd have to think that through.
>
> In some other instances it would not have worked because we use H-VPLS
> w/an MPLS U-PE.  The upstream N-PE would need a mechanism to relay the
> U-PE VLANs to other N-PEs, and potentially aggregate those from multiple
> U-PEs belonging to the same service. The N-PE would also have to maintain
> separate bridge domains itself. There is nothing in the draft covering an
> H-VPLS scenario which is fairly common.
>  
> We also create VLAN-unaware VPLS quite often since we do not want to be
> involved with adding/deleting customer VLANs and most customers do not
> have an explicit requirement for their VLANs to be in separate bridge
> domains across the VPLS.  In reality most of them assume the VPLS works
> that way since most L2 switches do, but we haven't run into issues using a
> shared MAC table.  
>
> Phil
>
>
>
> On 11/7/12 7:06 PM, "Fedyk, Donald (Don)"
> <donald.fedyk@alcatel-lucent.com> wrote:
>
> >Hi
> >
> >I know Giles as for SP input and I'm not an SP but reading this thread
> >I'm also not sure I that people are on the same page.
> >
> >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN
> >where the S-VLAN can multiplex C-VLANs  and the B-LAN encapsulates and
> >multiplexes S-VLANs (or also allowed C-VLANs).
> >
> >When we look at VPLS the MPLS Label can carry any one of the above as a
> >single VLAN (unaware). This inherently includes the above multiplex. To
> >allow multiplexing at this layer we are saying we allow carrying multiple
> >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label.
> >
> >While a label multiplex makes some sense for C-VLANs. (This is analogous
> >to the S-VLAN model).  I'm struggling with a label multiplex of VLAN
> >multiplexors or in other words beyond C-VLAN. (I don't think people are
> >suggesting we multiplex B-VLANs this way so I guess the questions is how
> >far should we take this and why is this needed given the service level
> >already supports multiplexers ?
> >
> >Regards,
> >Don  
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of
> >David Allan I
> >Sent: Wednesday, November 07, 2012 4:40 PM
> >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org
> >Subject: RE: Vlan-aware bundling over VPLS
> >
> >Given in 802.1 standards there is IVL (independent VLAN learning) and SVL
> >(shared VLAN learning), whether a MAC table exists per VID, per group of
> >VIDs, or for all VIDs in a bundle in theory is an
> >implementation/operational choice. Or should be.
> >
> >SVL does permit MAC information gleaned from one VID's traffic to be used
> >by another, which reduces the number of unknowns. OTOH if the VIDs
> >identify completely disjoint sets of endpoints there is no shared
> >information of consequence.
> >
> >Cheers
> >Dave
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of
> >UTTARO, JAMES
> >Sent: Wednesday, November 07, 2012 1:23 PM
> >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org
> >Subject: RE: Vlan-aware bundling over VPLS
> >
> >+1..
> >
> >Jim Uttaro
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of
> >Rogers, Josh
> >Sent: Wednesday, November 07, 2012 3:09 PM
> >To: Lucy yong; Giles Heron; l2vpn@ietf.org
> >Subject: Re: Vlan-aware bundling over VPLS
> >
> >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter.
> >The critical question for this scenario is if each VLAN has its own MAC
> >space or not?
> >
> >Under the currently available VPLS method, the MAC table is shared for
> >the entire VPLS instance.  This method is no different than a native
> >ethernet network using 802.1ad, I'm not concerned with 'isolating' the
> >mac table between vlans, but if I was I'd be inclined to use something
> >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT)
> >
> >
> >-Josh
> >
> >
> >On 11/7/12 2:02 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
> >
> >>Hi Josh,
> >>
> >>Thank you for the reply first.
> >>
> >>> -----Original Message-----
> >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com]
> >>> Sent: Wednesday, November 07, 2012 1:37 PM
> >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org
> >>> Subject: Re: Vlan-aware bundling over VPLS
> >>>
> >>> Regarding the trans-AS service scenario?
> >>[Lucy] I don't know, I post the question to know where it will be used.
> >> What we had previously
> >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN
> >>> type service from another operator (who delivered via VPLS).  This
> >>> allowed them to put any VLAN they like on the ENNI, and deliver it to
> >>> any endpoint on the VPLS instance.  Since they own the equipment
> >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to
> >>> deliver to that end point.
> >>> Since the VPLS instance is mac-learning, the only traffic that is
> >>> delivered that may be dropped by the CPE is BUM traffic.
> >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the
> >>filter. The critical question for this scenario is if each VLAN has its
> >>own MAC space or not?
> >>
> >>Lucy
> >>>
> >>> I'm not certain I understand the question well.  Does that answer it?
> >>>
> >>> -Josh
> >>>
> >>>
> >>>
> >>> On 11/7/12 1:32 PM, "Lucy yong" <lucy.yong@huawei.com> wrote:
> >>>
> >>> >I would like to add one more question to SP beside Giles's
> >>> >
> >>> >3) Does this service aspect mean whenever customer want to add a new
> >>> VLAN
> >>> >(a BD) into the VPLS service, it has to inform the SP and SP has to
> >>> >provision this on PE?
> >>> >
> >>> >Thanks,
> >>> >Lucy
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: Giles Heron [mailto:giles.heron@gmail.com]
> >>> >> Sent: Wednesday, November 07, 2012 8:55 AM
> >>> >> To: l2vpn@ietf.org
> >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar
> >>> >> Subject: Re: Vlan-aware bundling over VPLS
> >>> >>
> >>> >> I'll leave the draft authors to comment on the points raised by
> >>> >> Himanshu and Lucy
> >>> >>
> >>> >> But I would like SPs to comment as to:
> >>> >> 1) whether VLAN-aware bundling is a requirement
> >>> >> 2) whether they require VLAN-aware bundling both for VPLS and
> >>> >> E-VPN
> >>> >>
> >>> >> Giles (chair hat firmly on).
> >>> >>
> >>> >> On 7 Nov 2012, at 14:13, Lucy yong <lucy.yong@huawei.com> wrote:
> >>> >>
> >>> >> > There is a trade-off on the solution. individual BD may have
> >>> >> different QoS requirement, multiplxing them together in a single
> >>> >> PW
> >>> may
> >>> >> lose some QoS and OAM capability. For example, when congestion
> >>> happens,
> >>> >> some BD may work and some may not, PW status is not able to reflex
> >>> that
> >>> >> properly.
> >>> >> >
> >>> >> > Lucy
> >>> >> >
> >>> >> >> -----Original Message-----
> >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On
> >>> >> Behalf
> >>> >> >> Of Shah, Himanshu
> >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM
> >>> >> >> To: l2vpn@ietf.org
> >>> >> >> Subject: Vlan-aware bundling over VPLS
> >>> >> >>
> >>> >> >> clarification question:   If vlan is the tag used for demux over
> >>> >> single
> >>> >> >> PW and if that vlan needs to be advertised then what is the
> >>> saving?
> >>> >> Is
> >>> >> >> this just saving of the PW label?
> >>> >> >> Himanshu
> >>> >> >>
> >>> >> >> Sent from my iPad
> >>> >
> >>>
> >>> --=_alternative 003EDFDC48257AB0_=-- From donald.fedyk@alcatel-lucent.com Thu Nov 8 05:22: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 74E4E21F8BA8 for ; Thu, 8 Nov 2012 05:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 rmmJ6Vd8Besn for ; Thu, 8 Nov 2012 05:22:07 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACAC21F8BA9 for ; Thu, 8 Nov 2012 05:22:07 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA8DJ3Rj026487 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 14:22:02 +0100 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 14:21:41 +0100 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.198]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Thu, 8 Nov 2012 08:21:36 -0500 From: "Fedyk, Donald (Don)" To: Phil Bedard , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: Ac28Wd8CgSftmByxTkOJG8S2+4GckQAlziwAAAwsEYAACa8bAAAAJzCAAADqjIAAADV/AAACkbwAAAoxEfAAEC/FoP//jJcA//+tjcA= Date: Thu, 8 Nov 2012 13:21:35 +0000 Message-ID: <59E40B2663705C47B8C0A107CBFBA988044AC9@US70TWXCHMBA09.zam.alcatel-lucent.com> References: <59E40B2663705C47B8C0A107CBFBA988044865@US70TWXCHMBA09.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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, 08 Nov 2012 13:22:08 -0000 Hi Phil Inline Don> -----Original Message----- From: Phil Bedard [mailto:bedard.phil@gmail.com]=20 Sent: Wednesday, November 07, 2012 10:05 PM To: Fedyk, Donald (Don); l2vpn@ietf.org Subject: Re: Vlan-aware bundling over VPLS Part of the draft is the multiplexing, the other part is dynamically creating bridge domains for each bundled VLAN and pruning the unnecessary VLANs from remote PEs. =20 Don> Agree but you get that explicitly with a separate Label. The pruning i= s an extra function you must perform with VLAN aware. Sharing is controlled= in the pure Ethernet cases as well, S-VLAN multiplex is a shared FDB.=20 I thought a bit more and here is a use case where this draft may have been useful. We have a cell backhaul service delivered over VPLS for a mobile provider. Each cell site (hundreds) are delivered to a single aggregation UNI, however there is a requirement for each cell site to belong to its own bridge domain. This required creating a separate service for each cell site so the configuration on the aggregation node is substantial since each service requires its own PW configuration (no A-D in use.) With the mechanisms in this draft it would have required only creating a single service network-wide. There may have been some OAM implications to this but I'd have to think that through. Don> The tradeoff is Single service large FDB, many shared Access points, s= ingle label VLAN aware with VLAN pruning, versus=20 Multiple separate FDBs, separate access points, Multiple Labels VLAN unawar= e no pruning, But the Customer experience is shared both in QoS and Ethernet operations i= n the VLAN Aware case.=20 Flooding scope is increased per site and optionally pruned between sites. = =20 In some other instances it would not have worked because we use H-VPLS w/an MPLS U-PE. The upstream N-PE would need a mechanism to relay the U-PE VLANs to other N-PEs, and potentially aggregate those from multiple U-PEs belonging to the same service. The N-PE would also have to maintain separate bridge domains itself. There is nothing in the draft covering an H-VPLS scenario which is fairly common. Don> Good Point.=20 =20 We also create VLAN-unaware VPLS quite often since we do not want to be involved with adding/deleting customer VLANs and most customers do not have an explicit requirement for their VLANs to be in separate bridge domains across the VPLS. In reality most of them assume the VPLS works that way since most L2 switches do, but we haven't run into issues using a shared MAC table. =20 Don> Understood and you also get that with S-VLANs/B-VLANs.=20 Phil=20 On 11/7/12 7:06 PM, "Fedyk, Donald (Don)" wrote: >Hi > >I know Giles as for SP input and I'm not an SP but reading this thread >I'm also not sure I that people are on the same page. > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN >where the S-VLAN can multiplex C-VLANs and the B-LAN encapsulates and >multiplexes S-VLANs (or also allowed C-VLANs). > >When we look at VPLS the MPLS Label can carry any one of the above as a >single VLAN (unaware). This inherently includes the above multiplex. To >allow multiplexing at this layer we are saying we allow carrying multiple >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label. > >While a label multiplex makes some sense for C-VLANs. (This is analogous >to the S-VLAN model). I'm struggling with a label multiplex of VLAN >multiplexors or in other words beyond C-VLAN. (I don't think people are >suggesting we multiplex B-VLANs this way so I guess the questions is how >far should we take this and why is this needed given the service level >already supports multiplexers ? > >Regards, >Don =20 > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Wednesday, November 07, 2012 4:40 PM >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org >Subject: RE: Vlan-aware bundling over VPLS > >Given in 802.1 standards there is IVL (independent VLAN learning) and SVL >(shared VLAN learning), whether a MAC table exists per VID, per group of >VIDs, or for all VIDs in a bundle in theory is an >implementation/operational choice. Or should be. > >SVL does permit MAC information gleaned from one VID's traffic to be used >by another, which reduces the number of unknowns. OTOH if the VIDs >identify completely disjoint sets of endpoints there is no shared >information of consequence. > >Cheers >Dave > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >UTTARO, JAMES >Sent: Wednesday, November 07, 2012 1:23 PM >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org >Subject: RE: Vlan-aware bundling over VPLS > >+1..=20 > >Jim Uttaro > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Wednesday, November 07, 2012 3:09 PM >To: Lucy yong; Giles Heron; l2vpn@ietf.org >Subject: Re: Vlan-aware bundling over VPLS > >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filter. >The critical question for this scenario is if each VLAN has its own MAC >space or not? > >Under the currently available VPLS method, the MAC table is shared for >the entire VPLS instance. This method is no different than a native >ethernet network using 802.1ad, I'm not concerned with 'isolating' the >mac table between vlans, but if I was I'd be inclined to use something >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) > > >-Josh > > >On 11/7/12 2:02 PM, "Lucy yong" wrote: > >>Hi Josh, >> >>Thank you for the reply first. >> >>> -----Original Message----- >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com] >>> Sent: Wednesday, November 07, 2012 1:37 PM >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org >>> Subject: Re: Vlan-aware bundling over VPLS >>> >>> Regarding the trans-AS service scenario? >>[Lucy] I don't know, I post the question to know where it will be used. >> What we had previously >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN >>> type service from another operator (who delivered via VPLS). This >>> allowed them to put any VLAN they like on the ENNI, and deliver it to >>> any endpoint on the VPLS instance. Since they own the equipment >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to >>> deliver to that end point. >>> Since the VPLS instance is mac-learning, the only traffic that is >>> delivered that may be dropped by the CPE is BUM traffic. >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the >>filter. The critical question for this scenario is if each VLAN has its >>own MAC space or not? >> >>Lucy >>> >>> I'm not certain I understand the question well. Does that answer it? >>> >>> -Josh >>> >>> >>> >>> On 11/7/12 1:32 PM, "Lucy yong" wrote: >>> >>> >I would like to add one more question to SP beside Giles's >>> > >>> >3) Does this service aspect mean whenever customer want to add a new >>> VLAN >>> >(a BD) into the VPLS service, it has to inform the SP and SP has to >>> >provision this on PE? >>> > >>> >Thanks, >>> >Lucy >>> > >>> >> -----Original Message----- >>> >> From: Giles Heron [mailto:giles.heron@gmail.com] >>> >> Sent: Wednesday, November 07, 2012 8:55 AM >>> >> To: l2vpn@ietf.org >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar >>> >> Subject: Re: Vlan-aware bundling over VPLS >>> >> >>> >> I'll leave the draft authors to comment on the points raised by >>> >> Himanshu and Lucy >>> >> >>> >> But I would like SPs to comment as to: >>> >> 1) whether VLAN-aware bundling is a requirement >>> >> 2) whether they require VLAN-aware bundling both for VPLS and >>> >> E-VPN >>> >> >>> >> Giles (chair hat firmly on). >>> >> >>> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: >>> >> >>> >> > There is a trade-off on the solution. individual BD may have >>> >> different QoS requirement, multiplxing them together in a single >>> >> PW >>> may >>> >> lose some QoS and OAM capability. For example, when congestion >>> happens, >>> >> some BD may work and some may not, PW status is not able to reflex >>> that >>> >> properly. >>> >> > >>> >> > Lucy >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> >> Behalf >>> >> >> Of Shah, Himanshu >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM >>> >> >> To: l2vpn@ietf.org >>> >> >> Subject: Vlan-aware bundling over VPLS >>> >> >> >>> >> >> clarification question: If vlan is the tag used for demux over >>> >> single >>> >> >> PW and if that vlan needs to be advertised then what is the >>> saving? >>> >> Is >>> >> >> this just saving of the PW label? >>> >> >> Himanshu >>> >> >> >>> >> >> Sent from my iPad >>> > >>> >>> >>> 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 donald.fedyk@alcatel-lucent.com Thu Nov 8 07: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 8ED9021F8B7F for ; Thu, 8 Nov 2012 07:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, HELO_EQ_FR=0.35, 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 5-jsX5-EaYy1 for ; Thu, 8 Nov 2012 07:07:44 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7680C21F8B6C for ; Thu, 8 Nov 2012 07:07:43 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA8F3WPe032118 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 16:07:33 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 16:07:22 +0100 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.198]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 8 Nov 2012 10:07:20 -0500 From: "Fedyk, Donald (Don)" To: Lizhong Jin , "l2vpn@ietf.org" , "bedard.phil@gmail.com" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: AQHNvaPRgSftmByxTkOJG8S2+4GckZff/B0Q Date: Thu, 8 Nov 2012 15:07:19 +0000 Message-ID: <59E40B2663705C47B8C0A107CBFBA988044BBE@US70TWXCHMBA09.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_59E40B2663705C47B8C0A107CBFBA988044BBEUS70TWXCHMBA09zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 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, 08 Nov 2012 15:07:47 -0000 --_000_59E40B2663705C47B8C0A107CBFBA988044BBEUS70TWXCHMBA09zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong The way I see it: In the case of non VLAN aware you need to add a C-VLAN service to a new nod= e: * You create the service (local) * You add the access point (local) * You connect to the other service (PWs setup , Signaled, may be a= utomated) In the case of VLAN aware you need to add a C-VLAN service to a new node: * You add the access point to a shared service (Local) * The service advertizes the VLAN Vector to all other points (Signa= led, automatic) However if the Service you implement is an S-VLAN and you are adding a C-VL= AN on a VLAN unaware VPLS : * You add the access point to a shared service (Local) We don't need VLAN aware to get bundling. Don From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, November 08, 2012 6:26 AM To: l2vpn@ietf.org; bedard.phil@gmail.com; Fedyk, Donald (Don) Subject: Re: Vlan-aware bundling over VPLS It would be potentially useful for VLAN-aware bundling in datacenter (relat= ed with NVO3). If the virtualized L2 network could provide VLAN-aware bundl= ing, the customer could manage its own VLAN domain, otherwise one virtual n= etwork could only provide one broadcast domain. And the VM moving would be = easier in a VLAN-aware virtualized L2 network if the packet VLAN is added b= y VM. Lizhong > > ------------------------------ > > Message: 3 > Date: Wed, 07 Nov 2012 22:04:46 -0500 > From: Phil Bedard > To: "Fedyk, Donald (Don)" , > "l2vpn@ietf.org" > Subject: Re: Vlan-aware bundling over VPLS > Message-ID: > Content-Type: text/plain; charset=3D"US-ASCII" > > Part of the draft is the multiplexing, the other part is dynamically > creating bridge domains for each bundled VLAN and pruning the unnecessary > VLANs from remote PEs. > > > I thought a bit more and here is a use case where this draft may have bee= n > useful. We have a cell backhaul service delivered over VPLS for a mobile > provider. Each cell site (hundreds) are delivered to a single aggregatio= n > UNI, however there is a requirement for each cell site to belong to its > own bridge domain. This required creating a separate service for each > cell site so the configuration on the aggregation node is substantial > since each service requires its own PW configuration (no A-D in use.) > With the mechanisms in this draft it would have required only creating a > single service network-wide. There may have been some OAM implications t= o > this but I'd have to think that through. > > In some other instances it would not have worked because we use H-VPLS > w/an MPLS U-PE. The upstream N-PE would need a mechanism to relay the > U-PE VLANs to other N-PEs, and potentially aggregate those from multiple > U-PEs belonging to the same service. The N-PE would also have to maintain > separate bridge domains itself. There is nothing in the draft covering an > H-VPLS scenario which is fairly common. > > We also create VLAN-unaware VPLS quite often since we do not want to be > involved with adding/deleting customer VLANs and most customers do not > have an explicit requirement for their VLANs to be in separate bridge > domains across the VPLS. In reality most of them assume the VPLS works > that way since most L2 switches do, but we haven't run into issues using = a > shared MAC table. > > Phil > > > > On 11/7/12 7:06 PM, "Fedyk, Donald (Don)" > wrote: > > >Hi > > > >I know Giles as for SP input and I'm not an SP but reading this thread > >I'm also not sure I that people are on the same page. > > > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN > >where the S-VLAN can multiplex C-VLANs and the B-LAN encapsulates and > >multiplexes S-VLANs (or also allowed C-VLANs). > > > >When we look at VPLS the MPLS Label can carry any one of the above as a > >single VLAN (unaware). This inherently includes the above multiplex. To > >allow multiplexing at this layer we are saying we allow carrying multipl= e > >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label. > > > >While a label multiplex makes some sense for C-VLANs. (This is analogous > >to the S-VLAN model). I'm struggling with a label multiplex of VLAN > >multiplexors or in other words beyond C-VLAN. (I don't think people are > >suggesting we multiplex B-VLANs this way so I guess the questions is how > >far should we take this and why is this needed given the service level > >already supports multiplexers ? > > > >Regards, > >Don > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f > >David Allan I > >Sent: Wednesday, November 07, 2012 4:40 PM > >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.or= g > >Subject: RE: Vlan-aware bundling over VPLS > > > >Given in 802.1 standards there is IVL (independent VLAN learning) and SV= L > >(shared VLAN learning), whether a MAC table exists per VID, per group of > >VIDs, or for all VIDs in a bundle in theory is an > >implementation/operational choice. Or should be. > > > >SVL does permit MAC information gleaned from one VID's traffic to be use= d > >by another, which reduces the number of unknowns. OTOH if the VIDs > >identify completely disjoint sets of endpoints there is no shared > >information of consequence. > > > >Cheers > >Dave > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f > >UTTARO, JAMES > >Sent: Wednesday, November 07, 2012 1:23 PM > >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org > >Subject: RE: Vlan-aware bundling over VPLS > > > >+1.. > > > >Jim Uttaro > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f > >Rogers, Josh > >Sent: Wednesday, November 07, 2012 3:09 PM > >To: Lucy yong; Giles Heron; l2vpn@ietf.org > >Subject: Re: Vlan-aware bundling over VPLS > > > >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filte= r. > >The critical question for this scenario is if each VLAN has its own MAC > >space or not? > > > >Under the currently available VPLS method, the MAC table is shared for > >the entire VPLS instance. This method is no different than a native > >ethernet network using 802.1ad, I'm not concerned with 'isolating' the > >mac table between vlans, but if I was I'd be inclined to use something > >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) > > > > > >-Josh > > > > > >On 11/7/12 2:02 PM, "Lucy yong" wrote: > > > >>Hi Josh, > >> > >>Thank you for the reply first. > >> > >>> -----Original Message----- > >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >>> Sent: Wednesday, November 07, 2012 1:37 PM > >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org > >>> Subject: Re: Vlan-aware bundling over VPLS > >>> > >>> Regarding the trans-AS service scenario? > >>[Lucy] I don't know, I post the question to know where it will be used. > >> What we had previously > >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN > >>> type service from another operator (who delivered via VPLS). This > >>> allowed them to put any VLAN they like on the ENNI, and deliver it to > >>> any endpoint on the VPLS instance. Since they own the equipment > >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to > >>> deliver to that end point. > >>> Since the VPLS instance is mac-learning, the only traffic that is > >>> delivered that may be dropped by the CPE is BUM traffic. > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the > >>filter. The critical question for this scenario is if each VLAN has its > >>own MAC space or not? > >> > >>Lucy > >>> > >>> I'm not certain I understand the question well. Does that answer it? > >>> > >>> -Josh > >>> > >>> > >>> > >>> On 11/7/12 1:32 PM, "Lucy yong" wrote: > >>> > >>> >I would like to add one more question to SP beside Giles's > >>> > > >>> >3) Does this service aspect mean whenever customer want to add a new > >>> VLAN > >>> >(a BD) into the VPLS service, it has to inform the SP and SP has to > >>> >provision this on PE? > >>> > > >>> >Thanks, > >>> >Lucy > >>> > > >>> >> -----Original Message----- > >>> >> From: Giles Heron [mailto:giles.heron@gmail.com] > >>> >> Sent: Wednesday, November 07, 2012 8:55 AM > >>> >> To: l2vpn@ietf.org > >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > >>> >> Subject: Re: Vlan-aware bundling over VPLS > >>> >> > >>> >> I'll leave the draft authors to comment on the points raised by > >>> >> Himanshu and Lucy > >>> >> > >>> >> But I would like SPs to comment as to: > >>> >> 1) whether VLAN-aware bundling is a requirement > >>> >> 2) whether they require VLAN-aware bundling both for VPLS and > >>> >> E-VPN > >>> >> > >>> >> Giles (chair hat firmly on). > >>> >> > >>> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: > >>> >> > >>> >> > There is a trade-off on the solution. individual BD may have > >>> >> different QoS requirement, multiplxing them together in a single > >>> >> PW > >>> may > >>> >> lose some QoS and OAM capability. For example, when congestion > >>> happens, > >>> >> some BD may work and some may not, PW status is not able to reflex > >>> that > >>> >> properly. > >>> >> > > >>> >> > Lucy > >>> >> > > >>> >> >> -----Original Message----- > >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >>> >> Behalf > >>> >> >> Of Shah, Himanshu > >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM > >>> >> >> To: l2vpn@ietf.org > >>> >> >> Subject: Vlan-aware bundling over VPLS > >>> >> >> > >>> >> >> clarification question: If vlan is the tag used for demux ove= r > >>> >> single > >>> >> >> PW and if that vlan needs to be advertised then what is the > >>> saving? > >>> >> Is > >>> >> >> this just saving of the PW label? > >>> >> >> Himanshu > >>> >> >> > >>> >> >> Sent from my iPad > >>> > > >>> > >>> --_000_59E40B2663705C47B8C0A107CBFBA988044BBEUS70TWXCHMBA09zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lizhong

 <= /p>

The way I see it:

 <= /p>

In the case of non VLAN a= ware you need to add a C-VLAN service to a new node:

·      = ;   You create the se= rvice (local)

·      = ;   You add the acces= s point (local)

·      = ;   You connect to th= e other service (PWs setup , Signaled,  may be automated)

 <= /p>

In the case of VLAN aware= you need to add a C-VLAN service to a new node:

·      = ;   You add the acces= s point to a shared service (Local)

·      = ;   The service adver= tizes the VLAN Vector to all other points (Signaled, automatic)

 <= /p>

However if the Service yo= u implement is an S-VLAN and you are adding a C-VLAN on a VLAN unaware VPLS= :

·      = ;   You add the acces= s point to a shared service (Local)

 <= /span>

 <= /p>

We don’t need VLAN = aware to get bundling.

 <= /p>

Don

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Thursday, November 08, 2012 6:26 AM
To: l2vpn@ietf.org; bedard.phil@gmail.com; Fedyk, Donald (Don)
Subject: Re: Vlan-aware bundling over VPLS

 


It would be potentially useful for VLAN-aware bundling in datace= nter (related with NVO3). If the virtualized L2 network could provide VLAN-= aware bundling, the customer could manage its own VLAN domain, otherwise one virtual network could only provide one broadcast dom= ain. And the VM moving would be easier in a VLAN-aware virtualized L2 netwo= rk if the packet VLAN is added by VM.

Lizhong


>
> ------------------------------
>
> Message: 3
> Date: Wed, 07 Nov 2012 22:04:46 -0500
> From: Phil Bedard <bedard.phil@gmail.com>
> To: "Fedyk, Donald (Don)" <donald.fedyk@alcatel-lucent.co= m>,
>    "l2vpn@ietf.org" <l2vpn@ietf.org>
> Subject: Re: Vlan-aware bundling over VPLS
> Message-ID: <CCC066E0.64B29%bedard.phil@gmail.com>
> Content-Type: text/plain;   charset=3D"US-ASCII"
>
> Part of the draft is the multiplexing, the other part is dynamically > creating bridge domains for each bundled VLAN and pruning the unnecess= ary
> VLANs from remote PEs.
>  
>
> I thought a bit more and here is a use case where this draft may have = been
> useful.  We have a cell backhaul service delivered over VPLS for = a mobile
> provider.  Each cell site (hundreds) are delivered to a single ag= gregation
> UNI, however there is a requirement for each cell site to belong to it= s
> own bridge domain.  This required creating a separate service for= each
> cell site so the configuration on the aggregation node is substantial<= br> > since each service requires its own PW configuration (no A-D in use.)<= br> > With the mechanisms in this draft it would have required only creating= a
> single service network-wide.  There may have been some OAM implic= ations to
> this but I'd have to think that through.
>
> In some other instances it would not have worked because we use H-VPLS=
> w/an MPLS U-PE.  The upstream N-PE would need a mechanism to rela= y the
> U-PE VLANs to other N-PEs, and potentially aggregate those from multip= le
> U-PEs belonging to the same service. The N-PE would also have to maint= ain
> separate bridge domains itself. There is nothing in the draft covering= an
> H-VPLS scenario which is fairly common.
>  
> We also create VLAN-unaware VPLS quite often since we do not want to b= e
> involved with adding/deleting customer VLANs and most customers do not=
> have an explicit requirement for their VLANs to be in separate bridge<= br> > domains across the VPLS.  In reality most of them assume the VPLS= works
> that way since most L2 switches do, but we haven't run into issues usi= ng a
> shared MAC table.  
>
> Phil
>
>
>
> On 11/7/12 7:06 PM, "Fedyk, Donald (Don)"
> <donald.fedyk@alcatel-lucent.com> wrote:
>
> >Hi
> >
> >I know Giles as for SP input and I'm not an SP but reading this th= read
> >I'm also not sure I that people are on the same page.
> >
> >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-= VLAN
> >where the S-VLAN can multiplex C-VLANs  and the B-LAN encapsu= lates and
> >multiplexes S-VLANs (or also allowed C-VLANs).
> >
> >When we look at VPLS the MPLS Label can carry any one of the above= as a
> >single VLAN (unaware). This inherently includes the above multiple= x. To
> >allow multiplexing at this layer we are saying we allow carrying m= ultiple
> >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label.
> >
> >While a label multiplex makes some sense for C-VLANs. (This is ana= logous
> >to the S-VLAN model).  I'm struggling with a label multiplex = of VLAN
> >multiplexors or in other words beyond C-VLAN. (I don't think peopl= e are
> >suggesting we multiplex B-VLANs this way so I guess the questions = is how
> >far should we take this and why is this needed given the service l= evel
> >already supports multiplexers ?
> >
> >Regards,
> >Don  
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half Of
> >David Allan I
> >Sent: Wednesday, November 07, 2012 4:40 PM
> >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@i= etf.org
> >Subject: RE: Vlan-aware bundling over VPLS
> >
> >Given in 802.1 standards there is IVL (independent VLAN learning) = and SVL
> >(shared VLAN learning), whether a MAC table exists per VID, per gr= oup of
> >VIDs, or for all VIDs in a bundle in theory is an
> >implementation/operational choice. Or should be.
> >
> >SVL does permit MAC information gleaned from one VID's traffic to = be used
> >by another, which reduces the number of unknowns. OTOH if the VIDs=
> >identify completely disjoint sets of endpoints there is no shared<= br> > >information of consequence.
> >
> >Cheers
> >Dave
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half Of
> >UTTARO, JAMES
> >Sent: Wednesday, November 07, 2012 1:23 PM
> >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org
> >Subject: RE: Vlan-aware bundling over VPLS
> >
> >+1..
> >
> >Jim Uttaro
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half Of
> >Rogers, Josh
> >Sent: Wednesday, November 07, 2012 3:09 PM
> >To: Lucy yong; Giles Heron; l2vpn@ietf.org
> >Subject: Re: Vlan-aware bundling over VPLS
> >
> >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the= filter.
> >The critical question for this scenario is if each VLAN has its ow= n MAC
> >space or not?
> >
> >Under the currently available VPLS method, the MAC table is shared= for
> >the entire VPLS instance.  This method is no different than a= native
> >ethernet network using 802.1ad, I'm not concerned with 'isolating'= the
> >mac table between vlans, but if I was I'd be inclined to use somet= hing
> >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT)<= br> > >
> >
> >-Josh
> >
> >
> >On 11/7/12 2:02 PM, "Lucy yong" <lucy.yong@huawei.com= > wrote:
> >
> >>Hi Josh,
> >>
> >>Thank you for the reply first.
> >>
> >>> -----Original Message-----
> >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com]
> >>> Sent: Wednesday, November 07, 2012 1:37 PM
> >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org
> >>> Subject: Re: Vlan-aware bundling over VPLS
> >>>
> >>> Regarding the trans-AS service scenario?
> >>[Lucy] I don't know, I post the question to know where it will= be used.
> >> What we had previously
> >>> discussed/envisioned, and I've seen one other SP do, is b= uy a ELAN
> >>> type service from another operator (who delivered via VPL= S).  This
> >>> allowed them to put any VLAN they like on the ENNI, and d= eliver it to
> >>> any endpoint on the VPLS instance.  Since they own t= he equipment
> >>> (CPE) at each end, they simply allowed the vlan(s) they w= anted to
> >>> deliver to that end point.
> >>> Since the VPLS instance is mac-learning, the only traffic= that is
> >>> delivered that may be dropped by the CPE is BUM traffic.<= br> > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs= the
> >>filter. The critical question for this scenario is if each VLA= N has its
> >>own MAC space or not?
> >>
> >>Lucy
> >>>
> >>> I'm not certain I understand the question well.  Doe= s that answer it?
> >>>
> >>> -Josh
> >>>
> >>>
> >>>
> >>> On 11/7/12 1:32 PM, "Lucy yong" <lucy.yong@h= uawei.com> wrote:
> >>>
> >>> >I would like to add one more question to SP beside Gi= les's
> >>> >
> >>> >3) Does this service aspect mean whenever customer wa= nt to add a new
> >>> VLAN
> >>> >(a BD) into the VPLS service, it has to inform the SP= and SP has to
> >>> >provision this on PE?
> >>> >
> >>> >Thanks,
> >>> >Lucy
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: Giles Heron [mailto:giles.heron@gmail.com]=
> >>> >> Sent: Wednesday, November 07, 2012 8:55 AM
> >>> >> To: l2vpn@ietf.org
> >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar
> >>> >> Subject: Re: Vlan-aware bundling over VPLS
> >>> >>
> >>> >> I'll leave the draft authors to comment on the p= oints raised by
> >>> >> Himanshu and Lucy
> >>> >>
> >>> >> But I would like SPs to comment as to:
> >>> >> 1) whether VLAN-aware bundling is a requirement<= br> > >>> >> 2) whether they require VLAN-aware bundling both= for VPLS and
> >>> >> E-VPN
> >>> >>
> >>> >> Giles (chair hat firmly on).
> >>> >>
> >>> >> On 7 Nov 2012, at 14:13, Lucy yong <lucy.yong= @huawei.com> wrote:
> >>> >>
> >>> >> > There is a trade-off on the solution. indiv= idual BD may have
> >>> >> different QoS requirement, multiplxing them toge= ther in a single
> >>> >> PW
> >>> may
> >>> >> lose some QoS and OAM capability. For example, w= hen congestion
> >>> happens,
> >>> >> some BD may work and some may not, PW status is = not able to reflex
> >>> that
> >>> >> properly.
> >>> >> >
> >>> >> > Lucy
> >>> >> >
> >>> >> >> -----Original Message-----
> >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2= vpn-bounces@ietf.org] On
> >>> >> Behalf
> >>> >> >> Of Shah, Himanshu
> >>> >> >> Sent: Tuesday, November 06, 2012 2:04 P= M
> >>> >> >> To: l2vpn@ietf.org
> >>> >> >> Subject: Vlan-aware bundling over VPLS<= br> > >>> >> >>
> >>> >> >> clarification question:   If vlan = is the tag used for demux over
> >>> >> single
> >>> >> >> PW and if that vlan needs to be adverti= sed then what is the
> >>> saving?
> >>> >> Is
> >>> >> >> this just saving of the PW label?
> >>> >> >> Himanshu
> >>> >> >>
> >>> >> >> Sent from my iPad
> >>> >
> >>>
> >>>

--_000_59E40B2663705C47B8C0A107CBFBA988044BBEUS70TWXCHMBA09zam_-- From lucy.yong@huawei.com Thu Nov 8 11:07: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 7530F21F88B4 for ; Thu, 8 Nov 2012 11:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[AWL=-1.734, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 3Xys1uHYEU1P for ; Thu, 8 Nov 2012 11:07:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D477921F8825 for ; Thu, 8 Nov 2012 11:07:07 -0800 (PST) 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 ALI84277; Thu, 08 Nov 2012 19:07:06 +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; Thu, 8 Nov 2012 19:06:53 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 19:07:04 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 11:06:58 -0800 From: Lucy yong To: "Fedyk, Donald (Don)" , Lizhong Jin , "l2vpn@ietf.org" , "bedard.phil@gmail.com" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: AQHNvaPRgSftmByxTkOJG8S2+4GckZff/B0QgABPNzA= Date: Thu, 8 Nov 2012 19:06:58 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482D69D@dfweml505-mbx> References: <59E40B2663705C47B8C0A107CBFBA988044BBE@US70TWXCHMBA09.zam.alcatel-lucent.com> In-Reply-To: <59E40B2663705C47B8C0A107CBFBA988044BBE@US70TWXCHMBA09.zam.alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.93.92] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4482D69Ddfweml505mbx_" 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: Thu, 08 Nov 2012 19:07:12 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4482D69Ddfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I concur what Doc states. All-to-one bundling supports multiple bcast domains. The issue is if ther= e is a need for each BD to have own MAC space. I don't see this is necessar= y for a tenant. Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of F= edyk, Donald (Don) Sent: Thursday, November 08, 2012 9:07 AM To: Lizhong Jin; l2vpn@ietf.org; bedard.phil@gmail.com Subject: RE: Vlan-aware bundling over VPLS Hi Lizhong The way I see it: In the case of non VLAN aware you need to add a C-VLAN service to a new nod= e: * You create the service (local) * You add the access point (local) * You connect to the other service (PWs setup , Signaled, may be a= utomated) In the case of VLAN aware you need to add a C-VLAN service to a new node: * You add the access point to a shared service (Local) * The service advertizes the VLAN Vector to all other points (Signa= led, automatic) However if the Service you implement is an S-VLAN and you are adding a C-VL= AN on a VLAN unaware VPLS : * You add the access point to a shared service (Local) We don't need VLAN aware to get bundling. Don From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, November 08, 2012 6:26 AM To: l2vpn@ietf.org; bedard.phil@gmail.com; Fedyk, Donald (Don) Subject: Re: Vlan-aware bundling over VPLS It would be potentially useful for VLAN-aware bundling in datacenter (relat= ed with NVO3). If the virtualized L2 network could provide VLAN-aware bundl= ing, the customer could manage its own VLAN domain, otherwise one virtual n= etwork could only provide one broadcast domain. And the VM moving would be = easier in a VLAN-aware virtualized L2 network if the packet VLAN is added b= y VM. Lizhong > > ------------------------------ > > Message: 3 > Date: Wed, 07 Nov 2012 22:04:46 -0500 > From: Phil Bedard > To: "Fedyk, Donald (Don)" , > "l2vpn@ietf.org" > Subject: Re: Vlan-aware bundling over VPLS > Message-ID: > Content-Type: text/plain; charset=3D"US-ASCII" > > Part of the draft is the multiplexing, the other part is dynamically > creating bridge domains for each bundled VLAN and pruning the unnecessary > VLANs from remote PEs. > > > I thought a bit more and here is a use case where this draft may have bee= n > useful. We have a cell backhaul service delivered over VPLS for a mobile > provider. Each cell site (hundreds) are delivered to a single aggregatio= n > UNI, however there is a requirement for each cell site to belong to its > own bridge domain. This required creating a separate service for each > cell site so the configuration on the aggregation node is substantial > since each service requires its own PW configuration (no A-D in use.) > With the mechanisms in this draft it would have required only creating a > single service network-wide. There may have been some OAM implications t= o > this but I'd have to think that through. > > In some other instances it would not have worked because we use H-VPLS > w/an MPLS U-PE. The upstream N-PE would need a mechanism to relay the > U-PE VLANs to other N-PEs, and potentially aggregate those from multiple > U-PEs belonging to the same service. The N-PE would also have to maintain > separate bridge domains itself. There is nothing in the draft covering an > H-VPLS scenario which is fairly common. > > We also create VLAN-unaware VPLS quite often since we do not want to be > involved with adding/deleting customer VLANs and most customers do not > have an explicit requirement for their VLANs to be in separate bridge > domains across the VPLS. In reality most of them assume the VPLS works > that way since most L2 switches do, but we haven't run into issues using = a > shared MAC table. > > Phil > > > > On 11/7/12 7:06 PM, "Fedyk, Donald (Don)" > wrote: > > >Hi > > > >I know Giles as for SP input and I'm not an SP but reading this thread > >I'm also not sure I that people are on the same page. > > > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN > >where the S-VLAN can multiplex C-VLANs and the B-LAN encapsulates and > >multiplexes S-VLANs (or also allowed C-VLANs). > > > >When we look at VPLS the MPLS Label can carry any one of the above as a > >single VLAN (unaware). This inherently includes the above multiplex. To > >allow multiplexing at this layer we are saying we allow carrying multipl= e > >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label. > > > >While a label multiplex makes some sense for C-VLANs. (This is analogous > >to the S-VLAN model). I'm struggling with a label multiplex of VLAN > >multiplexors or in other words beyond C-VLAN. (I don't think people are > >suggesting we multiplex B-VLANs this way so I guess the questions is how > >far should we take this and why is this needed given the service level > >already supports multiplexers ? > > > >Regards, > >Don > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f > >David Allan I > >Sent: Wednesday, November 07, 2012 4:40 PM > >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.or= g > >Subject: RE: Vlan-aware bundling over VPLS > > > >Given in 802.1 standards there is IVL (independent VLAN learning) and SV= L > >(shared VLAN learning), whether a MAC table exists per VID, per group of > >VIDs, or for all VIDs in a bundle in theory is an > >implementation/operational choice. Or should be. > > > >SVL does permit MAC information gleaned from one VID's traffic to be use= d > >by another, which reduces the number of unknowns. OTOH if the VIDs > >identify completely disjoint sets of endpoints there is no shared > >information of consequence. > > > >Cheers > >Dave > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f > >UTTARO, JAMES > >Sent: Wednesday, November 07, 2012 1:23 PM > >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org > >Subject: RE: Vlan-aware bundling over VPLS > > > >+1.. > > > >Jim Uttaro > > > >-----Original Message----- > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f > >Rogers, Josh > >Sent: Wednesday, November 07, 2012 3:09 PM > >To: Lucy yong; Giles Heron; l2vpn@ietf.org > >Subject: Re: Vlan-aware bundling over VPLS > > > >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the filte= r. > >The critical question for this scenario is if each VLAN has its own MAC > >space or not? > > > >Under the currently available VPLS method, the MAC table is shared for > >the entire VPLS instance. This method is no different than a native > >ethernet network using 802.1ad, I'm not concerned with 'isolating' the > >mac table between vlans, but if I was I'd be inclined to use something > >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) > > > > > >-Josh > > > > > >On 11/7/12 2:02 PM, "Lucy yong" wrote: > > > >>Hi Josh, > >> > >>Thank you for the reply first. > >> > >>> -----Original Message----- > >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com] > >>> Sent: Wednesday, November 07, 2012 1:37 PM > >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org > >>> Subject: Re: Vlan-aware bundling over VPLS > >>> > >>> Regarding the trans-AS service scenario? > >>[Lucy] I don't know, I post the question to know where it will be used. > >> What we had previously > >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN > >>> type service from another operator (who delivered via VPLS). This > >>> allowed them to put any VLAN they like on the ENNI, and deliver it to > >>> any endpoint on the VPLS instance. Since they own the equipment > >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to > >>> deliver to that end point. > >>> Since the VPLS instance is mac-learning, the only traffic that is > >>> delivered that may be dropped by the CPE is BUM traffic. > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the > >>filter. The critical question for this scenario is if each VLAN has its > >>own MAC space or not? > >> > >>Lucy > >>> > >>> I'm not certain I understand the question well. Does that answer it? > >>> > >>> -Josh > >>> > >>> > >>> > >>> On 11/7/12 1:32 PM, "Lucy yong" wrote: > >>> > >>> >I would like to add one more question to SP beside Giles's > >>> > > >>> >3) Does this service aspect mean whenever customer want to add a new > >>> VLAN > >>> >(a BD) into the VPLS service, it has to inform the SP and SP has to > >>> >provision this on PE? > >>> > > >>> >Thanks, > >>> >Lucy > >>> > > >>> >> -----Original Message----- > >>> >> From: Giles Heron [mailto:giles.heron@gmail.com] > >>> >> Sent: Wednesday, November 07, 2012 8:55 AM > >>> >> To: l2vpn@ietf.org > >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > >>> >> Subject: Re: Vlan-aware bundling over VPLS > >>> >> > >>> >> I'll leave the draft authors to comment on the points raised by > >>> >> Himanshu and Lucy > >>> >> > >>> >> But I would like SPs to comment as to: > >>> >> 1) whether VLAN-aware bundling is a requirement > >>> >> 2) whether they require VLAN-aware bundling both for VPLS and > >>> >> E-VPN > >>> >> > >>> >> Giles (chair hat firmly on). > >>> >> > >>> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: > >>> >> > >>> >> > There is a trade-off on the solution. individual BD may have > >>> >> different QoS requirement, multiplxing them together in a single > >>> >> PW > >>> may > >>> >> lose some QoS and OAM capability. For example, when congestion > >>> happens, > >>> >> some BD may work and some may not, PW status is not able to reflex > >>> that > >>> >> properly. > >>> >> > > >>> >> > Lucy > >>> >> > > >>> >> >> -----Original Message----- > >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >>> >> Behalf > >>> >> >> Of Shah, Himanshu > >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM > >>> >> >> To: l2vpn@ietf.org > >>> >> >> Subject: Vlan-aware bundling over VPLS > >>> >> >> > >>> >> >> clarification question: If vlan is the tag used for demux ove= r > >>> >> single > >>> >> >> PW and if that vlan needs to be advertised then what is the > >>> saving? > >>> >> Is > >>> >> >> this just saving of the PW label? > >>> >> >> Himanshu > >>> >> >> > >>> >> >> Sent from my iPad > >>> > > >>> > >>> --_000_2691CE0099834E4A9C5044EEC662BB9D4482D69Ddfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I concur what Doc states.=

 <= /p>

All-to-one  bundling=  supports multiple bcast domains. The issue is if there is a need for= each BD to have own MAC space. I don’t see this is necessary for a tenant.

 <= /p>

Lucy

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Fedyk, Donald (Don)
Sent: Thursday, November 08, 2012 9:07 AM
To: Lizhong Jin; l2vpn@ietf.org; bedard.phil@gmail.com
Subject: RE: Vlan-aware bundling over VPLS

 

Hi Lizhong

 <= /p>

The way I see it:

 <= /p>

In the case of non VLAN a= ware you need to add a C-VLAN service to a new node:

·      = ;   You create the se= rvice (local)

·      = ;   You add the acces= s point (local)

·      = ;   You connect to th= e other service (PWs setup , Signaled,  may be automated)

 <= /p>

In the case of VLAN aware= you need to add a C-VLAN service to a new node:

·      = ;   You add the acces= s point to a shared service (Local)

·      = ;   The service adver= tizes the VLAN Vector to all other points (Signaled, automatic)

 <= /p>

However if the Service yo= u implement is an S-VLAN and you are adding a C-VLAN on a VLAN unaware VPLS= :

·      = ;   You add the acces= s point to a shared service (Local)

 <= /span>

 <= /p>

We don’t need VLAN = aware to get bundling.

 <= /p>

Don

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Thursday, November 08, 2012 6:26 AM
To: l2vpn@ietf.org; bedard.phil@gmail.com; Fedyk, Donald (Don)
Subject: Re: Vlan-aware bundling over VPLS

 


It would be potentially useful for VLAN-aware bundling in datace= nter (related with NVO3). If the virtualized L2 network could provide VLAN-= aware bundling, the customer could manage its own VLAN domain, otherwise one virtual network could only provide one broadcast dom= ain. And the VM moving would be easier in a VLAN-aware virtualized L2 netwo= rk if the packet VLAN is added by VM.

Lizhong


>
> ------------------------------
>
> Message: 3
> Date: Wed, 07 Nov 2012 22:04:46 -0500
> From: Phil Bedard <bedard.phil@gmail.com>
> To: "Fedyk, Donald (Don)" <donald.fedyk@alcatel-lucent.co= m>,
>    "l2vpn@ietf.org" <l2vpn@ietf.org>
> Subject: Re: Vlan-aware bundling over VPLS
> Message-ID: <CCC066E0.64B29%bedard.phil@gmail.com>
> Content-Type: text/plain;   charset=3D"US-ASCII"
>
> Part of the draft is the multiplexing, the other part is dynamically > creating bridge domains for each bundled VLAN and pruning the unnecess= ary
> VLANs from remote PEs.
>  
>
> I thought a bit more and here is a use case where this draft may have = been
> useful.  We have a cell backhaul service delivered over VPLS for = a mobile
> provider.  Each cell site (hundreds) are delivered to a single ag= gregation
> UNI, however there is a requirement for each cell site to belong to it= s
> own bridge domain.  This required creating a separate service for= each
> cell site so the configuration on the aggregation node is substantial<= br> > since each service requires its own PW configuration (no A-D in use.)<= br> > With the mechanisms in this draft it would have required only creating= a
> single service network-wide.  There may have been some OAM implic= ations to
> this but I'd have to think that through.
>
> In some other instances it would not have worked because we use H-VPLS=
> w/an MPLS U-PE.  The upstream N-PE would need a mechanism to rela= y the
> U-PE VLANs to other N-PEs, and potentially aggregate those from multip= le
> U-PEs belonging to the same service. The N-PE would also have to maint= ain
> separate bridge domains itself. There is nothing in the draft covering= an
> H-VPLS scenario which is fairly common.
>  
> We also create VLAN-unaware VPLS quite often since we do not want to b= e
> involved with adding/deleting customer VLANs and most customers do not=
> have an explicit requirement for their VLANs to be in separate bridge<= br> > domains across the VPLS.  In reality most of them assume the VPLS= works
> that way since most L2 switches do, but we haven't run into issues usi= ng a
> shared MAC table.  
>
> Phil
>
>
>
> On 11/7/12 7:06 PM, "Fedyk, Donald (Don)"
> <donald.fedyk@alcatel-lucent.com> wrote:
>
> >Hi
> >
> >I know Giles as for SP input and I'm not an SP but reading this th= read
> >I'm also not sure I that people are on the same page.
> >
> >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-= VLAN
> >where the S-VLAN can multiplex C-VLANs  and the B-LAN encapsu= lates and
> >multiplexes S-VLANs (or also allowed C-VLANs).
> >
> >When we look at VPLS the MPLS Label can carry any one of the above= as a
> >single VLAN (unaware). This inherently includes the above multiple= x. To
> >allow multiplexing at this layer we are saying we allow carrying m= ultiple
> >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label.
> >
> >While a label multiplex makes some sense for C-VLANs. (This is ana= logous
> >to the S-VLAN model).  I'm struggling with a label multiplex = of VLAN
> >multiplexors or in other words beyond C-VLAN. (I don't think peopl= e are
> >suggesting we multiplex B-VLANs this way so I guess the questions = is how
> >far should we take this and why is this needed given the service l= evel
> >already supports multiplexers ?
> >
> >Regards,
> >Don  
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half Of
> >David Allan I
> >Sent: Wednesday, November 07, 2012 4:40 PM
> >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@i= etf.org
> >Subject: RE: Vlan-aware bundling over VPLS
> >
> >Given in 802.1 standards there is IVL (independent VLAN learning) = and SVL
> >(shared VLAN learning), whether a MAC table exists per VID, per gr= oup of
> >VIDs, or for all VIDs in a bundle in theory is an
> >implementation/operational choice. Or should be.
> >
> >SVL does permit MAC information gleaned from one VID's traffic to = be used
> >by another, which reduces the number of unknowns. OTOH if the VIDs=
> >identify completely disjoint sets of endpoints there is no shared<= br> > >information of consequence.
> >
> >Cheers
> >Dave
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half Of
> >UTTARO, JAMES
> >Sent: Wednesday, November 07, 2012 1:23 PM
> >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org
> >Subject: RE: Vlan-aware bundling over VPLS
> >
> >+1..
> >
> >Jim Uttaro
> >
> >-----Original Message-----
> >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half Of
> >Rogers, Josh
> >Sent: Wednesday, November 07, 2012 3:09 PM
> >To: Lucy yong; Giles Heron; l2vpn@ietf.org
> >Subject: Re: Vlan-aware bundling over VPLS
> >
> >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the= filter.
> >The critical question for this scenario is if each VLAN has its ow= n MAC
> >space or not?
> >
> >Under the currently available VPLS method, the MAC table is shared= for
> >the entire VPLS instance.  This method is no different than a= native
> >ethernet network using 802.1ad, I'm not concerned with 'isolating'= the
> >mac table between vlans, but if I was I'd be inclined to use somet= hing
> >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT)<= br> > >
> >
> >-Josh
> >
> >
> >On 11/7/12 2:02 PM, "Lucy yong" <lucy.yong@huawei.com= > wrote:
> >
> >>Hi Josh,
> >>
> >>Thank you for the reply first.
> >>
> >>> -----Original Message-----
> >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com]
> >>> Sent: Wednesday, November 07, 2012 1:37 PM
> >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org
> >>> Subject: Re: Vlan-aware bundling over VPLS
> >>>
> >>> Regarding the trans-AS service scenario?
> >>[Lucy] I don't know, I post the question to know where it will= be used.
> >> What we had previously
> >>> discussed/envisioned, and I've seen one other SP do, is b= uy a ELAN
> >>> type service from another operator (who delivered via VPL= S).  This
> >>> allowed them to put any VLAN they like on the ENNI, and d= eliver it to
> >>> any endpoint on the VPLS instance.  Since they own t= he equipment
> >>> (CPE) at each end, they simply allowed the vlan(s) they w= anted to
> >>> deliver to that end point.
> >>> Since the VPLS instance is mac-learning, the only traffic= that is
> >>> delivered that may be dropped by the CPE is BUM traffic.<= br> > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs= the
> >>filter. The critical question for this scenario is if each VLA= N has its
> >>own MAC space or not?
> >>
> >>Lucy
> >>>
> >>> I'm not certain I understand the question well.  Doe= s that answer it?
> >>>
> >>> -Josh
> >>>
> >>>
> >>>
> >>> On 11/7/12 1:32 PM, "Lucy yong" <lucy.yong@h= uawei.com> wrote:
> >>>
> >>> >I would like to add one more question to SP beside Gi= les's
> >>> >
> >>> >3) Does this service aspect mean whenever customer wa= nt to add a new
> >>> VLAN
> >>> >(a BD) into the VPLS service, it has to inform the SP= and SP has to
> >>> >provision this on PE?
> >>> >
> >>> >Thanks,
> >>> >Lucy
> >>> >
> >>> >> -----Original Message-----
> >>> >> From: Giles Heron [mailto:giles.heron@gmail.com]=
> >>> >> Sent: Wednesday, November 07, 2012 8:55 AM
> >>> >> To: l2vpn@ietf.org
> >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar
> >>> >> Subject: Re: Vlan-aware bundling over VPLS
> >>> >>
> >>> >> I'll leave the draft authors to comment on the p= oints raised by
> >>> >> Himanshu and Lucy
> >>> >>
> >>> >> But I would like SPs to comment as to:
> >>> >> 1) whether VLAN-aware bundling is a requirement<= br> > >>> >> 2) whether they require VLAN-aware bundling both= for VPLS and
> >>> >> E-VPN
> >>> >>
> >>> >> Giles (chair hat firmly on).
> >>> >>
> >>> >> On 7 Nov 2012, at 14:13, Lucy yong <lucy.yong= @huawei.com> wrote:
> >>> >>
> >>> >> > There is a trade-off on the solution. indiv= idual BD may have
> >>> >> different QoS requirement, multiplxing them toge= ther in a single
> >>> >> PW
> >>> may
> >>> >> lose some QoS and OAM capability. For example, w= hen congestion
> >>> happens,
> >>> >> some BD may work and some may not, PW status is = not able to reflex
> >>> that
> >>> >> properly.
> >>> >> >
> >>> >> > Lucy
> >>> >> >
> >>> >> >> -----Original Message-----
> >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2= vpn-bounces@ietf.org] On
> >>> >> Behalf
> >>> >> >> Of Shah, Himanshu
> >>> >> >> Sent: Tuesday, November 06, 2012 2:04 P= M
> >>> >> >> To: l2vpn@ietf.org
> >>> >> >> Subject: Vlan-aware bundling over VPLS<= br> > >>> >> >>
> >>> >> >> clarification question:   If vlan = is the tag used for demux over
> >>> >> single
> >>> >> >> PW and if that vlan needs to be adverti= sed then what is the
> >>> saving?
> >>> >> Is
> >>> >> >> this just saving of the PW label?
> >>> >> >> Himanshu
> >>> >> >>
> >>> >> >> Sent from my iPad
> >>> >
> >>>
> >>>

--_000_2691CE0099834E4A9C5044EEC662BB9D4482D69Ddfweml505mbx_-- From lizhong.jin@zte.com.cn Fri Nov 9 01:27: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 C4CDA21F85FA for ; Fri, 9 Nov 2012 01:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.772 X-Spam-Level: X-Spam-Status: No, score=-99.772 tagged_above=-999 required=5 tests=[AWL=-2.826, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 UvVStcv9MYhR for ; Fri, 9 Nov 2012 01:27:34 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 54DF621F85EE for ; Fri, 9 Nov 2012 01:27:33 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id C4069128037F; Fri, 9 Nov 2012 17:28:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qA99RDWv052540; Fri, 9 Nov 2012 17:27:13 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <59E40B2663705C47B8C0A107CBFBA988044BBE@US70TWXCHMBA09.zam.alcatel-lucent.com> To: "Fedyk, Donald (Don)" Subject: RE: Vlan-aware bundling over VPLS MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Fri, 9 Nov 2012 17:26:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-09 17:27:08, Serialize complete at 2012-11-09 17:27:08 Content-Type: multipart/alternative; boundary="=_alternative 0033EF1D48257AB1_=" X-MAIL: mse02.zte.com.cn qA99RDWv052540 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, 09 Nov 2012 09:27:35 -0000 This is a multipart message in MIME format. --=_alternative 0033EF1D48257AB1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRG9uLA0KVGhlIHBvdGVudGlhbCBjYXNlIGluIG15IG1pbmQgaXMgaW4gZGF0YWNlbnRlci4g SW4gdGhlIHByb3ZpZGVyIEwyVlBOLCB0aGUgDQpjdXN0b21lciBhbHdheXMgaGFzIGEgQ0Ugc3dp dGNoIHdoaWNoIGNvdWxkIGRvIHRoZSBWTEFOIGZpbHRlcmluZyB0byANCmVuc3VyZSB0cmFmZmlj IHNlcGFyYXRpb24gYmV0d2VlbiBkaWZmZXJlbnQgY3VzdG9tZXIgVkxBTnMuIEJ1dCBpbiANCmRh dGFjZW50ZXIsIGlmIHRoZSBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIGVkZ2UgaXMgaW4gdGhlIGh5 cGVydmlzb3IsIHRoZXJlIA0KaXMgbm8gc3dpdGNoIHRvIGRvIFZMQU4gZmlsdGVyaW5nIGJldHdl ZW4gTlZFIGFuZCBWTSwgdGhlbiB0aGUgVk0gc2hvdWxkIA0KZG8gdGhlIHRyYWZmaWMgZmlsdGVy aW5nIGZvciBkaWZmZXJlbnQgVkxBTi4gSW4gVkxBTi1hd2FyZSBzd2l0Y2hpbmcsIHRoZSANCnRy YWZmaWMgd2lsbCBiZSBmaWx0ZXJlZCBhdCB0aGUgaW5ncmVzcyBOVkUsIGluc3RlYWQgb2YgVk0u DQoNCkZvciB0aGUgVk0gbW92aW5nIGNhc2UsIGl0IHdpbGwgYmUgYWxzbyB1c2VmdWwgaWYgdGhl IFZNJ3MgZ3Vlc3QgT1Mgd291bGQgDQphZGQgVkxBTjoNCjEuIFZNIGFkZHMgYSBWTEFOIHRvIHRy YWZmaWMgYW5kIGhhdmUgYW4gdGFnZ2VkIGludGVyZmFjZSB3aXRoIHZpcnR1YWwgDQpzd2l0Y2gu DQoyLiB0aGUgdmlydHVhbCBzd2l0Y2ggd2lsbCBiZSB0aGUgZWRnZSBvZiB2aXJ0dWFsIEwyIG5l dHdvcmsuDQozLiB3aGVuIFZNIG1vdmVzIHRvIGFub3RoZXIgcGxhY2UsIHRoZSBWTEFOLUlEIHNo b3VsZCBub3QgYmUgY2hhbmdlZC4NCklmIFZMQU4tdW5hd2FyZSBpcyBhcHBsaWVkLCB0aGUgVkxB Ti1JRCBtYXliZSBzdHJpcHBlZCBieSB0aGUgZWRnZSwgYW5kIA0KVkxBTiB0cmFuc2xhdGlvbiBp cyByZXF1aXJlZCB0byBjb25maWd1cmUgb24gdGhlIHZpcnR1YWwgc3dpdGNoIHdoZW4gVk0gDQpt b3ZpbmcuIFdoaWxlIGlmIFZMQU4tYXdhcmUgaXMgYXBwbGllZCwgaXQgZW5zdXJlcyB0aGUgc2Ft ZSBWTEFOIHRvIGJlIA0KdXNlZCBhdCB0aGUgZG9tYWlucyB0cmFmZmljIHRvL2Zyb20gVk1zLCBh bmQgVk0gY291bGQgbW92ZSBhY3Jvc3MgdGhlIA0KZG9tYWlucyBmcmVlbHkgd2l0aG91dCBib3Ro ZXJpbmcgdGhlIHZpcnR1YWwgc3dpdGNoLg0KVGhlIHZpcnR1YWwgTDIgbmV0d29yayBjb3VsZCBi ZSBFLVZQTiwgb3IgVlBMUz8gSSBhbSBub3Qgc3VyZS4gQnV0IGZvciBhbnkgDQp2aXJ0dWFsIEwy IG5ldHdvcmsgYXBwbGllZCBpbiBOVk8zLCBJIHRoaW5rIFZMQU4tYXdhcmUgaGFzIHBvdGVudGlh bCB1c2UgDQpjYXNlLiBkcmFmdC1yZWtodGVyLW52bzMtdm0tbW9iaWxpdHktaXNzdWVzLTAzIGRl c2NyaWJlcyB0aGUgbW92aW5nIGlzc3VlIA0KaW4gc2VjdGlvbiAzLjEuDQoNClRoYW5rcw0KTGl6 aG9uZw0KIA0KDQoiRmVkeWssIERvbmFsZCAoRG9uKSIgPGRvbmFsZC5mZWR5a0BhbGNhdGVsLWx1 Y2VudC5jb20+IHdyb3RlIDIwMTIvMTEvMDggDQoyMzowNzoxOToNCg0KPiBIaSBMaXpob25nDQo+ IA0KPiBUaGUgd2F5IEkgc2VlIGl0OiANCj4gDQo+IEluIHRoZSBjYXNlIG9mIG5vbiBWTEFOIGF3 YXJlIHlvdSBuZWVkIHRvIGFkZCBhIEMtVkxBTiBzZXJ2aWNlIHRvIGEgbmV3IA0Kbm9kZToNCj4g oaQgICAgICAgICBZb3UgY3JlYXRlIHRoZSBzZXJ2aWNlIChsb2NhbCkNCj4goaQgICAgICAgICBZ b3UgYWRkIHRoZSBhY2Nlc3MgcG9pbnQgKGxvY2FsKSANCj4goaQgICAgICAgICBZb3UgY29ubmVj dCB0byB0aGUgb3RoZXIgc2VydmljZSAoUFdzIHNldHVwICwgU2lnbmFsZWQsIA0KPiBtYXkgYmUg YXV0b21hdGVkKQ0KPiANCj4gSW4gdGhlIGNhc2Ugb2YgVkxBTiBhd2FyZSB5b3UgbmVlZCB0byBh ZGQgYSBDLVZMQU4gc2VydmljZSB0byBhIG5ldyANCm5vZGU6DQo+IKGkICAgICAgICAgWW91IGFk ZCB0aGUgYWNjZXNzIHBvaW50IHRvIGEgc2hhcmVkIHNlcnZpY2UgKExvY2FsKSANCj4goaQgICAg ICAgICBUaGUgc2VydmljZSBhZHZlcnRpemVzIHRoZSBWTEFOIFZlY3RvciB0byBhbGwgb3RoZXIg cG9pbnRzDQo+IChTaWduYWxlZCwgYXV0b21hdGljKSANCj4gDQo+IEhvd2V2ZXIgaWYgdGhlIFNl cnZpY2UgeW91IGltcGxlbWVudCBpcyBhbiBTLVZMQU4gYW5kIHlvdSBhcmUgYWRkaW5nDQo+IGEg Qy1WTEFOIG9uIGEgVkxBTiB1bmF3YXJlIFZQTFMgOg0KPiChpCAgICAgICAgIFlvdSBhZGQgdGhl IGFjY2VzcyBwb2ludCB0byBhIHNoYXJlZCBzZXJ2aWNlIChMb2NhbCkgDQo+IA0KPiANCj4gV2Ug ZG9uoa90IG5lZWQgVkxBTiBhd2FyZSB0byBnZXQgYnVuZGxpbmcuIA0KPiANCj4gRG9uIA0KPiAN Cj4gDQo+IA0KPiANCj4gRnJvbTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25nLmppbkB6dGUu Y29tLmNuXSANCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA4LCAyMDEyIDY6MjYgQU0NCj4g VG86IGwydnBuQGlldGYub3JnOyBiZWRhcmQucGhpbEBnbWFpbC5jb207IEZlZHlrLCBEb25hbGQg KERvbikNCj4gU3ViamVjdDogUmU6IFZsYW4tYXdhcmUgYnVuZGxpbmcgb3ZlciBWUExTDQo+IA0K PiANCj4gSXQgd291bGQgYmUgcG90ZW50aWFsbHkgdXNlZnVsIGZvciBWTEFOLWF3YXJlIGJ1bmRs aW5nIGluIGRhdGFjZW50ZXINCj4gKHJlbGF0ZWQgd2l0aCBOVk8zKS4gSWYgdGhlIHZpcnR1YWxp emVkIEwyIG5ldHdvcmsgY291bGQgcHJvdmlkZSANCj4gVkxBTi1hd2FyZSBidW5kbGluZywgdGhl IGN1c3RvbWVyIGNvdWxkIG1hbmFnZSBpdHMgb3duIFZMQU4gZG9tYWluLCANCj4gb3RoZXJ3aXNl IG9uZSB2aXJ0dWFsIG5ldHdvcmsgY291bGQgb25seSBwcm92aWRlIG9uZSBicm9hZGNhc3QgDQo+ IGRvbWFpbi4gQW5kIHRoZSBWTSBtb3Zpbmcgd291bGQgYmUgZWFzaWVyIGluIGEgVkxBTi1hd2Fy ZSANCj4gdmlydHVhbGl6ZWQgTDIgbmV0d29yayBpZiB0aGUgcGFja2V0IFZMQU4gaXMgYWRkZWQg YnkgVk0uIA0KPiANCj4gTGl6aG9uZyANCj4gDQo+IA0KPiA+IA0KPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+IA0KPiA+IE1lc3NhZ2U6IDMNCj4gPiBEYXRlOiBXZWQsIDA3 IE5vdiAyMDEyIDIyOjA0OjQ2IC0wNTAwDQo+ID4gRnJvbTogUGhpbCBCZWRhcmQgPGJlZGFyZC5w aGlsQGdtYWlsLmNvbT4NCj4gPiBUbzogIkZlZHlrLCBEb25hbGQgKERvbikiIDxkb25hbGQuZmVk eWtAYWxjYXRlbC1sdWNlbnQuY29tPiwNCj4gPiAgICAibDJ2cG5AaWV0Zi5vcmciIDxsMnZwbkBp ZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogVmxhbi1hd2FyZSBidW5kbGluZyBvdmVyIFZQTFMN Cj4gPiBNZXNzYWdlLUlEOiA8Q0NDMDY2RTAuNjRCMjklYmVkYXJkLnBoaWxAZ21haWwuY29tPg0K PiA+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgICBjaGFyc2V0PSJVUy1BU0NJSSINCj4gPiAN Cj4gPiBQYXJ0IG9mIHRoZSBkcmFmdCBpcyB0aGUgbXVsdGlwbGV4aW5nLCB0aGUgb3RoZXIgcGFy dCBpcyBkeW5hbWljYWxseQ0KPiA+IGNyZWF0aW5nIGJyaWRnZSBkb21haW5zIGZvciBlYWNoIGJ1 bmRsZWQgVkxBTiBhbmQgcHJ1bmluZyB0aGUgDQp1bm5lY2Vzc2FyeQ0KPiA+IFZMQU5zIGZyb20g cmVtb3RlIFBFcy4NCj4gPiANCj4gPiANCj4gPiBJIHRob3VnaHQgYSBiaXQgbW9yZSBhbmQgaGVy ZSBpcyBhIHVzZSBjYXNlIHdoZXJlIHRoaXMgZHJhZnQgbWF5IGhhdmUgDQpiZWVuDQo+ID4gdXNl ZnVsLiAgV2UgaGF2ZSBhIGNlbGwgYmFja2hhdWwgc2VydmljZSBkZWxpdmVyZWQgb3ZlciBWUExT IGZvciBhIA0KbW9iaWxlDQo+ID4gcHJvdmlkZXIuICBFYWNoIGNlbGwgc2l0ZSAoaHVuZHJlZHMp IGFyZSBkZWxpdmVyZWQgdG8gYSBzaW5nbGUgDQphZ2dyZWdhdGlvbg0KPiA+IFVOSSwgaG93ZXZl ciB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGZvciBlYWNoIGNlbGwgc2l0ZSB0byBiZWxvbmcgdG8g DQppdHMNCj4gPiBvd24gYnJpZGdlIGRvbWFpbi4gIFRoaXMgcmVxdWlyZWQgY3JlYXRpbmcgYSBz ZXBhcmF0ZSBzZXJ2aWNlIGZvciBlYWNoDQo+ID4gY2VsbCBzaXRlIHNvIHRoZSBjb25maWd1cmF0 aW9uIG9uIHRoZSBhZ2dyZWdhdGlvbiBub2RlIGlzIHN1YnN0YW50aWFsDQo+ID4gc2luY2UgZWFj aCBzZXJ2aWNlIHJlcXVpcmVzIGl0cyBvd24gUFcgY29uZmlndXJhdGlvbiAobm8gQS1EIGluIHVz ZS4pDQo+ID4gV2l0aCB0aGUgbWVjaGFuaXNtcyBpbiB0aGlzIGRyYWZ0IGl0IHdvdWxkIGhhdmUg cmVxdWlyZWQgb25seSBjcmVhdGluZyANCmENCj4gPiBzaW5nbGUgc2VydmljZSBuZXR3b3JrLXdp ZGUuICBUaGVyZSBtYXkgaGF2ZSBiZWVuIHNvbWUgT0FNIA0KaW1wbGljYXRpb25zIHRvDQo+ID4g dGhpcyBidXQgSSdkIGhhdmUgdG8gdGhpbmsgdGhhdCB0aHJvdWdoLg0KPiA+IA0KPiA+IEluIHNv bWUgb3RoZXIgaW5zdGFuY2VzIGl0IHdvdWxkIG5vdCBoYXZlIHdvcmtlZCBiZWNhdXNlIHdlIHVz ZSBILVZQTFMNCj4gPiB3L2FuIE1QTFMgVS1QRS4gIFRoZSB1cHN0cmVhbSBOLVBFIHdvdWxkIG5l ZWQgYSBtZWNoYW5pc20gdG8gcmVsYXkgdGhlDQo+ID4gVS1QRSBWTEFOcyB0byBvdGhlciBOLVBF cywgYW5kIHBvdGVudGlhbGx5IGFnZ3JlZ2F0ZSB0aG9zZSBmcm9tIA0KbXVsdGlwbGUNCj4gPiBV LVBFcyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgc2VydmljZS4gVGhlIE4tUEUgd291bGQgYWxzbyBo YXZlIHRvIA0KbWFpbnRhaW4NCj4gPiBzZXBhcmF0ZSBicmlkZ2UgZG9tYWlucyBpdHNlbGYuIFRo ZXJlIGlzIG5vdGhpbmcgaW4gdGhlIGRyYWZ0IGNvdmVyaW5nIA0KYW4NCj4gPiBILVZQTFMgc2Nl bmFyaW8gd2hpY2ggaXMgZmFpcmx5IGNvbW1vbi4NCj4gPiANCj4gPiBXZSBhbHNvIGNyZWF0ZSBW TEFOLXVuYXdhcmUgVlBMUyBxdWl0ZSBvZnRlbiBzaW5jZSB3ZSBkbyBub3Qgd2FudCB0byANCmJl DQo+ID4gaW52b2x2ZWQgd2l0aCBhZGRpbmcvZGVsZXRpbmcgY3VzdG9tZXIgVkxBTnMgYW5kIG1v c3QgY3VzdG9tZXJzIGRvIG5vdA0KPiA+IGhhdmUgYW4gZXhwbGljaXQgcmVxdWlyZW1lbnQgZm9y IHRoZWlyIFZMQU5zIHRvIGJlIGluIHNlcGFyYXRlIGJyaWRnZQ0KPiA+IGRvbWFpbnMgYWNyb3Nz IHRoZSBWUExTLiAgSW4gcmVhbGl0eSBtb3N0IG9mIHRoZW0gYXNzdW1lIHRoZSBWUExTIA0Kd29y a3MNCj4gPiB0aGF0IHdheSBzaW5jZSBtb3N0IEwyIHN3aXRjaGVzIGRvLCBidXQgd2UgaGF2ZW4n dCBydW4gaW50byBpc3N1ZXMgDQp1c2luZyBhDQo+ID4gc2hhcmVkIE1BQyB0YWJsZS4gDQo+ID4g DQo+ID4gUGhpbCANCj4gPiANCj4gPiANCj4gPiANCj4gPiBPbiAxMS83LzEyIDc6MDYgUE0sICJG ZWR5aywgRG9uYWxkIChEb24pIg0KPiA+IDxkb25hbGQuZmVkeWtAYWxjYXRlbC1sdWNlbnQuY29t PiB3cm90ZToNCj4gPiANCj4gPiA+SGkNCj4gPiA+DQo+ID4gPkkga25vdyBHaWxlcyBhcyBmb3Ig U1AgaW5wdXQgYW5kIEknbSBub3QgYW4gU1AgYnV0IHJlYWRpbmcgdGhpcyANCnRocmVhZA0KPiA+ ID5JJ20gYWxzbyBub3Qgc3VyZSBJIHRoYXQgcGVvcGxlIGFyZSBvbiB0aGUgc2FtZSBwYWdlLg0K PiA+ID4NCj4gPiA+V2hlbiB3ZSBsb29rIGF0IEV0aGVybmV0IElFRUUgODAyLjFRIHRoZXJlIGlz IGEgQy1WTEFOLCBTLVZMQU4sIA0KQi1WTEFODQo+ID4gPndoZXJlIHRoZSBTLVZMQU4gY2FuIG11 bHRpcGxleCBDLVZMQU5zICBhbmQgdGhlIEItTEFOIGVuY2Fwc3VsYXRlcyANCmFuZA0KPiA+ID5t dWx0aXBsZXhlcyBTLVZMQU5zIChvciBhbHNvIGFsbG93ZWQgQy1WTEFOcykuDQo+ID4gPg0KPiA+ ID5XaGVuIHdlIGxvb2sgYXQgVlBMUyB0aGUgTVBMUyBMYWJlbCBjYW4gY2FycnkgYW55IG9uZSBv ZiB0aGUgYWJvdmUgYXMgDQphDQo+ID4gPnNpbmdsZSBWTEFOICh1bmF3YXJlKS4gVGhpcyBpbmhl cmVudGx5IGluY2x1ZGVzIHRoZSBhYm92ZSBtdWx0aXBsZXguIA0KVG8NCj4gPiA+YWxsb3cgbXVs dGlwbGV4aW5nIGF0IHRoaXMgbGF5ZXIgd2UgYXJlIHNheWluZyB3ZSBhbGxvdyBjYXJyeWluZyAN Cm11bHRpcGxlDQo+ID4gPlZMQU5zIChDLVZMQU4sIFMtVkxBTiwgb3IgQi1WTEFOKSB3aXRoIGEg c2luZ2xlIGxhYmVsLg0KPiA+ID4NCj4gPiA+V2hpbGUgYSBsYWJlbCBtdWx0aXBsZXggbWFrZXMg c29tZSBzZW5zZSBmb3IgQy1WTEFOcy4gKFRoaXMgaXMgDQphbmFsb2dvdXMNCj4gPiA+dG8gdGhl IFMtVkxBTiBtb2RlbCkuICBJJ20gc3RydWdnbGluZyB3aXRoIGEgbGFiZWwgbXVsdGlwbGV4IG9m IFZMQU4NCj4gPiA+bXVsdGlwbGV4b3JzIG9yIGluIG90aGVyIHdvcmRzIGJleW9uZCBDLVZMQU4u IChJIGRvbid0IHRoaW5rIHBlb3BsZSANCmFyZQ0KPiA+ID5zdWdnZXN0aW5nIHdlIG11bHRpcGxl eCBCLVZMQU5zIHRoaXMgd2F5IHNvIEkgZ3Vlc3MgdGhlIHF1ZXN0aW9ucyBpcyANCmhvdw0KPiA+ ID5mYXIgc2hvdWxkIHdlIHRha2UgdGhpcyBhbmQgd2h5IGlzIHRoaXMgbmVlZGVkIGdpdmVuIHRo ZSBzZXJ2aWNlIA0KbGV2ZWwNCj4gPiA+YWxyZWFkeSBzdXBwb3J0cyBtdWx0aXBsZXhlcnMgPw0K PiA+ID4NCj4gPiA+UmVnYXJkcywNCj4gPiA+RG9uIA0KPiA+ID4NCj4gPiA+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+RnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KQmVoYWxmIE9mDQo+ID4gPkRhdmlkIEFsbGFu IEkNCj4gPiA+U2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwNywgMjAxMiA0OjQwIFBNDQo+ID4g PlRvOiBVVFRBUk8sIEpBTUVTOyAnUm9nZXJzLCBKb3NoJzsgTHVjeSB5b25nOyBHaWxlcyBIZXJv bjsgDQpsMnZwbkBpZXRmLm9yZw0KPiA+ID5TdWJqZWN0OiBSRTogVmxhbi1hd2FyZSBidW5kbGlu ZyBvdmVyIFZQTFMNCj4gPiA+DQo+ID4gPkdpdmVuIGluIDgwMi4xIHN0YW5kYXJkcyB0aGVyZSBp cyBJVkwgKGluZGVwZW5kZW50IFZMQU4gbGVhcm5pbmcpIGFuZCANClNWTA0KPiA+ID4oc2hhcmVk IFZMQU4gbGVhcm5pbmcpLCB3aGV0aGVyIGEgTUFDIHRhYmxlIGV4aXN0cyBwZXIgVklELCBwZXIg Z3JvdXAgDQpvZg0KPiA+ID5WSURzLCBvciBmb3IgYWxsIFZJRHMgaW4gYSBidW5kbGUgaW4gdGhl b3J5IGlzIGFuDQo+ID4gPmltcGxlbWVudGF0aW9uL29wZXJhdGlvbmFsIGNob2ljZS4gT3Igc2hv dWxkIGJlLg0KPiA+ID4NCj4gPiA+U1ZMIGRvZXMgcGVybWl0IE1BQyBpbmZvcm1hdGlvbiBnbGVh bmVkIGZyb20gb25lIFZJRCdzIHRyYWZmaWMgdG8gYmUgDQp1c2VkDQo+ID4gPmJ5IGFub3RoZXIs IHdoaWNoIHJlZHVjZXMgdGhlIG51bWJlciBvZiB1bmtub3ducy4gT1RPSCBpZiB0aGUgVklEcw0K PiA+ID5pZGVudGlmeSBjb21wbGV0ZWx5IGRpc2pvaW50IHNldHMgb2YgZW5kcG9pbnRzIHRoZXJl IGlzIG5vIHNoYXJlZA0KPiA+ID5pbmZvcm1hdGlvbiBvZiBjb25zZXF1ZW5jZS4NCj4gPiA+DQo+ ID4gPkNoZWVycw0KPiA+ID5EYXZlDQo+ID4gPg0KPiA+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID5Gcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91 bmNlc0BpZXRmLm9yZ10gT24gDQpCZWhhbGYgT2YNCj4gPiA+VVRUQVJPLCBKQU1FUw0KPiA+ID5T ZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA3LCAyMDEyIDE6MjMgUE0NCj4gPiA+VG86ICdSb2dl cnMsIEpvc2gnOyBMdWN5IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPiA+ID5T dWJqZWN0OiBSRTogVmxhbi1hd2FyZSBidW5kbGluZyBvdmVyIFZQTFMNCj4gPiA+DQo+ID4gPisx Li4gDQo+ID4gPg0KPiA+ID5KaW0gVXR0YXJvDQo+ID4gPg0KPiA+ID4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+ID5Gcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2 cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gDQpCZWhhbGYgT2YNCj4gPiA+Um9nZXJzLCBKb3NoDQo+ ID4gPlNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDcsIDIwMTIgMzowOSBQTQ0KPiA+ID5Ubzog THVjeSB5b25nOyBHaWxlcyBIZXJvbjsgbDJ2cG5AaWV0Zi5vcmcNCj4gPiA+U3ViamVjdDogUmU6 IFZsYW4tYXdhcmUgYnVuZGxpbmcgb3ZlciBWUExTDQo+ID4gPg0KPiA+ID5bTHVjeV0gSU1POiB0 aGlzIGlzIHdoYXQgYWxsLXRvLW9uZSBidW5kbGUgb2ZmZXIuIENQRSBwZXJmb3JtcyB0aGUgDQpm aWx0ZXIuDQo+ID4gPlRoZSBjcml0aWNhbCBxdWVzdGlvbiBmb3IgdGhpcyBzY2VuYXJpbyBpcyBp ZiBlYWNoIFZMQU4gaGFzIGl0cyBvd24gDQpNQUMNCj4gPiA+c3BhY2Ugb3Igbm90Pw0KPiA+ID4N Cj4gPiA+VW5kZXIgdGhlIGN1cnJlbnRseSBhdmFpbGFibGUgVlBMUyBtZXRob2QsIHRoZSBNQUMg dGFibGUgaXMgc2hhcmVkIA0KZm9yDQo+ID4gPnRoZSBlbnRpcmUgVlBMUyBpbnN0YW5jZS4gIFRo aXMgbWV0aG9kIGlzIG5vIGRpZmZlcmVudCB0aGFuIGEgbmF0aXZlDQo+ID4gPmV0aGVybmV0IG5l dHdvcmsgdXNpbmcgODAyLjFhZCwgSSdtIG5vdCBjb25jZXJuZWQgd2l0aCAnaXNvbGF0aW5nJyAN CnRoZQ0KPiA+ID5tYWMgdGFibGUgYmV0d2VlbiB2bGFucywgYnV0IGlmIEkgd2FzIEknZCBiZSBp bmNsaW5lZCB0byB1c2UgDQpzb21ldGhpbmcNCj4gPiA+YXZhaWxhYmxlIChpZSwgbXVsdGlwbGUg VlBMUyBpbnN0YW5jZXMvbXVsdGlwbGUgUFcncywgb3IgUEJCL1BCVCkNCj4gPiA+DQo+ID4gPg0K PiA+ID4tSm9zaA0KPiA+ID4NCj4gPiA+DQo+ID4gPk9uIDExLzcvMTIgMjowMiBQTSwgIkx1Y3kg eW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+DQo+ID4gPj5IaSBKb3No LA0KPiA+ID4+DQo+ID4gPj5UaGFuayB5b3UgZm9yIHRoZSByZXBseSBmaXJzdC4NCj4gPiA+Pg0K PiA+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+PiBGcm9tOiBSb2dlcnMs IEpvc2ggW21haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbV0NCj4gPiA+Pj4gU2VudDogV2Vk bmVzZGF5LCBOb3ZlbWJlciAwNywgMjAxMiAxOjM3IFBNDQo+ID4gPj4+IFRvOiBMdWN5IHlvbmc7 IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZw0KPiA+ID4+PiBTdWJqZWN0OiBSZTogVmxhbi1h d2FyZSBidW5kbGluZyBvdmVyIFZQTFMNCj4gPiA+Pj4NCj4gPiA+Pj4gUmVnYXJkaW5nIHRoZSB0 cmFucy1BUyBzZXJ2aWNlIHNjZW5hcmlvPw0KPiA+ID4+W0x1Y3ldIEkgZG9uJ3Qga25vdywgSSBw b3N0IHRoZSBxdWVzdGlvbiB0byBrbm93IHdoZXJlIGl0IHdpbGwgYmUgDQp1c2VkLg0KPiA+ID4+ IFdoYXQgd2UgaGFkIHByZXZpb3VzbHkNCj4gPiA+Pj4gZGlzY3Vzc2VkL2VudmlzaW9uZWQsIGFu ZCBJJ3ZlIHNlZW4gb25lIG90aGVyIFNQIGRvLCBpcyBidXkgYSBFTEFODQo+ID4gPj4+IHR5cGUg c2VydmljZSBmcm9tIGFub3RoZXIgb3BlcmF0b3IgKHdobyBkZWxpdmVyZWQgdmlhIFZQTFMpLiAg VGhpcw0KPiA+ID4+PiBhbGxvd2VkIHRoZW0gdG8gcHV0IGFueSBWTEFOIHRoZXkgbGlrZSBvbiB0 aGUgRU5OSSwgYW5kIGRlbGl2ZXIgaXQgDQp0bw0KPiA+ID4+PiBhbnkgZW5kcG9pbnQgb24gdGhl IFZQTFMgaW5zdGFuY2UuICBTaW5jZSB0aGV5IG93biB0aGUgZXF1aXBtZW50DQo+ID4gPj4+IChD UEUpIGF0IGVhY2ggZW5kLCB0aGV5IHNpbXBseSBhbGxvd2VkIHRoZSB2bGFuKHMpIHRoZXkgd2Fu dGVkIHRvDQo+ID4gPj4+IGRlbGl2ZXIgdG8gdGhhdCBlbmQgcG9pbnQuDQo+ID4gPj4+IFNpbmNl IHRoZSBWUExTIGluc3RhbmNlIGlzIG1hYy1sZWFybmluZywgdGhlIG9ubHkgdHJhZmZpYyB0aGF0 IGlzDQo+ID4gPj4+IGRlbGl2ZXJlZCB0aGF0IG1heSBiZSBkcm9wcGVkIGJ5IHRoZSBDUEUgaXMg QlVNIHRyYWZmaWMuDQo+ID4gPj5bTHVjeV0gSU1POiB0aGlzIGlzIHdoYXQgYWxsLXRvLW9uZSBi dW5kbGUgb2ZmZXIuIENQRSBwZXJmb3JtcyB0aGUNCj4gPiA+PmZpbHRlci4gVGhlIGNyaXRpY2Fs IHF1ZXN0aW9uIGZvciB0aGlzIHNjZW5hcmlvIGlzIGlmIGVhY2ggVkxBTiBoYXMgDQppdHMNCj4g PiA+Pm93biBNQUMgc3BhY2Ugb3Igbm90Pw0KPiA+ID4+DQo+ID4gPj5MdWN5DQo+ID4gPj4+DQo+ ID4gPj4+IEknbSBub3QgY2VydGFpbiBJIHVuZGVyc3RhbmQgdGhlIHF1ZXN0aW9uIHdlbGwuICBE b2VzIHRoYXQgYW5zd2VyIA0KaXQ/DQo+ID4gPj4+DQo+ID4gPj4+IC1Kb3NoDQo+ID4gPj4+DQo+ ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+IE9uIDExLzcvMTIgMTozMiBQTSwgIkx1Y3kgeW9uZyIg PGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+Pj4NCj4gPiA+Pj4gPkkgd291bGQg bGlrZSB0byBhZGQgb25lIG1vcmUgcXVlc3Rpb24gdG8gU1AgYmVzaWRlIEdpbGVzJ3MNCj4gPiA+ Pj4gPg0KPiA+ID4+PiA+MykgRG9lcyB0aGlzIHNlcnZpY2UgYXNwZWN0IG1lYW4gd2hlbmV2ZXIg Y3VzdG9tZXIgd2FudCB0byBhZGQgYSANCm5ldw0KPiA+ID4+PiBWTEFODQo+ID4gPj4+ID4oYSBC RCkgaW50byB0aGUgVlBMUyBzZXJ2aWNlLCBpdCBoYXMgdG8gaW5mb3JtIHRoZSBTUCBhbmQgU1Ag aGFzIA0KdG8NCj4gPiA+Pj4gPnByb3Zpc2lvbiB0aGlzIG9uIFBFPw0KPiA+ID4+PiA+DQo+ID4g Pj4+ID5UaGFua3MsDQo+ID4gPj4+ID5MdWN5DQo+ID4gPj4+ID4NCj4gPiA+Pj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4gPj4gRnJvbTogR2lsZXMgSGVyb24gW21haWx0 bzpnaWxlcy5oZXJvbkBnbWFpbC5jb21dDQo+ID4gPj4+ID4+IFNlbnQ6IFdlZG5lc2RheSwgTm92 ZW1iZXIgMDcsIDIwMTIgODo1NSBBTQ0KPiA+ID4+PiA+PiBUbzogbDJ2cG5AaWV0Zi5vcmcNCj4g PiA+Pj4gPj4gQ2M6IEhpbWFuc2h1IFNoYWg7IEx1Y3kgeW9uZzsgTmFiaWwgQml0YXINCj4gPiA+ Pj4gPj4gU3ViamVjdDogUmU6IFZsYW4tYXdhcmUgYnVuZGxpbmcgb3ZlciBWUExTDQo+ID4gPj4+ ID4+DQo+ID4gPj4+ID4+IEknbGwgbGVhdmUgdGhlIGRyYWZ0IGF1dGhvcnMgdG8gY29tbWVudCBv biB0aGUgcG9pbnRzIHJhaXNlZCBieQ0KPiA+ID4+PiA+PiBIaW1hbnNodSBhbmQgTHVjeQ0KPiA+ ID4+PiA+Pg0KPiA+ID4+PiA+PiBCdXQgSSB3b3VsZCBsaWtlIFNQcyB0byBjb21tZW50IGFzIHRv Og0KPiA+ID4+PiA+PiAxKSB3aGV0aGVyIFZMQU4tYXdhcmUgYnVuZGxpbmcgaXMgYSByZXF1aXJl bWVudA0KPiA+ID4+PiA+PiAyKSB3aGV0aGVyIHRoZXkgcmVxdWlyZSBWTEFOLWF3YXJlIGJ1bmRs aW5nIGJvdGggZm9yIFZQTFMgYW5kDQo+ID4gPj4+ID4+IEUtVlBODQo+ID4gPj4+ID4+DQo+ID4g Pj4+ID4+IEdpbGVzIChjaGFpciBoYXQgZmlybWx5IG9uKS4NCj4gPiA+Pj4gPj4NCj4gPiA+Pj4g Pj4gT24gNyBOb3YgMjAxMiwgYXQgMTQ6MTMsIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5j b20+IA0Kd3JvdGU6DQo+ID4gPj4+ID4+DQo+ID4gPj4+ID4+ID4gVGhlcmUgaXMgYSB0cmFkZS1v ZmYgb24gdGhlIHNvbHV0aW9uLiBpbmRpdmlkdWFsIEJEIG1heSBoYXZlDQo+ID4gPj4+ID4+IGRp ZmZlcmVudCBRb1MgcmVxdWlyZW1lbnQsIG11bHRpcGx4aW5nIHRoZW0gdG9nZXRoZXIgaW4gYSAN CnNpbmdsZQ0KPiA+ID4+PiA+PiBQVw0KPiA+ID4+PiBtYXkNCj4gPiA+Pj4gPj4gbG9zZSBzb21l IFFvUyBhbmQgT0FNIGNhcGFiaWxpdHkuIEZvciBleGFtcGxlLCB3aGVuIGNvbmdlc3Rpb24NCj4g PiA+Pj4gaGFwcGVucywNCj4gPiA+Pj4gPj4gc29tZSBCRCBtYXkgd29yayBhbmQgc29tZSBtYXkg bm90LCBQVyBzdGF0dXMgaXMgbm90IGFibGUgdG8gDQpyZWZsZXgNCj4gPiA+Pj4gdGhhdA0KPiA+ ID4+PiA+PiBwcm9wZXJseS4NCj4gPiA+Pj4gPj4gPg0KPiA+ID4+PiA+PiA+IEx1Y3kNCj4gPiA+ Pj4gPj4gPg0KPiA+ID4+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+ PiA+PiA+PiBGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNl c0BpZXRmLm9yZ10gDQpPbg0KPiA+ID4+PiA+PiBCZWhhbGYNCj4gPiA+Pj4gPj4gPj4gT2YgU2hh aCwgSGltYW5zaHUNCj4gPiA+Pj4gPj4gPj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDYsIDIw MTIgMjowNCBQTQ0KPiA+ID4+PiA+PiA+PiBUbzogbDJ2cG5AaWV0Zi5vcmcNCj4gPiA+Pj4gPj4g Pj4gU3ViamVjdDogVmxhbi1hd2FyZSBidW5kbGluZyBvdmVyIFZQTFMNCj4gPiA+Pj4gPj4gPj4N Cj4gPiA+Pj4gPj4gPj4gY2xhcmlmaWNhdGlvbiBxdWVzdGlvbjogICBJZiB2bGFuIGlzIHRoZSB0 YWcgdXNlZCBmb3IgZGVtdXggDQpvdmVyDQo+ID4gPj4+ID4+IHNpbmdsZQ0KPiA+ID4+PiA+PiA+ PiBQVyBhbmQgaWYgdGhhdCB2bGFuIG5lZWRzIHRvIGJlIGFkdmVydGlzZWQgdGhlbiB3aGF0IGlz IHRoZQ0KPiA+ID4+PiBzYXZpbmc/DQo+ID4gPj4+ID4+IElzDQo+ID4gPj4+ID4+ID4+IHRoaXMg anVzdCBzYXZpbmcgb2YgdGhlIFBXIGxhYmVsPw0KPiA+ID4+PiA+PiA+PiBIaW1hbnNodQ0KPiA+ ID4+PiA+PiA+Pg0KPiA+ID4+PiA+PiA+PiBTZW50IGZyb20gbXkgaVBhZA0KPiA+ID4+PiA+DQo+ ID4gPj4+DQo+ID4gPj4+DQo= --=_alternative 0033EF1D48257AB1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERvbiw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBwb3RlbnRpYWwgY2FzZSBpbiBteSBt aW5kIGlzIGluDQpkYXRhY2VudGVyLiBJbiB0aGUgcHJvdmlkZXIgTDJWUE4sIHRoZSBjdXN0b21l ciBhbHdheXMgaGFzIGEgQ0Ugc3dpdGNoDQp3aGljaCBjb3VsZCBkbyB0aGUgVkxBTiBmaWx0ZXJp bmcgdG8gZW5zdXJlIHRyYWZmaWMgc2VwYXJhdGlvbiBiZXR3ZWVuDQpkaWZmZXJlbnQgY3VzdG9t ZXIgVkxBTnMuIEJ1dCBpbiBkYXRhY2VudGVyLCBpZiB0aGUgbmV0d29yayB2aXJ0dWFsaXphdGlv bg0KZWRnZSBpcyBpbiB0aGUgaHlwZXJ2aXNvciwgdGhlcmUgaXMgbm8gc3dpdGNoIHRvIGRvIFZM QU4gZmlsdGVyaW5nIGJldHdlZW4NCk5WRSBhbmQgVk0sIHRoZW4gdGhlIFZNIHNob3VsZCBkbyB0 aGUgdHJhZmZpYyBmaWx0ZXJpbmcgZm9yIGRpZmZlcmVudCBWTEFOLg0KSW4gVkxBTi1hd2FyZSBz d2l0Y2hpbmcsIHRoZSB0cmFmZmljIHdpbGwgYmUgZmlsdGVyZWQgYXQgdGhlIGluZ3Jlc3MgTlZF LA0KaW5zdGVhZCBvZiBWTS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkZvciB0aGUgVk0gbW92aW5nIGNhc2UsIGl0IHdpbGwgYmUgYWxzbw0KdXNlZnVs IGlmIHRoZSBWTSdzIGd1ZXN0IE9TIHdvdWxkIGFkZCBWTEFOOjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gVk0gYWRkcyBhIFZMQU4gdG8gdHJhZmZpYyBhbmQg aGF2ZQ0KYW4gdGFnZ2VkIGludGVyZmFjZSB3aXRoIHZpcnR1YWwgc3dpdGNoLjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4gdGhlIHZpcnR1YWwgc3dpdGNoIHdp bGwgYmUgdGhlIGVkZ2UNCm9mIHZpcnR1YWwgTDIgbmV0d29yay48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuIHdoZW4gVk0gbW92ZXMgdG8gYW5vdGhlciBwbGFj ZSwgdGhlDQpWTEFOLUlEIHNob3VsZCBub3QgYmUgY2hhbmdlZC48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIFZMQU4tdW5hd2FyZSBpcyBhcHBsaWVkLCB0aGUg VkxBTi1JRA0KbWF5YmUgc3RyaXBwZWQgYnkgdGhlIGVkZ2UsIGFuZCBWTEFOIHRyYW5zbGF0aW9u IGlzIHJlcXVpcmVkIHRvIGNvbmZpZ3VyZQ0Kb24gdGhlIHZpcnR1YWwgc3dpdGNoIHdoZW4gVk0g bW92aW5nLiBXaGlsZSBpZiBWTEFOLWF3YXJlIGlzIGFwcGxpZWQsIGl0DQplbnN1cmVzIHRoZSBz YW1lIFZMQU4gdG8gYmUgdXNlZCBhdCB0aGUgZG9tYWlucyB0cmFmZmljIHRvL2Zyb20gVk1zLCBh bmQNClZNIGNvdWxkIG1vdmUgYWNyb3NzIHRoZSBkb21haW5zIGZyZWVseSB3aXRob3V0IGJvdGhl cmluZyB0aGUgdmlydHVhbCBzd2l0Y2guPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UaGUgdmlydHVhbCBMMiBuZXR3b3JrIGNvdWxkIGJlIEUtVlBOLA0Kb3IgVlBM Uz8gSSBhbSBub3Qgc3VyZS4gQnV0IGZvciBhbnkgdmlydHVhbCBMMiBuZXR3b3JrIGFwcGxpZWQg aW4gTlZPMywNCkkgdGhpbmsgVkxBTi1hd2FyZSBoYXMgcG90ZW50aWFsIHVzZSBjYXNlLiBkcmFm dC1yZWtodGVyLW52bzMtdm0tbW9iaWxpdHktaXNzdWVzLTAzDQpkZXNjcmliZXMgdGhlIG1vdmlu ZyBpc3N1ZSBpbiBzZWN0aW9uIDMuMS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+TGl6aG9uZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mcXVvdDtGZWR5aywgRG9uYWxkIChEb24pJnF1b3Q7ICZsdDtkb25hbGQuZmVkeWtAYWxjYXRl bC1sdWNlbnQuY29tJmd0Ow0Kd3JvdGUgMjAxMi8xMS8wOCAyMzowNzoxOTo8YnI+DQo8YnI+DQom Z3Q7IEhpIExpemhvbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m Z3Q7IFRoZSB3YXkgSSBzZWUgaXQ6IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jmd0OyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZndDsgSW4gdGhlIGNhc2Ugb2Ygbm9uIFZMQU4gYXdhcmUgeW91DQpuZWVkIHRvIGFk ZCBhIEMtVkxBTiBzZXJ2aWNlIHRvIGEgbmV3IG5vZGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IKGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K WW91IGNyZWF0ZSB0aGUgc2VydmljZSAobG9jYWwpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IKGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KWW91 IGFkZCB0aGUgYWNjZXNzIHBvaW50IChsb2NhbCkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IKGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KWW91 IGNvbm5lY3QgdG8gdGhlIG90aGVyIHNlcnZpY2UgKFBXcyBzZXR1cCAsIFNpZ25hbGVkLCAmbmJz cDs8YnI+DQomZ3Q7IG1heSBiZSBhdXRvbWF0ZWQpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jmd0OyBJbiB0aGUgY2FzZSBvZiBWTEFOIGF3YXJlIHlvdSBuZWVkDQp0 byBhZGQgYSBDLVZMQU4gc2VydmljZSB0byBhIG5ldyBub2RlOjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyChpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCllvdSBhZGQgdGhlIGFjY2VzcyBwb2ludCB0byBhIHNoYXJlZCBzZXJ2aWNlIChMb2NhbCkg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IKGkICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVGhlIHNlcnZpY2UgYWR2ZXJ0aXplcyB0aGUgVkxBTiBW ZWN0b3IgdG8gYWxsIG90aGVyIHBvaW50czxicj4NCiZndDsgKFNpZ25hbGVkLCBhdXRvbWF0aWMp IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgSG93ZXZlciBp ZiB0aGUgU2VydmljZSB5b3UgaW1wbGVtZW50DQppcyBhbiBTLVZMQU4gYW5kIHlvdSBhcmUgYWRk aW5nPGJyPg0KJmd0OyBhIEMtVkxBTiBvbiBhIFZMQU4gdW5hd2FyZSBWUExTIDo8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgoaQgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQpZb3UgYWRkIHRoZSBhY2Nlc3MgcG9pbnQgdG8gYSBzaGFyZWQgc2Vydmlj ZSAoTG9jYWwpIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsg Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IFdl IGRvbqGvdCBuZWVkIFZMQU4gYXdhcmUgdG8gZ2V0DQpidW5kbGluZy4gPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyBEb24gPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jmd0OyBGcm9tOiBMaXpob25nIEppbiBbbWFpbHRvOmxpemhvbmcuamlu QHp0ZS5jb20uY25dDQo8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwOCwgMjAx MiA2OjI2IEFNPGJyPg0KJmd0OyBUbzogbDJ2cG5AaWV0Zi5vcmc7IGJlZGFyZC5waGlsQGdtYWls LmNvbTsgRmVkeWssIERvbmFsZCAoRG9uKTxicj4NCiZndDsgU3ViamVjdDogUmU6IFZsYW4tYXdh cmUgYnVuZGxpbmcgb3ZlciBWUExTPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jmd0OyA8YnI+DQomZ3Q7IEl0IHdvdWxkIGJlIHBvdGVudGlhbGx5IHVzZWZ1bCBmb3Ig VkxBTi1hd2FyZSBidW5kbGluZyBpbiBkYXRhY2VudGVyPGJyPg0KJmd0OyAocmVsYXRlZCB3aXRo IE5WTzMpLiBJZiB0aGUgdmlydHVhbGl6ZWQgTDIgbmV0d29yayBjb3VsZCBwcm92aWRlIDxicj4N CiZndDsgVkxBTi1hd2FyZSBidW5kbGluZywgdGhlIGN1c3RvbWVyIGNvdWxkIG1hbmFnZSBpdHMg b3duIFZMQU4gZG9tYWluLA0KPGJyPg0KJmd0OyBvdGhlcndpc2Ugb25lIHZpcnR1YWwgbmV0d29y ayBjb3VsZCBvbmx5IHByb3ZpZGUgb25lIGJyb2FkY2FzdCA8YnI+DQomZ3Q7IGRvbWFpbi4gQW5k IHRoZSBWTSBtb3Zpbmcgd291bGQgYmUgZWFzaWVyIGluIGEgVkxBTi1hd2FyZSA8YnI+DQomZ3Q7 IHZpcnR1YWxpemVkIEwyIG5ldHdvcmsgaWYgdGhlIHBhY2tldCBWTEFOIGlzIGFkZGVkIGJ5IFZN LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgTGl6aG9uZyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE1lc3NhZ2U6IDM8YnI+DQomZ3Q7ICZn dDsgRGF0ZTogV2VkLCAwNyBOb3YgMjAxMiAyMjowNDo0NiAtMDUwMDxicj4NCiZndDsgJmd0OyBG cm9tOiBQaGlsIEJlZGFyZCAmbHQ7YmVkYXJkLnBoaWxAZ21haWwuY29tJmd0Ozxicj4NCiZndDsg Jmd0OyBUbzogJnF1b3Q7RmVkeWssIERvbmFsZCAoRG9uKSZxdW90OyAmbHQ7ZG9uYWxkLmZlZHlr QGFsY2F0ZWwtbHVjZW50LmNvbSZndDssPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsmcXVv dDtsMnZwbkBpZXRmLm9yZyZxdW90OyAmbHQ7bDJ2cG5AaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFN1YmplY3Q6IFJlOiBWbGFuLWF3YXJlIGJ1bmRsaW5nIG92ZXIgVlBMUzxicj4NCiZndDsg Jmd0OyBNZXNzYWdlLUlEOiAmbHQ7Q0NDMDY2RTAuNjRCMjklYmVkYXJkLnBoaWxAZ21haWwuY29t Jmd0Ozxicj4NCiZndDsgJmd0OyBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47ICZuYnNwOyBjaGFy c2V0PSZxdW90O1VTLUFTQ0lJJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBQ YXJ0IG9mIHRoZSBkcmFmdCBpcyB0aGUgbXVsdGlwbGV4aW5nLCB0aGUgb3RoZXIgcGFydCBpcyBk eW5hbWljYWxseTxicj4NCiZndDsgJmd0OyBjcmVhdGluZyBicmlkZ2UgZG9tYWlucyBmb3IgZWFj aCBidW5kbGVkIFZMQU4gYW5kIHBydW5pbmcgdGhlDQp1bm5lY2Vzc2FyeTxicj4NCiZndDsgJmd0 OyBWTEFOcyBmcm9tIHJlbW90ZSBQRXMuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgSSB0aG91Z2h0IGEgYml0IG1vcmUgYW5kIGhlcmUgaXMgYSB1 c2UgY2FzZSB3aGVyZSB0aGlzIGRyYWZ0DQptYXkgaGF2ZSBiZWVuPGJyPg0KJmd0OyAmZ3Q7IHVz ZWZ1bC4gJm5ic3A7V2UgaGF2ZSBhIGNlbGwgYmFja2hhdWwgc2VydmljZSBkZWxpdmVyZWQgb3Zl cg0KVlBMUyBmb3IgYSBtb2JpbGU8YnI+DQomZ3Q7ICZndDsgcHJvdmlkZXIuICZuYnNwO0VhY2gg Y2VsbCBzaXRlIChodW5kcmVkcykgYXJlIGRlbGl2ZXJlZCB0byBhDQpzaW5nbGUgYWdncmVnYXRp b248YnI+DQomZ3Q7ICZndDsgVU5JLCBob3dldmVyIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgZm9y IGVhY2ggY2VsbCBzaXRlIHRvIGJlbG9uZw0KdG8gaXRzPGJyPg0KJmd0OyAmZ3Q7IG93biBicmlk Z2UgZG9tYWluLiAmbmJzcDtUaGlzIHJlcXVpcmVkIGNyZWF0aW5nIGEgc2VwYXJhdGUgc2Vydmlj ZQ0KZm9yIGVhY2g8YnI+DQomZ3Q7ICZndDsgY2VsbCBzaXRlIHNvIHRoZSBjb25maWd1cmF0aW9u IG9uIHRoZSBhZ2dyZWdhdGlvbiBub2RlIGlzIHN1YnN0YW50aWFsPGJyPg0KJmd0OyAmZ3Q7IHNp bmNlIGVhY2ggc2VydmljZSByZXF1aXJlcyBpdHMgb3duIFBXIGNvbmZpZ3VyYXRpb24gKG5vIEEt RA0KaW4gdXNlLik8YnI+DQomZ3Q7ICZndDsgV2l0aCB0aGUgbWVjaGFuaXNtcyBpbiB0aGlzIGRy YWZ0IGl0IHdvdWxkIGhhdmUgcmVxdWlyZWQgb25seQ0KY3JlYXRpbmcgYTxicj4NCiZndDsgJmd0 OyBzaW5nbGUgc2VydmljZSBuZXR3b3JrLXdpZGUuICZuYnNwO1RoZXJlIG1heSBoYXZlIGJlZW4g c29tZSBPQU0NCmltcGxpY2F0aW9ucyB0bzxicj4NCiZndDsgJmd0OyB0aGlzIGJ1dCBJJ2QgaGF2 ZSB0byB0aGluayB0aGF0IHRocm91Z2guPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJ biBzb21lIG90aGVyIGluc3RhbmNlcyBpdCB3b3VsZCBub3QgaGF2ZSB3b3JrZWQgYmVjYXVzZSB3 ZSB1c2UNCkgtVlBMUzxicj4NCiZndDsgJmd0OyB3L2FuIE1QTFMgVS1QRS4gJm5ic3A7VGhlIHVw c3RyZWFtIE4tUEUgd291bGQgbmVlZCBhIG1lY2hhbmlzbQ0KdG8gcmVsYXkgdGhlPGJyPg0KJmd0 OyAmZ3Q7IFUtUEUgVkxBTnMgdG8gb3RoZXIgTi1QRXMsIGFuZCBwb3RlbnRpYWxseSBhZ2dyZWdh dGUgdGhvc2UgZnJvbQ0KbXVsdGlwbGU8YnI+DQomZ3Q7ICZndDsgVS1QRXMgYmVsb25naW5nIHRv IHRoZSBzYW1lIHNlcnZpY2UuIFRoZSBOLVBFIHdvdWxkIGFsc28gaGF2ZQ0KdG8gbWFpbnRhaW48 YnI+DQomZ3Q7ICZndDsgc2VwYXJhdGUgYnJpZGdlIGRvbWFpbnMgaXRzZWxmLiBUaGVyZSBpcyBu b3RoaW5nIGluIHRoZSBkcmFmdA0KY292ZXJpbmcgYW48YnI+DQomZ3Q7ICZndDsgSC1WUExTIHNj ZW5hcmlvIHdoaWNoIGlzIGZhaXJseSBjb21tb24uPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzxicj4N CiZndDsgJmd0OyBXZSBhbHNvIGNyZWF0ZSBWTEFOLXVuYXdhcmUgVlBMUyBxdWl0ZSBvZnRlbiBz aW5jZSB3ZSBkbyBub3QNCndhbnQgdG8gYmU8YnI+DQomZ3Q7ICZndDsgaW52b2x2ZWQgd2l0aCBh ZGRpbmcvZGVsZXRpbmcgY3VzdG9tZXIgVkxBTnMgYW5kIG1vc3QgY3VzdG9tZXJzDQpkbyBub3Q8 YnI+DQomZ3Q7ICZndDsgaGF2ZSBhbiBleHBsaWNpdCByZXF1aXJlbWVudCBmb3IgdGhlaXIgVkxB TnMgdG8gYmUgaW4gc2VwYXJhdGUNCmJyaWRnZTxicj4NCiZndDsgJmd0OyBkb21haW5zIGFjcm9z cyB0aGUgVlBMUy4gJm5ic3A7SW4gcmVhbGl0eSBtb3N0IG9mIHRoZW0gYXNzdW1lDQp0aGUgVlBM UyB3b3Jrczxicj4NCiZndDsgJmd0OyB0aGF0IHdheSBzaW5jZSBtb3N0IEwyIHN3aXRjaGVzIGRv LCBidXQgd2UgaGF2ZW4ndCBydW4gaW50byBpc3N1ZXMNCnVzaW5nIGE8YnI+DQomZ3Q7ICZndDsg c2hhcmVkIE1BQyB0YWJsZS4gJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBQ aGlsIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBPbiAxMS83LzEyIDc6MDYgUE0sICZxdW90O0ZlZHlrLCBEb25hbGQgKERvbikm cXVvdDs8YnI+DQomZ3Q7ICZndDsgJmx0O2RvbmFsZC5mZWR5a0BhbGNhdGVsLWx1Y2VudC5jb20m Z3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0O0hpPGJyPg0KJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0O0kga25vdyBHaWxlcyBhcyBmb3IgU1AgaW5w dXQgYW5kIEknbSBub3QgYW4gU1AgYnV0IHJlYWRpbmcNCnRoaXMgdGhyZWFkPGJyPg0KJmd0OyAm Z3Q7ICZndDtJJ20gYWxzbyBub3Qgc3VyZSBJIHRoYXQgcGVvcGxlIGFyZSBvbiB0aGUgc2FtZSBw YWdlLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDtXaGVuIHdlIGxvb2sg YXQgRXRoZXJuZXQgSUVFRSA4MDIuMVEgdGhlcmUgaXMgYSBDLVZMQU4sIFMtVkxBTiwNCkItVkxB Tjxicj4NCiZndDsgJmd0OyAmZ3Q7d2hlcmUgdGhlIFMtVkxBTiBjYW4gbXVsdGlwbGV4IEMtVkxB TnMgJm5ic3A7YW5kIHRoZSBCLUxBTg0KZW5jYXBzdWxhdGVzIGFuZDxicj4NCiZndDsgJmd0OyAm Z3Q7bXVsdGlwbGV4ZXMgUy1WTEFOcyAob3IgYWxzbyBhbGxvd2VkIEMtVkxBTnMpLjxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDtXaGVuIHdlIGxvb2sgYXQgVlBMUyB0aGUg TVBMUyBMYWJlbCBjYW4gY2FycnkgYW55IG9uZSBvZg0KdGhlIGFib3ZlIGFzIGE8YnI+DQomZ3Q7 ICZndDsgJmd0O3NpbmdsZSBWTEFOICh1bmF3YXJlKS4gVGhpcyBpbmhlcmVudGx5IGluY2x1ZGVz IHRoZSBhYm92ZQ0KbXVsdGlwbGV4LiBUbzxicj4NCiZndDsgJmd0OyAmZ3Q7YWxsb3cgbXVsdGlw bGV4aW5nIGF0IHRoaXMgbGF5ZXIgd2UgYXJlIHNheWluZyB3ZSBhbGxvdyBjYXJyeWluZw0KbXVs dGlwbGU8YnI+DQomZ3Q7ICZndDsgJmd0O1ZMQU5zIChDLVZMQU4sIFMtVkxBTiwgb3IgQi1WTEFO KSB3aXRoIGEgc2luZ2xlIGxhYmVsLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDtXaGlsZSBhIGxhYmVsIG11bHRpcGxleCBtYWtlcyBzb21lIHNlbnNlIGZvciBDLVZMQU5z LiAoVGhpcw0KaXMgYW5hbG9nb3VzPGJyPg0KJmd0OyAmZ3Q7ICZndDt0byB0aGUgUy1WTEFOIG1v ZGVsKS4gJm5ic3A7SSdtIHN0cnVnZ2xpbmcgd2l0aCBhIGxhYmVsIG11bHRpcGxleA0Kb2YgVkxB Tjxicj4NCiZndDsgJmd0OyAmZ3Q7bXVsdGlwbGV4b3JzIG9yIGluIG90aGVyIHdvcmRzIGJleW9u ZCBDLVZMQU4uIChJIGRvbid0IHRoaW5rDQpwZW9wbGUgYXJlPGJyPg0KJmd0OyAmZ3Q7ICZndDtz dWdnZXN0aW5nIHdlIG11bHRpcGxleCBCLVZMQU5zIHRoaXMgd2F5IHNvIEkgZ3Vlc3MgdGhlIHF1 ZXN0aW9ucw0KaXMgaG93PGJyPg0KJmd0OyAmZ3Q7ICZndDtmYXIgc2hvdWxkIHdlIHRha2UgdGhp cyBhbmQgd2h5IGlzIHRoaXMgbmVlZGVkIGdpdmVuIHRoZQ0Kc2VydmljZSBsZXZlbDxicj4NCiZn dDsgJmd0OyAmZ3Q7YWxyZWFkeSBzdXBwb3J0cyBtdWx0aXBsZXhlcnMgPzxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDtSZWdhcmRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7RG9u ICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDstLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7RnJvbTogbDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddDQpPbiBCZWhhbGYgT2Y8YnI+ DQomZ3Q7ICZndDsgJmd0O0RhdmlkIEFsbGFuIEk8YnI+DQomZ3Q7ICZndDsgJmd0O1NlbnQ6IFdl ZG5lc2RheSwgTm92ZW1iZXIgMDcsIDIwMTIgNDo0MCBQTTxicj4NCiZndDsgJmd0OyAmZ3Q7VG86 IFVUVEFSTywgSkFNRVM7ICdSb2dlcnMsIEpvc2gnOyBMdWN5IHlvbmc7IEdpbGVzIEhlcm9uOw0K bDJ2cG5AaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0O1N1YmplY3Q6IFJFOiBWbGFuLWF3YXJl IGJ1bmRsaW5nIG92ZXIgVlBMUzxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDtHaXZlbiBpbiA4MDIuMSBzdGFuZGFyZHMgdGhlcmUgaXMgSVZMIChpbmRlcGVuZGVudCBWTEFO IGxlYXJuaW5nKQ0KYW5kIFNWTDxicj4NCiZndDsgJmd0OyAmZ3Q7KHNoYXJlZCBWTEFOIGxlYXJu aW5nKSwgd2hldGhlciBhIE1BQyB0YWJsZSBleGlzdHMgcGVyIFZJRCwNCnBlciBncm91cCBvZjxi cj4NCiZndDsgJmd0OyAmZ3Q7VklEcywgb3IgZm9yIGFsbCBWSURzIGluIGEgYnVuZGxlIGluIHRo ZW9yeSBpcyBhbjxicj4NCiZndDsgJmd0OyAmZ3Q7aW1wbGVtZW50YXRpb24vb3BlcmF0aW9uYWwg Y2hvaWNlLiBPciBzaG91bGQgYmUuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0O1NWTCBkb2VzIHBlcm1pdCBNQUMgaW5mb3JtYXRpb24gZ2xlYW5lZCBmcm9tIG9uZSBWSUQn cyB0cmFmZmljDQp0byBiZSB1c2VkPGJyPg0KJmd0OyAmZ3Q7ICZndDtieSBhbm90aGVyLCB3aGlj aCByZWR1Y2VzIHRoZSBudW1iZXIgb2YgdW5rbm93bnMuIE9UT0ggaWYNCnRoZSBWSURzPGJyPg0K Jmd0OyAmZ3Q7ICZndDtpZGVudGlmeSBjb21wbGV0ZWx5IGRpc2pvaW50IHNldHMgb2YgZW5kcG9p bnRzIHRoZXJlIGlzIG5vDQpzaGFyZWQ8YnI+DQomZ3Q7ICZndDsgJmd0O2luZm9ybWF0aW9uIG9m IGNvbnNlcXVlbmNlLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDtDaGVl cnM8YnI+DQomZ3Q7ICZndDsgJmd0O0RhdmU8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0O0Zy b206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3Jn XQ0KT24gQmVoYWxmIE9mPGJyPg0KJmd0OyAmZ3Q7ICZndDtVVFRBUk8sIEpBTUVTPGJyPg0KJmd0 OyAmZ3Q7ICZndDtTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA3LCAyMDEyIDE6MjMgUE08YnI+ DQomZ3Q7ICZndDsgJmd0O1RvOiAnUm9nZXJzLCBKb3NoJzsgTHVjeSB5b25nOyBHaWxlcyBIZXJv bjsgbDJ2cG5AaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0O1N1YmplY3Q6IFJFOiBWbGFuLWF3 YXJlIGJ1bmRsaW5nIG92ZXIgVlBMUzxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsrMS4uIDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDtKaW0gVXR0 YXJvPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Oy0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDtGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10NCk9uIEJlaGFsZiBPZjxicj4NCiZn dDsgJmd0OyAmZ3Q7Um9nZXJzLCBKb3NoPGJyPg0KJmd0OyAmZ3Q7ICZndDtTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDA3LCAyMDEyIDM6MDkgUE08YnI+DQomZ3Q7ICZndDsgJmd0O1RvOiBMdWN5 IHlvbmc7IEdpbGVzIEhlcm9uOyBsMnZwbkBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7U3Vi amVjdDogUmU6IFZsYW4tYXdhcmUgYnVuZGxpbmcgb3ZlciBWUExTPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0O1tMdWN5XSBJTU86IHRoaXMgaXMgd2hhdCBhbGwtdG8tb25l IGJ1bmRsZSBvZmZlci4gQ1BFIHBlcmZvcm1zDQp0aGUgZmlsdGVyLjxicj4NCiZndDsgJmd0OyAm Z3Q7VGhlIGNyaXRpY2FsIHF1ZXN0aW9uIGZvciB0aGlzIHNjZW5hcmlvIGlzIGlmIGVhY2ggVkxB TiBoYXMNCml0cyBvd24gTUFDPGJyPg0KJmd0OyAmZ3Q7ICZndDtzcGFjZSBvciBub3Q/PGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0O1VuZGVyIHRoZSBjdXJyZW50bHkgYXZh aWxhYmxlIFZQTFMgbWV0aG9kLCB0aGUgTUFDIHRhYmxlDQppcyBzaGFyZWQgZm9yPGJyPg0KJmd0 OyAmZ3Q7ICZndDt0aGUgZW50aXJlIFZQTFMgaW5zdGFuY2UuICZuYnNwO1RoaXMgbWV0aG9kIGlz IG5vIGRpZmZlcmVudA0KdGhhbiBhIG5hdGl2ZTxicj4NCiZndDsgJmd0OyAmZ3Q7ZXRoZXJuZXQg bmV0d29yayB1c2luZyA4MDIuMWFkLCBJJ20gbm90IGNvbmNlcm5lZCB3aXRoICdpc29sYXRpbmcn DQp0aGU8YnI+DQomZ3Q7ICZndDsgJmd0O21hYyB0YWJsZSBiZXR3ZWVuIHZsYW5zLCBidXQgaWYg SSB3YXMgSSdkIGJlIGluY2xpbmVkIHRvDQp1c2Ugc29tZXRoaW5nPGJyPg0KJmd0OyAmZ3Q7ICZn dDthdmFpbGFibGUgKGllLCBtdWx0aXBsZSBWUExTIGluc3RhbmNlcy9tdWx0aXBsZSBQVydzLCBv cg0KUEJCL1BCVCk8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDstSm9zaDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0O09uIDExLzcvMTIgMjowMiBQTSwgJnF1b3Q7THVjeSB5b25n JnF1b3Q7ICZsdDtsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDsNCndyb3RlOjxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7SGkgSm9zaCw8YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDtUaGFuayB5b3UgZm9yIHRoZSByZXBseSBmaXJz dC48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9t OiBSb2dlcnMsIEpvc2ggW21haWx0bzpqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbV08YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDcsIDIwMTIgMToz NyBQTTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgVG86IEx1Y3kgeW9uZzsgR2lsZXMgSGVy b247IGwydnBuQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBS ZTogVmxhbi1hd2FyZSBidW5kbGluZyBvdmVyIFZQTFM8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBSZWdhcmRpbmcgdGhlIHRyYW5zLUFTIHNl cnZpY2Ugc2NlbmFyaW8/PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7W0x1Y3ldIEkgZG9uJ3Qga25v dywgSSBwb3N0IHRoZSBxdWVzdGlvbiB0byBrbm93IHdoZXJlDQppdCB3aWxsIGJlIHVzZWQuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFdoYXQgd2UgaGFkIHByZXZpb3VzbHk8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7IGRpc2N1c3NlZC9lbnZpc2lvbmVkLCBhbmQgSSd2ZSBzZWVuIG9uZSBv dGhlciBTUA0KZG8sIGlzIGJ1eSBhIEVMQU48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHR5 cGUgc2VydmljZSBmcm9tIGFub3RoZXIgb3BlcmF0b3IgKHdobyBkZWxpdmVyZWQNCnZpYSBWUExT KS4gJm5ic3A7VGhpczxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYWxsb3dlZCB0aGVtIHRv IHB1dCBhbnkgVkxBTiB0aGV5IGxpa2Ugb24gdGhlIEVOTkksDQphbmQgZGVsaXZlciBpdCB0bzxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgYW55IGVuZHBvaW50IG9uIHRoZSBWUExTIGluc3Rh bmNlLiAmbmJzcDtTaW5jZSB0aGV5DQpvd24gdGhlIGVxdWlwbWVudDxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyZndDsgKENQRSkgYXQgZWFjaCBlbmQsIHRoZXkgc2ltcGx5IGFsbG93ZWQgdGhlIHZs YW4ocykNCnRoZXkgd2FudGVkIHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBkZWxpdmVy IHRvIHRoYXQgZW5kIHBvaW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgU2luY2UgdGhl IFZQTFMgaW5zdGFuY2UgaXMgbWFjLWxlYXJuaW5nLCB0aGUgb25seQ0KdHJhZmZpYyB0aGF0IGlz PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBkZWxpdmVyZWQgdGhhdCBtYXkgYmUgZHJvcHBl ZCBieSB0aGUgQ1BFIGlzIEJVTQ0KdHJhZmZpYy48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDtbTHVj eV0gSU1POiB0aGlzIGlzIHdoYXQgYWxsLXRvLW9uZSBidW5kbGUgb2ZmZXIuIENQRQ0KcGVyZm9y bXMgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ZmlsdGVyLiBUaGUgY3JpdGljYWwgcXVlc3Rp b24gZm9yIHRoaXMgc2NlbmFyaW8gaXMgaWYNCmVhY2ggVkxBTiBoYXMgaXRzPGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7b3duIE1BQyBzcGFjZSBvciBub3Q/PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7THVjeTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEknbSBub3QgY2VydGFpbiBJIHVuZGVyc3RhbmQg dGhlIHF1ZXN0aW9uIHdlbGwuDQombmJzcDtEb2VzIHRoYXQgYW5zd2VyIGl0Pzxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IC1Kb3NoPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBPbiAxMS83 LzEyIDE6MzIgUE0sICZxdW90O0x1Y3kgeW9uZyZxdW90OyAmbHQ7bHVjeS55b25nQGh1YXdlaS5j b20mZ3Q7DQp3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7SSB3b3VsZCBsaWtlIHRvIGFkZCBvbmUgbW9yZSBxdWVzdGlvbiB0 byBTUA0KYmVzaWRlIEdpbGVzJ3M8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDszKSBEb2VzIHRoaXMgc2VydmljZSBhc3BlY3Qg bWVhbiB3aGVuZXZlciBjdXN0b21lcg0Kd2FudCB0byBhZGQgYSBuZXc8YnI+DQomZ3Q7ICZndDsg Jmd0OyZndDsmZ3Q7IFZMQU48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDsoYSBCRCkg aW50byB0aGUgVlBMUyBzZXJ2aWNlLCBpdCBoYXMgdG8gaW5mb3JtDQp0aGUgU1AgYW5kIFNQIGhh cyB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0O3Byb3Zpc2lvbiB0aGlzIG9uIFBF Pzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyZndDsgJmd0O1RoYW5rcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDtMdWN5PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgRnJvbTogR2lsZXMgSGVyb24gW21haWx0bzpnaWxlcy5oZXJvbkBn bWFpbC5jb21dPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBXZWRu ZXNkYXksIE5vdmVtYmVyIDA3LCAyMDEyIDg6NTUNCkFNPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBUbzogbDJ2cG5AaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7IENjOiBIaW1hbnNodSBTaGFoOyBMdWN5IHlvbmc7IE5hYmlsIEJpdGFyPGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogVmxhbi1hd2Fy ZSBidW5kbGluZyBvdmVyIFZQTFM8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJJ2xsIGxlYXZlIHRoZSBkcmFm dCBhdXRob3JzIHRvIGNvbW1lbnQNCm9uIHRoZSBwb2ludHMgcmFpc2VkIGJ5PGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBIaW1hbnNodSBhbmQgTHVjeTxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDsm Z3Q7IEJ1dCBJIHdvdWxkIGxpa2UgU1BzIHRvIGNvbW1lbnQgYXMgdG86PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAxKSB3aGV0aGVyIFZMQU4tYXdhcmUgYnVuZGxpbmcgaXMg YSByZXF1aXJlbWVudDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgMikgd2hl dGhlciB0aGV5IHJlcXVpcmUgVkxBTi1hd2FyZSBidW5kbGluZw0KYm90aCBmb3IgVlBMUyBhbmQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEUtVlBOPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgR2lsZXMgKGNoYWlyIGhhdCBmaXJtbHkgb24pLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9uIDcgTm92 IDIwMTIsIGF0IDE0OjEzLCBMdWN5IHlvbmcgJmx0O2x1Y3kueW9uZ0BodWF3ZWkuY29tJmd0Ow0K d3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyBUaGVyZSBpcyBhIHRyYWRlLW9mZiBvbiB0aGUg c29sdXRpb24uDQppbmRpdmlkdWFsIEJEIG1heSBoYXZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBkaWZmZXJlbnQgUW9TIHJlcXVpcmVtZW50LCBtdWx0aXBseGluZw0KdGhl bSB0b2dldGhlciBpbiBhIHNpbmdsZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZn dDsgUFc8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IG1heTxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyZndDsgbG9zZSBzb21lIFFvUyBhbmQgT0FNIGNhcGFiaWxpdHkuIEZvciBl eGFtcGxlLA0Kd2hlbiBjb25nZXN0aW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBoYXBw ZW5zLDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgc29tZSBCRCBtYXkgd29y ayBhbmQgc29tZSBtYXkgbm90LCBQVyBzdGF0dXMNCmlzIG5vdCBhYmxlIHRvIHJlZmxleDxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhhdDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsg Jmd0OyZndDsgcHJvcGVybHkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEx1Y3k8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBsMnZwbi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10NCk9uPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBCZWhhbGY8YnI+DQomZ3Q7ICZndDsgJmd0OyZn dDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IE9mIFNoYWgsIEhpbWFuc2h1PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAw NiwgMjAxMg0KMjowNCBQTTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0 OyZndDsgVG86IGwydnBuQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBWbGFuLWF3YXJlIGJ1bmRsaW5nIG92ZXINClZQTFM8YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uOiAm bmJzcDsNCklmIHZsYW4gaXMgdGhlIHRhZyB1c2VkIGZvciBkZW11eCBvdmVyPGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzaW5nbGU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsm Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFBXIGFuZCBpZiB0aGF0IHZsYW4gbmVlZHMgdG8gYmUNCmFk dmVydGlzZWQgdGhlbiB3aGF0IGlzIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgc2F2 aW5nPzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgSXM8YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IHRoaXMganVzdCBzYXZpbmcgb2YgdGhl IFBXIGxhYmVsPzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZndDsg SGltYW5zaHU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50IGZyb20gbXkg aVBhZDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PC9mb250Pg0K --=_alternative 0033EF1D48257AB1_=-- From donald.fedyk@alcatel-lucent.com Fri Nov 9 08:00: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 7AB1F21F8723 for ; Fri, 9 Nov 2012 08:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, HELO_EQ_FR=0.35, 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 poIgv0Qfhfjr for ; Fri, 9 Nov 2012 07:59:58 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3002F21F8720 for ; Fri, 9 Nov 2012 07:59:55 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA9FxJsk027537 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Nov 2012 16:59:51 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Nov 2012 16:59:37 +0100 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.198]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 9 Nov 2012 10:59:35 -0500 From: "Fedyk, Donald (Don)" To: Lizhong Jin Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: AQHNvaPRgSftmByxTkOJG8S2+4GckZff/B0QgAGU/QD////V0A== Date: Fri, 9 Nov 2012 15:59:34 +0000 Message-ID: <59E40B2663705C47B8C0A107CBFBA988046E2A@US70TWXCHMBA09.zam.alcatel-lucent.com> References: <59E40B2663705C47B8C0A107CBFBA988044BBE@US70TWXCHMBA09.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_59E40B2663705C47B8C0A107CBFBA988046E2AUS70TWXCHMBA09zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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, 09 Nov 2012 16:00:01 -0000 --_000_59E40B2663705C47B8C0A107CBFBA988046E2AUS70TWXCHMBA09zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lizhong If you need VLAN filtering then the PBB-VPLS already offers this capability= . PBB-VPLS is I-SID aware and allows the flexibility. My point is VLAN aware VPLS is recreating yet another version of VPLS with = new forwarding with essentially the same features available today with stan= dard tags. With the PBB-VPLS the limit on VLANs is 24 bit. Cheers, Don From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Friday, November 09, 2012 4:26 AM To: Fedyk, Donald (Don) Cc: bedard.phil@gmail.com; l2vpn@ietf.org Subject: RE: Vlan-aware bundling over VPLS Hi Don, The potential case in my mind is in datacenter. In the provider L2VPN, the = customer always has a CE switch which could do the VLAN filtering to ensure= traffic separation between different customer VLANs. But in datacenter, if= the network virtualization edge is in the hypervisor, there is no switch t= o do VLAN filtering between NVE and VM, then the VM should do the traffic f= iltering for different VLAN. In VLAN-aware switching, the traffic will be f= iltered at the ingress NVE, instead of VM. For the VM moving case, it will be also useful if the VM's guest OS would a= dd VLAN: 1. VM adds a VLAN to traffic and have an tagged interface with virtual swit= ch. 2. the virtual switch will be the edge of virtual L2 network. 3. when VM moves to another place, the VLAN-ID should not be changed. If VLAN-unaware is applied, the VLAN-ID maybe stripped by the edge, and VLA= N translation is required to configure on the virtual switch when VM moving= . While if VLAN-aware is applied, it ensures the same VLAN to be used at th= e domains traffic to/from VMs, and VM could move across the domains freely = without bothering the virtual switch. The virtual L2 network could be E-VPN, or VPLS? I am not sure. But for any = virtual L2 network applied in NVO3, I think VLAN-aware has potential use ca= se. draft-rekhter-nvo3-vm-mobility-issues-03 describes the moving issue in = section 3.1. Thanks Lizhong "Fedyk, Donald (Don)" wrote 2012/11/08 23= :07:19: > Hi Lizhong > > The way I see it: > > In the case of non VLAN aware you need to add a C-VLAN service to a new n= ode: > * You create the service (local) > * You add the access point (local) > * You connect to the other service (PWs setup , Signaled, > may be automated) > > In the case of VLAN aware you need to add a C-VLAN service to a new node: > * You add the access point to a shared service (Local) > * The service advertizes the VLAN Vector to all other points > (Signaled, automatic) > > However if the Service you implement is an S-VLAN and you are adding > a C-VLAN on a VLAN unaware VPLS : > * You add the access point to a shared service (Local) > > > We don't need VLAN aware to get bundling. > > Don > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Thursday, November 08, 2012 6:26 AM > To: l2vpn@ietf.org; bedard.phil@gmail.com; Fedyk, Donald (Don) > Subject: Re: Vlan-aware bundling over VPLS > > > It would be potentially useful for VLAN-aware bundling in datacenter > (related with NVO3). If the virtualized L2 network could provide > VLAN-aware bundling, the customer could manage its own VLAN domain, > otherwise one virtual network could only provide one broadcast > domain. And the VM moving would be easier in a VLAN-aware > virtualized L2 network if the packet VLAN is added by VM. > > Lizhong > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 07 Nov 2012 22:04:46 -0500 > > From: Phil Bedard > > To: "Fedyk, Donald (Don)" , > > "l2vpn@ietf.org" > > Subject: Re: Vlan-aware bundling over VPLS > > Message-ID: > > Content-Type: text/plain; charset=3D"US-ASCII" > > > > Part of the draft is the multiplexing, the other part is dynamically > > creating bridge domains for each bundled VLAN and pruning the unnecessa= ry > > VLANs from remote PEs. > > > > > > I thought a bit more and here is a use case where this draft may have b= een > > useful. We have a cell backhaul service delivered over VPLS for a mobi= le > > provider. Each cell site (hundreds) are delivered to a single aggregat= ion > > UNI, however there is a requirement for each cell site to belong to its > > own bridge domain. This required creating a separate service for each > > cell site so the configuration on the aggregation node is substantial > > since each service requires its own PW configuration (no A-D in use.) > > With the mechanisms in this draft it would have required only creating = a > > single service network-wide. There may have been some OAM implications= to > > this but I'd have to think that through. > > > > In some other instances it would not have worked because we use H-VPLS > > w/an MPLS U-PE. The upstream N-PE would need a mechanism to relay the > > U-PE VLANs to other N-PEs, and potentially aggregate those from multipl= e > > U-PEs belonging to the same service. The N-PE would also have to mainta= in > > separate bridge domains itself. There is nothing in the draft covering = an > > H-VPLS scenario which is fairly common. > > > > We also create VLAN-unaware VPLS quite often since we do not want to be > > involved with adding/deleting customer VLANs and most customers do not > > have an explicit requirement for their VLANs to be in separate bridge > > domains across the VPLS. In reality most of them assume the VPLS works > > that way since most L2 switches do, but we haven't run into issues usin= g a > > shared MAC table. > > > > Phil > > > > > > > > On 11/7/12 7:06 PM, "Fedyk, Donald (Don)" > > wrote: > > > > >Hi > > > > > >I know Giles as for SP input and I'm not an SP but reading this thread > > >I'm also not sure I that people are on the same page. > > > > > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN > > >where the S-VLAN can multiplex C-VLANs and the B-LAN encapsulates and > > >multiplexes S-VLANs (or also allowed C-VLANs). > > > > > >When we look at VPLS the MPLS Label can carry any one of the above as = a > > >single VLAN (unaware). This inherently includes the above multiplex. T= o > > >allow multiplexing at this layer we are saying we allow carrying multi= ple > > >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label. > > > > > >While a label multiplex makes some sense for C-VLANs. (This is analogo= us > > >to the S-VLAN model). I'm struggling with a label multiplex of VLAN > > >multiplexors or in other words beyond C-VLAN. (I don't think people ar= e > > >suggesting we multiplex B-VLANs this way so I guess the questions is h= ow > > >far should we take this and why is this needed given the service level > > >already supports multiplexers ? > > > > > >Regards, > > >Don > > > > > >-----Original Message----- > > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of > > >David Allan I > > >Sent: Wednesday, November 07, 2012 4:40 PM > > >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.= org > > >Subject: RE: Vlan-aware bundling over VPLS > > > > > >Given in 802.1 standards there is IVL (independent VLAN learning) and = SVL > > >(shared VLAN learning), whether a MAC table exists per VID, per group = of > > >VIDs, or for all VIDs in a bundle in theory is an > > >implementation/operational choice. Or should be. > > > > > >SVL does permit MAC information gleaned from one VID's traffic to be u= sed > > >by another, which reduces the number of unknowns. OTOH if the VIDs > > >identify completely disjoint sets of endpoints there is no shared > > >information of consequence. > > > > > >Cheers > > >Dave > > > > > >-----Original Message----- > > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of > > >UTTARO, JAMES > > >Sent: Wednesday, November 07, 2012 1:23 PM > > >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org > > >Subject: RE: Vlan-aware bundling over VPLS > > > > > >+1.. > > > > > >Jim Uttaro > > > > > >-----Original Message----- > > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of > > >Rogers, Josh > > >Sent: Wednesday, November 07, 2012 3:09 PM > > >To: Lucy yong; Giles Heron; l2vpn@ietf.org > > >Subject: Re: Vlan-aware bundling over VPLS > > > > > >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the fil= ter. > > >The critical question for this scenario is if each VLAN has its own MA= C > > >space or not? > > > > > >Under the currently available VPLS method, the MAC table is shared for > > >the entire VPLS instance. This method is no different than a native > > >ethernet network using 802.1ad, I'm not concerned with 'isolating' the > > >mac table between vlans, but if I was I'd be inclined to use something > > >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) > > > > > > > > >-Josh > > > > > > > > >On 11/7/12 2:02 PM, "Lucy yong" wrote: > > > > > >>Hi Josh, > > >> > > >>Thank you for the reply first. > > >> > > >>> -----Original Message----- > > >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com] > > >>> Sent: Wednesday, November 07, 2012 1:37 PM > > >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org > > >>> Subject: Re: Vlan-aware bundling over VPLS > > >>> > > >>> Regarding the trans-AS service scenario? > > >>[Lucy] I don't know, I post the question to know where it will be use= d. > > >> What we had previously > > >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN > > >>> type service from another operator (who delivered via VPLS). This > > >>> allowed them to put any VLAN they like on the ENNI, and deliver it = to > > >>> any endpoint on the VPLS instance. Since they own the equipment > > >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to > > >>> deliver to that end point. > > >>> Since the VPLS instance is mac-learning, the only traffic that is > > >>> delivered that may be dropped by the CPE is BUM traffic. > > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the > > >>filter. The critical question for this scenario is if each VLAN has i= ts > > >>own MAC space or not? > > >> > > >>Lucy > > >>> > > >>> I'm not certain I understand the question well. Does that answer i= t? > > >>> > > >>> -Josh > > >>> > > >>> > > >>> > > >>> On 11/7/12 1:32 PM, "Lucy yong" wrote: > > >>> > > >>> >I would like to add one more question to SP beside Giles's > > >>> > > > >>> >3) Does this service aspect mean whenever customer want to add a n= ew > > >>> VLAN > > >>> >(a BD) into the VPLS service, it has to inform the SP and SP has t= o > > >>> >provision this on PE? > > >>> > > > >>> >Thanks, > > >>> >Lucy > > >>> > > > >>> >> -----Original Message----- > > >>> >> From: Giles Heron [mailto:giles.heron@gmail.com] > > >>> >> Sent: Wednesday, November 07, 2012 8:55 AM > > >>> >> To: l2vpn@ietf.org > > >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > > >>> >> Subject: Re: Vlan-aware bundling over VPLS > > >>> >> > > >>> >> I'll leave the draft authors to comment on the points raised by > > >>> >> Himanshu and Lucy > > >>> >> > > >>> >> But I would like SPs to comment as to: > > >>> >> 1) whether VLAN-aware bundling is a requirement > > >>> >> 2) whether they require VLAN-aware bundling both for VPLS and > > >>> >> E-VPN > > >>> >> > > >>> >> Giles (chair hat firmly on). > > >>> >> > > >>> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: > > >>> >> > > >>> >> > There is a trade-off on the solution. individual BD may have > > >>> >> different QoS requirement, multiplxing them together in a single > > >>> >> PW > > >>> may > > >>> >> lose some QoS and OAM capability. For example, when congestion > > >>> happens, > > >>> >> some BD may work and some may not, PW status is not able to refl= ex > > >>> that > > >>> >> properly. > > >>> >> > > > >>> >> > Lucy > > >>> >> > > > >>> >> >> -----Original Message----- > > >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] = On > > >>> >> Behalf > > >>> >> >> Of Shah, Himanshu > > >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM > > >>> >> >> To: l2vpn@ietf.org > > >>> >> >> Subject: Vlan-aware bundling over VPLS > > >>> >> >> > > >>> >> >> clarification question: If vlan is the tag used for demux o= ver > > >>> >> single > > >>> >> >> PW and if that vlan needs to be advertised then what is the > > >>> saving? > > >>> >> Is > > >>> >> >> this just saving of the PW label? > > >>> >> >> Himanshu > > >>> >> >> > > >>> >> >> Sent from my iPad > > >>> > > > >>> > > >>> --_000_59E40B2663705C47B8C0A107CBFBA988046E2AUS70TWXCHMBA09zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lizhong

 <= /p>

If you need VLAN filterin= g then the PBB-VPLS already offers this capability.  PBB-VPLS is I-SID= aware and allows the flexibility.

 <= /p>

My point is VLAN aware VP= LS is recreating yet another version of VPLS with new forwarding with essen= tially the same features available today with standard tags. With the PBB-VPLS the limit on VLANs is 24 bit.  

 <= /p>

Cheers,=

Don

 <= /p>

 <= /p>

From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Friday, November 09, 2012 4:26 AM
To: Fedyk, Donald (Don)
Cc: bedard.phil@gmail.com; l2vpn@ietf.org
Subject: RE: Vlan-aware bundling over VPLS

 


Hi Don,
The potential case in my mind is in datacenter. In the provider = L2VPN, the customer always has a CE switch which could do the VLAN filterin= g to ensure traffic separation between different customer VLANs. But in datacenter, if the network virtualization edge is in the hyp= ervisor, there is no switch to do VLAN filtering between NVE and VM, then t= he VM should do the traffic filtering for different VLAN. In VLAN-aware swi= tching, the traffic will be filtered at the ingress NVE, instead of VM.

For the VM moving case, it will be also useful if the VM's guest= OS would add VLAN:
1. VM adds a VLAN to traffic and have an tagged interface with v= irtual switch.
2. the virtual switch will be the edge of virtual L2 network.
3. when VM moves to another place, the VLAN-ID should not be cha= nged.
If VLAN-unaware is applied, the VLAN-ID maybe stripped by the ed= ge, and VLAN translation is required to configure on the virtual switch whe= n VM moving. While if VLAN-aware is applied, it ensures the same VLAN to be used at the domains traffic to/from VMs, and VM could = move across the domains freely without bothering the virtual switch.
The virtual L2 network could be E-VPN, or VPLS? I am not sure. B= ut for any virtual L2 network applied in NVO3, I think VLAN-aware has poten= tial use case. draft-rekhter-nvo3-vm-mobility-issues-03 describes the moving issue in section 3.1.

Thanks
Lizhong
 

"Fedyk, Donald (Don)" <donald.fedyk@alcatel-lucent.= com> wrote 2012/11/08 23:07:19:

> Hi Lizhong
>  
> The way I see it:
>  
> In the case of non VLAN aware you need to add a C-VLAN serv= ice to a new node:
> ·         You create the service= (local)
> ·         You add the access poi= nt (local)
> ·         You connect to the oth= er service (PWs setup , Signaled,  
> may be automated)
>  
> In the case of VLAN aware you need to add a C-VLAN service = to a new node:
> ·         You add the access poi= nt to a shared service (Local)
> ·         The service advertizes= the VLAN Vector to all other points
> (Signaled, automatic)
>  
> However if the Service you implement is an S-VLAN and you a= re adding
> a C-VLAN on a VLAN unaware VPLS :
> ·         You add the access poi= nt to a shared service (Local)
>  
>  
> We don’t need VLAN aware to get bundling.
>  
> Don
>  
>  
>  
>  
> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
> Sent: Thursday, November 08, 2012 6:26 AM
> To: l2vpn@ietf.org; bedard.phil@gmail.com; Fedyk, Donald (Don)
> Subject: Re: Vlan-aware bundling over VPLS
>  
>
> It would be potentially useful for VLAN-aware bundling in datacenter > (related with NVO3). If the virtualized L2 network could provide
> VLAN-aware bundling, the customer could manage its own VLAN domain, > otherwise one virtual network could only provide one broadcast
> domain. And the VM moving would be easier in a VLAN-aware
> virtualized L2 network if the packet VLAN is added by VM.
>
> Lizhong
>
>
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 07 Nov 2012 22:04:46 -0500
> > From: Phil Bedard <bedard.phil@gmail.com>
> > To: "Fedyk, Donald (Don)" <donald.fedyk@alcatel-luce= nt.com>,
> >    "l2vpn@ietf.org" <l2vpn@ietf.org> > > Subject: Re: Vlan-aware bundling over VPLS
> > Message-ID: <CCC066E0.64B29%bedard.phil@gmail.com>
> > Content-Type: text/plain;   charset=3D"US-ASCII" > >
> > Part of the draft is the multiplexing, the other part is dynamica= lly
> > creating bridge domains for each bundled VLAN and pruning the unn= ecessary
> > VLANs from remote PEs.
> >  
> >
> > I thought a bit more and here is a use case where this draft may = have been
> > useful.  We have a cell backhaul service delivered over VPLS= for a mobile
> > provider.  Each cell site (hundreds) are delivered to a sing= le aggregation
> > UNI, however there is a requirement for each cell site to belong = to its
> > own bridge domain.  This required creating a separate servic= e for each
> > cell site so the configuration on the aggregation node is substan= tial
> > since each service requires its own PW configuration (no A-D in u= se.)
> > With the mechanisms in this draft it would have required only cre= ating a
> > single service network-wide.  There may have been some OAM i= mplications to
> > this but I'd have to think that through.
> >
> > In some other instances it would not have worked because we use H= -VPLS
> > w/an MPLS U-PE.  The upstream N-PE would need a mechanism to= relay the
> > U-PE VLANs to other N-PEs, and potentially aggregate those from m= ultiple
> > U-PEs belonging to the same service. The N-PE would also have to = maintain
> > separate bridge domains itself. There is nothing in the draft cov= ering an
> > H-VPLS scenario which is fairly common.
> >  
> > We also create VLAN-unaware VPLS quite often since we do not want= to be
> > involved with adding/deleting customer VLANs and most customers d= o not
> > have an explicit requirement for their VLANs to be in separate br= idge
> > domains across the VPLS.  In reality most of them assume the= VPLS works
> > that way since most L2 switches do, but we haven't run into issue= s using a
> > shared MAC table.  
> >
> > Phil
> >
> >
> >
> > On 11/7/12 7:06 PM, "Fedyk, Donald (Don)"
> > <donald.fedyk@alcatel-lucent.com> wrote:
> >
> > >Hi
> > >
> > >I know Giles as for SP input and I'm not an SP but reading th= is thread
> > >I'm also not sure I that people are on the same page.
> > >
> > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLA= N, B-VLAN
> > >where the S-VLAN can multiplex C-VLANs  and the B-LAN en= capsulates and
> > >multiplexes S-VLANs (or also allowed C-VLANs).
> > >
> > >When we look at VPLS the MPLS Label can carry any one of the = above as a
> > >single VLAN (unaware). This inherently includes the above mul= tiplex. To
> > >allow multiplexing at this layer we are saying we allow carry= ing multiple
> > >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label.
> > >
> > >While a label multiplex makes some sense for C-VLANs. (This i= s analogous
> > >to the S-VLAN model).  I'm struggling with a label multi= plex of VLAN
> > >multiplexors or in other words beyond C-VLAN. (I don't think = people are
> > >suggesting we multiplex B-VLANs this way so I guess the quest= ions is how
> > >far should we take this and why is this needed given the serv= ice level
> > >already supports multiplexers ?
> > >
> > >Regards,
> > >Don  
> > >
> > >-----Original Message-----
> > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] = On Behalf Of
> > >David Allan I
> > >Sent: Wednesday, November 07, 2012 4:40 PM
> > >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2= vpn@ietf.org
> > >Subject: RE: Vlan-aware bundling over VPLS
> > >
> > >Given in 802.1 standards there is IVL (independent VLAN learn= ing) and SVL
> > >(shared VLAN learning), whether a MAC table exists per VID, p= er group of
> > >VIDs, or for all VIDs in a bundle in theory is an
> > >implementation/operational choice. Or should be.
> > >
> > >SVL does permit MAC information gleaned from one VID's traffi= c to be used
> > >by another, which reduces the number of unknowns. OTOH if the= VIDs
> > >identify completely disjoint sets of endpoints there is no sh= ared
> > >information of consequence.
> > >
> > >Cheers
> > >Dave
> > >
> > >-----Original Message-----
> > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] = On Behalf Of
> > >UTTARO, JAMES
> > >Sent: Wednesday, November 07, 2012 1:23 PM
> > >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org > > >Subject: RE: Vlan-aware bundling over VPLS
> > >
> > >+1..
> > >
> > >Jim Uttaro
> > >
> > >-----Original Message-----
> > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] = On Behalf Of
> > >Rogers, Josh
> > >Sent: Wednesday, November 07, 2012 3:09 PM
> > >To: Lucy yong; Giles Heron; l2vpn@ietf.org
> > >Subject: Re: Vlan-aware bundling over VPLS
> > >
> > >[Lucy] IMO: this is what all-to-one bundle offer. CPE perform= s the filter.
> > >The critical question for this scenario is if each VLAN has i= ts own MAC
> > >space or not?
> > >
> > >Under the currently available VPLS method, the MAC table is s= hared for
> > >the entire VPLS instance.  This method is no different t= han a native
> > >ethernet network using 802.1ad, I'm not concerned with 'isola= ting' the
> > >mac table between vlans, but if I was I'd be inclined to use = something
> > >available (ie, multiple VPLS instances/multiple PW's, or PBB/= PBT)
> > >
> > >
> > >-Josh
> > >
> > >
> > >On 11/7/12 2:02 PM, "Lucy yong" <lucy.yong@huawe= i.com> wrote:
> > >
> > >>Hi Josh,
> > >>
> > >>Thank you for the reply first.
> > >>
> > >>> -----Original Message-----
> > >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com]<= br> > > >>> Sent: Wednesday, November 07, 2012 1:37 PM
> > >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org
> > >>> Subject: Re: Vlan-aware bundling over VPLS
> > >>>
> > >>> Regarding the trans-AS service scenario?
> > >>[Lucy] I don't know, I post the question to know where it= will be used.
> > >> What we had previously
> > >>> discussed/envisioned, and I've seen one other SP do,= is buy a ELAN
> > >>> type service from another operator (who delivered vi= a VPLS).  This
> > >>> allowed them to put any VLAN they like on the ENNI, = and deliver it to
> > >>> any endpoint on the VPLS instance.  Since they = own the equipment
> > >>> (CPE) at each end, they simply allowed the vlan(s) t= hey wanted to
> > >>> deliver to that end point.
> > >>> Since the VPLS instance is mac-learning, the only tr= affic that is
> > >>> delivered that may be dropped by the CPE is BUM traf= fic.
> > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE per= forms the
> > >>filter. The critical question for this scenario is if eac= h VLAN has its
> > >>own MAC space or not?
> > >>
> > >>Lucy
> > >>>
> > >>> I'm not certain I understand the question well. &nbs= p;Does that answer it?
> > >>>
> > >>> -Josh
> > >>>
> > >>>
> > >>>
> > >>> On 11/7/12 1:32 PM, "Lucy yong" <lucy.y= ong@huawei.com> wrote:
> > >>>
> > >>> >I would like to add one more question to SP besi= de Giles's
> > >>> >
> > >>> >3) Does this service aspect mean whenever custom= er want to add a new
> > >>> VLAN
> > >>> >(a BD) into the VPLS service, it has to inform t= he SP and SP has to
> > >>> >provision this on PE?
> > >>> >
> > >>> >Thanks,
> > >>> >Lucy
> > >>> >
> > >>> >> -----Original Message-----
> > >>> >> From: Giles Heron [mailto:giles.heron@gmail= .com]
> > >>> >> Sent: Wednesday, November 07, 2012 8:55 AM<= br> > > >>> >> To: l2vpn@ietf.org
> > >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > > >>> >> Subject: Re: Vlan-aware bundling over VPLS<= br> > > >>> >>
> > >>> >> I'll leave the draft authors to comment on = the points raised by
> > >>> >> Himanshu and Lucy
> > >>> >>
> > >>> >> But I would like SPs to comment as to:
> > >>> >> 1) whether VLAN-aware bundling is a require= ment
> > >>> >> 2) whether they require VLAN-aware bundling= both for VPLS and
> > >>> >> E-VPN
> > >>> >>
> > >>> >> Giles (chair hat firmly on).
> > >>> >>
> > >>> >> On 7 Nov 2012, at 14:13, Lucy yong <lucy= .yong@huawei.com> wrote:
> > >>> >>
> > >>> >> > There is a trade-off on the solution. = individual BD may have
> > >>> >> different QoS requirement, multiplxing them= together in a single
> > >>> >> PW
> > >>> may
> > >>> >> lose some QoS and OAM capability. For examp= le, when congestion
> > >>> happens,
> > >>> >> some BD may work and some may not, PW statu= s is not able to reflex
> > >>> that
> > >>> >> properly.
> > >>> >> >
> > >>> >> > Lucy
> > >>> >> >
> > >>> >> >> -----Original Message-----
> > >>> >> >> From: l2vpn-bounces@ietf.org [mail= to:l2vpn-bounces@ietf.org] On
> > >>> >> Behalf
> > >>> >> >> Of Shah, Himanshu
> > >>> >> >> Sent: Tuesday, November 06, 2012 2= :04 PM
> > >>> >> >> To: l2vpn@ietf.org
> > >>> >> >> Subject: Vlan-aware bundling over = VPLS
> > >>> >> >>
> > >>> >> >> clarification question:   If = vlan is the tag used for demux over
> > >>> >> single
> > >>> >> >> PW and if that vlan needs to be ad= vertised then what is the
> > >>> saving?
> > >>> >> Is
> > >>> >> >> this just saving of the PW label?<= br> > > >>> >> >> Himanshu
> > >>> >> >>
> > >>> >> >> Sent from my iPad
> > >>> >
> > >>>
> > >>>

--_000_59E40B2663705C47B8C0A107CBFBA988046E2AUS70TWXCHMBA09zam_-- From dcai@cisco.com Sun Nov 11 17:01: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 8F45821F84DD for ; Sun, 11 Nov 2012 17:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.488 X-Spam-Level: X-Spam-Status: No, score=-9.488 tagged_above=-999 required=5 tests=[AWL=1.110, 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 e3EI6U87QDTI for ; Sun, 11 Nov 2012 17:01:00 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B01F321F84D8 for ; Sun, 11 Nov 2012 17:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9700; q=dns/txt; s=iport; t=1352682060; x=1353891660; h=from:to:subject:date:message-id:mime-version; bh=HUrD/0UrJTtDQDg9+3Gj/UyDQmYl+Et9jAglff4gIyw=; b=WHklJSPuiPIvds+hSRQR8ucTxsg6U7SV6yxuG6771Gh5odRZKFVIsHEc hFvq0Z25wqTsykhw6bhIqfsyEgBm7R5ETHkL4l60MBbwMQlgxIj56QI9W bUF9//ro/+N8sXy8aqW9GA/7udgcpODJA5ERhyzbJtHhrTMtZqgfMZ040 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABxKoFCtJXG9/2dsb2JhbABEgknBDIEIgiABBBIBGl4BCCJWJgEEARoTB4dom2CfApF+YQOkVIFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="141107569" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 12 Nov 2012 01:00:55 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAC10tEA014232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 01:00:55 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.88]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Sun, 11 Nov 2012 19:00:55 -0600 From: "Dennis Cai (dcai)" To: "Fedyk, Donald (Don)" , Lizhong Jin , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS - add use case Thread-Topic: Vlan-aware bundling over VPLS - add use case Thread-Index: Ac3AcMnL5NU8a0UeQQGzGm0rzaKZSw== Date: Mon, 12 Nov 2012 01:00:54 +0000 Message-ID: <623637051A3DC34E80FC9BA35B4629950F6326D4@xmb-rcd-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.62] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19354.005 x-tm-as-result: No--28.612000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_623637051A3DC34E80FC9BA35B4629950F6326D4xmbrcdx05ciscoc_" MIME-Version: 1.0 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, 12 Nov 2012 01:01:02 -0000 --_000_623637051A3DC34E80FC9BA35B4629950F6326D4xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, I'm the co-author for this draft. I saw lots of interesting discussion and = points. I want to share some thoughts and use cases behind this draft The original use case is enterprise Data Center interconnect using VPLS. Th= e main motivation is for "user simplicity" which is very important in enter= prise space. Although this concept could also be applied to SP DCI as well,= or other SP applications potentially Think about enterprise customers who have multiple DC sites, and have hundr= eds of VLANs across DC sites, what will be the solution and configurations?= The solution today is to use one VPLS instance per VLAN. This gives huge c= onfiguration, and introduce many PWs unnecessarily. QinQ is not an option h= ere because it doesn't create separate broadcast domain per VLAN. It may ru= n into duplicated MAC issues Yes, as some of you already pointed out, the function in vlan-aware vpls h= as already been covered by PBB-VPLS. In fact, you can even treat this as a = "simplified" pbb-vpls to help understand this draft. On the other hand, we = didn't see much adoption of pbb-vpls in enterprise (but people in this alia= s can make comment). Pbb-vpls is considered complex (such as flooding packe= t pruning, MAC flushing, etc) and inefficient (big header) technology for e= nterprise DCI deployment. With VLAN-aware VPLS, we just use VLAN for service multiplexer, which can b= e used for flooding packet pruning, and per-VLAN MAC flushing. This is much= simple approach and doesn't introduce additional overhead. With platform i= mplementation, the bridge-domain could be created implicitly, so user is ev= en not aware of this. Per-bridge domain feature can still work as usual if = it's required. In short, it use same qinq over vpls configuration (simple and scalable) fr= om end user point of view. However, it create separated bridge-domain per V= LAN for true separation. Then it multiplex VLANs into same VPLS instance/PW= to reduce the control planning overhead Thanks Dennis --_000_623637051A3DC34E80FC9BA35B4629950F6326D4xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 <= /p>

I’m the co-author f= or this draft. I saw lots of interesting discussion and points. I want to s= hare some thoughts and use cases behind this draft

 <= /p>

The original use case is = enterprise Data Center interconnect using VPLS. The main motivation is for = “user simplicity” which is very important in enterprise space. Although this concept could also be applied to SP DCI as well, = ; or other SP applications potentially

 <= /p>

Think about enterprise cu= stomers who have multiple DC sites, and have hundreds of VLANs across DC si= tes, what will be the solution and configurations? The solution today is to use one VPLS instance per VLAN. This gives huge configuration,= and introduce many PWs unnecessarily. QinQ is not an option here because i= t doesn’t create separate broadcast domain per VLAN. It may run = into duplicated MAC issues

 <= /p>

Yes, as some of you alrea= dy pointed out, the function  in vlan-aware vpls has already been cove= red by PBB-VPLS. In fact, you can even treat this as a “simplified= 221; pbb-vpls to help understand this draft. On the other hand, we didn’t= see much adoption of pbb-vpls in enterprise (but people in this alias can = make comment). Pbb-vpls is considered complex (such as flooding packet prun= ing, MAC flushing, etc) and inefficient (big header) technology for enterprise DCI deployment.  

 <= /p>

With VLAN-aware VPLS, we = just use VLAN for service multiplexer, which can be used for flooding packe= t pruning, and per-VLAN MAC flushing. This is much simple approach and doesn’t introduce additional overhead. With platform im= plementation, the bridge-domain could be created implicitly, so user is eve= n not aware of this. Per-bridge domain feature can still work as usual if i= t’s required.

 <= /p>

In short, it use same qin= q over vpls configuration (simple and scalable) from end user point of view= . However, it create separated bridge-domain per VLAN for true separation. Then it multiplex VLANs into same VPLS instance/PW to red= uce the control planning overhead

 <= /p>

Thanks
Dennis

 <= /p>

 <= /p>

 <= /p>

--_000_623637051A3DC34E80FC9BA35B4629950F6326D4xmbrcdx05ciscoc_-- From lucy.yong@huawei.com Sun Nov 11 17:28:36 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 CCE5021F8477 for ; Sun, 11 Nov 2012 17:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 tagged_above=-999 required=5 tests=[AWL=-1.632, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 t54oai+brXKc for ; Sun, 11 Nov 2012 17:28:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F02ED21F8442 for ; Sun, 11 Nov 2012 17:28:31 -0800 (PST) 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 ALK89435; Mon, 12 Nov 2012 01:28:29 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 01:28:22 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 01:28:26 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Sun, 11 Nov 2012 17:28:21 -0800 From: Lucy yong To: Lizhong Jin , "Fedyk, Donald (Don)" Subject: RE: Vlan-aware bundling over VPLS Thread-Topic: Vlan-aware bundling over VPLS Thread-Index: AQHNvlxIgSftmByxTkOJG8S2+4GckZflarYg Date: Mon, 12 Nov 2012 01:28:21 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482ED3F@dfweml505-mbx> References: <59E40B2663705C47B8C0A107CBFBA988044BBE@US70TWXCHMBA09.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.163.56] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4482ED3Fdfweml505mbx_" 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, 12 Nov 2012 01:28:36 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4482ED3Fdfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMO: when VM and NVE are on co-located, i.e. both are on a server, the filt= ering implementation is internal, no need to address in standard, and VM mo= bility will work just fun. When VM and NVE are remotely located, i.e. VM an= d NVE are connected through a local physical network, then the filtering fu= nction should not perform on the NVE, should be at the local network edge. = Thus, neither case requires VLAN-aware bundling on NVE. Vm-mobility-issue d= raft is orthogonal to the VLAN-aware bundling request. Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of L= izhong Jin Sent: Friday, November 09, 2012 3:26 AM To: Fedyk, Donald (Don) Cc: l2vpn@ietf.org Subject: RE: Vlan-aware bundling over VPLS Hi Don, The potential case in my mind is in datacenter. In the provider L2VPN, the = customer always has a CE switch which could do the VLAN filtering to ensure= traffic separation between different customer VLANs. But in datacenter, if= the network virtualization edge is in the hypervisor, there is no switch t= o do VLAN filtering between NVE and VM, then the VM should do the traffic f= iltering for different VLAN. In VLAN-aware switching, the traffic will be f= iltered at the ingress NVE, instead of VM. For the VM moving case, it will be also useful if the VM's guest OS would a= dd VLAN: 1. VM adds a VLAN to traffic and have an tagged interface with virtual swit= ch. 2. the virtual switch will be the edge of virtual L2 network. 3. when VM moves to another place, the VLAN-ID should not be changed. If VLAN-unaware is applied, the VLAN-ID maybe stripped by the edge, and VLA= N translation is required to configure on the virtual switch when VM moving= . While if VLAN-aware is applied, it ensures the same VLAN to be used at th= e domains traffic to/from VMs, and VM could move across the domains freely = without bothering the virtual switch. The virtual L2 network could be E-VPN, or VPLS? I am not sure. But for any = virtual L2 network applied in NVO3, I think VLAN-aware has potential use ca= se. draft-rekhter-nvo3-vm-mobility-issues-03 describes the moving issue in = section 3.1. Thanks Lizhong "Fedyk, Donald (Don)" wrote 2012/11/08 23= :07:19: > Hi Lizhong > > The way I see it: > > In the case of non VLAN aware you need to add a C-VLAN service to a new n= ode: > * You create the service (local) > * You add the access point (local) > * You connect to the other service (PWs setup , Signaled, > may be automated) > > In the case of VLAN aware you need to add a C-VLAN service to a new node: > * You add the access point to a shared service (Local) > * The service advertizes the VLAN Vector to all other points > (Signaled, automatic) > > However if the Service you implement is an S-VLAN and you are adding > a C-VLAN on a VLAN unaware VPLS : > * You add the access point to a shared service (Local) > > > We don't need VLAN aware to get bundling. > > Don > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Thursday, November 08, 2012 6:26 AM > To: l2vpn@ietf.org; bedard.phil@gmail.com; Fedyk, Donald (Don) > Subject: Re: Vlan-aware bundling over VPLS > > > It would be potentially useful for VLAN-aware bundling in datacenter > (related with NVO3). If the virtualized L2 network could provide > VLAN-aware bundling, the customer could manage its own VLAN domain, > otherwise one virtual network could only provide one broadcast > domain. And the VM moving would be easier in a VLAN-aware > virtualized L2 network if the packet VLAN is added by VM. > > Lizhong > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 07 Nov 2012 22:04:46 -0500 > > From: Phil Bedard > > To: "Fedyk, Donald (Don)" , > > "l2vpn@ietf.org" > > Subject: Re: Vlan-aware bundling over VPLS > > Message-ID: > > Content-Type: text/plain; charset=3D"US-ASCII" > > > > Part of the draft is the multiplexing, the other part is dynamically > > creating bridge domains for each bundled VLAN and pruning the unnecessa= ry > > VLANs from remote PEs. > > > > > > I thought a bit more and here is a use case where this draft may have b= een > > useful. We have a cell backhaul service delivered over VPLS for a mobi= le > > provider. Each cell site (hundreds) are delivered to a single aggregat= ion > > UNI, however there is a requirement for each cell site to belong to its > > own bridge domain. This required creating a separate service for each > > cell site so the configuration on the aggregation node is substantial > > since each service requires its own PW configuration (no A-D in use.) > > With the mechanisms in this draft it would have required only creating = a > > single service network-wide. There may have been some OAM implications= to > > this but I'd have to think that through. > > > > In some other instances it would not have worked because we use H-VPLS > > w/an MPLS U-PE. The upstream N-PE would need a mechanism to relay the > > U-PE VLANs to other N-PEs, and potentially aggregate those from multipl= e > > U-PEs belonging to the same service. The N-PE would also have to mainta= in > > separate bridge domains itself. There is nothing in the draft covering = an > > H-VPLS scenario which is fairly common. > > > > We also create VLAN-unaware VPLS quite often since we do not want to be > > involved with adding/deleting customer VLANs and most customers do not > > have an explicit requirement for their VLANs to be in separate bridge > > domains across the VPLS. In reality most of them assume the VPLS works > > that way since most L2 switches do, but we haven't run into issues usin= g a > > shared MAC table. > > > > Phil > > > > > > > > On 11/7/12 7:06 PM, "Fedyk, Donald (Don)" > > wrote: > > > > >Hi > > > > > >I know Giles as for SP input and I'm not an SP but reading this thread > > >I'm also not sure I that people are on the same page. > > > > > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLAN, B-VLAN > > >where the S-VLAN can multiplex C-VLANs and the B-LAN encapsulates and > > >multiplexes S-VLANs (or also allowed C-VLANs). > > > > > >When we look at VPLS the MPLS Label can carry any one of the above as = a > > >single VLAN (unaware). This inherently includes the above multiplex. T= o > > >allow multiplexing at this layer we are saying we allow carrying multi= ple > > >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label. > > > > > >While a label multiplex makes some sense for C-VLANs. (This is analogo= us > > >to the S-VLAN model). I'm struggling with a label multiplex of VLAN > > >multiplexors or in other words beyond C-VLAN. (I don't think people ar= e > > >suggesting we multiplex B-VLANs this way so I guess the questions is h= ow > > >far should we take this and why is this needed given the service level > > >already supports multiplexers ? > > > > > >Regards, > > >Don > > > > > >-----Original Message----- > > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of > > >David Allan I > > >Sent: Wednesday, November 07, 2012 4:40 PM > > >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.= org > > >Subject: RE: Vlan-aware bundling over VPLS > > > > > >Given in 802.1 standards there is IVL (independent VLAN learning) and = SVL > > >(shared VLAN learning), whether a MAC table exists per VID, per group = of > > >VIDs, or for all VIDs in a bundle in theory is an > > >implementation/operational choice. Or should be. > > > > > >SVL does permit MAC information gleaned from one VID's traffic to be u= sed > > >by another, which reduces the number of unknowns. OTOH if the VIDs > > >identify completely disjoint sets of endpoints there is no shared > > >information of consequence. > > > > > >Cheers > > >Dave > > > > > >-----Original Message----- > > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of > > >UTTARO, JAMES > > >Sent: Wednesday, November 07, 2012 1:23 PM > > >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org > > >Subject: RE: Vlan-aware bundling over VPLS > > > > > >+1.. > > > > > >Jim Uttaro > > > > > >-----Original Message----- > > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf= Of > > >Rogers, Josh > > >Sent: Wednesday, November 07, 2012 3:09 PM > > >To: Lucy yong; Giles Heron; l2vpn@ietf.org > > >Subject: Re: Vlan-aware bundling over VPLS > > > > > >[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the fil= ter. > > >The critical question for this scenario is if each VLAN has its own MA= C > > >space or not? > > > > > >Under the currently available VPLS method, the MAC table is shared for > > >the entire VPLS instance. This method is no different than a native > > >ethernet network using 802.1ad, I'm not concerned with 'isolating' the > > >mac table between vlans, but if I was I'd be inclined to use something > > >available (ie, multiple VPLS instances/multiple PW's, or PBB/PBT) > > > > > > > > >-Josh > > > > > > > > >On 11/7/12 2:02 PM, "Lucy yong" wrote: > > > > > >>Hi Josh, > > >> > > >>Thank you for the reply first. > > >> > > >>> -----Original Message----- > > >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com] > > >>> Sent: Wednesday, November 07, 2012 1:37 PM > > >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org > > >>> Subject: Re: Vlan-aware bundling over VPLS > > >>> > > >>> Regarding the trans-AS service scenario? > > >>[Lucy] I don't know, I post the question to know where it will be use= d. > > >> What we had previously > > >>> discussed/envisioned, and I've seen one other SP do, is buy a ELAN > > >>> type service from another operator (who delivered via VPLS). This > > >>> allowed them to put any VLAN they like on the ENNI, and deliver it = to > > >>> any endpoint on the VPLS instance. Since they own the equipment > > >>> (CPE) at each end, they simply allowed the vlan(s) they wanted to > > >>> deliver to that end point. > > >>> Since the VPLS instance is mac-learning, the only traffic that is > > >>> delivered that may be dropped by the CPE is BUM traffic. > > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE performs the > > >>filter. The critical question for this scenario is if each VLAN has i= ts > > >>own MAC space or not? > > >> > > >>Lucy > > >>> > > >>> I'm not certain I understand the question well. Does that answer i= t? > > >>> > > >>> -Josh > > >>> > > >>> > > >>> > > >>> On 11/7/12 1:32 PM, "Lucy yong" wrote: > > >>> > > >>> >I would like to add one more question to SP beside Giles's > > >>> > > > >>> >3) Does this service aspect mean whenever customer want to add a n= ew > > >>> VLAN > > >>> >(a BD) into the VPLS service, it has to inform the SP and SP has t= o > > >>> >provision this on PE? > > >>> > > > >>> >Thanks, > > >>> >Lucy > > >>> > > > >>> >> -----Original Message----- > > >>> >> From: Giles Heron [mailto:giles.heron@gmail.com] > > >>> >> Sent: Wednesday, November 07, 2012 8:55 AM > > >>> >> To: l2vpn@ietf.org > > >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > > >>> >> Subject: Re: Vlan-aware bundling over VPLS > > >>> >> > > >>> >> I'll leave the draft authors to comment on the points raised by > > >>> >> Himanshu and Lucy > > >>> >> > > >>> >> But I would like SPs to comment as to: > > >>> >> 1) whether VLAN-aware bundling is a requirement > > >>> >> 2) whether they require VLAN-aware bundling both for VPLS and > > >>> >> E-VPN > > >>> >> > > >>> >> Giles (chair hat firmly on). > > >>> >> > > >>> >> On 7 Nov 2012, at 14:13, Lucy yong wrote: > > >>> >> > > >>> >> > There is a trade-off on the solution. individual BD may have > > >>> >> different QoS requirement, multiplxing them together in a single > > >>> >> PW > > >>> may > > >>> >> lose some QoS and OAM capability. For example, when congestion > > >>> happens, > > >>> >> some BD may work and some may not, PW status is not able to refl= ex > > >>> that > > >>> >> properly. > > >>> >> > > > >>> >> > Lucy > > >>> >> > > > >>> >> >> -----Original Message----- > > >>> >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] = On > > >>> >> Behalf > > >>> >> >> Of Shah, Himanshu > > >>> >> >> Sent: Tuesday, November 06, 2012 2:04 PM > > >>> >> >> To: l2vpn@ietf.org > > >>> >> >> Subject: Vlan-aware bundling over VPLS > > >>> >> >> > > >>> >> >> clarification question: If vlan is the tag used for demux o= ver > > >>> >> single > > >>> >> >> PW and if that vlan needs to be advertised then what is the > > >>> saving? > > >>> >> Is > > >>> >> >> this just saving of the PW label? > > >>> >> >> Himanshu > > >>> >> >> > > >>> >> >> Sent from my iPad > > >>> > > > >>> > > >>> --_000_2691CE0099834E4A9C5044EEC662BB9D4482ED3Fdfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMO: when VM and NVE are = on co-located, i.e. both are on a server, the filtering implementation is i= nternal, no need to address in standard, and VM mobility will work just fun. When VM and NVE are remotely located, i.e. VM and NVE = are connected through a local physical network, then the filtering function= should not perform on the NVE, should be at the local network edge. Thus, = neither case requires VLAN-aware bundling on NVE. Vm-mobility-issue draft is orthogonal to the VLAN-aware b= undling request.

 <= /p>

Lucy  

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Friday, November 09, 2012 3:26 AM
To: Fedyk, Donald (Don)
Cc: l2vpn@ietf.org
Subject: RE: Vlan-aware bundling over VPLS

 


Hi Don,
The potential case in my mind is in datacenter. In the provider = L2VPN, the customer always has a CE switch which could do the VLAN filterin= g to ensure traffic separation between different customer VLANs. But in datacenter, if the network virtualization edge is in the hyp= ervisor, there is no switch to do VLAN filtering between NVE and VM, then t= he VM should do the traffic filtering for different VLAN. In VLAN-aware swi= tching, the traffic will be filtered at the ingress NVE, instead of VM.

For the VM moving case, it will be also useful if the VM's guest= OS would add VLAN:
1. VM adds a VLAN to traffic and have an tagged interface with v= irtual switch.
2. the virtual switch will be the edge of virtual L2 network.
3. when VM moves to another place, the VLAN-ID should not be cha= nged.
If VLAN-unaware is applied, the VLAN-ID maybe stripped by the ed= ge, and VLAN translation is required to configure on the virtual switch whe= n VM moving. While if VLAN-aware is applied, it ensures the same VLAN to be used at the domains traffic to/from VMs, and VM could = move across the domains freely without bothering the virtual switch.
The virtual L2 network could be E-VPN, or VPLS? I am not sure. B= ut for any virtual L2 network applied in NVO3, I think VLAN-aware has poten= tial use case. draft-rekhter-nvo3-vm-mobility-issues-03 describes the moving issue in section 3.1.

Thanks
Lizhong
 

"Fedyk, Donald (Don)" <donald.fedyk@alcatel-lucent.= com> wrote 2012/11/08 23:07:19:

> Hi Lizhong
>  
> The way I see it:
>  
> In the case of non VLAN aware you need to add a C-VLAN serv= ice to a new node:
> ·         You create the service= (local)
> ·         You add the access poi= nt (local)
> ·         You connect to the oth= er service (PWs setup , Signaled,  
> may be automated)
>  
> In the case of VLAN aware you need to add a C-VLAN service = to a new node:
> ·         You add the access poi= nt to a shared service (Local)
> ·         The service advertizes= the VLAN Vector to all other points
> (Signaled, automatic)
>  
> However if the Service you implement is an S-VLAN and you a= re adding
> a C-VLAN on a VLAN unaware VPLS :
> ·         You add the access poi= nt to a shared service (Local)
>  
>  
> We don’t need VLAN aware to get bundling.
>  
> Don
>  
>  
>  
>  
> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
> Sent: Thursday, November 08, 2012 6:26 AM
> To: l2vpn@ietf.org; bedard.phil@gmail.com; Fedyk, Donald (Don)
> Subject: Re: Vlan-aware bundling over VPLS
>  
>
> It would be potentially useful for VLAN-aware bundling in datacenter > (related with NVO3). If the virtualized L2 network could provide
> VLAN-aware bundling, the customer could manage its own VLAN domain, > otherwise one virtual network could only provide one broadcast
> domain. And the VM moving would be easier in a VLAN-aware
> virtualized L2 network if the packet VLAN is added by VM.
>
> Lizhong
>
>
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 07 Nov 2012 22:04:46 -0500
> > From: Phil Bedard <bedard.phil@gmail.com>
> > To: "Fedyk, Donald (Don)" <donald.fedyk@alcatel-luce= nt.com>,
> >    "l2vpn@ietf.org" <l2vpn@ietf.org> > > Subject: Re: Vlan-aware bundling over VPLS
> > Message-ID: <CCC066E0.64B29%bedard.phil@gmail.com>
> > Content-Type: text/plain;   charset=3D"US-ASCII" > >
> > Part of the draft is the multiplexing, the other part is dynamica= lly
> > creating bridge domains for each bundled VLAN and pruning the unn= ecessary
> > VLANs from remote PEs.
> >  
> >
> > I thought a bit more and here is a use case where this draft may = have been
> > useful.  We have a cell backhaul service delivered over VPLS= for a mobile
> > provider.  Each cell site (hundreds) are delivered to a sing= le aggregation
> > UNI, however there is a requirement for each cell site to belong = to its
> > own bridge domain.  This required creating a separate servic= e for each
> > cell site so the configuration on the aggregation node is substan= tial
> > since each service requires its own PW configuration (no A-D in u= se.)
> > With the mechanisms in this draft it would have required only cre= ating a
> > single service network-wide.  There may have been some OAM i= mplications to
> > this but I'd have to think that through.
> >
> > In some other instances it would not have worked because we use H= -VPLS
> > w/an MPLS U-PE.  The upstream N-PE would need a mechanism to= relay the
> > U-PE VLANs to other N-PEs, and potentially aggregate those from m= ultiple
> > U-PEs belonging to the same service. The N-PE would also have to = maintain
> > separate bridge domains itself. There is nothing in the draft cov= ering an
> > H-VPLS scenario which is fairly common.
> >  
> > We also create VLAN-unaware VPLS quite often since we do not want= to be
> > involved with adding/deleting customer VLANs and most customers d= o not
> > have an explicit requirement for their VLANs to be in separate br= idge
> > domains across the VPLS.  In reality most of them assume the= VPLS works
> > that way since most L2 switches do, but we haven't run into issue= s using a
> > shared MAC table.  
> >
> > Phil
> >
> >
> >
> > On 11/7/12 7:06 PM, "Fedyk, Donald (Don)"
> > <donald.fedyk@alcatel-lucent.com> wrote:
> >
> > >Hi
> > >
> > >I know Giles as for SP input and I'm not an SP but reading th= is thread
> > >I'm also not sure I that people are on the same page.
> > >
> > >When we look at Ethernet IEEE 802.1Q there is a C-VLAN, S-VLA= N, B-VLAN
> > >where the S-VLAN can multiplex C-VLANs  and the B-LAN en= capsulates and
> > >multiplexes S-VLANs (or also allowed C-VLANs).
> > >
> > >When we look at VPLS the MPLS Label can carry any one of the = above as a
> > >single VLAN (unaware). This inherently includes the above mul= tiplex. To
> > >allow multiplexing at this layer we are saying we allow carry= ing multiple
> > >VLANs (C-VLAN, S-VLAN, or B-VLAN) with a single label.
> > >
> > >While a label multiplex makes some sense for C-VLANs. (This i= s analogous
> > >to the S-VLAN model).  I'm struggling with a label multi= plex of VLAN
> > >multiplexors or in other words beyond C-VLAN. (I don't think = people are
> > >suggesting we multiplex B-VLANs this way so I guess the quest= ions is how
> > >far should we take this and why is this needed given the serv= ice level
> > >already supports multiplexers ?
> > >
> > >Regards,
> > >Don  
> > >
> > >-----Original Message-----
> > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] = On Behalf Of
> > >David Allan I
> > >Sent: Wednesday, November 07, 2012 4:40 PM
> > >To: UTTARO, JAMES; 'Rogers, Josh'; Lucy yong; Giles Heron; l2= vpn@ietf.org
> > >Subject: RE: Vlan-aware bundling over VPLS
> > >
> > >Given in 802.1 standards there is IVL (independent VLAN learn= ing) and SVL
> > >(shared VLAN learning), whether a MAC table exists per VID, p= er group of
> > >VIDs, or for all VIDs in a bundle in theory is an
> > >implementation/operational choice. Or should be.
> > >
> > >SVL does permit MAC information gleaned from one VID's traffi= c to be used
> > >by another, which reduces the number of unknowns. OTOH if the= VIDs
> > >identify completely disjoint sets of endpoints there is no sh= ared
> > >information of consequence.
> > >
> > >Cheers
> > >Dave
> > >
> > >-----Original Message-----
> > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] = On Behalf Of
> > >UTTARO, JAMES
> > >Sent: Wednesday, November 07, 2012 1:23 PM
> > >To: 'Rogers, Josh'; Lucy yong; Giles Heron; l2vpn@ietf.org > > >Subject: RE: Vlan-aware bundling over VPLS
> > >
> > >+1..
> > >
> > >Jim Uttaro
> > >
> > >-----Original Message-----
> > >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] = On Behalf Of
> > >Rogers, Josh
> > >Sent: Wednesday, November 07, 2012 3:09 PM
> > >To: Lucy yong; Giles Heron; l2vpn@ietf.org
> > >Subject: Re: Vlan-aware bundling over VPLS
> > >
> > >[Lucy] IMO: this is what all-to-one bundle offer. CPE perform= s the filter.
> > >The critical question for this scenario is if each VLAN has i= ts own MAC
> > >space or not?
> > >
> > >Under the currently available VPLS method, the MAC table is s= hared for
> > >the entire VPLS instance.  This method is no different t= han a native
> > >ethernet network using 802.1ad, I'm not concerned with 'isola= ting' the
> > >mac table between vlans, but if I was I'd be inclined to use = something
> > >available (ie, multiple VPLS instances/multiple PW's, or PBB/= PBT)
> > >
> > >
> > >-Josh
> > >
> > >
> > >On 11/7/12 2:02 PM, "Lucy yong" <lucy.yong@huawe= i.com> wrote:
> > >
> > >>Hi Josh,
> > >>
> > >>Thank you for the reply first.
> > >>
> > >>> -----Original Message-----
> > >>> From: Rogers, Josh [mailto:josh.rogers@twcable.com]<= br> > > >>> Sent: Wednesday, November 07, 2012 1:37 PM
> > >>> To: Lucy yong; Giles Heron; l2vpn@ietf.org
> > >>> Subject: Re: Vlan-aware bundling over VPLS
> > >>>
> > >>> Regarding the trans-AS service scenario?
> > >>[Lucy] I don't know, I post the question to know where it= will be used.
> > >> What we had previously
> > >>> discussed/envisioned, and I've seen one other SP do,= is buy a ELAN
> > >>> type service from another operator (who delivered vi= a VPLS).  This
> > >>> allowed them to put any VLAN they like on the ENNI, = and deliver it to
> > >>> any endpoint on the VPLS instance.  Since they = own the equipment
> > >>> (CPE) at each end, they simply allowed the vlan(s) t= hey wanted to
> > >>> deliver to that end point.
> > >>> Since the VPLS instance is mac-learning, the only tr= affic that is
> > >>> delivered that may be dropped by the CPE is BUM traf= fic.
> > >>[Lucy] IMO: this is what all-to-one bundle offer. CPE per= forms the
> > >>filter. The critical question for this scenario is if eac= h VLAN has its
> > >>own MAC space or not?
> > >>
> > >>Lucy
> > >>>
> > >>> I'm not certain I understand the question well. &nbs= p;Does that answer it?
> > >>>
> > >>> -Josh
> > >>>
> > >>>
> > >>>
> > >>> On 11/7/12 1:32 PM, "Lucy yong" <lucy.y= ong@huawei.com> wrote:
> > >>>
> > >>> >I would like to add one more question to SP besi= de Giles's
> > >>> >
> > >>> >3) Does this service aspect mean whenever custom= er want to add a new
> > >>> VLAN
> > >>> >(a BD) into the VPLS service, it has to inform t= he SP and SP has to
> > >>> >provision this on PE?
> > >>> >
> > >>> >Thanks,
> > >>> >Lucy
> > >>> >
> > >>> >> -----Original Message-----
> > >>> >> From: Giles Heron [mailto:giles.heron@gmail= .com]
> > >>> >> Sent: Wednesday, November 07, 2012 8:55 AM<= br> > > >>> >> To: l2vpn@ietf.org
> > >>> >> Cc: Himanshu Shah; Lucy yong; Nabil Bitar > > >>> >> Subject: Re: Vlan-aware bundling over VPLS<= br> > > >>> >>
> > >>> >> I'll leave the draft authors to comment on = the points raised by
> > >>> >> Himanshu and Lucy
> > >>> >>
> > >>> >> But I would like SPs to comment as to:
> > >>> >> 1) whether VLAN-aware bundling is a require= ment
> > >>> >> 2) whether they require VLAN-aware bundling= both for VPLS and
> > >>> >> E-VPN
> > >>> >>
> > >>> >> Giles (chair hat firmly on).
> > >>> >>
> > >>> >> On 7 Nov 2012, at 14:13, Lucy yong <lucy= .yong@huawei.com> wrote:
> > >>> >>
> > >>> >> > There is a trade-off on the solution. = individual BD may have
> > >>> >> different QoS requirement, multiplxing them= together in a single
> > >>> >> PW
> > >>> may
> > >>> >> lose some QoS and OAM capability. For examp= le, when congestion
> > >>> happens,
> > >>> >> some BD may work and some may not, PW statu= s is not able to reflex
> > >>> that
> > >>> >> properly.
> > >>> >> >
> > >>> >> > Lucy
> > >>> >> >
> > >>> >> >> -----Original Message-----
> > >>> >> >> From: l2vpn-bounces@ietf.org [mail= to:l2vpn-bounces@ietf.org] On
> > >>> >> Behalf
> > >>> >> >> Of Shah, Himanshu
> > >>> >> >> Sent: Tuesday, November 06, 2012 2= :04 PM
> > >>> >> >> To: l2vpn@ietf.org
> > >>> >> >> Subject: Vlan-aware bundling over = VPLS
> > >>> >> >>
> > >>> >> >> clarification question:   If = vlan is the tag used for demux over
> > >>> >> single
> > >>> >> >> PW and if that vlan needs to be ad= vertised then what is the
> > >>> saving?
> > >>> >> Is
> > >>> >> >> this just saving of the PW label?<= br> > > >>> >> >> Himanshu
> > >>> >> >>
> > >>> >> >> Sent from my iPad
> > >>> >
> > >>>
> > >>>

--_000_2691CE0099834E4A9C5044EEC662BB9D4482ED3Fdfweml505mbx_-- From lucy.yong@huawei.com Sun Nov 11 17:54:41 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2583A21F84B3 for ; Sun, 11 Nov 2012 17:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.408, 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 DeUY81vE-aSx for ; Sun, 11 Nov 2012 17:54:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A55B721F8496 for ; Sun, 11 Nov 2012 17:54:37 -0800 (PST) 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 ALK90700; Mon, 12 Nov 2012 01:54:36 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 01:54:31 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 01:54:35 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Sun, 11 Nov 2012 17:54:30 -0800 From: Lucy yong To: "Dennis Cai (dcai)" , "Fedyk, Donald (Don)" , Lizhong Jin , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS - add use case Thread-Topic: Vlan-aware bundling over VPLS - add use case Thread-Index: Ac3AcMnL5NU8a0UeQQGzGm0rzaKZSwABNktA Date: Mon, 12 Nov 2012 01:54:29 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482ED61@dfweml505-mbx> References: <623637051A3DC34E80FC9BA35B4629950F6326D4@xmb-rcd-x05.cisco.com> In-Reply-To: <623637051A3DC34E80FC9BA35B4629950F6326D4@xmb-rcd-x05.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.163.56] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4482ED61dfweml505mbx_" 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: Mon, 12 Nov 2012 01:54:41 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4482ED61dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dennis, Please see inline. From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of D= ennis Cai (dcai) Sent: Sunday, November 11, 2012 7:01 PM To: Fedyk, Donald (Don); Lizhong Jin; l2vpn@ietf.org Subject: RE: Vlan-aware bundling over VPLS - add use case Hi, all, I'm the co-author for this draft. I saw lots of interesting discussion and = points. I want to share some thoughts and use cases behind this draft The original use case is enterprise Data Center interconnect using VPLS. Th= e main motivation is for "user simplicity" which is very important in enter= prise space. Although this concept could also be applied to SP DCI as well,= or other SP applications potentially Think about enterprise customers who have multiple DC sites, and have hundr= eds of VLANs across DC sites, what will be the solution and configurations?= The solution today is to use one VPLS instance per VLAN. This gives huge c= onfiguration, and introduce many PWs unnecessarily. QinQ is not an option h= ere because it doesn't create separate broadcast domain per VLAN. It may ru= n into duplicated MAC issues [Lucy] I heard that SP and enterprise customer use QinQ approach to achieve= "the simplify", and guess the enterprise DC has only one MAC address space= to deal with. Is that right? Thus, "all to one bundle" meet the request an= d let enterprise DC sites create separate broadcast domain per VLAN. When u= sing VLAN interconnect the sites together, VPLS merges the broadcast domain= into one over WAN network only, but not at the enterprise site. If all VLA= Ns use the same MAC space, I don't see much benefit for "user simplicity" b= y using VLAN-aware-bundling. It may save some bandwidth for SP WAN network = but make PE less scale. Yes, as some of you already pointed out, the function in vlan-aware vpls h= as already been covered by PBB-VPLS. In fact, you can even treat this as a = "simplified" pbb-vpls to help understand this draft. On the other hand, we = didn't see much adoption of pbb-vpls in enterprise (but people in this alia= s can make comment). Pbb-vpls is considered complex (such as flooding packe= t pruning, MAC flushing, etc) and inefficient (big header) technology for e= nterprise DCI deployment. [Lucy] PBB-VPLS is another option to achieve this. With VLAN-aware VPLS, we just use VLAN for service multiplexer, which can b= e used for flooding packet pruning, and per-VLAN MAC flushing. This is much= simple approach and doesn't introduce additional overhead. With platform i= mplementation, the bridge-domain could be created implicitly, so user is ev= en not aware of this. Per-bridge domain feature can still work as usual if = it's required. In short, it use same qinq over vpls configuration (simple and scalable) fr= om end user point of view. However, it create separated bridge-domain per V= LAN for true separation. Then it multiplex VLANs into same VPLS instance/PW= to reduce the control planning overhead [Lucy] As I mentioned in previous e-mail, there are treat-offs in supportin= g this service interface in VPLS. I am not yet convinced if we should work = on this service interface and hope see a concrete use case of it. Regards, Lucy Thanks Dennis --_000_2691CE0099834E4A9C5044EEC662BB9D4482ED61dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dennis,

 <= /p>

Please see inline.

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Dennis Cai (dcai)
Sent: Sunday, November 11, 2012 7:01 PM
To: Fedyk, Donald (Don); Lizhong Jin; l2vpn@ietf.org
Subject: RE: Vlan-aware bundling over VPLS - add use case=

 

Hi, all,

 <= /p>

I’m the co-author f= or this draft. I saw lots of interesting discussion and points. I want to s= hare some thoughts and use cases behind this draft

 <= /p>

The original use case is = enterprise Data Center interconnect using VPLS. The main motivation is for = “user simplicity” which is very important in enterprise space. Although this concept could also be applied to SP DCI as well, = ; or other SP applications potentially

 <= /p>

Think about enterprise cu= stomers who have multiple DC sites, and have hundreds of VLANs across DC si= tes, what will be the solution and configurations? The solution today is to use one VPLS instance per VLAN. This gives huge configuration,= and introduce many PWs unnecessarily. QinQ is not an option here because i= t doesn’t create separate broadcast domain per VLAN. It may run = into duplicated MAC issues

[Lucy] I heard that= SP and enterprise customer use QinQ approach to achieve “the simplif= y”, and guess the enterprise DC has only one MAC address space to deal with. Is that right? Thus, “all to one bundle” meet th= e request and let enterprise DC sites create separate broadcast domain per = VLAN. When using VLAN interconnect the sites together, VPLS merges the broa= dcast domain into one over WAN network only, but not at the enterprise site. If all VLANs use the same MAC space, I don= ’t see much benefit for “user simplicity” by using VLAN-a= ware-bundling. It may save some bandwidth for SP WAN network but make PE le= ss scale.

 <= /p>

 <= /p>

Yes, as some of you alrea= dy pointed out, the function  in vlan-aware vpls has already been cove= red by PBB-VPLS. In fact, you can even treat this as a “simplified= 221; pbb-vpls to help understand this draft. On the other hand, we didn’t= see much adoption of pbb-vpls in enterprise (but people in this alias can = make comment). Pbb-vpls is considered complex (such as flooding packet prun= ing, MAC flushing, etc) and inefficient (big header) technology for enterprise DCI deployment.  

[Lucy] PBB-VPLS is = another option to achieve this.

 <= /p>

With VLAN-aware VPLS, we = just use VLAN for service multiplexer, which can be used for flooding packe= t pruning, and per-VLAN MAC flushing. This is much simple approach and doesn’t introduce additional overhead. With platform im= plementation, the bridge-domain could be created implicitly, so user is eve= n not aware of this. Per-bridge domain feature can still work as usual if i= t’s required.

 <= /p>

In short, it use same qin= q over vpls configuration (simple and scalable) from end user point of view= . However, it create separated bridge-domain per VLAN for true separation. Then it multiplex VLANs into same VPLS instance/PW to red= uce the control planning overhead

[Lucy] As I mention= ed in previous e-mail, there are treat-offs in supporting this service inte= rface in VPLS. I am not yet convinced if we should work on this service interface and hope see a concrete use case of it.

 

Regards,=

Lucy=

 <= /p>

Thanks
Dennis

 <= /p>

 <= /p>

 <= /p>

--_000_2691CE0099834E4A9C5044EEC662BB9D4482ED61dfweml505mbx_-- From dcai@cisco.com Sun Nov 11 19:24: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 CB7FD21F8425 for ; Sun, 11 Nov 2012 19:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPfnuXtMqU4X for ; Sun, 11 Nov 2012 19:24:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 99B2C21F8484 for ; Sun, 11 Nov 2012 19:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18707; q=dns/txt; s=iport; t=1352690664; x=1353900264; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+7gm0AqTZE5+6kJPqR7vEmMADqAP7qldewu9MiuJ0W4=; b=e93q47JvixIy0TO0HLUWyWOmjLwrfXBWs3/qXL5o3J5WC2X/VbBKkIIR yvJSfpfVHdBQmTEIYPomGSX7lweRPp44nJyx8HtTQN4MGmmQvAxgK/MJY ICobO8SVABcMvcy/I3cOun0l7g8VoZa9xqQGwcC2qr3EIC6K1v5pUOmwb 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPhqoFCtJV2b/2dsb2JhbABEgknBCoEIgh4BAQEEEgEaXAIBCBEEAQELHQcyFAkIAQEEARIIEweHaJtYnweMFRqFT2EDpFSBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="141169746" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 12 Nov 2012 03:24:23 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAC3ONW6013726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 03:24:23 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.88]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Sun, 11 Nov 2012 21:24:23 -0600 From: "Dennis Cai (dcai)" To: Lucy yong , "Fedyk, Donald (Don)" , Lizhong Jin , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS - add use case Thread-Topic: Vlan-aware bundling over VPLS - add use case Thread-Index: Ac3AcMnL5NU8a0UeQQGzGm0rzaKZSwABNktAAAH9QTA= Date: Mon, 12 Nov 2012 03:24:22 +0000 Message-ID: <623637051A3DC34E80FC9BA35B4629950F632B7E@xmb-rcd-x05.cisco.com> References: <623637051A3DC34E80FC9BA35B4629950F6326D4@xmb-rcd-x05.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4482ED61@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4482ED61@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19354.005 x-tm-as-result: No--41.774600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_623637051A3DC34E80FC9BA35B4629950F632B7Exmbrcdx05ciscoc_" MIME-Version: 1.0 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, 12 Nov 2012 03:24:27 -0000 --_000_623637051A3DC34E80FC9BA35B4629950F632B7Exmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Lucy, Comments inline From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Sunday, November 11, 2012 8:54 PM To: Dennis Cai (dcai); Fedyk, Donald (Don); Lizhong Jin; l2vpn@ietf.org Subject: RE: Vlan-aware bundling over VPLS - add use case Hi Dennis, Please see inline. From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Dennis Cai (dcai) Sent: Sunday, November 11, 2012 7:01 PM To: Fedyk, Donald (Don); Lizhong Jin; l2vpn@ietf.org Subject: RE: Vlan-aware bundling over VPLS - add use case Hi, all, I'm the co-author for this draft. I saw lots of interesting discussion and = points. I want to share some thoughts and use cases behind this draft The original use case is enterprise Data Center interconnect using VPLS. Th= e main motivation is for "user simplicity" which is very important in enter= prise space. Although this concept could also be applied to SP DCI as well,= or other SP applications potentially Think about enterprise customers who have multiple DC sites, and have hundr= eds of VLANs across DC sites, what will be the solution and configurations?= The solution today is to use one VPLS instance per VLAN. This gives huge c= onfiguration, and introduce many PWs unnecessarily. QinQ is not an option h= ere because it doesn't create separate broadcast domain per VLAN. It may ru= n into duplicated MAC issues [Lucy] I heard that SP and enterprise customer use QinQ approach to achieve= "the simplify", and guess the enterprise DC has only one MAC address space= to deal with. Is that right? Thus, "all to one bundle" meet the request an= d let enterprise DC sites create separate broadcast domain per VLAN. When u= sing VLAN interconnect the sites together, VPLS merges the broadcast domain= into one over WAN network only, but not at the enterprise site. If all VLA= Ns use the same MAC space, I don't see much benefit for "user simplicity" b= y using VLAN-aware-bundling. It may save some bandwidth for SP WAN network = but make PE less scale. [dennis] even for enterprise DC, it could have duplicated MAC address acros= s different VLANs due to some virtual MAC address such as FW, load balancin= g, or even with VMs. The feedback of what we got is to prefer "separated" b= roadcast domain per VLAN to reduce the risk of the duplicated MAC address. = So normal qinq may not meet the requirement here. However, enterprise custo= mer does prefer the simplicity of the qinq over VPLS. Yes, as some of you already pointed out, the function in vlan-aware vpls h= as already been covered by PBB-VPLS. In fact, you can even treat this as a = "simplified" pbb-vpls to help understand this draft. On the other hand, we = didn't see much adoption of pbb-vpls in enterprise (but people in this alia= s can make comment). Pbb-vpls is considered complex (such as flooding packe= t pruning, MAC flushing, etc) and inefficient (big header) technology for e= nterprise DCI deployment. [Lucy] PBB-VPLS is another option to achieve this. [dcai] fully agree! Although PBB-VPLS can meet the full requirement, but it= 's considered as overkilled or too complex in enterprise space With VLAN-aware VPLS, we just use VLAN for service multiplexer, which can b= e used for flooding packet pruning, and per-VLAN MAC flushing. This is much= simple approach and doesn't introduce additional overhead. With platform i= mplementation, the bridge-domain could be created implicitly, so user is ev= en not aware of this. Per-bridge domain feature can still work as usual if = it's required. In short, it use same qinq over vpls configuration (simple and scalable) fr= om end user point of view. However, it create separated bridge-domain per V= LAN for true separation. Then it multiplex VLANs into same VPLS instance/PW= to reduce the control planning overhead [Lucy] As I mentioned in previous e-mail, there are treat-offs in supportin= g this service interface in VPLS. I am not yet convinced if we should work = on this service interface and hope see a concrete use case of it. [dcai] as I mentioned, the original use case is for enterprise DCI. The mai= n motivation is for user operational simplicity Regards, Lucy Thanks Dennis --_000_623637051A3DC34E80FC9BA35B4629950F632B7Exmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Lucy,

 <= /p>

Comments inline

 <= /p>

From: Lucy yon= g [mailto:lucy.yong@huawei.com]
Sent: Sunday, November 11, 2012 8:54 PM
To: Dennis Cai (dcai); Fedyk, Donald (Don); Lizhong Jin; l2vpn@ietf.= org
Subject: RE: Vlan-aware bundling over VPLS - add use case=

 

Hi Dennis,

 <= /p>

Please see inline.

 <= /p>

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Dennis Cai (dcai)
Sent: Sunday, November 11, 2012 7:01 PM
To: Fedyk, Donald (Don); Lizhong Jin; l2vpn@ietf.org
Subject: RE: Vlan-aware bundling over VPLS - add use case=

 

Hi, all,

 <= /p>

I’m the co-author f= or this draft. I saw lots of interesting discussion and points. I want to s= hare some thoughts and use cases behind this draft

 <= /p>

The original use case is = enterprise Data Center interconnect using VPLS. The main motivation is for = “user simplicity” which is very important in enterprise space. Although this concept could also be applied to SP DCI as well, = ; or other SP applications potentially

 <= /p>

Think about enterprise cu= stomers who have multiple DC sites, and have hundreds of VLANs across DC si= tes, what will be the solution and configurations? The solution today is to use one VPLS instance per VLAN. This gives huge configuration,= and introduce many PWs unnecessarily. QinQ is not an option here because i= t doesn’t create separate broadcast domain per VLAN. It may run = into duplicated MAC issues

[Lucy] I heard that= SP and enterprise customer use QinQ approach to achieve “the simplif= y”, and guess the enterprise DC has only one MAC address space to deal with. Is that right? Thus, “all to one bundle” meet th= e request and let enterprise DC sites create separate broadcast domain per = VLAN. When using VLAN interconnect the sites together, VPLS merges the broa= dcast domain into one over WAN network only, but not at the enterprise site. If all VLANs use the same MAC space, I don= ’t see much benefit for “user simplicity” by using VLAN-a= ware-bundling. It may save some bandwidth for SP WAN network but make PE le= ss scale.

[dennis] even for enterprise = DC, it could have duplicated MAC address across different VLANs due to some= virtual MAC address such as FW, load balancing, or even with VMs. The feedback of what we got is to prefer “separated”= broadcast domain per VLAN to reduce the risk of the duplicated MAC address= . So normal qinq may not meet the requirement here. However, enterprise cus= tomer does prefer the simplicity of the qinq over VPLS.

 <= /p>

Yes, as some of you alrea= dy pointed out, the function  in vlan-aware vpls has already been cove= red by PBB-VPLS. In fact, you can even treat this as a “simplified= 221; pbb-vpls to help understand this draft. On the other hand, we didn’t= see much adoption of pbb-vpls in enterprise (but people in this alias can = make comment). Pbb-vpls is considered complex (such as flooding packet prun= ing, MAC flushing, etc) and inefficient (big header) technology for enterprise DCI deployment.  

[Lucy] PBB-VPLS is = another option to achieve this.

[dcai] fully agree! Although PBB-VPLS can meet the full requireme= nt, but it’s considered as overkilled or too complex in enterprise sp= ace

 <= /p>

With VLAN-aware VPLS, we = just use VLAN for service multiplexer, which can be used for flooding packe= t pruning, and per-VLAN MAC flushing. This is much simple approach and doesn’t introduce additional overhead. With platform im= plementation, the bridge-domain could be created implicitly, so user is eve= n not aware of this. Per-bridge domain feature can still work as usual if i= t’s required.

 <= /p>

In short, it use same qin= q over vpls configuration (simple and scalable) from end user point of view= . However, it create separated bridge-domain per VLAN for true separation. Then it multiplex VLANs into same VPLS instance/PW to red= uce the control planning overhead

[Lucy] As I mention= ed in previous e-mail, there are treat-offs in supporting this service inte= rface in VPLS. I am not yet convinced if we should work on this service interface and hope see a concrete use case of it.

[dcai] as I mentioned, = the original use case is for enterprise DCI. The main motivation is for use= r operational simplicity

 

Regards,=

Lucy=

 <= /p>

Thanks
Dennis

 <= /p>

 <= /p>

 <= /p>

--_000_623637051A3DC34E80FC9BA35B4629950F632B7Exmbrcdx05ciscoc_-- From lucy.yong@huawei.com Mon Nov 12 07: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 CCE8121F85AF for ; Mon, 12 Nov 2012 07:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.386, 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 xNFERfE1a4ta for ; Mon, 12 Nov 2012 07:02:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF12D21F85AC for ; Mon, 12 Nov 2012 07:02:36 -0800 (PST) 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 AMR44606; Mon, 12 Nov 2012 15:02: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; Mon, 12 Nov 2012 15:02:04 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 15:02:09 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 12 Nov 2012 07:02:05 -0800 From: Lucy yong To: "Dennis Cai (dcai)" , "Fedyk, Donald (Don)" , Lizhong Jin , "l2vpn@ietf.org" Subject: RE: Vlan-aware bundling over VPLS - add use case Thread-Topic: Vlan-aware bundling over VPLS - add use case Thread-Index: Ac3AcMnL5NU8a0UeQQGzGm0rzaKZSwABNktAAAH9QTAAGfNM0A== Date: Mon, 12 Nov 2012 15:02:03 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4482EEA1@dfweml505-mbx> References: <623637051A3DC34E80FC9BA35B4629950F6326D4@xmb-rcd-x05.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4482ED61@dfweml505-mbx> <623637051A3DC34E80FC9BA35B4629950F632B7E@xmb-rcd-x05.cisco.com> In-Reply-To: <623637051A3DC34E80FC9BA35B4629950F632B7E@xmb-rcd-x05.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.80.50] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4482EEA1dfweml505mbx_" 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: Mon, 12 Nov 2012 15:02:37 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4482EEA1dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dennis, Snip.. In short, it use same qinq over vpls configuration (simple and scalable) fr= om end user point of view. However, it create separated bridge-domain per V= LAN for true separation. Then it multiplex VLANs into same VPLS instance/PW= to reduce the control planning overhead [Lucy] As I mentioned in previous e-mail, there are treat-offs in supportin= g this service interface in VPLS. I am not yet convinced if we should work = on this service interface and hope see a concrete use case of it. [dcai] as I mentioned, the original use case is for enterprise DCI. The mai= n motivation is for user operational simplicity [Lucy1] If a customer knows these tread-offs on the VPLS service, they may= think that PBB-VPLS is the right way to do in supporting different MAC spa= ces in each broadcast domain. IMO: supporting multiple mcast domain under o= ne MAC address space or supporting separated MAC address space in each broa= dcast domain are two distinct requirements. NVO3 is about the latter. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D4482EEA1dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dennis,

 <= /p>

Snip..<= /p>

 <= /p>

In short, it use same qin= q over vpls configuration (simple and scalable) from end user point of view= . However, it create separated bridge-domain per VLAN for true separation. Then it multiplex VLANs into same VPLS instance/PW to red= uce the control planning overhead

[Lucy] As I mention= ed in previous e-mail, there are treat-offs in supporting this service inte= rface in VPLS. I am not yet convinced if we should work on this service interface and hope see a concrete use case of it.

[dcai] as I mentioned, = the original use case is for enterprise DCI. The main motivation is for use= r operational simplicity

  

[Lucy1]  If a = customer knows these tread-offs on the VPLS service, they may think that PB= B-VPLS is the right way to do in supporting different MAC spaces in each broadcast domain. IMO: supporting multiple mcast domain under one = MAC address space or supporting separated MAC address space in each broadca= st domain are two distinct requirements. NVO3 is about the latter.

 

Lucy=

--_000_2691CE0099834E4A9C5044EEC662BB9D4482EEA1dfweml505mbx_-- From sajassi@cisco.com Wed Nov 14 10:26: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 09C9421F8769 for ; Wed, 14 Nov 2012 10:26:56 -0800 (PST) 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 FWToIGolgr41 for ; Wed, 14 Nov 2012 10:26:55 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C67ED21F86A9 for ; Wed, 14 Nov 2012 10:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7883; q=dns/txt; s=iport; t=1352917614; x=1354127214; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=e+oYek0Vvv1EZp6D5fnYz224nnQ4aQwb+PcpPnuF5BY=; b=TmkO7Qh9BYFU6+UU+Va0vnTKwnJM5bEaSSmFO+BmYTt5+ZrBIY12ZD8Q cUh2CWthnRgv7qEJ+f3PgHN+JHk4WGyjgN2ueNoHMkvs4jTYtPy3j8su8 DD0viatakjiwePlGZknh7cdB5Wi7ZXbVBZhjMDwHQETUIvjVPZOx5p8Mh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPjho1CtJV2d/2dsb2JhbABEgmzATIEIgh4BAQEEEgEKHSsIHgEIEQMBAgsUMREdCAIEARIIEweHVgMPAQqbJJY0DYlUi0RphUthA5JKgV2CcYoWgyaBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142394550" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2012 18:26:54 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAEIQshJ004134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 18:26:54 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 12:26:53 -0600 From: "Ali Sajassi (sajassi)" To: Jiangyuanlong , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfpoeCA Date: Wed, 14 Nov 2012 18:26:53 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7A2EF9@xmb-aln-x13.cisco.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D482286@szxeml546-mbx.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: [64.101.1.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--60.831400-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 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, 14 Nov 2012 18:26:56 -0000 Hi Yaunlong, Thanks for your comments. Please refer to my reply in line ... On 10/26/12 7:18 PM, "Jiangyuanlong" wrote: >Hi authors of draft-ietf-l2vpn-evpn-req-01 and all, > >I had a review of this document, and believe that some issues still need >to be resolved. > >Some technical comments: >1. In Section 4.1, it says: > "....This being the case, the first requirement for > active/active multi-homing is the ability to accommodate flexible > flow-based load-balancing from the CE node based on L2, L3 and/or L4 > header fields. > > A solution MUST be capable of supporting flexible flow-based load > balancing from the CE as described above." > =20 >I am not sure the current E-VPN framework can support CE load-balancing >based on L3 and/or L4 header fields. For example, if the frames with the >same MAC address are load-balanced on multiple PEs in a multi-homed >group, the remote PEs need to support sub-MAC flow-based forwarding, >furthermore, BGP signaling also needs substantial extensions to support >it. All these will pose a great challenge to EVPN. This is a data-plane function and has nothing to do with the control-plane BGP. Currently majority of LACP implementation do perform load balancing among member links using L3 and/or L4 headers besides MAC addresses. On the remote PE, when multiple adjacencies exist for the same MAC route, the PE can hash based on L2/L3/L4 header to pick one of those adjacencies. This also has nothing to do with the BGP control plane. > >2. At the end of Section 4.4, it says: >" > A multi-homed group (also known as a multi-chassis LACP group) is a > group of PEs supporting a multi-homed CE. >" >and in Section 4.5, it says: >" In order to simplify service provisioning and activation, the multi- > homing mechanism SHOULD allow arbitrary grouping of PE nodes into > redundancy groups where each redundancy group represents all multi- > homed groups that share the same group of PEs. This is best explained > with an example: consider three PE nodes - PE1, PE2 and PE3. >" >It seems a formal definition of redundancy group is needed (IMO, "each >redundancy group represents all multi-homed groups that share the same >group of PEs" is a little confusing), and multi-homed group is also not >clearly defined IMO (it seems a specific PE should be designated as DF in >multi-homed group while redundancy group is just a set of PEs according >to the EVPN framework). I think the text is very clear regarding multi-homed group and redundancy group and both of them are defined in the text. Section 4.4 defines multi-homed group by saying: "A multi-homed group (also known as a multi-chassis LACP group) is a group of PEs supporting a multi-homed CE" and section 4.5 defines redundancy group by saying: "each redundancy group represents all multi- homed groups that share the same group of Pes". If you think the definitions can be made better, please provide the text. >=20 > =20 >3. At the end of Section 6, it says: >" - Implementations SHOULD revert to using default values for > parameters as and where applicable. >" >It seems like a rule of thumb to use some default values for any >implementation or protocol design, do we really need to list this as an >EVPN requirement? Yes. > >4. In Section 10, it says: >" > A solution MUST be capable of supporting flexible VPN topologies that > are not constrained by the underlying mechanisms of the solution. >" >Not sure how can we determine the fulfillment of this mandatory >requirement? Hopefully after the discussion that we had on evpn-etree, it is now clear on how to fulfill this requirement. > >5. In Section 11, it says: >" > For scenarios where MAC learning is performed in data-plane, there > are no additional security aspects beyond those considered in > [RFC4761] and [RFC4762]. And for scenarios where MAC learning is > performed in control plane (via BGP), there are no additional > security aspects beyond those considered in [RFC4364]. >" >However, there is no description of "MAC learning" in the requirement >doc, so why it is discussed in the security section? It is proposed >either we remove these discussions, or refer to draft-ietf-l2vpn-evpn in >the first place (where it dwells in). This requirement doc is supposed to cover both E-VPN and PBB-EVPN. PBB-EVPN performs the MAC learning in data-plane. > >Some minor comments: >1. Section 2, s/for e.g./e.g.,/ >2. At the end of Section 2, all the section numbers referred to are in >disorder. >3. Section 3, the Terminology section is in a mess, and re-formatting is >needed. >4. Section 4.1, s/IGP ECMP paths/ECMP paths/, as E-VPN may well cross >multi-AS. >5. Section 4.2,=20 > s/For instance/For instance,/ >6. Section 4.2,=20 > s/between those LSPs/among those LSPs/ >7. In Section 4.2, it says: > "Similarly if LDP is being used as the transport LSP protocol, > then the solution MUST be able to leverage LDP ECMP capabilities." >1) s/transport LSP protocol/signaling protocol for transport LSPs/ >2) s/leverage LDP ECMP capabilities/leverage those LDP signaled equal >cost LSPs/, since "LDP ECMP capabilities" are somewhat ambiguous. > >8. In Section 4.2, it says: > "The solution MUST also be able to leverage work in the MPLS WG that is >in > progress to improve the load balancing capabilities of the network > based on entropy labels." =09 > It seems a reference to draft-ietf-mpls-entropy-label is needed. > =20 >9. In Section 4.3, > s/from cost standpoint/from a cost standpoint/ > s/the pair of PEs/multiple PEs/ or s/multi-homed/dual-homed/ > =20 >10. In Section 4.4, >s/multi-chassis LACP group/multi-chassis LAG/, since LACP is only the >control protocol for the LAG. Agreed to all. > >11. Section 4.6, >s/participate in the control/participate in the resiliency/, since G.8032 >is usually not regarded as a control protocol. G.8032 is considered as control protocol. > >12. Section 5, >1) What is the advantage of MP2MP LSP? Maybe an example or a reference >could be provided to justify it. >2) s/uncast/unicast/ > >13. Section 6, >1) s/MUST be maintained/MUST be maintained./ >2) s/on the access circuit/for the access circuit/ Agreed to all. > >14. Section 8, >s/the attachment circuit or PE/an attachment circuit or a PE/ Changed to the attachment circuit or the PE. > >15. Section 9, it says: >" ...it is required to minimize the flooding of broadcast > frames outside the confines of a given site. Of particular interest > is periodic ARP traffic. >" >Why periodic ARP traffic is of particular interest? it seems to me just >an example. Because that can constitutes the majority of the flood traffic. > >16. Section 10,=20 >s/with other roots/with roots/ Other roots is o.k. > >17. Section 13,=20 >1) For [802.1Q], it seems IEEE Std 802.1Q-2011 is the latest revision. >2) Two redundant references for [VPLS-MCAST] are included in this >section, it is proposed that the 1st should be removed. Done. > >Regards, >Yuanlong > >------------------------------ >Date: Fri, 19 Oct 2012 23:34:53 +0100 >From: Giles Heron >To: "l2vpn@ietf.org" >Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >Content-Type: text/plain; charset=3Dus-ascii > >This email initiates an L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 > >please comment to the list as to the suitability of this draft for >publication as a Standards Track RFC from the L2VPN WG. > >this last call will close on Friday 2nd November. > >Nabil & Giles=20 From sajassi@cisco.com Wed Nov 14 11:23: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 4A17021F87DE for ; Wed, 14 Nov 2012 11:23:02 -0800 (PST) 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 hd0gishU3tZW for ; Wed, 14 Nov 2012 11:23:01 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3243421F8769 for ; Wed, 14 Nov 2012 11:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7069; q=dns/txt; s=iport; t=1352920981; x=1354130581; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hwArSuz72hLuMsH+DNsPk2hn6/HM7vWFGZId3Gl+RxQ=; b=EXWrzq+b+HGjg9TAkmG4cWrZexcvNSr2XnJKj8qAP+DspZHgPuzANVM0 Vxc1gzvH/e3fLxcLmm+QCpTN11ixP7/vGJ0eRzce/h7JGMXFiqJgJ983k cmk5rD9Ggk9Mu3JJJPlnhubktz64S5SMn22fuT3knA8nj27D2sm71gRiF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAHvo1CtJXHB/2dsb2JhbABEgmzAT4EIgh4BAQEEDgQBCh0rIAYBCBEDAQEBAQoUCSgRFAkIAgQBEggTB4dWAw8BCpseljMNiVSLRGmFS2EDlCeCcYoWgyaBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142414907" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2012 19:23:00 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAEJN0r2007483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 19:23:00 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.0318.001; Wed, 14 Nov 2012 13:23:00 -0600 From: "Ali Sajassi (sajassi)" To: "Henderickx, Wim (Wim)" , Lucy yong , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACPdACAAE/VAIAAfFoAgABmAACAAAFxAIAAT1SAgAAAfICADYO2gA== Date: Wed, 14 Nov 2012 19:23:00 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> 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: [64.101.1.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--54.975400-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: <728DB3070EF8374BB520B6DDF78074D9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 14 Nov 2012 19:23:02 -0000 Wim, Lucy: I think we are all set. Going through your emails, we can conclude the following comment resolutions: On 11/4/12 11:40 AM, "Lucy yong" wrote: >1) in section 4.3, Text: The latter scenario often means that requiring a >dedicated > link between the PEs, for the operation of the multi-homing mechanism, >is not appealing from cost standpoint. > >Comment: a dedicated link between PEs. will this link is in IGP link too? >or private link. >May PE nodes that are multi-homed to a same CE be different ASes? If yes, >state it out. > Resolution: no change to the text. The draft states that having such a dedicated link (which is not an IGP link) is not desirable and thus cannot be assumed that such link exist. >2) in section 4.6, the last paragraph should state a requirement for flow >based load balance. > Resolution: Agreed, we add flow-based LB to the text. >3) It should add one requirement in supporting Ethernet L2VPN across >multi-ASes > Resolution: Agreed, we'll add that. >4) As the draft mentioned, the new service interfaces are required for DC >interconnection. If DC uses NVo3 in future, will these service interfaces >are still necessary? Suggest giving some use cases where the new service >interfaces are necessary in an appendix. > > Resolution: No change, as clarified in the email thread. Cheers, Ali On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" wrote: >Lucy, sure and this evolution into MEF is most likely to come, but I >believe it is a clear req for EVPN, so I believe we can close this point > >On 05/11/12 15:58, "Lucy yong" wrote: > >>Wim, >> >>I agree that we (IETF) don't have make ourselves dependent on MEF. >>However, there are a lot of service providers in MEF to specify Ethernet >>services and service interfaces. Such service interface has not yet to >>bring on the table there. This may be because the people in two SDOs may >>be from different orgs.. >> >>Thanks, >>Lucy >> >>> -----Original Message----- >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >>> Sent: Monday, November 05, 2012 10:15 AM >>> To: Lucy yong; l2vpn@ietf.org >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >>>=20 >>> -- Snip -- >>>=20 >>> [Lucy] OK. Maybe I did not follow the early requirement discussions. >>> Where >>> was this requirement coming from. MEF Services do not support such >>> service >>> interface. Was this from some operators in IETF? I just like to know a >>> use >>> case if possible. >>>=20 >>>=20 >>> WH> yes this is from operators of which some are on the co-author list. >>> The driver for this is more optimised and scalable implementations. MEF >>> might adopt this going fwd, so we should not make ourselves dependent >>> on >>> MEF >>>=20 >>> -- Snip -- >>>=20 >>> On 05/11/12 11:09, "Lucy yong" wrote: >>>=20 >>> > >>> > >>> >snip >>> >> >[Lucy] My second question is if PE nodes that are multi-homed to a >>> >> same >>> >> >CE may be in different ASes in latter case? Whether yes, or no, it >>> >> should >>> >> >state it out. >>> >> >>> >> WH2> this seems like an odd scenario >>> >[Lucy] agree. >>> >> > >>> >> >> > >>> >> >> >2) in section 4.6, the last paragraph should state a requirement >>> >> for >>> >> >> flow >>> >> >> >based load balance. >>> >> >> >>> >> >> WH> are you saying the Mac based load-balancing is a MUST or are >>> you >>> >> >> saying the MAC based load-balancing should be flow based >>> >> >[Lucy] Text: A solution MAY support multi-homed network with >>> >> >active/active MAC- >>> >> > based load balancing (i.e. different MAC addresses on a VLAN are >>> >> > reachable via different PEs). >>> >> > >>> >> >In section 4.1, it describes options for flow-based load balancing, >>> >> that >>> >> >should apply to here, right? >>> >> >That means the same MAC address may occur on the different PEs too. >>> >> WH2> yes >>> >> > >>> >> >> > >>> >> >> >3) It should add one requirement in supporting Ethernet L2VPN >>> >> across >>> >> >> >multi-Ases >>> >> >> >>> >> >> WH> agreed >>> >> >> > >>> >> >> >4) As the draft mentioned, the new service interfaces are >>> required >>> >> for >>> >> >> DC >>> >> >> >interconnection. If DC uses NVo3 in future, will these service >>> >> >> interfaces >>> >> >> >are still necessary? Suggest giving some use cases where the new >>> >> >> service >>> >> >> >interfaces are necessary in an appendix. >>> >> >> WH> it depends on what use case we have in NVO3: is the NVE >>> >> collocated >>> >> >> with the VM or is the NVE located at a TOR connected to a server. >>> >> >> Depending on the connectivity different solutions might be >>> required >>> >> and >>> >> >> as >>> >> >> such we made the requirement general and not specific since there >>> is >>> >> >> multiple solutions to this and this is a requirements draft >>> rather >>> >> than >>> >> >> solution draft. Use case should be covered in a separate doc. >>> >> >[Lucy] It, I think, is more about cases between DC GW and WAN PE. >>> For >>> >> >example, if NVO3 is used in DC, when we need VLAN aware bundle >>> service >>> >> >interface? Could you give a example? I don't have a problem to make >>> a >>> >> >general requirement, just want know where is the requirement coming >>> >> from. >>> >> > >>> >> >Lucy >>> >> >>> >> WH2> the service interface we are talking about here is how the EVPN >>> >> service is modelled on the DC GW/WAN PE. There are multiple >>> scenarios >>> >> which should be supported. The service interface here is an internal >>> >> modelling of the EVPN on the PE >>> >[Lucy] OK. Maybe I did not follow the early requirement discussions. >>> >Where was this requirement coming from. MEF Services do not support >>> such >>> >service interface. Was this from some operators in IETF? I just like >>> to >>> >know a use case if possible. >>> > >>> >Lucy >>> >> >> > >>> >> >> >Cheers, >>> >> >> >Lucy >>> >> >> > >>> >> >> >> ------------------------------ >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >>> >> >> >> From: Giles Heron >>> >> >> >> To: "l2vpn@ietf.org" >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii >>> >> >> >> >>> >> >> >> This email initiates an L2VPN WG Last Call for: >>> >> >> >> >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >>> >> >> >> >>> >> >> >> please comment to the list as to the suitability of this draft >>> >> for >>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. >>> >> >> >> >>> >> >> >> this last call will close on Friday 2nd November. >>> >> >> >> >>> >> >> >> Nabil & Giles >>> >> >> > >>> >> > >>> > >> > From sajassi@cisco.com Wed Nov 14 11:51: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 2901121F86FF for ; Wed, 14 Nov 2012 11:51:18 -0800 (PST) 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 DFLqUJnIE+OL for ; Wed, 14 Nov 2012 11:51:17 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8539B21F87B9 for ; Wed, 14 Nov 2012 11:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=562; q=dns/txt; s=iport; t=1352922677; x=1354132277; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=7Ycte5QWualNDMLn45vK/7Kk63tO/Xmts/Z2+aUwuxo=; b=Wyite8+OZzqmfeYlLiXfSMFyiqWRPggDTj94hOkNQIf7+vj+pO+FPBx/ CXSDjoKHvamv3Vni5ObMDPDWls73fRxoGpql9f8wzDFH1lZjfAmleOTg8 vPN/DZImtI0XDBPBl22gOOTYF8bAXE0Z0Zp20ir8SnZg1B67RLtQqJywf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPT0o1CtJXG+/2dsb2JhbABEgmzAUIEIgiABBA4EAQpIJgEIIlYlAgQBGhqHaAGbIqAXkXhhA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142402931" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 14 Nov 2012 19:51:17 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAEJpHEC001086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 19:51:17 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 13:51:16 -0600 From: "Ali Sajassi (sajassi)" To: "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , Lucy yong , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACPdACAAE/VAIAAfFoAgABmAACAAAFxAIAAT1SAgAAAfICADYO2gIAAB+aA Date: Wed, 14 Nov 2012 19:51:16 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7A2FC6@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.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: [64.101.1.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--27.176100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <832793B74EBDFA408930E37A35FE1408@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 14 Nov 2012 19:51:18 -0000 Revision to one of the resolution =8A > >>2) in section 4.6, the last paragraph should state a requirement for flow >>based load balance. >> > >Resolution: Agreed, we add flow-based LB to the text. Section 4.6 talks about dual-homed network and NOT dual-homed device. As such, no application has been identified that requires flow-based load balancing for multi-homed network! In other words, a network based on 802.1Q or G.8032 does not need flow-baesd LB. Therefore, we will not add such requirement to section 4.6. Cheers, Ali From lucy.yong@huawei.com Wed Nov 14 12:02:19 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 9102721F8749 for ; Wed, 14 Nov 2012 12:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 wDzGtDvN1hjI for ; Wed, 14 Nov 2012 12:02:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7FA21F87EF for ; Wed, 14 Nov 2012 12:02:18 -0800 (PST) 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 ALN48391; Wed, 14 Nov 2012 20:02:14 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 20:02:01 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 20:02:13 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 14 Nov 2012 12:02:07 -0800 From: Lucy yong To: "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAA/LkAABCgZoA= Date: Wed, 14 Nov 2012 20:02:06 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4483070F@dfweml505-mbx> References: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> <69670F7146898C4583F56DA9AD32F77B0D7A2FC6@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7A2FC6@xmb-aln-x13.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.79] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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: Wed, 14 Nov 2012 20:02:19 -0000 Hi Ali, The last paragraph in section 4.6 A solution MAY support multi-homed network with active/active MAC- based load balancing (i.e. different MAC addresses on a VLAN are reachable via different PEs). Should the load balancing function depend on whether dual-homed network or = dual homed device? IMO: it is not. We should not exclude that the packets w= ith the same MAC address appear on the different PEs. But the paragraph see= ms exclude that. That is my point. Regards, Lucy > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Wednesday, November 14, 2012 1:51 PM > To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); Lucy yong; > l2vpn@ietf.org > Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 >=20 >=20 > Revision to one of the resolution =A9 >=20 >=20 > > > >>2) in section 4.6, the last paragraph should state a requirement for > flow > >>based load balance. > >> > > > >Resolution: Agreed, we add flow-based LB to the text. >=20 >=20 > Section 4.6 talks about dual-homed network and NOT dual-homed device. > As > such, no application has been identified that requires flow-based load > balancing for multi-homed network! In other words, a network based on > 802.1Q or G.8032 does not need flow-baesd LB. >=20 >=20 > Therefore, we will not add such requirement to section 4.6. >=20 > Cheers, > Ali From sajassi@cisco.com Wed Nov 14 12:09: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 BD6C521F86A9 for ; Wed, 14 Nov 2012 12:09:35 -0800 (PST) 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 p0oIcPop2M38 for ; Wed, 14 Nov 2012 12:09:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DD97B21F8669 for ; Wed, 14 Nov 2012 12:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1972; q=dns/txt; s=iport; t=1352923775; x=1354133375; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Hjx8PXL2D6d6wTo3vhSyXQMe21sCt+39kUddSYDaujA=; b=CTjuBlEb3XASZsko1R2AzQ0FDacnuBouvb5DtJvBnNv8v8Fv1p8Kqh3Y y1rVy14dYuqTVmnwAQMsQkjoM+re5UCRf/V2CO4X4B79Vry6pQyW2TQ4S bJfp+6kypS4EwQNpfry0IqIzMjT3IM4hNL5644X77gx2fjL5lPBYyrDFz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFT5o1CtJV2d/2dsb2JhbABEgmzAT4EIgh4BAQEEDgQBCkggBgEIEQQBAQsdORQJCAIEARIIEweHaAGbLKAUjC2FS2EDpFSBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142432786" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2012 20:09:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAEK9YaX016211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 20:09:34 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 14:09:34 -0600 From: "Ali Sajassi (sajassi)" To: Lucy yong , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACPdACAAE/VAIAAfFoAgABmAACAAAFxAIAAT1SAgAAAfICADYO2gIAAB+aAgACJJQD//3v3AA== Date: Wed, 14 Nov 2012 20:09:33 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7A2FFF@xmb-aln-x13.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4483070F@dfweml505-mbx> 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: [64.101.1.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--44.203900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-2" Content-ID: <37ACE7522076B442904AA84D0D5187F4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 14 Nov 2012 20:09:35 -0000 Hi Lucy, Yes, the load balancing function should depend on whether we are talking about MHD or MHN. In case of MHD, LACP provides per-flow load balancing. However, in case of MHN, 802.1Q expects load balancing on a per-VLAN basis and G.8032 can expect load balancing on a per-MAC basis (for a given VLAN).=20 Cheers, Ali the paragraph intentionally excludes that as I cannot see of any application that requires it On 11/14/12 12:02 PM, "Lucy yong" wrote: >Hi Ali, > >The last paragraph in section 4.6 > > A solution MAY support multi-homed network with active/active MAC- > based load balancing (i.e. different MAC addresses on a VLAN are > reachable via different PEs). > >Should the load balancing function depend on whether dual-homed network >or dual homed device? IMO: it is not. We should not exclude that the >packets with the same MAC address appear on the different PEs. But the >paragraph seems exclude that. That is my point. > >Regards, >Lucy > >> -----Original Message----- >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >> Sent: Wednesday, November 14, 2012 1:51 PM >> To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); Lucy yong; >> l2vpn@ietf.org >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >>=20 >>=20 >>=20 >> Revision to one of the resolution =A9 >>=20 >>=20 >> > >> >>2) in section 4.6, the last paragraph should state a requirement for >> flow >> >>based load balance. >> >> >> > >> >Resolution: Agreed, we add flow-based LB to the text. >>=20 >>=20 >> Section 4.6 talks about dual-homed network and NOT dual-homed device. >> As >> such, no application has been identified that requires flow-based load >> balancing for multi-homed network! In other words, a network based on >> 802.1Q or G.8032 does not need flow-baesd LB. >>=20 >>=20 >> Therefore, we will not add such requirement to section 4.6. >>=20 >> Cheers, >> Ali > From lucy.yong@huawei.com Wed Nov 14 12:18:50 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 E746921F8755 for ; Wed, 14 Nov 2012 12:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 5-wLBb-9ZtBL for ; Wed, 14 Nov 2012 12:18:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D413421F8749 for ; Wed, 14 Nov 2012 12:18:47 -0800 (PST) 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 AMU64336; Wed, 14 Nov 2012 20:18:46 +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; Wed, 14 Nov 2012 20:18:32 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 04:18:43 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 14 Nov 2012 12:18:37 -0800 From: Lucy yong To: "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAPRT5A Date: Wed, 14 Nov 2012 20:18:36 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> References: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 14 Nov 2012 20:18:50 -0000 Hi Ali, >=20 > >1) in section 4.3, Text: The latter scenario often means that > requiring a > >dedicated > > link between the PEs, for the operation of the multi-homing > mechanism, > >is not appealing from cost standpoint. > > > >Comment: a dedicated link between PEs. will this link is in IGP link > too? > >or private link. > >May PE nodes that are multi-homed to a same CE be different ASes? If > yes, > >state it out. > > >=20 > Resolution: no change to the text. > The draft states that having such a dedicated link (which is not an IGP > link) is not desirable and thus cannot be assumed that such link exist. >=20 [Lucy] As Wim suggested, it is better to delete the following sentence in s= ection 4.3 because it does not serve any requirement and brings a confusion= . The latter scenario often means that requiring a dedicated link between the PEs, for the operation of the multi-homing mechanism, i= s not appealing from cost standpoint. Should we explicitly say if PEs associated with a multi-homed setup have to= be in the same IGP or not in different IGPs, i.e. different ASes? The foll= owing sentence implicitly state that. =20 =20 Furthermore, the IGP cost from remote PEs to the pair of PEs in the multi-h= omed setup cannot be assumed to be the same when those latter PEs are geo- redundant. Regards, Lucy > >2) in section 4.6, the last paragraph should state a requirement for > flow > >based load balance. > > >=20 > Resolution: Agreed, we add flow-based LB to the text. >=20 > >3) It should add one requirement in supporting Ethernet L2VPN across > >multi-ASes > > >=20 > Resolution: Agreed, we'll add that. >=20 >=20 > >4) As the draft mentioned, the new service interfaces are required for > DC > >interconnection. If DC uses NVo3 in future, will these service > interfaces > >are still necessary? Suggest giving some use cases where the new > service > >interfaces are necessary in an appendix. > > > > >=20 > Resolution: No change, as clarified in the email thread. >=20 > Cheers, > Ali >=20 >=20 >=20 >=20 > On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > wrote: >=20 > >Lucy, sure and this evolution into MEF is most likely to come, but I > >believe it is a clear req for EVPN, so I believe we can close this > point > > > >On 05/11/12 15:58, "Lucy yong" wrote: > > > >>Wim, > >> > >>I agree that we (IETF) don't have make ourselves dependent on MEF. > >>However, there are a lot of service providers in MEF to specify > Ethernet > >>services and service interfaces. Such service interface has not yet > to > >>bring on the table there. This may be because the people in two SDOs > may > >>be from different orgs.. > >> > >>Thanks, > >>Lucy > >> > >>> -----Original Message----- > >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > >>> Sent: Monday, November 05, 2012 10:15 AM > >>> To: Lucy yong; l2vpn@ietf.org > >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > >>> > >>> -- Snip -- > >>> > >>> [Lucy] OK. Maybe I did not follow the early requirement discussions. > >>> Where > >>> was this requirement coming from. MEF Services do not support such > >>> service > >>> interface. Was this from some operators in IETF? I just like to > know a > >>> use > >>> case if possible. > >>> > >>> > >>> WH> yes this is from operators of which some are on the co-author > list. > >>> The driver for this is more optimised and scalable implementations. > MEF > >>> might adopt this going fwd, so we should not make ourselves > dependent > >>> on > >>> MEF > >>> > >>> -- Snip -- > >>> > >>> On 05/11/12 11:09, "Lucy yong" wrote: > >>> > >>> > > >>> > > >>> >snip > >>> >> >[Lucy] My second question is if PE nodes that are multi-homed > to a > >>> >> same > >>> >> >CE may be in different ASes in latter case? Whether yes, or no, > it > >>> >> should > >>> >> >state it out. > >>> >> > >>> >> WH2> this seems like an odd scenario > >>> >[Lucy] agree. > >>> >> > > >>> >> >> > > >>> >> >> >2) in section 4.6, the last paragraph should state a > requirement > >>> >> for > >>> >> >> flow > >>> >> >> >based load balance. > >>> >> >> > >>> >> >> WH> are you saying the Mac based load-balancing is a MUST or > are > >>> you > >>> >> >> saying the MAC based load-balancing should be flow based > >>> >> >[Lucy] Text: A solution MAY support multi-homed network with > >>> >> >active/active MAC- > >>> >> > based load balancing (i.e. different MAC addresses on a VLAN > are > >>> >> > reachable via different PEs). > >>> >> > > >>> >> >In section 4.1, it describes options for flow-based load > balancing, > >>> >> that > >>> >> >should apply to here, right? > >>> >> >That means the same MAC address may occur on the different PEs > too. > >>> >> WH2> yes > >>> >> > > >>> >> >> > > >>> >> >> >3) It should add one requirement in supporting Ethernet > L2VPN > >>> >> across > >>> >> >> >multi-Ases > >>> >> >> > >>> >> >> WH> agreed > >>> >> >> > > >>> >> >> >4) As the draft mentioned, the new service interfaces are > >>> required > >>> >> for > >>> >> >> DC > >>> >> >> >interconnection. If DC uses NVo3 in future, will these > service > >>> >> >> interfaces > >>> >> >> >are still necessary? Suggest giving some use cases where the > new > >>> >> >> service > >>> >> >> >interfaces are necessary in an appendix. > >>> >> >> WH> it depends on what use case we have in NVO3: is the NVE > >>> >> collocated > >>> >> >> with the VM or is the NVE located at a TOR connected to a > server. > >>> >> >> Depending on the connectivity different solutions might be > >>> required > >>> >> and > >>> >> >> as > >>> >> >> such we made the requirement general and not specific since > there > >>> is > >>> >> >> multiple solutions to this and this is a requirements draft > >>> rather > >>> >> than > >>> >> >> solution draft. Use case should be covered in a separate doc. > >>> >> >[Lucy] It, I think, is more about cases between DC GW and WAN > PE. > >>> For > >>> >> >example, if NVO3 is used in DC, when we need VLAN aware bundle > >>> service > >>> >> >interface? Could you give a example? I don't have a problem to > make > >>> a > >>> >> >general requirement, just want know where is the requirement > coming > >>> >> from. > >>> >> > > >>> >> >Lucy > >>> >> > >>> >> WH2> the service interface we are talking about here is how the > EVPN > >>> >> service is modelled on the DC GW/WAN PE. There are multiple > >>> scenarios > >>> >> which should be supported. The service interface here is an > internal > >>> >> modelling of the EVPN on the PE > >>> >[Lucy] OK. Maybe I did not follow the early requirement > discussions. > >>> >Where was this requirement coming from. MEF Services do not > support > >>> such > >>> >service interface. Was this from some operators in IETF? I just > like > >>> to > >>> >know a use case if possible. > >>> > > >>> >Lucy > >>> >> >> > > >>> >> >> >Cheers, > >>> >> >> >Lucy > >>> >> >> > > >>> >> >> >> ------------------------------ > >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > >>> >> >> >> From: Giles Heron > >>> >> >> >> To: "l2vpn@ietf.org" > >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- > FBBEDB84BC32@gmail.com> > >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii > >>> >> >> >> > >>> >> >> >> This email initiates an L2VPN WG Last Call for: > >>> >> >> >> > >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 > >>> >> >> >> > >>> >> >> >> please comment to the list as to the suitability of this > draft > >>> >> for > >>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. > >>> >> >> >> > >>> >> >> >> this last call will close on Friday 2nd November. > >>> >> >> >> > >>> >> >> >> Nabil & Giles > >>> >> >> > > >>> >> > > >>> > > >> > > From lucy.yong@huawei.com Wed Nov 14 12:29:19 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 1EEBB21F8755 for ; Wed, 14 Nov 2012 12:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 yiZYjvLU+3ke for ; Wed, 14 Nov 2012 12:29:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B3DD121F86FF for ; Wed, 14 Nov 2012 12:29:16 -0800 (PST) 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 ALN49448; Wed, 14 Nov 2012 20:29:15 +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; Wed, 14 Nov 2012 20:29:02 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 20:29:14 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 14 Nov 2012 12:29:08 -0800 From: Lucy yong To: "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAA/LkAABCgZoD//4AYgIAAgh8Q Date: Wed, 14 Nov 2012 20:29:07 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44830750@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4483070F@dfweml505-mbx> <69670F7146898C4583F56DA9AD32F77B0D7A2FFF@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7A2FFF@xmb-aln-x13.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.79] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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: Wed, 14 Nov 2012 20:29:19 -0000 Hi Ali, I see your point. However, both 802.1Q and G.8032 do not support active-act= ive multi-homed links. Now, I am confused with this requirement in section = 4.6. A solution MUST also support multi-homed network with active/active VLAN-based load balancing (i.e. disjoint VLAN sets active on disparate PEs). Where is the requirement coming from. It is not from 802.1Q and G.8032. I d= on't know how Ethernet network will handle it. Lucy > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Wednesday, November 14, 2012 2:10 PM > To: Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org > Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 > Hi Lucy, >=20 > Yes, the load balancing function should depend on whether we are > talking > about MHD or MHN. In case of MHD, LACP provides per-flow load balancing. > However, in case of MHN, 802.1Q expects load balancing on a per-VLAN > basis > and G.8032 can expect load balancing on a per-MAC basis (for a given > VLAN). >=20 > Cheers, > Ali >=20 > the paragraph intentionally excludes that as I cannot see of any > application that requires it >=20 > On 11/14/12 12:02 PM, "Lucy yong" wrote: >=20 > >Hi Ali, > > > >The last paragraph in section 4.6 > > > > A solution MAY support multi-homed network with active/active MAC- > > based load balancing (i.e. different MAC addresses on a VLAN are > > reachable via different PEs). > > > >Should the load balancing function depend on whether dual-homed > network > >or dual homed device? IMO: it is not. We should not exclude that the > >packets with the same MAC address appear on the different PEs. But the > >paragraph seems exclude that. That is my point. > > > >Regards, > >Lucy > > > >> -----Original Message----- > >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > >> Sent: Wednesday, November 14, 2012 1:51 PM > >> To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); Lucy yong; > >> l2vpn@ietf.org > >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > >> > >> > >> > >> Revision to one of the resolution =A9 > >> > >> > >> > > >> >>2) in section 4.6, the last paragraph should state a requirement > for > >> flow > >> >>based load balance. > >> >> > >> > > >> >Resolution: Agreed, we add flow-based LB to the text. > >> > >> > >> Section 4.6 talks about dual-homed network and NOT dual-homed device. > >> As > >> such, no application has been identified that requires flow-based > load > >> balancing for multi-homed network! In other words, a network based > on > >> 802.1Q or G.8032 does not need flow-baesd LB. > >> > >> > >> Therefore, we will not add such requirement to section 4.6. > >> > >> Cheers, > >> Ali > > From wim.henderickx@alcatel-lucent.com Wed Nov 14 13:05:13 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 5792B21F8475 for ; Wed, 14 Nov 2012 13:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=0.500, 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 ah2FAvlhHdt6 for ; Wed, 14 Nov 2012 13:05:12 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2F14121F846E for ; Wed, 14 Nov 2012 13:05:11 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAEL4x1H028028 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Nov 2012 22:05:06 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 14 Nov 2012 22:05:05 +0100 From: "Henderickx, Wim (Wim)" To: "Ali Sajassi (sajassi)" , Lucy yong , "l2vpn@ietf.org" Date: Wed, 14 Nov 2012 22:05:05 +0100 Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: Ac3Cq7hZIxZdqObpRKyiZvbnOhR6tA== Message-ID: In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 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, 14 Nov 2012 21:05:13 -0000 indeed On 14/11/12 11:23, "Ali Sajassi (sajassi)" wrote: > >Wim, Lucy: > >I think we are all set. Going through your emails, we can conclude the >following comment resolutions: > >On 11/4/12 11:40 AM, "Lucy yong" wrote: > >>1) in section 4.3, Text: The latter scenario often means that requiring a >>dedicated >> link between the PEs, for the operation of the multi-homing mechanism, >>is not appealing from cost standpoint. >> >>Comment: a dedicated link between PEs. will this link is in IGP link too? >>or private link. >>May PE nodes that are multi-homed to a same CE be different ASes? If yes, >>state it out. >> > >Resolution: no change to the text. >The draft states that having such a dedicated link (which is not an IGP >link) is not desirable and thus cannot be assumed that such link exist. > >>2) in section 4.6, the last paragraph should state a requirement for flow >>based load balance. >> > >Resolution: Agreed, we add flow-based LB to the text. > >>3) It should add one requirement in supporting Ethernet L2VPN across >>multi-ASes >> > >Resolution: Agreed, we'll add that. > > >>4) As the draft mentioned, the new service interfaces are required for DC >>interconnection. If DC uses NVo3 in future, will these service interfaces >>are still necessary? Suggest giving some use cases where the new service >>interfaces are necessary in an appendix. >> >> > >Resolution: No change, as clarified in the email thread. > >Cheers, >Ali > > > > >On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > wrote: > >>Lucy, sure and this evolution into MEF is most likely to come, but I >>believe it is a clear req for EVPN, so I believe we can close this point >> >>On 05/11/12 15:58, "Lucy yong" wrote: >> >>>Wim, >>> >>>I agree that we (IETF) don't have make ourselves dependent on MEF. >>>However, there are a lot of service providers in MEF to specify Ethernet >>>services and service interfaces. Such service interface has not yet to >>>bring on the table there. This may be because the people in two SDOs may >>>be from different orgs.. >>> >>>Thanks, >>>Lucy >>> >>>> -----Original Message----- >>>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >>>> Sent: Monday, November 05, 2012 10:15 AM >>>> To: Lucy yong; l2vpn@ietf.org >>>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >>>>=20 >>>> -- Snip -- >>>>=20 >>>> [Lucy] OK. Maybe I did not follow the early requirement discussions. >>>> Where >>>> was this requirement coming from. MEF Services do not support such >>>> service >>>> interface. Was this from some operators in IETF? I just like to know a >>>> use >>>> case if possible. >>>>=20 >>>>=20 >>>> WH> yes this is from operators of which some are on the co-author >>>>list. >>>> The driver for this is more optimised and scalable implementations. >>>>MEF >>>> might adopt this going fwd, so we should not make ourselves dependent >>>> on >>>> MEF >>>>=20 >>>> -- Snip -- >>>>=20 >>>> On 05/11/12 11:09, "Lucy yong" wrote: >>>>=20 >>>> > >>>> > >>>> >snip >>>> >> >[Lucy] My second question is if PE nodes that are multi-homed to a >>>> >> same >>>> >> >CE may be in different ASes in latter case? Whether yes, or no, it >>>> >> should >>>> >> >state it out. >>>> >> >>>> >> WH2> this seems like an odd scenario >>>> >[Lucy] agree. >>>> >> > >>>> >> >> > >>>> >> >> >2) in section 4.6, the last paragraph should state a >>>>requirement >>>> >> for >>>> >> >> flow >>>> >> >> >based load balance. >>>> >> >> >>>> >> >> WH> are you saying the Mac based load-balancing is a MUST or are >>>> you >>>> >> >> saying the MAC based load-balancing should be flow based >>>> >> >[Lucy] Text: A solution MAY support multi-homed network with >>>> >> >active/active MAC- >>>> >> > based load balancing (i.e. different MAC addresses on a VLAN >>>>are >>>> >> > reachable via different PEs). >>>> >> > >>>> >> >In section 4.1, it describes options for flow-based load >>>>balancing, >>>> >> that >>>> >> >should apply to here, right? >>>> >> >That means the same MAC address may occur on the different PEs >>>>too. >>>> >> WH2> yes >>>> >> > >>>> >> >> > >>>> >> >> >3) It should add one requirement in supporting Ethernet L2VPN >>>> >> across >>>> >> >> >multi-Ases >>>> >> >> >>>> >> >> WH> agreed >>>> >> >> > >>>> >> >> >4) As the draft mentioned, the new service interfaces are >>>> required >>>> >> for >>>> >> >> DC >>>> >> >> >interconnection. If DC uses NVo3 in future, will these service >>>> >> >> interfaces >>>> >> >> >are still necessary? Suggest giving some use cases where the >>>>new >>>> >> >> service >>>> >> >> >interfaces are necessary in an appendix. >>>> >> >> WH> it depends on what use case we have in NVO3: is the NVE >>>> >> collocated >>>> >> >> with the VM or is the NVE located at a TOR connected to a >>>>server. >>>> >> >> Depending on the connectivity different solutions might be >>>> required >>>> >> and >>>> >> >> as >>>> >> >> such we made the requirement general and not specific since >>>>there >>>> is >>>> >> >> multiple solutions to this and this is a requirements draft >>>> rather >>>> >> than >>>> >> >> solution draft. Use case should be covered in a separate doc. >>>> >> >[Lucy] It, I think, is more about cases between DC GW and WAN PE. >>>> For >>>> >> >example, if NVO3 is used in DC, when we need VLAN aware bundle >>>> service >>>> >> >interface? Could you give a example? I don't have a problem to >>>>make >>>> a >>>> >> >general requirement, just want know where is the requirement >>>>coming >>>> >> from. >>>> >> > >>>> >> >Lucy >>>> >> >>>> >> WH2> the service interface we are talking about here is how the >>>>EVPN >>>> >> service is modelled on the DC GW/WAN PE. There are multiple >>>> scenarios >>>> >> which should be supported. The service interface here is an >>>>internal >>>> >> modelling of the EVPN on the PE >>>> >[Lucy] OK. Maybe I did not follow the early requirement discussions. >>>> >Where was this requirement coming from. MEF Services do not support >>>> such >>>> >service interface. Was this from some operators in IETF? I just like >>>> to >>>> >know a use case if possible. >>>> > >>>> >Lucy >>>> >> >> > >>>> >> >> >Cheers, >>>> >> >> >Lucy >>>> >> >> > >>>> >> >> >> ------------------------------ >>>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >>>> >> >> >> From: Giles Heron >>>> >> >> >> To: "l2vpn@ietf.org" >>>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >>>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >>>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii >>>> >> >> >> >>>> >> >> >> This email initiates an L2VPN WG Last Call for: >>>> >> >> >> >>>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >>>> >> >> >> >>>> >> >> >> please comment to the list as to the suitability of this >>>>draft >>>> >> for >>>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. >>>> >> >> >> >>>> >> >> >> this last call will close on Friday 2nd November. >>>> >> >> >> >>>> >> >> >> Nabil & Giles >>>> >> >> > >>>> >> > >>>> > >>> >> > From jdrake@juniper.net Wed Nov 14 13:15: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 5EABB21F84D7 for ; Wed, 14 Nov 2012 13:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.057 X-Spam-Level: * X-Spam-Status: No, score=1.057 tagged_above=-999 required=5 tests=[AWL=4.524, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 rqdJrQhm96hV for ; Wed, 14 Nov 2012 13:15:11 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id EF26A21F84C9 for ; Wed, 14 Nov 2012 13:15:10 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUKQJ3kZ2QqWCK3Yw77O/INLFVgB8XZsN@postini.com; Wed, 14 Nov 2012 13:15:11 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 14 Nov 2012 13:13:36 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 14 Nov 2012 13:13:35 -0800 Received: from CH1EHSOBE020.bigfish.com (216.32.181.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Nov 2012 13:20:32 -0800 Received: from mail93-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Nov 2012 21:13:35 +0000 Received: from mail93-ch1 (localhost [127.0.0.1]) by mail93-ch1-R.bigfish.com (Postfix) with ESMTP id D82C4240107 for ; Wed, 14 Nov 2012 21:13:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I542M1432I4015Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received: from mail93-ch1 (localhost.localdomain [127.0.0.1]) by mail93-ch1 (MessageSwitch) id 1352927612747405_14703; Wed, 14 Nov 2012 21:13:32 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail93-ch1.bigfish.com (Postfix) with ESMTP id B31C5E00F8; Wed, 14 Nov 2012 21:13:32 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Nov 2012 21:13:32 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.40]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0233.002; Wed, 14 Nov 2012 21:13:31 +0000 From: John E Drake To: Lucy yong , "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgAAq3wCAAE/VAIAAfFoAgABl/wCAAAFyAIAAT1OAgAAAfICADgnVAIAAD4gAgAAOdBA= Date: Wed, 14 Nov 2012 21:13:30 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E07E6D415@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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, 14 Nov 2012 21:15:12 -0000 Lucy, There should not be a requirement that two or more PEs providing multi-homi= ng to the same CE need to be in the same IGP. This is too restrictive and = totally unnecessary. Irrespectively Yours, John > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Lucy yong > Sent: Wednesday, November 14, 2012 12:19 PM > To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); l2vpn@ietf.org > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 > Hi Ali, >=20 > > > > >1) in section 4.3, Text: The latter scenario often means that > > requiring a > > >dedicated > > > link between the PEs, for the operation of the multi-homing > > mechanism, > > >is not appealing from cost standpoint. > > > > > >Comment: a dedicated link between PEs. will this link is in IGP link > > too? > > >or private link. > > >May PE nodes that are multi-homed to a same CE be different ASes? If > > yes, > > >state it out. > > > > > > > Resolution: no change to the text. > > The draft states that having such a dedicated link (which is not an > > IGP > > link) is not desirable and thus cannot be assumed that such link > exist. > > > [Lucy] As Wim suggested, it is better to delete the following sentence > in section 4.3 because it does not serve any requirement and brings a > confusion. >=20 > The latter scenario often means that requiring a dedicated > link between the PEs, for the operation of the multi-homing > mechanism, is not appealing from cost standpoint. >=20 > Should we explicitly say if PEs associated with a multi-homed setup > have to be in the same IGP or not in different IGPs, i.e. different > ASes? The following sentence implicitly state that. >=20 > Furthermore, the IGP cost from remote PEs to the pair of PEs in the > multi-homed setup > cannot be assumed to be the same when those latter PEs are geo- > redundant. >=20 > Regards, > Lucy > > >2) in section 4.6, the last paragraph should state a requirement for > > flow > > >based load balance. > > > > > > > Resolution: Agreed, we add flow-based LB to the text. > > > > >3) It should add one requirement in supporting Ethernet L2VPN across > > >multi-ASes > > > > > > > Resolution: Agreed, we'll add that. > > > > > > >4) As the draft mentioned, the new service interfaces are required > > >for > > DC > > >interconnection. If DC uses NVo3 in future, will these service > > interfaces > > >are still necessary? Suggest giving some use cases where the new > > service > > >interfaces are necessary in an appendix. > > > > > > > > > > Resolution: No change, as clarified in the email thread. > > > > Cheers, > > Ali > > > > > > > > > > On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > > wrote: > > > > >Lucy, sure and this evolution into MEF is most likely to come, but I > > >believe it is a clear req for EVPN, so I believe we can close this > > point > > > > > >On 05/11/12 15:58, "Lucy yong" wrote: > > > > > >>Wim, > > >> > > >>I agree that we (IETF) don't have make ourselves dependent on MEF. > > >>However, there are a lot of service providers in MEF to specify > > Ethernet > > >>services and service interfaces. Such service interface has not yet > > to > > >>bring on the table there. This may be because the people in two > SDOs > > may > > >>be from different orgs.. > > >> > > >>Thanks, > > >>Lucy > > >> > > >>> -----Original Message----- > > >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > lucent.com] > > >>> Sent: Monday, November 05, 2012 10:15 AM > > >>> To: Lucy yong; l2vpn@ietf.org > > >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > > >>> > > >>> -- Snip -- > > >>> > > >>> [Lucy] OK. Maybe I did not follow the early requirement > discussions. > > >>> Where > > >>> was this requirement coming from. MEF Services do not support > such > > >>> service interface. Was this from some operators in IETF? I just > > >>> like to > > know a > > >>> use > > >>> case if possible. > > >>> > > >>> > > >>> WH> yes this is from operators of which some are on the co-author > > list. > > >>> The driver for this is more optimised and scalable > implementations. > > MEF > > >>> might adopt this going fwd, so we should not make ourselves > > dependent > > >>> on > > >>> MEF > > >>> > > >>> -- Snip -- > > >>> > > >>> On 05/11/12 11:09, "Lucy yong" wrote: > > >>> > > >>> > > > >>> > > > >>> >snip > > >>> >> >[Lucy] My second question is if PE nodes that are multi-homed > > to a > > >>> >> same > > >>> >> >CE may be in different ASes in latter case? Whether yes, or > > >>> >> >no, > > it > > >>> >> should > > >>> >> >state it out. > > >>> >> > > >>> >> WH2> this seems like an odd scenario > > >>> >[Lucy] agree. > > >>> >> > > > >>> >> >> > > > >>> >> >> >2) in section 4.6, the last paragraph should state a > > requirement > > >>> >> for > > >>> >> >> flow > > >>> >> >> >based load balance. > > >>> >> >> > > >>> >> >> WH> are you saying the Mac based load-balancing is a MUST > or > > are > > >>> you > > >>> >> >> saying the MAC based load-balancing should be flow based > > >>> >> >[Lucy] Text: A solution MAY support multi-homed network > with > > >>> >> >active/active MAC- > > >>> >> > based load balancing (i.e. different MAC addresses on a > > >>> >> >VLAN > > are > > >>> >> > reachable via different PEs). > > >>> >> > > > >>> >> >In section 4.1, it describes options for flow-based load > > balancing, > > >>> >> that > > >>> >> >should apply to here, right? > > >>> >> >That means the same MAC address may occur on the different > PEs > > too. > > >>> >> WH2> yes > > >>> >> > > > >>> >> >> > > > >>> >> >> >3) It should add one requirement in supporting Ethernet > > L2VPN > > >>> >> across > > >>> >> >> >multi-Ases > > >>> >> >> > > >>> >> >> WH> agreed > > >>> >> >> > > > >>> >> >> >4) As the draft mentioned, the new service interfaces are > > >>> required > > >>> >> for > > >>> >> >> DC > > >>> >> >> >interconnection. If DC uses NVo3 in future, will these > > service > > >>> >> >> interfaces > > >>> >> >> >are still necessary? Suggest giving some use cases where > > >>> >> >> >the > > new > > >>> >> >> service > > >>> >> >> >interfaces are necessary in an appendix. > > >>> >> >> WH> it depends on what use case we have in NVO3: is the NVE > > >>> >> collocated > > >>> >> >> with the VM or is the NVE located at a TOR connected to a > > server. > > >>> >> >> Depending on the connectivity different solutions might be > > >>> required > > >>> >> and > > >>> >> >> as > > >>> >> >> such we made the requirement general and not specific since > > there > > >>> is > > >>> >> >> multiple solutions to this and this is a requirements draft > > >>> rather > > >>> >> than > > >>> >> >> solution draft. Use case should be covered in a separate > doc. > > >>> >> >[Lucy] It, I think, is more about cases between DC GW and WAN > > PE. > > >>> For > > >>> >> >example, if NVO3 is used in DC, when we need VLAN aware > bundle > > >>> service > > >>> >> >interface? Could you give a example? I don't have a problem > to > > make > > >>> a > > >>> >> >general requirement, just want know where is the requirement > > coming > > >>> >> from. > > >>> >> > > > >>> >> >Lucy > > >>> >> > > >>> >> WH2> the service interface we are talking about here is how > the > > EVPN > > >>> >> service is modelled on the DC GW/WAN PE. There are multiple > > >>> scenarios > > >>> >> which should be supported. The service interface here is an > > internal > > >>> >> modelling of the EVPN on the PE > > >>> >[Lucy] OK. Maybe I did not follow the early requirement > > discussions. > > >>> >Where was this requirement coming from. MEF Services do not > > support > > >>> such > > >>> >service interface. Was this from some operators in IETF? I just > > like > > >>> to > > >>> >know a use case if possible. > > >>> > > > >>> >Lucy > > >>> >> >> > > > >>> >> >> >Cheers, > > >>> >> >> >Lucy > > >>> >> >> > > > >>> >> >> >> ------------------------------ > > >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > > >>> >> >> >> From: Giles Heron > > >>> >> >> >> To: "l2vpn@ietf.org" > > >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > > >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- > > FBBEDB84BC32@gmail.com> > > >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii > > >>> >> >> >> > > >>> >> >> >> This email initiates an L2VPN WG Last Call for: > > >>> >> >> >> > > >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 > > >>> >> >> >> > > >>> >> >> >> please comment to the list as to the suitability of this > > draft > > >>> >> for > > >>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. > > >>> >> >> >> > > >>> >> >> >> this last call will close on Friday 2nd November. > > >>> >> >> >> > > >>> >> >> >> Nabil & Giles > > >>> >> >> > > > >>> >> > > > >>> > > > >> > > > >=20 From sajassi@cisco.com Wed Nov 14 13:25:13 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 2DFD821F84D2 for ; Wed, 14 Nov 2012 13:25:12 -0800 (PST) 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 rOIsN54fW86x for ; Wed, 14 Nov 2012 13:25:11 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BD77921F84D1 for ; Wed, 14 Nov 2012 13:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8874; q=dns/txt; s=iport; t=1352928308; x=1354137908; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=LYIOQGy/JcLL7tMo2aT9p8etIWRJor+yjnT1UHjpObk=; b=XFKrVjtOYeRx8DX46q7/oKb3KtPFehcVMvoLqNlfeHa4Y4CxDZsh/suO 6xYjCLKJ67M9LNwt8Gz6oa8r2QBaEOCHhp3sNMy9afFb5cHreLl10b1iZ McSgzrX592aYGvagT/aIVcRHerGtbmQvHC0/yEKFSIILuT96feHRivQ6c 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAkKpFCtJXG//2dsb2JhbABEgmzAVoEIgh4BAQEEDgQBCh0rIAYBCBEDAQEBAQoUCSgRFAkIAgQBEggTB4dXAw8BCpsiljANiVSLRGmFS2EDlCeCcYoWgyaBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142457259" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2012 21:25:08 +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 qAELP8P0025034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 21:25:08 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.0318.001; Wed, 14 Nov 2012 15:25:07 -0600 From: "Ali Sajassi (sajassi)" To: Lucy yong , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACPdACAAE/VAIAAfFoAgABmAACAAAFxAIAAT1SAgAAAfICADYO2gIAAlacA//+MeYA= Date: Wed, 14 Nov 2012 21:25:07 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7A305D@xmb-aln-x13.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> 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: [64.101.1.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--54.796500-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: <7EC6AAAB7FCA3146AED7EB5C32974323@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 14 Nov 2012 21:25:13 -0000 On 11/14/12 12:18 PM, "Lucy yong" wrote: >Hi Ali, > >>=20 >> >1) in section 4.3, Text: The latter scenario often means that >> requiring a >> >dedicated >> > link between the PEs, for the operation of the multi-homing >> mechanism, >> >is not appealing from cost standpoint. >> > >> >Comment: a dedicated link between PEs. will this link is in IGP link >> too? >> >or private link. >> >May PE nodes that are multi-homed to a same CE be different ASes? If >> yes, >> >state it out. >> > >>=20 >> Resolution: no change to the text. >> The draft states that having such a dedicated link (which is not an IGP >> link) is not desirable and thus cannot be assumed that such link exist. >>=20 >[Lucy] As Wim suggested, it is better to delete the following sentence in >section 4.3 because it does not serve any requirement and brings a >confusion. > > The latter scenario often means that requiring a dedicated > link between the PEs, for the operation of the multi-homing mechanism, >is not appealing from cost standpoint. I am adding the following two bullets, as further clarification, to sec. 4.3: A solution MUST support active/active multi-homing without the need for a dedicated control/data link among the PEs in the multi-homed group. A solution MUST NOT assume that the IGP cost from a remote PE to each of the PEs in the multi-homed group is the same. Cheers, Ali > >Should we explicitly say if PEs associated with a multi-homed setup have >to be in the same IGP or not in different IGPs, i.e. different ASes? The >following sentence implicitly state that. >=20 >Furthermore, the IGP cost from remote PEs to the pair of PEs in the >multi-homed setup > cannot be assumed to be the same when those latter PEs are geo- > redundant. > >Regards, >Lucy >> >2) in section 4.6, the last paragraph should state a requirement for >> flow >> >based load balance. >> > >>=20 >> Resolution: Agreed, we add flow-based LB to the text. >>=20 >> >3) It should add one requirement in supporting Ethernet L2VPN across >> >multi-ASes >> > >>=20 >> Resolution: Agreed, we'll add that. >>=20 >>=20 >> >4) As the draft mentioned, the new service interfaces are required for >> DC >> >interconnection. If DC uses NVo3 in future, will these service >> interfaces >> >are still necessary? Suggest giving some use cases where the new >> service >> >interfaces are necessary in an appendix. >> > >> > >>=20 >> Resolution: No change, as clarified in the email thread. >>=20 >> Cheers, >> Ali >>=20 >>=20 >>=20 >>=20 >> On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" >> wrote: >>=20 >> >Lucy, sure and this evolution into MEF is most likely to come, but I >> >believe it is a clear req for EVPN, so I believe we can close this >> point >> > >> >On 05/11/12 15:58, "Lucy yong" wrote: >> > >> >>Wim, >> >> >> >>I agree that we (IETF) don't have make ourselves dependent on MEF. >> >>However, there are a lot of service providers in MEF to specify >> Ethernet >> >>services and service interfaces. Such service interface has not yet >> to >> >>bring on the table there. This may be because the people in two SDOs >> may >> >>be from different orgs.. >> >> >> >>Thanks, >> >>Lucy >> >> >> >>> -----Original Message----- >> >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> lucent.com] >> >>> Sent: Monday, November 05, 2012 10:15 AM >> >>> To: Lucy yong; l2vpn@ietf.org >> >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >> >>> >> >>> -- Snip -- >> >>> >> >>> [Lucy] OK. Maybe I did not follow the early requirement discussions. >> >>> Where >> >>> was this requirement coming from. MEF Services do not support such >> >>> service >> >>> interface. Was this from some operators in IETF? I just like to >> know a >> >>> use >> >>> case if possible. >> >>> >> >>> >> >>> WH> yes this is from operators of which some are on the co-author >> list. >> >>> The driver for this is more optimised and scalable implementations. >> MEF >> >>> might adopt this going fwd, so we should not make ourselves >> dependent >> >>> on >> >>> MEF >> >>> >> >>> -- Snip -- >> >>> >> >>> On 05/11/12 11:09, "Lucy yong" wrote: >> >>> >> >>> > >> >>> > >> >>> >snip >> >>> >> >[Lucy] My second question is if PE nodes that are multi-homed >> to a >> >>> >> same >> >>> >> >CE may be in different ASes in latter case? Whether yes, or no, >> it >> >>> >> should >> >>> >> >state it out. >> >>> >> >> >>> >> WH2> this seems like an odd scenario >> >>> >[Lucy] agree. >> >>> >> > >> >>> >> >> > >> >>> >> >> >2) in section 4.6, the last paragraph should state a >> requirement >> >>> >> for >> >>> >> >> flow >> >>> >> >> >based load balance. >> >>> >> >> >> >>> >> >> WH> are you saying the Mac based load-balancing is a MUST or >> are >> >>> you >> >>> >> >> saying the MAC based load-balancing should be flow based >> >>> >> >[Lucy] Text: A solution MAY support multi-homed network with >> >>> >> >active/active MAC- >> >>> >> > based load balancing (i.e. different MAC addresses on a VLAN >> are >> >>> >> > reachable via different PEs). >> >>> >> > >> >>> >> >In section 4.1, it describes options for flow-based load >> balancing, >> >>> >> that >> >>> >> >should apply to here, right? >> >>> >> >That means the same MAC address may occur on the different PEs >> too. >> >>> >> WH2> yes >> >>> >> > >> >>> >> >> > >> >>> >> >> >3) It should add one requirement in supporting Ethernet >> L2VPN >> >>> >> across >> >>> >> >> >multi-Ases >> >>> >> >> >> >>> >> >> WH> agreed >> >>> >> >> > >> >>> >> >> >4) As the draft mentioned, the new service interfaces are >> >>> required >> >>> >> for >> >>> >> >> DC >> >>> >> >> >interconnection. If DC uses NVo3 in future, will these >> service >> >>> >> >> interfaces >> >>> >> >> >are still necessary? Suggest giving some use cases where the >> new >> >>> >> >> service >> >>> >> >> >interfaces are necessary in an appendix. >> >>> >> >> WH> it depends on what use case we have in NVO3: is the NVE >> >>> >> collocated >> >>> >> >> with the VM or is the NVE located at a TOR connected to a >> server. >> >>> >> >> Depending on the connectivity different solutions might be >> >>> required >> >>> >> and >> >>> >> >> as >> >>> >> >> such we made the requirement general and not specific since >> there >> >>> is >> >>> >> >> multiple solutions to this and this is a requirements draft >> >>> rather >> >>> >> than >> >>> >> >> solution draft. Use case should be covered in a separate doc. >> >>> >> >[Lucy] It, I think, is more about cases between DC GW and WAN >> PE. >> >>> For >> >>> >> >example, if NVO3 is used in DC, when we need VLAN aware bundle >> >>> service >> >>> >> >interface? Could you give a example? I don't have a problem to >> make >> >>> a >> >>> >> >general requirement, just want know where is the requirement >> coming >> >>> >> from. >> >>> >> > >> >>> >> >Lucy >> >>> >> >> >>> >> WH2> the service interface we are talking about here is how the >> EVPN >> >>> >> service is modelled on the DC GW/WAN PE. There are multiple >> >>> scenarios >> >>> >> which should be supported. The service interface here is an >> internal >> >>> >> modelling of the EVPN on the PE >> >>> >[Lucy] OK. Maybe I did not follow the early requirement >> discussions. >> >>> >Where was this requirement coming from. MEF Services do not >> support >> >>> such >> >>> >service interface. Was this from some operators in IETF? I just >> like >> >>> to >> >>> >know a use case if possible. >> >>> > >> >>> >Lucy >> >>> >> >> > >> >>> >> >> >Cheers, >> >>> >> >> >Lucy >> >>> >> >> > >> >>> >> >> >> ------------------------------ >> >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >> >>> >> >> >> From: Giles Heron >> >>> >> >> >> To: "l2vpn@ietf.org" >> >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >> >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- >> FBBEDB84BC32@gmail.com> >> >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii >> >>> >> >> >> >> >>> >> >> >> This email initiates an L2VPN WG Last Call for: >> >>> >> >> >> >> >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >> >>> >> >> >> >> >>> >> >> >> please comment to the list as to the suitability of this >> draft >> >>> >> for >> >>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. >> >>> >> >> >> >> >>> >> >> >> this last call will close on Friday 2nd November. >> >>> >> >> >> >> >>> >> >> >> Nabil & Giles >> >>> >> >> > >> >>> >> > >> >>> > >> >> >> > > From lucy.yong@huawei.com Wed Nov 14 13:28:58 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE89821F84DA for ; Wed, 14 Nov 2012 13:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 PR7WINimb2J8 for ; Wed, 14 Nov 2012 13:28:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B09A621F84D5 for ; Wed, 14 Nov 2012 13:28:56 -0800 (PST) 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 AMU67050; Wed, 14 Nov 2012 21:28:55 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 21:28:42 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 21:28:54 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 14 Nov 2012 13:28:47 -0800 From: Lucy yong To: "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAPRT5A//+n9ICAAIWs4A== Date: Wed, 14 Nov 2012 21:28:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448307BD@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> <69670F7146898C4583F56DA9AD32F77B0D7A305D@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7A305D@xmb-aln-x13.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 14 Nov 2012 21:28:59 -0000 Hi Ali, =20 Snip: . >=20 > I am adding the following two bullets, as further clarification, to sec. > 4.3: >=20 > A solution MUST support active/active multi-homing without the need > for a dedicated control/data link among the PEs in the multi-homed > group. >=20 > A solution MUST NOT assume that the IGP cost from a remote PE to > each > of the PEs in the multi-homed group is the same. [Lucy] These two requirements are very clear to me. It is clean the confusi= on. Cheers, Lucy >=20 > Cheers, >=20 > Ali >=20 > > > >Should we explicitly say if PEs associated with a multi-homed setup > have > >to be in the same IGP or not in different IGPs, i.e. different ASes? > The > >following sentence implicitly state that. > > > >Furthermore, the IGP cost from remote PEs to the pair of PEs in the > >multi-homed setup > > cannot be assumed to be the same when those latter PEs are geo- > > redundant. > > > >Regards, > >Lucy > >> >2) in section 4.6, the last paragraph should state a requirement > for > >> flow > >> >based load balance. > >> > > >> > >> Resolution: Agreed, we add flow-based LB to the text. > >> > >> >3) It should add one requirement in supporting Ethernet L2VPN > across > >> >multi-ASes > >> > > >> > >> Resolution: Agreed, we'll add that. > >> > >> > >> >4) As the draft mentioned, the new service interfaces are required > for > >> DC > >> >interconnection. If DC uses NVo3 in future, will these service > >> interfaces > >> >are still necessary? Suggest giving some use cases where the new > >> service > >> >interfaces are necessary in an appendix. > >> > > >> > > >> > >> Resolution: No change, as clarified in the email thread. > >> > >> Cheers, > >> Ali > >> > >> > >> > >> > >> On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > >> wrote: > >> > >> >Lucy, sure and this evolution into MEF is most likely to come, but > I > >> >believe it is a clear req for EVPN, so I believe we can close this > >> point > >> > > >> >On 05/11/12 15:58, "Lucy yong" wrote: > >> > > >> >>Wim, > >> >> > >> >>I agree that we (IETF) don't have make ourselves dependent on MEF. > >> >>However, there are a lot of service providers in MEF to specify > >> Ethernet > >> >>services and service interfaces. Such service interface has not > yet > >> to > >> >>bring on the table there. This may be because the people in two > SDOs > >> may > >> >>be from different orgs.. > >> >> > >> >>Thanks, > >> >>Lucy > >> >> > >> >>> -----Original Message----- > >> >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > >> lucent.com] > >> >>> Sent: Monday, November 05, 2012 10:15 AM > >> >>> To: Lucy yong; l2vpn@ietf.org > >> >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > >> >>> > >> >>> -- Snip -- > >> >>> > >> >>> [Lucy] OK. Maybe I did not follow the early requirement > discussions. > >> >>> Where > >> >>> was this requirement coming from. MEF Services do not support > such > >> >>> service > >> >>> interface. Was this from some operators in IETF? I just like to > >> know a > >> >>> use > >> >>> case if possible. > >> >>> > >> >>> > >> >>> WH> yes this is from operators of which some are on the co- > author > >> list. > >> >>> The driver for this is more optimised and scalable > implementations. > >> MEF > >> >>> might adopt this going fwd, so we should not make ourselves > >> dependent > >> >>> on > >> >>> MEF > >> >>> > >> >>> -- Snip -- > >> >>> > >> >>> On 05/11/12 11:09, "Lucy yong" wrote: > >> >>> > >> >>> > > >> >>> > > >> >>> >snip > >> >>> >> >[Lucy] My second question is if PE nodes that are multi- > homed > >> to a > >> >>> >> same > >> >>> >> >CE may be in different ASes in latter case? Whether yes, or > no, > >> it > >> >>> >> should > >> >>> >> >state it out. > >> >>> >> > >> >>> >> WH2> this seems like an odd scenario > >> >>> >[Lucy] agree. > >> >>> >> > > >> >>> >> >> > > >> >>> >> >> >2) in section 4.6, the last paragraph should state a > >> requirement > >> >>> >> for > >> >>> >> >> flow > >> >>> >> >> >based load balance. > >> >>> >> >> > >> >>> >> >> WH> are you saying the Mac based load-balancing is a MUST > or > >> are > >> >>> you > >> >>> >> >> saying the MAC based load-balancing should be flow based > >> >>> >> >[Lucy] Text: A solution MAY support multi-homed network > with > >> >>> >> >active/active MAC- > >> >>> >> > based load balancing (i.e. different MAC addresses on a > VLAN > >> are > >> >>> >> > reachable via different PEs). > >> >>> >> > > >> >>> >> >In section 4.1, it describes options for flow-based load > >> balancing, > >> >>> >> that > >> >>> >> >should apply to here, right? > >> >>> >> >That means the same MAC address may occur on the different > PEs > >> too. > >> >>> >> WH2> yes > >> >>> >> > > >> >>> >> >> > > >> >>> >> >> >3) It should add one requirement in supporting Ethernet > >> L2VPN > >> >>> >> across > >> >>> >> >> >multi-Ases > >> >>> >> >> > >> >>> >> >> WH> agreed > >> >>> >> >> > > >> >>> >> >> >4) As the draft mentioned, the new service interfaces are > >> >>> required > >> >>> >> for > >> >>> >> >> DC > >> >>> >> >> >interconnection. If DC uses NVo3 in future, will these > >> service > >> >>> >> >> interfaces > >> >>> >> >> >are still necessary? Suggest giving some use cases where > the > >> new > >> >>> >> >> service > >> >>> >> >> >interfaces are necessary in an appendix. > >> >>> >> >> WH> it depends on what use case we have in NVO3: is the > NVE > >> >>> >> collocated > >> >>> >> >> with the VM or is the NVE located at a TOR connected to a > >> server. > >> >>> >> >> Depending on the connectivity different solutions might be > >> >>> required > >> >>> >> and > >> >>> >> >> as > >> >>> >> >> such we made the requirement general and not specific > since > >> there > >> >>> is > >> >>> >> >> multiple solutions to this and this is a requirements > draft > >> >>> rather > >> >>> >> than > >> >>> >> >> solution draft. Use case should be covered in a separate > doc. > >> >>> >> >[Lucy] It, I think, is more about cases between DC GW and > WAN > >> PE. > >> >>> For > >> >>> >> >example, if NVO3 is used in DC, when we need VLAN aware > bundle > >> >>> service > >> >>> >> >interface? Could you give a example? I don't have a problem > to > >> make > >> >>> a > >> >>> >> >general requirement, just want know where is the requirement > >> coming > >> >>> >> from. > >> >>> >> > > >> >>> >> >Lucy > >> >>> >> > >> >>> >> WH2> the service interface we are talking about here is how > the > >> EVPN > >> >>> >> service is modelled on the DC GW/WAN PE. There are multiple > >> >>> scenarios > >> >>> >> which should be supported. The service interface here is an > >> internal > >> >>> >> modelling of the EVPN on the PE > >> >>> >[Lucy] OK. Maybe I did not follow the early requirement > >> discussions. > >> >>> >Where was this requirement coming from. MEF Services do not > >> support > >> >>> such > >> >>> >service interface. Was this from some operators in IETF? I just > >> like > >> >>> to > >> >>> >know a use case if possible. > >> >>> > > >> >>> >Lucy > >> >>> >> >> > > >> >>> >> >> >Cheers, > >> >>> >> >> >Lucy > >> >>> >> >> > > >> >>> >> >> >> ------------------------------ > >> >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > >> >>> >> >> >> From: Giles Heron > >> >>> >> >> >> To: "l2vpn@ietf.org" > >> >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > >> >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- > >> FBBEDB84BC32@gmail.com> > >> >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii > >> >>> >> >> >> > >> >>> >> >> >> This email initiates an L2VPN WG Last Call for: > >> >>> >> >> >> > >> >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 > >> >>> >> >> >> > >> >>> >> >> >> please comment to the list as to the suitability of > this > >> draft > >> >>> >> for > >> >>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. > >> >>> >> >> >> > >> >>> >> >> >> this last call will close on Friday 2nd November. > >> >>> >> >> >> > >> >>> >> >> >> Nabil & Giles > >> >>> >> >> > > >> >>> >> > > >> >>> > > >> >> > >> > > > From jdrake@juniper.net Wed Nov 14 13:29:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0D121F84E1 for ; Wed, 14 Nov 2012 13:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=2.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 5zCDPijILl-9 for ; Wed, 14 Nov 2012 13:29:33 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id AB77921F8500 for ; Wed, 14 Nov 2012 13:29:33 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUKQNPZNnVt8VBVtULxufdJY+yVuZOuYX@postini.com; Wed, 14 Nov 2012 13:29:33 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 14 Nov 2012 13:28:31 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 14 Nov 2012 13:28:30 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Nov 2012 13:35:25 -0800 Received: from mail31-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Nov 2012 21:28:28 +0000 Received: from mail31-tx2 (localhost [127.0.0.1]) by mail31-tx2-R.bigfish.com (Postfix) with ESMTP id 772154401B1 for ; Wed, 14 Nov 2012 21:28:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I542M1432I4015Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received: from mail31-tx2 (localhost.localdomain [127.0.0.1]) by mail31-tx2 (MessageSwitch) id 1352928505864689_27654; Wed, 14 Nov 2012 21:28:25 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.241]) by mail31-tx2.bigfish.com (Postfix) with ESMTP id C6B3E174004D; Wed, 14 Nov 2012 21:28:25 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Nov 2012 21:28:24 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.40]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0233.002; Wed, 14 Nov 2012 21:28:24 +0000 From: John E Drake To: "Ali Sajassi (sajassi)" , Lucy yong , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgAAq3wCAAE/VAIAAfFoAgABl/wCAAAFyAIAAT1OAgAAAfICADgnVAIAAD4gAgAASloCAAACPsA== Date: Wed, 14 Nov 2012 21:28:23 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E07E6D489@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> <69670F7146898C4583F56DA9AD32F77B0D7A305D@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7A305D@xmb-aln-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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, 14 Nov 2012 21:29:35 -0000 Ali, I don't mean to hold things up but is your second bullet really necessary? Irrespectively Yours, John > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Ali Sajassi (sajassi) > Sent: Wednesday, November 14, 2012 1:25 PM > To: Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org > Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 >=20 >=20 > On 11/14/12 12:18 PM, "Lucy yong" wrote: >=20 > >Hi Ali, > > > >> > >> >1) in section 4.3, Text: The latter scenario often means that > >> requiring a > >> >dedicated > >> > link between the PEs, for the operation of the multi-homing > >> mechanism, > >> >is not appealing from cost standpoint. > >> > > >> >Comment: a dedicated link between PEs. will this link is in IGP > link > >> too? > >> >or private link. > >> >May PE nodes that are multi-homed to a same CE be different ASes? > If > >> yes, > >> >state it out. > >> > > >> > >> Resolution: no change to the text. > >> The draft states that having such a dedicated link (which is not an > >> IGP > >> link) is not desirable and thus cannot be assumed that such link > exist. > >> > >[Lucy] As Wim suggested, it is better to delete the following sentence > >in section 4.3 because it does not serve any requirement and brings a > >confusion. > > > > The latter scenario often means that requiring a dedicated > > link between the PEs, for the operation of the multi-homing > >mechanism, is not appealing from cost standpoint. >=20 > I am adding the following two bullets, as further clarification, to > sec. > 4.3: >=20 > A solution MUST support active/active multi-homing without the need > for a dedicated control/data link among the PEs in the multi-homed > group. >=20 > A solution MUST NOT assume that the IGP cost from a remote PE to > each > of the PEs in the multi-homed group is the same. >=20 > Cheers, >=20 > Ali >=20 > > > >Should we explicitly say if PEs associated with a multi-homed setup > >have to be in the same IGP or not in different IGPs, i.e. different > >ASes? The following sentence implicitly state that. > > > >Furthermore, the IGP cost from remote PEs to the pair of PEs in the > >multi-homed setup > > cannot be assumed to be the same when those latter PEs are geo- > > redundant. > > > >Regards, > >Lucy > >> >2) in section 4.6, the last paragraph should state a requirement > for > >> flow > >> >based load balance. > >> > > >> > >> Resolution: Agreed, we add flow-based LB to the text. > >> > >> >3) It should add one requirement in supporting Ethernet L2VPN > across > >> >multi-ASes > >> > > >> > >> Resolution: Agreed, we'll add that. > >> > >> > >> >4) As the draft mentioned, the new service interfaces are required > >> >for > >> DC > >> >interconnection. If DC uses NVo3 in future, will these service > >> interfaces > >> >are still necessary? Suggest giving some use cases where the new > >> service > >> >interfaces are necessary in an appendix. > >> > > >> > > >> > >> Resolution: No change, as clarified in the email thread. > >> > >> Cheers, > >> Ali > >> > >> > >> > >> > >> On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > >> wrote: > >> > >> >Lucy, sure and this evolution into MEF is most likely to come, but > I > >> >believe it is a clear req for EVPN, so I believe we can close this > >> point > >> > > >> >On 05/11/12 15:58, "Lucy yong" wrote: > >> > > >> >>Wim, > >> >> > >> >>I agree that we (IETF) don't have make ourselves dependent on MEF. > >> >>However, there are a lot of service providers in MEF to specify > >> Ethernet > >> >>services and service interfaces. Such service interface has not > yet > >> to > >> >>bring on the table there. This may be because the people in two > >> >>SDOs > >> may > >> >>be from different orgs.. > >> >> > >> >>Thanks, > >> >>Lucy > >> >> > >> >>> -----Original Message----- > >> >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > >> lucent.com] > >> >>> Sent: Monday, November 05, 2012 10:15 AM > >> >>> To: Lucy yong; l2vpn@ietf.org > >> >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > >> >>> > >> >>> -- Snip -- > >> >>> > >> >>> [Lucy] OK. Maybe I did not follow the early requirement > discussions. > >> >>> Where > >> >>> was this requirement coming from. MEF Services do not support > >> >>> such service interface. Was this from some operators in IETF? I > >> >>> just like to > >> know a > >> >>> use > >> >>> case if possible. > >> >>> > >> >>> > >> >>> WH> yes this is from operators of which some are on the co- > author > >> list. > >> >>> The driver for this is more optimised and scalable > implementations. > >> MEF > >> >>> might adopt this going fwd, so we should not make ourselves > >> dependent > >> >>> on > >> >>> MEF > >> >>> > >> >>> -- Snip -- > >> >>> > >> >>> On 05/11/12 11:09, "Lucy yong" wrote: > >> >>> > >> >>> > > >> >>> > > >> >>> >snip > >> >>> >> >[Lucy] My second question is if PE nodes that are multi- > homed > >> to a > >> >>> >> same > >> >>> >> >CE may be in different ASes in latter case? Whether yes, or > >> >>> >> >no, > >> it > >> >>> >> should > >> >>> >> >state it out. > >> >>> >> > >> >>> >> WH2> this seems like an odd scenario > >> >>> >[Lucy] agree. > >> >>> >> > > >> >>> >> >> > > >> >>> >> >> >2) in section 4.6, the last paragraph should state a > >> requirement > >> >>> >> for > >> >>> >> >> flow > >> >>> >> >> >based load balance. > >> >>> >> >> > >> >>> >> >> WH> are you saying the Mac based load-balancing is a MUST > >> >>> >> >> WH> or > >> are > >> >>> you > >> >>> >> >> saying the MAC based load-balancing should be flow based > >> >>> >> >[Lucy] Text: A solution MAY support multi-homed network > with > >> >>> >> >active/active MAC- > >> >>> >> > based load balancing (i.e. different MAC addresses on a > >> >>> >> >VLAN > >> are > >> >>> >> > reachable via different PEs). > >> >>> >> > > >> >>> >> >In section 4.1, it describes options for flow-based load > >> balancing, > >> >>> >> that > >> >>> >> >should apply to here, right? > >> >>> >> >That means the same MAC address may occur on the different > >> >>> >> >PEs > >> too. > >> >>> >> WH2> yes > >> >>> >> > > >> >>> >> >> > > >> >>> >> >> >3) It should add one requirement in supporting Ethernet > >> L2VPN > >> >>> >> across > >> >>> >> >> >multi-Ases > >> >>> >> >> > >> >>> >> >> WH> agreed > >> >>> >> >> > > >> >>> >> >> >4) As the draft mentioned, the new service interfaces are > >> >>> required > >> >>> >> for > >> >>> >> >> DC > >> >>> >> >> >interconnection. If DC uses NVo3 in future, will these > >> service > >> >>> >> >> interfaces > >> >>> >> >> >are still necessary? Suggest giving some use cases where > >> >>> >> >> >the > >> new > >> >>> >> >> service > >> >>> >> >> >interfaces are necessary in an appendix. > >> >>> >> >> WH> it depends on what use case we have in NVO3: is the > NVE > >> >>> >> collocated > >> >>> >> >> with the VM or is the NVE located at a TOR connected to a > >> server. > >> >>> >> >> Depending on the connectivity different solutions might be > >> >>> required > >> >>> >> and > >> >>> >> >> as > >> >>> >> >> such we made the requirement general and not specific > since > >> there > >> >>> is > >> >>> >> >> multiple solutions to this and this is a requirements > draft > >> >>> rather > >> >>> >> than > >> >>> >> >> solution draft. Use case should be covered in a separate > doc. > >> >>> >> >[Lucy] It, I think, is more about cases between DC GW and > WAN > >> PE. > >> >>> For > >> >>> >> >example, if NVO3 is used in DC, when we need VLAN aware > >> >>> >> >bundle > >> >>> service > >> >>> >> >interface? Could you give a example? I don't have a problem > >> >>> >> >to > >> make > >> >>> a > >> >>> >> >general requirement, just want know where is the requirement > >> coming > >> >>> >> from. > >> >>> >> > > >> >>> >> >Lucy > >> >>> >> > >> >>> >> WH2> the service interface we are talking about here is how > >> >>> >> WH2> the > >> EVPN > >> >>> >> service is modelled on the DC GW/WAN PE. There are multiple > >> >>> scenarios > >> >>> >> which should be supported. The service interface here is an > >> internal > >> >>> >> modelling of the EVPN on the PE > >> >>> >[Lucy] OK. Maybe I did not follow the early requirement > >> discussions. > >> >>> >Where was this requirement coming from. MEF Services do not > >> support > >> >>> such > >> >>> >service interface. Was this from some operators in IETF? I just > >> like > >> >>> to > >> >>> >know a use case if possible. > >> >>> > > >> >>> >Lucy > >> >>> >> >> > > >> >>> >> >> >Cheers, > >> >>> >> >> >Lucy > >> >>> >> >> > > >> >>> >> >> >> ------------------------------ > >> >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > >> >>> >> >> >> From: Giles Heron > >> >>> >> >> >> To: "l2vpn@ietf.org" > >> >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > >> >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- > >> FBBEDB84BC32@gmail.com> > >> >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii > >> >>> >> >> >> > >> >>> >> >> >> This email initiates an L2VPN WG Last Call for: > >> >>> >> >> >> > >> >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 > >> >>> >> >> >> > >> >>> >> >> >> please comment to the list as to the suitability of > this > >> draft > >> >>> >> for > >> >>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. > >> >>> >> >> >> > >> >>> >> >> >> this last call will close on Friday 2nd November. > >> >>> >> >> >> > >> >>> >> >> >> Nabil & Giles > >> >>> >> >> > > >> >>> >> > > >> >>> > > >> >> > >> > > > >=20 From sajassi@cisco.com Wed Nov 14 13:30:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F7021F8508 for ; Wed, 14 Nov 2012 13:30:00 -0800 (PST) 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 mWTDk6MrhkOV for ; Wed, 14 Nov 2012 13:30:00 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E6B6E21F8503 for ; Wed, 14 Nov 2012 13:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3241; q=dns/txt; s=iport; t=1352928600; x=1354138200; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hfj3AtsQjhQPTeV9qjbjRWgwcNYTLW3vX9H345UHCMI=; b=meMITHKIfdPLtum1I1fWCKPxJKsZDGg7kk2xZULP2gyj3hfmSXec24xk WeElAfZoOmBus1Y5hOWAF9w/Xvx4EzwtRbkCB6NRyivogvtDmdiKXHfdi pyuKOqy9YFizhaxSCLMMOnApBqGZeePedjieUEwpNuPdYGvE6sxbOBsdX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAkKpFCtJV2b/2dsb2JhbABEgmzAVoEIgh4BAQEEDgQBCkggBgEIEQQBAQEKHTkUCQgCBAESCBMHh2kBmyygEYwthUthA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142461149" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 14 Nov 2012 21:29:59 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAELTxSR022353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 21:29:59 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 15:29:58 -0600 From: "Ali Sajassi (sajassi)" To: Lucy yong , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACPdACAAE/VAIAAfFoAgABmAACAAAFxAIAAT1SAgAAAfICADYO2gIAAB+aAgACJJQD//3v3AIAAi5WA//+K5AA= Date: Wed, 14 Nov 2012 21:29:58 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7A3075@xmb-aln-x13.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44830750@dfweml505-mbx> 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: [64.101.1.7] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 14 Nov 2012 21:30:00 -0000 Hi Lucy, When a G.8032 is dual-homed to a pair of PEs, you can have a scenario in which different set of MAC addresses for the same VLAN are learned by each of the PEs in the dual-homed group and thus the requirement in this section. Cheers, Ali =20 On 11/14/12 12:29 PM, "Lucy yong" wrote: >Hi Ali, > >I see your point. However, both 802.1Q and G.8032 do not support >active-active multi-homed links. Now, I am confused with this requirement >in section 4.6. > > A solution MUST also support multi-homed network with active/active > VLAN-based load balancing (i.e. disjoint VLAN sets active on > disparate PEs). > >Where is the requirement coming from. It is not from 802.1Q and G.8032. I >don't know how Ethernet network will handle it. > >Lucy > >> -----Original Message----- >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >> Sent: Wednesday, November 14, 2012 2:10 PM >> To: Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >>=20 >> Hi Lucy, >>=20 >> Yes, the load balancing function should depend on whether we are >> talking >> about MHD or MHN. In case of MHD, LACP provides per-flow load balancing. >> However, in case of MHN, 802.1Q expects load balancing on a per-VLAN >> basis >> and G.8032 can expect load balancing on a per-MAC basis (for a given >> VLAN). >>=20 >> Cheers, >> Ali >>=20 >> the paragraph intentionally excludes that as I cannot see of any >> application that requires it >>=20 >> On 11/14/12 12:02 PM, "Lucy yong" wrote: >>=20 >> >Hi Ali, >> > >> >The last paragraph in section 4.6 >> > >> > A solution MAY support multi-homed network with active/active MAC- >> > based load balancing (i.e. different MAC addresses on a VLAN are >> > reachable via different PEs). >> > >> >Should the load balancing function depend on whether dual-homed >> network >> >or dual homed device? IMO: it is not. We should not exclude that the >> >packets with the same MAC address appear on the different PEs. But the >> >paragraph seems exclude that. That is my point. >> > >> >Regards, >> >Lucy >> > >> >> -----Original Message----- >> >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >> >> Sent: Wednesday, November 14, 2012 1:51 PM >> >> To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); Lucy yong; >> >> l2vpn@ietf.org >> >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >> >> >> >> >> >> >> >> Revision to one of the resolution =A9 >> >> >> >> >> >> > >> >> >>2) in section 4.6, the last paragraph should state a requirement >> for >> >> flow >> >> >>based load balance. >> >> >> >> >> > >> >> >Resolution: Agreed, we add flow-based LB to the text. >> >> >> >> >> >> Section 4.6 talks about dual-homed network and NOT dual-homed device. >> >> As >> >> such, no application has been identified that requires flow-based >> load >> >> balancing for multi-homed network! In other words, a network based >> on >> >> 802.1Q or G.8032 does not need flow-baesd LB. >> >> >> >> >> >> Therefore, we will not add such requirement to section 4.6. >> >> >> >> Cheers, >> >> Ali >> > > From sajassi@cisco.com Wed Nov 14 13:32: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 5715321F8695 for ; Wed, 14 Nov 2012 13:32:17 -0800 (PST) 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 xHznAgNk0+aM for ; Wed, 14 Nov 2012 13:32:10 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 10A9721F84D7 for ; Wed, 14 Nov 2012 13:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10495; q=dns/txt; s=iport; t=1352928730; x=1354138330; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=72U5+RggoS3oYovs6dXiNBBE17a32krdLKEv//yDXBg=; b=CxlVfR5gHIAtV9GyCKYixVTq/N1V3tHGNp638OrvWMImwSF5wS+jaeIa 1l31eGuTbmn8XzvDf5OPxjMutRbtSbyFagNtnBIh1n3ByE1sdMsCiphKr GoHkT2D0svxrHV73w6PLwTCwx4jhC5bYc0J/1b046p9Elw++LYuZq1qEx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJYMpFCtJV2a/2dsb2JhbABEgmzAVoEIgh4BAQEEDgQBCh0rIAYBCBEDAQEBAQoUCSgRFAkIAgQBEggTB4dXAw8BCpsbljANiVSLRGmFS2EDlCeCcYoWgyaBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142459413" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2012 21:32:09 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAELW9LI025095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 21:32:09 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; Wed, 14 Nov 2012 15:32:08 -0600 From: "Ali Sajassi (sajassi)" To: John E Drake , Lucy yong , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACPdACAAE/VAIAAfFoAgABmAACAAAFxAIAAT1SAgAAAfICADYO2gIAAlacA//+MeYCAAIcGgP//evAA Date: Wed, 14 Nov 2012 21:32:08 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7A309A@xmb-aln-x13.cisco.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E07E6D489@BL2PRD0510MB349.namprd05.prod.outlook.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: [64.101.1.7] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--53.055400-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: <13FFBCFE3FC4C94D8A07FB6014D5D4B3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 14 Nov 2012 21:32:17 -0000 It is a clarification :-) Cheers, Ali On 11/14/12 1:28 PM, "John E Drake" wrote: >Ali, > >I don't mean to hold things up but is your second bullet really necessary? > >Irrespectively Yours, > >John > > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Ali Sajassi (sajassi) >> Sent: Wednesday, November 14, 2012 1:25 PM >> To: Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >>=20 >>=20 >>=20 >> On 11/14/12 12:18 PM, "Lucy yong" wrote: >>=20 >> >Hi Ali, >> > >> >> >> >> >1) in section 4.3, Text: The latter scenario often means that >> >> requiring a >> >> >dedicated >> >> > link between the PEs, for the operation of the multi-homing >> >> mechanism, >> >> >is not appealing from cost standpoint. >> >> > >> >> >Comment: a dedicated link between PEs. will this link is in IGP >> link >> >> too? >> >> >or private link. >> >> >May PE nodes that are multi-homed to a same CE be different ASes? >> If >> >> yes, >> >> >state it out. >> >> > >> >> >> >> Resolution: no change to the text. >> >> The draft states that having such a dedicated link (which is not an >> >> IGP >> >> link) is not desirable and thus cannot be assumed that such link >> exist. >> >> >> >[Lucy] As Wim suggested, it is better to delete the following sentence >> >in section 4.3 because it does not serve any requirement and brings a >> >confusion. >> > >> > The latter scenario often means that requiring a dedicated >> > link between the PEs, for the operation of the multi-homing >> >mechanism, is not appealing from cost standpoint. >>=20 >> I am adding the following two bullets, as further clarification, to >> sec. >> 4.3: >>=20 >> A solution MUST support active/active multi-homing without the need >> for a dedicated control/data link among the PEs in the multi-homed >> group. >>=20 >> A solution MUST NOT assume that the IGP cost from a remote PE to >> each >> of the PEs in the multi-homed group is the same. >>=20 >> Cheers, >>=20 >> Ali >>=20 >> > >> >Should we explicitly say if PEs associated with a multi-homed setup >> >have to be in the same IGP or not in different IGPs, i.e. different >> >ASes? The following sentence implicitly state that. >> > >> >Furthermore, the IGP cost from remote PEs to the pair of PEs in the >> >multi-homed setup >> > cannot be assumed to be the same when those latter PEs are geo- >> > redundant. >> > >> >Regards, >> >Lucy >> >> >2) in section 4.6, the last paragraph should state a requirement >> for >> >> flow >> >> >based load balance. >> >> > >> >> >> >> Resolution: Agreed, we add flow-based LB to the text. >> >> >> >> >3) It should add one requirement in supporting Ethernet L2VPN >> across >> >> >multi-ASes >> >> > >> >> >> >> Resolution: Agreed, we'll add that. >> >> >> >> >> >> >4) As the draft mentioned, the new service interfaces are required >> >> >for >> >> DC >> >> >interconnection. If DC uses NVo3 in future, will these service >> >> interfaces >> >> >are still necessary? Suggest giving some use cases where the new >> >> service >> >> >interfaces are necessary in an appendix. >> >> > >> >> > >> >> >> >> Resolution: No change, as clarified in the email thread. >> >> >> >> Cheers, >> >> Ali >> >> >> >> >> >> >> >> >> >> On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" >> >> wrote: >> >> >> >> >Lucy, sure and this evolution into MEF is most likely to come, but >> I >> >> >believe it is a clear req for EVPN, so I believe we can close this >> >> point >> >> > >> >> >On 05/11/12 15:58, "Lucy yong" wrote: >> >> > >> >> >>Wim, >> >> >> >> >> >>I agree that we (IETF) don't have make ourselves dependent on MEF. >> >> >>However, there are a lot of service providers in MEF to specify >> >> Ethernet >> >> >>services and service interfaces. Such service interface has not >> yet >> >> to >> >> >>bring on the table there. This may be because the people in two >> >> >>SDOs >> >> may >> >> >>be from different orgs.. >> >> >> >> >> >>Thanks, >> >> >>Lucy >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> >> lucent.com] >> >> >>> Sent: Monday, November 05, 2012 10:15 AM >> >> >>> To: Lucy yong; l2vpn@ietf.org >> >> >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >> >> >>> >> >> >>> -- Snip -- >> >> >>> >> >> >>> [Lucy] OK. Maybe I did not follow the early requirement >> discussions. >> >> >>> Where >> >> >>> was this requirement coming from. MEF Services do not support >> >> >>> such service interface. Was this from some operators in IETF? I >> >> >>> just like to >> >> know a >> >> >>> use >> >> >>> case if possible. >> >> >>> >> >> >>> >> >> >>> WH> yes this is from operators of which some are on the co- >> author >> >> list. >> >> >>> The driver for this is more optimised and scalable >> implementations. >> >> MEF >> >> >>> might adopt this going fwd, so we should not make ourselves >> >> dependent >> >> >>> on >> >> >>> MEF >> >> >>> >> >> >>> -- Snip -- >> >> >>> >> >> >>> On 05/11/12 11:09, "Lucy yong" wrote: >> >> >>> >> >> >>> > >> >> >>> > >> >> >>> >snip >> >> >>> >> >[Lucy] My second question is if PE nodes that are multi- >> homed >> >> to a >> >> >>> >> same >> >> >>> >> >CE may be in different ASes in latter case? Whether yes, or >> >> >>> >> >no, >> >> it >> >> >>> >> should >> >> >>> >> >state it out. >> >> >>> >> >> >> >>> >> WH2> this seems like an odd scenario >> >> >>> >[Lucy] agree. >> >> >>> >> > >> >> >>> >> >> > >> >> >>> >> >> >2) in section 4.6, the last paragraph should state a >> >> requirement >> >> >>> >> for >> >> >>> >> >> flow >> >> >>> >> >> >based load balance. >> >> >>> >> >> >> >> >>> >> >> WH> are you saying the Mac based load-balancing is a MUST >> >> >>> >> >> WH> or >> >> are >> >> >>> you >> >> >>> >> >> saying the MAC based load-balancing should be flow based >> >> >>> >> >[Lucy] Text: A solution MAY support multi-homed network >> with >> >> >>> >> >active/active MAC- >> >> >>> >> > based load balancing (i.e. different MAC addresses on a >> >> >>> >> >VLAN >> >> are >> >> >>> >> > reachable via different PEs). >> >> >>> >> > >> >> >>> >> >In section 4.1, it describes options for flow-based load >> >> balancing, >> >> >>> >> that >> >> >>> >> >should apply to here, right? >> >> >>> >> >That means the same MAC address may occur on the different >> >> >>> >> >PEs >> >> too. >> >> >>> >> WH2> yes >> >> >>> >> > >> >> >>> >> >> > >> >> >>> >> >> >3) It should add one requirement in supporting Ethernet >> >> L2VPN >> >> >>> >> across >> >> >>> >> >> >multi-Ases >> >> >>> >> >> >> >> >>> >> >> WH> agreed >> >> >>> >> >> > >> >> >>> >> >> >4) As the draft mentioned, the new service interfaces are >> >> >>> required >> >> >>> >> for >> >> >>> >> >> DC >> >> >>> >> >> >interconnection. If DC uses NVo3 in future, will these >> >> service >> >> >>> >> >> interfaces >> >> >>> >> >> >are still necessary? Suggest giving some use cases where >> >> >>> >> >> >the >> >> new >> >> >>> >> >> service >> >> >>> >> >> >interfaces are necessary in an appendix. >> >> >>> >> >> WH> it depends on what use case we have in NVO3: is the >> NVE >> >> >>> >> collocated >> >> >>> >> >> with the VM or is the NVE located at a TOR connected to a >> >> server. >> >> >>> >> >> Depending on the connectivity different solutions might be >> >> >>> required >> >> >>> >> and >> >> >>> >> >> as >> >> >>> >> >> such we made the requirement general and not specific >> since >> >> there >> >> >>> is >> >> >>> >> >> multiple solutions to this and this is a requirements >> draft >> >> >>> rather >> >> >>> >> than >> >> >>> >> >> solution draft. Use case should be covered in a separate >> doc. >> >> >>> >> >[Lucy] It, I think, is more about cases between DC GW and >> WAN >> >> PE. >> >> >>> For >> >> >>> >> >example, if NVO3 is used in DC, when we need VLAN aware >> >> >>> >> >bundle >> >> >>> service >> >> >>> >> >interface? Could you give a example? I don't have a problem >> >> >>> >> >to >> >> make >> >> >>> a >> >> >>> >> >general requirement, just want know where is the requirement >> >> coming >> >> >>> >> from. >> >> >>> >> > >> >> >>> >> >Lucy >> >> >>> >> >> >> >>> >> WH2> the service interface we are talking about here is how >> >> >>> >> WH2> the >> >> EVPN >> >> >>> >> service is modelled on the DC GW/WAN PE. There are multiple >> >> >>> scenarios >> >> >>> >> which should be supported. The service interface here is an >> >> internal >> >> >>> >> modelling of the EVPN on the PE >> >> >>> >[Lucy] OK. Maybe I did not follow the early requirement >> >> discussions. >> >> >>> >Where was this requirement coming from. MEF Services do not >> >> support >> >> >>> such >> >> >>> >service interface. Was this from some operators in IETF? I just >> >> like >> >> >>> to >> >> >>> >know a use case if possible. >> >> >>> > >> >> >>> >Lucy >> >> >>> >> >> > >> >> >>> >> >> >Cheers, >> >> >>> >> >> >Lucy >> >> >>> >> >> > >> >> >>> >> >> >> ------------------------------ >> >> >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >> >> >>> >> >> >> From: Giles Heron >> >> >>> >> >> >> To: "l2vpn@ietf.org" >> >> >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >> >> >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- >> >> FBBEDB84BC32@gmail.com> >> >> >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii >> >> >>> >> >> >> >> >> >>> >> >> >> This email initiates an L2VPN WG Last Call for: >> >> >>> >> >> >> >> >> >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >> >> >>> >> >> >> >> >> >>> >> >> >> please comment to the list as to the suitability of >> this >> >> draft >> >> >>> >> for >> >> >>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. >> >> >>> >> >> >> >> >> >>> >> >> >> this last call will close on Friday 2nd November. >> >> >>> >> >> >> >> >> >>> >> >> >> Nabil & Giles >> >> >>> >> >> > >> >> >>> >> > >> >> >>> > >> >> >> >> >> > >> > >>=20 > > From lucy.yong@huawei.com Wed Nov 14 13:44: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 E18C121F84E2 for ; Wed, 14 Nov 2012 13:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 7nYiKBclXown for ; Wed, 14 Nov 2012 13:44:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED20C21F8490 for ; Wed, 14 Nov 2012 13:44:56 -0800 (PST) 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 AMU67629; Wed, 14 Nov 2012 21:44:55 +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; Wed, 14 Nov 2012 21:44:42 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 05:44:54 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 14 Nov 2012 13:44:47 -0800 From: Lucy yong To: "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAA/LkAABCgZoD//4AYgIAAgh8Q//+UWQCAAISrIA== Date: Wed, 14 Nov 2012 21:44:46 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44830805@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D44830750@dfweml505-mbx> <69670F7146898C4583F56DA9AD32F77B0D7A3075@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7A3075@xmb-aln-x13.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.79] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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: Wed, 14 Nov 2012 21:44:59 -0000 Hi Ali, What you say is that two PEs participate G.8032 enabled Ethernet Ring Prote= ction or two bridges that participate a Ethernet Ring Protection connect to= two PEs respectively.=20 Lucy > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Wednesday, November 14, 2012 3:30 PM > To: Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org > Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 > Hi Lucy, >=20 > When a G.8032 is dual-homed to a pair of PEs, you can have a scenario > in > which different set of MAC addresses for the same VLAN are learned by > each > of the PEs in the dual-homed group and thus the requirement in this > section. >=20 > Cheers, > Ali >=20 > On 11/14/12 12:29 PM, "Lucy yong" wrote: >=20 > >Hi Ali, > > > >I see your point. However, both 802.1Q and G.8032 do not support > >active-active multi-homed links. Now, I am confused with this > requirement > >in section 4.6. > > > > A solution MUST also support multi-homed network with active/active > > VLAN-based load balancing (i.e. disjoint VLAN sets active on > > disparate PEs). > > > >Where is the requirement coming from. It is not from 802.1Q and G.8032. > I > >don't know how Ethernet network will handle it. > > > >Lucy > > > >> -----Original Message----- > >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > >> Sent: Wednesday, November 14, 2012 2:10 PM > >> To: Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org > >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > >> > >> Hi Lucy, > >> > >> Yes, the load balancing function should depend on whether we are > >> talking > >> about MHD or MHN. In case of MHD, LACP provides per-flow load > balancing. > >> However, in case of MHN, 802.1Q expects load balancing on a per-VLAN > >> basis > >> and G.8032 can expect load balancing on a per-MAC basis (for a given > >> VLAN). > >> > >> Cheers, > >> Ali > >> > >> the paragraph intentionally excludes that as I cannot see of any > >> application that requires it > >> > >> On 11/14/12 12:02 PM, "Lucy yong" wrote: > >> > >> >Hi Ali, > >> > > >> >The last paragraph in section 4.6 > >> > > >> > A solution MAY support multi-homed network with active/active > MAC- > >> > based load balancing (i.e. different MAC addresses on a VLAN are > >> > reachable via different PEs). > >> > > >> >Should the load balancing function depend on whether dual-homed > >> network > >> >or dual homed device? IMO: it is not. We should not exclude that > the > >> >packets with the same MAC address appear on the different PEs. But > the > >> >paragraph seems exclude that. That is my point. > >> > > >> >Regards, > >> >Lucy > >> > > >> >> -----Original Message----- > >> >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > >> >> Sent: Wednesday, November 14, 2012 1:51 PM > >> >> To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); Lucy yong; > >> >> l2vpn@ietf.org > >> >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > >> >> > >> >> > >> >> > >> >> Revision to one of the resolution =A9 > >> >> > >> >> > >> >> > > >> >> >>2) in section 4.6, the last paragraph should state a > requirement > >> for > >> >> flow > >> >> >>based load balance. > >> >> >> > >> >> > > >> >> >Resolution: Agreed, we add flow-based LB to the text. > >> >> > >> >> > >> >> Section 4.6 talks about dual-homed network and NOT dual-homed > device. > >> >> As > >> >> such, no application has been identified that requires flow-based > >> load > >> >> balancing for multi-homed network! In other words, a network > based > >> on > >> >> 802.1Q or G.8032 does not need flow-baesd LB. > >> >> > >> >> > >> >> Therefore, we will not add such requirement to section 4.6. > >> >> > >> >> Cheers, > >> >> Ali > >> > > > From lucy.yong@huawei.com Thu Nov 15 08:02: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 812AB21F8514 for ; Thu, 15 Nov 2012 08:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 mrKvhF6Z5GMz for ; Thu, 15 Nov 2012 08:02:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 33FCB21F8513 for ; Thu, 15 Nov 2012 08:02:27 -0800 (PST) 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 ALP36244; Thu, 15 Nov 2012 16:02:24 +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; Thu, 15 Nov 2012 16:02:06 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 16:02:21 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 08:02:18 -0800 From: Lucy yong To: John E Drake , "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAPRT5A//+ktQD//02+IA== Date: Thu, 15 Nov 2012 16:02:17 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44830B7A@dfweml505-mbx> References: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> <0182DEA5604B3A44A2EE61F3EE3ED69E07E6D415@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E07E6D415@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Thu, 15 Nov 2012 16:02:29 -0000 Hi John, Regarding if EVPN allows two PEs in different ASes to be homed to the same = CE, this is my original question on the last call of evpn req.. The current= document does not make it clear.=20 If this is the case, should we state that PEs that are homed to the same CE= may be in the AS or different ASes in the document to make it clear? Thanks, Lucy > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Wednesday, November 14, 2012 3:14 PM > To: Lucy yong; Ali Sajassi (sajassi); Henderickx, Wim (Wim); > l2vpn@ietf.org > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 > Lucy, >=20 > There should not be a requirement that two or more PEs providing multi- > homing to the same CE need to be in the same IGP. This is too > restrictive and totally unnecessary. >=20 > Irrespectively Yours, >=20 > John >=20 >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of Lucy yong > > Sent: Wednesday, November 14, 2012 12:19 PM > > To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); l2vpn@ietf.org > > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > Hi Ali, > > > > > > > > >1) in section 4.3, Text: The latter scenario often means that > > > requiring a > > > >dedicated > > > > link between the PEs, for the operation of the multi-homing > > > mechanism, > > > >is not appealing from cost standpoint. > > > > > > > >Comment: a dedicated link between PEs. will this link is in IGP > link > > > too? > > > >or private link. > > > >May PE nodes that are multi-homed to a same CE be different ASes? > If > > > yes, > > > >state it out. > > > > > > > > > > Resolution: no change to the text. > > > The draft states that having such a dedicated link (which is not an > > > IGP > > > link) is not desirable and thus cannot be assumed that such link > > exist. > > > > > [Lucy] As Wim suggested, it is better to delete the following > sentence > > in section 4.3 because it does not serve any requirement and brings a > > confusion. > > > > The latter scenario often means that requiring a dedicated > > link between the PEs, for the operation of the multi-homing > > mechanism, is not appealing from cost standpoint. > > > > Should we explicitly say if PEs associated with a multi-homed setup > > have to be in the same IGP or not in different IGPs, i.e. different > > ASes? The following sentence implicitly state that. > > > > Furthermore, the IGP cost from remote PEs to the pair of PEs in the > > multi-homed setup > > cannot be assumed to be the same when those latter PEs are geo- > > redundant. > > > > Regards, > > Lucy > > > >2) in section 4.6, the last paragraph should state a requirement > for > > > flow > > > >based load balance. > > > > > > > > > > Resolution: Agreed, we add flow-based LB to the text. > > > > > > >3) It should add one requirement in supporting Ethernet L2VPN > across > > > >multi-ASes > > > > > > > > > > Resolution: Agreed, we'll add that. > > > > > > > > > >4) As the draft mentioned, the new service interfaces are required > > > >for > > > DC > > > >interconnection. If DC uses NVo3 in future, will these service > > > interfaces > > > >are still necessary? Suggest giving some use cases where the new > > > service > > > >interfaces are necessary in an appendix. > > > > > > > > > > > > > > Resolution: No change, as clarified in the email thread. > > > > > > Cheers, > > > Ali > > > > > > > > > > > > > > > On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > > > wrote: > > > > > > >Lucy, sure and this evolution into MEF is most likely to come, but > I > > > >believe it is a clear req for EVPN, so I believe we can close this > > > point > > > > > > > >On 05/11/12 15:58, "Lucy yong" wrote: > > > > > > > >>Wim, > > > >> > > > >>I agree that we (IETF) don't have make ourselves dependent on MEF. > > > >>However, there are a lot of service providers in MEF to specify > > > Ethernet > > > >>services and service interfaces. Such service interface has not > yet > > > to > > > >>bring on the table there. This may be because the people in two > > SDOs > > > may > > > >>be from different orgs.. > > > >> > > > >>Thanks, > > > >>Lucy > > > >> > > > >>> -----Original Message----- > > > >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > > lucent.com] > > > >>> Sent: Monday, November 05, 2012 10:15 AM > > > >>> To: Lucy yong; l2vpn@ietf.org > > > >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > > > >>> > > > >>> -- Snip -- > > > >>> > > > >>> [Lucy] OK. Maybe I did not follow the early requirement > > discussions. > > > >>> Where > > > >>> was this requirement coming from. MEF Services do not support > > such > > > >>> service interface. Was this from some operators in IETF? I just > > > >>> like to > > > know a > > > >>> use > > > >>> case if possible. > > > >>> > > > >>> > > > >>> WH> yes this is from operators of which some are on the co- > author > > > list. > > > >>> The driver for this is more optimised and scalable > > implementations. > > > MEF > > > >>> might adopt this going fwd, so we should not make ourselves > > > dependent > > > >>> on > > > >>> MEF > > > >>> > > > >>> -- Snip -- > > > >>> > > > >>> On 05/11/12 11:09, "Lucy yong" wrote: > > > >>> > > > >>> > > > > >>> > > > > >>> >snip > > > >>> >> >[Lucy] My second question is if PE nodes that are multi- > homed > > > to a > > > >>> >> same > > > >>> >> >CE may be in different ASes in latter case? Whether yes, or > > > >>> >> >no, > > > it > > > >>> >> should > > > >>> >> >state it out. > > > >>> >> > > > >>> >> WH2> this seems like an odd scenario > > > >>> >[Lucy] agree. > > > >>> >> > > > > >>> >> >> > > > > >>> >> >> >2) in section 4.6, the last paragraph should state a > > > requirement > > > >>> >> for > > > >>> >> >> flow > > > >>> >> >> >based load balance. > > > >>> >> >> > > > >>> >> >> WH> are you saying the Mac based load-balancing is a MUST > > or > > > are > > > >>> you > > > >>> >> >> saying the MAC based load-balancing should be flow based > > > >>> >> >[Lucy] Text: A solution MAY support multi-homed network > > with > > > >>> >> >active/active MAC- > > > >>> >> > based load balancing (i.e. different MAC addresses on a > > > >>> >> >VLAN > > > are > > > >>> >> > reachable via different PEs). > > > >>> >> > > > > >>> >> >In section 4.1, it describes options for flow-based load > > > balancing, > > > >>> >> that > > > >>> >> >should apply to here, right? > > > >>> >> >That means the same MAC address may occur on the different > > PEs > > > too. > > > >>> >> WH2> yes > > > >>> >> > > > > >>> >> >> > > > > >>> >> >> >3) It should add one requirement in supporting Ethernet > > > L2VPN > > > >>> >> across > > > >>> >> >> >multi-Ases > > > >>> >> >> > > > >>> >> >> WH> agreed > > > >>> >> >> > > > > >>> >> >> >4) As the draft mentioned, the new service interfaces > are > > > >>> required > > > >>> >> for > > > >>> >> >> DC > > > >>> >> >> >interconnection. If DC uses NVo3 in future, will these > > > service > > > >>> >> >> interfaces > > > >>> >> >> >are still necessary? Suggest giving some use cases where > > > >>> >> >> >the > > > new > > > >>> >> >> service > > > >>> >> >> >interfaces are necessary in an appendix. > > > >>> >> >> WH> it depends on what use case we have in NVO3: is the > NVE > > > >>> >> collocated > > > >>> >> >> with the VM or is the NVE located at a TOR connected to a > > > server. > > > >>> >> >> Depending on the connectivity different solutions might > be > > > >>> required > > > >>> >> and > > > >>> >> >> as > > > >>> >> >> such we made the requirement general and not specific > since > > > there > > > >>> is > > > >>> >> >> multiple solutions to this and this is a requirements > draft > > > >>> rather > > > >>> >> than > > > >>> >> >> solution draft. Use case should be covered in a separate > > doc. > > > >>> >> >[Lucy] It, I think, is more about cases between DC GW and > WAN > > > PE. > > > >>> For > > > >>> >> >example, if NVO3 is used in DC, when we need VLAN aware > > bundle > > > >>> service > > > >>> >> >interface? Could you give a example? I don't have a problem > > to > > > make > > > >>> a > > > >>> >> >general requirement, just want know where is the > requirement > > > coming > > > >>> >> from. > > > >>> >> > > > > >>> >> >Lucy > > > >>> >> > > > >>> >> WH2> the service interface we are talking about here is how > > the > > > EVPN > > > >>> >> service is modelled on the DC GW/WAN PE. There are multiple > > > >>> scenarios > > > >>> >> which should be supported. The service interface here is an > > > internal > > > >>> >> modelling of the EVPN on the PE > > > >>> >[Lucy] OK. Maybe I did not follow the early requirement > > > discussions. > > > >>> >Where was this requirement coming from. MEF Services do not > > > support > > > >>> such > > > >>> >service interface. Was this from some operators in IETF? I > just > > > like > > > >>> to > > > >>> >know a use case if possible. > > > >>> > > > > >>> >Lucy > > > >>> >> >> > > > > >>> >> >> >Cheers, > > > >>> >> >> >Lucy > > > >>> >> >> > > > > >>> >> >> >> ------------------------------ > > > >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > > > >>> >> >> >> From: Giles Heron > > > >>> >> >> >> To: "l2vpn@ietf.org" > > > >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > > > >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- > > > FBBEDB84BC32@gmail.com> > > > >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii > > > >>> >> >> >> > > > >>> >> >> >> This email initiates an L2VPN WG Last Call for: > > > >>> >> >> >> > > > >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req- > 01 > > > >>> >> >> >> > > > >>> >> >> >> please comment to the list as to the suitability of > this > > > draft > > > >>> >> for > > > >>> >> >> >> publication as a Standards Track RFC from the L2VPN WG. > > > >>> >> >> >> > > > >>> >> >> >> this last call will close on Friday 2nd November. > > > >>> >> >> >> > > > >>> >> >> >> Nabil & Giles > > > >>> >> >> > > > > >>> >> > > > > >>> > > > > >> > > > > > > >=20 From jdrake@juniper.net Thu Nov 15 09:18:53 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A0C21F8993 for ; Thu, 15 Nov 2012 09:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=1.508, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 5hD137p2bFwK for ; Thu, 15 Nov 2012 09:18:52 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id F3A8421F8992 for ; Thu, 15 Nov 2012 09:18:51 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUKUj+9qGtStbzmXdWyxFcKEMLlDqqafc@postini.com; Thu, 15 Nov 2012 09:18:52 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 15 Nov 2012 09:15:52 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 15 Nov 2012 09:15:51 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.142) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 15 Nov 2012 09:22:47 -0800 Received: from mail13-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Nov 2012 17:15:50 +0000 Received: from mail13-db3 (localhost [127.0.0.1]) by mail13-db3-R.bigfish.com (Postfix) with ESMTP id CDF573002DF for ; Thu, 15 Nov 2012 17:15:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I542M1432I4015Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received: from mail13-db3 (localhost.localdomain [127.0.0.1]) by mail13-db3 (MessageSwitch) id 1352999747813852_19686; Thu, 15 Nov 2012 17:15:47 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.253]) by mail13-db3.bigfish.com (Postfix) with ESMTP id B93532600A5; Thu, 15 Nov 2012 17:15:47 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Nov 2012 17:15:45 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.40]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0233.002; Thu, 15 Nov 2012 17:15:44 +0000 From: John E Drake To: Lucy yong , "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgAAq3wCAAE/VAIAAfFoAgABl/wCAAAFyAIAAT1OAgAAAfICADgnVAIAAD4gAgAAOdBCAATxEgIAAFDMg Date: Thu, 15 Nov 2012 17:15:42 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E07E6E54A@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> <0182DEA5604B3A44A2EE61F3EE3ED69E07E6D415@BL2PRD0510MB349.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D44830B7A@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44830B7A@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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, 15 Nov 2012 17:18:53 -0000 Lucy, I don't want to slow things down but I think such a statement would be extr= emely helpful. Irrespectively Yours, John > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Thursday, November 15, 2012 8:02 AM > To: John E Drake; Ali Sajassi (sajassi); Henderickx, Wim (Wim); > l2vpn@ietf.org > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 > Hi John, >=20 > Regarding if EVPN allows two PEs in different ASes to be homed to the > same CE, this is my original question on the last call of evpn req.. > The current document does not make it clear. >=20 > If this is the case, should we state that PEs that are homed to the > same CE may be in the AS or different ASes in the document to make it > clear? >=20 > Thanks, > Lucy >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf > > Of John E Drake > > Sent: Wednesday, November 14, 2012 3:14 PM > > To: Lucy yong; Ali Sajassi (sajassi); Henderickx, Wim (Wim); > > l2vpn@ietf.org > > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > Lucy, > > > > There should not be a requirement that two or more PEs providing > > multi- homing to the same CE need to be in the same IGP. This is too > > restrictive and totally unnecessary. > > > > Irrespectively Yours, > > > > John > > > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of Lucy yong > > > Sent: Wednesday, November 14, 2012 12:19 PM > > > To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); l2vpn@ietf.org > > > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > > > Hi Ali, > > > > > > > > > > > >1) in section 4.3, Text: The latter scenario often means that > > > > requiring a > > > > >dedicated > > > > > link between the PEs, for the operation of the multi-homing > > > > mechanism, > > > > >is not appealing from cost standpoint. > > > > > > > > > >Comment: a dedicated link between PEs. will this link is in IGP > > link > > > > too? > > > > >or private link. > > > > >May PE nodes that are multi-homed to a same CE be different > ASes? > > If > > > > yes, > > > > >state it out. > > > > > > > > > > > > > Resolution: no change to the text. > > > > The draft states that having such a dedicated link (which is not > > > > an IGP > > > > link) is not desirable and thus cannot be assumed that such link > > > exist. > > > > > > > [Lucy] As Wim suggested, it is better to delete the following > > sentence > > > in section 4.3 because it does not serve any requirement and brings > > > a confusion. > > > > > > The latter scenario often means that requiring a dedicated > > > link between the PEs, for the operation of the multi-homing > > > mechanism, is not appealing from cost standpoint. > > > > > > Should we explicitly say if PEs associated with a multi-homed setup > > > have to be in the same IGP or not in different IGPs, i.e. different > > > ASes? The following sentence implicitly state that. > > > > > > Furthermore, the IGP cost from remote PEs to the pair of PEs in the > > > multi-homed setup > > > cannot be assumed to be the same when those latter PEs are geo- > > > redundant. > > > > > > Regards, > > > Lucy > > > > >2) in section 4.6, the last paragraph should state a requirement > > for > > > > flow > > > > >based load balance. > > > > > > > > > > > > > Resolution: Agreed, we add flow-based LB to the text. > > > > > > > > >3) It should add one requirement in supporting Ethernet L2VPN > > across > > > > >multi-ASes > > > > > > > > > > > > > Resolution: Agreed, we'll add that. > > > > > > > > > > > > >4) As the draft mentioned, the new service interfaces are > > > > >required for > > > > DC > > > > >interconnection. If DC uses NVo3 in future, will these service > > > > interfaces > > > > >are still necessary? Suggest giving some use cases where the new > > > > service > > > > >interfaces are necessary in an appendix. > > > > > > > > > > > > > > > > > > Resolution: No change, as clarified in the email thread. > > > > > > > > Cheers, > > > > Ali > > > > > > > > > > > > > > > > > > > > On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > > > > wrote: > > > > > > > > >Lucy, sure and this evolution into MEF is most likely to come, > > > > >but > > I > > > > >believe it is a clear req for EVPN, so I believe we can close > > > > >this > > > > point > > > > > > > > > >On 05/11/12 15:58, "Lucy yong" wrote: > > > > > > > > > >>Wim, > > > > >> > > > > >>I agree that we (IETF) don't have make ourselves dependent on > MEF. > > > > >>However, there are a lot of service providers in MEF to specify > > > > Ethernet > > > > >>services and service interfaces. Such service interface has not > > yet > > > > to > > > > >>bring on the table there. This may be because the people in two > > > SDOs > > > > may > > > > >>be from different orgs.. > > > > >> > > > > >>Thanks, > > > > >>Lucy > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > > > lucent.com] > > > > >>> Sent: Monday, November 05, 2012 10:15 AM > > > > >>> To: Lucy yong; l2vpn@ietf.org > > > > >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > >>> > > > > >>> -- Snip -- > > > > >>> > > > > >>> [Lucy] OK. Maybe I did not follow the early requirement > > > discussions. > > > > >>> Where > > > > >>> was this requirement coming from. MEF Services do not support > > > such > > > > >>> service interface. Was this from some operators in IETF? I > > > > >>> just like to > > > > know a > > > > >>> use > > > > >>> case if possible. > > > > >>> > > > > >>> > > > > >>> WH> yes this is from operators of which some are on the co- > > author > > > > list. > > > > >>> The driver for this is more optimised and scalable > > > implementations. > > > > MEF > > > > >>> might adopt this going fwd, so we should not make ourselves > > > > dependent > > > > >>> on > > > > >>> MEF > > > > >>> > > > > >>> -- Snip -- > > > > >>> > > > > >>> On 05/11/12 11:09, "Lucy yong" wrote: > > > > >>> > > > > >>> > > > > > >>> > > > > > >>> >snip > > > > >>> >> >[Lucy] My second question is if PE nodes that are multi- > > homed > > > > to a > > > > >>> >> same > > > > >>> >> >CE may be in different ASes in latter case? Whether yes, > > > > >>> >> >or no, > > > > it > > > > >>> >> should > > > > >>> >> >state it out. > > > > >>> >> > > > > >>> >> WH2> this seems like an odd scenario > > > > >>> >[Lucy] agree. > > > > >>> >> > > > > > >>> >> >> > > > > > >>> >> >> >2) in section 4.6, the last paragraph should state a > > > > requirement > > > > >>> >> for > > > > >>> >> >> flow > > > > >>> >> >> >based load balance. > > > > >>> >> >> > > > > >>> >> >> WH> are you saying the Mac based load-balancing is a > > > > >>> >> >> WH> MUST > > > or > > > > are > > > > >>> you > > > > >>> >> >> saying the MAC based load-balancing should be flow > based > > > > >>> >> >[Lucy] Text: A solution MAY support multi-homed network > > > with > > > > >>> >> >active/active MAC- > > > > >>> >> > based load balancing (i.e. different MAC addresses on > a > > > > >>> >> >VLAN > > > > are > > > > >>> >> > reachable via different PEs). > > > > >>> >> > > > > > >>> >> >In section 4.1, it describes options for flow-based load > > > > balancing, > > > > >>> >> that > > > > >>> >> >should apply to here, right? > > > > >>> >> >That means the same MAC address may occur on the > different > > > PEs > > > > too. > > > > >>> >> WH2> yes > > > > >>> >> > > > > > >>> >> >> > > > > > >>> >> >> >3) It should add one requirement in supporting > Ethernet > > > > L2VPN > > > > >>> >> across > > > > >>> >> >> >multi-Ases > > > > >>> >> >> > > > > >>> >> >> WH> agreed > > > > >>> >> >> > > > > > >>> >> >> >4) As the draft mentioned, the new service interfaces > > are > > > > >>> required > > > > >>> >> for > > > > >>> >> >> DC > > > > >>> >> >> >interconnection. If DC uses NVo3 in future, will these > > > > service > > > > >>> >> >> interfaces > > > > >>> >> >> >are still necessary? Suggest giving some use cases > > > > >>> >> >> >where the > > > > new > > > > >>> >> >> service > > > > >>> >> >> >interfaces are necessary in an appendix. > > > > >>> >> >> WH> it depends on what use case we have in NVO3: is the > > NVE > > > > >>> >> collocated > > > > >>> >> >> with the VM or is the NVE located at a TOR connected to > > > > >>> >> >> a > > > > server. > > > > >>> >> >> Depending on the connectivity different solutions might > > be > > > > >>> required > > > > >>> >> and > > > > >>> >> >> as > > > > >>> >> >> such we made the requirement general and not specific > > since > > > > there > > > > >>> is > > > > >>> >> >> multiple solutions to this and this is a requirements > > draft > > > > >>> rather > > > > >>> >> than > > > > >>> >> >> solution draft. Use case should be covered in a > separate > > > doc. > > > > >>> >> >[Lucy] It, I think, is more about cases between DC GW and > > WAN > > > > PE. > > > > >>> For > > > > >>> >> >example, if NVO3 is used in DC, when we need VLAN aware > > > bundle > > > > >>> service > > > > >>> >> >interface? Could you give a example? I don't have a > > > > >>> >> >problem > > > to > > > > make > > > > >>> a > > > > >>> >> >general requirement, just want know where is the > > requirement > > > > coming > > > > >>> >> from. > > > > >>> >> > > > > > >>> >> >Lucy > > > > >>> >> > > > > >>> >> WH2> the service interface we are talking about here is > how > > > the > > > > EVPN > > > > >>> >> service is modelled on the DC GW/WAN PE. There are > multiple > > > > >>> scenarios > > > > >>> >> which should be supported. The service interface here is > an > > > > internal > > > > >>> >> modelling of the EVPN on the PE > > > > >>> >[Lucy] OK. Maybe I did not follow the early requirement > > > > discussions. > > > > >>> >Where was this requirement coming from. MEF Services do not > > > > support > > > > >>> such > > > > >>> >service interface. Was this from some operators in IETF? I > > just > > > > like > > > > >>> to > > > > >>> >know a use case if possible. > > > > >>> > > > > > >>> >Lucy > > > > >>> >> >> > > > > > >>> >> >> >Cheers, > > > > >>> >> >> >Lucy > > > > >>> >> >> > > > > > >>> >> >> >> ------------------------------ > > > > >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > > > > >>> >> >> >> From: Giles Heron > > > > >>> >> >> >> To: "l2vpn@ietf.org" > > > > >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- > > > > FBBEDB84BC32@gmail.com> > > > > >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii > > > > >>> >> >> >> > > > > >>> >> >> >> This email initiates an L2VPN WG Last Call for: > > > > >>> >> >> >> > > > > >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn- > req- > > 01 > > > > >>> >> >> >> > > > > >>> >> >> >> please comment to the list as to the suitability of > > this > > > > draft > > > > >>> >> for > > > > >>> >> >> >> publication as a Standards Track RFC from the L2VPN > WG. > > > > >>> >> >> >> > > > > >>> >> >> >> this last call will close on Friday 2nd November. > > > > >>> >> >> >> > > > > >>> >> >> >> Nabil & Giles > > > > >>> >> >> > > > > > >>> >> > > > > > >>> > > > > > >> > > > > > > > > > > >=20 From sajassi@cisco.com Thu Nov 15 09:40:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3891C21F8417 for ; Thu, 15 Nov 2012 09:40:49 -0800 (PST) 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 fdtaudBEBXo6 for ; Thu, 15 Nov 2012 09:40:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B3F0321F89D5 for ; Thu, 15 Nov 2012 09:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4338; q=dns/txt; s=iport; t=1353001248; x=1354210848; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=YoPRVfXv2SnU6OONwWDs9QOds8UeqTAUs1iHBmXh3n8=; b=d1qOiJNwHKwnFYzYQBf65bLmeIo08UOzhMQ8EO8BcGFCP7ijucGAIWBI 7DfrUCQICEbF41v2dJq8bp3mBOksiBOtH91CEw8mVrEf+NcMjHWmL5/d3 P0lq/PHQlnnt/WCt67RJnE9og3JM18iCwADZvF7I5vGCOk/5uUnih+drk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJwnpVCtJV2b/2dsb2JhbABEgmy/UIEIgh4BAQEEDgQBCkggBgEIEQQBAQEKHTkUCQgCBAESCBMHh2sBnHegDYwxhUthA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="139861438" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 15 Nov 2012 17:40:46 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAFHektq027529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 17:40:46 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 11:40:45 -0600 From: "Ali Sajassi (sajassi)" To: Lucy yong , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACPdACAAE/VAIAAfFoAgABmAACAAAFxAIAAT1SAgAAAfICADYO2gIAAB+aAgACJJQD//3v3AIAAi5WA//+K5ACAAIo/AIAAyA2A Date: Thu, 15 Nov 2012 17:40:45 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7AB90A@xmb-aln-x13.cisco.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44830805@dfweml505-mbx> 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.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001 x-tm-as-result: No--47.542800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-2" Content-ID: <2CB8C2FA10E5FD4DBD546F3533D30A7A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 15 Nov 2012 17:40:49 -0000 Hi Lucy, I had the former one in mind. However, as long as the RPL owner is in the middle of the ring, both of the dual-homed PEs receives different set of MAC addresses for a given VLAN. Cheers, Ali=20 On 11/14/12 1:44 PM, "Lucy yong" wrote: >Hi Ali, > >What you say is that two PEs participate G.8032 enabled Ethernet Ring >Protection or two bridges that participate a Ethernet Ring Protection >connect to two PEs respectively. > >Lucy > >> -----Original Message----- >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >> Sent: Wednesday, November 14, 2012 3:30 PM >> To: Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >>=20 >> Hi Lucy, >>=20 >> When a G.8032 is dual-homed to a pair of PEs, you can have a scenario >> in >> which different set of MAC addresses for the same VLAN are learned by >> each >> of the PEs in the dual-homed group and thus the requirement in this >> section. >>=20 >> Cheers, >> Ali >>=20 >> On 11/14/12 12:29 PM, "Lucy yong" wrote: >>=20 >> >Hi Ali, >> > >> >I see your point. However, both 802.1Q and G.8032 do not support >> >active-active multi-homed links. Now, I am confused with this >> requirement >> >in section 4.6. >> > >> > A solution MUST also support multi-homed network with active/active >> > VLAN-based load balancing (i.e. disjoint VLAN sets active on >> > disparate PEs). >> > >> >Where is the requirement coming from. It is not from 802.1Q and G.8032. >> I >> >don't know how Ethernet network will handle it. >> > >> >Lucy >> > >> >> -----Original Message----- >> >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >> >> Sent: Wednesday, November 14, 2012 2:10 PM >> >> To: Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org >> >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >> >> >> >> Hi Lucy, >> >> >> >> Yes, the load balancing function should depend on whether we are >> >> talking >> >> about MHD or MHN. In case of MHD, LACP provides per-flow load >> balancing. >> >> However, in case of MHN, 802.1Q expects load balancing on a per-VLAN >> >> basis >> >> and G.8032 can expect load balancing on a per-MAC basis (for a given >> >> VLAN). >> >> >> >> Cheers, >> >> Ali >> >> >> >> the paragraph intentionally excludes that as I cannot see of any >> >> application that requires it >> >> >> >> On 11/14/12 12:02 PM, "Lucy yong" wrote: >> >> >> >> >Hi Ali, >> >> > >> >> >The last paragraph in section 4.6 >> >> > >> >> > A solution MAY support multi-homed network with active/active >> MAC- >> >> > based load balancing (i.e. different MAC addresses on a VLAN are >> >> > reachable via different PEs). >> >> > >> >> >Should the load balancing function depend on whether dual-homed >> >> network >> >> >or dual homed device? IMO: it is not. We should not exclude that >> the >> >> >packets with the same MAC address appear on the different PEs. But >> the >> >> >paragraph seems exclude that. That is my point. >> >> > >> >> >Regards, >> >> >Lucy >> >> > >> >> >> -----Original Message----- >> >> >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >> >> >> Sent: Wednesday, November 14, 2012 1:51 PM >> >> >> To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); Lucy yong; >> >> >> l2vpn@ietf.org >> >> >> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >> >> >> >> >> >> >> >> >> >> >> >> Revision to one of the resolution =A9 >> >> >> >> >> >> >> >> >> > >> >> >> >>2) in section 4.6, the last paragraph should state a >> requirement >> >> for >> >> >> flow >> >> >> >>based load balance. >> >> >> >> >> >> >> > >> >> >> >Resolution: Agreed, we add flow-based LB to the text. >> >> >> >> >> >> >> >> >> Section 4.6 talks about dual-homed network and NOT dual-homed >> device. >> >> >> As >> >> >> such, no application has been identified that requires flow-based >> >> load >> >> >> balancing for multi-homed network! In other words, a network >> based >> >> on >> >> >> 802.1Q or G.8032 does not need flow-baesd LB. >> >> >> >> >> >> >> >> >> Therefore, we will not add such requirement to section 4.6. >> >> >> >> >> >> Cheers, >> >> >> Ali >> >> > >> > > From sajassi@cisco.com Thu Nov 15 09:48:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7DA21F8BB8 for ; Thu, 15 Nov 2012 09:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 pM-iRFzf4HEd for ; Thu, 15 Nov 2012 09:48:04 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEA821F89FF for ; Thu, 15 Nov 2012 09:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12468; q=dns/txt; s=iport; t=1353001684; x=1354211284; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=blX8/X8msHlX8cUiJOfBSpTAdC/zGGaG2ZCoBdOFVa4=; b=EIO3AA7gPWi687m+MArLcnZGgSnIykBTuRSHEKpOsI8Nh8dOrxMjRmyI dDF+3W9XcNRBLXxTnYOiWenqhOGb8qKbodXxaS7LyZEEAwNZBINU+Zi3v gErFovijar2IltIDvQHx5Xq4ykCW22qMHQQwgyg1mNm5IMxK8cvGizb+Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAUqpVCtJV2Y/2dsb2JhbABEgmy/UIEIgh4BAQEEDgQBCh0rIAYBCBEDAQEBAQoUCSgRFAkIAgQBEggTB4dZAw8BCpxxligNiVSLSGmFS2EDlCeCcYoWgyaBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="142645595" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 15 Nov 2012 17:48:03 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAFHm3pq006929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 17:48:03 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 11:48:02 -0600 From: "Ali Sajassi (sajassi)" To: John E Drake , Lucy yong , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAPRT5A//+ktQD//02+IIAB4J8A//+C7wA= Date: Thu, 15 Nov 2012 17:48:02 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7AC927@xmb-aln-x13.cisco.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E07E6E54A@BL2PRD0510MB349.namprd05.prod.outlook.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.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001 x-tm-as-result: No--60.389900-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: <087D683B4E0E6B408CB10E1185F4A757@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 15 Nov 2012 17:48:06 -0000 All E-VPN attributes are transitive (including the ones uses for multi-homing), so multi-homing can span across multiple ASes. I will add a requirement in the multi-homing section to this effect. Cheers, Ali On 11/15/12 9:15 AM, "John E Drake" wrote: >Lucy, > >I don't want to slow things down but I think such a statement would be >extremely helpful. > >Irrespectively Yours, > >John > >> -----Original Message----- >> From: Lucy yong [mailto:lucy.yong@huawei.com] >> Sent: Thursday, November 15, 2012 8:02 AM >> To: John E Drake; Ali Sajassi (sajassi); Henderickx, Wim (Wim); >> l2vpn@ietf.org >> Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req >>=20 >> Hi John, >>=20 >> Regarding if EVPN allows two PEs in different ASes to be homed to the >> same CE, this is my original question on the last call of evpn req.. >> The current document does not make it clear. >>=20 >> If this is the case, should we state that PEs that are homed to the >> same CE may be in the AS or different ASes in the document to make it >> clear? >>=20 >> Thanks, >> Lucy >>=20 >> > -----Original Message----- >> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf >> > Of John E Drake >> > Sent: Wednesday, November 14, 2012 3:14 PM >> > To: Lucy yong; Ali Sajassi (sajassi); Henderickx, Wim (Wim); >> > l2vpn@ietf.org >> > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req >> > >> > Lucy, >> > >> > There should not be a requirement that two or more PEs providing >> > multi- homing to the same CE need to be in the same IGP. This is too >> > restrictive and totally unnecessary. >> > >> > Irrespectively Yours, >> > >> > John >> > >> > >> > > -----Original Message----- >> > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> > Behalf >> > > Of Lucy yong >> > > Sent: Wednesday, November 14, 2012 12:19 PM >> > > To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); l2vpn@ietf.org >> > > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req >> > > >> > > Hi Ali, >> > > >> > > > >> > > > >1) in section 4.3, Text: The latter scenario often means that >> > > > requiring a >> > > > >dedicated >> > > > > link between the PEs, for the operation of the multi-homing >> > > > mechanism, >> > > > >is not appealing from cost standpoint. >> > > > > >> > > > >Comment: a dedicated link between PEs. will this link is in IGP >> > link >> > > > too? >> > > > >or private link. >> > > > >May PE nodes that are multi-homed to a same CE be different >> ASes? >> > If >> > > > yes, >> > > > >state it out. >> > > > > >> > > > >> > > > Resolution: no change to the text. >> > > > The draft states that having such a dedicated link (which is not >> > > > an IGP >> > > > link) is not desirable and thus cannot be assumed that such link >> > > exist. >> > > > >> > > [Lucy] As Wim suggested, it is better to delete the following >> > sentence >> > > in section 4.3 because it does not serve any requirement and brings >> > > a confusion. >> > > >> > > The latter scenario often means that requiring a dedicated >> > > link between the PEs, for the operation of the multi-homing >> > > mechanism, is not appealing from cost standpoint. >> > > >> > > Should we explicitly say if PEs associated with a multi-homed setup >> > > have to be in the same IGP or not in different IGPs, i.e. different >> > > ASes? The following sentence implicitly state that. >> > > >> > > Furthermore, the IGP cost from remote PEs to the pair of PEs in the >> > > multi-homed setup >> > > cannot be assumed to be the same when those latter PEs are geo- >> > > redundant. >> > > >> > > Regards, >> > > Lucy >> > > > >2) in section 4.6, the last paragraph should state a requirement >> > for >> > > > flow >> > > > >based load balance. >> > > > > >> > > > >> > > > Resolution: Agreed, we add flow-based LB to the text. >> > > > >> > > > >3) It should add one requirement in supporting Ethernet L2VPN >> > across >> > > > >multi-ASes >> > > > > >> > > > >> > > > Resolution: Agreed, we'll add that. >> > > > >> > > > >> > > > >4) As the draft mentioned, the new service interfaces are >> > > > >required for >> > > > DC >> > > > >interconnection. If DC uses NVo3 in future, will these service >> > > > interfaces >> > > > >are still necessary? Suggest giving some use cases where the new >> > > > service >> > > > >interfaces are necessary in an appendix. >> > > > > >> > > > > >> > > > >> > > > Resolution: No change, as clarified in the email thread. >> > > > >> > > > Cheers, >> > > > Ali >> > > > >> > > > >> > > > >> > > > >> > > > On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" >> > > > wrote: >> > > > >> > > > >Lucy, sure and this evolution into MEF is most likely to come, >> > > > >but >> > I >> > > > >believe it is a clear req for EVPN, so I believe we can close >> > > > >this >> > > > point >> > > > > >> > > > >On 05/11/12 15:58, "Lucy yong" wrote: >> > > > > >> > > > >>Wim, >> > > > >> >> > > > >>I agree that we (IETF) don't have make ourselves dependent on >> MEF. >> > > > >>However, there are a lot of service providers in MEF to specify >> > > > Ethernet >> > > > >>services and service interfaces. Such service interface has not >> > yet >> > > > to >> > > > >>bring on the table there. This may be because the people in two >> > > SDOs >> > > > may >> > > > >>be from different orgs.. >> > > > >> >> > > > >>Thanks, >> > > > >>Lucy >> > > > >> >> > > > >>> -----Original Message----- >> > > > >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> > > > lucent.com] >> > > > >>> Sent: Monday, November 05, 2012 10:15 AM >> > > > >>> To: Lucy yong; l2vpn@ietf.org >> > > > >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >> > > > >>> >> > > > >>> -- Snip -- >> > > > >>> >> > > > >>> [Lucy] OK. Maybe I did not follow the early requirement >> > > discussions. >> > > > >>> Where >> > > > >>> was this requirement coming from. MEF Services do not support >> > > such >> > > > >>> service interface. Was this from some operators in IETF? I >> > > > >>> just like to >> > > > know a >> > > > >>> use >> > > > >>> case if possible. >> > > > >>> >> > > > >>> >> > > > >>> WH> yes this is from operators of which some are on the co- >> > author >> > > > list. >> > > > >>> The driver for this is more optimised and scalable >> > > implementations. >> > > > MEF >> > > > >>> might adopt this going fwd, so we should not make ourselves >> > > > dependent >> > > > >>> on >> > > > >>> MEF >> > > > >>> >> > > > >>> -- Snip -- >> > > > >>> >> > > > >>> On 05/11/12 11:09, "Lucy yong" wrote: >> > > > >>> >> > > > >>> > >> > > > >>> > >> > > > >>> >snip >> > > > >>> >> >[Lucy] My second question is if PE nodes that are multi- >> > homed >> > > > to a >> > > > >>> >> same >> > > > >>> >> >CE may be in different ASes in latter case? Whether yes, >> > > > >>> >> >or no, >> > > > it >> > > > >>> >> should >> > > > >>> >> >state it out. >> > > > >>> >> >> > > > >>> >> WH2> this seems like an odd scenario >> > > > >>> >[Lucy] agree. >> > > > >>> >> > >> > > > >>> >> >> > >> > > > >>> >> >> >2) in section 4.6, the last paragraph should state a >> > > > requirement >> > > > >>> >> for >> > > > >>> >> >> flow >> > > > >>> >> >> >based load balance. >> > > > >>> >> >> >> > > > >>> >> >> WH> are you saying the Mac based load-balancing is a >> > > > >>> >> >> WH> MUST >> > > or >> > > > are >> > > > >>> you >> > > > >>> >> >> saying the MAC based load-balancing should be flow >> based >> > > > >>> >> >[Lucy] Text: A solution MAY support multi-homed network >> > > with >> > > > >>> >> >active/active MAC- >> > > > >>> >> > based load balancing (i.e. different MAC addresses on >> a >> > > > >>> >> >VLAN >> > > > are >> > > > >>> >> > reachable via different PEs). >> > > > >>> >> > >> > > > >>> >> >In section 4.1, it describes options for flow-based load >> > > > balancing, >> > > > >>> >> that >> > > > >>> >> >should apply to here, right? >> > > > >>> >> >That means the same MAC address may occur on the >> different >> > > PEs >> > > > too. >> > > > >>> >> WH2> yes >> > > > >>> >> > >> > > > >>> >> >> > >> > > > >>> >> >> >3) It should add one requirement in supporting >> Ethernet >> > > > L2VPN >> > > > >>> >> across >> > > > >>> >> >> >multi-Ases >> > > > >>> >> >> >> > > > >>> >> >> WH> agreed >> > > > >>> >> >> > >> > > > >>> >> >> >4) As the draft mentioned, the new service interfaces >> > are >> > > > >>> required >> > > > >>> >> for >> > > > >>> >> >> DC >> > > > >>> >> >> >interconnection. If DC uses NVo3 in future, will these >> > > > service >> > > > >>> >> >> interfaces >> > > > >>> >> >> >are still necessary? Suggest giving some use cases >> > > > >>> >> >> >where the >> > > > new >> > > > >>> >> >> service >> > > > >>> >> >> >interfaces are necessary in an appendix. >> > > > >>> >> >> WH> it depends on what use case we have in NVO3: is the >> > NVE >> > > > >>> >> collocated >> > > > >>> >> >> with the VM or is the NVE located at a TOR connected to >> > > > >>> >> >> a >> > > > server. >> > > > >>> >> >> Depending on the connectivity different solutions might >> > be >> > > > >>> required >> > > > >>> >> and >> > > > >>> >> >> as >> > > > >>> >> >> such we made the requirement general and not specific >> > since >> > > > there >> > > > >>> is >> > > > >>> >> >> multiple solutions to this and this is a requirements >> > draft >> > > > >>> rather >> > > > >>> >> than >> > > > >>> >> >> solution draft. Use case should be covered in a >> separate >> > > doc. >> > > > >>> >> >[Lucy] It, I think, is more about cases between DC GW and >> > WAN >> > > > PE. >> > > > >>> For >> > > > >>> >> >example, if NVO3 is used in DC, when we need VLAN aware >> > > bundle >> > > > >>> service >> > > > >>> >> >interface? Could you give a example? I don't have a >> > > > >>> >> >problem >> > > to >> > > > make >> > > > >>> a >> > > > >>> >> >general requirement, just want know where is the >> > requirement >> > > > coming >> > > > >>> >> from. >> > > > >>> >> > >> > > > >>> >> >Lucy >> > > > >>> >> >> > > > >>> >> WH2> the service interface we are talking about here is >> how >> > > the >> > > > EVPN >> > > > >>> >> service is modelled on the DC GW/WAN PE. There are >> multiple >> > > > >>> scenarios >> > > > >>> >> which should be supported. The service interface here is >> an >> > > > internal >> > > > >>> >> modelling of the EVPN on the PE >> > > > >>> >[Lucy] OK. Maybe I did not follow the early requirement >> > > > discussions. >> > > > >>> >Where was this requirement coming from. MEF Services do not >> > > > support >> > > > >>> such >> > > > >>> >service interface. Was this from some operators in IETF? I >> > just >> > > > like >> > > > >>> to >> > > > >>> >know a use case if possible. >> > > > >>> > >> > > > >>> >Lucy >> > > > >>> >> >> > >> > > > >>> >> >> >Cheers, >> > > > >>> >> >> >Lucy >> > > > >>> >> >> > >> > > > >>> >> >> >> ------------------------------ >> > > > >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 >> > > > >>> >> >> >> From: Giles Heron >> > > > >>> >> >> >> To: "l2vpn@ietf.org" >> > > > >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >> > > > >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- >> > > > FBBEDB84BC32@gmail.com> >> > > > >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii >> > > > >>> >> >> >> >> > > > >>> >> >> >> This email initiates an L2VPN WG Last Call for: >> > > > >>> >> >> >> >> > > > >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn- >> req- >> > 01 >> > > > >>> >> >> >> >> > > > >>> >> >> >> please comment to the list as to the suitability of >> > this >> > > > draft >> > > > >>> >> for >> > > > >>> >> >> >> publication as a Standards Track RFC from the L2VPN >> WG. >> > > > >>> >> >> >> >> > > > >>> >> >> >> this last call will close on Friday 2nd November. >> > > > >>> >> >> >> >> > > > >>> >> >> >> Nabil & Giles >> > > > >>> >> >> > >> > > > >>> >> > >> > > > >>> > >> > > > >> >> > > > > >> > > >> > >>=20 > > From lucy.yong@huawei.com Thu Nov 15 09:50: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 128C921F89EF for ; Thu, 15 Nov 2012 09:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 m7rTggySfkqr for ; Thu, 15 Nov 2012 09:50:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 53F6821F85FC for ; Thu, 15 Nov 2012 09:50:40 -0800 (PST) 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 AMV45768; Thu, 15 Nov 2012 17:50:38 +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; Thu, 15 Nov 2012 17:50:24 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 17:50:37 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 09:50:35 -0800 From: Lucy yong To: "Ali Sajassi (sajassi)" , John E Drake , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAPRT5A//+ktQD//02+IIAB4J8A//+C7wD//93jAA== Date: Thu, 15 Nov 2012 17:50:34 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44830CB4@dfweml505-mbx> References: <0182DEA5604B3A44A2EE61F3EE3ED69E07E6E54A@BL2PRD0510MB349.namprd05.prod.outlook.com> <69670F7146898C4583F56DA9AD32F77B0D7AC927@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7AC927@xmb-aln-x13.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Thu, 15 Nov 2012 17:50:43 -0000 Good! This is clear now. Lucy > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Thursday, November 15, 2012 11:48 AM > To: John E Drake; Lucy yong; Henderickx, Wim (Wim); l2vpn@ietf.org > Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 >=20 >=20 > All E-VPN attributes are transitive (including the ones uses for > multi-homing), so multi-homing can span across multiple ASes. I will > add a > requirement in the multi-homing section to this effect. >=20 > Cheers, > Ali >=20 > On 11/15/12 9:15 AM, "John E Drake" wrote: >=20 > >Lucy, > > > >I don't want to slow things down but I think such a statement would be > >extremely helpful. > > > >Irrespectively Yours, > > > >John > > > >> -----Original Message----- > >> From: Lucy yong [mailto:lucy.yong@huawei.com] > >> Sent: Thursday, November 15, 2012 8:02 AM > >> To: John E Drake; Ali Sajassi (sajassi); Henderickx, Wim (Wim); > >> l2vpn@ietf.org > >> Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > >> > >> Hi John, > >> > >> Regarding if EVPN allows two PEs in different ASes to be homed to > the > >> same CE, this is my original question on the last call of evpn req.. > >> The current document does not make it clear. > >> > >> If this is the case, should we state that PEs that are homed to the > >> same CE may be in the AS or different ASes in the document to make > it > >> clear? > >> > >> Thanks, > >> Lucy > >> > >> > -----Original Message----- > >> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> Behalf > >> > Of John E Drake > >> > Sent: Wednesday, November 14, 2012 3:14 PM > >> > To: Lucy yong; Ali Sajassi (sajassi); Henderickx, Wim (Wim); > >> > l2vpn@ietf.org > >> > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > >> > > >> > Lucy, > >> > > >> > There should not be a requirement that two or more PEs providing > >> > multi- homing to the same CE need to be in the same IGP. This is > too > >> > restrictive and totally unnecessary. > >> > > >> > Irrespectively Yours, > >> > > >> > John > >> > > >> > > >> > > -----Original Message----- > >> > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > >> > Behalf > >> > > Of Lucy yong > >> > > Sent: Wednesday, November 14, 2012 12:19 PM > >> > > To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); l2vpn@ietf.org > >> > > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > >> > > > >> > > Hi Ali, > >> > > > >> > > > > >> > > > >1) in section 4.3, Text: The latter scenario often means that > >> > > > requiring a > >> > > > >dedicated > >> > > > > link between the PEs, for the operation of the multi- > homing > >> > > > mechanism, > >> > > > >is not appealing from cost standpoint. > >> > > > > > >> > > > >Comment: a dedicated link between PEs. will this link is in > IGP > >> > link > >> > > > too? > >> > > > >or private link. > >> > > > >May PE nodes that are multi-homed to a same CE be different > >> ASes? > >> > If > >> > > > yes, > >> > > > >state it out. > >> > > > > > >> > > > > >> > > > Resolution: no change to the text. > >> > > > The draft states that having such a dedicated link (which is > not > >> > > > an IGP > >> > > > link) is not desirable and thus cannot be assumed that such > link > >> > > exist. > >> > > > > >> > > [Lucy] As Wim suggested, it is better to delete the following > >> > sentence > >> > > in section 4.3 because it does not serve any requirement and > brings > >> > > a confusion. > >> > > > >> > > The latter scenario often means that requiring a dedicated > >> > > link between the PEs, for the operation of the multi-homing > >> > > mechanism, is not appealing from cost standpoint. > >> > > > >> > > Should we explicitly say if PEs associated with a multi-homed > setup > >> > > have to be in the same IGP or not in different IGPs, i.e. > different > >> > > ASes? The following sentence implicitly state that. > >> > > > >> > > Furthermore, the IGP cost from remote PEs to the pair of PEs in > the > >> > > multi-homed setup > >> > > cannot be assumed to be the same when those latter PEs are > geo- > >> > > redundant. > >> > > > >> > > Regards, > >> > > Lucy > >> > > > >2) in section 4.6, the last paragraph should state a > requirement > >> > for > >> > > > flow > >> > > > >based load balance. > >> > > > > > >> > > > > >> > > > Resolution: Agreed, we add flow-based LB to the text. > >> > > > > >> > > > >3) It should add one requirement in supporting Ethernet L2VPN > >> > across > >> > > > >multi-ASes > >> > > > > > >> > > > > >> > > > Resolution: Agreed, we'll add that. > >> > > > > >> > > > > >> > > > >4) As the draft mentioned, the new service interfaces are > >> > > > >required for > >> > > > DC > >> > > > >interconnection. If DC uses NVo3 in future, will these > service > >> > > > interfaces > >> > > > >are still necessary? Suggest giving some use cases where the > new > >> > > > service > >> > > > >interfaces are necessary in an appendix. > >> > > > > > >> > > > > > >> > > > > >> > > > Resolution: No change, as clarified in the email thread. > >> > > > > >> > > > Cheers, > >> > > > Ali > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > >> > > > wrote: > >> > > > > >> > > > >Lucy, sure and this evolution into MEF is most likely to come, > >> > > > >but > >> > I > >> > > > >believe it is a clear req for EVPN, so I believe we can close > >> > > > >this > >> > > > point > >> > > > > > >> > > > >On 05/11/12 15:58, "Lucy yong" wrote: > >> > > > > > >> > > > >>Wim, > >> > > > >> > >> > > > >>I agree that we (IETF) don't have make ourselves dependent > on > >> MEF. > >> > > > >>However, there are a lot of service providers in MEF to > specify > >> > > > Ethernet > >> > > > >>services and service interfaces. Such service interface has > not > >> > yet > >> > > > to > >> > > > >>bring on the table there. This may be because the people in > two > >> > > SDOs > >> > > > may > >> > > > >>be from different orgs.. > >> > > > >> > >> > > > >>Thanks, > >> > > > >>Lucy > >> > > > >> > >> > > > >>> -----Original Message----- > >> > > > >>> From: Henderickx, Wim (Wim) > [mailto:wim.henderickx@alcatel- > >> > > > lucent.com] > >> > > > >>> Sent: Monday, November 05, 2012 10:15 AM > >> > > > >>> To: Lucy yong; l2vpn@ietf.org > >> > > > >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > >> > > > >>> > >> > > > >>> -- Snip -- > >> > > > >>> > >> > > > >>> [Lucy] OK. Maybe I did not follow the early requirement > >> > > discussions. > >> > > > >>> Where > >> > > > >>> was this requirement coming from. MEF Services do not > support > >> > > such > >> > > > >>> service interface. Was this from some operators in IETF? I > >> > > > >>> just like to > >> > > > know a > >> > > > >>> use > >> > > > >>> case if possible. > >> > > > >>> > >> > > > >>> > >> > > > >>> WH> yes this is from operators of which some are on the > co- > >> > author > >> > > > list. > >> > > > >>> The driver for this is more optimised and scalable > >> > > implementations. > >> > > > MEF > >> > > > >>> might adopt this going fwd, so we should not make > ourselves > >> > > > dependent > >> > > > >>> on > >> > > > >>> MEF > >> > > > >>> > >> > > > >>> -- Snip -- > >> > > > >>> > >> > > > >>> On 05/11/12 11:09, "Lucy yong" > wrote: > >> > > > >>> > >> > > > >>> > > >> > > > >>> > > >> > > > >>> >snip > >> > > > >>> >> >[Lucy] My second question is if PE nodes that are > multi- > >> > homed > >> > > > to a > >> > > > >>> >> same > >> > > > >>> >> >CE may be in different ASes in latter case? Whether > yes, > >> > > > >>> >> >or no, > >> > > > it > >> > > > >>> >> should > >> > > > >>> >> >state it out. > >> > > > >>> >> > >> > > > >>> >> WH2> this seems like an odd scenario > >> > > > >>> >[Lucy] agree. > >> > > > >>> >> > > >> > > > >>> >> >> > > >> > > > >>> >> >> >2) in section 4.6, the last paragraph should state > a > >> > > > requirement > >> > > > >>> >> for > >> > > > >>> >> >> flow > >> > > > >>> >> >> >based load balance. > >> > > > >>> >> >> > >> > > > >>> >> >> WH> are you saying the Mac based load-balancing is a > >> > > > >>> >> >> WH> MUST > >> > > or > >> > > > are > >> > > > >>> you > >> > > > >>> >> >> saying the MAC based load-balancing should be flow > >> based > >> > > > >>> >> >[Lucy] Text: A solution MAY support multi-homed > network > >> > > with > >> > > > >>> >> >active/active MAC- > >> > > > >>> >> > based load balancing (i.e. different MAC addresses > on > >> a > >> > > > >>> >> >VLAN > >> > > > are > >> > > > >>> >> > reachable via different PEs). > >> > > > >>> >> > > >> > > > >>> >> >In section 4.1, it describes options for flow-based > load > >> > > > balancing, > >> > > > >>> >> that > >> > > > >>> >> >should apply to here, right? > >> > > > >>> >> >That means the same MAC address may occur on the > >> different > >> > > PEs > >> > > > too. > >> > > > >>> >> WH2> yes > >> > > > >>> >> > > >> > > > >>> >> >> > > >> > > > >>> >> >> >3) It should add one requirement in supporting > >> Ethernet > >> > > > L2VPN > >> > > > >>> >> across > >> > > > >>> >> >> >multi-Ases > >> > > > >>> >> >> > >> > > > >>> >> >> WH> agreed > >> > > > >>> >> >> > > >> > > > >>> >> >> >4) As the draft mentioned, the new service > interfaces > >> > are > >> > > > >>> required > >> > > > >>> >> for > >> > > > >>> >> >> DC > >> > > > >>> >> >> >interconnection. If DC uses NVo3 in future, will > these > >> > > > service > >> > > > >>> >> >> interfaces > >> > > > >>> >> >> >are still necessary? Suggest giving some use cases > >> > > > >>> >> >> >where the > >> > > > new > >> > > > >>> >> >> service > >> > > > >>> >> >> >interfaces are necessary in an appendix. > >> > > > >>> >> >> WH> it depends on what use case we have in NVO3: is > the > >> > NVE > >> > > > >>> >> collocated > >> > > > >>> >> >> with the VM or is the NVE located at a TOR connected > to > >> > > > >>> >> >> a > >> > > > server. > >> > > > >>> >> >> Depending on the connectivity different solutions > might > >> > be > >> > > > >>> required > >> > > > >>> >> and > >> > > > >>> >> >> as > >> > > > >>> >> >> such we made the requirement general and not > specific > >> > since > >> > > > there > >> > > > >>> is > >> > > > >>> >> >> multiple solutions to this and this is a > requirements > >> > draft > >> > > > >>> rather > >> > > > >>> >> than > >> > > > >>> >> >> solution draft. Use case should be covered in a > >> separate > >> > > doc. > >> > > > >>> >> >[Lucy] It, I think, is more about cases between DC GW > and > >> > WAN > >> > > > PE. > >> > > > >>> For > >> > > > >>> >> >example, if NVO3 is used in DC, when we need VLAN > aware > >> > > bundle > >> > > > >>> service > >> > > > >>> >> >interface? Could you give a example? I don't have a > >> > > > >>> >> >problem > >> > > to > >> > > > make > >> > > > >>> a > >> > > > >>> >> >general requirement, just want know where is the > >> > requirement > >> > > > coming > >> > > > >>> >> from. > >> > > > >>> >> > > >> > > > >>> >> >Lucy > >> > > > >>> >> > >> > > > >>> >> WH2> the service interface we are talking about here is > >> how > >> > > the > >> > > > EVPN > >> > > > >>> >> service is modelled on the DC GW/WAN PE. There are > >> multiple > >> > > > >>> scenarios > >> > > > >>> >> which should be supported. The service interface here > is > >> an > >> > > > internal > >> > > > >>> >> modelling of the EVPN on the PE > >> > > > >>> >[Lucy] OK. Maybe I did not follow the early requirement > >> > > > discussions. > >> > > > >>> >Where was this requirement coming from. MEF Services do > not > >> > > > support > >> > > > >>> such > >> > > > >>> >service interface. Was this from some operators in IETF? > I > >> > just > >> > > > like > >> > > > >>> to > >> > > > >>> >know a use case if possible. > >> > > > >>> > > >> > > > >>> >Lucy > >> > > > >>> >> >> > > >> > > > >>> >> >> >Cheers, > >> > > > >>> >> >> >Lucy > >> > > > >>> >> >> > > >> > > > >>> >> >> >> ------------------------------ > >> > > > >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > >> > > > >>> >> >> >> From: Giles Heron > >> > > > >>> >> >> >> To: "l2vpn@ietf.org" > >> > > > >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn- > req > >> > > > >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- > >> > > > FBBEDB84BC32@gmail.com> > >> > > > >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii > >> > > > >>> >> >> >> > >> > > > >>> >> >> >> This email initiates an L2VPN WG Last Call for: > >> > > > >>> >> >> >> > >> > > > >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn- > >> req- > >> > 01 > >> > > > >>> >> >> >> > >> > > > >>> >> >> >> please comment to the list as to the suitability > of > >> > this > >> > > > draft > >> > > > >>> >> for > >> > > > >>> >> >> >> publication as a Standards Track RFC from the > L2VPN > >> WG. > >> > > > >>> >> >> >> > >> > > > >>> >> >> >> this last call will close on Friday 2nd November. > >> > > > >>> >> >> >> > >> > > > >>> >> >> >> Nabil & Giles > >> > > > >>> >> >> > > >> > > > >>> >> > > >> > > > >>> > > >> > > > >> > >> > > > > > >> > > > >> > > >> > > > > From lucy.yong@huawei.com Thu Nov 15 10:06:46 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 4EA2621F84F9 for ; Thu, 15 Nov 2012 10:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 5+DxqCivF+Yf for ; Thu, 15 Nov 2012 10:06:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CE0D621F8A1B for ; Thu, 15 Nov 2012 10:06:43 -0800 (PST) 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 ALP42828; Thu, 15 Nov 2012 18:06:40 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 18:05:18 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 18:05:33 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 10:05:29 -0800 From: Lucy yong To: John E Drake , "Ali Sajassi (sajassi)" , "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNs+lkV4LAWIKrW0iRSTYU1PDg1pfaGvVQgACw+wD//6rIoIABIWcA//+w/3CAALZyAP//xEoAABFwwoABwTqLAAAPRT5A//+ktQD//02+IIACAiYAgAB5XfA= Date: Thu, 15 Nov 2012 18:05:29 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44830CD5@dfweml505-mbx> References: <69670F7146898C4583F56DA9AD32F77B0D7A2F49@xmb-aln-x13.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D4483073A@dfweml505-mbx> <0182DEA5604B3A44A2EE61F3EE3ED69E07E6D415@BL2PRD0510MB349.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D44830B7A@dfweml505-mbx> <0182DEA5604B3A44A2EE61F3EE3ED69E07E6E54A@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E07E6E54A@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Thu, 15 Nov 2012 18:06:46 -0000 John, I don't want to slow this down too. We just make sure the requirements are = clear, which will be very helpful in the solution development. Regards, Lucy > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of John E Drake > Sent: Thursday, November 15, 2012 11:16 AM > To: Lucy yong; Ali Sajassi (sajassi); Henderickx, Wim (Wim); > l2vpn@ietf.org > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req >=20 > Lucy, >=20 > I don't want to slow things down but I think such a statement would be > extremely helpful. >=20 > Irrespectively Yours, >=20 > John >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Thursday, November 15, 2012 8:02 AM > > To: John E Drake; Ali Sajassi (sajassi); Henderickx, Wim (Wim); > > l2vpn@ietf.org > > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > Hi John, > > > > Regarding if EVPN allows two PEs in different ASes to be homed to the > > same CE, this is my original question on the last call of evpn req.. > > The current document does not make it clear. > > > > If this is the case, should we state that PEs that are homed to the > > same CE may be in the AS or different ASes in the document to make it > > clear? > > > > Thanks, > > Lucy > > > > > -----Original Message----- > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > Behalf > > > Of John E Drake > > > Sent: Wednesday, November 14, 2012 3:14 PM > > > To: Lucy yong; Ali Sajassi (sajassi); Henderickx, Wim (Wim); > > > l2vpn@ietf.org > > > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > > > Lucy, > > > > > > There should not be a requirement that two or more PEs providing > > > multi- homing to the same CE need to be in the same IGP. This is > too > > > restrictive and totally unnecessary. > > > > > > Irrespectively Yours, > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > > > Behalf > > > > Of Lucy yong > > > > Sent: Wednesday, November 14, 2012 12:19 PM > > > > To: Ali Sajassi (sajassi); Henderickx, Wim (Wim); l2vpn@ietf.org > > > > Subject: RE: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > > > > > Hi Ali, > > > > > > > > > > > > > > >1) in section 4.3, Text: The latter scenario often means that > > > > > requiring a > > > > > >dedicated > > > > > > link between the PEs, for the operation of the multi-homing > > > > > mechanism, > > > > > >is not appealing from cost standpoint. > > > > > > > > > > > >Comment: a dedicated link between PEs. will this link is in > IGP > > > link > > > > > too? > > > > > >or private link. > > > > > >May PE nodes that are multi-homed to a same CE be different > > ASes? > > > If > > > > > yes, > > > > > >state it out. > > > > > > > > > > > > > > > > Resolution: no change to the text. > > > > > The draft states that having such a dedicated link (which is > not > > > > > an IGP > > > > > link) is not desirable and thus cannot be assumed that such > link > > > > exist. > > > > > > > > > [Lucy] As Wim suggested, it is better to delete the following > > > sentence > > > > in section 4.3 because it does not serve any requirement and > brings > > > > a confusion. > > > > > > > > The latter scenario often means that requiring a dedicated > > > > link between the PEs, for the operation of the multi-homing > > > > mechanism, is not appealing from cost standpoint. > > > > > > > > Should we explicitly say if PEs associated with a multi-homed > setup > > > > have to be in the same IGP or not in different IGPs, i.e. > different > > > > ASes? The following sentence implicitly state that. > > > > > > > > Furthermore, the IGP cost from remote PEs to the pair of PEs in > the > > > > multi-homed setup > > > > cannot be assumed to be the same when those latter PEs are > geo- > > > > redundant. > > > > > > > > Regards, > > > > Lucy > > > > > >2) in section 4.6, the last paragraph should state a > requirement > > > for > > > > > flow > > > > > >based load balance. > > > > > > > > > > > > > > > > Resolution: Agreed, we add flow-based LB to the text. > > > > > > > > > > >3) It should add one requirement in supporting Ethernet L2VPN > > > across > > > > > >multi-ASes > > > > > > > > > > > > > > > > Resolution: Agreed, we'll add that. > > > > > > > > > > > > > > > >4) As the draft mentioned, the new service interfaces are > > > > > >required for > > > > > DC > > > > > >interconnection. If DC uses NVo3 in future, will these service > > > > > interfaces > > > > > >are still necessary? Suggest giving some use cases where the > new > > > > > service > > > > > >interfaces are necessary in an appendix. > > > > > > > > > > > > > > > > > > > > > > Resolution: No change, as clarified in the email thread. > > > > > > > > > > Cheers, > > > > > Ali > > > > > > > > > > > > > > > > > > > > > > > > > On 11/5/12 4:00 PM, "Henderickx, Wim (Wim)" > > > > > wrote: > > > > > > > > > > >Lucy, sure and this evolution into MEF is most likely to come, > > > > > >but > > > I > > > > > >believe it is a clear req for EVPN, so I believe we can close > > > > > >this > > > > > point > > > > > > > > > > > >On 05/11/12 15:58, "Lucy yong" wrote: > > > > > > > > > > > >>Wim, > > > > > >> > > > > > >>I agree that we (IETF) don't have make ourselves dependent on > > MEF. > > > > > >>However, there are a lot of service providers in MEF to > specify > > > > > Ethernet > > > > > >>services and service interfaces. Such service interface has > not > > > yet > > > > > to > > > > > >>bring on the table there. This may be because the people in > two > > > > SDOs > > > > > may > > > > > >>be from different orgs.. > > > > > >> > > > > > >>Thanks, > > > > > >>Lucy > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > > > > lucent.com] > > > > > >>> Sent: Monday, November 05, 2012 10:15 AM > > > > > >>> To: Lucy yong; l2vpn@ietf.org > > > > > >>> Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req > > > > > >>> > > > > > >>> -- Snip -- > > > > > >>> > > > > > >>> [Lucy] OK. Maybe I did not follow the early requirement > > > > discussions. > > > > > >>> Where > > > > > >>> was this requirement coming from. MEF Services do not > support > > > > such > > > > > >>> service interface. Was this from some operators in IETF? I > > > > > >>> just like to > > > > > know a > > > > > >>> use > > > > > >>> case if possible. > > > > > >>> > > > > > >>> > > > > > >>> WH> yes this is from operators of which some are on the co- > > > author > > > > > list. > > > > > >>> The driver for this is more optimised and scalable > > > > implementations. > > > > > MEF > > > > > >>> might adopt this going fwd, so we should not make ourselves > > > > > dependent > > > > > >>> on > > > > > >>> MEF > > > > > >>> > > > > > >>> -- Snip -- > > > > > >>> > > > > > >>> On 05/11/12 11:09, "Lucy yong" wrote: > > > > > >>> > > > > > >>> > > > > > > >>> > > > > > > >>> >snip > > > > > >>> >> >[Lucy] My second question is if PE nodes that are > multi- > > > homed > > > > > to a > > > > > >>> >> same > > > > > >>> >> >CE may be in different ASes in latter case? Whether yes, > > > > > >>> >> >or no, > > > > > it > > > > > >>> >> should > > > > > >>> >> >state it out. > > > > > >>> >> > > > > > >>> >> WH2> this seems like an odd scenario > > > > > >>> >[Lucy] agree. > > > > > >>> >> > > > > > > >>> >> >> > > > > > > >>> >> >> >2) in section 4.6, the last paragraph should state a > > > > > requirement > > > > > >>> >> for > > > > > >>> >> >> flow > > > > > >>> >> >> >based load balance. > > > > > >>> >> >> > > > > > >>> >> >> WH> are you saying the Mac based load-balancing is a > > > > > >>> >> >> WH> MUST > > > > or > > > > > are > > > > > >>> you > > > > > >>> >> >> saying the MAC based load-balancing should be flow > > based > > > > > >>> >> >[Lucy] Text: A solution MAY support multi-homed > network > > > > with > > > > > >>> >> >active/active MAC- > > > > > >>> >> > based load balancing (i.e. different MAC addresses > on > > a > > > > > >>> >> >VLAN > > > > > are > > > > > >>> >> > reachable via different PEs). > > > > > >>> >> > > > > > > >>> >> >In section 4.1, it describes options for flow-based > load > > > > > balancing, > > > > > >>> >> that > > > > > >>> >> >should apply to here, right? > > > > > >>> >> >That means the same MAC address may occur on the > > different > > > > PEs > > > > > too. > > > > > >>> >> WH2> yes > > > > > >>> >> > > > > > > >>> >> >> > > > > > > >>> >> >> >3) It should add one requirement in supporting > > Ethernet > > > > > L2VPN > > > > > >>> >> across > > > > > >>> >> >> >multi-Ases > > > > > >>> >> >> > > > > > >>> >> >> WH> agreed > > > > > >>> >> >> > > > > > > >>> >> >> >4) As the draft mentioned, the new service > interfaces > > > are > > > > > >>> required > > > > > >>> >> for > > > > > >>> >> >> DC > > > > > >>> >> >> >interconnection. If DC uses NVo3 in future, will > these > > > > > service > > > > > >>> >> >> interfaces > > > > > >>> >> >> >are still necessary? Suggest giving some use cases > > > > > >>> >> >> >where the > > > > > new > > > > > >>> >> >> service > > > > > >>> >> >> >interfaces are necessary in an appendix. > > > > > >>> >> >> WH> it depends on what use case we have in NVO3: is > the > > > NVE > > > > > >>> >> collocated > > > > > >>> >> >> with the VM or is the NVE located at a TOR connected > to > > > > > >>> >> >> a > > > > > server. > > > > > >>> >> >> Depending on the connectivity different solutions > might > > > be > > > > > >>> required > > > > > >>> >> and > > > > > >>> >> >> as > > > > > >>> >> >> such we made the requirement general and not specific > > > since > > > > > there > > > > > >>> is > > > > > >>> >> >> multiple solutions to this and this is a requirements > > > draft > > > > > >>> rather > > > > > >>> >> than > > > > > >>> >> >> solution draft. Use case should be covered in a > > separate > > > > doc. > > > > > >>> >> >[Lucy] It, I think, is more about cases between DC GW > and > > > WAN > > > > > PE. > > > > > >>> For > > > > > >>> >> >example, if NVO3 is used in DC, when we need VLAN aware > > > > bundle > > > > > >>> service > > > > > >>> >> >interface? Could you give a example? I don't have a > > > > > >>> >> >problem > > > > to > > > > > make > > > > > >>> a > > > > > >>> >> >general requirement, just want know where is the > > > requirement > > > > > coming > > > > > >>> >> from. > > > > > >>> >> > > > > > > >>> >> >Lucy > > > > > >>> >> > > > > > >>> >> WH2> the service interface we are talking about here is > > how > > > > the > > > > > EVPN > > > > > >>> >> service is modelled on the DC GW/WAN PE. There are > > multiple > > > > > >>> scenarios > > > > > >>> >> which should be supported. The service interface here is > > an > > > > > internal > > > > > >>> >> modelling of the EVPN on the PE > > > > > >>> >[Lucy] OK. Maybe I did not follow the early requirement > > > > > discussions. > > > > > >>> >Where was this requirement coming from. MEF Services do > not > > > > > support > > > > > >>> such > > > > > >>> >service interface. Was this from some operators in IETF? I > > > just > > > > > like > > > > > >>> to > > > > > >>> >know a use case if possible. > > > > > >>> > > > > > > >>> >Lucy > > > > > >>> >> >> > > > > > > >>> >> >> >Cheers, > > > > > >>> >> >> >Lucy > > > > > >>> >> >> > > > > > > >>> >> >> >> ------------------------------ > > > > > >>> >> >> >> Date: Fri, 19 Oct 2012 23:34:53 +0100 > > > > > >>> >> >> >> From: Giles Heron > > > > > >>> >> >> >> To: "l2vpn@ietf.org" > > > > > >>> >> >> >> Subject: WG Last Call for draft-ietf-l2vpn-evpn- > req > > > > > >>> >> >> >> Message-ID: <755C3ABB-ADE3-42EE-8BE1- > > > > > FBBEDB84BC32@gmail.com> > > > > > >>> >> >> >> Content-Type: text/plain; charset=3Dus-ascii > > > > > >>> >> >> >> > > > > > >>> >> >> >> This email initiates an L2VPN WG Last Call for: > > > > > >>> >> >> >> > > > > > >>> >> >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn- > > req- > > > 01 > > > > > >>> >> >> >> > > > > > >>> >> >> >> please comment to the list as to the suitability > of > > > this > > > > > draft > > > > > >>> >> for > > > > > >>> >> >> >> publication as a Standards Track RFC from the > L2VPN > > WG. > > > > > >>> >> >> >> > > > > > >>> >> >> >> this last call will close on Friday 2nd November. > > > > > >>> >> >> >> > > > > > >>> >> >> >> Nabil & Giles > > > > > >>> >> >> > > > > > > >>> >> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > >=20 From sajassi@cisco.com Thu Nov 15 10:09: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 5DD3521F852B for ; Thu, 15 Nov 2012 10:09:56 -0800 (PST) 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 N2lkFaVxZntM for ; Thu, 15 Nov 2012 10:09:55 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6520021F8522 for ; Thu, 15 Nov 2012 10:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2255; q=dns/txt; s=iport; t=1353002995; x=1354212595; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6jymIqme0ZTCJFEbee56h13LMRq8/YxaPEYttwtXnqA=; b=ckt6zwcH/PxZ2QHcyosb6QIayXDavzq4o2S9XqTI+BXnqwoJD9tPx8p/ pPBSdkZKA1BmDn5uZ4kx6SPDs8/kk+Ub+B7ahFlJCp4Hpkvlp9D2BITp4 mlRQoQhGa3i3qUkCW549cYZLRfsLnCYkr+YJ+aX3RdGtX3VyFvtFvpfDc w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAwvpVCtJV2d/2dsb2JhbABEgmy/UIEIgh4BAQEEDgQBCh0rFBIBCBEDAQIBChQxER0IAgQBDQUIGodZAw8BCpxzlikNiVSLSGmFS2EDlCeCcYoWgyaBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="142654914" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 15 Nov 2012 18:09:55 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAFI9sgB016361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 18:09:54 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 12:09:54 -0600 From: "Ali Sajassi (sajassi)" To: Giles Heron , Lucy yong Subject: Re: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Topic: WG Last Call for draft-ietf-l2vpn-evpn-req Thread-Index: AQHNw1xpV4LAWIKrW0iRSTYU1PDg1g== Date: Thu, 15 Nov 2012 18:09:53 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7ADA94@xmb-aln-x13.cisco.com> In-Reply-To: <7FCECE66-0834-4836-81CF-44BA48DA84B3@gmail.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.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001 x-tm-as-result: No--41.952200-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, 15 Nov 2012 18:09:56 -0000 Giles, Nabil: I think all the comments regarding this last call have been resolved. I have already incorporated them into the next rev. of the draft. Regards, Ali On 11/4/12 1:02 PM, "Giles Heron" wrote: >Thanks Lucy, > >authors - I'd like to see you address Yuanlong and Lucy's comments. >Perhaps you can discuss face-to-face this week? > >Once the comments have been addressed we can progress the draft further. > >thanks. > >Giles > >On 4 Nov 2012, at 19:40, Lucy yong wrote: > >> I support this draft but have some comments. >>=20 >> 1) in section 4.3, Text: The latter scenario often means that requiring >>a dedicated >> link between the PEs, for the operation of the multi-homing >>mechanism, is not appealing from cost standpoint. >>=20 >> Comment: a dedicated link between PEs. will this link is in IGP link >>too? or private link. >> May PE nodes that are multi-homed to a same CE be different ASes? If >>yes, state it out. >>=20 >> 2) in section 4.6, the last paragraph should state a requirement for >>flow based load balance. >>=20 >> 3) It should add one requirement in supporting Ethernet L2VPN across >>multi-ASes >>=20 >> 4) As the draft mentioned, the new service interfaces are required for >>DC interconnection. If DC uses NVo3 in future, will these service >>interfaces are still necessary? Suggest giving some use cases where the >>new service interfaces are necessary in an appendix. >>=20 >> Cheers, >> Lucy >>=20 >>> ------------------------------ >>> Date: Fri, 19 Oct 2012 23:34:53 +0100 >>> From: Giles Heron >>> To: "l2vpn@ietf.org" >>> Subject: WG Last Call for draft-ietf-l2vpn-evpn-req >>> Message-ID: <755C3ABB-ADE3-42EE-8BE1-FBBEDB84BC32@gmail.com> >>> Content-Type: text/plain; charset=3Dus-ascii >>>=20 >>> This email initiates an L2VPN WG Last Call for: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-req-01 >>>=20 >>> please comment to the list as to the suitability of this draft for >>> publication as a Standards Track RFC from the L2VPN WG. >>>=20 >>> this last call will close on Friday 2nd November. >>>=20 >>> Nabil & Giles >>=20 > From internet-drafts@ietf.org Fri Nov 16 18:03:40 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 3A8C121F8779; Fri, 16 Nov 2012 18:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 hcYLFjsOY0qp; Fri, 16 Nov 2012 18:03:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF94C21F8456; Fri, 16 Nov 2012 18:03:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-pbb-vpls-interop-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121117020339.4304.74176.idtracker@ietfa.amsl.com> Date: Fri, 16 Nov 2012 18:03:39 -0800 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, 17 Nov 2012 02:03:40 -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 Interoperability with Provider Backbone Bridges Author(s) : Ali Sajassi Samer Salam Chris Metz Nabil Bitar Dinesh Mohan Florin Balus Filename : draft-ietf-l2vpn-pbb-vpls-interop-03.txt Pages : 26 Date : 2012-11-16 Abstract: The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge functionality in VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008, and aims to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H- VPLS with existing MPLS access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-pbb-vpls-interop There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-vpls-interop-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-pbb-vpls-interop-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lucy.yong@huawei.com Tue Nov 20 12:57:30 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 A47F721F848B for ; Tue, 20 Nov 2012 12:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.225, 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 IQgUgTJaMXU3 for ; Tue, 20 Nov 2012 12:57:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4346321F8479 for ; Tue, 20 Nov 2012 12:57:27 -0800 (PST) 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 AMZ32847; Tue, 20 Nov 2012 20:57:26 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 20:56:58 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 20:57:24 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 12:57:20 -0800 From: Lucy yong To: "Ali Sajassi (sajassi)" Subject: editing suggestion on draft-ietf-l2vpn-evpn-02 Thread-Topic: editing suggestion on draft-ietf-l2vpn-evpn-02 Thread-Index: Ac3HYaCxlVOoEalPR/aKnfP6DKoG8Q== Date: Tue, 20 Nov 2012 20:57:19 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448328A1@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.49] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D448328A1dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "draft-ietf-l2vpn-evpn@tools.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, 20 Nov 2012 20:57:30 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D448328A1dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ali, In the L2VPN WG meeting, I pointed out that current draft states multicast = related process in several chapters and suggested to consolidate them. Here= is my suggestion how to consolidate them. Make charter 12, 13 and 17 into one chapter titled as broad, multi, and unk= nown cast processing and place this chapter at current charter 17 position.= Make the 12,13, and 17 content as three sub-sections in the new chapter. I= MO: 13.2 is not necessary. It just needs to state that the procedures for u= sing P-tunnel is the same as the procedure in 12.2. The large paragraph in = section 14.1 for unknown flood processing is redundant too, just need to a = reference. Charter 17 also have some redundant text that mentioned in 12 o= r 13 such as ingress replication and p2mp LSPs, etc. Under the suggested organization, the draft structure will be more clear, c= hapter 8 is about BGP extension, chapter 9 is about multi-homing functions.= Chapter 10~14 is about unicast traffic process and charter. The chapter 15= (new charter) is about multicasting process. Here are some additional comments and suggestions on the draft. * Chapter 7, Ethernet Tag. Comment: it is very important for us to distinct the multiple broadcast dom= ains and separated MAC spaces in the network virtualization. The document s= hould state that "an Ethernet Tag identifies a particular broadcast domain = in an EVI, e.g. a VLAN, in an EVI. An EVI corresponds to one customer MAC s= pace and consists of one or more broadcast domains and." * Text in Ch 7: Further, some deployment scenarios guarantee uniqueness of broadcast domain identifiers across all EVIs; all points of attachment of a given EVI use the same broadcast domain identifier(s) and no other EVI uses these broadcast domain identifier(s). Comments: I think that it means that uniqueness of broadcast domain = identifier across all PEs for a given EVI. Since one PE may be configured with multiple EVI for different customer. Current stateme= nt makes a bit of confusion. * Text in 7.3, Furthermore, there are multiple bridge domains per PE for the EVI: = one broadcast domain per CE broadcast domain identifier. The sentence is not clear. Do you mean multiple broadcast domains per= PE for the EVI? If yes, it is better to state as multiple multicast domai= ns per PE for the EVI. In fact, the text in 8.3 and 17 describes the relate= d procedures in supporting multiple multicast domains. * Text in 17.3, The procedures are the same as those in [VPLS-MCAST] with S- PMSI A-= D routes in [VPLS-MCAST] replaced by E-VPN Selective A-D routes. Should it be: The procedures are the same as those in [VPLS-MCAST] = with S- PMSI A-D routes in [VPLS-MCAST] and replaced by E-VPN Selective A-D= routes. * Text in 17.3, A E-VPN Selective A-D route includes an optional Ethernet Tag field. Also an E-VPN selective A-D route may encode a MAC address in the Group field. The encoding details of the E-VPN selective A-D route will be described in the next revision. I don't think this can be down such each. How to match the selective tre= e and Ethernet tag based multicast domain? Can they have different topologi= es? * Text in ch 12 : received from a CE encapsulated in a given Ethern= et Tag in an EVI, ... should be: received from a CE and encapsulated with a given Ethernet Tag at= PE for an EVI,... * The document use P2MP LSP and P-tunnel in these chapters and desc= ribe for the same purpose. Suggest to make them consistent. * Change "imposition PE" to "ingress PE" and "disposition PE" to "= egress PE". We don't need to define new components to describe the procedur= e. * Replace "a E-VPN" to "an E-VPN" Hope these help make the document more clear, concise, and less duplication= s. Regards, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D448328A1dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ali,

 

In the L2VPN WG meeting, I pointed out that current = draft states multicast related process in several chapters and suggested to= consolidate them. Here is my suggestion how to consolidate them.

 

Make charter 12, 13 and 17 into one chapter titled a= s broad, multi, and unknown cast processing and place this chapter at curre= nt charter 17 position. Make the 12,13, and 17 content as three sub-section= s in the new chapter. IMO: 13.2 is not necessary. It just needs to state that the procedures for using P-tunn= el is the same as the procedure in 12.2. The large paragraph in section 14.= 1 for unknown flood processing is redundant too, just need to a  refer= ence. Charter 17 also have some redundant text that mentioned in 12 or 13 such as ingress replication and p2mp LSPs,= etc.

 

Under the suggested organization, the draft structur= e will be more clear, chapter 8 is about BGP extension, chapter 9 is about = multi-homing functions. Chapter 10~14 is about unicast traffic process and = charter. The chapter 15 (new charter) is about multicasting process.

 

 

Here are some additional comments and suggestions on= the draft.

 

·         Chapter 7, Ethernet Tag.

Comment: it is very impo= rtant for us to distinct the multiple broadcast domains and separated MAC s= paces in the network virtualization. The document should state that “= an Ethernet Tag identifies a particular broadcast domain in an EVI, e.g. a VLAN, in an EVI. An EVI corresponds to one custom= er MAC space and consists of one or more broadcast domains and.”

 

·         Text in Ch 7:

   Further, some deployment sc= enarios guarantee uniqueness of broadcast

   domain identifiers across all EV= Is;  all points of attachment of a

   given EVI use the same broadcast= domain identifier(s) and no other

=    EVI uses these broadcast domain identifier(s).

=  

       Comments: I thi= nk that it means that uniqueness of broadcast domain identifier across &nbs= p;all PEs for a given EVI. Since one PE may be  

       configured= with multiple EVI for different customer. Current statement makes a bit of= confusion.

 

·         Text in 7.3,

        Furt= hermore, there are multiple bridge domains per PE for the EVI: one broadcas= t domain per CE broadcast domain

       identifier.

 

      The sentence is not c= lear. Do you mean multiple broadcast domains per PE for the EVI?  If y= es, it is better to state as multiple multicast domains per PE for the EVI.= In fact, the text in 8.3 and 17 describes the related procedures in supporting multiple multicast domains.

 

·         Text in 17.3,

       The procedures = are the same as those in [VPLS-MCAST] with S- PMSI A-D routes in [VPLS-MCAS= T] replaced by E-VPN Selective A-D

   routes.

 

       Should it be: &= nbsp;The procedures are the same as those in [VPLS-MCAST] with S- PMSI A-D = routes in [VPLS-MCAST] and replaced by E-VPN Selective A-D  routes.

 

·         Text in 17.3,

   A E-VPN Selective A-D route incl= udes an optional

   Ethernet Tag field. Also an E-VP= N selective A-D route may encode a

   MAC address in the Group field. = The encoding details of the E-VPN

   selective A-D route will be desc= ribed in the next revision.

 

   I don’t think this can be = down such each. How to match the selective tree and Ethernet tag based mult= icast domain? Can they have different topologies?

 

·         Text in ch 12 : received from a CE encapsula= ted in a given Ethernet Tag in an EVI, …

should be: received from = a CE and encapsulated with a given Ethernet Tag at PE for an EVI,…

 

·         The document use P2MP LSP and P-tunnel in th= ese chapters and describe for  the same purpose. Suggest to make them = consistent.

 

·         Change “imposition PE”  to = “ingress PE” and “disposition PE” to “egress = PE”. We don’t need to define new components to describe the pro= cedure.

·         Replace “a E-VPN” to “an E= -VPN”

 

Hope these help make the document more clear, concis= e, and less duplications.

 

Regards,

Lucy

 

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D448328A1dfweml505mbx_-- From Internet-Drafts@ietf.org Tue Nov 27 14:05: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 0715C21F84BC; Tue, 27 Nov 2012 14:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 P28eyHmxQlAD; Tue, 27 Nov 2012 14:05:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66921F849A; Tue, 27 Nov 2012 14:05:43 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121127220543.32343.40374.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 14:05:43 -0800 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, 27 Nov 2012 22:05:44 -0000 --NextPart 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 : Multicast in VPLS Author(s) : R. Aggarwal, et al Filename : draft-ietf-l2vpn-vpls-mcast Pages : 47 Date : Nov. 27, 2012 This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-mcast"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-11-27140543.I-D@ietf.org> --NextPart-- From giles.heron@gmail.com Wed Nov 28 08:14:50 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 7879421F87F7 for ; Wed, 28 Nov 2012 08:14:50 -0800 (PST) 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 oAs2u3sq+AVl for ; Wed, 28 Nov 2012 08:14:50 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C02D921F87EE for ; Wed, 28 Nov 2012 08:14:49 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so5096719eaa.31 for ; Wed, 28 Nov 2012 08:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=sPyeG+kWKABQirWV4TLHJNYwVSvMYi/G5GS9qULkJwI=; b=ZMY/VEfE6XYOy4hgYF87mjvDGvkEfyiWYH7fI+vFf1n9T31IfiFUlunnjI5nWEgxPm r/nI0AO9jmR9f2gizz+gnfPZZDtnK7o+m2Wm47A3LYKUSGzKH4kK8/9BbI+jvbDoLOL4 hiIEPyaDu97L7k36I+dVcsuhtj+6WGfYRGLsHy8pF/g8aIB0zMut5I9nE2NLnGKrAyP2 5nzptjZn5RysMay6RkmN1QJJKYFUaPK2ggDbSYz4bHsNK7RcQCRxDG5msWCYQIh8kUV+ qh37degFrdD/GkrEY+ykBXnAsDCp1Hr5YHEGTxov+Nc8arl0kgb1clUPuDIwYWHWifZI F2uA== Received: by 10.14.194.71 with SMTP id l47mr70577668een.6.1354119288943; Wed, 28 Nov 2012 08:14:48 -0800 (PST) Received: from dhcp-bdlk10-vlan254-10-147-56-125.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 46sm47905884eeg.4.2012.11.28.08.14.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Nov 2012 08:14:48 -0800 (PST) From: Giles Heron Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: L2VPN Minutes Date: Wed, 28 Nov 2012 16:14:40 +0000 Message-Id: To: "l2vpn@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Andrew McLachlan 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, 28 Nov 2012 16:14:50 -0000 Hi all I've posted the draft L2VPN minutes from Atlanta: http://www.ietf.org/proceedings/85/minutes/minutes-85-l2vpn thanks to Drew for taking these. please do send any corrections to me and I'll amend and re-post. Giles From nabil.n.bitar@verizon.com Wed Nov 28 13:50: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 64CDB21F8431 for ; Wed, 28 Nov 2012 13:50:48 -0800 (PST) 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=[AWL=-0.001, 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 4aV78+ESedzg for ; Wed, 28 Nov 2012 13:50:47 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 23CC621F842F for ; Wed, 28 Nov 2012 13:50:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 28 Nov 2012 21:50:40 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.84,180,1355097600"; d="scan'208,217";a="374945409" Received: from fldp1lumxc7hb04.verizon.com (HELO FLDP1LUMXC7HB04.us.one.verizon.com) ([166.68.75.83]) by fldsmtpi01.verizon.com with ESMTP; 28 Nov 2012 21:50:34 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB04.us.one.verizon.com ([166.68.75.83]) with mapi; Wed, 28 Nov 2012 16:50:34 -0500 To: "l2vpn@ietf.org" Date: Wed, 28 Nov 2012 16:50:25 -0500 Subject: Polling for IPR on the VPLS multicast draft draft-ietf-l2vpn-vpls-mcast-12 Thread-Topic: Polling for IPR on the VPLS multicast draft draft-ietf-l2vpn-vpls-mcast-12 Thread-Index: Ac3NsmSdDw+mFXOvSQyN+l64ChdrBg== 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: multipart/alternative; boundary="_000_CCDBE6286B889nabilnbitarverizoncom_" 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: Wed, 28 Nov 2012 21:50:48 -0000 --_000_CCDBE6286B889nabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= ls-mcast-12.txt, multicast in VPLS, in order to ensure that IPR has been di= sclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 53= 78 for more details). If you are listed as a document author or contributor, please respond to t= his email whether or not you are aware of any relevant IPR that has not bee= n properly disclosed. The draft will not be adopted until a response has be= en received from each author and contributor. If you are on the l2vpn WG email list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. The draft c= an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-12 This poll closes on Monday December 3, 2012. Thanks, Nabil & Giles --_000_CCDBE6286B889nabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

We are polling for knowl= edge of any IPR that applies to draft-ietf-l2vpn-vpls-mcast-12.txt, mu= lticast in VPLS, in order to ensure that IPR has been disclosed in com= pliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).=  

If you are listed as a docum= ent author o= r contributor,  please respond to this email whether or not you a= re aware of any relevant IPR that has not been properly disclosed. The draft w= ill not be adopted until a response has been received from each author= and contributor.

If you are on the l2vpn WG email list but are not listed= as an author of any IPR that has not yet been disclosed in conformance with IETF rules. The dr= aft can be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mca= st-12
<= div>


Thanks,
Nabil & Giles


=

--_000_CCDBE6286B889nabilnbitarverizoncom_-- From yakov@juniper.net Wed Nov 28 14:08: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 3DE0B21F8943 for ; Wed, 28 Nov 2012 14:08:21 -0800 (PST) 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 7-GHm4VVyud4 for ; Wed, 28 Nov 2012 14:08:20 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1D79C21F846A for ; Wed, 28 Nov 2012 14:08:19 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKULaLT/saJAootSIMRFcKn89ni6ophS91@postini.com; Wed, 28 Nov 2012 14:08:20 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 28 Nov 2012 14:06:37 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qASM6Y304419; Wed, 28 Nov 2012 14:06:35 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201211282206.qASM6Y304419@magenta.juniper.net> To: "Bitar, Nabil N" Subject: Re: Polling for IPR on the VPLS multicast draft draft-ietf-l2vpn-vpls-mcast-12 In-Reply-To: References: X-MH-In-Reply-To: "Bitar, Nabil N" message dated "Wed, 28 Nov 2012 16:50:25 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9500.1354140392.1@juniper.net> Date: Wed, 28 Nov 2012 14:06:32 -0800 From: Yakov Rekhter Cc: "l2vpn@ietf.org" , yakov@juniper.net, 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: Wed, 28 Nov 2012 22:08:21 -0000 Nabil, > Hi, > > We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= > ls-mcast-12.txt, multicast in VPLS, in order to ensure that IPR has been di= > sclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 53= > 78 for more details). > > If you are listed as a document author or contributor, please respond to t= > his email whether or not you are aware of any relevant IPR that has not bee= > n properly disclosed. The draft will not be adopted until a response has be= > en received from each author and contributor. > > If you are on the l2vpn WG email list but are not listed as an author or co= > ntributor, then please explicitly respond only if you are aware of any IPR = > that has not yet been disclosed in conformance with IETF rules. The draft c= > an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-12 > > This poll closes on Monday December 3, 2012. Juniper has already disclosed several IPRs at https://datatracker.ietf.org/ipr/1117/. In view of the large number of patent applications involved, we would like to take this opportunity to check whether there are any other declarations or updates. Yakov. From jakob.heitz@ericsson.com Wed Nov 28 14:49: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 AD7A521F890A for ; Wed, 28 Nov 2012 14:49:56 -0800 (PST) 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=[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 SwtkiLIqpjgd for ; Wed, 28 Nov 2012 14:49:56 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2D20621F8902 for ; Wed, 28 Nov 2012 14:49:56 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qASMnVgm012499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Nov 2012 16:49:55 -0600 Received: from EUSAAHC002.ericsson.se (147.117.188.78) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 28 Nov 2012 17:49:45 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 17:49:45 -0500 From: Jakob Heitz To: "l2vpn@ietf.org" Subject: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UA== Date: Wed, 28 Nov 2012 22:49:44 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E0F65FD@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0F65FDeusaamb109ericsso_" MIME-Version: 1.0 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, 28 Nov 2012 22:49:56 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0F65FDeusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a LAG interface (ES1), and is sending packets with MAC address MAC1 on VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a Ethe= rnet A-D route per ESI for ESI1 as well as an Ethernet A-D route per EVI for . A remote PE, PE3 considers MAC1 as reachable via both PE1 and PE2. Now, suppose PE1 withdraws its advertisement of MAC1. Does PE3 still consider MAC1 as reachable via PE2? I would think not, but it's not stated in the draft. -- Jakob Heitz. x25475. 510-566-2901 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0F65FDeusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
   Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2=
) on a
   LAG interface (ES1), and is sending packets with MAC address MAC1 on
   VLAN1. MAC1 is advertised only by PE1=
. Both PE1 and PE2 advertise a Ethernet A-D
   route per ESI for ESI1 as well as an Ethernet A-D route per EVI for
   <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 as reachable
   via both PE1 and PE2.
&nbs= p;
Now, suppose PE1 withdraws its advertisement of MAC= 1.
Does PE3 still consider MAC1 as reachable via PE2?<= /font>
I would think not, but it's not stated in the draft= .

-- Jakob Heitz. x25475. 5= 10-566-2901

 
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0F65FDeusaamb109ericsso_-- From sajassi@cisco.com Thu Nov 29 00:21: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 E96C221F8983 for ; Thu, 29 Nov 2012 00:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ismR7vjtaTqc for ; Thu, 29 Nov 2012 00:21:07 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B649421F8965 for ; Thu, 29 Nov 2012 00:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5509; q=dns/txt; s=iport; t=1354177266; x=1355386866; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=M0bv8pwCf1Yg1RaTeKFxPZfJf1zDzJ35ygdneNNKSBs=; b=NUwnPu82WIV0LFdv+T0a/bA1OKqWWrRSvkQdU5xoFKfasQ8TFYsmH/Cn OEiHOstxzajQh7c4bhKb5Wv9/5ntPGO7O/qIy9oRwda51E5ueHpUctvf2 hniilAKD8grHMLiRFm3W5/3B253fYQYEdVoVfAcRDhd2muimeYfsThS8u Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADIat1CtJXG8/2dsb2JhbABBA4JJI703FnOCHgEBAQQtXgEIEQMBAgsdORQJCAEBBAESCIgIAb8+jD+BFYJLYQOmRYJygiE X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147479542" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 29 Nov 2012 08:21:06 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAT8L6vf008378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 08:21:06 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 02:21:05 -0600 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKA Date: Thu, 29 Nov 2012 08:21:04 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7D0080@xmb-aln-x13.cisco.com> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E0F65FD@eusaamb109.ericsson.se> 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.145.235] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B0D7D0080xmbalnx13ciscoc_" MIME-Version: 1.0 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, 29 Nov 2012 08:21:08 -0000 --_000_69670F7146898C4583F56DA9AD32F77B0D7D0080xmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good question! The reason that PE1 withdraws MAC1 can be: 1. there is a failure between MHD and PE1 (e.g., a link or port failure) 2. MAC1 ages out on PE1 In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency for = MAC1 to PE2. In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE2. In= this case, MAC1 is not reachable via either PE1 or PE2. I think we can elaborate this on the next rev. of the draft. Cheers, Ali From: Jakob Heitz > Date: Wednesday, November 28, 2012 2:49 PM To: "l2vpn@ietf.org" > Subject: EVPN: withdrawing the alias Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a LAG interface (ES1), and is sending packets with MAC address MAC1 on VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a Ethe= rnet A-D route per ESI for ESI1 as well as an Ethernet A-D route per EVI for . A remote PE, PE3 considers MAC1 as reachable via both PE1 and PE2. Now, suppose PE1 withdraws its advertisement of MAC1. Does PE3 still consider MAC1 as reachable via PE2? I would think not, but it's not stated in the draft. -- Jakob Heitz. x25475. 510-566-2901 --_000_69670F7146898C4583F56DA9AD32F77B0D7D0080xmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <7AEDA959A0992B44B0B63E7113CBECB4@cisco.com> Content-Transfer-Encoding: quoted-printable

Good question! The reason that PE1 withdraws MAC1 can be:

  1. there is a failure between MHD and PE1 (e.g., a link or port failure)
  2. MAC1 ages out on PE1
In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency= for MAC1 to PE2.
In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE= 2. In this case, MAC1 is not reachable via either PE1 or PE2.

I think we can elaborate this on the next rev. of the draft.

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, November 28, 2012 = 2:49 PM
To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: EVPN: withdrawing the alia= s

   Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2=
) on a
   LAG interface (ES1), and is sending packets with MAC address MAC1 on
   VLAN1. MAC1 is advertised only by PE1=
. Both PE1 and PE2 advertise a Ethernet A-D
   route per ESI for ESI1 as well as an Ethernet A-D route per EVI for
   <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 as reachable
   via both PE1 and PE2.
&nbs= p;
Now, suppose PE1 withdraws its advertisement of MAC= 1.
Does PE3 still consider MAC1 as reachable via PE2?<= /font>
I would think not, but it's not stated in the draft= .

-- Jakob Heitz. x25475. 5= 10-566-2901

 
 --_000_69670F7146898C4583F56DA9AD32F77B0D7D0080xmbalnx13ciscoc_-- From jakob.heitz@ericsson.com Thu Nov 29 05:02: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 49AE321F89DC for ; Thu, 29 Nov 2012 05:02:28 -0800 (PST) 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=[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 gu1GnWZtoiIb for ; Thu, 29 Nov 2012 05:02:21 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id ADC3D21F89D7 for ; Thu, 29 Nov 2012 05:02:21 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qATD2Koo009479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 07:02:20 -0600 Received: from EUSAAHC008.ericsson.se (147.117.188.96) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 08:02:19 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 08:02:19 -0500 From: Jakob Heitz To: "Ali Sajassi (sajassi)" Subject: Re: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8= Date: Thu, 29 Nov 2012 13:02:19 +0000 Message-ID: <99A8A675-B3B5-4F26-8D40-EFCA70F7A8D0@ericsson.com> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E0F65FD@eusaamb109.ericsson.se>, <69670F7146898C4583F56DA9AD32F77B0D7D0080@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7D0080@xmb-aln-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_99A8A675B3B54F268D40EFCA70F7A8D0ericssoncom_" 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, 29 Nov 2012 13:02:28 -0000 --_000_99A8A675B3B54F268D40EFCA70F7A8D0ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In case of (1), PE2 will advertise MAC1 *only* if there is traffic from MAC= 1. This is by no means assured. In that case, if PE2 does not advertise MAC= 1 before PE1 withdraws it, does PE3 consider MAC1 as unknown? Perhaps PE1 could delay its withdrawal, or not send it at all. PE1 withdraw= s the Ethernet A-D. That could trigger an aging timer on PE3 for the alias. I propose: If a PE has advertised an Ethernet A-D route and has advertised a MAC route= covered by that Ethernet A-D route and this PE subsequently withdraws the = Ethernet A-D route, then it shall not withdraw the MAC route. If a first PE has received an Ethernet A-D route and a MAC route covered by= that Ethernet A-D route from a second PE and has an alias for that MAC rou= te from a third PE and subsequently receives a withdrawal of the Ethernet A= -D route from the second PE, then the first PE shall immediately delete its= MAC route to the second PE and start an aging timer to delete its alias. -- Jakob Heitz. On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" > wrote: Good question! The reason that PE1 withdraws MAC1 can be: 1. there is a failure between MHD and PE1 (e.g., a link or port failure) 2. MAC1 ages out on PE1 In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency for = MAC1 to PE2. In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE2. In= this case, MAC1 is not reachable via either PE1 or PE2. I think we can elaborate this on the next rev. of the draft. Cheers, Ali From: Jakob Heitz > Date: Wednesday, November 28, 2012 2:49 PM To: "l2vpn@ietf.org" > Subject: EVPN: withdrawing the alias Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a LAG interface (ES1), and is sending packets with MAC address MAC1 on VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a Ethe= rnet A-D route per ESI for ESI1 as well as an Ethernet A-D route per EVI for . A remote PE, PE3 considers MAC1 as reachable via both PE1 and PE2. Now, suppose PE1 withdraws its advertisement of MAC1. Does PE3 still consider MAC1 as reachable via PE2? I would think not, but it's not stated in the draft. -- Jakob Heitz. x25475. 510-566-2901 --_000_99A8A675B3B54F268D40EFCA70F7A8D0ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In case of (1), PE2 will advertise MAC1 *only* if there is traffic fro= m MAC1. This is by no means assured. In that case, if PE2 does not advertis= e MAC1 before PE1 withdraws it, does PE3 consider MAC1 as unknown?

Perhaps PE1 could delay its withdrawal, or not send it at all. PE1 wit= hdraws the Ethernet A-D. That could trigger an aging timer on PE3 for the a= lias.

I propose:

If a PE has advertised an Ethernet A-D route and has advertised a MAC = route covered by that Ethernet A-D route and this PE subsequently withdraws= the Ethernet A-D route, then it shall not withdraw the MAC route.

If a first PE has received an Ethernet A-D route and a MAC route covered by that Ethernet A-D route from= a second PE and has an alias for that MAC route from a third PE and subseq= uently receives a withdrawal of the Ethernet A-D route from the second PE, then the first PE shall immediately delete i= ts MAC route to the second PE and start an aging timer to delete its alias.=

--
Jakob Heitz.


On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:


Good question! The reason that PE1 withdraws MAC1 can be:

  1. there is a failure between MHD and PE1 (e.g., a link or port failure)
  2. MAC1 ages out on PE1
In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency= for MAC1 to PE2.
In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE= 2. In this case, MAC1 is not reachable via either PE1 or PE2.

I think we can elaborate this on the next rev. of the draft.

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, November 28, 2012 = 2:49 PM
To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: EVPN: withdrawing the alia= s

   Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2=
) on a
   LAG interface (ES1), and is sending packets with MAC address MAC1 on
   VLAN1. MAC1 is advertised only by PE1=
. Both PE1 and PE2 advertise a Ethernet A-D
   route per ESI for ESI1 as well as an Ethernet A-D route per EVI for
   <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 as reachable
   via both PE1 and PE2.
&nbs= p;
Now, suppose PE1 withdraws its advertisement of MAC= 1.
Does PE3 still consider MAC1 as reachable via PE2?<= /font>
I would think not, but it's not stated in the draft= .

-- Jakob Heitz. x25475. 5= 10-566-2901

 
--_000_99A8A675B3B54F268D40EFCA70F7A8D0ericssoncom_-- From lufang@cisco.com Thu Nov 29 06:54: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 BD3AD21F8A92 for ; Thu, 29 Nov 2012 06:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8-fEXPRRXxv for ; Thu, 29 Nov 2012 06:54:00 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAC021F8A7D for ; Thu, 29 Nov 2012 06:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8740; q=dns/txt; s=iport; t=1354200821; x=1355410421; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=XlRTZqh6e3JBb7zp+vbow7PfjP7T4Cmi7znZvfeL31o=; b=QItsOlUBSe81HV8wy27nurPzUqp6Bbm9w7r3pBoJVYrU31f70qVqgdBT rorbqlSUjB9wdegC3CDxYtl5spmopiXxcUuHOc9CzHf5NZRJ1SD8j5QrG 5ihoCnHA8az0XARtAZQBPbcZfW1t4ewkUAFU8cuomEVxTWQuPcZH1pMLt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FANV1t1CtJV2a/2dsb2JhbABEgkm0SgGHBYIAFnOCHgEBAQR5EgEIEQMBAgsdORQJCAIEAQ0FCId2Aw8Mvx6LV2kLg1VhA5JPhE6PKIJygWw1 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147608058" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 29 Nov 2012 14:53:27 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qATErRnJ016409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 14:53:27 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.191]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 08:53:27 -0600 From: "Luyuan Fang (lufang)" To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: Re: Polling for IPR on the VPLS multicast draft draft-ietf-l2vpn-vpls-mcast-12 Thread-Topic: Polling for IPR on the VPLS multicast draft draft-ietf-l2vpn-vpls-mcast-12 Thread-Index: AQHNzkFJs8gg109Sr0uulj/fDdu7kg== Date: Thu, 29 Nov 2012 14:53:26 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD931018BF76@xmb-rcd-x03.cisco.com> 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.4.120824 x-originating-ip: [10.21.88.124] Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD931018BF76xmbrcdx03ciscoc_" MIME-Version: 1.0 Cc: "Giles Heron \(giheron\)" 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, 29 Nov 2012 14:54:02 -0000 --_000_0DB8F45437AB844CBB5102F807A0AD931018BF76xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not from my side. Luyuan From: , Nabil N > Date: Wednesday, November 28, 2012 4:50 PM To: "l2vpn@ietf.org" > Cc: "Giles Heron (giheron)" > Subject: Polling for IPR on the VPLS multicast draft draft-ietf-l2vpn-vpls-= mcast-12 Hi, We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= ls-mcast-12.txt, multicast in VPLS, in order to ensure that IPR has been di= sclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 53= 78 for more details). If you are listed as a document author or contributor, please respond to t= his email whether or not you are aware of any relevant IPR that has not bee= n properly disclosed. The draft will not be adopted until a response has be= en received from each author and contributor. If you are on the l2vpn WG email list but are not listed as an author or co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. The draft c= an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-12 This poll closes on Monday December 3, 2012. Thanks, Nabil & Giles --_000_0DB8F45437AB844CBB5102F807A0AD931018BF76xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <27B833B7EC73AD4B98BD7C63BCF95755@cisco.com> Content-Transfer-Encoding: quoted-printable
Not from my side.
Luyuan

From: <Bitar>, Nabil N <nabil.n.bitar@verizon.com>= ;
Date: Wednesday, November 28, 2012 = 4:50 PM
To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Cc: "Giles Heron (giheron)&quo= t; <giheron@cisco.com>
Subject: Polling for IPR on the VPL= S multicast draft draft-ietf-l2vpn-vpls-mcast-12

Hi,

We are polling for knowledge of any IPR= that applies to draft-ietf-l2vpn-vpls-mcast-12.txt, multicast in VPLS, in order to ensu= re that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).=  

If you are listed as a document author&= nbsp;or contributor,  please respond to this email whether or not you ar= e aware of any relevant IPR that has not been properly disclosed. The draft will not be adopted until a response has been received from eac= h author and contributor.

If = you are on the l2vpn WG email list but are not listed as an author or contributor, then= please explicitly respond only if you are aware of an= y IPR that has not yet been disclosed in conformance with IETF = rules. The draft can be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mca= st-12

This poll closes on Monday December 3, 2012.

Thanks,
Nabil & Giles



 --_000_0DB8F45437AB844CBB5102F807A0AD931018BF76xmbrcdx03ciscoc_-- From sajassi@cisco.com Thu Nov 29 11:19: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 65E9B21F8B9E for ; Thu, 29 Nov 2012 11:19:08 -0800 (PST) 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 oAP0y0+9twX9 for ; Thu, 29 Nov 2012 11:19:07 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 29E8C21F8B6D for ; Thu, 29 Nov 2012 11:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12781; q=dns/txt; s=iport; t=1354216747; x=1355426347; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=PO7w7EIlqFwF4MW66nKOqG/RDwjnEEr1prvHYRp1Reg=; b=hbgSSdftsuIFJA02+OKecC01L1/89G0gT1tYuFdofUYhnSut7QzMr71g 4jP3NQ1fTKki9Pju5L3rJwjV2+KVdTKU7U3IVm/DOuBUcQCHWN4kzZPYN 8a8sV8biOO4redYmklhrfpXTNsIFK3VrNpyPJ8ibQ56DfSdefSxr8XxdB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANe0t1CtJV2Z/2dsb2JhbABBA4JJI70ZFnOCHgEBAQQtTBIBCBEDAQILHTkUCQgBAQQOBQiICAG/HYxAgRWCS2EDpkWCcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147710408" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 29 Nov 2012 19:19:00 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qATJJ0ul007719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 19:19:00 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.0318.001; Thu, 29 Nov 2012 13:19:00 -0600 From: "Ali Sajassi (sajassi)" To: Jakob Heitz Subject: Re: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgA== Date: Thu, 29 Nov 2012 19:19:00 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7D03E6@xmb-aln-x13.cisco.com> In-Reply-To: <99A8A675-B3B5-4F26-8D40-EFCA70F7A8D0@ericsson.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: [64.101.1.7] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B0D7D03E6xmbalnx13ciscoc_" 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, 29 Nov 2012 19:19:08 -0000 --_000_69670F7146898C4583F56DA9AD32F77B0D7D03E6xmbalnx13ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Let me summarize the operation as follow: 1. if the remote PE (e.g., PE3) only receives MAC1 advertisement from on= ly one of the PE in the Multi-homing group (e.g., from PE1), then upon rece= iving withdraw message for this MAC1, PE3 will flood subsequent traffic to= ward MAC1. This covers the scenario in which MAC1 ages out on PE1. 2. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) messag= e from PE1 first (before MAC1 route withdraw), then because of aliasing, PE= 3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In which= case, it removes MAC1 entry from its table and starts flooding traffic tow= ard MAC1. This covers link/port failure scenario. More comments in line =85 From: Jakob Heitz > Date: Thursday, November 29, 2012 5:02 AM To: Cisco Employee > Cc: "l2vpn@ietf.org" > Subject: Re: EVPN: withdrawing the alias In case of (1), PE2 will advertise MAC1 *only* if there is traffic from MAC= 1. This is by no means assured. In that case, if PE2 does not advertise MAC= 1 before PE1 withdraws it, does PE3 consider MAC1 as unknown? Ali> yes, PE3 consider MAC1 as unknown and starts flooding traffic toward M= AC1 till it learns it from PE2. Perhaps PE1 could delay its withdrawal, or not send it at all. PE1 withdraw= s the Ethernet A-D. That could trigger an aging timer on PE3 for the alias. Ali> No need to delay the withdraw. Ether AD mass-withdraw message will cau= se PE3 to remove aliasing and thus traffic gets forwarded to PE2 for MAC1. = If MAC1 is advertised by PE2 before MAC1 is withdrawn by PE1, then there i= s no flooding; otherwise, there will be little bit of flooding till PE3 lea= rns MAC1 from PE2. Cheers, Ali I propose: If a PE has advertised an Ethernet A-D route and has advertised a MAC route= covered by that Ethernet A-D route and this PE subsequently withdraws the = Ethernet A-D route, then it shall not withdraw the MAC route. If a first PE has received an Ethernet A-D route and a MAC route covered by= that Ethernet A-D route from a second PE and has an alias for that MAC rou= te from a third PE and subsequently receives a withdrawal of the Ethernet A= -D route from the second PE, then the first PE shall immediately delete its= MAC route to the second PE and start an aging timer to delete its alias. -- Jakob Heitz. On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" > wrote: Good question! The reason that PE1 withdraws MAC1 can be: 1. there is a failure between MHD and PE1 (e.g., a link or port failure) 2. MAC1 ages out on PE1 In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency for = MAC1 to PE2. In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE2. In= this case, MAC1 is not reachable via either PE1 or PE2. I think we can elaborate this on the next rev. of the draft. Cheers, Ali From: Jakob Heitz > Date: Wednesday, November 28, 2012 2:49 PM To: "l2vpn@ietf.org" > Subject: EVPN: withdrawing the alias Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a LAG interface (ES1), and is sending packets with MAC address MAC1 on VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a Ethe= rnet A-D route per ESI for ESI1 as well as an Ethernet A-D route per EVI for . A remote PE, PE3 considers MAC1 as reachable via both PE1 and PE2. Now, suppose PE1 withdraws its advertisement of MAC1. Does PE3 still consider MAC1 as reachable via PE2? I would think not, but it's not stated in the draft. -- Jakob Heitz. x25475. 510-566-2901 --_000_69670F7146898C4583F56DA9AD32F77B0D7D03E6xmbalnx13ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <28B7E2A19D216F42A408CB86C7D21977@cisco.com> Content-Transfer-Encoding: quoted-printable

Let me summarize the operation as follow:

  1. if the remote PE (e.g., PE3) only receives MAC1 advertisement from only= one of the PE in the Multi-homing group (e.g., from PE1), then upon receiv= ing withdraw message for this MAC1,  PE3 will flood subsequent traffic= toward MAC1. This covers the scenario in which MAC1 ages out on PE1.
  2. If the remote PE (e.g., PE3) receiv= es Ether AD (mass withdraw) message from PE1 first (before MAC1 route withd= raw), then because of aliasing, PE3 forwards traffic to PE2 till it receive= s MAC1 withdraw from PE1. In which case, it removes MAC1 entry from its table and starts flooding traffic toward MAC1. This covers link/port f= ailure scenario.

More comments in line =85

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thursday, November 29, 2012 5= :02 AM
To: Cisco Employee <sajassi@cisco.com>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: Re: EVPN: withdrawing the = alias

In case of (1), PE2 will advertise MAC1 *only* if there is traffic fro= m MAC1. This is by no means assured. In that case, if PE2 does not advertis= e MAC1 before PE1 withdraws it, does PE3 consider MAC1 as unknown?

Ali> yes, PE3 consider MAC1 as unknown and starts flooding traffic = toward MAC1 till it learns it from PE2.

Perhaps PE1 could delay its withdrawal, or not send it at all. PE1 wit= hdraws the Ethernet A-D. That could trigger an aging timer on PE3 for the a= lias.

Ali> No need to delay the withdraw. Ether AD mass-withdraw message = will cause PE3 to remove aliasing and thus traffic gets forwarded to PE2 fo= r MAC1. If MAC1 is advertised by PE2 before  MAC1 is withdrawn by PE1,= then there is no flooding; otherwise, there will be little bit of flooding till PE3 learns MAC1 from PE2.

Cheers,
Ali

I propose:

If a PE has advertised an Ethernet A-D route and has advertised a MAC = route covered by that Ethernet A-D route and this PE subsequently withdraws= the Ethernet A-D route, then it shall not withdraw the MAC route.

If a first PE has received an Ethernet A-D route and a MAC route covered by that Ethernet A-D route from= a second PE and has an alias for that MAC route from a third PE and subseq= uently receives a withdrawal of the Ethernet A-D route from the second PE, then the first PE shall immediately delete i= ts MAC route to the second PE and start an aging timer to delete its alias.=

--
Jakob Heitz.


On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:


Good question! The reason that PE1 withdraws MAC1 can be:

  1. there is a failure between MHD and PE1 (e.g., a link or port failure)
  2. MAC1 ages out on PE1
In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency= for MAC1 to PE2.
In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE= 2. In this case, MAC1 is not reachable via either PE1 or PE2.

I think we can elaborate this on the next rev. of the draft.

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, November 28, 2012 = 2:49 PM
To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: EVPN: withdrawing the alia= s

   Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2=
) on a
   LAG interface (ES1), and is sending packets with MAC address MAC1 on
   VLAN1. MAC1 is advertised only by PE1=
. Both PE1 and PE2 advertise a Ethernet A-D
   route per ESI for ESI1 as well as an Ethernet A-D route per EVI for
   <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 as reachable
   via both PE1 and PE2.
&nbs= p;
Now, suppose PE1 withdraws its advertisement of MAC= 1.
Does PE3 still consider MAC1 as reachable via PE2?<= /font>
I would think not, but it's not stated in the draft= .

-- Jakob Heitz. x25475. 5= 10-566-2901

 
 --_000_69670F7146898C4583F56DA9AD32F77B0D7D03E6xmbalnx13ciscoc_-- From lucy.yong@huawei.com Thu Nov 29 12:40: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 012BC21F8C4F for ; Thu, 29 Nov 2012 12:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 7LwvkdMPJRDY for ; Thu, 29 Nov 2012 12:40:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 25BD321F8C42 for ; Thu, 29 Nov 2012 12:40:52 -0800 (PST) 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 AMA58631; Thu, 29 Nov 2012 20:40:52 +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; Thu, 29 Nov 2012 20:40:38 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 20:40:51 +0000 Received: from DFWEML505-MBB.china.huawei.com ([169.254.1.192]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Thu, 29 Nov 2012 12:40:47 -0800 From: Lucy yong To: "Ali Sajassi (sajassi)" , Jakob Heitz Subject: RE: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgAAGcYYw Date: Thu, 29 Nov 2012 20:40:46 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44852F4C@dfweml505-mbb.china.huawei.com> References: <99A8A675-B3B5-4F26-8D40-EFCA70F7A8D0@ericsson.com> <69670F7146898C4583F56DA9AD32F77B0D7D03E6@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7D03E6@xmb-aln-x13.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.90.162] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44852F4Cdfweml505mbbchi_" 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: Thu, 29 Nov 2012 20:40:57 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44852F4Cdfweml505mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See below. From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= li Sajassi (sajassi) Sent: Thursday, November 29, 2012 1:19 PM To: Jakob Heitz Cc: l2vpn@ietf.org Subject: Re: EVPN: withdrawing the alias Let me summarize the operation as follow: 1. if the remote PE (e.g., PE3) only receives MAC1 advertisement from on= ly one of the PE in the Multi-homing group (e.g., from PE1), then upon rece= iving withdraw message for this MAC1, PE3 will flood subsequent traffic to= ward MAC1. This covers the scenario in which MAC1 ages out on PE1. [Lucy] I don't understand this action. The issue is how remote PE to differ= entiate the failure withdraw via the age out withdraw at a PE. 1. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) messag= e from PE1 first (before MAC1 route withdraw), then because of aliasing, PE= 3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In which= case, it removes MAC1 entry from its table and starts flooding traffic tow= ard MAC1. This covers link/port failure scenario. [Lucy] in second point, you mean "PE3 forwards traffic to PE2 till it recei= ves MAC1 withdraw from PE2, ...", not PE1. Lucy More comments in line ... From: Jakob Heitz > Date: Thursday, November 29, 2012 5:02 AM To: Cisco Employee > Cc: "l2vpn@ietf.org" > Subject: Re: EVPN: withdrawing the alias In case of (1), PE2 will advertise MAC1 *only* if there is traffic from MAC= 1. This is by no means assured. In that case, if PE2 does not advertise MAC= 1 before PE1 withdraws it, does PE3 consider MAC1 as unknown? Ali> yes, PE3 consider MAC1 as unknown and starts flooding traffic toward M= AC1 till it learns it from PE2. Perhaps PE1 could delay its withdrawal, or not send it at all. PE1 withdraw= s the Ethernet A-D. That could trigger an aging timer on PE3 for the alias. Ali> No need to delay the withdraw. Ether AD mass-withdraw message will cau= se PE3 to remove aliasing and thus traffic gets forwarded to PE2 for MAC1. = If MAC1 is advertised by PE2 before MAC1 is withdrawn by PE1, then there i= s no flooding; otherwise, there will be little bit of flooding till PE3 lea= rns MAC1 from PE2. Cheers, Ali I propose: If a PE has advertised an Ethernet A-D route and has advertised a MAC route= covered by that Ethernet A-D route and this PE subsequently withdraws the = Ethernet A-D route, then it shall not withdraw the MAC route. If a first PE has received an Ethernet A-D route and a MAC route covered by= that Ethernet A-D route from a second PE and has an alias for that MAC rou= te from a third PE and subsequently receives a withdrawal of the Ethernet A= -D route from the second PE, then the first PE shall immediately delete its= MAC route to the second PE and start an aging timer to delete its alias. -- Jakob Heitz. On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" > wrote: Good question! The reason that PE1 withdraws MAC1 can be: 1. there is a failure between MHD and PE1 (e.g., a link or port failure) 2. MAC1 ages out on PE1 In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency for = MAC1 to PE2. In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE2. In= this case, MAC1 is not reachable via either PE1 or PE2. I think we can elaborate this on the next rev. of the draft. Cheers, Ali From: Jakob Heitz > Date: Wednesday, November 28, 2012 2:49 PM To: "l2vpn@ietf.org" > Subject: EVPN: withdrawing the alias Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a LAG interface (ES1), and is sending packets with MAC address MAC1 on VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a Ethe= rnet A-D route per ESI for ESI1 as well as an Ethernet A-D route per EVI for . A remote PE, PE3 considers MAC1 as reachable via both PE1 and PE2. Now, suppose PE1 withdraws its advertisement of MAC1. Does PE3 still consider MAC1 as reachable via PE2? I would think not, but it's not stated in the draft. -- Jakob Heitz. x25475. 510-566-2901 --_000_2691CE0099834E4A9C5044EEC662BB9D44852F4Cdfweml505mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See below.

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Thursday, November 29, 2012 1:19 PM
To: Jakob Heitz
Cc: l2vpn@ietf.org
Subject: Re: EVPN: withdrawing the alias

 

 

Let me summarize the operat= ion as follow:

 

  1. if the remote PE (e.g., PE3) only receives MAC1 advertisement = from only one of the PE in the Multi-homing group (e.g., from PE1), then up= on receiving withdraw message for this MAC1,  PE3 will flood subsequent traffic toward MAC1. This covers the scenario in which MA= C1 ages out on PE1.

[Lucy] I don’t understand t= his action. The issue is how remote PE to differentiate the failure withdraw via the age out withdraw at a PE.

  1. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw)= message from PE1 first (before MAC1 route withdraw), then because of alias= ing, PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In which case, it removes MAC1 entry from its table and= starts flooding traffic toward MAC1. This covers link/port failure scenari= o.

[Lucy] in second point, you mean = “PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE2, …&#= 8221;, not PE1.

Lucy

 

More comments in line ̷= 0;

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thursday, November 29, 2012 5:02 AM
To: Cisco Employee <sajassi@= cisco.com>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: Re: EVPN: withdrawing the alias

 

In case of (1), PE2 will ad= vertise MAC1 *only* if there is traffic from MAC1. This is by no means assu= red. In that case, if PE2 does not advertise MAC1 before PE1 withdraws it, does PE3 consider MAC1 as unknown?

 

Ali> yes, PE3 consider M= AC1 as unknown and starts flooding traffic toward MAC1 till it learns it fr= om PE2.

 

Perhaps PE1 could delay its= withdrawal, or not send it at all. PE1 withdraws the Ethernet A-D. That co= uld trigger an aging timer on PE3 for the alias.

 

Ali> No need to delay th= e withdraw. Ether AD mass-withdraw message will cause PE3 to remove aliasin= g and thus traffic gets forwarded to PE2 for MAC1. If MAC1 is advertised by PE2 before  MAC1 is withdrawn by PE1, then there is = no flooding; otherwise, there will be little bit of flooding till PE3 learn= s MAC1 from PE2.

 

Cheers,

Ali

 

I propose:

 

If a PE has advertised an E= thernet A-D route and has advertised a MAC route covered by that Ethernet A= -D route and this PE subsequently withdraws the Ethernet A-D route, then it shall not withdraw the MAC route.

 

If a first PE has received&= nbsp;an Ethernet A-D route and a MAC route= covered by that Ethernet A-D route from a second PE and has an alias for that MAC route from a third PE and subsequently receives a withd= rawal of the Ethernet A-D route from the second PE, then the first PE = shall immediately delete its MAC route to the second PE and start an aging = timer to delete its alias.

--

Jakob Heitz.

 


On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:

 

Good question! The reason t= hat PE1 withdraws MAC1 can be:

 

  1. there is a failure between MHD and PE1 (e.g., a link or port f= ailure)
  2. MAC1 ages out on PE1

In case of (1), PE2 will ad= vertise MAC1 and PE3 will set its adjacency for MAC1 to PE2.

In case of (2), PE1 withdra= ws MAC1 but there is no advertisement by PE2. In this case, MAC1 is not rea= chable via either PE1 or PE2.

 

I think we can elaborate th= is on the next rev. of the draft.

 

Cheers,

Ali

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, November 28, 2012 2:49 PM
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: EVPN: withdrawing the alias

  

   Consider a CE (CE1) that is dual-homed to tw=
o PEs (PE1 and PE2) on a
 &=
nbsp; LAG interface (ES1), and is sending packets with MAC address MAC1 on<=
o:p>
 &=
nbsp; VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a E=
thernet A-D
 &=
nbsp; route per ESI for ESI1 as well as an Ethernet A-D route per EVI for
 &=
nbsp; <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 as reachable
 &=
nbsp; via both PE1 and PE2.

 

Now, suppose PE1 withdraws its advertiseme= nt of MAC1.

Does PE3 still consider MAC1 as reachable = via PE2?

I would think not, but it's not stated in = the draft.

--
Jakob Heitz. x25475. 510-566-2901

 

--_000_2691CE0099834E4A9C5044EEC662BB9D44852F4Cdfweml505mbbchi_-- From jakob.heitz@ericsson.com Thu Nov 29 13:01: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 CB38C21F88CD for ; Thu, 29 Nov 2012 13:01:37 -0800 (PST) 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=[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 gkUx6txzOp2n for ; Thu, 29 Nov 2012 13:01:34 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 313D321F885F for ; Thu, 29 Nov 2012 13:01:34 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qATLA0BH022783; Thu, 29 Nov 2012 15:10:02 -0600 Received: from EUSAAHC007.ericsson.se (147.117.188.93) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 16:01:23 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 16:01:23 -0500 From: Jakob Heitz To: Lucy yong , "Ali Sajassi (sajassi)" Subject: RE: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgAAGcYYwAAC8jtA= Date: Thu, 29 Nov 2012 21:01:22 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E0F99A6@eusaamb109.ericsson.se> References: <99A8A675-B3B5-4F26-8D40-EFCA70F7A8D0@ericsson.com> <69670F7146898C4583F56DA9AD32F77B0D7D03E6@xmb-aln-x13.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D44852F4C@dfweml505-mbb.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44852F4C@dfweml505-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0F99A6eusaamb109ericsso_" 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, 29 Nov 2012 21:01:37 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0F99A6eusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand what Ali said. It answered my question. Let me try in other words. Here is the sequence: 1. PE1 advertises Ether AD 2. PE1 advertises MAC1 3. PE3 adds a MAC route for MAC1 to PE1 4. PE2 advertises Ether AD 5. PE3 adds a MAC alias for MAC1 to PE2 6. PE1 loses connection to the ethernet segment. 7. PE1 withdraws Ether AD 8. PE3 removes its MAC route for MAC1 to PE1, but retains the alias to PE2 - PE3 forwards traffic for MAC1 unicast to PE2 9. PE1 withdraws MAC1 10. PE3 removes its alias for MAC1 to PE2 - PE3 floods traffic for MAC1 11. PE2 receives local traffic from MAC1 and learns it 12. PE2 advertises MAC1 13. PE3 adds a MAC route for MAC1 to PE2 - PE3 forwards traffic for MAC1 unicast to PE2 step 12 could happen before step 9. In that case, PE3 will never flood. Steps 1 to 5 could happen in a different order without changing the outcome= . -- Jakob Heitz. x25475. 510-566-2901 ________________________________ From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Thursday, November 29, 2012 12:41 PM To: Ali Sajassi (sajassi); Jakob Heitz Cc: l2vpn@ietf.org Subject: RE: EVPN: withdrawing the alias See below. From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= li Sajassi (sajassi) Sent: Thursday, November 29, 2012 1:19 PM To: Jakob Heitz Cc: l2vpn@ietf.org Subject: Re: EVPN: withdrawing the alias Let me summarize the operation as follow: 1. if the remote PE (e.g., PE3) only receives MAC1 advertisement from on= ly one of the PE in the Multi-homing group (e.g., from PE1), then upon rece= iving withdraw message for this MAC1, PE3 will flood subsequent traffic to= ward MAC1. This covers the scenario in which MAC1 ages out on PE1. [Lucy] I don't understand this action. The issue is how remote PE to differ= entiate the failure withdraw via the age out withdraw at a PE. 1. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) messag= e from PE1 first (before MAC1 route withdraw), then because of aliasing, PE= 3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In which= case, it removes MAC1 entry from its table and starts flooding traffic tow= ard MAC1. This covers link/port failure scenario. [Lucy] in second point, you mean "PE3 forwards traffic to PE2 till it recei= ves MAC1 withdraw from PE2, ...", not PE1. Lucy More comments in line ... From: Jakob Heitz > Date: Thursday, November 29, 2012 5:02 AM To: Cisco Employee > Cc: "l2vpn@ietf.org" > Subject: Re: EVPN: withdrawing the alias In case of (1), PE2 will advertise MAC1 *only* if there is traffic from MAC= 1. This is by no means assured. In that case, if PE2 does not advertise MAC= 1 before PE1 withdraws it, does PE3 consider MAC1 as unknown? Ali> yes, PE3 consider MAC1 as unknown and starts flooding traffic toward M= AC1 till it learns it from PE2. Perhaps PE1 could delay its withdrawal, or not send it at all. PE1 withdraw= s the Ethernet A-D. That could trigger an aging timer on PE3 for the alias. Ali> No need to delay the withdraw. Ether AD mass-withdraw message will cau= se PE3 to remove aliasing and thus traffic gets forwarded to PE2 for MAC1. = If MAC1 is advertised by PE2 before MAC1 is withdrawn by PE1, then there i= s no flooding; otherwise, there will be little bit of flooding till PE3 lea= rns MAC1 from PE2. Cheers, Ali I propose: If a PE has advertised an Ethernet A-D route and has advertised a MAC route= covered by that Ethernet A-D route and this PE subsequently withdraws the = Ethernet A-D route, then it shall not withdraw the MAC route. If a first PE has received an Ethernet A-D route and a MAC route covered by= that Ethernet A-D route from a second PE and has an alias for that MAC rou= te from a third PE and subsequently receives a withdrawal of the Ethernet A= -D route from the second PE, then the first PE shall immediately delete its= MAC route to the second PE and start an aging timer to delete its alias. -- Jakob Heitz. On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" > wrote: Good question! The reason that PE1 withdraws MAC1 can be: 1. there is a failure between MHD and PE1 (e.g., a link or port failure) 2. MAC1 ages out on PE1 In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency for = MAC1 to PE2. In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE2. In= this case, MAC1 is not reachable via either PE1 or PE2. I think we can elaborate this on the next rev. of the draft. Cheers, Ali From: Jakob Heitz > Date: Wednesday, November 28, 2012 2:49 PM To: "l2vpn@ietf.org" > Subject: EVPN: withdrawing the alias Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a LAG interface (ES1), and is sending packets with MAC address MAC1 on VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a Ethe= rnet A-D route per ESI for ESI1 as well as an Ethernet A-D route per EVI for . A remote PE, PE3 considers MAC1 as reachable via both PE1 and PE2. Now, suppose PE1 withdraws its advertisement of MAC1. Does PE3 still consider MAC1 as reachable via PE2? I would think not, but it's not stated in the draft. -- Jakob Heitz. x25475. 510-566-2901 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0F99A6eusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I understand what Ali sa= id. It answered my question.
Let me try in other word= s.
Here is the sequence:
 1. PE1 advertises = Ether AD
 2. PE1 advertises = MAC1
 3. PE3 adds a MAC = route for MAC1 to PE1
 4. PE2 advertises = Ether AD
 5. PE3 adds a MAC = alias for MAC1 to PE2
 6. PE1 loses conne= ction to the ethernet segment.
 7. PE1 withdraws E= ther AD
 8. PE3 removes its= MAC route for MAC1 to PE1, but retains the alias to PE2
    - PE3= forwards traffic for MAC1 unicast to PE2
 9. PE1 withdraws M= AC1
10. PE3 removes its alia= s for MAC1 to PE2
    - PE3= floods traffic for MAC1
11. PE2 receives local t= raffic from MAC1 and learns it
12. PE2 advertises MAC1<= /font>
13. PE3 adds a MAC route= for MAC1 to PE2
    - PE3= forwards traffic for MAC1 unicast to PE2
&= nbsp;
step 12 = could happen before step 9.
In that = case, PE3 will never flood.
Steps 1 = to 5 could happen in a different order without changing the outcome.=

-- Jakob Heitz. x25475. 5= 10-566-2901

 

From: Lucy yong [mailto:lucy.yong@h= uawei.com]
Sent: Thursday, November 29, 2012 12:41 PM
To: Ali Sajassi (sajassi); Jakob Heitz
Cc: l2vpn@ietf.org
Subject: RE: EVPN: withdrawing the alias

See below.

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@i= etf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Thursday, November 29, 2012 1:19 PM
To: Jakob Heitz
Cc: l2vpn@ietf.org
Subject: Re: EVPN: withdrawing the alias

 

 

Let me summarize the operation as follow:<= o:p>

 

  1. if t= he remote PE (e.g., PE3) only receives MAC1 advertisement from only one of = the PE in the Multi-homing group (e.g., from PE1), then upon receiving with= draw message for this MAC1,  PE3 will flood subsequent traffic toward MAC1. This covers the scenario in which MA= C1 ages out on PE1.

[Lucy] I don’t understand this action. The issue is h= ow remote PE to differentiate the failure withdraw via the age out withdraw= at a PE.

  1. If t= he remote PE (e.g., PE3) receives Ether AD (mass withdraw) message from PE1= first (before MAC1 route withdraw), then because of aliasing, PE3 forwards= traffic to PE2 till it receives MAC1 withdraw from PE1. In which case, it removes MAC1 entry from its table and= starts flooding traffic toward MAC1. This covers link/port failure scenari= o.

[Lucy] in second point, you mean “PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE2, …”, not PE1.

Lucy

 

More comments in line …

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thursday, November 29, 2012 5:02 AM
To: Cisco Employee <sajassi@= cisco.com>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: Re: EVPN: withdrawing the alias

 

In case of (1), PE2 will advertise MAC1 *o= nly* if there is traffic from MAC1. This is by no means assured. In that ca= se, if PE2 does not advertise MAC1 before PE1 withdraws it, does PE3 consider MAC1 as unknown?

 

Ali> yes, PE3 consider MAC1 as unknown = and starts flooding traffic toward MAC1 till it learns it from PE2.

 

Perhaps PE1 could delay its withdrawal, or= not send it at all. PE1 withdraws the Ethernet A-D. That could trigger an = aging timer on PE3 for the alias.

 

Ali> No need to delay the withdraw. Eth= er AD mass-withdraw message will cause PE3 to remove aliasing and thus traf= fic gets forwarded to PE2 for MAC1. If MAC1 is advertised by PE2 before  MAC1 is withdrawn by PE1, then ther= e is no flooding; otherwise, there will be little bit of flooding till PE3 = learns MAC1 from PE2.

 

Cheers,

Ali

 

I propose:

 

If a PE has advertised an Ethernet A-D rou= te and has advertised a MAC route covered by that Ethernet A-D route and th= is PE subsequently withdraws the Ethernet A-D route, then it shall not withdraw the MAC route.

 

If a first PE has received an Ethernet A-D route and a MAC route covered by tha= t Ethernet A-D route from a second PE and has an alias for that MAC route from a third PE and subsequently receives a wi= thdrawal of the Ethernet A-D route from the second PE, then the first = PE shall immediately delete its MAC route to the second PE and start an agi= ng timer to delete its alias.

--

Jakob Heitz.

 


On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:

 

Good question! The reason that PE1 withdra= ws MAC1 can be:

 

  1. ther= e is a failure between MHD and PE1 (e.g., a link or port failure)
  2. MAC1= ages out on PE1

In case of (1), PE2 will advertise MAC1 an= d PE3 will set its adjacency for MAC1 to PE2.

In case of (2), PE1 withdraws MAC1 but the= re is no advertisement by PE2. In this case, MAC1 is not reachable via eith= er PE1 or PE2.

 

I think we can elaborate this on the next = rev. of the draft.

 

Cheers,

Ali

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, November 28, 2012 2:49 PM
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: EVPN: withdrawing the alias

 

   Consider a CE (CE1) that is dual-hom=
ed to two PEs (PE1 and PE2) on a
 =
;  LAG interface (ES1), and is sending packets with MAC address MAC1 o=
n
 =
;  VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a=
 Ethernet A-D
 =
;  route per ESI for ESI1 as well as an Ethernet A-D route per EVI for=

 =
;  <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 as reachable
 =
;  via both PE1 and PE2.

 

Now, suppose PE1 withdraws its advertisement of M= AC1.

Does PE3 still consider MAC1 as reachable via PE2= ?

I would think not, but it's not stated in the dra= ft.

--
Jakob Heitz. x25475. 510-566-2901<= /span>

 

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0F99A6eusaamb109ericsso_-- From lucy.yong@huawei.com Thu Nov 29 13:45:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1728A21F8C6F for ; Thu, 29 Nov 2012 13:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.066, 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 eP0k9iITI59I for ; Thu, 29 Nov 2012 13:45:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFDA21F8C6A for ; Thu, 29 Nov 2012 13:45:29 -0800 (PST) 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 AMA61155; Thu, 29 Nov 2012 21:45:26 +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; Thu, 29 Nov 2012 21:45:11 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 21:45:25 +0000 Received: from DFWEML505-MBB.china.huawei.com ([169.254.1.192]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 29 Nov 2012 13:45:23 -0800 From: Lucy yong To: Jakob Heitz , "Ali Sajassi (sajassi)" Subject: RE: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgAAGcYYwAAC8jtAAAhnc0A== Date: Thu, 29 Nov 2012 21:45:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44852F76@dfweml505-mbb.china.huawei.com> References: <99A8A675-B3B5-4F26-8D40-EFCA70F7A8D0@ericsson.com> <69670F7146898C4583F56DA9AD32F77B0D7D03E6@xmb-aln-x13.cisco.com> <2691CE0099834E4A9C5044EEC662BB9D44852F4C@dfweml505-mbb.china.huawei.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E0F99A6@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E0F99A6@eusaamb109.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.90.162] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44852F76dfweml505mbbchi_" 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: Thu, 29 Nov 2012 21:45:34 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44852F76dfweml505mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jakob, Thank you for the explanation. It is clear to me know. Lucy From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] Sent: Thursday, November 29, 2012 3:01 PM To: Lucy yong; Ali Sajassi (sajassi) Cc: l2vpn@ietf.org Subject: RE: EVPN: withdrawing the alias I understand what Ali said. It answered my question. Let me try in other words. Here is the sequence: 1. PE1 advertises Ether AD 2. PE1 advertises MAC1 3. PE3 adds a MAC route for MAC1 to PE1 4. PE2 advertises Ether AD 5. PE3 adds a MAC alias for MAC1 to PE2 6. PE1 loses connection to the ethernet segment. 7. PE1 withdraws Ether AD 8. PE3 removes its MAC route for MAC1 to PE1, but retains the alias to PE2 - PE3 forwards traffic for MAC1 unicast to PE2 9. PE1 withdraws MAC1 10. PE3 removes its alias for MAC1 to PE2 - PE3 floods traffic for MAC1 11. PE2 receives local traffic from MAC1 and learns it 12. PE2 advertises MAC1 13. PE3 adds a MAC route for MAC1 to PE2 - PE3 forwards traffic for MAC1 unicast to PE2 step 12 could happen before step 9. In that case, PE3 will never flood. Steps 1 to 5 could happen in a different order without changing the outcome= . -- Jakob Heitz. x25475. 510-566-2901 ________________________________ From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Thursday, November 29, 2012 12:41 PM To: Ali Sajassi (sajassi); Jakob Heitz Cc: l2vpn@ietf.org Subject: RE: EVPN: withdrawing the alias See below. From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= li Sajassi (sajassi) Sent: Thursday, November 29, 2012 1:19 PM To: Jakob Heitz Cc: l2vpn@ietf.org Subject: Re: EVPN: withdrawing the alias Let me summarize the operation as follow: 1. if the remote PE (e.g., PE3) only receives MAC1 advertisement from on= ly one of the PE in the Multi-homing group (e.g., from PE1), then upon rece= iving withdraw message for this MAC1, PE3 will flood subsequent traffic to= ward MAC1. This covers the scenario in which MAC1 ages out on PE1. [Lucy] I don't understand this action. The issue is how remote PE to differ= entiate the failure withdraw via the age out withdraw at a PE. 1. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) messag= e from PE1 first (before MAC1 route withdraw), then because of aliasing, PE= 3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In which= case, it removes MAC1 entry from its table and starts flooding traffic tow= ard MAC1. This covers link/port failure scenario. [Lucy] in second point, you mean "PE3 forwards traffic to PE2 till it recei= ves MAC1 withdraw from PE2, ...", not PE1. Lucy More comments in line ... From: Jakob Heitz > Date: Thursday, November 29, 2012 5:02 AM To: Cisco Employee > Cc: "l2vpn@ietf.org" > Subject: Re: EVPN: withdrawing the alias In case of (1), PE2 will advertise MAC1 *only* if there is traffic from MAC= 1. This is by no means assured. In that case, if PE2 does not advertise MAC= 1 before PE1 withdraws it, does PE3 consider MAC1 as unknown? Ali> yes, PE3 consider MAC1 as unknown and starts flooding traffic toward M= AC1 till it learns it from PE2. Perhaps PE1 could delay its withdrawal, or not send it at all. PE1 withdraw= s the Ethernet A-D. That could trigger an aging timer on PE3 for the alias. Ali> No need to delay the withdraw. Ether AD mass-withdraw message will cau= se PE3 to remove aliasing and thus traffic gets forwarded to PE2 for MAC1. = If MAC1 is advertised by PE2 before MAC1 is withdrawn by PE1, then there i= s no flooding; otherwise, there will be little bit of flooding till PE3 lea= rns MAC1 from PE2. Cheers, Ali I propose: If a PE has advertised an Ethernet A-D route and has advertised a MAC route= covered by that Ethernet A-D route and this PE subsequently withdraws the = Ethernet A-D route, then it shall not withdraw the MAC route. If a first PE has received an Ethernet A-D route and a MAC route covered by= that Ethernet A-D route from a second PE and has an alias for that MAC rou= te from a third PE and subsequently receives a withdrawal of the Ethernet A= -D route from the second PE, then the first PE shall immediately delete its= MAC route to the second PE and start an aging timer to delete its alias. -- Jakob Heitz. On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" > wrote: Good question! The reason that PE1 withdraws MAC1 can be: 1. there is a failure between MHD and PE1 (e.g., a link or port failure) 2. MAC1 ages out on PE1 In case of (1), PE2 will advertise MAC1 and PE3 will set its adjacency for = MAC1 to PE2. In case of (2), PE1 withdraws MAC1 but there is no advertisement by PE2. In= this case, MAC1 is not reachable via either PE1 or PE2. I think we can elaborate this on the next rev. of the draft. Cheers, Ali From: Jakob Heitz > Date: Wednesday, November 28, 2012 2:49 PM To: "l2vpn@ietf.org" > Subject: EVPN: withdrawing the alias Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a LAG interface (ES1), and is sending packets with MAC address MAC1 on VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a Ethe= rnet A-D route per ESI for ESI1 as well as an Ethernet A-D route per EVI for . A remote PE, PE3 considers MAC1 as reachable via both PE1 and PE2. Now, suppose PE1 withdraws its advertisement of MAC1. Does PE3 still consider MAC1 as reachable via PE2? I would think not, but it's not stated in the draft. -- Jakob Heitz. x25475. 510-566-2901 --_000_2691CE0099834E4A9C5044EEC662BB9D44852F76dfweml505mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jakob,

 <= /p>

Thank you for the explana= tion. It is clear to me know.

 <= /p>

Lucy

 <= /p>

From: Jakob He= itz [mailto:jakob.heitz@ericsson.com]
Sent: Thursday, November 29, 2012 3:01 PM
To: Lucy yong; Ali Sajassi (sajassi)
Cc: l2vpn@ietf.org
Subject: RE: EVPN: withdrawing the alias

 

I understand what Ali said. It answered my= question.

Let me try in other words.

Here is the sequence:

 1. PE1 advertises Ether AD

 2. PE1 advertises MAC1

 3. PE3 adds a MAC route for MAC1 to = PE1

 4. PE2 advertises Ether AD

 5. PE3 adds a MAC alias for MAC1 to = PE2

 6. PE1 loses connection to the ether= net segment.

 7. PE1 withdraws Ether AD

 8. PE3 removes its MAC route for MAC= 1 to PE1, but retains the alias to PE2

    - PE3 forwards traffic = for MAC1 unicast to PE2

 9. PE1 withdraws MAC1

10. PE3 removes its alias for MAC1 to PE2<= /span>

    - PE3 floods traffic fo= r MAC1

11. PE2 receives local traffic from MAC1 a= nd learns it

12. PE2 advertises MAC1<= /p>

13. PE3 adds a MAC route for MAC1 to PE2

    - PE3 forwards traffic = for MAC1 unicast to PE2

 

step 12 could happen before step 9.

In that case, PE3 will never flood.

Steps 1 to 5 could happen in a different o= rder without changing the outcome.

--
Jakob Heitz. x25475. 510-566-2901

 

 

From:<= /span> Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Thursday, November 29, 2012 12:41 PM
To: Ali Sajassi (sajassi); Jakob Heitz
Cc: l2vpn@ietf.org
Subject: RE: EVPN: withdrawing the alias

See below.

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Thursday, November 29, 2012 1:19 PM
To: Jakob Heitz
Cc: l2vpn@ietf.org
Subject: Re: EVPN: withdrawing the alias

 

 

Let me summarize the operat= ion as follow:

 

  1. if the remote PE (e.g., PE3) only receives MAC1 advertisement = from only one of the PE in the Multi-homing group (e.g., from PE1), then up= on receiving withdraw message for this MAC1,  PE3 will flood subsequent traffic toward MAC1. This covers the scenario in which MA= C1 ages out on PE1.

[Lucy] I don’t understand t= his action. The issue is how remote PE to differentiate the failure withdraw via the age out withdraw at a PE.

  1. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw)= message from PE1 first (before MAC1 route withdraw), then because of alias= ing, PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In which case, it removes MAC1 entry from its table and= starts flooding traffic toward MAC1. This covers link/port failure scenari= o.

[Lucy] in second point, you mean = “PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE2, …&#= 8221;, not PE1.

Lucy

 

More comments in line ̷= 0;

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thursday, November 29, 2012 5:02 AM
To: Cisco Employee <sajassi@= cisco.com>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: Re: EVPN: withdrawing the alias

 

In case of (1), PE2 will ad= vertise MAC1 *only* if there is traffic from MAC1. This is by no means assu= red. In that case, if PE2 does not advertise MAC1 before PE1 withdraws it, does PE3 consider MAC1 as unknown?

 

Ali> yes, PE3 consider M= AC1 as unknown and starts flooding traffic toward MAC1 till it learns it fr= om PE2.

 

Perhaps PE1 could delay its= withdrawal, or not send it at all. PE1 withdraws the Ethernet A-D. That co= uld trigger an aging timer on PE3 for the alias.

 

Ali> No need to delay th= e withdraw. Ether AD mass-withdraw message will cause PE3 to remove aliasin= g and thus traffic gets forwarded to PE2 for MAC1. If MAC1 is advertised by PE2 before  MAC1 is withdrawn by PE1, then there is = no flooding; otherwise, there will be little bit of flooding till PE3 learn= s MAC1 from PE2.

 

Cheers,

Ali

 

I propose:

 

If a PE has advertised an E= thernet A-D route and has advertised a MAC route covered by that Ethernet A= -D route and this PE subsequently withdraws the Ethernet A-D route, then it shall not withdraw the MAC route.

 

If a first PE has received&= nbsp;an Ethernet A-D route and a MAC route= covered by that Ethernet A-D route from a second PE and has an alias for that MAC route from a third PE and subsequently receives a withd= rawal of the Ethernet A-D route from the second PE, then the first PE = shall immediately delete its MAC route to the second PE and start an aging = timer to delete its alias.

--

Jakob Heitz.

 


On Nov 29, 2012, at 12:21 AM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:

 

Good question! The reason t= hat PE1 withdraws MAC1 can be:

 

  1. there is a failure between MHD and PE1 (e.g., a link or port f= ailure)
  2. MAC1 ages out on PE1

In case of (1), PE2 will ad= vertise MAC1 and PE3 will set its adjacency for MAC1 to PE2.

In case of (2), PE1 withdra= ws MAC1 but there is no advertisement by PE2. In this case, MAC1 is not rea= chable via either PE1 or PE2.

 

I think we can elaborate th= is on the next rev. of the draft.

 

Cheers,

Ali

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, November 28, 2012 2:49 PM
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: EVPN: withdrawing the alias

  

   Consider a CE (CE1) that is dual-homed to tw=
o PEs (PE1 and PE2) on a
 &=
nbsp; LAG interface (ES1), and is sending packets with MAC address MAC1 on<=
o:p>
 &=
nbsp; VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE2 advertise a E=
thernet A-D
 &=
nbsp; route per ESI for ESI1 as well as an Ethernet A-D route per EVI for
 &=
nbsp; <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 as reachable
 &=
nbsp; via both PE1 and PE2.

 

Now, suppose PE1 withdraws its advertiseme= nt of MAC1.

Does PE3 still consider MAC1 as reachable = via PE2?

I would think not, but it's not stated in = the draft.

--
Jakob Heitz. x25475. 510-566-2901

 

--_000_2691CE0099834E4A9C5044EEC662BB9D44852F76dfweml505mbbchi_-- From nabil.n.bitar@verizon.com Fri Nov 30 08:02: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 372B221F8B4A for ; Fri, 30 Nov 2012 08:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 7wq68DafZl4i for ; Fri, 30 Nov 2012 08:02:05 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 49DD521F89DA for ; Fri, 30 Nov 2012 08:02:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe02.verizon.com with ESMTP; 30 Nov 2012 16:02:03 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.84,191,1355097600"; d="scan'208,217";a="376080123" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi01.verizon.com with ESMTP; 30 Nov 2012 16:02:03 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB01.us.one.verizon.com ([166.68.45.78]) with mapi; Fri, 30 Nov 2012 11:02:03 -0500 To: "l2vpn@ietf.org" Importance: high X-Priority: 1 Date: Fri, 30 Nov 2012 11:02:02 -0500 Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 - extended call Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 - extended call Thread-Index: Ac3PFAl2bpEV4FmZR4qc0BrCQcPi1A== 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: multipart/alternative; boundary="_000_CCDE1CF06BC8Fnabilnbitarverizoncom_" 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: Fri, 30 Nov 2012 16:02:06 -0000 --_000_CCDE1CF06BC8Fnabilnbitarverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The WG last call passed without any feedback. We would like the working gro= up to take another look at this because it will be hard to gage support for= a draft or move it forward without feedback. Thus, we decided to give it another try.. We are issuing or extending the = WG Last call for the draft =93Requirements for MEF E-Tree Support in L2VPN=94 which can be found at http://tools.ietf.org/html/draft= -ietf-l2vpn-etree-reqt-03 Please, review the draft and send any comments to the L2VPN working group e= mail list. Please, indicate if you support moving the draft forward. You are encouraged to send extensive comments as you see fit. The extended Working group last call will close on Friday December 7, 2012. Thanks, Nabil & Giles From: , Nabil Bitar > Date: Friday, November 2, 2012 7:43 AM To: "l2vpn@ietf.org" > Cc: Giles Heron > Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 Hi, This is the start of a two-week working group last call on the draft =93Req= uirements for MEF E-Tree Support in L2VPN=94. The draft can be found at h= ttp://tools.ietf.org/html/draft-ietf-l2vpn-etree-reqt-03 Please, review the draft and send any comments to the L2VPN working group e= mail list. You are encouraged to send extensive comments as you see fit. This WG last call will close on Friday November 16th, 2012. Regards, Giles & Nabil --_000_CCDE1CF06BC8Fnabilnbitarverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,
The WG last call = passed without any feedback. We would like the working group to take anothe= r look at this because it will be hard to gage support for a draft or move = it forward without feedback. 
Thus, we decided to give it another try.. W= e are issuing or extending the  WG Last call for the draft   =93Req= uirements for MEF E-Tree
=94 which can be found at &= nbsp;= http://tools.ietf.org/html/draft-ietf-l2vpn-etree-reqt-03

Please, review the draft and send any comments to the L2VPN wo= rking group email list.  Please, indica= te if you support moving the draft forward.
You are encouraged to send extensive comments as you see fit.

=
The extended Working group= last call will close on Friday December 7, 2012.
<= font class=3D"Apple-style-span" face=3D"Times New Roman">
Thanks,
Nabil & Giles





F= rom: <Bitar>, Nabil Bitar <nabil.n.bitar@verizon.com>
Date: Friday, November 2, 2012 7:43 AM
To: "l2vpn@= ietf.org" <l2vpn@ietf.org= >
Cc: Giles Heron <giheron@cisco.com>
Subject: [l2vpn] WG last call for draft-ietf-l2v= pn-etree-reqt-03


[l2vpn= ]  WG last call for draft-ietf-l2vpn-vpls-macflush-ld-01
<= font face=3D"Times New Roman">Hi,
Thi= s is the start of a two-week working group last call on the draft =93Requirements for MEF E-Tree Support in L2VPN=94.  The draft can b= e found at  http://tools.ietf.org/html/draft-ietf-l2vpn-etree-reqt-03

Please, review the draft and send any comments to the L2VPN working group e= mail list. You are encouraged to send extensive comments as you see fit.
This WG last call will close on Friday November 16th, 2012.
 
Regards,
Giles & Nabil


--_000_CCDE1CF06BC8Fnabilnbitarverizoncom_-- From lucy.yong@huawei.com Fri Nov 30 12:56: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 C297A21F8488 for ; Fri, 30 Nov 2012 12:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ws3PeHvuJBGq for ; Fri, 30 Nov 2012 12:56:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D321F8D47 for ; Fri, 30 Nov 2012 12:56:20 -0800 (PST) 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 ANJ29966; Fri, 30 Nov 2012 20:56:18 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Nov 2012 20:55:59 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Nov 2012 20:56:15 +0000 Received: from DFWEML505-MBB.china.huawei.com ([169.254.1.192]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 30 Nov 2012 12:56:10 -0800 From: Lucy yong To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: RE: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 - extended call Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 - extended call Thread-Index: Ac3PFAl2bpEV4FmZR4qc0BrCQcPi1AAKICpw Date: Fri, 30 Nov 2012 20:56:09 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44853412@dfweml505-mbb.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.85.255] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44853412dfweml505mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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: Fri, 30 Nov 2012 20:56:23 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44853412dfweml505mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nabil, It is my understanding that IETF process for a last call do not require an= explicit support in the e-mail, individuals only need to voice up if he/sh= e has a comment on the draft. Thus if there is no any feedback on it, it me= ans everyone support without any comment. Is that right? Thanks, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= itar, Nabil N Sent: Friday, November 30, 2012 10:02 AM To: l2vpn@ietf.org Cc: Giles Heron Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 - extended= call Importance: High Hi, The WG last call passed without any feedback. We would like the working gro= up to take another look at this because it will be hard to gage support for= a draft or move it forward without feedback. Thus, we decided to give it another try.. We are issuing or extending the = WG Last call for the draft "Requirements for MEF E-Tree Support in L2VPN" which can be found at http://tools.ietf.org/html/draft-i= etf-l2vpn-etree-reqt-03 Please, review the draft and send any comments to the L2VPN working group e= mail list. Please, indicate if you support moving the draft forward. You are encouraged to send extensive comments as you see fit. The extended Working group last call will close on Friday December 7, 2012. Thanks, Nabil & Giles From: , Nabil Bitar > Date: Friday, November 2, 2012 7:43 AM To: "l2vpn@ietf.org" > Cc: Giles Heron > Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 Hi, This is the start of a two-week working group last call on the draft "Requi= rements for MEF E-Tree Support in L2VPN". The draft can be found at http://tools.ietf.org/html/d= raft-ietf-l2vpn-etree-reqt-03 Please, review the draft and send any comments to the L2VPN working group e= mail list. You are encouraged to send extensive comments as you see fit. This WG last call will close on Friday November 16th, 2012. Regards, Giles & Nabil --_000_2691CE0099834E4A9C5044EEC662BB9D44853412dfweml505mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [l2vpn]  WG last call for draft-ietf-l2vpn-vpls-macflush-ld-01<= /title> <style><!-- /* Font Definitions */ @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.apple-style-span {mso-style-name:apple-style-span;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"word-wrap: bre= ak-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Hi Nabil,<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">It is my understanding &n= bsp;that IETF process for a last call do not require an explicit support in= the e-mail, individuals only need to voice up if he/she has a comment on the draft. Thus if there is no any feedback on it, it means e= veryone support without any comment.  Is that right?  <o:p></o:p>= </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Thanks,<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Lucy<o:p></o:p></span></p= > <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] <b>On Behalf Of </b>Bitar, Nabil N<br> <b>Sent:</b> Friday, November 30, 2012 10:02 AM<br> <b>To:</b> l2vpn@ietf.org<br> <b>Cc:</b> Giles Heron<br> <b>Subject:</b> [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 - e= xtended call<br> <b>Importance:</b> High<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif";color:black">Hi,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif";color:black">The WG last call passed wit= hout any feedback. We would like the working group to take another look at = this because it will be hard to gage support for a draft or move it forward without feedback. <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif";color:black">Thus, we decided to give it= another try.. We are issuing or extending the  WG Last call for the d= raft  </span><span style=3D"font-family:"Calibri","sans= -serif";color:black"> </span><span class=3D"apple-style-span"><sp= an style=3D"color:black">“Requirements for MEF E-Tree</span></span><span style=3D"font-size:10.5pt;font-family:&q= uot;Calibri","sans-serif";color:black"><o:p></o:p></span></p= > </div> <p class=3D"MsoNormal"><span class=3D"apple-style-span"><span style=3D"font= -family:"Calibri","sans-serif";color:black">Support in = L2VPN” which</span></span><span class=3D"apple-style-span"><span styl= e=3D"color:black"> can be found at  <a href=3D"http://tools.ietf.= org/html/draft-ietf-l2vpn-etree-reqt-03">http://tools.ietf.org/html/draft-i= etf-l2vpn-etree-reqt-03</a></span></span><span style=3D"color:black"><o:p><= /o:p></span></p> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span class=3D"apple-style-span"><span style=3D"colo= r:black">Please, review the draft and send any comments to the L2VPN workin= g group email list.  Please, indicate if you support moving the d= raft forward.</span></span><span style=3D"color:black"><o:p></o:p></span></= p> </div> <div> <p class=3D"MsoNormal"><span class=3D"apple-style-span"><span style=3D"colo= r:black">You are encouraged to send extensive comments as you see fit.</spa= n></span><span style=3D"color:black"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span class=3D"apple-style-span"><span style=3D"colo= r:black">The extended Working group last call will close on Friday December= 7, 2012.</span></span><span style=3D"color:black"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span class=3D"apple-style-span"><span style=3D"colo= r:black">Thanks,</span></span><span style=3D"color:black"><o:p></o:p></span= ></p> </div> <div> <p class=3D"MsoNormal"><span class=3D"apple-style-span"><span style=3D"colo= r:black">Nabil & Giles</span></span><span style=3D"color:black"><o:p></= o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <div> <p class=3D"MsoNormal"><span style=3D"color:black"><o:p> </o:p></span>= </p> </div> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif";color:black"><o:p> </o:p></span></p= > </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif";color:black"><o:p> </o:p></span></p= > </div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri","sans-serif";color:black">From: </span></b><span style=3D"font-size:11.0pt;font-family:"Calibri",= "sans-serif";color:black"><Bitar>, Nabil Bitar <<a href= =3D"mailto:nabil.n.bitar@verizon.com">nabil.n.bitar@verizon.com</a>><br> <b>Date: </b>Friday, November 2, 2012 7:43 AM<br> <b>To: </b>"<a href=3D"mailto:l2vpn@ietf.org">l2vpn@ietf.org</a>"= <<a href=3D"mailto:l2vpn@ietf.org">l2vpn@ietf.org</a>><br> <b>Cc: </b>Giles Heron <<a href=3D"mailto:giheron@cisco.com">giheron@cis= co.com</a>><br> <b>Subject: </b>[l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03<o:p= ></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif";color:black"><o:p> </o:p></span></p= > </div> <div> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri","sans-serif";color:black"><o:p> </o:p></span></p= > </div> <div> <div> <p class=3D"MsoNormal" style=3D"mso-line-height-alt:0pt"><span style=3D"fon= t-family:"Calibri","sans-serif";color:black">Hi,</span>= <span style=3D"font-size:10.5pt;color:black"><br> </span><span style=3D"font-family:"Calibri","sans-serif"= ;;color:black">This is the start of a two-week working group last call on t= he draft </span><span class=3D"apple-style-span"><span style=3D"color:black">“= Requirements for MEF E-Tree<o:p></o:p></span></span></p> <p class=3D"MsoNormal"><span class=3D"apple-style-span"><span style=3D"colo= r:black">Support in L2VPN</span></span><span style=3D"color:black">”<= span class=3D"apple-style-span">.  The draft can be found at  <a = href=3D"http://tools.ietf.org/html/draft-ietf-l2vpn-etree-reqt-03">http://t= ools.ietf.org/html/draft-ietf-l2vpn-etree-reqt-03</a></span></span><span st= yle=3D"font-size:10.5pt;font-family:"Calibri","sans-serif&qu= ot;;color:black"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"color:= black"><br> Please, review the draft and send any comments to the L2VPN working group e= mail list. You are encouraged to send extensive comments as you see fit.<br= > <br> This WG last call will close on Friday November 16th, 2012.<br>  <br> Regards,<br> Giles & Nabil<br> <br> </span><span style=3D"font-size:10.5pt;font-family:"Calibri",&quo= t;sans-serif";color:black"><o:p></o:p></span></p> </div> </div> </div> </div> </div> </div> </div> </div> </body> </html> --_000_2691CE0099834E4A9C5044EEC662BB9D44853412dfweml505mbbchi_--