From jakob.heitz@ericsson.com Sat Dec 1 22:42: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 52A4121F8EB0 for ; Sat, 1 Dec 2012 22:42:08 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWTDgLn8tz-R for ; Sat, 1 Dec 2012 22:42:07 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3941821F8EA3 for ; Sat, 1 Dec 2012 22:42:07 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qB26oqLw012845 for ; Sun, 2 Dec 2012 00:50:53 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 2 Dec 2012 01:41:53 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Sun, 2 Dec 2012 01:41:53 -0500 From: Jakob Heitz To: "l2vpn@ietf.org" Subject: EVPN: ES-Import and RT-Constrain Thread-Topic: EVPN: ES-Import and RT-Constrain Thread-Index: Ac3QWBxfPX23/85PSUahfduODR5PRw== Date: Sun, 2 Dec 2012 06:41:52 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E0FE32A@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.134] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0FE32Aeusaamb109ericsso_" 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: Sun, 02 Dec 2012 06:42:08 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0FE32Aeusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just like a route-target, the ES-Import Extended Community is used to filter the routes that contain them. As such, they should be able to take advantage of RT-Constrain (rfc4684). The RT-Constrain NLRI needs no modification. All that is needed is for an RT-Constrain implementation to add the ES-Import as a filter criteria. A sentence in the EVPN draft as follows should ensure that: A BGP speaker that includes both the (AFI, SAFI) of RT-Constrain (rfc4684) as well as of EVPN in the capabilitiy advertisement MUST apply the RT-Constrain procedures to any ES-import extended community it receives in the RT-Constrain Route Target Membership NLRI. -- Jakob Heitz. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0FE32Aeusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just like a route-target, the ES-Import Extended Co= mmunity is used
to filter the routes that contain them. As such, th= ey should be
able to take advantage of RT-Constrain (rfc4684).
 
The RT-Constrain NLRI needs no modification. All&nb= sp;that is needed
is for an RT-Constrain implementation to add the ES= -Import
as a filter criteria. A sentence in the EVPN draft = as follows
should ensure that:
&nbs= p;
A BGP speaker that includes both the (AFI, SAFI) of= RT-Constrain (rfc4684)
as well as of EVPN in the capabilitiy advertis= ement MUST apply
the RT-Constrain procedures to any ES-import extend= ed community
it receives in the RT-Constrain Route Target Member= ship NLRI.
 
