From nobody Mon Feb 1 06:51:24 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A5E1A9300 for ; Mon, 1 Feb 2016 06:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 BV5Ymz6XThDd for ; Mon, 1 Feb 2016 06:51:21 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E3B1A92FB for ; Mon, 1 Feb 2016 06:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2465; q=dns/txt; s=iport; t=1454338281; x=1455547881; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QtGawf/kz4pLJIzCeDeA9KLa2XW7pn6t9pDW17jZi2E=; b=GFz7eE32nZ/Rtt0NciXa7d6MC4+IZvSpaCCuGUGPm/FH629eFz0iNZZU GLbGtblPxRqM1nSDfUFsGbW5wQOHUpcHRSBiRXG00ZWohY6YW933gYltd 3JcCkKuNjlYnwg2hnFJNpvB1p6JfJolyz+U1DEX6RJRHhbxg/xOPjl2im c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCTcK9W/49dJa1bA4M6Um0GiFKxX?= =?us-ascii?q?QENgWQYCoVtAoE2OBQBAQEBAQEBgQqEQgEBBAEBARpJCBkCAgEIGC4bDAslAgQ?= =?us-ascii?q?BEhuIAA6vXIx7AQEBAQEBAQEBAQEBAQEBAQEBAQEBFQSGC4Q3hAIRASkWERWDc?= =?us-ascii?q?wWNXYkSAYVGiASBW0qDeIMlhBSBGopsg1EBHgEBQoNsagGHRQcXHQF7AQEB?= X-IronPort-AV: E=Sophos;i="5.22,380,1449532800"; d="scan'208";a="233597761" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2016 14:51:20 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u11EpKfi018364 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2016 14:51:20 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 1 Feb 2016 09:51:19 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1104.009; Mon, 1 Feb 2016 09:51:19 -0500 From: "Patrice Brissette (pbrisset)" To: "thomas.morin@orange.com" , BESS , "draft-ietf-bess-evpn-etree@tools.ietf.org" Thread-Topic: [bess] WG Last Call on draft-ietf-bess-evpn-etree Thread-Index: AQHRXQACl7hlsVXo3E6veR+QFWaf7A== Date: Mon, 1 Feb 2016 14:51:19 +0000 Message-ID: References: <569DF8F7.2000703@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.244] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <99EA13D478F5A64E94393E2C447F5545@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 14:51:23 -0000 Folks, I=B9m supporting this document. It does provide a right etree solution for EVPN. Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com Think before you print.This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here=20 for Company Registration Information. >> >>On 1/19/16, 12:51 AM, "BESS on behalf of thomas.morin@orange.com" >> wrote: >> >>>Hello Working Group, >>> >>>This email starts a Working Group Last Call on >>>draft-ietf-bess-evpn-etree [1] which is considered mature and ready for >>>a final working group review. >>> >>>Please read the document if you haven't read the most recent version yet >>>(-03), and send your comments to the list, no later than *February the >>>2nd* (2016-02-02). >>> >>>This is not only a call for comments on the document, but also a call of >>>support for its publication. >>> >>>*Coincidentally*, we are also polling for knowledge of any IPR that >>>applies to draft-ietf-bess-evpn-etree, to ensure that IPR has been >>>disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >>>and 5378 for more details). >>> >>>*If* you are listed as a document author or contributor of >>>draft-ietf-bess-evpn-etree please respond to this email and indicate >>>whether or not you are aware of any relevant IPR. >>> >>>Thank you, >>> >>>Thomas/Martin >>> >>>[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree >>> >>>_______________________________________________ >>>BESS mailing list >>>BESS@ietf.org >>>https://www.ietf.org/mailman/listinfo/bess >> >>_______________________________________________ >>BESS mailing list >>BESS@ietf.org >>https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Mon Feb 1 07:33:06 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5987D1ACEA7 for ; Mon, 1 Feb 2016 07:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 KCH11qkBLZ7l for ; Mon, 1 Feb 2016 07:33:03 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292E51ACEA5 for ; Mon, 1 Feb 2016 07:33:02 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-21-56af779eb88a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id B1.67.06940.E977FA65; Mon, 1 Feb 2016 16:19:58 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Mon, 1 Feb 2016 10:33:01 -0500 From: Jeff Tantsura To: Thomas Morin , BESS , "draft-ietf-bess-evpn-etree@tools.ietf.org" Thread-Topic: [bess] WG Last Call on draft-ietf-bess-evpn-etree Thread-Index: AQHRUpaNZ428WsTHsEu6hEYngcRlrp8XyxCA Date: Mon, 1 Feb 2016 15:33:00 +0000 Message-ID: <2C30F6B5-290D-478B-A4A5-2640443B3771@ericsson.com> References: <569DF8F7.2000703@orange.com> In-Reply-To: <569DF8F7.2000703@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-ID: <7B702D79D6ED4A42BC301DE0CFE068E9@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyuXRPoO688vVhBvsPKlusOD6T2WJy/2MW iw37jrI5MHssWfKTyaPl2Uk2jy+XP7MFMEdx2aSk5mSWpRbp2yVwZfRefslS8Iiv4v4DjQbG DXxdjJwcEgImEhO73zBD2GISF+6tZ+ti5OIQEjjCKDH3XjsrSEJIYBmjxO5eXhCbTcBA4v+3 4ywgRSICcxklvl16xA6SEBawk3hx/BkbiC0iYC/x4f5ZRgjbSOLEyn6wQSwCKhLne++DbeMF qlnUfokdYoGmxKFvE8FqOAW0JG5t2gU2hxHoou+n1jCB2MwC4hK3nsxngrhUQGLJnvNQV4tK vHz8D6xXVEBX4uP1fewQcSWJOa+vAdVwAPVqSqzfpQ8xxlpi7h+IE5gFFCWmdD9khzhHUOLk zCcsExjFZyHZNguhexaS7llIumch6V7AyLqKkaO0uCAnN93IYBMjMMqOSbDp7mC8P93zEKMA B6MSD++GyHVhQqyJZcWVuYcYJTiYlUR4K9LXhwnxpiRWVqUW5ccXleakFh9ilOZgURLnXeoA lBJITyxJzU5NLUgtgskycXBKNTC61Hzn/3GhfNffjTvV/oey/PqfJNZwwzvS7rDIp12P2ltZ XXfvkdTo3G4+TezLj+pg8+NXXv2dKqh8JGKNNf9K7fyliz5UFv0Nd/RUsp6rFbak5hT/20Of CmYFTZgiuFNm2aE13f3PeiZpfHbZYhjmxnvy0qas0kANxcsWp746ah+dY2VvHCypxFKckWio xVxUnAgABJeeH64CAAA= Archived-At: Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:33:05 -0000 SGksDQoNClN1cHBvcnQsIHZlcnkgbXVjaCBuZWVkZWQgdG8gY29tcGxldGUgZGVmaW5pdGlvbiBv ZiBNRUYgc2VydmljZXMgb3ZlciBFVlBOLg0KDQpDaGVlcnMsDQpKZWZmDQoNCg0KDQoNCg0KDQoN Ck9uIDEvMTkvMTYsIDA5OjUxLCAiQkVTUyBvbiBiZWhhbGYgb2YgVGhvbWFzIE1vcmluIiA8YmVz cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4g d3JvdGU6DQoNCj5IZWxsbyBXb3JraW5nIEdyb3VwLA0KPg0KPlRoaXMgZW1haWwgc3RhcnRzIGEg V29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gDQo+ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUg WzFdIHdoaWNoIGlzIGNvbnNpZGVyZWQgbWF0dXJlIGFuZCByZWFkeSBmb3IgDQo+YSBmaW5hbCB3 b3JraW5nIGdyb3VwIHJldmlldy4NCj4NCj5QbGVhc2UgcmVhZCB0aGUgZG9jdW1lbnQgaWYgeW91 IGhhdmVuJ3QgcmVhZCB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiB5ZXQgDQo+KC0wMyksIGFuZCBz ZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QsIG5vIGxhdGVyIHRoYW4gKkZlYnJ1YXJ5IHRo ZSANCj4ybmQqICgyMDE2LTAyLTAyKS4NCj4NCj5UaGlzIGlzIG5vdCBvbmx5IGEgY2FsbCBmb3Ig Y29tbWVudHMgb24gdGhlIGRvY3VtZW50LCBidXQgYWxzbyBhIGNhbGwgb2YgDQo+c3VwcG9ydCBm b3IgaXRzIHB1YmxpY2F0aW9uLg0KPg0KPipDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNvIHBv bGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgDQo+YXBwbGllcyB0byBkcmFmdC1p ZXRmLWJlc3MtZXZwbi1ldHJlZSwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIA0KPmRpc2Ns b3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4 NzksIDM2NjkgDQo+YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo+DQo+KklmKiB5b3UgYXJl IGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBvZiANCj5kcmFmdC1p ZXRmLWJlc3MtZXZwbi1ldHJlZSBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBpbmRp Y2F0ZSANCj53aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIu DQo+DQo+VGhhbmsgeW91LA0KPg0KPlRob21hcy9NYXJ0aW4NCj4NCj5bMV0gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUNCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkJFU1MgbWFpbGlu ZyBsaXN0DQo+QkVTU0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYmVzcw0K From nobody Mon Feb 1 07:47:58 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D051ACEF1 for ; Mon, 1 Feb 2016 07:47:56 -0800 (PST) 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 Jn7HQE948UbT for ; Mon, 1 Feb 2016 07:47:54 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031F41ACEF4 for ; Mon, 1 Feb 2016 07:47:53 -0800 (PST) Received: from BY1PR0501MB1240.namprd05.prod.outlook.com (10.160.200.139) by BL2PR05MB929.namprd05.prod.outlook.com (10.242.198.14) with Microsoft SMTP Server (TLS) id 15.1.396.15; Mon, 1 Feb 2016 15:47:50 +0000 Received: from BY1PR0501MB1240.namprd05.prod.outlook.com ([10.160.200.139]) by BY1PR0501MB1240.namprd05.prod.outlook.com ([10.160.200.139]) with mapi id 15.01.0396.020; Mon, 1 Feb 2016 15:47:50 +0000 From: Wen Lin To: Ravi Shekhar , Aldrin Isaac Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Thread-Index: AQHRXQfn+H1Fv5rK00mHMpMVvM4lHw== Date: Mon, 1 Feb 2016 15:47:50 +0000 Message-ID: References: <56A72A83.10906@orange.com> <7d90f2e0-f400-46ab-a01b-2755f1687435@email.android.com> In-Reply-To: <7d90f2e0-f400-46ab-a01b-2755f1687435@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BL2PR05MB929; 5:BhoKtLt40WkF2mIP/EMUj6FU7gCKU8G8Qyel3FZJ5s+aN30yZjTo20Ip/lwYFF4/xhxAp3fR3uzzDD4LY3g9FRtSr8Z4uFwtl80OrqheUyps33az+9o7EEUwjjFqDSLxPoNFYpcbnqSR7BMHGEC9SQ==; 24:qBJBcedkkiwOnWoJe1+BRQAAOrnVdcXCy0QgJeEmCnzE6yArtoDJZbG8AB60Yau3HvmRI0cyJBELNVQI0zHqvyE8VLSkHIXHV3W/7uRUCK4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB929; x-ms-office365-filtering-correlation-id: 64202ca7-5a81-4e9d-2666-08d32b1f0a5c x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BL2PR05MB929; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB929; x-forefront-prvs: 0839D067E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(10400500002)(106116001)(5004730100002)(36756003)(99286002)(19617315012)(19580405001)(19580395003)(2950100001)(2900100001)(83506001)(77096005)(15975445007)(86362001)(5001770100001)(3660700001)(40100003)(50986999)(189998001)(76176999)(5001960100002)(87936001)(2906002)(54356999)(4326007)(4001350100001)(3470700001)(3280700002)(66066001)(5002640100001)(230783001)(5008740100001)(586003)(3846002)(102836003)(1220700001)(1096002)(11100500001)(122556002)(92566002)(16236675004)(6055255003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB929; H:BY1PR0501MB1240.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D2D4E5737288Dwlinjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2016 15:47:50.5913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB929 Archived-At: Cc: "EXT - thomas.morin@orange.com" , "bess@ietf.org" , "draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:47:56 -0000 --_000_D2D4E5737288Dwlinjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as a co-author. Not aware of any IPR. This solution provides effi= cient multicast delivery if multicast support in the underlay cannot be use= d or is undesirable. Wen From: BESS > on behalf = of Ravi Shekhar > Date: Sunday, January 31, 2016 at 12:30 PM To: Aldrin Isaac > Cc: "EXT - thomas.morin@orange.com" >, "bess@ietf.org" >, "draft-rabadan-bess-e= vpn-optimized-ir@tools.ietf.org" > Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir= -02 Support as co-author. A solution without percolating multicast forwarding s= tate on every device in the core or edge is very desirable. Not aware of an= y IPR. - Ravi Shekhar. On Jan 31, 2016 8:48 AM, Aldrin Isaac > wrote: Support as co-author. IETF should adopt this use-case -- optimized multi-de= stination forwarding for overlays where multicast support is not available = in the underlay. I am not aware of any related IPR. On Tue, Jan 26, 2016 at 12:12 AM Thomas Morin > wrote: Hello working group, This email starts a two-week poll on adopting draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons). This poll runs until **February 9th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). =3D=3D> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you 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. Thank you, Martin & Thomas bess chairs [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess --_000_D2D4E5737288Dwlinjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <296D07A9853F0C499AB082D5FD75E233@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Support as a co-author.  Not aware of any IPR.  This solutio= n provides efficient multicast delivery if multicast support in the underla= y cannot be used or is undesirable.
 
Wen

From: BESS <bess-bounces@ietf.org> on behalf of Ravi Shekha= r <rshekhar@juniper.net><= br> Date: Sunday, January 31, 2016 at 1= 2:30 PM
To: Aldrin Isaac <aldrin.isaac@gmail.com>
Cc: "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, "bess@ietf.org" <bess@ietf.o= rg>, "draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org" <draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org>
Subject: Re: [bess] Poll for adopti= on: draft-rabadan-bess-evpn-optimized-ir-02

Support as co-author. A solution without percolating multica= st forwarding state on every device in the core or edge is very desirable. = Not aware of any IPR.

- Ravi Shekhar.

On Jan 31, 2016 8:48 AM, Aldrin Isaac <aldrin.isaac@gmail.com> wrote:
Support as co-author. IETF should adopt= this use-case -- optimized multi-destination forwarding for overlays where= multicast support is not available in the underlay. I am not aware of any = related IPR.

On Tue, Jan 26, 2016 at 12:12 AM Thomas Morin <thomas.morin@orange.com> wrote:<= br>
Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until **February 9th**.


*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

=3D=3D> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any
relevant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you 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.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02













_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
 --_000_D2D4E5737288Dwlinjunipernet_-- From mkatiyar@juniper.net Mon Feb 1 10:40:29 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF66B1B3418 for ; Mon, 1 Feb 2016 10:40:29 -0800 (PST) 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, 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 RtWrm3uRFZRN for ; Mon, 1 Feb 2016 10:40:27 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575651B33D8 for ; Mon, 1 Feb 2016 10:40:26 -0800 (PST) Received: from CY1PR0501MB1740.namprd05.prod.outlook.com (10.163.140.22) by CY1PR0501MB1740.namprd05.prod.outlook.com (10.163.140.22) with Microsoft SMTP Server (TLS) id 15.1.396.15; Mon, 1 Feb 2016 18:40:10 +0000 Received: from CY1PR0501MB1740.namprd05.prod.outlook.com ([10.163.140.22]) by CY1PR0501MB1740.namprd05.prod.outlook.com ([10.163.140.22]) with mapi id 15.01.0396.020; Mon, 1 Feb 2016 18:40:10 +0000 From: Mukul Katiyar To: "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Thread-Index: AQHRXR/66Z8hiy4690m2756fNOEosg== Date: Mon, 1 Feb 2016 18:40:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1740; 5:/kxsPF5T9ZdviIfSLt8WcXu7TFTWELLqsPsd0AGW8wj6b3GHjFr/Km314CuEefWGdyyZyLSJ8nhbu4Yk8Y+DpaVU4uKtk5wwRdLxOiB8JHedMVw+wHYZ0tHPJzHQGsE7EW3t1tTaAW/+RViaYb19jg==; 24:l+tmz6DBIXySql6aoXA6rvR1i/kcDogc22e119knMb4c2K9ZDSXtnvuOGxBp420fogtIBVeZVMzRB4+fMN8FWq5ejZ2vfOqKDQBaClPdpMA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1740; x-ms-office365-filtering-correlation-id: d2695714-c043-4446-852b-08d32b371d23 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1740; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1740; x-forefront-prvs: 0839D067E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(102836003)(54356999)(3846002)(6116002)(586003)(50986999)(561944003)(5008740100001)(10400500002)(86362001)(66066001)(40100003)(11100500001)(92566002)(5001960100002)(99286002)(122556002)(19580395003)(19580405001)(5002640100001)(16236675004)(83506001)(4326007)(87936001)(2900100001)(3280700002)(3470700001)(106116001)(1730700002)(1220700001)(5004730100002)(230783001)(36756003)(4001350100001)(2906002)(3660700001)(77096005)(110136002)(2351001)(15975445007)(189998001)(2501003)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1740; H:CY1PR0501MB1740.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D2D4E61432A96mkatiyarjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2016 18:40:10.0028 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1740 Archived-At: Cc: "Rabadan, Jorge \(Nokia - US\)" , Mukul Katiyar Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:13:54 -0000 --_000_D2D4E61432A96mkatiyarjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello BESS Working group, I support this proposal as a co-author and am unaware of any IPR. It provi= des efficient multicast replication and delivery. Thanks & Regards Mukul Katiyar Juniper Networks mkatiyar@juniper.net -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin Sent: Tuesday, January 26, 2016 12:13 AM To: bess@ietf.org Cc: draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org Subject: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Hello working group, This email starts a two-week poll on adopting draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. Please send comments to the list and state if you support adoption or not (= in the later case, please also state the reasons). This poll runs until **February 9th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies= to this draft, to ensure that IPR has been disclosed in compliance with IE= TF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). =3D=3D> *If* you are listed as a document author or contributor please resp= ond to this email and indicate whether or not you are aware of any relevant= IPR. The draft will not be adopted until a response has been received from each = author and contributor. If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in = conformance with IETF rules. Thank you, Martin & Thomas bess chairs [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 --_000_D2D4E61432A96mkatiyarjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <669B65578087554C9BE9F0A0BC150F2A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable 
Hello BESS=
 Working group,

I support this proposal as a=
 co-author and am unaware of any IPR.  It provides efficient multicast repl=
ication and delivery.

Thanks & Regards
Mukul Katiyar

Juniper Networks
mkatiyar@juniper.net

-----Original Message-----
From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin
Sent: Tuesday, January 26, 2016 12:13 AM
To: bess@ietf.org
Cc: draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org
Subject: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02

Hello working group,

This email starts a two-week poll on adopting
draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item.

Please send comments to the list and state if you support adoption or not (=
in the later case, please also state the reasons).

This poll runs until **February 9th**.


*Coincidentally*, we are also polling for knowledge of any IPR that applies=
 to this draft, to ensure that IPR has been disclosed in compliance with IE=
TF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

=3D=3D> *If* you are listed as a document author or contributor please r=
espond to this email and indicate whether or not you are aware of any relev=
ant IPR.

The draft will not be adopted until a response has been received from each =
author and contributor.

If you are not listed as an author or contributor, then please explicitly r=
espond only if you are aware of any IPR that has not yet been disclosed in =
conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02
--_000_D2D4E61432A96mkatiyarjunipernet_-- From nobody Mon Feb 1 14:41:53 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38741B380C for ; Mon, 1 Feb 2016 14:41:51 -0800 (PST) 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, 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 LV0j5KYS1pr1 for ; Mon, 1 Feb 2016 14:41:46 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B231B3808 for ; Mon, 1 Feb 2016 14:41:45 -0800 (PST) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1714.namprd05.prod.outlook.com (10.163.120.17) with Microsoft SMTP Server (TLS) id 15.1.396.15; Mon, 1 Feb 2016 22:41:26 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0396.020; Mon, 1 Feb 2016 22:41:26 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Ali Sajassi (sajassi)" , "EXT - thomas.morin@orange.com" , BESS , "draft-ietf-bess-evpn-etree@tools.ietf.org" Thread-Topic: [bess] WG Last Call on draft-ietf-bess-evpn-etree Thread-Index: AQHRUpaMVQrN89Df00yEa17B4G+tKZ8OWnfAgAh9sgCAAQPKYA== Date: Mon, 1 Feb 2016 22:41:26 +0000 Message-ID: References: <569DF8F7.2000703@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1714; 5:8TuNiqQ37v8JA4OsV1cMCO4QHzgKBchKIcG8CvGybhIDCxHTp5wZcXPaDRbs5Zk9eNh3K1qj8aVLA3AEAyXJf95T7Puj4xTXXV68O4g3DI6/b6lUXWbEGMFin1WNX2FCux5sEqA3lBXxI1RGgeiPwQ==; 24:z9LgWWh3Zz2nXeDxfUQIqHpiFXNESaobJ54UOBYLBiF7/oCntzpzmx2k/BB3bl5Frrg56eNTyw0fWgulKgZgv6X51YWzyn/YvxCzKglsfBA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-ms-office365-filtering-correlation-id: f88d31a2-2e8b-49a9-f9b4-08d32b58d1ca x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 0839D067E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51914003)(13464003)(377424004)(479174004)(377454003)(10400500002)(5001960100002)(5001770100001)(40100003)(107886002)(122556002)(2501003)(99286002)(3280700002)(106116001)(5008740100001)(66066001)(74316001)(15975445007)(77096005)(586003)(3846002)(2950100001)(102836003)(6116002)(230783001)(1096002)(11100500001)(2900100001)(1220700001)(2906002)(50986999)(76576001)(19580395003)(54356999)(87936001)(19580405001)(76176999)(86362001)(5002640100001)(92566002)(189998001)(3660700001)(33656002)(5003600100002)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2016 22:41:26.4822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1714 Archived-At: Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 22:41:51 -0000 Ali, One more question about PBB-EVPN. For the regular EVPN, section 3.3.2 talks about a situation where the only = traffic is BUM. There is no need for mac learning in that situation. For PBB-EVPN, I assume this is also possible. With this, there is no need t= o advertise per-ES B-mac addresses - a single pair of global root/leaf B-ma= c addresses are enough. Perhaps this can be mentioned for parity/completeness. Of course, this is n= ot a big deal and either way it's fine - but I do want to ask to confirm my= understanding. Jeffrey > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Monday, February 01, 2016 2:04 AM > To: Jeffrey (Zhaohui) Zhang ; EXT - > thomas.morin@orange.com ; BESS ; > draft-ietf-bess-evpn-etree@tools.ietf.org > Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree >=20 > Hi Jeffrey, >=20 > Thanks for the review. Your comments helps tighten the draft some more. I > have updated the draft and will publish it next (rev04). Majority of the > comments were editorial in nature for better clarifications. Since the > existing draft (rev03) reflects the consensus regarding our several round= s > of discussions where we have taken care of the technical items, it is > consistent with our expectation of not seeing any major issue during the > LC. Please refer to my replies in line. >=20 > Cheers, > Ali >=20 >=20 > On 1/27/16, 5:26 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" > wrote: >=20 > >I was involved in relevant discussions, and have reviewed once more for > >this LC. > > > >I support the publication, but with the following questions/comments. > > > >2.1 Scenario 1: Leaf OR Root site(s) per PE > > > > ... If the number of EVIs is very large > > (e.g., more than 32K or 64K), then RT type 0 as defined in [RFC4360] > > SHOULD be used; otherwise, RT type 2 is sufficient. > > > >RFC 7153 should be referenced for "Type 2". >=20 >=20 > Done. >=20 > > > >Additionally, why is 32K mentioned? I can understand the 64k part. >=20 > Removed 32K since the example is clear enough with 64K >=20 > > > > ... the MPLS-encapsulated frames MUST be tagged with an > > indication of whether they originated from a Leaf AC or not. > > > >Perhaps change the last line to "indication if they originated from a > >Leaf AC"? Packets from a root AC are not tagged with a leaf indication. >=20 > OK. Better yet. It should say =B3indication when they originated from a l= eaf > AC=B2. >=20 > > > > Other mechanisms for identifying whether an egress AC is a root or > > leaf is beyond the scope of this document. > > > >Should "egress" be "ingress" in the above paragraph? Or simply removed? >=20 > Nice catch! It is =B3ingress=B2. It is now corrected. >=20 > > > > ... This Leaf MPLS label is advertised to other PE devices, > > using a new EVPN Extended Community called E-TREE Extended Community > > (section 5.1) along with an Ethernet A-D per ES route with ESI of > > zero and a set of Route Targets (RTs) corresponding to all the leaf > > ACs on the PE. > > > >Perhaps change the last sentence to "... corresponding to all EVIs that > >have leaf sites on the PE." >=20 > The second to last sentence of section 3.2.1 says the same thing. I > changed this sentence and removed the 2nd to last sentence. >=20 > > > >3.2.3 BUM traffic originated from a multi-homed site on a leaf AC > > > > In this scenario, it is assumed that a multi-homed Ethernet Segment > > (ES) can have a mixed of both leaf and root ACs with each AC > > designating a subnet (e.g., a VLAN). > > > >I understand that different VLANs on the same ES could be roots or > >leaves. I suppose it's more important to say that for the same vlan, > >different PEs on the same ES must have the same root/leaf designation. >=20 > That=B9s given. >=20 > > > >Perhaps the first sentence could be reworded as the following to capture > >the above point: > > > > While different ACs (VLANs) on the same ES could have different > > root/leaf designation (some being roots and some being leaves), > > the same VLAN does have the same root/leaf designation on all > > PEs on the same ES. >=20 > That=B9s fine. It makes it more clear. >=20 > > > >For the following: > > > > ... the PEs with Leaf sites perform MAC learning in the > > data-path over their Ethernet Segments, and advertise reachability in > > EVPN MAC Advertisement routes which are imported only by PEs with at > > least one Root site in the EVI. A PE with only Leaf sites will not > > import these routes. PEs with Root and/or Leaf sites may use the > > Ethernet A-D routes for aliasing (in the case of multi-homed > > segments) and for mass MAC withdrawal per [RFC 7432]. > > > >The above seems to contradict with the recommendation in Section 2.2. If > >the context is the scenario described in section 2.1 then that's fine, > >but the text does not have a clear context. >=20 > Agreed. Updated the section to indicate the context is section 2.1. >=20 > > > > > >3.3.2 E-Tree without MAC Learning > > > > The PEs implementing an E-Tree service need not perform MAC learning > > when the traffic flows between Root and Leaf sites are multicast or > > broadcast. > > > >I suppose an "only" word should be added at the end of the above sentenc= e. >=20 > Agreed. >=20 > > > > > > The fields of the IMET route are populated per the procedures defined > > in [RFC7432], and the route import rules are as described in previous > > sections. > > > >The route import rules described in previous sections are for MAC routes= , > >not IMET routes. Additionally, those rules may not be recommended, so > >might as well delete the last sentence. >=20 > Changed the last sentence to =B3=D0, and the multicast tunnel setup crite= ria > are as described in the previous section.=B2 >=20 > > > >Section 3.3.1 talks about BUM procedures. That is not specific to 3.3.1 > >though. Perhaps extract that out to a separate section, and remove the > >BUM text from 3.3.2 as well. >=20 > I think it is OK. >=20 > > > > The E-TREE Extended Community is encoded as an 8-octet value as > > follows: > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type=3D0x06 | Sub-Type=3D0x04 | Flags(1 Octet)| = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reserved=3D0 | Leaf Label = | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >I assume the octect after the flags octet is also reserved=3D0. Better m= ark > >it as "Reserved=3D0". >=20 > Agreed. >=20 > > > >When it is used with Ethernet A-D per ES route, the leaf flag SHOULD be > >set to 0 but ignored by the receiving routers. Therefore, why not set it > >to 1 to be consistent the MAC/IP route case? >=20 > Because the flag is used for known unicast traffic and Leaf label for BUM > traffic. We don=B9t want to mix the two. >=20 > Cheers, > Ali >=20 > > > >Thanks. > >Jeffrey > > > >> -----Original Message----- > >> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin > >> Sent: Tuesday, January 19, 2016 3:51 AM > >> To: BESS ; draft-ietf-bess-evpn-etree@tools.ietf.org > >> Subject: [bess] WG Last Call on draft-ietf-bess-evpn-etree > >> > >> Hello Working Group, > >> > >> This email starts a Working Group Last Call on > >> draft-ietf-bess-evpn-etree [1] which is considered mature and ready fo= r > >> a final working group review. > >> > >> Please read the document if you haven't read the most recent version > yet > >> (-03), and send your comments to the list, no later than *February the > >> 2nd* (2016-02-02). > >> > >> This is not only a call for comments on the document, but also a call > of > >> support for its publication. > >> > >> *Coincidentally*, we are also polling for knowledge of any IPR that > >> applies to draft-ietf-bess-evpn-etree, to ensure that IPR has been > >> disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > >> and 5378 for more details). > >> > >> *If* you are listed as a document author or contributor of > >> draft-ietf-bess-evpn-etree please respond to this email and indicate > >> whether or not you are aware of any relevant IPR. > >> > >> Thank you, > >> > >> Thomas/Martin > >> > >> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree > >> > >> _______________________________________________ > >> BESS mailing list > >> BESS@ietf.org > >> https://www.ietf.org/mailman/listinfo/bess > > > >_______________________________________________ > >BESS mailing list > >BESS@ietf.org > >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Feb 2 07:40:45 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5231B2C51; Tue, 2 Feb 2016 07:40:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202154042.19833.28943.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 07:40:42 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-pta-flags-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 15:40:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services Working Group of the IETF. Title : Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags Authors : Eric C. Rosen Thomas Morin Filename : draft-ietf-bess-pta-flags-02.txt Pages : 5 Date : 2016-02-02 Abstract: The BGP-based control procedures for Multicast Virtual Private Networks make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the Flags field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the PMSI Tunnel attribute. This document updates RFC 6514. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-pta-flags-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-pta-flags-02 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 Tue Feb 2 19:39:36 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8991B32E6 for ; Tue, 2 Feb 2016 19:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 6EEFfWjZdRRu for ; Tue, 2 Feb 2016 19:39:25 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7A81B32D0 for ; Tue, 2 Feb 2016 19:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1553; q=dns/txt; s=iport; t=1454470760; x=1455680360; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KsmrDrAzlTju2dzr/AVFDxalTsY00k3pH4/h9FD8P+s=; b=cZzcd0LJTHgAem6hQO1wyFHMrnkVLEzIW3+gbwxCkoW+JdO1uBdedoS/ p5mzkhotFT0RMBMLwjuXkwGBgaq8RA+E21ddI3SZwk8pN7dGdLnoH9aq3 oTBZbncK3eMhJCgzSXd8vC/A0XZyTyru6zE58+DWB2usjaT/G9K27U9ix I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQDWdbFW/5pdJa1egzpSbQaIU7FrA?= =?us-ascii?q?Q2BZBcKhWwCgUE4FAEBAQEBAQGBCoRCAQEEAQEBNzQLEAIBCDYQJwslAgQBDQW?= =?us-ascii?q?IGw6/OwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEikaEAhEBhFgBBJZxAYVGiASBW?= =?us-ascii?q?4RCiFSOPgEeAQFCg2RqiDs0fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,388,1449532800"; d="scan'208";a="73064531" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2016 03:39:20 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u133dJGY004401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Feb 2016 03:39:20 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 2 Feb 2016 22:39:19 -0500 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Tue, 2 Feb 2016 22:39:19 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Thread-Index: AQHRWBFg8os23LZLbEi+Ot5ZNsBZW58ZhnqA Date: Wed, 3 Feb 2016 03:39:19 +0000 Message-ID: References: <56A72A83.10906@orange.com> In-Reply-To: <56A72A83.10906@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <00492E51B0297A43B6927FA01B632BA3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 03:39:30 -0000 As a co-author, I support adoption of this draft and I am not aware of any IPR regarding this draft. -Ali On 1/26/16, 12:12 AM, "BESS on behalf of Thomas Morin" wrote: >Hello working group, > >This email starts a two-week poll on adopting >draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. > >Please send comments to the list and state if you support adoption or >not (in the later case, please also state the reasons). > >This poll runs until **February 9th**. > > >*Coincidentally*, we are also polling for knowledge of any IPR that >applies to this draft, to ensure that IPR has been disclosed in >compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >and 5378 for more details). > >=3D=3D> *If* you are listed as a document author or contributor please >respond to this email and indicate whether or not you are aware of any >relevant IPR. > >The draft will not be adopted until a response has been received from >each author and contributor. > >If you 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. > >Thank you, > >Martin & Thomas >bess chairs > >[1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 > > > > > > > > > > > > > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Wed Feb 3 06:55:50 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC41ACDC3 for ; Wed, 3 Feb 2016 06:55:49 -0800 (PST) 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 IivF0s-KqN36 for ; Wed, 3 Feb 2016 06:55:47 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216FB1ACDC7 for ; Wed, 3 Feb 2016 06:55:47 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id xg9so3255644igb.1 for ; Wed, 03 Feb 2016 06:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=P4Yv6cS0wiYou85EM4AWqzjzecCNp+D2N1b2D/015gA=; b=n07LLBTYZw+pLl9YjxWNC1VYiywiaazkdzOeCArqOu75OBCrGgBlSstPBRM/1MOiUs vvetfhqViHnZSSY4fTjB4UPRkeVOuGHesq2izi7Dmam0oDq2pZf9/MTW4yIuCX2EcWvw A6JcPhzFXEVOgCiQ7hL3NTf1jurZemv1YXxZeokA68jzUcQz4W+0grYqdHv2BfT/JsLb iZeg3Veoatr/ViKQr/HXG1tsuVZ2yxjme/LWkJzUJhGIzO/4SEYAEOi7Xue0sWyY+nyY AlJe/EyK3a4IkHBQjThizz20R8cLLrWk8tJS1MzfJIpBzjpz9UjQdtuGVj56gfURQoAi 8Bbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=P4Yv6cS0wiYou85EM4AWqzjzecCNp+D2N1b2D/015gA=; b=Ar5c409Fa+4GcUAPU7Cw56HUHpuf/yyYlZU1aJFWmeXJAVGtKR49Lw28eu+X48ye8V Ts+GPgaA0RDmQ6k0bMkaCGDbfe4zgtaRXOP2eZ4s1dPnTolQhuDTrJUxhe6zEDY1Uw+c 1YftfVXTTZl8kSC6f3gB49P9XNO6uSzenTf2/A2y5KhDRe6bmPiQZ9TGJfyEM5NQRCW2 3UWOVXykxBFPdEUkyReWwHvxFLoB9P0RzuuvSf3PIVTS6mhhK0Xs6g/4q1q4P194eB9N nJgzbGqRXPmdzVpAZYRb75HniwTMgEsii5a7uoYGUTDKYbS/R72uhO6AkQ+PxJEIJkaf cQ3g== X-Gm-Message-State: AG10YOToYFBPdCF9ssdgwyIKjhsqpABTbuMd1ucjJYrGdVveuZXgu6X0wwymjhzUlY4QeXr4rq0s/l8AZUAJZQ== X-Received: by 10.50.61.177 with SMTP id q17mr3901164igr.68.1454511346520; Wed, 03 Feb 2016 06:55:46 -0800 (PST) MIME-Version: 1.0 References: <569DF8F7.2000703@orange.com> In-Reply-To: <569DF8F7.2000703@orange.com> From: Aldrin Isaac Date: Wed, 03 Feb 2016 14:55:36 +0000 Message-ID: To: BESS , Thomas Morin , draft-ietf-bess-evpn-etree@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7bdca440219c16052aded0e3 Archived-At: Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 14:55:49 -0000 --047d7bdca440219c16052aded0e3 Content-Type: text/plain; charset=UTF-8 I support as co-author. Not aware of any related IPR. Cheers, Aldrin On Tue, Jan 19, 2016 at 12:51 AM Thomas Morin wrote: > Hello Working Group, > > This email starts a Working Group Last Call on > draft-ietf-bess-evpn-etree [1] which is considered mature and ready for > a final working group review. > > Please read the document if you haven't read the most recent version yet > (-03), and send your comments to the list, no later than *February the > 2nd* (2016-02-02). > > This is not only a call for comments on the document, but also a call of > support for its publication. > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to draft-ietf-bess-evpn-etree, to ensure that IPR has been > disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > *If* you are listed as a document author or contributor of > draft-ietf-bess-evpn-etree please respond to this email and indicate > whether or not you are aware of any relevant IPR. > > Thank you, > > Thomas/Martin > > [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --047d7bdca440219c16052aded0e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support as co-author. Not aware of a= ny related IPR.
Cheers,
Aldrin

<= div dir=3D"ltr">On Tue, Jan 19, 2016 at 12:51 AM Thomas Morin <thomas.morin@orange.com> wrote:<= br>
Hello Working Group,

This email starts a Working Group Last Call on
draft-ietf-bess-evpn-etree [1] which is considered mature and ready for
a final working group review.

Please read the document if you haven't read the most recent version ye= t
(-03), and send your comments to the list, no later than *February the
2nd* (2016-02-02).

This is not only a call for comments on the document, but also a call of support for its publication.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to draft-ietf-bess-evpn-etree, to ensure that IPR has been
disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

*If* you are listed as a document author or contributor of
draft-ietf-bess-evpn-etree please respond to this email and indicate
whether or not you are aware of any relevant IPR.

Thank you,

Thomas/Martin

[1] https://datatracker.ietf.org/doc/draf= t-ietf-bess-evpn-etree

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--047d7bdca440219c16052aded0e3-- From nobody Fri Feb 5 08:57:03 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF42D1B3B93; Fri, 5 Feb 2016 08:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 NK86a5E2FWVF; Fri, 5 Feb 2016 08:56:56 -0800 (PST) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696411B3B8D; Fri, 5 Feb 2016 08:56:53 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id AB33A2032F; Fri, 5 Feb 2016 17:56:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 7FFE11A0054; Fri, 5 Feb 2016 17:56:51 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0279.002; Fri, 5 Feb 2016 17:56:51 +0100 From: To: "bess@ietf.org" Thread-Topic: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AdFgNjTaXB7JK7ocQLKDXemsWvLl+Q== Date: Fri, 5 Feb 2016 16:56:50 +0000 Message-ID: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_m7cqvm0qi93kq9u3ubuc15pr1454691102503emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:57:03 -0000 --_000_m7cqvm0qi93kq9u3ubuc15pr1454691102503emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gd29ya2luZyBncm91cCwNCg0KVGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xs IG9uIGFkb3B0aW5nIGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kIFsxXSBhcyBhIHdv cmtpbmcgZ3JvdXAgaXRlbS4NCg0KUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYW5k IHN0YXRlIGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yIG5vdCAoaW4gdGhlIGxhdGVyIGNhc2Us IHBsZWFzZSBhbHNvIHN0YXRlIHRoZSByZWFzb25zKS4NCg0KVGhpcyBwb2xsIHJ1bnMgdW50aWwg KipGZWJydWFyeSAxOXRoKiouDQoNCipDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNvIHBvbGxp bmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCB0 byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJ RVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9y ZSBkZXRhaWxzKS4NCg0KPT0+ICpJZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRo b3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQgaW5kaWNh dGUgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KDQpU aGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJl Y2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG5v dCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNp dGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90 IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRo YW5rIHlvdSwNCg0KTWFydGluICYgVGhvbWFzDQpiZXNzIGNoYWlycw0KDQpbMV0gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kLTAyDQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_m7cqvm0qi93kq9u3ubuc15pr1454691102503emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi PkhlbGxvIHdvcmtpbmcgZ3JvdXAsPC9wPg0KPHAgZGlyPSJsdHIiPlRoaXMgZW1haWwgc3RhcnRz IGEgdHdvLXdlZWsgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFy cC1uZCBbMV0gYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uPC9wPg0KPHAgZGlyPSJsdHIiPlBsZWFz ZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9w dGlvbiBvciBub3QgKGluIHRoZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVh c29ucykuDQo8L3A+DQo8cCBkaXI9Imx0ciI+VGhpcyBwb2xsIHJ1bnMgdW50aWwgKipGZWJydWFy eSAxOXRoKiouPC9wPg0KPHAgZGlyPSJsdHIiPipDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNv IHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy YWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug d2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm b3IgbW9yZSBkZXRhaWxzKS4NCjwvcD4NCjxwIGRpcj0ibHRyIj49PSZndDsgKklmKiB5b3UgYXJl IGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9u ZCB0byB0aGlzIGVtYWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJl IG9mIGFueSByZWxldmFudCBJUFIuPC9wPg0KPHAgZGlyPSJsdHIiPlRoZSBkcmFmdCB3aWxsIG5v dCBiZSBhZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNo IGF1dGhvciBhbmQgY29udHJpYnV0b3IuPC9wPg0KPHAgZGlyPSJsdHIiPklmIHlvdSBhcmUgbm90 IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0 bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3Qg eWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy48L3A+DQo8 cCBkaXI9Imx0ciI+VGhhbmsgeW91LDwvcD4NCjxwIGRpcj0ibHRyIj5NYXJ0aW4gJmFtcDsgVGhv bWFzPGJyPg0KYmVzcyBjaGFpcnM8L3A+DQo8cCBkaXI9Imx0ciI+WzFdIDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0w MiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94 eS1hcnAtbmQtMDI8L2E+PC9wPg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5 Pg0KPC9odG1sPg0K --_000_m7cqvm0qi93kq9u3ubuc15pr1454691102503emailandroidcom_-- From nobody Fri Feb 5 09:07:13 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109B91B3BA9 for ; Fri, 5 Feb 2016 09:07:12 -0800 (PST) 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 okB_y7pVmFb1 for ; Fri, 5 Feb 2016 09:06:58 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CF01B3BA5 for ; Fri, 5 Feb 2016 09:06:58 -0800 (PST) Received: by mail-pa0-x235.google.com with SMTP id yy13so36852123pab.3 for ; Fri, 05 Feb 2016 09:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hWtlsQNQDMH8hp9zqC0NFlKzUsmTRCWHbkqg2OUBAZc=; b=t7jQUnZQQHdx6Dnio6uycCOx7UVpOQ7jOZ7p47V8gILD5u1wK+1G6e5gi7klbt6GJu 3nhsP0vByJhz2aBDo8Mha7h/TiPf3xAXfHdI5HLryZMC2iq8RVKo3MqMTNh5lF3OVcHW IS38VuYfaauV4ODmZUdJgY1Ou4V2uJ47944zVPmuZ7iDrbVVE56G8KEi/AGWVyWM1Ns/ wtKYQsFe3NQTK/6CfaCjY+Zn1K5xnZ38d2ofcKfOZHWsx3w0AA4Nfe3YnD/NhDU09dZU +zXT4F5eX5oBzCvql8loA8LviDrNPJFJXYlUskYKT0DUJbTaHoyT9LcXfknpSW7LMzPR sw1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hWtlsQNQDMH8hp9zqC0NFlKzUsmTRCWHbkqg2OUBAZc=; b=Z9x5Jlhj7Z0Rnyi+PU0sfASJ7XqTeZJouPplDuGivRyo4ToyHhJg4R8qNNWX0Z47nP cM8ItOyqhOM+IffxtzkRqnSXm2GZZSHrtWpVAzdTOMwNyYh8AlCp2dPmbWBdt8hoASKy 2ADxh5jvty8qXnGQrp4H2K3APEQTCbNLkVYLFtirmr7osbrrbnXYG5V0TOOkj6ws4gbE 2sk+g8sfvqiEYepYg6sYeQ92nlagTs13tKUG2rlZJxyG5fulKgYAiHXzzI/BM7ZvNYCM aAnp5o3r+0T6uU/sobVREXFwWtqsJhLhq045Uo2avEBm5383uN4sfd6/BeCZcarxPH0y NiGw== X-Gm-Message-State: AG10YORwqiMSd+FuI4ZzLowfig9lJtuxBCXauG2kPAKEAYkNEZXiEgoz5u6XXkeZTBc/eA== X-Received: by 10.66.160.101 with SMTP id xj5mr21354474pab.153.1454692017674; Fri, 05 Feb 2016 09:06:57 -0800 (PST) Received: from [28.17.106.27] ([172.58.25.209]) by smtp.gmail.com with ESMTPSA id c24sm15413960pfj.41.2016.02.05.09.06.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 09:06:56 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-90788E91-8AB8-4D98-89AB-A179131E7134 Mime-Version: 1.0 (1.0) From: Sami Boutros X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Fri, 5 Feb 2016 09:06:56 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <569DF8F7.2000703@orange.com> To: Aldrin Isaac Archived-At: Cc: Thomas Morin , "draft-ietf-bess-evpn-etree@tools.ietf.org" , BESS Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 17:07:12 -0000 --Apple-Mail-90788E91-8AB8-4D98-89AB-A179131E7134 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Same here and I am not aware of any ipr beyond what was already disclosed Sami Sent from my iPhone > On Feb 3, 2016, at 6:55 AM, Aldrin Isaac wrote: >=20 > I support as co-author. Not aware of any related IPR.=20 > Cheers, > Aldrin >=20 >> On Tue, Jan 19, 2016 at 12:51 AM Thomas Morin w= rote: >> Hello Working Group, >>=20 >> This email starts a Working Group Last Call on >> draft-ietf-bess-evpn-etree [1] which is considered mature and ready for >> a final working group review. >>=20 >> Please read the document if you haven't read the most recent version yet >> (-03), and send your comments to the list, no later than *February the >> 2nd* (2016-02-02). >>=20 >> This is not only a call for comments on the document, but also a call of >> support for its publication. >>=20 >> *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to draft-ietf-bess-evpn-etree, to ensure that IPR has been >> disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >> and 5378 for more details). >>=20 >> *If* you are listed as a document author or contributor of >> draft-ietf-bess-evpn-etree please respond to this email and indicate >> whether or not you are aware of any relevant IPR. >>=20 >> Thank you, >>=20 >> Thomas/Martin >>=20 >> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --Apple-Mail-90788E91-8AB8-4D98-89AB-A179131E7134 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Same here and I am not aware of any ipr beyond what was already disclosed

Sami

Sent from my iPhone

On Feb 3, 2016, at 6:55 AM, Aldrin Isaac <aldrin.isaac@gmail.com> wrote:

I support as co-author. Not aware of any related IPR.
Cheers,
Aldrin

On Tue, Jan 19, 2016 at 12:51 AM Thomas Morin <thomas.morin@orange.com> wrote:
Hello Working Group,

This email starts a Working Group Last Call on
draft-ietf-bess-evpn-etree [1] which is considered mature and ready for
a final working group review.

Please read the document if you haven't read the most recent version yet
(-03), and send your comments to the list, no later than *February the
2nd* (2016-02-02).

This is not only a call for comments on the document, but also a call of
support for its publication.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to draft-ietf-bess-evpn-etree, to ensure that IPR has been
disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

*If* you are listed as a document author or contributor of
draft-ietf-bess-evpn-etree please respond to this email and indicate
whether or not you are aware of any relevant IPR.

Thank you,

Thomas/Martin

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--Apple-Mail-90788E91-8AB8-4D98-89AB-A179131E7134-- From nobody Fri Feb 5 09:59:24 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA1B1A1A70; Fri, 5 Feb 2016 09:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 hCWjEPz9g3re; Fri, 5 Feb 2016 09:59:19 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A711A1A4E; Fri, 5 Feb 2016 09:59:14 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-13-56b4e2dcd54d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 61.DF.32102.CD2E4B65; Fri, 5 Feb 2016 18:58:52 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Fri, 5 Feb 2016 12:59:13 -0500 From: Antoni Przygienda To: "thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AdFgNjTaXB7JK7ocQLKDXemsWvLl+QACJ82Q Date: Fri, 5 Feb 2016 17:59:11 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F180EB9C184@eusaamb103.ericsson.se> References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> 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_2E4BB27CAB87BF43B4207C0E55860F180EB9C184eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyuXRPuO6dR1vCDK7Pl7dYcXwms8XsCUeZ LTbsO8rmwOyxZMlPJo+WZyfZApiiuGxSUnMyy1KL9O0SuDK2TGphLJhXWHFp33XGBsYpeV2M nBwSAiYSty9sZYKwxSQu3FvP1sXIxSEkcIRRYtHvGUwQzjJGiYv9J9lAqtgELCQuf3vKDGKL CERJzGrbwQ5iMwvESjzufwdWIyzgLHFhXysbRI2LxP39KxkhbCOJrtuLWUBsFgEViZ99W1hB bF4BX4l9V5rBbCGBPInFfy6B1XAK5Es83NADNocR6Lrvp9YwQewSl7j1ZD7U1QISS/acZ4aw RSVePv7HCmErSXz8PR/oNg6g+nyJo7PUIVYJSpyc+YRlAqPoLCSTZiFUzUJSBRHWlFi/Sx+i WlFiSvdDdghbQ6J1zlx2ZPEFjOyrGDlKiwtyctONDDcxAmPrmASb4w7Gvb2ehxgFOBiVeHg/ XN8cJsSaWFZcmXuIUYKDWUmEl+vgljAh3pTEyqrUovz4otKc1OJDjNIcLErivHOd14cJCaQn lqRmp6YWpBbBZJk4OKUaGCeZXrmyeWqT+K6SfpnIykLxdb8FfVPk9NRt7rLnpcromPBxllrP K88N632xqkPlR0nh/sKQSwk7+f4c3+M9+e4yXYeinJdr+rtX9aeseZwqc6ps5aOybI43Gpp+ b0ULFT0m902viz6U8vAQ0zONmS0/XrnM/VDCJOV/6P3BPx33BfQfnrViUWIpzkg01GIuKk4E ANT+PFqpAgAA Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 17:59:22 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F180EB9C184eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBnb29kIG9uZSwgKzEsIHdoZW4gbWF0dXJlcyBtYXliZSBldmVuIGEgQkNQIGtpbmQgb2Yg c3RhdHVzID8NCg0KdGhhbmtzDQoNCi0tLSB0b255DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCuKAnFNpbXBsZSwgY2xlYXIgcHVycG9zZSBhbmQgcHJpbmNp cGxlcyBnaXZlIHJpc2UgdG8gY29tcGxleCBhbmQgaW50ZWxsaWdlbnQgYmVoYXZpb3IuIENvbXBs ZXggcnVsZXMgYW5kIHJlZ3VsYXRpb25zIGdpdmUgcmlzZSB0byBzaW1wbGUgYW5kIHN0dXBpZCBi ZWhhdmlvci7igJ0NCi0tLSBEZWUgSG9jaw0KDQpGcm9tOiBCRVNTIFttYWlsdG86YmVzcy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgdGhvbWFzLm1vcmluQG9yYW5nZS5jb20NClNlbnQ6 IEZyaWRheSwgRmVicnVhcnkgMDUsIDIwMTYgODo1NyBBTQ0KVG86IGJlc3NAaWV0Zi5vcmcNCkNj OiBkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZEBpZXRmLm9yZw0KU3ViamVjdDogW2Jl c3NdIENhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0w Mg0KDQoNCkhlbGxvIHdvcmtpbmcgZ3JvdXAsDQoNClRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdl ZWsgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZCBbMV0g YXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uDQoNClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBs aXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvciBub3QgKGluIHRoZSBsYXRl ciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQoNClRoaXMgcG9sbCBydW5z IHVudGlsICoqRmVicnVhcnkgMTl0aCoqLg0KDQoqQ29pbmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxz byBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBk cmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzgg Zm9yIG1vcmUgZGV0YWlscykuDQoNCj09PiAqSWYqIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1l bnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5k IGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ Ui4NCg0KVGhlIGRyYWZ0IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMg YmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCg0KSWYgeW91 IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2Ug ZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg aGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVz Lg0KDQpUaGFuayB5b3UsDQoNCk1hcnRpbiAmIFRob21hcw0KYmVzcyBjaGFpcnMNCg0KWzFdIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1u ZC0wMg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlv dS4NCg== --_000_2E4BB27CAB87BF43B4207C0E55860F180EB9C184eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkVyYXMgRGVtaSBJVEMiOw0K CXBhbm9zZS0xOjIgMTEgOCA1IDMgNSA0IDIgOCA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlll cywgZ29vZCBvbmUsICYjNDM7MSwgd2hlbiBtYXR1cmVzIG1heWJlIGV2ZW4gYSBCQ1Aga2luZCBv ZiBzdGF0dXMgPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRl ci1kaXY7Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAxLjBwdCAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJv cmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPnRoYW5rcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tLS0gdG9ueTwvc3Bhbj48L2I+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7RXJhcyBEZW1pIElU QyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpub25lO3Bh ZGRpbmc6MGluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtFcmFzIERlbWkgSVRDJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v OnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYm9yZGVyOm5v bmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6IzFGNDk3 RCI+4oCcU2ltcGxlLCBjbGVhciBwdXJwb3NlIGFuZCBwcmluY2lwbGVzIGdpdmUgcmlzZSB0byBj b21wbGV4IGFuZCBpbnRlbGxpZ2VudCBiZWhhdmlvci4gQ29tcGxleCBydWxlcyBhbmQgcmVndWxh dGlvbnMgZ2l2ZSByaXNlIHRvIHNpbXBsZSBhbmQgc3R1cGlkIGJlaGF2aW9yLuKAnQ0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpub25l O3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOiMxRjQ5N0Qi Pi0tLQ0KPGI+RGVlIEhvY2s8L2I+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQkVTUyBbbWFpbHRvOmJlc3MtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+dGhvbWFzLm1vcmluQG9yYW5nZS5jb208YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAwNSwgMjAxNiA4OjU3IEFNPGJyPg0KPGI+VG86 PC9iPiBiZXNzQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1zbnItYmVzcy1ldnBuLXBy b3h5LWFycC1uZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbYmVzc10gQ2FsbCBmb3Ig YWRvcHRpb246IGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kLTAyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHA+SGVsbG8gd29ya2luZyBncm91cCw8bzpwPjwvbzpwPjwvcD4NCjxw PlRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1zbnIt YmVzcy1ldnBuLXByb3h5LWFycC1uZCBbMV0gYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uPG86cD48 L286cD48L3A+DQo8cD5QbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCBhbmQgc3RhdGUg aWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3Igbm90IChpbiB0aGUgbGF0ZXIgY2FzZSwgcGxlYXNl IGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KPG86cD48L286cD48L3A+DQo8cD5UaGlzIHBvbGwg cnVucyB1bnRpbCAqKkZlYnJ1YXJ5IDE5dGgqKi48bzpwPjwvbzpwPjwvcD4NCjxwPipDb2luY2lk ZW50YWxseSosIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwg NDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCjxvOnA+PC9vOnA+PC9wPg0K PHA+PT0mZ3Q7ICpJZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29u dHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQgaW5kaWNhdGUgd2hldGhl ciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLjxvOnA+PC9vOnA+PC9w Pg0KPHA+VGhlIGRyYWZ0IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMg YmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci48bzpwPjwvbzpw PjwvcD4NCjxwPklmIHlvdSBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0 b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUg b2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNl IHdpdGggSUVURiBydWxlcy48bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rIHlvdSw8bzpwPjwvbzpw PjwvcD4NCjxwPk1hcnRpbiAmYW1wOyBUaG9tYXM8YnI+DQpiZXNzIGNoYWlyczxvOnA+PC9vOnA+ PC9wPg0KPHA+WzFdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z bnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0wMiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94eS1hcnAtbmQtMDI8L2E+PG86cD48L286cD48L3A+ DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7PG86cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286 cD48L3ByZT4NCjxwcmU+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5r IHlvdS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_2E4BB27CAB87BF43B4207C0E55860F180EB9C184eusaamb103erics_-- From nobody Fri Feb 5 10:01:21 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5BE1A1A4E; Fri, 5 Feb 2016 10:01:20 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 fHAIzRYWNcR2; Fri, 5 Feb 2016 10:01:17 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3261A1A70; Fri, 5 Feb 2016 10:01:16 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 0ACC17587441E; Fri, 5 Feb 2016 18:01:12 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u15I1FYb013481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Feb 2016 18:01:15 GMT 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 u15I1Fkh003861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Feb 2016 19:01:15 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.125]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 5 Feb 2016 19:01:15 +0100 From: "Rabadan, Jorge (Nokia - US)" To: "thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AdFgNjTaXB7JK7ocQLKDXemsWvLl+QACP3UA Date: Fri, 5 Feb 2016 18:01:14 +0000 Message-ID: <3402959E-C619-4079-984D-F539DFB7CC5F@alcatel-lucent.com> References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_3402959EC6194079984DF539DFB7CC5Falcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 18:01:20 -0000 --_000_3402959EC6194079984DF539DFB7CC5Falcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjby1hdXRob3IuDQpOb3QgYXdhcmUgb2YgYW55IElQUi4uDQoNClRoYW5rcy4N CkpvcmdlDQoNCkZyb206ICJ0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86dGhvbWFzLm1v cmluQG9yYW5nZS5jb20+IiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5t b3JpbkBvcmFuZ2UuY29tPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkgNSwgMjAxNiBhdCA1OjU2 IFBNDQpUbzogImJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJlc3NAaWV0Zi5vcmc+IiA8YmVzc0BpZXRm Lm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4+DQpDYzogImRyYWZ0LXNuci1iZXNzLWV2cG4tcHJv eHktYXJwLW5kQGlldGYub3JnPG1haWx0bzpkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1u ZEBpZXRmLm9yZz4iIDxkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZEBpZXRmLm9yZzxt YWlsdG86ZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94eS1hcnAtbmRAaWV0Zi5vcmc+Pg0KU3ViamVj dDogQ2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kLTAy DQoNCg0KSGVsbG8gd29ya2luZyBncm91cCwNCg0KVGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2Vl ayBwb2xsIG9uIGFkb3B0aW5nIGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kIFsxXSBh cyBhIHdvcmtpbmcgZ3JvdXAgaXRlbS4NCg0KUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxp c3QgYW5kIHN0YXRlIGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yIG5vdCAoaW4gdGhlIGxhdGVy IGNhc2UsIHBsZWFzZSBhbHNvIHN0YXRlIHRoZSByZWFzb25zKS4NCg0KVGhpcyBwb2xsIHJ1bnMg dW50aWwgKipGZWJydWFyeSAxOXRoKiouDQoNCipDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNv IHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy YWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug d2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm b3IgbW9yZSBkZXRhaWxzKS4NCg0KPT0+ICpJZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVu dCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQg aW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBS Lg0KDQpUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBi ZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3Ug YXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBl eHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBo YXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMu DQoNClRoYW5rIHlvdSwNCg0KTWFydGluICYgVGhvbWFzDQpiZXNzIGNoYWlycw0KDQpbMV0gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5k LTAyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCg== --_000_3402959EC6194079984DF539DFB7CC5Falcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NXB4OyBmb250LWZhbWlseTogJ05va2lhIFB1cmUgVGV4dCcsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj5TdXBwb3J0IGFzIGNvLWF1dGhvci48L2Rpdj4NCjxkaXY+Tm90IGF3YXJl IG9mIGFueSBJUFIuLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLjwvZGl2 Pg0KPGRpdj5Kb3JnZTwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVS RSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JE RVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5H LUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JE RVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9z cGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFz Lm1vcmluQG9yYW5nZS5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLm1v cmluQG9yYW5nZS5jb20iPnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwgRmVicnVhcnkg NSwgMjAxNiBhdCA1OjU2IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv OiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJlc3NAaWV0Zi5v cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3Nw YW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5k QGlldGYub3JnIj5kcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZEBpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1u ZEBpZXRmLm9yZyI+ZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94eS1hcnAtbmRAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ Q2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kLTAyPGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNv bGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGRpcj0ibHRyIj5IZWxsbyB3b3JraW5nIGdyb3VwLDwvcD4NCjxwIGRpcj0ibHRyIj5UaGlzIGVt YWlsIHN0YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gYWRvcHRpbmcgZHJhZnQtc25yLWJlc3MtZXZw bi1wcm94eS1hcnAtbmQgWzFdIGFzIGEgd29ya2luZyBncm91cCBpdGVtLjwvcD4NCjxwIGRpcj0i bHRyIj5QbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCBhbmQgc3RhdGUgaWYgeW91IHN1 cHBvcnQgYWRvcHRpb24gb3Igbm90IChpbiB0aGUgbGF0ZXIgY2FzZSwgcGxlYXNlIGFsc28gc3Rh dGUgdGhlIHJlYXNvbnMpLg0KPC9wPg0KPHAgZGlyPSJsdHIiPlRoaXMgcG9sbCBydW5zIHVudGls ICoqRmVicnVhcnkgMTl0aCoqLjwvcD4NCjxwIGRpcj0ibHRyIj4qQ29pbmNpZGVudGFsbHkqLCB3 ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBj b21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2Njkg YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo8L3A+DQo8cCBkaXI9Imx0ciI+PT0mZ3Q7ICpJ ZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxl YXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQgaW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91 IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLjwvcD4NCjxwIGRpcj0ibHRyIj5UaGUgZHJh ZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVk IGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLjwvcD4NCjxwIGRpcj0ibHRyIj5JZiB5 b3UgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFz ZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhh dCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVs ZXMuPC9wPg0KPHAgZGlyPSJsdHIiPlRoYW5rIHlvdSw8L3A+DQo8cCBkaXI9Imx0ciI+TWFydGlu ICZhbXA7IFRob21hczxicj4NCmJlc3MgY2hhaXJzPC9wPg0KPHAgZGlyPSJsdHIiPlsxXSA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94 eS1hcnAtbmQtMDIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNuci1iZXNz LWV2cG4tcHJveHktYXJwLW5kLTAyPC9hPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy DQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRo YW5rIHlvdS4NCjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3402959EC6194079984DF539DFB7CC5Falcatellucentcom_-- From nobody Fri Feb 5 10:43:07 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20D51A877A; Fri, 5 Feb 2016 10:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 vcvIlwY2bmSs; Fri, 5 Feb 2016 10:43:04 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531CB1A8774; Fri, 5 Feb 2016 10:43:03 -0800 (PST) Received: from [172.22.239.4] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u15Ih09c031397 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Feb 2016 10:43:01 -0800 To: thomas.morin@orange.com, "bess@ietf.org" References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> From: Erik Nordmark Message-ID: <56B4ED34.7040702@acm.org> Date: Fri, 5 Feb 2016 10:43:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Content-Type: multipart/alternative; boundary="------------080800080600030904090606" X-Sonic-CAuth: UmFuZG9tSVayE6Z6VGBZNt697VtKJWfonISP9kE+dRrg+Zxw78cEaIn7aLCeg9uy/cb+YmK/Tk1rdxoPpuNIgH+0tTKPFKc6 X-Sonic-ID: C;2uRmSDjM5RGuGsEl14k5kQ== M;eHy4SDjM5RGuGsEl14k5kQ== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 18:43:06 -0000 This is a multi-part message in MIME format. --------------080800080600030904090606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As a co-author I'm not aware of any relevant IPR for this document. Erik On 2/5/16 8:56 AM, thomas.morin@orange.com wrote: > > Hello working group, > > This email starts a two-week poll on adopting > draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). > > This poll runs until **February 19th**. > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you 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. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02 > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------080800080600030904090606 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

As a co-author I'm not aware of any relevant IPR for this document.

   Erik

On 2/5/16 8:56 AM, thomas.morin@orange.com wrote:

Hello working group,

This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item.

Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons).

This poll runs until **February 19th**.

*Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR.

The draft will not be adopted until a response has been received from each author and contributor.

If you 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.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------080800080600030904090606-- From nobody Fri Feb 5 11:18:42 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0D41A885B; Fri, 5 Feb 2016 11:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 Tj9xfn1S1CHt; Fri, 5 Feb 2016 11:18:40 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id E7F081A885A; Fri, 5 Feb 2016 11:18:39 -0800 (PST) Received: from [24.125.34.202] (helo=misfits.twoguys.org) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1aRltg-0000IK-Cy; Fri, 05 Feb 2016 14:18:24 -0500 Received: from misfits.twoguys.org (localhost.twoguys.org [127.0.0.1]) by misfits.twoguys.org (8.14.4/8.12.11) with ESMTP id u15JIJMM027294; Fri, 5 Feb 2016 14:18:19 -0500 Received: (from ghankins@localhost) by misfits.twoguys.org (8.14.4/8.14.4/Submit) id u15JIJTZ027293; Fri, 5 Feb 2016 14:18:19 -0500 X-Authentication-Warning: misfits.twoguys.org: ghankins set sender to greg.hankins@alcatel-lucent.com using -f Date: Fri, 5 Feb 2016 14:18:19 -0500 From: "Hankins, Greg (Nokia - US)" To: "bess@ietf.org" Message-ID: <20160205191819.GA27286@alcatel-lucent.com> References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> <3402959E-C619-4079-984D-F539DFB7CC5F@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3402959E-C619-4079-984D-F539DFB7CC5F@alcatel-lucent.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-ELNK-Trace: 176464c9115cf5b39c7f779228e2f6aeda0071232e20db4d4016c6a8477aab9593d0f0a786d29d18350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.125.34.202 Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 19:18:41 -0000 I support this draft as a co-author, and I am not aware of any IPR. Greg -- Greg Hankins IP/Optical Networks, Nokia -----Original Message----- Date: Fri, 5 Feb 2016 18:01:14 +0000 From: "Rabadan, Jorge (Nokia - US)" To: "thomas.morin@orange.com" , "bess@ietf.org" CC: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Support as co-author. Not aware of any IPR.. Thanks. Jorge From: "thomas.morin@orange.com" > Date: Friday, February 5, 2016 at 5:56 PM To: "bess@ietf.org" > Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" > Subject: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Hello working group, This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item. Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons). This poll runs until **February 19th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). ==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you 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. Thank you, Martin & Thomas bess chairs [1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Feb 5 12:25:00 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E591ACE89; Fri, 5 Feb 2016 12:24:58 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 gVQHfXSc3aGU; Fri, 5 Feb 2016 12:24:56 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60461ACE4C; Fri, 5 Feb 2016 12:24:55 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 86A79718CEC6E; Fri, 5 Feb 2016 20:24:50 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u15KOrtg002082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Feb 2016 20:24:53 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u15KOqU0025789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Feb 2016 21:24:52 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.98]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 5 Feb 2016 21:24:52 +0100 From: "Henderickx, Wim (Nokia - BE)" To: "thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AQHRYFNEdqPcBxqvXEqcG3xGl9pa8w== Date: Fri, 5 Feb 2016 20:24:52 +0000 Message-ID: <45EB1B83-577F-43BB-9115-8D4AB6FEEC41@alcatel-lucent.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_45EB1B83577F43BB91158D4AB6FEEC41alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 20:24:59 -0000 --_000_45EB1B83577F43BB91158D4AB6FEEC41alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYSBjby1hdXRob3IgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEg V0cgaXRlbS4gSXQgaGFzIHNldmVyYWwgYXBwbGljYWJpbGl0aWVzOiBJWFAsIERDLCBXQU4gdXNl IGNhc2VzDQpJIGFtIG5vdCBhd2FyZSBvZiBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0DQoNCkZy b206IEJFU1MgPGJlc3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YmVzcy1ib3VuY2VzQGlldGYu b3JnPj4gb24gYmVoYWxmIG9mICJ0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86dGhvbWFz Lm1vcmluQG9yYW5nZS5jb20+IiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21h cy5tb3JpbkBvcmFuZ2UuY29tPj4NCkRhdGU6IEZyaWRheSA1IEZlYnJ1YXJ5IDIwMTYgYXQgMTc6 NTYNClRvOiAiYmVzc0BpZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4iIDxiZXNzQGlldGYu b3JnPG1haWx0bzpiZXNzQGlldGYub3JnPj4NCkNjOiAiZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94 eS1hcnAtbmRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5k QGlldGYub3JnPiIgPGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kQGlldGYub3JnPG1h aWx0bzpkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZEBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBbYmVzc10gQ2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJw LW5kLTAyDQoNCg0KSGVsbG8gd29ya2luZyBncm91cCwNCg0KVGhpcyBlbWFpbCBzdGFydHMgYSB0 d28td2VlayBwb2xsIG9uIGFkb3B0aW5nIGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5k IFsxXSBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbS4NCg0KUGxlYXNlIHNlbmQgY29tbWVudHMgdG8g dGhlIGxpc3QgYW5kIHN0YXRlIGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yIG5vdCAoaW4gdGhl IGxhdGVyIGNhc2UsIHBsZWFzZSBhbHNvIHN0YXRlIHRoZSByZWFzb25zKS4NCg0KVGhpcyBwb2xs IHJ1bnMgdW50aWwgKipGZWJydWFyeSAxOXRoKiouDQoNCipDb2luY2lkZW50YWxseSosIHdlIGFy ZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KPT0+ICpJZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBk b2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCBhbmQgaW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZh bnQgSVBSLg0KDQpUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNl IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJ ZiB5b3UgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBs ZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIg dGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYg cnVsZXMuDQoNClRoYW5rIHlvdSwNCg0KTWFydGluICYgVGhvbWFzDQpiZXNzIGNoYWlycw0KDQpb MV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHkt YXJwLW5kLTAyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCg== --_000_45EB1B83577F43BB91158D4AB6FEEC41alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <305F3CBACE29244380E9BD99DB5FBF94@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkFzIGEgY28tYXV0aG9yIEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBh cyBhIFdHIGl0ZW0uIEl0IGhhcyBzZXZlcmFsIGFwcGxpY2FiaWxpdGllczogSVhQLCBEQywgV0FO IHVzZSBjYXNlczwvZGl2Pg0KPGRpdj5JIGFtIG5vdCBhd2FyZSBvZiBJUFIgcmVsYXRlZCB0byB0 aGlzIGRyYWZ0PC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1C T1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9U VE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1U T1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5H LVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+ QkVTUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3MtYm91bmNlc0BpZXRmLm9yZyI+YmVzcy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mICZxdW90OzxhIGhyZWY9Im1haWx0bzp0 aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3Jp bkBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ RGF0ZTogPC9zcGFuPkZyaWRheSA1IEZlYnJ1YXJ5IDIwMTYgYXQgMTc6NTY8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpiZXNzQGlldGYub3JnIj5iZXNzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQt c25yLWJlc3MtZXZwbi1wcm94eS1hcnAtbmRAaWV0Zi5vcmciPmRyYWZ0LXNuci1iZXNzLWV2cG4t cHJveHktYXJwLW5kQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kQGlldGYub3JnIj5kcmFmdC1zbnItYmVzcy1ldnBu LXByb3h5LWFycC1uZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bYmVzc10gQ2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0 LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kLTAyPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBkaXI9Imx0ciI+SGVsbG8gd29ya2luZyBncm91cCw8L3A+ DQo8cCBkaXI9Imx0ciI+VGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xsIG9uIGFkb3B0 aW5nIGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kIFsxXSBhcyBhIHdvcmtpbmcgZ3Jv dXAgaXRlbS48L3A+DQo8cCBkaXI9Imx0ciI+UGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxp c3QgYW5kIHN0YXRlIGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yIG5vdCAoaW4gdGhlIGxhdGVy IGNhc2UsIHBsZWFzZSBhbHNvIHN0YXRlIHRoZSByZWFzb25zKS4NCjwvcD4NCjxwIGRpcj0ibHRy Ij5UaGlzIHBvbGwgcnVucyB1bnRpbCAqKkZlYnJ1YXJ5IDE5dGgqKi48L3A+DQo8cCBkaXI9Imx0 ciI+KkNvaW5jaWRlbnRhbGx5Kiwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9m IGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBo YXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUg UkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KPC9wPg0K PHAgZGlyPSJsdHIiPj09Jmd0OyAqSWYqIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0 aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGlj YXRlIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi48L3A+ DQo8cCBkaXI9Imx0ciI+VGhlIGRyYWZ0IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNw b25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci48 L3A+DQo8cCBkaXI9Imx0ciI+SWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBj b250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFy ZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29u Zm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLjwvcD4NCjxwIGRpcj0ibHRyIj5UaGFuayB5b3UsPC9w Pg0KPHAgZGlyPSJsdHIiPk1hcnRpbiAmYW1wOyBUaG9tYXM8YnI+DQpiZXNzIGNoYWlyczwvcD4N CjxwIGRpcj0ibHRyIj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kLTAyIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0wMjwvYT48L3A+DQo8cHJl Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQo8L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_45EB1B83577F43BB91158D4AB6FEEC41alcatellucentcom_-- From nobody Fri Feb 5 18:31:12 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2611A88B2 for ; Fri, 5 Feb 2016 18:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 BnzvPMI7Zl2v for ; Fri, 5 Feb 2016 18:31:07 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A551A88AD for ; Fri, 5 Feb 2016 18:31:07 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id z185so66653855ywf.0 for ; Fri, 05 Feb 2016 18:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuagenetworks-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=//i8ICfMZhKhfiY/2x5LujRLxE5Qv54r6TN+MbH4Mm4=; b=hWPipjT0QkvJAa0dbqGyJ2kXX6XwCJ/epMw+0O8wMU2bB9inXaOB63dm4zoiTx6sZF G4/PlexY1O8DNFzkLDMMbm91kybZoLFchju69z4L564VWREoxzl2pODxKumeFF+zOPPy mxlZZax0jT9tyf+BINay6uVcFMmgtWf2pFUDfTzBLHAo/HqCmQ9UvXJKusZgdE3VLido DQ9m+qhStP2xx0G64ifan7NdNBiDOLQGj4ObYrZldChzL4E/xyxtN+0N8Dcz8hW8m+Yt /Vcq9h2onIEVTF+kRcGsWnlb0ONSx18vFSrz0p7iR6p2G8nXyCOmUThvs73DwVLrBx61 DtlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=//i8ICfMZhKhfiY/2x5LujRLxE5Qv54r6TN+MbH4Mm4=; b=QO1eZJgr8rgU1/rCeuRWOhPhBU6vyzh1LziuFbZTSbn6eFulabLjKiSFGjfyOY4SCt +XV0D7l3VrU/ntfK3LoSqbl3AIPLsteTZDJyRRfS7UIOCrWdpCtcuGdokJEJTHB2ajZO VKJU1X1VC2wRT30xResoXMJfpVryuEfqn7LN/dQk0a2irEkFNpaKsaI5cgvXVIyN7gSL IzTSrP2sWfs40DqXFYg0AGwTXuUvUf/JrIZL7x+ppe8t70e3QQx3cNSfPCKcd8GztoOU SABZT0qGjq+8dXB2fhT07gQFEfv5h2H0DDziuf1g/bO+/wYpVNWvkcU6qlz/VjyaC/sC msHw== X-Gm-Message-State: AG10YOSW3uf1+b1tOoq8P1gb9i1IUXeZ7oiefNT5ECCNFaOONfAj8yyjc71u7di2zcQrCY7h X-Received: by 10.13.242.5 with SMTP id b5mr8656970ywf.246.1454725866905; Fri, 05 Feb 2016 18:31:06 -0800 (PST) Received: from ?IPv6:2600:1017:b80e:3c23:60cb:da1d:21a3:1754? ([2600:1017:b80e:3c23:60cb:da1d:21a3:1754]) by smtp.gmail.com with ESMTPSA id 204sm12827274ywz.39.2016.02.05.18.31.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 18:31:06 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-5B5059A9-6393-4CB1-BEE3-CA6220344398 Mime-Version: 1.0 (1.0) From: Nabeel Cocker X-Mailer: iPhone Mail (13D15) In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Date: Fri, 5 Feb 2016 21:31:04 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> To: thomas.morin@orange.com Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" , "bess@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 02:31:09 -0000 --Apple-Mail-5B5059A9-6393-4CB1-BEE3-CA6220344398 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I Support this draft.=20 Regards, Nabeel > On Feb 5, 2016, at 11:56 AM, wrote: >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-ar= p-nd [1] as a working group item. >=20 > Please send comments to the list and state if you support adoption or not (= in the later case, please also state the reasons). >=20 > This poll runs until **February 19th**. >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that applie= s to this draft, to ensure that IPR has been disclosed in compliance with IE= TF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > =3D=3D> *If* you are listed as a document author or contributor please res= pond to this email and indicate whether or not you are aware of any relevant= IPR. >=20 > The draft will not be adopted until a response has been received from each= author and contributor. >=20 > If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in c= onformance with IETF rules. >=20 > Thank you, >=20 > Martin & Thomas > bess chairs >=20 > [1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02 >=20 > __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged in= formation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and del= ete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been= modified, changed or falsified. > Thank you. > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --Apple-Mail-5B5059A9-6393-4CB1-BEE3-CA6220344398 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I Support this draft. 

Regards,
Nabeel

On Feb 5, 2016, at 11:56 AM, <thomas.morin@orange.com> <thomas.morin@orange.com> wrote:

Hello working group,

This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item.

Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons).

This poll runs until **February 19th**.

*Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR.

The draft will not be adopted until a response has been received from each author and contributor.

If you 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.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--Apple-Mail-5B5059A9-6393-4CB1-BEE3-CA6220344398-- From nobody Fri Feb 5 18:31:31 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893EC1A88C0 for ; Fri, 5 Feb 2016 18:31:30 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 QFL9ub76gNXb for ; Fri, 5 Feb 2016 18:31:29 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107391A88BD for ; Fri, 5 Feb 2016 18:31:29 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id z185so66658240ywf.0 for ; Fri, 05 Feb 2016 18:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuagenetworks-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GaND8+6QySDfbjKNiYKC5Gw7QYZPhJxZHJ7uQs/0ziU=; b=vNmxiRAqi3aq76LWwMo40QGX9YlG7/zzZaXiXZfZZb+5f4QxU6f+x9jWYCkrvaWsfP bdM/+y+Bf+nwqQ1KMFU+T0bhSiLPYPpYnlxfuj/aHUJ7GJXxgx93RtL1M74vW5Nc0HNT hiN09CDAiUKQRmp5F8lnLRqmCCMt126wvg8RoN6gzhfcSKwoAr74324VghiFoDOqHBKK uJl094K/wRpQPdd7AeNuykxDYfgilB+miV24t9l96fXZBSvX3d6v5xICzdKUVLMtrYQN VN1bmjoKxr7v7bADo5yyMlbrTFqjSHZgfBLtWNSBvi9cyS2J1dhyLatUucc2iuq8zamV iKkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=GaND8+6QySDfbjKNiYKC5Gw7QYZPhJxZHJ7uQs/0ziU=; b=OC/KU8pSQCyvlaTuYQ3FYUP48uZRC0uHnlyOVcPQlo2s+MgEc+bYZAr1SDokIh8LM6 v4S2jKkFG+Ioj16tVDGqftzYqN2biXn0InAOTadyhuByhoauiD2eZsAlo5dkHc8xJppe NwLSz48CHzNsRjsEqlfqki4q5cj9Rm7aXb7e6ccQ7hGIbAzVCJlHM8yyBrnjQ5fMDe3Z jbSzDtqN5kDK/PlyOCyXV1Heo7DnLXnzVT9L63wsTWaoTzz0eyP1URis+ZjkitwgkSrU ACabtJ1/k7/BP7vHA9kPLXVb0jb1G3ocjOilhCOZEwu+BINV5buAwKOXTo9nwawbf0bb BcAg== X-Gm-Message-State: AG10YOTodhsE5ZfE65AZ8zGjNADYz0etmSqeO02Xv5Hlm2ktRN1SOQWWktM0wLsVirHPdr84 X-Received: by 10.13.253.129 with SMTP id n123mr9470282ywf.64.1454725888373; Fri, 05 Feb 2016 18:31:28 -0800 (PST) Received: from ?IPv6:2600:1017:b80e:3c23:60cb:da1d:21a3:1754? ([2600:1017:b80e:3c23:60cb:da1d:21a3:1754]) by smtp.gmail.com with ESMTPSA id y4sm508073ywa.28.2016.02.05.18.31.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 18:31:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Nabeel Cocker X-Mailer: iPhone Mail (13D15) In-Reply-To: <56A72A83.10906@orange.com> Date: Fri, 5 Feb 2016 21:31:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4B3A1C05-7DD5-40FA-B079-77986138AAAC@nuagenetworks.net> References: <56A72A83.10906@orange.com> To: Thomas Morin Archived-At: Cc: draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org, bess@ietf.org Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 02:31:30 -0000 I support this draft.=20 Regards, Nabeel > On Jan 26, 2016, at 3:12 AM, Thomas Morin wrote:= >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting > draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. >=20 > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). >=20 > This poll runs until **February 9th**. >=20 >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). >=20 > =3D=3D> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any rel= evant IPR. >=20 > The draft will not be adopted until a response has been received from > each author and contributor. >=20 > If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in c= onformance with IETF rules. >=20 > Thank you, >=20 > Martin & Thomas > bess chairs >=20 > [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Fri Feb 5 22:10:19 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518821B2FB6; Fri, 5 Feb 2016 15:39:56 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Zj67gUunfzfV; Fri, 5 Feb 2016 15:39:53 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A241B2FB5; Fri, 5 Feb 2016 15:39:52 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id EBDA6BCEE504D; Fri, 5 Feb 2016 23:39:47 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u15NdpCi030068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Feb 2016 23:39:51 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u15NdpA9019253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Feb 2016 23:39:51 GMT Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.60]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 5 Feb 2016 18:39:51 -0500 From: "Oya Luengo, Roberto (Nokia - US)" To: "thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AQHRYG6BXB7JK7ocQLKDXemsWvLl+Q== Date: Fri, 5 Feb 2016 23:39:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_D2DA72BB535AFrobertooyaluengoalcatellucentcom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 05 Feb 2016 22:10:16 -0800 Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 23:39:56 -0000 --_000_D2DA72BB535AFrobertooyaluengoalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support From: BESS > on behalf = of "thomas.morin@orange.com" > Date: Friday, February 5, 2016 at 8:56 AM To: "bess@ietf.org" > Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" > Subject: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Hello working group, This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp= -nd [1] as a working group item. Please send comments to the list and state if you support adoption or not (= in the later case, please also state the reasons). This poll runs until **February 19th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies= to this draft, to ensure that IPR has been disclosed in compliance with IE= TF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). =3D=3D> *If* you are listed as a document author or contributor please resp= ond to this email and indicate whether or not you are aware of any relevant= IPR. The draft will not be adopted until a response has been received from each = author and contributor. If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in = conformance with IETF rules. Thank you, Martin & Thomas bess chairs [1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D2DA72BB535AFrobertooyaluengoalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support

From: BESS <bess-bounces@ietf.org> on behalf of "thomas.morin@orange.com" <= ;thomas.morin@orange.com>=
Date: Friday, February 5, 2016 at 8= :56 AM
To: "bess@ietf.org" <bess@i= etf.org>
Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.o= rg" <draft-snr-bess-evpn-proxy-arp-nd@ietf.org>
Subject: [bess] Call for adoption: = draft-snr-bess-evpn-proxy-arp-nd-02

Hello working group,

This email starts a two-week poll on adopting draft-snr-bess= -evpn-proxy-arp-nd [1] as a working group item.

Please send comments to the list and state if you support ad= option or not (in the later case, please also state the reasons).

This poll runs until **February 19th**.

*Coincidentally*, we are also polling for knowledge of any I= PR that applies to this draft, to ensure that IPR has been disclosed in com= pliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more de= tails).

=3D=3D> *If* you are listed as a document author or contr= ibutor please respond to this email and indicate whether or not you are awa= re of any relevant IPR.

The draft will not be adopted until a response has been rece= ived from each author and contributor.

If you are not listed as an author or contributor, then plea= se explicitly respond only if you are aware of any IPR that has not yet bee= n disclosed in conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_D2DA72BB535AFrobertooyaluengoalcatellucentcom_-- From nobody Sat Feb 6 05:47:21 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 066C21B326E; Sat, 6 Feb 2016 05:47:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160206134720.7440.68607.idtracker@ietfa.amsl.com> Date: Sat, 06 Feb 2016 05:47:20 -0800 Archived-At: Subject: [bess] The BESS WG has placed draft-snr-bess-evpn-proxy-arp-nd in state "Call For Adoption By WG Issued" X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 13:47:20 -0000 The BESS WG has placed draft-snr-bess-evpn-proxy-arp-nd in state Call For Adoption By WG Issued (entered by Martin Vigoureux) The document is available at https://datatracker.ietf.org/doc/draft-snr-bess-evpn-proxy-arp-nd/ From nobody Sun Feb 7 08:16:52 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47F01B3C80 for ; Sun, 7 Feb 2016 08:16:50 -0800 (PST) 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 tPZQdbEYTW5L for ; Sun, 7 Feb 2016 08:16:49 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083B21B3C7D for ; Sun, 7 Feb 2016 08:16:49 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id c3so36109303vkb.3 for ; Sun, 07 Feb 2016 08:16:48 -0800 (PST) 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=17lgqd70xx5PeNp7S31UKFKKEFmjy39njBNzs7mYx/M=; b=Ht8BRWXavGF6vVkvCBG50uXyghe1lnZfwFk4VTJ5hOjtEjS0KB7EdXeO/Cnk2CbL+N SSTM3iJtTRJx3wHq7A9avfDV9l9f/1+p4+CX4N7RWovwOnkmTL9wyhsORpGHfSJfsm1B zJLQMjZbZbf9XBNVJGCirssoxdVKi5HkCzELlopS+iMhxEtnxRnSXsW+7s1LxlMHvc/v iCysFffs1bD64DJxkvg50piQ4TkQI9KLcwYFxntB3ynlI8BmibZ9GdtjF6PFhDfl5pjL +wAi0caE+qjjyJX+yeO4Xbs3QqXMrewgQnr+5Qq3yz70ZqBuYrfT9+vl/SNT0nRZhp/i jm1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=17lgqd70xx5PeNp7S31UKFKKEFmjy39njBNzs7mYx/M=; b=T/rpwVJ94RlaT7wyofqtwf57rt0JwZu0f4kHGPqJfnb4Ak/EVkTsrmal0zjkHXom8+ fEki9k0PJWi1Mb4T5QDOZj6VafGJqQo4fxrlJhQ9jmrdNiSHWwg1FceHC8vpxP/K9KYT 0ugSOMf08uchUkGPYi2HgxRn8Rq4ASJRqV+H/YTcbzmGi9YacLt2hShlBnX1BIGRq61u Tfk308Pfr+38UgvOo85caRp6fYzIiDUlAfGlkclvosuMLnRVnVYnOIOPANbR5LwKEX8y 9ImJPh0UHmia5qib8Laxik4Zt8UGoa/t1QgrHxADNSH6FLUjjycY0OOzafveBvkpPacB /6mw== X-Gm-Message-State: AG10YOQjzpTPs7McQAEY5u0bn54Vb0efVbSo7pOaUvTV2t8EWXlTmAqx5dPNicvmxcCWB2MmvrMJ+c7s8WRbJQ== MIME-Version: 1.0 X-Received: by 10.31.33.80 with SMTP id h77mr4626944vkh.24.1454861808094; Sun, 07 Feb 2016 08:16:48 -0800 (PST) Received: by 10.31.196.193 with HTTP; Sun, 7 Feb 2016 08:16:47 -0800 (PST) Received: by 10.31.196.193 with HTTP; Sun, 7 Feb 2016 08:16:47 -0800 (PST) In-Reply-To: <56A72A83.10906@orange.com> References: <56A72A83.10906@orange.com> Date: Sun, 7 Feb 2016 11:16:47 -0500 Message-ID: From: Senad Palislamovic To: Thomas Morin Content-Type: multipart/alternative; boundary=001a11c03f7044d39f052b30699a Archived-At: Cc: draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org, bess@ietf.org Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 16:16:51 -0000 --001a11c03f7044d39f052b30699a Content-Type: text/plain; charset=UTF-8 Support for the reasons already stated by the group. /Senad On Jan 26, 2016 3:12 AM, "Thomas Morin" wrote: > Hello working group, > > This email starts a two-week poll on adopting > draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). > > This poll runs until **February 9th**. > > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you 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. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 > > > > > > > > > > > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --001a11c03f7044d39f052b30699a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Support for the reasons already stated by the group.=C2=A0 <= /p>

/Senad

On Jan 26, 2016 3:12 AM, "Thomas Morin"= ; <thomas.morin@orange.com> wrote:
Hello w= orking group,

This email starts a two-week poll on adopting
draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until **February 9th**.


*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

=3D=3D> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any rele= vant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in = conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/d= raft-rabadan-bess-evpn-optimized-ir-02













_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--001a11c03f7044d39f052b30699a-- From nobody Sun Feb 7 08:57:13 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E191A000B; Sun, 7 Feb 2016 08:57:11 -0800 (PST) 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 98r53xn0l1_9; Sun, 7 Feb 2016 08:57:10 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40021A0006; Sun, 7 Feb 2016 08:57:09 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id e6so82727501vkh.2; Sun, 07 Feb 2016 08:57:09 -0800 (PST) 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=kvWuZ7WCwFuoLCaZ9dqgjCcrgGi9GKRNw42L7H4fDDc=; b=vZkJRbOzxYuE2mcTaHq0gYXPSLfE4nF0Z5EMijZNCFthA/5POG0GHiySkHrATTaPXW co1bKEMMXA+++UrEE2U3bK/mifc96lcgfCXlyO3fMCUFQdojXvRxJ/7sbTr+3wjLof69 SS5FpAZXzXDhVziOf3ekyWs/XSd2F566VBOfy+qsdJhOWsvA+3lvuC1KtqhCd1x6z5Xp 3yg4QkmNZjXZWyNX6Sp1dQLRibV2fyQee/uCEl2bAuBxQjnTETuXWQXLVvtvvUJ2fnmT lP0BqN1y3vtwG6Le587MkoJovwZtIz4JPj9GFrHm7cr4uR+3taOlGrtpqXV6Mt/KvD0j vb5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kvWuZ7WCwFuoLCaZ9dqgjCcrgGi9GKRNw42L7H4fDDc=; b=lf9oGLplZfjcEP59HhJ8U3EqXlhqACOkfm0bdkcFD4TO/FKP85tFxL47RFEEWt8s9B 4YNCms2NpAx3PEOsYlwLdTUHQGcCgoJVTaGNtXYxP/W3ysHuGBeZLZkLVmiWT+As09X3 8Mx3mVpU6oEaDyNXQhvIWOtqJs8wMOW+TMWJSkG04lBYirzVCdrN/OVZCZwKfSZt1KOV Jt1B/dzgh+Fs4ApipNA6d4+pZ7TQLPbekup93HOJ8xTxZENMpyf4AlFWgakk/mXnkI+P OMD3sKsNfxXKzGI7PwIeByD/YZLzcdOihXFJToSYx9Z3P63yvkiTvrr17Wzn0HJYa9XU 6qlg== X-Gm-Message-State: AG10YOR1JSnJ8w+eD8y/UKbMiY6CmGgQE0bhg1u3Iflf7suc7sfqrCIZCa2yMHH6DxqCEI0na2MnuqAOoW+cvg== MIME-Version: 1.0 X-Received: by 10.31.2.14 with SMTP id 14mr16825769vkc.9.1454864228825; Sun, 07 Feb 2016 08:57:08 -0800 (PST) Received: by 10.31.196.193 with HTTP; Sun, 7 Feb 2016 08:57:08 -0800 (PST) Received: by 10.31.196.193 with HTTP; Sun, 7 Feb 2016 08:57:08 -0800 (PST) In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Date: Sun, 7 Feb 2016 11:57:08 -0500 Message-ID: From: Senad Palislamovic To: thomas.morin@orange.com Content-Type: multipart/alternative; boundary=001a113dc5b48e40cb052b30f92f Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" , "bess@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 16:57:12 -0000 --001a113dc5b48e40cb052b30f92f Content-Type: text/plain; charset=UTF-8 +1 /Senad On Feb 5, 2016 11:57 AM, wrote: > Hello working group, > > This email starts a two-week poll on adopting > draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item. > > Please send comments to the list and state if you support adoption or not > (in the later case, please also state the reasons). > > This poll runs until **February 19th**. > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in compliance > with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please respond > to this email and indicate whether or not you are aware of any relevant IPR. > > The draft will not be adopted until a response has been received from each > author and contributor. > > If you 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. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02 > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > --001a113dc5b48e40cb052b30f92f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1
/Senad

On Feb 5, 2016 11:57 AM, <thomas.morin@orange.com> wrote:

Hello working group,

This email starts a two-week poll on adopting draft-snr-bess= -evpn-proxy-arp-nd [1] as a working group item.

Please send comments to the list and state if you support ad= option or not (in the later case, please also state the reasons).

This poll runs until **February 19th**.

*Coincidentally*, we are also polling for knowledge of any I= PR that applies to this draft, to ensure that IPR has been disclosed in com= pliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more de= tails).

=3D=3D> *If* you are listed as a document author or contr= ibutor please respond to this email and indicate whether or not you are awa= re of any relevant IPR.

The draft will not be adopted until a response has been rece= ived from each author and contributor.

If you are not listed as an author or contributor, then plea= se explicitly respond only if you are aware of any IPR that has not yet bee= n disclosed in conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

--001a113dc5b48e40cb052b30f92f-- From nobody Sun Feb 7 11:23:34 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210221A1AB3 for ; Sun, 7 Feb 2016 11:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=unavailable 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 eStJEyRBS6cB for ; Sun, 7 Feb 2016 11:23:30 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FF31A1AA9 for ; Sun, 7 Feb 2016 11:23:30 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id b67so17387318qgb.1 for ; Sun, 07 Feb 2016 11:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuagenetworks-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=msKvSx9jkwGYUIwo9kYvN0X7Xk91L1aoCxg1K6rpSMo=; b=SRznqOC8QbRk0lW/DVT3U4fa5F3mRxS8lwydsVk4mgSbUYfJ+1591cj2chtFr4wf66 ZzT4Y5s+7KitAniLUtDxv8pWpY+/C35C3GcvPenMd6Z3/xmKe1H5MfwQiYbmX+ZNCb0Y fp6HinzTsu+Z5+F0dqcPf7FvRDNHCW6ItZ1otL/H6VAEIPHiZ6Lh4bWUJ0KPOdXPPf/W 9P459NA3pqlAc8hf43iiZ73aKXZILcKr20wMfyOw6OPyvIGD86jX0QklYystaHMu+Ksd 09L3hVxR+rw4YaVJfbU3b6HPcnv3YHMLxJn+hgQJJBey5kMyZvRZr1cK/qB/RI4KS7HW kfMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=msKvSx9jkwGYUIwo9kYvN0X7Xk91L1aoCxg1K6rpSMo=; b=Uv+uDbfsXZ1mNKMp1eFgJsiq4e+4oJ88x3ZV2G2EGlympoSMhkQCkn3dVSPOYdNnSL z4ldWGUSGkHlX6Y3xTy8E2Sa5BVTpTjON8G8jT6wCxXfKKO3EAv2qZvddGc1YoymcqsT RrOjE2jIPxx7dkjT4cRn8HbfGA1i8u5TfHxWZl40mIStBiFgQa1uqrQStjmu0dGDr+Nd z/8E1DLLAhR7D/0wLwCKeGY7sDFsLfO1q7OjKk/scJj82mLo9K0EQeO4KoKLT45KfZti WpFq24+bypG/6pXvwNMvu8SFBHCYA3Qu193XmGO5ziQOWAwE0+/V7VqU7QhvXe+kg21y oC0w== X-Gm-Message-State: AG10YOQSvlBjwUztlng5yio1jWkiDBDIauvTsbHD3e5zLWD2Gpnd/AngX1wSyg34N1F4cztO X-Received: by 10.140.226.8 with SMTP id w8mr32020857qhb.83.1454873009198; Sun, 07 Feb 2016 11:23:29 -0800 (PST) Received: from [192.168.1.13] (pool-96-246-136-179.nycmny.fios.verizon.net. [96.246.136.179]) by smtp.gmail.com with ESMTPSA id b135sm12520144qka.2.2016.02.07.11.23.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Feb 2016 11:23:28 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-28FC0635-28DD-4954-ABBF-912C2F00AB74 Mime-Version: 1.0 (1.0) From: Nabeel Cocker X-Mailer: iPhone Mail (13D15) In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Date: Sun, 7 Feb 2016 14:23:27 -0500 Content-Transfer-Encoding: 7bit Message-Id: <960F1A01-B23F-47EF-85EA-521063637CFF@nuagenetworks.net> References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> To: thomas.morin@orange.com Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" , "bess@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 19:23:32 -0000 --Apple-Mail-28FC0635-28DD-4954-ABBF-912C2F00AB74 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Support Regards, Nabeel > On Feb 5, 2016, at 11:56 AM, wrote: >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-ar= p-nd [1] as a working group item. >=20 > Please send comments to the list and state if you support adoption or not (= in the later case, please also state the reasons). >=20 > This poll runs until **February 19th**. >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that applie= s to this draft, to ensure that IPR has been disclosed in compliance with IE= TF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > =3D=3D> *If* you are listed as a document author or contributor please res= pond to this email and indicate whether or not you are aware of any relevant= IPR. >=20 > The draft will not be adopted until a response has been received from each= author and contributor. >=20 > If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in c= onformance with IETF rules. >=20 > Thank you, >=20 > Martin & Thomas > bess chairs >=20 > [1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02 >=20 > __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged in= formation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and del= ete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been= modified, changed or falsified. > Thank you. > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --Apple-Mail-28FC0635-28DD-4954-ABBF-912C2F00AB74 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Support

Regards,
Nabeel

On Feb 5, 2016, at 11:56 AM, <thomas.morin@orange.com> <thomas.morin@orange.com> wrote:

Hello working group,

This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item.

Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons).

This poll runs until **February 19th**.

*Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR.

The draft will not be adopted until a response has been received from each author and contributor.

If you 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.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--Apple-Mail-28FC0635-28DD-4954-ABBF-912C2F00AB74-- From nobody Mon Feb 8 10:52:31 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850C71B317E; Mon, 8 Feb 2016 10:52:28 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 llOPAc6ydarS; Mon, 8 Feb 2016 10:52:25 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1085E1B317D; Mon, 8 Feb 2016 10:52:24 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id BEA20F54DE841; Mon, 8 Feb 2016 18:52:21 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u18IqNWa018814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Feb 2016 18:52:23 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u18IqNGT000638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Feb 2016 18:52:23 GMT Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.8]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 8 Feb 2016 13:52:23 -0500 From: "Sathappan, Senthil (Nokia - US)" To: "thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AdFgNjTaXB7JK7ocQLKDXemsWvLl+QCa1obQ Date: Mon, 8 Feb 2016 18:52:22 +0000 Message-ID: <67BB2DACD18480429D1A539B1086C78573967309@US70TWXCHMBA10.zam.alcatel-lucent.com> References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_67BB2DACD18480429D1A539B1086C78573967309US70TWXCHMBA10z_" MIME-Version: 1.0 Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 18:52:28 -0000 --_000_67BB2DACD18480429D1A539B1086C78573967309US70TWXCHMBA10z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjby1hdXRob3IuIE5vdCBhd2FyZSBvZiBhbnkgSVBSDQpUaGFua3MsDQpTZW50 aGlsLg0KDQpGcm9tOiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSBbbWFpbHRvOnRob21hcy5tb3Jp bkBvcmFuZ2UuY29tXQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAwNSwgMjAxNiA4OjU3IEFNDQpU bzogYmVzc0BpZXRmLm9yZw0KQ2M6IGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kQGll dGYub3JnDQpTdWJqZWN0OiBDYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtc25yLWJlc3MtZXZwbi1w cm94eS1hcnAtbmQtMDINCg0KDQpIZWxsbyB3b3JraW5nIGdyb3VwLA0KDQpUaGlzIGVtYWlsIHN0 YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gYWRvcHRpbmcgZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94 eS1hcnAtbmQgWzFdIGFzIGEgd29ya2luZyBncm91cCBpdGVtLg0KDQpQbGVhc2Ugc2VuZCBjb21t ZW50cyB0byB0aGUgbGlzdCBhbmQgc3RhdGUgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3Igbm90 IChpbiB0aGUgbGF0ZXIgY2FzZSwgcGxlYXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KDQpU aGlzIHBvbGwgcnVucyB1bnRpbCAqKkZlYnJ1YXJ5IDE5dGgqKi4NCg0KKkNvaW5jaWRlbnRhbGx5 Kiwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBs aWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQg aW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAz NjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQo9PT4gKklmKiB5b3UgYXJlIGxpc3Rl ZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0 aGlzIGVtYWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFu eSByZWxldmFudCBJUFIuDQoNClRoZSBkcmFmdCB3aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEg cmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0 b3IuDQoNCklmIHlvdSBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3Is IHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdp dGggSUVURiBydWxlcy4NCg0KVGhhbmsgeW91LA0KDQpNYXJ0aW4gJiBUaG9tYXMNCmJlc3MgY2hh aXJzDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc25yLWJlc3MtZXZw bi1wcm94eS1hcnAtbmQtMDINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s DQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KDQpUaGFuayB5b3UuDQo= --_000_67BB2DACD18480429D1A539B1086C78573967309US70TWXCHMBA10z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0 Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlN1cHBvcnQgYXMgY28tYXV0aG9yLiBOb3QgYXdhcmUg b2YgYW55IElQUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5UaGFua3MsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPlNlbnRoaWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdGhvbWFzLm1vcmluQG9y YW5nZS5jb20gW21haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDA1LCAyMDE2IDg6NTcgQU08YnI+DQo8Yj5Ubzo8L2I+IGJl c3NAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJw LW5kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IENhbGwgZm9yIGFkb3B0aW9uOiBkcmFm dC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwPkhlbGxvIHdvcmtpbmcgZ3JvdXAsPG86cD48L286cD48L3A+DQo8cD5UaGlzIGVtYWlsIHN0 YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gYWRvcHRpbmcgZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94 eS1hcnAtbmQgWzFdIGFzIGEgd29ya2luZyBncm91cCBpdGVtLjxvOnA+PC9vOnA+PC9wPg0KPHA+ UGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYW5kIHN0YXRlIGlmIHlvdSBzdXBwb3J0 IGFkb3B0aW9uIG9yIG5vdCAoaW4gdGhlIGxhdGVyIGNhc2UsIHBsZWFzZSBhbHNvIHN0YXRlIHRo ZSByZWFzb25zKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBwb2xsIHJ1bnMgdW50aWwgKipG ZWJydWFyeSAxOXRoKiouPG86cD48L286cD48L3A+DQo8cD4qQ29pbmNpZGVudGFsbHkqLCB3ZSBh cmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPj09Jmd0OyAqSWYq IHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFz ZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBh cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBkcmFm dCB3aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQg ZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuPG86cD48L286cD48L3A+DQo8cD5JZiB5 b3UgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFz ZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhh dCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVs ZXMuPG86cD48L286cD48L3A+DQo8cD5UaGFuayB5b3UsPG86cD48L286cD48L3A+DQo8cD5NYXJ0 aW4gJmFtcDsgVGhvbWFzPGJyPg0KYmVzcyBjaGFpcnM8bzpwPjwvbzpwPjwvcD4NCjxwPlsxXSA8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc25yLWJlc3MtZXZwbi1w cm94eS1hcnAtbmQtMDIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNuci1i ZXNzLWV2cG4tcHJveHktYXJwLW5kLTAyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Q2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j PG86cD48L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5U aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPG86cD48L286 cD48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_67BB2DACD18480429D1A539B1086C78573967309US70TWXCHMBA10z_-- From nobody Mon Feb 8 12:14:31 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953301B3299 for ; Mon, 8 Feb 2016 12:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 uprczK4l1K97 for ; Mon, 8 Feb 2016 12:14:20 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092261B329F for ; Mon, 8 Feb 2016 12:14:20 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id hb3so64016452igb.0 for ; Mon, 08 Feb 2016 12:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuagenetworks-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/VQ0tZMhrsl441dD3KYnpCTSTxHvhrQZE0S7bH1m5iI=; b=Mx9D1x/zSlwY5McF2QR5mkLimyCgc75B3LYsbjo19dywzcRYBpDIdnodD1SEc2ui+P LKLpHIP0xL5KpOti0AIJIOvV7vp//txmw063u0Rc9T4xJCTOPa9pAL0h1k2CO31IImaJ ykca/fIkWR6zJOHa68OqUoPLEMVCrvNuIOwnFpUDS2vdZ2aDhTmDw1C3JGGG9l1SxWj8 6E5neJON3GCWh6HG3zCW/HzUpCCbnk8is2awAbZWhfFtF9JKJnQ3eakYm6iF5mC5V+/X l/T9ouxmXekfdtQ7eAfbTcyEToVMZn7ziIyva07y4j/mTYGk+On5ZEqz/pFP7oGExFQN ET7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/VQ0tZMhrsl441dD3KYnpCTSTxHvhrQZE0S7bH1m5iI=; b=L98hhgPsVxe84nZyAKMU9/0cJu0kwLuaQIblDBcm6M9Slx2oXiEy9Aj+vy3Kz5/nMb 6o5QNIyKpx0673Jc+n8s0g4XnR+/vZf/SMYm9TYmwRPtUm4hvF/tI0V8WW5mi1kOLOCA h1geNipTzCuPNvsUKbKoMAVX6S89vC0VkrhgfaQocQdJQHyf7AmTIv3Ar5EDRnN7kGO2 DI6g+cJs7DsVQ0MvvgbAHdWvb9+OmV6S+BZ4ws8Op2eAEwz+MCnoEDCOllMf5U2TPxAB B3mc9E5blE4aZ5juR2GR7NaYmVbklbOAH/wKtDNQmaT9Fu6z6I1cIc17rlhzh+ihIoBo js4g== X-Gm-Message-State: AG10YORp8IuAMaS9etI1VBU+RA4DLciHm+B6kJoXZjYkbDc97mlZEZABXSDjNqfAgpKq3LAlYJt2L4UcsDGJjM6p MIME-Version: 1.0 X-Received: by 10.50.2.70 with SMTP id 6mr741459igs.74.1454962459346; Mon, 08 Feb 2016 12:14:19 -0800 (PST) Received: by 10.36.109.129 with HTTP; Mon, 8 Feb 2016 12:14:19 -0800 (PST) In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Date: Mon, 8 Feb 2016 15:14:19 -0500 Message-ID: From: Nabeel Cocker To: Thomas Morin Content-Type: multipart/alternative; boundary=089e0115fc0e8d3ddc052b47d8eb Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" , "bess@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 20:14:21 -0000 --089e0115fc0e8d3ddc052b47d8eb Content-Type: text/plain; charset=UTF-8 I support this draft. thanks, Nabeel On Fri, Feb 5, 2016 at 11:56 AM, wrote: > Hello working group, > > This email starts a two-week poll on adopting > draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item. > > Please send comments to the list and state if you support adoption or not > (in the later case, please also state the reasons). > > This poll runs until **February 19th**. > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in compliance > with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please respond > to this email and indicate whether or not you are aware of any relevant IPR. > > The draft will not be adopted until a response has been received from each > author and contributor. > > If you 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. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02 > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > --089e0115fc0e8d3ddc052b47d8eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support this draft.

thanks,
Nabeel


On Fri, Feb 5, 2016 at 11:56 AM, <thomas.morin@ora= nge.com> wrote:

Hello working group,

This email starts a two-week poll on adopting draft-snr-bess= -evpn-proxy-arp-nd [1] as a working group item.

Please send comments to the list and state if you support ad= option or not (in the later case, please also state the reasons).

This poll runs until **February 19th**.

*Coincidentally*, we are also polling for knowledge of any I= PR that applies to this draft, to ensure that IPR has been disclosed in com= pliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more de= tails).

=3D=3D> *If* you are listed as a document author or contr= ibutor please respond to this email and indicate whether or not you are awa= re of any relevant IPR.

The draft will not be adopted until a response has been rece= ived from each author and contributor.

If you are not listed as an author or contributor, then plea= se explicitly respond only if you are aware of any IPR that has not yet bee= n disclosed in conformance with IETF rules.

Thank you,

Martin & Thomas
bess chairs

[1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


--089e0115fc0e8d3ddc052b47d8eb-- From nobody Mon Feb 8 14:11:41 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2111B33FD; Mon, 8 Feb 2016 14:11:38 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 3PWT_Eg-LbXF; Mon, 8 Feb 2016 14:11:36 -0800 (PST) Received: from de-cix.net (relay3.de-cix.net [IPv6:2a02:c50:0:1e::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6451B340F; Mon, 8 Feb 2016 14:11:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,418,1449529200"; d="scan'208,217";a="2600209" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw011.de-cix.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2016 23:11:23 +0100 Received: from MS-EXCHANGE.for-the-inter.net (ms-exchange.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id DF40DB009A; Mon, 8 Feb 2016 23:11:21 +0100 (CET) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 8 Feb 2016 23:11:21 +0100 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1156.000; Mon, 8 Feb 2016 23:11:21 +0100 From: Thomas King To: "thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AQHRYFNEdqPcBxqvXEqcG3xGl9pa858iuo8A Date: Mon, 8 Feb 2016 22:11:21 +0000 Message-ID: <45C1D613-FB6A-40E8-AD5B-226B18D47EDC@de-cix.net> References: <45EB1B83-577F-43BB-9115-8D4AB6FEEC41@alcatel-lucent.com> In-Reply-To: <45EB1B83-577F-43BB-9115-8D4AB6FEEC41@alcatel-lucent.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.141.123] Content-Type: multipart/alternative; boundary="_000_45C1D613FB6A40E8AD5B226B18D47EDCdecixnet_" MIME-Version: 1.0 Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 22:11:38 -0000 --_000_45C1D613FB6A40E8AD5B226B18D47EDCdecixnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYSBjby1hdXRob3IgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGFzIGEg V0cgaXRlbS4gSXQgaGFzIHNldmVyYWwgYXBwbGljYWJpbGl0aWVzOiBJWFAsIERDLCBXQU4gdXNl IGNhc2VzDQpJIGFtIG5vdCBhd2FyZSBvZiBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0DQoNCkJl c3QgcmVnYXJkcywNClRob21hcw0KDQpGcm9tOiBCRVNTIDxiZXNzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmJlc3MtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAidGhvbWFzLm1vcmlu QG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPiIgPHRob21hcy5tb3Jp bkBvcmFuZ2UuY29tPG1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4+DQpEYXRlOiBGcmlk YXkgNSBGZWJydWFyeSAyMDE2IGF0IDE3OjU2DQpUbzogImJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJl c3NAaWV0Zi5vcmc+IiA8YmVzc0BpZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4+DQpDYzog ImRyYWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kQGlldGYub3JnPG1haWx0bzpkcmFmdC1z bnItYmVzcy1ldnBuLXByb3h5LWFycC1uZEBpZXRmLm9yZz4iIDxkcmFmdC1zbnItYmVzcy1ldnBu LXByb3h5LWFycC1uZEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94eS1h cnAtbmRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW2Jlc3NdIENhbGwgZm9yIGFkb3B0aW9uOiBkcmFm dC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0wMg0KDQoNCkhlbGxvIHdvcmtpbmcgZ3JvdXAs DQoNClRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBhZG9wdGluZyBkcmFmdC1z bnItYmVzcy1ldnBuLXByb3h5LWFycC1uZCBbMV0gYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uDQoN ClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9y dCBhZG9wdGlvbiBvciBub3QgKGluIHRoZSBsYXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0 aGUgcmVhc29ucykuDQoNClRoaXMgcG9sbCBydW5zIHVudGlsICoqRmVicnVhcnkgMTl0aCoqLg0K DQoqQ29pbmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhh cyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBS RkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNCj09PiAq SWYqIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBs ZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlv dSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCg0KVGhlIGRyYWZ0IHdpbGwgbm90IGJl IGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0 aG9yIGFuZCBjb250cmlidXRvci4NCg0KSWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhv ciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYg eW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQg aW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQpUaGFuayB5b3UsDQoNCk1hcnRpbiAm IFRob21hcw0KYmVzcyBjaGFpcnMNCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0wMg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0K VGhhbmsgeW91Lg0KDQo= --_000_45C1D613FB6A40E8AD5B226B18D47EDCdecixnet_ Content-Type: text/html; charset="utf-8" Content-ID: <35C25911A55E8540AD8362F6E22D3214@for-the-inter.net> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj5BcyBhIGNvLWF1dGhvciBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMg ZHJhZnQgYXMgYSBXRyBpdGVtLiBJdCBoYXMgc2V2ZXJhbCBhcHBsaWNhYmlsaXRpZXM6IElYUCwg REMsIFdBTiB1c2UgY2FzZXM8L2Rpdj4NCjxkaXY+SSBhbSBub3QgYXdhcmUgb2YgSVBSIHJlbGF0 ZWQgdG8gdGhpcyBkcmFmdDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj5UaG9tYXM8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdiBpZD0iIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JE RVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5H LUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JE RVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9z cGFuPkJFU1MgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmciPmJlc3Mt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDs8YSBocmVmPSJtYWls dG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tIj50aG9tYXMu bW9yaW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXkgNSBGZWJydWFyeSAyMDE2IGF0IDE3OjU2PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFp bHRvOmJlc3NAaWV0Zi5vcmciPmJlc3NAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRy YWZ0LXNuci1iZXNzLWV2cG4tcHJveHktYXJwLW5kQGlldGYub3JnIj5kcmFmdC1zbnItYmVzcy1l dnBuLXByb3h5LWFycC1uZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpk cmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZEBpZXRmLm9yZyI+ZHJhZnQtc25yLWJlc3Mt ZXZwbi1wcm94eS1hcnAtbmRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W2Jlc3NdIENhbGwgZm9yIGFkb3B0aW9uOiBk cmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0wMjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgZGlyPSJsdHIiPkhlbGxvIHdvcmtpbmcgZ3JvdXAs PC9wPg0KPHAgZGlyPSJsdHIiPlRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBh ZG9wdGluZyBkcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZCBbMV0gYXMgYSB3b3JraW5n IGdyb3VwIGl0ZW0uPC9wPg0KPHAgZGlyPSJsdHIiPlBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRo ZSBsaXN0IGFuZCBzdGF0ZSBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvciBub3QgKGluIHRoZSBs YXRlciBjYXNlLCBwbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQo8L3A+DQo8cCBkaXI9 Imx0ciI+VGhpcyBwb2xsIHJ1bnMgdW50aWwgKipGZWJydWFyeSAxOXRoKiouPC9wPg0KPHAgZGly PSJsdHIiPipDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRn ZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAo c2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCjwv cD4NCjxwIGRpcj0ibHRyIj49PSZndDsgKklmKiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50 IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBp bmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIu PC9wPg0KPHAgZGlyPSJsdHIiPlRoZSBkcmFmdCB3aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEg cmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0 b3IuPC9wPg0KPHAgZGlyPSJsdHIiPklmIHlvdSBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Ig b3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlv dSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGlu IGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy48L3A+DQo8cCBkaXI9Imx0ciI+VGhhbmsgeW91 LDwvcD4NCjxwIGRpcj0ibHRyIj5NYXJ0aW4gJmFtcDsgVGhvbWFzPGJyPg0KYmVzcyBjaGFpcnM8 L3A+DQo8cCBkaXI9Imx0ciI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zbnItYmVzcy1ldnBuLXByb3h5LWFycC1uZC0wMiI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc25yLWJlc3MtZXZwbi1wcm94eS1hcnAtbmQtMDI8L2E+PC9wPg0K PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KPC9wcmU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_45C1D613FB6A40E8AD5B226B18D47EDCdecixnet_-- From nobody Mon Feb 8 17:15:13 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C231B3EF8 for ; Mon, 8 Feb 2016 17:15:12 -0800 (PST) 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, 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 iNmhFi2qONcu for ; Mon, 8 Feb 2016 17:15:09 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:791]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F5B1B3EE9 for ; Mon, 8 Feb 2016 17:15:09 -0800 (PST) Received: from BY2PR05MB791.namprd05.prod.outlook.com (10.141.225.22) by BY2PR05MB792.namprd05.prod.outlook.com (10.141.225.28) with Microsoft SMTP Server (TLS) id 15.1.403.16; Tue, 9 Feb 2016 01:14:49 +0000 Received: from BY2PR05MB791.namprd05.prod.outlook.com ([10.141.225.22]) by BY2PR05MB791.namprd05.prod.outlook.com ([10.141.225.22]) with mapi id 15.01.0396.020; Tue, 9 Feb 2016 01:14:48 +0000 From: Nischal Sheth To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Thread-Index: AQHRWBFepeMmAPvlcUyD+4rRf/ojUp8i/mYA Date: Tue, 9 Feb 2016 01:14:48 +0000 Message-ID: <3AAC0AAF-5548-4916-A1B0-BC10B09C4C98@juniper.net> References: <56A72A83.10906@orange.com> In-Reply-To: <56A72A83.10906@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; BY2PR05MB792; 5:Pf2urea5NpHtFIvxe/1oS24civtEjH0e/5lKKMP98RfH+cQR9MkmILIk/vvlk6mw5nrkadMaVnSvlF6djicT4ROPQ4mQNDxD45rA10r5YJdQMIqlFta4nWBYexopXp9eUGn/eW1rJl0LMdZq1KozIg==; 24:0K1xOZZzoGm9ms8+Ar76aYVIx/0qGylD0iS4atoz6UmXtr5iv8bDNZGSh/hT14isPWcaXck2SaeRoBHe5BXtasFuXUedkKSpACgQEBqvWlk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB792; x-ms-office365-filtering-correlation-id: 40077401-d4ed-4fda-1227-08d330ee67a8 x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR05MB792; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB792; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(36756003)(54356999)(92566002)(5002640100001)(5008740100001)(2501003)(6116002)(1220700001)(3660700001)(230783001)(86362001)(102836003)(1096002)(76176999)(586003)(3846002)(82746002)(33656002)(50986999)(77096005)(2950100001)(99286002)(40100003)(106116001)(2900100001)(19580395003)(2906002)(189998001)(87936001)(5001770100001)(3280700002)(4326007)(5001960100002)(122556002)(10400500002)(66066001)(5004730100002)(83716003)(19580405001)(15975445007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB792; H:BY2PR05MB791.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2016 01:14:48.7695 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB792 Archived-At: Cc: "draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 01:15:12 -0000 Support as co-author. Am not aware of any IPR. -Nischal On Jan 26, 2016, at 12:12 AM, Thomas Morin wrote: > Hello working group, >=20 > This email starts a two-week poll on adopting > draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. >=20 > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). >=20 > This poll runs until **February 9th**. >=20 >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). >=20 > =3D=3D> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any re= levant IPR. >=20 > The draft will not be adopted until a response has been received from > each author and contributor. >=20 > If you 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 i= n conformance with IETF rules. >=20 > Thank you, >=20 > Martin & Thomas > bess chairs >=20 > [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Mon Feb 8 17:46:33 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471741B3F2A for ; Mon, 8 Feb 2016 17:46:31 -0800 (PST) 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 7v8DNQ3_evhk for ; Mon, 8 Feb 2016 17:46:29 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C89A1B3F28 for ; Mon, 8 Feb 2016 17:46:29 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-31-56b944dda1a3 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 47.08.32102.DD449B65; Tue, 9 Feb 2016 02:46:05 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Mon, 8 Feb 2016 20:46:26 -0500 From: Antoni Przygienda To: Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Thread-Index: AQHRWBFeRR0qgchge0CB9XP+TQzNBp8jBxkw Date: Tue, 9 Feb 2016 01:46:25 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F180EB9D159@eusaamb103.ericsson.se> References: <56A72A83.10906@orange.com> In-Reply-To: <56A72A83.10906@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonQfeuy84wg10nLCxWHJ/JbLFpQge7 xYZ9R9kcmD2WLPnJ5NHy7CSbx5fLn9kCmKO4bFJSczLLUov07RK4Mq7eWMVe8IO/ou29WQPj d54uRk4OCQETifu7JrNB2GISF+6tB7K5OIQEjjBKzNn3nBEkISSwjFGiZSsXiM0mYCFx+dtT ZhBbRMBb4sXbE0wgNrNAocThye/YQWxhgQCJKSeuM0LUBEqcun8VaCgHkG0k8eCzIEiYRUBF 4txziDG8Ar4SU3evhVqlLvHs1hcwm1NAQ2Lu2SNg4xmBbvt+ag3UKnGJW0/mM0HcLCCxZM95 ZghbVOLl43+sELaixL7+6ewQ9ToSC3Z/YoOwtSWWLXwNtVdQ4uTMJywTGMVmIRk7C0nLLCQt s5C0LGBkWcXIUVpckJObbmS4iREYNcck2Bx3MO7t9TzEKMDBqMTD+0F2Z5gQa2JZcWXuIUYJ DmYlEV6blzvChHhTEiurUovy44tKc1KLDzFKc7AoifPOdV4fJiSQnliSmp2aWpBaBJNl4uCU amBUOrr25utNSvekZpxuNElZ3h7qvi8sTJzt7vlazod3XixYpX2vYUtz2Pl/KWlO7oqvPkrK /PggbNDZsIx9pr+l4MoXt3aaJgiGrJJWnXD2Lv+OFH6uw9EmCQ+f68960W9W4LTr8hOO5vLk ng7+/if8pmttJvx9O5/zKp+2SmHvakP1gENBaU+UWIozEg21mIuKEwGsXyGwlgIAAA== Archived-At: Cc: "draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 01:46:31 -0000 Support, smart extension to the basic IR ... thanks=20 --- tony _____________________________________________ "Simple, clear purpose and principles give rise to complex and intelligent = behavior. Complex rules and regulations give rise to simple and stupid beha= vior."=20 --- Dee Hock=20 > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin > Sent: Tuesday, January 26, 2016 12:13 AM > To: bess@ietf.org > Cc: draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org > Subject: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-0= 2 >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting > draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. >=20 > Please send comments to the list and state if you support adoption or not= (in > the later case, please also state the reasons). >=20 > This poll runs until **February 9th**. >=20 >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that appli= es to > this draft, to ensure that IPR has been disclosed in compliance with IETF= IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > =3D=3D> *If* you are listed as a document author or contributor please re= spond > to this email and indicate whether or not you are aware of any relevant I= PR. >=20 > The draft will not be adopted until a response has been received from eac= h > author and contributor. >=20 > If you 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. >=20 > Thank you, >=20 > Martin & Thomas > bess chairs >=20 > [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Mon Feb 8 18:11:03 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2613D1B3F55 for ; Mon, 8 Feb 2016 18:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 G7FH_pBiTA35 for ; Mon, 8 Feb 2016 18:11:00 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360371B3EE6 for ; Mon, 8 Feb 2016 18:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2400; q=dns/txt; s=iport; t=1454983860; x=1456193460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZZUhqV+kyjeyQYNqQwEU7zuEvlpYTuAz0eDgs6JR80E=; b=kmmKVhAe+VosPXgBeJp9R8Qr272/Ayzd/Sr9CidVkHLxUStufe7IhcU9 +p7g1f6/JD1g/6V3wN4ddNNhidI+bT8Y2ddlHPSt9cw1RGrZk017sCjve 7HvXpFrKjitI66RF1Kh0IqodvpjkNAzNjgUgdaSGDXMVEg5b81LKEooOx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQALSrlW/xbLJq1ehAxtBohVsREBD?= =?us-ascii?q?YFmFwqFbAKBbRQBAQEBAQEBgQqEQQEBAQQBAQFrCwwEAgEIEQQBASgHJwsUCQg?= =?us-ascii?q?CBAENBYgbDr1uAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGEoQ3hAIRAYRYAQSWd?= =?us-ascii?q?QGFS4gEgVuEQ4hVjj0BHgEBQoNkaocjNHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,418,1449532800"; d="scan'208";a="649149941" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2016 02:10:58 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u192AvpT028856 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Feb 2016 02:10:57 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 21:10:56 -0500 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 21:10:56 -0500 From: "Satya Mohanty (satyamoh)" To: Antoni Przygienda , Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Thread-Index: AQHRYt8coZxj13ptY0WgBjW3Bj9bPg== Date: Tue, 9 Feb 2016 02:10:56 +0000 Message-ID: References: <56A72A83.10906@orange.com> <2E4BB27CAB87BF43B4207C0E55860F180EB9D159@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F180EB9D159@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.56.21] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 02:11:02 -0000 +1 Thanks, =8BSatya On 2/8/16, 5:46 PM, "BESS on behalf of Antoni Przygienda" wrote: >Support, smart extension to the basic IR ... > >thanks=20 > >--- tony >_____________________________________________ >"Simple, clear purpose and principles give rise to complex and >intelligent behavior. Complex rules and regulations give rise to simple >and stupid behavior." >--- Dee Hock=20 > >> -----Original Message----- >> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin >> Sent: Tuesday, January 26, 2016 12:13 AM >> To: bess@ietf.org >> Cc: draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org >> Subject: [bess] Poll for adoption: >>draft-rabadan-bess-evpn-optimized-ir-02 >>=20 >> Hello working group, >>=20 >> This email starts a two-week poll on adopting >> draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. >>=20 >> Please send comments to the list and state if you support adoption or >>not (in >> the later case, please also state the reasons). >>=20 >> This poll runs until **February 9th**. >>=20 >>=20 >> *Coincidentally*, we are also polling for knowledge of any IPR that >>applies to >> this draft, to ensure that IPR has been disclosed in compliance with >>IETF IPR >> rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >>=20 >> =3D=3D> *If* you are listed as a document author or contributor please >>respond >> to this email and indicate whether or not you are aware of any relevant >>IPR. >>=20 >> The draft will not be adopted until a response has been received from >>each >> author and contributor. >>=20 >> If you 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. >>=20 >> Thank you, >>=20 >> Martin & Thomas >> bess chairs >>=20 >> [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Feb 9 01:13:53 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67941A872D; Tue, 9 Feb 2016 01:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 AZ24sYzI8mfI; Tue, 9 Feb 2016 01:13:48 -0800 (PST) Received: from de-cix.net (relay3.de-cix.net [IPv6:2a02:c50:0:1e::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C9D1A873A; Tue, 9 Feb 2016 01:13:47 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.22,420,1449529200"; d="asc'?scan'208"; a="2600800" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw011.de-cix.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2016 10:13:45 +0100 Received: from MS-EXCHANGE.for-the-inter.net (ms-exchange.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id CBBDAB009A; Tue, 9 Feb 2016 10:13:44 +0100 (CET) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 9 Feb 2016 10:13:44 +0100 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1156.000; Tue, 9 Feb 2016 10:13:44 +0100 From: Daniel Melzer To: "thomas.morin@orange.com" Thread-Topic: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AdFgNjTaXB7JK7ocQLKDXemsWvLl+QC25aiA Date: Tue, 9 Feb 2016 09:13:44 +0000 Message-ID: <99D23307-D988-4786-B7B0-7FF81FB53E75@de-cix.net> References: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> In-Reply-To: <20598_1454691411_56B4D453_20598_5221_54_m7cqvm0qi93kq9u3ubuc15pr.1454691102503@email.android.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.141.200] Content-Type: multipart/signed; boundary="Apple-Mail=_AFD08B95-A9E7-467A-870B-6446B01AB3BE"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@ietf.org" , Daniel Melzer , "bess@ietf.org" Subject: Re: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 09:13:51 -0000 --Apple-Mail=_AFD08B95-A9E7-467A-870B-6446B01AB3BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support this draft as co-author. I=E2=80=99m not aware of any IPR = relating to the draft. Best regards, Daniel > Am 05.02.2016 um 17:56 schrieb thomas.morin@orange.com: >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting = draft-snr-bess-evpn-proxy-arp-nd [1] as a working group item. >=20 > Please send comments to the list and state if you support adoption or = not (in the later case, please also state the reasons). >=20 > This poll runs until **February 19th**. >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that = applies to this draft, to ensure that IPR has been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details). >=20 > =3D=3D> *If* you are listed as a document author or contributor please = respond to this email and indicate whether or not you are aware of any = relevant IPR. >=20 > The draft will not be adopted until a response has been received from = each author and contributor. >=20 > If you 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. >=20 > Thank you, >=20 > Martin & Thomas > bess chairs >=20 > [1] https://tools.ietf.org/html/draft-snr-bess-evpn-proxy-arp-nd-02 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 -- Daniel Melzer Manager Network & Data Centre DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | = Germany | www.de-cix.net Phone +49 69 1730902 25 | Fax +49 69 4056 2716 | = daniel.melzer@de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135 --Apple-Mail=_AFD08B95-A9E7-467A-870B-6446B01AB3BE 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 - http://gpgtools.org iQIcBAEBCAAGBQJWua3JAAoJEA1ao379WaNX358P/39UBfi8F7OfxkDu6CLaSEMF ZADOZT0G3vYgqObqsqiL4Jedd9zHH3YpVqKCgehCjl1IjVuDx7wxUvGSNzX7vCOZ o1vRHF5t4xPFZtOQRX+vKwDJUVn9Hm6gDh+itDS/OzWcTlwYkQBRuwlySJByFOXe 057Uz4SjVA/CZO65bPTHMd04T1+zUFKXuxLWTmBzITakIt0E7V2twqw928L+8KFD S24D9oXnf6gdboBeAgr8j9IqmMhZjlBJ+tKQehV8RkpvPiOWrATYF4hJvfRHHyKr GVOxRnhs0ulynBAQAUaiFpmTx2IGFCCkDfJuv7hPXMGwJgQqwr/8vpbw7Jtw0bkp G9uz9rGvg8mOnaHzWCnAcyE4m9CkHwMVNtou8JXm7G6uEDsUcjXzFmJFtuxH0QqA jNB/v/Prdw5cAYxXfZDNdlr44xpNXfZIKm4/jq8eNmwfhCkZAzxubIw14ub0K+60 XjywESVcpE8AW5zMF7sSDZBh1L4vHMpFT/eZJa358uRyFmAw6T8uE57iXAuBHQY3 QzCgIYF/uqqdZeT8lUM3yK5ij/ZT5f6wFTBcv6EX70asnG1RbIxZQGHL3vRnq8pq puiaQw4lfrmSMN88Hz2LbuiFJK6EWO3psiqKki5egEP3suSuZyRXF1MfCRrCy60s Nqz5diBZb3cAAHA0rcIu =viGE -----END PGP SIGNATURE----- --Apple-Mail=_AFD08B95-A9E7-467A-870B-6446B01AB3BE-- From nobody Tue Feb 9 23:26:34 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E971B37D3 for ; Tue, 9 Feb 2016 23:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 sHvkP7ZxAYK4 for ; Tue, 9 Feb 2016 23:26:31 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AED1B37CF for ; Tue, 9 Feb 2016 23:26:30 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-29-56bae60ff909 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id A6.29.32102.F06EAB65; Wed, 10 Feb 2016 08:26:07 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Wed, 10 Feb 2016 02:26:29 -0500 From: Jeff Tantsura To: Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Thread-Index: AQHRY9RbISSrfAp2e0KzVy619Bt4Bg== Date: Wed, 10 Feb 2016 07:26:27 +0000 Message-ID: References: <56A72A83.10906@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160109 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-ID: <6202DF1F6942FD4BB927340BE6D32E88@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyuXRPuC7/s11hBvPu6FusOD6T2WLThA52 iw37jrI5MHssWfKTyaPl2Uk2jy+XP7MFMEdx2aSk5mSWpRbp2yVwZdx48Yux4I5gxbb3v9ga GBcIdjFyckgImEjMn/eTCcIWk7hwbz1bFyMXh5DAEUaJr/t/MncxcgA5yxklnteA1LAJGEj8 /3acBcQWEfCWePH2BFgvs0ChxOHJ79hByoUFAiT6V5lBlARKnLp/lQ3C1pNYP+UbWAmLgKrE kQ4hkDCvgL3EvLt/GEFsIYFkiQkLPrGD2JwCbhJH3q0Dm84IdNn3U2ugNolL3HoyH+piAYkl e84zQ9iiEi8f/2MFsUUFdCU+Xt/HDhFXkpjz+hrYI8wCmhLrd+lDjLGWmLS9jx3CVpSY0v2Q HeIcQYmTM5+wTGCUmIVk2yyE7llIumch6Z6FpHsBI+sqRo7S4oKc3HQjw02MwLg7JsHmuINx b6/nIUYBDkYlHl4D811hQqyJZcWVuYcYJTiYlUR4128ECvGmJFZWpRblxxeV5qQWH2KU5mBR Eued67w+TEggPbEkNTs1tSC1CCbLxMEp1cA4p6r76bpfgY/dmphrhe7s6jtzzqFzHv/v+ocd 5ame9zLCeFZNPMDaVzX/7y6+WV3rYj9y57/5fk5nd4FHEuOJCUlbpBo+utmbH6j6HG09Z8nf lEcuv6auLIvYvyR5kuAqzeqqsEuJ971n8K6pj1hjpGrn+2aO3jYdttU337ALblhw5Hze0dQD SizFGYmGWsxFxYkAPnYJB7cCAAA= Archived-At: Cc: "draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 07:26:32 -0000 WWVzL3N1cHBvcnQNCg0KQ2hlZXJzLA0KSmVmZg0KDQoNCg0KDQoNCj5PbiAyNi8wMS8xNiAwOTox MiwgIkJFU1Mgb24gYmVoYWxmIG9mIFRob21hcyBNb3JpbiIgPGJlc3MtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgdGhvbWFzLm1vcmluQG9yYW5nZS5jb20+IHdyb3RlOg0KPg0KPj5IZWxs byB3b3JraW5nIGdyb3VwLA0KPj4NCj4+VGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xs IG9uIGFkb3B0aW5nDQo+PmRyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLW9wdGltaXplZC1pci0wMiBb MV0gYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uDQo+Pg0KPj5QbGVhc2Ugc2VuZCBjb21tZW50cyB0 byB0aGUgbGlzdCBhbmQgc3RhdGUgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3INCj4+bm90IChp biB0aGUgbGF0ZXIgY2FzZSwgcGxlYXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KPj4NCj4+ VGhpcyBwb2xsIHJ1bnMgdW50aWwgKipGZWJydWFyeSA5dGgqKi4NCj4+DQo+Pg0KPj4qQ29pbmNp ZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0 aGF0DQo+PmFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVu IGRpc2Nsb3NlZCBpbg0KPj5jb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNz IDM5NzksIDQ4NzksIDM2NjkNCj4+YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo+Pg0KPj49 PT4gKklmKiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRv ciBwbGVhc2UNCj4+cmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9y IG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSANCj4+cmVsZXZhbnQgSVBSLg0KPj4NCj4+VGhlIGRy YWZ0IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZl ZCBmcm9tDQo+PmVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4+DQo+PklmIHlvdSBhcmUg bm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIA0KPj5l eHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBo YXMgbm90IHlldCANCj4+YmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1 bGVzLg0KPj4NCj4+VGhhbmsgeW91LA0KPj4NCj4+TWFydGluICYgVGhvbWFzDQo+PmJlc3MgY2hh aXJzDQo+Pg0KPj5bMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhYmFkYW4t YmVzcy1ldnBuLW9wdGltaXplZC1pci0wMg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+QkVTUyBtYWlsaW5nIGxpc3QNCj4+QkVTU0BpZXRmLm9yZw0KPj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkJFU1MgbWFpbGluZyBsaXN0DQo+ QkVTU0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVz cw0K From nobody Wed Feb 10 03:34:18 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79CD1A1B8C for ; Wed, 10 Feb 2016 03:34:16 -0800 (PST) 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 XzP2PYE4KjnV for ; Wed, 10 Feb 2016 03:34:14 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79C91A1B7F for ; Wed, 10 Feb 2016 03:34:13 -0800 (PST) Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1713.namprd05.prod.outlook.com (10.163.120.16) with Microsoft SMTP Server (TLS) id 15.1.403.16; Wed, 10 Feb 2016 11:34:12 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0403.017; Wed, 10 Feb 2016 11:34:12 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 Thread-Index: AQHRY9RgiywkP3+Ec0ajDcfNS0On9p8lJibw Date: Wed, 10 Feb 2016 11:34:12 +0000 Message-ID: References: <56A72A83.10906@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1713; 5:aRomdpLQTDBJ15i8QGCAPJHVHE1x/CmL0L98SXv2OuTfxHa7YVF3rupTCRxq9xca4Txtyz1AP7e33hvBqtxQEa5mBQeF17jxtRrT6+5p8Ds5hFYwdwiCkL2m6M3yc1+Mrbb2YHBQW3rZ3ayt7iY08A==; 24:FtRiGgplEylQaE3EpUlsZ8CxF3UEEn1h35dcgpbUhjc81686zWozGASyNtCmtGBnNZGbdEoPen1miiRO1h3n7t0C+Rlbp78xewUFU59zylI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1713; x-ms-office365-filtering-correlation-id: 5755e418-3cc6-4d0d-c921-08d3320e1922 x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR0501MB1713; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1713; x-forefront-prvs: 0848C1A6AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(5003600100002)(2501003)(122556002)(1220700001)(76576001)(10400500002)(5001770100001)(586003)(77096005)(74316001)(19580395003)(87936001)(40100003)(50986999)(54356999)(3846002)(189998001)(1096002)(92566002)(76176999)(3280700002)(5001960100002)(86362001)(19580405001)(5002640100001)(2906002)(6116002)(15975445007)(3660700001)(102836003)(4326007)(230783001)(5004730100002)(2950100001)(11100500001)(99286002)(2900100001)(106116001)(5008740100001)(66066001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1713; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2016 11:34:12.1544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1713 Archived-At: Cc: "draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 11:34:17 -0000 Support. >=20 > >On 26/01/16 09:12, "BESS on behalf of Thomas Morin" bounces@ietf.org on behalf of thomas.morin@orange.com> wrote: > > > >>Hello working group, > >> > >>This email starts a two-week poll on adopting > >>draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. > >> > >>Please send comments to the list and state if you support adoption or > >>not (in the later case, please also state the reasons). > >> > >>This poll runs until **February 9th**. > >> > >> > >>*Coincidentally*, we are also polling for knowledge of any IPR that > >>applies to this draft, to ensure that IPR has been disclosed in > >>compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > >>and 5378 for more details). > >> > >>=3D=3D> *If* you are listed as a document author or contributor please > >>respond to this email and indicate whether or not you are aware of any > >>relevant IPR. > >> > >>The draft will not be adopted until a response has been received from > >>each author and contributor. > >> > >>If you 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. > >> > >>Thank you, > >> > >>Martin & Thomas > >>bess chairs > >> > >>[1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>BESS mailing list > >>BESS@ietf.org > >>https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ > >BESS mailing list > >BESS@ietf.org > >https://www.ietf.org/mailman/listinfo/bess > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Thu Feb 11 07:18:35 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94381B331E; Thu, 11 Feb 2016 07:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 dJ47OFcMtBhn; Thu, 11 Feb 2016 07:18:29 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1242F1B334A; Thu, 11 Feb 2016 07:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=592; q=dns/txt; s=iport; t=1455203909; x=1456413509; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6Cfwcql29YhQS+SnkfdJqd0AAy8TnNuK7IEeenhnF08=; b=BxmhuH+8Fuf1EAJoGMiZ+hxKzLgYIhDHnz+DPDTb0JP1Nm9Qo+fNfKtV 4ykZXkUFe5drJE0u7b+emREuF2Qr9aNDIb7ROa/Wn+PzNske86pXbk49R 1tMUsTSMV19u61/WjWPB5N3qrioDQtuOBdEMCoQJfJpInc2ev/zhOvrcs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAgD3pLxW/4gNJK1egzqBPwaIVal6h?= =?us-ascii?q?yABDYFnhg0CgTE4FAEBAQEBAQGBCoRCAQEEOj8QAgEINhAyJQIEAQ0FiBrBDgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARWGEgGENYhsAQSNJ4VHhAkBjVKBXYRDiFWOP?= =?us-ascii?q?QEeAQFCgimBPGqHV3wBAQE?= X-IronPort-AV: E=Sophos;i="5.22,431,1449532800"; d="scan'208";a="237272587" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 15:18:28 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1BFIS1J021460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 15:18:28 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 09:18:27 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 09:18:27 -0600 From: "Alvaro Retana (aretana)" To: Eric C Rosen , "mpls-chairs@ietf.org" Thread-Topic: [mpls] draft-rosen-idr-rfc3107bis-00 Thread-Index: AQHRTi3mrZ8QLyqAlEOXDyS5JPxiFp8nM0yA Date: Thu, 11 Feb 2016 15:18:27 +0000 Message-ID: References: <5696933E.1080802@juniper.net> In-Reply-To: <5696933E.1080802@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] [mpls] draft-rosen-idr-rfc3107bis-00 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 15:18:31 -0000 On 1/13/16, 1:11 PM, "mpls on behalf of Eric C Rosen" wrote: Hi! >While I put "idr" in the name of the draft, it's not completely >obvious which WG should own this draft (assuming it progresses) Deborah and I had a quick chat about this point and we think that (if it progresses) this document should belong in mpls -- if for no other reason just because RFC3107 was produced there. mpls-chairs: If this document progresses, please make sure that both idr and bess are cc'd on adoption and WGCL. Thanks! Alvaro. From nobody Thu Feb 11 14:44:19 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9E01B3087; Thu, 11 Feb 2016 14:44:07 -0800 (PST) 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 KlTtYqtQi_62; Thu, 11 Feb 2016 14:44:03 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717521B2A28; Thu, 11 Feb 2016 14:44:03 -0800 (PST) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.152] (66.129.241.13) by CY1PR0501MB2155.namprd05.prod.outlook.com (10.164.3.153) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 11 Feb 2016 22:44:00 +0000 To: "Alvaro Retana (aretana)" , "mpls-chairs@ietf.org" References: <5696933E.1080802@juniper.net> From: Eric C Rosen Message-ID: <56BD0EAC.4020700@juniper.net> Date: Thu, 11 Feb 2016 17:43:56 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CO2PR05CA021.namprd05.prod.outlook.com (10.141.241.149) To CY1PR0501MB2155.namprd05.prod.outlook.com (25.164.3.153) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2155; 2:M74SHcmnWo/e5j/GT+U/IqLavaKxFwGkhhSHOqraWdjz7+yCMXiaj49dwIeIn7QWz76qD0z+C4CesunqvX8SWUT/0Ggh5Tdu021I5LPoyJ+DIynwYfME+wMWsk2IqeIA5nAEu29LorOIeziF2MXPZA==; 3:cZsyME/AEU4Gxp20oY0DJwiHwjmeseKI4OAYjcKYbikci77ATk7HrxHGDkXvPKxQzZ2Vi3hCRlQ9N6DmL+jv0W29HV58aBoln1NynhdRH5Jx3INUVbKG+omIIDr6EPe2; 25:FDeD7K4XtTMQ2sc5IPPVhlWu0oeTUSf2FOK94gDmo9IDJAwHlkys5e67grq0Yn49V/jcfP42IHehf099JTxCd1h3JJc30K6UjQfnmcOVLUh+WxCGAAKQb0/oYC/4ko5rIZ0pvxF+zV7LJiuBhhoX4VpvkSHlSnbj0lTnEhJ8bjh46yxP+J+4rjP+HCLKV6Hj0+MBZ1W7uAKO/GB3sJwGUuJ1Vvx9tkCqXouWiXzVYQ3miJCXYp2Q04LDLFsmCv0alKzbW9uRZddSbG3PXpueBqbRKPPkPnsEDmComGcyMrY/moYVsQfW/0Z37ifeY5Ou X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB2155; X-MS-Office365-Filtering-Correlation-Id: 93efef9c-4bd5-4b0d-5d53-08d33334d66b X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2155; 20:r9q0ozJv6P17RGJIazrAI4WRG5eCEtvSHgTqxj6O3dUddbmZfzd0Qd/Gybb8yXwCE9H/6pGPxzXrTWkAnocEC+JeKZeCRqe7PD7ya0Cs7eSzJF8mFCnb/GrNsmB95JzIVCUA2MOXPTPk5YBOwi/x30PeIJevq/yyeH+8475Ro15WKz/DCodVFuz6iYExv9jWD72KxqpET2R0z5DKfHZgheBMbQRYH8A64vbK8LCiIknRmrr6ZEXi0hraoiP/ouTczNsKJ5Izz553hJ90RvVuB8JD5DDOFcOP5jBgORupSVn8PG5MQB7tcd1yeccYOI9zfGUDFMhjPv/0fK2sazJfHXNIjRha835pzNAmZnq+KBAz5tix6jtQy6HoszlNnB0eoOHbqEjeQ4sKMVXi4A8Xq+mMWr3mGGSJt7FxMacF3WjvaG5kMJjMTNq1uck9BmNMHMSB7GguO2vkTz4MUmqNnXPxaD9YRHRuy1KTTdelRqG9VlCjX7QaqczWxRM0VFkP; 4:ixr2CVqVmLDZwnsYwwSnFpogNYRU4hRfOQDvwC/S4+csU0zV85CMDCIrMRliK8vhHD2RY8yS0fA9jznzIW17eVl63uwaIp1geLFWaoUBZ3bwMuQUr4bop3qb6ZLcMr8YpfgY01BcDteEFo4rJv6TiD0X6u/ADU6F9LnP4knbPTu2mD4k4WVL2xO+r1hFn8oyRr0/Pc5ny0ZMjJpl9aI69TBbZCH8NCljeLBGTS+9h9X1YlkyC8ZQu+f2fUvI/DToyJySUwRQGasnwhwQgQ67IQOQjizL8/rmQaKRVHTUqb/7PJbgmyxGguzbdCKXSZ5tzeGTnrYQEBkUuW7cnKS4m1Cfj/UPpf5mDhfaHJa/Jdb2yTsE5Gg4vGKhGaPHxFU2pmnH9hORXDzOHbqYKQpJ5N4yAnEoePz6lHeWGgEVR9c= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2155; X-Forefront-PRVS: 08497C3D99 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174004)(24454002)(377454003)(122386002)(230700001)(5008740100001)(19580395003)(19580405001)(40100003)(64126003)(33656002)(230783001)(50466002)(87266999)(586003)(86362001)(87976001)(77096005)(6116002)(3846002)(59896002)(2950100001)(92566002)(83506001)(2501003)(23746002)(42186005)(5004730100002)(50986999)(5001960100002)(1096002)(189998001)(47776003)(54356999)(36756003)(65816999)(66066001)(76176999)(4001350100001)(65806001)(65956001)(2906002)(5001770100001)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2155; H:[172.29.35.152]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR0501MB2155; 23:J5S2vFY1+5O4rHtlqtClz5PkSd2n7JWQ2AS?= =?Windows-1252?Q?7ZXpdZLg5v7hvB1xzExTsdhks3kcQwGFGtILFEI9/VvS8VeFbzeWNZ3y?= =?Windows-1252?Q?OaMMd/4VZ/UULM2nWetYIVzNZrBpel66u+C+ZLa3wC4TJcJIEBsCoKkO?= =?Windows-1252?Q?P5uPv3d27Ujzooyx2XWgmj+dR+IdBb6+9YsAINCRgVcr3JEgYCOe8l3M?= =?Windows-1252?Q?8OZ7F/yz0BMEsbh7vwHnu8ojaApQ5RVtwz6QpQWBq57qTahpUHHGaHYg?= =?Windows-1252?Q?X29nyZYW7ILYQ5s7XWqPUprp1Io/Pz3bybrglZZZe8hDDjXhF72vKvmN?= =?Windows-1252?Q?ictmeQumMcxPdOZag9LGpRmGAAMxu4FwgZwC7jrgSSTw3kWkQPr1NodG?= =?Windows-1252?Q?hVmfWV7C0wvAdN/Y4E5+bg9W4242OMfP/qaOzJR5kpawVMlxE24cRhaY?= =?Windows-1252?Q?317zjPOPp7GUEIbg7MoHlxnTzrti3a6iFH70BGRNPAKNFRFTKfirxekk?= =?Windows-1252?Q?d5Swt8iucFIhueBcWqoeTafcZhd7yAxPsJxCTDc3ooLjqNbgKdOjqIM4?= =?Windows-1252?Q?EmLEgYBlpOodWjioxFIVOitns6+JOUe9xiLqLaxaW4UFe3IaxPlo8ynd?= =?Windows-1252?Q?NkOK1ruN/g6D5HA5WQ6fHoxcVgHEygAsqgPlOw7cpTHQ3/PptCU+VgNE?= =?Windows-1252?Q?pkR8iy0A/K+Lx3NjyRBFA2b/UGUJxMXhIyt6yraQ4RVGYzSRu+3j/fwc?= =?Windows-1252?Q?wSEL/tY9dsK2/fthUW43zSEcXWptQyuqHTOpngWSQfWvhENYeBm5/K+l?= =?Windows-1252?Q?eH0axxYi2kjNWfsQDVAAPheeKfKkRAbyFCoFzeClQiYYEyJ8ho6nx3YG?= =?Windows-1252?Q?C8vZpKbO+l79fLxbpNxdckeaUMI4zzqrfAKMUvB6eI7dQT4KERkl8jGB?= =?Windows-1252?Q?Mu+qNv+YqJgVBrjIboCp4oR9LG6nEywddzBOe8P5fGWs3KdXY8oLxuGr?= =?Windows-1252?Q?RtKY6XxBYxpj4NiAN1/0iGMS9GrnN8U/udCumboSC8wIqO3ALevBhpr/?= =?Windows-1252?Q?R+3ngcqttH2uCKuw7n6mezdFpshUyeHodKgivK7ivbISxDwz/ualUGVe?= =?Windows-1252?Q?egin1ZQGlWp16Ew6/IAfKo8DnyFW7bLyWVuv6BCDZ139YSBecRqlCg+t?= =?Windows-1252?Q?nMjT8Z7by/pVmk3/sWvNR/oaLOO1PyNM3dM/0cmdjqwOofMDTQkLWY+4?= =?Windows-1252?Q?3yWTSa2u++pFsx9mJSxm3ZwxrRFedTzLirpp42pe7yK7NdwfuB0lJGrG?= =?Windows-1252?Q?uJsgg?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2155; 5:Q2aT1JjsVaFKZCNttKPYL9nwWSmsPrpOOOrSzmRmb1Uoot7HxEQTj+McDzPK6EHa21FDD6Zzi58nnb54Qbs3KE0PthGxUUg+zpaUKpfTIUEF6DrzkFwv7Fige46ewGNusaNVrVVBGgP94lphcgoLxQ==; 24:zc7M0rXIN36Pgl7SyY6MLhXZ2DYavNCGZ8S0cdDVuzcXuL89P3cJHspgBUSNyj4S6PQ4eQWrsjeRmiK6jaKYtOwo8na1CaHzdF1h6jBqWig= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2016 22:44:00.6485 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2155 Archived-At: Cc: "rtg-ads@ietf.org" , "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] [mpls] draft-rosen-idr-rfc3107bis-00 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:44:08 -0000 I've reposted the draft as draft-rosen-mpls-rfc3107bis-00. On 2/11/2016 10:18 AM, Alvaro Retana (aretana) wrote: > On 1/13/16, 1:11 PM, "mpls on behalf of Eric C Rosen" > wrote: > > Hi! > >> While I put "idr" in the name of the draft, it's not completely >> obvious which WG should own this draft (assuming it progresses) > Deborah and I had a quick chat about this point and we think that (if it > progresses) this document should belong in mpls -- if for no other reason > just because RFC3107 was produced there. > > mpls-chairs: If this document progresses, please make sure that both idr > and bess are cc'd on adoption and WGCL. > > Thanks! > > Alvaro. > From nobody Thu Feb 11 15:38:46 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595811A6FBA; Thu, 11 Feb 2016 15:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 nL6TDz_2f0ww; Thu, 11 Feb 2016 15:38:26 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FD91B3C7F; Thu, 11 Feb 2016 15:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6146; q=dns/txt; s=iport; t=1455233906; x=1456443506; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=56j+8vLztHIY8UyAk5Lux4jqWX6h7z3uE1/rNEDKk8A=; b=jiRouNYSycAymZ9i/nhEYPXf+NMsQAIowWgop/yeWHklYBV0wlxAc5k+ KIoCdYFopo9dTS9txp13Sut+vLITvpIp38x0Jg7CPnCIIsPC27yrLH/Lu TRajnZGBYIC0AqJ6rFTCUFbCRKjth5c7LfzuWoRRXGApO19h+THU2AMis A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgD2Gr1W/5pdJa1egzpSbQaIVbEuD?= =?us-ascii?q?oFnFwqFbAKBNjgUAQEBAQEBAYEKhEEBAQEDAQEBASBLCwULAgEIGCoCAicLJQI?= =?us-ascii?q?EDgUOBod+CA6yM48IAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQQEhhKBbAiCQocyK?= =?us-ascii?q?4EPBZZ3AYJ/gWSIb451jj0BHgFDggIZgUpqh1d8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="asc'?scan'208";a="236741421" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 23:38:25 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1BNcPIF004716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 23:38:25 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 18:38:24 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 18:38:24 -0500 From: "Carlos Pignataro (cpignata)" To: Eric C Rosen Thread-Topic: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt Thread-Index: AQHRQYNgm76iX7yesESh/1GkNtrtOp8oG2EA Date: Thu, 11 Feb 2016 23:38:24 +0000 Message-ID: References: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> <56815342.7030609@juniper.net> In-Reply-To: <56815342.7030609@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.228.25] Content-Type: multipart/signed; boundary="Apple-Mail=_25EBF653-7EAA-4C34-8CC1-C3202866254B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "bess@ietf.org" Subject: Re: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 23:38:31 -0000 --Apple-Mail=_25EBF653-7EAA-4C34-8CC1-C3202866254B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Eric, Thanks for sending this out =E2=80=94 I am interested in this document, = and will give it a critical review (in particular the sections you call = out below). In the mean time, however, I wanted to send a few high-level comments = (prepended with =E2=80=9CCMP=E2=80=9D) from scanning through it. I hope = these are useful. 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types This section defines Tunnel Encapsulation sub-TLVs for the following tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], [RFC4023]). CMP: More comments below, but I am a bit confused about the need to = include MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for = example. CMP: A couple of editorial comments as well: For GRE, I think you also = need to cite RFC 7676 (GRE over IPv6) CMP: Also, having this document Obsolete RFC 5512 effectively also = orphans a number of Tunnel types and sub-TLVs. For example, Tunnel Types = values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel = Authenticator sub-TLV. I do not know if the answer is to also have that = incorporated (useful parts as you say) and obsoleted. Maybe not, maybe = it does make sense given it is a short doc, which would lead to a = complete self-contained set of Tunnel types. 3.2.4. L2TPv3 =E2=80=A6 Cookie: an optional, variable length (encoded in octets -- 0 to 8 octets) value used by L2TPv3 to check the association of a CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8 3.2.7. MPLS-in-GRE CMP: This seems to be an example and not a separate encapsulation type. = This is GRE Type, with MPLS as protocol sub-TLV. I see that the section = says: While it is not really necessary to have both the GRE and MPLS-in-GRE tunnel types, both are included for reasons of backwards compatibility. CMP: I will also note that having two different ways of doing the same = thing (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us = away from interop., and that there does not seem to be MPLS-in-GRE = defined in any RFC (so it seems like potentially a good time to = rationalize instead of perpetuate). My $0.02 only. CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we = interop the two types of =E2=80=9C MPLS-over-GRE=E2=80=9D? Should an = example be also added about MPLS-over-L3TPv3? 3.3.1. IPv4 DS Field CMP: Why not also define this for IPv6? 3.3.2. UDP Destination Port CMP: One additional thought. Obsoleting RFC 5512 also removes the anchor = from RFC 5640 =E2=80=94 that is not a terrible deal in itself, but is = there also an opportunity to generalize the Load-Balancing approach = thereby defined to also include the new encapsulations=E2=80=99 LB, = UDP-based (port as the LB Field), etc? I hope these are clear and useful =E2=80=94 Thanks! =E2=80=94 Carlos. > On Dec 28, 2015, at 10:20 AM, Eric C Rosen wrote: >=20 > The -01 revision of draft-ietf-idr-tunnel-encaps has the following = changes from the -00 revision: >=20 > - By popular request, it has been written in such a way as to obsolete = RFC5512. This means that anything useful in RFC5512 had to be = incorporated into the new draft. I would welcome opinions on whether = this was done correctly. >=20 > - Two new sub-TLVs are specified: "MPLS Label Stack" and = "Prefix-SID". I would welcome opinions on whether these are useful or = not. (I'm pretty sure that the first is useful, the second is more = speculative.) >=20 > - If you are familiar with deployed uses of the Encapsulation Extended = Community, the Color Extended Community, or the Router's MAC Extended = Community, it may be worth checking section 4 to make sure that the = draft does not introduce any problems. >=20 > - I wish more folks would take a critical look at section 8, which is = primarily about the use of VXLAN/NVGRE/VXLAN-GPE together with labeled = address families. >=20 > I would also be interested in hearing if anyone has an opinion on the = utility of using this sort of mechanism to signal IPsec tunnels. Once = RFC 5512 is obsoleted, RFC 5566 ("BGP IPsec Tunnel Encapsulation = Attribute") will need to be revised. It might be possible to generalize = that in such a way as to facilitate the secure interconnection of two = private ASes across the public Internet. Comments on whether RFC 5566 = takes a reasonable approach would be welcome. >=20 >=20 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --Apple-Mail=_25EBF653-7EAA-4C34-8CC1-C3202866254B 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 - http://gpgtools.org iQIcBAEBCAAGBQJWvRsmAAoJEIXgpQGOZny95MIP/09bX9/OwVR9f4c0GuE+B3bR lNdtd4oTW054RjrHBdRJyKEpNpsv0iL/Dwnk6L5mrqI+5z3rsubbExWGYb+rOirC 1TZ82kmE/9/cflHVS79djcfHb5lYAAfqDhmNe87fC2DRcr5y86DXyoYGc79ffZmZ 6tI3xwPJmdEl6ix81O56NOL63gXMamtGw0E77gGORCcXTbyRWbdUmrHE25DYwuC+ bG+pME+/U6XYRYUMQsOBEryIByy/B29RSdf+j3Ma+2AYojW42/v2hATxEkurVDla fqTYugCkx9Yrh6b1MbpAYiPz2w1HanRTWYxBHewUiLZJxz6eAdvw/edPe0WOwgSI 9I8vPx9I/0IGLBGg7Xh0o2rILyq8caAYWUpd3l8JDYMJ5+N80zwL1NLwtZi9ecEY BVtADC/ExPaPcue9vn7aUjwqg6TraW2+wmJMyCr1/0bq9pLSbvDdFaVF7wbKZ4+0 Yw6+mYXS+tqZpijPHleZQKnaV+hfVW2H/8B+Lzt1JtdUJEtNa020NQ3YzcRBeCo0 Vzjbe9+KFuuxEJmOw/qxgHS90yAmtmjorzdH6H2ZuE/1n09ScEUygLIF1SqCFwmF e+f5NGnT8vpPTK2L30uTnVLKy9YR0W+NWuVLN7WAQZR/yByfBmlrJEI3xnSCZbvi jPXCibaTA/UhfWnG656O =rR1X -----END PGP SIGNATURE----- --Apple-Mail=_25EBF653-7EAA-4C34-8CC1-C3202866254B-- From nobody Mon Feb 15 09:22:42 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F0B1A8A4C; Mon, 15 Feb 2016 09:22:41 -0800 (PST) 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, 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 z9y_GJnRHH8x; Mon, 15 Feb 2016 09:22:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8B71A89D3; Mon, 15 Feb 2016 09:22:33 -0800 (PST) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.136] (66.129.241.11) by CY1PR0501MB2154.namprd05.prod.outlook.com (10.164.3.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 15 Feb 2016 17:22:10 +0000 To: "Carlos Pignataro (cpignata)" References: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> <56815342.7030609@juniper.net> From: Eric C Rosen Message-ID: <56C2093D.7080800@juniper.net> Date: Mon, 15 Feb 2016 12:22:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BY2PR13CA0036.namprd13.prod.outlook.com (25.162.223.46) To CY1PR0501MB2154.namprd05.prod.outlook.com (25.164.3.152) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2154; 2:EKO5RYP6SSQfIC39WuY9c+4/mGwUe+LdwBCb28HFQX14YDTJbibr9m3mnoBXFLiVyb9nPttUEhUJBo8PP2IWHbv9KiTQDkL8GBOmJgQntY7a1T1MtH2n0pfAvE5/Q6sri8WIViMPwaOAOdBTtzas7g==; 3:kY1nddgYJQFZN4GzsV73gh6W2TUhgRlE/cQ4J6tBR/O8ZKI87OR4C7Z1/XFrZR9r2YQIeB9166IhwmJgj8RNmcOxX8VdmgzxqWC6qXRBYZCaw1QxeKKnwyYBC6Dxg8Db; 25:WIzdP+c5xNm6i8qQhONqelVYJlY5biCuZhPsEblDlt6pYzQWdyS3BBG5rviKYI0t/HS8hxawWECjS6xadwRQnPYz+eZus2oii7ubXUaoPfHkHxmrd6VL1E6gs0Q6GIVzUWZFpAPXJzdkp7w+JC0IMOyLO+u6aVv+3ALl4qyms+Vi2zkUE2/OKTgJgnbt39FdHBYjEb/SEHAbqUwHIMqFRg9dFaOgUP22magLY4F6+hNCIgYyd41AMpM9c+dCc/LjfNtti/d6Sg+Ocw3UaKtBHHD9uSjLX71OgcbtqtOrG0Hb70xRoTaGyS4e+Wxygw5S X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB2154; X-MS-Office365-Filtering-Correlation-Id: cb85da8b-a160-477b-fe15-08d3362c8a69 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2154; 20:DbP7Jt5IxKLpXctHjQyfqcABcV/HO4o9lnmPTj361rFUlrJMKAFzpjO9jN083fdIDf62UadIgNF00bi4nlSkbq6s2qsYGRaqjnzZhG0T2XUgQWUzAFP1apgxqRUOPaRSEw1LtzFoluJEmrpMG4tPnFDnmRObdMIQq16onCKAM9Br/kSmfvY6jOY63YmTWI5hRZP82bUQAuafsKTY23eNhEDTuX3f2Cv5pXMkYl9egUYYIhaqJABg2joITur4oUmKDHM76Z61Qau+oyJGsvr/x2osDnZLbMhze7B1lwyCSOc19lVOW8TE3AsL/H3anFEGFSOsQpGVeEm0ItGLSyipgFD64AtZR04UEreTsk2bhgI77YGzdgh6aTbJ11hdX2iUJ2y0TBBMJIs0+tDmUUhYaD1you+np0c+mJJFaNoxIgmRwGSHXsScx8bqALbShBaXqhGly/NsHxnm+E0cL149NWLITVZyzjDhiUbicinueBziEeqls5i2tjmRRQu9aFfe; 4:y/QuF70OwL7XrrRes9NvYQLzZC9Ft6BmFMlZSKLoj3LQxo493PHAcc5qwV70SgRzBlMUzDdO73Vct7xmgdwKucnarFlqhd36W4SnTv6Jc2lkaBtDWfgPZM50FsgDy6VOpeWgZgLRACwHjteYoJ0LZlUuuT8MuXKN2CdVe96xVe7lVBcV0DmelH4xbfs/Emamxxn/ALkvANOsSKZwwn2JQs2I6xPFR5KkSeHDYcT6K2J12j8fSEBZEIO7lxXWbAVLSfKRecrXq69Zt+8xA0iLpxUOLUfLyw+E5ffoUI2NxIQD0AfiOcr2QS9/o3SXuTjdhLA7U1JkS5asat7HnFPHemA7P1QG0NF7VUNV57PvEYaVB3ExGGMvJn0bVnRqk06X X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2154; X-Forefront-PRVS: 08534B37A7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(52604005)(479174004)(377454003)(24454002)(189998001)(36756003)(5890100001)(42186005)(80316001)(4001350100001)(83506001)(110136002)(86362001)(50466002)(5001960100002)(23676002)(5004730100002)(2870700001)(50986999)(65816999)(87976001)(77096005)(1096002)(33656002)(122386002)(5008740100001)(87266999)(54356999)(76176999)(65806001)(586003)(92566002)(2906002)(40100003)(6116002)(4326007)(230783001)(66066001)(65956001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2154; H:[172.29.34.136]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA1MDFNQjIxNTQ7MjM6blh0dVhsQWhIdzY2aVJoMVlYdzEzaXRK?= =?utf-8?B?bTV6WjVPNmc4WmR6YzJKc2Rtc2VUK3JPQk1Fc011K01Kd1ZwRTEvN3V1eGU5?= =?utf-8?B?T3RjcDRBQWtLVFEwaU1yTzg0MElYcUlEbGJjVGQ5NkI2Sit5Vkxkb2RMV3VY?= =?utf-8?B?Z3FkN09VQjdhRVVjcVRaU0ZFaElFbTVxZ0VuY01uM1UvaGV2YVRkVmswL0s5?= =?utf-8?B?b2xPZDdReE04Y202RG0zNFVNaWppejVwSHRWZnZra01yOU9lazF5SUtFNjM1?= =?utf-8?B?MlFwVVFYWEttb1phTUg3N2x5a2RPTHBmekFtb1Q0aDMzaHVMVXlLaXFDMEtq?= =?utf-8?B?VUt2UVJvOTF3VFlNSDlQM1RmVm5od2MvcmJac1Z2VW1PZkxBRE14ZGovVnAv?= =?utf-8?B?aGRvVjQ0b0pRVUxsajRTdmZuZTFseS9JM3lZdzM4Nit4UXhNQ3dtdXVUSmtT?= =?utf-8?B?cEt0REVkOFpMSWRVSmRZWE1Sd1hyZklyekJOSXBZK0hpZy9rT1Fka2VxN2R5?= =?utf-8?B?Ry85RWdZdlVOQ1prRFAyUG53dTNRd3N4OTlpQ1RQZzV3SjdGU2RpR2UvL0Uv?= =?utf-8?B?WnZWTUNGNXpuRmh4MjVqcEczcy9jQmxRUHp4VE5qVUJnTEVZTFJmeTB1aEpF?= =?utf-8?B?NDROOUU5emVzUVp3b1hUTmJ2K2xWK21uU1FLT1Z1R3llOWxXejdsdUJyWXM4?= =?utf-8?B?d3NRUkJ6ZC9GWmVqM2pUU0JrbGxJNk9kT2g0TXRjeFlHVWQ1bGpNWng1aC90?= =?utf-8?B?QzhZMUFvS3BHTEM2a2sycEZVMGZrTTZKVkdBUi9SV0dOVUM2OTlEOWVRa3lz?= =?utf-8?B?NWwreHFySDNtTFgwWElSUWxXejlXeVFDcmppSW9zUVYwc2JQVFNmZmZ2dEVi?= =?utf-8?B?dG5KRUlFK2hUdzlKQ2pEalR4WnFINUxscVNucDA5QVpLL25EclF3bDVLa2t6?= =?utf-8?B?Njl3SkdjYit3SlgvaXl3Zno3dW1EMklaRnFvc3o2Q2xxclV6OE8rcVNZQ3do?= =?utf-8?B?cjVSSHhPa3BxYzgxWnVVNHBjOHlhdUtNSnhxenlJZW4zRHltZDcxS0hwZkY5?= =?utf-8?B?OEFnWFZQUGx0dE5TaVFXc0FUYXB5b1JQamdxQk9rcmxPOFk2Q0ZUeGdkLzl5?= =?utf-8?B?QXRiK2cwK0dWaUkvbG9QRUJJTVRYY1ZsSzB0ckNFa1JuKzlKYy9WUXlZZ1Qy?= =?utf-8?B?RlA0Mm9QTTNGRkJ0MXRTaEpMOTdYeHVDSDVabmxabDRkQmxjRDRGRnBXWEox?= =?utf-8?B?YzRjZUVrWFNCWEhFSDFtQzVmSDZRbExlZWlPOW0yN3VvVWZTL0JiU0oxT3hE?= =?utf-8?B?OE9FTFluQ1I3ZXJQdjNmWnFRbi9BMGFHRVhhRUFmcHhlbXNjTHBJajFHZzJT?= =?utf-8?B?UnB0MHF5c2RteU1RM2lHbnlPaDl4RHI0NzFpTDA1eXZaV0o0UFVhcnBQNW5j?= =?utf-8?B?Y1BxMEl6OUZRK3VpVmFnbHhlQllkdC94dmZ6Q0dvZzh3dmk5Q0g4c2RCaWF4?= =?utf-8?B?eU5ObjJYRHVDMGljbzBoYmlqSE5GdEhVZTZFOEpPR1lGd1U3dDAwS3JDUENB?= =?utf-8?Q?gzt?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2154; 5:kxZTnC9k9rV042O0KAzq0npmxVfjWYA9621pYnJKxduYWySUtsSHUcDau5cUBvvxtI7d6im0Kqs86pqA7hKofExMtJHgtgDJTvhPsNZzLyMGVny5YakwvkAPluzDD0ZwhQ+bu9/b2mArlDOylhZSYg==; 24:3b0W4/qXrmcdhf70WD1Ex+/1BHKrOJW4a+UI5i+xZlmAxSw29dsvWQQ+fJhKeoy8VpDwSRZyg60m9YHPMF1Wl860vSZ2hPAzaiVDp3fgXHU= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2016 17:22:10.8815 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2154 Archived-At: Cc: "idr@ietf.org" , "bess@ietf.org" Subject: Re: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:22:41 -0000 On 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote: > Hi, Eric, > > Thanks for sending this out — I am interested in this document, and will give it a critical review (in particular the sections you call out below). Thanks! > > In the mean time, however, I wanted to send a few high-level comments (prepended with “CMP”) from scanning through it. I hope these are useful. > > 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types > > This section defines Tunnel Encapsulation sub-TLVs for the following > tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE > ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890], > [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], > [RFC4023]). > > > CMP: More comments below, but I am a bit confused about the need to include MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for example. MPLS-in-GRE is included in section 3.2 because there is already a tunnel type codepoint allocated for it, and if that tunnel type is used, an encapsulation sub-TLV is needed in order to signal the GRE key. One can argue that there is no need for the MPLS-in-GRE tunnel type, since everything you can do with it could be done instead with the GRE tunnel type. But unless and until we decide to deprecate the MPLS-in-GRE tunnel type, it needs to be included. In theory, I would love to see the MPLS-in-GRE tunnel type deprecated, but I worry that that might introduce a backwards compatibility problem. This is certainly something that can be discussed by the WG. IP-in-IP is not mentioned in section 3.2 because, although there is a tunnel type codepoint allocated for it, no one has ever defined an encapsulation sub-TLV for it. Also, if it is necessary to signal values for the fields of the outer iP header, it might make more sense to use an "outer encapsulation sub-TLV" (section 3.3). Do you have an opinion about this? > > CMP: A couple of editorial comments as well: For GRE, I think you also need to cite RFC 7676 (GRE over IPv6) Sure. > > CMP: Also, having this document Obsolete RFC 5512 effectively also orphans a number of Tunnel types and sub-TLVs. For example, Tunnel Types values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel Authenticator sub-TLV. I do not know if the answer is to also have that incorporated (useful parts as you say) and obsoleted. Maybe not, maybe it does make sense given it is a short doc, which would lead to a complete self-contained set of Tunnel types. I think RFC 5566 will have to be obsoleted and replaced. I've been thinking about that, but I'm still not sure how much of 5566 should be moved into the tunnel-encaps draft and how much should be in a separate draft. There are some non-obvious issues to consider. For example, 5566 really is just intended to facilitate iPsec Security Associations between BGP Next Hops, but with the tunnel encapsulation attribute we could presumably set up Security Associations from ingress to egress. > > 3.2.4. L2TPv3 > … > Cookie: an optional, variable length (encoded in octets -- 0 to 8 > octets) value used by L2TPv3 to check the association of a > > CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8 Do you have a reference for that? Section 4.1 of RFC 3931 seems to say only that the field is variable length with a maximum size of 64 bits. > > 3.2.7. MPLS-in-GRE > > CMP: This seems to be an example and not a separate encapsulation type. This is GRE Type, with MPLS as protocol sub-TLV. I see that the section says: > > While it is not really necessary to have both the GRE and MPLS-in-GRE > tunnel types, both are included for reasons of backwards > compatibility. > > CMP: I will also note that having two different ways of doing the same thing (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us away from interop., and that there does not seem to be MPLS-in-GRE defined in any RFC (so it seems like potentially a good time to rationalize instead of perpetuate). My $0.02 only. Tunnel type 11 is used by draft-ietf-bess-evpn-overlay. > > CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we interop the two types of “ MPLS-over-GRE”? Well, the two ways of doing the same thing are explicitly defined to be equivalent, so I don't think there is an interop issue, the issue is more of "can we get rid of the MPLS-in-GRE type without causing a backwards compatibility problem". > Should an example be also added about MPLS-over-L3TPv3? Surely no one will ever propose MPLS-over-L2TPv3 again! > > 3.3.1. IPv4 DS Field > > CMP: Why not also define this for IPv6? There are a lot of possible Outer Encapsulation sub-TLVs that could be created, I only included a couple of examples that seemed like they might be useful. If you have some sub-TLVs to suggest for the case where the outer encapsulation is IPv6, please suggest some text. (Some IPv6-specific text will probably make it easier to get the draft past the IESG ;-)) > > 3.3.2. UDP Destination Port > > CMP: One additional thought. Obsoleting RFC 5512 also removes the anchor from RFC 5640 — that is not a terrible deal in itself, but is there also an opportunity to generalize the Load-Balancing approach thereby defined to also include the new encapsulations’ LB, UDP-based (port as the LB Field), etc? I wasn't aware of RFC 5640. I don't think there's anything in RFC 5640 that requires the Encapsulation-SAFI. So at a minimum, I think we can get by with saying that the tunnel-encaps draft updates RFC 5640, and that the LB Block sub-TLV can be included in the a tunnel TLV of a tunnel encapsulation attribute that is attached to an update of any AFI/SAFI. If you think it is worthwhile to generalize the load balancing approach of RFC 5640, perhaps the best approach would be to do a 5640bis. > > I hope these are clear and useful — Thanks! > Looking forward to any additional comments you might have! From nobody Mon Feb 15 09:24:29 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086CE1A902F for ; Mon, 15 Feb 2016 09:24:29 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 kw5THFVUROjB for ; Mon, 15 Feb 2016 09:24:27 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0618.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::618]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59861A902E for ; Mon, 15 Feb 2016 09:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0SHlIawkiSQ9uMRQ7pfSAGAZzOxXN+dWLEC0zSk3MLY=; b=npApbd63DOglZf5hXkFIK8ciryA6IKO4a5mCzyeP95V/mGrF4ajMT16ZE3gk0KL39JAloMteN8zWR+QDxa2fwveZIUUgwzTkc0+F6bntFw5fAEuK2+QlIYKq9WeAYWFpMSy9f5BLeGhNTdvuedT+31Ws8bhvujTMIc1hLS0Pph4= Received: from DM2PR10CA0083.namprd10.prod.outlook.com (10.141.241.51) by SN1PR10MB1040.namprd10.prod.outlook.com (10.164.25.14) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 15 Feb 2016 17:24:08 +0000 Received: from BN1BFFO11FD052.protection.gbl (2a01:111:f400:7c10::1:188) by DM2PR10CA0083.outlook.office365.com (2a01:111:e400:2464::51) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Mon, 15 Feb 2016 17:24:08 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=sv-ex13-prd1.infinera.com; Received: from sv-ex13-prd1.infinera.com (204.128.141.23) by BN1BFFO11FD052.mail.protection.outlook.com (10.58.145.7) with Microsoft SMTP Server (TLS) id 15.1.415.6 via Frontend Transport; Mon, 15 Feb 2016 17:24:08 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 15 Feb 2016 09:22:52 -0800 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.1044.021; Mon, 15 Feb 2016 09:22:52 -0800 From: Iftekhar Hussain To: "thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: Ref: [bess] Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 Thread-Index: AdFoFEtP0flC1cZSSya0jxif5WNh5g== Date: Mon, 15 Feb 2016 17:22:51 +0000 Message-ID: <322e482513cf4b6e8a5940752ed6de89@sv-ex13-prd1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: multipart/alternative; boundary="_000_322e482513cf4b6e8a5940752ed6de89svex13prd1infineracom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD052; 1:fIKKhjNIox0bOnVt58jOyV4Fd3DAkDgkRqpm8ZEteueuddHCXKnN4RGJ6y/B81KjwjKRfTFEvgKIrNTSVoj2Q/QxFRnCuojGVBYTbR2+3v/VCL1OVWWyE1YZJGbr5n9j7R5Y82+G8Z4jx1v1mkvwelpizkLM0mnPrh7awnKeLS/AZQwXIdc8C68OxDA2r6pCl/C0sw9ipW+vvN/N4/juO+IaQgDK0Vbq2bJ91tDy1hzm/PFyx03Y2kzqsex3FugssV0+FEE8hSPYhDtFs/EyXmdH1coHPBaWC9a5FERtNfMXGh00EgGq9IzRL4iCsSnlIRpMuHKAdz8bZgFhEErt1bjW0JeCRNKcyrUxvLGpmdk/DpV5p3SXAlp/YwElXQpgkbt0vLjIFI5ULSHsgoHo5Y9gwDZsNslqPwLth61gRC0= X-Forefront-Antispam-Report: CIP:204.128.141.23; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(164054003)(189002)(199003)(5004730100002)(260700001)(300700001)(30436002)(512954002)(84326002)(106466001)(16236675004)(4546004)(108616004)(92566002)(54356999)(19580395003)(50986999)(77096005)(2501003)(15975445007)(5003600100002)(229853001)(1220700001)(16796002)(3846002)(19300405004)(5008740100001)(102836003)(6116002)(24736003)(2900100001)(189998001)(2906002)(4326007)(11100500001)(586003)(6806005)(53416004)(790700001)(19625215002)(86362001)(10400500002)(1096002)(230783001)(33646002)(5001770100001)(5001970100001)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR10MB1040; H:sv-ex13-prd1.infinera.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-MS-Office365-Filtering-Correlation-Id: 5f060b3e-532b-433f-bff2-08d3362ccff9 X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB1040; 2:8fSQCeaICU3gMxpmWMTWvLa3EwUtuA3v20ubabWDc+MqfsVgGP4GGnY3Ws7ZOZKqaaJCgxOQTrD+PrDc44Tjhlm731Sf2OrmjBuZ1Hccm4YH4nHlnA5fAqfrc3bDiJ+om6Yp2YLiqz9a6U74peIZ26SQyjDpJbZ6cZ0BvfdLjkByeaNozHj6yWFwnq+y6PYy; 3:jjDdFAoW3hYmiQIl4lWI2R6GquWrQi0cltZ4HMW7ePmuMFcLW+j24c6fWQfNR/HtTdgwbu8o3MQULXyc7B2Wo6CeVQXYVC6ruVVnepGyjM6At+Er8xFONELsCYE9l8ECvjMR4xam7dS1JsCsseF5lIj1EG2HqsRxDzLfpg3pUymmkovFYUIHnxPF0N4fQ73zbwFn7ikLgWXbKZqN/Bu1l/7jHl43cl+RoHtwnrl7gNtRQKsdMWsahdyK3+F+e1hGcAO3Kc6Mr+Fet6Su9K5a/w==; 25:5r9aFWCM1L4LgX0icofa42isD4fQm3w4VtJF5yaaBljOxl46jVje67GMrpZtbUpIolYIJIOYTX5ycbHbiiig0XVitUvrmRlbudnizQv9Bdo2shQy/cGR1xTFEuZlXzZQCc89n+bmnMN4NQOnn3vES0z10Pk3uG4rHyXP9j/wAAmoH8TX0EZh9CysXjMY71ayXZI607+DUmumZ/wOWP/BI5zdaW45T/nwBkArLs0ODRVbpTyaYciCuraZNe6ZfIRtNzzcZcmD2ZhHWB+ehDhSA6H7IEIYW5UOmJIIqEo3ZqPVy1UJTMvd3lG4Y7E12yQ8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:SN1PR10MB1040; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13017025)(13015025)(5005006)(13018025)(13023025)(13024025)(8121501046)(10201501046)(3002001); SRVR:SN1PR10MB1040; BCL:0; PCL:0; RULEID:; SRVR:SN1PR10MB1040; X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB1040; 4:wh6o/sI0c1kgcALeLvMOOpm+6AkcJVaqNTLQ1neZ7nAftgpaPbPqSuQmQVZg76n65fW/2i5DjmPPAe59Ou14rRTQqfe5bd+7u/osNaLuNy6Jc1UbH4EGP3Gbq6ouQc29/+nm3mdOYo0BTVfC7Vt/5pzmOAPcl85qvnzpzLTC2QtTjvVkctDPhe75mdoQuK3YPXzmQi8F3aO2Pyg3mWyyM4hHjlbzmGX7LPx0SCkg8ttGAcMwQT6TZq77XBMpf8d4nHdY2xyy0JS2TOUkJRe9/uR6XDc6g4i+F/mnCQgNayQg4iuQ5IwlMmMP7k5LmvwabjNlfRRph7rYdabOxWY8OIpZXLMlKMooPWacOniB2qXeWeiWh52Jh5OKwMIBsChk/TA+UjJwa+Qqh7/wJRmPGfjATQOHycNscsh8Z2NLSaGD10Jgs+rTknduf2iEAEi2ottNdAiZckcVS4qIvDbo9A== X-Forefront-PRVS: 08534B37A7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR10MB1040; 23:NzQbA2Fm37cSi7ZuAyU3god/lvEr5LCsaBhuhvmD3?= =?us-ascii?Q?T8qq/1q/qzVVYgcDDzYLGz6k5Tovg5AMMLDk8ZpsFm2/nQUBXjc0KM9l7SXn?= =?us-ascii?Q?MMIYaNCFwVqy3l7tsyhacujaxYN76/43q2N/KVZi//GAPzbsmM/FUF7iP8WE?= =?us-ascii?Q?77Ox/HcSogeX7BwU9BM+wJQCHvhZD++5/EbcpKn6PRuz1Ce3CuRiZFhCjmlX?= =?us-ascii?Q?J6ratesPhW+wFbAuFxKdkF7ZkbmBFK5fVkOdIBJKodPFu3Qh1gfRrl/M9x4Y?= =?us-ascii?Q?WmHreXcL2Szheuucm64yXRPVgOdUL/QOvBw+5iWkDELRHdKD0qw/o44S9aNF?= =?us-ascii?Q?WSpE+8g3xKasCI01p/UPSXpgUNGFWH3vazHHXvafnFniTQ3e9uy37pj7q4Vt?= =?us-ascii?Q?hdpoa79g55ZBK3dyOLJ7iRNQy3hW95Lw8npK29F2J4jorjpTdV6GVcbHhIpj?= =?us-ascii?Q?Ei6vwQNKXvPBWoekk9AWuU3dXaT1w4uUoGxwP59X9daXGBxj3VaDu+r/VnZ9?= =?us-ascii?Q?C9fJg54r4x1VPC0bJ7JqoXSw9UX315KeDs9eh6+kdBL401gfbDNO1VE+a55G?= =?us-ascii?Q?Gok45bdiYCxYV9eXnO86m86oN0PWKu7ih2zRPvU6g1gZXpOgvwvvavh2TX1a?= =?us-ascii?Q?2pOMVoGl9m/mSB9+DHqlp8CjjD05wSVe1rw9ZjjwY+h28VGVtMNnXPzK9vJO?= =?us-ascii?Q?db0VgDhs/0cnBkSSVIqXnynZV/i2BBoWNUp9yakd2lmnn28gpXeQ+GXuRquf?= =?us-ascii?Q?gHTUDpIllepdyo98j4Efgycy1w+6LBRMKWX7L7R3RVwFZCZtuh0lmUgcV/IJ?= =?us-ascii?Q?hg4hKQ56gZzd443gMDZzIn7n6UnA3K72L8dmRG2WJVpnL1D5aNU5oxo18l67?= =?us-ascii?Q?QvC+8oYxpw4b8wkfFVFzs6fxWJnan1pibrjlQVDIIVC5OdUgH1P9n9/9ViJv?= =?us-ascii?Q?7ynf6zpMn6ryd4gwRI9Fetgh/tLv/g2MUU9puWOn60wMxdvvzjDAdah/B2mE?= =?us-ascii?Q?nSyV3t/qgyEB1icEzDP7NeB2vQKdpABc5nan0Rv9r6D7z9iIJHGWPjrDKRIv?= =?us-ascii?Q?GB53+0Uc3DsdCIwOVVRbuXmDSz2o/wOBr4Ji/qtVO7TCfyXsFe97Jqo0HJL4?= =?us-ascii?Q?Qp4JdFvJCPernP550XTkpombcmW/HD+x1WHLI+i0kbOEcCLQ7JRtL0wMXQqL?= =?us-ascii?Q?J6YqxVSY5QdwX5DMnFQIhxDzW0R+uYNzErWr8hW+FL9/hUL+E+HRPUvmGEOE?= =?us-ascii?Q?xJKozwmkfNl0vImVhuaGwEZqrG+9HGENgR+kLnDOpxdaiCvF3zraz2v7Hz/W?= =?us-ascii?Q?TFK2rK2IDXUyd27+BwZyHHSwdwRtwBw2qi+ISFRXZRf?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR10MB1040; 5:JeR+3v+J1lKBXj5+OP+GtIvs3hzAvNTRo5v9wFxpNHzxd6rQWJ/rfmaQJxF8LyrNx+pZAJwi1OEYS+mbfYGgKezmxbBXQ3vj0V101jR/NZKrbulx8nsK7S88/Y2o2juFMyJy1Av1pT5VChLZiEVzxw==; 24:jmhBVWaHGn3as70mHniRdEMXxPm7LbiJPlw190acC1Pl81ysQpZOtfFsPnDuNieZcHiDfvAJliGPkzu72o/KmsxcESc3WL+hS2phOpYviko= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2016 17:24:08.2589 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[sv-ex13-prd1.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR10MB1040 Archived-At: Cc: "draft-snr-bess-evpn-proxy-arp-nd@tools.ietf.org" Subject: [bess] Ref: Call for adoption: draft-snr-bess-evpn-proxy-arp-nd-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:24:29 -0000 --_000_322e482513cf4b6e8a5940752ed6de89svex13prd1infineracom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. I have read the draft and found it to provide very useful operational infor= mation. Thanks, Iftekhar From: To: "bess at ietf.org" Cc: "draft-snr-bess-evpn-proxy-arp-nd at ietf.org" Date: Fri, 5 Feb 2016 16:56:50 +0000 Hello working group, This email starts a two-week poll on adopting draft-snr-bess-evpn-proxy-arp= -nd [1] as a working group item. Please send comments to the list and state if you support adoption or not (= in the later case, please also state the reasons). This poll runs until **February 19th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies= to this draft, to ensure that IPR has been disclosed in compliance with IE= TF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). =3D=3D> *If* you are listed as a document author or contributor please resp= ond to this email and indicate whether or not you are aware of any relevant= IPR. The draft will not be adopted until a response has been received from each = author and contributor. If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in = conformance with IETF rules. Thank you, Martin & Thomas bess chairs [1] https://tools.ietf.org/html/draft-snr-b --_000_322e482513cf4b6e8a5940752ed6de89svex13prd1infineracom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

I have read the draft and found it to provide very u= seful operational information.

 

Thanks,

Iftekhar

From: <thomas.morin at orange.com><= /p>

To: "bess at ietf.org" <bess at ietf.or= g>

Cc: "draft-snr-bess-evpn-proxy-arp-nd at ietf.o= rg" <draft-snr-bess-evpn-proxy-arp-nd at ietf.org>

Date: Fri, 5 Feb 2016 16:56:50 +0000<= /p>

 

Hello working group,

 

This email starts a two-week poll on adopting draft-= snr-bess-evpn-proxy-arp-nd [1] as a working group item.

 

Please send comments to the list and state if you su= pport adoption or not (in the later case, please also state the reasons).

 

This poll runs until **February 19th**.

 

*Coincidentally*, we are also polling for knowledge = of any IPR that applies to this draft, to ensure that IPR has been disclose= d in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for= more details).

 

=3D=3D> *If* you are listed as a document author = or contributor please respond to this email and indicate whether or not you= are aware of any relevant IPR.

 

The draft will not be adopted until a response has b= een received from each author and contributor.

 

If you are not listed as an author or contributor, t= hen please explicitly respond only if you are aware of any IPR that has not= yet been disclosed in conformance with IETF rules.

 

Thank you,

 

Martin & Thomas

bess chairs

 

[1] https://tools.ietf.org/html/draft-snr-b

--_000_322e482513cf4b6e8a5940752ed6de89svex13prd1infineracom_-- From nobody Mon Feb 22 08:58:46 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4C31AC435 for ; Mon, 22 Feb 2016 08:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Vwus8j8pv6zq for ; Mon, 22 Feb 2016 08:58:42 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C151A1B3C for ; Mon, 22 Feb 2016 08:58:42 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 6DA70586B9F32; Mon, 22 Feb 2016 16:58:37 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1MGwdlw021931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Feb 2016 16:58:40 GMT 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 u1MGwd01003544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Feb 2016 17:58:39 +0100 Received: from [135.224.194.238] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 22 Feb 2016 17:58:38 +0100 Message-ID: <56CB3E3E.6080602@alcatel-lucent.com> Date: Mon, 22 Feb 2016 17:58:38 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] Archived-At: Cc: draft-fm-bess-service-chaining@tools.ietf.org Subject: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 16:58:45 -0000 Hello working group, This email starts a two-week poll on adopting draft-fm-bess-service-chaining-02 [1] as a working group Document. Please state on the list if you support adoption or not (in both cases, please also state the reasons). This poll runs until *the 7th of March*. Note that IPR has been disclosed against an earlier version of this document: https://datatracker.ietf.org/ipr/2284/ Yet, we are *coincidentally* also polling for knowledge of any other IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). ==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you 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. Thank you, Martin & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ From nobody Mon Feb 22 12:54:33 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210561A6F29 for ; Mon, 22 Feb 2016 12:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 TDsQ_2NgcKeU for ; Mon, 22 Feb 2016 12:54:30 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A251A6F1F for ; Mon, 22 Feb 2016 12:54:30 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 0D25B6025815C; Mon, 22 Feb 2016 20:54:25 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1MKsRpq001529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Feb 2016 20:54:28 GMT 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 u1MKsRwb003165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Feb 2016 21:54:27 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.224]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 22 Feb 2016 21:54:27 +0100 From: "Henderickx, Wim (Nokia - BE)" To: "Vigoureux, Martin (Nokia - FR)" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJPjcTDN227ok+kboB6zWVPoZ84i0+A Date: Mon, 22 Feb 2016 20:54:26 +0000 Message-ID: <49650344-5CE0-47E4-B3F5-EF1E8D03508B@alcatel-lucent.com> References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <349135B78F55784EB950479859BE0D32@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 20:54:32 -0000 SSBzdXBwb3J0IGFkb3B0aW9uIGFzIFdHIGRvYyBidXQgbm9uZSBvZiBteSBxdWVzdGlvbnMgaGF2 ZSBiZWVuIGFkZHJlc3NlZCBzbyBmYXINCg0KDQoNCg0KT24gMjIvMDIvMTYgMTc6NTgsICJCRVNT IG9uIGJlaGFsZiBvZiBNYXJ0aW4gVmlnb3VyZXV4IiA8YmVzcy1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbT4gd3JvdGU6DQoNCj5IZWxsbyB3 b3JraW5nIGdyb3VwLA0KPg0KPlRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBh ZG9wdGluZw0KPmRyYWZ0LWZtLWJlc3Mtc2VydmljZS1jaGFpbmluZy0wMiBbMV0gYXMgYSB3b3Jr aW5nIGdyb3VwIERvY3VtZW50Lg0KPg0KPlBsZWFzZSBzdGF0ZSBvbiB0aGUgbGlzdCBpZiB5b3Ug c3VwcG9ydCBhZG9wdGlvbiBvciBub3QgKGluIGJvdGggY2FzZXMsIA0KPnBsZWFzZSBhbHNvIHN0 YXRlIHRoZSByZWFzb25zKS4NCj4NCj5UaGlzIHBvbGwgcnVucyB1bnRpbCAqdGhlIDd0aCBvZiBN YXJjaCouDQo+DQo+Tm90ZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCBhbiBl YXJsaWVyIHZlcnNpb24gb2YgdGhpcyANCj5kb2N1bWVudDoNCj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2lwci8yMjg0Lw0KPg0KPllldCwgd2UgYXJlICpjb2luY2lkZW50YWxseSogYWxz byBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IG90aGVyDQo+SVBSIHRoYXQgYXBwbGllcyB0 byB0aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkDQo+aW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5 DQo+YW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo+DQo+PT0+ICpJZiogeW91IGFyZSBsaXN0 ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlDQo+cmVzcG9uZCB0 byB0aGlzIGVtYWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueQ0KPnJlbGV2YW50IElQUi4NCj4NCj5UaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1 bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20NCj5lYWNoIGF1dGhvciBhbmQg Y29udHJpYnV0b3IuDQo+DQo+SWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBj b250cmlidXRvciwgdGhlbiBwbGVhc2UgDQo+ZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91 IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgDQo+YmVlbiBkaXNjbG9zZWQg aW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPg0KPlRoYW5rIHlvdSwNCj4NCj5NYXJ0 aW4gJiBUaG9tYXMNCj5iZXNzIGNoYWlycw0KPg0KPlsxXSBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1mbS1iZXNzLXNlcnZpY2UtY2hhaW5pbmcvDQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5CRVNTIG1haWxpbmcgbGlz dA0KPkJFU1NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Jlc3MNCg== From nobody Mon Feb 22 13:01:47 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16221A7000 for ; Mon, 22 Feb 2016 13:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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.006, 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 tTpruyJX2ggp for ; Mon, 22 Feb 2016 13:01:41 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D33B1A6FFE for ; Mon, 22 Feb 2016 13:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2100; q=dns/txt; s=iport; t=1456174901; x=1457384501; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cjIG3XKS8Uw1DJqth9nUxgjnOqegPlHPS+JPXjmmTaw=; b=KhsEY2+UJ7GGnQUYY1gVjBPjqrGtPQ6q4hyuy8bDro3+zJD+V8xSG0Da X4sUEcTb0wU+yQp84ba4SP9RolRCke8mcIkiy4NiM80qMaS1WaXTBkW9I MvVXsNNqH1Zk0aoJUQXoImPE+7D59Uir+EJi/R34GPNGjfO0NChomq3oC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuAgBrdstW/5xdJa1egzpSbQa6TgENg?= =?us-ascii?q?WYXCoVsAoFEOBQBAQEBAQEBZCeEQgEBBAEBAWsLEAIBCBguJwslAgQBDQWIGw6?= =?us-ascii?q?5XwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEOoQFEQGEWAWNYoklAYVWiAeBX?= =?us-ascii?q?IRDiFSOSAEeAQFCggMZgUhqhwg0fQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,486,1449532800"; d="scan'208";a="240423905" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2016 21:01:40 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1ML1eTK023738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Feb 2016 21:01:40 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 22 Feb 2016 15:01:39 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.009; Mon, 22 Feb 2016 15:01:39 -0600 From: "Dhananjaya Rao (dhrao)" To: "Henderickx, Wim (Nokia - BE)" , "Vigoureux, Martin (Nokia - FR)" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJQpHLPkTaW3U6h1WCC55PmEZ84794A//974gA= Date: Mon, 22 Feb 2016 21:01:39 +0000 Message-ID: References: <56CB3E3E.6080602@alcatel-lucent.com> <49650344-5CE0-47E4-B3F5-EF1E8D03508B@alcatel-lucent.com> In-Reply-To: <49650344-5CE0-47E4-B3F5-EF1E8D03508B@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.165.188] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 21:01:47 -0000 Hi Wim, Thanks again for the support and your suggestions. I believe we did address them in the latest version, but I=B9ll check again. Regards, -Dhananjaya On 2/22/16, 12:54 PM, "BESS on behalf of Henderickx, Wim (Nokia - BE)" wrote: >I support adoption as WG doc but none of my questions have been addressed >so far > > > > >On 22/02/16 17:58, "BESS on behalf of Martin Vigoureux" > wrote: > >>Hello working group, >> >>This email starts a two-week poll on adopting >>draft-fm-bess-service-chaining-02 [1] as a working group Document. >> >>Please state on the list if you support adoption or not (in both cases, >>please also state the reasons). >> >>This poll runs until *the 7th of March*. >> >>Note that IPR has been disclosed against an earlier version of this >>document: >>https://datatracker.ietf.org/ipr/2284/ >> >>Yet, we are *coincidentally* also polling for knowledge of any other >>IPR that applies to this draft, to ensure that IPR has been disclosed >>in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >>and 5378 for more details). >> >>=3D=3D> *If* you are listed as a document author or contributor please >>respond to this email and indicate whether or not you are aware of any >>relevant IPR. >> >>The draft will not be adopted until a response has been received from >>each author and contributor. >> >>If you 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. >> >>Thank you, >> >>Martin & Thomas >>bess chairs >> >>[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ >> >>_______________________________________________ >>BESS mailing list >>BESS@ietf.org >>https://www.ietf.org/mailman/listinfo/bess >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Feb 23 01:31:42 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7839A1B3F9D for ; Tue, 23 Feb 2016 01:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5xJCHuHzC0kL for ; Tue, 23 Feb 2016 01:31:39 -0800 (PST) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89491B39FA for ; Tue, 23 Feb 2016 01:31:39 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id CEC11200BC for ; Tue, 23 Feb 2016 10:31:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id AD48420057 for ; Tue, 23 Feb 2016 10:31:37 +0100 (CET) Received: from [10.193.71.12] (10.168.234.5) by OPEXCLILM32.corporate.adroot.infra.ftgroup (10.114.31.32) with Microsoft SMTP Server (TLS) id 14.3.279.2; Tue, 23 Feb 2016 10:31:37 +0100 To: References: <56CB3E3E.6080602@alcatel-lucent.com> From: Organization: Orange Message-ID: <9997_1456219897_56CC26F9_9997_2574_1_56CC26F3.5030904@orange.com> Date: Tue, 23 Feb 2016 10:31:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.5] Archived-At: Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 09:31:41 -0000 Hi Martin, I'm not aware of any related and undisclosed IPR. (and yes, as a co-author, I certainly support adoption!) -Thomas Martin Vigoureux : > Hello working group, > > This email starts a two-week poll on adopting > draft-fm-bess-service-chaining-02 [1] as a working group Document. > > Please state on the list if you support adoption or not (in both > cases, please also state the reasons). > > This poll runs until *the 7th of March*. > > Note that IPR has been disclosed against an earlier version of this > document: > https://datatracker.ietf.org/ipr/2284/ > > Yet, we are *coincidentally* also polling for knowledge of any other > IPR that applies to this draft, to ensure that IPR has been disclosed > in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you 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. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Tue Feb 23 05:24:11 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55E41B2C1E for ; Tue, 23 Feb 2016 05:24:08 -0800 (PST) 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 8RWwT0rqle-q for ; Tue, 23 Feb 2016 05:24:05 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147F41B2C1A for ; Tue, 23 Feb 2016 05:24:04 -0800 (PST) Received: from BLUPR05MB339.namprd05.prod.outlook.com (10.141.24.149) by BLUPR05MB339.namprd05.prod.outlook.com (10.141.24.149) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 13:24:03 +0000 Received: from BLUPR05MB339.namprd05.prod.outlook.com ([169.254.2.8]) by BLUPR05MB339.namprd05.prod.outlook.com ([169.254.2.8]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 13:24:03 +0000 From: Stuart Mackie To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJQ2GM1yzoOXUKpHa9e6Zvzm585S/UA Date: Tue, 23 Feb 2016 13:24:03 +0000 Message-ID: <4154D811-176C-4399-9E2B-7F5B7B0F837F@juniper.net> References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB339; 5:GpuRwFb+5uUiY1zI9L+6tfVlT+0v+SGu6GLT9naQfBsBiB1QSATy7Z+oDUuulUqi8tjgq86BvRuNJODE89+8JPUPLDX7GSmp3MgeLbZ3HoJWISyR/4ggDrXTRgv062i9RWb5iEf1OhHvnwmHQ0ycEQ==; 24:tq3v5Tit4qtP1UOKou663Ct4XmpWy+P4S0W9CZ1H1PVZ+CFjZZhlb0UowQZARvQjb0iJUtq37WcfaqRJU5UR+aB1Owm2zHshkUmEIIOwnQg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB339; x-ms-office365-filtering-correlation-id: 298ec195-4cb9-4bd9-c74e-08d33c549974 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR05MB339; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB339; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377454003)(82746002)(19580395003)(19580405001)(586003)(3280700002)(3846002)(3660700001)(66066001)(33656002)(15975445007)(2900100001)(4326007)(2906002)(2950100001)(230783001)(83506001)(102836003)(5004730100002)(5008740100001)(1220700001)(1096002)(6116002)(10400500002)(122556002)(11100500001)(40100003)(92566002)(36756003)(99286002)(106116001)(87936001)(189998001)(5001960100002)(76176999)(5001770100001)(50986999)(54356999)(5002640100001)(2501003)(83716003)(4001350100001)(86362001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB339; H:BLUPR05MB339.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2BDD78746A6BF14993AB1A692F04BACF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 13:24:03.7142 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB339 Archived-At: Cc: "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 13:24:09 -0000 QXMgY28tYXV0aG9yLCBJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4gSSBhbSBub3Qg YXdhcmUgb2YgYW55IElQUiByZWxhdGluZyB0byB0aGlzIGRyYWZ0IGFwYXJ0IGZyb20gdGhhdCBm aWxlZCBieSBFcmljc3NvbiBhbmQgcmVwb3J0ZWQgdG8gdGhlIElFVEYgYXQgdGhlIGZvbGxvd2lu ZyBVUkw6DQoNCi0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9kcmFm dD1kcmFmdC1mbS1iZXNzLXNlcnZpY2UtY2hhaW5pbmcmc3VibWl0PWRyYWZ0JnJmYz0mZG9jdGl0 bGU9Jmdyb3VwPSZob2xkZXI9JmlwcnRpdGxlPSZwYXRlbnQ9IA0KDQoNClN0dWFydA0KLTkxNCA4 ODYgMjUzNA0KDQoNCg0KDQoNCg0KT24gMi8yMi8xNiwgMTE6NTggQU0sICJCRVNTIG9uIGJlaGFs ZiBvZiBNYXJ0aW4gVmlnb3VyZXV4IiA8YmVzcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbT4gd3JvdGU6DQoNCj5IZWxsbyB3b3JraW5nIGdy b3VwLA0KPg0KPlRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBhZG9wdGluZw0K PmRyYWZ0LWZtLWJlc3Mtc2VydmljZS1jaGFpbmluZy0wMiBbMV0gYXMgYSB3b3JraW5nIGdyb3Vw IERvY3VtZW50Lg0KPg0KPlBsZWFzZSBzdGF0ZSBvbiB0aGUgbGlzdCBpZiB5b3Ugc3VwcG9ydCBh ZG9wdGlvbiBvciBub3QgKGluIGJvdGggY2FzZXMsIA0KPnBsZWFzZSBhbHNvIHN0YXRlIHRoZSBy ZWFzb25zKS4NCj4NCj5UaGlzIHBvbGwgcnVucyB1bnRpbCAqdGhlIDd0aCBvZiBNYXJjaCouDQo+ DQo+Tm90ZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCBhbiBlYXJsaWVyIHZl cnNpb24gb2YgdGhpcyANCj5kb2N1bWVudDoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2lwci8yMjg0Lw0KPg0KPllldCwgd2UgYXJlICpjb2luY2lkZW50YWxseSogYWxzbyBwb2xsaW5n IGZvciBrbm93bGVkZ2Ugb2YgYW55IG90aGVyDQo+SVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy YWZ0LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkDQo+aW4gY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5DQo+YW5kIDUz NzggZm9yIG1vcmUgZGV0YWlscykuDQo+DQo+PT0+ICpJZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBk b2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlDQo+cmVzcG9uZCB0byB0aGlzIGVt YWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KPnJl bGV2YW50IElQUi4NCj4NCj5UaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJl c3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20NCj5lYWNoIGF1dGhvciBhbmQgY29udHJpYnV0 b3IuDQo+DQo+SWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRv ciwgdGhlbiBwbGVhc2UgDQo+ZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgDQo+YmVlbiBkaXNjbG9zZWQgaW4gY29uZm9y bWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPg0KPlRoYW5rIHlvdSwNCj4NCj5NYXJ0aW4gJiBUaG9t YXMNCj5iZXNzIGNoYWlycw0KPg0KPlsxXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1mbS1iZXNzLXNlcnZpY2UtY2hhaW5pbmcvDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5CRVNTIG1haWxpbmcgbGlzdA0KPkJFU1NA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCg== From nobody Tue Feb 23 06:06:38 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CE71B2E35 for ; Tue, 23 Feb 2016 06:06:27 -0800 (PST) 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 ctWWIojzXRUa for ; Tue, 23 Feb 2016 06:06:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458DD1B2E28 for ; Tue, 23 Feb 2016 06:06:23 -0800 (PST) Received: from BY2PR0501MB2072.namprd05.prod.outlook.com (10.163.197.154) by BY2PR0501MB2070.namprd05.prod.outlook.com (10.163.197.152) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 14:06:21 +0000 Received: from BY2PR0501MB2072.namprd05.prod.outlook.com ([10.163.197.154]) by BY2PR0501MB2072.namprd05.prod.outlook.com ([10.163.197.154]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 14:06:21 +0000 From: Bruno Rijsman To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJTGLil/GHzPk21SGrmKSB3UZ85JWCA Date: Tue, 23 Feb 2016 14:06:20 +0000 Message-ID: References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BY2PR0501MB2070; 5:RDecL15QSEYOQ9mDI8gq05jZR494hQxiLzej4ALC50fesiZq1hHVocIcEJB6/nGOe5klAdRpMWPyOvJoFp9JjUL2eNYmf2ZfsSTVTm6Y3jFf5Dqt7F4Cr8PmGrCr9Zg4xk8qwshfq3t+UkH3VzKw2w==; 24:PcRkmFILvSzuJ0mpBHngQBHqrEFLjw8XaiGE+8Ty3XRhONIdCCa3lhNXYxLvFUaLHweneYLoYUkegI6+itBvwyn8tqn/3Ct3iT/sQNapN34= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB2070; x-ms-office365-filtering-correlation-id: 87676482-4d29-413c-7997-08d33c5a81ff x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR0501MB2070; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB2070; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(377454003)(87936001)(106116001)(99286002)(36756003)(92566002)(2501003)(40100003)(122556002)(5002640100001)(5001960100002)(86362001)(76176999)(50986999)(189998001)(5001770100001)(4001350100001)(66066001)(19580405001)(19580395003)(586003)(54356999)(3846002)(102836003)(3660700001)(3280700002)(1096002)(5008740100001)(83506001)(6116002)(5004730100002)(1220700001)(10400500002)(11100500001)(2906002)(2950100001)(15975445007)(77096005)(4326007)(2900100001)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2070; H:BY2PR0501MB2072.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 14:06:20.2754 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2070 Archived-At: Cc: "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 14:06:27 -0000 The only IPR of which I am personally aware of is the 2284 disclosure mentioned below. On 2/22/16, 8:58 AM, "Martin Vigoureux" wrote: >Hello working group, > >This email starts a two-week poll on adopting >draft-fm-bess-service-chaining-02 [1] as a working group Document. > >Please state on the list if you support adoption or not (in both cases, >please also state the reasons). > >This poll runs until *the 7th of March*. > >Note that IPR has been disclosed against an earlier version of this >document: >https://datatracker.ietf.org/ipr/2284/ > >Yet, we are *coincidentally* also polling for knowledge of any other >IPR that applies to this draft, to ensure that IPR has been disclosed >in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >and 5378 for more details). > >=3D=3D> *If* you are listed as a document author or contributor please >respond to this email and indicate whether or not you are aware of any >relevant IPR. > >The draft will not be adopted until a response has been received from >each author and contributor. > >If you 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. > >Thank you, > >Martin & Thomas >bess chairs > >[1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ From nobody Tue Feb 23 09:14:30 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F7A1B36EF for ; Tue, 23 Feb 2016 09:14:28 -0800 (PST) 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 9ppgfDiall5n for ; Tue, 23 Feb 2016 09:14:27 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AA61B3706 for ; Tue, 23 Feb 2016 09:14:27 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u1NHDlM7028970; Tue, 23 Feb 2016 12:14:26 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 216mm1n4v3-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Feb 2016 12:14:26 -0500 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 u1NHEPco010690; Tue, 23 Feb 2016 12:14:25 -0500 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 u1NHEKTV010601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Feb 2016 12:14:24 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 23 Feb 2016 17:14:15 GMT Received: from MISOUT7MSGUSRCF.ITServices.sbc.com ([169.254.6.245]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 12:14:15 -0500 From: "NAPIERALA, MARIA H" To: Bruno Rijsman Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbl2eIfSl0fntc0qOO5NuEWronw== Date: Tue, 23 Feb 2016 17:14:14 +0000 Message-ID: <12AC9292-14B2-4B2C-AFAD-27F4D73635BB@att.com> References: <56CB3E3E.6080602@alcatel-lucent.com>, 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-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-23_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602230189 Archived-At: Cc: Martin Vigoureux , "draft-fm-bess-service-chaining@tools.ietf.org" , "bess@ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 17:14:29 -0000 I am not aware of any IPR Maria Sent from my iPhone > On Feb 23, 2016, at 8:06 AM, Bruno Rijsman wrote: >=20 > The only IPR of which I am personally aware of is the 2284 disclosure > mentioned below. >=20 >=20 >=20 >> On 2/22/16, 8:58 AM, "Martin Vigoureux" wro= te: >>=20 >> Hello working group, >>=20 >> This email starts a two-week poll on adopting >> draft-fm-bess-service-chaining-02 [1] as a working group Document. >>=20 >> Please state on the list if you support adoption or not (in both cases, >> please also state the reasons). >>=20 >> This poll runs until *the 7th of March*. >>=20 >> Note that IPR has been disclosed against an earlier version of this >> document: >> https://datatracker.ietf.org/ipr/2284/ >>=20 >> Yet, we are *coincidentally* also polling for knowledge of any other >> IPR that applies to this draft, to ensure that IPR has been disclosed >> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >> and 5378 for more details). >>=20 >> =3D=3D> *If* you are listed as a document author or contributor please >> respond to this email and indicate whether or not you are aware of any >> relevant IPR. >>=20 >> The draft will not be adopted until a response has been received from >> each author and contributor. >>=20 >> If you 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. >>=20 >> Thank you, >>=20 >> Martin & Thomas >> bess chairs >>=20 >> [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Feb 23 10:13:13 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DFE1B3DE1 for ; Tue, 23 Feb 2016 10:13:12 -0800 (PST) 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 fGNLtinviwLQ for ; Tue, 23 Feb 2016 10:13:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0134.outbound.protection.outlook.com [207.46.100.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5841A1B3DC4 for ; Tue, 23 Feb 2016 10:13:07 -0800 (PST) Received: from BN1PR05MB939.namprd05.prod.outlook.com (10.255.206.14) by BN1PR05MB938.namprd05.prod.outlook.com (10.255.205.25) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 18:13:06 +0000 Received: from BN1PR05MB939.namprd05.prod.outlook.com ([10.255.206.14]) by BN1PR05MB939.namprd05.prod.outlook.com ([10.255.206.14]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 18:13:06 +0000 From: Ravi Shekhar To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Thread-Index: AQHRbZJQOt+4iu7w6kGkUSFlaoleZ5858EzQ Date: Tue, 23 Feb 2016 18:13:06 +0000 Message-ID: References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; BN1PR05MB938; 5:X2+Czlde27EmmYFMVvbPMLYlfO1ZLMxH5N0tPB0ENCG8vNK5IKNxEavXogD4ObRGLNYV+nDROxFDjN4Mziod8hOc5BjM0vwcNLKUvzG2RJ34Mp+NjuUTKYbZ5llv7+6ndCiNTGWWLGtUgXNKj6mF7Q==; 24:7PhSO/R0cHD1r5jO7zuLdNKTT1iU7cWKnZ/FyLrsz9TWPZPeHM2DLYuVF0U0InsL8CGe4qWg7irGm8zpzZVsXQPPanMAB2fI0rI3YM0wbbE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB938; x-ms-office365-filtering-correlation-id: 666af47c-59a4-42b0-4205-08d33c7cfa62 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN1PR05MB938; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB938; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(87936001)(3846002)(102836003)(54356999)(76176999)(50986999)(11100500001)(5001960100002)(106116001)(189998001)(76576001)(86362001)(5004730100002)(40100003)(5003600100002)(5008740100001)(230783001)(5002640100001)(586003)(1220700001)(1096002)(2906002)(3660700001)(6116002)(74316001)(15975445007)(3280700002)(99286002)(92566002)(33656002)(2900100001)(122556002)(10400500002)(2950100001)(19580405001)(77096005)(19580395003)(2501003)(4326007)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB938; H:BN1PR05MB939.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 18:13:06.3101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB938 Archived-At: Cc: "draft-fm-bess-service-chaining@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 18:13:12 -0000 Support.=20 We need a standards and interoperable way of chaining L2 and L3 services in= the network. - Ravi. -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux Sent: Monday, February 22, 2016 8:59 AM To: bess@ietf.org Cc: draft-fm-bess-service-chaining@tools.ietf.org Subject: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Hello working group, This email starts a two-week poll on adopting draft-fm-bess-service-chaining-02 [1] as a working group Document. Please state on the list if you support adoption or not (in both cases, ple= ase also state the reasons). This poll runs until *the 7th of March*. Note that IPR has been disclosed against an earlier version of this document: https://datatracker.ietf.org/ipr/2284/ Yet, we are *coincidentally* also polling for knowledge of any other IPR th= at applies to this draft, to ensure that IPR has been disclosed in complian= ce with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details= ). =3D=3D> *If* you are listed as a document author or contributor please resp= ond to this email and indicate whether or not you are aware of any relevant= IPR. The draft will not be adopted until a response has been received from each = author and contributor. If you are not listed as an author or contributor, then please explicitly r= espond only if you are aware of any IPR that has not yet been disclosed in = conformance with IETF rules. Thank you, Martin & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Tue Feb 23 14:56:06 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37171A90CD; Tue, 23 Feb 2016 14:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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.006, 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 TivOvwxCP-N2; Tue, 23 Feb 2016 14:56:00 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E5C1B361F; Tue, 23 Feb 2016 14:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42231; q=dns/txt; s=iport; t=1456268144; x=1457477744; h=from:to:cc:subject:date:message-id:mime-version; bh=MrQg9P3eXo0G7f8+ozO8iRoaoCJgX2aFaXjT1mHbGTo=; b=gg4eR/DO+2ooRAsNjo0AG072ZEFf4zwA3EiGp48NAwf/l5JGxPTIWh3Q 5SVbnLIGvaPFKIHnvmp/PPn/hclVP3FUDT/6nGm0mKY+diqK5yB4xRvQ3 KH0DeT4r7XZWGJGmEQfcqqxVQ9L28szR94h+CPes7aM8velwvA7yE21KK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAQ48xW/4sNJK1egm5MgUW6ZgENg?= =?us-ascii?q?WaGDYFKOBQBAQEBAQEBZBwLhEQEGlINEgFAAT8nBA4eAogDvT8BAQEBAQUBAQE?= =?us-ascii?q?BAQEBGYYSgz2FDIRgBZJzhBQBjV2BXIRDiFKFcohWAR4BAUKCAwUUgUiHZT19A?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.22,491,1449532800"; d="scan'208,217";a="241890828" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2016 22:55:42 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1NMtgGh016577 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 22:55:42 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 16:55:40 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 23 Feb 2016 16:55:41 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-bess-multicast-damping@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-multicast-damping-03 Thread-Index: AQHRbo1R5e3rbxWH10Omol5b+cXuqg== Date: Tue, 23 Feb 2016 22:55:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: multipart/alternative; boundary="_000_D2DBF5CB10DEE7aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: [bess] AD Review of draft-ietf-bess-multicast-damping-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:56:05 -0000 --_000_D2DBF5CB10DEE7aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I think that the title of this document clearly reflects what you want to d= o =97 which may be one of the reasons there was virtually no discussion abo= ut it (or any of its predecessors) on the list. However, I think the conte= nts leave many open doors that need to be closed before this document can b= e published. I put more detailed comments below, but my main concerns are here: 1. The Abstract says that the procedures are "inspired from BGP unicast = route damping". It seems to me that the intent is in fact to adopt the alg= orithm from RFC2439. However, the text is not explicit/clear about that. 2. As you all know, the history behind BGP damping has not been without = it being considered useless and even having recommendations (from RIPE, for= example) not to use it. How did you arrive at the default and maximum val= ues? It concerns me that there are no known implementations (from the Shep= herd's report). Because of that, I think this document would be better sui= ted as an Experimental RFC, with the explicit purpose of gaining experience= with the values and determine the impact in live deployments (which then c= ould support a standard version). Please consider changing the intended St= atus. According to the e-mail archive, it looks like an early presentation of thi= s work happened in an mboned meeting, but I didn't find discussion on the p= im or idr lists. Once the comments below are addressed I will want to forw= ard the document to pim/idr for their review. Thanks! Alvaro. Major: 1. There are 6 authors listed on the front page. According to RFC7322, = the total number is generally limited to 5. Please work among yourselves t= o cut the number of authors. Alternatively, we can just list an Editor (th= ere's one already identified)..or you can produce a justification detailing= the contributions of each author to consider an exception. 2. Replace the reference to RFC4601 with a reference to draft-ietf-pim-r= fc4601bis. Note that the section numbers have changed slightly! 3. Are you adopting the exponential decay algorithm from RFC2439? That = seems to be what's happening because you are not explicitly defining a new = algorithm, but some of the text leave doubts. For example: * "inspired from BGP unicast route damping" I know the application = is different, but if the algorithm is the same then please say it. * Section 5.1. (PIM procedures) * "updating the *figure-of-merit* based on the decay algorithm mu= st be done prior to this increment" This statement seems to directly imply= that the algorithm is used. Please reorder the steps to explicitly call t= his one out, instead of plugging it in as an afterthought. BTW, should the= "must" be "MUST"? Ordering should help you not having to deal with that l= ast question. * "Same techniques as the ones described in [RFC2439] can be appl= ied=85" "Can be"? This sentence seems to imply that what is described in= RFC2439 is optional. Are there other ways of determining the same thing? = What about the exponential decay algorithm? * It would also help if the terminology was consistent. For exam= ple, instead of "damping becomes active" use "suppressed". I can see how "= suppressed" may give the wrong impression as only the propagation of state = is affected. Explaining then how the terminology applies would make it eas= ier to reuse, avoid confusion and be clear. Note that there's no mention o= f RFC2439 in the terminology section. 4. Section 3. (Overview): "=85it is expected that this technique will al= low to meet the goals of protecting the multicast routing infrastructure co= ntrol plane without a significant average increase of bandwidth". In gener= al, I want to make sure that the qualities of the solution and the expected= results are properly reflected in the document. [I'm using the text above = as the base for my comment, but the impact is larger.] Some questions: * "=85it is expected that this technique will=85" I wonder why an a= ssertion can't be made that this technique can (vs just expecting that it w= ill) address specific problems. Is it the case that experience is needed t= o make a stronger assertion? Are the goals the same (or at least similar) = in every network? Are there implementations available? If so, please cons= ider an "Implementation Status" section (see rfc6982). What has been the d= eployment experience? This goes back to my comment above about the Intende= d Status of this document. * What specifically are the goals? In a couple of places the text p= oints back at Section 1. (Introduction), but I'm not sure exactly what the = goals are. Of special interest for understanding the goals is the part in = Section 4.2. (Existing PIM, IGMP and MLD timers) where other solutions are = discarded for not meeting them. * There is scattered text that talks about "=85ensure that the lo= ad put on the BGP control plane, and on the P-tunnel setup control plane, r= emains under control=85", "protecting these control planes=85avoiding negat= ive effects=85although at the expense of a minimal increase in average of b= andwidth use=85". However, the description is too vague to point at what = can satisfy these goals and what can't. * Section 4.1. (Rate-limiting of multicast control traffic) mentions= the "risk described in Section 1", which does mention "risks of denial of = service attacks". Is that the risk you're referring to, or something else? * Section 4.3. (BGP Route Damping) mentions "the principle described= in this document", which I thought was related to the goals, but Section 1= says that the "base principle is described in Section 3". I'm assuming t= he "principle" in question is such that a "network operator=85can delay the= propagation of multicast state prune messages between PEs, when faced with= a rate of multicast state dynamicity exceeding a certain configurable thre= shold". That sounds like a potential goal to me. 5. Section 5.2. (Procedures for multicast VPN state damping) * In the Introduction you write that "Section 16 of [RFC6514] specif= ically spells out the need for damping the activity=85" I think that RFC65= 14 does a lot more than that: Section 16.1. (Dampening C-Multicast Routes)= "proposes OPTIONAL route dampening procedures similar to what is described= in [RFC2439]." Those procedures look very similar to the ones in this do= cument. What is the difference? Is the intent of this document to complem= ent, replace or maybe update what is already specified in RFC6514? * There's an rfc2119 conflict. "=85then the withdrawal of a C-mult= icast route=85SHOULD NOT be damped. An implementation of the specification= in this document MUST whether, not damp these withdrawals by default, or a= lternatively provide a tuning knob to disable the damping of these withdraw= als." s/whether/either The "MUST..not damp" and "SHOULD NOT be damped" a= re in conflict. I think that eliminating the last sentence would fix the= problem and still allow an implementation to put in any knobs that it want= s. 6. Section 7.3. (Default and maximum values) lists values that are "RECO= MMENDED to adopt as default conservative values". Any guidance about when = and/or how an operator should consider changing the recommended defaults? = What does "conservative" mean in this context? What if the operator wants = to be more aggressive? Minor: 1. In 4.2 * s/prune override interval/J/P_Override_Interval * Reference for explicit tracking..?? BTW, how would the mechanism = in this document interact with explicit tracking? 2. Section 5.1. (PIM procedures): * "=85a router implementing these procedures MUST=85apply unchanged = procedures for everything=85". I guess that these "unchanged procedures" a= re the ones in rfc4601bis, right? In other words, what you seem to want is= that, in addition to what rfc4601bis specifies, for the other steps define= d in this document to happen. If that is correct, please reword the descri= ption to make it clear =97 at least put a reference so that there is no que= stion about which procedures are left unchanged. * "=85freeze the upstream state machine=85and setup a trigger to upd= ate it=85" Maybe a word like "hold" or "maintain" might be better. In fac= t, even better would be an explicit indication that "events that may result= in the state changing [rfc4601bis] SHOULD be ignored until the reuse thres= hold is reached", or something along those lines. What should the state be= updated to when the reuse threshold is reached? * I had some trouble parsing this text: "When the recompilation is d= one periodically, the period should be low enough to not significantly dela= y the inactivation of damping on a multicast state beyond what the operator= wanted to configure (i.e. for a *decay-half-life* of 10s, recomputing the = *figure-of-merit* each minute would result in a multicast state to remained= damped for a much longer time than what the parameters are supposed to com= mand)." I think I got it=85but what I don't get (based on my understandi= ng of RFC2439) is that the figure-of-merit should decay according to the ha= lf-life, so I don't get why its value would be adjusted at a period that is= not related to the half-life. 3. Section 5.2. (Procedures for multicast VPN state damping) * There are several places in this section where rfc2119 language is= used to describe what an implementation should do that sound to me as an a= ttempt to define functionality that is mandatory to implement (MTI). I fin= d that hard/impossible to enforce and would like to see the rfc2119 languag= e removed. Please see below.. * The text says that an "implementation of [RFC6513] relying on the = use of PIM to carry C-multicast routing information MUST support this techn= ique." That "MUST" is really strong and it makes me think that this docume= nt should then be marked as an update to RFC6513. Is that the intent? Rea= ding through it again, is the intent MTI? * "=85the following procedure is proposed as an alternative to the p= rocedures in Section 5.1=85" "proposed"?? Does this mean that 5.1 is also= applicable in this case (when "BGP is used to distribute C-multicast routi= ng information")? It sounds like the operator would have an option =97 if= so, when should each be considered? * Later in the same section you wrote: "=85choice to implement da= mping based on BGP routes or the procedures described in Section 5, is up t= o the implementor, but at least one of the two MUST be implemented." I thi= nk it should be section 5.1. Do you really mean the "implementor", or are = you referring to the operator of the network? The "MUST" sounds too strong= for me because it is not needed for interoperability (rfc2119) -- or is th= is an attempt at MTI? * Same question/observation for "In the perspective of allowing d= amping to be done on RRs and ASBRs, implementing the BGP approach is RECOMM= ENDED." Maybe s/RECOMMENDED/recommended * "=85it can be considered useful to also be able to apply damping o= n RRs as well." When is it considered useful? * Note that later you also write: "=85in such a context, it is RE= COMMENDED to not enable any multicast VPN route damping on RRs=85" This p= artially answers the question. It would be nice to put the guidance togeth= er. * "=85damping SHOULD NOT be applied to BGP routes of the following s= ub-types=85" Are there cases when it is ok? In other words, why is the "S= HOULD NOT" not a "MUST NOT"? 4. Section 6.1. (Damping mVPN P-tunnel change events) "Possible ways to = do so depend on the type of P-tunnel, and local implementation details are = left up to the implementor. The following is proposed as example of how= the above can be achieved." Either you leave it as an implementation deta= il or you provide guidance. If this document was Experimental, then provid= ing guidance it great! Nits: 1. Please put references on first appearance. For example, IGMP and MLD= are mentioned in the introduction, but no reference is made until the 5th = mention. The same for BGP route damping=85 * You also need a reference to route reflectors. 2. "these control planes" Which control planes? Please be specific. = There are other places where "these" is uses that may not be completely cle= ar..please take a look. 3. s/these specifications/this specification 4. s/when enabled /when enabled, 5. "PIM-SM specifications [RFC4609]" RFC4609 is not the PIM spec. 6. Section 6.2. (Procedures for Ethernet VPNs) "=85an implementation of= these procedures MUST follow the procedures described in Section 6.1." It= is not completely clear which "these procedures" are. I'm guessing RFC711= 7. --_000_D2DBF5CB10DEE7aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <81E6FB20E580E343ACE076F5AA614046@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

I think that the title of this document clearly reflects what you want to d= o =97 which may be one of the reasons there was virtually no discussion abo= ut it (or any of its predecessors) on the list.  However, I think the = contents leave many open doors that need to be closed before this document can be published.

I put more detai= led comments below, but my main concerns are here:
  1. The Abstract says that the procedures= are "inspired from BG= P unicast route damping".  It seems to me that the intent is in fact to ad= opt the algorithm from RFC243= 9.  However, the text is not explicit/clear about that. 
  2. As you all know, the history behind BGP damping has not been without it bei= ng considered useless and even having recommendations (from RIPE, for examp= le) not to use it.  How did you arrive at the default and maximum valu= es?  It concerns me that there are no known implementations (from the Shepherd's report).  Because of that, = I think this document would be better suited as an Experimental R= FC, with the explicit purpose of gaining experience with the values and det= ermine the impact in live deployments (which then could support a standard version).  Please consider changing the intended S= tatus.
According to the e-mail archive, it looks like an early presentation of thi= s work happened in an mboned meeting, but I didn't find discussion on the p= im or idr lists.  Once the comments below are addressed I will want to= forward the document to pim/idr for their review.

Thanks!

Alvaro.


Major:
  1. There are 6 authors listed on the front page.  According to RFC7322, t= he total number is generally limited to 5.  Please work among yourselv= es to cut the number of authors.  Alternatively, we can just list an E= ditor (there's one already identified)..or you can produce a justification detailing the contributions of each author to = consider an exception.
  2. Replace the reference to RFC4601 with a reference to draft-ietf-pim-rfc4601= bis.  Note that the section numbers have changed slightly!
  3. Are you adopting the exponential decay algorithm from RFC2439?  That s= eems to be what's happening because you are not explicitly defining a new a= lgorithm, but some of the text leave doubts.  For example:
    • "inspired from BGP unicast route damping"  I know the applic= ation is different, but if the algorithm is the same then please say it.
    • Section 5.1. (PIM procedures)
      • "updating the *figure-of-merit* based on the decay algorithm must be d= one prior to this increment"  This statement seems to directly im= ply that the algorithm is used.  Please reorder the steps to explicitl= y call this one out, instead of plugging it in as an afterthought.  BTW, should the "must" be "MUST"? =  Ordering should help you not having to deal with that last question.<= /li>
      • "Same tec= hniques as the ones described in [RFC2439] can be applied=85"   &q= uot;Can be"?  This sentence seems to imply that what is described= in RFC2439 is optional.  Are there other ways of determining the same= thing?  What about the exponential decay algorithm?
      • It would also help if the terminology was c= onsistent.  For example, instead of "damping becomes active&= quot; use "suppressed".  I can see how "suppressed= " may give the wrong impression as only the propagation of s= tate is affected.  Explaining then how the terminology applies would make it easie= r to reuse, avoid confusion and be clear.  Note that there's no mentio= n of RFC2439 in the terminology section.
  4. Section 3. (Overview): "= =85it is expected that this technique will allow to mee= t the goals of protecting the multicast routing infrastructure control plane without a significant average increase of bandwidth".  In genera= l, I want to make sure that the qualities of the solution and the expe= cted results are properly reflected in the document. [I'm using the text above as the base for my comment, but the impact is larger.= ]  Some questions:
    • "=85technique will=85"  I wonder why an assertion can't be made that this technique can (vs just expecting that it will) address specific problems.=  Is it the case that experience is needed to make a stronger assertio= n?  Are the goals the same (or at least similar) in every network? &nb= sp;Are there implementations available?  If so, please consider an "Implementation Status" section (see rfc6982).  What has been the deployment= experience?  This goes back to my comment above about the Intended St= atus of this document.
    • What specifically are the goals? &= nbsp;In a couple of places the text points back at Section 1. (Introduction), but I'm not sure exactly what the goals are.  Of special in= terest for understanding the goals is the part in Section 4.2. (Existing PIM, IGMP and MLD timers) where= other solutions are discarded for not meeting them.
      • There is scattered text that t= alks about "=85ensure that th= e load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control=85", "protecting these control planes=85avoiding negative effects=85although at th= e expense of a minimal increase in average of bandwidth use=85".   However, the descripti= on is too vague to point at what can satisfy these goals and what can't.
    • Section 4.1. (Rate-limiting of multicast control traffic) mentions the "risk described in Section 1", which does mentio= n "risks of denial of service attacks".  Is that the risk you're referrin= g to, or something else?   
    • Section 4.3. (BGP Route Damping) mentions "the principle described in this document", which I thought was related to the goals, but= Section 1 says that  the "base principle is described in Section 3".  I'm assuming the &= quot;principle" in question is such that a "network operator=85can delay the propagat= ion of multicast state prune messages between PEs, when faced w= ith a rate of multicast state dynamicity exceeding a certain configurable t= hreshold".  That sounds like a potential goal to me.
  5. Section 5.2. (Procedures for multica= st VPN state damping)  
    • In the Introduction you write = that "Section= 16 of [RFC6514] specifically spells out the need for damping the activit= y=85"  I think that RFC6514 does a lot more than that:  Sect= ion 16.1. (Dampening C-Multicast Routes) "proposes OPTIONAL route dampening procedures similar to what is described in [RFC2439]."   Th= ose procedures look very similar to the ones in this document.  What i= s the difference?  Is the intent of this document to complement, = replace or maybe update what is already specified in RFC6514?
      • There's an rfc2119 conflict.   "= ;=85then the withd= rawal of a C-multicast route=85SHOULD NOT be damped.  An implementation of the specification in this <= /span>document MUST wheth= er, not damp these withdrawals by default, or alternatively provide a tuning knob to disable the damping of these withdrawals."  s/whether/either   The &quo= t;MUST..not damp" and "SHOULD NOT be damped" are in conflict= .    I think that eliminating the last sentence would fix th= e problem and still allow an implementation to put in any knobs that it wants.
    • Section 7.3. (Default and maximum values) lists values that are= "RECOMMENDED to adopt as default conservative values".  Any guidance about wh= en and/or how an operator should consider changing the recommended defaults= ?  What does "conservative" mean in this context?  What= if the operator wants to be more aggressive? 


Minor:
  1. In 4.2
    • s/prune override interval/J/P_Override_Interval
    • Reference for explicit tracking..??  BTW, how would the= mechanism in this document interact with explicit tracking?
    • Section 5.1. (PIM procedures): =
      • "=85a router implementing these procedures MUST=85apply unchanged procedures for everything=85".  I guess that these "unchanged procedures" are the ones in rfc4601b= is, right?  In other words, what you seem to want is that, in addition= to what rfc4601bis specifies, for the other steps defined in this document= to happen.  If that is correct, please reword the description to make it clear =97 at least put a reference so= that there is no question about which procedures are left unchan= ged.
      • "=85freeze the upstream state machine=85and setup a trigger to update it=85"  Maybe a word like "hold" or "maintain" might be = better.  In fact, even better would be an explicit indication tha= t "events that may result in the state changing [rfc4601bis] SHOULD be= ignored until the reuse threshold is reached", or something alon= g those lines.  What should the state be updated to when the reuse threshold = is reached?
      • I had some tro= uble parsing this text: "When= the recompilation is done periodically, the period should be low enough to no= t significant= ly delay the inactivation of damping on a multicast state beyond what the operator wanted = to configure (i.e. for a *decay-half-life* of 10s, recomputing the *figure-of-merit* each minute would result in a multicast state to remained damped = for a much longer time than w= hat the parameters are supposed to command)."    I think I got it=85but what I don't get (based= on my understanding of RFC2439) is that the figure-of-merit should de= cay according to the half-life, so I don't get why its value would be = adjusted at a period that is not related to the half-life.
    • Section 5.2. (Procedures for multicast VPN state damping) 
      • There are several places in this sect= ion where rfc2119 language is used to describe what an implementation shoul= d do that sound to me as an attempt to define functionality that is&nb= sp;mandatory to implement (MTI).  I find that hard/impossible to enforce and would like to see the rfc2119 language remo= ved.  Please see below..
      • The text says that an "implementation of [RFC6513] rel= ying on the use of PIM to carry C-multicast routing information MUST support this technique."  That "MUST" is really strong and it = makes me think that this document should then be marked as an update to RFC= 6513.  Is that the intent?  Reading through it again, is the intent MTI?
      • =85the following procedure is proposed as an alternative to the procedures in Section 5.1=85"  = ;"proposed"??  Does this mean that 5.1 is also applicable in= this case (when "BGP is used to distribute C-mult= icast routing information")?   It sounds like the operator would = have an option =97 if so, when should each be considered?
        • Later in the same section you wrote: "=85choice to implement damping b= ased on BGP routes or the procedures described in Section 5, is up to the i= mplementor, but at least one of the two MUST be implemented."  I = think it should be section 5.1.  Do you really mean the "implementor", or are you referring to the operator of the n= etwork?  The "MUST" sounds too strong for me because it is n= ot needed for interoperability (rfc2119) -- or is this an attempt at MTI?
        • Same question/observation for &quo= t;In the perspective of allowing damping to be done on RRs and ASBRs, imple= menting the BGP approach is RECOMMENDED."  Maybe s/RECOMMENDED/re= commended
      • "=85it can be=  considered u= seful to also be able to apply damping on RRs as well."  When is it considered useful?
        • Note that later you also write: "=85in such a context, it is RECOMMENDED to not enable any multicast = VPN route damping on RRs=85"   This partially answers the qu= estion.  It would be nice to put the guidance together.
        • "=85damping SHOULD N= OT be applied to BGP routes of the following sub-types=85"  Are there cases when it is ok?  In other words, why is the "SHOULD NOT" not= a "MUST NOT"?
      • 6.1. (Damping mVPN = P-tunnel change events) "Possible ways to do so left up to the im= plementor.     The following is proposed as example of how the above can be achieved."  Either you leave it as a= n implementation detail or you provide guidance.  If this documen= t was Experimental, then providing guidance it great!


Nits:
  1. Please put references on first appearance.  For example, IGMP and MLD = are mentioned in the introduction, but no reference is made until the 5th m= ention.  The same for BGP route damping=85
    • You also need a reference to route reflectors.
  2. "these control planes"  Which control planes?  Please b= e specific.   There are other places where "these" is uses t= hat may not be completely clear..please take a look.
  3. s/these specifications/this specification
  4. s/when enabled /when enabled,
  5. "PIM-SM specifications [RFC4609]"   RFC4609 is not the PIM s= pec.
  6. Section 6.2. (Procedures for= Ethernet VPNs)  "=85an implementation of these procedures MUST f= ollow the procedures described in Section 6.1."  It is not comple= tely clear which "these procedures" are.  I'm guessing RFC71= 17.

--_000_D2DBF5CB10DEE7aretanaciscocom_-- From nobody Wed Feb 24 08:58:16 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822591A017C; Wed, 24 Feb 2016 08:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.411 X-Spam-Level: * X-Spam-Status: No, score=1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MANGLED_BELOW=2.3, RP_MATCHES_RCVD=-0.006, SPF_SOFTFAIL=0.665] 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 W07HVHcoF8rv; Wed, 24 Feb 2016 08:58:07 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 267FC1B2A66; Wed, 24 Feb 2016 08:58:06 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4DF67E30080; Wed, 24 Feb 2016 17:58:05 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 09D36E3007F; Wed, 24 Feb 2016 17:58:04 +0100 (CET) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Wed, 24 Feb 2016 17:58:03 +0100 To: "Alvaro Retana (aretana)" , "draft-ietf-bess-multicast-damping@ietf.org" References: From: Thomas Morin Organization: Orange Message-ID: <56CDE11B.1000900@orange.com> Date: Wed, 24 Feb 2016 17:58:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040507000107040807090200" Archived-At: Cc: "bess-chairs@ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-multicast-damping-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 16:58:14 -0000 --------------040507000107040807090200 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Alvaro, Thanks for your very careful review. I may not agree with every comment made, but many will certainly improve the document. See inlined below... Thanks, -Thomas 2016-02-23, Alvaro Retana (aretana): > The Abstract says that the procedures are "inspired from BGP unicast > route damping". It seems to me that the intent is in fact to adopt > the algorithm from RFC2439. However, the text is not explicit/clear > about that. Saying so would I think actually be a misleading simplification, the reader may miss the facts: - that the proposal is to keep advertising a dampened multicast VPN state up (in RFC2439, a dampened route stops being advertised) - that the document is not BGP-specific but also specifies a mechanism for the PIM FSM - that only exponential decay is borrowed from RFC2439 > 1. As you all know, the history behind BGP damping has not been > without it being considered useless and even having > recommendations (from RIPE, for example) not to use it. > A few things are important to have in mind: - the application context here is not the Internet - multicast state propagates in a very different fashion - the damping algorithm techniques is not the same - the side-effects of damping unicast and damping multicast as proposed here are fundamentally different: here damping causes no impact on the service Overall, I would say that the weaknesses of RFC2439 and the recommendations in RFC7196 were well known by co-authors and that we came to the conclusion that this multicast VPN would not suffer from similar weaknesses. > How did you arrive at the default and maximum values? By simulating with simple parameters and choosing conservative low-risk values. Considering that, by design, whatever the parameters, multicast streams will be delivered unchanged and that the only thing you tradeoff against is less dynamicity and a possibly slightly increased bandwidth use, the default and maximum values do not have to be perfectly tuned. > It concerns me that there are no known implementations (from the > Shepherd's report). This concern is valid. See below... > Because of that, I think this document would be better suited as an > Experimental RFC, with the explicit purpose of gaining experience with > the values and determine the impact in live deployments (which then > could support a standard version). Please consider changing the > intended Status. Let me go back to why this proposal started: some lab testing was done showing that it was easy, in the lab, to create significant overload on PE and RRs BGP stacks by flapping multicast state at the edge. Having a standard track to provide the appropriate tooling against this DoS risk seems to me as making sense. I think that the proposed procedures are not close enough to the solution and problem addressed by RFC2439 to say that RFC2439's history is an argument to pass through an Experimental RFC first. > According to the e-mail archive, it looks like an early presentation > of this work happened in an mboned meeting, but I didn't find > discussion on the pim or idr lists. Once the comments below are > addressed I will want to forward the document to pim/idr for their review. Practically speaking pim/mboned is roughly the same people. But yes, forwarding the document to these working group is fine. > Major: > > 1. There are 6 authors listed on the front page. According to > RFC7322, the total number is generally limited to 5. Please work > among yourselves to cut the number of authors. Alternatively, we > can just list an Editor (there's one already identified)..or you > can produce a justification detailing the contributions of each > author to consider an exception. > Ok, we will address that. > 1. Replace the reference to RFC4601 with a reference to > draft-ietf-pim-rfc4601bis. Note that the section numbers have > changed slightly! > Yes, we can update. (you see me surprised to see that appear as a "major" issue!) > 1. Are you adopting the exponential decay algorithm from RFC2439? > That seems to be what's happening because you are not explicitly > defining a new algorithm, but some of the text leave doubts. For > example: > * "inspired from BGP unicast route damping" I know the > application is different, but if the algorithm is the same > then please say it. > The procedures associated to the exponential decay are different. > 1. > * Section 5.1. (PIM procedures) > o "updating the *figure-of-merit* based on the decay > algorithm must be done prior to this increment" This > statement seems to directly imply that the algorithm is > used. Please reorder the steps to explicitly call this > one out, instead of plugging it in as an afterthought. > BTW, should the "must" be "MUST"? Ordering should help > you not having to deal with that last question. > I've revised the text to describe this step in its own bullet, prior to "updating the figure-of-merit", to avoid this "after thought" impression and make it as mandatory as the other steps. > 1. > * > o "Same techniques as the ones described in [RFC2439] can be > applied…" "Can be"? This sentence seems to imply that > what is described in RFC2439 is optional. Are there other > ways of determining the same thing? What about the > exponential decay algorithm? > No, there are just multiple ways possible to update the figure-of-merit, including the ones RFC2439 mention or detail. I've reformulated the text to avoid misinterpretation: These specifications do not impose the use of a particular technique to update the *figure-of-merit* following the exponential decay algorithm based on the configured *decay-half-life*. In particular the same techniques as the ones described in [RFC2439] can be applied. The only requirement is that the *figure-of-merit* has to be updated prior to increasing it and that its decay below the *reuse-threshold* has to be timely reacted upon: in particular, if the recomputation is done periodically, the period should be low enough to not significantly delay the inactivation of damping on a multicast state beyond what the operator wanted to configure (i.e. for a *decay-half-life* of 10s, recomputing the *figure-of-merit* each minute would result in a multicast state to remained damped for a much longer time than what the parameters are supposed to command). > 1. > * > o It would also help if the terminology was consistent. For > example, instead of "damping becomes active" use > "suppressed". I can see how "suppressed" may give the > wrong impression as only the propagation of state is > affected. Explaining then how the terminology applies > would make it easier to reuse, avoid confusion and be > clear. Note that there's no mention of RFC2439 in the > terminology section. > Using the "suppressed" term to describe a state that we artifically keep active is the most confusing thing that I can think of. As you say this would give a wrong impression. I would go as far as to say that the document would be barely understandable. But maybe we can add this to the terminology section: In these specifications, damping of a multicast state will be said to be "active" or "inactive". Note that the term used for a unicast route which is dampened is "suppressed", but we avoid this term is these specifications given that a dampened multicast state is kept active. Would that help ? > 1. > * > > 2. Section 3. (Overview): "…it is expected that this technique will > allow to meet the goals of protecting the multicast routing > infrastructure control plane without a significant > average increase of bandwidth". In general, I want to make sure > that the qualities of the solution and the expected results are > properly reflected in the document. [I'm using the text above as > the base for my comment, but the impact is larger.] Some questions: > * "…it is expected that this technique will…" I wonder why an > assertion can't be made that this technique can (vs just > expecting that it will) address specific problems. Is it the > case that experience is needed to make a stronger assertion? > Are the goals the same (or at least similar) in every > network? Are there implementations available? If so, please > consider an "Implementation Status" section (see rfc6982). > What has been the deployment experience? This goes back to > my comment above about the Intended Status of this document. > "It is expected" reflects the idea that the slight increase in bandwidth will not be significant in most cases. We can expand the text a bit to explain what would be the cases where that would not work. Let me suggest the following reformulation: "That said, basic simulation of the exponential decay algorithm show that the multicast state churn can be drastically reduced without significantly increasing the duration for which multicast traffic is forwarded. Hence, using this technique will efficiently protect the multicast routing infrastructure control plane against the issues described here, without a significant average increase of bandwidth. The exception will be a scenario where the network dimensioning does not allow to extend the time a multicast flow is forwarded beyond the duration for which is it needed by receivers". > 1. > * What specifically are the goals? In a couple of places the > text points back at Section 1. (Introduction), but I'm not > sure exactly what the goals are. Of special interest for > understanding the goals is the part in Section 4.2. (Existing > PIM, IGMP and MLD timers) where other solutions are discarded > for not meeting them. > o There is scattered text that talks about "…ensure that the > load put on the BGP control plane, and on the P-tunnel > setup control plane, remains under control…", "protecting > these control planes…avoiding negative effects…although at > the expense of a minimal increase in average of > bandwidth use…". However, the description is too vague > to point at what can satisfy these goals and what can't. > Section one 1 says: - " Hence, mechanisms need to be put in place to ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control regardless of the frequency at which multicast memberships changes are made by end hosts." -then "This document describes procedures, remotely inspired from existing BGP route damping, aimed at protecting these control planes while at the same time avoiding negative effects on the service provided, although at the expense of a minimal increase in average of bandwidth use in the network." The intent was that the text would be enough to make the goals clear. Would the following change of the second sentence provide suitable detail to help understand what can satisfy these goals and what can't : ...? [...] aimed at offering means to set an upper bound to the affected control planes (BGP RFC6514 processing, and the P-tunnel control plane protocol in certain cases as well) while at the same time preserving service provided (delivering the stream to the end user as requested), although at the expense of a minimal increase in average of bandwidth use in the network. I see that we can reorder the text to avoid splitting the explanation of goals. The new text would look like the following: In VPN contexts, providing isolation between customers of a shared infrastructure is a core requirement resulting in stringent expectations with regards to risks of denial of service attacks. By nature multicast memberships change based on the behavior of multicast applications running on end hosts, hence the frequency of membership changes can legitimately be much higher than the typical churn of unicast routing states. Section 16 of [RFC6514] specifically spells out the need for damping the activity of C-multicast and Leaf Auto-discovery routes. Hence, mechanisms need to be put in place to ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control regardless of the frequency at which multicast memberships changes are made by end hosts. This document describes procedures, remotely inspired from existing BGP route damping, aimed at offering means to set an upper bound to the amount of processing for the mVPN control planes protocols ([RFC6514], and the P-tunnel control plane protocol in certain cases as well), while at the same time preserving service provided (delivering the stream to the end user as requested), although at the expense of a minimal increase in average of bandwidth use in the network. > 1. > > > > * Section 4.1. (Rate-limiting of multicast control traffic) > mentions the "risk described in Section 1", which does mention > "risks of denial of service attacks". Is that the risk you're > referring to, or something else? > Yes. I've made that explicit in section 4.1. > 1. > * Section 4.3. (BGP Route Damping) mentions "the principle > described in this document", which I thought was related to > the goals, but Section 1 says that the "base principle is > described in Section 3". I'm assuming the "principle" in > question is such that a "network operator…can delay the > propagation of multicast state prune messages between PEs, > when faced with a rate of multicast state dynamicity exceeding > a certain configurable threshold". That sounds like a > potential goal to me. > The base principe described in section 3 is a way to achieve the goal, rather than a goal in itself. > 1. > > > 2. Section 5.2. (Procedures for multicast VPN state damping) > * In the Introduction you write that "Section 16 of [RFC6514] > specifically spells out the need for damping the activity…" I > think that RFC6514 does a lot more than that: Section 16.1. > (Dampening C-Multicast Routes) "proposes OPTIONAL > route dampening procedures similar to what is described in > [RFC2439]." Those procedures look very similar to the ones > in this document. What is the difference? Is the intent of > this document to complement, replace or maybe update what is > already specified in RFC6514? > Indeed, the base ideas for dampening were already here when we wrote RFC6514. draft-ietf-bess-multicast-damping provides precision on how to implement RFC6514 16.1.1, but this is not an update per se as nothing in RFC6514 is changed. We can make that fully explicit by saying in Section 1: Section 16 of [RFC6514] specifically spells out the need for damping the activity of C-multicast and Leaf Auto-discovery routes, and outlines how to do it by "delay the advertisement of withdrawals of C-multicast routes". These specifications provides appropriate detail on how to implement that and how to make that controllable by the operator. > 1. > * There's an rfc2119 conflict. "…then the withdrawal of a > C-multicast route…SHOULD NOT be damped. An implementation of > the specification in this document MUST whether, not damp > these withdrawals by default, or alternatively provide a > tuning knob to disable the damping of these withdrawals." > s/whether/either The "MUST..not damp" and "SHOULD NOT be > damped" are in conflict. I think that eliminating the last > sentence would fix the problem and still allow an > implementation to put in any knobs that it wants. > (Ok for s/whether/either) These two sentences were discussed already quite a lot, and I think we need to keep this. There is in fact not a conflict: what needs to be enforced in a deployment is that "[under some conditions] ... SHOULD NOT damp some specific withdrawals", to ensure that in implementations that this will doable we add "MUST ([not damp these withdrawals by default] or [provide a tuning knob to not damp these withdrawals])". Removing the second sentence would mean something not strong enough: on implementations that damp withdrawals by default (they can do that, because this is acceptable in some deployments), we absolutely need the knob (to address the more problematic deployment scenario). > 1. > > > > 2. Section 7.3. (Default and maximum values) lists values that are > "RECOMMENDED to adopt as default conservative values". Any guid >> 1. ance about when and/or how an operator should consider >> changing the recommended defaults? What does "conservative" >> mean in this context? What if the operator wants to be >> more aggressive? > We can certainly improve this section a little bit. I propose to add: This section proposes default and maximum values, conservative so as to not significantly impact network dimentioning but still prevent post-dampening multicast state churn to go beyond what can be considered a reasonably low churn for a multicast state. The following values are RECOMMENDED to adopt as default values: And, as illustrations: With these values, as an illustrations: o a multicast state not updated more frequently than one every 6s will not be dampened o a multicast state changing once per second for 3s, and then not changing, will not be dampened o a multicast state changing once per second for 4s, and then not changing, will be dampened after the fourth change for approximately 13s o a multicast state changing twice per second for 30s, and then not changing, will be dampened after the fourth change for approximately 13s > 1. >> >> >> Minor: > > 1. In 4.2 > * s/prune override interval/J/P_Override_Interval > I'd rather keep the plain text version. > 1. > * Reference for explicit tracking..?? BTW, how would the > mechanism in this document interact with explicit tracking? > Will add a reference. > 1. Section 5.1. (PIM procedures): > * "…a router implementing these procedures MUST…apply unchanged > procedures for everything…". I guess that these "unchanged > procedures" are the ones in rfc4601bis, right? In other > words, what you seem to want is that, in addition to what > rfc4601bis specifies, for the other steps defined in this > document to happen. If that is correct, please reword the > description to make it clear — at least put a reference so > that there is no question about which procedures are left > unchanged. > Ok. > 1. > * "…freeze the upstream state machine…and setup a trigger to > update it…" Maybe a word like "hold" or "maintain" might be > better. In fact, even better would be an explicit indication > that "events that may result in the state changing > [rfc4601bis] SHOULD be ignored until the reuse threshold is > reached", or something along those lines. > I'll adopt your suggested text, with the precision that only changes in the upstream state machinie will be ignored. > 1. > * What should the state be updated to when the reuse threshold > is reached? > I've added this detail. hold the upstream state machine in Joined state so that events that may result in the upstream state changing based on RFC4601bis SHOULD be ignored until the reuse threshold is reached, and setup a trigger to update the upstream state machine based on downstream state machines once the reuse threshold is reached. The effect is that in the meantime, PIM Join messages will be sent as refreshes to the upstream neighbor, but no PIM Prune message will be sent. > 1. > * I had some trouble parsing this text: "When > the recompilation is done periodically, the period should be > low enough to not significantly delay the inactivation of > damping on a multicast state beyond what the operator wanted > to configure (i.e. for a *decay-half-life* of 10s, recomputing > the *figure-of-merit* each minute would result in a multicast > state to remained damped for a much longer time than what the > parameters are supposed to command)." I think I got it…but > what I don't get (based on my understanding of RFC2439) is > that the figure-of-merit should decay according to the > half-life, so I don't get why its value would be adjusted at a > period that is not related to the half-life. > You have many ways to simulate a behavior triggered by a decaying value crossing a threshold: - periodically recompute the value and see whether it crossed the threshold: naive/easy approach, the period does not need to be related to the decay-half-life as long as it is short enough - compute the time at which it will reach the threshold and setup a timer to fire at that time - more optimized to group computation for multiple routes/states, see RFC2439 > 1. > > > 2. Section 5.2. (Procedures for multicast VPN state damping) > * There are several places in this section where rfc2119 > language is used to describe what an implementation should do > that sound to me as an attempt to define functionality that > is mandatory to implement (MTI). I find that hard/impossible > to enforce and would like to see the rfc2119 language removed. > Please see below.. > Yes, the MUSTs in this 5.1 and 5.2 intent to carry the meaning of "mandatory to implement". > 1. > * The text says that an "implementation of [RFC6513] relying on > the use of PIM to carry C-multicast routing information MUST > support this technique." That "MUST" is really strong and it > makes me think that this document should then be marked as an > update to RFC6513. Is that the intent? Reading through it > again, is the intent MTI? > No, the intent is not to update RFC6513. I've added the precision: "MUST support this technique, to be compliant with these specifications." > 1. > * "…the following procedure is proposed as an alternative to the > procedures in Section 5.1…" "proposed"?? Does this mean that > 5.1 is also applicable in this case (when "BGP is used to > distribute C-multicast routing information")? > Yes. > 1. > * It sounds like the operator would have an option — if so, > when should each be considered? > o Later in the same section you wrote: "…choice to implement > damping based on BGP routes or the procedures described in > Section 5, is up to the implementor, but at least one of > the two MUST be implemented." I think it should be > section 5.1. > Yes indeed. I will correct. > 1. > * > o Do you really mean the "implementor", or are you > referring to the operator of the network? The "MUST" > sounds too strong for me because it is not needed for > interoperability (rfc2119) -- or is this an attempt at MTI? > This is an indication for implementors, so MTI. > 1. > * > o Same question/observation for "In the perspective of > allowing damping to be done on RRs and ASBRs, implementing > the BGP approach is RECOMMENDED." Maybe > s/RECOMMENDED/recommended > I understand that you seem to prefer avoiding RFC2119 language for MTI things. But I don't know another way than RFC2119 language to indicate what is mandatory to implement to be compliant with a spec, and I think this is a fairly well established practice. This is not the first document to use RFC2119 to indicate MTI things. What is the rationale for not using RFC2119 language ? > 1. > * > > * "…it can be considered useful to also be able to apply damping > on RRs as well." When is it considered useful? > o Note that later you also write: "…in such a context, it is > RECOMMENDED to not enable any multicast VPN route damping > on RRs…" This partially answers the question. It would > be nice to put the guidance together. > I've added text to improve that. > 1. > * > > * "…damping SHOULD NOT be applied to BGP routes of the following > sub-types…" Are there cases when it is ok? In other words, > why is the "SHOULD NOT" not a "MUST NOT"? > Maybe someone can find a case where this does not break things, under some conditions. We saw nothing mandating the use of "MUST NOT". > 1. > > > 2. Section 6.1. (Damping mVPN P-tunnel change events) "Possible ways > to do so depend on the type of P-tunnel, and local implementation > details are left up to the implementor. The following is > proposed as example of how the above can be achieved." Either you > leave it as an implementation detail or you provide guidance. If > this document was Experimental, then providing guidance it great! > There is a gap between "example" and "guidance". I think an example can help the reader (implementor or deployer). Guidance would mean that we start influencing the implementor, which is not the idea here. > > > Nits: > > 1. Please put references on first appearance. For example, IGMP and > MLD are mentioned in the introduction, but no reference is made > until the 5th mention. The same for BGP route damping… > Ok. > 1. > * You also need a reference to route reflectors. > Added. > 1. > > > 2. "these control planes" Which control planes? Please be specific. > There are other places where "these" is uses that may not be > completely clear..please take a look. > Reworded as part of other changes following your comments. > 1. s/these specifications/this specification > ok > 1. s/when enabled /when enabled, > ok > > 1. "PIM-SM specifications [RFC4609]" RFC4609 is not the PIM spec. > Yes, typo. Thanks. > 1. Section 6.2. (Procedures for Ethernet VPNs) "…an implementation > of these procedures MUST follow the procedures described in > Section 6.1." It is not completely clear which "these procedures" > are. I'm guessing RFC7117. > Yes, fixed. --------------040507000107040807090200 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Alvaro,

Thanks for your very careful review.
I may not agree with every comment made, but many will certainly improve the document.

See inlined below...

Thanks,

-Thomas


2016-02-23, Alvaro Retana (aretana):
The Abstract says that the procedures are "inspired from BGP unicast route damping".  It seems to me that the intent is in fact to adopt the algorithm from RFC2439.  However, the text is not explicit/clear about that.

Saying so would I think actually be a misleading simplification, the reader may miss the facts:
- that the proposal is to keep advertising a dampened multicast VPN state up (in RFC2439, a dampened route stops being advertised)
- that the document is not BGP-specific but also specifies a mechanism for the PIM FSM
- that only exponential decay is borrowed from RFC2439

  1. As you all know, the history behind BGP damping has not been without it being considered useless and even having recommendations (from RIPE, for example) not to use it. 

A few things are important to have in mind:
- the application context here is not the Internet
- multicast state propagates in a very different fashion
- the damping algorithm techniques is not the same
- the side-effects of damping unicast and damping multicast as proposed here are fundamentally different: here damping causes no impact on the service

Overall, I would say that the weaknesses of RFC2439 and the recommendations in RFC7196 were well known by co-authors and that we came to the conclusion that this multicast VPN would not suffer from similar weaknesses.

How did you arrive at the default and maximum values? 

By simulating with simple parameters and choosing conservative low-risk values.
Considering that, by design, whatever the parameters, multicast streams will be delivered unchanged and that the only thing you tradeoff against is less dynamicity and a possibly slightly increased bandwidth use, the default and maximum values do not have to be perfectly tuned.

It concerns me that there are no known implementations (from the Shepherd's report). 

This concern is valid.
See below...

Because of that, I think this document would be better suited as an Experimental RFC, with the explicit purpose of gaining experience with the values and determine the impact in live deployments (which then could support a standard version).  Please consider changing the intended Status.

Let me go back to why this proposal started: some lab testing was done showing that it was easy, in the lab, to create significant overload on PE and RRs BGP stacks by flapping multicast state at the edge.  Having a standard track to provide the appropriate tooling against this DoS risk seems to me as making sense.  I think that the proposed procedures are not close enough to the solution and problem addressed by RFC2439 to say that RFC2439's history is an argument to pass through an Experimental RFC first.

According to the e-mail archive, it looks like an early presentation of this work happened in an mboned meeting, but I didn't find discussion on the pim or idr lists.  Once the comments below are addressed I will want to forward the document to pim/idr for their review.

Practically speaking pim/mboned is roughly the same people.
But yes, forwarding the document to these working group is fine.

Major:
  1. There are 6 authors listed on the front page.  According to RFC7322, the total number is generally limited to 5.  Please work among yourselves to cut the number of authors.  Alternatively, we can just list an Editor (there's one already identified)..or you can produce a justification detailing the contributions of each author to consider an exception.

Ok, we will address that.

  1. Replace the reference to RFC4601 with a reference to draft-ietf-pim-rfc4601bis.  Note that the section numbers have changed slightly!

Yes, we can update.
(you see me surprised to see that appear as a "major" issue!)

  1. Are you adopting the exponential decay algorithm from RFC2439?  That seems to be what's happening because you are not explicitly defining a new algorithm, but some of the text leave doubts.  For example:
    • "inspired from BGP unicast route damping"  I know the application is different, but if the algorithm is the same then please say it.

The procedures associated to the exponential decay are different.

    • Section 5.1. (PIM procedures)
      • "updating the *figure-of-merit* based on the decay algorithm must be done prior to this increment"  This statement seems to directly imply that the algorithm is used.  Please reorder the steps to explicitly call this one out, instead of plugging it in as an afterthought.  BTW, should the "must" be "MUST"?  Ordering should help you not having to deal with that last question.

I've revised the text to describe this step in its own bullet, prior to "updating the figure-of-merit", to avoid this "after thought" impression and make it as mandatory as the other steps.


      • "Same techniques as the ones described in [RFC2439] can be applied…"   "Can be"?  This sentence seems to imply that what is described in RFC2439 is optional.  Are there other ways of determining the same thing?  What about the exponential decay algorithm?

No, there are just multiple ways possible to update the figure-of-merit, including the ones RFC2439 mention or detail.

I've reformulated the text to avoid misinterpretation:

  These specifications do not impose the use of a particular technique
   to update the *figure-of-merit* following the exponential decay
   algorithm based on the configured *decay-half-life*. In particular
   the same techniques as the ones described in [RFC2439] can be
   applied.  The only requirement is that the *figure-of-merit* has to
   be updated prior to increasing it and that its decay below the
   *reuse-threshold* has to be timely reacted upon: in particular, if
   the recomputation is done periodically, the period should be low
   enough to not significantly delay the inactivation of damping on a
   multicast state beyond what the operator wanted to configure (i.e.
   for a *decay-half-life* of 10s, recomputing the *figure-of-merit*
   each minute would result in a multicast state to remained damped for
   a much longer time than what the parameters are supposed to command).



      • It would also help if the terminology was consistent.  For example, instead of "damping becomes active" use "suppressed".  I can see how "suppressed" may give the wrong impression as only the propagation of state is affected.  Explaining then how the terminology applies would make it easier to reuse, avoid confusion and be clear.  Note that there's no mention of RFC2439 in the terminology section.

Using the "suppressed" term to describe a state that we artifically keep active is the most confusing thing that I can think of. As you say this would give a wrong impression.  I would go as far as to say that the document would be barely understandable.

But maybe we can add this to the terminology section:
In these specifications, damping of a multicast state will be said to be "active" or "inactive". Note that the term used for a unicast route which is dampened is "suppressed", but we avoid this term is these specifications given that a dampened multicast state is kept active.
Would that help ?


  2. Section 3. (Overview): "…it is expected that this technique will allow to meet the goals of protecting the multicast routing infrastructure control plane without a significant average increase of bandwidth".  In general, I want to make sure that the qualities of the solution and the expected results are properly reflected in the document. [I'm using the text above as the base for my comment, but the impact is larger.]  Some questions:
    • "…it is expected that this technique will…"  I wonder why an assertion can't be made that this technique can (vs just expecting that it will) address specific problems.  Is it the case that experience is needed to make a stronger assertion?  Are the goals the same (or at least similar) in every network?  Are there implementations available?  If so, please consider an "Implementation Status" section (see rfc6982).  What has been the deployment experience?  This goes back to my comment above about the Intended Status of this document.

"It is expected" reflects the idea that the slight increase in bandwidth will not be significant in most cases.
We can expand the text a bit to explain what would be the cases where that would not work.

Let me suggest the following reformulation:

"That said, basic simulation of the exponential decay algorithm show that the multicast state churn can be drastically reduced without significantly increasing the duration for which multicast traffic is forwarded. Hence, using this technique will efficiently protect the multicast routing infrastructure control plane against the issues described here, without a significant average increase of bandwidth.  The exception will be a scenario where the network dimensioning does not allow to extend the time a multicast flow is forwarded beyond the duration for which is it needed by receivers".


    • What specifically are the goals?  In a couple of places the text points back at Section 1. (Introduction), but I'm not sure exactly what the goals are.  Of special interest for understanding the goals is the part in Section 4.2. (Existing PIM, IGMP and MLD timers) where other solutions are discarded for not meeting them.
      • There is scattered text that talks about "…ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control…", "protecting these control planes…avoiding negative effects…although at the expense of a minimal increase in average of bandwidth use…".   However, the description is too vague to point at what can satisfy these goals and what can't.


Section one 1 says:
- " Hence, mechanisms need to be put in place to ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control regardless of the frequency at which multicast memberships changes are made by end hosts."
-then  "This document describes procedures, remotely inspired from existing BGP route damping, aimed at protecting these control planes while at the same time avoiding negative effects on the service provided, although at the expense of a minimal increase in average of bandwidth use in the network."

The intent was that the text would be enough to make the goals clear.

Would the following change of the second sentence provide suitable detail to help understand what can satisfy these goals and what can't :   ...?

[...] aimed at offering means to set an upper bound to the affected control planes (BGP RFC6514 processing, and the P-tunnel control plane protocol in certain cases as well) while at the same time preserving service provided (delivering the stream to the end user as requested), although at the expense of a minimal increase in average of bandwidth use in the network.

I see that we can reorder the text to avoid splitting the explanation of goals.

The new text would look like the following:

   In VPN contexts, providing isolation between customers of a shared
   infrastructure is a core requirement resulting in stringent
   expectations with regards to risks of denial of service attacks.

   By nature multicast memberships change based on the behavior of
   multicast applications running on end hosts, hence the frequency of
   membership changes can legitimately be much higher than the typical
   churn of unicast routing states.  Section 16 of [RFC6514]
   specifically spells out the need for damping the activity of
   C-multicast and Leaf Auto-discovery routes.

   Hence, mechanisms need to be put in place to ensure that the load put
   on the BGP control plane, and on the P-tunnel setup control plane,
   remains under control regardless of the frequency at which multicast
   memberships changes are made by end hosts.

   This document describes procedures, remotely inspired from existing
   BGP route damping, aimed at offering means to set an upper bound to
   the amount of processing for the mVPN control planes protocols
   ([RFC6514], and the P-tunnel control plane protocol in certain cases
   as well), while at the same time preserving service provided
   (delivering the stream to the end user as requested), although at the
   expense of a minimal increase in average of bandwidth use in the
   network.



    • Section 4.1. (Rate-limiting of multicast control traffic) mentions the "risk described in Section 1", which does mention "risks of denial of service attacks".  Is that the risk you're referring to, or something else?  

Yes. I've made that explicit in section 4.1.

    • Section 4.3. (BGP Route Damping) mentions "the principle described in this document", which I thought was related to the goals, but Section 1 says that  the "base principle is described in Section 3".  I'm assuming the "principle" in question is such that a "network operator…can delay the propagation of multicast state prune messages between PEs, when faced with a rate of multicast state dynamicity exceeding a certain configurable threshold".  That sounds like a potential goal to me.

The base principe described in section 3 is a way to achieve the goal, rather than a goal in itself.


  2. Section 5.2. (Procedures for multicast VPN state damping)  
    • In the Introduction you write that "Section 16 of [RFC6514] specifically spells out the need for damping the activity…"  I think that RFC6514 does a lot more than that:  Section 16.1. (Dampening C-Multicast Routes) "proposes OPTIONAL route dampening procedures similar to what is described in [RFC2439]."   Those procedures look very similar to the ones in this document.  What is the difference?  Is the intent of this document to complement, replace or maybe update what is already specified in RFC6514?

Indeed, the base ideas for dampening were already here when we wrote RFC6514.
draft-ietf-bess-multicast-damping provides precision on how to implement RFC6514 16.1.1, but this is not an update per se as nothing in RFC6514 is changed.

We can make that fully explicit by saying in Section 1:

   Section 16 of [RFC6514] specifically spells out the need for damping
   the activity of C-multicast and Leaf Auto-discovery routes, and
   outlines how to do it by "delay the advertisement of withdrawals of
   C-multicast routes".  These specifications provides appropriate
   detail on how to implement that and how to make that controllable
   by the operator.



    • There's an rfc2119 conflict.   "…then the withdrawal of a C-multicast route…SHOULD NOT be damped.  An implementation of the specification in this document MUST whether, not damp these withdrawals by default, or alternatively provide a tuning knob to disable the damping of these withdrawals."  s/whether/either   The "MUST..not damp" and "SHOULD NOT be damped" are in conflict.    I think that eliminating the last sentence would fix the problem and still allow an implementation to put in any knobs that it wants.

(Ok for s/whether/either)

These two sentences were discussed already quite a lot, and I think we need to keep this.

There is in fact not a conflict: what needs to be enforced in a deployment is that "[under some conditions]  ... SHOULD NOT damp some specific withdrawals", to ensure that in implementations that this will doable we add "MUST ([not damp these withdrawals by default] or [provide a tuning knob to not damp these withdrawals])".

Removing the second sentence would mean something not strong enough: on implementations that damp withdrawals by default (they can do that, because this is acceptable in some deployments), we absolutely need the knob (to address the more problematic deployment scenario).



  2. Section 7.3. (Default and maximum values) lists values that are "RECOMMENDED to adopt as default conservative values".  Any guid
    1. ance about when and/or how an operator should consider changing the recommended defaults?  What does "conservative" mean in this context?  What if the operator wants to be more aggressive?

We can certainly improve this section a little bit.

I propose to add:

   This section proposes default and maximum values, conservative so as
   to not significantly impact network dimentioning but still prevent
   post-dampening multicast state churn to go beyond what can be
   considered a reasonably low churn for a multicast state.

   The following values are RECOMMENDED to adopt as default values:

And, as illustrations:

   With these values, as an illustrations:

   o  a multicast state not updated more frequently than one every 6s
      will not be dampened

   o  a multicast state changing once per second for 3s, and then not
      changing, will not be dampened

   o  a multicast state changing once per second for 4s, and then not
      changing, will be dampened after the fourth change for
      approximately 13s

   o  a multicast state changing twice per second for 30s, and then not
      changing, will be dampened after the fourth change for
      approximately 13s





  1. Minor:
  1. In 4.2
    • s/prune override interval/J/P_Override_Interval

I'd rather keep the plain text version.

    • Reference for explicit tracking..??  BTW, how would the mechanism in this document interact with explicit tracking?

Will add a reference.

  1. Section 5.1. (PIM procedures): 
    • "…a router implementing these procedures MUST…apply unchanged procedures for everything…".  I guess that these "unchanged procedures" are the ones in rfc4601bis, right?  In other words, what you seem to want is that, in addition to what rfc4601bis specifies, for the other steps defined in this document to happen.  If that is correct, please reword the description to make it clear — at least put a reference so that there is no question about which procedures are left unchanged.

Ok.

    • "…freeze the upstream state machine…and setup a trigger to update it…"  Maybe a word like "hold" or "maintain" might be better.  In fact, even better would be an explicit indication that "events that may result in the state changing [rfc4601bis] SHOULD be ignored until the reuse threshold is reached", or something along those lines. 

I'll adopt your suggested text, with the precision that only changes in the upstream state machinie will be ignored.

    • What should the state be updated to when the reuse threshold is reached?

I've added this detail.

hold the upstream state machine in Joined state so that events that may result in the upstream state changing based on RFC4601bis SHOULD be ignored until the reuse threshold is reached, and setup a trigger to update the upstream state machine based on downstream state machines once the reuse threshold is reached. The effect is that in the meantime, PIM Join messages will be sent as refreshes to the upstream neighbor, but no PIM Prune message will be sent.


    • I had some trouble parsing this text: "When the recompilation is done periodically, the period should be low enough to not significantly delay the inactivation of damping on a multicast state beyond what the operator wanted to configure (i.e. for a *decay-half-life* of 10s, recomputing the *figure-of-merit* each minute would result in a multicast state to remained damped for a much longer time than what the parameters are supposed to command)."    I think I got it…but what I don't get (based on my understanding of RFC2439) is that the figure-of-merit should decay according to the half-life, so I don't get why its value would be adjusted at a period that is not related to the half-life.

You have many ways to simulate a behavior triggered by a decaying value crossing a threshold:
- periodically recompute the value and see whether it crossed the threshold: naive/easy approach, the period does not need to be related to the decay-half-life as long as it is short enough
- compute the time at which it will reach the threshold and setup a timer to fire at that time
- more optimized to group computation for multiple routes/states, see RFC2439


  2. Section 5.2. (Procedures for multicast VPN state damping) 
    • There are several places in this section where rfc2119 language is used to describe what an implementation should do that sound to me as an attempt to define functionality that is mandatory to implement (MTI).  I find that hard/impossible to enforce and would like to see the rfc2119 language removed.  Please see below..

Yes, the MUSTs in this 5.1 and 5.2 intent to carry the meaning of "mandatory to implement".

    • The text says that an "implementation of [RFC6513] relying on the use of PIM to carry C-multicast routing information MUST support this technique."  That "MUST" is really strong and it makes me think that this document should then be marked as an update to RFC6513.  Is that the intent?  Reading through it again, is the intent MTI?

No, the intent is not to update RFC6513.
I've added the precision: "MUST support this technique, to be compliant with these specifications."


    • "…the following procedure is proposed as an alternative to the procedures in Section 5.1…"  "proposed"??  Does this mean that 5.1 is also applicable in this case (when "BGP is used to distribute C-multicast routing information")? 

Yes.

    • It sounds like the operator would have an option — if so, when should each be considered?
      • Later in the same section you wrote: "…choice to implement damping based on BGP routes or the procedures described in Section 5, is up to the implementor, but at least one of the two MUST be implemented."  I think it should be section 5.1.

Yes indeed. I will correct.

      •  Do you really mean the "implementor", or are you referring to the operator of the network?  The "MUST" sounds too strong for me because it is not needed for interoperability (rfc2119) -- or is this an attempt at MTI?

This is an indication for implementors, so MTI.


      • Same question/observation for "In the perspective of allowing damping to be done on RRs and ASBRs, implementing the BGP approach is RECOMMENDED."  Maybe s/RECOMMENDED/recommended

I understand that you seem to prefer avoiding RFC2119 language for MTI things.
But I don't know another way than RFC2119 language to indicate what is mandatory to implement to be compliant with a spec, and I think this is a fairly well established practice. This is not the first document to use RFC2119 to indicate MTI things.

What is the rationale for not using RFC2119 language ?



    • "…it can be considered useful to also be able to apply damping on RRs as well."  When is it considered useful?
      • Note that later you also write: "…in such a context, it is RECOMMENDED to not enable any multicast VPN route damping on RRs…"   This partially answers the question.  It would be nice to put the guidance together.

I've added text to improve that.



    • "…damping SHOULD NOT be applied to BGP routes of the following sub-types…"  Are there cases when it is ok?  In other words, why is the "SHOULD NOT" not a "MUST NOT"?

Maybe someone can find a case where this does not break things, under some conditions.
We saw nothing mandating the use of "MUST NOT".


  2. Section 6.1. (Damping mVPN P-tunnel change events) "Possible ways to do so depend on the type of P-tunnel, and local implementation details are left up to the implementor.     The following is proposed as example of how the above can be achieved."  Either you leave it as an implementation detail or you provide guidance.  If this document was Experimental, then providing guidance it great!

There is a gap between "example" and "guidance".
I think an example can help the reader (implementor or deployer).
Guidance would mean that we start influencing the implementor, which is not the idea here.




Nits:
  1. Please put references on first appearance.  For example, IGMP and MLD are mentioned in the introduction, but no reference is made until the 5th mention.  The same for BGP route damping…

Ok.


    • You also need a reference to route reflectors.

Added.


  2. "these control planes"  Which control planes?  Please be specific.   There are other places where "these" is uses that may not be completely clear..please take a look.

Reworded as part of other changes following your comments.

  1. s/these specifications/this specification

ok

  1. s/when enabled /when enabled,

ok
  1. "PIM-SM specifications [RFC4609]"   RFC4609 is not the PIM spec.

Yes, typo.
Thanks.

  1. Section 6.2. (Procedures for Ethernet VPNs)  "…an implementation of these procedures MUST follow the procedures described in Section 6.1."  It is not completely clear which "these procedures" are.  I'm guessing RFC7117.

Yes, fixed.


--------------040507000107040807090200-- From nobody Wed Feb 24 22:35:18 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEB81A8025; Wed, 24 Feb 2016 15:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 mUviJVae1tPT; Wed, 24 Feb 2016 15:14:46 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0481A7113; Wed, 24 Feb 2016 15:14:46 -0800 (PST) Received: from mb-2.local ([172.56.39.39]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1ONEVrb096382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Feb 2016 23:14:31 GMT (envelope-from joelja@bogus.com) To: Eric C Rosen , Benoit Claise , Susan Hares , "'The IESG'" References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> <567859EC.6030103@juniper.net> <006101d13ce1$725cd650$571682f0$@ndzh.com> <56799F9F.4010907@juniper.net> <000d01d13d94$80868a10$81939e30$@ndzh.com> <56966A3D.4000708@juniper.net> <56A88FE9.7000505@cisco.com> <56A90DEF.2000701@juniper.net> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 24 Feb 2016 15:14:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <56A90DEF.2000701@juniper.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GiE6C5x5AcwtnVdKJe4VwTfHCe8Um9qSj" Archived-At: X-Mailman-Approved-At: Wed, 24 Feb 2016 22:35:17 -0800 Cc: draft-ietf-bess-mvpn-extranet@ietf.org, "'John G. Scudder'" , aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 23:14:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GiE6C5x5AcwtnVdKJe4VwTfHCe8Um9qSj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I've reviewed this again in light of our discussion during the IESG review. From my vantage point discussion on this document is intended to address corner cases, as is the document itself since inter-vpn exchange of multicast traffic is itself (in particular for asm) a corner-case, I'm not sure I suscribe to the rairty of asm vs ssm but for the appication described, ok . n 1/27/16 10:35 AM, Eric C Rosen wrote: > On 1/27/2016 4:37 AM, Benoit Claise wrote: >> >> This document doesn't give an operator =E2=80=9Cso-what=E2=80=9D for d= eployment in 60 >> pages. > I'm afraid I don't understand this sentence. >=20 >> You know, a few summary paragraphs that indicates where this >> specification is useful and where it is not for operators, and the >> potential fragility of the solution (which could be in a new >> operational consideration section or in the security considerations. > As I've been trying to explain to Sue, I don't understand what is being= > asked for in these "few summary paragraphs". An "operator's guide to > provisioning extranets" would be useful, but not within the scope of > this draft. I'm having a little trouble parsing where you disagree. Providing operational advice isn't in scope? Section 1.3 goes into detail to the point where it is hard to parse the application of route distinguishers.= > The security considerations section already points out that > misconfiguration of the Route Targets may result in misdelivery of > traffic; the above text is merely a paraphrase of material that is > already present in the document. >=20 > Note that there is no requirement to have a separate "operational > considerations" section. nor would that I think be necessary to address the concern. >> I don't think I've seen text around coordination to set up filter, for= >> example. > Coordination to set up filters? I don't know what you are referring to= =2E extranets are by the nature set up by too independant entities. one presumes both mutual cooridnation, and design efforts required to avoid collisions. the concerns in 2.3.2 Section 3 of this document describes a procedure known as "extranet separation". When extranet separation is used, the ambiguity of Section 2.1 is prevented. However, the ambiguity of Section 2.2 is not prevented by extranet separation. Therefore, the use of extranet separation is not a sufficient condition for avoiding the procedures referenced in Section 2.3.1. Extranet separation is, however, implied by the policies discussed in this section (Section 2.3.2). so being prescriptive with respect to how these may be operated seems like it would be helpful. >> >> Sue has been trying to be helpful and even proposed some text: >> >> Whenever a VPN is provisioned, there is a risk that provisioning >> errors will result in an unintended cross-connection of VPNs, >> which would create a security problem for the customers. Extranet= >> can be particularly tricky, as it intentionally cross-connects >> VPNs, but in a manner that is intended to be strictly limited by >> policy. If one is connecting two VPNs that have overlapping >> address spaces, one has to be sure that the inter-VPN traffic >> isn't to/from the part of the address space that is in the >> overlap. The draft discusses a lot of the corner cases, and a lot= >> of the scenarios in which things can go wrong.=20 >> >=20 > Actually, I wrote that text in an email to Sue. Although it too is jus= t > a paraphrase of existing materiaI, I could add it to the "overview" > section as part of the description of what an extranet is. Are you > saying that you will lift the DISCUSS if I just add that paragraph?=20 >=20 >=20 >=20 --GiE6C5x5AcwtnVdKJe4VwTfHCe8Um9qSj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbOOVEACgkQ8AA1q7Z/VrKcaQCfXc9R8oeDJJpRKA3M7wX26TsO jDoAn0572Ry5fV2iEirOVvA8Qbi7hZEL =ZWQl -----END PGP SIGNATURE----- --GiE6C5x5AcwtnVdKJe4VwTfHCe8Um9qSj-- From nobody Thu Feb 25 14:24:38 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B89B1B3599; Thu, 25 Feb 2016 13:25:53 -0800 (PST) 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, 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 ytUiPuZj6dsL; Thu, 25 Feb 2016 13:25:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBD91B3593; Thu, 25 Feb 2016 13:25:46 -0800 (PST) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.34.211] (66.129.241.11) by DM2PR05MB800.namprd05.prod.outlook.com (10.141.180.26) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 25 Feb 2016 21:25:23 +0000 To: joel jaeggli , Benoit Claise , "Susan Hares" , 'The IESG' References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> <567859EC.6030103@juniper.net> <006101d13ce1$725cd650$571682f0$@ndzh.com> <56799F9F.4010907@juniper.net> <000d01d13d94$80868a10$81939e30$@ndzh.com> <56966A3D.4000708@juniper.net> <56A88FE9.7000505@cisco.com> <56A90DEF.2000701@juniper.net> From: Eric C Rosen Message-ID: <56CF713C.8010105@juniper.net> Date: Thu, 25 Feb 2016 16:25:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BY2PR13CA0040.namprd13.prod.outlook.com (25.162.223.50) To DM2PR05MB800.namprd05.prod.outlook.com (10.141.180.26) X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB800; 2:22c3zF3ji0zSVOU1kaedL9aiEeVKTHgw2J7x8gxaZDL+1ZYL7h296oJ+OdS5xZjAdVT9D9pKC7JMsNDGe9rtwuUaYtVBs28bzaLmlJ0WFWJHm4o1YGMDOJEkjb78YoG0ooYa6B5RtRmyh7b8VHgZvA==; 3:08ppNC2B6KOsNKBzvrG+S35TjkWBqvtttRyr6kFbRJZmu8bj2A9mXj+pC30GcesczgmJqrgrdBGoRHcPF5HYqpsV4BokD5tKrLzoByJtaErzugZNsGPUjK6QhN9g4SMG; 25:1714O002VRHUnPHxlOy97rekqLyCS/jMlACpk8tCxHK+HrEIk77pNr8kIZ/jA1osQ0+D/YHvaTh2W0BeiT2SOjvJQbKK2h2edJHHSXUOwBTIEfcBG6STsA6C7qZdTF21VvpB5ECYTFu6J9QAHOVfCHonyaFeTuujlErrOxaIJnUbob6LEiz1bpEC/+8ByskjxOpD/0IZeTeAoC1LWOmSz5fUEA/Ep1EASn1Y+Zo6Ag8kLV5DeLl8gLZFfLGoW62lg3CAI2bAcDZFhOnZkQxMi5Xx2IMoYXoPcv7uhwFPTFC0j5ingkPjYaBn84g8jZdLd3bZxXBXL+QsiXkg3jMkow== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB800; X-MS-Office365-Filtering-Correlation-Id: eb5b5591-133f-4678-7548-08d33e2a2cd6 X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB800; 20:VokUcBomo33RvTSbJR7TAhxuFU5w/0y+wB7152f7EoO2gUCIXh4FTSSbTHZ9J6K3WzonvqZU7xfVdq8349noy2liSWzhzYGOJhS8Iu2XkvI3sdq1onBXr/3Yi4hna7zCz2eYpIeXWfzuxSC4iFSdC6dVYkj5zObxRCJDQRbM1ejMe5O/phzM4Ph54s02ReCBqzp+Ex+6UwwdefaEOZJnylm9CTZSljWdboRM6VqNYZd/9zJvpXRUNFBgK47atSV57YgGqI4bbjpDB3czmcaDg9XwBy0bSTO/+e6Xu76tEsCmAjqnHRgDVhDumJybd43A+3dITaYobgatLtFss9tJE9hcigillMIK7yFVDZmt66yxeBJNodR/tu/lzWgIctzha/9pgiJg4SOr2polMV39mvTpKvFMwmezWi26L2k1aiI65Jw3zooGLEmOtEBWXrTe2GYN1A2QbrqrtqhGZE4jIV+WyjFUjWfF4HgLvZyi5cTyjZJNWccGp+h9OFeU2wEa; 4:y1LNdXXV+tFibbmV0CisJr6rxaVjgNSqI+vTJykjg5ieagCgFTmHuNQ97Q47dmtEe2MfM39jaraKVolHaducuyIdVt8uWuYV+dgKKZktNgmkZjBPGBsdOSFizywxgtdWQIfvkbE1+eLvomql/7O9jIqsA4m2PW/03D9F34GT07KDDc2m6KsjYmRys4PWScXwwxNpXtvcm4dTiggbWxn324QDBlL0hcqFlzMDsHP9ggxVnjXXs3yYQkk+knfyqT9ibNXQzq82esFu48HjtFk+TaZAtKyGHdTUtC9Bpydtj1d6ENAhBwcis43gODAAaIY4z7jcOYuBpzOfv2iBl7q7SdzGEDUOAsgGnbIo/ATlMf4MXQjUmBAMcKOYJSYMnu2c X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DM2PR05MB800; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB800; X-Forefront-PRVS: 08635C03D4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(479174004)(24454002)(76176999)(54356999)(50986999)(33656002)(77096005)(5001770100001)(5008740100001)(64126003)(87266999)(6116002)(586003)(93886004)(23676002)(2906002)(3846002)(80316001)(66066001)(50466002)(83506001)(189998001)(4326007)(92566002)(5001960100002)(86362001)(230700001)(122386002)(230783001)(47776003)(65806001)(87976001)(40100003)(65816999)(5890100001)(4001350100001)(2950100001)(42186005)(5004730100002)(36756003)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB800; H:[172.29.34.211]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjA1TUI4MDA7MjM6Z2IyS2VzcDBZV0pyd0p3OUk1ZjYrQWh1UDJz?= =?utf-8?B?d1dMaFNPOGFpaEFESGNNcGZ2RkJnU2V2M3VIcGpneUNuVXdFSHBzTWlld0Iv?= =?utf-8?B?WEZjV2RYWlRMbGJPK25tWkM1K2dGbUVGVnpzdnZWV2pQRThBeGpzdHJoUGRR?= =?utf-8?B?MlkwRUNZbkx1RWFoRnpOVVBaa2IwVDU4Nm5FODdTUEpOaEFpem45Z0JNdGZs?= =?utf-8?B?c04wNTk3cHhXRDZRYndGaUZKRlVyRU81d0hRTVp0MUpYUStDZ2grcWh1TGQz?= =?utf-8?B?L1psSGs4YUJ5RGw1azJESk5KNnlMR0dlK1lYc1NsQzJYbzd3TVQxN0pJb3R0?= =?utf-8?B?YnhKdzhWd0dEampMeXVtenIzTVVBclBrb2IvelE3SjZEdnQvQlFFNEtNK1FF?= =?utf-8?B?c2E2SUVJTXNlNWNvUjZ0YVdDRGpsOFNnSFNtTk54ekc4Q2xXa3V1UWNyb0Qw?= =?utf-8?B?MS93MUJNQUlzai9SNEk1SzdjU0hXcEJzMTRpcGFmcFR6K05DRHBTcE1FbWg0?= =?utf-8?B?Z1MzNnoxVVl0cnQ4U2NjRVg0eFdjamFVbEVpZGU2cFNoM3doVjVoL3pGRy9U?= =?utf-8?B?SHNScGdaQTZPN3o2b2YyczRzemJUa2VHbG56TFFZL3FIMUg0dGJLRE1IVmg2?= =?utf-8?B?NE1paFF4cjg1NG9SbWFLc1NjS20xb29Dejh5RHJGWGltY1h2NnFveCt4MkVU?= =?utf-8?B?UmkzQkFkOGRTRkJuYXF5Vm5GcjZDSlB2QjAvUkxTeDRiYlJJbUdjRENxVnNJ?= =?utf-8?B?d3B6ZkhybERRUEFvZ24xZlJlQzJGNi9tN2xXWm5zR0I0QzZ4TkVKR2ZrMGlW?= =?utf-8?B?UG55Rk5RUlRzdDhwWmQ1NEhPV1UzWWxCdmQzR1YybFhRU1E4cUREQmtudWZU?= =?utf-8?B?SVdJRHZna0hYWGFOa2ZkK1NRYU4rQkV4c2paUnBWc1p4bE1Od1N6ZmJ4M0ZV?= =?utf-8?B?dHVmcVplYnQ2anZDUjVXQXdYS1hBU3duNmZsNCtnbHBQa25TYWJlNUVVbkVX?= =?utf-8?B?QjJKMWRtM1ZNUkU3Rmd6bEhWYzRxdHZGdU9kNUFVS00vRWRIcU9BNlBIVmRN?= =?utf-8?B?azVldTFXdDZLODRXTDdHdnBKOFdmelBWcElmbUxZUittcExidmRFRHhiVmtC?= =?utf-8?B?cmxvUmdWdXZNRGJqbjBaWVpuOWhWYjBobHdNQkJURmowTmlyUUUwUk1qNmJF?= =?utf-8?B?QWcxNERNWGFsU0txRG1Ib0VJL3o3bXQvZUNMb0k1UnZTeklDSi9mNHBPQlFh?= =?utf-8?B?UVRhMGJDdzcvWGJIVS90QnlxblFTblhiMTBDVUlPRGp5dFdrOEM3bGZNZzk4?= =?utf-8?B?UThybTN0MGZSaVE4dXcwazlkSXFaNmZLL21CVFBtMnRMNjdFZ1ZTSEFZZW4z?= =?utf-8?B?VElJMTdWMW15WFVGdWpjVTVjK2VpUVZuZzVMc1UvTUJaTldvcEV0b3VKT2pO?= =?utf-8?B?NGVMeXdXQi9FYUlLREIzUXI4NTRlMm9WajFrNlpvK1IvNjFVdlduMHJ5Y0NR?= =?utf-8?B?ek00TmY5bGZSbzgxOTNwd3lKTmR0eW5acE1MTDIyM1pva3k0Ukw1TmQrV1NF?= =?utf-8?Q?LuxvTNi6mHyodtsKB16LfB99cxPDVNFNxN00Gu7sTjk=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB800; 5:VMc3ioiC9CCpxpzv8M8wuZimUNje8S/b4zxS/6VrubVKM5o4vAS/+43IVrLgxXXFAbAjNBBpYQfbBbFBqc8HWBZd98pHt/GpIYv6HstrrkxaCh9jPhVjw94ak/5t0qoJJlwzSVZ2rkcGMyAyf4RgJA==; 24:iNsC4ICmm4PB+9vBqioqqO7tuVH8yLhgmTlvVKVCEcIFnDuzyaw8RTMfJjLgZR4osDKOMq1oYfwmhzOsdHNnbcAd635zGCx6GFgUjlOtXUE= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2016 21:25:23.0703 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB800 Archived-At: X-Mailman-Approved-At: Thu, 25 Feb 2016 14:24:31 -0800 Cc: draft-ietf-bess-mvpn-extranet@ietf.org, "'John G. Scudder'" , aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 21:25:53 -0000 On 2/24/2016 6:14 PM, joel jaeggli wrote: > Providing > operational advice isn't in scope? Section 1.3 goes into detail to the > point where it is hard to parse the application of route distinguishers. Anyone who understands the normative references will know what a Route Distinguisher is and what a VRF is. The fundamental part of provisioning any RFC4364 VPN is to create the VRFs, and to provision each VRF with Route Distinguishers. Section 1.3 states that, for the purposes of MVPN, two VRFs MUST NOT be configured with the same RD. It further states that if the "extranet separation" feature is not required, every VRF MUST be configured with a single RD. If the feature is required, every VRF MUST be configured with two RDs, one called the "default RD" and one called the "extranet RD". In other words, that entire section specifies requirements that must be met by whatever process is used to provision the MVPN extranet. It also specifies reasons why these requirements are in place by mentioning some of the situations in which the protocols presuppose that these provisioning requirements are met. I don't see what's missing. I find it puzzling that a section whose whole purpose is to clarify the provisioning requirements (and the dependencies of the protocols on those requirements) would be held up as an example of how there are no operational considerations. It's true that the section is more focused on providing a precise description of the provisioning requirements than on providing a tutorial or guide or "advice". But the former is within the scope of the document and the latter is not. After all, the purpose of this document is to specify the protocols and procedures that need to be implemented. The purpose is not to define a service model or provisioning system. > extranets are by the nature set up by two independent entities. one > presumes both mutual cooridnation, and design efforts required to avoid > collisions. Extranet involves two VPNs, but the provisioning of the extranet is generally done by the single service provider that is providing both of those VPNs. Thus the provisioning of an extranet generally does not require coordination between two independent entities. It is possible that two independent providers will coordinate to provide an extranet, but it is also possible that two independent providers will coordinate to provide a single VPN, if that single VPN has sites attached to both providers. For this reason, RFC4364 defines the Route Targets in such a way as to enable service providers to allocate globally unique Route Targets. The need for uniqueness of the Route Targets is not specific to extranet or to multicast, and is covered in the normative references. > the concerns in 2.3.2 > > Section 3 of this document describes a procedure known as "extranet > separation". When extranet separation is used, the ambiguity of > Section 2.1 is prevented. However, the ambiguity of Section 2.2 is > not prevented by extranet separation. Therefore, the use of extranet > separation is not a sufficient condition for avoiding the procedures > referenced in Section 2.3.1. Extranet separation is, however, > implied by the policies discussed in this section (Section 2.3.2). > > so being prescriptive with respect to how these may be operated seems > like it would be helpful. The draft goes into excruciating detail about how to avoid address ambiguity when moving data between two VPNs that have overlapping address spaces. It specifies a protocol-based mechanism ("discard from the wrong tunnel") allows you to determine which of two streams is the one you want, even if both streams use the same IP addresses. It also specifies policies, for assigning multicast flows to tunnels, that can be used to avoid address ambiguity. Again, I don't see what is lacking. > Note that there is no requirement to have a separate "operational > considerations" section. > nor would that I think be necessary to address the concern. > Perhaps someone could explain to me exactly what is necessary to address the concern. From nobody Sun Feb 28 08:37:10 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7F01A6F30; Sun, 28 Feb 2016 08:37:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160228163705.24380.24145.idtracker@ietfa.amsl.com> Date: Sun, 28 Feb 2016 08:37:05 -0800 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Joel Jaeggli's Discuss on draft-ietf-bess-mvpn-extranet-06: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 16:37:05 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-bess-mvpn-extranet-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- After further discussion related to the ops dir review, I'm going to have to echo Benoit and the Opsdir reviewers concern. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sue Hares performed the opsdir review. benoit holds the discuss for the points she raised. Status: Not ready, three major concerns and two editorial nits: Major concerns: 1) Specification of the Extranet Source Extended Community and Extra Source extended Community Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2, and 3.3. 2) Why is there no Deployment considerations section? The whole draft is a set of rules for handling policy, BGP A-D routes, tunnel set-up, and PIM Join/leaves in the case of an intra net. Unless these rules are followed exactly, traffic may flow into a VPN it is not suppose to. If the customer and the SP must coordinate on setting up filters, the procedure is outside the document. An error in any of these set-ups is considered a “security violation”. Milo Medin stated “with enough trust” a rock can fly to the moon. However, the NASA flights were fragile and risky. In the journey to the moon, there was no other choice. Instrumentation has 4-5 backups. In this set-up, one has to ask “is there another choice” to this whole design that seem fragile addition of extranets to an intra-AS multicast design. If the design is not fragile, then there should be a deployment section indicating how to manage the RTs, RDs, and policy set-up. Perhaps experience with the Intra-As has shown deployment tips that would make this less fragile. If so, it would be good to include an operations consideration section. If a new class of tools provides monitoring or provisioning, mentioning these would be useful. If yang modules are being developed, that would be useful. Places that indicate issues with violated constraint: p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25 last paragraph (violation of constraints will cause things to not work. However, only policy can control), p. 27 4.2.2 (1st paragraph, Route Reflector must not change), p. 31 (5.1, first paragraph), 3) Is security section really a security section? It seems more like “do this policy” or this will fail. It should get a stronger review from the security directorate From nobody Sun Feb 28 10:57:22 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BB11A6F30; Sun, 28 Feb 2016 08:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 V1tkHi8s4YUo; Sun, 28 Feb 2016 08:37:03 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E571A6F2E; Sun, 28 Feb 2016 08:37:03 -0800 (PST) Received: from mb-2.local (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u1SGaeSh024819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 28 Feb 2016 16:36:41 GMT (envelope-from joelja@bogus.com) To: Eric C Rosen , Benoit Claise , Susan Hares , "'The IESG'" References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> <567859EC.6030103@juniper.net> <006101d13ce1$725cd650$571682f0$@ndzh.com> <56799F9F.4010907@juniper.net> <000d01d13d94$80868a10$81939e30$@ndzh.com> <56966A3D.4000708@juniper.net> <56A88FE9.7000505@cisco.com> <56A90DEF.2000701@juniper.net> <56CF713C.8010105@juniper.net> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: Date: Sun, 28 Feb 2016 08:36:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <56CF713C.8010105@juniper.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="So9kjJ6rJNK14Ls8jQP08Fkmwl77m14Df" Archived-At: X-Mailman-Approved-At: Sun, 28 Feb 2016 10:57:18 -0800 Cc: draft-ietf-bess-mvpn-extranet@ietf.org, aretana@cisco.com, "'John G. Scudder'" , bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 16:37:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --So9kjJ6rJNK14Ls8jQP08Fkmwl77m14Df Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/25/16 1:25 PM, Eric C Rosen wrote: > On 2/24/2016 6:14 PM, joel jaeggli wrote: >> Providing >> operational advice isn't in scope? Section 1.3 goes into detail to the= >> point where it is hard to parse the application of route distinguishe= rs. > Anyone who understands the normative references will know what a Route > Distinguisher is and what a VRF is. The fundamental part of > provisioning any RFC4364 VPN is to create the VRFs, and to provision > each VRF with Route Distinguishers. Yeah, I'm not convinced of that, there is eleborate discussion of the requirement for one RD per VRF and then extranet seperation adds a twist that. However, when Extranet Separation is used, some of the local-RD routes exported from the VRF will contain the extranet RD. Details concerning the exported routes that contain the extranet RD can be found in Sections 4.1 and 7.3. > Section 1.3 states that, for the purposes of MVPN, two VRFs MUST NOT be= > configured with the same RD. >=20 > It further states that if the "extranet separation" feature is not > required, every VRF MUST be configured with a single RD. If the featur= e > is required, every VRF MUST be configured with two RDs, one called the > "default RD" and one called the "extranet RD". >=20 > In other words, that entire section specifies requirements that must be= > met by whatever process is used to provision the MVPN extranet. It also= > specifies reasons why these requirements are in place by mentioning som= e > of the situations in which the protocols presuppose that these > provisioning requirements are met. >=20 > I don't see what's missing. I find it puzzling that a section whose > whole purpose is to clarify the provisioning requirements (and the > dependencies of the protocols on those requirements) would be held up a= s > an example of how there are no operational considerations. > > It's true that the section is more focused on providing a precise > description of the provisioning requirements than on providing a > tutorial or guide or "advice". But the former is within the scope of > the document and the latter is not. After all, the purpose of this > document is to specify the protocols and procedures that need to be > implemented. The purpose is not to define a service model or > provisioning system. >=20 >> extranets are by the nature set up by two independent entities. one >> presumes both mutual cooridnation, and design efforts required to avoi= d >> collisions. > Extranet involves two VPNs, but the provisioning of the extranet is > generally done by the single service provider that is providing both of= > those VPNs. Thus the provisioning of an extranet generally does not > require coordination between two independent entities. >=20 > It is possible that two independent providers will coordinate to provid= e > an extranet, but it is also possible that two independent providers wil= l > coordinate to provide a single VPN, if that single VPN has sites > attached to both providers. >=20 > For this reason, RFC4364 defines the Route Targets in such a way as to > enable service providers to allocate globally unique Route Targets. =20 > The need for uniqueness of the Route Targets is not specific to extrane= t > or to multicast, and is covered in the normative references. >=20 >> the concerns in 2.3.2 >> >> Section 3 of this document describes a procedure known as "extrane= t >> separation". When extranet separation is used, the ambiguity of >> Section 2.1 is prevented. However, the ambiguity of Section 2.2 i= s >> not prevented by extranet separation. Therefore, the use of extra= net >> separation is not a sufficient condition for avoiding the procedur= es >> referenced in Section 2.3.1. Extranet separation is, however, >> implied by the policies discussed in this section (Section 2.3.2).= >> >> so being prescriptive with respect to how these may be operated seems >> like it would be helpful. > The draft goes into excruciating detail about how to avoid address > ambiguity when moving data between two VPNs that have overlapping > address spaces. It specifies a protocol-based mechanism ("discard from= > the wrong tunnel") allows you to determine which of two streams is the > one you want, even if both streams use the same IP addresses. It also > specifies policies, for assigning multicast flows to tunnels, that can > be used to avoid address ambiguity. >=20 > Again, I don't see what is lacking. >> Note that there is no requirement to have a separate "operational >> considerations" section. >> nor would that I think be necessary to address the concern. >> > Perhaps someone could explain to me exactly what is necessary to addres= s > the concern. >=20 >=20 >=20 --So9kjJ6rJNK14Ls8jQP08Fkmwl77m14Df Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlbTIhMACgkQ8AA1q7Z/VrIvbwCfSbwYPG1QMuMjHEEA3ZRRyMy9 ls0An0I7dMS7SA3M3Dci2iuUX/qfDKt7 =50DP -----END PGP SIGNATURE----- --So9kjJ6rJNK14Ls8jQP08Fkmwl77m14Df-- From nobody Sun Feb 28 18:56:43 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D071B2A99; Sun, 28 Feb 2016 18:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.607 X-Spam-Level: X-Spam-Status: No, score=-12.607 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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.006, 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 8qUIzoncydH4; Sun, 28 Feb 2016 18:56:35 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506EF1B2A7F; Sun, 28 Feb 2016 18:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30474; q=dns/txt; s=iport; t=1456714595; x=1457924195; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=I8vNS30nd/2Hx6oZLBE8B1ivEGKMaNhh/3Td3NrUKlk=; b=bz4W85kcRISc4qpiYO0Hd3EGAVxZh35VVFxz8WoingkDbrGMJ8Z9WRu+ SkKsODsoYiqdW/2Kr3xgZqSvBD5rv+mgCWKLbqVuycvf6ZBilmbzGJDut NYTZmYRL98vaXk6QGh+nI4L8Fia1tMUafcVyErAOgJo2CFk/jSWnHdGvH U=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAgCWstNW/4QNJK1egzpSbQa6Vg6BZ?= =?us-ascii?q?iOFcAKBJjgUAQEBAQEBAWQnhEEBAQEDARoJVgULAgEIGCAKAgIyJQIEDgUJBYg?= =?us-ascii?q?JCA6vW44rAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGEoFsgk6ED1OCUyuBDwWHU?= =?us-ascii?q?IslhBcBgwiBZGyCb4UagV6ERIhShXMWiEABHgFDggMZgUhqAQEBhwU9fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,518,1449532800"; d="asc'?scan'208,217";a="243570621" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 02:56:33 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1T2uXJM023432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Feb 2016 02:56:33 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 28 Feb 2016 20:56:32 -0600 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.009; Sun, 28 Feb 2016 20:56:33 -0600 From: "Carlos Pignataro (cpignata)" To: Eric C Rosen Thread-Topic: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt Thread-Index: AQHRQYNgm76iX7yesESh/1GkNtrtOp8oG2EAgAXw9YCAFQ7OAA== Date: Mon, 29 Feb 2016 02:56:32 +0000 Message-ID: <8A075A71-4B7F-4A8A-893D-596ED436E384@cisco.com> References: <20151221171512.15817.2209.idtracker@ietfa.amsl.com> <56815342.7030609@juniper.net> <56C2093D.7080800@juniper.net> In-Reply-To: <56C2093D.7080800@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.255.113] Content-Type: multipart/signed; boundary="Apple-Mail=_0B18B767-0822-4372-8C6B-45EDC44516EF"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "bess@ietf.org" Subject: Re: [bess] I-D Action: draft-ietf-idr-tunnel-encaps-01.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 02:56:40 -0000 --Apple-Mail=_0B18B767-0822-4372-8C6B-45EDC44516EF Content-Type: multipart/alternative; boundary="Apple-Mail=_2B05E73D-B176-45F5-B753-0C8C69FC1C2F" --Apple-Mail=_2B05E73D-B176-45F5-B753-0C8C69FC1C2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eric, Thanks for the response =E2=80=94 please find some follow-ups inline. > On Feb 15, 2016, at 12:22 PM, Eric C Rosen wrote: >=20 > On 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote: >> Hi, Eric, >>=20 >> Thanks for sending this out =E2=80=94 I am interested in this = document, and will give it a critical review (in particular the sections = you call out below). > Thanks! >>=20 >> In the mean time, however, I wanted to send a few high-level comments = (prepended with =E2=80=9CCMP=E2=80=9D) from scanning through it. I hope = these are useful. >>=20 >> 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types >>=20 >> This section defines Tunnel Encapsulation sub-TLVs for the = following >> tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE >> ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890], >> [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], >> [RFC4023]). >>=20 >>=20 >> CMP: More comments below, but I am a bit confused about the need to = include MPLS-in-GRE, and the lack of IP-in-IP (Tunnel Type 7) for = example. > MPLS-in-GRE is included in section 3.2 because there is already a = tunnel type codepoint allocated for it, and if that tunnel type is used, = an encapsulation sub-TLV is needed in order to signal the GRE key. >=20 > One can argue that there is no need for the MPLS-in-GRE tunnel type, = since everything you can do with it could be done instead with the GRE = tunnel type. But unless and until we decide to deprecate the = MPLS-in-GRE tunnel type, it needs to be included. In theory, I would = love to see the MPLS-in-GRE tunnel type deprecated, but I worry that = that might introduce a backwards compatibility problem. This is = certainly something that can be discussed by the WG. >=20 I agree =E2=80=94 and would welcome that discussion as well. > IP-in-IP is not mentioned in section 3.2 because, although there is a = tunnel type codepoint allocated for it, no one has ever defined an = encapsulation sub-TLV for it. Also, if it is necessary to signal values = for the fields of the outer iP header, it might make more sense to use = an "outer encapsulation sub-TLV" (section 3.3). Do you have an opinion = about this? You are right, Section 3.2 is indeed about the sub-TLVs. I believe I was = reacting to IP-in-IP not being mentioned anywhere (other than briefly in = the IANA section). Perhaps I was expecting something like this, although I agree with you = it=E2=80=99s a no-op: 3.2.x. IP-in-IP This document does not defines an encapsulation sub-TLV for IP-in-IP = tunnels. When the tunnel type is IP-in-IP, the encapsulation sub-TLV MUST NOT = be used. Now, IP-in-IP and other tunnels (like for example MPLS-over-UDP) present = an interesting question (that you raise above): In these, is the = encapsulation IP and UDP, or is this a null encapsulation with an outer = encapsulation of IP and UDP? To me, the pragmatic case is to use the Outer encapsulation sub-TLV for = IP fields in IP-in-IP, and for UDP fields in MPLS-over-UDP. However, if the Tunnel Type is IP-in-IP (7), then using an = Outer-encapsulation sub-TLV would imply IP-in-IP-in-IP. Is IP-in-IP a = null tunnel type with outer encapsulation and with protocol =3D 0x0800? = No. It is an IP-in-IP tunnel type. No protocol (since the tunnel encap = constraints it to IP), and no outer encap. It is not =E2=80=9Cfurther = encapsulated inside UDP and/or IP=E2=80=9D as the text in section 1.3 It would certainly help to explain this explicitly. It gets equally interesting with MPLS-over-UDP, because =E2=80=9CUDP=E2=80= =9D is not a tunnel type specified just yet, which could be used with = MPLS protocol type sub-TLV. Or a more limiting and duplicative = MPLS-in-UDP tunnel type. What tunnel type is used there? null encap? = protocol type sub-TLV? One additional comment =E2=80=94 I could not figure out the sorting = order for the encapsulations in subsections 3.2.x. I would consider = sorting by tunnel type value in ascending order, and starting each = sub-section with a =E2=80=9CThis encapsulation sub-TLV is used when the = Tunnel Type is XYZ (numerical value)" >>=20 >> CMP: A couple of editorial comments as well: For GRE, I think you = also need to cite RFC 7676 (GRE over IPv6) > Sure. Thank you. >>=20 >> CMP: Also, having this document Obsolete RFC 5512 effectively also = orphans a number of Tunnel types and sub-TLVs. For example, Tunnel Types = values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel = Authenticator sub-TLV. I do not know if the answer is to also have that = incorporated (useful parts as you say) and obsoleted. Maybe not, maybe = it does make sense given it is a short doc, which would lead to a = complete self-contained set of Tunnel types. > I think RFC 5566 will have to be obsoleted and replaced. I've been = thinking about that, but I'm still not sure how much of 5566 should be = moved into the tunnel-encaps draft and how much should be in a separate = draft. There are some non-obvious issues to consider. For example, = 5566 really is just intended to facilitate iPsec Security Associations = between BGP Next Hops, but with the tunnel encapsulation attribute we = could presumably set up Security Associations from ingress to egress. Indeed. Thank you =E2=80=94 the goal would be that 5566 does not get = completely out-of-sync. >>=20 >> 3.2.4. L2TPv3 I forgot to mention, the way in which the encapsulation sub-TLV is = defined, this specifies only encapsulation for L2TPv3 directly over IP. = This section, as well as all references to it, should be =E2=80=9CL2TPv3 = over IP=E2=80=9D (like the tunnel type is named now) = http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel= -types = L2TPv3 can run: * over IP: https://tools.ietf.org/html/rfc3931#section-4.1.1.1 = * over UDP: https://tools.ietf.org/html/rfc3931#section-4.1.2.1 = And L2TPv3 over UDP has a slightly different encap header, so using the = outer encap sub-TLV is not the way to define L2TPv3 over UDP. = Consequently, I=E2=80=99d explicitly say =E2=80=9CL2TPv3 over IP=E2=80=9D = everywhere. >> =E2=80=A6 >> Cookie: an optional, variable length (encoded in octets -- 0 to = 8 >> octets) value used by L2TPv3 to check the association of a >>=20 >> CMP: The cookie can only take sizes 0, 4, or 8 octets, and not 0..8 > Do you have a reference for that? Section 4.1 of RFC 3931 seems to = say only that the field is variable length with a maximum size of 64 = bits. Yes, RFC 3931, when defining the Assigned Cookie: = https://tools.ietf.org/html/rfc3931#page-50 = as well as the 4th = paragraph of S8.2 of RFC 3931. >>=20 >> 3.2.7. MPLS-in-GRE >>=20 >> CMP: This seems to be an example and not a separate encapsulation = type. This is GRE Type, with MPLS as protocol sub-TLV. I see that the = section says: >>=20 >> While it is not really necessary to have both the GRE and = MPLS-in-GRE >> tunnel types, both are included for reasons of backwards >> compatibility. >>=20 >> CMP: I will also note that having two different ways of doing the = same thing (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes = us away from interop., and that there does not seem to be MPLS-in-GRE = defined in any RFC (so it seems like potentially a good time to = rationalize instead of perpetuate). My $0.02 only. > Tunnel type 11 is used by draft-ietf-bess-evpn-overlay. >>=20 >> CMP: Should MPLS-over-GRE be an example only? Or otherwise, how do we = interop the two types of =E2=80=9C MPLS-over-GRE=E2=80=9D? > Well, the two ways of doing the same thing are explicitly defined to = be equivalent, so I don't think there is an interop issue, the issue is = more of "can we get rid of the MPLS-in-GRE type without causing a = backwards compatibility problem=E2=80=9D. Sorry, what I meant was if an endpoint understands one way, and the = other endpoint the other way only. I do not disagree with what you write, but an explicit statement would = not hurt (and may help) >> Should an example be also added about MPLS-over-L3TPv3? > Surely no one will ever propose MPLS-over-L2TPv3 again! I meant it in the sense of why a special case for MPLS-over-GRE as its = own type. >>=20 >> 3.3.1. IPv4 DS Field >>=20 >> CMP: Why not also define this for IPv6? > There are a lot of possible Outer Encapsulation sub-TLVs that could be = created, I only included a couple of examples that seemed like they = might be useful. If you have some sub-TLVs to suggest for the case = where the outer encapsulation is IPv6, please suggest some text. (Some = IPv6-specific text will probably make it easier to get the draft past = the IESG ;-)) Sorry I was not clear =E2=80=94 this is what I meant: Section 3.3.1 is defining a DS field based on RFC 2474. RFC 2474 in turn = defines the DS field for the IPv4 TOS and the IPv6 TC octets. Therefore, why would this sub-section be suddenly limited to IPv4, when = 2474 applies to both IPv4 and IPv6? In other words, why not: =E2=80=9C3.3.1. IP DS Field=E2=80=9D? [I did not mean let=E2=80=99s have some IPv6-specific sub-TLVs] I have been thinking about the Flow Label advertisement for IPv6, but = I=E2=80=99m still thinking about it :-) Lastly, this reminds me of a very small nit: Sections 3.6 (and others?) = refers to the MPLS ToS field, when that=E2=80=99s been renamed to the TC = field https://tools.ietf.org/html/rfc5462 = . >>=20 >> 3.3.2. UDP Destination Port >>=20 >> CMP: One additional thought. Obsoleting RFC 5512 also removes the = anchor from RFC 5640 =E2=80=94 that is not a terrible deal in itself, = but is there also an opportunity to generalize the Load-Balancing = approach thereby defined to also include the new encapsulations=E2=80=99 = LB, UDP-based (port as the LB Field), etc? > I wasn't aware of RFC 5640. >=20 > I don't think there's anything in RFC 5640 that requires the = Encapsulation-SAFI. So at a minimum, I think we can get by with saying = that the tunnel-encaps draft updates RFC 5640, and that the LB Block = sub-TLV can be included in the a tunnel TLV of a tunnel encapsulation = attribute that is attached to an update of any AFI/SAFI. Exactly. >=20 > If you think it is worthwhile to generalize the load balancing = approach of RFC 5640, perhaps the best approach would be to do a = 5640bis. If you don=E2=80=99t disagree, I think saying what you described two = paragraphs above would really help (and most likely be sufficient). >=20 >>=20 >> I hope these are clear and useful =E2=80=94 Thanks! >>=20 > Looking forward to any additional comments you might have! Apologies for the delay in sending these out as well as with this = follow-up. One additional small request =E2=80=94 in Section 12.5, could we please = reserve a couple of values for experiments? =E2=80=9C IANA is requested to assign two codepoints from the "BGP Tunnel Encapsulation Tunnel Types" registry for experimentation. The values 65534 and 65535 are recommended for experimental use. =E2=80=9C Thanks! =E2=80=94 Carlos. --Apple-Mail=_2B05E73D-B176-45F5-B753-0C8C69FC1C2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Eric,

Thanks for the response =E2=80=94 please find some follow-ups = inline.

On Feb 15, 2016, at 12:22 PM, = Eric C Rosen <erosen@juniper.net> wrote:

On = 2/11/2016 6:38 PM, Carlos Pignataro (cpignata) wrote:
Hi, Eric,

Thanks for sending this out =E2=80=94 I am = interested in this document, and will give it a critical review (in = particular the sections you call out below).
Thanks!

In the mean time, however, I wanted to send a = few high-level comments (prepended with =E2=80=9CCMP=E2=80=9D) from = scanning through it. I hope these are useful.

3.2.  Encapsulation Sub-TLVs for Particular Tunnel = Types

   This section = defines Tunnel Encapsulation sub-TLVs for the following
=    tunnel types: VXLAN ([RFC7348]), VXLAN-GPE = ([VXLAN-GPE]), NVGRE
   ([RFC7637]), GTP = ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890],
=    [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], = [RFC2890],
   [RFC4023]).


CMP: More comments below, but I am a bit = confused about the need to include MPLS-in-GRE, and the lack of IP-in-IP = (Tunnel Type 7) for example.
MPLS-in-GRE is = included in section 3.2 because there is already a tunnel type codepoint = allocated for it, and if that tunnel type is used, an encapsulation = sub-TLV is needed in order to signal the GRE key.

One can argue that there is no need for the MPLS-in-GRE = tunnel type, since everything you can do with it could be done instead = with the GRE tunnel type.  But unless and until we decide to = deprecate the MPLS-in-GRE tunnel type, it needs to be included. =    In theory, I would love to see the MPLS-in-GRE tunnel = type deprecated, but I worry that that might introduce a backwards = compatibility problem.    This is certainly something = that can be discussed by the WG.


I = agree =E2=80=94 and would welcome that discussion as well.

IP-in-IP is not mentioned in section 3.2 because, although = there is a tunnel type codepoint allocated for it, no one has ever = defined an encapsulation sub-TLV for it.  Also, if it is necessary = to signal values for the fields of the outer iP header, it might make = more sense to use an "outer encapsulation sub-TLV" (section 3.3). =  Do you have an opinion about this?

You = are right, Section 3.2 is indeed about the sub-TLVs. I believe I was = reacting to IP-in-IP not being mentioned anywhere (other than briefly in = the IANA section).

Perhaps I was = expecting something like this, although I agree with you it=E2=80=99s a = no-op:

3.2.x. IP-in-IP

   This document does not defines = an encapsulation sub-TLV for IP-in-IP = tunnels.
   When the tunnel type is IP-in-IP, the = encapsulation sub-TLV MUST NOT be used.

Now, IP-in-IP and other tunnels (like for example = MPLS-over-UDP) present an interesting question (that you raise above): = In these, is the encapsulation IP and UDP, or is this a null = encapsulation with an outer encapsulation of IP and UDP?

To me, the pragmatic case is to use the Outer = encapsulation sub-TLV for IP fields in IP-in-IP, and for UDP fields in = MPLS-over-UDP. 

However, if the = Tunnel Type is IP-in-IP (7), then using an Outer-encapsulation sub-TLV = would imply IP-in-IP-in-IP. Is IP-in-IP a null tunnel type with outer = encapsulation and with protocol =3D 0x0800? No. It is an IP-in-IP tunnel = type. No protocol (since the tunnel encap constraints it to IP), and no = outer encap. It is not =E2=80=9Cfurther encapsulated inside UDP and/or = IP=E2=80=9D as the text in section 1.3

It would certainly help to explain this = explicitly.

It gets equally = interesting with MPLS-over-UDP, because =E2=80=9CUDP=E2=80=9D is not a = tunnel type specified just yet, which could be used with MPLS protocol = type sub-TLV. Or a more limiting and duplicative MPLS-in-UDP tunnel = type.  What tunnel type is used there? null encap? protocol type = sub-TLV?

One additional comment =E2=80= =94 I could not figure out the sorting order for the encapsulations in = subsections 3.2.x. I would consider sorting by tunnel type value in = ascending order, and starting each sub-section with a =E2=80=9CThis = encapsulation sub-TLV is used when the Tunnel Type is XYZ (numerical = value)"


CMP: A couple of editorial comments as well: = For GRE, I think you also need to cite RFC 7676 (GRE over IPv6)
Sure.

Thank = you.


CMP: Also, having this document Obsolete RFC 5512 effectively = also orphans a number of Tunnel types and sub-TLVs. For example, Tunnel = Types values 3-6 from RFC 5566 (IPsec Tunnel Encap) and IPsec Tunnel = Authenticator sub-TLV. I do not know if the answer is to also have that = incorporated (useful parts as you say) and obsoleted. Maybe not, maybe = it does make sense given it is a short doc, which would lead to a = complete self-contained set of Tunnel types.
I = think RFC 5566 will have to be obsoleted and replaced.  I've been = thinking about that, but I'm still not sure how much of 5566 should be = moved into the tunnel-encaps draft and how much should be in a separate = draft.  There are some non-obvious issues to consider.  For = example, 5566 really is  just intended to facilitate iPsec Security = Associations between BGP Next Hops, but with the tunnel encapsulation = attribute we could presumably set up Security Associations from ingress = to egress.

Indeed. Thank you =E2=80=94 the goal would be that = 5566 does not get completely out-of-sync.


3.2.4.  L2TPv3

I forgot to mention, the way in which the = encapsulation sub-TLV is defined, this specifies only encapsulation for = L2TPv3 directly over IP. This section, as well as all references to it, = should be =E2=80=9CL2TPv3 over IP=E2=80=9D (like the tunnel type is = named now) http://www.iana.org/assignments/bgp-parameters/bgp-parameters.x= html#tunnel-types

L2TPv3 can = run:
* over IP: https://tools.ietf.org/html/rfc3931#section-4.1.1.1 
* over UDP: https://tools.ietf.org/html/rfc3931#section-4.1.2.1 

And L2TPv3 over UDP has a slightly = different encap header, so using the outer encap sub-TLV is not the way = to define L2TPv3 over UDP. Consequently, I=E2=80=99d explicitly say = =E2=80=9CL2TPv3 over IP=E2=80=9D everywhere.

=E2=80=A6
      Cookie: an = optional, variable length (encoded in octets -- 0 to 8
=       octets) value used by L2TPv3 to = check the association of a

CMP: The cookie = can only take sizes 0, 4, or 8 octets, and not 0..8
Do you have a reference for that?  Section = 4.1 of RFC 3931 seems to say only that the field is variable length with = a maximum size of 64 bits.
Yes, RFC 3931, when defining the Assigned = Cookie: https://tools.ietf.org/html/rfc3931#page-50 as well = as the 4th paragraph of S8.2 of RFC 3931.


3.2.7.  MPLS-in-GRE

CMP: This seems to be an example and not a = separate encapsulation type. This is GRE Type, with MPLS as protocol = sub-TLV. I see that the section says:

=    While it is not really necessary to have both the GRE = and MPLS-in-GRE
   tunnel types, both are = included for reasons of backwards
=    compatibility.

CMP: I = will also note that having two different ways of doing the same thing = (Tunnel Type 2 and protocol 0x8847 vs. Tunnel Type 11) takes us away = from interop., and that there does not seem to be MPLS-in-GRE defined in = any RFC (so it seems like potentially a good time to rationalize instead = of perpetuate). My $0.02 only.
Tunnel type 11 = is used by draft-ietf-bess-evpn-overlay.

CMP: Should MPLS-over-GRE be an = example only? Or otherwise, how do we interop the two types of =E2=80=9C = MPLS-over-GRE=E2=80=9D?
Well, the two ways of = doing the same thing are explicitly defined to be equivalent, so I don't = think there is an interop issue, the issue is more of "can we get rid of = the MPLS-in-GRE type without causing a backwards compatibility = problem=E2=80=9D.

Sorry, what I meant was if an endpoint understands = one way, and the other endpoint the other way only. 

I do not disagree with what you write, but an = explicit statement would not hurt (and may help)

Should an example be = also added about MPLS-over-L3TPv3?
Surely no = one will ever propose MPLS-over-L2TPv3 again!

I = meant it in the sense of why a special case for MPLS-over-GRE as its own = type.


3.3.1.  IPv4 DS Field

CMP: = Why not also define this for IPv6?
There are = a lot of possible Outer Encapsulation sub-TLVs that could be created, I = only included a couple of examples that seemed like they might be = useful.  If you have some sub-TLVs to suggest for the case where = the outer encapsulation is IPv6, please suggest some text. =   (Some IPv6-specific text will probably make it easier to get = the draft past the IESG ;-))

Sorry = I was not clear =E2=80=94 this is what I meant:

Section 3.3.1 is defining a DS field based on RFC = 2474. RFC 2474 in turn defines the DS field for the IPv4 TOS and the = IPv6 TC octets. 

Therefore, why = would this sub-section be suddenly limited to IPv4, when 2474 applies to = both IPv4 and IPv6?

In other words, = why not: =E2=80=9C3.3.1.  IP DS Field=E2=80=9D?

[I did not mean let=E2=80=99s have some = IPv6-specific sub-TLVs]

I have been = thinking about the Flow Label advertisement for IPv6, but I=E2=80=99m = still thinking about it :-)

Lastly, = this reminds me of a very small nit: Sections 3.6 (and others?) refers = to the MPLS ToS field, when that=E2=80=99s been renamed to the TC = field https://tools.ietf.org/html/rfc5462.


3.3.2. =  UDP Destination Port

CMP: One = additional thought. Obsoleting RFC 5512 also removes the anchor from RFC = 5640 =E2=80=94 that is not a terrible deal in itself, but is there also = an opportunity to generalize the Load-Balancing approach thereby defined = to also include the new encapsulations=E2=80=99 LB, UDP-based (port as = the LB Field), etc?
I wasn't aware of RFC = 5640.

I don't think there's anything in RFC = 5640 that requires the Encapsulation-SAFI.  So at a minimum, I = think we can get by with saying that the tunnel-encaps draft updates RFC = 5640, and that the LB Block sub-TLV can be included in the a tunnel TLV = of a tunnel encapsulation attribute that is attached to an update of any = AFI/SAFI.

Exactly.


If= you think it is worthwhile to generalize the load balancing approach of = RFC 5640, perhaps the best approach would be to do a 5640bis.

If = you don=E2=80=99t disagree, I think saying what you described two = paragraphs above would really help (and most likely be = sufficient).



I hope these are clear and useful =E2=80=94 = Thanks!

Looking forward to any = additional comments you might have!

Apologies for the delay in sending these out as well as with = this follow-up.

One additional small request =E2=80=94 in Section 12.5, could = we please reserve a couple of values for experiments?

=E2=80=9C
   IANA is requested to assign two = codepoints from the "BGP Tunnel
  =  Encapsulation Tunnel Types" registry for experimentation. = The 
   values 65534 and 65535 = are recommended for experimental use.
=E2=80=9C
=

Thanks!

=E2=80=94 = Carlos.

= --Apple-Mail=_2B05E73D-B176-45F5-B753-0C8C69FC1C2F-- --Apple-Mail=_0B18B767-0822-4372-8C6B-45EDC44516EF 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 - http://gpgtools.org iQIcBAEBCAAGBQJW07NgAAoJEIXgpQGOZny9hsYP/3iYBd2+CetnaIJ2gj2/HC1N GIxSMqoF0xig3hwK9b+baryMprkgXF1lTOqC7Dy8XbBfl7bVJ1cszTZrw7F8i4p4 LTHtqhvijKt8ekZdscmcHk3YbidhvaW9/q3rU6Oa7dGzuGfDEMlgfKRltpzN6NXk FRPdBz6jo2+A+ojnhMvdg3p7FFUb5XY/g1a+lf4rKB74geKUR5P6ARbhARI2ffAi LKUYfWh/cWXqUpGN9dHaGZEtO9+tnMmrEQbjkQi73/atfcJQ9mOEvkp+4XF2XKP/ QMmImq2/ZYmVL0AvnBR6bNX8IbRZREnBrpOaQ/YhoncmKWAkGqQy1rrHiFCoZpoY Kdr4Xck/4ZQK2/xNhF2JyTYGS1NgHxDtEfQ4X6O9ScmoOWhVRCykAl7okSXhkS5P hlJFfu2yRnZ1tJK/iWpF35aRe1cliJ2wSRWMXwQLycsc4AFcsNUv9NsHZcSIbJu8 MlCrKLIqjBRNC1ufU2XJTWywtx/Ue7kopXfXU/GvJT3VzDVSbM99tzRxx9Exm7/n uIItTIQJyl568oi97w7W4d2d3ATgNTcsSzIa4Q5bfYNiV6lSa0QEYVoqwS8QXQ2Y /SM2+wX2v5f5dLx1wjN3aX9iPB1CJsUzXYhIZZbViXwVDBPjOHgQM/Z+oPxjfwiH m9J3NmkSw5cfCQqpl+Qd =tLwz -----END PGP SIGNATURE----- --Apple-Mail=_0B18B767-0822-4372-8C6B-45EDC44516EF-- From nobody Mon Feb 29 00:07:33 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C7F1B2DA3 for ; Mon, 29 Feb 2016 00:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.006, SPF_SOFTFAIL=0.665] 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 v0Hvjx1-FnF5 for ; Mon, 29 Feb 2016 00:07:32 -0800 (PST) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 477EA1B2D9D for ; Mon, 29 Feb 2016 00:07:32 -0800 (PST) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7E29241024C; Mon, 29 Feb 2016 09:07:31 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 6C13A41024B; Mon, 29 Feb 2016 09:07:31 +0100 (CET) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Mon, 29 Feb 2016 09:07:30 +0100 To: References: <56A72A83.10906@orange.com> From: Thomas Morin Organization: Orange Message-ID: <56D3FC42.1090901@orange.com> Date: Mon, 29 Feb 2016 09:07:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56A72A83.10906@orange.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-rabadan-bess-evpn-optimized-ir@tools.ietf.org Subject: [bess] draft-rabadan-bess-evpn-optimized-ir is adopted (was Re: Poll for adoption: draft-rabadan-bess-evpn-optimized-ir-02) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 08:07:33 -0000 Hi everyone, This draft is now a WG document. Authors, can you please repost as draft-ietf-bess-evpn-optimized-ir ? Thanks, -Thomas 2016-01-26, Thomas Morin: > Hello working group, > > This email starts a two-week poll on adopting > draft-rabadan-bess-evpn-optimized-ir-02 [1] as a working group item. > > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). > > This poll runs until **February 9th**. > > > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you 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. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://tools.ietf.org/html/draft-rabadan-bess-evpn-optimized-ir-02 > > > > > > > > > > > > > From nobody Mon Feb 29 01:45:41 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA451B2EFF; Mon, 29 Feb 2016 01:45:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160229094540.978.46862.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 01:45:40 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-optimized-ir-00.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 09:45:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services of the IETF. Title : Optimized Ingress Replication solution for EVPN Authors : Jorge Rabadan Senthil Sathappan Wim Henderickx Ali Sajassi Aldrin Isaac Filename : draft-ietf-bess-evpn-optimized-ir-00.txt Pages : 24 Date : 2016-02-29 Abstract: Network Virtualization Overlay (NVO) networks using EVPN as control plane may use ingress replication (IR) or PIM-based trees to convey the overlay multicast traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the NVO core network. IR avoids the dependency on PIM in the NVO network core. While IR provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of IR in NVO networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-optimized-ir-00 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 Mon Feb 29 10:09:55 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABE61B342E for ; Mon, 29 Feb 2016 10:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.2 X-Spam-Level: X-Spam-Status: No, score=-101.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, 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 6hUGYHjaceaX for ; Mon, 29 Feb 2016 10:09:51 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA6C1B393B for ; Mon, 29 Feb 2016 10:09:51 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u1TI9nDc026838; Mon, 29 Feb 2016 18:09:49 GMT Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u1TI9dT9026716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 29 Feb 2016 18:09:41 GMT From: "Adrian Farrel" To: "'Martin Vigoureux'" , References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Date: Mon, 29 Feb 2016 18:09:39 -0000 Message-ID: <02cc01d1731c$5eb7fe10$1c27fa30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGYNzxtGtu+pw3mSOviWI5H/hbi7J+1yNdA X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22164.001 X-TM-AS-Result: No--17.577-10.0-31-10 X-imss-scan-details: No--17.577-10.0-31-10 X-TMASE-MatchedRID: y/2oPz6gbvgwk3SkELeip2zBijri5+RV6Jj6zYvfFASdI/DikZ1UPFvZ d+pzqSxfYEwjdRBgFKUTNcrm8YCxBNcUNjoF7YuV+z2c4lioPkgZskwWqoib3LBOE9APtGEpkpC WzIXhzQFbJZ1RCjSbQw5gsVv7cmyxiVm/X1CarJBT46Ow+EhYOAYAPqHoVmYR1MUvXa3LfbfnF4 EK4QR5mj6Ro5WkokkJ2DSNs6QXbpjEyfTozpcRipMSBMTQNiSAmH96+GQqaOozFWOYrWw6A+4Sv dNfpgvgEVtxaPoSt7AeYZj+jjPzyU1+zyfzlN7y/sToY2qzpx79b0xgYrma7dRnEQCUU+jzjocz muoPCq2xGLMPeaI1PBQmr4Wee5RGiqbT4Shp3t2MY2ggO//qkGZ1Hp86fYxc Archived-At: Cc: draft-fm-bess-service-chaining@tools.ietf.org Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 18:09:54 -0000 As a co-author of draft-rfernando-bess-service-chaining on which this I-D is partially based: - I am unaware of any related IPR - I am really pleased to see some convergence between the authors of the various drafts - I believe the WG needs to be working on a document in this area - I think this is a really good starting point Adrian > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: 22 February 2016 16:59 > To: bess@ietf.org > Cc: draft-fm-bess-service-chaining@tools.ietf.org > Subject: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 > > Hello working group, > > This email starts a two-week poll on adopting > draft-fm-bess-service-chaining-02 [1] as a working group Document. > > Please state on the list if you support adoption or not (in both cases, > please also state the reasons). > > This poll runs until *the 7th of March*. > > Note that IPR has been disclosed against an earlier version of this > document: > https://datatracker.ietf.org/ipr/2284/ > > Yet, we are *coincidentally* also polling for knowledge of any other > IPR that applies to this draft, to ensure that IPR has been disclosed > in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you 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. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Mon Feb 29 11:32:58 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2181B3A82; Mon, 29 Feb 2016 11:32:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160229193251.24780.65072.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 11:32:51 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 19:32:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services of the IETF. Title : Interconnect Solution for EVPN Overlay networks Authors : Jorge Rabadan Senthil Sathappan Wim Henderickx Senad Palislamovic Ali Sajassi Dennis Cai Filename : draft-ietf-bess-dci-evpn-overlay-02.txt Pages : 23 Date : 2016-02-29 Abstract: This document describes how Network Virtualization Overlay networks (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running EVPN and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS or EVPN/PBB-EVPN, and proposes a solution for the interworking between both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-dci-evpn-overlay-02 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 Mon Feb 29 23:17:14 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FB21B29F6; Mon, 29 Feb 2016 23:17:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160301071713.24855.85385.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 23:17:13 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-virtual-subnet-fib-reduction-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 07:17:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services of the IETF. Title : FIB Reduction in Virtual Subnet Authors : Xiaohu Xu Christian Jacquenet Truman Boyes Brendan Fee Wim Henderickx Filename : draft-ietf-bess-virtual-subnet-fib-reduction-02.txt Pages : 6 Date : 2016-02-29 Abstract: Virtual Subnet is a BGP/MPLS IP VPN-based subnet extension solution which is intended for building Layer3 network virtualization overlays within and/or between data centers. This document describes a mechanism for reducing the FIB size of PE routers in the Virtual Subnet context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet-fib-reduction/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-virtual-subnet-fib-reduction-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-virtual-subnet-fib-reduction-02 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/