From nobody Tue May 6 11:45:06 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C501A01C4; Tue, 6 May 2014 11:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzYRQCgw_xYj; Tue, 6 May 2014 11:45:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 243871A01BB; Tue, 6 May 2014 11:44:59 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 6 May 2014 18:44:54 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.235]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.235]) with mapi id 15.00.0934.000; Tue, 6 May 2014 18:44:54 +0000 From: Ronald Bonica To: "l2vpn@ietf.org" , "l3vpn@ietf.org" Subject: FW: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-03.txt Thread-Topic: New Version Notification for draft-bonica-l3vpn-orf-covering-prefixes-03.txt Thread-Index: AQHPaVqUEER+56SCQk6F+hA23NJk9Zsz445A Date: Tue, 6 May 2014 18:44:54 +0000 Message-ID: References: <20140506183844.12541.75986.idtracker@ietfa.amsl.com> In-Reply-To: <20140506183844.12541.75986.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(13464003)(189002)(199002)(377424004)(51704005)(99396002)(77982001)(80022001)(66066001)(54356999)(50986999)(4396001)(74316001)(99286001)(76176999)(79102001)(76576001)(21056001)(19580395003)(81342001)(46102001)(74502001)(81542001)(31966008)(64706001)(74662001)(101416001)(87936001)(92566001)(19580405001)(83072002)(20776003)(85852003)(83322001)(33646001)(15975445006)(76482001)(86362001)(15202345003)(2656002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/98s6cKFTW5_fOr7idFWnJAbe3Xg X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 18:45:02 -0000 UGxlYXNlIHJldmlldyBhbmQgY29tbWVudC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAwNiwgMjAxNCAyOjM5IFBNDQo+IFRv OiBIdWFqaW4gSmVuZzsgWGlhb2h1IFh1OyBZYWtvdiBSZWtodGVyOyBMdWN5IFlvbmc7IFJvbmFs ZCBCb25pY2E7IFhpYW9odQ0KPiBYdTsgTHVjeSBZb25nOyBIdWFqaW4gSmVuZzsgTHVheSBKYWxp bDsgUm9uYWxkIEJvbmljYTsgWWFrb3YgUmVraHRlcjsgS2V5dXINCj4gUGF0ZWw7IEtleXVyIFBh dGVsOyBMdWF5IEphbGlsDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtYm9uaWNhLWwzdnBuLW9yZi1jb3ZlcmluZy0NCj4gcHJlZml4ZXMtMDMudHh0DQo+IA0K PiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJvbmljYS1sM3Zwbi1vcmYtY292ZXJp bmctcHJlZml4ZXMtMDMudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg Um9uIEJvbmljYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBO YW1lOgkJZHJhZnQtYm9uaWNhLWwzdnBuLW9yZi1jb3ZlcmluZy1wcmVmaXhlcw0KPiBSZXZpc2lv bjoJMDMNCj4gVGl0bGU6CQlDb3ZlcmluZyBQcmVmaXhlcyBPdXRib3VuZCBSb3V0ZSBGaWx0ZXIg Zm9yIEJHUC00DQo+IERvY3VtZW50IGRhdGU6CTIwMTQtMDUtMDcNCj4gR3JvdXA6CQlsM3Zwbg0K PiBQYWdlczoJCTE5DQo+IFVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1ib25pY2EtbDN2cG4tb3JmLQ0KPiBjb3ZlcmluZy1wcmVmaXhlcy0w My50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJvbmljYS1sM3Zwbi1vcmYtY292ZXJpbmctDQo+IHByZWZpeGVzLw0KPiBIdG1saXpl ZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9uaWNhLWwzdnBuLW9y Zi1jb3ZlcmluZy0NCj4gcHJlZml4ZXMtMDMNCj4gRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJvbmljYS1sM3Zwbi1vcmYtY292ZXJpbmctDQo+ IHByZWZpeGVzLTAzDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgbmV3IE9SRi10eXBlLCBjYWxsZWQgdGhlICJDb3ZlcmluZyBQcmVmaXhlcw0KPiAgICBPUkYg KENQLU9SRikiLiAgQ1AtT1JGIGlzIGFwcGxpY2FibGUgaW4gVmlydHVhbCBIdWItYW5kLVNwb2tl IFZQTnMuDQo+ICAgIEl0IGFsc28gaXMgYXBwbGljYWJsZSBpbiBCR1AvTVBMUyBFdGhlcm5ldCBW UE4gKEVWUE4pIE5ldHdvcmtzLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed May 7 10:10:10 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81661A07D6; Wed, 7 May 2014 10:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmXiiAdB6QSN; Wed, 7 May 2014 10:09:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCE01A07D1; Wed, 7 May 2014 10:09:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-evpn-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507170955.4126.17527.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 10:09:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/suCUIbo6bVt4c0SXD4a55DnC1Xo Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 17:10:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : BGP MPLS Based Ethernet VPN Authors : Ali Sajassi Rahul Aggarwal Nabil Bitar Aldrin Isaac James Uttaro Filename : draft-ietf-l2vpn-evpn-07.txt Pages : 50 Date : 2014-05-07 Abstract: This document describes procedures for BGP MPLS based Ethernet VPNs (EVPN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-evpn-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 9 06:01:57 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15CF1A02A2 for ; Fri, 9 May 2014 06:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISIDJNkkcl2L for ; Fri, 9 May 2014 06:01:54 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7E21A029E for ; Fri, 9 May 2014 06:01:54 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so4109473qaq.31 for ; Fri, 09 May 2014 06:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=AaHv7UBe45Ek+Lb3eOyk7yujQYEXUxFVAs8nApp0g9Q=; b=aG74CnoJDYb6rMdtib4yN1P76hcH2Drnaqubbam6UHLAphQtmPDPvtoU06tNm78Tbh FXnkRUBlxL6kxWpsQk440G1iDalICvhcATIipr3ijurKRnZqDBklAClsrtMeqqpDMoqo v10BCjKknDBWdhh7dSo0XGG5HCz669R9TH+uszJQlT2yAwMqAnaadooN/weEDbtCsXNq CWS1h2shbI00XtJgDoGTJynJVVabjNy+sIjJKW29mo8N9wPsycFtShu//gjZhRx7DsRo ScPwM2i/3RcSjOphcs4Q959eFSlo5CX3x6DzltuYqlcxstpp0Fi1J7Je718liYd+B0Vz zh0w== X-Received: by 10.224.19.131 with SMTP id a3mr14051052qab.3.1399640509073; Fri, 09 May 2014 06:01:49 -0700 (PDT) Received: from dhcp-lon06-vla300-10-148-88-243.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id c10sm6513199qad.41.2014.05.09.06.01.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 May 2014 06:01:48 -0700 (PDT) From: Giles Heron Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: WG LC for draft-ietf-l2vpn-evpn-07 Message-Id: Date: Fri, 9 May 2014 14:01:45 +0100 To: "l2vpn@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/lueXPR4YSAzYTM2cGKXtGJcYZnY X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 13:01:56 -0000 This email initiates an IETF L2VPN WG Last Call for: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 please comment to the list as to the suitability of this draft for = publication as a Standards Track RFC from the L2VPN WG. this last call will close on Friday 23rd May 2014. Nabil & Giles= From nobody Fri May 9 08:05:50 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF1F1A0015 for ; Fri, 9 May 2014 08:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8kLLl2AmPcb for ; Fri, 9 May 2014 08:05:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 93F651A0010 for ; Fri, 9 May 2014 08:05:45 -0700 (PDT) Received: from BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) by BLUPR05MB594.namprd05.prod.outlook.com (10.141.203.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 15:05:39 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 9 May 2014 15:05:38 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0934.000; Fri, 9 May 2014 15:05:38 +0000 From: John E Drake To: Giles Heron , "l2vpn@ietf.org" Subject: RE: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4bwHmd7R5W6iEqNhfbqA7/6rps4WPDg Date: Fri, 9 May 2014 15:05:38 +0000 Message-ID: <9ee4831b644b4085bf9090f6ffc51b2c@BLUPR05MB562.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(13464003)(51704005)(377454003)(15975445006)(85852003)(83072002)(2656002)(79102001)(87936001)(31966008)(74662001)(74502001)(74316001)(81542001)(92566001)(76176999)(81342001)(101416001)(99286001)(50986999)(54356999)(77096999)(64706001)(21056001)(76482001)(76576001)(33646001)(19580395003)(20776003)(83322001)(19580405001)(77982001)(66066001)(46102001)(86362001)(15202345003)(4396001)(80022001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB561; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/lsdi4Yyv-9wJGa1w4s9EHCObH34 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:05:48 -0000 Nabil & Giles, The draft is suitable for publication. Yours Irrespectively, John > -----Original Message----- > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron > Sent: Friday, May 09, 2014 6:02 AM > To: l2vpn@ietf.org > Subject: WG LC for draft-ietf-l2vpn-evpn-07 >=20 > This email initiates an IETF L2VPN WG Last Call for: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >=20 > please comment to the list as to the suitability of this draft for public= ation as a > Standards Track RFC from the L2VPN WG. >=20 > this last call will close on Friday 23rd May 2014. >=20 > Nabil & Giles From nobody Fri May 9 08:12:08 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2621A0043 for ; Fri, 9 May 2014 08:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRWWrjPhxE8s for ; Fri, 9 May 2014 08:11:51 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1CABA1A02ED for ; Fri, 9 May 2014 08:11:02 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s49FAtIU000961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 May 2014 10:10:56 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s49FAsdp030484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 17:10:54 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.14]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 9 May 2014 17:10:54 +0200 From: "Henderickx, Wim (Wim)" To: Giles Heron , "l2vpn@ietf.org" Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4bd/EEuY+yR+Ue9XpTq7Iileps4WrAA Date: Fri, 9 May 2014 15:10:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D49889BB8B6214C82456C4E20310705@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/bsoL_l-xoyQGR5DspRDpkm7FqYU X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:11:57 -0000 I believe it is ready for publication. On 09/05/14 15:01, "Giles Heron" wrote: >This email initiates an IETF L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >please comment to the list as to the suitability of this draft for >publication as a Standards Track RFC from the L2VPN WG. > >this last call will close on Friday 23rd May 2014. > >Nabil & Giles From nobody Fri May 9 08:17:47 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEDF1A0296 for ; Fri, 9 May 2014 08:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7s12YF1kG_Z for ; Fri, 9 May 2014 08:17:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6771A002D for ; Fri, 9 May 2014 08:17:43 -0700 (PDT) Received: from DM2PR05CA007.namprd05.prod.outlook.com (10.141.96.27) by DM2PR05MB398.namprd05.prod.outlook.com (10.141.102.26) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 15:17:37 +0000 Received: from BY2FFO11FD006.protection.gbl (2a01:111:f400:7c0c::140) by DM2PR05CA007.outlook.office365.com (2a01:111:e400:2428::27) with Microsoft SMTP Server (TLS) id 15.0.939.12 via Frontend Transport; Fri, 9 May 2014 15:17:36 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.939.9 via Frontend Transport; Fri, 9 May 2014 15:17:35 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 9 May 2014 08:17:35 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s49FHXL53524; Fri, 9 May 2014 08:17:34 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201405091517.s49FHXL53524@magenta.juniper.net> To: "Henderickx, Wim (Wim)" Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 In-Reply-To: References: X-MH-In-Reply-To: "Henderickx, Wim (Wim)" message dated "Fri, 09 May 2014 15:10:53 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70702.1399648653.1@juniper.net> Date: Fri, 9 May 2014 08:17:33 -0700 From: Yakov Rekhter X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(479174003)(24454002)(189002)(199002)(51704005)(50986999)(20776003)(80022001)(54356999)(47776003)(76176999)(77096999)(64706001)(23726002)(2009001)(50466002)(83072002)(81542001)(81342001)(85852003)(31966008)(74502001)(46406003)(86362001)(79102001)(4396001)(44976005)(46102001)(77982001)(6806004)(76482001)(84676001)(92566001)(16796002)(92726001)(74662001)(81156002)(19580395003)(19580405001)(83322001)(69596002)(97756001)(21056001)(87936001)(68736004)(97736001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB398; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Forefront-PRVS: 02065A9E77 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=yakov@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/gdcvOl5n5EMrj-nYPrbm92upBTM Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:17:45 -0000 +1 Yakov. > I believe it is ready for publication. > > On 09/05/14 15:01, "Giles Heron" wrote: > > >This email initiates an IETF L2VPN WG Last Call for: > > > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > > > >please comment to the list as to the suitability of this draft for > >publication as a Standards Track RFC from the L2VPN WG. > > > >this last call will close on Friday 23rd May 2014. > > > >Nabil & Giles > > From nobody Fri May 9 08:21:06 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCEE1A000D for ; Fri, 9 May 2014 08:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTXl_rTUFC4t for ; Fri, 9 May 2014 08:20:58 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 36E6B1A000F for ; Fri, 9 May 2014 08:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=600; q=dns/txt; s=iport; t=1399648853; x=1400858453; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jAfz5MsHq9lsxG0IrIJ8pFcn8uCVmDlrV7B6Y8sxdzM=; b=JOtYmGKZxURdAcNbuE89pwlHLrSrcEFwcHRSI9D6qCkOhu5JUR3QSIiZ o3PU0Qcnb7CB5813JAxGqLsislv9ZPjBqVLHbrQBprvrmERdk36R/kKPI hru3FCo0JLD2oL4zakD7usb9nH6zbyCfBvTerqj0SFvHT0qPGhsMSHUjd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkIAAfxbFOtJA2G/2dsb2JhbABZgwZPWKsdCwEBAQEBAQUBmhgBgRcWdIIlAQEBBB0dPxIBCBgeMRElAgQOBYgtAxENymQNhh8XhVaGZYE1EQFQB4RABJdVgXKBPItihWSDNoF2OQ X-IronPort-AV: E=Sophos;i="4.97,1018,1389744000"; d="scan'208";a="42492756" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 09 May 2014 15:20:53 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s49FKr7Y000796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 15:20:53 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 9 May 2014 10:20:52 -0500 From: "Keyur Patel (keyupate)" To: Yakov Rekhter , "Henderickx, Wim (Wim)" Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa5nXj1brqW5hmEKRbMgx+5Y3EJs4Pn0A Date: Fri, 9 May 2014 15:20:52 +0000 Message-ID: In-Reply-To: <201405091517.s49FHXL53524@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.66.246] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/qjEu1ESCx0x38RhK5h2nyOHHxiE Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:21:00 -0000 +1. Regards, Keyur On 5/9/14 8:17 AM, "Yakov Rekhter" wrote: >+1 > >Yakov. > >> I believe it is ready for publication. >>=20 >> On 09/05/14 15:01, "Giles Heron" wrote: >>=20 >> >This email initiates an IETF L2VPN WG Last Call for: >> > >> >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >> > >> >please comment to the list as to the suitability of this draft for >> >publication as a Standards Track RFC from the L2VPN WG. >> > >> >this last call will close on Friday 23rd May 2014. >> > >> >Nabil & Giles >>=20 >>=20 > From nobody Fri May 9 08:22:28 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06A01A0013 for ; Fri, 9 May 2014 08:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTvTb9kW1NRX for ; Fri, 9 May 2014 08:22:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0475C1A000D for ; Fri, 9 May 2014 08:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=826; q=dns/txt; s=iport; t=1399648935; x=1400858535; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=kOxVEwtrhAeegwBim9PX1H+u52yPx2NJYWyXDML6KDs=; b=MEhx8r9QU0Z7ONnmlM9z6YXRofW/PaqLvPAluUFHjyG++pQE+O1op7Ou mKAUb+pAlcR+eICtw4Fusd+md+FygWhEkZ+YhM9RmCfqxsv+B7HJmFwLJ 4OjoEAw5Ll/sZjVff/2E433VCMw1ynzO1ALWwrCkfP7K3NjBhLF7xlsDJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAGDybFOtJV2Y/2dsb2JhbABZgmUhT1jFTAGBFxZ0giwdHToXAQg2MRElAgQBEogtAxEBDMpqDYYfF4w7gTURAVeEQASXVYFygTyLYoVkgzaBdjk X-IronPort-AV: E=Sophos;i="4.97,1018,1389744000"; d="scan'208";a="323701454" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 09 May 2014 15:22:15 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s49FMEWb012994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 15:22:14 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 9 May 2014 10:22:14 -0500 From: "Ali Sajassi (sajassi)" To: Giles Heron , "l2vpn@ietf.org" Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4bfKww+zA7e20SY4lQkWXSUDps4PFKA Date: Fri, 9 May 2014 15:22:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.155.156.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/DTWC90VeHbl2r6YncIdC7okRoW8 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:22:25 -0000 Giles, Thanks very much for the detailed review of this draft in preparation for the WG LC. I have received half a dozen rounds of comments from you with well over 100 comments in total and some of those comments took several rounds of emails to resolve. As the result of this process, we believe this draft is in better shape and thus helping us with the next stage of AD review after this WG LC is completed. Cheers, Ali On 5/9/14 6:01 AM, "Giles Heron" wrote: >This email initiates an IETF L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >please comment to the list as to the suitability of this draft for >publication as a Standards Track RFC from the L2VPN WG. > >this last call will close on Friday 23rd May 2014. > >Nabil & Giles From nobody Fri May 9 08:23:33 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EBD1A001A for ; Fri, 9 May 2014 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F4U4kMKmjSM for ; Fri, 9 May 2014 08:23:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D08771A0018 for ; Fri, 9 May 2014 08:23:27 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-0b-536ca3cd3d8d Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A7.45.07420.DC3AC635; Fri, 9 May 2014 11:45:49 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 9 May 2014 11:23:22 -0400 From: Jeff Tantsura To: Giles Heron Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4bn0IRJ+GhLoEmh3eiqY0Z/dJs4Xiv+ Date: Fri, 9 May 2014 15:23:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXRPiO7ZxTnBBjumqFk8PTqD0eLxt0Ps DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGv7uXWAt+Mlcsn7yCqYFxInMXIyeHhICJ xMnzu6FsMYkL99azdTFycQgJHGWUuH9kGwuEs4xR4untNWwgVWwCBhL/vx1nAbFFBNQlOuZs YwKxmQVUJVo27WMEsYUF9CVeT3kMFOcAqjGQ+Lc9BqLcSKLv6SKwMIuAisS7y7kgYV4Be4lD O7vApggJ2Eg0Lt4GNp1TwFbi3MS7YBMZgW77fmoN1CZxiVtP5jNB3CwgsWTPeaj7RSVePv7H ClGjI7Fg9yc2CFtbYtnC18wQuwQlTs58wjKBUXQWklGzkLTMQtIyC0nLAkaWVYwcpcWpZbnp RgabGIGxcEyCTXcH456XlocYBTgYlXh4F4RmBwuxJpYVV+YeYpTmYFES5y34EhssJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgVFw913hk4e+2+yKkV/y5Cd3wudEsZt3qjTDIr6qb1jO0fWl Z83mFDnxFrE4p+OhUhN0kjPbcu+cnrrpIX+r5/K+6xLZvDxbeDKnPDydsW5r1+2wgptnX4Wu WH50yZKHy7asyb2tIdtiWFXrMn3rl8AHPqtaNY4fE/yuvqX/z8VbtzcFXtCL2+yixFKckWio xVxUnAgAqf/5dGYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/pb7h5_MGhyKLijamMZmYNEeQiNE Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:23:30 -0000 Hi, This draft is suitable and very welcome for publication.=20 Regards, Jeff > On May 9, 2014, at 6:02 AM, "Giles Heron" wrote: >=20 > This email initiates an IETF L2VPN WG Last Call for: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >=20 > please comment to the list as to the suitability of this draft for public= ation as a Standards Track RFC from the L2VPN WG. >=20 > this last call will close on Friday 23rd May 2014. >=20 > Nabil & Giles From nobody Fri May 9 08:47:28 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22A01A02C4 for ; Fri, 9 May 2014 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PUW2-QCPFkV for ; Fri, 9 May 2014 08:47:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 817EB1A02F0 for ; Fri, 9 May 2014 08:47:01 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by BN1PR05MB218.namprd05.prod.outlook.com (10.255.206.20) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 15:46:55 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.25]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.25]) with mapi id 15.00.0939.000; Fri, 9 May 2014 15:46:53 +0000 From: Ronald Bonica To: "Keyur Patel (keyupate)" , Yakov Rekhter , "Henderickx, Wim (Wim)" Subject: RE: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa5oD+EfXzPiqjkiZUuZ2n5hNGps4XVMAgAAHOiA= Date: Fri, 9 May 2014 15:46:52 +0000 Message-ID: References: <201405091517.s49FHXL53524@magenta.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(377454003)(51704005)(479174003)(189002)(199002)(64706001)(81542001)(81342001)(33646001)(46102001)(20776003)(99286001)(2656002)(87936001)(66066001)(77982001)(80022001)(79102001)(4396001)(74662001)(74502001)(31966008)(76576001)(76482001)(19580405001)(76176999)(85852003)(101416001)(1941001)(74316001)(92566001)(21056001)(54356999)(19580395003)(50986999)(83322001)(83072002)(86362001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB218; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/GL9_Kxqvvc92AB33oobK95a9S0o Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:47:23 -0000 +1 > -----Original Message----- > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Keyur Patel > (keyupate) > Sent: Friday, May 09, 2014 11:21 AM > To: Yakov Rekhter; Henderickx, Wim (Wim) > Cc: l2vpn@ietf.org > Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 >=20 > +1. >=20 > Regards, > Keyur >=20 > On 5/9/14 8:17 AM, "Yakov Rekhter" wrote: >=20 > >+1 > > > >Yakov. > > > >> I believe it is ready for publication. > >> > >> On 09/05/14 15:01, "Giles Heron" wrote: > >> > >> >This email initiates an IETF L2VPN WG Last Call for: > >> > > >> >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >> > > >> >please comment to the list as to the suitability of this draft for > >> >publication as a Standards Track RFC from the L2VPN WG. > >> > > >> >this last call will close on Friday 23rd May 2014. > >> > > >> >Nabil & Giles > >> > >> > > From nobody Fri May 9 10:01:32 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13CE1A008A for ; Fri, 9 May 2014 10:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI3uk9DGWqCe for ; Fri, 9 May 2014 10:01:30 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 011211A0086 for ; Fri, 9 May 2014 10:01:29 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 5e90d635.2b6cfc626940.498007.00-2454.1354811.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 09 May 2014 17:01:25 +0000 (UTC) X-MXL-Hash: 536d09e552b02b84-1ebe7f9b3b669b667799d7394a43f28bc2b15881 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 4c90d635.0.497498.00-2250.1353341.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 09 May 2014 17:00:53 +0000 (UTC) X-MXL-Hash: 536d09c563f6fd7d-65fda0ecbc656b88d7eed70e54b581918fade365 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s49H0pSg024343; Fri, 9 May 2014 13:00:52 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s49H0eTa022044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2014 13:00:44 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 9 May 2014 17:00:27 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0174.001; Fri, 9 May 2014 13:00:26 -0400 From: "UTTARO, JAMES" To: "'Keyur Patel (keyupate)'" , "'Yakov Rekhter'" , "'Henderickx, Wim (Wim)'" Subject: RE: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa5nYBlXkIMC/O0qdxHPW/qz/k5s4oGEA///Yt3A= Date: Fri, 9 May 2014 17:00:23 +0000 Message-ID: References: <201405091517.s49FHXL53524@magenta.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=SapAgItu c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=GldK7Gj4gv8A:10 a=ofMgfj31e3cA:10 a=lB4lNuC3LbQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=pGLkceISAAAA:8 ] X-AnalysisOut: [a=R4fB4xaYi3j5bD0DgTkA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:] X-AnalysisOut: [10 a=peF9eE_zjQwA:10 a=MSl-tDqOz04A:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014050601)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/m3VcEM6zaHObx7SrG1N7gPiR2g0 Cc: "'l2vpn@ietf.org'" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 17:01:31 -0000 +1 Jim Uttaro -----Original Message----- From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Keyur Patel (keyup= ate) Sent: Friday, May 09, 2014 11:21 AM To: Yakov Rekhter; Henderickx, Wim (Wim) Cc: l2vpn@ietf.org Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07=20 +1. Regards, Keyur On 5/9/14 8:17 AM, "Yakov Rekhter" wrote: >+1 > >Yakov. > >> I believe it is ready for publication. >>=20 >> On 09/05/14 15:01, "Giles Heron" wrote: >>=20 >> >This email initiates an IETF L2VPN WG Last Call for: >> > >> >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >> > >> >please comment to the list as to the suitability of this draft for >> >publication as a Standards Track RFC from the L2VPN WG. >> > >> >this last call will close on Friday 23rd May 2014. >> > >> >Nabil & Giles >>=20 >>=20 > From nobody Fri May 9 10:12:18 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8BE1A008F for ; Fri, 9 May 2014 10:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCGiqjUpIPCT for ; Fri, 9 May 2014 10:12:14 -0700 (PDT) Received: from atl4mhob16.myregisteredsite.com (atl4mhob16.myregisteredsite.com [209.17.115.109]) by ietfa.amsl.com (Postfix) with ESMTP id 1953E1A0306 for ; Fri, 9 May 2014 10:12:13 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob16.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s49HBwCl026726 for ; Fri, 9 May 2014 13:11:58 -0400 Received: (qmail 8330 invoked by uid 0); 9 May 2014 17:11:55 -0000 X-TCPREMOTEIP: 96.241.221.83 X-Authenticated-UID: william.zayas@fibercrossing.net Received: from unknown (HELO ?192.168.1.3?) (william.zayas@fibercrossing.net@96.241.221.83) by 0 with ESMTPA; 9 May 2014 17:11:55 -0000 Date: Fri, 09 May 2014 13:11:53 -0400 Subject: RE: WG LC for draft-ietf-l2vpn-evpn-07 Message-ID: <67vdgo9on08dfywt80ni2uop.1399655513126@email.android.com> Importance: normal From: William Zayas To: "UTTARO, JAMES" , "'Keyur Patel (keyupate)'" , "'Yakov Rekhter'" , "'Henderickx, Wim (Wim)'" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_4294763572167940" Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/hWWI5nk7Lw7EbeUubz9axLjgR-o Cc: "'l2vpn@ietf.org'" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 17:12:15 -0000 ----_com.android.email_4294763572167940 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KzEKCkNoZWVycwoKQmlsbAoKPGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0t PC9kaXY+PGRpdj5Gcm9tOiAiVVRUQVJPLCBKQU1FUyIgPGp1MTczOEBhdHQuY29tPiA8L2Rpdj48 ZGl2PkRhdGU6MDUvMDkvMjAxNCAgMTowMCBQTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5Ubzog IidLZXl1ciBQYXRlbCAoa2V5dXBhdGUpJyIgPGtleXVwYXRlQGNpc2NvLmNvbT4sJ1lha292IFJl a2h0ZXInIDx5YWtvdkBqdW5pcGVyLm5ldD4sIidIZW5kZXJpY2t4LCBXaW0gKFdpbSknIiA8d2lt LmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPiA8L2Rpdj48ZGl2PkNjOiAiJ2wydnBuQGll dGYub3JnJyIgPGwydnBuQGlldGYub3JnPiA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJFOiBXRyBMQyBm b3IgZHJhZnQtaWV0Zi1sMnZwbi1ldnBuLTA3IDwvZGl2PjxkaXY+CjwvZGl2PisxCgpKaW0gVXR0 YXJvCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBMMnZwbiBbbWFpbHRvOmwydnBu LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZXl1ciBQYXRlbCAoa2V5dXBhdGUpClNl bnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDExOjIxIEFNClRvOiBZYWtvdiBSZWtodGVyOyBIZW5k ZXJpY2t4LCBXaW0gKFdpbSkKQ2M6IGwydnBuQGlldGYub3JnClN1YmplY3Q6IFJlOiBXRyBMQyBm b3IgZHJhZnQtaWV0Zi1sMnZwbi1ldnBuLTA3IAoKKzEuCgpSZWdhcmRzLApLZXl1cgoKT24gNS85 LzE0IDg6MTcgQU0sICJZYWtvdiBSZWtodGVyIiA8eWFrb3ZAanVuaXBlci5uZXQ+IHdyb3RlOgoK PisxCj4KPllha292Lgo+Cj4+IEkgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24u Cj4+IAo+PiBPbiAwOS8wNS8xNCAxNTowMSwgIkdpbGVzIEhlcm9uIiA8Z2lsZXMuaGVyb25AZ21h aWwuY29tPiB3cm90ZToKPj4gCj4+ID5UaGlzIGVtYWlsIGluaXRpYXRlcyBhbiBJRVRGIEwyVlBO IFdHIExhc3QgQ2FsbCBmb3I6Cj4+ID4KPj4gPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbDJ2cG4tZXZwbi0wNwo+PiA+Cj4+ID5wbGVhc2UgY29tbWVudCB0byB0aGUgbGlz dCBhcyB0byB0aGUgc3VpdGFiaWxpdHkgb2YgdGhpcyBkcmFmdCBmb3IKPj4gPnB1YmxpY2F0aW9u IGFzIGEgU3RhbmRhcmRzIFRyYWNrIFJGQyBmcm9tIHRoZSBMMlZQTiBXRy4KPj4gPgo+PiA+dGhp cyBsYXN0IGNhbGwgd2lsbCBjbG9zZSBvbiBGcmlkYXkgMjNyZCBNYXkgMjAxNC4KPj4gPgo+PiA+ TmFiaWwgJiBHaWxlcwo+PiAKPj4gCj4KCgo= ----_com.android.email_4294763572167940 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+KzE8ZGl2Pjxicj48L2Rpdj48ZGl2 PkNoZWVyczwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QmlsbDwvZGl2Pjxicj48YnI+PGRpdj4t LS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiAiVVRUQVJP LCBKQU1FUyIgPGp1MTczOEBhdHQuY29tPiA8L2Rpdj48ZGl2PkRhdGU6MDUvMDkvMjAxNCAgMTow MCBQTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5UbzogIidLZXl1ciBQYXRlbCAoa2V5dXBhdGUp JyIgPGtleXVwYXRlQGNpc2NvLmNvbT4sJ1lha292IFJla2h0ZXInIDx5YWtvdkBqdW5pcGVyLm5l dD4sIidIZW5kZXJpY2t4LCBXaW0gKFdpbSknIiA8d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNl bnQuY29tPiA8L2Rpdj48ZGl2PkNjOiAiJ2wydnBuQGlldGYub3JnJyIgPGwydnBuQGlldGYub3Jn PiA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJFOiBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1sMnZwbi1ldnBu LTA3IDwvZGl2PjxkaXY+PGJyPjwvZGl2PisxPGJyPjxicj5KaW0gVXR0YXJvPGJyPjxicj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiBMMnZwbiBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZXl1ciBQYXRlbCAoa2V5dXBhdGUpPGJyPlNlbnQ6 IEZyaWRheSwgTWF5IDA5LCAyMDE0IDExOjIxIEFNPGJyPlRvOiBZYWtvdiBSZWtodGVyOyBIZW5k ZXJpY2t4LCBXaW0gKFdpbSk8YnI+Q2M6IGwydnBuQGlldGYub3JnPGJyPlN1YmplY3Q6IFJlOiBX RyBMQyBmb3IgZHJhZnQtaWV0Zi1sMnZwbi1ldnBuLTA3IDxicj48YnI+KzEuPGJyPjxicj5SZWdh cmRzLDxicj5LZXl1cjxicj48YnI+T24gNS85LzE0IDg6MTcgQU0sICJZYWtvdiBSZWtodGVyIiAm bHQ7eWFrb3ZAanVuaXBlci5uZXQmZ3Q7IHdyb3RlOjxicj48YnI+Jmd0OysxPGJyPiZndDs8YnI+ Jmd0O1lha292Ljxicj4mZ3Q7PGJyPiZndDsmZ3Q7IEkgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3Ig cHVibGljYXRpb24uPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7Jmd0OyBPbiAwOS8wNS8xNCAxNTowMSwg IkdpbGVzIEhlcm9uIiAmbHQ7Z2lsZXMuaGVyb25AZ21haWwuY29tJmd0OyB3cm90ZTo8YnI+Jmd0 OyZndDsgPGJyPiZndDsmZ3Q7ICZndDtUaGlzIGVtYWlsIGluaXRpYXRlcyBhbiBJRVRGIEwyVlBO IFdHIExhc3QgQ2FsbCBmb3I6PGJyPiZndDsmZ3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0O2h0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbDJ2cG4tZXZwbi0wNzxicj4mZ3Q7Jmd0 OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDtwbGVhc2UgY29tbWVudCB0byB0aGUgbGlzdCBhcyB0byB0 aGUgc3VpdGFiaWxpdHkgb2YgdGhpcyBkcmFmdCBmb3I8YnI+Jmd0OyZndDsgJmd0O3B1YmxpY2F0 aW9uIGFzIGEgU3RhbmRhcmRzIFRyYWNrIFJGQyBmcm9tIHRoZSBMMlZQTiBXRy48YnI+Jmd0OyZn dDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7dGhpcyBsYXN0IGNhbGwgd2lsbCBjbG9zZSBvbiBGcmlk YXkgMjNyZCBNYXkgMjAxNC48YnI+Jmd0OyZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7TmFiaWwg JmFtcDsgR2lsZXM8YnI+Jmd0OyZndDsgPGJyPiZndDsmZ3Q7IDxicj4mZ3Q7PGJyPjxicj48YnI+ PC9ib2R5Pg== ----_com.android.email_4294763572167940-- From nobody Fri May 9 11:20:46 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D4B1A00A3 for ; Fri, 9 May 2014 11:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zP6E_a5T8Vl for ; Fri, 9 May 2014 11:20:44 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB7AB1A0078 for ; Fri, 9 May 2014 11:20:43 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-99-536ccd57125c Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CB.4F.07420.75DCC635; Fri, 9 May 2014 14:43:04 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Fri, 9 May 2014 14:20:38 -0400 From: Gregory Mirsky To: Giles Heron , "l2vpn@ietf.org" Subject: RE: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4bny49s3NKadEmxDa7vPlQm1ps4j0Zg Date: Fri, 9 May 2014 18:20:38 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ACD08@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.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXRPuG7E2Zxgg+Y/zBZPj85gtHj87RC7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUxZcdq9oIDLBXLbzcyNzBeZO5i5OSQEDCR uHhuFwuELSZx4d56ti5GLg4hgaOMEhevfGOEcJYxSnw9OIcRpIpNwEjixcYedhBbRMBL4ub/ e2BxYQF9iUlbrwJN4gCKG0j82x4DUWIkceFLExOIzSKgInG19xAbiM0r4Ctx/PBzsMVCAjYS jYu3gdmcArYS5ybeBRvJCHTQ91NrwHqZBcQlbj2ZzwRxqIDEkj3noR4QlXj5+B8rhK0kMWnp OVaIeh2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxi5CgtTi3L TTcy2MQIjIZjEmy6Oxj3vLQ8xCjAwajEw6uwPCdYiDWxrLgy9xCjNAeLkjhvwZfYYCGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MS0LyzvAsfz/zqtvHTm3hPLuHy3Qrl5zMNxRdEH9AIE+u 84x75/YdjvVXbpVa20n29cnq8KawMa/WYqrdEjBJ1fJ86mbh/XM3/ouONy1gd930zP1GfHDu y/rsPYpxBtdnPv5awO/ZY3lwiuSnbUuuK7dWSYjPOt138ehCZ6c/jY0qjtYn1aYrsRRnJBpq MRcVJwIAFwMIyGcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/5yng3ahl4-gttEdKChkC4AZjtAY X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 18:20:45 -0000 Stable, concise and much needed document. Regards, Greg -----Original Message----- From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron Sent: Friday, May 09, 2014 6:02 AM To: l2vpn@ietf.org Subject: WG LC for draft-ietf-l2vpn-evpn-07 This email initiates an IETF L2VPN WG Last Call for: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 please comment to the list as to the suitability of this draft for publicat= ion as a Standards Track RFC from the L2VPN WG. this last call will close on Friday 23rd May 2014. Nabil & Giles From nobody Fri May 9 11:22:47 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785691A0306 for ; Fri, 9 May 2014 11:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-1YMcPUrx2U for ; Fri, 9 May 2014 11:22:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ACF021A02D9 for ; Fri, 9 May 2014 11:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=411; q=dns/txt; s=iport; t=1399659759; x=1400869359; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4DLDG9cpiX/wjt8qwVxgYfFzSY+zTerYIrixTzq3NHQ=; b=BHW/sGKfgS/BdlP5o0B7twGcv5DpVdufGdeb4V5XOW6yZ/IdzH3bFZSv MgwlAOKVzDO3zKFS1WwOdzeDisnsPQHlT9irB+fhuarZ3EVqgj6we6Btd doNLnMKWBVX+V/5iXnaalTXHZmevwYnNPIO+1eoalQsbbY1/hvXxDj9WD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJYcbVOtJA2L/2dsb2JhbABZgwZPWMVMAYEZFnSCJgEBBB0dTwIBCDYQIRElAgQTiC0DEQ3Kaw2GHxeMO4E1EQFXhEAEl1WBcoE8i2KFZIM2gXY5 X-IronPort-AV: E=Sophos;i="4.97,1019,1389744000"; d="scan'208";a="323687069" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 09 May 2014 18:22:33 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s49IMWU4023052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 9 May 2014 18:22:33 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.162]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 9 May 2014 13:22:32 -0500 From: "Satya Mohanty (satyamoh)" To: "l2vpn@ietf.org" Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4bfoL+txGZ2sUy7imI+D4bdFJs4brKA Date: Fri, 9 May 2014 18:21:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.212.245] Content-Type: text/plain; charset="us-ascii" Content-ID: <8EF503EB010F27498F50297FDE0B2303@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/q8dYBzsTR74XO1YjcyurR4JWh9U X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 18:22:45 -0000 +1 Regards, --Satya On 5/9/14 6:01 AM, "Giles Heron" wrote: >This email initiates an IETF L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >please comment to the list as to the suitability of this draft for >publication as a Standards Track RFC from the L2VPN WG. > >this last call will close on Friday 23rd May 2014. > >Nabil & Giles From nobody Fri May 9 11:26:17 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6D81A0099 for ; Fri, 9 May 2014 11:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2Gh73J1Z6bJ for ; Fri, 9 May 2014 11:26:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A7F411A0078 for ; Fri, 9 May 2014 11:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=395; q=dns/txt; s=iport; t=1399659969; x=1400869569; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PMwpQJjBM6tx+1UHe00IIWMi/WdZdEmak7ZXF/ChczI=; b=iYwbPwQPlwJJdiMb+jVJH22lHhLZRI2+/1+6Q1c7s+4m14+nB0x+Vpvh 1MDB7x2aSP+daaNgyD5NNMwPpgzk3rtud7kW+dxg3AvTeCYE6R+4S1yXe CRQ/YujQAezQIO6Wv0C0Sjg2N8LjquT2G4vqD5hKTtBiwD/N4jVKDGBFD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkIAA8dbVOtJV2R/2dsb2JhbABZgwZPWKsdCwEBAQEBAQUBmhgBgRkWdIImAQEEHR1PAgEINhAhESUCBAESiC0DEQ3Kbg2GHxeFVoZlgTURAVeEQASXVYFygTyLYoVkgzaBdjk X-IronPort-AV: E=Sophos;i="4.97,1019,1389744000"; d="scan'208";a="42526247" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 09 May 2014 18:26:08 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s49IQ8hH019546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 18:26:08 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 9 May 2014 13:26:08 -0500 From: "Patrice Brissette (pbrisset)" To: Giles Heron , "l2vpn@ietf.org" Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4bfi1LE7rN6IEmfyc99sUbBT5s4of0A Date: Fri, 9 May 2014 18:26:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.74.50] Content-Type: text/plain; charset="us-ascii" Content-ID: <720B11B13BB1B24989769BDE4941DF8C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/bGMkVWb6AVYAXFfRIZGKVl6PCu8 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 18:26:15 -0000 +1 On 2014-05-09, 9:01 AM, "Giles Heron" wrote: >This email initiates an IETF L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >please comment to the list as to the suitability of this draft for >publication as a Standards Track RFC from the L2VPN WG. > >this last call will close on Friday 23rd May 2014. > >Nabil & Giles From nobody Sat May 10 03:12:28 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1841A0210 for ; Sat, 10 May 2014 03:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK2IUEJk1de3 for ; Sat, 10 May 2014 03:12:24 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E653D1A020E for ; Sat, 10 May 2014 03:12:23 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.54.72]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 394411802AD1; Sat, 10 May 2014 12:12:16 +0200 (CEST) Message-ID: <536DFB7F.3080601@pi.nu> Date: Sat, 10 May 2014 12:12:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Patrice Brissette (pbrisset)" , satyamoh@cisco.com Subject: What does "+1" mean - Re: WG LC for draft-ietf-l2vpn-evpn-07 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/b2ufnWVWRZSz8kaXC2isPLAvmwA Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 10:12:27 -0000 Folks, We have had two mails responding "+1" to the start of a working group last call. What does this mean, are this mails to tell us that it is really time to start a wglc? A personal reflection would be that one should avoid "+1" since it does help, say what you mean instead. BTW, this is a well-written and well-structured document, that with the exception for two dated references seems to be ready to send to the IESG with a request for publication. /Loa On 2014-05-09 20:26, Patrice Brissette (pbrisset) wrote: > +1 > > On 2014-05-09, 9:01 AM, "Giles Heron" wrote: > >> This email initiates an IETF L2VPN WG Last Call for: >> >> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >> >> please comment to the list as to the suitability of this draft for >> publication as a Standards Track RFC from the L2VPN WG. >> >> this last call will close on Friday 23rd May 2014. >> >> Nabil & Giles > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat May 10 06:18:36 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322CC1A0248 for ; Sat, 10 May 2014 06:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVruZlP7FR9p for ; Sat, 10 May 2014 06:18:32 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA461A0247 for ; Sat, 10 May 2014 06:18:32 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id s7so5223840qap.20 for ; Sat, 10 May 2014 06:18:27 -0700 (PDT) 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=Va9UBmc9U7iGVmayL7tGnzJnfuHJiB+tGRDs6XSUscc=; b=VxS+pt3fPnb/2nDy38poFtzDkm+MJS+/Lj6LQdj56vHGyEcXXHmjRpBtz9MN7yJWiW hmsSwXhndrfEZafOHPO4wpAxBsi2jvuJI3XLge/A7YrPN0LTOaXGXxR4BsYkGQfprQ9J EXjXBcGHuJYd0t/ncAlqqu4uv3VmCBoM6v8Ejq/r9EMcBkuEaH7TO1oPDEBY4aq4Ir14 594dSsWxY1ppWtdzobSdUa5tnuM1t8mlkpgTPDz8ALWkYZmZNZ5O8zQbP84cxictQagZ rvzVhZ4kSDfYyROC2aDcoZDM2a1IOrnZSh4PRBX4Lugch/58qs7PBBxSM6B0zT/wOsyx hv6Q== X-Received: by 10.140.37.135 with SMTP id r7mr21901115qgr.61.1399727907063; Sat, 10 May 2014 06:18:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.80.100 with HTTP; Sat, 10 May 2014 06:18:06 -0700 (PDT) In-Reply-To: <536DFB7F.3080601@pi.nu> References: <536DFB7F.3080601@pi.nu> From: "Andrew G. Malis" Date: Sat, 10 May 2014 09:18:06 -0400 Message-ID: Subject: Re: What does "+1" mean - Re: WG LC for draft-ietf-l2vpn-evpn-07 To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c146d0aecc5804f90b8c32 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/XwKNoyN-oRR7vrlXkuMF93pV6hs Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 13:18:34 -0000 --001a11c146d0aecc5804f90b8c32 Content-Type: text/plain; charset=UTF-8 I agree with Loa's assessment of the document. Cheers, Andy On Sat, May 10, 2014 at 6:12 AM, Loa Andersson wrote: > Folks, > > We have had two mails responding "+1" to the start of a working > group last call. What does this mean, are this mails to tell us > that it is really time to start a wglc? > > A personal reflection would be that one should avoid "+1" since > it does help, say what you mean instead. > > BTW, this is a well-written and well-structured document, that > with the exception for two dated references seems to be ready > to send to the IESG with a request for publication. > > > /Loa > > On 2014-05-09 20:26, Patrice Brissette (pbrisset) wrote: > >> +1 >> >> On 2014-05-09, 9:01 AM, "Giles Heron" wrote: >> >> This email initiates an IETF L2VPN WG Last Call for: >>> >>> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >>> >>> please comment to the list as to the suitability of this draft for >>> publication as a Standards Track RFC from the L2VPN WG. >>> >>> this last call will close on Friday 23rd May 2014. >>> >>> Nabil & Giles >>> >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > --001a11c146d0aecc5804f90b8c32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Loa's assessment of the document.
Cheers,
Andy



On Sat, May 10, 2014 at 6:1= 2 AM, Loa Andersson <loa@pi.nu> wrote:
Folks,

We have had two mails responding "+1" to the start of a working group last call. What does this mean, are this mails to tell us
that it is really time to start a wglc?

A personal reflection would be that one should avoid "+1" since it does help, say what you mean instead.

BTW, this is a well-written and well-structured document, that
with the exception for two dated references seems to be ready
to send to the IESG with a request for publication.


/Loa

On 2014-05-09 20:26, Patrice Brissette (pbrisset) wrote:
+1

On 2014-05-09, 9:01 AM, "Giles Heron" <giles.heron@gmail.com> wrote:
This email initiates an IETF L2VPN WG Last Call for:

http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07

please comment to the list as to the suitability of this draft for
publication as a Standards Track RFC from the L2VPN WG.

this last call will close on Friday 23rd May 2014.

Nabil & Giles


--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64


--001a11c146d0aecc5804f90b8c32-- From nobody Sat May 10 12:01:56 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FC51A028A for ; Sat, 10 May 2014 12:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96ju_af_5xxi for ; Sat, 10 May 2014 12:01:52 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2511A027D for ; Sat, 10 May 2014 12:01:52 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s4AJ1iih014799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 May 2014 14:01:45 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s4AJ1iPH012484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 May 2014 21:01:44 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.243]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sat, 10 May 2014 21:01:44 +0200 From: "Rabadan, Jorge (Jorge)" To: Giles Heron , "l2vpn@ietf.org" Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPbIJI5rSQglUUUEmFuKqANKyATw== Date: Sat, 10 May 2014 19:01:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <976FE0E581FA8D4781432A376E336084@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/WJxoTm_NVCWw8v2u00QRjW-tmmc X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 19:01:54 -0000 The draft is suitable for publication. Thanks. Jorge -----Original Message----- From: Giles Heron Date: Friday, May 9, 2014 at 6:01 AM To: "l2vpn@ietf.org" Subject: WG LC for draft-ietf-l2vpn-evpn-07 >This email initiates an IETF L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >please comment to the list as to the suitability of this draft for >publication as a Standards Track RFC from the L2VPN WG. > >this last call will close on Friday 23rd May 2014. > >Nabil & Giles From nobody Sun May 11 17:43:27 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDD81A03AE for ; Sun, 11 May 2014 17:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYhR4Hd-NX0Y for ; Sun, 11 May 2014 17:43:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4108A1A03AA for ; Sun, 11 May 2014 17:43:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGP96846; Mon, 12 May 2014 00:43:13 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 May 2014 01:41:41 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 May 2014 01:43:11 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.203]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 12 May 2014 08:43:04 +0800 From: "Xialiang (Frank)" To: Giles Heron Subject: RE: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4cfpFDY7qoL/kekN4XeMX0T1ps8Hv+A Date: Mon, 12 May 2014 00:43:03 +0000 Message-ID: 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.135.42.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/0tFZEpiYp1SHdKFXv5qvu03Xggg Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 00:43:25 -0000 Support for publication! B.R. Frank > -----Original Message----- > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron > Sent: Friday, May 09, 2014 9:02 PM > To: l2vpn@ietf.org > Subject: WG LC for draft-ietf-l2vpn-evpn-07 >=20 > This email initiates an IETF L2VPN WG Last Call for: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >=20 > please comment to the list as to the suitability of this draft for public= ation as > a Standards Track RFC from the L2VPN WG. >=20 > this last call will close on Friday 23rd May 2014. >=20 > Nabil & Giles From nobody Sun May 11 18:04:36 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BAD1A03AA for ; Sun, 11 May 2014 18:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcORrwUkNsXD for ; Sun, 11 May 2014 18:04:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 598001A02AE for ; Sun, 11 May 2014 18:04:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEA77834; Mon, 12 May 2014 01:04:26 +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.3.158.1; Mon, 12 May 2014 02:03:35 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 May 2014 02:04:25 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 12 May 2014 09:04:17 +0800 From: Lizhenbin To: Giles Heron , "l2vpn@ietf.org" Subject: =?gb2312?B?tPC4tDogV0cgTEMgZm9yIGRyYWZ0LWlldGYtbDJ2cG4tZXZwbi0wNw==?= Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4cfBt41gW3ZQk6uQ4SCKNSwt5s8JJUA Date: Mon, 12 May 2014 01:04:16 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D0820A4DA@nkgeml506-mbx.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.76.77] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Clovj_c-CYIc_JQxkRpgsO5perQ X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 01:04:34 -0000 SXQgdHJ1bHkgdGFrZXMgYSBsb25nIHRpbWUgdG8gYmVjb21lIHN0YWJsZS4gQW5kIG1hbnkgaW1w bGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IGF2YWlsYWJsZSBhY2NvcmRpbmcgdG8gdGhlIGRyYWZ0 LiBTdXBwb3J0IGZvciBwdWJsaWNhdGlvbi4NCg0KWmhlbmJpbihSb2JpbikNCg0KLS0tLS3Tyrz+ 1K28/i0tLS0tDQq3orz+yMs6IEwydnBuIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10g tPqx7SBHaWxlcyBIZXJvbg0Kt6LLzcqxvOQ6IDIwMTTE6jXUwjnI1SAyMTowMg0KytW8/sjLOiBs MnZwbkBpZXRmLm9yZw0K1vfM4jogV0cgTEMgZm9yIGRyYWZ0LWlldGYtbDJ2cG4tZXZwbi0wNw0K DQpUaGlzIGVtYWlsIGluaXRpYXRlcyBhbiBJRVRGIEwyVlBOIFdHIExhc3QgQ2FsbCBmb3I6DQoN Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbDJ2cG4tZXZwbi0wNw0KDQpw bGVhc2UgY29tbWVudCB0byB0aGUgbGlzdCBhcyB0byB0aGUgc3VpdGFiaWxpdHkgb2YgdGhpcyBk cmFmdCBmb3IgcHVibGljYXRpb24gYXMgYSBTdGFuZGFyZHMgVHJhY2sgUkZDIGZyb20gdGhlIEwy VlBOIFdHLg0KDQp0aGlzIGxhc3QgY2FsbCB3aWxsIGNsb3NlIG9uIEZyaWRheSAyM3JkIE1heSAy MDE0Lg0KDQpOYWJpbCAmIEdpbGVzDQo= From nobody Sun May 11 21:43:16 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245EA1A03EC for ; Sun, 11 May 2014 21:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxRFa30fiQhv for ; Sun, 11 May 2014 21:43:11 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 71D4A1A03EA for ; Sun, 11 May 2014 21:43:11 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-ac-5370021aba37 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5C.B1.07420.A1200735; Mon, 12 May 2014 01:04:58 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 12 May 2014 00:43:04 -0400 From: Jakob Heitz To: "l2vpn@ietf.org" Subject: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMzw== Date: Mon, 12 May 2014 04:43:03 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@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.12] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4Ceusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXSPn64UU0Gwwc63KhaPvx1id2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtWGxILHrhX3Np5ib2DcYtfFyMkhIWAi8Xt3HzOELSZx4d56 ti5GLg4hgaOMEgev72MDSQgJLGeU2NuaCmKzCehIfLveBdTAwSEioCqxu4ULJMwsYCbReXMy O0hYGKjkxpEEkLCIgKHEjlPPmCBsPYlNG2aDrWIB6py1YQ4jiM0r4CvRsnQzmM0IdML3U2uY IEaKS9x6Mp8J4jQBiSV7zkOdKSrx8vE/VghbSWLO62vMEPX5Ej3POtggZgpKnJz5hGUCo/As JKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAiMhWMS bLo7GPe8tDzEKMDBqMTDu2BXfrAQa2JZcWXuIUZpDhYlcd6CL7HBQgLpiSWp2ampBalF8UWl OanFhxiZODilGhgnXX2vbdzmeUXZ6IBacFqJoRa7ENP8N9JVTZ4/Ra/lX02YGPRU2lV83ezZ IfM0VhxJWS3fqJ7OFj+j6Ppc0zXPWsQzv80WWM5y33XJCzZR7+aVR2vOL197YWeVcb1W7Oz6 PUk7jiac3Wil5vfrfw9LRmLnmfkuawRf/2/Unh+3sWPafU7TClElluKMREMt5qLiRAA/xL2J ZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/-vJo8-C2khC4fKBBGRKaAGgnNeY Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 04:43:14 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4Ceusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution ... If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to "Support of this route is OPTIONAL unles= s non-reserved ESIs are used" or just be changed to MANDATORY? Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4Ceusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tony and I have an issue.

The draft says

8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route

 
 
   This section describes the procedures used to constr=
uct the Ethernet
   A-D per EVPN Instance (EVI) route, which is used for=
 aliasing (as
   discussed above). Support of this route is OPTIONAL.

 

And

 

9.2.2 Route Resolution

 

…

   If the Ethernet Segment Identifier field in a receiv=
ed MAC
   Advertisement route is set to a non-reserved ESI, th=
en if the
   receiving PE decides to install forwarding state for=
 the associated
   MAC address, it MUST be when both the MAC Advertisem=
ent route AND the
   associated set of Ethernet A-D per ES routes have be=
en received.

 

 

Should this sentence be changed to “= Support of this route is = OPTIONAL unless non-reserved ESIs are used” or just be changed to MANDATORY?

 

Thanks,

Jakob.

 

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4Ceusaamb109erics_-- From nobody Sun May 11 21:57:09 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28E1A03F1 for ; Sun, 11 May 2014 21:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwFWIbGyp96w for ; Sun, 11 May 2014 21:57:07 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0570D1A03EF for ; Sun, 11 May 2014 21:57:06 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-f1-5370055d9db3 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9B.C1.07420.D5500735; Mon, 12 May 2014 01:18:53 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Mon, 12 May 2014 00:57:00 -0400 From: Jakob Heitz To: "l2vpn@ietf.org" Subject: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48w== Date: Mon, 12 May 2014 04:56:59 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A80@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.12] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053A80eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXRPlG4sa0GwwYeLBhaPvx1id2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRt+R5ewFqy0qPj6Zy9bA+M2wi5GTQ0LARGJnbxMbhC0mceHe eiCbi0NI4CijxMObJxkhnOWMEp+bHjKCVLEJ6Eh8u97F3MXIwSEioCqxu4ULJMwsYCbReXMy O4gtLCAlcXXOA2YQW0RAXqLxx1pWCFtPYufFhWDLWIBaj26fDlbPK+Ar8ah3Glg9I9AR30+t YYKYKS5x68l8JojjBCSW7DnPDGGLSrx8/I8VwlaSmPP6GjNEfb7EybV/GCFmCkqcnPmEZQKj 8Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLU4ty003MtjECIyI YxJsujsY97y0PMQowMGoxMO7YFd+sBBrYllxZe4hRmkOFiVx3oIvscFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGBfMOWqb/yRv7im5opCl+pMkjDXsLiaLHJjPv1kr8yP3rXcnHP78+v0x OmWnzKv6/eudb+3NnDH3OKfrR09nr6+cSsoRGvwPWSNzLkTdP7JjnnZOgOihbqUfut+jVJS7 nU2kOG6mvmAQzPmhe17e/9ecPluunowPDzlmpTX5f06cm9b8YdaD+UosxRmJhlrMRcWJADry gutpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/2fhnkccouOt-Dm-Gv5-ItgFu2Dg Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 04:57:08 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053A80eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053A80eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have another issue

In section 10: ARP and ND, the draft says:=

 

  = ; If there are multiple IP addresses associated with a MAC address,

  = ; then multiple MAC advertisement routes MUST be generated, one for

  = ; each IP address. For instance, this may be the case when there are

  = ; both an IPv4 and an IPv6 address associated with the MAC address.

 = 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC
   advertisement route with that particular IP address =
MUST be
   withdrawn.

 

If such a route is withdrawn and no MAC ro= ute without IP exists, then the MAC address will be forgotten. Therefore, w= e would like to add a sentence:

 

Whenever a PE advertises one or more MAC a= dvertisement routes with IP address for a particular MAC address, it MUST a= lso advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053A80eusaamb109erics_-- From nobody Sun May 11 22:16:46 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795B31A03EF for ; Sun, 11 May 2014 22:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmBFSUcNAXyM for ; Sun, 11 May 2014 22:16:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2141A03ED for ; Sun, 11 May 2014 22:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13223; q=dns/txt; s=iport; t=1399871796; x=1401081396; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=NfoNYdEcoK7nBC+jnj/pRwC9hb2A7o+Ffk9E/v2xA5o=; b=OR7m8vDXmWWz+2HHqzatUMDGfy/x1E5k36YS1GXLPtLWW5v5ZQDSEGMn WNRIhfZvGRthxggFoMRfDf06jRGIjF1B7d6VH0raroTQiZkdTtfJlNrXs tvMMv89IDxUaBXrJSDY7r1rZapEVX0jiObIm8Qu+xxwNWhGywnbYfKvv7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAC9YcFOtJA2K/2dsb2JhbABZgkIjIU9YvGSIfgGBFxZ0giUBAgQtTBIBCBEDAQIoORQJCAEBBAENBYhBAQzNdReOQREHhEAEhXiTUIE8kUuDNm0BgUE X-IronPort-AV: E=Sophos;i="4.97,1033,1389744000"; d="scan'208,217";a="42962799" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 12 May 2014 05:16:36 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4C5GZeX007011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 05:16:36 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 12 May 2014 00:16:35 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMz///7AeA Date: Mon, 12 May 2014 05:16:35 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.66.92] Content-Type: multipart/alternative; boundary="_000_CF95A55CD37EFsajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/5jrgwySDxn6xE1B08mLvtM62n6s Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:16:44 -0000 --_000_CF95A55CD37EFsajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jakob, We are talking about two different routes. Section 8.4.1 talks about Ethern= et A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The= former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para). For rev 7, I added a clarification sentence to the end of the 3rd para of s= ection 9.2.2 saying: "The dependency of MAC routes installation on Ethernet A-D per ES ro= utes, is to ensure that MAC routes don't get accidentally installed during mass withdraw period." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:43 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: optional ethernet A-D per EVI route Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution =85 If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to =93Support of this route is OPTIONAL unl= ess non-reserved ESIs are used=94 or just be changed to MANDATORY? Thanks, Jakob. --_000_CF95A55CD37EFsajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <25066291CB4CA44E8E7F8B5C6D87F44F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Jakob,

We are talking about two different routes. Section 8.4.1 talks about E= thernet A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES= . The former one is optional but no the latter one. As the matter of fact s= ection 8.2.1 states that the support of the latter one is mandatory (1st para).

For rev 7, I added a clarification sentence to the end of the 3rd para= of section 9.2.2 saying:

       "The dependency of MAC = routes installation on Ethernet A-D per ES routes,
   is to ensure =
that MAC routes don't get accidentally installed during
   mass withdraw period."

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 9:43 PM<= br> To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: optional ethernet A-D per = EVI route

 --_000_CF95A55CD37EFsajassiciscocom_-- From nobody Sun May 11 22:34:05 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB891A03F8 for ; Sun, 11 May 2014 22:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMEtG6fZZMXH for ; Sun, 11 May 2014 22:34:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 812311A02C7 for ; Sun, 11 May 2014 22:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9926; q=dns/txt; s=iport; t=1399872836; x=1401082436; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=5L4Sg1veED+uEpJ2EzABVe8l7NqcB83fXHTjSOLRvFQ=; b=LN5ZT+E80XlSJYYHcZiE3GjiDh/3ANxaBHncLJZhwnia7Yur3xRZfmxm R4A4hmA1GnObrMEuO9w5AJ38W+zSIiTFTdH0BqecvvgvRFFByy3jMUbju HbCssR0HPzir0Kud+OXn+C6cl4Lsi2iGte27RhggWXLbUCax+919q7nxZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAKJccFOtJA2B/2dsb2JhbABZgkIjIU9YxWEBgRcWdIIlAQIELUwSAQgRAwECKDkUCQgBAQQBDQWIQQHOBxeOQREHhEAEmUiTB4M2gi8 X-IronPort-AV: E=Sophos;i="4.97,1033,1389744000"; d="scan'208,217";a="324128309" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 12 May 2014 05:33:55 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4C5XtR3007208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 05:33:55 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.03.0123.003; Mon, 12 May 2014 00:33:55 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA Date: Mon, 12 May 2014 05:33:54 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A80@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.66.92] Content-Type: multipart/alternative; boundary="_000_CF95A92DD380Bsajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/GlS3wgViLNsTAXI3YBLYkd_JrhQ Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:34:03 -0000 --_000_CF95A92DD380Bsajassiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF95A92DD380Bsajassiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2FEA320120C57C4F8E8FC3BE1CDC83F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Jakob,

I believe the currency text is correct and sufficient. What use case d= o you have in mind? 

EVPN PE devices that only do L2 (w/ flooding), only advertise MAC rout= e (w/o IP address) and EVPN PE devices that do L2 w/ ARP suppression, adver= tise both MAC and IP. In the latter case, if there are several IP addresses= map to the same MAC address, then the MAC address from MAC-VRF only gets removed, when there is no more ARP = entry with that MAC address.

Cheers,
Ali

We have another issue

In section 10: ARP and ND, the draft = says:

 

   If = there are multiple IP addresses associated with a MAC address,

   the= n multiple MAC advertisement routes MUST be generated, one for

   eac= h IP address. For instance, this may be the case when there are<= /span>

   bot= h an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC
   advertisement route with that particular IP address =
MUST be
   withdrawn.

 

If such a route is withdrawn and no M= AC route without IP exists, then the MAC address will be forgotten. Therefo= re, we would like to add a sentence:

 

Whenever a PE advertises one or more = MAC advertisement routes with IP address for a particular MAC address, it M= UST also advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

--_000_CF95A92DD380Bsajassiciscocom_-- From nobody Sun May 11 22:34:36 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBC71A03FD for ; Sun, 11 May 2014 22:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDfy_fNIzPJ7 for ; Sun, 11 May 2014 22:34:09 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 579681A03F6 for ; Sun, 11 May 2014 22:34:09 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-fb-53700b9ba0e8 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.F3.02831.B9B00735; Mon, 12 May 2014 01:45:31 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Mon, 12 May 2014 01:34:02 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMz///7AeA///ad0A= Date: Mon, 12 May 2014 05:34:01 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053B47@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@eusaamb109.ericsson.se> 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.12] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053B47eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPuO5s7oJgg4vr5SwefzvEbvHubDOL A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx/PBeloLJLYwVW47uZ2tgXFnWxcjJISFg IrHq4wtmCFtM4sK99WxdjFwcQgJHGSU+7f3IDOEsZ5R4OHs7O0gVm4COxLfrXWAdIgIhEqf7 WhhBbGYBM4nOm5PBaoQFDCRePp/CBlFjKLHj1DMmCNtKYn3XJLA4i4CqxMZjX8DqeQV8JaYs XQpWIyRQJNF07DRYDaeAvsSf2R9ZQGxGoOu+n1rDBLFLXOLWk/lMEFcLSCzZcx7qA1GJl4// sULYShJzXl9jhqjPl/iz4AUrxC5BiZMzn7BMYBSdhWTULCRls5CUQcR1JBbs/sQGYWtLLFv4 mhnGPnPgMROy+AJG9lWMHKXFqWW56UaGmxiBkXVMgs1xB+OCT5aHGAU4GJV4eBfsyg8WYk0s K67MPcQozcGiJM6b/ik2WEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjhrrLHgXJl5gzdObU 37t1g+XDlbk+/k09h1kmLTzo+XVVembYcTu9wyfrt2vz5XtsaK9iuuT0sYR12hpPPzePiV4G Cq7f5/ZU/qpW7f57bk/l3kC/mte/7utrpGzcYvCrerpImN3M5svuV5J7j8/c75YfX/GJO9/y o/gdvV1LI1/MPW2+RHGREktxRqKhFnNRcSIAFBI+cI0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/OIgXzhcOD510SVGetL2wfGOia3k Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:34:18 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053B47eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Ali. We didn't quite tie together the optionality of aliasing with the optionali= ty of the route. You have clarified it. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:17 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Hi Jakob, We are talking about two different routes. Section 8.4.1 talks about Ethern= et A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The= former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para). For rev 7, I added a clarification sentence to the end of the 3rd para of s= ection 9.2.2 saying: "The dependency of MAC routes installation on Ethernet A-D per ES routes, is to ensure that MAC routes don't get accidentally installed during mass withdraw period." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:43 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: optional ethernet A-D per EVI route Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution ... If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to "Support of this route is OPTIONAL unles= s non-reserved ESIs are used" or just be changed to MANDATORY? Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053B47eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Ali.

 

We didn’t quite tie together the opt= ionality of aliasing with the optionality of the route.

You have clarified it.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@c= isco.com]
Sent: Sunday, May 11, 2014 10:17 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: optional ethernet A-D per EVI route

 

&n= bsp;

Hi Jako= b,

&n= bsp;

We are = talking about two different routes. Section 8.4.1 talks about Ethernet A-D = per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The former= one is optional but no the latter one. As the matter of fact section 8.2.1 states that the support of the latter = one is mandatory (1st para).

&n= bsp;

For rev= 7, I added a clarification sentence to the end of the 3rd para of section = 9.2.2 saying:

&n= bsp;

       "The

dependency of MAC routes installation on Ethernet A-D<= /o:p>

per ES routes= ,

   =
is to ensure that MAC routes don't get accidentally installed during
   =
mass withdraw period."
 
Cheers,<=
/o:p>
Ali

&n= bsp;

From: jakob.heitz@e= ricsson.com>
Date: Sunday, May 11, 2014 9:43 PM
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: optional ethernet A-D per EVI route

&n= bsp;

Tony and I have an issue.

The draft says

8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route

 
 
   This section describes the procedures used to constr=
uct the Ethernet
   A-D per EVPN Instance (EVI) route, which is used for=
 aliasing (as
   discussed above). Support of this route is OPTIONAL.

 <= o:p>

And

 <= o:p>

9.2.2 Route Resolution

 

…= 

   If the Ethernet Segment Identifier field in a receiv=
ed MAC
   Advertisement route is set to a non-reserved ESI, th=
en if the
   receiving PE decides to install forwarding state for=
 the associated
   MAC address, it MUST be when both the MAC Advertisem=
ent route AND the

   associated set of Ethernet A-D per ES routes have be=
en received. 


 <=
o:p>


 <=
o:p>


Should this sentence be changed to “=
Support of this route is =
OPTIONAL unless non-reserved ESIs are used”
 or just be changed to MANDATORY?


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053B47eusaamb109erics_-- From nobody Sun May 11 22:39:08 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8F01A03F7 for ; Sun, 11 May 2014 22:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BisD06VPRRWI for ; Sun, 11 May 2014 22:39:04 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2A1A02C7 for ; Sun, 11 May 2014 22:39:04 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-1b-53700cc3393b Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6C.F3.02831.3CC00735; Mon, 12 May 2014 01:50:27 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 12 May 2014 01:38:58 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaA= Date: Mon, 12 May 2014 05:38:57 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8D@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A80@eusaamb109.ericsson.se> 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.12] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8Deusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPiO5hnoJggyeNyhaPvx1it3h3tpnF gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4uUO44GZKxZWnl9gaGCdEdjFyckgImEic fHufDcIWk7hwbz2QzcUhJHCUUeLXlkPsEM5yRonFl2axglSxCehIfLvexQxiiwiESJzua2EE sZkFzCQ6b05mB7GFBeQkPnccZYKokZdo/LGWFcK2kvj6/wJYPYuAqsSkN4/ANvMK+ErsnvoZ bKaQQJFEe+8NsBpOAX2J768+gc1kBLru+6k1TBC7xCVuPZnPBHG1gMSSPeeZIWxRiZeP/7FC 2EoSc15fA4pzANXnS2x9rQexSlDi5MwnLBMYRWchmTQLoWoWkiqIEh2JBbs/sUHY2hLLFr5m hrHPHHjMhCy+gJF9FSNHaXFqWW66keEmRmBEHZNgc9zBuOCT5SFGAQ5GJR7eBbvyg4VYE8uK K3MPMUpzsCiJ86Z/ig0WEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFgq+UYk1r9p191jXNlr AuuUJyYIW7+evUXJJG3ti9k/JW/u2ntiVtXZ72tadm3qObTwyaUipdoJ52SXi9vtvctse9P7 sZTklgAGr3XiNdtjLbt5kjfnxX85KlEeMdXhxRH2a1PkbT88mffprcNzllUeJyP3nLzAMX+7 AVeB/yuHd9tO2C+JsN+jxFKckWioxVxUnAgAhAsx44kCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/PVffPV01BTGCjCROzqyuUQlLKlg Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:39:06 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8Deusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8Deusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@c= isco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Hi Jako= b,

&n= bsp;

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

&n= bsp;

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: jakob.heitz@e= ricsson.com>
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: MAC route with IP

&n= bsp;

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8Deusaamb109erics_-- From nobody Sun May 11 22:53:20 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79451A03FC for ; Sun, 11 May 2014 22:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXBKj1hbOH0O for ; Sun, 11 May 2014 22:53:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AA3DC1A03F9 for ; Sun, 11 May 2014 22:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15397; q=dns/txt; s=iport; t=1399873991; x=1401083591; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=kk6maOLIgav+29EyLMo2I1Jxd5rFkzhPL1zhvLulbNw=; b=jctMoz7m8oKJ6/lNy64GcOO2PiAYA7vUk4lT2YMvyvxVd5BlM8Nn2WNa qW7N5mY2LMSaXQn88j7AmXnJvBmnGQVJsVf/lruGStkKNQlrQS4Po49tL EJQ4T+Mk4VqXLFgjZGRzvkxoGTHeih9Ol5Ng+B6vO6ALiwFnLLiIdqyrq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFABthcFOtJV2Q/2dsb2JhbABZgkIjIU9YxWEBgRcWdIIlAQEBBC1MEgEIEQMBAQEoORQJCAEBBAENBYhBAc4KF45BEQYBhEAEhXiTUJMHgzaCLw X-IronPort-AV: E=Sophos;i="4.97,1033,1389744000"; d="scan'208,217";a="323922287" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 12 May 2014 05:53:10 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4C5rA1X000817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 05:53:10 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 12 May 2014 00:53:10 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaCAACfogA== Date: Mon, 12 May 2014 05:53:09 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8D@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.66.92] Content-Type: multipart/alternative; boundary="_000_CF95AD07D382Dsajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/3qfNUYpCJ22aE5x2qBVk2xf9Yyo Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:53:19 -0000 --_000_CF95AD07D382Dsajassiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, but that's the case when that MAC address is associated with other IP = addresses per my example below. And as long as there are other ARP entry (o= r entries) for that MAC address after deleting that IP/MAC pair, the MAC ad= dress will remain in the MAC-VRF. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:38 PM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF95AD07D382Dsajassiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <848763E9243F9044BF1DB310A3C5F50D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Yes, but that's the case when that MAC address is associated with othe= r IP addresses per my example below. And as long as there are other ARP ent= ry (or entries) for that MAC address after deleting that IP/MAC pair, the M= AC address will remain in the MAC-VRF. 

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 10:38 PM=
To: Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

When the IP address is dissociated wi= th the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

&nbs= p;

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Hi Jako= b,

&n= bsp;

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

&n= bsp;

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jak= ob Heitz <jakob.heitz@ericss= on.com>
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: MAC route with IP

&n= bsp;

We have another issue

In section 10: ARP and ND, the draft = says:

 

   If = there are multiple IP addresses associated with a MAC address,

   the= n multiple MAC advertisement routes MUST be generated, one for

   eac= h IP address. For instance, this may be the case when there are

   bot= h an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no M=
AC route without IP exists, then the MAC address will be forgotten. Therefo=
re, we would like to add a sentence:


 


Whenever a PE advertises one or more =
MAC advertisement routes with IP address for a particular MAC address, it M=
UST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF95AD07D382Dsajassiciscocom_-- From nobody Sun May 11 22:59:27 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41AD1A03FD for ; Sun, 11 May 2014 22:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y-_-_85NSxI for ; Sun, 11 May 2014 22:59:23 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 670471A03FE for ; Sun, 11 May 2014 22:59:22 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-be-537011844d5c Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 96.24.02831.48110735; Mon, 12 May 2014 02:10:45 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 12 May 2014 01:59:16 -0400 From: Jakob Heitz To: Jakob Heitz , "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkA== Date: Mon, 12 May 2014 05:59:14 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053BF0@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A80@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8D@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8D@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.12] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053BF0eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiG6rYEGwwfe9vBaPvx1it3h3tpnF gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4dugia8G+FsaKN1umsDYwrijtYuTkkBAw kZh0op8JwhaTuHBvPVsXIxeHkMBRRolLa76zQjjLGSXWXZzIDlLFJqAj8e16FzOILSJQI7Hr 7AVWEJtZwEyi8+ZksBphATmJzx1HmSBq5CUaf6wFquEAsp0kmu+HgYRZBFQl+l7NYgQJ8wr4 Skw9KgmxahujxKevaxlBajgF/CR+LZjHAmIzAh33/dQaJohV4hK3nsyHOlpAYsme88wQtqjE y8f/WCFsJYk5r68xQ9TnS0y6uwrsNF4BQYmTM5+wTGAUnYVk1CwkZbOQlEHEdSQW7P7EBmFr Syxb+JoZxj5z4DETsvgCRvZVjBylxalluelGhpsYgXF1TILNcQfjgk+WhxgFOBiVeHgX7MoP FmJNLCuuzD3EKM3BoiTOm/4pNlhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY2rVYlExv+3L zb46T95Tm37ipviCgwpGNhrfslstKjm5F0pa/+dcPjuGp7tyZ15Cp3RPpmnqMbfmZXMuVZ+V 49Jr6YoouKZV+uHDnTMZcyt5Hf8cU2V85tKenBsyNZNF7f4//eAtu1ew5V1ON3nBJ+L0JuOR 9L7b/cxTD8h93r31ScrF3Tv2KLEUZyQaajEXFScCANbWe9+MAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Fh2sE2K2JfnZhOqm9D8ZBlLqUsE Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:59:25 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053BF0eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053BF0eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

People clear ARP caches when they get too = big. When that happens, the bridge table may not be cleared at the same tim= e or at all.

An ARP cache may have a different timeout = than the bridge table.

A bridge can snoop ARP messages to learn b= indings and those bindings can time out.

However, many other packets can come from = the same MAC address, keeping the MAC alive in the bridge table. In this ca= se, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other than b= y snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] <= b>On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Hi Jako= b,

&n= bsp;

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

&n= bsp;

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: jakob.heitz@ericsson.com&= gt;
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni= .przygienda@ericsson.com>
Subject: MAC route with IP

&n= bsp;

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03053BF0eusaamb109erics_-- From nobody Sun May 11 23:11:08 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95A21A03FC for ; Sun, 11 May 2014 23:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9fybyLEzPiS for ; Sun, 11 May 2014 23:11:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 394761A03FE for ; Sun, 11 May 2014 23:11:00 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-b8-537016ad528d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B0.42.07420.DA610735; Mon, 12 May 2014 02:32:45 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Mon, 12 May 2014 02:10:52 -0400 From: Antoni Przygienda To: "Ali Sajassi (sajassi)" , Jakob Heitz , "l2vpn@ietf.org" Subject: RE: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMz///7AeA///dMbA= Date: Mon, 12 May 2014 06:10:51 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1812B4B8@eusaamb103.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@eusaamb109.ericsson.se> 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.11] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1812B4B8eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPuO5asYJggwf/9S0efzvEbvHubDOL A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRPXk6a8HOVUwV+6ZINTC+6mTqYuTkkBAw kWhe/hTKFpO4cG89WxcjF4eQwFFGiScN/9khnOWMEqeOzWUBqWITsJC4/O0pM4gtIlAjsfDb e1YQW1jAQOLl8ylsEHFDiR2nnjFB2FYSb47fA+rl4GARUJXo7g8ECfMKeEvc3zSREcQWEiiS aDp2GqyVU0Bf4s/sj2CrGIEO+n5qDdgYZgFxiVtP5kMdKiCxZM95ZghbVOLl43+sELaSxMff 89kh6vMlFn/+yA6xS1Di5MwnLBMYRWYhGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjM hCy+gJF9FSNHaXFqWW66kcEmRmD8HJNg093BuOel5SFGAQ5GJR7eBbvyg4VYE8uKK3MPMUpz sCiJ8xZ8iQ0WEkhPLEnNTk0tSC2KLyrNSS0+xMjEwQmMH4Pw6I0H/qbczW8p1Jxe9XBn92qz G0UrzwX/mqcjnlx+x6pVdUZisZm+lv/s9sDcYzIvkswj73+5vX+ayzf5Pm6D9KRDwicVGoo8 Pj5Lns/wdMPMt7nXVm6/H/nZ9si0lT96bE4YL3CZJC6ze3awRe8Z42wdQZm+9c909niWyYeF rv71ztjnjBJLcUaioRZzUXEiAK3hBR2AAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/tqokL7MvYOPSjLup5d_TdaK98-g X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 06:11:04 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1812B4B8eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, I'm struggling with the 'optional per EVI route' which I also thi= nk should be dropped as Jakob suggests. I'm referring to the -07 and unroll= ing the issue: Per 14.1.2 A remote PE that receives a MAC advertisement route with non- reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D per ES route for that ES. -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet A-D route per EVI exist, only then the label from that latter route *must* be used. First, should that be a capital MUST ? Second, that seems to imply that lo= ad balancing cannot be done without the per EVI route ? Or that without a p= er EVI route all-active-redundancy mode cannot install MACs from remote PEs= ? Per 8.4 Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. To address this issue, EVPN introduces the concept of 'Aliasing' which is the ability of a PE to signal that it has reachability to an EVPN instance on a given ES even when it has learnt no MAC addresses from that EVI/ES. The Ethernet A-D per EVI route is used for this purpose. A remote PE that receives a MAC advertisement route with non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND Ethernet A-D per ES routes for that ES with the 'Single-Active' bit in the flags of the ESI Label Extended Community set to 0. Now, what does that mean exactly since English is tad loose here (same as i= n 14.1.2) : the MAC is valid if (EITHER the EAD per EVI is here or EAD per ES) OR does= it imply that BOTH must be present and lack of an A-D per EVI route will = prevent aliasing (but nothing else, i.e. the route can be installed into th= e fwd path) ? Or can the MAC be installed anyway since it's all a SHOULD ? I seem to read the intention as: . if you have an EAD per EVI and _NO_ EAD per ESI you canno= t use the MAC (no load-balancing until ESI is up per section 8.4 above ) . if you have ESI only, you can (that's just aliasing) . if you have EVI _AND_ ESI, the EVI label (in the route) ta= kes precedence and we start to 'load-balance' --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:17 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Hi Jakob, We are talking about two different routes. Section 8.4.1 talks about Ethern= et A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The= former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para). For rev 7, I added a clarification sentence to the end of the 3rd para of s= ection 9.2.2 saying: "The dependency of MAC routes installation on Ethernet A-D per ES routes, is to ensure that MAC routes don't get accidentally installed during mass withdraw period." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:43 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: optional ethernet A-D per EVI route Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution ... If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to "Support of this route is OPTIONAL unles= s non-reserved ESIs are used" or just be changed to MANDATORY? Thanks, Jakob. --_000_2E4BB27CAB87BF43B4207C0E55860F1812B4B8eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Actually, I’m struggli= ng with the ‘optional per EVI route’ which I also think should = be dropped as Jakob suggests. I’m referring to the -07 and unrolling the issue:

=  

Per 14.1.2

 

        A rem= ote PE that receives a MAC advertisement route with non-<= /font>

   reserved ESI SHOULD consider the ad= vertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND an Ethernet A-D

   per ES route for that ES.<= /span>

 

   -If a set of Ethernet A-D per ES ro= utes for that ES AND an Ethernet

   A-D route per EVI exist, only then = the label from that latter route

   *must* be used.

 

First, should that be= a capital MUST ?  Second, that seems to imply that load balancing can= not be done without the per EVI route ? Or that without a per EVI route all-active-redundancy mode cannot install MACs fro= m remote PEs ?

 

Per 8.4

 

        There= fore, in order to handle corner cases and race conditions, the

   Ethernet A-D per EVI route MUST NOT= be used for traffic forwarding by

   a remote PE until it also receives = the associated set of Ethernet A-D

   per ES routes.

 

        To ad= dress this issue, EVPN introduces the concept of 'Aliasing'

   which is the ability of a PE to sig= nal that it has reachability to an

   EVPN instance on a given ES even wh= en it has learnt no MAC addresses

   from that EVI/ES. The Ethernet A-D = per EVI route is used for this

   purpose. A remote PE that receives = a MAC advertisement route with

   non-reserved ESI SHOULD consider th= e advertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND Ethernet A-D per

   ES routes for that ES with the 'Sin= gle-Active' bit in the flags of

   the ESI Label Extended Community se= t to 0.

   &nb= sp;          

Now, what does that m= ean exactly since English is tad loose here (same as in 14.1.2) :

the MAC is valid if  (EITHER= the EAD per EVI is here or EAD per ES) OR does it imply that  BOTH mu= st be present and lack of an A-D per EVI route will prevent aliasing (but nothing else, i.e. the route can be installed into t= he fwd path) ? Or can the MAC be installed anyway since it’s all a SH= OULD ?

 

I seem to read the intention as:<= o:p>

 

          =      . if you have an EAD per EVI and  _NO_ EAD per ESI you cannot use the MA= C (no load-balancing until ESI is up per section 8.4 above )

          =      . if you have ESI only, you can (that’s just= aliasing)

          =      . if you have EVI _AND_ ESI, the EVI label (in the route) takes precedence an= d we start to ‘load-balance’

 

 

--- tony

=  

=  

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 1= 0:17 PM
To: Jakob Heitz; l2vpn@ietf.= org
Cc: Antoni Przygienda
Subject: Re: optional ethern= et A-D per EVI route

 

 <= /p>

Hi Jakob,

 <= /p>

We are talking about two differe= nt routes. Section 8.4.1 talks about Ethernet A-D per EVI; whereas, section= 9.2.2 talks about Ethernet A-D per ES. The former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para).<= o:p>

 <= /p>

For rev 7, I added a clarificati= on sentence to the end of the 3rd para of section 9.2.2 saying:<= /span>

 <= /p>

&n= bsp;      "The

depen= dency of MAC routes installation on Ethernet A-D

per ES routes,

   is t=
o ensure that MAC routes don't get accidentally installed during=

   mass=
 withdraw period."
 =

Cheers,
Ali

 <= /p>

From: Ja= kob Heitz <jakob.heitz@erics= son.com>
Date: Sunday, May 11, 2014 9= :43 PM
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: optional ethernet A= -D per EVI route

 <= /p>

Tony and I have an issue.

The draft says

8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route<= font color=3D"black"><= /h4> 
 
 
  =
; This section describes the procedures used to construct the Ethernet
  =
; A-D per EVPN Instance (EVI) route, which is used for aliasing (as<=
/font><=
/font>
  =
; discussed above). Support of this route is OPTIONAL.

 

And

 

9.2.2 Route Resolution

 

…

  =
; If the Ethernet Segment Identifier field in a received MAC<=
font color=3D"black"><=
/pre>

  =
; Advertisement route is set to a non-reserved ESI, then if the


  =
; receiving PE decides to install forwarding state for the associated


  =
; MAC address, it MUST be when both the MAC Advertisement route AND the


  =
; associated set of Ethernet A-D per ES routes have been received. <=
/font><=
/font>


 


 


Should this sentence be changed to “Sup=
port
 of this route is OPTIONAL unless non-reserved ESIs are used<=
font size=3D"1" color=3D"#a014a0" face=3D"Lucida Console">”=
 or just be changed to MANDATORY?


 


Thanks,


Jakob.


 

--_000_2E4BB27CAB87BF43B4207C0E55860F1812B4B8eusaamb103ericsso_-- From nobody Sun May 11 23:23:23 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F56E1A040B for ; Sun, 11 May 2014 23:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvwmi5II5Pqb for ; Sun, 11 May 2014 23:23:17 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 81EE51A03FE for ; Sun, 11 May 2014 23:23:17 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-01-5370198faa4d Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B2.52.07420.F8910735; Mon, 12 May 2014 02:45:03 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 12 May 2014 02:23:11 -0400 From: Antoni Przygienda To: "Ali Sajassi (sajassi)" , Jakob Heitz , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaCAACfogP//2UcQ Date: Mon, 12 May 2014 06:23:10 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1812B4DF@eusaamb103.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053B8D@eusaamb109.ericsson.se> 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.11] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1812B4DFeusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPiG6/ZEGwwcZ7JhaPvx1it3h3tpnF gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MrY2vqKveDeF8aKzc/PMDcwfrjJ2MXIwSEh YCKx+qt+FyMnkCkmceHeerYuRi4OIYGjjBKtE/6zQjjLGSXWr//DBFLFJmAhcfnbU2YQW0Sg RmLht/esILawgJzE546jTBBxeYnGH2tZQRaICLhJPHyhAxJmEVCV6Nl8HSzMK+AtcaEvHyQs JFAksWblbkYQm1NAX6Lv5WwWEJsR6J7vp9aATWQWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/scK YStJfPw9nx2iPl/i98QtYPW8AoISJ2c+YZnAKDILyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1 M4x95sBjJmTxBYzsqxg5SotTy3LTjQw2MQKj55gEm+4Oxj0vLQ8xCnAwKvHwLtiVHyzEmlhW XJl7iFGag0VJnLfgS2ywkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZF/J2vNp3YfdSc8Rx3 /p+4W5Ucsz7/WtfP9SF25mnV2yuzWpS6dvwofN4WbuQTrLtw3e/Ed3G/mv963L9h2MmRd6vO gWt6w/KNHP+ktLl9n/t9Zbu3+ElK1hqXPZJXHuuJr+aL2uNeu9rmRP/n9FMpERyzSnYH6H+u UrXac2F3wlGTkOoLll+VWIozEg21mIuKEwFHKSpdfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/AfdzzTLRkA-3xYr0QvTKcEmkip8 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 06:23:21 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1812B4DFeusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ali, there are at least two cases when receiving updates from peers which are ta= d hairy given the encoding: 1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone jus= t withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP r= outes are still valid to me or at least that could be emphasized in the dra= ft that they do (i.e. all routes are truly independent). 2. Since we have mac based disposition there is nothing that prevents = a neighbor to advertise multiple MAC/IP routes with different labels. It s= hould obviously not imply that we have to lookup the IP address on the pack= et (if we even have one) to decide which label is needed. Should all this = labels be considered pointing to the same MAC & equivalent ? Such a conditi= on considered invalid transient and MAC labels for this MAC ignored complet= ely ? What if we get one route with the label & another without ? We use t= he label nevertheless for the same MAC ? And my final interesting observation: A single primary/single backup case would be simple & easy, = the way the protocol spec stands today, I don't think there is anything tha= t prevents it from operating in multiple-primaries, multiple-backup mode = (as in two guys clear the single-active bits & all other set them) [unless = I misunderstood something massively]. Do we load balance the primaries un= til both fail & then either flood (multiple backups) or fail back on the se= condary ? Otherwise, very good draft I think solving tons of hard problems in (for th= e customer and in terms of protocols mechanics) fairly elegant way. --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:53 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Yes, but that's the case when that MAC address is associated with other IP = addresses per my example below. And as long as there are other ARP entry (o= r entries) for that MAC address after deleting that IP/MAC pair, the MAC ad= dress will remain in the MAC-VRF. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:38 PM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2E4BB27CAB87BF43B4207C0E55860F1812B4DFeusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Ali,

=  

= there are at least two cases= when receiving updates from peers which are tad hairy given the encoding:<= o:p>

=  

1.      We receive a MAC/no-IP  & a set of MAC/IP = routes & then someone just withdraws the MAC/no-IP.  It does not s= eem very logical that the MAC/IP routes are still valid to me or at least that could be emphasized in the draft that they do (i.e.= all routes are truly independent).

2.      Since we have mac based disposition there is nothin= g that prevents a neighbor to advertise multiple MAC/IP routes with differe= nt labels.  It should obviously not imply that we have to lookup the IP address on the packet (if we even have= one) to decide which label is needed.  Should all this labels be cons= idered pointing to the same MAC & equivalent ? Such a condition conside= red invalid transient and MAC labels for this MAC ignored completely ?  What if we get one route with the labe= l & another without ? We use the label nevertheless for the same MAC ?

=  

= And my final interesting obs= ervation:

=  

=     &nbs= p;          A single primary/s= ingle backup case would be simple & easy, the way the protocol spec sta= nds today, I don’t think there is anything that prevents it from operating in  multiple-primaries, multiple-back= up mode  (as in two guys clear the single-active bits & all other = set them) [unless I misunderstood something massively].   Do we l= oad balance the primaries until both fail & then either flood (multiple backups) or fail back on the secondary ?

=  

= Otherwise, very good draft I= think solving tons of hard problems in (for the customer and in terms of p= rotocols mechanics) fairly elegant way.

=  

= --- tony

=

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 1= 0:53 PM
To: Jakob Heitz; l2vpn@ietf.= org
Cc: Antoni Przygienda
Subject: Re: MAC route with = IP

 

 <= /p>

Yes, but that's the case when th= at MAC address is associated with other IP addresses per my example below. = And as long as there are other ARP entry (or entries) for that MAC address after deleting that IP/MAC pair, the MAC add= ress will remain in the MAC-VRF. 

 <= /p>

Cheers,=

Ali

 <= /p>

From: Ja= kob Heitz <jakob.heitz@erics= son.com>
Date: Sunday, May 11, 2014 1= 0:38 PM
To: Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: RE: MAC route with = IP

 <= /p>

When the IP address is dissociated with the MAC address, b= ut the MAC address still exits.

 

Cheers,

Jakob.

 

From:= Ali Sajassi (= sajassi) [mailto:sajassi@cisco.com= ]
Sent: Sunday, May 11, 2014 1= 0:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with = IP

 <= /p>

 

Hi Jakob,

 

I believe the currency text is c= orrect and sufficient. What use case do you have in mind? 

 

EVPN PE devices that only do L2 = (w/ flooding), only advertise MAC route (w/o IP address) and EVPN PE device= s that do L2 w/ ARP suppression, advertise both MAC and IP. In the latter case, if there are several IP addresses map= to the same MAC address, then the MAC address from MAC-VRF only gets remov= ed, when there is no more ARP entry with that MAC address.

 

Cheers,

Ali

 

From: Ja= kob Heitz <jakob.heitz@erics= son.com>
Date: Sunday, May 11, 2014 9= :56 PM
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: MAC route with IP

 

We have another issue<= span style=3D"color:black">

In section 10: ARP and ND, the draft says:

 

   If there are multip= le IP addresses associated with a MAC address,

   then multiple MAC a= dvertisement routes MUST be generated, one for

   each IP address. Fo= r instance, this may be the case when there are

   both an IPv4 and an= IPv6 address associated with the MAC address.

 

  =
; When the IP address is dissociated with the MAC address, then the MAC
  =
; advertisement route with that particular IP address MUST be=
=

  =
; withdrawn.

 

If such a route is withdrawn and no MAC route without IP e= xists, then the MAC address will be forgotten. Therefore, we would like to add a sentence:

 

Whenever a PE advertises one or more MAC advertisement rou= tes with IP address for a particular MAC address, it MUST also advertise one MAC advertisement route without an IP address for = that MAC address.

 

Thanks,

Jakob.

 

--_000_2E4BB27CAB87BF43B4207C0E55860F1812B4DFeusaamb103ericsso_-- From nobody Sun May 11 23:51:01 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F78E1A0415 for ; Sun, 11 May 2014 23:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qh7KeUG5SUs for ; Sun, 11 May 2014 23:50:55 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 313B21A007E for ; Sun, 11 May 2014 23:50:55 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-c8-53701d9851e9 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6E.64.02831.89D10735; Mon, 12 May 2014 03:02:16 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Mon, 12 May 2014 02:50:47 -0400 From: Jakob Heitz To: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMz///7AeA///dMbCAAF6q9w== Date: Mon, 12 May 2014 06:50:47 +0000 Message-ID: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@eusaamb109.ericsson.se> , <2E4BB27CAB87BF43B4207C0E55860F1812B4B8@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1812B4B8@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E9CF04E5404C4A30A8495ED74DEA8677ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPrO4M2YJgg43NKhaPvx1it3h3tpnF gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYNHM1c8Gr9UwVhw5HNDA29zF1MXJySAiY SHxedQDKFpO4cG89WxcjF4eQwFFGiZdL97KCJIQEljNKPO7PALHZBHQkvl3vYgaxRQTMJBZN OMoIYjMLhEhMPN8BFOfgEBYwkOj/aABRYiix49QzJgjbSeL61rtg5SwCqhLf/r8EG8MrYC+x cO8iqL2bGCUefWhnB0lwCvhILPv6CsxmBDru+6k1TBC7xCVuPZkPdbSAxJI955khbFGJl4// sULUJEt83XeSEWKBoMTJmU9YJjCKzELSPgtJ2SwkZRBxA4n35+YzQ9jaEssWvoay9SU2fjnL iCy+gJF9FSNHaXFqWW66keEmRmD8HJNgc9zBuOCT5SFGAQ5GJR7eBbvyg4VYE8uKK3MPMUpz sCiJ86Z/ig0WEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOid+NVL78MGnmncW66ryrr/FLsl v/N59h5rm8IIu3C7M3Zv5+TOPyBvt2nD4/0aTi/Y14Uz2lzl/yb4/fq/hiV/RCbFPPNK3LjE 4W8k37uQlR7iBxZMZQpUrX64/rfPsjCT1lV9C8sqNnvmGvru9LOOnhkmZxul8XPmOc3FG0J3 beFQuG7y+Z4SS3FGoqEWc1FxIgCirLS3gAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/R75ux0UDkWHLwSoCSwYazzKGdzE Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 06:50:58 -0000 --_000_E9CF04E5404C4A30A8495ED74DEA8677ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Tony, Ali clarified it like this for me: Aliasing requires the 'per EVI' route. A= liasing is optional. Therefore, the 'per EVI' route is optional. And I know a cat named Socrates :) -- Jakob Heitz. On May 11, 2014, at 11:10 PM, "Antoni Przygienda" > wrote: Actually, I=92m struggling with the =91optional per EVI route=92 which I al= so think should be dropped as Jakob suggests. I=92m referring to the -07 an= d unrolling the issue: Per 14.1.2 A remote PE that receives a MAC advertisement route with non- reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D per ES route for that ES. -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet A-D route per EVI exist, only then the label from that latter route *must* be used. First, should that be a capital MUST ? Second, that seems to imply that lo= ad balancing cannot be done without the per EVI route ? Or that without a p= er EVI route all-active-redundancy mode cannot install MACs from remote PEs= ? Per 8.4 Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. To address this issue, EVPN introduces the concept of 'Aliasing' which is the ability of a PE to signal that it has reachability to an EVPN instance on a given ES even when it has learnt no MAC addresses from that EVI/ES. The Ethernet A-D per EVI route is used for this purpose. A remote PE that receives a MAC advertisement route with non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND Ethernet A-D per ES routes for that ES with the 'Single-Active' bit in the flags of the ESI Label Extended Community set to 0. Now, what does that mean exactly since English is tad loose here (same as i= n 14.1.2) : the MAC is valid if (EITHER the EAD per EVI is here or EAD per ES) OR does= it imply that BOTH must be present and lack of an A-D per EVI route will = prevent aliasing (but nothing else, i.e. the route can be installed into th= e fwd path) ? Or can the MAC be installed anyway since it=92s all a SHOULD = ? I seem to read the intention as: . if you have an EAD per EVI and _NO_ EAD per ESI you canno= t use the MAC (no load-balancing until ESI is up per section 8.4 above ) . if you have ESI only, you can (that=92s just aliasing) . if you have EVI _AND_ ESI, the EVI label (in the route) ta= kes precedence and we start to =91load-balance=92 --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:17 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Hi Jakob, We are talking about two different routes. Section 8.4.1 talks about Ethern= et A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The= former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para). For rev 7, I added a clarification sentence to the end of the 3rd para of s= ection 9.2.2 saying: "The dependency of MAC routes installation on Ethernet A-D per ES routes, is to ensure that MAC routes don't get accidentally installed during mass withdraw period." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:43 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: optional ethernet A-D per EVI route Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution =85 If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to =93Support of this route is OPTIONAL unl= ess non-reserved ESIs are used=94 or just be changed to MANDATORY? Thanks, Jakob. --_000_E9CF04E5404C4A30A8495ED74DEA8677ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Tony,

Ali clarified it like this for me: Aliasing requires the 'per EVI' rou= te. Aliasing is optional. Therefore, the 'per EVI' route is optional.

And I know a cat named Socrates :)

--
Jakob Heitz.


On May 11, 2014, at 11:10 PM, "Antoni Przygienda" <antoni.przygienda@ericsson.com&g= t; wrote:

= Actually, I=92m struggling w= ith the =91optional per EVI route=92 which I also think should be dropped a= s Jakob suggests. I=92m referring to the -07 and unrolling the issue:

=  

Per 14.1.2

 

        A rem= ote PE that receives a MAC advertisement route with non-<= /font>

   reserved ESI SHOULD consider the ad= vertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND an Ethernet A-D

   per ES route for that ES.<= /span>

 

   -If a set of Ethernet A-D per ES ro= utes for that ES AND an Ethernet

   A-D route per EVI exist, only then = the label from that latter route

   *must* be used.

 

First, should that be= a capital MUST ?  Second, that seems to imply that load balancing can= not be done without the per EVI route ? Or that without a per EVI route all-active-redundancy mode cannot install MACs fro= m remote PEs ?

 

Per 8.4

 

        There= fore, in order to handle corner cases and race conditions, the

   Ethernet A-D per EVI route MUST NOT= be used for traffic forwarding by

   a remote PE until it also receives = the associated set of Ethernet A-D

   per ES routes.

 

        To ad= dress this issue, EVPN introduces the concept of 'Aliasing'

   which is the ability of a PE to sig= nal that it has reachability to an

   EVPN instance on a given ES even wh= en it has learnt no MAC addresses

   from that EVI/ES. The Ethernet A-D = per EVI route is used for this

   purpose. A remote PE that receives = a MAC advertisement route with

   non-reserved ESI SHOULD consider th= e advertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND Ethernet A-D per

   ES routes for that ES with the 'Sin= gle-Active' bit in the flags of

   the ESI Label Extended Community se= t to 0.

   &nb= sp;          

Now, what does that m= ean exactly since English is tad loose here (same as in 14.1.2) :

the MAC is valid if  (EITHER= the EAD per EVI is here or EAD per ES) OR does it imply that  BOTH mu= st be present and lack of an A-D per EVI route will prevent aliasing (but nothing else, i.e. the route can be installed into t= he fwd path) ? Or can the MAC be installed anyway since it=92s all a SHOULD= ?

 

I seem to read the intention as:<= o:p>

 

          =      . if you have an EAD per EVI and  _NO_ EAD per ESI you cannot use the MA= C (no load-balancing until ESI is up per section 8.4 above )

          =      . if you have ESI only, you can (that=92s just ali= asing)

          =      . if you have EVI _AND_ ESI, the EVI label (in the route) takes precedence an= d we start to =91load-balance=92

 

 

--- tony

=  

=  

From: Ali Sajassi (sajassi) [mailto:sajassi@cis= co.com]
Sent: Sunday, May 11, 2014 1= 0:17 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: optional ethern= et A-D per EVI route

 

 <= /p>

Hi Jakob,

 <= /p>

We are talking about two differe= nt routes. Section 8.4.1 talks about Ethernet A-D per EVI; whereas, section= 9.2.2 talks about Ethernet A-D per ES. The former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para).<= o:p>

 <= /p>

For rev 7, I added a clarificati= on sentence to the end of the 3rd para of section 9.2.2 saying:<= /span>

 <= /p>

&n= bsp;      "The

depen= dency of MAC routes installation on Ethernet A-D

per ES routes,

   is t=
o ensure that MAC routes don't get accidentally installed during=

   mass=
 withdraw period."
 =

Cheers,
Ali

 <= /p>

From: Ja= kob Heitz <jakob.heitz@erics= son.com>
Date: Sunday, May 11, 2014 9= :43 PM
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: optional ethernet A= -D per EVI route

 <= /p>

Tony and I have an issue.

The draft says

8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route<= font color=3D"black"><= /h4> 
 
 
  =
; This section describes the procedures used to construct the Ethernet
  =
; A-D per EVPN Instance (EVI) route, which is used for aliasing (as<=
/font><=
/font>
  =
; discussed above). Support of this route is OPTIONAL.

 

And

 

9.2.2 Route Resolution

 

=85

  =
; If the Ethernet Segment Identifier field in a received MAC<=
font color=3D"black"><=
/pre>

  =
; Advertisement route is set to a non-reserved ESI, then if the


  =
; receiving PE decides to install forwarding state for the associated


  =
; MAC address, it MUST be when both the MAC Advertisement route AND the


  =
; associated set of Ethernet A-D per ES routes have been received. <=
/font><=
/font>


 


 


Should this sentence be changed to =93Support
 of this route is OPTIONAL unless non-reserved ESIs are used<=
font size=3D"1" color=3D"#a014a0" face=3D"Lucida Console">=94 or =
just be changed to MANDATORY?


 


Thanks,


Jakob.


 

--_000_E9CF04E5404C4A30A8495ED74DEA8677ericssoncom_-- From nobody Mon May 12 02:13:25 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDA81A0584 for ; Mon, 12 May 2014 02:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIPADKRvr509 for ; Mon, 12 May 2014 02:13:22 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 46A971A055D for ; Mon, 12 May 2014 02:13:22 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so7774610obc.2 for ; Mon, 12 May 2014 02:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YpqObADZNjBq6FtW8vZqBLyK/mdWi6WgLsAmhnK+lys=; b=GsYAeN1Au8cvMd3WN4H+ZvlKiq4zmzl4PmkIAagBmcM/F0133wxU4YI3D4vjusC1EG VKJ4mbUgJCE/GNsm2dt10VrMzZzsoIAVsOwFCdgXTh1UThsjmZEep2FcRS2Su7Z3JTXU Rdhf6KT6rzjxkiTWYnWMVM19kzgOmrACmnpbWpJXsVROWSGD2269QZ52yDOPPO1/gyXJ jrIBdfxa+wW5Oqi5edOY9O73zXH1z9N4pfk3M+4jbScQtgXLGdZHpgL/Gc/EYubYq3Uy ygWwC8ZhlWX1jYV9fCcmD/V8tr7gdKYcC8ZKRO/aKoTGe8EMLG0Z7ZV+EVcDPY4pS+iH d2Ew== MIME-Version: 1.0 X-Received: by 10.182.72.227 with SMTP id g3mr31492064obv.28.1399885996267; Mon, 12 May 2014 02:13:16 -0700 (PDT) Received: by 10.182.148.8 with HTTP; Mon, 12 May 2014 02:13:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 May 2014 04:13:16 -0500 Message-ID: Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 From: Luay Jalil To: Giles Heron Content-Type: multipart/alternative; boundary=001a11c2fc52889fd304f9305bc9 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ptAAMOzm6N1BCXOHReiqGGG0edI Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 09:13:23 -0000 --001a11c2fc52889fd304f9305bc9 Content-Type: text/plain; charset=UTF-8 Support Luay On Friday, May 9, 2014, Giles Heron wrote: > This email initiates an IETF L2VPN WG Last Call for: > > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > > please comment to the list as to the suitability of this draft for > publication as a Standards Track RFC from the L2VPN WG. > > this last call will close on Friday 23rd May 2014. > > Nabil & Giles > -- *Luay* --001a11c2fc52889fd304f9305bc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support=C2=A0

Luay

On Friday, May 9, 2014, Giles = Heron <giles.heron@gmail.com> wrote:
This email initiates an IETF L2VPN WG Last Call for:

http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07

please comment to the list as to the suitability of this draft for publicat= ion as a Standards Track RFC from the L2VPN WG.

this last call will close on Friday 23rd May 2014.

Nabil & Giles


--
Luay
--001a11c2fc52889fd304f9305bc9-- From nobody Mon May 12 03:28:43 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC3D1A03F9 for ; Sun, 11 May 2014 22:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAE8dhnuAG3i for ; Sun, 11 May 2014 22:52:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC7FC1A03FC for ; Sun, 11 May 2014 22:52:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEA93269; Mon, 12 May 2014 05:52:37 +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.3.158.1; Mon, 12 May 2014 06:51:46 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 May 2014 06:52:36 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.124]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Mon, 12 May 2014 13:52:33 +0800 From: Duwenhua To: Giles Heron , "l2vpn@ietf.org" Subject: RE: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4cfC2bWgdTK0kOVjRpPPV9yNps8dTgA Date: Mon, 12 May 2014 05:52:32 +0000 Message-ID: <4535442760C9C74B90334E7DFB3D5CC425EA4794@SZXEMA512-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/LGiedkTgVORvLHIR78Ub6SA24sE X-Mailman-Approved-At: Mon, 12 May 2014 03:28:39 -0700 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 05:52:47 -0000 I support it to become publication. =20 > -----Original Message----- > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron > Sent: Friday, May 09, 2014 9:02 PM > To: l2vpn@ietf.org > Subject: WG LC for draft-ietf-l2vpn-evpn-07 >=20 > This email initiates an IETF L2VPN WG Last Call for: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >=20 > please comment to the list as to the suitability of this draft for public= ation as > a Standards Track RFC from the L2VPN WG. >=20 > this last call will close on Friday 23rd May 2014. >=20 > Nabil & Giles From nobody Mon May 12 04:38:14 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83A1A069B for ; Mon, 12 May 2014 04:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdq66izLXjoV for ; Mon, 12 May 2014 04:38:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) by ietfa.amsl.com (Postfix) with ESMTP id C5E411A069E for ; Mon, 12 May 2014 04:38:04 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.934.12; Mon, 12 May 2014 11:37:57 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0934.000; Mon, 12 May 2014 11:37:57 +0000 From: John E Drake To: Antoni Przygienda , "Ali Sajassi (sajassi)" , Jakob Heitz , "l2vpn@ietf.org" Subject: RE: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMz///7AeA///dMbD//1JTgA== Date: Mon, 12 May 2014 11:37:56 +0000 Message-ID: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@eusaamb109.ericsson.se> <2E4BB27CAB87BF43B4207C0E55860F1812B4B8@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1812B4B8@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(164054003)(377454003)(199002)(189002)(74316001)(80022001)(66066001)(21056001)(99286001)(46102001)(83072002)(19300405004)(85852003)(86362001)(92566001)(76176999)(19625215002)(76576001)(16236675002)(15975445006)(74662001)(2656002)(81542001)(87936001)(4396001)(101416001)(64706001)(15202345003)(31966008)(77096999)(50986999)(79102001)(19580395003)(54356999)(33646001)(76482001)(19580405001)(99396002)(81342001)(74502001)(77982001)(83322001)(20776003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: multipart/alternative; boundary="_000_cf729cd87d904d348a4bf37911346d30BLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/a4AZioVY6s-9l-URu3hF5lLSKvk X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 11:38:10 -0000 --_000_cf729cd87d904d348a4bf37911346d30BLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tony, The set of Per ESI Ethernet AD routes indicate that the advertising PE has = connectivity to the specified ES. Neither MAC Advertisement routes nor Per= EVI Ethernet routes (for aliasing) for a given ES may be used until the co= rresponding set of Per ES Ethernet AD routes for that ES have been received= . Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Antoni Przygienda Sent: Sunday, May 11, 2014 11:11 PM To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org Subject: RE: optional ethernet A-D per EVI route Actually, I'm struggling with the 'optional per EVI route' which I also thi= nk should be dropped as Jakob suggests. I'm referring to the -07 and unroll= ing the issue: Per 14.1.2 A remote PE that receives a MAC advertisement route with non- reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D per ES route for that ES. -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet A-D route per EVI exist, only then the label from that latter route *must* be used. First, should that be a capital MUST ? Second, that seems to imply that lo= ad balancing cannot be done without the per EVI route ? Or that without a p= er EVI route all-active-redundancy mode cannot install MACs from remote PEs= ? Per 8.4 Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. To address this issue, EVPN introduces the concept of 'Aliasing' which is the ability of a PE to signal that it has reachability to an EVPN instance on a given ES even when it has learnt no MAC addresses from that EVI/ES. The Ethernet A-D per EVI route is used for this purpose. A remote PE that receives a MAC advertisement route with non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND Ethernet A-D per ES routes for that ES with the 'Single-Active' bit in the flags of the ESI Label Extended Community set to 0. Now, what does that mean exactly since English is tad loose here (same as i= n 14.1.2) : the MAC is valid if (EITHER the EAD per EVI is here or EAD per ES) OR does= it imply that BOTH must be present and lack of an A-D per EVI route will = prevent aliasing (but nothing else, i.e. the route can be installed into th= e fwd path) ? Or can the MAC be installed anyway since it's all a SHOULD ? I seem to read the intention as: . if you have an EAD per EVI and _NO_ EAD per ESI you canno= t use the MAC (no load-balancing until ESI is up per section 8.4 above ) . if you have ESI only, you can (that's just aliasing) . if you have EVI _AND_ ESI, the EVI label (in the route) ta= kes precedence and we start to 'load-balance' --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:17 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Hi Jakob, We are talking about two different routes. Section 8.4.1 talks about Ethern= et A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The= former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para). For rev 7, I added a clarification sentence to the end of the 3rd para of s= ection 9.2.2 saying: "The dependency of MAC routes installation on Ethernet A-D per ES routes, is to ensure that MAC routes don't get accidentally installed during mass withdraw period." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:43 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: optional ethernet A-D per EVI route Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution ... If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to "Support of this route is OPTIONAL unles= s non-reserved ESIs are used" or just be changed to MANDATORY? Thanks, Jakob. --_000_cf729cd87d904d348a4bf37911346d30BLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tony,

 

The set of Per ESI Eth= ernet AD routes indicate that the advertising PE has connectivity to the sp= ecified ES.  Neither MAC Advertisement routes nor Per EVI Ethernet rou= tes (for aliasing) for a given ES may be used until the corresponding set of Per ES Ethernet AD routes for that ES = have been received.

 

Yours Irrespectively,<= o:p>

 

John=

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] <= b>On Behalf Of Antoni Przygienda
Sent: Sunday, May 11, 2014 11:11 PM
To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org
Subject: RE: optional ethernet A-D per EVI route

 

Actually, I’m st= ruggling with the ‘optional per EVI route’ which I also think s= hould be dropped as Jakob suggests. I’m referring to the -07 and unro= lling the issue:

 

Per 14.1.2

 

  = ;      A remote PE that receives a MAC advertiseme= nt route with non-

  = ; reserved ESI SHOULD consider the advertised MAC address to be<= /span>

  = ; reachable via all PEs that have advertised reachability to that MAC<= /o:p>

  = ; address' EVI/ES via the combination of an Ethernet A-D per EVI route=

  = ; for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D=

   per = ES route for that ES.

 

  = ; -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet<= /o:p>

  = ; A-D route per EVI exist, only then the label from that latter route<= /o:p>

  = ; *must* be used.

 

First, should t= hat be a capital MUST ?  Second, that seems to imply that load balanci= ng cannot be done without the per EVI route ? Or that without a per EVI rou= te all-active-redundancy mode cannot install MACs from remote PEs ?

 

Per 8.4

 

  = ;      Therefore, in order to handle corner cases = and race conditions, the

  = ; Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by

  = ; a remote PE until it also receives the associated set of Ethernet A-D

  = ; per ES routes.

 

  = ;      To address this issue, EVPN introduces the = concept of 'Aliasing'

  = ; which is the ability of a PE to signal that it has reachability to an

  = ; EVPN instance on a given ES even when it has learnt no MAC addresses=

  = ; from that EVI/ES. The Ethernet A-D per EVI route is used for this

  = ; purpose. A remote PE that receives a MAC advertisement route with

  = ; non-reserved ESI SHOULD consider the advertised MAC address to be

  = ; reachable via all PEs that have advertised reachability to that MAC<= /o:p>

  = ; address' EVI/ES via the combination of an Ethernet A-D per EVI route=

  = ; for that EVI/ES (and Ethernet Tag if applicable) AND Ethernet A-D per

  = ; ES routes for that ES with the 'Single-Active' bit in the flags of

  = ; the ESI Label Extended Community set to 0.

  &nb= sp;            =

Now, what does = that mean exactly since English is tad loose here (same as in 14.1.2) :

the MAC is valid if = (EITHER the EAD per EVI is here or EAD per ES) OR does it imply that  = ;BOTH must be present and lack of an A-D per EVI route will prevent aliasin= g (but nothing else, i.e. the route can be installed into the fwd path) ? Or can the MAC be installed anyway since it’s a= ll a SHOULD ?

 

I seem to read the intent= ion as:

 

        &nbs= p;      . if you have an EAD per EVI and  _NO_ EAD per ESI you cannot use the MAC (no load-balancing until ESI is= up per section 8.4 above )

        &nbs= p;      . if you have ESI only, you can (that̵= 7;s just aliasing)

        &nbs= p;      . if you have EVI _AND_ ESI, the EV= I label (in the route) takes precedence and we start to ‘load-balance= ’

 

 

--- tony

 

 

From: Ali Saja= ssi (sajassi) [mailto:sajassi@cisco.co= m]
Sent: Sunday, May 11, 2014 10:17 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: optional ethernet A-D per EVI route

 

&n= bsp;

Hi Jako= b,

&n= bsp;

We are = talking about two different routes. Section 8.4.1 talks about Ethernet A-D = per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The former= one is optional but no the latter one. As the matter of fact section 8.2.1 states that the support of the latter = one is mandatory (1st para).

&n= bsp;

For rev= 7, I added a clarification sentence to the end of the 3rd para of section = 9.2.2 saying:

&n= bsp;

       "The

dependency of MAC routes installation on Ethernet A-D<= /o:p>

per ES routes= ,

   =
is to ensure that MAC routes don't get accidentally installed during
   =
mass withdraw period."
 
Cheers,<=
/o:p>
Ali

&n= bsp;

From: jakob.heitz@e= ricsson.com>
Date: Sunday, May 11, 2014 9:43 PM
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: optional ethernet A-D per EVI route

&n= bsp;

Tony and I have an issue.

The draft says

8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route

 
 
   This section describes the procedures used to constr=
uct the Ethernet
   A-D per EVPN Instance (EVI) route, which is used for=
 aliasing (as
   discussed above). Support of this route is OPTIONAL.

 <= o:p>

And

 <= o:p>

9.2.2 Route Resolution

 

…= 

   If the Ethernet Segment Identifier field in a receiv=
ed MAC
   Advertisement route is set to a non-reserved ESI, th=
en if the
   receiving PE decides to install forwarding state for=
 the associated
   MAC address, it MUST be when both the MAC Advertisem=
ent route AND the

   associated set of Ethernet A-D per ES routes have be=
en received. 


 <=
o:p>


 <=
o:p>


Should this sentence be changed to “=
Support of this route is =
OPTIONAL unless non-reserved ESIs are used”
 or just be changed to MANDATORY?


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_cf729cd87d904d348a4bf37911346d30BLUPR05MB562namprd05pro_-- From nobody Mon May 12 10:32:05 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862B31A0751 for ; Mon, 12 May 2014 10:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sowqZuiLuAUb for ; Mon, 12 May 2014 10:31:57 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B71A074E for ; Mon, 12 May 2014 10:31:56 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-9e-5370b3cf75b3 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A1.09.02831.FC3B0735; Mon, 12 May 2014 13:43:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 12 May 2014 13:31:47 -0400 From: Antoni Przygienda To: Jakob Heitz Subject: RE: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMz///7AeA///dMbCAAF6q9///TS7Q Date: Mon, 12 May 2014 17:31:47 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1812B608@eusaamb103.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@eusaamb109.ericsson.se> , <2E4BB27CAB87BF43B4207C0E55860F1812B4B8@eusaamb103.ericsson.se> 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.12] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1812B608eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXSPn+75zQXBBj39WhaPvx1it3h3tpnF gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mro6r7KWLB9C1PFh3cfWRoYv09k6mLk5JAQ MJF4cGgDM4QtJnHh3nq2LkYuDiGBo4wSC++eY4RwljNKNNzrBatiE7CQuPztKZDNwSEioCVx 8gA7SJhZIERi4vkOsBJhAQOJl8+nsIHYIgKGEjtOPWOCsN0kpu2eDVbPIqAqsXnmCbB6XgFv ifdPulggdr1glDh0aiFYM6eAg8Sth9cYQWxGoOu+n1rDBLFMXOLWk/lQHwhILNlzHuoDUYmX j/+xQthKEnNeXwO7k1kgX+LLCjeIXYISJ2c+YZnAKDoLyaRZCFWzkFRBlOhILNj9iQ3C1pZY tvA1M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQLj6pgEm+MOxgWfLA8xCnAwKvHwLphdECzE mlhWXJl7iFGag0VJnDf9U2ywkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsas0z7BzvdT+a6e dzPXdAubMU0mKJzn0bXHpX+P1SbmpbhUHf8gZsq5YLn46+vcp5c31GbGWsk0c+bov5J0Tgte tGz9juAgm/38hY++bt5sc/CJyE2drdsmqkVHPrmVNDtgT2bxknPsXY42hRlSdQ9zQ5rePju+ XzQwz9Hzf0hJbd7TnAuhaUosxRmJhlrMRcWJAJ7/JhCMAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/DQNCm6vCNs_o01RbmBBYFUkpDtU Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:32:02 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1812B608eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, yes, that would confirm pretty much the interpretation that I came up w= ith. Agreed albeit I think it is not the easiest draft to parse to wring th= at out [alas, I didn't attend enough mike sessions over last 2 years I ass= ume] ;-} --- tony From: Jakob Heitz Sent: Sunday, May 11, 2014 11:51 PM To: Antoni Przygienda Cc: Ali Sajassi (sajassi); l2vpn@ietf.org Subject: Re: optional ethernet A-D per EVI route Tony, Ali clarified it like this for me: Aliasing requires the 'per EVI' route. A= liasing is optional. Therefore, the 'per EVI' route is optional. And I know a cat named Socrates :) -- Jakob Heitz. On May 11, 2014, at 11:10 PM, "Antoni Przygienda" > wrote: Actually, I'm struggling with the 'optional per EVI route' which I also thi= nk should be dropped as Jakob suggests. I'm referring to the -07 and unroll= ing the issue: Per 14.1.2 A remote PE that receives a MAC advertisement route with non- reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D per ES route for that ES. -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet A-D route per EVI exist, only then the label from that latter route *must* be used. First, should that be a capital MUST ? Second, that seems to imply that lo= ad balancing cannot be done without the per EVI route ? Or that without a p= er EVI route all-active-redundancy mode cannot install MACs from remote PEs= ? Per 8.4 Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. To address this issue, EVPN introduces the concept of 'Aliasing' which is the ability of a PE to signal that it has reachability to an EVPN instance on a given ES even when it has learnt no MAC addresses from that EVI/ES. The Ethernet A-D per EVI route is used for this purpose. A remote PE that receives a MAC advertisement route with non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND Ethernet A-D per ES routes for that ES with the 'Single-Active' bit in the flags of the ESI Label Extended Community set to 0. Now, what does that mean exactly since English is tad loose here (same as i= n 14.1.2) : the MAC is valid if (EITHER the EAD per EVI is here or EAD per ES) OR does= it imply that BOTH must be present and lack of an A-D per EVI route will = prevent aliasing (but nothing else, i.e. the route can be installed into th= e fwd path) ? Or can the MAC be installed anyway since it's all a SHOULD ? I seem to read the intention as: . if you have an EAD per EVI and _NO_ EAD per ESI you canno= t use the MAC (no load-balancing until ESI is up per section 8.4 above ) . if you have ESI only, you can (that's just aliasing) . if you have EVI _AND_ ESI, the EVI label (in the route) ta= kes precedence and we start to 'load-balance' --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:17 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Hi Jakob, We are talking about two different routes. Section 8.4.1 talks about Ethern= et A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The= former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para). For rev 7, I added a clarification sentence to the end of the 3rd para of s= ection 9.2.2 saying: "The dependency of MAC routes installation on Ethernet A-D per ES routes, is to ensure that MAC routes don't get accidentally installed during mass withdraw period." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:43 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: optional ethernet A-D per EVI route Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution ... If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to "Support of this route is OPTIONAL unles= s non-reserved ESIs are used" or just be changed to MANDATORY? Thanks, Jakob. --_000_2E4BB27CAB87BF43B4207C0E55860F1812B608eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Ok, yes, that would confirm = pretty much the interpretation that I came up with. Agreed albeit I think i= t is not the easiest draft to parse to wring that out [alas, I didn’t attend enough mike sessions over last 2 yea= rs  I assume] ;-}

=  

= --- tony

=  

From: Jakob Heitz
Sent: Sunday, May 11, 2014 1= 1:51 PM
To: Antoni Przygienda
Cc: Ali Sajassi (sajassi); l= 2vpn@ietf.org
Subject: Re: optional ethern= et A-D per EVI route

 

Tony,

 

Ali clarified it like this for me: Aliasing requires the 'pe= r EVI' route. Aliasing is optional. Therefore, the 'per EVI' route is optio= nal.

 

And I know a cat named Socrates :)

--

Jakob Heitz.

 


On May 11, 2014, at 11:10 PM, "Antoni Przygienda" <antoni.przygienda@ericsson.com&g= t; wrote:

= Actually, I’m struggli= ng with the ‘optional per EVI route’ which I also think should = be dropped as Jakob suggests. I’m referring to the -07 and unrolling the issue:

=  

Per 14.1.2

 <= o:p>

        A rem= ote PE that receives a MAC advertisement route with non-=

   reserved ESI SHOULD consider the ad= vertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND an Ethernet A-D

   per ES route for that ES.

 <= o:p>

   -If a set of Ethernet A-D per ES ro= utes for that ES AND an Ethernet

   A-D route per EVI exist, only then = the label from that latter route

   *must* be used.

 <= o:p>

First, should that be= a capital MUST ?  Second, that seems to imply that load balancing can= not be done without the per EVI route ? Or that without a per EVI route all-active-redundancy mode cannot install MACs fro= m remote PEs ?

 <= o:p>

Per 8.4=

 <= o:p>

        There= fore, in order to handle corner cases and race conditions, the

   Ethernet A-D per EVI route MUST NOT= be used for traffic forwarding by

   a remote PE until it also receives = the associated set of Ethernet A-D

   per ES routes.

 <= o:p>

        To ad= dress this issue, EVPN introduces the concept of 'Aliasing'

   which is the ability of a PE to sig= nal that it has reachability to an

   EVPN instance on a given ES even wh= en it has learnt no MAC addresses

   from that EVI/ES. The Ethernet A-D = per EVI route is used for this

   purpose. A remote PE that receives = a MAC advertisement route with

   non-reserved ESI SHOULD consider th= e advertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND Ethernet A-D per

   ES routes for that ES with the 'Sin= gle-Active' bit in the flags of

   the ESI Label Extended Community se= t to 0.

   &nb= sp;          

Now, what does that m= ean exactly since English is tad loose here (same as in 14.1.2) :

the MAC is valid if  (EITHER= the EAD per EVI is here or EAD per ES) OR does it imply that  BOTH mu= st be present and lack of an A-D per EVI route will prevent aliasing (but nothing else, i.e. the route can be installed into t= he fwd path) ? Or can the MAC be installed anyway since it’s all a SH= OULD ?

 

I seem to read the intention as:<= o:p>

 

          =      . if you have an EAD per EVI and  _NO_ EAD per ESI you cannot use the MA= C (no load-balancing until ESI is up per section 8.4 above )

          =      . if you have ESI only, you can (that’s just= aliasing)

          =      . if you have EVI _AND_ ESI, the EVI label (in the route) takes precedence an= d we start to ‘load-balance’

 

 

--- tony

=  

=  

From: Ali Sajassi (sajassi) [mailto:sajassi@cis= co.com]
Sent: Sunday, May 11, 2014 1= 0:17 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: optional ethern= et A-D per EVI route

 

 <= /p>

Hi Jakob,

 <= /p>

We are talking about two differe= nt routes. Section 8.4.1 talks about Ethernet A-D per EVI; whereas, section= 9.2.2 talks about Ethernet A-D per ES. The former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para).<= /span>

 <= /p>

For rev 7, I added a clarificati= on sentence to the end of the 3rd para of section 9.2.2 saying:

 <= /p>

&n= bsp;      "The

depen= dency of MAC routes installation on Ethernet A-D<= /o:p>

per ES routes,

   is t=
o ensure that MAC routes don't get accidentally installed during
   mass=
 withdraw period."
 
Cheers,
Ali=

 <= /p>

From: Jakob Heitz <jakob.heitz@ericsson.com> Date: Sunday, May 11, 2014 9= :43 PM
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: optional ethernet A= -D per EVI route

 <= /p>

Tony and I have an issue.

The draft says

8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route<= o:p>

 
 
  =
; This section describes the procedures used to construct the Ethernet
  =
; A-D per EVPN Instance (EVI) route, which is used for aliasing (as<=
/font>
  =
; discussed above). Support of this route is OPTIONAL.

 

And

 

9.2.2 Route Resolution

 

…

  =
; If the Ethernet Segment Identifier field in a received MAC<=
o:p>
  =
; Advertisement route is set to a non-reserved ESI, then if the
  =
; receiving PE decides to install forwarding state for the associated
  =
; MAC address, it MUST be when both the MAC Advertisement route AND the
  =
; associated set of Ethernet A-D per ES routes have been received. <=
/font>

 

 

Should this sentence be changed to “Sup= port of this route is OPTIONAL unless non-reserved ESIs are used<= font size=3D"1" color=3D"#a014a0" face=3D"Lucida Console">”= or just be changed to MANDATORY?

 

Thanks,

Jakob.

 

--_000_2E4BB27CAB87BF43B4207C0E55860F1812B608eusaamb103ericsso_-- From nobody Mon May 12 10:36:14 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D28F1A073C for ; Mon, 12 May 2014 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRZBgrxU2fUv for ; Mon, 12 May 2014 10:36:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 501891A0733 for ; Mon, 12 May 2014 10:36:07 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.934.12; Mon, 12 May 2014 17:35:53 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0934.000; Mon, 12 May 2014 17:35:53 +0000 From: John E Drake To: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMz///7AeA///dMbCAAF6q9///TS7QgAFnEC0= Date: Mon, 12 May 2014 17:35:53 +0000 Message-ID: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@eusaamb109.ericsson.se> , <2E4BB27CAB87BF43B4207C0E55860F1812B4B8@eusaamb103.ericsson.se> , <2E4BB27CAB87BF43B4207C0E55860F1812B608@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1812B608@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.195.180] x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(24454002)(164054003)(189002)(377454003)(199002)(66066001)(92726001)(21056001)(80022001)(99286001)(46102001)(83072002)(85852003)(86362001)(92566001)(19625215002)(76176999)(16236675002)(74662001)(15975445006)(82746002)(83716003)(81542001)(87936001)(4396001)(101416001)(64706001)(15202345003)(77982001)(31966008)(77096999)(36756003)(76482001)(19580395003)(50986999)(99396002)(19580405001)(54356999)(2656002)(79102001)(81342001)(74502001)(83322001)(20776003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: multipart/alternative; boundary="_000_A2E807E07AAB45F8B6F4CC931139C832junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/3vTBQ2LAJStqWeg4krXlDXAyUv4 Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:36:11 -0000 --_000_A2E807E07AAB45F8B6F4CC931139C832junipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just for grins try reading a 01 or 02 version of the draft. Sent from my iPhone On May 12, 2014, at 1:32 PM, "Antoni Przygienda" > wrote: Ok, yes, that would confirm pretty much the interpretation that I came up w= ith. Agreed albeit I think it is not the easiest draft to parse to wring th= at out [alas, I didn=92t attend enough mike sessions over last 2 years I a= ssume] ;-} --- tony From: Jakob Heitz Sent: Sunday, May 11, 2014 11:51 PM To: Antoni Przygienda Cc: Ali Sajassi (sajassi); l2vpn@ietf.org Subject: Re: optional ethernet A-D per EVI route Tony, Ali clarified it like this for me: Aliasing requires the 'per EVI' route. A= liasing is optional. Therefore, the 'per EVI' route is optional. And I know a cat named Socrates :) -- Jakob Heitz. On May 11, 2014, at 11:10 PM, "Antoni Przygienda" > wrote: Actually, I=92m struggling with the =91optional per EVI route=92 which I al= so think should be dropped as Jakob suggests. I=92m referring to the -07 an= d unrolling the issue: Per 14.1.2 A remote PE that receives a MAC advertisement route with non- reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D per ES route for that ES. -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet A-D route per EVI exist, only then the label from that latter route *must* be used. First, should that be a capital MUST ? Second, that seems to imply that lo= ad balancing cannot be done without the per EVI route ? Or that without a p= er EVI route all-active-redundancy mode cannot install MACs from remote PEs= ? Per 8.4 Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. To address this issue, EVPN introduces the concept of 'Aliasing' which is the ability of a PE to signal that it has reachability to an EVPN instance on a given ES even when it has learnt no MAC addresses from that EVI/ES. The Ethernet A-D per EVI route is used for this purpose. A remote PE that receives a MAC advertisement route with non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND Ethernet A-D per ES routes for that ES with the 'Single-Active' bit in the flags of the ESI Label Extended Community set to 0. Now, what does that mean exactly since English is tad loose here (same as i= n 14.1.2) : the MAC is valid if (EITHER the EAD per EVI is here or EAD per ES) OR does= it imply that BOTH must be present and lack of an A-D per EVI route will = prevent aliasing (but nothing else, i.e. the route can be installed into th= e fwd path) ? Or can the MAC be installed anyway since it=92s all a SHOULD = ? I seem to read the intention as: . if you have an EAD per EVI and _NO_ EAD per ESI you canno= t use the MAC (no load-balancing until ESI is up per section 8.4 above ) . if you have ESI only, you can (that=92s just aliasing) . if you have EVI _AND_ ESI, the EVI label (in the route) ta= kes precedence and we start to =91load-balance=92 --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:17 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Hi Jakob, We are talking about two different routes. Section 8.4.1 talks about Ethern= et A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The= former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para). For rev 7, I added a clarification sentence to the end of the 3rd para of s= ection 9.2.2 saying: "The dependency of MAC routes installation on Ethernet A-D per ES routes, is to ensure that MAC routes don't get accidentally installed during mass withdraw period." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:43 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: optional ethernet A-D per EVI route Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution =85 If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to =93Support of this route is OPTIONAL unl= ess non-reserved ESIs are used=94 or just be changed to MANDATORY? Thanks, Jakob. --_000_A2E807E07AAB45F8B6F4CC931139C832junipernet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just for grins try reading a 01 or 02 version of the draft.

Sent from my iPhone

On May 12, 2014, at 1:32 PM, "Antoni Przygienda" <antoni.przygienda@ericsson.com>= ; wrote:

= Ok, yes, that would confirm = pretty much the interpretation that I came up with. Agreed albeit I think i= t is not the easiest draft to parse to wring that out [alas, I didn=92t attend enough mike sessions over last 2 years&n= bsp; I assume] ;-}

=  

= --- tony

=  

From: Jakob Heitz
Sent: Sunday, May 11, 2014 1= 1:51 PM
To: Antoni Przygienda
Cc: Ali Sajassi (sajassi); <= a href=3D"mailto:l2vpn@ietf.org"> l2vpn@ietf.org
Subject: Re: optional ethern= et A-D per EVI route

 

Tony,

 

Ali clarified it like this for me: Aliasing requires the 'pe= r EVI' route. Aliasing is optional. Therefore, the 'per EVI' route is optio= nal.

 

And I know a cat named Socrates :)

--

Jakob Heitz.

 


On May 11, 2014, at 11:10 PM, "Antoni Przygienda" <antoni.przygienda@ericsson.com&g= t; wrote:

= Actually, I=92m struggling w= ith the =91optional per EVI route=92 which I also think should be dropped a= s Jakob suggests. I=92m referring to the -07 and unrolling the issue:

=  

Per 14.1.2

 <= o:p>

        A rem= ote PE that receives a MAC advertisement route with non-=

   reserved ESI SHOULD consider the ad= vertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND an Ethernet A-D

   per ES route for that ES.

 <= o:p>

   -If a set of Ethernet A-D per ES ro= utes for that ES AND an Ethernet

   A-D route per EVI exist, only then = the label from that latter route

   *must* be used.

 <= o:p>

First, should that be= a capital MUST ?  Second, that seems to imply that load balancing can= not be done without the per EVI route ? Or that without a per EVI route all-active-redundancy mode cannot install MACs fro= m remote PEs ?

 <= o:p>

Per 8.4=

 <= o:p>

        There= fore, in order to handle corner cases and race conditions, the

   Ethernet A-D per EVI route MUST NOT= be used for traffic forwarding by

   a remote PE until it also receives = the associated set of Ethernet A-D

   per ES routes.

 <= o:p>

        To ad= dress this issue, EVPN introduces the concept of 'Aliasing'

   which is the ability of a PE to sig= nal that it has reachability to an

   EVPN instance on a given ES even wh= en it has learnt no MAC addresses

   from that EVI/ES. The Ethernet A-D = per EVI route is used for this

   purpose. A remote PE that receives = a MAC advertisement route with

   non-reserved ESI SHOULD consider th= e advertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND Ethernet A-D per

   ES routes for that ES with the 'Sin= gle-Active' bit in the flags of

   the ESI Label Extended Community se= t to 0.

   &nb= sp;          

Now, what does that m= ean exactly since English is tad loose here (same as in 14.1.2) :

the MAC is valid if  (EITHER= the EAD per EVI is here or EAD per ES) OR does it imply that  BOTH mu= st be present and lack of an A-D per EVI route will prevent aliasing (but nothing else, i.e. the route can be installed into t= he fwd path) ? Or can the MAC be installed anyway since it=92s all a SHOULD= ?

 

I seem to read the intention as:<= o:p>

 

          =      . if you have an EAD per EVI and  _NO_ EAD per ESI you cannot use the MA= C (no load-balancing until ESI is up per section 8.4 above )

          =      . if you have ESI only, you can (that=92s just ali= asing)

          =      . if you have EVI _AND_ ESI, the EVI label (in the route) takes precedence an= d we start to =91load-balance=92

 

 

--- tony

=  

=  

From: Ali Sajassi (sajassi) [mailto:sajassi@cis= co.com]
Sent: Sunday, May 11, 2014 1= 0:17 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: optional ethern= et A-D per EVI route

 

 <= /p>

Hi Jakob,

 <= /p>

We are talking about two differe= nt routes. Section 8.4.1 talks about Ethernet A-D per EVI; whereas, section= 9.2.2 talks about Ethernet A-D per ES. The former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para).<= /span>

 <= /p>

For rev 7, I added a clarificati= on sentence to the end of the 3rd para of section 9.2.2 saying:

 <= /p>

&n= bsp;      "The

depen= dency of MAC routes installation on Ethernet A-D<= /o:p>

per ES routes,

   is t=
o ensure that MAC routes don't get accidentally installed during
   mass=
 withdraw period."
 
Cheers,
Ali=

 <= /p>

From: Jakob Heitz <jakob.heitz@ericsson.com> Date: Sunday, May 11, 2014 9= :43 PM
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: optional ethernet A= -D per EVI route

 <= /p>

Tony and I have an issue.

The draft says

8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route<= o:p>

 
 
  =
; This section describes the procedures used to construct the Ethernet
  =
; A-D per EVPN Instance (EVI) route, which is used for aliasing (as<=
/font>
  =
; discussed above). Support of this route is OPTIONAL.

 

And

 

9.2.2 Route Resolution

 

=85

  =
; If the Ethernet Segment Identifier field in a received MAC<=
o:p>
  =
; Advertisement route is set to a non-reserved ESI, then if the
  =
; receiving PE decides to install forwarding state for the associated
  =
; MAC address, it MUST be when both the MAC Advertisement route AND the
  =
; associated set of Ethernet A-D per ES routes have been received. <=
/font>

 

 

Should this sentence be changed to =93Support of this route is OPTIONAL unless non-reserved ESIs are used<= font size=3D"1" color=3D"#a014a0" face=3D"Lucida Console">=94 or = just be changed to MANDATORY?

 

Thanks,

Jakob.

 

--_000_A2E807E07AAB45F8B6F4CC931139C832junipernet_-- From nobody Mon May 12 10:37:32 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642EC1A0733 for ; Mon, 12 May 2014 10:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiE2RhWjxCsx for ; Mon, 12 May 2014 10:37:24 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9D1A0756 for ; Mon, 12 May 2014 10:37:20 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-47-5370b514e25c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 20.69.02831.415B0735; Mon, 12 May 2014 13:48:36 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Mon, 12 May 2014 13:37:13 -0400 From: Antoni Przygienda To: John E Drake , "Ali Sajassi (sajassi)" , Jakob Heitz , "l2vpn@ietf.org" Subject: RE: optional ethernet A-D per EVI route Thread-Topic: optional ethernet A-D per EVI route Thread-Index: Ac9tmo9QXH1GYTvGSny5wGqVCAmMz///7AeA///dMbD//1JTgP/+P6fg Date: Mon, 12 May 2014 17:37:13 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1812B644@eusaamb103.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053A4C@eusaamb109.ericsson.se> <2E4BB27CAB87BF43B4207C0E55860F1812B4B8@eusaamb103.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1812B644eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPrK7I1oJgg88fVS3m3HW2ePztELvF u7PNLA7MHlN+b2T1WLLkJ5PH9aar7AHMUVw2Kak5mWWpRfp2CVwZjSvnsRfsPc1U8er4ddYG xqXLmboYOTkkBEwklq3byw5hi0lcuLeerYuRi0NI4CijxLK3L6Cc5YwSVzd+AqtiE7CQuPzt KTNIQkRgIaPE2zUrmEESwgIGEi+fT2EDsUUEDCV2nHrGBGG7Sbxpn84IYrMIqEp8ObqPFcTm FfCWmD3/PxPEhgYmib8besCKOAXCJE7unQY2lBHopu+n1oANYhYQl7j1ZD7U3QISS/acZ4aw RSVePv7HCmErSUxaeo4Voj5fYsfEyUwQywQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuE rS2xbOFrZhj7zIHHTMjiCxjZVzFylBanluWmGxluYgRG1jEJNscdjAs+WR5iFOBgVOLhXTC7 IFiINbGsuDL3EKM0B4uSOG/6p9hgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyldc6XIhx/ WitoMCzfay92gsW4e516v/wGWxbbScWlMudnfnoZ+KYwrc9KY+fTZbZzN8l92PlRrqZMgn2/ 2CSVuZF3Ey4vufIlOYR3X8GGf+m6bjlb5Jb6r7074/HkLrtLX5fc2N1sr3VV0WyZzuTqL+Ur 3pazvjkxW1vF2mpflElW+hzeqiYlluKMREMt5qLiRABTy8BGjQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/OaVc1mPtj4w8rSxH8oqIUpzjdLY X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:37:29 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1812B644eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks John, my question was aimed at _optional_ A-D-E per EVI, not per ES.= Per ES are clear (and so I think the optional per EVI as well in its inten= tion). Thanks. tony From: John E Drake [mailto:jdrake@juniper.net] Sent: Monday, May 12, 2014 4:38 AM To: Antoni Przygienda; Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org Subject: RE: optional ethernet A-D per EVI route Tony, The set of Per ESI Ethernet AD routes indicate that the advertising PE has = connectivity to the specified ES. Neither MAC Advertisement routes nor Per= EVI Ethernet routes (for aliasing) for a given ES may be used until the co= rresponding set of Per ES Ethernet AD routes for that ES have been received= . Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Antoni Przygienda Sent: Sunday, May 11, 2014 11:11 PM To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org Subject: RE: optional ethernet A-D per EVI route Actually, I'm struggling with the 'optional per EVI route' which I also thi= nk should be dropped as Jakob suggests. I'm referring to the -07 and unroll= ing the issue: Per 14.1.2 A remote PE that receives a MAC advertisement route with non- reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D per ES route for that ES. -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet A-D route per EVI exist, only then the label from that latter route *must* be used. First, should that be a capital MUST ? Second, that seems to imply that lo= ad balancing cannot be done without the per EVI route ? Or that without a p= er EVI route all-active-redundancy mode cannot install MACs from remote PEs= ? Per 8.4 Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. To address this issue, EVPN introduces the concept of 'Aliasing' which is the ability of a PE to signal that it has reachability to an EVPN instance on a given ES even when it has learnt no MAC addresses from that EVI/ES. The Ethernet A-D per EVI route is used for this purpose. A remote PE that receives a MAC advertisement route with non-reserved ESI SHOULD consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address' EVI/ES via the combination of an Ethernet A-D per EVI route for that EVI/ES (and Ethernet Tag if applicable) AND Ethernet A-D per ES routes for that ES with the 'Single-Active' bit in the flags of the ESI Label Extended Community set to 0. Now, what does that mean exactly since English is tad loose here (same as i= n 14.1.2) : the MAC is valid if (EITHER the EAD per EVI is here or EAD per ES) OR does= it imply that BOTH must be present and lack of an A-D per EVI route will = prevent aliasing (but nothing else, i.e. the route can be installed into th= e fwd path) ? Or can the MAC be installed anyway since it's all a SHOULD ? I seem to read the intention as: . if you have an EAD per EVI and _NO_ EAD per ESI you canno= t use the MAC (no load-balancing until ESI is up per section 8.4 above ) . if you have ESI only, you can (that's just aliasing) . if you have EVI _AND_ ESI, the EVI label (in the route) ta= kes precedence and we start to 'load-balance' --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:17 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: optional ethernet A-D per EVI route Hi Jakob, We are talking about two different routes. Section 8.4.1 talks about Ethern= et A-D per EVI; whereas, section 9.2.2 talks about Ethernet A-D per ES. The= former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para). For rev 7, I added a clarification sentence to the end of the 3rd para of s= ection 9.2.2 saying: "The dependency of MAC routes installation on Ethernet A-D per ES routes, is to ensure that MAC routes don't get accidentally installed during mass withdraw period." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:43 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: optional ethernet A-D per EVI route Tony and I have an issue. The draft says 8.4.1 Co= nstructing the Ethernet A-D per EVPN Instance (EVI) Route This section describes the procedures used to construct the Ethernet A-D per EVPN Instance (EVI) route, which is used for aliasing (as discussed above). Support of this route is OPTIONAL. And 9.2.2 Ro= ute Resolution ... If the Ethernet Segment Identifier field in a received MAC Advertisement route is set to a non-reserved ESI, then if the receiving PE decides to install forwarding state for the associated MAC address, it MUST be when both the MAC Advertisement route AND the associated set of Ethernet A-D per ES routes have been received. Should this sentence be changed to "Support of this route is OPTIONAL unles= s non-reserved ESIs are used" or just be changed to MANDATORY? Thanks, Jakob. --_000_2E4BB27CAB87BF43B4207C0E55860F1812B644eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Thanks John, my question was= aimed at _optional_ A-D-E = per EVI, not per ES. Per ES are clear (and so I think the optional per EVI as well in its intention). Thanks. tony<= /o:p>

=  

From: John E Drake [mailto:jdrake@juniper.net]
Sent: Monday, May 12, 2014 4= :38 AM
To: Antoni Przygienda; Ali S= ajassi (sajassi); Jakob Heitz; l2vpn@ietf.org
Subject: RE: optional ethern= et A-D per EVI route

 

= Tony,

=  

= The set of Per ESI Ethernet = AD routes indicate that the advertising PE has connectivity to the specifie= d ES.  Neither MAC Advertisement routes nor Per EVI Ethernet routes (for aliasing) for a given ES may be used until th= e corresponding set of Per ES Ethernet AD routes for that ES have been rece= ived.

=  

= Yours Irrespectively,

=  

= John

=  

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Antoni Przygien= da
Sent: Sunday, May 11, 2014 1= 1:11 PM
To: Ali Sajassi (sajassi); J= akob Heitz; l2vpn@ietf.org
Subject: RE: optional ethern= et A-D per EVI route

 

= Actually, I’m struggli= ng with the ‘optional per EVI route’ which I also think should = be dropped as Jakob suggests. I’m referring to the -07 and unrolling the issue:

=  

Per 14.1.2

 

        A rem= ote PE that receives a MAC advertisement route with non-<= /font>

   reserved ESI SHOULD consider the ad= vertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND an Ethernet A-D

   per ES route for that ES.<= /span>

 

   -If a set of Ethernet A-D per ES ro= utes for that ES AND an Ethernet

   A-D route per EVI exist, only then = the label from that latter route

   *must* be used.

 

First, should that be= a capital MUST ?  Second, that seems to imply that load balancing can= not be done without the per EVI route ? Or that without a per EVI route all-active-redundancy mode cannot install MACs fro= m remote PEs ?

 

Per 8.4

 

        There= fore, in order to handle corner cases and race conditions, the

   Ethernet A-D per EVI route MUST NOT= be used for traffic forwarding by

   a remote PE until it also receives = the associated set of Ethernet A-D

   per ES routes.

 

        To ad= dress this issue, EVPN introduces the concept of 'Aliasing'

   which is the ability of a PE to sig= nal that it has reachability to an

   EVPN instance on a given ES even wh= en it has learnt no MAC addresses

   from that EVI/ES. The Ethernet A-D = per EVI route is used for this

   purpose. A remote PE that receives = a MAC advertisement route with

   non-reserved ESI SHOULD consider th= e advertised MAC address to be

   reachable via all PEs that have adv= ertised reachability to that MAC

   address' EVI/ES via the combination= of an Ethernet A-D per EVI route

   for that EVI/ES (and Ethernet Tag i= f applicable) AND Ethernet A-D per

   ES routes for that ES with the 'Sin= gle-Active' bit in the flags of

   the ESI Label Extended Community se= t to 0.

   &nb= sp;          

Now, what does that m= ean exactly since English is tad loose here (same as in 14.1.2) :

the MAC is valid if  (EITHER= the EAD per EVI is here or EAD per ES) OR does it imply that  BOTH mu= st be present and lack of an A-D per EVI route will prevent aliasing (but nothing else, i.e. the route can be installed into t= he fwd path) ? Or can the MAC be installed anyway since it’s all a SH= OULD ?

 

I seem to read the intention as:<= o:p>

 

          =      . if you have an EAD per EVI and  _NO_ EAD per ESI you cannot use the MA= C (no load-balancing until ESI is up per section 8.4 above )

          =      . if you have ESI only, you can (that’s just= aliasing)

          =      . if you have EVI _AND_ ESI, the EVI label (in the route) takes precedence an= d we start to ‘load-balance’

 

 

--- tony

=  

=  

From: Ali Sajassi (sajassi) [mailto:sajassi@cis= co.com]
Sent: Sunday, May 11, 2014 1= 0:17 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: optional ethern= et A-D per EVI route

 

 <= /p>

Hi Jakob,

 <= /p>

We are talking about two differe= nt routes. Section 8.4.1 talks about Ethernet A-D per EVI; whereas, section= 9.2.2 talks about Ethernet A-D per ES. The former one is optional but no the latter one. As the matter of fact sectio= n 8.2.1 states that the support of the latter one is mandatory (1st para).<= o:p>

 <= /p>

For rev 7, I added a clarificati= on sentence to the end of the 3rd para of section 9.2.2 saying:<= /span>

 <= /p>

&n= bsp;      "Thedepen= dency of MAC routes installation on Ethernet A-D

per ES routes,

   is t=
o ensure that MAC routes don't get accidentally installed during=

   mass=
 withdraw period."
 =

Cheers,
Ali

 <= /p>

From: Jakob Heitz <jakob.heitz@ericsson.com> Date: Sunday, May 11, 2014 9= :43 PM
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: optional ethernet A= -D per EVI route

 <= /p>

Tony and I have an issue.

The draft says

8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route<= font color=3D"black"><= /h4> 
 
 
  =
; This section describes the procedures used to construct the Ethernet
  =
; A-D per EVPN Instance (EVI) route, which is used for aliasing (as<=
/font><=
/font>
  =
; discussed above). Support of this route is OPTIONAL.

 

And

 

9.2.2 Route Resolution

 

…

  =
; If the Ethernet Segment Identifier field in a received MAC<=
font color=3D"black"><=
/pre>

  =
; Advertisement route is set to a non-reserved ESI, then if the


  =
; receiving PE decides to install forwarding state for the associated


  =
; MAC address, it MUST be when both the MAC Advertisement route AND the


  =
; associated set of Ethernet A-D per ES routes have been received. <=
/font><=
/font>


 


 


Should this sentence be changed to “Sup=
port
 of this route is OPTIONAL unless non-reserved ESIs are used<=
font size=3D"1" color=3D"#a014a0" face=3D"Lucida Console">”=
 or just be changed to MANDATORY?


 


Thanks,


Jakob.


 

--_000_2E4BB27CAB87BF43B4207C0E55860F1812B644eusaamb103ericsso_-- From nobody Mon May 12 17:47:47 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C481A07D4 for ; Mon, 12 May 2014 17:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO4RnRgVcxsI for ; Mon, 12 May 2014 17:47:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 466401A07B3 for ; Mon, 12 May 2014 17:47:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEB79595; Tue, 13 May 2014 00:47:37 +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.3.158.1; Tue, 13 May 2014 01:46:03 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 13 May 2014 01:47:36 +0100 Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.73]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 13 May 2014 08:47:32 +0800 From: Mingui Zhang To: Giles Heron , "l2vpn@ietf.org" Subject: RE: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Topic: WG LC for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPa4cfDryNSdVoAUuZObmInhgeSZs9sn4g Date: Tue, 13 May 2014 00:47:31 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7336E2F25@nkgeml508-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Wj6edXAI6X-zXVIWiMPZ6O7mErQ X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 00:47:46 -0000 Support for publication. Thanks, Mingui >-----Original Message----- >From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron >Sent: Friday, May 09, 2014 9:02 PM >To: l2vpn@ietf.org >Subject: WG LC for draft-ietf-l2vpn-evpn-07 > >This email initiates an IETF L2VPN WG Last Call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >please comment to the list as to the suitability of this draft for publica= tion as a >Standards Track RFC from the L2VPN WG. > >this last call will close on Friday 23rd May 2014. > >Nabil & Giles From nobody Mon May 12 18:03:50 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C571A07DB; Mon, 12 May 2014 18:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4ZMj_jY_que; Mon, 12 May 2014 18:03:43 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0221A07D9; Mon, 12 May 2014 18:03:43 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 41F5912EB996; Tue, 13 May 2014 09:03:28 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id D458C71E3D2; Tue, 13 May 2014 09:03:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4D13Q2B097982; Tue, 13 May 2014 09:03:26 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) In-Reply-To: References: To: Giles Heron Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 MIME-Version: 1.0 X-KeepSent: C4B82006:C4B336B7-48257CD7:00057DE8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: chen.ran@zte.com.cn Date: Tue, 13 May 2014 09:03:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-13 09:03:27, Serialize complete at 2014-05-13 09:03:27 Content-Type: multipart/alternative; boundary="=_alternative 0005C14448257CD7_=" X-MAIL: mse02.zte.com.cn s4D13Q2B097982 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/hzGyYP9cdb-OaBGtEDQ8pIIEvds Cc: "l2vpn@ietf.org" , L2vpn X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 01:03:47 -0000 This is a multipart message in MIME format. --=_alternative 0005C14448257CD7_= Content-Type: text/plain; charset="US-ASCII" Support. Ran Chen > -----Original Message----- > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron > Sent: Friday, May 09, 2014 9:02 PM > To: l2vpn@ietf.org > Subject: WG LC for draft-ietf-l2vpn-evpn-07 > > This email initiates an IETF L2VPN WG Last Call for: > > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > > please comment to the list as to the suitability of this draft for publication as > a Standards Track RFC from the L2VPN WG. > > this last call will close on Friday 23rd May 2014. > > Nabil & Giles --=_alternative 0005C14448257CD7_= Content-Type: text/html; charset="US-ASCII" Support.
Ran Chen


> -----Original Message-----
> From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron
> Sent: Friday, May 09, 2014 9:02 PM
> To: l2vpn@ietf.org
> Subject: WG LC for draft-ietf-l2vpn-evpn-07
>
> This email initiates an IETF L2VPN WG Last Call for:
>
> http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07
>
> please comment to the list as to the suitability of this draft for publication as
> a Standards Track RFC from the L2VPN WG.
>
> this last call will close on Friday 23rd May 2014.
>
> Nabil & Giles
 --=_alternative 0005C14448257CD7_=-- From nobody Mon May 12 23:21:32 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2103C1A03F7 for ; Mon, 12 May 2014 23:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzcFIvY_bwDO for ; Mon, 12 May 2014 23:21:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D9B151A0844 for ; Mon, 12 May 2014 23:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21304; q=dns/txt; s=iport; t=1399962081; x=1401171681; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=wQWU+s+kl4dJRTi2CDMx5R+Gvs5JcFb3rTEC73VUplo=; b=iy9ih+EHQqYret87OjI98zXdewuISqryjqNh/dVgBze4lrOCblt1ZYMu el30czHVsuw5StzkGalfuWd6LkfNMh426eIh/LUkprHEvEy2pDiPVR8TY rVCiGIxFVITAc7vXdYEqpIlCRiF5pCpJBCWCN3IRk88AwHp19+3gdzIeX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAO24cVOtJA2L/2dsb2JhbABZgkIjIU9YxXoBgRoWdIIlAQEBBC1MEgEIEQMBAQEhBzkUCQgBAQQBDQWIQQHQbBeOQREGAQaEOgSFeJNQkweDNoIv X-IronPort-AV: E=Sophos;i="4.97,1041,1389744000"; d="scan'208,217";a="324222477" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 13 May 2014 06:21:18 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4D6LI8p002368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 06:21:18 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 13 May 2014 01:21:18 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA Date: Tue, 13 May 2014 06:21:18 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053BF0@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.89.9.64] Content-Type: multipart/alternative; boundary="_000_CF96FC89D38FDsajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/GNJT4VmxSJ2U_FYO5Fw7xK2uq1U Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 06:21:30 -0000 --_000_CF96FC89D38FDsajassiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF96FC89D38FDsajassiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7C509286914C6E408C7985AB9AB100B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Jakob, Antoni:

Agreed that the ARP entries can timeout independent from the MAC table= and thus the entries in MAC-VRF and ARP table can be deleted independent o= f each other. However, the existing text is still accurate. It already cove= rs the scenario that is interest to you where there are multiple IP/MAC pair advertisement for a given MAC = plus MAC-only advertisement. In such case, the withdraw of a IP/MAC pair wi= ll remove the corresponding IP/MAC entry in the ARP table but it doesn't re= move the MAC entry in the MAC-VRF table. 

I added the following couple of sentences to the end of 2nd para of se= ction 10 for further clarification:

"If the receiving PE has already received a MAC-only advertisemen= t for MACx in addition to the IPx/MACx advertisement, then when it receives= a withdraw message for the IPx/MACx, it MUST delete the corresponding entr= y from the ARP table. However, it MUST not delete the MACx entry from the MAC-VRF table unless it receives a with= draw message for MACx only."

Cheers,
Ali


From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM=
To: Jakob Heitz <jakob.heitz@ericsson.com>, Cisco Employ= ee <sajassi@cisco.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

People clear ARP caches when they get= too big. When that happens, the bridge table may not be cleared at the sam= e time or at all.

An ARP cache may have a different tim= eout than the bridge table.

A bridge can snoop ARP messages to le= arn bindings and those bindings can time out.

However, many other packets can come = from the same MAC address, keeping the MAC alive in the bridge table. In th= is case, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other t= han by snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

&nbs= p;

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 

When the IP address is dissociated wi= th the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Hi Jako= b,

&n= bsp;

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

&n= bsp;

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jak= ob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf.org" <l2vpn@ietf= .org>
Cc: Antoni Przygienda <antoni.przygi= enda@ericsson.com>
Subject: MAC route with IP

&n= bsp;

We have another issue

In section 10: ARP and ND, the draft = says:

 

   If = there are multiple IP addresses associated with a MAC address,

   the= n multiple MAC advertisement routes MUST be generated, one for

   eac= h IP address. For instance, this may be the case when there are

   bot= h an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no M=
AC route without IP exists, then the MAC address will be forgotten. Therefo=
re, we would like to add a sentence:


 


Whenever a PE advertises one or more =
MAC advertisement routes with IP address for a particular MAC address, it M=
UST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF96FC89D38FDsajassiciscocom_-- From nobody Tue May 13 09:07:17 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9411A00BC for ; Tue, 13 May 2014 09:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jevq-BrHrZ7 for ; Tue, 13 May 2014 09:07:09 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 857281A0144 for ; Tue, 13 May 2014 09:06:39 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-8a-5371f3acbd22 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7D.60.07420.CA3F1735; Tue, 13 May 2014 12:27:56 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 13 May 2014 12:06:21 -0400 From: Antoni Przygienda To: "Ali Sajassi (sajassi)" , Jakob Heitz , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaCAACfogP//2UcQgALDCwCAAEC5AA== Date: Tue, 13 May 2014 16:06:21 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1812BC4E@eusaamb103.ericsson.se> References: <2E4BB27CAB87BF43B4207C0E55860F1812B4DF@eusaamb103.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1812BC4Eeusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPgu6az4XBBvv+yVk8/naI3eLd2WYW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj6olFTAVblzJWzP8Y1sC4aCJjFyMnh4SA icTd1hNsELaYxIV764FsLg4hgaOMElO3PWKEcJYzSmzqOcAMUsUmYCFx+dtTMFtEoEZi4bf3 rCC2sICcxOeOo0wQcXmJxh9rWSHsMInDDdfAbBYBVYkVF0+C9fIKeEscOHoE7AohgQKJXRtn gcU5BfQlXmw6CVbPCHTR91NrwGYyC4hL3HoynwniUgGJJXvOM0PYohIvH/9jhbCVJCYtPccK UZ8vcXdmHzvELkGJkzOfsExgFJmFZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4 Akb2VYwcpcWpZbnpRgabGIERdEyCTXcH456XlocYBTgYlXh4F8wuCBZiTSwrrsw9xCjNwaIk zlvwJTZYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OLZHOUwT32WVk2k/PkZqZz6G3SOCL6 cbVeaL7bVNaKzx+D2zdvzz72xDzK8RzvtcONgmcXZzMVHBJxi3kjrrgiXEBT863MhKUa3Qr5 L7w1d645+45n1YnZlg0OTI+Y7qxdG+NiHebwlyuL5/Ptmrbwa33XUxprJqRksHqZRKss89bS 3j3/rxJLcUaioRZzUXEiAMuI/kqBAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/H5kIq1zBED1ACBrrcHBAXvO4EfU X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:07:13 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1812BC4Eeusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable inline From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 8:45 AM To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org Subject: Re: MAC route with IP Antoni, From: Antoni Przygienda > Date: Sunday, May 11, 2014 11:23 PM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Subject: RE: MAC route with IP Ali, there are at least two cases when receiving updates from peers which are ta= d hairy given the encoding: 1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone jus= t withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP r= outes are still valid to me or at least that could be emphasized in the dra= ft that they do (i.e. all routes are truly independent). MAC/IP routes will be independent from MAC-only route. If both are advertis= ed, then withdrawing the MAC/IP route should clean up the ARP table but not= remove the entry in the MAC-VRF. [Tony said] ack, I understood that & the draft read carefully states that i= n ARP/ND procedures. I would mildly suggest to explicitly state what you wr= ite in the draft prominently since this question will come up persistently = and misinterpretation of that clause will cause hard-to-track interop probl= ems. 2. Since we have mac based disposition there is nothing that prevents = a neighbor to advertise multiple MAC/IP routes with different labels. It s= hould obviously not imply that we have to lookup the IP address on the pack= et (if we even have one) to decide which label is needed. Should all this = labels be considered pointing to the same MAC & equivalent ? Such a conditi= on considered invalid transient and MAC labels for this MAC ignored complet= ely ? What if we get one route with the label & another without ? We use t= he label nevertheless for the same MAC ? The label represents the MAC address in case of label per MAC advertisement= . So, even when you advertise multiple IP addresses for the same MAC, they = all should use the same label. [Tony said] the 'should' will not help resolve the possible issue. I would = suggest for the draft to clearly state a 'SHOULD' and specify desired behav= ior when this clause is violated, as in: SHOULD/MAY log an error and MAY us= e any of the advertised labels. And my final interesting observation: A single primary/single backup case would be simple & easy, = the way the protocol spec stands today, I don't think there is anything tha= t prevents it from operating in multiple-primaries, multiple-backup mode = (as in two guys clear the single-active bits & all other set them) [unless = I misunderstood something massively]. Do we load balance the primaries un= til both fail & then either flood (multiple backups) or fail back on the se= condary ? For a given ES, all PEs should advertise the same redundancy group mode (ei= ther all-active or single-active mode) for that ES. Otherwise, an error sho= uld be logged. [Tony said] Again, a 'SHOULD' in the draft would be good as well: "An error= MUST be logged" would be very desirable. So, I agree with all you say, Ali, it's just I think this things deserve ex= plicit statements in the draft due to potential of causing hard-to-track de= ployments bugs and therefore easing up the life of the operators chasing st= uff like this (e.g. the last one could be a genuine hard-to-track misconfig= ). --_000_2E4BB27CAB87BF43B4207C0E55860F1812BC4Eeusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= inline

=  

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 = 8:45 AM
To: Antoni Przygienda; Jakob= Heitz; l2vpn@ietf.org
Subject: Re: MAC route with = IP

 

Antoni,

 <= /p>

From: An= toni Przygienda <anton= i.przygienda@ericsson.com>
Date: Sunday, May 11, 2014 1= 1:23 PM
To: Cisco Employee <sajassi@cisco.com>, Jakob Heitz <= jakob.heitz@ericsson.com>= ;, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: MAC route with = IP

 <= /p>

= Ali, =

=  

= there are at least two cases= when receiving updates from peers which are tad hairy given the encoding:<= /span><= /span>

=  

1.=       We receive a MAC/no-IP  & a set of MAC/IP = routes & then someone just withdraws the MAC/no-IP.  It does not s= eem very logical that the MAC/IP routes are still valid to me or at least that could be emphasized in the draft that they do (i.e.= all routes are truly independent).

 

MAC/IP routes will be independent fr= om MAC-only route. If both are advertised, then withdrawing the MAC/IP rout= e should clean up the ARP table but not remove the entry in the MAC-VRF.

[Tony said] ack, I understood that & the draft read carefu= lly states that in ARP/ND procedures. I would mildly suggest to explicitly state what you write in the draft prominently= since this question will come up persistently and misinterpretation of tha= t clause will cause hard-to-track interop problems.

 

2.=       Since we have mac based disposition there is nothin= g that prevents a neighbor to advertise multiple MAC/IP routes with differe= nt labels.  It should obviously not imply that we have to lookup the IP address on the packet (if we even have= one) to decide which label is needed.  Should all this labels be cons= idered pointing to the same MAC & equivalent ? Such a condition conside= red invalid transient and MAC labels for this MAC ignored completely ?  What if we get one route with the labe= l & another without ? We use the label nevertheless for the same MAC ?<= /span><= /span>

 

The label represents the MAC address= in case of label per MAC advertisement. So, even when you advertise multip= le IP addresses for the same MAC, they all should use the same label.

[Tony said] the ‘should’ will not help resolve the= possible issue. I would suggest for the draft to clearly state a ‘SHOULD’ and specify desired behavior when this clause= is violated, as in: SHOULD/MAY log an error and MAY use any of the adverti= sed labels.

=  

= And my final interesting obs= ervation:

=  

=     &nbs= p;          A single primary/s= ingle backup case would be simple & easy, the way the protocol spec sta= nds today, I don’t think there is anything that prevents it from operating in  multiple-primaries, multiple-back= up mode  (as in two guys clear the single-active bits & all other = set them) [unless I misunderstood something massively].   Do we l= oad balance the primaries until both fail & then either flood (multiple backups) or fail back on the secondary ?

 

For a given ES, all PEs should adver= tise the same redundancy group mode (either all-active or single-active mod= e) for that ES. Otherwise, an error should be logged.=

[Tony said] Again, a ‘SHOULD’ in the draft would b= e good as well: “An error MUST be logged”  would be very desirable.

 

So, I agree with all you say, Ali, it’s just I think thi= s things deserve explicit statements in the draft due to potential of causing hard-to-track deployments bugs and therefore e= asing up the life of the operators chasing stuff like this (e.g. the last o= ne could be a genuine hard-to-track misconfig).

 <= /p>

--_000_2E4BB27CAB87BF43B4207C0E55860F1812BC4Eeusaamb103ericsso_-- From nobody Tue May 13 09:10:42 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E46B1A011D for ; Tue, 13 May 2014 09:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLs2d_-OKOLm for ; Tue, 13 May 2014 09:10:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 688241A00BC for ; Tue, 13 May 2014 09:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36839; q=dns/txt; s=iport; t=1399997300; x=1401206900; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=0Vsc1NEpfpSqg6rioLtemSNkOvQ/AJIUIrk6g7SA6es=; b=YGvtUq7ETO/xE9HZtH5xo8kMa/fLltYAe+O/U+BYr38hR9yZ4+ygoSnP 3KheM2vJDN8sVnAUXk3fbXWh+KxZoOGlfoX3NcltzM9Wf3PQEvMHF+iXo ZViSPD8PPlDkiiiENHifmX+kA1uRa3Y/Z6DMVfNb/QWyCQISDNvEFgO7p o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAJk9clOtJA2K/2dsb2JhbABZgkIjIU9YxXoBgSIWdIIlAQEBBA4fOCYBCBEDAQEBIQEGORQJCAIEARKIQQHQaheNZ1oXAYRABIV4k1CTB4M2gi8 X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208,217";a="324547875" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 13 May 2014 15:45:10 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4DFjAbp009591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 15:45:10 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 13 May 2014 10:45:10 -0500 From: "Ali Sajassi (sajassi)" To: Antoni Przygienda , Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: AQHPbsJRaQfHHQKqR0C1MGMVDrT48w== Date: Tue, 13 May 2014 15:45:08 +0000 Message-ID: In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1812B4DF@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.48] Content-Type: multipart/alternative; boundary="_000_CF970326D3932sajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/71dXvf2d0NHw7ezTfq75qjZPX3Y X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:10:38 -0000 --_000_CF970326D3932sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Antoni, From: Antoni Przygienda > Date: Sunday, May 11, 2014 11:23 PM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Subject: RE: MAC route with IP Ali, there are at least two cases when receiving updates from peers which are ta= d hairy given the encoding: 1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone jus= t withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP r= outes are still valid to me or at least that could be emphasized in the dra= ft that they do (i.e. all routes are truly independent). MAC/IP routes will be independent from MAC-only route. If both are advertis= ed, then withdrawing the MAC/IP route should clean up the ARP table but not= remove the entry in the MAC-VRF. 2. Since we have mac based disposition there is nothing that prevents = a neighbor to advertise multiple MAC/IP routes with different labels. It s= hould obviously not imply that we have to lookup the IP address on the pack= et (if we even have one) to decide which label is needed. Should all this = labels be considered pointing to the same MAC & equivalent ? Such a conditi= on considered invalid transient and MAC labels for this MAC ignored complet= ely ? What if we get one route with the label & another without ? We use t= he label nevertheless for the same MAC ? The label represents the MAC address in case of label per MAC advertisement= . So, even when you advertise multiple IP addresses for the same MAC, they = all should use the same label. And my final interesting observation: A single primary/single backup case would be simple & easy, = the way the protocol spec stands today, I don=92t think there is anything t= hat prevents it from operating in multiple-primaries, multiple-backup mode= (as in two guys clear the single-active bits & all other set them) [unles= s I misunderstood something massively]. Do we load balance the primaries = until both fail & then either flood (multiple backups) or fail back on the = secondary ? For a given ES, all PEs should advertise the same redundancy group mode (ei= ther all-active or single-active mode) for that ES. Otherwise, an error sho= uld be logged. Cheers, Ali Otherwise, very good draft I think solving tons of hard problems in (for th= e customer and in terms of protocols mechanics) fairly elegant way. --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:53 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Yes, but that's the case when that MAC address is associated with other IP = addresses per my example below. And as long as there are other ARP entry (o= r entries) for that MAC address after deleting that IP/MAC pair, the MAC ad= dress will remain in the MAC-VRF. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:38 PM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF970326D3932sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <46754F69BF98A048B31F610D722AB28E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Antoni,


= Ali,

=  

= there are at least two cases= when receiving updates from peers which are tad hairy given the encoding:<= o:p>

=  

1.      We receive a MAC/no-IP  & a set of MAC= /IP routes & then someone just withdraws the MAC/no-IP.  It does n= ot seem very logical that the MAC/IP routes are still valid to me or at least that could be emphasized in the draft that they do= (i.e. all routes are truly independent).

MAC/IP routes will = be independent from MAC-only route. If both are advertised, then withdrawin= g the MAC/IP route should clean up the ARP table but not remove the entry i= n the MAC-VRF.
 

2.      Since we have mac based disposition there is no= thing that prevents a neighbor to advertise multiple MAC/IP routes with dif= ferent labels.  It should obviously not imply that we have to lookup the IP address on the packet (if we even = have one) to decide which label is needed.  Should all this labels be = considered pointing to the same MAC & equivalent ? Such a condition con= sidered invalid transient and MAC labels for this MAC ignored completely ?  What if we get one route with the = label & another without ? We use the label nevertheless for the same MA= C ?

The label represent= s the MAC address in case of label per MAC advertisement. So, even when you= advertise multiple IP addresses for the same MAC, they all should use the = same label.

=  

= And my final interesting obs= ervation:

=  

=     &nbs= p;          A single primary/s= ingle backup case would be simple & easy, the way the protocol spec sta= nds today, I don=92t think there is anything that prevents it from operating in  multiple-primaries, multiple-back= up mode  (as in two guys clear the single-active bits & all other = set them) [unless I misunderstood something massively].   Do we l= oad balance the primaries until both fail & then either flood (multiple backups) or fail back on the secondary ?

For a given ES, all= PEs should advertise the same redundancy group mode (either all-active or = single-active mode) for that ES. Otherwise, an error should be logged.

Cheers,
Ali

=

=  

= Otherwise, very good draft I= think solving tons of hard problems in (for the customer and in terms of p= rotocols mechanics) fairly elegant way.

=  

= --- tony

=

From:= Ali Sajassi (sajassi) [mailto:sajassi@cis= co.com]
Sent: Sunday, May 11, 2014 1= 0:53 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with = IP

 

 <= /p>

Yes, but that's the case when th= at MAC address is associated with other IP addresses per my example below. = And as long as there are other ARP entry (or entries) for that MAC address after deleting that IP/MAC pair, the MAC add= ress will remain in the MAC-VRF. 

 <= /p>

Cheers,=

Ali

 <= /p>

From: Jakob Heitz <jakob.heitz@ericsson.com><= br> Date: Sunday, May 11, 2014 1= 0:38 PM
To: Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: RE: MAC route with = IP

 <= /p>

When the IP address is dissociated with the MAC addre= ss, but the MAC address still exits.

 

Cheers,

Jakob.

 

From:= Ali Sajassi (= sajassi) [mailto:sajassi@cisco.com= ]
Sent: Sunday, May 11, 2014 1= 0:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with = IP

 <= /p>

 

Hi Jakob,

 

I believe the currency text is c= orrect and sufficient. What use case do you have in mind? 

 

EVPN PE devices that only do L2 = (w/ flooding), only advertise MAC route (w/o IP address) and EVPN PE device= s that do L2 w/ ARP suppression, advertise both MAC and IP. In the latter case, if there are several IP addresses map= to the same MAC address, then the MAC address from MAC-VRF only gets remov= ed, when there is no more ARP entry with that MAC address.

 

Cheers,

Ali

 

From: Jakob Heitz <jakob.heitz@ericsson.com><= br> Date: Sunday, May 11, 2014 9= :56 PM
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.= com>
Subject: MAC route with IP

 

We have another issue

In section 10: ARP and ND, the draft says:

 

   If there are multiple IP= addresses associated with a MAC address,

   then multiple MAC advert= isement routes MUST be generated, one for

   each IP address. For ins= tance, this may be the case when there are

   both an IPv4 and an IPv6= address associated with the MAC address.

 

  =
; When the IP address is dissociated with the MAC address, then the MAC
  =
; advertisement route with that particular IP address MUST be=
=

  =
; withdrawn.

 

If such a route is withdrawn and no MAC route without= IP exists, then the MAC address will be forgotten. Therefore, we would like to add a sentence:

 

Whenever a PE advertises one or more MAC advertisemen= t routes with IP address for a particular MAC address, it MUST also advertise one MAC advertisement route without an= IP address for that MAC address.

 

Thanks,

Jakob.

 

 --_000_CF970326D3932sajassiciscocom_-- From nobody Tue May 13 09:28:35 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87E41A00BC for ; Tue, 13 May 2014 09:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNzopIfH29pV for ; Tue, 13 May 2014 09:28:30 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B8F831A00B2 for ; Tue, 13 May 2014 09:28:29 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-15-5371f664f844 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F2.B3.02831.466F1735; Tue, 13 May 2014 12:39:32 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 13 May 2014 12:28:22 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kA= Date: Tue, 13 May 2014 16:28:21 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053BF0@eusaamb109.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXSPt27qt8Jgg+f8Fo+/HWK3eHe2mcWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyvgwaS5bwcdTjBU3509hbWC8tpmxi5GTQ0LA ROJBwwlmCFtM4sK99WxdjFwcQgJHGSVOb1rMBpIQEljOKPFkLhOIzSagI/HtehdYg4hAiMTp vhawQcwCZhKdNyezg9jCAnISnzuOMkHUyEs0/ljLCmH7SXR/ecsCYrMIqEo82XsBbA6vgK/E jT1vWCB2FUk8mTIdaA4HB6eAvsTzeX4gYUag276fWsMEsUpc4taT+UwQNwtILNlzHup+UYmX j/+xQthKEpOWnmOFqM+XuPRyHRPEKkGJkzOfsExgFJ2FZNQsJGWzkJRBxHUkFuz+xAZha0ss W/iaGcY+c+AxE7L4Akb2VYwcpcWpZbnpRoabGIFRdUyCzXEH44JPlocYBTgYlXh4F8wuCBZi TSwrrsw9xCjNwaIkzpv+KTZYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+Osov9XNgQI3TC2 EdEv5J/9diGTVVFbRqn+m5OnZ6SejBeUO+J+SVXO+WfXjs3PpzxSYEjWUnl/RHVXn8u0vd+2 3Du2eeH3wASP6y+mSqWEBO2IlrdTVukvvZTwIF8j7sG6y8xvL/rIVXMWHLdU5+Jv90rZcDYk 6BfjI+X0y/cXSM6cvrih2VmJpTgj0VCLuag4EQDs2LTDiwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/do07ULIHN0aRz-Mxwa7sPSCzpAw Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:28:32 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Saja= ssi (sajassi) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Jakob, = Antoni:

&n= bsp;

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. =

&n= bsp;

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

&n= bsp;

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

&n= bsp;

Cheers,=

Ali

&n= bsp;

&n= bsp;

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

People clear ARP caches when they get too = big. When that happens, the bridge table may not be cleared at the same tim= e or at all.

An ARP cache may have a different timeout = than the bridge table.=

A bridge can snoop ARP messages to learn b= indings and those bindings can time out.=

However, many other packets can come from = the same MAC address, keeping the MAC alive in the bridge table. In this ca= se, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other than b= y snooping ARPs, by configuration, for example.

Such configurations can be removed.=

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= /a>

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= o:p>

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4eusaamb109erics_-- From nobody Tue May 13 09:30:35 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7431A0117 for ; Tue, 13 May 2014 09:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cuLGG1RQhtn for ; Tue, 13 May 2014 09:30:32 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 988841A00B2 for ; Tue, 13 May 2014 09:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25611; q=dns/txt; s=iport; t=1399998625; x=1401208225; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Sm2juplnzd958m2L8tBi/b8WTV5lK0lYZvl//7Xihs0=; b=bNxJCR1OtaYqpKGedYsI/5pNlVR3gUYfGEhmWL2lhVilFJvOl8JLl2gV scRQJh3PT4bcySlSrdYUTwbcJTV89AV6+Zn1EOjQR+qiGfx4v+tzpQgld 986BYj060zvx1a0cccKdxjQ5kKYc0GwK8wsgzlnfSHLAazWHeNS2d/szo I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAFRIclOtJV2d/2dsb2JhbABZgkIjIU9YxX0BgSIWdIIlAQEBBA4fOCYBCBEDAQEBIQc5FAkIAgQBEhmIKAHHKBeNY1oXAYRABJlQkxCDNoIw X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208,217";a="43447073" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 13 May 2014 16:30:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4DGUOiR002172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 16:30:24 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 13 May 2014 11:30:24 -0500 From: "Ali Sajassi (sajassi)" To: Antoni Przygienda , Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: AQHPbsJRaQfHHQKqR0C1MGMVDrT485s/ANyA//+RXIA= Date: Tue, 13 May 2014 16:30:23 +0000 Message-ID: In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1812BC4E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.48] Content-Type: multipart/alternative; boundary="_000_CF979460D399Csajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/URKyXQdEEenwI5y08SrCvpvRHrU X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:30:34 -0000 --_000_CF979460D399Csajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Antoni Przygienda > Date: Tuesday, May 13, 2014 9:06 AM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Subject: RE: MAC route with IP inline From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 8:45 AM To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org Subject: Re: MAC route with IP Antoni, From: Antoni Przygienda > Date: Sunday, May 11, 2014 11:23 PM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Subject: RE: MAC route with IP Ali, there are at least two cases when receiving updates from peers which are ta= d hairy given the encoding: 1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone jus= t withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP r= outes are still valid to me or at least that could be emphasized in the dra= ft that they do (i.e. all routes are truly independent). MAC/IP routes will be independent from MAC-only route. If both are advertis= ed, then withdrawing the MAC/IP route should clean up the ARP table but not= remove the entry in the MAC-VRF. [Tony said] ack, I understood that & the draft read carefully states that i= n ARP/ND procedures. I would mildly suggest to explicitly state what you wr= ite in the draft prominently since this question will come up persistently = and misinterpretation of that clause will cause hard-to-track interop probl= ems. OK. I have already added couple of sentences to clarify this per my previou= s reply to Jakob. 2. Since we have mac based disposition there is nothing that prevents = a neighbor to advertise multiple MAC/IP routes with different labels. It s= hould obviously not imply that we have to lookup the IP address on the pack= et (if we even have one) to decide which label is needed. Should all this = labels be considered pointing to the same MAC & equivalent ? Such a conditi= on considered invalid transient and MAC labels for this MAC ignored complet= ely ? What if we get one route with the label & another without ? We use t= he label nevertheless for the same MAC ? The label represents the MAC address in case of label per MAC advertisement= . So, even when you advertise multiple IP addresses for the same MAC, they = all should use the same label. [Tony said] the =91should=92 will not help resolve the possible issue. I wo= uld suggest for the draft to clearly state a =91SHOULD=92 and specify desir= ed behavior when this clause is violated, as in: SHOULD/MAY log an error an= d MAY use any of the advertised labels. I'll take it under consideration. And my final interesting observation: A single primary/single backup case would be simple & easy, = the way the protocol spec stands today, I don=92t think there is anything t= hat prevents it from operating in multiple-primaries, multiple-backup mode= (as in two guys clear the single-active bits & all other set them) [unles= s I misunderstood something massively]. Do we load balance the primaries = until both fail & then either flood (multiple backups) or fail back on the = secondary ? For a given ES, all PEs should advertise the same redundancy group mode (ei= ther all-active or single-active mode) for that ES. Otherwise, an error sho= uld be logged. [Tony said] Again, a =91SHOULD=92 in the draft would be good as well: =93An= error MUST be logged=94 would be very desirable. OK. We'll add that. Cheers, Ali So, I agree with all you say, Ali, it=92s just I think this things deserve = explicit statements in the draft due to potential of causing hard-to-track = deployments bugs and therefore easing up the life of the operators chasing = stuff like this (e.g. the last one could be a genuine hard-to-track misconf= ig). --_000_CF979460D399Csajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable



= inline

=  

From:= Ali Sajassi (sajassi) [mailto:sajassi@cis= co.com]
Sent: Tuesday, May 13, 2014 = 8:45 AM
To: Antoni Przygienda; Jakob= Heitz; l2vpn@ietf.org
Subject: Re: MAC route with = IP

 

Antoni,

 <= /p>

From: Antoni Przygienda = <antoni.przygienda@eri= csson.com>
Date: Sunday, May 11, 2014 1= 1:23 PM
To: Cisco Employee <sajassi@cisco.com>, Jakob Heitz <= jakob.heitz@ericsson.com>= ;, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: MAC route with = IP

 <= /p>

= Ali, =

=  

= there are at least two cases= when receiving updates from peers which are tad hairy given the encoding:<= /span><= /span>

=  

= 1.      We receive a MAC/no-IP  & a set of MAC= /IP routes & then someone just withdraws the MAC/no-IP.  It does n= ot seem very logical that the MAC/IP routes are still valid to me or at least that could be emphasized in the draft that they do= (i.e. all routes are truly independent).

 

MAC/IP routes will be independent fr= om MAC-only route. If both are advertised, then withdrawing the MAC/IP rout= e should clean up the ARP table but not remove the entry in the MAC-VRF.

[Tony said] ack, I understood that & the draft read carefu= lly states that in ARP/ND procedures. I would mildly suggest to explicitly state what you write in the draft prominently= since this question will come up persistently and misinterpretation of tha= t clause will cause hard-to-track interop problems.


OK. I have already added couple of sentences to clarify this per my pr= evious reply to Jakob.

 

= 2.      Since we have mac based disposition there is no= thing that prevents a neighbor to advertise multiple MAC/IP routes with dif= ferent labels.  It should obviously not imply that we have to lookup the IP address on the packet (if we even = have one) to decide which label is needed.  Should all this labels be = considered pointing to the same MAC & equivalent ? Such a condition con= sidered invalid transient and MAC labels for this MAC ignored completely ?  What if we get one route with the = label & another without ? We use the label nevertheless for the same MA= C ?

 

The label represents the MAC address= in case of label per MAC advertisement. So, even when you advertise multip= le IP addresses for the same MAC, they all should use the same label.

[Tony said] the =91should=92 will not help resolve the possibl= e issue. I would suggest for the draft to clearly state a =91SHOULD=92 and specify desired behavior when this clause is viol= ated, as in: SHOULD/MAY log an error and MAY use any of the advertised labe= ls.

I'll take it under consideration.

=  

= And my final interesting obs= ervation:

=  

=     &nbs= p;          A single primary/s= ingle backup case would be simple & easy, the way the protocol spec sta= nds today, I don=92t think there is anything that prevents it from operating in  multiple-primaries, multiple-back= up mode  (as in two guys clear the single-active bits & all other = set them) [unless I misunderstood something massively].   Do we l= oad balance the primaries until both fail & then either flood (multiple backups) or fail back on the secondary ?

 

For a given ES, all PEs should adver= tise the same redundancy group mode (either all-active or single-active mod= e) for that ES. Otherwise, an error should be logged.=

[Tony said] Again, a =91SHOULD=92 in the draft would be good a= s well: =93An error MUST be logged=94  would be very desirable.


OK. We'll add that.

Cheers,
Ali

 

So, I agree with all you say, Ali, it=92s just I think this th= ings deserve explicit statements in the draft due to potential of causing hard-to-track deployments bugs and therefore e= asing up the life of the operators chasing stuff like this (e.g. the last o= ne could be a genuine hard-to-track misconfig).

 <= /p>

--_000_CF979460D399Csajassiciscocom_-- From nobody Tue May 13 09:35:02 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58911A012E for ; Tue, 13 May 2014 09:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_vKbMZXtKf5 for ; Tue, 13 May 2014 09:34:56 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7A61A011A for ; Tue, 13 May 2014 09:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28684; q=dns/txt; s=iport; t=1399998890; x=1401208490; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=3ZJ6DbUEsXnr/Dq0WP1mfZN18Ctfp8gWhWuPVaxvnH0=; b=cFIbKldduga7Ylg27gFtOIUuc2hXJTB9aNOgQladvU7gZJPi3UvgEsQH Dh6Wwxx8J/XfWyIQPSikOF/8kJ+u1wYVV7EN2zo0I5LoXGgllMj2f2MOB 3KkkONIDgai4dSVvbJXAOVUwU9xJ9J0Vr6W2nzVp/IneTnPYBbLCNPNAN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAE5JclOtJA2J/2dsb2JhbABZgkIjIU9YxX0BgSIWdIIlAQEBBC1MEgEIEQMBAQEhAQY5FAkIAgQBDQWIQQHHGxeOPREGAQaEOgSFeJNYkxCDNoIw X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208,217";a="43455893" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 13 May 2014 16:34:49 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4DGYnZr009875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 16:34:49 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.03.0123.003; Tue, 13 May 2014 11:34:49 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gA== Date: Tue, 13 May 2014 16:34:48 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.48] Content-Type: multipart/alternative; boundary="_000_CF9796B2D39B1sajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/RdrPSU_tyRfLV_PTCRJkWXo9524 Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:35:00 -0000 --_000_CF9796B2D39B1sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jakob, If there is no MAC-only route, then it is fine as well =96 e.g., we don't n= eed the MAC-only route for the MAC/IP route to work. If there is only MAC/I= P route, the FIB entry will be populated based on that route and if it is w= ithdrawn, then FIB entry gets deleted. However, if there are both MAC/IP ro= ute and MAC-only route, and one of them gets withdrawn, then the FIB entry = will still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF9796B2D39B1sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Jakob,

If there is no MAC-only route, then it is fine as well =96 e.g., we do= n't need the MAC-only route for the MAC/IP route to work. If there is only = MAC/IP route, the FIB entry will be populated based on that route and if it= is withdrawn, then FIB entry gets deleted. However, if there are both MAC/IP route and MAC-only route, and o= ne of them gets withdrawn, then the FIB entry will still exist. This is the= correct behavior.

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM=
To: Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

 

&n= bsp;

Jakob, = Antoni:

&n= bsp;

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. =

&n= bsp;

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

&n= bsp;

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

&n= bsp;

Cheers,=

Ali

&n= bsp;

&n= bsp;

From: Jakob Heitz <jakob.heitz= @ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

People clear ARP caches when they get= too big. When that happens, the bridge table may not be cleared at the sam= e time or at all.

An ARP cache may have a different tim= eout than the bridge table.

A bridge can snoop ARP messages to le= arn bindings and those bindings can time out.

However, many other packets can come = from the same MAC address, keeping the MAC alive in the bridge table. In th= is case, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other t= han by snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

 

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated wi= th the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft = says:

 

   If = there are multiple IP addresses associated with a MAC address,

   the= n multiple MAC advertisement routes MUST be generated, one for

   eac= h IP address. For instance, this may be the case when there are

   bot= h an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no M=
AC route without IP exists, then the MAC address will be forgotten. Therefo=
re, we would like to add a sentence:


 


Whenever a PE advertises one or more =
MAC advertisement routes with IP address for a particular MAC address, it M=
UST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF9796B2D39B1sajassiciscocom_-- From nobody Tue May 13 09:37:44 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A8D1A0087 for ; Tue, 13 May 2014 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiDxVLypySE3 for ; Tue, 13 May 2014 09:37:39 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0AECB1A00B2 for ; Tue, 13 May 2014 09:37:29 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-af-5371faead35d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A9.22.07420.AEAF1735; Tue, 13 May 2014 12:58:50 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 13 May 2014 12:37:17 -0400 From: Jakob Heitz To: Antoni Przygienda , "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaCAACfogP//2UcQgALDCwCAAEC5AIAAd5lA Date: Tue, 13 May 2014 16:37:15 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055F87@eusaamb109.ericsson.se> References: <2E4BB27CAB87BF43B4207C0E55860F1812B4DF@eusaamb103.ericsson.se> <2E4BB27CAB87BF43B4207C0E55860F1812BC4E@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1812BC4E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055F87eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPuO6rX4XBBs9/WVs8/naI3eLd2WYW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjQ+MLpoLlyxgrpl9Zz97AeH4CYxcjJ4eE gIlE49f1TBC2mMSFe+vZuhi5OIQEjjJKPJhznQUkISSwnFGi80gkiM0moCPx7XoXM0iRiEAH o8TCh9PBJgkLyEl87jgKNklEQF6i8cdaVgg7SqJnwxN2EJtFQFXi+OtGoA0cHLwCvhJ9k8oh lm1ilGjubgCr4RTwkThwfyEziM0IdNH3U2vAZjILiEvcejIf6lIBiSV7zjND2KISLx//Y4Ww lSQmLT3HClGfL9HZvRvM5hUQlDg58wnLBEaRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh 7DMHHjMhiy9gZF/FyFFanFqWm25ksIkRGEPHJNh0dzDueWl5iFGAg1GJh3fB7IJgIdbEsuLK 3EOM0hwsSuK8BV9ig4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwrng7W+Z9AKfqR8VbezKY o6ccaV6TKGMsuJVPW+2745zslTLc+lICIiVlV2R66oKeNjDfNJ2Y0Pdu1+dU+xkPaxl/iAZ/ 2JcaxHXhWKT1FMu7V+sjvnbMqlQ+f0Olo05uxmQp4+NFrbaTJKb+e2M72UX/mb7DM4GIu9kF l74sWccwL/5+efQ9JZbijERDLeai4kQAHOYE6oICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/5b7v2LuyKOGSczsBlgsONOH5VJ8 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:37:42 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055F87eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How do we write code for the receiver if it receives different labels on th= e different MAC routes? Say we receive, in order: MAC1/IP1 Label1 MAC1/no-IP Label2 MAC1/IP2 Label1 The sender might have sent, in order: MAC1/IP1 Label1 MAC1/IP2 Label1 MAC1/no-IP Label2 A route reflector can reflect routes in a different order than it received = them. Which label should the receiver program? Thanks, Jakob. From: Antoni Przygienda Sent: Tuesday, May 13, 2014 9:06 AM To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org Subject: RE: MAC route with IP inline From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 8:45 AM To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org Subject: Re: MAC route with IP Antoni, From: Antoni Przygienda > Date: Sunday, May 11, 2014 11:23 PM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Subject: RE: MAC route with IP Ali, there are at least two cases when receiving updates from peers which are ta= d hairy given the encoding: 1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone ju= st withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP = routes are still valid to me or at least that could be emphasized in the dr= aft that they do (i.e. all routes are truly independent). MAC/IP routes will be independent from MAC-only route. If both are advertis= ed, then withdrawing the MAC/IP route should clean up the ARP table but not= remove the entry in the MAC-VRF. [Tony said] ack, I understood that & the draft read carefully states that i= n ARP/ND procedures. I would mildly suggest to explicitly state what you wr= ite in the draft prominently since this question will come up persistently = and misinterpretation of that clause will cause hard-to-track interop probl= ems. 2. Since we have mac based disposition there is nothing that prevents= a neighbor to advertise multiple MAC/IP routes with different labels. It = should obviously not imply that we have to lookup the IP address on the pac= ket (if we even have one) to decide which label is needed. Should all this= labels be considered pointing to the same MAC & equivalent ? Such a condit= ion considered invalid transient and MAC labels for this MAC ignored comple= tely ? What if we get one route with the label & another without ? We use = the label nevertheless for the same MAC ? The label represents the MAC address in case of label per MAC advertisement= . So, even when you advertise multiple IP addresses for the same MAC, they = all should use the same label. [Tony said] the 'should' will not help resolve the possible issue. I would = suggest for the draft to clearly state a 'SHOULD' and specify desired behav= ior when this clause is violated, as in: SHOULD/MAY log an error and MAY us= e any of the advertised labels. And my final interesting observation: A single primary/single backup case would be simple & easy, = the way the protocol spec stands today, I don't think there is anything tha= t prevents it from operating in multiple-primaries, multiple-backup mode = (as in two guys clear the single-active bits & all other set them) [unless = I misunderstood something massively]. Do we load balance the primaries un= til both fail & then either flood (multiple backups) or fail back on the se= condary ? For a given ES, all PEs should advertise the same redundancy group mode (ei= ther all-active or single-active mode) for that ES. Otherwise, an error sho= uld be logged. [Tony said] Again, a 'SHOULD' in the draft would be good as well: "An error= MUST be logged" would be very desirable. So, I agree with all you say, Ali, it's just I think this things deserve ex= plicit statements in the draft due to potential of causing hard-to-track de= ployments bugs and therefore easing up the life of the operators chasing st= uff like this (e.g. the last one could be a genuine hard-to-track misconfig= ). --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055F87eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How do we write code f= or the receiver if it receives different labels on the different MAC routes= ?

Say we receive, in ord= er:

MAC1/IP1 Label1

MAC1/no-IP Label2=

MAC1/IP2 Label1

 

The sender might have = sent, in order:

MAC1/IP1 Label1

MAC1/IP2 Label1

MAC1/no-IP Label2=

 

A route reflector can = reflect routes in a different order than it received them.

Which label should the= receiver program?

 

Thanks,

Jakob.

 

 

From: Antoni P= rzygienda
Sent: Tuesday, May 13, 2014 9:06 AM
To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org
Subject: RE: MAC route with IP

 

inline

 

From: Ali Saja= ssi (sajassi) [mailto:sajassi@cisco.co= m]
Sent: Tuesday, May 13, 2014 8:45 AM
To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org
Subject: Re: MAC route with IP

 

Antoni,

&n= bsp;

From: Antoni Przygienda <antoni.przygienda@ericsson.com>
Date: Sunday, May 11, 2014 11:23 PM
To: Cisco Employee <sajassi@= cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Subject: RE: MAC route with IP

&n= bsp;

Ali,

 

there are at least two= cases when receiving updates from peers which are tad hairy given the enco= ding:

 

1.  =      We receive a M= AC/no-IP  & a set of MAC/IP routes & then someone just withdra= ws the MAC/no-IP.  It does not seem very logical that the MAC/IP route= s are still valid to me or at least that could be emphasized in the draft that they do (i.e. all routes are truly independent).<= span style=3D"color:black">

 

MAC/IP ro= utes will be independent from MAC-only route. If both are advertised, then = withdrawing the MAC/IP route should clean up the ARP table but not remove t= he entry in the MAC-VRF.=

[Tony said] ack,= I understood that & the draft read carefully states that in ARP/ND pro= cedures. I would mildly suggest to explicitly state what you write in the d= raft prominently since this question will come up persistently and misinterpretation of that clause will cause hard-= to-track interop problems.

 

2.  =      Since we have = mac based disposition there is nothing that prevents a neighbor to advertis= e multiple MAC/IP routes with different labels.  It should obviously n= ot imply that we have to lookup the IP address on the packet (if we even have one) to decide which label is neede= d.  Should all this labels be considered pointing to the same MAC &= ; equivalent ? Such a condition considered invalid transient and MAC labels= for this MAC ignored completely ?  What if we get one route with the label & another without ? We use the labe= l nevertheless for the same MAC ?

 

The label= represents the MAC address in case of label per MAC advertisement. So, eve= n when you advertise multiple IP addresses for the same MAC, they all shoul= d use the same label.

[Tony said] the = ‘should’ will not help resolve the possible issue. I would sugg= est for the draft to clearly state a ‘SHOULD’ and specify desir= ed behavior when this clause is violated, as in: SHOULD/MAY log an error and MAY use any of the advertised labels.

 

And my final interesti= ng observation:

 

   &nbs= p;           A single pri= mary/single backup case would be simple & easy, the way the protocol sp= ec stands today, I don’t think there is anything that prevents it fro= m operating in  multiple-primaries, multiple-backup mode  (as in two guys clear the single-active bits & all other se= t them) [unless I misunderstood something massively].   Do we loa= d balance the primaries until both fail & then either flood (multiple b= ackups) or fail back on the secondary ?<= o:p>

 

For a giv= en ES, all PEs should advertise the same redundancy group mode (either all-= active or single-active mode) for that ES. Otherwise, an error should be lo= gged.

[Tony said] Agai= n, a ‘SHOULD’ in the draft would be good as well: “An err= or MUST be logged”  would be very desirable.

 

So, I agree with= all you say, Ali, it’s just I think this things deserve explicit sta= tements in the draft due to potential of causing hard-to-track deployments = bugs and therefore easing up the life of the operators chasing stuff like this (e.g. the last one could be a genuine ha= rd-to-track misconfig).

 =

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055F87eusaamb109erics_-- From nobody Tue May 13 09:43:09 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5591A0116 for ; Tue, 13 May 2014 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiVyeVxhuwfJ for ; Tue, 13 May 2014 09:43:01 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C71A0102 for ; Tue, 13 May 2014 09:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23454; q=dns/txt; s=iport; t=1399999374; x=1401208974; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=jWckuCcYuaYZic0Y2oof6TrPIL+okv26EOAFtvRdO/g=; b=dtmOojr7j0+Sfw9jFThJ53mTtNqC3Tk6KfXVEk3pwac9DJ517rpue+gY 3lbf1d4VFewX71b09O31e9OjkSmYv4Br0YCdA4syXjQLaHM5AToMhL22a uC8E/RxVqok506/E4GI/SHRHfCA3dqnOBHFIKqLmHB3/4rRvjhSN8Pr0Q k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFALNKclOtJA2M/2dsb2JhbABZgkIjIU9YxX0BgSIWdIIlAQEBBA4fOCYBCBEDAQEBIQc5FAkIAgQBEhmIKAHHHBeNY1oXAYRABJVXg3mTEIM2gjA X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208,217";a="43444196" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 13 May 2014 16:42:54 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4DGgsXL002432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 16:42:54 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 13 May 2014 11:42:54 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , Antoni Przygienda , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: AQHPbsJRaQfHHQKqR0C1MGMVDrT485s/ANyAgAAIooD//4w4gA== Date: Tue, 13 May 2014 16:42:53 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055F87@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.48] Content-Type: multipart/alternative; boundary="_000_CF9798C1D39C0sajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/l4EvpvDaxmxCHwC4HVV9QfZzGuw X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:43:04 -0000 --_000_CF9798C1D39C0sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The labels should all be the same. In case of EVI-based disposition, the la= bel identifies the EVI and a MAC lookup is performed based on the MAC. Thus= , the order of routes in which they are received, doesn't matter. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:37 AM To: Antoni Przygienda >, Cisco Employee >, "l2vpn@ietf.org" > Subject: RE: MAC route with IP How do we write code for the receiver if it receives different labels on th= e different MAC routes? Say we receive, in order: MAC1/IP1 Label1 MAC1/no-IP Label2 MAC1/IP2 Label1 The sender might have sent, in order: MAC1/IP1 Label1 MAC1/IP2 Label1 MAC1/no-IP Label2 A route reflector can reflect routes in a different order than it received = them. Which label should the receiver program? Thanks, Jakob. From: Antoni Przygienda Sent: Tuesday, May 13, 2014 9:06 AM To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org Subject: RE: MAC route with IP inline From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 8:45 AM To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org Subject: Re: MAC route with IP Antoni, From: Antoni Przygienda > Date: Sunday, May 11, 2014 11:23 PM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Subject: RE: MAC route with IP Ali, there are at least two cases when receiving updates from peers which are ta= d hairy given the encoding: 1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone ju= st withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP = routes are still valid to me or at least that could be emphasized in the dr= aft that they do (i.e. all routes are truly independent). MAC/IP routes will be independent from MAC-only route. If both are advertis= ed, then withdrawing the MAC/IP route should clean up the ARP table but not= remove the entry in the MAC-VRF. [Tony said] ack, I understood that & the draft read carefully states that i= n ARP/ND procedures. I would mildly suggest to explicitly state what you wr= ite in the draft prominently since this question will come up persistently = and misinterpretation of that clause will cause hard-to-track interop probl= ems. 2. Since we have mac based disposition there is nothing that prevents= a neighbor to advertise multiple MAC/IP routes with different labels. It = should obviously not imply that we have to lookup the IP address on the pac= ket (if we even have one) to decide which label is needed. Should all this= labels be considered pointing to the same MAC & equivalent ? Such a condit= ion considered invalid transient and MAC labels for this MAC ignored comple= tely ? What if we get one route with the label & another without ? We use = the label nevertheless for the same MAC ? The label represents the MAC address in case of label per MAC advertisement= . So, even when you advertise multiple IP addresses for the same MAC, they = all should use the same label. [Tony said] the =91should=92 will not help resolve the possible issue. I wo= uld suggest for the draft to clearly state a =91SHOULD=92 and specify desir= ed behavior when this clause is violated, as in: SHOULD/MAY log an error an= d MAY use any of the advertised labels. And my final interesting observation: A single primary/single backup case would be simple & easy, = the way the protocol spec stands today, I don=92t think there is anything t= hat prevents it from operating in multiple-primaries, multiple-backup mode= (as in two guys clear the single-active bits & all other set them) [unles= s I misunderstood something massively]. Do we load balance the primaries = until both fail & then either flood (multiple backups) or fail back on the = secondary ? For a given ES, all PEs should advertise the same redundancy group mode (ei= ther all-active or single-active mode) for that ES. Otherwise, an error sho= uld be logged. [Tony said] Again, a =91SHOULD=92 in the draft would be good as well: =93An= error MUST be logged=94 would be very desirable. So, I agree with all you say, Ali, it=92s just I think this things deserve = explicit statements in the draft due to potential of causing hard-to-track = deployments bugs and therefore easing up the life of the operators chasing = stuff like this (e.g. the last one could be a genuine hard-to-track misconf= ig). --_000_CF9798C1D39C0sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1D898758C759E747BB3F2A9D0D430F18@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

The labels should all be the same. In case of EVI-based disposition, t= he label identifies the EVI and a MAC lookup is performed based on the MAC.= Thus, the order of routes in which they are received, doesn't matter.

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:37 AM=
To: Antoni Przygienda <antoni.przygienda@ericsson.com>, Cisco Employee <sajassi@cis= co.com>, "l2vpn@ietf.org&= quot; <l2vpn@ietf.org>
Subject: RE: MAC route with IP

How do we write code f= or the receiver if it receives different labels on the different MAC routes= ?

Say we receive, in ord= er:

MAC1/IP1 Label1

MAC1/no-IP Label2=

MAC1/IP2 Label1

 

The sender might have = sent, in order:

MAC1/IP1 Label1

MAC1/IP2 Label1

MAC1/no-IP Label2=

 

A route reflector can = reflect routes in a different order than it received them.

Which label should the= receiver program?

 

Thanks,

Jakob.

 

 

From: Antoni Przygienda
Sent: Tuesday, May 13, 2014 9:06 AM
To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org
Subject: RE: MAC route with IP

 

inline

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 8:45 AM
To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org
Subject: Re: MAC route with IP

 

Antoni,

&n= bsp;

From: Antoni Przygienda <antoni.przygienda@ericsson.com>
Date: Sunday, May 11, 2014 11:23 PM
To: Cisco Employee <sajassi@= cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Subject: RE: MAC route with IP

&n= bsp;

Ali,

 

there are at least two= cases when receiving updates from peers which are tad hairy given the enco= ding:

 

1. &n= bsp;     We receive= a MAC/no-IP  & a set of MAC/IP routes & then someone just wit= hdraws the MAC/no-IP.  It does not seem very logical that the MAC/IP r= outes are still valid to me or at least that could be emphasized in the draft that they do (i.e. all routes are truly independen= t).

 

MAC/IP ro= utes will be independent from MAC-only route. If both are advertised, then = withdrawing the MAC/IP route should clean up the ARP table but not remove t= he entry in the MAC-VRF.=

[Tony said] ack,= I understood that & the draft read carefully states that in ARP/ND pro= cedures. I would mildly suggest to explicitly state what you write in the d= raft prominently since this question will come up persistently and misinterpretation of that clause will cause hard-= to-track interop problems.

 

2. &n= bsp;     Since we h= ave mac based disposition there is nothing that prevents a neighbor to adve= rtise multiple MAC/IP routes with different labels.  It should obvious= ly not imply that we have to lookup the IP address on the packet (if we even have one) to decide which label is ne= eded.  Should all this labels be considered pointing to the same MAC &= amp; equivalent ? Such a condition considered invalid transient and MAC lab= els for this MAC ignored completely ?  What if we get one route with the label & another without ? We use the labe= l nevertheless for the same MAC ?

 

The label= represents the MAC address in case of label per MAC advertisement. So, eve= n when you advertise multiple IP addresses for the same MAC, they all shoul= d use the same label.

[Tony said] the = =91should=92 will not help resolve the possible issue. I would suggest for = the draft to clearly state a =91SHOULD=92 and specify desired behavior when= this clause is violated, as in: SHOULD/MAY log an error and MAY use any of the advertised labels.

 

And my final interesti= ng observation:

 

   &nbs= p;           A single pri= mary/single backup case would be simple & easy, the way the protocol sp= ec stands today, I don=92t think there is anything that prevents it from op= erating in  multiple-primaries, multiple-backup mode  (as in two guys clear the single-active bits & all other se= t them) [unless I misunderstood something massively].   Do we loa= d balance the primaries until both fail & then either flood (multiple b= ackups) or fail back on the secondary ?<= o:p>

 

For a giv= en ES, all PEs should advertise the same redundancy group mode (either all-= active or single-active mode) for that ES. Otherwise, an error should be lo= gged.

[Tony said] Agai= n, a =91SHOULD=92 in the draft would be good as well: =93An error MUST be l= ogged=94  would be very desirable.

 

So, I agree with= all you say, Ali, it=92s just I think this things deserve explicit stateme= nts in the draft due to potential of causing hard-to-track deployments bugs= and therefore easing up the life of the operators chasing stuff like this (e.g. the last one could be a genuine ha= rd-to-track misconfig).

 =

--_000_CF9798C1D39C0sajassiciscocom_-- From nobody Tue May 13 09:44:12 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470841A0127 for ; Tue, 13 May 2014 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSKG5uycVznZ for ; Tue, 13 May 2014 09:44:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B56B31A0131 for ; Tue, 13 May 2014 09:44:03 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-5d-5371fc7ada84 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C1.82.07420.A7CF1735; Tue, 13 May 2014 13:05:30 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 13 May 2014 12:43:51 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA Date: Tue, 13 May 2014 16:43:50 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4@eusaamb109.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPoG7Vn8Jgg+UvdSwefzvEbvHubDOL A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRPe0zc8GaFqaKU08+sjYwbn3G2MXIySEh YCIxeesqVghbTOLCvfVsXYxcHEICRxkl7i7qYYRwljNKtD7sBetgE9CR+Ha9ixnEFhEIkTjd 1wIWZxYwk+i8OZkdxBYWkJP43HGUCaJGXqLxx1pWCDtKYtXfL2BxFgFViT8PToDFeQV8JW49 WAPWKyRQJLFrVSeYzSmgL/H19m02EJsR6Lrvp9YwQewSl7j1ZD4TxNUCEkv2nGeGsEUlXj7+ B/WNksSkpedYIerzJRY9+sEGsUtQ4uTMJywTGEVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+ Zoaxzxx4zIQsvoCRfRUjR2lxalluupHBJkZgbB2TYNPdwbjnpeUhRgEORiUe3gWzC4KFWBPL iitzDzFKc7AoifMWfIkNFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY71TpbLnM6F5q9cpo 66pZeYtPnOO8sacgZIdAr83qE7PO7DW/evRib5d74clKjVUeMzkzpt/hUP3Pd36PzbIXTy9z cgqLLLVd9b2V4Y+12P6XTkYpJzi38h5pCX21fvFH0y6u8IS6ZeuEldrua13l1vvgN3d26a1n E/q5BRoPzS268kSx+gmnEktxRqKhFnNRcSIAlo3/WY4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/_CduUjwq0qV6WQ4rdpZLipiN-6s Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:44:09 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well - e.g., we don't nee= d the MAC-only route for the MAC/IP route to work. If there is only MAC/IP = route, the FIB entry will be populated based on that route and if it is wit= hdrawn, then FIB entry gets deleted. However, if there are both MAC/IP rout= e and MAC-only route, and one of them gets withdrawn, then the FIB entry wi= ll still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more MAC a= dvertisement routes with IP address for a particular MAC address, it MUST a= lso advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Saja= ssi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Jakob,<= o:p>

&n= bsp;

If ther= e is no MAC-only route, then it is fine as well – e.g., we don't need= the MAC-only route for the MAC/IP route to work. If there is only MAC/IP r= oute, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get too = big. When that happens, the bridge table may not be cleared at the same tim= e or at all.

An ARP cache may have a different timeout = than the bridge table.=

A bridge can snoop ARP messages to learn b= indings and those bindings can time out.=

However, many other packets can come from = the same MAC address, keeping the MAC alive in the bridge table. In this ca= se, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other than b= y snooping ARPs, by configuration, for example.

Such configurations can be removed.=

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= /a>

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= o:p>

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7eusaamb109erics_-- From nobody Tue May 13 09:49:45 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091C21A016A for ; Tue, 13 May 2014 09:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMZkk1eubdD6 for ; Tue, 13 May 2014 09:49:37 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5C501A0173 for ; Tue, 13 May 2014 09:49:08 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-b0-5371fdab12b6 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.C2.07420.BADF1735; Tue, 13 May 2014 13:10:35 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 13 May 2014 12:49:01 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" , Antoni Przygienda , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaCAACfogP//2UcQgALDCwCAAEC5AIAAd5lA//9X0YAACDNHcA== Date: Tue, 13 May 2014 16:49:00 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03056030@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055F87@eusaamb109.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056030eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXSPt+7qv4XBBievqFo8/naI3eLd2WYW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj9Q6Ogn/nGSu2vXrN3sC4cxtjFyMnh4SA icScNWvYIWwxiQv31rN1MXJxCAkcZZQ4sf0bM4SznFFi5drTTCBVbAI6Et+ud4ElRAQ6GCWe vf7HDJIQFpCT+NxxFKxIREBeovHHWlYIO0ui4fttMJtFQFWic9YNsBpeAV+JZ4++g50hJFAk 0fvjDwuIzSmgL7H0aD/YSYxAJ30/tQasnllAXOLWk/lMEKcKSCzZc54ZwhaVePn4HyuErSQx aek5Voj6fIlPayBu4BUQlDg58wnLBEaRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMH HjMhiy9gZF/FyFFanFqWm25ksIkRGEPHJNh0dzDueWl5iFGAg1GJh3fB7IJgIdbEsuLK3EOM 0hwsSuK8BV9ig4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwml03YNyTe+wvg1EgT3nuT9cr /CaftZhZDhzNKM5ZLMK05Mgnt2NRrdyS6ZwaIolMj574cH9+kumfsHRR8frpb+Wmplna60Rv DMm/xaC0e/IGJr/d8XYzWGUkgiRvTWzIOfx1XcQUzr8CDPevTAmbrcr1wWLTVOGUmIat83T2 /ZVxrTRctDNQiaU4I9FQi7moOBEAULOQbYICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Kxl7scfEpeCAK69cXmwNosCogLc X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:49:42 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056030eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Error handling for the error of receiving different labels: Treat-as-withdr= aw ? Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:43 AM To: Jakob Heitz; Antoni Przygienda; l2vpn@ietf.org Subject: Re: MAC route with IP The labels should all be the same. In case of EVI-based disposition, the la= bel identifies the EVI and a MAC lookup is performed based on the MAC. Thus= , the order of routes in which they are received, doesn't matter. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:37 AM To: Antoni Przygienda >, Cisco Employee >, "l2vpn@ietf.org" > Subject: RE: MAC route with IP How do we write code for the receiver if it receives different labels on th= e different MAC routes? Say we receive, in order: MAC1/IP1 Label1 MAC1/no-IP Label2 MAC1/IP2 Label1 The sender might have sent, in order: MAC1/IP1 Label1 MAC1/IP2 Label1 MAC1/no-IP Label2 A route reflector can reflect routes in a different order than it received = them. Which label should the receiver program? Thanks, Jakob. From: Antoni Przygienda Sent: Tuesday, May 13, 2014 9:06 AM To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org Subject: RE: MAC route with IP inline From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 8:45 AM To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org Subject: Re: MAC route with IP Antoni, From: Antoni Przygienda > Date: Sunday, May 11, 2014 11:23 PM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Subject: RE: MAC route with IP Ali, there are at least two cases when receiving updates from peers which are ta= d hairy given the encoding: 1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone ju= st withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP = routes are still valid to me or at least that could be emphasized in the dr= aft that they do (i.e. all routes are truly independent). MAC/IP routes will be independent from MAC-only route. If both are advertis= ed, then withdrawing the MAC/IP route should clean up the ARP table but not= remove the entry in the MAC-VRF. [Tony said] ack, I understood that & the draft read carefully states that i= n ARP/ND procedures. I would mildly suggest to explicitly state what you wr= ite in the draft prominently since this question will come up persistently = and misinterpretation of that clause will cause hard-to-track interop probl= ems. 2. Since we have mac based disposition there is nothing that prevents= a neighbor to advertise multiple MAC/IP routes with different labels. It = should obviously not imply that we have to lookup the IP address on the pac= ket (if we even have one) to decide which label is needed. Should all this= labels be considered pointing to the same MAC & equivalent ? Such a condit= ion considered invalid transient and MAC labels for this MAC ignored comple= tely ? What if we get one route with the label & another without ? We use = the label nevertheless for the same MAC ? The label represents the MAC address in case of label per MAC advertisement= . So, even when you advertise multiple IP addresses for the same MAC, they = all should use the same label. [Tony said] the 'should' will not help resolve the possible issue. I would = suggest for the draft to clearly state a 'SHOULD' and specify desired behav= ior when this clause is violated, as in: SHOULD/MAY log an error and MAY us= e any of the advertised labels. And my final interesting observation: A single primary/single backup case would be simple & easy, = the way the protocol spec stands today, I don't think there is anything tha= t prevents it from operating in multiple-primaries, multiple-backup mode = (as in two guys clear the single-active bits & all other set them) [unless = I misunderstood something massively]. Do we load balance the primaries un= til both fail & then either flood (multiple backups) or fail back on the se= condary ? For a given ES, all PEs should advertise the same redundancy group mode (ei= ther all-active or single-active mode) for that ES. Otherwise, an error sho= uld be logged. [Tony said] Again, a 'SHOULD' in the draft would be good as well: "An error= MUST be logged" would be very desirable. So, I agree with all you say, Ali, it's just I think this things deserve ex= plicit statements in the draft due to potential of causing hard-to-track de= ployments bugs and therefore easing up the life of the operators chasing st= uff like this (e.g. the last one could be a genuine hard-to-track misconfig= ). --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056030eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Error handling for the= error of receiving different labels: Treat-as-withdraw ?=

 

Thanks,

Jakob.

 

From: Ali Saja= ssi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:43 AM
To: Jakob Heitz; Antoni Przygienda; l2vpn@ietf.org
Subject: Re: MAC route with IP

 

&n= bsp;

The lab= els should all be the same. In case of EVI-based disposition, the label ide= ntifies the EVI and a MAC lookup is performed based on the MAC. Thus, the o= rder of routes in which they are received, doesn't matter.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:37 AM
To: Antoni Przygienda <antoni.przygienda@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: MAC route with IP

&n= bsp;

How do we write code f= or the receiver if it receives different labels on the different MAC routes= ?

Say we receive, in ord= er:

MAC1/IP1 Label1=

MAC1/no-IP Label2

MAC1/IP2 Label1=

 

The sender might have = sent, in order:

MAC1/IP1 Label1=

MAC1/IP2 Label1=

MAC1/no-IP Label2

 

A route reflector can = reflect routes in a different order than it received them.

Which label should the= receiver program?

 

Thanks,

Jakob.

 

 

From: Antoni Przygienda
Sent: Tuesday, May 13, 2014 9:06 AM
To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org
Subject: RE: MAC route with IP

 =

inline

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 8:45 AM
To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org
Subject: Re: MAC route with IP

 =

Antoni,

 <= /span>

From: Antoni Przygienda <antoni.przygienda@ericsson.com>
Date: Sunday, May 11, 2014 11:23 PM
To: Cisco Employee <sajassi@= cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Subject: RE: MAC route with IP

 <= /span>

Ali,

 

there are at least two= cases when receiving updates from peers which are tad hairy given the enco= ding:

 

1.  =      We receive a M= AC/no-IP  & a set of MAC/IP routes & then someone just withdra= ws the MAC/no-IP.  It does not seem very logical that the MAC/IP route= s are still valid to me or at least that could be emphasized in the draft that they do (i.e. all routes are truly independent).<= span style=3D"color:black">

 <= /span>

MAC/IP ro= utes will be independent from MAC-only route. If both are advertised, then = withdrawing the MAC/IP route should clean up the ARP table but not remove t= he entry in the MAC-VRF.

[Tony said] ack,= I understood that & the draft read carefully states that in ARP/ND pro= cedures. I would mildly suggest to explicitly state what you write in the d= raft prominently since this question will come up persistently and misinterpretation of that clause will cause hard-= to-track interop problems.

 

2.  =      Since we have = mac based disposition there is nothing that prevents a neighbor to advertis= e multiple MAC/IP routes with different labels.  It should obviously n= ot imply that we have to lookup the IP address on the packet (if we even have one) to decide which label is neede= d.  Should all this labels be considered pointing to the same MAC &= ; equivalent ? Such a condition considered invalid transient and MAC labels= for this MAC ignored completely ?  What if we get one route with the label & another without ? We use the labe= l nevertheless for the same MAC ?

 <= /span>

The label= represents the MAC address in case of label per MAC advertisement. So, eve= n when you advertise multiple IP addresses for the same MAC, they all shoul= d use the same label.<= /p>

[Tony said] the = ‘should’ will not help resolve the possible issue. I would sugg= est for the draft to clearly state a ‘SHOULD’ and specify desir= ed behavior when this clause is violated, as in: SHOULD/MAY log an error and MAY use any of the advertised labels.

 

And my final interesti= ng observation:

 

   &nbs= p;           A single pri= mary/single backup case would be simple & easy, the way the protocol sp= ec stands today, I don’t think there is anything that prevents it fro= m operating in  multiple-primaries, multiple-backup mode  (as in two guys clear the single-active bits & all other se= t them) [unless I misunderstood something massively].   Do we loa= d balance the primaries until both fail & then either flood (multiple b= ackups) or fail back on the secondary ?<= o:p>

 <= /span>

For a giv= en ES, all PEs should advertise the same redundancy group mode (either all-= active or single-active mode) for that ES. Otherwise, an error should be lo= gged.

[Tony said] Agai= n, a ‘SHOULD’ in the draft would be good as well: “An err= or MUST be logged”  would be very desirable.

 

So, I agree with= all you say, Ali, it’s just I think this things deserve explicit sta= tements in the draft due to potential of causing hard-to-track deployments = bugs and therefore easing up the life of the operators chasing stuff like this (e.g. the last one could be a genuine ha= rd-to-track misconfig).

 =

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056030eusaamb109erics_-- From nobody Tue May 13 09:50:07 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780641A0170 for ; Tue, 13 May 2014 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRXKyEIjHvAh for ; Tue, 13 May 2014 09:49:45 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C5CA51A0167 for ; Tue, 13 May 2014 09:49:40 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-df-5371fdcb67da Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 15.D2.07420.BCDF1735; Tue, 13 May 2014 13:11:07 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 13 May 2014 12:49:30 -0400 From: Antoni Przygienda To: "Ali Sajassi (sajassi)" , Jakob Heitz , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaCAACfogP//2UcQgALDCwCAAEC5AIAAd5lA//9X0YAACFF1AA== Date: Tue, 13 May 2014 16:49:29 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1812BCE4@eusaamb103.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055F87@eusaamb109.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1812BCE4eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPuO7pv4XBBku36lk8/naI3eLd2WYW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj8b8TLAVd05kqDnWvYW9gbPjB2MXIySEh YCKx6PZ3NghbTOLCvfVANheHkMBRRomvPW2sIAkhgeWMEm92hoPYbAIWEpe/PWUGsUUEaiQW fnsPViMsICfxueMoE0RcXqLxx1pWCDtL4tnZx+wgNouAqsStmUdZQGxeAW+Jv2t7GSHmF0n0 /vgDFucU0JdYerQfrJ4R6KDvp9aAzWQWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKYStJTFp6 jhWiPl9i3byTbBC7BCVOznzCMoFRZBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdM yOILGNlXMXKUFqeW5aYbGWxiBEbQMQk23R2Me15aHmIU4GBU4uFdMLsgWIg1say4MvcQozQH i5I4b8GX2GAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjDVTavq4PytIKudMdH/91n+F0Cu3 2U7TbZ+p1F2VXdpxYPUG45U/C9+s+JDxMOS2/kPHNpvbQiEXDQR0zhTO3PlLqy776iLGwiOm aeavJXhmri84rdvfdOzIjJ/qn0yuL3gvs2lDc9NZVflpc4My12jH3RYRT+fev9jwslPb0lQp GZO/ilpWZ5VYijMSDbWYi4oTAUoH/mCBAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/3NmW9108bpjJwEYJWoDnKr70PLg X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:49:55 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F1812BCE4eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ali, as far I saw, small 'shoulds' never prevented a protocol from doing st= uff like this intentionally or unintentionally once enough people took a st= ab @ it. In my experience, the price in a spec of dense, non-orthogonal = encodings like this one is certain amount of verbiage necessary to resolve = the collisions or behavior intended on some such. I concur with Jakob as to clarification of this verbosely as well as the M= AC, MAC/IP route advertisements. I spoke up, chiming out now. Again, I think it's a great spec of high impo= rtance, otherwise I wouldn't be thinking through the possible implications = of remaining corner-cases ;-) --- tony From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:43 AM To: Jakob Heitz; Antoni Przygienda; l2vpn@ietf.org Subject: Re: MAC route with IP The labels should all be the same. In case of EVI-based disposition, the la= bel identifies the EVI and a MAC lookup is performed based on the MAC. Thus= , the order of routes in which they are received, doesn't matter. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:37 AM To: Antoni Przygienda >, Cisco Employee >, "l2vpn@ietf.org" > Subject: RE: MAC route with IP How do we write code for the receiver if it receives different labels on th= e different MAC routes? Say we receive, in order: MAC1/IP1 Label1 MAC1/no-IP Label2 MAC1/IP2 Label1 The sender might have sent, in order: MAC1/IP1 Label1 MAC1/IP2 Label1 MAC1/no-IP Label2 A route reflector can reflect routes in a different order than it received = them. Which label should the receiver program? Thanks, Jakob. From: Antoni Przygienda Sent: Tuesday, May 13, 2014 9:06 AM To: Ali Sajassi (sajassi); Jakob Heitz; l2vpn@ietf.org Subject: RE: MAC route with IP inline From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 8:45 AM To: Antoni Przygienda; Jakob Heitz; l2vpn@ietf.org Subject: Re: MAC route with IP Antoni, From: Antoni Przygienda > Date: Sunday, May 11, 2014 11:23 PM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Subject: RE: MAC route with IP Ali, there are at least two cases when receiving updates from peers which are ta= d hairy given the encoding: 1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone jus= t withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP r= outes are still valid to me or at least that could be emphasized in the dra= ft that they do (i.e. all routes are truly independent). MAC/IP routes will be independent from MAC-only route. If both are advertis= ed, then withdrawing the MAC/IP route should clean up the ARP table but not= remove the entry in the MAC-VRF. [Tony said] ack, I understood that & the draft read carefully states that i= n ARP/ND procedures. I would mildly suggest to explicitly state what you wr= ite in the draft prominently since this question will come up persistently = and misinterpretation of that clause will cause hard-to-track interop probl= ems. 2. Since we have mac based disposition there is nothing that prevents = a neighbor to advertise multiple MAC/IP routes with different labels. It s= hould obviously not imply that we have to lookup the IP address on the pack= et (if we even have one) to decide which label is needed. Should all this = labels be considered pointing to the same MAC & equivalent ? Such a conditi= on considered invalid transient and MAC labels for this MAC ignored complet= ely ? What if we get one route with the label & another without ? We use t= he label nevertheless for the same MAC ? The label represents the MAC address in case of label per MAC advertisement= . So, even when you advertise multiple IP addresses for the same MAC, they = all should use the same label. [Tony said] the 'should' will not help resolve the possible issue. I would = suggest for the draft to clearly state a 'SHOULD' and specify desired behav= ior when this clause is violated, as in: SHOULD/MAY log an error and MAY us= e any of the advertised labels. And my final interesting observation: A single primary/single backup case would be simple & easy, = the way the protocol spec stands today, I don't think there is anything tha= t prevents it from operating in multiple-primaries, multiple-backup mode = (as in two guys clear the single-active bits & all other set them) [unless = I misunderstood something massively]. Do we load balance the primaries un= til both fail & then either flood (multiple backups) or fail back on the se= condary ? For a given ES, all PEs should advertise the same redundancy group mode (ei= ther all-active or single-active mode) for that ES. Otherwise, an error sho= uld be logged. [Tony said] Again, a 'SHOULD' in the draft would be good as well: "An error= MUST be logged" would be very desirable. So, I agree with all you say, Ali, it's just I think this things deserve ex= plicit statements in the draft due to potential of causing hard-to-track de= ployments bugs and therefore easing up the life of the operators chasing st= uff like this (e.g. the last one could be a genuine hard-to-track misconfig= ). --_000_2E4BB27CAB87BF43B4207C0E55860F1812BCE4eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Ali, as far I saw, small = 216;shoulds’ never prevented a protocol from doing stuff like this in= tentionally or unintentionally once enough people took a stab @ it.  In my experience, the price in a spec of  dense,&n= bsp; non-orthogonal encodings like this one is certain amount of verbiage n= ecessary to resolve the collisions or behavior intended on some such. 

=  

= I concur with Jakob as to cl= arification of this verbosely as well as the  MAC, MAC/IP  route = advertisements.

=  

= I spoke up, chiming out now.=  Again, I think it’s a great spec of high importance, otherwise= I wouldn’t be thinking through the possible implications of remaining corner-cases  ;-)

=  

= --- tony

=  

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 = 9:43 AM
To: Jakob Heitz; Antoni Przy= gienda; l2vpn@ietf.org
Subject: Re: MAC route with = IP

 

 <= /p>

The labels should all be the sam= e. In case of EVI-based disposition, the label identifies the EVI and a MAC= lookup is performed based on the MAC. Thus, the order of routes in which they are received, doesn't matter.=

 <= /p>

Cheers,=

Ali

 <= /p>

From: Ja= kob Heitz <jakob.heitz@erics= son.com>
Date: Tuesday, May 13, 2014 = 9:37 AM
To: Antoni Przygienda <antoni.przygienda@ericsson.= com>, Cisco Employee <sajass= i@cisco.com>, "l2vpn@ietf.org= " <l2vpn@ietf.org>
Subject: RE: MAC route with = IP

 <= /p>

= How do we write code for the= receiver if it receives different labels on the different MAC routes?

= Say we receive, in order:

= MAC1/IP1 Label1

= MAC1/no-IP Label2

= MAC1/IP2 Label1

=  

= The sender might have sent, = in order:

= MAC1/IP1 Label1

= MAC1/IP2 Label1

= MAC1/no-IP Label2

=  

= A route reflector can reflec= t routes in a different order than it received them.

= Which label should the recei= ver program?

=  

= Thanks,

= Jakob.

=  

=  

= From: Antoni Przygienda
Sent: Tuesday, May 13, 2014 = 9:06 AM
To: Ali Sajassi (sajassi); J= akob Heitz; l2vpn@ietf.org
Subject: RE: MAC route with = IP

 <= /p>

= inline

=  

= From: Ali Sajassi (sajassi) [mailto:sajassi= @cisco.com]
Sent: Tuesday, May 13, 2014 = 8:45 AM
To: Antoni Przygienda; Jakob= Heitz; l2vpn@ietf.org
Subject: Re: MAC route with = IP

 <= /p>

Antoni,

 

From: An= toni Przygienda <anton= i.przygienda@ericsson.com>
Date: Sunday, May 11, 2014 1= 1:23 PM
To: Cisco Employee <sajassi@cisco.com>, Jakob Heitz <= jakob.heitz@ericsson.com>= ;, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: MAC route with = IP

 

= Ali, =

=  

= there are at least two cases= when receiving updates from peers which are tad hairy given the encoding:<= /span><= /span>

=  

1.=       We receive a MAC/no-IP  & a set of MAC/IP = routes & then someone just withdraws the MAC/no-IP.  It does not s= eem very logical that the MAC/IP routes are still valid to me or at least that could be emphasized in the draft that they do (i.e.= all routes are truly independent).

 

MAC/IP routes will be independent fr= om MAC-only route. If both are advertised, then withdrawing the MAC/IP rout= e should clean up the ARP table but not remove the entry in the MAC-VRF.

[Tony said] ack, I understood that & the draft read carefu= lly states that in ARP/ND procedures. I would mildly suggest to explicitly state what you write in the draft prominently= since this question will come up persistently and misinterpretation of tha= t clause will cause hard-to-track interop problems.

 

2.=       Since we have mac based disposition there is nothin= g that prevents a neighbor to advertise multiple MAC/IP routes with differe= nt labels.  It should obviously not imply that we have to lookup the IP address on the packet (if we even have= one) to decide which label is needed.  Should all this labels be cons= idered pointing to the same MAC & equivalent ? Such a condition conside= red invalid transient and MAC labels for this MAC ignored completely ?  What if we get one route with the labe= l & another without ? We use the label nevertheless for the same MAC ?<= /span><= /span>

 

The label represents the MAC address= in case of label per MAC advertisement. So, even when you advertise multip= le IP addresses for the same MAC, they all should use the same label.

[Tony said] the ‘should’ will not help resolve the= possible issue. I would suggest for the draft to clearly state a ‘SHOULD’ and specify desired behavior when this clause= is violated, as in: SHOULD/MAY log an error and MAY use any of the adverti= sed labels.

=  

= And my final interesting obs= ervation:

=  

=     &nbs= p;          A single primary/s= ingle backup case would be simple & easy, the way the protocol spec sta= nds today, I don’t think there is anything that prevents it from operating in  multiple-primaries, multiple-back= up mode  (as in two guys clear the single-active bits & all other = set them) [unless I misunderstood something massively].   Do we l= oad balance the primaries until both fail & then either flood (multiple backups) or fail back on the secondary ?

 

For a given ES, all PEs should adver= tise the same redundancy group mode (either all-active or single-active mod= e) for that ES. Otherwise, an error should be logged.=

[Tony said] Again, a ‘SHOULD’ in the draft would b= e good as well: “An error MUST be logged”  would be very desirable.

 

So, I agree with all you say, Ali, it’s just I think thi= s things deserve explicit statements in the draft due to potential of causing hard-to-track deployments bugs and therefore e= asing up the life of the operators chasing stuff like this (e.g. the last o= ne could be a genuine hard-to-track misconfig).

 <= /p>

--_000_2E4BB27CAB87BF43B4207C0E55860F1812BCE4eusaamb103ericsso_-- From nobody Tue May 13 10:01:09 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FAC1A00EA for ; Tue, 13 May 2014 10:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-S-3TtF9vmn for ; Tue, 13 May 2014 10:01:03 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC61A008E for ; Tue, 13 May 2014 10:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36690; q=dns/txt; s=iport; t=1400000456; x=1401210056; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=+EC6TXKdxKzQ65riGhCw2fB1YaBy2U8/VdeqBnJ3kDU=; b=XidWt2ovIGuhKshJ63l9m72kyDlA7GbaTkMxS/lpCv8aUAcNhUEISNYF 2RRP8T2x5iIaFyxeiEXy4aM0rMTmjc1SDYr1w+46Ao7XkA1ZzyuGKMaPq 60Ont/Nn+KGGYGiYLWYPrnlUrvrdVaxgcGD8lIQTGYBwNiNLkRMpuQkJi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAF1PclOtJA2G/2dsb2JhbABZgkIjIU9YxX0BgSIWdIIlAQEBBC1ADBIBCBEDAQEBIQEGORQJCAIEAQ0FG4gmAccSF449EQYBBoQ6BIV4j1+DeZMQgzaCMA X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208,217";a="43448954" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP; 13 May 2014 17:00:42 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4DH0goJ009786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 17:00:42 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 13 May 2014 12:00:41 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoA= Date: Tue, 13 May 2014 17:00:41 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.48] Content-Type: multipart/alternative; boundary="_000_CF979A14D39CBsajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/_4Py-9unG4cLmPHS-NBFqwcvG8Q Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:01:06 -0000 --_000_CF979A14D39CBsajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well =96 e.g., we don't n= eed the MAC-only route for the MAC/IP route to work. If there is only MAC/I= P route, the FIB entry will be populated based on that route and if it is w= ithdrawn, then FIB entry gets deleted. However, if there are both MAC/IP ro= ute and MAC-only route, and one of them gets withdrawn, then the FIB entry = will still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF979A14D39CBsajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I can understand that if route reflector receives different routes fro= m different speakers, then it can re-order them. But we are talking about d= ifferent routes from the same speaker (same BGP session and TCP/IP connecti= on).

In your scenario below, the if the MAC is learned via data-plane learn= ing, then the sender has already sent a MAC-only advertisement anyway, so t= here is no issue.

There can be scenarios in which both MAC/IP and MAC-only routes are ad= vertise for the same MAC and there are scenarios where only MAC/IP routes a= re advertised. I don't want to constrain the solution unnecessarily by sayi= ng that MAC-only route must be accompanied with MAC/IP route. Again, I am not precluding what you are saying. I just = don't want to make it a requirement.

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:43 AM=
To: Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more = MAC advertisement routes with IP address for a particular MAC address, it M= UST also advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

 

&n= bsp;

Jakob,<= o:p>

&n= bsp;

If ther= e is no MAC-only route, then it is fine as well =96 e.g., we don't need the= MAC-only route for the MAC/IP route to work. If there is only MAC/IP route= , the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jakob Heitz <jakob.heitz= @ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi= ) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jakob Heitz <jakob.heitz= @ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get= too big. When that happens, the bridge table may not be cleared at the sam= e time or at all.

An ARP cache may have a different tim= eout than the bridge table.

A bridge can snoop ARP messages to le= arn bindings and those bindings can time out.

However, many other packets can come = from the same MAC address, keeping the MAC alive in the bridge table. In th= is case, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other t= han by snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

 

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated wi= th the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft = says:

 

   If = there are multiple IP addresses associated with a MAC address,

   the= n multiple MAC advertisement routes MUST be generated, one for

   eac= h IP address. For instance, this may be the case when there are

   bot= h an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no M=
AC route without IP exists, then the MAC address will be forgotten. Therefo=
re, we would like to add a sentence:


 


Whenever a PE advertises one or more =
MAC advertisement routes with IP address for a particular MAC address, it M=
UST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF979A14D39CBsajassiciscocom_-- From nobody Tue May 13 10:14:24 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A599C1A0171 for ; Tue, 13 May 2014 10:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDYWjTli-ZqQ for ; Tue, 13 May 2014 10:14:17 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 905261A015B for ; Tue, 13 May 2014 10:14:17 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-07-5372038e3e44 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E7.64.07420.E8302735; Tue, 13 May 2014 13:35:43 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 13 May 2014 13:13:46 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38A== Date: Tue, 13 May 2014 17:13:45 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03056144@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056144eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPoG4/c1GwwYKP4haPvx1it3h3tpnF gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4cLa6oPUIU8XXadoNjGvmMXUxcnJICJhI PL+zmhnCFpO4cG89WxcjF4eQwFFGiY5ta5khnOWMEntOLGMFqWIT0JH4dr0LrENEIETidF8L I4jNLGAm0XlzMjuILSwgJ/G54ygTRI28ROOPtawQdpbEjp0HwepZBFQldt38wAJi8wr4Sixa 088GYgsJFEmcPbECrJdTQF/iwoa/YDMZga77fmoNE8QucYlbT+ZDfSAgsWTPeagPRCVePv7H CmErSUxaeo4Voj5f4v+bqUwQuwQlTs58wjKBUXQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFr Zhj7zIHHTMjiCxjZVzFylBanluWmGxlsYgTG1TEJNt0djHteWh5iFOBgVOLhXTC7IFiINbGs uDL3EKM0B4uSOG/Bl9hgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw7plX4bMpfXp9ifSd0 mvc1/lVljPFiM5dsYKv+vTp49hmZI+9WTRe8vShrwc9LoZvXfWQ4Y1cum/D0Z+USF1FRhxOp OasuhaiabVzZy/T8tqlMBF/sIt3XDl2K0pOL+v5+PvU0bpfr7XibtflTP7G2xgqdY0ph+PTL VWx//za+RzmhMd+aZUKUWIozEg21mIuKEwG8uxapjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/kZ95DLduSqVjLyIYqV2hi4ZUAOw Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:14:22 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056144eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don't want to make it a requirement. Then some words to alert the= implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well - e.g., we don't nee= d the MAC-only route for the MAC/IP route to work. If there is only MAC/IP = route, the FIB entry will be populated based on that route and if it is wit= hdrawn, then FIB entry gets deleted. However, if there are both MAC/IP rout= e and MAC-only route, and one of them gets withdrawn, then the FIB entry wi= ll still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056144eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A route reflector can = and frequently does reorder routes from the same speaker.=

For example, a version= walk of a tree does not walk in version order, it walks in key order.=

Fine, you don’t = want to make it a requirement. Then some words to alert the implementor

 

Whenever a PE withdraws all MAC advertisem= ent routes with IP address for a particular MAC address, but it still knows= the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address well in adv= ance of the withdrawals. This is because BGP announcements of different rou= tes are not required to be received in the same order in which they were se= nt.

 

Cheers,

Jakob.

 

From: Ali Saja= ssi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

&n= bsp;

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

&n= bsp;

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more MAC a= dvertisement routes with IP address for a particular MAC address, it MUST a= lso advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well – e.g., we don't need= the MAC-only route for the MAC/IP route to work. If there is only MAC/IP r= oute, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get too = big. When that happens, the bridge table may not be cleared at the same tim= e or at all.

An ARP cache may have a different timeout = than the bridge table.=

A bridge can snoop ARP messages to learn b= indings and those bindings can time out.=

However, many other packets can come from = the same MAC address, keeping the MAC alive in the bridge table. In this ca= se, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other than b= y snooping ARPs, by configuration, for example.

Such configurations can be removed.=

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= /a>

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= o:p>

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056144eusaamb109erics_-- From nobody Tue May 13 10:25:12 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5BA1A017F for ; Tue, 13 May 2014 10:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCo66medMvJK for ; Tue, 13 May 2014 10:25:05 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id CDF131A0179 for ; Tue, 13 May 2014 10:25:04 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4DHOqCq018321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2014 12:24:53 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s4DHOolZ016428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 19:24:51 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.243]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 13 May 2014 19:24:51 +0200 From: "Rabadan, Jorge (Jorge)" To: Jakob Heitz , "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//pmIA Date: Tue, 13 May 2014 17:24:51 +0000 Message-ID: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E03056144@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03056144@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_CF97A2A9412ECjorgerabadanalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/oXD4yrnaR1RWOZVeFgUuBr_RRkc Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:25:09 -0000 --_000_CF97A2A9412ECjorgerabadanalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ali and Jakob, I totally agree with Ali and would not like to add that requirement. Advertising mac-only + mac/ip or only mac/ip depends on how you learn the I= P and how you learn the mac address. Normally both will be advertised if da= ta plane learning is done, since the source mac learning and the snooping o= f the control packets to get the IP are independent processes. But in hyper= visor-based NVE cases, MAC/IP can be learnt at once through control/managem= ent plane so in that case a single mac/ip advertisement will be issue. I would not even add that sentence. In my opinion it is an implementation o= ption to send mac-only or mac-only + mac/ip for the same mac. Afaik there i= s nothing in the draft against it and again it depends on how you learn bot= h, mac and ip. My 2 cents. Jorge From: Jakob Heitz > Date: Tuesday, May 13, 2014 at 10:13 AM To: "Ali Sajassi (sajassi)" >, = "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don=92t want to make it a requirement. Then some words to alert t= he implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well =96 e.g., we don't n= eed the MAC-only route for the MAC/IP route to work. If there is only MAC/I= P route, the FIB entry will be populated based on that route and if it is w= ithdrawn, then FIB entry gets deleted. However, if there are both MAC/IP ro= ute and MAC-only route, and one of them gets withdrawn, then the FIB entry = will still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF97A2A9412ECjorgerabadanalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <06025933CB5F684BB99F7D74D75AC4C5@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Hi Ali and Jakob,

I totally agree with Ali and would not like to add that requirement.
Advertising mac-only + mac/ip or only mac/ip depends on how you le= arn the IP and how you learn the mac address. Normally both will be adverti= sed if data plane learning is done, since the source mac learning and the s= nooping of the control packets to get the IP are independent processes. But in hypervisor-based NVE cases, MAC/I= P can be learnt at once through control/management plane so in that case a = single mac/ip advertisement will be issue.

I would not even add that sentence. In my opinion it is an implementat= ion option to send mac-only or mac-only + mac/ip for the same mac. Afai= k there is nothing in the draft against it and again it depends on how you = learn both, mac and ip.

My 2 cents.
Jorge

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 at 10:1= 3 AM
To: "Ali Sajassi (sajassi)&quo= t; <sajassi@cisco.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

A route reflector can = and frequently does reorder routes from the same speaker.=

For example, a version= walk of a tree does not walk in version order, it walks in key order.=

Fine, you don=92t want= to make it a requirement. Then some words to alert the implementor

 

Whenever a PE withdraws all MAC advert= isement routes with IP address for a particular MAC address, but it still k= nows the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address wel= l in advance of the withdrawals. This is because BGP announcements of diffe= rent routes are not required to be received in the same order in which they= were sent.

 

Cheers,

Jakob.

 

 

&n= bsp;

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

&n= bsp;

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

&n= bsp;

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jakob Heitz <jakob.heitz@= ericsson.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more M= AC advertisement routes with IP address for a particular MAC address, it MU= ST also advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) = [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well =96 e.g., we don't need the= MAC-only route for the MAC/IP route to work. If there is only MAC/IP route= , the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@= ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) = [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jakob Heitz <jakob.heitz@= ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get = too big. When that happens, the bridge table may not be cleared at the same= time or at all.

An ARP cache may have a different time= out than the bridge table.

A bridge can snoop ARP messages to lea= rn bindings and those bindings can time out.

However, many other packets can come f= rom the same MAC address, keeping the MAC alive in the bridge table. In thi= s case, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other th= an by snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

 

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated wit= h the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf.= org" <l2vp= n@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: MAC route with IP

 <= /span>

We have another issue

In section 10: ARP and ND, the draft s= ays:

 

   If t= here are multiple IP addresses associated with a MAC address,

   then= multiple MAC advertisement routes MUST be generated, one for

   each= IP address. For instance, this may be the case when there are

   both= an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no MA=
C route without IP exists, then the MAC address will be forgotten. Therefor=
e, we would like to add a sentence:=



 


Whenever a PE advertises one or more M=
AC advertisement routes with IP address for a particular MAC address, it MU=
ST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF97A2A9412ECjorgerabadanalcatellucentcom_-- From nobody Tue May 13 10:33:43 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DF01A012E for ; Tue, 13 May 2014 10:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHPuRFEIMaxJ for ; Tue, 13 May 2014 10:33:35 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A4D151A00EA for ; Tue, 13 May 2014 10:33:34 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-4b-537208149b61 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 98.95.07420.41802735; Tue, 13 May 2014 13:55:01 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Tue, 13 May 2014 13:33:27 -0400 From: Jakob Heitz To: "Rabadan, Jorge (Jorge)" , "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//pmIA//60mdA= Date: Tue, 13 May 2014 17:33:26 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E030561D0@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E03056144@eusaamb109.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E030561D0eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZXLonSleUoyjY4NNHLotvl5awWDz+dojd 4t3ZZhYHZo/WZ3tZPab83sjqsWTJT6YA5igum5TUnMyy1CJ9uwSujKk/trIXfO9mrnjSOJWl gfHCXaYuRk4OCQETiW3vH0DZYhIX7q1n62Lk4hASOMoocefgf1aQhJDAckaJjh8BIDabgI7E t+tdzCBFIgITGSV6zp5lAUkwC5hJdN6czA5iCwvISXzuOAo2VURAXqLxx1pWCLtMYuqTFmYQ m0VAVWLV+mtgNbwCvhIPNx1lhtj8ilHi6N9pYIM4BewkJlyZBtbMCHTe91NrmCCWiUvcejIf 6mwBiSV7zjND2KISLx//Y4WwlSQmLT3HClGfL3Fm8WRmiGWCEidnPmGZwCg6C8moWUjKZiEp g4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYOUqLU8ty040MNjECI+6YBJvuDsY9Ly0P MQpwMCrx8C6YXRAsxJpYVlyZe4hRmoNFSZy34EtssJBAemJJanZqakFqUXxRaU5q8SFGJg5O qQbGTQvEr8f8qSk8WLjnn3Z/48sDlU7pq1IUlG1fa5VfV2Za0rt/sWr7rZOZiw73Hju66Nkk OZEeBUGRALcjWzrXde3NuR6q/mL6Fw9mbyb/Iq+kvlIbuU8nNgvuT6uozHg8MaVxynavGOtj TieZTmhZ2Fk3ah9qZw+026CkqegjnTpbbmP9qkYlluKMREMt5qLiRABKNoxNmQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/mD_2nYp-u8taHl85SLyaWualNYM Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:33:42 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E030561D0eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jorge, I can see your point. In your case, you never have a case where you know th= e MAC and not the IP. In that case, it is fine not to advertise a MAC only = route, because if you can never lose the MAC/IP binding without also losing= the MAC address. Would you agree that my softer sentence does not conflict= with your case: Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Rabadan, Jorge (Jorge) [mailto:jorge.rabadan@alcatel-lucent.com] Sent: Tuesday, May 13, 2014 10:25 AM To: Jakob Heitz; Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Ali and Jakob, I totally agree with Ali and would not like to add that requirement. Advertising mac-only + mac/ip or only mac/ip depends on how you learn the I= P and how you learn the mac address. Normally both will be advertised if da= ta plane learning is done, since the source mac learning and the snooping o= f the control packets to get the IP are independent processes. But in hyper= visor-based NVE cases, MAC/IP can be learnt at once through control/managem= ent plane so in that case a single mac/ip advertisement will be issue. I would not even add that sentence. In my opinion it is an implementation o= ption to send mac-only or mac-only + mac/ip for the same mac. Afaik there i= s nothing in the draft against it and again it depends on how you learn bot= h, mac and ip. My 2 cents. Jorge From: Jakob Heitz > Date: Tuesday, May 13, 2014 at 10:13 AM To: "Ali Sajassi (sajassi)" >, = "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don't want to make it a requirement. Then some words to alert the= implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well - e.g., we don't nee= d the MAC-only route for the MAC/IP route to work. If there is only MAC/IP = route, the FIB entry will be populated based on that route and if it is wit= hdrawn, then FIB entry gets deleted. However, if there are both MAC/IP rout= e and MAC-only route, and one of them gets withdrawn, then the FIB entry wi= ll still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E030561D0eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jorge,

 

I can see your point. = In your case, you never have a case where you know the MAC and not the IP. = In that case, it is fine not to advertise a MAC only route, because if you = can never lose the MAC/IP binding without also losing the MAC address. Would you agree that my softer sentence does = not conflict with your case:

 

Whenever a PE withdraws all MAC advertisem= ent routes with IP address for a particular MAC address, but it still knows= the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address well in adv= ance of the withdrawals. This is because BGP announcements of different rou= tes are not required to be received in the same order in which they were se= nt.

 

Cheers,

Jakob.

 

From: Rabadan,= Jorge (Jorge) [mailto:jorge.rabadan@alcatel-lucent.com]
Sent: Tuesday, May 13, 2014 10:25 AM
To: Jakob Heitz; Ali Sajassi (sajassi); l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

Hi Ali and Jakob,<= /span>

 

I totally agree with Ali and = would not like to add that requirement.

Advertising mac-only + ma= c/ip or only mac/ip depends on how you learn the IP and how you learn the m= ac address. Normally both will be advertised if data plane learning is done, since the source mac learning and the snooping of the control pac= kets to get the IP are independent processes. But in hypervisor-based NVE c= ases, MAC/IP can be learnt at once through control/management plane so in t= hat case a single mac/ip advertisement will be issue.

 

I would not even add that sen= tence. In my opinion it is an implementation option to send mac-only or mac= -only + mac/ip for the same mac. Afaik there is nothing in the draft against it and again it depends on how you learn both, mac an= d ip.

 

My 2 cents.=

Jorge

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 at 10:13 AM
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 

A route reflector can = and frequently does reorder routes from the same speaker.

For example, a version= walk of a tree does not walk in version order, it walks in key order.

Fine, you don’t = want to make it a requirement. Then some words to alert the implementor

 

Whenever a PE withdraws all MAC advertisem= ent routes with IP address for a particular MAC address, but it still knows= the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address well in adv= ance of the withdrawals. This is because BGP announcements of different rou= tes are not required to be received in the same order in which they were se= nt.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

 <= /span>

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

 <= /span>

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more MAC a= dvertisement routes with IP address for a particular MAC address, it MUST a= lso advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well – e.g., we don't need= the MAC-only route for the MAC/IP route to work. If there is only MAC/IP r= oute, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get too = big. When that happens, the bridge table may not be cleared at the same tim= e or at all.

An ARP cache may have a different timeout = than the bridge table.=

A bridge can snoop ARP messages to learn b= indings and those bindings can time out.=

However, many other packets can come from = the same MAC address, keeping the MAC alive in the bridge table. In this ca= se, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other than b= y snooping ARPs, by configuration, for example.

Such configurations can be removed.=

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= /a>

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= o:p>

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E030561D0eusaamb109erics_-- From nobody Tue May 13 10:38:13 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255911A01C4 for ; Tue, 13 May 2014 10:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sPWF49efLyS for ; Tue, 13 May 2014 10:37:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 97ACE1A0189 for ; Tue, 13 May 2014 10:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45390; q=dns/txt; s=iport; t=1400002653; x=1401212253; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=LdVA/POZY80glO5pmXKqaWR6IXe1bT/dtlyA88acfJY=; b=XGP+lKE0HtT04FAp/Emlu8sr9QT1igqC3pMvbw0zi0zCYskh/cHprjXr qZLRGoDc0FGwdCCREXdqghdkFt08XzlKQAxO1lLkqTbgBBD0coFpYzNc3 BXnLHTzAWWT3lBK40i3yL53Qezu0MMJGoMH9D4qAh2q8r9LU7rm+g+WtF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAF1XclOtJA2K/2dsb2JhbABZgkIjIU9YxX0BgSMWdIIlAQEBBC1ADBIBCBEDAQEBIQEGORQJCAIEAQ0FG4gmAccXF449EQYBBoQ6BIV4j1+DeZMQgzaBbgc7 X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208,217";a="43464670" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 13 May 2014 17:37:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4DHbWBW018316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 17:37:32 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 13 May 2014 12:37:33 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA Date: Tue, 13 May 2014 17:37:31 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03056144@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.48] Content-Type: multipart/alternative; boundary="_000_CF97A18ED39F2sajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/HG5v_rHkfWQIFemsJqmMXS0SE7c Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:38:02 -0000 --_000_CF97A18ED39F2sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement =96 e.g., why doesn't the sender send MAC-only advertisem= ent as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 10:13 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don=92t want to make it a requirement. Then some words to alert t= he implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well =96 e.g., we don't n= eed the MAC-only route for the MAC/IP route to work. If there is only MAC/I= P route, the FIB entry will be populated based on that route and if it is w= ithdrawn, then FIB entry gets deleted. However, if there are both MAC/IP ro= ute and MAC-only route, and one of them gets withdrawn, then the FIB entry = will still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF97A18ED39F2sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <238E1E2161EDB04DA5E2B754C7068AB8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Even if there is reordering by route reflector, then as I said, I don'= t see an issue here :-) In your example, the receiver sees the withdrawn of= the IP/MAC route before receiving the MAC-only route. In that case, the tr= affic toward that MAC address will get flooding (or dropped if flooding is disabled) till it receives the MAC= -only route. However, why does the sender has to wait till it withdraws the= IP/MAC advertisement before sending the MAC-only advertisement =96 e.g., w= hy doesn't the sender send MAC-only advertisement as soon as it learns it.

Again, there are scenarios in which learning is done in data-plane alo= ng with ARP suppression. In such scenarios, the sender should send MAC-only= route as soon as it learns it and MAC/IP route when it snoops the ARP. &nb= sp;However, there are other scenarios where there is no MAC learning in data-plane. In such scenario, when a VM = becomes known, the MAC/IP route is advertised and if the VM goes away, MAC/= IP is withdrawn. In such scenarios, we don't want to advertise an extra rou= te (MAC-only route) unnecessarily.

Cheers,
Ali 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 10:13 A= M
To: Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

A route reflector can = and frequently does reorder routes from the same speaker.=

For example, a version= walk of a tree does not walk in version order, it walks in key order.=

Fine, you don=92t want= to make it a requirement. Then some words to alert the implementor

 

Whenever a PE withdraws all MAC adver= tisement routes with IP address for a particular MAC address, but it still = knows the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address wel= l in advance of the withdrawals. This is because BGP announcements of diffe= rent routes are not required to be received in the same order in which they= were sent.

 

Cheers,

Jakob.

 

 

&n= bsp;

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

&n= bsp;

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

&n= bsp;

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jakob Heitz <jakob.heitz= @ericsson.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more = MAC advertisement routes with IP address for a particular MAC address, it M= UST also advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi= ) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well =96 e.g., we don't need the= MAC-only route for the MAC/IP route to work. If there is only MAC/IP route= , the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz= @ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi= ) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jakob Heitz <jakob.heitz= @ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get= too big. When that happens, the bridge table may not be cleared at the sam= e time or at all.

An ARP cache may have a different tim= eout than the bridge table.

A bridge can snoop ARP messages to le= arn bindings and those bindings can time out.

However, many other packets can come = from the same MAC address, keeping the MAC alive in the bridge table. In th= is case, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other t= han by snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

 

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated wi= th the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft = says:

 

   If = there are multiple IP addresses associated with a MAC address,

   the= n multiple MAC advertisement routes MUST be generated, one for

   eac= h IP address. For instance, this may be the case when there are

   bot= h an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no M=
AC route without IP exists, then the MAC address will be forgotten. Therefo=
re, we would like to add a sentence:


 


Whenever a PE advertises one or more =
MAC advertisement routes with IP address for a particular MAC address, it M=
UST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF97A18ED39F2sajassiciscocom_-- From nobody Tue May 13 10:41:50 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3691A019E for ; Tue, 13 May 2014 10:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfQxO_1SHLG5 for ; Tue, 13 May 2014 10:41:44 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEF41A0188 for ; Tue, 13 May 2014 10:41:44 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4DHfW5Y028483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2014 12:41:33 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s4DHfUx0008389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 19:41:31 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.243]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 13 May 2014 19:41:30 +0200 From: "Rabadan, Jorge (Jorge)" To: Jakob Heitz , "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//pmIA//60mdD//fy4gA== Date: Tue, 13 May 2014 17:41:28 +0000 Message-ID: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E03056144@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E030561D0@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E030561D0@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_CF97A6224130Fjorgerabadanalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/wu3folk8KoBQ6_lMy0Eh9UoZDjo Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:41:49 -0000 --_000_CF97A6224130Fjorgerabadanalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jakob, I am not against that =91softer=92 sentence. I simply think it is not even = necessary. But if you convince the authors I am ok. Thanks. Jorge From: Jakob Heitz > Date: Tuesday, May 13, 2014 at 10:33 AM To: Jorge Rabadan >, "Ali Sajassi (sajassi)" >, "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Jorge, I can see your point. In your case, you never have a case where you know th= e MAC and not the IP. In that case, it is fine not to advertise a MAC only = route, because if you can never lose the MAC/IP binding without also losing= the MAC address. Would you agree that my softer sentence does not conflict= with your case: Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Rabadan, Jorge (Jorge) [mailto:jorge.rabadan@alcatel-lucent.com] Sent: Tuesday, May 13, 2014 10:25 AM To: Jakob Heitz; Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Ali and Jakob, I totally agree with Ali and would not like to add that requirement. Advertising mac-only + mac/ip or only mac/ip depends on how you learn the I= P and how you learn the mac address. Normally both will be advertised if da= ta plane learning is done, since the source mac learning and the snooping o= f the control packets to get the IP are independent processes. But in hyper= visor-based NVE cases, MAC/IP can be learnt at once through control/managem= ent plane so in that case a single mac/ip advertisement will be issue. I would not even add that sentence. In my opinion it is an implementation o= ption to send mac-only or mac-only + mac/ip for the same mac. Afaik there i= s nothing in the draft against it and again it depends on how you learn bot= h, mac and ip. My 2 cents. Jorge From: Jakob Heitz > Date: Tuesday, May 13, 2014 at 10:13 AM To: "Ali Sajassi (sajassi)" >, = "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don=92t want to make it a requirement. Then some words to alert t= he implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well =96 e.g., we don't n= eed the MAC-only route for the MAC/IP route to work. If there is only MAC/I= P route, the FIB entry will be populated based on that route and if it is w= ithdrawn, then FIB entry gets deleted. However, if there are both MAC/IP ro= ute and MAC-only route, and one of them gets withdrawn, then the FIB entry = will still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF97A6224130Fjorgerabadanalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6B77AF325036F7478334768772C74400@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Jakob,

I am not against that =91softer=92 sentence. I simply think it is not = even necessary.
But if you convince the authors I am ok.

Thanks.
Jorge

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 at 10:3= 3 AM
To: Jorge Rabadan <jorge.rabadan@alcatel-lucent.com= >, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "l2= vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

Jorge,

 

I can see your point. = In your case, you never have a case where you know the MAC and not the IP. = In that case, it is fine not to advertise a MAC only route, because if you = can never lose the MAC/IP binding without also losing the MAC address. Would you agree that my softer sentence does = not conflict with your case:

 

Whenever a PE withdraws all MAC advert= isement routes with IP address for a particular MAC address, but it still k= nows the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address wel= l in advance of the withdrawals. This is because BGP announcements of diffe= rent routes are not required to be received in the same order in which they= were sent.

 

Cheers,

Jakob.

 

From: Rabadan, Jorge (Jorge) [mailto:jorge.rabadan@alcatel-lucent.com]
Sent: Tuesday, May 13, 2014 10:25 AM
To: Jakob Heitz; Ali Sajassi (sajassi); l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

Hi Ali and Jakob,

 

I totally agree with Ali and would not like to a= dd that requirement.

Advertising mac-only + mac/ip or only mac/ip= depends on how you learn the IP and how you learn the mac address. Normall= y both will be advertised if data plane learning is done, since the source mac learning and the snooping of the co= ntrol packets to get the IP are independent processes. But in hypervisor-ba= sed NVE cases, MAC/IP can be learnt at once through control/management plan= e so in that case a single mac/ip advertisement will be issue.

 

I would not even add that sentence. In my opinio= n it is an implementation option to send mac-only or mac-only + mac/ip = for the same mac. Afaik there is nothing in the draft against it and again it depends on how you learn both, mac an= d ip.

 

My 2 cents.

Jorge

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 at 10:13 AM
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 

A route reflector can = and frequently does reorder routes from the same speaker.

For example, a version= walk of a tree does not walk in version order, it walks in key order.

Fine, you don=92t want= to make it a requirement. Then some words to alert the implementor<= span style=3D"color:black">

 

Whenever a PE withdraws all MAC advert= isement routes with IP address for a particular MAC address, but it still k= nows the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address wel= l in advance of the withdrawals. This is because BGP announcements of diffe= rent routes are not required to be received in the same order in which they= were sent.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) = [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

 <= /span>

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

 <= /span>

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@= ericsson.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more M= AC advertisement routes with IP address for a particular MAC address, it MU= ST also advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) = [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well =96 e.g., we don't need the= MAC-only route for the MAC/IP route to work. If there is only MAC/IP route= , the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@= ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) = [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jakob Heitz <jakob.heitz@= ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get = too big. When that happens, the bridge table may not be cleared at the same= time or at all.

An ARP cache may have a different time= out than the bridge table.

A bridge can snoop ARP messages to lea= rn bindings and those bindings can time out.

However, many other packets can come f= rom the same MAC address, keeping the MAC alive in the bridge table. In thi= s case, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other th= an by snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

 

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated wit= h the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf.= org" <l2vp= n@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: MAC route with IP

 <= /span>

We have another issue

In section 10: ARP and ND, the draft s= ays:

 

   If t= here are multiple IP addresses associated with a MAC address,

   then= multiple MAC advertisement routes MUST be generated, one for

   each= IP address. For instance, this may be the case when there are

   both= an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no MA=
C route without IP exists, then the MAC address will be forgotten. Therefor=
e, we would like to add a sentence:=



 


Whenever a PE advertises one or more M=
AC advertisement routes with IP address for a particular MAC address, it MU=
ST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF97A6224130Fjorgerabadanalcatellucentcom_-- From nobody Tue May 13 10:42:06 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B401A01B3 for ; Tue, 13 May 2014 10:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 706leQ9paQyp for ; Tue, 13 May 2014 10:41:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 259101A0194 for ; Tue, 13 May 2014 10:41:46 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.0.939.12; Tue, 13 May 2014 17:41:38 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0934.000; Tue, 13 May 2014 17:41:38 +0000 From: John E Drake To: "Rabadan, Jorge (Jorge)" , Jakob Heitz , "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//pmIA//6xUIA= Date: Tue, 13 May 2014 17:41:38 +0000 Message-ID: <05828317202145d59723fee7d9291315@BLUPR05MB562.namprd05.prod.outlook.com> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E03056144@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-forefront-prvs: 0210479ED8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(199002)(189002)(377454003)(164054003)(2656002)(85852003)(19625215002)(46102001)(81542001)(76576001)(81342001)(15202345003)(19300405004)(33646001)(101416001)(83072002)(19580405001)(76482001)(54356999)(87936001)(79102001)(4396001)(21056001)(83322001)(77982001)(74502001)(66066001)(86362001)(50986999)(80022001)(15975445006)(20776003)(74662001)(99286001)(19580395003)(76176999)(77096999)(74316001)(99396002)(427584002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: multipart/alternative; boundary="_000_05828317202145d59723fee7d9291315BLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/J9Dc-L0Q02lHorUvH95tJl9obQw Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:41:57 -0000 --_000_05828317202145d59723fee7d9291315BLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jorge, I completely agree. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Rabadan, Jorge (Jo= rge) Sent: Tuesday, May 13, 2014 10:25 AM To: Jakob Heitz; Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Ali and Jakob, I totally agree with Ali and would not like to add that requirement. Advertising mac-only + mac/ip or only mac/ip depends on how you learn the I= P and how you learn the mac address. Normally both will be advertised if da= ta plane learning is done, since the source mac learning and the snooping o= f the control packets to get the IP are independent processes. But in hyper= visor-based NVE cases, MAC/IP can be learnt at once through control/managem= ent plane so in that case a single mac/ip advertisement will be issue. I would not even add that sentence. In my opinion it is an implementation o= ption to send mac-only or mac-only + mac/ip for the same mac. Afaik there i= s nothing in the draft against it and again it depends on how you learn bot= h, mac and ip. My 2 cents. Jorge From: Jakob Heitz > Date: Tuesday, May 13, 2014 at 10:13 AM To: "Ali Sajassi (sajassi)" >, = "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don't want to make it a requirement. Then some words to alert the= implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well - e.g., we don't nee= d the MAC-only route for the MAC/IP route to work. If there is only MAC/IP = route, the FIB entry will be populated based on that route and if it is wit= hdrawn, then FIB entry gets deleted. However, if there are both MAC/IP rout= e and MAC-only route, and one of them gets withdrawn, then the FIB entry wi= ll still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_05828317202145d59723fee7d9291315BLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jorge,

 

I completely agree.

 

Yours Irrespectively,<= o:p>

 

John=

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] <= b>On Behalf Of Rabadan, Jorge (Jorge)
Sent: Tuesday, May 13, 2014 10:25 AM
To: Jakob Heitz; Ali Sajassi (sajassi); l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

Hi Ali and Jakob,<= /span>

 

I totally agree with Ali and = would not like to add that requirement.

Advertising mac-only + ma= c/ip or only mac/ip depends on how you learn the IP and how you learn the m= ac address. Normally both will be advertised if data plane learning is done, since the source mac learning and the snooping of the control pac= kets to get the IP are independent processes. But in hypervisor-based NVE c= ases, MAC/IP can be learnt at once through control/management plane so in t= hat case a single mac/ip advertisement will be issue.

 

I would not even add that sen= tence. In my opinion it is an implementation option to send mac-only or mac= -only + mac/ip for the same mac. Afaik there is nothing in the draft against it and again it depends on how you learn both, mac an= d ip.

 

My 2 cents.=

Jorge

 

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 at 10:13 AM
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 

A route reflector can = and frequently does reorder routes from the same speaker.

For example, a version= walk of a tree does not walk in version order, it walks in key order.

Fine, you don’t = want to make it a requirement. Then some words to alert the implementor

 

Whenever a PE withdraws all MAC advertisem= ent routes with IP address for a particular MAC address, but it still knows= the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address well in adv= ance of the withdrawals. This is because BGP announcements of different rou= tes are not required to be received in the same order in which they were se= nt.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

 <= /span>

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

 <= /span>

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

 <= /span>

Cheers,=

Ali

 <= /span>

From: jakob.heitz@e= ricsson.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more MAC a= dvertisement routes with IP address for a particular MAC address, it MUST a= lso advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well – e.g., we don't need= the MAC-only route for the MAC/IP route to work. If there is only MAC/IP r= oute, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: jakob.heitz@e= ricsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: jakob.heitz@e= ricsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get too = big. When that happens, the bridge table may not be cleared at the same tim= e or at all.

An ARP cache may have a different timeout = than the bridge table.=

A bridge can snoop ARP messages to learn b= indings and those bindings can time out.=

However, many other packets can come from = the same MAC address, keeping the MAC alive in the bridge table. In this ca= se, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other than b= y snooping ARPs, by configuration, for example.

Such configurations can be removed.=

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= /a>

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= o:p>

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

From: jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf= .org" <l2v= pn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: MAC route with IP

 <= /span>

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_05828317202145d59723fee7d9291315BLUPR05MB562namprd05pro_-- From nobody Tue May 13 10:44:56 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3258C1A0194 for ; Tue, 13 May 2014 10:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFb_t47azSSX for ; Tue, 13 May 2014 10:44:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8A71A019F for ; Tue, 13 May 2014 10:44:44 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.0.939.12; Tue, 13 May 2014 17:44:36 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0934.000; Tue, 13 May 2014 17:44:36 +0000 From: John E Drake To: "Ali Sajassi (sajassi)" , Jakob Heitz , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xA= Date: Tue, 13 May 2014 17:44:35 +0000 Message-ID: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03056144@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-forefront-prvs: 0210479ED8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(199002)(189002)(377454003)(164054003)(2656002)(85852003)(19625215002)(46102001)(81542001)(76576001)(81342001)(15202345003)(19300405004)(33646001)(101416001)(83072002)(19580405001)(76482001)(54356999)(87936001)(79102001)(4396001)(21056001)(83322001)(77982001)(74502001)(66066001)(86362001)(50986999)(80022001)(15975445006)(20776003)(74662001)(99286001)(19580395003)(76176999)(77096999)(74316001)(99396002)(427584002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: multipart/alternative; boundary="_000_bdc24c5c43e745c3aabd2c99a08b9f93BLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Li-HsJldwXi55wYhI87fphVD6HI Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:44:53 -0000 --_000_bdc24c5c43e745c3aabd2c99a08b9f93BLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ali, As both Jorge and you have pointed out, there may indeed be cases for which= there should not be a MAC only route. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) Sent: Tuesday, May 13, 2014 10:38 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement - e.g., why doesn't the sender send MAC-only advertisemen= t as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 10:13 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don't want to make it a requirement. Then some words to alert the= implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well - e.g., we don't nee= d the MAC-only route for the MAC/IP route to work. If there is only MAC/IP = route, the FIB entry will be populated based on that route and if it is wit= hdrawn, then FIB entry gets deleted. However, if there are both MAC/IP rout= e and MAC-only route, and one of them gets withdrawn, then the FIB entry wi= ll still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_bdc24c5c43e745c3aabd2c99a08b9f93BLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ali,=

 

As both Jorge and you = have pointed out, there may indeed be cases for which there should not be a= MAC only route.

 

Yours Irrespectively,<= o:p>

 

John=

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] <= b>On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Even if= there is reordering by route reflector, then as I said, I don't see an iss= ue here :-) In your example, the receiver sees the withdrawn of the IP/MAC = route before receiving the MAC-only route. In that case, the traffic toward that MAC address will get flooding= (or dropped if flooding is disabled) till it receives the MAC-only route. = However, why does the sender has to wait till it withdraws the IP/MAC adver= tisement before sending the MAC-only advertisement – e.g., why doesn't the sender send MAC-only advertise= ment as soon as it learns it.

&n= bsp;

Again, = there are scenarios in which learning is done in data-plane along with ARP = suppression. In such scenarios, the sender should send MAC-only route as so= on as it learns it and MAC/IP route when it snoops the ARP.  However, there are other scenarios where the= re is no MAC learning in data-plane. In such scenario, when a VM becomes kn= own, the MAC/IP route is advertised and if the VM goes away, MAC/IP is with= drawn. In such scenarios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

&n= bsp;

Cheers,=

Ali&nbs= p;

&n= bsp;

From: jakob.heitz@e= ricsson.com>
Date: Tuesday, May 13, 2014 10:13 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

A route reflector can = and frequently does reorder routes from the same speaker.

For example, a version= walk of a tree does not walk in version order, it walks in key order.

Fine, you don’t = want to make it a requirement. Then some words to alert the implementor

 

Whenever a PE withdraws all MAC advertisem= ent routes with IP address for a particular MAC address, but it still knows= the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address well in adv= ance of the withdrawals. This is because BGP announcements of different rou= tes are not required to be received in the same order in which they were se= nt.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

 <= /span>

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

 <= /span>

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

 <= /span>

Cheers,=

Ali

 <= /span>

From: jakob.heitz@e= ricsson.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more MAC a= dvertisement routes with IP address for a particular MAC address, it MUST a= lso advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well – e.g., we don't need= the MAC-only route for the MAC/IP route to work. If there is only MAC/IP r= oute, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: jakob.heitz@e= ricsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: jakob.heitz@e= ricsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get too = big. When that happens, the bridge table may not be cleared at the same tim= e or at all.

An ARP cache may have a different timeout = than the bridge table.=

A bridge can snoop ARP messages to learn b= indings and those bindings can time out.=

However, many other packets can come from = the same MAC address, keeping the MAC alive in the bridge table. In this ca= se, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other than b= y snooping ARPs, by configuration, for example.

Such configurations can be removed.=

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= /a>

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= o:p>

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

From: jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf= .org" <l2v= pn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: MAC route with IP

 <= /span>

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_bdc24c5c43e745c3aabd2c99a08b9f93BLUPR05MB562namprd05pro_-- From nobody Tue May 13 10:55:18 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160341A0159 for ; Tue, 13 May 2014 10:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bObRMl2tyCY9 for ; Tue, 13 May 2014 10:55:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0F61A011A for ; Tue, 13 May 2014 10:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50968; q=dns/txt; s=iport; t=1400003704; x=1401213304; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=4MO77l/J8FCxXgzfNFWWRz6fIyN117qLf9/5HplADxA=; b=RA55KrWNNOauAXwcg7lFq+XdVkM0QNQTKNEsJ+x2BQ4XBGGjL6T7YWRj sllBbYeDH091v4IaTVcv1AUFzh4oqNDRg2Xk+V/20jjNRmEVHPWKAyCT+ JYKBwxUSyggGwu7osrs+ZXwkptNxRnyErnOlKU5aJSS9rPp50DvUhe9ol A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAFZbclOtJV2a/2dsb2JhbABZgkIjIU9YxX0BgSMWdIIlAQEBBBoTQAwSAQgRAwEBASEBBjkUCQgCBAENBRuIJgHHEheOPREGAQaEOgSFeI9fg3mTEIM2gW4HOw X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208,217";a="43463154" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 13 May 2014 17:55:03 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4DHt3Cl003010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 17:55:03 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 13 May 2014 12:55:03 -0500 From: "Ali Sajassi (sajassi)" To: John E Drake , Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xD//I4AAA== Date: Tue, 13 May 2014 17:55:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.48] Content-Type: multipart/alternative; boundary="_000_CF97A870D3A1Bsajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/HRNRJiiH83nPirlSJQhiv59VHOY Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:55:15 -0000 --_000_CF97A870D3A1Bsajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, although my email and Jorge's emails crossed each others, we are both = saying exactly the same thing. That's why I think the existing text is sufficient and we don't need to add= any thing more because both of the scenarios I mentioned below can happen = and the existing text covers them both. Cheers, Ali From: John E Drake > Date: Tuesday, May 13, 2014 10:44 AM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Ali, As both Jorge and you have pointed out, there may indeed be cases for which= there should not be a MAC only route. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) Sent: Tuesday, May 13, 2014 10:38 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement =96 e.g., why doesn't the sender send MAC-only advertisem= ent as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 10:13 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don=92t want to make it a requirement. Then some words to alert t= he implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well =96 e.g., we don't n= eed the MAC-only route for the MAC/IP route to work. If there is only MAC/I= P route, the FIB entry will be populated based on that route and if it is w= ithdrawn, then FIB entry gets deleted. However, if there are both MAC/IP ro= ute and MAC-only route, and one of them gets withdrawn, then the FIB entry = will still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF97A870D3A1Bsajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <08BCD3670C7FFD449F94C48140A91CF0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Yes, although my email and Jorge's emails crossed each others, we are = both saying exactly the same thing.

That's why I think the existing text is sufficient and we don't need t= o add any thing more because both of the scenarios I mentioned below can ha= ppen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake@juniper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,=

 

As both Jorge and you = have pointed out, there may indeed be cases for which there should not be a= MAC only route.

 

Yours Irrespectively,<= o:p>

 

John=

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Even if= there is reordering by route reflector, then as I said, I don't see an iss= ue here :-) In your example, the receiver sees the withdrawn of the IP/MAC = route before receiving the MAC-only route. In that case, the traffic toward that MAC address will get flooding= (or dropped if flooding is disabled) till it receives the MAC-only route. = However, why does the sender has to wait till it withdraws the IP/MAC adver= tisement before sending the MAC-only advertisement =96 e.g., why doesn't the sender send MAC-only advertisement= as soon as it learns it.

&n= bsp;

Again, = there are scenarios in which learning is done in data-plane along with ARP = suppression. In such scenarios, the sender should send MAC-only route as so= on as it learns it and MAC/IP route when it snoops the ARP.  However, there are other scenarios where the= re is no MAC learning in data-plane. In such scenario, when a VM becomes kn= own, the MAC/IP route is advertised and if the VM goes away, MAC/IP is with= drawn. In such scenarios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

&n= bsp;

Cheers,=

Ali&nbs= p;

&n= bsp;

From: Jak= ob Heitz <jakob.heitz@ericss= on.com>
Date: Tuesday, May 13, 2014 10:13 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

A route reflector can = and frequently does reorder routes from the same speaker.

For example, a version= walk of a tree does not walk in version order, it walks in key order.

Fine, you don=92t want= to make it a requirement. Then some words to alert the implementor<= span style=3D"color:black">

 

Whenever a PE withdraws all MAC adver= tisement routes with IP address for a particular MAC address, but it still = knows the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address wel= l in advance of the withdrawals. This is because BGP announcements of diffe= rent routes are not required to be received in the same order in which they= were sent.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi= ) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

 <= /span>

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

 <= /span>

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jak= ob Heitz <jakob.heitz@ericss= on.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more = MAC advertisement routes with IP address for a particular MAC address, it M= UST also advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi= ) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well =96 e.g., we don't need the= MAC-only route for the MAC/IP route to work. If there is only MAC/IP route= , the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jak= ob Heitz <jakob.heitz@ericss= on.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi= ) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jak= ob Heitz <jakob.heitz@ericss= on.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get= too big. When that happens, the bridge table may not be cleared at the sam= e time or at all.

An ARP cache may have a different tim= eout than the bridge table.

A bridge can snoop ARP messages to le= arn bindings and those bindings can time out.

However, many other packets can come = from the same MAC address, keeping the MAC alive in the bridge table. In th= is case, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other t= han by snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

 

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated wi= th the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft = says:

 

   If = there are multiple IP addresses associated with a MAC address,

   the= n multiple MAC advertisement routes MUST be generated, one for

   eac= h IP address. For instance, this may be the case when there are

   bot= h an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no M=
AC route without IP exists, then the MAC address will be forgotten. Therefo=
re, we would like to add a sentence:


 


Whenever a PE advertises one or more =
MAC advertisement routes with IP address for a particular MAC address, it M=
UST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF97A870D3A1Bsajassiciscocom_-- From nobody Tue May 13 11:00:26 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD7E1A018C for ; Tue, 13 May 2014 11:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTfgnAtCX4dp for ; Tue, 13 May 2014 11:00:19 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id B4D331A011A for ; Tue, 13 May 2014 11:00:19 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4DI07HC007512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2014 13:00:08 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s4DI06Qv030070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 20:00:06 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.243]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 13 May 2014 20:00:06 +0200 From: "Rabadan, Jorge (Jorge)" To: "Ali Sajassi (sajassi)" , John E Drake , Jakob Heitz , "l2vpn@ietf.org" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xD//I4AAP/5j/EA Date: Tue, 13 May 2014 18:00:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CF97AB9B41328jorgerabadanalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/20VJ3ePaGL1UQ_ktXcObST7MK44 Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 18:00:24 -0000 --_000_CF97AB9B41328jorgerabadanalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Fully agree. Thx Jorge From: "Ali Sajassi (sajassi)" > Date: Tuesday, May 13, 2014 at 10:55 AM To: John E Drake >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: Re: MAC route with IP Yes, although my email and Jorge's emails crossed each others, we are both = saying exactly the same thing. That's why I think the existing text is sufficient and we don't need to add= any thing more because both of the scenarios I mentioned below can happen = and the existing text covers them both. Cheers, Ali From: John E Drake > Date: Tuesday, May 13, 2014 10:44 AM To: Cisco Employee >, Jakob Hei= tz >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Ali, As both Jorge and you have pointed out, there may indeed be cases for which= there should not be a MAC only route. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) Sent: Tuesday, May 13, 2014 10:38 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement =96 e.g., why doesn't the sender send MAC-only advertisem= ent as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 10:13 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. Fine, you don=92t want to make it a requirement. Then some words to alert t= he implementor Whenever a PE withdraws all MAC advertisement routes with IP address for a = particular MAC address, but it still knows the MAC address, it SHOULD adver= tise one MAC advertisement route without an IP address for that MAC address= well in advance of the withdrawals. This is because BGP announcements of d= ifferent routes are not required to be received in the same order in which = they were sent. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well =96 e.g., we don't n= eed the MAC-only route for the MAC/IP route to work. If there is only MAC/I= P route, the FIB entry will be populated based on that route and if it is w= ithdrawn, then FIB entry gets deleted. However, if there are both MAC/IP ro= ute and MAC-only route, and one of them gets withdrawn, then the FIB entry = will still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_CF97AB9B41328jorgerabadanalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0AB48886F48FED4A8F82F80505E125A1@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Fully agree.

Thx
Jorge

From: "Ali Sajassi (sajassi)&q= uot; <sajassi@cisco.com>
Date: Tuesday, May 13, 2014 at 10:5= 5 AM
To: John E Drake <jdrake@juniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: Re: MAC route with IP


Yes, although my email and Jorge's emails crossed each others, we are = both saying exactly the same thing.

That's why I think the existing text is sufficient and we don't need t= o add any thing more because both of the scenarios I mentioned below can ha= ppen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake@juniper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,=

 

As both Jorge and you = have pointed out, there may indeed be cases for which there should not be a= MAC only route.

 

Yours Irrespectively,<= o:p>

 

John=

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

Even if= there is reordering by route reflector, then as I said, I don't see an iss= ue here :-) In your example, the receiver sees the withdrawn of the IP/MAC = route before receiving the MAC-only route. In that case, the traffic toward that MAC address will get flooding= (or dropped if flooding is disabled) till it receives the MAC-only route. = However, why does the sender has to wait till it withdraws the IP/MAC adver= tisement before sending the MAC-only advertisement =96 e.g., why doesn't the sender send MAC-only advertisement= as soon as it learns it.

&n= bsp;

Again, = there are scenarios in which learning is done in data-plane along with ARP = suppression. In such scenarios, the sender should send MAC-only route as so= on as it learns it and MAC/IP route when it snoops the ARP.  However, there are other scenarios where the= re is no MAC learning in data-plane. In such scenario, when a VM becomes kn= own, the MAC/IP route is advertised and if the VM goes away, MAC/IP is with= drawn. In such scenarios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

&n= bsp;

Cheers,=

Ali&nbs= p;

&n= bsp;

From: Jako= b Heitz <jakob.heitz@ericsso= n.com>
Date: Tuesday, May 13, 2014 10:13 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

A route reflector can = and frequently does reorder routes from the same speaker.

For example, a version= walk of a tree does not walk in version order, it walks in key order.

Fine, you don=92t want= to make it a requirement. Then some words to alert the implementor<= span style=3D"color:black">

 

Whenever a PE withdraws all MAC advert= isement routes with IP address for a particular MAC address, but it still k= nows the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address wel= l in advance of the withdrawals. This is because BGP announcements of diffe= rent routes are not required to be received in the same order in which they= were sent.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) = [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

 <= /span>

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

 <= /span>

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jako= b Heitz <jakob.heitz@ericsso= n.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more M= AC advertisement routes with IP address for a particular MAC address, it MU= ST also advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) = [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well =96 e.g., we don't need the= MAC-only route for the MAC/IP route to work. If there is only MAC/IP route= , the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jako= b Heitz <jakob.heitz@ericsso= n.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) = [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jako= b Heitz <jakob.heitz@ericsso= n.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get = too big. When that happens, the bridge table may not be cleared at the same= time or at all.

An ARP cache may have a different time= out than the bridge table.

A bridge can snoop ARP messages to lea= rn bindings and those bindings can time out.

However, many other packets can come f= rom the same MAC address, keeping the MAC alive in the bridge table. In thi= s case, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other th= an by snooping ARPs, by configuration, for example.

Such configurations can be removed.

 

Cheers,

Jakob.

 

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated wit= h the MAC address, but the MAC address still exits.

 

Cheers,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jako= b Heitz <jakob.heitz@e= ricsson.com>
Date: Sunday, May 11, 2014 9:56 PM
To: "l2vpn@ietf.org&= quot; <l2vpn@ietf.org= >
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: MAC route with IP

 <= /span>

We have another issue

In section 10: ARP and ND, the draft s= ays:

 

   If t= here are multiple IP addresses associated with a MAC address,

   then= multiple MAC advertisement routes MUST be generated, one for

   each= IP address. For instance, this may be the case when there are

   both= an IPv4 and an IPv6 address associated with the MAC address.

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 


If such a route is withdrawn and no MA=
C route without IP exists, then the MAC address will be forgotten. Therefor=
e, we would like to add a sentence:=



 


Whenever a PE advertises one or more M=
AC advertisement routes with IP address for a particular MAC address, it MU=
ST also advertise one MAC advertisement
 route without an IP address for that MAC address.


 


Thanks,


Jakob.


 
--_000_CF97AB9B41328jorgerabadanalcatellucentcom_-- From nobody Tue May 13 11:14:46 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFF51A0189 for ; Tue, 13 May 2014 11:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TFWb6v_MDR3 for ; Tue, 13 May 2014 11:14:39 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 542211A010C for ; Tue, 13 May 2014 11:14:39 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f73so664838yha.38 for ; Tue, 13 May 2014 11:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=beTBodDDRZ+/yl/bE71P6qYaMqDV/8k8cRsuRz345HU=; b=HQC9DsYVsuycz5FHElV+kW2N/vQ/xxJ64LfZJ1shI9xtL+fGs43hFH+8abQixgCcKn c+0ZhZVgBinhE6GARw9H7+RVNB9WHiaArDZnZ9QlWeXWcD+ZIk0NZmI57OVmibk2SKBS 3usK2uMqWSAusbs5i8tnh6nuuazpNlTi0et9llXOGbnj1P9uIvUW+iAAAAr7FUqga7ZD 6CKb4qS77CHFPce5b5DFzZ13v7dPvoKYG6GGjXfjXFuM8ZAMydWWGr0DsCRMglOrinWb akc+FS4oI9kqJl5fDWVkyJz4H60zDysv5mKRiPdZhIwxbcvu0VRHlHHnyHELb54zTcG1 iAuA== MIME-Version: 1.0 X-Received: by 10.236.166.169 with SMTP id g29mr5981973yhl.135.1400004872730; Tue, 13 May 2014 11:14:32 -0700 (PDT) Received: by 10.170.75.136 with HTTP; Tue, 13 May 2014 11:14:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 14:14:32 -0400 Message-ID: Subject: Re: MAC route with IP From: Aldrin Isaac To: "Ali Sajassi (sajassi)" Content-Type: multipart/alternative; boundary=20cf303f6cb21f7d8b04f94c09cd Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/vQVrv894T7wro5D1_WNQeh-t7lc Cc: Antoni Przygienda , "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 18:14:41 -0000 --20cf303f6cb21f7d8b04f94c09cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Would it be worthwhile to mention that MAC/IP routes should not be used as a proxy for MAC-only route? On Tuesday, May 13, 2014, Ali Sajassi (sajassi) wrote: > > Yes, although my email and Jorge's emails crossed each others, we are > both saying exactly the same thing. > > That's why I think the existing text is sufficient and we don't need to > add any thing more because both of the scenarios I mentioned below can > happen and the existing text covers them both. > > Cheers, > Ali > > > > From: John E Drake > > > Date: Tuesday, May 13, 2014 10:44 AM > To: Cisco Employee >, > Jakob Heitz >, > "l2vpn@ietf.org " < > l2vpn@ietf.org > > Cc: Antoni Przygienda > > > Subject: RE: MAC route with IP > > Ali, > > > > As both Jorge and you have pointed out, there may indeed be cases for > which there should not be a MAC only route. > > > > Yours Irrespectively, > > > > John > > > > *From:* L2vpn [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Ali Sajassi > (sajassi) > *Sent:* Tuesday, May 13, 2014 10:38 AM > *To:* Jakob Heitz; l2vpn@ietf.org > *Cc:* Antoni Przygienda > *Subject:* Re: MAC route with IP > > > > > > Even if there is reordering by route reflector, then as I said, I don't > see an issue here :-) In your example, the receiver sees the withdrawn of > the IP/MAC route before receiving the MAC-only route. In that case, the > traffic toward that MAC address will get flooding (or dropped if flooding > is disabled) till it receives the MAC-only route. However, why does the > sender has to wait till it withdraws the IP/MAC advertisement before > sending the MAC-only advertisement =E2=80=93 e.g., why doesn't the sender= send > MAC-only advertisement as soon as it learns it. > > > > Again, there are scenarios in which learning is done in data-plane along > with ARP suppression. In such scenarios, the sender should send MAC-only > route as soon as it learns it and MAC/IP route when it snoops the ARP. > However, there are other scenarios where there is no MAC learning in > data-plane. In such scenario, when a VM becomes known, the MAC/IP route i= s > advertised and if the VM goes away, MAC/IP is withdrawn. In such scenario= s, > we don't want to advertise an extra route (MAC-only route) unnecessarily. > > > > Cheers, > > Ali > > > > *From: *Jakob Heitz > *Date: *Tuesday, May 13, 2014 10:13 AM > *To: *Cisco Employee , "l2vpn@ietf.org" > > *Cc: *Antoni Przygienda > *Subject: *RE: MAC route with IP > > > > A route reflector can and frequently does reorder routes from the same > speaker. > > For example, a version walk of a tree does not walk in version order, it > walks in key order. > > --20cf303f6cb21f7d8b04f94c09cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Would it be worthwhile to mention=C2=A0that MAC/IP routes shou= ld not be used as a=C2=A0proxy for MAC-only route?

On Tuesday, May 1= 3, 2014, Ali Sajassi (sajassi) <saj= assi@cisco.com> wrote:

Yes, although my email and Jorge's emails crossed each others, we = are both saying exactly the same thing.

That's why I think the existing text is sufficient and we don'= t need to add any thing more because both of the scenarios I mentioned belo= w can happen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake@juniper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi@cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.o= rg" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,

=C2=A0

As both Jorge and you have pointed out, th= ere may indeed be cases for which there should not be a MAC only route.<= /u>

=C2=A0

Yours Irrespectively,=

=C2=A0

John

=C2=A0

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

=C2=A0

=C2=A0=

Even if there is reordering= by route reflector, then as I said, I don't see an issue here :-) In y= our example, the receiver sees the withdrawn of the IP/MAC route before rec= eiving the MAC-only route. In that case, the traffic toward that MAC address will get flooding= (or dropped if flooding is disabled) till it receives the MAC-only route. = However, why does the sender has to wait till it withdraws the IP/MAC adver= tisement before sending the MAC-only advertisement =E2=80=93 e.g., why doesn't the sender send MAC-only adv= ertisement as soon as it learns it.

=C2=A0=

Again, there are scenarios = in which learning is done in data-plane along with ARP suppression. In such= scenarios, the sender should send MAC-only route as soon as it learns it a= nd MAC/IP route when it snoops the ARP. =C2=A0However, there are other scenarios where the= re is no MAC learning in data-plane. In such scenario, when a VM becomes kn= own, the MAC/IP route is advertised and if the VM goes away, MAC/IP is with= drawn. In such scenarios, we don't want to advertise an extra route (MAC-only route) unnecessarily.<= /span>

=C2=A0=

Cheers,

Ali=C2=A0

=C2=A0=

From: = Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 10:13 AM
To: Cisco Employee <sajassi@cisco.com>, "l2vpn@= ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com><= br> Subject: RE: MAC route with IP

=C2=A0=

A route reflector can and frequently does = reorder routes from the same speaker.=

For example, a version walk of a tree does= not walk in version order, it walks in key order.

<= /div>
--20cf303f6cb21f7d8b04f94c09cd-- From nobody Tue May 13 11:32:43 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C18C1A010C for ; Tue, 13 May 2014 11:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDecot8bA97H for ; Tue, 13 May 2014 11:32:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED651A0101 for ; Tue, 13 May 2014 11:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13269; q=dns/txt; s=iport; t=1400005953; x=1401215553; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=pDV3igocgjZ1xDiy/5CiP3y/RVkdysitk5J9gfeWHe0=; b=QFJyDF1SmJxIpJKjm77XruRsgdzuKtD6A00VjD6oMmOAl+2vxD3CFaB8 wfZI2xhEw7pKK8UrV8VCwng7wVfRUjnj8RRPix3h0lq3t9Et4lqODtAYM xew6cpMVF+MdoaUtyY20FIRq537HY2aEYEFQuRp92s30wJNP/w/7LlOxU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAENkclOtJA2B/2dsb2JhbABZgkIjIU9YxX4BgSMWdIIlAQEBBG0MEgEIEQMBAQEoKBEUCQgCBA4FiC0DEQHAOg2GVBQDBowzggQRBgGEQASFeI9fggaBc40nhWmDNoFuBzs X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208,217";a="324379732" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 13 May 2014 18:32:32 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4DIWWPi025740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 May 2014 18:32:32 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 13 May 2014 13:32:32 -0500 From: "Ali Sajassi (sajassi)" To: Aldrin Isaac Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xD//I4AAP/4oTIA//GyuYA= Date: Tue, 13 May 2014 18:32:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.48] Content-Type: multipart/alternative; boundary="_000_CF97B0F9D3A93sajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/x6y56OrFttTre2qiXhDvuHRwcmQ Cc: Antoni Przygienda , "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 18:32:41 -0000 --_000_CF97B0F9D3A93sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Aldrin, I believe the application of MAC/IP route in section 10 is clear. However, = if you think we can make further clarification, please suggest the text. We= need to make sure the functionality that we specify is clearly described a= nd explained. We don't need to describe/mention the functionality that is n= ot used/needed. Thanks, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 11:14 AM To: Cisco Employee > Cc: John E Drake >, Jakob Hei= tz >, "l2vpn@ietf= .org" >, Anton= i Przygienda > Subject: Re: MAC route with IP Would it be worthwhile to mention that MAC/IP routes should not be used as = a proxy for MAC-only route? On Tuesday, May 13, 2014, Ali Sajassi (sajassi) > wrote: Yes, although my email and Jorge's emails crossed each others, we are both = saying exactly the same thing. That's why I think the existing text is sufficient and we don't need to add= any thing more because both of the scenarios I mentioned below can happen = and the existing text covers them both. Cheers, Ali From: John E Drake > Date: Tuesday, May 13, 2014 10:44 AM To: Cisco Employee >, Jakob Heitz >, "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Ali, As both Jorge and you have pointed out, there may indeed be cases for which= there should not be a MAC only route. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) Sent: Tuesday, May 13, 2014 10:38 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement =96 e.g., why doesn't the sender send MAC-only advertisem= ent as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz Date: Tuesday, May 13, 2014 10:13 AM To: Cisco Employee , "l2vpn@ietf.org" Cc: Antoni Przygienda Subject: RE: MAC route with IP A route reflector can and frequently does reorder routes from the same spea= ker. For example, a version walk of a tree does not walk in version order, it wa= lks in key order. --_000_CF97B0F9D3A93sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <62847F09BA3B6641B513B9ACD43FC718@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Aldrin,

I believe the application of MAC/IP route in section 10 is clear. Howe= ver, if you think we can make further clarification, please suggest the tex= t. We need to make sure the functionality that we specify is clearly descri= bed and explained. We don't need to describe/mention the functionality that is not used/needed.

Thanks,
Ali

From: Aldrin Isaac <aldrin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 11:14 A= M
To: Cisco Employee <sajassi@cisco.com>
Cc: John E Drake <jdrake@juniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <an= toni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

Would it be worthwhile to mention that MAC/IP routes should not be used as a proxy for MAC-only route?

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:

Yes, although my email and Jorge's emails crossed each others, we are = both saying exactly the same thing.

That's why I think the existing text is sufficient and we don't need t= o add any thing more because both of the scenarios I mentioned below can ha= ppen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake= @juniper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi= @cisco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,

 

As both Jorge and you have pointed out, th= ere may indeed be cases for which there should not be a MAC only route.<= /u>

 

Yours Irrespectively,=

 

John

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

 =

Even if there is reordering= by route reflector, then as I said, I don't see an issue here :-) In your = example, the receiver sees the withdrawn of the IP/MAC route before receivi= ng the MAC-only route. In that case, the traffic toward that MAC address will get flooding (or dropped if flood= ing is disabled) till it receives the MAC-only route. However, why does the= sender has to wait till it withdraws the IP/MAC advertisement before sendi= ng the MAC-only advertisement =96 e.g., why doesn't the sender send MAC-only advertisement as soon as it lea= rns it.

 =

Again, there are scenarios = in which learning is done in data-plane along with ARP suppression. In such= scenarios, the sender should send MAC-only route as soon as it learns it a= nd MAC/IP route when it snoops the ARP.  However, there are other scenarios where there is no MAC learni= ng in data-plane. In such scenario, when a VM becomes known, the MAC/IP rou= te is advertised and if the VM goes away, MAC/IP is withdrawn. In such scen= arios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

 =

Cheers,

Ali 

 =

From: Jakob= Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 10:13 AM
To: Cisco Employee <sajassi@cisco.com>, "l2vpn@= ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com><= br> Subject: RE: MAC route with IP

 =

A route reflector can and frequently does = reorder routes from the same speaker.=

For example, a version walk of a tree does= not walk in version order, it walks in key order.

 --_000_CF97B0F9D3A93sajassiciscocom_-- From nobody Tue May 13 16:26:34 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB69F1A0205 for ; Tue, 13 May 2014 16:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5r-ns9Lqsik for ; Tue, 13 May 2014 16:26:26 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D18F11A01E5 for ; Tue, 13 May 2014 16:26:25 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-8a-537258536404 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 10.7A.02831.35852735; Tue, 13 May 2014 19:37:24 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 13 May 2014 19:26:17 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" , "l2vpn@ietf.org" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//yEw4A== Date: Tue, 13 May 2014 23:26:16 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03056935@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se> 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.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056935eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXSPn25IRFGwwbWNHBaPvx1it3h3tpnF gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4/H4zc8H7/UwV3V/NGhj7ZjN1MXJySAiY SLxYsQrKFpO4cG89WxcjF4eQwFFGibafd6Cc5YwSz6fMZAWpYhPQkfh2vYsZxBYRCJE43dfC CGIzC5hJdN6czA5iCwvISXzuOMoEUSMv0fhjLSuEnSUxbdMqNhCbRUBVYvPBdUA1HBy8Ar4S c74WgYSFBIokzp5YAdbKKaAvcWHDX7CRjEDHfT+1hglilbjErSfzoY4WkFiy5zwzhC0q8fLx P1YIW0li0tJzrBD1+RKfe/ewgNi8AoISJ2c+YZnAKDoLyahZSMpmISmDiOtILNj9iQ3C1pZY tvA1M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQLj6pgEm+MOxgWfLA8xCnAwKvHwJqoWBQux JpYVV+YeYpTmYFES503/FBssJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVGacW363uCOU8pr 2fc/vHlE5kZY0vsds4rCDv9RFXy6+8Ss6UFpHV4HulwZBI0Ofv5VO+mJxmaJpRlz1RkzMyLK NbbYyzWfka6Z+e1n0XsVh1O2VpdY0r0qXstVKE9KFrgVeW+lfZ3bj/tNNpMjqzgWRKiJB2dm TdWdeOhSqFr3n/QvZz14diqxFGckGmoxFxUnAgBmV8bzjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/5RBgpPzVmiJmgllC0tirXexr0RU Cc: Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 23:26:30 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056935eusaamb109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Ali. I recognize the case where a MAC only route is not needed. My text does not preclude that. My text is advisory to avoid the small time of flooding in an unlikely scen= ario. I do recognize that it is not necessary to ensure correctness of the draft. With that: I have studied the draft and consider it ready for publication. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from dif= ferent speakers, then it can re-order them. But we are talking about differ= ent routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, = then the sender has already sent a MAC-only advertisement anyway, so there = is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are adverti= se for the same MAC and there are scenarios where only MAC/IP routes are ad= vertised. I don't want to constrain the solution unnecessarily by saying th= at MAC-only route must be accompanied with MAC/IP route. Again, I am not pr= ecluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed = out, but the MAC is still known, it must send a MAC only route before it wi= thdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not ann= ounce/withdraw of the same route), the receiver can receive the withdrawal = of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well - e.g., we don't nee= d the MAC-only route for the MAC/IP route to work. If there is only MAC/IP = route, the FIB entry will be populated based on that route and if it is wit= hdrawn, then FIB entry gets deleted. However, if there are both MAC/IP rout= e and MAC-only route, and one of them gets withdrawn, then the FIB entry wi= ll still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz > Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee >, "l2vpn@ie= tf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and = thus the entries in MAC-VRF and ARP table can be deleted independent of eac= h other. However, the existing text is still accurate. It already covers th= e scenario that is interest to you where there are multiple IP/MAC pair adv= ertisement for a given MAC plus MAC-only advertisement. In such case, the w= ithdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the = ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section= 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx= in addition to the IPx/MACx advertisement, then when it receives a withdra= w message for the IPx/MACx, it MUST delete the corresponding entry from the= ARP table. However, it MUST not delete the MACx entry from the MAC-VRF tab= le unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz >= , Cisco Employee >, "l2vpn@ietf= .org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridg= e table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can ti= me out. However, many other packets can come from the same MAC address, keeping the= MAC alive in the bridge table. In this case, the MAC-IP binding will be lo= st without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration= , for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC addres= s still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you= have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/= o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise = both MAC and IP. In the latter case, if there are several IP addresses map = to the same MAC address, then the MAC address from MAC-VRF only gets remove= d, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz > Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the M= AC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP addre= ss for a particular MAC address, it MUST also advertise one MAC advertiseme= nt route without an IP address for that MAC address. Thanks, Jakob. --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056935eusaamb109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Ali.=

I recognize the case w= here a MAC only route is not needed.

My text does not precl= ude that.

My text is advisory to= avoid the small time of flooding in an unlikely scenario.

I do recognize that it= is not necessary to ensure correctness of the draft.

With that:<= /span>

 

I have studied the dra= ft and consider it ready for publication.

 

Thanks,

Jakob.

 

From: Ali Saja= ssi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

&n= bsp;

I can u= nderstand that if route reflector receives different routes from different = speakers, then it can re-order them. But we are talking about different rou= tes from the same speaker (same BGP session and TCP/IP connection).

&n= bsp;

In your= scenario below, the if the MAC is learned via data-plane learning, then th= e sender has already sent a MAC-only advertisement anyway, so there is no i= ssue.

&n= bsp;

There c= an be scenarios in which both MAC/IP and MAC-only routes are advertise for = the same MAC and there are scenarios where only MAC/IP routes are advertise= d. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/I= P route. Again, I am not precluding what you are saying. I just don't want = to make it a requirement.

&n= bsp;

Cheers,=

Ali

&n= bsp;

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:43 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

&n= bsp;

Then if a sender withd= raws a MAC/IP route, say because the ARP cache timed out, but the MAC is st= ill known, it must send a MAC only route before it withdraws the MAC/IP rou= te.

Now, because route ref= lectors can reorder route advertisements (but not announce/withdraw of the = same route), the receiver can receive the withdrawal of the MAC/IP before i= t receives the announcement of the MAC only.

To prevent this glitch= , I propose

 

Whenever a PE advertises one or more MAC a= dvertisement routes with IP address for a particular MAC address, it MUST a= lso advertise one MAC advertisement route without an IP address for that MAC address.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob,<= /span>

 <= /span>

If ther= e is no MAC-only route, then it is fine as well – e.g., we don't need= the MAC-only route for the MAC/IP route to work. If there is only MAC/IP r= oute, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However= , if there are both MAC/IP route and MAC-only route, and one of them gets w= ithdrawn, then the FIB entry will still exist. This is the correct behavior= .

 <= /span>

Cheers,=

Ali

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tuesday, May 13, 2014 9:28 AM
To: Cisco Employee <sajassi@= cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

My concern is not that= a MAC/IP withdrawal might delete a MAC only route.

It is that there might= not be a MAC only route there at all.

 

Thanks,

Jakob.

 

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Jakob, = Antoni:

 <= /span>

Agreed = that the ARP entries can timeout independent from the MAC table and thus th= e entries in MAC-VRF and ARP table can be deleted independent of each other= . However, the existing text is still accurate. It already covers the scenario that is interest to you where the= re are multiple IP/MAC pair advertisement for a given MAC plus MAC-only adv= ertisement. In such case, the withdraw of a IP/MAC pair will remove the cor= responding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. 

 <= /span>

I added= the following couple of sentences to the end of 2nd para of section 10 for= further clarification:

 <= /span>

"I= f the receiving PE has already received a MAC-only advertisement for MACx i= n addition to the IPx/MACx advertisement, then when it receives a withdraw = message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete th= e MACx entry from the MAC-VRF table unless it receives a withdraw message f= or MACx only."

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <jako= b.heitz@ericsson.com>, Cisco Employee <sajassi@cisco.com>, "l2vpn@ietf.org" <l2vpn@iet= f.org>
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: RE: MAC route with IP

 <= /span>

People clear ARP caches when they get too = big. When that happens, the bridge table may not be cleared at the same tim= e or at all.

An ARP cache may have a different timeout = than the bridge table.=

A bridge can snoop ARP messages to learn b= indings and those bindings can time out.=

However, many other packets can come from = the same MAC address, keeping the MAC alive in the bridge table. In this ca= se, the MAC-IP binding will be lost without the MAC address itself being lost.

IP-MAC bindings can be learnt other than b= y snooping ARPs, by configuration, for example.

Such configurations can be removed.=

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= /a>

From: L2vpn [ma= ilto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); l2vpn@i= etf.org
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

 =

When the IP address is dissociated with th= e MAC address, but the MAC address still exits.

 <= o:p>

Cheers,=

Jakob.<= o:p>

 <= o:p>

From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 =

 <= /span>

Hi Jako= b,

 <= /span>

I belie= ve the currency text is correct and sufficient. What use case do you have i= n mind? 

 <= /span>

EVPN PE= devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP ad= dress) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MA= C and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address= from MAC-VRF only gets removed, when there is no more ARP entry with that = MAC address.

 <= /span>

Cheers,=

Ali

 <= /span>

 <= /span>

We have another issue

In section 10: ARP and ND, the draft says:=

 <= o:p>

  = ; If there are multiple IP addresses associated with a MAC address,<= span style=3D"color:black">

  = ; then multiple MAC advertisement routes MUST be generated, one for<= span style=3D"color:black">

  = ; each IP address. For instance, this may be the case when there are=

  = ; both an IPv4 and an IPv6 address associated with the MAC address.<= span style=3D"color:black">

 

   When the IP address is dissociated with the MAC addr=
ess, then the MAC

   advertisement route with that particular IP address =
MUST be


   withdrawn.


 <=
o:p>


If such a route is withdrawn and no MAC ro=
ute without IP exists, then the MAC address will be forgotten. Therefore, w=
e would like to add a sentence:


 <=
o:p>


Whenever a PE advertises one or more MAC a=
dvertisement routes with IP address for a particular MAC address, it MUST a=
lso advertise one MAC advertisement route without
 an IP address for that MAC address.


 <=
o:p>


Thanks,=



Jakob.<=
o:p>


 <=
o:p>
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056935eusaamb109erics_-- From nobody Tue May 13 20:02:28 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EAC1A0226 for ; Tue, 13 May 2014 20:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxvuyadlpMPy for ; Tue, 13 May 2014 20:02:22 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id C99B01A0197 for ; Tue, 13 May 2014 20:02:21 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so1168937yha.12 for ; Tue, 13 May 2014 20:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FdKyr9Aw3Ke+ougl7hSnb69Htfib4+xetu+x3C6TXyI=; b=LDLu61lbgNsFXtvq9z8qxcwQzoCc5gNRlm4kLTYV3Upa4+nCwXaic854TOxf/+IDyS RuA5GVXg68ktO8p+ARE9toDFySoEwAj1HbsoOrxUBTnfyGHrNMpEgwfeaSx8u3Edrfbq 6JJNe6zO2z7h6Z+M/PTY/w12IpHLq3QZ2IEsZZ5A5A+NSNZqqB3htMmiYS3m/k/HM66x nlC1D34u0ecPRg/yi/Gmayt8IHxZfx+th+xST9z9IkMwJjcC74yJGiLh8eBUjnmNrw+t m9rh9gNrnTxsnx7lyNnbuNuRimShUrn9S++KMkSXY7J1DwKXxMGb19zCAFigbP+9it6u hvQg== MIME-Version: 1.0 X-Received: by 10.236.159.67 with SMTP id r43mr1303152yhk.50.1400036535239; Tue, 13 May 2014 20:02:15 -0700 (PDT) Received: by 10.170.75.136 with HTTP; Tue, 13 May 2014 20:02:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 May 2014 23:02:14 -0400 Message-ID: Subject: Re: MAC route with IP From: Aldrin Isaac To: "Ali Sajassi (sajassi)" Content-Type: multipart/alternative; boundary=20cf30434c645b0bc904f9536831 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/L1q4BYjm1DG-tBO4nwUqbn3WGhg Cc: Antoni Przygienda , "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 03:02:26 -0000 --20cf30434c645b0bc904f9536831 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about: "Note that a MAC-only route can be advertised along with MAC/IP routes for = use cases where an active MAC must remain reachable when all IP's become disassociated with that MAC." On Tuesday, May 13, 2014, Ali Sajassi (sajassi) wrote: > Hi Aldrin, > > I believe the application of MAC/IP route in section 10 is clear. > However, if you think we can make further clarification, please suggest t= he > text. We need to make sure the functionality that we specify is clearly > described and explained. We don't need to describe/mention the > functionality that is not used/needed. > > Thanks, > Ali > > From: Aldrin Isaac > > > Date: Tuesday, May 13, 2014 11:14 AM > To: Cisco Employee > > > Cc: John E Drake >, > Jakob Heitz >, > "l2vpn@ietf.org " < > l2vpn@ietf.org >, Antoni > Przygienda > > > Subject: Re: MAC route with IP > > Would it be worthwhile to mention that MAC/IP routes should not be used > as a proxy for MAC-only route? > > On Tuesday, May 13, 2014, Ali Sajassi (sajassi) wrote= : > > > Yes, although my email and Jorge's emails crossed each others, we are > both saying exactly the same thing. > > That's why I think the existing text is sufficient and we don't need to > add any thing more because both of the scenarios I mentioned below can > happen and the existing text covers them both. > > Cheers, > Ali > > > > From: John E Drake > Date: Tuesday, May 13, 2014 10:44 AM > To: Cisco Employee , Jakob Heitz < > jakob.heitz@ericsson.com>, "l2vpn@ietf.org" > Cc: Antoni Przygienda > Subject: RE: MAC route with IP > > Ali, > > > > As both Jorge and you have pointed out, there may indeed be cases for > which there should not be a MAC only route. > > > > Yours Irrespectively, > > > > John > > > > *From:* L2vpn [mailto:l2vpn-bounces@ietf.org] *On Behalf Of * Ali Sajassi > (sajassi) > *Sent:* Tuesday, May 13, 2014 10:38 AM > *To:* Jakob Heitz; l2vpn@ietf.org > *Cc:* Antoni Przygienda > *Subject:* Re: MAC route with IP > > > > > > Even if there is reordering by route reflector, then as I said, I don't > see an issue here :-) In your example, the receiver sees the withdrawn of > the IP/MAC route before receiving the MAC-only route. In that case, the > traffic toward that MAC address will get flooding (or dropped if flooding > is disabled) till it receives the MAC-only route. However, why does the > sender has to wait till it withdraws the IP/MAC advertisement before > sending the MAC-only advertisement =E2=80=93 e.g., why doesn't the sender= send > MAC-only advertisement as soon as it learns it. > > > > Again, there are scenarios in which learning is done in data-plane along > with ARP suppression. In such scenarios, the sender should send MAC-only > route as soon as it learns it and MAC/IP route when it snoops the ARP. > However, there are other scenarios where there is no MAC learning in > data-plane. In such scenario, when a VM becomes known, the MAC/IP route i= s > advertised and if the VM goes away, MAC/IP is withdrawn. In such scenario= s, > we don't want to advertise an extra route (MAC-only route) unnecessarily. > > > > Cheers, > > Ali > > > > *From: *Jakob Heitz > *Date: * > > --20cf30434c645b0bc904f9536831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about:

"Note that a=C2=A0MAC-only route can=C2= =A0be advertised along=C2=A0with=C2=A0MAC/IP routes=C2=A0for= =C2=A0use cases where=C2=A0an active MAC must=C2=A0remain=C2=A0reachable wh= en=C2=A0all IP's become disassociated=C2=A0with that MAC."

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:
Hi Aldrin,

I believe the application of MAC/IP route in section 10 is clear. Howe= ver, if you think we can make further clarification, please suggest the tex= t. We need to make sure the functionality that we specify is clearly descri= bed and explained. We don't need to describe/mention the functionality that is not used/needed.

Thanks,
Ali

From: Aldrin Isaac <aldrin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 11:14 A= M
To: Cisco Employee <sajassi@cisco.com>
Cc: John E Drake <jdrake@juniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.o= rg" <l2vpn@ietf.org>, Antoni Przygienda <antoni.przygienda@= ericsson.com>
Subject: Re: MAC route with IP

Would it be worthwhile to mention=C2=A0that MAC/IP routes should not be used as a=C2=A0proxy for MAC-only route?

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:

Yes, although my email and Jorge's emails crossed each others, we = are both saying exactly the same thing.

That's why I think the existing text is sufficient and we don'= t need to add any thing more because both of the scenarios I mentioned belo= w can happen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake@ju= niper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi@c= isco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni= .przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,

=C2=A0

As both Jorge and you have pointed out, th= ere may indeed be cases for which there should not be a MAC only route.<= /u>

=C2=A0

Yours Irrespectively,=

=C2=A0

John

=C2=A0

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

=C2=A0

=C2=A0=

Even if there is reordering= by route reflector, then as I said, I don't see an issue here :-) In y= our example, the receiver sees the withdrawn of the IP/MAC route before rec= eiving the MAC-only route. In that case, the traffic toward that MAC address will get flooding (or dropped if flood= ing is disabled) till it receives the MAC-only route. However, why does the= sender has to wait till it withdraws the IP/MAC advertisement before sendi= ng the MAC-only advertisement =E2=80=93 e.g., why doesn't the sender send MAC-only advertisement as soon as it= learns it.

=C2=A0=

Again, there are scenarios = in which learning is done in data-plane along with ARP suppression. In such= scenarios, the sender should send MAC-only route as soon as it learns it a= nd MAC/IP route when it snoops the ARP. =C2=A0However, there are other scenarios where there is no MAC learni= ng in data-plane. In such scenario, when a VM becomes known, the MAC/IP rou= te is advertised and if the VM goes away, MAC/IP is withdrawn. In such scen= arios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

=C2=A0=

Cheers,

Ali=C2=A0

=C2=A0=

From:= Jakob Heitz <jakob.heitz@ericsson.com>
Date:

--20cf30434c645b0bc904f9536831-- From nobody Tue May 13 23:22:52 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2E31A023D for ; Tue, 13 May 2014 23:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcWYRzmT2AeW for ; Tue, 13 May 2014 23:22:47 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id A7B461A0238 for ; Tue, 13 May 2014 23:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15473; q=dns/txt; s=iport; t=1400048561; x=1401258161; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=nKl4QYmQBfFoC5/+u3WKAgAo0qVHyJEVwJsLE5EQiIg=; b=KU3QioW8bGIYUxdNBfieg1qwZ/FgXjYhFmRygcb8/UWSGXIVOLrfcP0x RXcMihXEGnpYb1zId+JBgiWoKj4rX6Vp8WwcfYGFK9QrJhPA/TOYn74zA mncdrb6vbf68Pz1vDLKcQDgN3tfNz+Cy6sYQsk7cmeg3VtOWF+O7PSzLM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAFcLc1OtJA2I/2dsb2JhbABZgkIjIU9YxXMBgR4WdIIlAQEBBG0MEgEIEQMBAQEoKBEUCQgCBA4FiC0DEQHKCQ2GVBQDBowzggQRBgGEQASFeJFmgXONKYVqgzaBbgc7 X-IronPort-AV: E=Sophos;i="4.97,1050,1389744000"; d="scan'208,217";a="43643380" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 14 May 2014 06:22:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4E6MeRS021746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 06:22:40 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 14 May 2014 01:22:40 -0500 From: "Ali Sajassi (sajassi)" To: Aldrin Isaac Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xD//I4AAP/4oTIA//GyuYD/4mGtAP/FALUA Date: Wed, 14 May 2014 06:22:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.89.14.185] Content-Type: multipart/alternative; boundary="_000_CF985727D3B10sajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/WBHfjIRl4yRLH4PIQAa6_FReyiw Cc: Antoni Przygienda , "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 06:22:50 -0000 --_000_CF985727D3B10sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Aldrin, How about the following: "Note that a MAC-only route can be advertised along with but independent fr= om MAC/IP route for scenarios where the MAC learning over access network/no= de is done in data-plane and independent from ARP snooping that generates M= AC/IP route. In scenarios where host MAC/IP is learned via management or co= ntrol plane, then the sender PE may only generates and advertises MAC/IP ro= ute." Cheers, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 8:02 PM To: Cisco Employee > Cc: John E Drake >, Jakob Hei= tz >, "l2vpn@ietf= .org" >, Anton= i Przygienda > Subject: Re: MAC route with IP How about: "Note that a MAC-only route can be advertised along with MAC/IP routes for = use cases where an active MAC must remain reachable when all IP's become di= sassociated with that MAC." On Tuesday, May 13, 2014, Ali Sajassi (sajassi) > wrote: Hi Aldrin, I believe the application of MAC/IP route in section 10 is clear. However, = if you think we can make further clarification, please suggest the text. We= need to make sure the functionality that we specify is clearly described a= nd explained. We don't need to describe/mention the functionality that is n= ot used/needed. Thanks, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 11:14 AM To: Cisco Employee > Cc: John E Drake >, Jakob Heitz >, "l2vpn@ietf.org" >, Antoni Przygienda > Subject: Re: MAC route with IP Would it be worthwhile to mention that MAC/IP routes should not be used as = a proxy for MAC-only route? On Tuesday, May 13, 2014, Ali Sajassi (sajassi) wrote: Yes, although my email and Jorge's emails crossed each others, we are both = saying exactly the same thing. That's why I think the existing text is sufficient and we don't need to add= any thing more because both of the scenarios I mentioned below can happen = and the existing text covers them both. Cheers, Ali From: John E Drake Date: Tuesday, May 13, 2014 10:44 AM To: Cisco Employee , Jakob Heitz , "l2vpn@ietf.org" Cc: Antoni Przygienda Subject: RE: MAC route with IP Ali, As both Jorge and you have pointed out, there may indeed be cases for which= there should not be a MAC only route. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) Sent: Tuesday, May 13, 2014 10:38 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement =96 e.g., why doesn't the sender send MAC-only advertisem= ent as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz Date: --_000_CF985727D3B10sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <18964EC70FEDB4458B3FBA3AA464C71E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Aldrin,

How about the following:

"Note that a MAC-only route can be advertised along with but inde= pendent from MAC/IP route for scenarios where the MAC learning over access = network/node is done in data-plane and independent from ARP snooping that g= enerates MAC/IP route. In scenarios where host MAC/IP is learned via management or control plane, then the sender PE= may only generates and advertises MAC/IP route."

Cheers,
Ali

From: Aldrin Isaac <aldrin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 8:02 PM=
To: Cisco Employee <sajassi@cisco.com>
Cc: John E Drake <jdrake@juniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <an= toni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

How about:

"Note that a MAC-only route can be advertised along&nbs= p;with MAC/IP routes for use cases where a= n active MAC must remain reachable when all IP's become disa= ssociated with that MAC."

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:
Hi Aldrin,

I believe the application of MAC/IP route in section 10 is clear. Howe= ver, if you think we can make further clarification, please suggest the tex= t. We need to make sure the functionality that we specify is clearly descri= bed and explained. We don't need to describe/mention the functionality that is not used/needed.

Thanks,
Ali

From: Aldrin Isaac <al= drin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 11:14 A= M
To: Cisco Employee <sajassi= @cisco.com>
Cc: John E Drake <jdrake@j= uniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przy= gienda <antoni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

Would it be worthwhile to mention that MAC/IP routes should not be used as a proxy for MAC-only route?

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:

Yes, although my email and Jorge's emails crossed each others, we are = both saying exactly the same thing.

That's why I think the existing text is sufficient and we don't need t= o add any thing more because both of the scenarios I mentioned below can ha= ppen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake@ju= niper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi@c= isco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni= .przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,

 

As both Jorge and you have pointed out, th= ere may indeed be cases for which there should not be a MAC only route.<= /u>

 

Yours Irrespectively,=

 

John

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

 =

Even if there is reordering= by route reflector, then as I said, I don't see an issue here :-) In your = example, the receiver sees the withdrawn of the IP/MAC route before receivi= ng the MAC-only route. In that case, the traffic toward that MAC address will get flooding (or dropped if flood= ing is disabled) till it receives the MAC-only route. However, why does the= sender has to wait till it withdraws the IP/MAC advertisement before sendi= ng the MAC-only advertisement =96 e.g., why doesn't the sender send MAC-only advertisement as soon as it lea= rns it.

 =

Again, there are scenarios = in which learning is done in data-plane along with ARP suppression. In such= scenarios, the sender should send MAC-only route as soon as it learns it a= nd MAC/IP route when it snoops the ARP.  However, there are other scenarios where there is no MAC learni= ng in data-plane. In such scenario, when a VM becomes known, the MAC/IP rou= te is advertised and if the VM goes away, MAC/IP is withdrawn. In such scen= arios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

 =

Cheers,

Ali 

 =

From: Jakob= Heitz <jakob.heitz@ericsson.com>
Date:

--_000_CF985727D3B10sajassiciscocom_-- From nobody Wed May 14 00:09:24 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32DB1A0277 for ; Wed, 14 May 2014 00:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23A-f0Z1SV8F for ; Wed, 14 May 2014 00:09:19 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 65FE11A0276 for ; Wed, 14 May 2014 00:09:19 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-df-5372c7361bb4 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EC.9D.07420.637C2735; Wed, 14 May 2014 03:30:30 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Wed, 14 May 2014 03:09:04 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xD//I4AAP/4sfYA//Fe5YD/4i9hAP/EJsOA/4iDnNE= Date: Wed, 14 May 2014 07:09:04 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AC766891B9AF493AA24295D58BDC7069ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonStfseFGwwa31ehYzd7eyWMy562zx +Nshdot3Z5tZHFg8pvzeyOqxc9Zddo8lS34yeVxvusoewBLFZZOSmpNZllqkb5fAlbH72De2 gk2tjBXbFyxma2BcWNzFyMkhIWAicaZ/MhOELSZx4d56ti5GLg4hgaOMEm1LvkM5yxklHlzc xwhSxSagI/HtehcziC0ioC8xsW0KI0gRM0hRx/Ut7CAJYQE5iV1LtzBBFMlLNP5YywpSJCIw j1Hi4uoOsG4WAVWJ58smgdm8AvYSDcc/gTULCRRLHF/9FszmBNrQt2M/2CBGoPu+n1oDZjML iEvcejIf6m4BiSV7zjND2KISLx//Y4WoSZa4ffsCK8R8QYmTM5+wTGAUmYWkfRaSsllIyiDi BhLvz81nhrC1JZYtfA1l60ts/HKWEVl8ASP7KkaO0uLUstx0I4NNjMBYOybBpruDcc9Ly0OM AhyMSjy8CapFwUKsiWXFlbmHGKU5WJTEeQu+xAYLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YFzS+1lNbtKmHdq32fnluN3+rJowY2n9L/2/731nqr+6zL8i0W7dF55XcqkZdQdlwtR3vti9 9PPHmPnHq9k+1G6XXn/Sdk3Atn7mTtPIxwyzy9iadUKS2VnkXsUkcKbur3T8K9N4wzVgjs3j iM1mSv16N1aq9u3X+VvBFHvOonxmaUfr1cCHc5RYijMSDbWYi4oTAQ21MN+WAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/t8fngADhSwaX5Ogq12IYMQ-Rylg Cc: "l2vpn@ietf.org" , Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 07:09:22 -0000 --_000_AC766891B9AF493AA24295D58BDC7069ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Note that a MAC-only route can be advertised along with but independently = of a MAC/IP route in scenarios where the MAC learning over the access netwo= rk is done in the data-plane and independently of ARP snooping that generat= es the MAC/IP route. This ensures that if the ARP entry times out and cause= s the MAC/IP to be withdrawn, then the MAC information will not be lost. In= scenarios where the host MAC/IP is learned via the management or control p= lanes, the sender PE may advertise only the MAC/IP route." -- Jakob Heitz. On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" > wrote: Hi Aldrin, How about the following: "Note that a MAC-only route can be advertised along with but independent fr= om MAC/IP route for scenarios where the MAC learning over access network/no= de is done in data-plane and independent from ARP snooping that generates M= AC/IP route. In scenarios where host MAC/IP is learned via management or co= ntrol plane, then the sender PE may only generates and advertises MAC/IP ro= ute." Cheers, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 8:02 PM To: Cisco Employee > Cc: John E Drake >, Jakob Hei= tz >, "l2vpn@ietf= .org" >, Anton= i Przygienda > Subject: Re: MAC route with IP How about: "Note that a MAC-only route can be advertised along with MAC/IP routes for = use cases where an active MAC must remain reachable when all IP's become di= sassociated with that MAC." On Tuesday, May 13, 2014, Ali Sajassi (sajassi) > wrote: Hi Aldrin, I believe the application of MAC/IP route in section 10 is clear. However, = if you think we can make further clarification, please suggest the text. We= need to make sure the functionality that we specify is clearly described a= nd explained. We don't need to describe/mention the functionality that is n= ot used/needed. Thanks, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 11:14 AM To: Cisco Employee > Cc: John E Drake >, Jakob Heitz >, "l2vpn@ietf.org" >, Antoni Przygienda > Subject: Re: MAC route with IP Would it be worthwhile to mention that MAC/IP routes should not be used as = a proxy for MAC-only route? On Tuesday, May 13, 2014, Ali Sajassi (sajassi) wrote: Yes, although my email and Jorge's emails crossed each others, we are both = saying exactly the same thing. That's why I think the existing text is sufficient and we don't need to add= any thing more because both of the scenarios I mentioned below can happen = and the existing text covers them both. Cheers, Ali From: John E Drake Date: Tuesday, May 13, 2014 10:44 AM To: Cisco Employee , Jakob Heitz , "l2vpn@ietf.org" Cc: Antoni Przygienda Subject: RE: MAC route with IP Ali, As both Jorge and you have pointed out, there may indeed be cases for which= there should not be a MAC only route. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) Sent: Tuesday, May 13, 2014 10:38 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement =96 e.g., why doesn't the sender send MAC-only advertisem= ent as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz Date: --_000_AC766891B9AF493AA24295D58BDC7069ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
"Note that a MAC-= only route can be advertised along with but independently of a MAC/IP route= in scenarios where the MAC learning over the access network is done in the= data-plane and independently of ARP snooping that generates the MAC/IP route. This ensures that if the ARP entry times = out and causes the MAC/IP to be withdrawn, then the MAC information will no= t be lost. In scenarios where the host MAC/IP is learned via the management= or control planes, the sender PE may advertise only the MAC/IP route."

--
Jakob Heitz.


On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:


Hi Aldrin,

How about the following:

"Note that a MAC-only route can be advertised along with but inde= pendent from MAC/IP route for scenarios where the MAC learning over access = network/node is done in data-plane and independent from ARP snooping that g= enerates MAC/IP route. In scenarios where host MAC/IP is learned via management or control plane, then the sender PE= may only generates and advertises MAC/IP route."

Cheers,
Ali

From: Aldrin Isaac <aldrin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 8:02 PM=
To: Cisco Employee <sajassi@cisco.com>
Cc: John E Drake <jdrake@juniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <an= toni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

How about:

"Note that a MAC-only route can be advertised along&nbs= p;with MAC/IP routes for use cases where a= n active MAC must remain reachable when all IP's become disa= ssociated with that MAC."

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:
Hi Aldrin,

I believe the application of MAC/IP route in section 10 is clear. Howe= ver, if you think we can make further clarification, please suggest the tex= t. We need to make sure the functionality that we specify is clearly descri= bed and explained. We don't need to describe/mention the functionality that is not used/needed.

Thanks,
Ali

From: Aldrin Isaac <al= drin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 11:14 A= M
To: Cisco Employee <sajassi= @cisco.com>
Cc: John E Drake <jdrake@j= uniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przy= gienda <antoni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

Would it be worthwhile to mention that MAC/IP routes should not be used as a proxy for MAC-only route?

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:

Yes, although my email and Jorge's emails crossed each others, we are = both saying exactly the same thing.

That's why I think the existing text is sufficient and we don't need t= o add any thing more because both of the scenarios I mentioned below can ha= ppen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake@ju= niper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi@c= isco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni= .przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,

 

As both Jorge and you have pointed out, th= ere may indeed be cases for which there should not be a MAC only route.<= /u>

 

Yours Irrespectively,=

 

John

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

 =

Even if there is reordering= by route reflector, then as I said, I don't see an issue here :-) In your = example, the receiver sees the withdrawn of the IP/MAC route before receivi= ng the MAC-only route. In that case, the traffic toward that MAC address will get flooding (or dropped if flood= ing is disabled) till it receives the MAC-only route. However, why does the= sender has to wait till it withdraws the IP/MAC advertisement before sendi= ng the MAC-only advertisement =96 e.g., why doesn't the sender send MAC-only advertisement as soon as it lea= rns it.

 =

Again, there are scenarios = in which learning is done in data-plane along with ARP suppression. In such= scenarios, the sender should send MAC-only route as soon as it learns it a= nd MAC/IP route when it snoops the ARP.  However, there are other scenarios where there is no MAC learni= ng in data-plane. In such scenario, when a VM becomes known, the MAC/IP rou= te is advertised and if the VM goes away, MAC/IP is withdrawn. In such scen= arios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

 =

Cheers,

Ali 

 =

From: Jakob= Heitz <jakob.heitz@ericsson.com>
Date:

--_000_AC766891B9AF493AA24295D58BDC7069ericssoncom_-- From nobody Wed May 14 04:33:54 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3C71A0068 for ; Wed, 14 May 2014 04:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlB1p_3A2Z8C for ; Wed, 14 May 2014 04:33:51 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0A91A0015 for ; Wed, 14 May 2014 04:33:51 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so1749527wes.37 for ; Wed, 14 May 2014 04:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=28sCvxJSdk7pGrrJULRVfOH6tZLN9iuQ6oG+C1QUUAg=; b=aLvnNDiLvKHQzy3M6otGMH8BVdIPChICHwWF/9IOaHWIO9HzzPUtfNiI9gaGr8LozT C4MS4oY0nzNdx7ggNaK5GnqVFFsHTX+X//SUGLEuPzlTrCWAjhUNQMuWKIj4q6zYwPAx V7XHLC/C24WYgzDtl8S9vSHS9cvj9UaNTvc3Ntd2S2fO8EJ39TJiKSunPacezgM4WEmP Sxk7ohyr0D2NnvM16LRol9Y8qYBzHKbX15Ie5CcIHqfyZZSZPoMk6ZkUFmvKPJBYghWF enyd1UDPeTbLxfVLHD79Q5frB2tehS5QbdIZ+v4N3hmnDnhDg6RYq1HmxMKmQW/Pv1oe rlSw== X-Received: by 10.180.92.34 with SMTP id cj2mr25716135wib.15.1400067224072; Wed, 14 May 2014 04:33:44 -0700 (PDT) Received: from ?IPv6:2001:420:4805:1254:c956:f777:a3c7:4114? ([2001:420:4805:1254:c956:f777:a3c7:4114]) by mx.google.com with ESMTPSA id cw2sm2144295wjb.39.2014.05.14.04.33.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 04:33:42 -0700 (PDT) From: Giles Heron Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: [netmod] YANG Advice and Editing Session at the next IETF meeting Date: Wed, 14 May 2014 12:33:40 +0100 References: <5372944D.5010509@cisco.com> To: "l2vpn@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/_IyNCrlGFLXX2yGNLiQPEYvYXjk X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 11:33:52 -0000 probably worth attending if we're thinking of doing L2VPN YANG models = (e.g. for EVPN). anyone else interested in participating in that effort? I'm happy to = lead it. Begin forwarded message: > From: Benoit Claise > Subject: [netmod] YANG Advice and Editing Session at the next IETF = meeting > Date: 13 May 2014 22:53:17 BST > To: undisclosed-recipients:; >=20 > [Sorry for the potential cross-posting] >=20 > http://www.ietf.org/meeting/90/tutorials/yang-session.html > Let me stress that this should be an interactive session, and not a = tutorial. > So come with your (plan to create) YANG modules. >=20 > Regards, Benoit >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed May 14 07:10:24 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DED41A00C3 for ; Wed, 14 May 2014 07:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8J2F4H6ickM for ; Wed, 14 May 2014 07:10:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C3E1F1A00D3 for ; Wed, 14 May 2014 07:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19644; q=dns/txt; s=iport; t=1400076604; x=1401286204; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=pCmFpo10UI31Y7YlipXIK/Fp7ozlbCuVOvCeXlqSVbs=; b=caDgsINx6ySJG6CSSsf0royNdgjuDIpYRxSeInVIUXOyAGmK/h3hvOA4 HOgFGAOxcFzBO93eV5fckDRzjnU/HPlap+eOF6Nbd8r7zKha0vXx3KliZ 5B2aXTWmNof4fzPWQfXOOqRmKLGSFoSQZH8wQYW4ox+RhgpZ8tW1APAyj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFABl4c1OtJV2Y/2dsb2JhbABZgkIjIU9YxW4BgR8WdIIlAQEBBG0MEgEIEQMBAQEoKBEUCQgCBA4FiC0DEQHKPQ2GVBQDBowzggQRBgGEQASFeJFmgXONKoVqgzaBbgc7 X-IronPort-AV: E=Sophos;i="4.97,1052,1389744000"; d="scan'208,217";a="324860481" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 14 May 2014 14:10:03 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4EEA3Pd008483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 14:10:03 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 14 May 2014 09:10:02 -0500 From: "Ali Sajassi (sajassi)" To: Jakob Heitz Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xD//I4AAP/4oTIA//GyuYD/4mGtAP/FALUA/4l/GAD/Ev3sgA== Date: Wed, 14 May 2014 14:10:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.89.8.107] Content-Type: multipart/alternative; boundary="_000_CF98C654D3B54sajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/3zqhEOZ5pB1AtW3qVJhGgMzZu4E Cc: "l2vpn@ietf.org" , Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 14:10:16 -0000 --_000_CF98C654D3B54sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jakob, Changed your sentence to: "In such scenarios when the ARP entry times out a= nd causes the MAC/IP to be withdrawn, then the MAC information will not be = lost." Cheers, Ali From: Jakob Heitz > Date: Wednesday, May 14, 2014 12:09 AM To: Cisco Employee > Cc: Aldrin Isaac >, J= ohn E Drake >, "l2vpn@ietf.or= g" >, Antoni P= rzygienda > Subject: Re: MAC route with IP "Note that a MAC-only route can be advertised along with but independently = of a MAC/IP route in scenarios where the MAC learning over the access netwo= rk is done in the data-plane and independently of ARP snooping that generat= es the MAC/IP route. This ensures that if the ARP entry times out and cause= s the MAC/IP to be withdrawn, then the MAC information will not be lost. In= scenarios where the host MAC/IP is learned via the management or control p= lanes, the sender PE may advertise only the MAC/IP route." -- Jakob Heitz. On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" > wrote: Hi Aldrin, How about the following: "Note that a MAC-only route can be advertised along with but independent fr= om MAC/IP route for scenarios where the MAC learning over access network/no= de is done in data-plane and independent from ARP snooping that generates M= AC/IP route. In scenarios where host MAC/IP is learned via management or co= ntrol plane, then the sender PE may only generates and advertises MAC/IP ro= ute." Cheers, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 8:02 PM To: Cisco Employee > Cc: John E Drake >, Jakob Hei= tz >, "l2vpn@ietf= .org" >, Anton= i Przygienda > Subject: Re: MAC route with IP How about: "Note that a MAC-only route can be advertised along with MAC/IP routes for = use cases where an active MAC must remain reachable when all IP's become di= sassociated with that MAC." On Tuesday, May 13, 2014, Ali Sajassi (sajassi) > wrote: Hi Aldrin, I believe the application of MAC/IP route in section 10 is clear. However, = if you think we can make further clarification, please suggest the text. We= need to make sure the functionality that we specify is clearly described a= nd explained. We don't need to describe/mention the functionality that is n= ot used/needed. Thanks, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 11:14 AM To: Cisco Employee > Cc: John E Drake >, Jakob Heitz >, "l2vpn@ietf.org" >, Antoni Przygienda > Subject: Re: MAC route with IP Would it be worthwhile to mention that MAC/IP routes should not be used as = a proxy for MAC-only route? On Tuesday, May 13, 2014, Ali Sajassi (sajassi) wrote: Yes, although my email and Jorge's emails crossed each others, we are both = saying exactly the same thing. That's why I think the existing text is sufficient and we don't need to add= any thing more because both of the scenarios I mentioned below can happen = and the existing text covers them both. Cheers, Ali From: John E Drake Date: Tuesday, May 13, 2014 10:44 AM To: Cisco Employee , Jakob Heitz , "l2vpn@ietf.org" Cc: Antoni Przygienda Subject: RE: MAC route with IP Ali, As both Jorge and you have pointed out, there may indeed be cases for which= there should not be a MAC only route. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) Sent: Tuesday, May 13, 2014 10:38 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement =96 e.g., why doesn't the sender send MAC-only advertisem= ent as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz Date: --_000_CF98C654D3B54sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Jakob,

Changed your sentence to: "In such scenarios when the ARP en= try times out and causes the MAC/IP to be withdrawn, then the MAC informati= on will not be lost."

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, May 14, 2014 12:09= AM
To: Cisco Employee <sajassi@cisco.com>
Cc: Aldrin Isaac <aldrin.isaac@gmail.com>, John E Drake &l= t;jdrake@juniper.net>, "<= a href=3D"mailto:l2vpn@ietf.org">l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <an= toni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

"Note that a MAC-= only route can be advertised along with but independently of a MAC/IP route= in scenarios where the MAC learning over the access network is done in the= data-plane and independently of ARP snooping that generates the MAC/IP route. This ensures that if the ARP entry times = out and causes the MAC/IP to be withdrawn, then the MAC information will no= t be lost. In scenarios where the host MAC/IP is learned via the management= or control planes, the sender PE may advertise only the MAC/IP route."

--
Jakob Heitz.


On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:


Hi Aldrin,

How about the following:

"Note that a MAC-only route can be advertised along with but inde= pendent from MAC/IP route for scenarios where the MAC learning over access = network/node is done in data-plane and independent from ARP snooping that g= enerates MAC/IP route. In scenarios where host MAC/IP is learned via management or control plane, then the sender PE= may only generates and advertises MAC/IP route."

Cheers,
Ali

From: Aldrin Isaac <aldrin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 8:02 PM=
To: Cisco Employee <sajassi@cisco.com>
Cc: John E Drake <jdrake@juniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <an= toni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

How about:

"Note that a MAC-only route can be advertised along&nbs= p;with MAC/IP routes for use cases where a= n active MAC must remain reachable when all IP's become disa= ssociated with that MAC."

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:
Hi Aldrin,

I believe the application of MAC/IP route in section 10 is clear. Howe= ver, if you think we can make further clarification, please suggest the tex= t. We need to make sure the functionality that we specify is clearly descri= bed and explained. We don't need to describe/mention the functionality that is not used/needed.

Thanks,
Ali

From: Aldrin Isaac <al= drin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 11:14 A= M
To: Cisco Employee <sajassi= @cisco.com>
Cc: John E Drake <jdrake@j= uniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przy= gienda <antoni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

Would it be worthwhile to mention that MAC/IP routes should not be used as a proxy for MAC-only route?

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:

Yes, although my email and Jorge's emails crossed each others, we are = both saying exactly the same thing.

That's why I think the existing text is sufficient and we don't need t= o add any thing more because both of the scenarios I mentioned below can ha= ppen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake@ju= niper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi@c= isco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni= .przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,

 

As both Jorge and you have pointed out, th= ere may indeed be cases for which there should not be a MAC only route.<= /u>

 

Yours Irrespectively,=

 

John

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

 =

Even if there is reordering= by route reflector, then as I said, I don't see an issue here :-) In your = example, the receiver sees the withdrawn of the IP/MAC route before receivi= ng the MAC-only route. In that case, the traffic toward that MAC address will get flooding (or dropped if flood= ing is disabled) till it receives the MAC-only route. However, why does the= sender has to wait till it withdraws the IP/MAC advertisement before sendi= ng the MAC-only advertisement =96 e.g., why doesn't the sender send MAC-only advertisement as soon as it lea= rns it.

 =

Again, there are scenarios = in which learning is done in data-plane along with ARP suppression. In such= scenarios, the sender should send MAC-only route as soon as it learns it a= nd MAC/IP route when it snoops the ARP.  However, there are other scenarios where there is no MAC learni= ng in data-plane. In such scenario, when a VM becomes known, the MAC/IP rou= te is advertised and if the VM goes away, MAC/IP is withdrawn. In such scen= arios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

 =

Cheers,

Ali 

 =

From: Jakob= Heitz <jakob.heitz@ericsson.com>
Date:

--_000_CF98C654D3B54sajassiciscocom_-- From nobody Wed May 14 08:45:30 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191C51A00C3 for ; Wed, 14 May 2014 08:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86uazy6ECaXu for ; Wed, 14 May 2014 08:45:26 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D5CA61A00B8 for ; Wed, 14 May 2014 08:45:25 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-c4-5373402fbf0e Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1A.9C.07420.F2043735; Wed, 14 May 2014 12:06:39 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Wed, 14 May 2014 11:45:18 -0400 From: Jakob Heitz To: "Ali Sajassi (sajassi)" Subject: Re: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xD//I4AAP/4sfYA//Fe5YD/4i9hAP/EJsOA/4iDnNH/EE6MAP4gxYi+ Date: Wed, 14 May 2014 15:45:18 +0000 Message-ID: <09FCE01D-E028-482C-9323-C8674B2E54E7@ericsson.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_09FCE01DE028482C9323C8674B2E54E7ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonUFffoTjY4Od5fYuZu1tZLObcdbZ4 /O0Qu8W7s80sDiweU35vZPXYOesuu8eSJT+ZPK43XWUPYInisklJzcksSy3St0vgylh1orLg 4WzGisUT/rA1ML5tY+xi5OSQEDCRWPpjLiuELSZx4d56ti5GLg4hgaOMEk9PnGOHcJYzSqxq 2Q7WwSagI/HtehcziC0ioC8xsW0KI0gRM0hRx/Ut7CAJYQE5iV1LtzBBFMlLNP5YywpSJCKw ilHi0OJzbCAJFgFViZWtT8F28wrYSzw7vBeomQNoXZLEhD53EJMTaMGmXxogFYxA130/tQZs JLOAuMStJ/OZIK4WkFiy5zwzhC0q8fLxP1aImmSJ952PmCCmC0qcnPmEZQKjyCwk7bOQlM1C UgYRN5B4f24+M4StLbFs4WsoW19i45ezjMjiCxjZVzFylBanluWmGxlsYgTG2TEJNt0djHte Wh5iFOBgVOLhTVAtChZiTSwrrsw9xCjNwaIkzlvwJTZYSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2PE0mOH+KXzufT5U2OC0lL+f510XfAZ06l13+vubz3f7F5069qiJ2dX19llWlQelpnu 9vOQu7qzww5XBUv2nK1Xdhq/VmbZ81IspGvqpJWNO1/1Gvhudzx5ttchRq1useNPl+JrS/qU z0RwT36x/+91zZgVtSy2S3jmT3aXupF03NfA/VZfoYISS3FGoqEWc1FxIgAzHPHIlAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/LZhr6oLMSrg-u6z2U8SEk9ncVgo Cc: "l2vpn@ietf.org" , Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:45:28 -0000 --_000_09FCE01DE028482C9323C8674B2E54E7ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Looks good. Thanks. -- Jakob Heitz. On May 14, 2014, at 7:10 AM, "Ali Sajassi (sajassi)" > wrote: Hi Jakob, Changed your sentence to: "In such scenarios when the ARP entry times out a= nd causes the MAC/IP to be withdrawn, then the MAC information will not be = lost." Cheers, Ali From: Jakob Heitz > Date: Wednesday, May 14, 2014 12:09 AM To: Cisco Employee > Cc: Aldrin Isaac >, J= ohn E Drake >, "l2vpn@ietf.or= g" >, Antoni P= rzygienda > Subject: Re: MAC route with IP "Note that a MAC-only route can be advertised along with but independently = of a MAC/IP route in scenarios where the MAC learning over the access netwo= rk is done in the data-plane and independently of ARP snooping that generat= es the MAC/IP route. This ensures that if the ARP entry times out and cause= s the MAC/IP to be withdrawn, then the MAC information will not be lost. In= scenarios where the host MAC/IP is learned via the management or control p= lanes, the sender PE may advertise only the MAC/IP route." -- Jakob Heitz. On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" > wrote: Hi Aldrin, How about the following: "Note that a MAC-only route can be advertised along with but independent fr= om MAC/IP route for scenarios where the MAC learning over access network/no= de is done in data-plane and independent from ARP snooping that generates M= AC/IP route. In scenarios where host MAC/IP is learned via management or co= ntrol plane, then the sender PE may only generates and advertises MAC/IP ro= ute." Cheers, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 8:02 PM To: Cisco Employee > Cc: John E Drake >, Jakob Hei= tz >, "l2vpn@ietf= .org" >, Anton= i Przygienda > Subject: Re: MAC route with IP How about: "Note that a MAC-only route can be advertised along with MAC/IP routes for = use cases where an active MAC must remain reachable when all IP's become di= sassociated with that MAC." On Tuesday, May 13, 2014, Ali Sajassi (sajassi) > wrote: Hi Aldrin, I believe the application of MAC/IP route in section 10 is clear. However, = if you think we can make further clarification, please suggest the text. We= need to make sure the functionality that we specify is clearly described a= nd explained. We don't need to describe/mention the functionality that is n= ot used/needed. Thanks, Ali From: Aldrin Isaac > Date: Tuesday, May 13, 2014 11:14 AM To: Cisco Employee > Cc: John E Drake >, Jakob Heitz >, "l2vpn@ietf.org" >, Antoni Przygienda > Subject: Re: MAC route with IP Would it be worthwhile to mention that MAC/IP routes should not be used as = a proxy for MAC-only route? On Tuesday, May 13, 2014, Ali Sajassi (sajassi) wrote: Yes, although my email and Jorge's emails crossed each others, we are both = saying exactly the same thing. That's why I think the existing text is sufficient and we don't need to add= any thing more because both of the scenarios I mentioned below can happen = and the existing text covers them both. Cheers, Ali From: John E Drake Date: Tuesday, May 13, 2014 10:44 AM To: Cisco Employee , Jakob Heitz , "l2vpn@ietf.org" Cc: Antoni Przygienda Subject: RE: MAC route with IP Ali, As both Jorge and you have pointed out, there may indeed be cases for which= there should not be a MAC only route. Yours Irrespectively, John From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) Sent: Tuesday, May 13, 2014 10:38 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP Even if there is reordering by route reflector, then as I said, I don't see= an issue here :-) In your example, the receiver sees the withdrawn of the = IP/MAC route before receiving the MAC-only route. In that case, the traffic= toward that MAC address will get flooding (or dropped if flooding is disab= led) till it receives the MAC-only route. However, why does the sender has = to wait till it withdraws the IP/MAC advertisement before sending the MAC-o= nly advertisement =96 e.g., why doesn't the sender send MAC-only advertisem= ent as soon as it learns it. Again, there are scenarios in which learning is done in data-plane along wi= th ARP suppression. In such scenarios, the sender should send MAC-only rout= e as soon as it learns it and MAC/IP route when it snoops the ARP. However= , there are other scenarios where there is no MAC learning in data-plane. I= n such scenario, when a VM becomes known, the MAC/IP route is advertised an= d if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't wan= t to advertise an extra route (MAC-only route) unnecessarily. Cheers, Ali From: Jakob Heitz Date: --_000_09FCE01DE028482C9323C8674B2E54E7ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Looks good. Thanks.

--
Jakob Heitz.


On May 14, 2014, at 7:10 AM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:


Hi Jakob,

Changed your sentence to: "In such scenarios when the ARP en= try times out and causes the MAC/IP to be withdrawn, then the MAC informati= on will not be lost."

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, May 14, 2014 12:09= AM
To: Cisco Employee <sajassi@cisco.com>
Cc: Aldrin Isaac <aldrin.isaac@gmail.com>, John E Drake &l= t;jdrake@juniper.net>, "<= a href=3D"mailto:l2vpn@ietf.org">l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <an= toni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

"Note that a MAC-= only route can be advertised along with but independently of a MAC/IP route= in scenarios where the MAC learning over the access network is done in the= data-plane and independently of ARP snooping that generates the MAC/IP route. This ensures that if the ARP entry times = out and causes the MAC/IP to be withdrawn, then the MAC information will no= t be lost. In scenarios where the host MAC/IP is learned via the management= or control planes, the sender PE may advertise only the MAC/IP route."

--
Jakob Heitz.


On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" <sajassi@cisco.com> wrote:


Hi Aldrin,

How about the following:

"Note that a MAC-only route can be advertised along with but inde= pendent from MAC/IP route for scenarios where the MAC learning over access = network/node is done in data-plane and independent from ARP snooping that g= enerates MAC/IP route. In scenarios where host MAC/IP is learned via management or control plane, then the sender PE= may only generates and advertises MAC/IP route."

Cheers,
Ali

From: Aldrin Isaac <aldrin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 8:02 PM=
To: Cisco Employee <sajassi@cisco.com>
Cc: John E Drake <jdrake@juniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <an= toni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

How about:

"Note that a MAC-only route can be advertised along&nbs= p;with MAC/IP routes for use cases where a= n active MAC must remain reachable when all IP's become disa= ssociated with that MAC."

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:
Hi Aldrin,

I believe the application of MAC/IP route in section 10 is clear. Howe= ver, if you think we can make further clarification, please suggest the tex= t. We need to make sure the functionality that we specify is clearly descri= bed and explained. We don't need to describe/mention the functionality that is not used/needed.

Thanks,
Ali

From: Aldrin Isaac <al= drin.isaac@gmail.com>
Date: Tuesday, May 13, 2014 11:14 A= M
To: Cisco Employee <sajassi= @cisco.com>
Cc: John E Drake <jdrake@j= uniper.net>, Jakob Heitz <jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przy= gienda <antoni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

Would it be worthwhile to mention that MAC/IP routes should not be used as a proxy for MAC-only route?

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:

Yes, although my email and Jorge's emails crossed each others, we are = both saying exactly the same thing.

That's why I think the existing text is sufficient and we don't need t= o add any thing more because both of the scenarios I mentioned below can ha= ppen and the existing text covers them both.

Cheers,
Ali



From: John E Drake <jdrake@ju= niper.net>
Date: Tuesday, May 13, 2014 10:44 A= M
To: Cisco Employee <sajassi@c= isco.com>, Jakob Heitz <jakob.heitz@ericsson.com>, &quo= t;l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Antoni Przygienda <antoni= .przygienda@ericsson.com>
Subject: RE: MAC route with IP

Ali,

 

As both Jorge and you have pointed out, th= ere may indeed be cases for which there should not be a MAC only route.<= /u>

 

Yours Irrespectively,=

 

John

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf O= f Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; l2vpn@ietf.org
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

 

 =

Even if there is reordering= by route reflector, then as I said, I don't see an issue here :-) In your = example, the receiver sees the withdrawn of the IP/MAC route before receivi= ng the MAC-only route. In that case, the traffic toward that MAC address will get flooding (or dropped if flood= ing is disabled) till it receives the MAC-only route. However, why does the= sender has to wait till it withdraws the IP/MAC advertisement before sendi= ng the MAC-only advertisement =96 e.g., why doesn't the sender send MAC-only advertisement as soon as it lea= rns it.

 =

Again, there are scenarios = in which learning is done in data-plane along with ARP suppression. In such= scenarios, the sender should send MAC-only route as soon as it learns it a= nd MAC/IP route when it snoops the ARP.  However, there are other scenarios where there is no MAC learni= ng in data-plane. In such scenario, when a VM becomes known, the MAC/IP rou= te is advertised and if the VM goes away, MAC/IP is withdrawn. In such scen= arios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

 =

Cheers,

Ali 

 =

From: Jakob= Heitz <jakob.heitz@ericsson.com>
Date:

--_000_09FCE01DE028482C9323C8674B2E54E7ericssoncom_-- From nobody Wed May 14 09:07:59 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F981A02B4 for ; Wed, 14 May 2014 09:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh55tF3iXfSF for ; Wed, 14 May 2014 09:07:56 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBC31A029F for ; Wed, 14 May 2014 09:07:55 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 19so1744073ykq.24 for ; Wed, 14 May 2014 09:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OY+G5tuqgx2a5LqycygpYdtMTgtDErlADcUzpv2IYCo=; b=iSakpgVj2A1S5GqQae+EkgmtGESSQXULmLqCeJHkVeidgbIfEdRU6ARvuXUwxpaow2 OPjJWp1dhn8OY4F8N+zsHIDVcNUf2553r9Qrn13Pa6aS3NcTPcPPnNoY29XLoHCURoYd kmZtG+y08HUzPdn2x7NqYppO2URUXiD9mOwG2qIWZsTSywwen79wFazeyUS79CNv15aN rPoOgLyvQqpALiVTdLD1zbdx0YjAgv9KYuLgO/TfWa4q9MlTk64RFxKe30FQ67KbvF7t muiJfqXxgVIigu9B48WmfB3pCLT2mUKdT+8+IFk4vJuOJ8BiozKmjwsSRINzR/XFbZ7x hAuw== MIME-Version: 1.0 X-Received: by 10.236.167.105 with SMTP id h69mr6683253yhl.30.1400083669197; Wed, 14 May 2014 09:07:49 -0700 (PDT) Received: by 10.170.75.136 with HTTP; Wed, 14 May 2014 09:07:48 -0700 (PDT) In-Reply-To: <09FCE01D-E028-482C-9323-C8674B2E54E7@ericsson.com> References: <09FCE01D-E028-482C-9323-C8674B2E54E7@ericsson.com> Date: Wed, 14 May 2014 12:07:48 -0400 Message-ID: Subject: Re: MAC route with IP From: Aldrin Isaac To: Jakob Heitz Content-Type: multipart/alternative; boundary=20cf303f6b72c22a8704f95e6142 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/uU8yKrEI736baprCqAq4AzpK5e4 Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" , Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:07:58 -0000 --20cf303f6b72c22a8704f95e6142 Content-Type: text/plain; charset=UTF-8 +1 :) On Wednesday, May 14, 2014, Jakob Heitz wrote: > Looks good. Thanks. > > -- > Jakob Heitz. > > > On May 14, 2014, at 7:10 AM, "Ali Sajassi (sajassi)" > wrote: > > > Hi Jakob, > > Changed your sentence to: "In such scenarios when the ARP entry times > out and causes the MAC/IP to be withdrawn, then the MAC information will > not be lost." > > Cheers, > Ali > > From: Jakob Heitz > Date: Wednesday, May 14, 2014 12:09 AM > To: Cisco Employee > Cc: Aldrin Isaac , John E Drake < > jdrake@juniper.net>, "l2vpn@ietf.org" , Antoni Przygienda > > Subject: Re: MAC route with IP > > "Note that a MAC-only route can be advertised along with but > independently of a MAC/IP route in scenarios where the MAC learning over > the access network is done in the data-plane and independently of ARP > snooping that generates the MAC/IP route. This ensures that if the ARP > entry times out and causes the MAC/IP to be withdrawn, then the MAC > information will not be lost. In scenarios where the host MAC/IP is learned > via the management or control planes, the sender PE may advertise only the > MAC/IP route." > > -- > Jakob Heitz. > > > On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" > wrote: > > > Hi Aldrin, > > How about the following: > > "Note that a MAC-only route can be advertised along with but independent > from MAC/IP route for scenarios where the MAC learning over access > network/node is done in data-plane and independent from ARP snooping that > generates MAC/IP route. In scenarios where host MAC/IP is learned via > management or control plane, then the sender PE may only generates and > advertises MAC/IP route." > > Cheers, > Ali > > From: Aldrin Isaac > Date: Tuesday, May 13, 2014 8:02 PM > To: Cisco Employee > Cc: John E Drake , Jakob Heitz < > jakob.heitz@ericsson.com>, "l2vpn@ietf.org" , Antoni > Przygienda > Subject: Re: MAC route with IP > > --20cf303f6b72c22a8704f95e6142 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1=C2=A0 :)

On Wednesday, May 14, 2014, Jakob Heitz <= ;jakob.heitz@ericsson.com&g= t; wrote:
Looks good. Thanks.

--
Jakob Heitz.


On May 14, 2014, at 7:10 AM, "Ali Sajassi (sajassi)" <sajas= si@cisco.com> wrote:


Hi Jakob,

Changed your sentence to: "In such scenarios=C2=A0when the ARP en= try times out and causes the MAC/IP to be withdrawn, then the MAC informati= on will not be lost."

Cheers,
Ali

From: Jakob Heitz <jakob.heit= z@ericsson.com>
Date: Wednesday, May 14, 2014 12:09= AM
To: Cisco Employee <sajassi@c= isco.com>
Cc: Aldrin Isaac <aldrin.isaa= c@gmail.com>, John E Drake <jdrake@juniper.net>, "= l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

"Note that a MAC-only route can be advertised along with bu= t independently of a MAC/IP route in scenarios where the MAC learning over = the access network is done in the data-plane and independently of ARP snoop= ing that generates the MAC/IP route. This ensures that if the ARP entry times = out and causes the MAC/IP to be withdrawn, then the MAC information will no= t be lost. In scenarios where the host MAC/IP is learned via the management= or control planes, the sender PE may advertise only the MAC/IP route."

--
Jakob Heitz.


On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" <saja= ssi@cisco.com> wrote:


Hi Aldrin,

How about the following:

"Note that a MAC-only route can be advertised along with but inde= pendent from MAC/IP route for scenarios where the MAC learning over access = network/node is done in data-plane and independent from ARP snooping that g= enerates MAC/IP route. In scenarios where host MAC/IP is learned via management or control plane, then the sender PE= may only generates and advertises MAC/IP route."

Cheers,
Ali

From: Aldrin Isaac <aldrin.is= aac@gmail.com>
Date: Tuesday, May 13, 2014 8:02 PM=
To: Cisco Employee <sajassi@c= isco.com>
Cc: John E Drake <jdrake@juni= per.net>, Jakob Heitz <jakob.heitz@ericsson.com>, "= ;l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: Re: MAC route with IP
=
--20cf303f6b72c22a8704f95e6142-- From nobody Wed May 14 09:11:53 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D718F1A02CC for ; Wed, 14 May 2014 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX3MVwrBEHzY for ; Wed, 14 May 2014 09:11:44 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 33FB91A029F for ; Wed, 14 May 2014 09:11:44 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 19so1753318ykq.36 for ; Wed, 14 May 2014 09:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p2/9Lne1Ccqodi5ShX3FGSY1EjJrOaWEci86kAu4uuo=; b=aDoUQbwrC4aRZHt6YIVnFl1P0FzxV9QLJQdaPGOmLvxESBfmrco019kpHB55cecjlB ej5qo9pj2BKMw/aLba4ko2nJElUOCIaT+7BQLupVz4C6jJWQnOjJhoewEG/z2HD2jvC+ GpJK84O/nBcT7AMlOpnv4YrxPkaJ4CT9y/GbjvhMG0laoU1uaAHEINK7Pt0TVisl6/no rFGf+AqWVJRp3XFiuX/23inRAT6CtBPgKOFNHoGHYb8OHnHgtwA1Q0rVM6vf/OQonH+r W+gkVfKTOMs4AQJ3TGwHtpyr5/gNW8ba8DYE76u9BFU7tcbDUUilLmNmcItykl74VFwh DHxQ== MIME-Version: 1.0 X-Received: by 10.236.167.105 with SMTP id h69mr6713360yhl.30.1400083897297; Wed, 14 May 2014 09:11:37 -0700 (PDT) Received: by 10.170.75.136 with HTTP; Wed, 14 May 2014 09:11:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 May 2014 12:11:37 -0400 Message-ID: Subject: Re: MAC route with IP From: Aldrin Isaac To: "Ali Sajassi (sajassi)" Content-Type: multipart/alternative; boundary=20cf303f6b725ab22804f95e6f1d Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/5kAxCa_dMjxeBjVh3I4VZlTIvjI Cc: Antoni Przygienda , "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:11:52 -0000 --20cf303f6b725ab22804f95e6f1d Content-Type: text/plain; charset=UTF-8 Btw should "in such scenerarios when" be "in such scenarios where" ? On Wednesday, May 14, 2014, Ali Sajassi (sajassi) wrote: > > Hi Jakob, > > Changed your sentence to: "In such scenarios when the ARP entry times > out and causes the MAC/IP to be withdrawn, then the MAC information will > not be lost." > > Cheers, > Ali > > From: Jakob Heitz > > > Date: Wednesday, May 14, 2014 12:09 AM > To: Cisco Employee > > > Cc: Aldrin Isaac >, > John E Drake >, > "l2vpn@ietf.org " < > l2vpn@ietf.org >, Antoni > Przygienda > > > Subject: Re: MAC route with IP > > "Note that a MAC-only route can be advertised along with but > independently of a MAC/IP route in scenarios where the MAC learning over > the access network is done in the data-plane and independently of ARP > snooping that generates the MAC/IP route. This ensures that if the ARP > entry times out and causes the MAC/IP to be withdrawn, then the MAC > information will not be lost. In scenarios where the host MAC/IP is learned > via the management or control planes, the sender PE may advertise only the > MAC/IP route." > > -- > Jakob Heitz. > > > On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" > wrote: > > > Hi Aldrin, > > How about the following: > > "Note that a MAC-only route can be advertised along with but independent > from MAC/IP route for scenarios where the MAC learning over access > network/node is done in data-plane and independent from ARP snooping that > generates MAC/IP route. In scenarios where host MAC/IP is learned via > management or control plane, then the sender PE may only generates and > advertises MAC/IP route." > > Cheers, > Ali > > From: Aldrin Isaac > Date: Tuesday, May 13, 2014 8:02 PM > To: Cisco Employee > Cc: John E Drake , Jakob Heitz < > jakob.heitz@ericsson.com>, "l2vpn@ietf.org" , Antoni > Przygienda > Subject: Re: MAC route with IP > > How about: > > "Note that a MAC-only route can be advertised along with MAC/IP > routes for use cases where an active MAC must remain reachable when all > IP's become disassociated with that MAC." > > On Tuesday, May 13, 2014, Ali Sajassi (sajassi) wrote: > > Hi Aldrin, > > I believe the application of MAC/IP route in section 10 is clear. > However, if you think we can make further clarification, please suggest the > text. We need to make sure the functionality that we specify is clearly > described and explained. We don't need to describe/mention the > functionality that is not used/needed. > > Thanks, > Ali > > From: Aldrin Isaac > Date: Tuesday, May 13, 2014 11:14 AM > To: Cisco Employee > Cc: John E Drake , Jakob Heitz < > jakob.heitz@ericsson.com>, "l2vpn@ietf.org" , Antoni > Przygienda > Subject: Re: MAC route with IP > > Would it be worthwhile to mention that MAC/IP routes should no > > --20cf303f6b725ab22804f95e6f1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Btw should "in such scenerarios when" be "in such scenarios = where" ?

On Wednesday, May 14, 2014, Ali Sajassi (= sajassi) <sajassi@cisco.com>= wrote:

Hi Jakob,

Changed your sentence to: "In such scenarios=C2=A0when the ARP en= try times out and causes the MAC/IP to be withdrawn, then the MAC informati= on will not be lost."

Cheers,
Ali

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wednesday, May 14, 2014 12:09= AM
To: Cisco Employee <sajassi@cisco.com>
Cc: Aldrin Isaac <aldrin.isaac@gmail.com>, John E Drake <jdrake@juniper.net>, "l2vpn@ietf.org<= /a>" <l2vpn@ietf.org>, Antoni Przygienda <antoni.przygienda@= ericsson.com>
Subject: Re: MAC route with IP

"Note that a MAC-only route can be advertised along with bu= t independently of a MAC/IP route in scenarios where the MAC learning over = the access network is done in the data-plane and independently of ARP snoop= ing that generates the MAC/IP route. This ensures that if the ARP entry times = out and causes the MAC/IP to be withdrawn, then the MAC information will no= t be lost. In scenarios where the host MAC/IP is learned via the management= or control planes, the sender PE may advertise only the MAC/IP route."

--
Jakob Heitz.


On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" <saja= ssi@cisco.com> wrote:


Hi Aldrin,

How about the following:

"Note that a MAC-only route can be advertised along with but inde= pendent from MAC/IP route for scenarios where the MAC learning over access = network/node is done in data-plane and independent from ARP snooping that g= enerates MAC/IP route. In scenarios where host MAC/IP is learned via management or control plane, then the sender PE= may only generates and advertises MAC/IP route."

Cheers,
Ali

From: Aldrin Isaac <aldrin.is= aac@gmail.com>
Date: Tuesday, May 13, 2014 8:02 PM=
To: Cisco Employee <sajassi@c= isco.com>
Cc: John E Drake <jdrake@juni= per.net>, Jakob Heitz <jakob.heitz@ericsson.com>, "= ;l2vpn@ietf.org" <l2vpn@ietf.org>, Antoni Przygienda <antoni.przygienda@ericsson.com>
Subject: Re: MAC route with IP

How about:

"Note that a=C2=A0MAC-only route can=C2=A0be advertised along=C2= =A0with=C2=A0MAC/IP routes=C2=A0for=C2=A0use cases where=C2=A0= an active MAC must=C2=A0remain=C2=A0reachable when=C2=A0all IP's become= disassociated=C2=A0with that MAC."

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote:
--20cf303f6b725ab22804f95e6f1d-- From nobody Wed May 14 10:20:28 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1301A0323 for ; Wed, 14 May 2014 10:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM3pvARtt9Mf for ; Wed, 14 May 2014 10:20:06 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0291A032B for ; Wed, 14 May 2014 10:20:04 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-d8-5373565c47f7 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A8.82.07420.C5653735; Wed, 14 May 2014 13:41:16 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Wed, 14 May 2014 13:19:55 -0400 From: Jakob Heitz To: Aldrin Isaac , "Ali Sajassi (sajassi)" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//4r38P//LYQA//434xD//I4AAP/4sfYA//Fe5YD/4i9hAP/EJsOA/4iDnNH/EE6MAP4gex+A/EEmkiA= Date: Wed, 14 May 2014 17:19:55 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03057CEE@eusaamb109.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.10] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03057CEEeusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZXLonVjcmrDjY4Op1FYuZu1tZLObcdbZ4 /O0Qu8W7s80sDiweU35vZPXYOesuu8eSJT+ZPK43XWUPYInisklJzcksSy3St0vgyvjY85St 4NAtxoqlr5eyNTA+uMLYxcjJISFgInF9730WCFtM4sK99WxdjFwcQgJHGSUuPt4F5SxnlHg/ 5zkTSBWbgI7Et+tdzCC2iECExPbbTUBxDg5mgTqJljNZIGFhATmJzx1HmSBK5CUaf6xlBZkj IrCJUWLh79usIAkWAVWJGWv7wYp4BXwlpuz9yQixbDWjxKxVR8EWcAoEStzqOM0OYjMCnff9 1BqwBmYBcYlbT+YzQZwtILFkz3lmCFtU4uXjf6wQtpLEpKXnWCHq8yVmf7zHCLFMUOLkzCcs ExhFZyEZNQtJ2SwkZbPAftOUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYOUqLU8ty040M NjECI/CYBJvuDsY9Ly0PMQpwMCrx8CaoFgULsSaWFVfmHmKU5mBREuct+BIbLCSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoGxJrZ0z+GqC6V7ve8cLbvsGa7GUMnqZ3znR/UDNtWJDELubnfb SjiV3D/N6rKd9k7kgorkZHfR6R4LJO0KmVYYans4/i4xs/Hf+Uqp1PBn+WeWUJVUacujMQfX tKaayHz4MfN5+yxjuXJnZUGef585i/5Ia71jjQp7/jOqZY9d2Rq3Vsk6ayWW4oxEQy3mouJE AItjNGWhAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/DZTD3iUVdgU5UetZ7wyE-Hl2ALE Cc: "l2vpn@ietf.org" , Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:20:11 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03057CEEeusaamb109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBiZSBtb3JlIGluY2xpbmVkIHRvIHB1dCBhIGNvbW1hIGFmdGVyIHdoZW46DQoiSW4g c3VjaCBzY2VuYXJpb3MsIHdoZW4gdGhlIEFSUCBlbnRyeSB0aW1lcyBvdXQgYW5kIGNhdXNlcyB0 aGUgTUFDL0lQIHRvIGJlIHdpdGhkcmF3biwgdGhlbiB0aGUgTUFDIGluZm9ybWF0aW9uIHdpbGwg bm90IGJlIGxvc3QuIg0KDQpDaGVlcnMsDQpKYWtvYi4NCg0KRnJvbTogQWxkcmluIElzYWFjIFtt YWlsdG86YWxkcmluLmlzYWFjQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE0LCAy MDE0IDk6MTIgQU0NClRvOiBBbGkgU2FqYXNzaSAoc2FqYXNzaSkNCkNjOiBKYWtvYiBIZWl0ejsg Sm9obiBFIERyYWtlOyBsMnZwbkBpZXRmLm9yZzsgQW50b25pIFByenlnaWVuZGENClN1YmplY3Q6 IFJlOiBNQUMgcm91dGUgd2l0aCBJUA0KDQpCdHcgc2hvdWxkICJpbiBzdWNoIHNjZW5lcmFyaW9z IHdoZW4iIGJlICJpbiBzdWNoIHNjZW5hcmlvcyB3aGVyZSIgPw0KDQpPbiBXZWRuZXNkYXksIE1h eSAxNCwgMjAxNCwgQWxpIFNhamFzc2kgKHNhamFzc2kpIDxzYWphc3NpQGNpc2NvLmNvbTxtYWls dG86c2FqYXNzaUBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkgSmFrb2IsDQoNCkNoYW5nZWQgeW91 ciBzZW50ZW5jZSB0bzogIkluIHN1Y2ggc2NlbmFyaW9zIHdoZW4gdGhlIEFSUCBlbnRyeSB0aW1l cyBvdXQgYW5kIGNhdXNlcyB0aGUgTUFDL0lQIHRvIGJlIHdpdGhkcmF3biwgdGhlbiB0aGUgTUFD IGluZm9ybWF0aW9uIHdpbGwgbm90IGJlIGxvc3QuIg0KDQpDaGVlcnMsDQpBbGkNCg0KRnJvbTog SmFrb2IgSGVpdHogPGpha29iLmhlaXR6QGVyaWNzc29uLmNvbTxqYXZhc2NyaXB0Ol9lKCU3QiU3 RCwnY3ZtbCcsJ2pha29iLmhlaXR6QGVyaWNzc29uLmNvbScpOz4+DQpEYXRlOiBXZWRuZXNkYXks IE1heSAxNCwgMjAxNCAxMjowOSBBTQ0KVG86IENpc2NvIEVtcGxveWVlIDxzYWphc3NpQGNpc2Nv LmNvbTxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3NhamFzc2lAY2lzY28uY29tJyk7Pj4N CkNjOiBBbGRyaW4gSXNhYWMgPGFsZHJpbi5pc2FhY0BnbWFpbC5jb208amF2YXNjcmlwdDpfZSgl N0IlN0QsJ2N2bWwnLCdhbGRyaW4uaXNhYWNAZ21haWwuY29tJyk7Pj4sIEpvaG4gRSBEcmFrZSA8 amRyYWtlQGp1bmlwZXIubmV0PGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnamRyYWtlQGp1 bmlwZXIubmV0Jyk7Pj4sICJsMnZwbkBpZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3Zt bCcsJ2wydnBuQGlldGYub3JnJyk7PiIgPGwydnBuQGlldGYub3JnPGphdmFzY3JpcHQ6X2UoJTdC JTdELCdjdm1sJywnbDJ2cG5AaWV0Zi5vcmcnKTs+PiwgQW50b25pIFByenlnaWVuZGEgPGFudG9u aS5wcnp5Z2llbmRhQGVyaWNzc29uLmNvbTxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2Fu dG9uaS5wcnp5Z2llbmRhQGVyaWNzc29uLmNvbScpOz4+DQpTdWJqZWN0OiBSZTogTUFDIHJvdXRl IHdpdGggSVANCg0KIk5vdGUgdGhhdCBhIE1BQy1vbmx5IHJvdXRlIGNhbiBiZSBhZHZlcnRpc2Vk IGFsb25nIHdpdGggYnV0IGluZGVwZW5kZW50bHkgb2YgYSBNQUMvSVAgcm91dGUgaW4gc2NlbmFy aW9zIHdoZXJlIHRoZSBNQUMgbGVhcm5pbmcgb3ZlciB0aGUgYWNjZXNzIG5ldHdvcmsgaXMgZG9u ZSBpbiB0aGUgZGF0YS1wbGFuZSBhbmQgaW5kZXBlbmRlbnRseSBvZiBBUlAgc25vb3BpbmcgdGhh dCBnZW5lcmF0ZXMgdGhlIE1BQy9JUCByb3V0ZS4gVGhpcyBlbnN1cmVzIHRoYXQgaWYgdGhlIEFS UCBlbnRyeSB0aW1lcyBvdXQgYW5kIGNhdXNlcyB0aGUgTUFDL0lQIHRvIGJlIHdpdGhkcmF3biwg dGhlbiB0aGUgTUFDIGluZm9ybWF0aW9uIHdpbGwgbm90IGJlIGxvc3QuIEluIHNjZW5hcmlvcyB3 aGVyZSB0aGUgaG9zdCBNQUMvSVAgaXMgbGVhcm5lZCB2aWEgdGhlIG1hbmFnZW1lbnQgb3IgY29u dHJvbCBwbGFuZXMsIHRoZSBzZW5kZXIgUEUgbWF5IGFkdmVydGlzZSBvbmx5IHRoZSBNQUMvSVAg cm91dGUuIg0KDQotLQ0KSmFrb2IgSGVpdHouDQoNCg0KT24gTWF5IDEzLCAyMDE0LCBhdCAxMToy MiBQTSwgIkFsaSBTYWphc3NpIChzYWphc3NpKSIgPHNhamFzc2lAY2lzY28uY29tPG1haWx0bzpz YWphc3NpQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBBbGRyaW4sDQoNCkhvdyBhYm91dCB0aGUg Zm9sbG93aW5nOg0KDQoiTm90ZSB0aGF0IGEgTUFDLW9ubHkgcm91dGUgY2FuIGJlIGFkdmVydGlz ZWQgYWxvbmcgd2l0aCBidXQgaW5kZXBlbmRlbnQgZnJvbSBNQUMvSVAgcm91dGUgZm9yIHNjZW5h cmlvcyB3aGVyZSB0aGUgTUFDIGxlYXJuaW5nIG92ZXIgYWNjZXNzIG5ldHdvcmsvbm9kZSBpcyBk b25lIGluIGRhdGEtcGxhbmUgYW5kIGluZGVwZW5kZW50IGZyb20gQVJQIHNub29waW5nIHRoYXQg Z2VuZXJhdGVzIE1BQy9JUCByb3V0ZS4gSW4gc2NlbmFyaW9zIHdoZXJlIGhvc3QgTUFDL0lQIGlz IGxlYXJuZWQgdmlhIG1hbmFnZW1lbnQgb3IgY29udHJvbCBwbGFuZSwgdGhlbiB0aGUgc2VuZGVy IFBFIG1heSBvbmx5IGdlbmVyYXRlcyBhbmQgYWR2ZXJ0aXNlcyBNQUMvSVAgcm91dGUuIg0KDQpD aGVlcnMsDQpBbGkNCg0KRnJvbTogQWxkcmluIElzYWFjIDxhbGRyaW4uaXNhYWNAZ21haWwuY29t PG1haWx0bzphbGRyaW4uaXNhYWNAZ21haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE1heSAxMywg MjAxNCA4OjAyIFBNDQpUbzogQ2lzY28gRW1wbG95ZWUgPHNhamFzc2lAY2lzY28uY29tPG1haWx0 bzpzYWphc3NpQGNpc2NvLmNvbT4+DQpDYzogSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5u ZXQ8bWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldD4+LCBKYWtvYiBIZWl0eiA8amFrb2IuaGVpdHpA ZXJpY3Nzb24uY29tPG1haWx0bzpqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb20+PiwgImwydnBuQGll dGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+PiwgQW50b25pIFByenlnaWVuZGEgPGFudG9uaS5wcnp5Z2llbmRhQGVyaWNz c29uLmNvbTxtYWlsdG86YW50b25pLnByenlnaWVuZGFAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6 IFJlOiBNQUMgcm91dGUgd2l0aCBJUA0KDQpIb3cgYWJvdXQ6DQoNCiJOb3RlIHRoYXQgYSBNQUMt b25seSByb3V0ZSBjYW4gYmUgYWR2ZXJ0aXNlZCBhbG9uZyB3aXRoIE1BQy9JUCByb3V0ZXMgZm9y IHVzZSBjYXNlcyB3aGVyZSBhbiBhY3RpdmUgTUFDIG11c3QgcmVtYWluIHJlYWNoYWJsZSB3aGVu IGFsbCBJUCdzIGJlY29tZSBkaXNhc3NvY2lhdGVkIHdpdGggdGhhdCBNQUMuIg0KDQpPbiBUdWVz ZGF5LCBNYXkgMTMsIDIwMTQsIEFsaSBTYWphc3NpIChzYWphc3NpKSA8c2FqYXNzaUBjaXNjby5j b208bWFpbHRvOnNhamFzc2lAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBBbGRyaW4sDQoNCkkgYmVs aWV2ZSB0aGUgYXBwbGljYXRpb24gb2YgTUFDL0lQIHJvdXRlIGluIHNlY3Rpb24gMTAgaXMgY2xl YXIuIEhvd2V2ZXIsIGlmIHlvdSB0aGluayB3ZSBjYW4gbWFrZSBmdXJ0aGVyIGNsYXJpZmljYXRp b24sIHBsZWFzZSBzdWdnZXN0IHRoZSB0ZXh0LiBXZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGUgZnVu Y3Rpb25hbGl0eSB0aGF0IHdlIHNwZWNpZnkgaXMgY2xlYXJseSBkZXNjcmliZWQgYW5kIGV4cGxh aW5lZC4gV2UgZG9uJ3QgbmVlZCB0byBkZXNjcmliZS9tZW50aW9uIHRoZSBmdW5jdGlvbmFsaXR5 IHRoYXQgaXMgbm90IHVzZWQvbmVlZGVkLg0KDQpUaGFua3MsDQpBbGkNCg0KRnJvbTogQWxkcmlu IElzYWFjIDxhbGRyaW4uaXNhYWNAZ21haWwuY29tPG1haWx0bzphbGRyaW4uaXNhYWNAZ21haWwu Y29tPj4NCkRhdGU6IFR1ZXNkYXksIE1heSAxMywgMjAxNCAxMToxNCBBTQ0KVG86IENpc2NvIEVt cGxveWVlIDxzYWphc3NpQGNpc2NvLmNvbTxtYWlsdG86c2FqYXNzaUBjaXNjby5jb20+Pg0KQ2M6 IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0PG1haWx0bzpqZHJha2VAanVuaXBlci5u ZXQ+PiwgSmFrb2IgSGVpdHogPGpha29iLmhlaXR6QGVyaWNzc29uLmNvbTxtYWlsdG86amFrb2Iu aGVpdHpAZXJpY3Nzb24uY29tPj4sICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4sIEFudG9uaSBQcnp5 Z2llbmRhIDxhbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208bWFpbHRvOmFudG9uaS5wcnp5 Z2llbmRhQGVyaWNzc29uLmNvbT4+DQpTdWJqZWN0OiBSZTogTUFDIHJvdXRlIHdpdGggSVANCg0K V291bGQgaXQgYmUgd29ydGh3aGlsZSB0byBtZW50aW9uIHRoYXQgTUFDL0lQIHJvdXRlcyBzaG91 bGQgbm8NCg== --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03057CEEeusaamb109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1 Y2lkYSBHcmFuZGUiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3 b3VsZCBiZSBtb3JlIGluY2xpbmVkIHRvIHB1dCBhIGNvbW1hIGFmdGVyIHdoZW46PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDtJbiBzdWNoIHNjZW5hcmlvcywmbmJzcDt3aGVuIHRo ZSBBUlAgZW50cnkgdGltZXMgb3V0IGFuZCBjYXVzZXMgdGhlIE1BQy9JUCB0byBiZSB3aXRoZHJh d24sIHRoZW4gdGhlIE1BQyBpbmZvcm1hdGlvbiB3aWxsIG5vdCBiZSBsb3N0LiZxdW90OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5KYWtvYi48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWxkcmluIElzYWFjIFttYWlsdG86YWxkcmluLmlzYWFj QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSAxNCwgMjAxNCA5 OjEyIEFNPGJyPg0KPGI+VG86PC9iPiBBbGkgU2FqYXNzaSAoc2FqYXNzaSk8YnI+DQo8Yj5DYzo8 L2I+IEpha29iIEhlaXR6OyBKb2huIEUgRHJha2U7IGwydnBuQGlldGYub3JnOyBBbnRvbmkgUHJ6 eWdpZW5kYTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTUFDIHJvdXRlIHdpdGggSVA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ0dyBzaG91bGQgJnF1b3Q7aW4gc3VjaCBzY2VuZXJh cmlvcyB3aGVuJnF1b3Q7IGJlICZxdW90O2luIHN1Y2ggc2NlbmFyaW9zIHdoZXJlJnF1b3Q7ID88 YnI+DQo8YnI+DQpPbiBXZWRuZXNkYXksIE1heSAxNCwgMjAxNCwgQWxpIFNhamFzc2kgKHNhamFz c2kpICZsdDs8YSBocmVmPSJtYWlsdG86c2FqYXNzaUBjaXNjby5jb20iPnNhamFzc2lAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBKYWtvYiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q2hhbmdlZCB5b3VyIHNlbnRlbmNl IHRvOiAmcXVvdDtJbiBzdWNoIHNjZW5hcmlvcyZuYnNwO3doZW4gdGhlIEFSUCBlbnRyeSB0aW1l cyBvdXQgYW5kIGNhdXNlcyB0aGUgTUFDL0lQIHRvIGJlIHdpdGhkcmF3biwgdGhlbiB0aGUgTUFD IGluZm9ybWF0aW9uIHdpbGwgbm90IGJlIGxvc3QuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkFsaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgR3JhbmRlJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgR3JhbmRlJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5KYWtvYiBIZWl0eiAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpf ZSglN0IlN0QsJ2N2bWwnLCdqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb20nKTsiIHRhcmdldD0iX2Js YW5rIj5qYWtvYi5oZWl0ekBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5X ZWRuZXNkYXksIE1heSAxNCwgMjAxNCAxMjowOSBBTTxicj4NCjxiPlRvOiA8L2I+Q2lzY28gRW1w bG95ZWUgJmx0OzxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnc2FqYXNzaUBj aXNjby5jb20nKTsiIHRhcmdldD0iX2JsYW5rIj5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5BbGRyaW4gSXNhYWMgJmx0OzxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdC JTdELCdjdm1sJywnYWxkcmluLmlzYWFjQGdtYWlsLmNvbScpOyIgdGFyZ2V0PSJfYmxhbmsiPmFs ZHJpbi5pc2FhY0BnbWFpbC5jb208L2E+Jmd0OywgSm9obiBFIERyYWtlICZsdDs8YSBocmVmPSJq YXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2pkcmFrZUBqdW5pcGVyLm5ldCcpOyIgdGFyZ2V0 PSJfYmxhbmsiPmpkcmFrZUBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJqYXZh c2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2wydnBuQGlldGYub3JnJyk7IiB0YXJnZXQ9Il9ibGFu ayI+bDJ2cG5AaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9ImphdmFzY3JpcHQ6X2Uo JTdCJTdELCdjdm1sJywnbDJ2cG5AaWV0Zi5vcmcnKTsiIHRhcmdldD0iX2JsYW5rIj5sMnZwbkBp ZXRmLm9yZzwvYT4mZ3Q7LCBBbnRvbmkgUHJ6eWdpZW5kYSAmbHQ7PGEgaHJlZj0iamF2YXNjcmlw dDpfZSglN0IlN0QsJ2N2bWwnLCdhbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb20nKTsiIHRh cmdldD0iX2JsYW5rIj5hbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogTUFDIHJvdXRlIHdpdGggSVA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDtOb3RlIHRoYXQgYSBNQUMtb25s eSByb3V0ZSBjYW4gYmUgYWR2ZXJ0aXNlZCBhbG9uZyB3aXRoIGJ1dCBpbmRlcGVuZGVudGx5IG9m IGEgTUFDL0lQIHJvdXRlIGluIHNjZW5hcmlvcyB3aGVyZSB0aGUgTUFDIGxlYXJuaW5nIG92ZXIg dGhlIGFjY2VzcyBuZXR3b3JrIGlzIGRvbmUNCiBpbiB0aGUgZGF0YS1wbGFuZSBhbmQgaW5kZXBl bmRlbnRseSBvZiBBUlAgc25vb3BpbmcgdGhhdCBnZW5lcmF0ZXMgdGhlIE1BQy9JUCByb3V0ZS4g VGhpcyBlbnN1cmVzIHRoYXQgaWYgdGhlIEFSUCBlbnRyeSB0aW1lcyBvdXQgYW5kIGNhdXNlcyB0 aGUgTUFDL0lQIHRvIGJlIHdpdGhkcmF3biwgdGhlbiB0aGUgTUFDIGluZm9ybWF0aW9uIHdpbGwg bm90IGJlIGxvc3QuIEluIHNjZW5hcmlvcyB3aGVyZSB0aGUgaG9zdCBNQUMvSVAgaXMgbGVhcm5l ZA0KIHZpYSB0aGUgbWFuYWdlbWVudCBvciBjb250cm9sIHBsYW5lcywgdGhlIHNlbmRlciBQRSBt YXkgYWR2ZXJ0aXNlIG9ubHkgdGhlIE1BQy9JUCByb3V0ZS4mcXVvdDs8YnI+DQo8YnI+DQotLSA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5KYWtvYiBIZWl0ei48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxicj4NCk9uIE1heSAxMywgMjAxNCwgYXQgMTE6MjIgUE0sICZxdW90O0FsaSBTYWph c3NpIChzYWphc3NpKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhamFzc2lAY2lzY28uY29t Ij5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBBbGRyaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkhvdyBhYm91dCB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDtOb3RlIHRoYXQgYSBNQUMtb25seSByb3V0ZSBjYW4gYmUg YWR2ZXJ0aXNlZCBhbG9uZyB3aXRoIGJ1dCBpbmRlcGVuZGVudCBmcm9tIE1BQy9JUCByb3V0ZSBm b3Igc2NlbmFyaW9zIHdoZXJlIHRoZSBNQUMgbGVhcm5pbmcgb3ZlciBhY2Nlc3MgbmV0d29yay9u b2RlIGlzIGRvbmUNCiBpbiBkYXRhLXBsYW5lIGFuZCBpbmRlcGVuZGVudCBmcm9tIEFSUCBzbm9v cGluZyB0aGF0IGdlbmVyYXRlcyBNQUMvSVAgcm91dGUuIEluIHNjZW5hcmlvcyB3aGVyZSBob3N0 IE1BQy9JUCBpcyBsZWFybmVkIHZpYSBtYW5hZ2VtZW50IG9yIGNvbnRyb2wgcGxhbmUsIHRoZW4g dGhlIHNlbmRlciBQRSBtYXkgb25seSBnZW5lcmF0ZXMgYW5kIGFkdmVydGlzZXMgTUFDL0lQIHJv dXRlLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbGk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVj aWRhIEdyYW5kZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 THVjaWRhIEdyYW5kZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QWxkcmlu IElzYWFjICZsdDs8YSBocmVmPSJtYWlsdG86YWxkcmluLmlzYWFjQGdtYWlsLmNvbSI+YWxkcmlu LmlzYWFjQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE1heSAx MywgMjAxNCA4OjAyIFBNPGJyPg0KPGI+VG86IDwvYj5DaXNjbyBFbXBsb3llZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNhamFzc2lAY2lzY28uY29tIj5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5Kb2huIEUgRHJha2UgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJha2VAanVu aXBlci5uZXQiPmpkcmFrZUBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCBKYWtvYiBIZWl0eiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpha29iLmhlaXR6QGVyaWNzc29uLmNvbSI+amFrb2IuaGVpdHpAZXJpY3Nz b24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2 cG5AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmci PmwydnBuQGlldGYub3JnPC9hPiZndDssDQogQW50b25pIFByenlnaWVuZGEgJmx0OzxhIGhyZWY9 Im1haWx0bzphbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb20iPmFudG9uaS5wcnp5Z2llbmRh QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBNQUMgcm91dGUg d2l0aCBJUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SG93IGFi b3V0Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDtOb3RlIHRoYXQgYSZuYnNw O01BQy1vbmx5IHJvdXRlIGNhbiZuYnNwO2JlIGFkdmVydGlzZWQgYWxvbmcmbmJzcDt3aXRoJm5i c3A7TUFDL0lQIHJvdXRlcyZuYnNwO2ZvciZuYnNwO3VzZSBjYXNlcyB3aGVyZSZuYnNwO2FuIGFj dGl2ZSBNQUMgbXVzdCZuYnNwO3JlbWFpbiZuYnNwO3JlYWNoYWJsZSB3aGVuJm5ic3A7YWxsIElQ J3MgYmVjb21lIGRpc2Fzc29jaWF0ZWQmbmJzcDt3aXRoDQogdGhhdCBNQUMuJnF1b3Q7PGJyPg0K PGJyPg0KT24gVHVlc2RheSwgTWF5IDEzLCAyMDE0LCBBbGkgU2FqYXNzaSAoc2FqYXNzaSkgJmx0 OzxhIGhyZWY9Im1haWx0bzpzYWphc3NpQGNpc2NvLmNvbSI+c2FqYXNzaUBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkg QWxkcmluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGJlbGlldmUgdGhl IGFwcGxpY2F0aW9uIG9mIE1BQy9JUCByb3V0ZSBpbiBzZWN0aW9uIDEwIGlzIGNsZWFyLiBIb3dl dmVyLCBpZiB5b3UgdGhpbmsgd2UgY2FuIG1ha2UgZnVydGhlciBjbGFyaWZpY2F0aW9uLCBwbGVh c2Ugc3VnZ2VzdCB0aGUgdGV4dC4gV2UgbmVlZCB0bw0KIG1ha2Ugc3VyZSB0aGUgZnVuY3Rpb25h bGl0eSB0aGF0IHdlIHNwZWNpZnkgaXMgY2xlYXJseSBkZXNjcmliZWQgYW5kIGV4cGxhaW5lZC4g V2UgZG9uJ3QgbmVlZCB0byBkZXNjcmliZS9tZW50aW9uIHRoZSBmdW5jdGlvbmFsaXR5IHRoYXQg aXMgbm90IHVzZWQvbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbGk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7THVjaWRhIEdyYW5kZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7THVjaWRhIEdyYW5kZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+QWxkcmluIElzYWFjICZsdDs8YSBocmVmPSJtYWlsdG86YWxkcmluLmlzYWFjQGdtYWlsLmNv bSI+YWxkcmluLmlzYWFjQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNk YXksIE1heSAxMywgMjAxNCAxMToxNCBBTTxicj4NCjxiPlRvOiA8L2I+Q2lzY28gRW1wbG95ZWUg Jmx0OzxhIGhyZWY9Im1haWx0bzpzYWphc3NpQGNpc2NvLmNvbSI+c2FqYXNzaUBjaXNjby5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Sm9obiBFIERyYWtlICZsdDs8YSBocmVmPSJtYWlsdG86 amRyYWtlQGp1bmlwZXIubmV0Ij5qZHJha2VAanVuaXBlci5uZXQ8L2E+Jmd0OywgSmFrb2IgSGVp dHogJmx0OzxhIGhyZWY9Im1haWx0bzpqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb20iPmpha29iLmhl aXR6QGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0 Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmwydnBu QGlldGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT4mZ3Q7LA0KIEFudG9uaSBQcnp5Z2llbmRhICZs dDs8YSBocmVmPSJtYWlsdG86YW50b25pLnByenlnaWVuZGFAZXJpY3Nzb24uY29tIj5hbnRvbmku cHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog TUFDIHJvdXRlIHdpdGggSVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPldvdWxkIGl0IGJlIHdvcnRod2hpbGUgdG8gbWVudGlvbiZuYnNwO3RoYXQgTUFDL0lQIHJv dXRlcyBzaG91bGQgbm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03057CEEeusaamb109erics_-- From nobody Wed May 14 12:33:21 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CD21A0146 for ; Wed, 14 May 2014 12:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAxkecUELX8s for ; Wed, 14 May 2014 12:33:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 755231A00D5 for ; Wed, 14 May 2014 12:33:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT87535; Wed, 14 May 2014 19:33:04 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 14 May 2014 20:32:26 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 14 May 2014 20:33:02 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Wed, 14 May 2014 12:32:58 -0700 From: Linda Dunbar To: Jakob Heitz , Aldrin Isaac , "Ali Sajassi (sajassi)" Subject: RE: MAC route with IP Thread-Topic: MAC route with IP Thread-Index: AQHPbyDoaQfHHQKqR0C1MGMVDrT485tAEOWAgAAM+ACAAHWeAIAAIfmAgAATFYD//69u0A== Date: Wed, 14 May 2014 19:32:58 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D09BE9@dfweml701-chm.china.huawei.com> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03057CEE@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03057CEE@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.155] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D09BE9dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/8su3X-bUVKijRSX8mWsJG6EWq2c Cc: "l2vpn@ietf.org" , Antoni Przygienda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 19:33:19 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D09BE9dfweml701chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXNu4oCZdCBpdCBzYW1lIGFzIOKAnFN0aWNreSBNQUPigJ0gb3Ig4oCcUGVyc2lzdGVudCBNQUMg TGVhcm5pbmfigJ0/DQoNCkxpbmRhDQoNCkZyb206IEwydnBuIFttYWlsdG86bDJ2cG4tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpha29iIEhlaXR6DQpTZW50OiBXZWRuZXNkYXksIE1h eSAxNCwgMjAxNCAxMjoyMCBQTQ0KVG86IEFsZHJpbiBJc2FhYzsgQWxpIFNhamFzc2kgKHNhamFz c2kpDQpDYzogbDJ2cG5AaWV0Zi5vcmc7IEFudG9uaSBQcnp5Z2llbmRhDQpTdWJqZWN0OiBSRTog TUFDIHJvdXRlIHdpdGggSVANCg0KSSB3b3VsZCBiZSBtb3JlIGluY2xpbmVkIHRvIHB1dCBhIGNv bW1hIGFmdGVyIHdoZW46DQoiSW4gc3VjaCBzY2VuYXJpb3MsIHdoZW4gdGhlIEFSUCBlbnRyeSB0 aW1lcyBvdXQgYW5kIGNhdXNlcyB0aGUgTUFDL0lQIHRvIGJlIHdpdGhkcmF3biwgdGhlbiB0aGUg TUFDIGluZm9ybWF0aW9uIHdpbGwgbm90IGJlIGxvc3QuIg0KDQpDaGVlcnMsDQpKYWtvYi4NCg0K RnJvbTogQWxkcmluIElzYWFjIFttYWlsdG86YWxkcmluLmlzYWFjQGdtYWlsLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgTWF5IDE0LCAyMDE0IDk6MTIgQU0NClRvOiBBbGkgU2FqYXNzaSAoc2FqYXNz aSkNCkNjOiBKYWtvYiBIZWl0ejsgSm9obiBFIERyYWtlOyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86 bDJ2cG5AaWV0Zi5vcmc+OyBBbnRvbmkgUHJ6eWdpZW5kYQ0KU3ViamVjdDogUmU6IE1BQyByb3V0 ZSB3aXRoIElQDQoNCkJ0dyBzaG91bGQgImluIHN1Y2ggc2NlbmVyYXJpb3Mgd2hlbiIgYmUgImlu IHN1Y2ggc2NlbmFyaW9zIHdoZXJlIiA/DQoNCk9uIFdlZG5lc2RheSwgTWF5IDE0LCAyMDE0LCBB bGkgU2FqYXNzaSAoc2FqYXNzaSkgPHNhamFzc2lAY2lzY28uY29tPG1haWx0bzpzYWphc3NpQGNp c2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBKYWtvYiwNCg0KQ2hhbmdlZCB5b3VyIHNlbnRlbmNlIHRv OiAiSW4gc3VjaCBzY2VuYXJpb3Mgd2hlbiB0aGUgQVJQIGVudHJ5IHRpbWVzIG91dCBhbmQgY2F1 c2VzIHRoZSBNQUMvSVAgdG8gYmUgd2l0aGRyYXduLCB0aGVuIHRoZSBNQUMgaW5mb3JtYXRpb24g d2lsbCBub3QgYmUgbG9zdC4iDQoNCkNoZWVycywNCkFsaQ0KDQpGcm9tOiBKYWtvYiBIZWl0eiA8 amFrb2IuaGVpdHpAZXJpY3Nzb24uY29tPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnamFr b2IuaGVpdHpAZXJpY3Nzb24uY29tJyk7Pj4NCkRhdGU6IFdlZG5lc2RheSwgTWF5IDE0LCAyMDE0 IDEyOjA5IEFNDQpUbzogQ2lzY28gRW1wbG95ZWUgPHNhamFzc2lAY2lzY28uY29tPGphdmFzY3Jp cHQ6X2UoJTdCJTdELCdjdm1sJywnc2FqYXNzaUBjaXNjby5jb20nKTs+Pg0KQ2M6IEFsZHJpbiBJ c2FhYyA8YWxkcmluLmlzYWFjQGdtYWlsLmNvbTxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcs J2FsZHJpbi5pc2FhY0BnbWFpbC5jb20nKTs+PiwgSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBl ci5uZXQ8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdqZHJha2VAanVuaXBlci5uZXQnKTs+ PiwgImwydnBuQGlldGYub3JnPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnbDJ2cG5AaWV0 Zi5vcmcnKTs+IiA8bDJ2cG5AaWV0Zi5vcmc8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCds MnZwbkBpZXRmLm9yZycpOz4+LCBBbnRvbmkgUHJ6eWdpZW5kYSA8YW50b25pLnByenlnaWVuZGFA ZXJpY3Nzb24uY29tPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnYW50b25pLnByenlnaWVu ZGFAZXJpY3Nzb24uY29tJyk7Pj4NClN1YmplY3Q6IFJlOiBNQUMgcm91dGUgd2l0aCBJUA0KDQoi Tm90ZSB0aGF0IGEgTUFDLW9ubHkgcm91dGUgY2FuIGJlIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBi dXQgaW5kZXBlbmRlbnRseSBvZiBhIE1BQy9JUCByb3V0ZSBpbiBzY2VuYXJpb3Mgd2hlcmUgdGhl IE1BQyBsZWFybmluZyBvdmVyIHRoZSBhY2Nlc3MgbmV0d29yayBpcyBkb25lIGluIHRoZSBkYXRh LXBsYW5lIGFuZCBpbmRlcGVuZGVudGx5IG9mIEFSUCBzbm9vcGluZyB0aGF0IGdlbmVyYXRlcyB0 aGUgTUFDL0lQIHJvdXRlLiBUaGlzIGVuc3VyZXMgdGhhdCBpZiB0aGUgQVJQIGVudHJ5IHRpbWVz IG91dCBhbmQgY2F1c2VzIHRoZSBNQUMvSVAgdG8gYmUgd2l0aGRyYXduLCB0aGVuIHRoZSBNQUMg aW5mb3JtYXRpb24gd2lsbCBub3QgYmUgbG9zdC4gSW4gc2NlbmFyaW9zIHdoZXJlIHRoZSBob3N0 IE1BQy9JUCBpcyBsZWFybmVkIHZpYSB0aGUgbWFuYWdlbWVudCBvciBjb250cm9sIHBsYW5lcywg dGhlIHNlbmRlciBQRSBtYXkgYWR2ZXJ0aXNlIG9ubHkgdGhlIE1BQy9JUCByb3V0ZS4iDQoNCi0t DQpKYWtvYiBIZWl0ei4NCg0KDQpPbiBNYXkgMTMsIDIwMTQsIGF0IDExOjIyIFBNLCAiQWxpIFNh amFzc2kgKHNhamFzc2kpIiA8c2FqYXNzaUBjaXNjby5jb208bWFpbHRvOnNhamFzc2lAY2lzY28u Y29tPj4gd3JvdGU6DQoNCkhpIEFsZHJpbiwNCg0KSG93IGFib3V0IHRoZSBmb2xsb3dpbmc6DQoN CiJOb3RlIHRoYXQgYSBNQUMtb25seSByb3V0ZSBjYW4gYmUgYWR2ZXJ0aXNlZCBhbG9uZyB3aXRo IGJ1dCBpbmRlcGVuZGVudCBmcm9tIE1BQy9JUCByb3V0ZSBmb3Igc2NlbmFyaW9zIHdoZXJlIHRo ZSBNQUMgbGVhcm5pbmcgb3ZlciBhY2Nlc3MgbmV0d29yay9ub2RlIGlzIGRvbmUgaW4gZGF0YS1w bGFuZSBhbmQgaW5kZXBlbmRlbnQgZnJvbSBBUlAgc25vb3BpbmcgdGhhdCBnZW5lcmF0ZXMgTUFD L0lQIHJvdXRlLiBJbiBzY2VuYXJpb3Mgd2hlcmUgaG9zdCBNQUMvSVAgaXMgbGVhcm5lZCB2aWEg bWFuYWdlbWVudCBvciBjb250cm9sIHBsYW5lLCB0aGVuIHRoZSBzZW5kZXIgUEUgbWF5IG9ubHkg Z2VuZXJhdGVzIGFuZCBhZHZlcnRpc2VzIE1BQy9JUCByb3V0ZS4iDQoNCkNoZWVycywNCkFsaQ0K DQpGcm9tOiBBbGRyaW4gSXNhYWMgPGFsZHJpbi5pc2FhY0BnbWFpbC5jb208bWFpbHRvOmFsZHJp bi5pc2FhY0BnbWFpbC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWF5IDEzLCAyMDE0IDg6MDIgUE0N ClRvOiBDaXNjbyBFbXBsb3llZSA8c2FqYXNzaUBjaXNjby5jb208bWFpbHRvOnNhamFzc2lAY2lz Y28uY29tPj4NCkNjOiBKb2huIEUgRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldDxtYWlsdG86amRy YWtlQGp1bmlwZXIubmV0Pj4sIEpha29iIEhlaXR6IDxqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb208 bWFpbHRvOmpha29iLmhlaXR6QGVyaWNzc29uLmNvbT4+LCAibDJ2cG5AaWV0Zi5vcmc8bWFpbHRv OmwydnBuQGlldGYub3JnPiIgPGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+ LCBBbnRvbmkgUHJ6eWdpZW5kYSA8YW50b25pLnByenlnaWVuZGFAZXJpY3Nzb24uY29tPG1haWx0 bzphbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb20+Pg0KU3ViamVjdDogUmU6IE1BQyByb3V0 ZSB3aXRoIElQDQoNCkhvdyBhYm91dDoNCg0KIk5vdGUgdGhhdCBhIE1BQy1vbmx5IHJvdXRlIGNh biBiZSBhZHZlcnRpc2VkIGFsb25nIHdpdGggTUFDL0lQIHJvdXRlcyBmb3IgdXNlIGNhc2VzIHdo ZXJlIGFuIGFjdGl2ZSBNQUMgbXVzdCByZW1haW4gcmVhY2hhYmxlIHdoZW4gYWxsIElQJ3MgYmVj b21lIGRpc2Fzc29jaWF0ZWQgd2l0aCB0aGF0IE1BQy4iDQoNCk9uIFR1ZXNkYXksIE1heSAxMywg MjAxNCwgQWxpIFNhamFzc2kgKHNhamFzc2kpIDxzYWphc3NpQGNpc2NvLmNvbTxtYWlsdG86c2Fq YXNzaUBjaXNjby5jb20+PiB3cm90ZToNCkhpIEFsZHJpbiwNCg0KSSBiZWxpZXZlIHRoZSBhcHBs aWNhdGlvbiBvZiBNQUMvSVAgcm91dGUgaW4gc2VjdGlvbiAxMCBpcyBjbGVhci4gSG93ZXZlciwg aWYgeW91IHRoaW5rIHdlIGNhbiBtYWtlIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbiwgcGxlYXNlIHN1 Z2dlc3QgdGhlIHRleHQuIFdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoZSBmdW5jdGlvbmFsaXR5IHRo YXQgd2Ugc3BlY2lmeSBpcyBjbGVhcmx5IGRlc2NyaWJlZCBhbmQgZXhwbGFpbmVkLiBXZSBkb24n dCBuZWVkIHRvIGRlc2NyaWJlL21lbnRpb24gdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyBub3Qg dXNlZC9uZWVkZWQuDQoNClRoYW5rcywNCkFsaQ0KDQpGcm9tOiBBbGRyaW4gSXNhYWMgPGFsZHJp bi5pc2FhY0BnbWFpbC5jb208bWFpbHRvOmFsZHJpbi5pc2FhY0BnbWFpbC5jb20+Pg0KRGF0ZTog VHVlc2RheSwgTWF5IDEzLCAyMDE0IDExOjE0IEFNDQpUbzogQ2lzY28gRW1wbG95ZWUgPHNhamFz c2lAY2lzY28uY29tPG1haWx0bzpzYWphc3NpQGNpc2NvLmNvbT4+DQpDYzogSm9obiBFIERyYWtl IDxqZHJha2VAanVuaXBlci5uZXQ8bWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldD4+LCBKYWtvYiBI ZWl0eiA8amFrb2IuaGVpdHpAZXJpY3Nzb24uY29tPG1haWx0bzpqYWtvYi5oZWl0ekBlcmljc3Nv bi5jb20+PiwgImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBp ZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+PiwgQW50b25pIFByenlnaWVuZGEgPGFudG9u aS5wcnp5Z2llbmRhQGVyaWNzc29uLmNvbTxtYWlsdG86YW50b25pLnByenlnaWVuZGFAZXJpY3Nz b24uY29tPj4NClN1YmplY3Q6IFJlOiBNQUMgcm91dGUgd2l0aCBJUA0KDQpXb3VsZCBpdCBiZSB3 b3J0aHdoaWxlIHRvIG1lbnRpb24gdGhhdCBNQUMvSVAgcm91dGVzIHNob3VsZCBubw0K --_000_4A95BA014132FF49AE685FAB4B9F17F645D09BE9dfweml701chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJM dWNpZGEgR3JhbmRlIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Jc27igJl0IGl0IHNhbWUg YXMg4oCcU3RpY2t5IE1BQ+KAnSBvciDigJxQZXJzaXN0ZW50IE1BQyBMZWFybmluZ+KAnT8NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TGluZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMMnZwbiBbbWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpha29iIEhlaXR6PGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDE0LCAyMDE0IDEyOjIwIFBNPGJyPg0KPGI+VG86PC9i PiBBbGRyaW4gSXNhYWM7IEFsaSBTYWphc3NpIChzYWphc3NpKTxicj4NCjxiPkNjOjwvYj4gbDJ2 cG5AaWV0Zi5vcmc7IEFudG9uaSBQcnp5Z2llbmRhPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBN QUMgcm91dGUgd2l0aCBJUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxk IGJlIG1vcmUgaW5jbGluZWQgdG8gcHV0IGEgY29tbWEgYWZ0ZXIgd2hlbjo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZxdW90O0luIHN1Y2ggc2NlbmFyaW9zLCZuYnNwO3doZW4gdGhlIEFS UCBlbnRyeSB0aW1lcyBvdXQgYW5kIGNhdXNlcyB0aGUgTUFDL0lQIHRvIGJlIHdpdGhkcmF3biwg dGhlbiB0aGUgTUFDIGluZm9ybWF0aW9uIHdpbGwgbm90IGJlIGxvc3QuJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkpha29iLjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBBbGRyaW4gSXNhYWMgWzxhIGhyZWY9Im1haWx0bzphbGRyaW4u aXNhYWNAZ21haWwuY29tIj5tYWlsdG86YWxkcmluLmlzYWFjQGdtYWlsLmNvbTwvYT5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMTQsIDIwMTQgOToxMiBBTTxicj4NCjxiPlRv OjwvYj4gQWxpIFNhamFzc2kgKHNhamFzc2kpPGJyPg0KPGI+Q2M6PC9iPiBKYWtvYiBIZWl0ejsg Sm9obiBFIERyYWtlOyA8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYu b3JnPC9hPjsgQW50b25pIFByenlnaWVuZGE8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE1BQyBy b3V0ZSB3aXRoIElQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdHcgc2hvdWxkICZx dW90O2luIHN1Y2ggc2NlbmVyYXJpb3Mgd2hlbiZxdW90OyBiZSAmcXVvdDtpbiBzdWNoIHNjZW5h cmlvcyB3aGVyZSZxdW90OyA/PGJyPg0KPGJyPg0KT24gV2VkbmVzZGF5LCBNYXkgMTQsIDIwMTQs IEFsaSBTYWphc3NpIChzYWphc3NpKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhamFzc2lAY2lzY28u Y29tIj5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+SGkgSmFrb2IsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNo YW5nZWQgeW91ciBzZW50ZW5jZSB0bzogJnF1b3Q7SW4gc3VjaCBzY2VuYXJpb3MmbmJzcDt3aGVu IHRoZSBBUlAgZW50cnkgdGltZXMgb3V0IGFuZCBjYXVzZXMgdGhlIE1BQy9JUCB0byBiZSB3aXRo ZHJhd24sIHRoZW4gdGhlIE1BQyBpbmZvcm1hdGlvbiB3aWxsIG5vdCBiZSBsb3N0LiZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIEdyYW5kZSZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIEdyYW5k ZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmFrb2IgSGVpdHogJmx0Ozxh IGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnamFrb2IuaGVpdHpAZXJpY3Nzb24u Y29tJyk7IiB0YXJnZXQ9Il9ibGFuayI+amFrb2IuaGVpdHpAZXJpY3Nzb24uY29tPC9hPiZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXkgMTQsIDIwMTQgMTI6MDkgQU08YnI+DQo8 Yj5UbzogPC9iPkNpc2NvIEVtcGxveWVlICZsdDs8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3 RCwnY3ZtbCcsJ3NhamFzc2lAY2lzY28uY29tJyk7IiB0YXJnZXQ9Il9ibGFuayI+c2FqYXNzaUBj aXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+QWxkcmluIElzYWFjICZsdDs8YSBocmVm PSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2FsZHJpbi5pc2FhY0BnbWFpbC5jb20nKTsi IHRhcmdldD0iX2JsYW5rIj5hbGRyaW4uaXNhYWNAZ21haWwuY29tPC9hPiZndDssIEpvaG4gRSBE cmFrZSAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdqZHJha2VAanVu aXBlci5uZXQnKTsiIHRhcmdldD0iX2JsYW5rIj5qZHJha2VAanVuaXBlci5uZXQ8L2E+Jmd0Oywg JnF1b3Q7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdsMnZwbkBpZXRmLm9y ZycpOyIgdGFyZ2V0PSJfYmxhbmsiPmwydnBuQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBo cmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2wydnBuQGlldGYub3JnJyk7IiB0YXJn ZXQ9Il9ibGFuayI+bDJ2cG5AaWV0Zi5vcmc8L2E+Jmd0OywgQW50b25pIFByenlnaWVuZGEgJmx0 OzxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnYW50b25pLnByenlnaWVuZGFA ZXJpY3Nzb24uY29tJyk7IiB0YXJnZXQ9Il9ibGFuayI+YW50b25pLnByenlnaWVuZGFAZXJpY3Nz b24uY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IE1BQyByb3V0ZSB3aXRoIElQ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+JnF1b3Q7 Tm90ZSB0aGF0IGEgTUFDLW9ubHkgcm91dGUgY2FuIGJlIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBi dXQgaW5kZXBlbmRlbnRseSBvZiBhIE1BQy9JUCByb3V0ZSBpbiBzY2VuYXJpb3Mgd2hlcmUgdGhl IE1BQyBsZWFybmluZyBvdmVyIHRoZSBhY2Nlc3MgbmV0d29yayBpcyBkb25lDQogaW4gdGhlIGRh dGEtcGxhbmUgYW5kIGluZGVwZW5kZW50bHkgb2YgQVJQIHNub29waW5nIHRoYXQgZ2VuZXJhdGVz IHRoZSBNQUMvSVAgcm91dGUuIFRoaXMgZW5zdXJlcyB0aGF0IGlmIHRoZSBBUlAgZW50cnkgdGlt ZXMgb3V0IGFuZCBjYXVzZXMgdGhlIE1BQy9JUCB0byBiZSB3aXRoZHJhd24sIHRoZW4gdGhlIE1B QyBpbmZvcm1hdGlvbiB3aWxsIG5vdCBiZSBsb3N0LiBJbiBzY2VuYXJpb3Mgd2hlcmUgdGhlIGhv c3QgTUFDL0lQIGlzIGxlYXJuZWQNCiB2aWEgdGhlIG1hbmFnZW1lbnQgb3IgY29udHJvbCBwbGFu ZXMsIHRoZSBzZW5kZXIgUEUgbWF5IGFkdmVydGlzZSBvbmx5IHRoZSBNQUMvSVAgcm91dGUuJnF1 b3Q7PGJyPg0KPGJyPg0KLS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SmFr b2IgSGVpdHouPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQpPbiBNYXkgMTMsIDIwMTQsIGF0IDExOjIy IFBNLCAmcXVvdDtBbGkgU2FqYXNzaSAoc2FqYXNzaSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpzYWphc3NpQGNpc2NvLmNvbSI+c2FqYXNzaUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgQWxkcmluLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Ib3cgYWJvdXQgdGhlIGZvbGxvd2luZzo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+JnF1b3Q7Tm90ZSB0aGF0IGEgTUFD LW9ubHkgcm91dGUgY2FuIGJlIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBidXQgaW5kZXBlbmRlbnQg ZnJvbSBNQUMvSVAgcm91dGUgZm9yIHNjZW5hcmlvcyB3aGVyZSB0aGUgTUFDIGxlYXJuaW5nIG92 ZXIgYWNjZXNzIG5ldHdvcmsvbm9kZSBpcyBkb25lDQogaW4gZGF0YS1wbGFuZSBhbmQgaW5kZXBl bmRlbnQgZnJvbSBBUlAgc25vb3BpbmcgdGhhdCBnZW5lcmF0ZXMgTUFDL0lQIHJvdXRlLiBJbiBz Y2VuYXJpb3Mgd2hlcmUgaG9zdCBNQUMvSVAgaXMgbGVhcm5lZCB2aWEgbWFuYWdlbWVudCBvciBj b250cm9sIHBsYW5lLCB0aGVuIHRoZSBzZW5kZXIgUEUgbWF5IG9ubHkgZ2VuZXJhdGVzIGFuZCBh ZHZlcnRpc2VzIE1BQy9JUCByb3V0ZS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+QWxpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBHcmFuZGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBHcmFuZGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkFsZHJpbiBJc2FhYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZHJpbi5pc2Fh Y0BnbWFpbC5jb20iPmFsZHJpbi5pc2FhY0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5UdWVzZGF5LCBNYXkgMTMsIDIwMTQgODowMiBQTTxicj4NCjxiPlRvOiA8L2I+Q2lzY28g RW1wbG95ZWUgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWphc3NpQGNpc2NvLmNvbSI+c2FqYXNzaUBj aXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Sm9obiBFIERyYWtlICZsdDs8YSBocmVm PSJtYWlsdG86amRyYWtlQGp1bmlwZXIubmV0Ij5qZHJha2VAanVuaXBlci5uZXQ8L2E+Jmd0Oywg SmFrb2IgSGVpdHogJmx0OzxhIGhyZWY9Im1haWx0bzpqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb20i Pmpha29iLmhlaXR6QGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT4mZ3Q7LA0KIEFudG9uaSBQcnp5 Z2llbmRhICZsdDs8YSBocmVmPSJtYWlsdG86YW50b25pLnByenlnaWVuZGFAZXJpY3Nzb24uY29t Ij5hbnRvbmkucHJ6eWdpZW5kYUBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5SZTogTUFDIHJvdXRlIHdpdGggSVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkhvdyBhYm91dDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+JnF1 b3Q7Tm90ZSB0aGF0IGEmbmJzcDtNQUMtb25seSByb3V0ZSBjYW4mbmJzcDtiZSBhZHZlcnRpc2Vk IGFsb25nJm5ic3A7d2l0aCZuYnNwO01BQy9JUCByb3V0ZXMmbmJzcDtmb3ImbmJzcDt1c2UgY2Fz ZXMgd2hlcmUmbmJzcDthbiBhY3RpdmUgTUFDIG11c3QmbmJzcDtyZW1haW4mbmJzcDtyZWFjaGFi bGUgd2hlbiZuYnNwO2FsbCBJUCdzIGJlY29tZSBkaXNhc3NvY2lhdGVkJm5ic3A7d2l0aA0KIHRo YXQgTUFDLiZxdW90Ozxicj4NCjxicj4NCk9uIFR1ZXNkYXksIE1heSAxMywgMjAxNCwgQWxpIFNh amFzc2kgKHNhamFzc2kpICZsdDs8YSBocmVmPSJtYWlsdG86c2FqYXNzaUBjaXNjby5jb20iPnNh amFzc2lAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkhpIEFsZHJpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SSBiZWxpZXZlIHRoZSBhcHBsaWNhdGlvbiBvZiBNQUMvSVAgcm91dGUgaW4gc2VjdGlv biAxMCBpcyBjbGVhci4gSG93ZXZlciwgaWYgeW91IHRoaW5rIHdlIGNhbiBtYWtlIGZ1cnRoZXIg Y2xhcmlmaWNhdGlvbiwgcGxlYXNlIHN1Z2dlc3QgdGhlIHRleHQuIFdlIG5lZWQgdG8NCiBtYWtl IHN1cmUgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCB3ZSBzcGVjaWZ5IGlzIGNsZWFybHkgZGVzY3Jp YmVkIGFuZCBleHBsYWluZWQuIFdlIGRvbid0IG5lZWQgdG8gZGVzY3JpYmUvbWVudGlvbiB0aGUg ZnVuY3Rpb25hbGl0eSB0aGF0IGlzIG5vdCB1c2VkL25lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+QWxpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBHcmFuZGUmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBHcmFuZGUmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkFsZHJpbiBJc2FhYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFs ZHJpbi5pc2FhY0BnbWFpbC5jb20iPmFsZHJpbi5pc2FhY0BnbWFpbC5jb208L2E+Jmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBNYXkgMTMsIDIwMTQgMTE6MTQgQU08YnI+DQo8Yj5Ubzog PC9iPkNpc2NvIEVtcGxveWVlICZsdDs8YSBocmVmPSJtYWlsdG86c2FqYXNzaUBjaXNjby5jb20i PnNhamFzc2lAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPkpvaG4gRSBEcmFrZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldCI+amRyYWtlQGp1bmlwZXIubmV0 PC9hPiZndDssIEpha29iIEhlaXR6ICZsdDs8YSBocmVmPSJtYWlsdG86amFrb2IuaGVpdHpAZXJp Y3Nzb24uY29tIj5qYWtvYi5oZWl0ekBlcmljc3Nvbi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+Jmd0OywNCiBB bnRvbmkgUHJ6eWdpZW5kYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFudG9uaS5wcnp5Z2llbmRhQGVy aWNzc29uLmNvbSI+YW50b25pLnByenlnaWVuZGFAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IE1BQyByb3V0ZSB3aXRoIElQPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Xb3VsZCBpdCBiZSB3b3J0aHdoaWxlIHRvIG1lbnRpb24m bmJzcDt0aGF0IE1BQy9JUCByb3V0ZXMgc2hvdWxkIG5vPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F645D09BE9dfweml701chmchi_-- From nobody Fri May 16 07:48:40 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0131A02A8; Fri, 16 May 2014 07:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcn10vlC9uwO; Fri, 16 May 2014 07:48:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2981A02DB; Fri, 16 May 2014 07:48:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-inter-domain-redundancy-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140516144831.7836.98319.idtracker@ietfa.amsl.com> Date: Fri, 16 May 2014 07:48:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/12QDX_f_Oev-yxMQ7HrAvMCb6n0 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 14:48:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Redundancy Mechanism for Inter-domain VPLS Service Authors : Zhihua Liu Lizhong Jin Ran Chen Dennis Cai Samer Salam Filename : draft-ietf-l2vpn-vpls-inter-domain-redundancy-07.txt Pages : 12 Date : 2014-05-16 Abstract: In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy only with a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redundancy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-vpls-inter-domain-redundancy-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 16 13:37:28 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F381A0317; Fri, 16 May 2014 13:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tFxWD_sg5zL; Fri, 16 May 2014 13:30:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 952B41A02CB; Fri, 16 May 2014 13:30:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: raggarwa_1@yahoo.com, sajassi@cisco.com, aisaac71@bloomberg.net, uttaro@att.com, nabil.n.bitar@verizon.com Subject: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-evpn-07 X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140516203017.7540.99566.idtracker@ietfa.amsl.com> Date: Fri, 16 May 2014 13:30:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/8d0CNf137j-sN7T4qK8P4ik855I X-Mailman-Approved-At: Fri, 16 May 2014 13:37:25 -0700 Cc: l2vpn@ietf.org, giheron@cisco.com, akatlas@gmail.com, ipr-announce@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:30:19 -0000 Dear Rahul Aggarwal, Ali Sajassi, Aldrin Isaac, Jim Uttaro, Dr. Nabil N. Bitar: An IPR disclosure that pertains to your Internet-Draft entitled "BGP MPLS Based Ethernet VPN" (draft-ietf-l2vpn-evpn) was submitted to the IETF Secretariat on 2014-05-16 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2362/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn- evpn-07.""); The IETF Secretariat From nobody Fri May 16 13:37:35 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EEF1A0317; Fri, 16 May 2014 13:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpIbpkzJ2dFC; Fri, 16 May 2014 13:30:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E78DD1A02EE; Fri, 16 May 2014 13:30:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: raggarwa_1@yahoo.com, sajassi@cisco.com, aisaac71@bloomberg.net, uttaro@att.com, nabil.n.bitar@verizon.com Subject: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-evpn-07 X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140516203017.12304.64162.idtracker@ietfa.amsl.com> Date: Fri, 16 May 2014 13:30:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/tU_7zfS75YjFmFQFDsVbFPkOyNA X-Mailman-Approved-At: Fri, 16 May 2014 13:37:25 -0700 Cc: l2vpn@ietf.org, giheron@cisco.com, akatlas@gmail.com, ipr-announce@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:30:30 -0000 Dear Rahul Aggarwal, Ali Sajassi, Aldrin Isaac, Jim Uttaro, Dr. Nabil N. Bitar: An IPR disclosure that pertains to your Internet-Draft entitled "BGP MPLS Based Ethernet VPN" (draft-ietf-l2vpn-evpn) was submitted to the IETF Secretariat on 2014-05-16 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2362/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn- evpn-07.""); The IETF Secretariat From nobody Mon May 19 02:34:07 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2D51A032D for ; Mon, 19 May 2014 02:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Trbx6LKNB7I5 for ; Mon, 19 May 2014 02:34:03 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043401A01A8 for ; Mon, 19 May 2014 02:34:03 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB529.eurprd03.prod.outlook.com (10.242.109.153) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 09:34:01 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0944.000; Mon, 19 May 2014 09:34:01 +0000 From: Alexander Vainshtein To: "tnadeau@lucidvision.com" , "kkoushik@cisco.com" , "rohit.mediratta@alcatel-lucent.com" Subject: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Topic: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Index: Ac9zRXZtGaEhhrgKQHa1aq4D/fY9OA== Date: Mon, 19 May 2014 09:34:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(53754006)(252514010)(199002)(189002)(51874003)(50986999)(19625215002)(99396002)(33646001)(101416001)(74316001)(74662001)(83322001)(19580395003)(19580405001)(15975445006)(31966008)(74502001)(19300405004)(15202345003)(21056001)(54356999)(77096999)(76482001)(2201001)(92566001)(83072002)(85852003)(46102001)(86362001)(87936001)(81342001)(76576001)(79102001)(4396001)(81542001)(77982001)(64706001)(2656002)(16236675002)(66066001)(20776003)(80022001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB529; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; Content-Type: multipart/alternative; boundary="_000_b8fe93b3b39d4bb78dd64bbac8aec4cbAM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/mB405k7DjRoyuq_F0CYtgJBgcNw Cc: "l2vpn@ietf.org" , Rotem Cohen X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 09:34:06 -0000 --_000_b8fe93b3b39d4bb78dd64bbac8aec4cbAM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've looked up the current version of draft-ietf-l2vpn-vpls-mib and I di= d not find there any explicit reference to (local) attachment circuits of V= PLS. (Neither the term "attachment circuit" nor its common abbreviation "AC= " appear in the text.) At the same time, to the best of my understanding, attachment circuits form= a substantial component of any VPLS instance. Did I miss something? If yes, could somebody please explain how one could indicate that, say, a s= pecific VLAN on a specific Ethernet port belongs to a given VPLS instance a= s defined in the draft? If not, could somebody please explain why presenting such functionality is = considered unnecessary in the VPLS MIB? Regards, lots of thanks in advance, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 --_000_b8fe93b3b39d4bb78dd64bbac8aec4cbAM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I’ve looked up the current version of draft-ietf-l2vpn-vpls-mib and I did not find there any explicit referen= ce to (local) attachment circuits of VPLS. (Neither the term “attachm= ent circuit” nor its common abbreviation “AC” appear in t= he text.)

 

At the same time, to the best of my understanding, a= ttachment circuits form a substantial component of any VPLS instance.<= /o:p>

 

Did I miss something?

 

If yes, could somebody please explain how one could = indicate that, say, a specific VLAN on a specific Ethernet port belongs to = a given VPLS instance as defined in the draft?

 

If not, could somebody please explain why presenting= such functionality is considered unnecessary in the VPLS MIB?

 

Regards, lots of thanks in advance,

       Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

--_000_b8fe93b3b39d4bb78dd64bbac8aec4cbAM3PR03MB612eurprd03pro_-- From nobody Mon May 19 06:04:45 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6721A036A for ; Mon, 19 May 2014 06:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq9FRNpPFpvq for ; Mon, 19 May 2014 06:04:40 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D4D1A036C for ; Mon, 19 May 2014 06:04:32 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB531.eurprd03.prod.outlook.com (10.242.109.155) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 13:04:30 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0944.000; Mon, 19 May 2014 13:04:30 +0000 From: Alexander Vainshtein To: "tnadeau@lucidvision.com" , "kkoushik@cisco.com" , "rohit.mediratta@alcatel-lucent.com" Subject: RE: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Topic: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Index: Ac9zRXZtGaEhhrgKQHa1aq4D/fY9OAAHKXlA Date: Mon, 19 May 2014 13:04:30 +0000 Message-ID: <474c07eb20a84773a9d51a6281af5fa2@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(51694002)(377454003)(252514010)(189002)(53754006)(199002)(99396002)(74662001)(77982001)(19580395003)(33646001)(74316001)(83322001)(31966008)(76576001)(4396001)(83072002)(81542001)(81342001)(46102001)(87936001)(16236675002)(85852003)(19580405001)(76482001)(74502001)(19300405004)(50986999)(54356999)(77096999)(2656002)(92566001)(86362001)(64706001)(80022001)(2201001)(15975445006)(66066001)(21056001)(19609705001)(15202345003)(79102001)(20776003)(101416001)(19625215002)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB531; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; Content-Type: multipart/alternative; boundary="_000_474c07eb20a84773a9d51a6281af5fa2AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/s3W57UkN7WWeChJ6D77UKRepFno Cc: "'l2vpn@ietf.org'" , Rotem Cohen X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 13:04:44 -0000 --_000_474c07eb20a84773a9d51a6281af5fa2AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Just wanted to add that in the case of L3 VPNs the corresponding MIB (RFC 4= 382) addresses = the similar question in an unambiguous manner by introducing the mplsL3VpnI= fConfTable. It would be interesting to know why the same approach has not been taken wi= th VPLS ACs. My 2c, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: Alexander Vainshtein Sent: Monday, May 19, 2014 12:34 PM To: 'tnadeau@lucidvision.com'; 'kkoushik@cisco.com'; 'rohit.mediratta@alcat= el-lucent.com' Cc: l2vpn@ietf.org; Gideon Agmon; Rotem Cohen (Rotem.Cohen@ecitele.com) Subject: Representation of VPLS attachment circuits in the VPLS MIB draft Hi all, I've looked up the current version of draft-ietf-l2vpn-vpls-mib and I di= d not find there any explicit reference to (local) attachment circuits of V= PLS. (Neither the term "attachment circuit" nor its common abbreviation "AC= " appear in the text.) At the same time, to the best of my understanding, attachment circuits form= a substantial component of any VPLS instance. Did I miss something? If yes, could somebody please explain how one could indicate that, say, a s= pecific VLAN on a specific Ethernet port belongs to a given VPLS instance a= s defined in the draft? If not, could somebody please explain why presenting such functionality is = considered unnecessary in the VPLS MIB? Regards, lots of thanks in advance, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 --_000_474c07eb20a84773a9d51a6281af5fa2AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Just wanted=
 to add that in the case of L3 VPNs the corresponding MIB (RFC 4382) addres=
ses the similar question in an unambiguous manner by introducing the mplsL3VpnIfConfTable.
 

It would be interestin= g to know why the same approach has not been taken with VPLS ACs.

My 2c,

   &nbs= p;   Sasha

Email: Alexander.Vains= htein@ecitele.com

Mobile: 054-9266302

 

From: Alexande= r Vainshtein
Sent: Monday, May 19, 2014 12:34 PM
To: 'tnadeau@lucidvision.com'; 'kkoushik@cisco.com'; 'rohit.mediratt= a@alcatel-lucent.com'
Cc: l2vpn@ietf.org; Gideon Agmon; Rotem Cohen (Rotem.Cohen@ecitele.c= om)
Subject: Representation of VPLS attachment circuits in the VPLS MIB = draft

 

Hi all,

I’ve looked up the current version of draft-ietf-l2vpn-vpls-mib and I did not find there any explicit referen= ce to (local) attachment circuits of VPLS. (Neither the term “attachm= ent circuit” nor its common abbreviation “AC” appear in t= he text.)

 

At the same time, to the best of my understanding, a= ttachment circuits form a substantial component of any VPLS instance.<= /o:p>

 

Did I miss something?

 

If yes, could somebody please explain how one could = indicate that, say, a specific VLAN on a specific Ethernet port belongs to = a given VPLS instance as defined in the draft?

 

If not, could somebody please explain why presenting= such functionality is considered unnecessary in the VPLS MIB?

 

Regards, lots of thanks in advance,

       Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

--_000_474c07eb20a84773a9d51a6281af5fa2AM3PR03MB612eurprd03pro_-- From nobody Mon May 19 06:09:34 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ADE1A037A for ; Mon, 19 May 2014 06:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMVWSiZ2BZag for ; Mon, 19 May 2014 06:09:29 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097F71A037F for ; Mon, 19 May 2014 06:09:29 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 13:09:26 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0944.000; Mon, 19 May 2014 13:09:26 +0000 From: Alexander Vainshtein To: "tnadeau@lucidvision.com" , "kkoushik@cisco.com" , "rohit.mediratta@alcatel-lucent.com" Subject: RE: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Topic: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Index: Ac9zRXZtGaEhhrgKQHa1aq4D/fY9OAAHKXlAAABWa+A= Date: Mon, 19 May 2014 13:09:25 +0000 Message-ID: References: <474c07eb20a84773a9d51a6281af5fa2@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <474c07eb20a84773a9d51a6281af5fa2@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(252514010)(51694002)(377454003)(53754006)(189002)(199002)(74502001)(16236675002)(74662001)(19580395003)(19609705001)(76482001)(86362001)(15975445006)(83322001)(19580405001)(19300405004)(21056001)(101416001)(4396001)(31966008)(92566001)(76576001)(81342001)(74316001)(99396002)(81542001)(87936001)(64706001)(20776003)(66066001)(2656002)(83072002)(80022001)(77096999)(46102001)(19625215002)(54356999)(50986999)(76176999)(85852003)(15202345003)(77982001)(33646001)(2201001)(79102001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB612; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; Content-Type: multipart/alternative; boundary="_000_e402f6af93a14d409c1054587b771d3fAM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/d9no5eB77m8IoV91NbcBAarLNrg Cc: "'l2vpn@ietf.org'" , Rotem Cohen X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 13:09:33 -0000 --_000_e402f6af93a14d409c1054587b771d3fAM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending - received some "undeliverable" messages... Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshte= in Sent: Monday, May 19, 2014 4:05 PM To: tnadeau@lucidvision.com; kkoushik@cisco.com; rohit.mediratta@alcatel-lu= cent.com Cc: 'l2vpn@ietf.org'; Rotem Cohen Subject: RE: Representation of VPLS attachment circuits in the VPLS MIB dra= ft Hi all, Just wanted to add that in the case of L3 VPNs the corresponding MIB (RFC 4= 382) addresses = the similar question in an unambiguous manner by introducing the mplsL3VpnI= fConfTable. It would be interesting to know why the same approach has not been taken wi= th VPLS ACs. My 2c, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: Alexander Vainshtein Sent: Monday, May 19, 2014 12:34 PM To: 'tnadeau@lucidvision.com'; 'kkoushik@cisco.com'; 'rohit.mediratta@alcat= el-lucent.com' Cc: l2vpn@ietf.org; Gideon Agmon; Rotem Cohen (Rotem= .Cohen@ecitele.com) Subject: Representation of VPLS attachment circuits in the VPLS MIB draft Hi all, I've looked up the current version of draft-ietf-l2vpn-vpls-mib and I di= d not find there any explicit reference to (local) attachment circuits of V= PLS. (Neither the term "attachment circuit" nor its common abbreviation "AC= " appear in the text.) At the same time, to the best of my understanding, attachment circuits form= a substantial component of any VPLS instance. Did I miss something? If yes, could somebody please explain how one could indicate that, say, a s= pecific VLAN on a specific Ethernet port belongs to a given VPLS instance a= s defined in the draft? If not, could somebody please explain why presenting such functionality is = considered unnecessary in the VPLS MIB? Regards, lots of thanks in advance, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 --_000_e402f6af93a14d409c1054587b771d3fAM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending – rece= ived some “undeliverable” messages…

 

Regards,

   &nbs= p;   Sasha

Email: Alexander.Vains= htein@ecitele.com

Mobile: 054-9266302

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Monday, May 19, 2014 4:05 PM
To: tnadeau@lucidvision.com; kkoushik@cisco.com; rohit.mediratta@alc= atel-lucent.com
Cc: 'l2vpn@ietf.org'; Rotem Cohen
Subject: RE: Representation of VPLS attachment circuits in the VPLS = MIB draft

 

Hi all,

Just wanted=
 to add that in the case of L3 VPNs the corresponding MIB (RFC 4382) addres=
ses the similar question in an unambiguous manner by introducing the mplsL3VpnIfConfTable.
 

It would be interestin= g to know why the same approach has not been taken with VPLS ACs.

My 2c,

   &nbs= p;   Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

From: Alexande= r Vainshtein
Sent: Monday, May 19, 2014 12:34 PM
To: 'tnadeau@lucidvision.com'; 'kkoushik@cisco.com'; 'rohit.mediratt= a@alcatel-lucent.com'
Cc: l2vpn@ietf.org; Gideon Agm= on; Rotem Cohen (Rotem.Cohen@eci= tele.com)
Subject: Representation of VPLS attachment circuits in the VPLS MIB = draft

 

Hi all,

I’ve looked up the current version of draft-ietf-l2vpn-vpls-mib and I did not find there any explicit referen= ce to (local) attachment circuits of VPLS. (Neither the term “attachm= ent circuit” nor its common abbreviation “AC” appear in t= he text.)

 

At the same time, to the best of my understanding, a= ttachment circuits form a substantial component of any VPLS instance.<= /o:p>

 

Did I miss something?

 

If yes, could somebody please explain how one could = indicate that, say, a specific VLAN on a specific Ethernet port belongs to = a given VPLS instance as defined in the draft?

 

If not, could somebody please explain why presenting= such functionality is considered unnecessary in the VPLS MIB?

 

Regards, lots of thanks in advance,

       Sasha

Email: Alexander.Vainshtein@ecitele.com

Mobile: 054-9266302

 

--_000_e402f6af93a14d409c1054587b771d3fAM3PR03MB612eurprd03pro_-- From nobody Mon May 19 07:11:15 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452201A038D for ; Mon, 19 May 2014 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oILjSmy1uzvP for ; Mon, 19 May 2014 07:11:06 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id AA1531A005C for ; Mon, 19 May 2014 07:11:05 -0700 (PDT) Received: from [172.30.1.206] (c-98-247-226-85.hsd1.wa.comcast.net [98.247.226.85]) by lucidvision.com (Postfix) with ESMTP id 5C92127B17B0; Mon, 19 May 2014 10:11:03 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C9A50079-FE83-4150-9145-FB9D4457A7AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Representation of VPLS attachment circuits in the VPLS MIB draft From: Thomas Nadeau In-Reply-To: Date: Mon, 19 May 2014 10:11:13 -0400 Message-Id: <4F06F912-87F9-4D78-B685-000FA9FD6C0D@lucidvision.com> References: To: Alexander Vainshtein X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/771j3MEoUIb5LsLPuPJwls3ptAk Cc: "l2vpn@ietf.org" , "kkoushik@cisco.com" , "rohit.mediratta@alcatel-lucent.com" , Rotem Cohen X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 14:11:13 -0000 --Apple-Mail=_C9A50079-FE83-4150-9145-FB9D4457A7AF Content-Type: multipart/alternative; boundary="Apple-Mail=_C684E64C-4450-42BA-B92F-8571997C124E" --Apple-Mail=_C684E64C-4450-42BA-B92F-8571997C124E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =09 ACs are attached to the VPLS instances and are represented as = IfMIB entries.=20 --Tom On May 19, 2014:5:34 AM, at 5:34 AM, Alexander Vainshtein = wrote: > Hi all, > I=92ve looked up the current version of draft-ietf-l2vpn-vpls-mib and = I did not find there any explicit reference to (local) attachment = circuits of VPLS. (Neither the term =93attachment circuit=94 nor its = common abbreviation =93AC=94 appear in the text.) > =20 > At the same time, to the best of my understanding, attachment circuits = form a substantial component of any VPLS instance. > =20 > Did I miss something? > =20 > If yes, could somebody please explain how one could indicate that, = say, a specific VLAN on a specific Ethernet port belongs to a given VPLS = instance as defined in the draft? > =20 > If not, could somebody please explain why presenting such = functionality is considered unnecessary in the VPLS MIB? > =20 > Regards, lots of thanks in advance, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 --Apple-Mail=_C684E64C-4450-42BA-B92F-8571997C124E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 =
= ACs are attached to the VPLS instances and are represented as = IfMIB entries. 

= --Tom


On May 19, 2014:5:34 AM, = at 5:34 AM, Alexander Vainshtein <Alexander.Vainshtein@ecit= ele.com> wrote:

Hi = all,
I=92ve looked up the current = version of draft-ietf-l2vpn-vpls-mib and I did not find there = any explicit reference to (local) attachment circuits of VPLS. (Neither = the term =93attachment circuit=94 nor its common abbreviation =93AC=94 = appear in the text.)
 
At the = same time, to the best of my understanding, attachment circuits form a = substantial component of any VPLS instance.
 
Did I = miss something?
 
If yes, = could somebody please explain how one could indicate that, say, a = specific VLAN on a specific Ethernet port belongs to a given VPLS = instance as defined in the draft?
 
If not, = could somebody please explain why presenting such functionality is = considered unnecessary in the VPLS MIB?
 
Regards, = lots of thanks in advance,
       = Sasha
Mobile: = 054-9266302

= --Apple-Mail=_C684E64C-4450-42BA-B92F-8571997C124E-- --Apple-Mail=_C9A50079-FE83-4150-9145-FB9D4457A7AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTehEBAAoJEPcO+I7eiUJZ9Q4QAK3l2XcoYJnJJzDejehrhtux 1krqr94nz6DoeJI/hZ5DYNVTim9IogQ5ljOVFR0HjRXcDR48khC+Ica/mv3ALDki cs0O+2u85OLqIHsCusMZx9tEEt6wtE15G+AxRBM6yWZuTFnjQfWbM/IVYnvmzSw/ G/y3VnAznjWOfE4yfXm+nZpV2bHByboRG12/t3G5qU8NAFnD8C8NnhzehzOfkZLQ 00n1BNkjiqK7XA5EIhcVQqtLurBdWeW+vGmWF9+bbvGYb6BvmkwsdywT7Bjokiwu jcgFvtzN9aQeVfBWqkCLPIZvfill8D848PNw8mIkw+5yyHdfj4vU9KvLPEMtOWSK WeMc8pBVek8D+joI5vOz8XW/09MQy470+PO9OiEGfpddHcNkIiKBstAPxUxGncjM vVXGWYG4n0l1pwfvq4HBxcCO00ZZzMnQ6aiKuamrxRatpiRR3P69ZXT0omAsPRUu eWyFCUsme+ewj15huMe41PbWxBkeMljIxTGUHSTiDIKOOIMr/yeQAIZ5fRmRjh/z JmRQEvj279D1KHg47vG4A627231e71sIvRX/IXsf8W291uKV0JZvx6smNbphswUA 4uCYe6dTA3ap7BJivmzxhykpqb35o1iY0m01LPKlYXrC8BKHdA0i0TBKr3pLMOmM HMTszN6SJ8r+R1VB15eq =kDEm -----END PGP SIGNATURE----- --Apple-Mail=_C9A50079-FE83-4150-9145-FB9D4457A7AF-- From nobody Mon May 19 07:40:20 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6A1A00E9 for ; Mon, 19 May 2014 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgA9dGF-BWWc for ; Mon, 19 May 2014 07:40:14 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A983B1A00E5 for ; Mon, 19 May 2014 07:40:13 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 14:40:11 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0944.000; Mon, 19 May 2014 14:40:11 +0000 From: Alexander Vainshtein To: Thomas Nadeau Subject: RE: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Topic: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Index: Ac9zRXZtGaEhhrgKQHa1aq4D/fY9OAAJrpqAAADWPaA= Date: Mon, 19 May 2014 14:40:11 +0000 Message-ID: <38f3dbce088c436c92cb0449b67d4541@AM3PR03MB612.eurprd03.prod.outlook.com> References: <4F06F912-87F9-4D78-B685-000FA9FD6C0D@lucidvision.com> In-Reply-To: <4F06F912-87F9-4D78-B685-000FA9FD6C0D@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(189002)(199002)(24454002)(377454003)(53754006)(252514010)(80022001)(86362001)(66066001)(20776003)(79102001)(83072002)(74316001)(15975445006)(85852003)(87936001)(16236675002)(2656002)(64706001)(33646001)(81542001)(4396001)(15202345003)(101416001)(99396002)(76576001)(83322001)(19580405001)(19580395003)(19300405004)(46102001)(74502001)(81342001)(21056001)(19609705001)(50986999)(76482001)(31966008)(77982001)(77096999)(54356999)(19625215002)(92566001)(76176999)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB532; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; Content-Type: multipart/alternative; boundary="_000_38f3dbce088c436c92cb0449b67d4541AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/G0s-wjemHoAW6jcdGzLWXMwfSPI Cc: "l2vpn@ietf.org" , "kkoushik@cisco.com" , "rohit.mediratta@alcatel-lucent.com" , Rotem Cohen X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 14:40:18 -0000 --_000_38f3dbce088c436c92cb0449b67d4541AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, Lots of thanks for a prompt response. Unfortunately ACs as IfMIB entries are not mentioned anywhere in the draft. I would expect something similar to the PW Binding table for binding ACs to= a VPLS instance, but there is no such thing there. And while the draft mentions that it uses the definitions for RFC 2863 in t= he text, the actual IMPORT clauses do not list this RFC at all! Could you please elaborate? Regards, and lots of thanks in advance, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Monday, May 19, 2014 5:11 PM To: Alexander Vainshtein Cc: kkoushik@cisco.com; rohit.mediratta@alcatel-lucent.com; l2vpn@ietf.org;= Gideon Agmon; Rotem Cohen Subject: Re: Representation of VPLS attachment circuits in the VPLS MIB dra= ft ACs are attached to the VPLS instances and are represented as IfM= IB entries. --Tom On May 19, 2014:5:34 AM, at 5:34 AM, Alexander Vainshtein > wrote: Hi all, I've looked up the current version of draft-ietf-l2vpn-vpls-mib and I di= d not find there any explicit reference to (local) attachment circuits of V= PLS. (Neither the term "attachment circuit" nor its common abbreviation "AC= " appear in the text.) At the same time, to the best of my understanding, attachment circuits form= a substantial component of any VPLS instance. Did I miss something? If yes, could somebody please explain how one could indicate that, say, a s= pecific VLAN on a specific Ethernet port belongs to a given VPLS instance a= s defined in the draft? If not, could somebody please explain why presenting such functionality is = considered unnecessary in the VPLS MIB? Regards, lots of thanks in advance, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 --_000_38f3dbce088c436c92cb0449b67d4541AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tom,

Lots of thanks for a prom= pt response.

 <= /p>

Unfortunately ACs as IfMI= B entries are not mentioned anywhere in the draft.

I would expect something = similar to the PW Binding table for binding ACs to a VPLS instance, but the= re is no such thing there.

 <= /p>

And while the draft menti= ons that it uses the definitions for RFC 2863 in the text, the actual  = ;IMPORT clauses do not list this RFC at all!

 <= /p>

 <= /p>

Could you please elaborat= e?

 <= /p>

Regards, and lots of than= ks in advance,

    &= nbsp;  Sasha

Email: Alexander.Vainshte= in@ecitele.com

Mobile: 054-9266302<= /o:p>

 <= /p>

From: Thomas N= adeau [mailto:tnadeau@lucidvision.com]
Sent: Monday, May 19, 2014 5:11 PM
To: Alexander Vainshtein
Cc: kkoushik@cisco.com; rohit.mediratta@alcatel-lucent.com; l2vpn@ie= tf.org; Gideon Agmon; Rotem Cohen
Subject: Re: Representation of VPLS attachment circuits in the VPLS = MIB draft

 

   &nb= sp;     

   &nb= sp;      ACs are attached to the VPLS insta= nces and are represented as IfMIB entries. 

 

   &nb= sp;      --Tom

 

 

On May 19, 2014:5:34 AM, at 5:34 AM, Alexander Vains= htein <Alexander.Vai= nshtein@ecitele.com> wrote:



Hi all,

I’ve looked up the current versio= n of draft-ietf-l2vpn-vpls-mib and I did not find there any explicit reference to (local) attachment circuits= of VPLS. (Neither the term “attachment circuit” nor its common= abbreviation “AC” appear in the text.)

 

At the same time, to the best of my und= erstanding, attachment circuits form a substantial component of any VPLS in= stance.

 

Did I miss something?=

 

If yes, could somebody please explain h= ow one could indicate that, say, a specific VLAN on a specific Ethernet por= t belongs to a given VPLS instance as defined in the draft?

 

If not, could somebody please explain w= hy presenting such functionality is considered unnecessary in the VPLS MIB?=

 <= /o:p>

Regards, lots of thanks in advance,

       Sa= sha

Mobile: 054-9266302

 

--_000_38f3dbce088c436c92cb0449b67d4541AM3PR03MB612eurprd03pro_-- From nobody Mon May 19 08:43:46 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBE01A018F; Mon, 19 May 2014 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ejr01fMf5fz; Mon, 19 May 2014 08:22:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A891A0169; Mon, 19 May 2014 08:22:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: raggarwa_1@yahoo.com, sajassi@cisco.com, aisaac71@bloomberg.net, uttaro@att.com, nabil.n.bitar@verizon.com Subject: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-evpn-07 (2) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140519152244.15299.42075.idtracker@ietfa.amsl.com> Date: Mon, 19 May 2014 08:22:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/UFHgh45jkb767waeVCt4A7HFUdQ X-Mailman-Approved-At: Mon, 19 May 2014 08:43:45 -0700 Cc: l2vpn@ietf.org, giheron@cisco.com, akatlas@gmail.com, ipr-announce@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 15:22:46 -0000 Dear Rahul Aggarwal, Ali Sajassi, Aldrin Isaac, Jim Uttaro, Dr. Nabil N. Bitar: An IPR disclosure that pertains to your Internet-Draft entitled "BGP MPLS Based Ethernet VPN" (draft-ietf-l2vpn-evpn) was submitted to the IETF Secretariat on 2014-05-17 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2363/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn- evpn-07 (2).""); The IETF Secretariat From nobody Mon May 19 14:02:50 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE331A02AA; Mon, 19 May 2014 14:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Mx_brlTXN7U; Mon, 19 May 2014 14:02:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A440E1A041B; Mon, 19 May 2014 14:02:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Redundancy Mechanism for Inter-domain VPLS Service' to Proposed Standard (draft-ietf-l2vpn-vpls-inter-domain-redundancy-07.txt) X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140519210229.15203.65073.idtracker@ietfa.amsl.com> Date: Mon, 19 May 2014 14:02:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/zxh4aX0-splOB4sfHV9WxtZijvU Cc: l2vpn mailing list , l2vpn chair , RFC Editor X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 21:02:38 -0000 The IESG has approved the following document: - 'Redundancy Mechanism for Inter-domain VPLS Service' (draft-ietf-l2vpn-vpls-inter-domain-redundancy-07.txt) as Proposed Standard This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redundancy/ Technical Summary: In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy only with a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains. Working Group Summary: This document is an L2VPN Working Group document, and has been discussed in the working group through multiple iterations of the draft and its predecessor draft (draft-liu-l2vpn-vpls-inter-domain-redundancy). It has been essentially stable since WG adoption in May 2013. Prior to WG adoption the protocol operations in the predecessor draft were removed, leaving the draft as a simple BCP on options for configuring redundancy for inter-domain VPLS services. Document Quality: The document is short (11 pages in total) and to the point. Personnel: Document Shepherd: Giles Heron (giheron@cisco.com) Area Director: Adrian Farrel (Adrian@olddog.co.uk) From nobody Tue May 20 08:46:43 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6841A06FA for ; Tue, 20 May 2014 08:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giEVpg6dqI38 for ; Tue, 20 May 2014 08:46:36 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA4F1A076C for ; Tue, 20 May 2014 08:46:34 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB530.eurprd03.prod.outlook.com (10.242.109.154) with Microsoft SMTP Server (TLS) id 15.0.944.11; Tue, 20 May 2014 15:46:32 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0944.000; Tue, 20 May 2014 15:46:31 +0000 From: Alexander Vainshtein To: Thomas Nadeau , "Giles Heron (giles.heron@gmail.com)" Subject: RE: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Topic: Representation of VPLS attachment circuits in the VPLS MIB draft Thread-Index: Ac9zRXZtGaEhhrgKQHa1aq4D/fY9OAAJrpqAAADWPaAANDPUAA== Date: Tue, 20 May 2014 15:46:30 +0000 Message-ID: <625bd69ef3be4c8f9c61292c760b28fb@AM3PR03MB612.eurprd03.prod.outlook.com> References: <4F06F912-87F9-4D78-B685-000FA9FD6C0D@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(199002)(189002)(377454003)(24454002)(252514010)(53754006)(77096999)(79102001)(76176999)(76482001)(80022001)(74316001)(54356999)(83072002)(33646001)(15202345003)(81342001)(21056001)(20776003)(19300405004)(19625215002)(85852003)(4396001)(64706001)(19580395003)(31966008)(74502001)(50986999)(86362001)(74662001)(66066001)(46102001)(16236675002)(99396002)(76576001)(19580405001)(2656002)(83322001)(92566001)(15975445006)(19609705001)(77982001)(87936001)(81542001)(101416001)(24736002)(217873001)(562404015); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB530; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; Content-Type: multipart/alternative; boundary="_000_625bd69ef3be4c8f9c61292c760b28fbAM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/5oumP1r1VnP7JB4skiwKo4jlSYo Cc: "l2vpn@ietf.org" , "kkoushik@cisco.com" , "rohit.mediratta@alcatel-lucent.com" , Rotem Cohen X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 15:46:40 -0000 --_000_625bd69ef3be4c8f9c61292c760b28fbAM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This is a gentle reminder that I still have not seen any answers to my ques= tion - or, to be more specific, an answer that refers to specific objects d= efined in the VPLS MIB draft. I am adding Giles (who was the shepherd of this document) and Nabil to this= thread. For the reference, the L3VPN MIB (RFC 4382) defines a dedicated table (mplsL3VpnIfConfTable) that performs = this functionality. I would expect something similar in this draft, but could not find it in th= ere. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: Alexander Vainshtein Sent: Monday, May 19, 2014 5:40 PM To: 'Thomas Nadeau' Cc: kkoushik@cisco.com; rohit.mediratta@alcatel-lucent.com; l2vpn@ietf.org;= Gideon Agmon; Rotem Cohen Subject: RE: Representation of VPLS attachment circuits in the VPLS MIB dra= ft Tom, Lots of thanks for a prompt response. Unfortunately ACs as IfMIB entries are not mentioned anywhere in the draft. I would expect something similar to the PW Binding table for binding ACs to= a VPLS instance, but there is no such thing there. And while the draft mentions that it uses the definitions for RFC 2863 in t= he text, the actual IMPORT clauses do not list this RFC at all! Could you please elaborate? Regards, and lots of thanks in advance, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Monday, May 19, 2014 5:11 PM To: Alexander Vainshtein Cc: kkoushik@cisco.com; rohit.mediratta@alcatel-= lucent.com; l2vpn@ietf.org; Gideon Agmon; Rotem Cohen Subject: Re: Representation of VPLS attachment circuits in the VPLS MIB dra= ft ACs are attached to the VPLS instances and are represented as IfM= IB entries. --Tom On May 19, 2014:5:34 AM, at 5:34 AM, Alexander Vainshtein > wrote: Hi all, I've looked up the current version of draft-ietf-l2vpn-vpls-mib and I di= d not find there any explicit reference to (local) attachment circuits of V= PLS. (Neither the term "attachment circuit" nor its common abbreviation "AC= " appear in the text.) At the same time, to the best of my understanding, attachment circuits form= a substantial component of any VPLS instance. Did I miss something? If yes, could somebody please explain how one could indicate that, say, a s= pecific VLAN on a specific Ethernet port belongs to a given VPLS instance a= s defined in the draft? If not, could somebody please explain why presenting such functionality is = considered unnecessary in the VPLS MIB? Regards, lots of thanks in advance, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 --_000_625bd69ef3be4c8f9c61292c760b28fbAM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

This is a gentle reminder= that I still have not seen any answers to my question – or, to be mo= re specific, an answer that refers to specific objects defined in the VPLS MIB draft.

I am adding Giles (who wa= s the shepherd of this document) and Nabil to this thread.

 <= /p> 

For the reference, the L3VPN MIB (RFC 4382) defines a dedi=
cated table (mplsL3VpnIfConfTable=
) that performs this functionality. <=
/span>
I would expect something similar in this dr=
aft, but could not find it in there.

 <= /p>

Regards,

    &= nbsp;  Sasha

Email: Alexander.Vainshte= in@ecitele.com

Mobile: 054-9266302<= /o:p>

 <= /p>

From: Alexande= r Vainshtein
Sent: Monday, May 19, 2014 5:40 PM
To: 'Thomas Nadeau'
Cc: kkoushik@cisco.com; rohit.mediratta@alcatel-lucent.com; l2vpn@ie= tf.org; Gideon Agmon; Rotem Cohen
Subject: RE: Representation of VPLS attachment circuits in the VPLS = MIB draft

 

Tom,

Lots of thanks for a prom= pt response.

 <= /p>

Unfortunately ACs as IfMI= B entries are not mentioned anywhere in the draft.

I would expect something = similar to the PW Binding table for binding ACs to a VPLS instance, but the= re is no such thing there.

 <= /p>

And while the draft menti= ons that it uses the definitions for RFC 2863 in the text, the actual  = ;IMPORT clauses do not list this RFC at all!

 <= /p>

 <= /p>

Could you please elaborat= e?

 <= /p>

Regards, and lots of than= ks in advance,

    &= nbsp;  Sasha

Email: Alexander.Vainshtein@ec= itele.com

Mobile: 054-9266302<= /o:p>

 <= /p>

From: Thomas N= adeau [mailto:tnadeau@lucidvisio= n.com]
Sent: Monday, May 19, 2014 5:11 PM
To: Alexander Vainshtein
Cc: kkoushik@cisco.com; rohit.mediratta@alcatel-lucent.com; l= 2vpn@ietf.org; Gideon Agmon; Rotem Cohen
Subject: Re: Representation of VPLS attachment circuits in the VPLS = MIB draft

 

   &nb= sp;     

   &nb= sp;      ACs are attached to the VPLS insta= nces and are represented as IfMIB entries. 

 

   &nb= sp;      --Tom

 

 

On May 19, 2014:5:34 AM, at 5:34 AM, Alexander Vains= htein <Alexander.Vai= nshtein@ecitele.com> wrote:

 

Hi all,

I’ve looked up the current versio= n of draft-ietf-l2vpn-vpls-mib and I did not find there any explicit reference to (local) attachment circuits= of VPLS. (Neither the term “attachment circuit” nor its common= abbreviation “AC” appear in the text.)

 

At the same time, to the best of my und= erstanding, attachment circuits form a substantial component of any VPLS in= stance.

 

Did I miss something?=

 

If yes, could somebody please explain h= ow one could indicate that, say, a specific VLAN on a specific Ethernet por= t belongs to a given VPLS instance as defined in the draft?

 

If not, could somebody please explain w= hy presenting such functionality is considered unnecessary in the VPLS MIB?=

 <= /o:p>

Regards, lots of thanks in advance,

       Sa= sha

Mobile: 054-9266302

 

--_000_625bd69ef3be4c8f9c61292c760b28fbAM3PR03MB612eurprd03pro_-- From nobody Wed May 21 08:57:58 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375E41A03DD; Wed, 21 May 2014 08:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5utE5V1rzTv; Wed, 21 May 2014 08:57:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A74F1A0741; Wed, 21 May 2014 08:57:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-etree-frwk-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140521155748.5561.89737.idtracker@ietfa.amsl.com> Date: Wed, 21 May 2014 08:57:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/q6TeD0duBE5N4FB1YGGzhvd5ubY Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:57:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network Authors : Raymond Key Lucy Yong Simon Delord Frederic Jounay Lizhong Jin Filename : draft-ietf-l2vpn-etree-frwk-05.txt Pages : 13 Date : 2014-05-21 Abstract: This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-etree-frwk/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-etree-frwk-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-etree-frwk-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 21 18:30:31 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4761C1A0031; Wed, 21 May 2014 18:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBs9RBnayOCV; Wed, 21 May 2014 18:30:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9981A0037; Wed, 21 May 2014 18:30:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ED9AC18A997; Wed, 21 May 2014 18:30:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7209 on Requirements for Ethernet VPN (EVPN) X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140522013006.ED9AC18A997@rfc-editor.org> Date: Wed, 21 May 2014 18:30:06 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/7cyMK_hZEZZjEbbKXSWrsX6MGoo Cc: l2vpn@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 01:30:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7209 Title: Requirements for Ethernet VPN (EVPN) Author: A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, A. Isaac Status: Informational Stream: IETF Date: May 2014 Mailbox: sajassi@cisco.com, raggarwa_1@yahoo.com, uttaro@att.com, nabil.n.bitar@verizon.com, wim.henderickx@alcatel-lucent.com, aisaac71@bloomberg.net Pages: 15 Characters: 34040 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-evpn-req-07.txt URL: http://www.rfc-editor.org/rfc/rfc7209.txt The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu May 22 07:18:27 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ACD1A015C; Thu, 22 May 2014 07:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L7mmleefid7; Thu, 22 May 2014 07:18:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A131A017A; Thu, 22 May 2014 07:18:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-etree-frwk-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140522141821.19893.6515.idtracker@ietfa.amsl.com> Date: Thu, 22 May 2014 07:18:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Pp-I4lkKDv5pGGlpO7cIF9pw2z4 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:18:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network Authors : Raymond Key Lucy Yong Simon Delord Frederic Jounay Lizhong Jin Filename : draft-ietf-l2vpn-etree-frwk-06.txt Pages : 13 Date : 2014-05-22 Abstract: This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-etree-frwk/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-etree-frwk-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-etree-frwk-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 23 09:01:36 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F571A01BA for ; Fri, 23 May 2014 09:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL36FkpNe3xl for ; Fri, 23 May 2014 09:01:31 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AF91A0039 for ; Fri, 23 May 2014 09:01:31 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s4NFxodN018959; Fri, 23 May 2014 12:01:27 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0a-00103a01.pphosted.com with ESMTP id 1m1sexattp-3 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 23 May 2014 12:01:27 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVCGSIE2K1301.ciena.com (2.6.6.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 23 May 2014 12:01:05 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Fri, 23 May 2014 12:00:56 -0400 From: "Shah, Himanshu" To: "l2vpn@ietf.org" Date: Fri, 23 May 2014 12:00:54 -0400 Subject: Request to adopt draft-boutros-l2vpn-mpls-tp-mac-wd-03 Thread-Topic: Request to adopt draft-boutros-l2vpn-mpls-tp-mac-wd-03 Thread-Index: Ac92n0AAmd85MLEDQeuOSZTGWgDMvg== Message-ID: <40746B2300A8FC4AB04EE722A593182B70AA2948@ONWVEXCHMB04.ciena.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-20712.000 x-tm-as-result: No--39.710600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182B70AA2948ONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-23_06:2014-05-23,2014-05-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405230203 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Pkps4Or1oL6ngZ8R4k6rK_OEfU0 Cc: "msiva@cisco.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:01:35 -0000 --_000_40746B2300A8FC4AB04EE722A593182B70AA2948ONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG - We posted the following draft while back. http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-03 Sami presented this draft a few times in L2VPN WG while I pursued the same = in PWE3 WG. There was a good consensus in PWE3 WG for the draft but was felt that MAC w= ithdraw work should reside in L2VPN WG. Hence the update was sent to L2VPN WG. We have added a service provider as = a co-author. There is a good interest in this work especially from those service provide= rs who have deployed MPLS-TP network with static PWs. Since there has been sufficient history to this document, the authors requ= est that this be adopted as WG draft. Thanks, himanshu --_000_40746B2300A8FC4AB04EE722A593182B70AA2948ONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = --_000_40746B2300A8FC4AB04EE722A593182B70AA2948ONWVEXCHMB04cie_-- From nobody Sun May 25 08:40:57 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A091A03DA for ; Sun, 25 May 2014 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ_x2I84IskX for ; Sun, 25 May 2014 08:40:53 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3011A0315 for ; Sun, 25 May 2014 08:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=nabil.n.bitar@verizon.com; q=dns/txt; s=corp; t=1401032449; x=1432568449; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JcEH1PF57NAHhgxvJl/9px1aEwA+WVhfhI9HeDLuuuE=; b=rats9Qc2BPk8BzGq1xreqDESIh4k4BUpy3UZ4vht2wrTfaK0HDk1uiwa BLbTQ0WBSt5pCrx8xUhCwokUxdEZ6Xra1qOqJfuQidJCJPlbA1pmfwmKL arCduK8mF0IFhJ/L76xxcgcY4gOfQaXRTEGK9o/JGVr/5HAdBHRmHv2E1 U=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe02.verizonbusiness.com with ESMTP; 25 May 2014 15:40:48 +0000 From: "Bitar, Nabil N" To: "Bitar, Nabil N" , "l2vpn@ietf.org" X-IronPort-AV: E=Sophos;i="4.98,906,1392163200"; d="scan'208";a="729749986" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi02.verizon.com with ESMTP; 25 May 2014 15:40:48 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Sun, 25 May 2014 11:40:47 -0400 Date: Sun, 25 May 2014 11:40:47 -0400 Subject: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pim-snooping-06. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pim-snooping-06. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC+y0ElTxAw21UCVXEsDnxkbqA== Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/BFhX4JppFasgUx8IGG9-PBGrx00 Cc: "Giles Heron \(giheron@cisco.com\)" , "zzhang@juniper.net" , "rqiu@juniper.net" , "vhemige@gmail.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 15:40:55 -0000 Hi, We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= ls-pim-snooping-06, PIM Snooping over VPLS, in order to ensure that IPR has= been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 366= 9 and 5378 for more details). If you are listed as a document author, please respond to this email wheth= er or not you are aware of any relevant IPR that has not been properly disc= losed. The draft will not be progressed 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 co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. The draft c= an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pim-snoopin= g-06 This poll closes on Sunday 06/01/2014. Thanks, Nabil & Giles From nobody Sun May 25 08:41:51 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1701A0234 for ; Sun, 25 May 2014 08:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTir_hMLbuVQ for ; Sun, 25 May 2014 08:41:48 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0ABC1A01FB for ; Sun, 25 May 2014 08:41:47 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4PFfdD9022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 25 May 2014 10:41:41 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s4PFfdQg020775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 May 2014 17:41:39 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 25 May 2014 17:41:39 +0200 From: "Henderickx, Wim (Wim)" To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: Re: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC7Gzket0WwJD0+jmc4QCxnQzZtRbzeA Date: Sun, 25 May 2014 15:41:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <2A9530C449EDF440AE9D24232E23C349@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ShSVurrIZlSTnwO-BwIubJpKBrk Cc: "Giles Heron \(giheron@cisco.com\)" , "jiangyuanlong@huawei.com" , "Balus, Florin Stelian \(Florin\)" , "Sagessi \(sajassi@cisco.com\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 15:41:49 -0000 not aware of IPR related to this draft On 25/05/14 17:34, "Bitar, Nabil N" wrote: > > >Hi, > >We are polling for knowledge of any IPR that applies to >draft-ietf-l2vpn-vpls-pe-etree-03.txt, Ethernet-Tree (E-Tree) Support in >Virtual Private LAN Service (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, 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 progressed 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-pe-etree-03. > >This poll closes on Sunday 06/01/2014. > > >Thanks, >Nabil & Giles From nobody Sun May 25 20:00:47 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6CD1A0434 for ; Sun, 25 May 2014 20:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vf0HhGYpJn1 for ; Sun, 25 May 2014 20:00:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D4A1A0432 for ; Sun, 25 May 2014 20:00:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEN28706; Mon, 26 May 2014 03:00:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 04:00:15 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 04:00:39 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.41]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Mon, 26 May 2014 11:00:27 +0800 From: Jiangyuanlong To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: RE: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC7Gzket0WwJD0+jmc4QCxnQzZtSLJEA Date: Mon, 26 May 2014 03:00:27 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7354BD@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/SVhU299SqrP1xdjlOmTSU2Rf2pg Cc: "Giles Heron \(giheron@cisco.com\)" , "florin.balus@alcatel-lucent.com" , "Sagessi \(sajassi@cisco.com\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 03:00:46 -0000 Not aware of any relevant IPR that has not been properly disclosed. B.R., Yuanlong -----Original Message----- From: Bitar, Nabil N [mailto:nabil.n.bitar@verizon.com]=20 Sent: Sunday, May 25, 2014 11:34 PM To: Bitar, Nabil N; l2vpn@ietf.org Cc: Giles Heron (giheron@cisco.com); Jiangyuanlong; Lucy yong; manuel.paul@= telekom.de; frederic.jounay@orange.ch; florin.balus@alcatel-lucent.com; wim= .henderickx@alcatel-lucent.com; Sagessi (sajassi@cisco.com) Subject: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll c= loses on 6/1/2014. Please, respond Hi, We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= ls-pe-etree-03.txt, Ethernet-Tree (E-Tree) Support in Virtual Private LAN S= ervice (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, please respond to this email wheth= er or not you are aware of any relevant IPR that has not been properly disc= losed. The draft will not be progressed 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 co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. The draft c= an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-03= . This poll closes on Sunday 06/01/2014. Thanks, Nabil & Giles From nobody Sun May 25 21:26:39 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32EB1A0454 for ; Sun, 25 May 2014 21:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsCA5avbZYgo for ; Sun, 25 May 2014 21:26:35 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391541A046C for ; Sun, 25 May 2014 21:26:33 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4Q4QRJe026878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 25 May 2014 23:26:28 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s4Q4QQQQ030580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 May 2014 06:26:26 +0200 Received: from [138.203.14.185] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 26 May 2014 06:26:25 +0200 Message-ID: <5382C26D.8060004@alcatel-lucent.com> Date: Mon, 26 May 2014 06:26:21 +0200 From: Olivier Dornon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: Re: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pim-snooping-06. Poll closes on 6/1/2014. Please, respond References: , In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/vbxVqaPPHLpB61wWyTfsorZ8BNo Cc: "zzhang@juniper.net" , "Giles Heron \(giheron@cisco.com\)" , "rqiu@juniper.net" , "vhemige@gmail.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 04:26:36 -0000 I'm not aware of any IPR related to this draft. Olivier. On 05/25/2014 05:40 PM, Bitar, Nabil N wrote: > Hi, > > We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vpls-pim-snooping-06, PIM Snooping over 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, 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 progressed 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-pim-snooping-06 > > This poll closes on Sunday 06/01/2014. > > > Thanks, > Nabil & Giles From nobody Mon May 26 05:06:39 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DDB1A03DA for ; Sun, 25 May 2014 08:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suK71AvVZegQ for ; Sun, 25 May 2014 08:34:16 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99EF21A0315 for ; Sun, 25 May 2014 08:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=nabil.n.bitar@verizon.com; q=dns/txt; s=corp; t=1401032054; x=1432568054; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=a+14kgl7tiSR0YidSrtOV/nszxeYbqPEry7d9EmdqBs=; b=TONfCH3lQ1cRTUXYdysDIJ9bq2gW0ZIdJ5wEyGtnjlVdScykRsFxlZy8 RwIqqSXgoU5abvAQRDa/PJt9JpY+5GKo3QrRBhDWzdk4ao2kDNFslWAJG t283rttmG4cxX1YEImFfDj8uAB4W5oX6RMksO3HVE+nrLF5/j1WKkCWai g=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 25 May 2014 15:34:11 +0000 From: "Bitar, Nabil N" To: "Bitar, Nabil N" , "l2vpn@ietf.org" X-IronPort-AV: E=Sophos;i="4.98,906,1392163200"; d="scan'208";a="729748692" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi02.verizon.com with ESMTP; 25 May 2014 15:34:11 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB02.us.one.verizon.com ([166.68.75.85]) with mapi; Sun, 25 May 2014 11:34:11 -0400 Date: Sun, 25 May 2014 11:34:11 -0400 Subject: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC7Gzket0WwJD0+jmc4QCxnQzQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/OKWWRlaTZNnD4DW5P2pa9LAUrtQ X-Mailman-Approved-At: Mon, 26 May 2014 05:06:34 -0700 Cc: "Giles Heron \(giheron@cisco.com\)" , "jiangyuanlong@huawei.com" , "florin.balus@alcatel-lucent.com" , "Sagessi \(sajassi@cisco.com\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 15:34:18 -0000 Hi, We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= ls-pe-etree-03.txt, Ethernet-Tree (E-Tree) Support in Virtual Private LAN S= ervice (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, please respond to this email wheth= er or not you are aware of any relevant IPR that has not been properly disc= losed. The draft will not be progressed 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 co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. The draft c= an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-03= . This poll closes on Sunday 06/01/2014. Thanks, Nabil & Giles From nobody Mon May 26 05:06:40 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6F1A0450 for ; Sun, 25 May 2014 20:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxUy3ooi3yWj for ; Sun, 25 May 2014 20:35:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E371A0448 for ; Sun, 25 May 2014 20:35:38 -0700 (PDT) Received: from BY2PR05MB693.namprd05.prod.outlook.com (10.141.222.20) by BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 26 May 2014 03:35:32 +0000 Received: from BY2PR05MB693.namprd05.prod.outlook.com ([10.141.222.20]) by BY2PR05MB693.namprd05.prod.outlook.com ([10.141.222.20]) with mapi id 15.00.0944.000; Mon, 26 May 2014 03:35:32 +0000 From: Ray Qiu To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: Re: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pim-snooping-06. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pim-snooping-06. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC+y0ElTxAw21UCVXEsDnxkbqJtRwVyA Date: Mon, 26 May 2014 03:35:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.239.10] x-forefront-prvs: 02234DBFF6 x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(479174003)(377454003)(24454002)(5423002)(51704005)(189002)(199002)(164054003)(66066001)(4396001)(81342001)(87936001)(80022001)(21056001)(81542001)(99286001)(99396002)(92726001)(20776003)(85852003)(92566001)(83072002)(64706001)(2656002)(31966008)(79102001)(46102001)(74662001)(86362001)(74502001)(19580395003)(19580405001)(83322001)(101416001)(77096999)(50986999)(76176999)(54356999)(76482001)(77982001)(83506001)(36756003)(94096001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB079; H:BY2PR05MB693.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rqiu@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/By1TDQ9RG1Yp6J9ngr7Ox8TyHI4 X-Mailman-Approved-At: Mon, 26 May 2014 05:06:34 -0700 Cc: "Jeffrey \(Zhaohui\) Zhang" , "Giles Heron \(giheron@cisco.com\)" , "vhemige@gmail.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 03:35:40 -0000 As a co-author of the draft, I state that I am not aware of any relevant IPR. Thanks, Ray On 5/25/14, 8:40 AM, "Bitar, Nabil N" wrote: >Hi, > >We are polling for knowledge of any IPR that applies to >draft-ietf-l2vpn-vpls-pim-snooping-06, PIM Snooping over 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, 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 progressed 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-pim-snooping-06 > >This poll closes on Sunday 06/01/2014. > > >Thanks, >Nabil & Giles From nobody Mon May 26 07:00:04 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD901A015F for ; Mon, 26 May 2014 07:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1jcDnnsqyUC for ; Mon, 26 May 2014 07:00:01 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E3C1A0157 for ; Mon, 26 May 2014 07:00:00 -0700 (PDT) Received: from [85.158.139.163:51536] by server-16.bemta-5.messagelabs.com id 20/95-19700-DD843835; Mon, 26 May 2014 13:59:57 +0000 X-Env-Sender: Frederic.Jounay@orange.ch X-Msg-Ref: server-13.tower-188.messagelabs.com!1401112796!4246275!1 X-Originating-IP: [213.55.206.7] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32723 invoked from network); 26 May 2014 13:59:56 -0000 Received: from unknown (HELO chcrochs054.orange.ch) (213.55.206.7) by server-13.tower-188.messagelabs.com with RC4-SHA encrypted SMTP; 26 May 2014 13:59:56 -0000 Received: from CHCROCHC051.orange.ch ([fe80:0000:0000:0000:704b:3a68:12.14.247.83]) by chcrochs054.orange.ch ([172.19.166.54]) with mapi; Mon, 26 May 2014 15:58:55 +0200 From: =?iso-8859-1?Q?Jounay_Fr=E9d=E9ric?= To: "Bitar, Nabil N" , "l2vpn@ietf.org" Date: Mon, 26 May 2014 15:58:54 +0200 Subject: RE: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC7Gzket0WwJD0+jmc4QCxnQzZtS5L6g Message-ID: <78046FD1C8FE0345AFBC11640A8DF6E201864A3D6701@CHCROCHC051.orange.ch> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/kS0tbxoaj8o4Oeisl1pEnVpYR4s Cc: "Giles Heron \(giheron@cisco.com\)" , "jiangyuanlong@huawei.com" , "florin.balus@alcatel-lucent.com" , "Sagessi \(sajassi@cisco.com\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 14:00:03 -0000 Hi Not aware of any patent related to this draft BR Fred -----Original Message----- From: Bitar, Nabil N [mailto:nabil.n.bitar@verizon.com]=20 Sent: Sunday, 25 May 2014 17:34 To: Bitar, Nabil N; l2vpn@ietf.org Cc: Giles Heron (giheron@cisco.com); jiangyuanlong@huawei.com; lucyyong@hua= wei.com; manuel.paul@telekom.de; Jounay Fr=E9d=E9ric; florin.balus@alcatel-= lucent.com; wim.henderickx@alcatel-lucent.com; Sagessi (sajassi@cisco.com) Subject: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll c= loses on 6/1/2014. Please, respond Hi, We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= ls-pe-etree-03.txt, Ethernet-Tree (E-Tree) Support in Virtual Private LAN S= ervice (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, please respond to this email wheth= er or not you are aware of any relevant IPR that has not been properly disc= losed. The draft will not be progressed 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 co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. The draft c= an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-03= . This poll closes on Sunday 06/01/2014. Thanks, Nabil & Giles From nobody Mon May 26 07:23:00 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0301A016C for ; Mon, 26 May 2014 07:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGYl6gyabF5q for ; Mon, 26 May 2014 07:22:57 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7321A0160 for ; Mon, 26 May 2014 07:22:57 -0700 (PDT) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 26 May 2014 16:22:51 +0200 Received: from HE101454.emea1.cds.t-internal.com ([10.125.92.150]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Mon, 26 May 2014 16:22:51 +0200 From: To: , Date: Mon, 26 May 2014 16:22:50 +0200 Subject: AW: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC7Gzket0WwJD0+jmc4QCxnQzZtS5L6ggAAAw6A= Message-ID: <08AFB17A021B974CBAA6BA84FA19B43CA07D926188@HE101454.emea1.cds.t-internal.com> References: <78046FD1C8FE0345AFBC11640A8DF6E201864A3D6701@CHCROCHC051.orange.ch> In-Reply-To: <78046FD1C8FE0345AFBC11640A8DF6E201864A3D6701@CHCROCHC051.orange.ch> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/BS-CVe_sCMiroxvXzZAtfpXN7cQ Cc: giheron@cisco.com, jiangyuanlong@huawei.com, florin.balus@alcatel-lucent.com, sajassi@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 14:22:59 -0000 Dear All, I am not aware of any relevant IPR that has not been properly disclosed. Best Regards, Manuel =20 -----Original Message----- From: Bitar, Nabil N [mailto:nabil.n.bitar@verizon.com]=20 Sent: Sunday, 25 May 2014 17:34 To: Bitar, Nabil N; l2vpn@ietf.org Cc: Giles Heron (giheron@cisco.com); jiangyuanlong@huawei.com; lucyyong@hua= wei.com; manuel.paul@telekom.de; Jounay Fr=E9d=E9ric; florin.balus@alcatel-= lucent.com; wim.henderickx@alcatel-lucent.com; Sagessi (sajassi@cisco.com) Subject: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll c= loses on 6/1/2014. Please, respond Hi, We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= ls-pe-etree-03.txt, Ethernet-Tree (E-Tree) Support in Virtual Private LAN S= ervice (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, please respond to this email wheth= er or not you are aware of any relevant IPR that has not been properly disc= losed. The draft will not be progressed 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 co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. The draft c= an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-03= . This poll closes on Sunday 06/01/2014. Thanks, Nabil & Giles From nobody Tue May 27 07:29:30 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E364E1A0435 for ; Tue, 27 May 2014 07:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUuBruW_fAJ1 for ; Tue, 27 May 2014 07:29:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB791A0158 for ; Tue, 27 May 2014 07:29:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEP21574; Tue, 27 May 2014 14:29:14 +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.3.158.1; Tue, 27 May 2014 15:28:44 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 15:29:12 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Tue, 27 May 2014 07:28:55 -0700 From: Lucy yong To: "Manuel.Paul@telekom.de" , "nabil.n.bitar@verizon.com" , "l2vpn@ietf.org" Subject: RE: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC7Gzket0WwJD0+jmc4QCxnQzZtS5L6ggAAAw6CAAZip0A== Date: Tue, 27 May 2014 14:28:54 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45388FAF@dfweml701-chm.china.huawei.com> References: <78046FD1C8FE0345AFBC11640A8DF6E201864A3D6701@CHCROCHC051.orange.ch> <08AFB17A021B974CBAA6BA84FA19B43CA07D926188@HE101454.emea1.cds.t-internal.com> In-Reply-To: <08AFB17A021B974CBAA6BA84FA19B43CA07D926188@HE101454.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.221] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/26dWUYCuP0qw-CDVyDRoeGuSviM Cc: "giheron@cisco.com" , Jiangyuanlong , "florin.balus@alcatel-lucent.com" , "sajassi@cisco.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 14:29:28 -0000 I am not aware of a relevant IPR that has not been properly disclosed. Lucy=20 -----Original Message----- From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de]=20 Sent: Monday, May 26, 2014 9:23 AM To: nabil.n.bitar@verizon.com; l2vpn@ietf.org Cc: giheron@cisco.com; Jiangyuanlong; Lucy yong; florin.balus@alcatel-lucen= t.com; wim.henderickx@alcatel-lucent.com; sajassi@cisco.com; Frederic.Jouna= y@orange.ch Subject: AW: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Po= ll closes on 6/1/2014. Please, respond Dear All, I am not aware of any relevant IPR that has not been properly disclosed. Best Regards, Manuel =20 -----Original Message----- From: Bitar, Nabil N [mailto:nabil.n.bitar@verizon.com]=20 Sent: Sunday, 25 May 2014 17:34 To: Bitar, Nabil N; l2vpn@ietf.org Cc: Giles Heron (giheron@cisco.com); jiangyuanlong@huawei.com; lucyyong@hua= wei.com; manuel.paul@telekom.de; Jounay Fr=E9d=E9ric; florin.balus@alcatel-= lucent.com; wim.henderickx@alcatel-lucent.com; Sagessi (sajassi@cisco.com) Subject: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll c= loses on 6/1/2014. Please, respond Hi, We are polling for knowledge of any IPR that applies to draft-ietf-l2vpn-vp= ls-pe-etree-03.txt, Ethernet-Tree (E-Tree) Support in Virtual Private LAN S= ervice (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, please respond to this email wheth= er or not you are aware of any relevant IPR that has not been properly disc= losed. The draft will not be progressed 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 co= ntributor, then please explicitly respond only if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. The draft c= an be found at http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-03= . This poll closes on Sunday 06/01/2014. Thanks, Nabil & Giles From nobody Tue May 27 22:45:23 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C641A035D for ; Tue, 27 May 2014 22:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceiyQvrRWNC1 for ; Tue, 27 May 2014 22:45:19 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A6D1A0358 for ; Tue, 27 May 2014 22:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1159; q=dns/txt; s=iport; t=1401255916; x=1402465516; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0s0CczOss+O5ZPZiN72z0+UqWcnl9YjCFESBxLpn2Ak=; b=jJSx/ZVPqtvKKmPGFiYQO0GWkNNRlwWxrv1E8SZkSk7VEWa2mfPuZeqG 01XjlZGjSYqP0n2jxHFkbhv0B5Hxh/NOjV5OBQ4qMCyzAtI3Murd89oNN xqiCvFegFFyaIXq3+fKZmx7VjkbIUVVrhpQmzIIfScYqq0WTaD8eptfDt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAPp2hVOtJV2d/2dsb2JhbABZgmUiUljCMwGBChZ0giw6PxIBCDYFPSUCBAENBYguAxEBDNVEF4w8gTQRAVAHhEAElXOEAYE9kWqBeIFAbIEKOQ X-IronPort-AV: E=Sophos;i="4.98,925,1392163200"; d="scan'208";a="328422541" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 28 May 2014 05:45:15 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4S5jF0P004931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 05:45:15 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 28 May 2014 00:45:15 -0500 From: "Ali Sajassi (sajassi)" To: "Bitar, Nabil N" , "l2vpn@ietf.org" Subject: Re: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Topic: [l2vpn] IPR Poll for draft-ietf-l2vpn-vpls-pe-etree-03.txt. Poll closes on 6/1/2014. Please, respond Thread-Index: AQHPeC7Gzket0WwJD0+jmc4QCxnQzZtVXhiA Date: Wed, 28 May 2014 05:45:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.21.81.249] Content-Type: text/plain; charset="us-ascii" Content-ID: <168D600526B40E459B98F358BC780984@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/egG8kclRL-LWDFMHY2BR1Kg606M Cc: "Giles Heron \(giheron\)" , "jiangyuanlong@huawei.com" , "florin.balus@alcatel-lucent.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 05:45:21 -0000 Not aware of any relevant IPR (if any) that hasn't already been disclosed. Regards, Ali On 5/25/14 8:34 AM, "Bitar, Nabil N" wrote: > > >Hi, > >We are polling for knowledge of any IPR that applies to >draft-ietf-l2vpn-vpls-pe-etree-03.txt, Ethernet-Tree (E-Tree) Support in >Virtual Private LAN Service (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, 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 progressed 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-pe-etree-03. > >This poll closes on Sunday 06/01/2014. > > >Thanks, >Nabil & Giles From nobody Wed May 28 04:29:20 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE801A00C6 for ; Wed, 28 May 2014 04:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkgzZ0dj3Dvu for ; Wed, 28 May 2014 04:29:16 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953C51A0950 for ; Wed, 28 May 2014 04:29:16 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a1so10789145wgh.15 for ; Wed, 28 May 2014 04:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=gTY8lPCvnMnFevJbPqT+SPGKrEgUNlPFLm7YwtxOHy0=; b=jryzosviwTtJO2F1V3GsgbtjAr8MoAZdTj298//Jyo8ChSjZRKy8v/E/iDQaIJXzIX rkRUjfn707VZwEQnylAWngMCjTQvb4vB1yoUlX/HdyB+bDAcT+D0PCx9kansCS8qM924 SQ/cXi1F6WdnC3QMRrl9hSHvccs5SxhAFTRnvU6P9Da9bmu7fQ4AApzAMJEePjDFSsih sMS5NnvZ2XTAvcVG7nU+jzoRp69gqW3kGVZFEtJ2/858ryfHVI7tbzxFz/H+mK4wAXzg w7SpaeGPGxjhhuq6Z66bDIMsiteGi9YI74J9QBSNtPkfvJx+RLC2LXXULRohtLFmeOBx RPJA== X-Received: by 10.194.133.1 with SMTP id oy1mr34528630wjb.87.1401276550652; Wed, 28 May 2014 04:29:10 -0700 (PDT) Received: from [10.61.202.177] (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id mw4sm16121662wib.12.2014.05.28.04.29.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 04:29:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: WG LC for draft-ietf-l2vpn-evpn-07 From: Giles Heron In-Reply-To: Date: Wed, 28 May 2014 12:29:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "l2vpn@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/lM52NJ2_AjbiJuNMr1Nx8SmEP6Q X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 11:29:18 -0000 Hi all. this WG LC has now passed. however... I forgot to issue an IPR call before the WG LC. I'll send an IPR call = as a separate email. Giles On 9 May 2014, at 14:01, Giles Heron wrote: > This email initiates an IETF L2VPN WG Last Call for: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >=20 > please comment to the list as to the suitability of this draft for = publication as a Standards Track RFC from the L2VPN WG. >=20 > this last call will close on Friday 23rd May 2014. >=20 > Nabil & Giles From nobody Thu May 29 05:51:58 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA051A08E8 for ; Thu, 29 May 2014 05:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMghact3r2C2 for ; Thu, 29 May 2014 05:51:55 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477961A08E3 for ; Thu, 29 May 2014 05:51:55 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so348796wgg.12 for ; Thu, 29 May 2014 05:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=TZzsRHQRUvoEtQAYgEhzgRhyO+7OEzOySGoEx8ZuuEk=; b=b9pXxvmFM6N2Gk34Gay5vxikbBLROQ/cRhsqzww+BeAZi2l6hwiVMWLzAwqO/6OW8w N7Xf27ZFkzRGyvK6ePsJ9L5z9LWoasuWbxpi7D5Gd6q7bIcGOy4tZtqnFZHolIqIkixK lhhIqIerTRze1HIaWSYv6/sM7M7SQM4legU0pvbadPc4wR5fRXE08ee0omPIJrq5UyGM ZZz4gI8O98uqpLnkUIIJ11GqqHhln8h+uYLkybAh+KKUhbJPYHa7unKRVaCUPp2w/egY Wyj+yGqkPSoYQmnL2sz8UQPy+vY6L2T6YM6guP8Gn/+fq6BttX8Ucxk8rF7hKwK+qxAT 9kAw== X-Received: by 10.194.246.234 with SMTP id xz10mr10203127wjc.77.1401367909422; Thu, 29 May 2014 05:51:49 -0700 (PDT) Received: from [10.61.203.129] (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id je7sm2660590wic.14.2014.05.29.05.51.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 05:51:48 -0700 (PDT) From: Giles Heron Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: IPR call for draft-ietf-l2vpn-evpn-07 Date: Thu, 29 May 2014 13:51:47 +0100 Message-Id: To: l2vpn@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/N-3xTXfL9wSv4Cb7EV5aRrqPVVI X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:51:56 -0000 Hi, this email initiates an IPR call for: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 would all authors please respond to this email indicating whether there = is any IPR they are aware of which has not already been disclosed to the = IETF. Likewise if anyone else is aware of any IPR that has not already been = disclosed to the IETF would you please respond to this email. And would everyone please take a look at the IPR that has already been = disclosed - especially in view of the fact that one of those disclosures = only happened this month: = https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddra= ft-ietf-l2vpn-evpn Please respond to the list if you have any concerns about the impact of = any of this IPR on the suitability of this draft for adoption as a = standards-track RFC. this IPR call closes on Thursday 10th June 2014. Giles= From nobody Thu May 29 06:42:44 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190B81A0911 for ; Thu, 29 May 2014 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ_1vodoLxmZ for ; Thu, 29 May 2014 06:42:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD2B1A0909 for ; Thu, 29 May 2014 06:42:40 -0700 (PDT) Received: from BL2PR05MB210.namprd05.prod.outlook.com (10.242.198.145) by BL2PR05MB212.namprd05.prod.outlook.com (10.242.198.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 29 May 2014 13:42:34 +0000 Received: from BL2PR05MB210.namprd05.prod.outlook.com ([169.254.6.98]) by BL2PR05MB210.namprd05.prod.outlook.com ([169.254.6.98]) with mapi id 15.00.0949.001; Thu, 29 May 2014 13:42:34 +0000 From: Yakov Rekhter To: Giles Heron , "l2vpn@ietf.org" Subject: RE: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Topic: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPezzeM+uGjJWVVUGwzb9gfJo4hptXkP4Q Date: Thu, 29 May 2014 13:42:33 +0000 Message-ID: <88eb6faf05ff4b50bf873908d0a9b39a@BL2PR05MB210.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.10] x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(199002)(377454003)(189002)(13464003)(36944003)(64706001)(15975445006)(79102001)(66066001)(80022001)(92566001)(74316001)(20776003)(83072002)(85852003)(86362001)(15202345003)(87936001)(76176999)(81342001)(54356999)(101416001)(31966008)(2656002)(46102001)(19580395003)(19580405001)(81542001)(83322001)(77982001)(76576001)(99286001)(99396002)(50986999)(33646001)(76482001)(21056001)(4396001)(74502001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB212; H:BL2PR05MB210.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=yakov@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/wZBjJ8ZlV6wOvV0G-rmkkTuzi2w X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:42:43 -0000 Giles, > -----Original Message----- > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron > Sent: Thursday, May 29, 2014 8:52 AM > To: l2vpn@ietf.org > Subject: IPR call for draft-ietf-l2vpn-evpn-07 >=20 > Hi, >=20 > this email initiates an IPR call for: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >=20 > would all authors please respond to this email indicating whether there > is any IPR they are aware of which has not already been disclosed to > the IETF. I am not aware of any IPR related to draft-ietf-l2vpn-evpn-07 Yakov. >=20 > Likewise if anyone else is aware of any IPR that has not already been > disclosed to the IETF would you please respond to this email. >=20 > And would everyone please take a look at the IPR that has already been > disclosed - especially in view of the fact that one of those > disclosures only happened this month: >=20 > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddr= af > t-ietf-l2vpn-evpn >=20 > Please respond to the list if you have any concerns about the impact of > any of this IPR on the suitability of this draft for adoption as a > standards-track RFC. >=20 > this IPR call closes on Thursday 10th June 2014. >=20 > Giles From nobody Thu May 29 06:49:33 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD951A0931 for ; Thu, 29 May 2014 06:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfYU8KAzFwcv for ; Thu, 29 May 2014 06:49:31 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F6A1A0909 for ; Thu, 29 May 2014 06:49:31 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4TDnP9e023415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 May 2014 08:49:26 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s4TDnJ1W014406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 15:49:24 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 29 May 2014 15:49:23 +0200 From: "Henderickx, Wim (Wim)" To: Giles Heron , "l2vpn@ietf.org" Subject: Re: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Topic: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPezzKjBRj2AMhkUGd5yiLRp9psJtXkw6A Date: Thu, 29 May 2014 13:49:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <37875C4D33C0EB4292372C66BBC5711C@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/z6uo3t_vo4Ey5H556i67zcWbgOk X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:49:33 -0000 We recently disclosed IPR against this WG draft. An IPR disclosure that pertains to your Internet-Draft entitled "BGP MPLS Based Ethernet VPN" (draft-ietf-l2vpn-evpn) was submitted to the IETF Secretariat on 2014-05-17 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2363/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn- evpn-07 (2).""); The IETF Secretariat Originally (2012) our IPR people disclosed IPR against draft-raggarwa-sajassi-l2vpn-evpn-04. https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ra ggarwa-sajassi-l2vpn-evpn and not on the WG document. One we discovered the IPR was not disclosed against the WG document we recently resubmitted the IPR against the WG doc. On 29/05/14 14:51, "Giles Heron" wrote: >Hi, > >this email initiates an IPR call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >would all authors please respond to this email indicating whether there >is any IPR they are aware of which has not already been disclosed to the >IETF. > >Likewise if anyone else is aware of any IPR that has not already been >disclosed to the IETF would you please respond to this email. > >And would everyone please take a look at the IPR that has already been >disclosed - especially in view of the fact that one of those disclosures >only happened this month: > >https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddra= ft-i >etf-l2vpn-evpn > >Please respond to the list if you have any concerns about the impact of >any of this IPR on the suitability of this draft for adoption as a >standards-track RFC. > >this IPR call closes on Thursday 10th June 2014. > >Giles From nobody Thu May 29 07:12:35 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F91A0950 for ; Thu, 29 May 2014 07:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u-1gDQgkpsd for ; Thu, 29 May 2014 07:12:30 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BB81A094A for ; Thu, 29 May 2014 07:12:30 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id a4047835.2ae619294940.5052109.00-2448.14067448.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 29 May 2014 14:12:26 +0000 (UTC) X-MXL-Hash: 5387404a24005e36-231a39b5c83d74af687a37e6c5c855e762498fb5 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 13047835.0.5051882.00-2132.14066779.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 29 May 2014 14:12:02 +0000 (UTC) X-MXL-Hash: 5387403275c3e152-fef69807c4f7fbd20bc1c2b027c1fac552b99f41 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4TEC1eC000987; Thu, 29 May 2014 10:12:01 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4TEBq0v000765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 10:11:58 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 29 May 2014 14:11:44 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.251]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Thu, 29 May 2014 10:11:44 -0400 From: "UTTARO, JAMES" To: "'Giles Heron'" , "'l2vpn@ietf.org'" Subject: RE: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Topic: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPezzJSebA23VnbEaGFFnE7O9P7ptXmV+g Date: Thu, 29 May 2014 14:11:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Kpj6LxqN c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=7RyupwSTV8QA:10 a=ofMgfj31e3cA:10 a=lB4lNuC3LbQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=MHSEV1fPoWCI1D8nuQgA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/S1pRH9QNNuLLeV1f-hLuqrqw0CU X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:12:32 -0000 None that I am aware of Jim Uttaro -----Original Message----- From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron Sent: Thursday, May 29, 2014 8:52 AM To: l2vpn@ietf.org Subject: IPR call for draft-ietf-l2vpn-evpn-07 Hi, this email initiates an IPR call for: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 would all authors please respond to this email indicating whether there is = any IPR they are aware of which has not already been disclosed to the IETF. Likewise if anyone else is aware of any IPR that has not already been discl= osed to the IETF would you please respond to this email. And would everyone please take a look at the IPR that has already been disc= losed - especially in view of the fact that one of those disclosures only h= appened this month: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-l2vpn-evpn Please respond to the list if you have any concerns about the impact of any= of this IPR on the suitability of this draft for adoption as a standards-t= rack RFC. this IPR call closes on Thursday 10th June 2014. Giles From nobody Thu May 29 08:56:39 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85791A0441 for ; Thu, 29 May 2014 08:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDvDVu_C9wWl for ; Thu, 29 May 2014 08:56:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB851A6F72 for ; Thu, 29 May 2014 08:56:03 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 29 May 2014 15:55:57 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0949.001; Thu, 29 May 2014 15:55:57 +0000 From: John E Drake To: Giles Heron , "l2vpn@ietf.org" Subject: RE: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Topic: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPezzjyK5eZGutmkynpKnBEf8ejZtXtkcQ Date: Thu, 29 May 2014 15:55:57 +0000 Message-ID: <66ec711789b949adb62c0db1e423bc85@BLUPR05MB562.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(36944003)(13464003)(377454003)(199002)(189002)(51704005)(81342001)(66066001)(54356999)(20776003)(92566001)(31966008)(81542001)(74662001)(74502001)(85852003)(4396001)(76176999)(76576001)(101416001)(2656002)(74316001)(76482001)(46102001)(15202345003)(50986999)(64706001)(80022001)(77982001)(86362001)(15975445006)(77096999)(19580395003)(79102001)(33646001)(83322001)(87936001)(99396002)(19580405001)(99286001)(83072002)(21056001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/038b3cyxoTCNQ3YZEo7mOYq1r2Y X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:56:35 -0000 I'm not aware of any IPR which has not already been disclosed. Yours Irrespectively, John > -----Original Message----- > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron > Sent: Thursday, May 29, 2014 5:52 AM > To: l2vpn@ietf.org > Subject: IPR call for draft-ietf-l2vpn-evpn-07 >=20 > Hi, >=20 > this email initiates an IPR call for: >=20 > http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >=20 > would all authors please respond to this email indicating whether there i= s any > IPR they are aware of which has not already been disclosed to the IETF. >=20 > Likewise if anyone else is aware of any IPR that has not already been dis= closed > to the IETF would you please respond to this email. >=20 > And would everyone please take a look at the IPR that has already been > disclosed - especially in view of the fact that one of those disclosures = only > happened this month: >=20 > https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddr= aft- > ietf-l2vpn-evpn >=20 > Please respond to the list if you have any concerns about the impact of a= ny of > this IPR on the suitability of this draft for adoption as a standards-tra= ck RFC. >=20 > this IPR call closes on Thursday 10th June 2014. >=20 > Giles From nobody Thu May 29 09:05:15 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B601A6FC8 for ; Thu, 29 May 2014 09:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWMNfEHqgg7j for ; Thu, 29 May 2014 09:05:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB66A1A6FC3 for ; Thu, 29 May 2014 09:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1085; q=dns/txt; s=iport; t=1401379509; x=1402589109; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=eb3zCkg5CCpk3f2WXZZoRAZH0fyORIWv6McIhutm4/Q=; b=NIv6Oz+sA2b1CWHjmLR3lPlc/9WQ5u46f6YtwaM2DazU4EAe5VqGvaUX ekbITbBI4dgWqk5vzWq4+8R7e1xSCdxPwhC+oPO/A1/awi5oy9k83hZIN mnPPyLWIVBHdAPL0spCWTYAV5BvRLwNdAEJTl19s+aqnM8WqLAtAUp3xy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAKVZh1OtJV2Q/2dsb2JhbABZgmUiUljCNgGBDBZ0giwdHVEBCDYxESUCBAESiC4DEQEM0R8NhhMXjDyBNBEBHTqEQASXf4F2gT2LeYVzgziBdjk X-IronPort-AV: E=Sophos;i="4.98,934,1392163200"; d="scan'208";a="328694575" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 29 May 2014 16:05:05 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4TG55iW032409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 16:05:05 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 29 May 2014 11:05:05 -0500 From: "Ali Sajassi (sajassi)" To: Giles Heron , "l2vpn@ietf.org" Subject: Re: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Topic: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPezzLdvIOLQb1U02n8ObQu8twWptXl4AA Date: Thu, 29 May 2014 16:05:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.128.2.45] Content-Type: text/plain; charset="us-ascii" Content-ID: <7684FBEFDED80F45BF7B2E5763084D99@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/wN10U_Y3T9g7HGKjw0fuor1eDRA X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:05:14 -0000 I'm not aware of any relevant IPR that has not already been disclosed. Regards, Ali On 5/29/14 5:51 AM, "Giles Heron" wrote: >Hi, > >this email initiates an IPR call for: > >http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 > >would all authors please respond to this email indicating whether there >is any IPR they are aware of which has not already been disclosed to the >IETF. > >Likewise if anyone else is aware of any IPR that has not already been >disclosed to the IETF would you please respond to this email. > >And would everyone please take a look at the IPR that has already been >disclosed - especially in view of the fact that one of those disclosures >only happened this month: > >https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddra= ft-i >etf-l2vpn-evpn > >Please respond to the list if you have any concerns about the impact of >any of this IPR on the suitability of this draft for adoption as a >standards-track RFC. > >this IPR call closes on Thursday 10th June 2014. > >Giles From nobody Thu May 29 09:16:30 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13B01A6FF8 for ; Thu, 29 May 2014 09:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pduWAkj68BIb for ; Thu, 29 May 2014 09:16:27 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2CF1A6FDF for ; Thu, 29 May 2014 09:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1297; q=dns/txt; s=iport; t=1401380142; x=1402589742; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Ncg0WSvScDIEnGkynolcnaqsgV3CofiL7ZQB11TJW00=; b=jzfqX4/zFummxvScabT4kzIegApTcLzcF1zwNdHbOTFH/i+68gQvhPdY 9lEeO/R1aFyQhVQcwKgh3cPOJhOpMQd7gi/ILI4C1jt6WqbE5vbEkyFUO kzoV2nTpczyFbgZVUF+j8fOtFmK/7oRAXGxyZqxr+H7BXsemHA0a6oE2G I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYHAJdch1OtJV2Z/2dsb2JhbABZgwdSWKoHCwEBAQEBAQUBmBgBgQwWdIIlAQEBBB0dUQEIGB4xESUCBAESiC4DEQ3RIg2GExeFVYZngTQRAR06hEAEl3+BdoE9i3mFc4M4gXY5 X-IronPort-AV: E=Sophos;i="4.98,934,1392163200"; d="scan'208";a="48347032" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 29 May 2014 16:15:41 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4TGFfkV004380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 16:15:41 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 29 May 2014 11:15:41 -0500 From: "Keyur Patel (keyupate)" To: "Ali Sajassi (sajassi)" , Giles Heron , "l2vpn@ietf.org" Subject: Re: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Topic: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Index: AQHPezzLlw7+FExp3kefQP9xWXEGxptYDNkA//+Ql4A= Date: Thu, 29 May 2014 16:15:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.125] Content-Type: text/plain; charset="us-ascii" Content-ID: <152CEE545507DA4EB08BB0BAE3AA6FC5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/GhHW445f1MgZPeJ9oFa2sKUWmxg X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:16:28 -0000 I'm not aware of any relevant IPR that has not already been disclosed. Regards, Keyur On 5/29/14 9:05 AM, "Ali Sajassi (sajassi)" wrote: > >I'm not aware of any relevant IPR that has not already been disclosed. > > >Regards, >Ali > >On 5/29/14 5:51 AM, "Giles Heron" wrote: > >>Hi, >> >>this email initiates an IPR call for: >> >>http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 >> >>would all authors please respond to this email indicating whether there >>is any IPR they are aware of which has not already been disclosed to the >>IETF. >> >>Likewise if anyone else is aware of any IPR that has not already been >>disclosed to the IETF would you please respond to this email. >> >>And would everyone please take a look at the IPR that has already been >>disclosed - especially in view of the fact that one of those disclosures >>only happened this month: >> >>https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddr= aft- >>i >>etf-l2vpn-evpn >> >>Please respond to the list if you have any concerns about the impact of >>any of this IPR on the suitability of this draft for adoption as a >>standards-track RFC. >> >>this IPR call closes on Thursday 10th June 2014. >> >>Giles > From nobody Fri May 30 02:58:18 2014 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7691A084B for ; Fri, 30 May 2014 02:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_u7MoCy0THf for ; Fri, 30 May 2014 02:58:15 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8E61A07A5 for ; Fri, 30 May 2014 02:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=nabil.n.bitar@verizon.com; q=dns/txt; s=corp; t=1401443891; x=1432979891; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Xo9MCDCwxJIs5l7DJbxChwhv8+sYXLiQ1262V0V0vXE=; b=HbgDmvASje8wHNzu+B88HFOiMYdcCJtJt8hFGPf7HEJFS+BcPyTGkAML 2n/vFELmOUbw4bD7PnmU8A9Ea3PpAeNZkUM8uQphGEBE1Km7k12YfWYdv +LD/ttf1udfOVX6BxPONURVQuJDQYdE2EU/KEKOl7pZDJZAAOfK/xqe8+ w=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe02.verizonbusiness.com with ESMTP; 30 May 2014 09:58:10 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.98,940,1392163200"; d="scan'208";a="758183649" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi01.verizon.com with ESMTP; 30 May 2014 09:58:09 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Fri, 30 May 2014 05:58:09 -0400 To: Giles Heron , "l2vpn@ietf.org" Date: Fri, 30 May 2014 05:56:47 -0400 Subject: RE: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Topic: IPR call for draft-ietf-l2vpn-evpn-07 Thread-Index: Ac97PMSRyUpRJdxpSx2JO/aCEvKyXQAsLPEC Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Jch5CQNW9WJqbZYMc0MdAjp3ysU X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 09:58:16 -0000 Hi, I am not aware of any IPR related to this draft that has not been properly = disclosed. Thanks, Nabil ____________________________ From: Giles Heron [giles.heron@gmail.com] Sent: Thursday, May 29, 2014 8:51 AM To: l2vpn@ietf.org Cc: Bitar, Nabil N Subject: IPR call for draft-ietf-l2vpn-evpn-07 Hi, this email initiates an IPR call for: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-07 would all authors please respond to this email indicating whether there is = any IPR they are aware of which has not already been disclosed to the IETF. Likewise if anyone else is aware of any IPR that has not already been discl= osed to the IETF would you please respond to this email. And would everyone please take a look at the IPR that has already been disc= losed - especially in view of the fact that one of those disclosures only h= appened this month: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraf= t-ietf-l2vpn-evpn Please respond to the list if you have any concerns about the impact of any= of this IPR on the suitability of this draft for adoption as a standards-t= rack RFC. this IPR call closes on Thursday 10th June 2014. Giles

WG –

We= posted the following draft while back.

http://tools.ietf.org/html/draft-boutros-l2vp= n-mpls-tp-mac-wd-03

 

Sami presented this draft a few times in L2VPN WG while I pursued the sa= me in PWE3 WG.

There was a good consensus in PWE3 WG for the draft but was felt that MAC = withdraw work

should reside in L2VPN WG.

<= i> 

Hence the update was sent to L2VPN WG. We have added a service provi= der as a co-author.

There is a good interest in this work especially from those service p= roviders who have

deployed MPLS-TP network with static PWs.

 

Since there has been sufficient history to this= document,  the authors request that this be

=

adopted as WG draft.<= /i>

 

=

Thanks,

himanshu