--
Jakob Heitz.
 
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E0FE32Aeusaamb109ericsso_-- From y.kamite@ntt.com Mon Dec 3 17:22: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 E426021F892A for ; Mon, 3 Dec 2012 17:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 R68aIxsP8w8F for ; Mon, 3 Dec 2012 17:22:14 -0800 (PST) Received: from mgw020.noc.ntt.com (mgw020.noc.ntt.com [210.160.55.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1382921F8928 for ; Mon, 3 Dec 2012 17:22:14 -0800 (PST) Received: from c0044i0.coe.ntt.com (unknown [10.18.161.13]) by mgw020.noc.ntt.com (NTT Com MailSV) with ESMTP id 1D2564460155; Tue, 4 Dec 2012 10:22:13 +0900 (JST) Received: from C0038I0.coe.ntt.com (10.18.160.42) by c0044i0.coe.ntt.com (10.18.161.13) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Dec 2012 10:22:11 +0900 Received: from C0007I0.coe.ntt.com ([169.254.1.46]) by C0038I0.coe.ntt.com ([10.18.160.42]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 10:22:12 +0900 From: Yuji Kamite 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: Ac3NsmSdDw+mFXOvSQyN+l64ChdrBgECvbCg Date: Tue, 4 Dec 2012 01:22:12 +0000 Message-ID: <1A095D7ECD89A64C9D3C77AE2DDE660B57DE6CDD@C0007I0.coe.ntt.com> References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: nabil.n.bitar@verizon.com, l2vpn@ietf.org x-ccmail-original-cc: giheron@cisco.com x-originating-ip: [10.50.137.96] Content-Type: multipart/alternative; boundary="_000_1A095D7ECD89A64C9D3C77AE2DDE660B57DE6CDDC0007I0coenttco_" 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: Tue, 04 Dec 2012 01:22:17 -0000 --_000_1A095D7ECD89A64C9D3C77AE2DDE660B57DE6CDDC0007I0coenttco_ Content-Type: text/plain; charset="iso-2022-jp" I'm not aware of any other IPRs. Regrads, Yuji From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N Sent: Thursday, November 29, 2012 6:50 AM To: l2vpn@ietf.org Cc: Giles Heron 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-vpls-mcast-12.txt, multicast in VPLS, in order to ensure 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 or contributor, please respond to this email whether or not you are aware of any relevant IPR that has not been properly disclosed. The draft will 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 or contributor, 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 can 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_1A095D7ECD89A64C9D3C77AE2DDE660B57DE6CDDC0007I0coenttco_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1T IEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwg ZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6Ilw2NkY4XDVGMEZcMzA2QVwzMDU3IFwoXDY1ODdcNUI1N1wpIjsNCgltYXJnaW46MG1tOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJNUyBHb3RoaWMiO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLmENCgl7bXNvLXN0eWxlLW5hbWU6Ilw2NkY4XDVGMEZcMzA2QVwzMDU3IFwoXDY1ODdc NUI1N1wpIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6XDY2Rjhc NUYwRlwzMDZBXDMwNTc7DQoJZm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjk5LjI1 cHQgMzAuMG1tIDMwLjBtbSAzMC4wbW07fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiI+DQo8djp0ZXh0Ym94IGluc2V0PSI1 Ljg1cHQsLjdwdCw1Ljg1cHQsLjdwdCIgLz4NCjwvbzpzaGFwZWRlZmF1bHRzPjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJKQSIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSdt IG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBScy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWdyYWRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPll1amk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGwydnBuLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5CaXRhciwgTmFiaWwgTjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92 ZW1iZXIgMjksIDIwMTIgNjo1MCBBTTxicj4NCjxiPlRvOjwvYj4gbDJ2cG5AaWV0Zi5vcmc8YnI+ DQo8Yj5DYzo8L2I+IEdpbGVzIEhlcm9uPGJyPg0KPGI+U3ViamVjdDo8L2I+IFBvbGxpbmcgZm9y IElQUiBvbiB0aGUgVlBMUyBtdWx0aWNhc3QgZHJhZnQgZHJhZnQtaWV0Zi1sMnZwbi12cGxzLW1j YXN0LTEyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNw YW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkhpLDwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldlIGFy ZSBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0Jm5ic3A7YXBwbGllcyB0byBk cmFmdC1pZXRmLWwydnBuLXZwbHMtbWNhc3QtMTIudHh0LCBtdWx0aWNhc3QgaW4gVlBMUywgaW4N CiBvcmRlciB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluJm5ic3A7Y29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFu ZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0 aG9yJm5ic3A7b3IgY29udHJpYnV0b3IsICZuYnNwO3BsZWFzZSByZXNwb25kJm5ic3A7dG8gdGhp cyBlbWFpbCB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlDQogb2YgYW55IHJlbGV2YW50IElQ UiB0aGF0IGhhcyBub3QgYmVlbiBwcm9wZXJseSBkaXNjbG9zZWQuIFRoZSZuYnNwO2RyYWZ0IHdp bGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9t IGVhY2gmbmJzcDthdXRob3IgYW5kIGNvbnRyaWJ1dG9yLjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIHlvdSBhcmUgb24gdGhlIGwydnBuIFdHIGVtYWlsIGxp c3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciZuYnNwO29yIGNvbnRyaWJ1dG9yLCB0 aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlJm5ic3A7 b2YgYW55DQogSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFu Y2Ugd2l0aCBJRVRGJm5ic3A7cnVsZXMuJm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1z dHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5UaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sMnZwbi12cGxzLW1jYXN0LTEyIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWwydnBuLXZwbHMtbWNhc3QtMTI8L2E+PC9z cGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1z dHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5UaGlzIHBvbGwgY2xvc2VzIG9uIE1vbmRheSBEZWNlbWJlciAzLCAyMDEyLjwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5OYWJpbCAmYW1wOyBHaWxlczwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_1A095D7ECD89A64C9D3C77AE2DDE660B57DE6CDDC0007I0coenttco_-- From raymond.key@hotmail.com Tue Dec 4 05:29: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 51E6F21F866F for ; Tue, 4 Dec 2012 05:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 ZgCOmRuNt7jg for ; Tue, 4 Dec 2012 05:29:05 -0800 (PST) Received: from snt0-omc3-s10.snt0.hotmail.com (snt0-omc3-s10.snt0.hotmail.com [65.55.90.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7F27421F863F for ; Tue, 4 Dec 2012 05:29:05 -0800 (PST) Received: from SNT123-W19 ([65.55.90.137]) by snt0-omc3-s10.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 05:29:03 -0800 X-Originating-IP: [113.87.133.45] X-EIP: [pZpocuYTwVOSpVUGX18rbb89FYOy5SOw] X-Originating-Email: [raymond.key@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_16de1ec5-dd8a-4425-91db-06d98c458497_" From: Raymond Key Sender: To: , Subject: RE: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 - extended call Date: Wed, 5 Dec 2012 00:29:01 +1100 Importance: High In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 04 Dec 2012 13:29:03.0898 (UTC) FILETIME=[5405FFA0:01CDD223] Cc: giheron@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, 04 Dec 2012 13:29:06 -0000 --_16de1ec5-dd8a-4425-91db-06d98c458497_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi L2VPN WG I support moving the draft forward. I am author of the draft. = In the WG adoption polling last year (29 Sep 2011 - 13 Oct 2011)=2C there w= ere sixteen responses on the mailing list and all are Yes. Three of the si= xteen responses were from authors. As far as I can remember=2C there have b= een no significant changes after the draft was adopted.00 --> 01: Add secti= on 5.4 "External Network Network Interface"=2C following MEF published MEF = 26.101 --> 02: Refer to "L2VPN" instead of "VPLS"=2C in response to WG Chai= rs' comment02 --> 03: Refer to "Multipoint L2VPN" instead of "L2VPN"=2C in = response to Ali's comment Thanks=2CRaymond Key From: nabil.n.bitar@verizon.= com To: l2vpn@ietf.org Date: Fri=2C 30 Nov 2012 11:02:02 -0500 Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 - extende= d call CC: giheron@cisco.com Hi=2CThe WG last call passed without any feedback. We would like the workin= g group to take another look at this because it will be hard to gage suppor= t for a draft or move it forward without feedback. Thus=2C we decided to gi= ve it another try.. We are issuing or extending the WG Last call for the d= raft =93Requirements for MEF E-Tree Support in L2VPN=94 which can be foun= d at http://tools.ietf.org/html/draft-ietf-l2vpn-etree-reqt-03 Please=2C review the draft and send any comments to the L2VPN working group= email list. Please=2C indicate if you support moving the draft forward.Yo= u are encouraged to send extensive comments as you see fit. The extended Working group last call will close on Friday December 7=2C 201= 2. Thanks=2CNabil & Giles From: =2C Nabil Bitar Date: Friday=2C November 2=2C 2012 7:43 AM To: "l2vpn@ietf.org" Cc: Giles Heron Subject: [l2vpn] WG last call for draft-ietf-l2vpn-etree-reqt-03 [l2vpn] WG last call for draft-ietf-l2vpn-vpls-macflush-ld-01Hi=2C 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/htm= l/draft-ietf-l2vpn-etree-reqt-03 Please=2C review the draft and send any comments to the L2VPN working group= email list. You are encouraged to send extensive comments as you see fit. This WG last call will close on Friday November 16th=2C 2012. =20 Regards=2C Giles & Nabil = --_16de1ec5-dd8a-4425-91db-06d98c458497_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi L2VPN WG
 =3B
I support moving the draft forward. =3B I am=  =3Bauthor of the draft.
 =3B
In =3Bthe WG =3Badoptio= n polling =3Blast year (29 Sep 2011 - 13 Oct 2011)=2C there were sixtee= n responses on the mailing list and all are =3BYes. =3B =3BThre= e of the sixteen responses =3Bwere from =3Bauthors.
 =3B
= As far as I can remember=2C =3Bthere have been no significant changes a= fter the draft was adopted.
00 -->=3B 01: Add section 5.4 "External Ne= twork Network Interface"=2C following MEF published MEF 26.1
01 -->=3B= 02: Refer to "L2VPN" instead of "VPLS"=2C in response to WG Chairs' commen= t
02 -->=3B 03: Refer to "Multipoint L2VPN" instead of "L2VPN"=2C in r= esponse to Ali's comment
 =3B
Thanks=2C
Raymond Key
 = =3B
F= rom: nabil.n.bitar@verizon.com
To: l2vpn@ietf.org
Date: Fri=2C 30 Nov= 2012 11:02:02 -0500
Subject: [l2vpn] WG last call for draft-ietf-l2vpn= -etree-reqt-03 - extended call
CC: giheron@cisco.com

Hi= =2C
The WG last call passed without any feedback. We would like the worki= ng group to take another look at this because it will be hard to gage suppo= rt for a draft or move it forward without feedback. =3B
Thus=2C we de= cided to give it another try.. We are issuing or extending the  =3BWG L= ast call for the draft  =3B =3B=93Requirements for M= EF E-Tree
= Support in L2VPN=94 which =3Bcan be= found at  =3Bhttp://tools.ietf.org/html/draft-ietf-l2vpn-= etree-reqt-03

Please=2C review = the draft and send any comments to the L2VPN working group email list. = =3B =3BPlease=2C indicate if you suppor= t moving the draft forward.
You ar= e encouraged to send extensive comments as you see fit.

The extended Working = group last call will close on Friday December 7=2C 2012.

=
Thanks=2C
Nab= il &=3B Giles


<= /font>


From: = <=3BBitar>=3B=2C Nabil Bitar <=3Bnabil.n.bitar@verizon.com>=3B
Date: Friday=2C November 2=2C 2012 7:43 AM
To: "l2= vpn@ietf.org" <=3Bl2vpn@ietf.org>=3B
Cc: Giles Heron <= =3Bgiheron@cisco.com>=3B
Subject: [l2vpn] WG last call for= draft-ietf-l2vpn-etree-reqt-03


[l2vpn]  =3BWG last call for draft-ie= tf-l2vpn-vpls-macflush-ld-01
Hi=2C
This is the start of= a two-week working group last call on the draft =93= Requirements for MEF E-Tree Support in L2VPN=94.  =3BThe dra= ft can be found at  =3Bhttp://tools.ietf.org/html/draft-ie= tf-l2vpn-etree-reqt-03
<= font face=3D"Times New Roman">
Please=2C review the draft and send any comments to the L2VPN working group= email list. You are encouraged to send extensive comments as you see fit.<= br>
This WG last call will close on Friday November 16th=2C 2012.
 =3B
Regards=2C
Giles &=3B Nabil


= --_16de1ec5-dd8a-4425-91db-06d98c458497_-- From jakob.heitz@ericsson.com Tue Dec 4 20:38:31 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085EC21F8C0A for ; Tue, 4 Dec 2012 20:38:31 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnFmFo-lKkba for ; Tue, 4 Dec 2012 20:38:30 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 752C321F8BFE for ; Tue, 4 Dec 2012 20:38:30 -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 qB54cT8V026919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Dec 2012 22:38:29 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 4 Dec 2012 23:38:28 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 23:38:28 -0500 From: Jakob Heitz To: "l2vpn@ietf.org" Subject: RE: EVPN: ES-Import and RT-Constrain Thread-Topic: EVPN: ES-Import and RT-Constrain Thread-Index: Ac3QWBxfPX23/85PSUahfduODR5PRwCSguQQ Date: Wed, 5 Dec 2012 04:38:28 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E105749@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_2F3EBB88EC3A454AAB08915FBF0B8C7E105749eusaamb109ericsso_" 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, 05 Dec 2012 04:38:31 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E105749eusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is this wrong or a good idea? Is there a better way for ES-Import to take advantage of RT-Constrain? Should this be a question to IDR? -- Jakob Heitz. ________________________________ From: Jakob Heitz Sent: Saturday, December 01, 2012 10:42 PM To: l2vpn@ietf.org Subject: EVPN: ES-Import and RT-Constrain Just like a route-target, the ES-Import Extended Community is used to filter the routes that contain them. As such, they should be able to take advantage of RT-Constrain (rfc4684). The RT-Constrain NLRI needs no modification. All that is needed is for an RT-Constrain implementation to add the ES-Import as a filter criteria. A sentence in the EVPN draft as follows should ensure that: A BGP speaker that includes both the (AFI, SAFI) of RT-Constrain (rfc4684) as well as of EVPN in the capabilitiy advertisement MUST apply the RT-Constrain procedures to any ES-import extended community it receives in the RT-Constrain Route Target Membership NLRI. -- Jakob Heitz. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E105749eusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Is this wrong or a good = idea?
Is there a better way fo= r ES-Import to take advantage of RT-Constrain?
Should this be a questio= n to IDR?

-- Jakob Heitz.

 

From: Jakob Heitz
Sent: Saturday, December 01, 2012 10:42 PM
To: l2vpn@ietf.org
Subject: EVPN: ES-Import and RT-Constrain

Just like a route-target, the ES-Import Extended Co= mmunity is used
to filter the routes that contain them. As such, th= ey should be
able to take advantage of RT-Constrain (rfc4684).
 
The RT-Constrain NLRI needs no modification. All&nb= sp;that is needed
is for an RT-Constrain implementation to add the ES= -Import
as a filter criteria. A sentence in the EVPN draft = as follows
should ensure that:
&nbs= p;
A BGP speaker that includes both the (AFI, SAFI) of= RT-Constrain (rfc4684)
as well as of EVPN in the capabilitiy advertis= ement MUST apply
the RT-Constrain procedures to any ES-import extend= ed community
it receives in the RT-Constrain Route Target Member= ship NLRI.
 
--
Jakob Heitz.
 
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E105749eusaamb109ericsso_-- From jie.dong@huawei.com Wed Dec 5 19:36: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 8E2A821F8965 for ; Wed, 5 Dec 2012 19:36:34 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZh5a5pc5dIK for ; Wed, 5 Dec 2012 19:36:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9746721F8826 for ; Wed, 5 Dec 2012 19:36:30 -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 ANN46037; Thu, 06 Dec 2012 03:36:28 +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, 6 Dec 2012 03:35:54 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 03:36:25 +0000 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.99]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 11:36:21 +0800 From: Jie Dong To: "Ali Sajassi (sajassi)" , Jakob Heitz Subject: RE: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgAFCLWLg Date: Thu, 6 Dec 2012 03:36:20 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927326E75DF@szxeml504-mbx.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: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.164] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927326E75DFszxeml504mbxchi_" 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, 06 Dec 2012 03:36:34 -0000 --_000_76CD132C3ADEF848BD84D028D243C927326E75DFszxeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ali, Jakob, Here is one comment about scenario 2: 2. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) mes= sage from PE1 first (before MAC1 route withdraw), then because of aliasing,= PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In wh= ich case, it removes MAC1 entry from its table and starts flooding traffic = toward MAC1. This covers link/port failure scenario. When PE2 receives the traffic to MAC1 before it advertises the MAC1 route, = will it treat the traffic as unknown unicast? If so, since PE2 may not beco= me the DF for the segment, it can not flood the traffic to the segment and = the traffic will get dropped. Is this understanding correct? Regards, Jie From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= li Sajassi (sajassi) Sent: Friday, November 30, 2012 3:19 AM 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. 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 ... 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_76CD132C3ADEF848BD84D028D243C927326E75DFszxeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ali, Ja= kob,

 = ;

Here is on= e comment about scenario 2:

2.=        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 wh= ich case, it removes MAC1 entry from its table and starts flooding traffic = toward MAC1. This covers link/port failure scenario.

When PE2 r= eceives the traffic to MAC1 before it advertises the MAC1 route, will it tr= eat the traffic as unknown unicast? If so, since PE2 may not become the DF for the segment, it can not flood the traffic to the segment= and the traffic will get dropped. Is this understanding correct?

 = ;

Regards,

Jie

 = ;

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Ali Sajassi (sajassi)
Sent: Friday, November 30, 2012 3:19 AM
To: Jakob Heitz
Cc: l2vpn@ietf.org
Subject: Re: EVPN: withdrawing the alias

 

 <= /o:p>

Let me summa= rize the operation as follow:

 <= /o:p>

  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., fro= m PE1), then upon receiving withdraw message for this MAC1,  PE3 will flood subsequent traffic toward MAC1. This covers the scena= rio in which MAC1 ages out on PE1.
  2. If the remote PE (e.g., PE3) receives Ether AD = (mass withdraw) message from PE1 first (before MAC1 route withdraw), then b= ecause 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 f= ailure scenario.

 <= /o:p>

More comment= s in line …

 <= /o:p>

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

 <= /o:p>

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

 <= /o:p>

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

 <= /o:p>

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

 <= /o:p>

Ali> No n= eed to delay the withdraw. Ether AD mass-withdraw message will cause 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 t= here is no flooding; otherwise, there will be little bit of flooding till P= E3 learns MAC1 from PE2.

 <= /o:p>

Cheers,=

Ali

 <= /o:p>

I propose:

 <= /o:p>

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.

 <= /o:p>

If a first P= E 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 subsequently re= ceives 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 s= tart an aging timer to delete its alias.

--

Jakob Heitz.=

 <= /o:p>


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

 <= /o:p>

Good questio= n! The reason that PE1 withdraws MAC1 can be:

 <= /o:p>

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

    3. 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.

     <= /o:p>

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

     <= /o:p>

    Cheers,=

    Ali

     <= /o:p>

    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

     <= /o:p>

       Consider a CE (CE1) that is d=
ual-homed to two PEs (PE1 and PE2) on a
       LAG interface (ES1), and is sending packets with MAC a=
ddress MAC1 on
       VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE=
2 advertise a Ethernet A-D
       route per ESI for ESI1 as well as an Ethernet A-D rout=
e per EVI for
       <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 a=
s reachable
       via both PE1 and PE2.

     <= /o:p>

    Now, suppose PE1 withdraws = its advertisement of MAC1.

    Does PE3 still consider MAC= 1 as reachable via PE2?=

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

    --
    Jakob Heitz. x25475. 510-566-2= 901

     <= /o:p>

--_000_76CD132C3ADEF848BD84D028D243C927326E75DFszxeml504mbxchi_-- From jakob.heitz@ericsson.com Wed Dec 5 19:50:04 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 EB64C21F8CF8 for ; Wed, 5 Dec 2012 19:50:04 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBlVigQUyIhK for ; Wed, 5 Dec 2012 19:50:01 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8658321F8C97 for ; Wed, 5 Dec 2012 19:50:01 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qB63xPD5026885; Wed, 5 Dec 2012 21:59:27 -0600 Received: from EUSAAHC004.ericsson.se (147.117.188.84) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 22:49:57 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 22:49:57 -0500 From: Jakob Heitz To: Jie Dong , "Ali Sajassi (sajassi)" Subject: RE: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgAFCLWLgAAE0RpA= Date: Thu, 6 Dec 2012 03:49:55 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E107B6B@eusaamb109.ericsson.se> References: <99A8A675-B3B5-4F26-8D40-EFCA70F7A8D0@ericsson.com> <69670F7146898C4583F56DA9AD32F77B0D7D03E6@xmb-aln-x13.cisco.com> <76CD132C3ADEF848BD84D028D243C927326E75DF@szxeml504-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927326E75DF@szxeml504-mbx.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_2F3EBB88EC3A454AAB08915FBF0B8C7E107B6Beusaamb109ericsso_" 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, 06 Dec 2012 03:50:05 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E107B6Beusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand the same. Hopefully, PE2 would also receive the the withdrawal of the Ethernet Segmen= t route from PE1 in a timely manner and recalculate the DF. -- Jakob Heitz. ________________________________ From: Jie Dong [mailto:jie.dong@huawei.com] Sent: Wednesday, December 05, 2012 7:36 PM To: Ali Sajassi (sajassi); Jakob Heitz Cc: l2vpn@ietf.org Subject: RE: EVPN: withdrawing the alias Hi Ali, Jakob, Here is one comment about scenario 2: 2. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) mes= sage from PE1 first (before MAC1 route withdraw), then because of aliasing,= PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In wh= ich case, it removes MAC1 entry from its table and starts flooding traffic = toward MAC1. This covers link/port failure scenario. When PE2 receives the traffic to MAC1 before it advertises the MAC1 route, = will it treat the traffic as unknown unicast? If so, since PE2 may not beco= me the DF for the segment, it can not flood the traffic to the segment and = the traffic will get dropped. Is this understanding correct? Regards, Jie From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= li Sajassi (sajassi) Sent: Friday, November 30, 2012 3:19 AM 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. 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 ... 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_2F3EBB88EC3A454AAB08915FBF0B8C7E107B6Beusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I understand the same.
Hopefully, PE2 would als= o receive the the withdrawal of the Ethernet Segment route
from PE1 in a timely manner and recal= culate the DF.
 
--
Jakob Heitz.

From: Jie Dong [mailto:jie.dong@hua= wei.com]
Sent: Wednesday, December 05, 2012 7:36 PM
To: Ali Sajassi (sajassi); Jakob Heitz
Cc: l2vpn@ietf.org
Subject: RE: EVPN: withdrawing the alias

Hi Ali, Jakob,=

 <= /p>

Here is one comment about= scenario 2:

2.    &= nbsp;  If the 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 floodin= g traffic toward MAC1. This covers link/port failure scenario.

When PE2 receives the tra= ffic to MAC1 before it advertises the MAC1 route, will it treat the traffic= as unknown unicast? If so, since PE2 may not become the DF for the segment, it can not flood the traffic to the= segment and the traffic will get dropped. Is this understanding correct?

 <= /p>

Regards,

Jie

 <= /p>

From: l2vpn-bounces@ie= tf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Friday, November 30, 2012 3:19 AM
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 fr= om only one of the PE in the Multi-homing group (e.g., from PE1), then upon= receiving 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) receives Ether AD (mass withdraw) m= essage from PE1 first (before MAC1 route withdraw), then because of aliasin= g, PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In which case, it removes MAC1 entry f= rom its table and starts flooding traffic toward MAC1. This covers link/por= t failure scenario.

 

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 P= E1, then there is no flooding; otherwise, there will be little bit of flood= ing till PE3 learns 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 re= ceives 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 s= tart an aging timer to delete its alias.

--

Jakob Heitz.

 

 

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 fai= lure)
  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) t=
hat 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 ro=
ute per EVI for
   <ESI1, VLAN1>. A remote PE, PE3 considers MAC1=
 as reachable
   via both PE1 and PE2.

 

Now, suppose PE1 withdraws its adv= ertisement of MAC1.

Does PE3 still consider MAC1 as re= achable via PE2?

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

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

 

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E107B6Beusaamb109ericsso_-- From jie.dong@huawei.com Wed Dec 5 22:42: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 878DB21F8BC8 for ; Wed, 5 Dec 2012 22:42:54 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUqRptlXlHht for ; Wed, 5 Dec 2012 22:42:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE69121F8BC4 for ; Wed, 5 Dec 2012 22:42:52 -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 ANN57411; Thu, 06 Dec 2012 06:42:51 +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; Thu, 6 Dec 2012 06:42:14 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 06:42:46 +0000 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.99]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 14:42:39 +0800 From: Jie Dong To: "l2vpn@ietf.org" Subject: Extended communities in EVPN Thread-Topic: Extended communities in EVPN Thread-Index: Ac3TfOH1Ma2/3yaERPe96h8i7+3gxw== Date: Thu, 6 Dec 2012 06:42:39 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927326E766B@szxeml504-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.164] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927326E766Bszxeml504mbxchi_" 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, 06 Dec 2012 06:42:54 -0000 --_000_76CD132C3ADEF848BD84D028D243C927326E766Bszxeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Here are some comments about the extended communities in EVPN draft. 1. The EVPN draft defines 4 new extended communities, all of which ar= e defined as transitive extended communities. But I noticed that in ESI MPL= S Label Extended Community, ES-Import Extended Community and MAC Mobility E= xtended Community, the high-order octet of the Type field is 0x44, which me= ans non-transitive. Besides, according to IANA's registry, the type code 0x= 44 has been assigned to "QoS Marking" which is a regular non-transitive ext= ended community, thus it cannot be reused as the high-order octet of an ext= ended type. Thus I would propose to change the type value 0x44 in evpn draft to TBA. 2. In section 8.8, "The value of the second octet (Sub-Type) is 0x030d (Default Gateway) as de= fined by IANA." should be "The value of the second octet (Sub-Type) is 0x0d as defined by IANA." Best regards, Jie --_000_76CD132C3ADEF848BD84D028D243C927326E766Bszxeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Here are some comments about th= e extended communities in EVPN draft.

 

1= .   &= nbsp;   The EVPN draft defines = 4 new extended communities, all of which are defined as transitive extended= communities. But I noticed that in ESI MPLS Label Extended Community, ES-I= mport Extended Community and MAC Mobility Extended Community, the high-order octet of the Type field is 0x44, which = means non-transitive. Besides, according to IANA’s registry, the type= code 0x44 has been assigned to “QoS Marking” which is a regula= r non-transitive extended community, thus it cannot be reused as the high-order octet of an extended type. <= /p>

 

Thus I would propose to change = the type value 0x44 in evpn draft to TBA.

 

2= .   &= nbsp;   In section 8.8,

&#= 8220;The value of the second octet (Sub-Type) is 0x030d (Default Gateway) a= s defined by IANA.”

 

should be

 

&#= 8220;The value of the second octet (Sub-Type) is 0x0d as defined by IANA.&#= 8221;

 

 

Best regards,=

Jie

 

--_000_76CD132C3ADEF848BD84D028D243C927326E766Bszxeml504mbxchi_-- From sajassi@cisco.com Thu Dec 6 00:25: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 10EEA21F8C1B for ; Thu, 6 Dec 2012 00:25:17 -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 Ht2THE2oucY4 for ; Thu, 6 Dec 2012 00:25:15 -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 13FAE21F8C09 for ; Thu, 6 Dec 2012 00:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32760; q=dns/txt; s=iport; t=1354782315; x=1355991915; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=A31nEXQ0pH3co9CfqSZBFnp9LriA3okeA1ZzMnlxwwU=; b=QfJJxvY+ClnxZtNYm/AV27QW2udhYR6vRvcxAn+fUFaReurN1GoWTS7E qUVCzQtZ7g2moJo9F/8lfXJufnOe8RCFQSdwN/qgEK1eLsNzf5rB9kAFl pie5qqkA23yF+Cr8ovAnTma4cwTbEbdQfF7lrD5gCPlxEP0mExZCg5owQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAARWwFCtJV2d/2dsb2JhbABBA4JJI7tAFnOCHgEBAQQtTBIBCBEDAQEBCxYBBjkUCQgBAQQBDQUIiAgBwlOMN4EVgkthA6ZKgnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149971017" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 06 Dec 2012 08:25:11 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB68PB2f000689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 08:25:11 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 02:25:10 -0600 From: "Ali Sajassi (sajassi)" To: Jie Dong , Jakob Heitz Subject: Re: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgAFCLWLgAAcGhIA= Date: Thu, 6 Dec 2012 08:25:10 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7D24F3@xmb-aln-x13.cisco.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927326E75DF@szxeml504-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: [10.21.125.22] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B0D7D24F3xmbalnx13ciscoc_" 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, 06 Dec 2012 08:25:17 -0000 --_000_69670F7146898C4583F56DA9AD32F77B0D7D24F3xmbalnx13ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable PE2 can receive both unicast traffic as well as flooded traffic for MAC1. I= f it receives unicast packets for MAC1 (via unicast LSP), then it simply fo= rwards them to its segment. However, if it receives flooded traffic for MAC= 1 (via mcast LSP) and it is not DF for it, then it drops them. Cheers, Ali From: Jie Dong > Date: Wednesday, December 5, 2012 7:36 PM To: Cisco Employee >, Jakob Hei= tz > Cc: "l2vpn@ietf.org" > Subject: RE: EVPN: withdrawing the alias Hi Ali, Jakob, Here is one comment about scenario 2: 2. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) mes= sage from PE1 first (before MAC1 route withdraw), then because of aliasing,= PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In wh= ich case, it removes MAC1 entry from its table and starts flooding traffic = toward MAC1. This covers link/port failure scenario. When PE2 receives the traffic to MAC1 before it advertises the MAC1 route, = will it treat the traffic as unknown unicast? If so, since PE2 may not beco= me the DF for the segment, it can not flood the traffic to the segment and = the traffic will get dropped. Is this understanding correct? Regards, Jie From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Friday, November 30, 2012 3:19 AM 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. 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_69670F7146898C4583F56DA9AD32F77B0D7D24F3xmbalnx13ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <65907518C3CAF147BAA06E03A3E62D39@cisco.com> Content-Transfer-Encoding: quoted-printable

PE2 can receive both unicast traffic as well as flooded traffic for MA= C1. If it receives unicast packets for MAC1 (via unicast LSP), then it simp= ly forwards them to its segment. However, if it receives flooded traffic fo= r MAC1 (via mcast LSP) and it is not DF for it, then it drops them.

Cheers,
Ali

From: Jie Dong <jie.dong@huawei.com>
Date: Wednesday, December 5, 2012 7= :36 PM
To: Cisco Employee <sajassi@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: RE: EVPN: withdrawing the = alias

Hi Ali, Jakob,

 =

Here is one comme= nt about scenario 2:

2.       If the remote PE= (e.g., PE3) receives Ether AD (mass withdraw) message from PE1 first (befo= re MAC1 route withdraw), then because of aliasing, PE3 forwards traffic to PE2 till it receives MAC1 withdraw fr= om PE1. In which case, it removes MAC1 entry from its table and starts floo= ding traffic toward MAC1. This covers link/port failure scenario.

When PE2 receives= the traffic to MAC1 before it advertises the MAC1 route, will it treat the= traffic as unknown unicast? If so, since PE2 may not become the DF for the segment, it can not flood the traffic to= the segment and the traffic will get dropped. Is this understanding correc= t?

 =

Regards,

Jie

 =

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Friday, November 30, 2012 3:19 AM
To: Jakob Heitz
Cc: l2vpn@ietf.org
Subject: Re: EVPN: withdrawing the alias

 

 

Let me summarize the operati= on as follow:

 

  1. if the remote PE (e.g., PE3) only receives MAC1 advertisement fro= m only one of the PE in the Multi-homing group (e.g., from PE1), then upon = receiving 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) receives Ether AD (mass withdraw) me= ssage 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 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"= <l2vpn@ietf.org>
Subject: Re: EVPN: withdrawing the alias

 

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

 

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

 

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

 

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 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 learns MAC1 from PE2.

 

Cheers,

Ali

 

I propose:=

 

If a PE has advertised an Et= hernet 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&n= bsp;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 re= ceives 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 s= tart an aging timer to delete its alias.

--

Jakob Heitz.

 

sajassi@cisco.com> wrote:

 

Good question! The reason th= at PE1 withdraws MAC1 can be:

 

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

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

In case of (2), PE1 withdraw= s MAC1 but there is no advertisement by PE2. In this case, MAC1 is not reac= hable via either PE1 or PE2.

 

I think we can elaborate thi= s 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 d=
ual-homed to two PEs (PE1 and PE2) on a
   LAG interface (ES1), and is sending packets with MAC a=
ddress MAC1 on
   VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE=
2 advertise a Ethernet A-D
   route per ESI for ESI1 as well as an Ethernet A-D rout=
e per EVI for
   <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 a=
s reachable
   via both PE1 and PE2.

 

Now, suppose PE1 withdraws its a= dvertisement 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_69670F7146898C4583F56DA9AD32F77B0D7D24F3xmbalnx13ciscoc_-- From sajassi@cisco.com Thu Dec 6 00:30: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 2B22821F8482 for ; Thu, 6 Dec 2012 00:30:05 -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 AeSw+guWs298 for ; Thu, 6 Dec 2012 00:30:04 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 056A121F8481 for ; Thu, 6 Dec 2012 00:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11441; q=dns/txt; s=iport; t=1354782604; x=1355992204; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=pzDB0RmJm8KiMphfhStkuoS9X4N1NhV/JrmlZQJFG00=; b=G4+vOwZKmHmndasCzZztHwxiwH7YdnQW9lAUw7q8fjwh5yi6oMdf+ySE CzS2DKXm4YvpCl/OgUu52EfrXVUU2m4dFF5t6vhLtbVsPFYMVZ/aP/GWe yFPb+KVHJcVKwQo7LOQf7gJFxZFrJtRhoHJOvfsaj9X9V5BL74a3eLQgH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIlWwFCtJV2c/2dsb2JhbABEgkkju0AWc4IeAQEBBC1eAQgRAwECCx05FAkIAQEEARIIDId8AcJNjDeDYGEDklCTeoJygiE X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149967659" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 06 Dec 2012 08:30:03 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB68U3wb024105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 08:30:03 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 02:30:02 -0600 From: "Ali Sajassi (sajassi)" To: Jie Dong , "l2vpn@ietf.org" Subject: Re: Extended communities in EVPN Thread-Topic: Extended communities in EVPN Thread-Index: Ac3TfOH1Ma2/3yaERPe96h8i7+3gx////HmA Date: Thu, 6 Dec 2012 08:30:02 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7D2532@xmb-aln-x13.cisco.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927326E766B@szxeml504-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: [10.21.125.22] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B0D7D2532xmbalnx13ciscoc_" 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, 06 Dec 2012 08:30:05 -0000 --_000_69670F7146898C4583F56DA9AD32F77B0D7D2532xmbalnx13ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Noted. Thanks, Ali From: Jie Dong > Date: Wednesday, December 5, 2012 10:42 PM To: "l2vpn@ietf.org" > Subject: Extended communities in EVPN Hi, Here are some comments about the extended communities in EVPN draft. 1. The EVPN draft defines 4 new extended communities, all of which ar= e defined as transitive extended communities. But I noticed that in ESI MPL= S Label Extended Community, ES-Import Extended Community and MAC Mobility E= xtended Community, the high-order octet of the Type field is 0x44, which me= ans non-transitive. Besides, according to IANA=92s registry, the type code = 0x44 has been assigned to =93QoS Marking=94 which is a regular non-transiti= ve extended community, thus it cannot be reused as the high-order octet of = an extended type. Thus I would propose to change the type value 0x44 in evpn draft to TBA. 2. In section 8.8, =93The value of the second octet (Sub-Type) is 0x030d (Default Gateway) as = defined by IANA.=94 should be =93The value of the second octet (Sub-Type) is 0x0d as defined by IANA.=94 Best regards, Jie --_000_69670F7146898C4583F56DA9AD32F77B0D7D2532xmbalnx13ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <375C88222CDE5E4B91A15E768649224A@cisco.com> Content-Transfer-Encoding: quoted-printable

Noted.

Thanks,
Ali

From: Jie Dong <jie.dong@huawei.com>
Date: Wednesday, December 5, 2012 1= 0:42 PM
To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: Extended communities in EV= PN

Hi,

 

Here are some comments about th= e extended communities in EVPN draft.

 

1.  &nb= sp;    The EVPN draft defi= nes 4 new extended communities, all of which are defined as transitive exte= nded communities. But I noticed that in ESI MPLS Label Extended Community, = ES-Import Extended Community and MAC Mobility Extended Community, the high-order octet of the Type field is 0x4= 4, which means non-transitive. Besides, according to IANA=92s registry, the= type code 0x44 has been assigned to =93QoS Marking=94 which is a regular n= on-transitive extended community, thus it cannot be reused as the high-order octet of an extended type.

 

Thus I would propose to change = the type value 0x44 in evpn draft to TBA.

 

2.  &nb= sp;    In section 8.8,

= =93The value of the second octet (Sub-Type) is 0x030d (Default Gateway) as = defined by IANA.=94

 

should be

 

= =93The value of the second octet (Sub-Type) is 0x0d as defined by IANA.=94<= o:p>

 

 

Best regards,=

Jie

 

 --_000_69670F7146898C4583F56DA9AD32F77B0D7D2532xmbalnx13ciscoc_-- From sajassi@cisco.com Thu Dec 6 00:53: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 AD5DE21F857B for ; Thu, 6 Dec 2012 00:53:17 -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 rQHuTSnv0NgU for ; Thu, 6 Dec 2012 00:53:17 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CDE8B21F850D for ; Thu, 6 Dec 2012 00:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5001; q=dns/txt; s=iport; t=1354783997; x=1355993597; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=vZxmVoGwr+wm7kSrnotnGcy8zG2RZlJL4kzH92+t9Q4=; b=ENYtOZ0oopz/OQwjMI4Ac7EO86xOZ76ogitPFBJK6m/53vB75e4HA+Hp +UXU4esfGCl20CPEn0mcSLmDSVAPBy1NxF5FAKhosnF1jJH1JEvDkaann 5WyVOULo9DE0+SedTxxN6aAX0hyR/fUMoO5oEwSJ7wXOIOqs0KdzX4YHS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOBbwFCtJXHA/2dsb2JhbABEgkkju0AWc4IeAQEBBIELAQgRBAEBCx05FAkIAQEEARIIDId8AcI0jDeDYGEDpkqCcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149972810" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 06 Dec 2012 08:53:16 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB68rGNc018971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 08:53:16 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 02:53:16 -0600 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: EVPN: ES-Import and RT-Constrain Thread-Topic: EVPN: ES-Import and RT-Constrain Thread-Index: Ac3QWBxfPX23/85PSUahfduODR5PRwCSguQQADcNNwA= Date: Thu, 6 Dec 2012 08:53:15 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7D25C6@xmb-aln-x13.cisco.com> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E105749@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.125.22] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B0D7D25C6xmbalnx13ciscoc_" 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, 06 Dec 2012 08:53:17 -0000 --_000_69670F7146898C4583F56DA9AD32F77B0D7D25C6xmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that's the basic idea but it should be vetted in IDR. Cheers, Ali ________________________________ From: Jakob Heitz Sent: Saturday, December 01, 2012 10:42 PM To: l2vpn@ietf.org Subject: EVPN: ES-Import and RT-Constrain Just like a route-target, the ES-Import Extended Community is used to filter the routes that contain them. As such, they should be able to take advantage of RT-Constrain (rfc4684). The RT-Constrain NLRI needs no modification. All that is needed is for an RT-Constrain implementation to add the ES-Import as a filter criteria. A sentence in the EVPN draft as follows should ensure that: A BGP speaker that includes both the (AFI, SAFI) of RT-Constrain (rfc4684) as well as of EVPN in the capabilitiy advertisement MUST apply the RT-Constrain procedures to any ES-import extended community it receives in the RT-Constrain Route Target Membership NLRI. -- Jakob Heitz. --_000_69670F7146898C4583F56DA9AD32F77B0D7D25C6xmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <99554CE6A5B8BF4F8F1EC8B497593157@cisco.com> Content-Transfer-Encoding: quoted-printable

Yes, that's the basic idea but it should be vetted in IDR.

Cheers,
Ali
From: Jakob Heitz
Sent: Saturday, December 01, 2012 10:42 PM
To: l2vpn@ietf.org
Subject: EVPN: ES-Import and RT-Constrain

Just like a route-target, the ES-Import Extended Co= mmunity is used
to filter the routes that contain them. As such, th= ey should be
able to take advantage of RT-Constrain (rfc4684).
 
The RT-Constrain NLRI needs no modification. All&nb= sp;that is needed
is for an RT-Constrain implementation to add the ES= -Import
as a filter criteria. A sentence in the EVPN draft = as follows
should ensure that:
&nbs= p;
A BGP speaker that includes both the (AFI, SAFI) of= RT-Constrain (rfc4684)
as well as of EVPN in the capabilitiy advertis= ement MUST apply
the RT-Constrain procedures to any ES-import extend= ed community
it receives in the RT-Constrain Route Target Member= ship NLRI.
 
--
Jakob Heitz.
 
 --_000_69670F7146898C4583F56DA9AD32F77B0D7D25C6xmbalnx13ciscoc_-- From jie.dong@huawei.com Thu Dec 6 01:19:22 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8721F8629 for ; Thu, 6 Dec 2012 01:19:21 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLmLcNv8m7t6 for ; Thu, 6 Dec 2012 01:19:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E98D321F853F for ; Thu, 6 Dec 2012 01:19:14 -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 AMF64576; Thu, 06 Dec 2012 09:19:13 +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; Thu, 6 Dec 2012 09:17:39 +0000 Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 09:18:08 +0000 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.99]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 17:18:02 +0800 From: Jie Dong To: "Ali Sajassi (sajassi)" , Jakob Heitz Subject: RE: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgAFCLWLgAAcGhIAABQ7SYA== Date: Thu, 6 Dec 2012 09:18:01 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927326E76F9@szxeml504-mbx.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C927326E75DF@szxeml504-mbx.china.huawei.com> <69670F7146898C4583F56DA9AD32F77B0D7D24F3@xmb-aln-x13.cisco.com> In-Reply-To: <69670F7146898C4583F56DA9AD32F77B0D7D24F3@xmb-aln-x13.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.164] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927326E76F9szxeml504mbxchi_" 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, 06 Dec 2012 09:19:22 -0000 --_000_76CD132C3ADEF848BD84D028D243C927326E76F9szxeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ali, Thanks for your prompt response. Just want to further confirm my understand= ing : If PE2 receives packets for MAC1 via unicast LSP, it can be 1) the remote PE sends unicast packets to PE2. 2) the remote PE floods unknown unicast packets using ingress replica= tion. Since the flooded traffic with ingress replication would carry the downstre= am assigned label which PE2 advertised in PMSI Tunnel attribute, PE2 can te= ll whether the packets are unicast or flooded unknown unicast, and will onl= y forward the unicast traffic to the segment. The flooded traffic for MAC1 = using ingress replication will be dropped by PE2 if it is not DF. Regards, Jie From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Thursday, December 06, 2012 4:25 PM To: Jie Dong; Jakob Heitz Cc: l2vpn@ietf.org Subject: Re: EVPN: withdrawing the alias PE2 can receive both unicast traffic as well as flooded traffic for MAC1. I= f it receives unicast packets for MAC1 (via unicast LSP), then it simply fo= rwards them to its segment. However, if it receives flooded traffic for MAC= 1 (via mcast LSP) and it is not DF for it, then it drops them. Cheers, Ali From: Jie Dong > Date: Wednesday, December 5, 2012 7:36 PM To: Cisco Employee >, Jakob Hei= tz > Cc: "l2vpn@ietf.org" > Subject: RE: EVPN: withdrawing the alias Hi Ali, Jakob, Here is one comment about scenario 2: 2. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) mess= age from PE1 first (before MAC1 route withdraw), then because of aliasing, = PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In whi= ch case, it removes MAC1 entry from its table and starts flooding traffic t= oward MAC1. This covers link/port failure scenario. When PE2 receives the traffic to MAC1 before it advertises the MAC1 route, = will it treat the traffic as unknown unicast? If so, since PE2 may not beco= me the DF for the segment, it can not flood the traffic to the segment and = the traffic will get dropped. Is this understanding correct? Regards, Jie From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Friday, November 30, 2012 3:19 AM 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. 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 ... 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_76CD132C3ADEF848BD84D028D243C927326E76F9szxeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ali,

 = ;

Thanks for= your prompt response. Just want to further confirm my understanding :=

 = ;

If PE2 rec= eives packets for MAC1 via unicast LSP, it can be

1)       th= e remote PE sends unicast packets to PE2.

2)       th= e remote PE floods unknown unicast packets using ingress replication.<= /o:p>

 = ;

Since the = flooded traffic with ingress replication would carry the downstream assigne= d label which PE2 advertised in PMSI Tunnel attribute, PE2 can tell whether the packets are unicast or flooded unknown unicast, and w= ill only forward the unicast traffic to the segment. The flooded traffic fo= r MAC1 using ingress replication will be dropped by PE2 if it is not DF.

 = ;

Regards,

Jie

 = ;

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Thursday, December 06, 2012 4:25 PM
To: Jie Dong; Jakob Heitz
Cc: l2vpn@ietf.org
Subject: Re: EVPN: withdrawing the alias

 

 <= /o:p>

PE2 can rece= ive both unicast traffic as well as flooded traffic for MAC1. If it receive= s unicast packets for MAC1 (via unicast LSP), then it simply forwards them to its segment. However, if it receives flooded traffic for = MAC1 (via mcast LSP) and it is not DF for it, then it drops them.

 <= /o:p>

Cheers,=

Ali

 <= /o:p>

From: Jie Dong <jie.dong@huawei.com>
Date: Wednesday, December 5, 2012 7:36 PM
To: Cisco Employee <sajassi@= cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: RE: EVPN: withdrawing the alias

 <= /o:p>

Hi Ali, Ja= kob,

 

Here is on= e comment about scenario 2:

2.      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 wh= ich case, it removes MAC1 entry from its table and starts flooding traffic = toward MAC1. This covers link/port failure scenario.

When PE2 r= eceives the traffic to MAC1 before it advertises the MAC1 route, will it tr= eat the traffic as unknown unicast? If so, since PE2 may not become the DF for the segment, it can not flood the traffic to the segment= and the traffic will get dropped. Is this understanding correct?

 

Regards,

Jie=

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Friday, November 30, 2012 3:19 AM
To: Jakob Heitz
Cc: l2vpn@ietf.org
Subject: Re: EVPN: withdrawing the alias

 

 

Let me summa= rize 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., fro= m PE1), then upon receiving withdraw message for this MAC1,  PE3 will flood subsequent traffic toward MAC1. This covers the scena= rio in which MAC1 ages out on PE1.
  2. If the remote PE (e.g., PE3) receives Ether AD = (mass withdraw) message from PE1 first (before MAC1 route withdraw), then b= ecause 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 f= ailure scenario.

 

More comment= s 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 *only* if there is traffic from MAC1. This is b= y no means assured. In that case, 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 Ethern= et A-D. That could trigger an aging timer on PE3 for the alias.

 

Ali> No n= eed to delay the withdraw. Ether AD mass-withdraw message will cause 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 t= here is no flooding; otherwise, there will be little bit of flooding till P= E3 learns MAC1 from PE2.<= o:p>

 

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 P= E 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 subsequently re= ceives 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 s= tart 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 questio= n! 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 c= an 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 d=
ual-homed to two PEs (PE1 and PE2) on a
   LAG interface (ES1), and is sending packets with MAC a=
ddress MAC1 on
   VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE=
2 advertise a Ethernet A-D
   route per ESI for ESI1 as well as an Ethernet A-D rout=
e per EVI for
   <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 a=
s reachable
   via both PE1 and PE2.

 

Now, suppose PE1 withdraws = its advertisement of MAC1.

Does PE3 still consider MAC= 1 as reachable via PE2?

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

--
Jakob Heitz. x25475. 510-566-2= 901

 

--_000_76CD132C3ADEF848BD84D028D243C927326E76F9szxeml504mbxchi_-- From sajassi@cisco.com Thu Dec 6 09:32: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 4330221F85EA for ; Thu, 6 Dec 2012 09:32:11 -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 DWqFZHoLAfwE for ; Thu, 6 Dec 2012 09:32:09 -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 53A8E21F85D6 for ; Thu, 6 Dec 2012 09:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46738; q=dns/txt; s=iport; t=1354815129; x=1356024729; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=xxMHzq0XajNSIava2h1mhQz1FJXkaga0DGk30QV1gSM=; b=PecojRbiMiVVOsVTxhJehM5rNuLcQ8Y5V8EWGypVctZNt3zNGxaYRQCT qItZzonwawOuPmtvrQzkjTaBytzBKnkCf+URDlkcFEfRwrSu8hLgpolSe FDowlmT8MygFGDKb8Qxyi32a0yEvjTg/uv7RhiPKOyQGedpxnYxnGYD38 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANTUwFCtJXG//2dsb2JhbABBA4JJI7s+FnOCHgEBAQQtTBIBCBEDAQEBCxYBBjkUCQgCBAENBQiICAHCVIw5gRWCTWEDpkqCc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150138757" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 06 Dec 2012 17:32:08 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB6HW8xd001715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 17:32:08 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 11:32:07 -0600 From: "Ali Sajassi (sajassi)" To: Jie Dong , Jakob Heitz Subject: Re: EVPN: withdrawing the alias Thread-Topic: EVPN: withdrawing the alias Thread-Index: Ac3NuqjqrYzIHexTSRuilVAuUQE4UAAPwwKAAA4Doq8ACPbAgAFCLWLgAAcGhIAABQ7SYAAOC76A Date: Thu, 6 Dec 2012 17:32:06 +0000 Message-ID: <69670F7146898C4583F56DA9AD32F77B0D7D275C@xmb-aln-x13.cisco.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927326E76F9@szxeml504-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: [10.128.2.166] Content-Type: multipart/alternative; boundary="_000_69670F7146898C4583F56DA9AD32F77B0D7D275Cxmbalnx13ciscoc_" 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, 06 Dec 2012 17:32:11 -0000 --_000_69670F7146898C4583F56DA9AD32F77B0D7D275Cxmbalnx13ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Exactly! Cheers Ali From: Jie Dong > Date: Thursday, December 6, 2012 1:18 AM To: Cisco Employee >, Jakob Hei= tz > Cc: "l2vpn@ietf.org" > Subject: RE: EVPN: withdrawing the alias Hi Ali, Thanks for your prompt response. Just want to further confirm my understand= ing : If PE2 receives packets for MAC1 via unicast LSP, it can be 1) the remote PE sends unicast packets to PE2. 2) the remote PE floods unknown unicast packets using ingress replica= tion. Since the flooded traffic with ingress replication would carry the downstre= am assigned label which PE2 advertised in PMSI Tunnel attribute, PE2 can te= ll whether the packets are unicast or flooded unknown unicast, and will onl= y forward the unicast traffic to the segment. The flooded traffic for MAC1 = using ingress replication will be dropped by PE2 if it is not DF. Regards, Jie From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Thursday, December 06, 2012 4:25 PM To: Jie Dong; Jakob Heitz Cc: l2vpn@ietf.org Subject: Re: EVPN: withdrawing the alias PE2 can receive both unicast traffic as well as flooded traffic for MAC1. I= f it receives unicast packets for MAC1 (via unicast LSP), then it simply fo= rwards them to its segment. However, if it receives flooded traffic for MAC= 1 (via mcast LSP) and it is not DF for it, then it drops them. Cheers, Ali From: Jie Dong > Date: Wednesday, December 5, 2012 7:36 PM To: Cisco Employee >, Jakob Hei= tz > Cc: "l2vpn@ietf.org" > Subject: RE: EVPN: withdrawing the alias Hi Ali, Jakob, Here is one comment about scenario 2: 2. If the remote PE (e.g., PE3) receives Ether AD (mass withdraw) mess= age from PE1 first (before MAC1 route withdraw), then because of aliasing, = PE3 forwards traffic to PE2 till it receives MAC1 withdraw from PE1. In whi= ch case, it removes MAC1 entry from its table and starts flooding traffic t= oward MAC1. This covers link/port failure scenario. When PE2 receives the traffic to MAC1 before it advertises the MAC1 route, = will it treat the traffic as unknown unicast? If so, since PE2 may not beco= me the DF for the segment, it can not flood the traffic to the segment and = the traffic will get dropped. Is this understanding correct? Regards, Jie From:l2vpn-bounces@ietf.org [mailto:l2vpn-bo= unces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Friday, November 30, 2012 3:19 AM 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. 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_69670F7146898C4583F56DA9AD32F77B0D7D275Cxmbalnx13ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <64629BF86FDAC341A95E5DC3E15E2B33@cisco.com> Content-Transfer-Encoding: quoted-printable

Exactly!

Cheers
Ali

From: Jie Dong <jie.dong@huawei.com>
Date: Thursday, December 6, 2012 1:= 18 AM
To: Cisco Employee <sajassi@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: RE: EVPN: withdrawing the = alias

Hi Ali,

 =

Thanks for your p= rompt response. Just want to further confirm my understanding :<= /span>

 =

If PE2 receives p= ackets for MAC1 via unicast LSP, it can be

1)       the r= emote PE sends unicast packets to PE2.

2)       the r= emote PE floods unknown unicast packets using ingress replication.

 =

Since the flooded= traffic with ingress replication would carry the downstream assigned label= which PE2 advertised in PMSI Tunnel attribute, PE2 can tell whether the packets are unicast or flooded unknown unicast, a= nd will only forward the unicast traffic to the segment. The flooded traffi= c for MAC1 using ingress replication will be dropped by PE2 if it is not DF= .

 =

Regards,

Jie

 =

From: Ali Sajassi (sajas= si) [mailto:sajassi@cisco.com]
Sent: Thursday, December 06, 2012 4:25 PM
To: Jie Dong; Jakob Heitz
Cc: l2vpn@ietf.org
Subject: Re: EVPN: withdrawing the alias

 

 

PE2 can receive both unicast= traffic as well as flooded traffic for MAC1. If it receives unicast packet= s for MAC1 (via unicast LSP), then it simply forwards them to its segment. However, if it receives flooded traff= ic for MAC1 (via mcast LSP) and it is not DF for it, then it drops them.

 

Cheers,

Ali

 

From: Jie Dong <jie.dong@huawei.com>
Date: Wednesday, December 5, 2012 7:36 PM
To: Cisco Employee <sajassi@= cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: RE: EVPN: withdrawing the alias

 

Hi Ali, Jakob,

 

Here is one comme= nt about scenario 2:=

2.      If the remote PE= (e.g., PE3) receives Ether AD (mass withdraw) message from PE1 first (befo= re MAC1 route withdraw), then because of aliasing, PE3 forwards traffic to PE2 till it receives MAC1 withdraw fr= om PE1. In which case, it removes MAC1 entry from its table and starts floo= ding traffic toward MAC1. This covers link/port failure scenario.

When PE2 receives= the traffic to MAC1 before it advertises the MAC1 route, will it treat the= traffic as unknown unicast? If so, since PE2 may not become the DF for the segment, it can not flood the traffic to= the segment and the traffic will get dropped. Is this understanding correc= t?

 

Regards,

Jie

 

 

 

Let me summarize the operati= on as follow:<= /span>

 

  1. if the remote PE (e.g., PE3) only receives MAC1 advertisement fro= m only one of the PE in the Multi-homing group (e.g., from PE1), then upon = receiving 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) receives Ether AD (mass withdraw) me= ssage 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 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"= <l2vpn@ietf.org>
Subject: Re: EVPN: withdrawing the alias

 

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

 

Ali> yes, PE3 consider MA= C1 as unknown and starts flooding traffic toward MAC1 till it learns it fro= m PE2.<= /p>

 

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

 

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 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 learns MAC1 from PE2.

 

Cheers,

Ali

 

I propose:

 

If a PE has advertised an Et= hernet 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&n= bsp;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 re= ceives 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 s= tart an aging timer to delete its alias.

--

Jakob Heitz.

 

sajassi@cisco.com> wrote:

 

Good question! The reason th= at PE1 withdraws MAC1 can be:

 

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

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

In case of (2), PE1 withdraw= s MAC1 but there is no advertisement by PE2. In this case, MAC1 is not reac= hable via either PE1 or PE2.

 

I think we can elaborate thi= s 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 d=
ual-homed to two PEs (PE1 and PE2) on a
   LAG interface (ES1), and is sending packets with MAC a=
ddress MAC1 on
   VLAN1. MAC1 is advertised only by PE1. Both PE1 and PE=
2 advertise a Ethernet A-D
   route per ESI for ESI1 as well as an Ethernet A-D rout=
e per EVI for
   <ESI1, VLAN1>. A remote PE, PE3 considers MAC1 a=
s reachable
   via both PE1 and PE2.

 

Now, suppose PE1 withdraws its a= dvertisement 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_69670F7146898C4583F56DA9AD32F77B0D7D275Cxmbalnx13ciscoc_-- From internet-drafts@ietf.org Mon Dec 10 11:04: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 66FC121F845D; Mon, 10 Dec 2012 11:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 EGJxpPIUFN6p; Mon, 10 Dec 2012 11:04:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A5D21F865D; Mon, 10 Dec 2012 11:04:00 -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-ipls-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121210190400.13328.52337.idtracker@ietfa.amsl.com> Date: Mon, 10 Dec 2012 11:04:00 -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: Mon, 10 Dec 2012 19:04:01 -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 : IP-Only LAN Service (IPLS) Author(s) : Himanshu Shah Eric Rosen Francois Le Faucheur Giles Heron Filename : draft-ietf-l2vpn-ipls-11.txt Pages : 25 Date : 2012-12-10 Abstract: A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-ipls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-ipls-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From MBiswas@ixiacom.com Tue Dec 11 06:32: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 1358B21F84C8 for ; Tue, 11 Dec 2012 06:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 VxLjW9OcLlfu for ; Tue, 11 Dec 2012 06:32:33 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2905321F8485 for ; Tue, 11 Dec 2012 06:32:32 -0800 (PST) Received: from mail144-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Dec 2012 14:32:32 +0000 Received: from mail144-co9 (localhost [127.0.0.1]) by mail144-co9-R.bigfish.com (Postfix) with ESMTP id 4F7253A01BA for ; Tue, 11 Dec 2012 14:32:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.149; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0611HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(z5405izc85fh168aJzz1de0h1202h1e76h1d1ah1d2ahzz18c673h17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail144-co9: domain of ixiacom.com designates 157.56.244.149 as permitted sender) client-ip=157.56.244.149; envelope-from=MBiswas@ixiacom.com; helo=CH1PRD0611HT003.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail144-co9 (localhost.localdomain [127.0.0.1]) by mail144-co9 (MessageSwitch) id 1355236344962189_16016; Tue, 11 Dec 2012 14:32:24 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.244]) by mail144-co9.bigfish.com (Postfix) with ESMTP id E8A3980059 for ; Tue, 11 Dec 2012 14:32:24 +0000 (UTC) Received: from CH1PRD0611HT003.namprd06.prod.outlook.com (157.56.244.149) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Dec 2012 14:32:18 +0000 Received: from CH1PRD0611MB444.namprd06.prod.outlook.com ([169.254.6.200]) by CH1PRD0611HT003.namprd06.prod.outlook.com ([10.255.148.166]) with mapi id 14.16.0245.002; Tue, 11 Dec 2012 14:32:14 +0000 From: Manomugdha Biswas To: "l2vpn@ietf.org" Subject: EVPN Thread-Topic: EVPN Thread-Index: Ac3XqrmsT3aN7yrTRnGvX79vshcFgg== Date: Tue, 11 Dec 2012 14:32:13 +0000 Message-ID: <8F59616961A3BD458BB4F59E7102BA042A6AE682@CH1PRD0611MB444.namprd06.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.14.67] Content-Type: multipart/alternative; boundary="_000_8F59616961A3BD458BB4F59E7102BA042A6AE682CH1PRD0611MB444_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0611HT003.namprd06.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0611HT003.namprd06.prod.outlook.com X-OriginatorOrg: ixiacom.com X-Mailman-Approved-At: Tue, 11 Dec 2012 10:23:23 -0800 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, 11 Dec 2012 14:33:52 -0000 --_000_8F59616961A3BD458BB4F59E7102BA042A6AE682CH1PRD0611MB444_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is regarding bgp path attributes in bgp update packet for route type "= Inclusive Multicast Ethernet Tag Route". We need to send path attributes for route type "MAC Advertisement Route". D= o we need to send path attributes for "Inclusive Multicast Ethernet Tag Rou= te" other than route target? Or we need to send only route targets for "Inc= lusive Multicast Ethernet Tag Route". Regards, Mano --_000_8F59616961A3BD458BB4F59E7102BA042A6AE682CH1PRD0611MB444_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is regarding bgp = path attributes in bgp update packet for route type “Inclusive M= ulticast Ethernet Tag Route”.

 

We need to send path a= ttributes for route type “MAC Advertisement Route&#= 8221;. Do we need to send path attributes for “Inclusive Multicast Et= hernet Tag Route” other than route target? Or we need to send only ro= ute targets for “Inclusive Multicast Ethernet Tag Route&#= 8221;.

 

Regards,

Mano<= /span>

--_000_8F59616961A3BD458BB4F59E7102BA042A6AE682CH1PRD0611MB444_-- From jakob.heitz@ericsson.com Tue Dec 11 10:55:09 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9333221F8563 for ; Tue, 11 Dec 2012 10:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.020, 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 VMGg0pyUbpHe for ; Tue, 11 Dec 2012 10:55:08 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 931A721F855F for ; Tue, 11 Dec 2012 10:55:08 -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 qBBJ5Ind006047; Tue, 11 Dec 2012 13:05:27 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Dec 2012 13:55:06 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Tue, 11 Dec 2012 13:55:06 -0500 From: Jakob Heitz To: Manomugdha Biswas , "l2vpn@ietf.org" Subject: RE: EVPN Thread-Topic: EVPN Thread-Index: Ac3XqrmsT3aN7yrTRnGvX79vshcFggAIyi9g Date: Tue, 11 Dec 2012 18:55:05 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E10F4FD@eusaamb109.ericsson.se> References: <8F59616961A3BD458BB4F59E7102BA042A6AE682@CH1PRD0611MB444.namprd06.prod.outlook.com> In-Reply-To: <8F59616961A3BD458BB4F59E7102BA042A6AE682@CH1PRD0611MB444.namprd06.prod.outlook.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_2F3EBB88EC3A454AAB08915FBF0B8C7E10F4FDeusaamb109ericsso_" 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: Tue, 11 Dec 2012 18:55:09 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E10F4FDeusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PMSI tunnel attribute is required. I would include the mandatory attributes as in rfc4271, just to ensure smooth progression through routers. Maybe we can relax this?? AS path is needed to prevent looping of the update message. Nexthop is included inside of MP_REACH. -- Jakob Heitz. ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of M= anomugdha Biswas Sent: Tuesday, December 11, 2012 6:32 AM To: l2vpn@ietf.org Subject: EVPN Hi, This is regarding bgp path attributes in bgp update packet for route type "= Inclusive Multicast Ethernet Tag Route". We need to send path attributes for route type "MAC Advertisement Route". D= o we need to send path attributes for "Inclusive Multicast Ethernet Tag Rou= te" other than route target? Or we need to send only route targets for "Inc= lusive Multicast Ethernet Tag Route". Regards, Mano --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E10F4FDeusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
PMSI tunnel attribute is= required.
I would include the mand= atory attributes as in rfc4271,
just to ensure smooth pr= ogression through routers.
Maybe we can relax this?= ?
AS path is needed to pre= vent looping of the update message.
Nexthop is included insi= de of MP_REACH.

-- Jakob Heitz.

 

From: l2vpn-bounces@ietf.org [mailt= o:l2vpn-bounces@ietf.org] On Behalf Of Manomugdha Biswas
Sent: Tuesday, December 11, 2012 6:32 AM
To: l2vpn@ietf.org
Subject: EVPN

Hi,

This is regarding bgp path attributes in bgp update = packet for route type “Inclusive Multicast Ethernet Tag Route= 221;.

 

We need to send path attributes for route type ̶= 0;= MAC Advertisement Route”. Do we need to send path attributes for “Inclusive Multicast Et= hernet Tag Route” other than route target? Or we need to send only ro= ute targets for “Inclusive Multicast Ethernet Tag Route”.

 

Regards,

Mano

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E10F4FDeusaamb109ericsso_-- From ietf-ipr@ietf.org Wed Dec 12 10:14: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 5525E21F88F4; Wed, 12 Dec 2012 10:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 7r-ctCMIKByl; Wed, 12 Dec 2012 10:14:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DEF21F889C; Wed, 12 Dec 2012 10:14:32 -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, yakov@juniper.net, y.kamite@ntt.com, lufang@cisco.com Subject: IPR Disclosure: Juniper's Statement of IPR Related to draft-ietf-l2vpn-vpls-mcast-12 X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212181431.8240.48354.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 10:14:31 -0800 X-Mailman-Approved-At: Wed, 12 Dec 2012 15:17:27 -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: Wed, 12 Dec 2012 18:14:34 -0000 Dear Rahul Aggarwal, Yakov Rekhter, Yuji Kamite, Luyuan Fang: An IPR disclosure that pertains to your Internet-Draft entitled "Multicast= in VPLS" (draft-ietf-l2vpn-vpls-mcast) was submitted to the IETF Secretariat on 2012-12-08 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1939/). The title of the IPR disclosure is "Juniper's Statement of IPR Related to draft-ietf-l2vpn-vpls- mcast-12.""); The IETF Secretariat From MBiswas@ixiacom.com Tue Dec 18 00:46: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 2743821F8739 for ; Tue, 18 Dec 2012 00:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=1.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 IilpdfoI9cYQ for ; Tue, 18 Dec 2012 00:46:39 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF621F8736 for ; Tue, 18 Dec 2012 00:46:39 -0800 (PST) Received: from mail64-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Dec 2012 08:46:39 +0000 Received: from mail64-tx2 (localhost [127.0.0.1]) by mail64-tx2-R.bigfish.com (Postfix) with ESMTP id 010F880102; Tue, 18 Dec 2012 08:46:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.149; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0611HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371Ic85fh168aJzz1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail64-tx2: domain of ixiacom.com designates 157.56.244.149 as permitted sender) client-ip=157.56.244.149; envelope-from=MBiswas@ixiacom.com; helo=CH1PRD0611HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail64-tx2 (localhost.localdomain [127.0.0.1]) by mail64-tx2 (MessageSwitch) id 135582039759186_8309; Tue, 18 Dec 2012 08:46:37 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.254]) by mail64-tx2.bigfish.com (Postfix) with ESMTP id 009CFF0005D; Tue, 18 Dec 2012 08:46:37 +0000 (UTC) Received: from CH1PRD0611HT005.namprd06.prod.outlook.com (157.56.244.149) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Dec 2012 08:46:35 +0000 Received: from CH1PRD0611MB444.namprd06.prod.outlook.com ([169.254.6.200]) by CH1PRD0611HT005.namprd06.prod.outlook.com ([10.255.148.168]) with mapi id 14.16.0245.002; Tue, 18 Dec 2012 08:46:34 +0000 From: Manomugdha Biswas To: Jakob Heitz , "l2vpn@ietf.org" Subject: RE: EVPN Thread-Topic: EVPN Thread-Index: Ac3XqrmsT3aN7yrTRnGvX79vshcFggAIyi9gAUj8XoA= Date: Tue, 18 Dec 2012 08:46:33 +0000 Message-ID: <8F59616961A3BD458BB4F59E7102BA042A6B0E8E@CH1PRD0611MB444.namprd06.prod.outlook.com> References: <8F59616961A3BD458BB4F59E7102BA042A6AE682@CH1PRD0611MB444.namprd06.prod.outlook.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E10F4FD@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E10F4FD@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.14.67] Content-Type: multipart/alternative; boundary="_000_8F59616961A3BD458BB4F59E7102BA042A6B0E8ECH1PRD0611MB444_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0611HT005.namprd06.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0611HT005.namprd06.prod.outlook.com X-OriginatorOrg: ixiacom.com X-Mailman-Approved-At: Tue, 18 Dec 2012 11:57:01 -0800 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, 18 Dec 2012 08:46:41 -0000 --_000_8F59616961A3BD458BB4F59E7102BA042A6B0E8ECH1PRD0611MB444_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is regarding mac mobility extended community in mac advertisement in P= BB-EVPN. What is the use of Counter in mac mobility? Regards, Mano From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] Sent: 12 December 2012 AM 12:25 To: Manomugdha Biswas; l2vpn@ietf.org Subject: RE: EVPN PMSI tunnel attribute is required. I would include the mandatory attributes as in rfc4271, just to ensure smooth progression through routers. Maybe we can relax this?? AS path is needed to prevent looping of the update message. Nexthop is included inside of MP_REACH. -- Jakob Heitz. ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Manom= ugdha Biswas Sent: Tuesday, December 11, 2012 6:32 AM To: l2vpn@ietf.org Subject: EVPN Hi, This is regarding bgp path attributes in bgp update packet for route type "= Inclusive Multicast Ethernet Tag Route". We need to send path attributes for route type "MAC Advertisement Route". D= o we need to send path attributes for "Inclusive Multicast Ethernet Tag Rou= te" other than route target? Or we need to send only route targets for "Inc= lusive Multicast Ethernet Tag Route". Regards, Mano --_000_8F59616961A3BD458BB4F59E7102BA042A6B0E8ECH1PRD0611MB444_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

This is regarding mac = mobility extended community in mac advertisement in PBB-EVPN.

 

What is the use of Cou= nter in mac mobility?

 

Regards,

Mano=

 

From:= Jakob Heitz [mailto:jakob.heitz@ericsson.com]
Sent: 12 December 2012 AM 12:25
To: Manomugdha Biswas; l2vpn@ietf.org
Subject: RE: EVPN

 

PMSI tunnel att= ribute is required.<= /o:p>

I would include= the mandatory attributes as in rfc4271,

just to ensure = smooth progression through routers.

Maybe we can re= lax this??

AS path is need= ed to prevent looping of the update message.

Nexthop is incl= uded inside of MP_REACH.<= o:p>

--
Jakob Heitz.

 

&nbs= p;

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Manomugdha Biswas Sent: Tuesday, December 11, 2012 6:32 AM
To: l2vpn@ietf.org
Subject: EVPN

Hi,

This is regarding bgp path attributes in bgp update = packet for route type “Inclusive Multicast Ethernet Tag Route”.

 

We need to send path attributes for route type ̶= 0;MAC Advertisement Route”. Do we need to send path attributes for “Inclusive Multicast Et= hernet Tag Route” other than route target? Or we need to send only ro= ute targets for “Inclusive Multicast Ethernet Tag Route&#= 8221;.

 

Regards,

Mano

--_000_8F59616961A3BD458BB4F59E7102BA042A6B0E8ECH1PRD0611MB444_-- From giles.heron@gmail.com Wed Dec 19 07:59: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 6BEBD21F8A4B for ; Wed, 19 Dec 2012 07:59:07 -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 Dwyyx9iVtI3Q for ; Wed, 19 Dec 2012 07:59:06 -0800 (PST) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 44EC621F8A72 for ; Wed, 19 Dec 2012 07:59:06 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id d4so1116762eek.10 for ; Wed, 19 Dec 2012 07:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=oczQWHQHxn04ElLkR4wNUG3suG0aIFgi1VQv7IpydIE=; b=0MgjRRZsw9JlT7+m+ma9xTcZpg9vR8HSS7xwHWyaD51iDIw1TBcVdUkYqgS3/a2RNI tlPf9g9uPii9dPAJBlAjFolD7k6JlCh/r/Z7rCmkaPz6EYXd3Nk1CMKtXDbV/feE1jUI me1nSmgVphQb9FGxjlxz/Wrs4prmVXtN52WjsJkyD93212IL90B6a/1w2qpyslwt++WB 6M1F9dzhBF4EC6BynBrQr9ff0zfxDRCMrP3AZGLfc6TE9pzAM71mh1hYOYEfMfpwxYYG 3KP2Qavu+T4uHE/2IMkjTLqLZEuRzbY5Zpj4ZTboLzRTF3iJh6XLMbxAYD/QSv9Cdjh2 BsvQ== X-Received: by 10.14.0.133 with SMTP id 5mr14996762eeb.29.1355932745357; Wed, 19 Dec 2012 07:59:05 -0800 (PST) Received: from [192.168.1.4] (host217-41-3-38.in-addr.btopenworld.com. [217.41.3.38]) by mx.google.com with ESMTPS id l3sm9915285eem.14.2012.12.19.07.59.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 07:59:04 -0800 (PST) From: Giles Heron Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: WG Last Call on draft-ietf-l2vpn-ipls Date: Wed, 19 Dec 2012 15:59:00 +0000 Message-Id: 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: Wed, 19 Dec 2012 15:59:07 -0000 This email initiates an L2VPN WG Last Call for: http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-11 please comment to the list as to the suitability of this draft for = publication as an Informational RFC from the L2VPN WG. As always it'd = be good to hear some comments over and above the usual "Support!". = Well, given the season any comments at all would be good ;) this last call will close on Friday 4th January. Nabil & Giles From josh.rogers@twcable.com Wed Dec 19 08:16: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 652A121F8AD6 for ; Wed, 19 Dec 2012 08:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.308 X-Spam-Level: * X-Spam-Status: No, score=1.308 tagged_above=-999 required=5 tests=[AWL=2.771, 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 6LI5qXFYRPWE for ; Wed, 19 Dec 2012 08:16:55 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D391721F8A9A for ; Wed, 19 Dec 2012 08:16:54 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,318,1355115600"; d="scan'208";a="735243" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 19 Dec 2012 11:16:48 -0500 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 19 Dec 2012 11:16:54 -0500 From: "Rogers, Josh" To: Giles Heron , "l2vpn@ietf.org" Date: Wed, 19 Dec 2012 11:16:52 -0500 Subject: Re: WG Last Call on draft-ietf-l2vpn-ipls Thread-Topic: WG Last Call on draft-ietf-l2vpn-ipls Thread-Index: Ac3eBEIgsTnRo/U5QUCjHMnqbFHNcA== 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.5.121010 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, 19 Dec 2012 16:16:55 -0000 I support publication. This methodology is attractive due to the isolation of the AC, potential isolation and/or mitigation loop on the AC, improved SP visibility into customer traffic benefiting coop troubleshooting and support for multicast customer traffic (to not be treated as broadcast). I do, however, see some overlap with EVPN, and would like to hear how the authors see the relationship between some of the EVPN work and this? -Josh On 12/19/12 9:59 AM, "Giles Heron" wrote: >This email initiates an L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-11 > >please comment to the list as to the suitability of this draft for >publication as an Informational RFC from the L2VPN WG. As always it'd be >good to hear some comments over and above the usual "Support!". Well, >given the season any comments at all would be good ;) > >this last call will close on Friday 4th January. > >Nabil & Giles 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 wim.henderickx@alcatel-lucent.com Wed Dec 19 11:56:39 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 2864121F8742 for ; Wed, 19 Dec 2012 11:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 nUD1WZUNodRh for ; Wed, 19 Dec 2012 11:56:38 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1021F86C0 for ; Wed, 19 Dec 2012 11:56:38 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBJJu0YV030731 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Dec 2012 20:56:36 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 19 Dec 2012 20:56:31 +0100 From: "Henderickx, Wim (Wim)" To: Giles Heron , "l2vpn@ietf.org" Date: Wed, 19 Dec 2012 20:56:30 +0100 Subject: Re: WG Last Call on draft-ietf-l2vpn-ipls Thread-Topic: WG Last Call on draft-ietf-l2vpn-ipls Thread-Index: Ac3eIvB7dC6f03YITKeZkbATjyHbjA== Message-ID: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 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: Wed, 19 Dec 2012 19:56:39 -0000 I would not support this given E_VPN is a superior solution. On 19/12/12 16:59, "Giles Heron" wrote: >This email initiates an L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-11 > >please comment to the list as to the suitability of this draft for >publication as an Informational RFC from the L2VPN WG. As always it'd be >good to hear some comments over and above the usual "Support!". Well, >given the season any comments at all would be good ;) > >this last call will close on Friday 4th January. > >Nabil & Giles From gregory.mirsky@ericsson.com Wed Dec 19 15:12: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 6C14121F8932 for ; Wed, 19 Dec 2012 15:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.254, 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 I5-gaatGhYU4 for ; Wed, 19 Dec 2012 15:12:13 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2E621F88DB for ; Wed, 19 Dec 2012 15:12:13 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBJNNjOp021124; Wed, 19 Dec 2012 17:23:46 -0600 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 18:12:11 -0500 From: Gregory Mirsky To: Giles Heron , "l2vpn@ietf.org" Subject: RE: WG Last Call on draft-ietf-l2vpn-ipls Thread-Topic: WG Last Call on draft-ietf-l2vpn-ipls Thread-Index: AQHN3gHXckNJrIR3ZEmelW3WlnfXRpggu++g Date: Wed, 19 Dec 2012 23:12:10 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11202AE69@eusaamb103.ericsson.se> References: 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.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11202AE69eusaamb103ericsso_" 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, 19 Dec 2012 23:12:14 -0000 --_000_7347100B5761DC41A166AC17F22DF11202AE69eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, would publication of the document fall into the following case (http://www.= ietf.org/iesg/informational-vs-experimental.html): * ... work that could be practiced, was developed in the IETF, has be= en dropped for some reason, but is being published for the record. That's I= nformational, unless the IESG determines that Historic status is more appro= priate. Support if that is the case and Historic status will be suggested to IESG o= r, even better, selected by the WG itself. Otherwise - do not support publication. Regards, Greg -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= iles Heron Sent: Wednesday, December 19, 2012 7:59 AM To: l2vpn@ietf.org Subject: WG Last Call on draft-ietf-l2vpn-ipls This email initiates an L2VPN WG Last Call for: http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-11 please comment to the list as to the suitability of this draft for publicat= ion as an Informational RFC from the L2VPN WG. As always it'd be good to h= ear some comments over and above the usual "Support!". Well, given the sea= son any comments at all would be good ;) this last call will close on Friday 4th January. Nabil & Giles --_000_7347100B5761DC41A166AC17F22DF11202AE69eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
would publication of the document fall into the following case (http://www.ietf.org/iesg/informational-vs-experimental.html<= /u>):
  • ... work that could be practiced, was developed in the IETF, has been d= ropped for some reason, but is being published for the record. That's Infor= mational, unless the IESG determines that Historic status is more appropria= te.
Support if that is the case and Historic status will be suggested to I= ESG or, even better, selected by the WG itself.
Otherwise - do not support publication.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf Of Giles Heron
Sent: Wednesday, December 19, 2012 7:59 AM
To: l2vpn@ietf.org
Subject: WG Last Call on draft-ietf-l2vpn-ipls
 
This email initiates an L2VPN WG Last Call for:
 
 
please comment to the list as to the suitability of this draft for pub= lication as an Informational RFC from the L2VPN WG.  As always it'd be= good to hear some comments over and above the usual "Support!".&= nbsp; Well, given the season any comments at all would be good ;)
 
this last call will close on Friday 4th January.
 
Nabil & Giles
 
 --_000_7347100B5761DC41A166AC17F22DF11202AE69eusaamb103ericsso_-- From xuxiaohu@huawei.com Wed Dec 19 18:01: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 CF0CC21F8A63 for ; Wed, 19 Dec 2012 18:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, CN_BODY_35=0.339, 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 vox0CgfuZls2 for ; Wed, 19 Dec 2012 18:01:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B94D621F8A5D for ; Wed, 19 Dec 2012 18:01: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 ANZ69993; Thu, 20 Dec 2012 02:01:40 +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; Thu, 20 Dec 2012 02:00:57 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 02:01:01 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 10:00:54 +0800 From: Xuxiaohu To: Giles Heron , "l2vpn@ietf.org" Subject: re: WG Last Call on draft-ietf-l2vpn-ipls Thread-Topic: WG Last Call on draft-ietf-l2vpn-ipls Thread-Index: AQHN3gHO9L81FFTe9UmbZWT3W2L+iJgg7I+w Date: Thu, 20 Dec 2012 02:00:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758947E@szxeml525-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] 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: Thu, 20 Dec 2012 02:01:42 -0000 DQpTdXBwb3J0IHB1YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KDQpYaWFvaHUN Cg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBHaWxlcw0KPiBIZXJvbg0KPiC3 osvNyrG85DogMjAxMsTqMTLUwjE5yNUgMjM6NTkNCj4gytW8/sjLOiBsMnZwbkBpZXRmLm9yZw0K PiDW98ziOiBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1sMnZwbi1pcGxzDQo+IA0KPiBUaGlz IGVtYWlsIGluaXRpYXRlcyBhbiBMMlZQTiBXRyBMYXN0IENhbGwgZm9yOg0KPiANCj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sMnZwbi1pcGxzLTExDQo+IA0KPiBwbGVh c2UgY29tbWVudCB0byB0aGUgbGlzdCBhcyB0byB0aGUgc3VpdGFiaWxpdHkgb2YgdGhpcyBkcmFm dCBmb3IgcHVibGljYXRpb24gYXMgYW4NCj4gSW5mb3JtYXRpb25hbCBSRkMgZnJvbSB0aGUgTDJW UE4gV0cuICBBcyBhbHdheXMgaXQnZCBiZSBnb29kIHRvIGhlYXIgc29tZQ0KPiBjb21tZW50cyBv dmVyIGFuZCBhYm92ZSB0aGUgdXN1YWwgIlN1cHBvcnQhIi4gIFdlbGwsIGdpdmVuIHRoZSBzZWFz b24gYW55DQo+IGNvbW1lbnRzIGF0IGFsbCB3b3VsZCBiZSBnb29kIDspDQo+IA0KPiB0aGlzIGxh c3QgY2FsbCB3aWxsIGNsb3NlIG9uIEZyaWRheSA0dGggSmFudWFyeS4NCj4gDQo+IE5hYmlsICYg R2lsZXMNCg== From kireeti.kompella@gmail.com Wed Dec 19 21:22: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 E6C3921F88A2 for ; Wed, 19 Dec 2012 21:22:54 -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 iOayOe7jl+Pl for ; Wed, 19 Dec 2012 21:22:54 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 64F5821F84FF for ; Wed, 19 Dec 2012 21:22:52 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id 16so2849714obc.27 for ; Wed, 19 Dec 2012 21:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:x-mailer:from:subject:date :to; bh=wPvXYUxF41Nq+iLrjb5F7qelIQwESYpjtTlwxk03cn4=; b=QVqaRXNg2m4Z4rK1y/k5YPRKukL3IZM6MPTdNxLbwkzPydF0nKsLy+sayUas5lk6gf D0IJcFcjzRi7ttuc8QiQSzv18SHRbXe01aGNLoUl9bZXR1MhtkbHXM44qxr9ASdiMEny yye6c4LdFA3htfA9GN7hXJW1UCS9SVspENMBPAtvmgCqmt0sh1ZlbDmJ7AE5/kb+VHVc MJYEcDfr+ckgX1eFcgMzZ9/clJL4P+g0pelLwZaltlGBr8EktPz5mA4k+DGa6Fod5MUW fFfXousUp13R9lC6U21H+xRjiH4lEBtWovcDHdde6DOjoDcvE7SOUpGm5pGk6Agw3fID z4XQ== X-Received: by 10.60.30.42 with SMTP id p10mr6937536oeh.59.1355980971948; Wed, 19 Dec 2012 21:22:51 -0800 (PST) Received: from [192.168.1.72] (75-37-193-116.lightspeed.lsatca.sbcglobal.net. [75.37.193.116]) by mx.google.com with ESMTPS id u1sm5211772oee.8.2012.12.19.21.22.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 21:22:50 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <2FDE4274-DC84-462C-ACBA-076D1DEF829F@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9A405) From: Kireeti Kompella Subject: Re: WG Last Call on draft-ietf-l2vpn-ipls Date: Wed, 19 Dec 2012 21:22:48 -0800 To: "Henderickx, Wim (Wim)" 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, 20 Dec 2012 05:22:55 -0000 +1 Sent from my iPad On Dec 19, 2012, at 11:56, "Henderickx, Wim (Wim)" wrote: > I would not support this given E_VPN is a superior solution. >=20 > On 19/12/12 16:59, "Giles Heron" wrote: >=20 >> This email initiates an L2VPN WG Last Call for: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-11 >>=20 >> please comment to the list as to the suitability of this draft for >> publication as an Informational RFC from the L2VPN WG. As always it'd be= >> good to hear some comments over and above the usual "Support!". Well, >> given the season any comments at all would be good ;) >>=20 >> this last call will close on Friday 4th January. >>=20 >> Nabil & Giles >=20 From agmalis@gmail.com Fri Dec 21 11:28:22 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549FD21F8814 for ; Fri, 21 Dec 2012 11:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.249, 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 5wo1L5-EZUTm for ; Fri, 21 Dec 2012 11:28:21 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id CE61321F869E for ; Fri, 21 Dec 2012 11:28:21 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so6862164ieb.11 for ; Fri, 21 Dec 2012 11:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=USy2h0RjnSuIv/iKjHHnK1utu7RRSWv0+SO8kikcSXY=; b=QNTTWT1oXbdrTsSD9V69OtANelqzqQFRtaoe7ehBI2AwdktB58RPcwIm97kgFNNK9w gfv3xoIMxEEBCimubKp6Jo+461f35Wa1kf08/fa3zJrEzGedCKVhVRNQmlIRl/AWUti2 uUye4D4ZyrHY0Y8MGjabodAsA4XYOmU67DRAjkgMX3aiqUn0mscr5R1XFh7U/D4+ZsXV ZvALX4wQBzmhkNv1oaHDQCY7mHuDkii6l3FPU/I6rlaoNYGfMATzdnjM7lLfQAPTjSiX k7r+WVCSHuONtD/29ZLX8joj79zBvQUSOA1e1IfZmOEYZjVp9B+QXyOWwoijjLduxqKr YEBQ== Received: by 10.50.178.67 with SMTP id cw3mr14624561igc.53.1356118101379; Fri, 21 Dec 2012 11:28:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.51.228 with HTTP; Fri, 21 Dec 2012 11:28:01 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 21 Dec 2012 14:28:01 -0500 Message-ID: Subject: Re: WG Last Call on draft-ietf-l2vpn-ipls To: Giles Heron Content-Type: multipart/alternative; boundary=e89a8f643896b4ca7104d161d941 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 19:28:22 -0000 --e89a8f643896b4ca7104d161d941 Content-Type: text/plain; charset=ISO-8859-1 Giles, I support publication, but I do wonder if Historic would be more appropriate at this point, unless there actually are implementations out there somewhere. Cheers, Andy On Wed, Dec 19, 2012 at 10:59 AM, Giles Heron wrote: > This email initiates an L2VPN WG Last Call for: > > http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-11 > > please comment to the list as to the suitability of this draft for > publication as an Informational RFC from the L2VPN WG. As always it'd be > good to hear some comments over and above the usual "Support!". Well, > given the season any comments at all would be good ;) > > this last call will close on Friday 4th January. > > Nabil & Giles > --e89a8f643896b4ca7104d161d941 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Giles,

I support publication, but I do wo= nder if Historic would be more appropriate at this point, unless there actu= ally are implementations out there somewhere.

Cheers,
Andy


On Wed, Dec 19, 2012 at 10:59 AM, Giles Heron <giles.heron@gmail.com<= /a>> wrote:
This email initiates an L2VPN WG Last Call f= or:

http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-11

please comment to the list as to the suitability of this draft for publicat= ion as an Informational RFC from the L2VPN WG. =A0As always it'd be goo= d to hear some comments over and above the usual "Support!". =A0W= ell, given the season any comments at all would be good ;)

this last call will close on Friday 4th January.

Nabil & Giles

--e89a8f643896b4ca7104d161d941--