From nobody Sat Jul 1 07:53:55 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339A1128BC8; Sat, 1 Jul 2017 07:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=dGs3BT0g; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=GGA9IuUs 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 v3aQQyH4PxPV; Sat, 1 Jul 2017 07:53:41 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 C0A6F127180; Sat, 1 Jul 2017 07:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498920482; x=1530456482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tOYUwwUkY2e9/jKtJgENIjVUb0YoJH7mujKOsyHFIoM=; b=dGs3BT0gZtKrnf3Cn/QcIk2kUPJTJApEs0cp+SpO9iErnc4wK3q/X1a9 zq7+HjnLoRxgGQzXil2/CYMbwHNLEoa/gmK9y13XVj6eWFQHgLXSO8lOt PTcnjDme9m9n6PT3BCVAMjoMsvP+IfK7jSiklIavFGsCDxSEG+W2ezXjd k=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2017 09:47:59 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2017 20:48:28 +0600 Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v61ErYiP013098 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Jul 2017 10:53:35 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v61ErYiP013098 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498920815; bh=Ykwf0xoaRMa8qYDBCgz0fvPavOc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GGA9IuUskNWMoEuEzOYJK/AGlgywt0ZlRWvFxBi3pW3W128+lTToD/CBMDtfTmiLY 04t6diKSkZvUvF2jrnkfPdek6r9ZgpYl953kJDqWz5E6EVwlF00jmCV6oAYHfCscrp 9Sio0OUwsXipYFsuHC2gASiRWGyqj6w7MZFBw8/0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v61ErYiP013098 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Sat, 1 Jul 2017 10:53:19 -0400 Received: from MXHUB304.corp.emc.com (MXHUB304.corp.emc.com [10.146.3.30]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v61ErJsN004413 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sat, 1 Jul 2017 10:53:19 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB304.corp.emc.com ([10.146.3.30]) with mapi id 14.03.0352.000; Sat, 1 Jul 2017 10:53:16 -0400 To: Donald Eastlake CC: Magnus Westerlund , "tsv-art@ietf.org" , "draft-ietf-trill-over-ip.all@ietf.org" , IETF Discussion , "trill@ietf.org" Thread-Topic: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations Thread-Index: AdLurvO3SYOqL32fRKuavuJggYEWYwDffoiAABLbSJA= Date: Sat, 1 Jul 2017 14:53:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [trill] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 14:53:45 -0000 QWxzbywgYXMgbm90ZWQgZWFybGllciBpbiB0aGlzIGRpc2N1c3Npb24sIFJGQyA3NjU3IGV4cGxp Y2l0bHkgZGlzY291cmFnZXMgdXNlIG9mIG11bHRpcGxlIERTQ1BzIGluIGEgc2luZ2xlIFRDUCBj b25uZWN0aW9uLiAgVGhhdCBuZWVkcyB0byBiZSByZWZsZWN0ZWQgaW4gdGhlIFRDUCBlbmNhcHN1 bGF0aW9uIHRleHQgaW4gdGhlIHRyaWxsLW92ZXItaXAgZHJhZnQgLSBpbiBwYXJ0aWN1bGFyLCB0 aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24gNC4zIG9uIG1hcHBpbmcgdG8gRFNDUHMgZnJvbSBU UklMTCBwcmlvcml0eSBhbmQgREVJIGRvZXMgbm90IGFwcGVhciB0byBiZSBjb25zaXN0ZW50IHdp dGggUkZDIDc2NTcgZm9yIFRDUC1iYXNlZCBlbmNhcHN1bGF0aW9uLg0KDQpUaGFua3MsIC0tRGF2 aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb25hbGQgRWFzdGxh a2UgW21haWx0bzpkM2UzZTNAZ21haWwuY29tXQ0KPiBTZW50OiBGcmlkYXksIEp1bmUgMzAsIDIw MTcgOTo0MyBQTQ0KPiBUbzogQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPg0KPiBD YzogTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT47IHRz di0NCj4gYXJ0QGlldGYub3JnOyBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXAuYWxsQGlldGYub3Jn OyBJRVRGIERpc2N1c3Npb24NCj4gPGlldGZAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW1Rzdi1hcnRdIFRzdmFydCBlYXJseSByZXZpZXcgb2YgZHJhZnQtaWV0Zi10 cmlsbC1vdmVyLWlwLTEwIC0gRUNOICYNCj4gRFNDUCBjb25zaWRlcmF0aW9ucw0KPiANCj4gSGkg RGF2aWQsDQo+IA0KPiBPbiBNb24sIEp1biAyNiwgMjAxNyBhdCAzOjA0IFBNLCBCbGFjaywgRGF2 aWQgPERhdmlkLkJsYWNrQGRlbGwuY29tPg0KPiB3cm90ZToNCj4gPiBBZGRpbmcgc29tZSBjb21t ZW50cyBvbiBFQ04gYW5kIERTQ1AgLi4uDQo+ID4NCj4gPj4gPiBTZWN0aW9uIDQuMzoNCj4gPj4g Pg0KPiA+PiA+ICAgIFRSSUxMIG92ZXIgSVAgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCBz ZXR0aW5nIHRoZSBEU0NQIHZhbHVlIGluDQo+ID4+ID4gICAgdGhlIG91dGVyIElQIEhlYWRlciBv ZiBUUklMTCBwYWNrZXRzIHRoZXkgc2VuZCBieSBtYXBwaW5nIHRoZSBUUklMTA0KPiA+PiA+ICAg IHByaW9yaXR5IGFuZCBERUkgdG8gdGhlIERTQ1AuIFRoZXkgTUFZIHN1cHBvcnQsIGZvciBhIFRS SUxMIERhdGENCj4gPj4gPiAgICBwYWNrZXQgd2hlcmUgdGhlIG5hdGl2ZSBmcmFtZSBwYXlsb2Fk IGlzIGFuIElQIHBhY2tldCwgbWFwcGluZyB0aGUNCj4gPj4gPiAgICBEU0NQIGluIHRoaXMgaW5u ZXIgSVAgcGFja2V0IHRvIHRoZSBvdXRlciBJUCBIZWFkZXIgd2l0aCB0aGUgZGVmYXVsdA0KPiA+ PiA+ICAgIGZvciB0aGF0IG1hcHBpbmcgYmVpbmcgdG8gY29weSB0aGUgRFNDUCB3aXRob3V0IGNo YW5nZS4NCj4gPj4gPg0KPiA+PiA+IEkgdGhpbmsgaXQgaXMgZmluZSB0byByZXF1aXJlIHRoYXQg aW1wbGVtZW50YXRpb25zIGFyZSBjYXBhYmxlIG9mIHNldHRpbmcNCj4gPj4gPiBEU0NQIHZhbHVl cyBvbiB0aGUgb3V0ZXIgSVAgaGVhZGVyLiBIb3dldmVyLCBJIGZhaWwgdG8gc2VlIGFueSBkaXNj dXNzaW9uIG9mDQo+ID4+ID4gdGhlIHBvdGVudGlhbCBpc3N1ZXMgd2l0aCBhY3R1YWxseSBzZXR0 aW5nIHRoZSBEU0NQIHZhbHVlcy4gSXQgaXMgb25lIHRoaW5nIHRvDQo+ID4+ID4gZG8gdGhpcyBp biBhbiBJUCBiYWNrIGJvbmUgdXNlIGNhc2Ugd2hlcmUgb25lIGNhbiBrbm93IGFuZCBoYXZlIGNv bnRyb2wNCj4gPj4gPiBvdmVyIHRoZSBQSEIgdGhhdCB0aGUgRFNDUCB2YWx1ZXMgbWFwcyB0by4g QnV0IG90aGVyd2lzZSwgb3ZlciBnZW5lcmFsIGludGVybmV0IHRoZQ0KPiA+PiA+IGJlaGF2aW9y IGlzIG5vdCB0aGF0IHByZWRpY3RhYmxlLiBPbmUgY2FuIGVhc2lseSBiZSBzdWJqZWN0IHRvIHBv bGljZXJzIG9yDQo+ID4+ID4gcmVtYXBwaW5nLiBBbHNvIGFzIHRoZSBhY3R1YWwgRFNDUCBjb2Rl IHBvaW50IHVzYWdlIGlzIGRvbWFpbiBzcGVjaWZpYyB0aGlzIGlzDQo+ID4+ID4gZGlmZmljdWx0 LiBQcmlvcml0eSByZXZlcnNhbCBpcyBsaWtlbHkgdGhlIGxlYXN0IG9mIHRoZSBwcm9ibGVtcyB0 aGF0IHRoaXMgY2FuDQo+ID4+ID4gcnVuIGludG8gb3ZlciBnZW5lcmFsIEludGVybmV0Lg0KPiA+ Pg0KPiA+PiBJdCBzb3VuZHMgbGlrZSBhcHByb3ByaWF0ZSBkaXNjdXNzaW9uIGFuZCB3YXJuaW5n cyBhYm91dCB0aGVzZSBpc3N1ZXMNCj4gPj4gd291bGQgcmVzb2x2ZSB0aGUgYWJvdmUgY29tbWVu dC4NCj4gPg0KPiA+IEZvciBFQ04sIHNlZSBSRkMgNjA0MCBhbmQgZHJhZnQtaWV0Zi10c3Z3Zy1y ZmM2MDQwdXBkYXRlLXNoaW0uICBJbiBwYXJ0aWN1bGFyLA0KPiA+IGNvcHlpbmcgdGhlIGlubmVy IEVDTiBjb2RlcG9pbnQgdG8gdGhlIG91dGVyIElQIGhlYWRlciBlbmNhcHN1bGF0aW9uIHdpdGhv dXQNCj4gPiByZXF1aXJpbmcgZGVjYXBzdWxhdGlvbiBwcm9jZXNzaW5nIGFzIHNwZWNpZmllZCBp biBSRkMgNjA0MCBvciB0aGUgNjA0MHVwZGF0ZS1zaGltDQo+ID4gZHJhZnQgY2FuIGxvc2UgY29u Z2VzdGlvbiBpbmRpY2F0aW9ucyBmcm9tIHRoZSBuZXR3b3JrIGFuZCBoZW5jZSBpcyB3cm9uZw0K PiA+IChpdCdzIGFsc28gd3Jvbmcgd3J0IFJGQyAzMTY4LCBidXQgUkZDIDYwNDAgYW5kIHRoZSA2 MDQwdXBkYXRlLXNoaW0gZHJhZnRzIGFyZQ0KPiA+IGJldHRlciBhbmQgbW9yZSBjdXJyZW50IHJl ZmVyZW5jZXMpLg0KPiANCj4gVGhhdCdzIGEgZ29vZCBwb2ludC4NCj4gDQo+ID4gRm9yIERTQ1Bz LCBzdGFydCB3aXRoIFJGQyAyOTgzIC0gdGhpbmtpbmcgYWJvdXQgdGhlIHZhbGlkaXR5IChvciBs aWtlbHkgdmFsaWRpdHkpDQo+ID4gb2YgdGhlIG91dGVyIERTQ1AgYXQgdGhlIGRlY2Fwc3VsYXRv ciBtYXkgaGVscCBpbiBjaG9vc2luZyB3aGV0aGVyIHRvDQo+ID4gcmVjb21tZW5kIGEgdW5pZm9y bSBtb2RlbCAoZS5nLiwgY29weSBEU0NQIG91dCBhdCBpbmdyZXNzLCBjb3B5IGJhY2sgaW4gYXQN Cj4gPiBlZ3Jlc3MpIG9yIGEgcGlwZSBtb2RlbCAoZS5nLiwgZG8gc29tZXRoaW5nIHJlYXNvbmFi bGUgZm9yIG91dGVyIERTQ1AgYXQNCj4gPiBpbmdyZXNzLCBpZ25vcmUgaXQgb24gZWdyZXNzKSBh cyB0aGUgaW1wbGVtZW50YXRpb24gZGVmYXVsdC4NCj4gDQo+IEkgYmVsaWV2ZSB0aGUgZGVmYXVs dCBiZWhhdmlvciBpbiB0aGUgY3VycmVudCBkcmFmdCBpcyB0aGUgYmVzdA0KPiBkZWZhdWx0LiBU aGF0IHNldHMgRFNDUCBiYXNlZCBvbiB0aGUgc2FtZSBUUklMTCBIZWFkZXIgaW5kaWNpYSB0aGF0 DQo+IGNvbnRyb2xzIGRlZmF1bHQgUW9TIG9uIG5vbi1JUCBsaW5rcy4NCj4gDQo+ID4gLS0gRFND UCBtYXBwaW5nIHRvL2Zyb20gVFJJTEwvRXRoZXJuZXQgcHJpb3JpdGllcw0KPiA+DQo+ID4+IFRo ZSBpbnRlbnQgaW4gdGhlIGRyYWZ0IGlzIHRvIHJlZmxlY3QgdGhlIGRlZmF1bHQgcmVsYXRpdmUg cHJpb3JpdHkgb2YNCj4gPj4gdGhlIGRpZmZlcmVudCBwcmlvcml0eSBjb2RlIHBvaW50cyBpbiBJ RUVFIFN0ZCA4MDIuMVEgd2hlcmUgcHJpb3JpdHkgMQ0KPiA+PiBpcyBsb3dlciB0aGFuIHByaW9y aXR5IDAuIEF0IGEgcXVpY2sgbG9vaywgaXQgYXBwZWFycyB0byBtZSB0aGF0IFJGQw0KPiA+PiAy NDc0IHJlcXVpcmVzIHRoYXQgMHgwMDEwMDAgYmUgaGFuZGxlZCBhcyBiZWluZyBvZiBhIHByaW9y aXR5IG5vdA0KPiA+PiBsb3dlciB0aGFuIHRoZSBwcmlvcml0eSB3aXRoIHdoaWNoIDB4MDAwMDAw IGlzIGhhbmRsZWQuIFlldCBSRkMgMzY2MiwNCj4gPj4gd2hpY2ggeW91IHBvaW50IHRvLCBzZWVt cyB0byBzdWdnZXN0IHVzaW5nIDB4MDAxMDAwIGFzIGEgbG93ZXINCj4gPj4gcHJpb3JpdHkgY29k ZSBwb2ludCB0aGFuIDB4MDAwMDAwLiBHaXZlbiB0aGF0IDM2NjIgbm90IG9ubHkgZG9lcyBub3QN Cj4gPj4gdXBkYXRlIDI0NzQgYnV0IGlzIG9ubHkgSW5mb3JtYXRpb25hbCB3aGlsZSAyNDc0IGlz IFN0YW5kYXJkcyBUcmFjaywgSQ0KPiA+PiB3b3VsZCBzYXkgdGhhdCAyNDc0IGRvbWluYXRlcyBh bmQgdGhhdCB0aGlzIGRyYWZ0IG1ha2VzIHRoZSBiZXN0DQo+ID4+IGFzc3VtcHRpb25zIGl0IGNh biBhYm91dCBkZWZhdWx0IGJlaGF2aW9yLi4uDQo+ID4NCj4gPiBXZWxsIC4uLiB0aGF0J3MgYSBk aXNjdXNzaW9uIGFib3V0IHRleHQgaW4gUkZDcyB0aGF0IGFyZSB3ZWxsIG92ZXIgYSBkZWNhZGUN Cj4gPiBvbGQsIGFuZCBpbiBhbiBhcmVhIChsZXNzLXRoYW4tYmVzdC1lZmZvcnQgc2VydmljZSkg d2hlcmUgdGhlIGFzcGlyYXRpb25zDQo+ID4gb2YgYXQgbGVhc3QgUkZDIDM2NjIgd2VyZW4ndCBy ZWFsaXplZCAuLi4gYnV0IHRoYXQgUkZDIGlzIG5vdCBzYWZlIHRvIGlnbm9yZSwNCj4gPiBlaXRo ZXIuDQo+ID4NCj4gPiBJbiBwcmFjdGljZSwgdGhlIHNwZWNpZmljYXRpb24gb2YgQ1MxIGZvciBs ZXNzLXRoYW4tYmVzdC1lZmZvcnQgc2VydmljZSBoYXMNCj4gPiBiZWVuIHByb211bGdhdGVkIGJ5 IFJGQyA0NTk0IHJhdGhlciB0aGFuIFJGQyAzNjYyLCBhbmQgUkZDIDQ1OTQgaGFzDQo+ID4gaGFk IHNpZ25pZmljYW50ICJydW5uaW5nIGNvZGUiIGltcGFjdCBvbiBuZXR3b3JrIGRlc2lnbiBhbmQg b3BlcmF0aW9uLg0KPiA+DQo+ID4gQXMgTWFnbnVzIG1lbnRpb25lZCBSRkM3NjU3LCBJIHN0cm9u Z2x5IHN1Z2dlc3Qgc3RhcnRpbmcgZnJvbSB0aGUNCj4gPiBSRkMgNzY1NyBkaXNjdXNzaW9uIG9m IHRoaXMgdG9waWMgaW4gb3JkZXIgdG8gZmlndXJlIG91dCB3aGF0IHRvIGRvLiAgSSdtDQo+ID4g bm90IHN1cmUgd2hhdCB0byByZWNvbW1lbmQsIGJ1dCBJIGRvIHRoaW5rIHRoYXQgc3RhcnRpbmcg ZnJvbQ0KPiA+IFJGQyA3NjU3IChyYXRoZXIgdGhhbiBSRkMgMjQ3NCBhbmQgUkZDIDM2NjIpIGlz IHRoZSBiZXR0ZXIgYXBwcm9hY2guDQo+IA0KPiBPSy4NCj4gDQo+ID4gRldJVywgdGhlIFRTVldH IFdHIGlzIGluIHRoZSBwcm9jZXNzIG9mIGZpZ3VyaW5nIG91dCB3aGljaCBEU0NQDQo+ID4gdG8g cmVjb21tZW5kIGZvciBsZXNzLXRoYW4tYmVzdC1lZmZvcnQtc2VydmljZSBpbiBwbGFjZSBvZiBD UzEgLSB0aGF0J3MNCj4gPiBsaWtlbHkgdG8gYmUgYW4gYWN0aXZlIHRvcGljIG9mIGRpc2N1c3Np b24gaW4gUHJhZ3VlLg0KPiANCj4gSSdsbCB0cnkgdG8gYXR0ZW5kIHRoYXQgc2Vzc2lvbi4NCj4g DQo+IFRoYW5rcywNCj4gRG9uYWxkDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cj4gIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQo+ICAx NTUgQmVhdmVyIFN0cmVldCwgTWlsZm9yZCwgTUEgMDE3NTcgVVNBDQo+ICBkM2UzZTNAZ21haWwu Y29tDQo+IA0KPiA+IFRoYW5rcywgLS1EYXZpZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+IEZyb206IFRzdi1hcnQgW21haWx0bzp0c3YtYXJ0LWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBEb25hbGQNCj4gPj4gRWFzdGxha2UNCj4gPj4gU2VudDogU3Vu ZGF5LCBKdW5lIDI1LCAyMDE3IDg6MDcgUE0NCj4gPj4gVG86IE1hZ251cyBXZXN0ZXJsdW5kIDxt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQo+ID4+IENjOiB0c3YtYXJ0QGlldGYub3Jn OyBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXAuYWxsQGlldGYub3JnOyBJRVRGIERpc2N1c3Npb24N Cj4gPj4gPGlldGZAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTog W1Rzdi1hcnRdIFRzdmFydCBlYXJseSByZXZpZXcgb2YgZHJhZnQtaWV0Zi10cmlsbC1vdmVyLWlw LTEwDQo+ID4+DQo+ID4+IEhpIE1hZ251cywNCj4gPj4NCj4gPj4gVGhhbmtzIGZvciB0aGUgZXh0 ZW5zaXZlIHJldmlldy4gU2VlIG15IHJlc3BvbnNlcyBiZWxvdy4NCj4gPj4NCj4gPj4gT24gVGh1 LCBKdW4gMTUsIDIwMTcgYXQgMTozMiBQTSwgTWFnbnVzIFdlc3Rlcmx1bmQNCj4gPj4gPG1hZ251 cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ID4+ID4NCj4gPj4gPiBSZXZpZXdl cjogTWFnbnVzIFdlc3Rlcmx1bmQNCj4gPj4gPiBSZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHkNCj4g Pj4gPg0KPiA+PiA+IEVhcmx5IHJldmlldyBvZiBkcmFmdC1pZXRmLXRyaWxsLW92ZXItaXAtMTAN Cj4gPj4gPiBSZXZpZXdlcjogTWFnbnVzIFdlc3Rlcmx1bmQNCj4gPj4gPiBSZXZpZXcgcmVzdWx0 OiBOb3QgUmVhZHkNCj4gPj4gPg0KPiA+PiA+IFRTVi1BUlQgcmV2aWV3IGNvbW1lbnRzOg0KPiA+ PiA+DQo+ID4+ID4gSSBoYXZlIHNldCB0aGlzIHRvIG5vdCByZWFkeSBhcyB0aGVyZSBhcmUgc2V2 ZXJhbCBpc3N1ZXMsIHNvbWUgc2lnbmlmaWNhbnQNCj4gdGhhdA0KPiA+PiA+IGNvdWxkIGFmZmVj dCB0aGUgcHJvdG9jb2wgcmVhbGl6YXRpb24gc2lnbmlmaWNhbnRseS4gU29tZSBtYXkgYmUgbWUN Cj4gbWlzc2luZw0KPiA+PiA+IHRoaW5ncyBpbiBUUklMTCwgSSB3YXMgbm90IHRoYXQgZmFtaWxp YXIgd2l0aCBpdCBiZWZvcmUgdGhpcyByZXZpZXcgYW5kIEkgaGF2ZQ0KPiA+PiA+IG9ubHkgdHJp ZWQgbG9va2luZyB1cCB0aGluZ3MsIG5vdCByZWFkaW5nIHRoZSB3aG9sZSBlYXJsaWVyIHNwZWNp ZmljYXRpb25zLg0KPiBTbw0KPiA+PiA+IGRvbid0IGhlc2l0YXRlIHRvIHB1c2ggYmFjayBhbmQg cHJvdmlkZSBwb2ludGVycyB0byB0aGluZ3MgdGhhdCBjYW4NCj4gcmVzb2x2ZQ0KPiA+PiA+IGlz c3Vlcy4gVGhlIGF1dGhvcnMgYW5kIHRoZSBXRyBjbGVhcmx5IGhhdmUgdGhvdWdodCBhYm91dCBh IGxvdCBvZiBpc3N1ZXMNCj4gPj4gYW5kDQo+ID4+ID4gZGVhbHQgd2l0aCBtdWNoIGFscmVhZHku DQo+ID4+DQo+ID4+IE9LLiBIb3BlZnVsbHkgd2UgY2FuIHJlc29sdmUgdGhlc2Ugb25lIHdheSBv ciB0aGUgb3RoZXIuDQo+ID4+DQo+ID4+ID4gRGlmZnNlcnYgdXNhZ2UNCj4gPj4gPiAtLS0tLS0t LS0tLS0tLQ0KPiA+PiA+DQo+ID4+ID4gU2VjdGlvbiA0LjM6DQo+ID4+ID4NCj4gPj4gPiAgICBU UklMTCBvdmVyIElQIGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQgc2V0dGluZyB0aGUgRFND UCB2YWx1ZSBpbg0KPiA+PiA+ICAgIHRoZSBvdXRlciBJUCBIZWFkZXIgb2YgVFJJTEwgcGFja2V0 cyB0aGV5IHNlbmQgYnkgbWFwcGluZyB0aGUgVFJJTEwNCj4gPj4gPiAgICBwcmlvcml0eSBhbmQg REVJIHRvIHRoZSBEU0NQLiBUaGV5IE1BWSBzdXBwb3J0LCBmb3IgYSBUUklMTCBEYXRhDQo+ID4+ ID4gICAgcGFja2V0IHdoZXJlIHRoZSBuYXRpdmUgZnJhbWUgcGF5bG9hZCBpcyBhbiBJUCBwYWNr ZXQsIG1hcHBpbmcgdGhlDQo+ID4+ID4gICAgRFNDUCBpbiB0aGlzIGlubmVyIElQIHBhY2tldCB0 byB0aGUgb3V0ZXIgSVAgSGVhZGVyIHdpdGggdGhlIGRlZmF1bHQNCj4gPj4gPiAgICBmb3IgdGhh dCBtYXBwaW5nIGJlaW5nIHRvIGNvcHkgdGhlIERTQ1Agd2l0aG91dCBjaGFuZ2UuDQo+ID4+ID4N Cj4gPj4gPiBJIHRoaW5rIGl0IGlzIGZpbmUgdG8gcmVxdWlyZSB0aGF0IGltcGxlbWVudGF0aW9u cyBhcmUgY2FwYWJsZSAgb2Ygc2V0dGluZw0KPiA+PiA+IERTQ1AgdmFsdWVzIG9uIHRoZSBvdXRl ciBJUCBoZWFkZXIuIEhvd2V2ZXIsIEkgZmFpbCB0byBzZWUgYW55IGRpc2N1c3Npb24NCj4gb2YN Cj4gPj4gPiB0aGUgcG90ZW50aWFsIGlzc3VlcyB3aXRoIGFjdHVhbGx5IHNldHRpbmcgdGhlIERT Q1AgdmFsdWVzLiBJdCBpcyBvbmUgdGhpbmcNCj4gdG8NCj4gPj4gPiBkbyB0aGlzIGluIGFuIElQ IGJhY2sgYm9uZSB1c2UgY2FzZSB3aGVyZSBvbmUgY2FuIGtub3cgYW5kIGhhdmUgY29udHJvbA0K PiA+PiBvdmVyDQo+ID4+ID4gdGhlIFBIQiB0aGF0IHRoZSBEU0NQIHZhbHVlcyBtYXBzIHRvLiBC dXQgb3RoZXJ3aXNlLCBvdmVyIGdlbmVyYWwNCj4gPj4gaW50ZXJuZXQgdGhlDQo+ID4+ID4gYmVo YXZpb3IgaXMgbm90IHRoYXQgcHJlZGljdGFibGUuIE9uZSBjYW4gZWFzaWx5IGJlIHN1YmplY3Qg dG8gcG9saWNlcnMgb3INCj4gPj4gPiByZW1hcHBpbmcuIEFsc28gYXMgdGhlIGFjdHVhbCBEU0NQ IGNvZGUgcG9pbnQgdXNhZ2UgaXMgZG9tYWluIHNwZWNpZmljDQo+IHRoaXMNCj4gPj4gaXMNCj4g Pj4gPiBkaWZmaWN1bHQuIFByaW9yaXR5IHJldmVyc2FsIGlzIGxpa2VseSB0aGUgbGVhc3Qgb2Yg dGhlIHByb2JsZW1zIHRoYXQgdGhpcyBjYW4NCj4gPj4gPiBydW4gaW50byBvdmVyIGdlbmVyYWwg SW50ZXJuZXQuDQo+ID4+DQo+ID4+IEl0IHNvdW5kcyBsaWtlIGFwcHJvcHJpYXRlIGRpc2N1c3Np b24gYW5kIHdhcm5pbmdzIGFib3V0IHRoZXNlIGlzc3Vlcw0KPiA+PiB3b3VsZCByZXNvbHZlIHRo ZSBhYm92ZSBjb21tZW50Lg0KPiA+Pg0KPiA+PiA+IFNlY3Rpb24gNC4zOg0KPiA+PiA+DQo+ID4+ ID4gICAgVGhlIGRlZmF1bHQgVFJJTEwgcHJpb3JpdHkgYW5kIERFSSB0byBEU0NQIG1hcHBpbmcs IHdoaWNoIG1heSBiZQ0KPiA+PiA+ICAgIGNvbmZpZ3VyZWQgcGVyIFRSSUxMIG92ZXIgSVAgcG9y dCwgaXMgYW4gZm9sbG93cy4gTm90ZSB0aGF0IHRoZSBERUkNCj4gPj4gPiAgICB2YWx1ZSBkb2Vz IG5vdCBhZmZlY3QgdGhlIGRlZmF1bHQgbWFwcGluZyBhbmQsIHRvIHByb3ZpZGUgYQ0KPiA+PiA+ ICAgIHBvdGVudGlhbGx5IGxvd2VyIHByaW9yaXR5IHNlcnZpY2UgdGhhbiB0aGUgZGVmYXVsdCBw cmlvcml0eSAwLA0KPiA+PiA+ICAgIHByaW9yaXR5IDEgaXMgY29uc2lkZXJlZCBsb3dlciBwcmlv cml0eSB0aGFuIDAuIFNvIHRoZSBwcmlvcml0eQ0KPiA+PiA+ICAgIHNlcXVlbmNlIGZyb20gbG93 ZXIgdG8gaGlnaGVyIHByaW9yaXR5IGlzIDEsIDAsIDIsIDMsIDQsIDUsIDYsIDcuDQo+ID4+ID4N Cj4gPj4gPiAgICAgICBUUklMTCBQcmlvcml0eSAgREVJICBEU0NQIEZpZWxkIChCaW5hcnkvZGVj aW1hbCkNCj4gPj4gPiAgICAgICAtLS0tLS0tLS0tLS0tLSAgLS0tICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+PiA+ICAgICAgICAgICAgICAgICAgIDAgICAwLzEgIDAwMTAwMCAv IDgNCj4gPj4gPiAgICAgICAgICAgICAgICAgICAxICAgMC8xICAwMDAwMDAgLyAwDQo+ID4+ID4g ICAgICAgICAgICAgICAgICAgMiAgIDAvMSAgMDEwMDAwIC8gMTYNCj4gPj4gPiAgICAgICAgICAg ICAgICAgICAzICAgMC8xICAwMTEwMDAgLyAyNA0KPiA+PiA+ICAgICAgICAgICAgICAgICAgIDQg ICAwLzEgIDEwMDAwMCAvIDMyDQo+ID4+ID4gICAgICAgICAgICAgICAgICAgNSAgIDAvMSAgMTAx MDAwIC8gNDANCj4gPj4gPiAgICAgICAgICAgICAgICAgICA2ICAgMC8xICAxMTAwMDAgLyA0OA0K PiA+PiA+ICAgICAgICAgICAgICAgICAgIDcgICAwLzEgIDExMTAwMCAvIDU2DQo+ID4+ID4NCj4g Pj4gPiBUaGlzIGFwcGVhciB0byBiZSBhbiBwcm9ibGVtYXRpYyBtYXBwaW5nLiBBdCBsZWFzdCBm b3IgcHJpbyAwIGFuZCAxLiBBcw0KPiA+PiA+IHByaW9yaXR5IDEgYXBwZWFycyB0byBiZSBpbnRl bmRlZCB0byBiZSBoaWdoZXIgdGhhbiBwcmlvcml0eSAwLCBpdCBpcw0KPiA+PiA+IGludGVyZXN0 aW5nIHRoYXQgaXQgaXMgbWFwcGVkIHRvIENTMSwgd2hpY2ggdG8gcXVvdGUNCj4gPj4gPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM3NjU3LzoNCj4gPj4gPg0KPiA+PiA+IENT MSAoJzAwMTAwMCcpIHdhcyBzdWJzZXF1ZW50bHkgZGVzaWduYXRlZCBhcyB0aGUgcmVjb21tZW5k ZWQNCj4gPj4gPiAgICAgICBjb2RlcG9pbnQgZm9yIHRoZSBMb3dlciBFZmZvcnQgKExFKSBQSEIg W1JGQzM2NjJdLg0KPiA+PiA+DQo+ID4+ID4gU28gd2hhdCBpcyBwcm9wb3NlZCBjYW4gaW4gYSBu ZXR3b3JrIHVzaW5nIGRlZmF1bHQgbWFwcGluZywgcmVzdWx0IGluDQo+IHRoYXQNCj4gPj4geW91 DQo+ID4+ID4gZ2V0IHByaW9yaXR5IDAgdG8gYmUgbG93ZXIgcHJpb3JpdHkgdGhhbiAxLiBQbHVz IHRoYXQgaW4gc29tZSBuZXR3b3JrcyB0aGlzDQo+IGNhbg0KPiA+PiA+IGFsc28gcmVzdWx0cyBp biBzdHJhbmdlIHJlbWFwcGluZyB0aGF0IHJlc3VsdHMgaW4gYSBkaWZmZXJlbnQgUEhCIGZvciBD UzENCj4gPj4gdGhhbi4NCj4gPj4NCj4gPj4gVGhlIGludGVudCBpbiB0aGUgZHJhZnQgaXMgdG8g cmVmbGVjdCB0aGUgZGVmYXVsdCByZWxhdGl2ZSBwcmlvcml0eSBvZg0KPiA+PiB0aGUgZGlmZmVy ZW50IHByaW9yaXR5IGNvZGUgcG9pbnRzIGluIElFRUUgU3RkIDgwMi4xUSB3aGVyZSBwcmlvcml0 eSAxDQo+ID4+IGlzIGxvd2VyIHRoYW4gcHJpb3JpdHkgMC4gQXQgYSBxdWljayBsb29rLCBpdCBh cHBlYXJzIHRvIG1lIHRoYXQgUkZDDQo+ID4+IDI0NzQgcmVxdWlyZXMgdGhhdCAweDAwMTAwMCBi ZSBoYW5kbGVkIGFzIGJlaW5nIG9mIGEgcHJpb3JpdHkgbm90DQo+ID4+IGxvd2VyIHRoYW4gdGhl IHByaW9yaXR5IHdpdGggd2hpY2ggMHgwMDAwMDAgaXMgaGFuZGxlZC4gWWV0IFJGQyAzNjYyLA0K PiA+PiB3aGljaCB5b3UgcG9pbnQgdG8sIHNlZW1zIHRvIHN1Z2dlc3QgdXNpbmcgMHgwMDEwMDAg YXMgYSBsb3dlcg0KPiA+PiBwcmlvcml0eSBjb2RlIHBvaW50IHRoYW4gMHgwMDAwMDAuIEdpdmVu IHRoYXQgMzY2MiBub3Qgb25seSBkb2VzIG5vdA0KPiA+PiB1cGRhdGUgMjQ3NCBidXQgaXMgb25s eSBJbmZvcm1hdGlvbmFsIHdoaWxlIDI0NzQgaXMgU3RhbmRhcmRzIFRyYWNrLCBJDQo+ID4+IHdv dWxkIHNheSB0aGF0IDI0NzQgZG9taW5hdGVzIGFuZCB0aGF0IHRoaXMgZHJhZnQgbWFrZXMgdGhl IGJlc3QNCj4gPj4gYXNzdW1wdGlvbnMgaXQgY2FuIGFib3V0IGRlZmF1bHQgYmVoYXZpb3IuLi4N Cj4gPj4NCj4gPj4gPiBNVFUgYW5kIEZyYWdtZW50YXRpb24NCj4gPj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4gPg0KPiA+PiA+IEkgdGhpbmsgdGhlcmUgYXJlIHR3byBtYWluIGlzc3Vl IGhlcmUuIFRoZSBmaXJzdCBvbmUgaXMgTVRVRCBkaXNjb3ZlcnkNCj4gPj4gPiBvZiB0aGUgYWN0 dWFsIElQIHBhdGggTVRVIGJldHdlZW4gdGhlIHBvcnRzLiBUaGF0IHdpbGwgYmUgbmVlZGVkIHRv DQo+ID4+IHByZXZlbnQNCj4gPj4gPiBhIGxvdCBvZiB0cmFmZmljIGdvaW5nIGludG8gTVRVIGJs YWNrIGhvbGVzLiBFc3BlY2lhbGx5IGFzIFRSSUxMIHJlcXVyaWVzDQo+ID4+ID4gMTQ3MCBieXRl IHN1cHBvcnQgd2hpY2ggaXMgbGlrZXkgYWJvdmUgYSBsb3Qgb2YgcGF0aHMuDQo+ID4+DQo+ID4+ IFNlZW1zIGxpa2UgaXQgd291bGQgZGVwZW5kIG9uIHRoZSBlbnZpcm9ubWVudHMgd2hlcmUgVFJJ TEwgd2FzIHVzZWQuDQo+ID4+IEZvciBleGFtcGxlLCBJIGRvIG5vdCB0aGluayAxNDcwIHdvdWxk IGJlIGEgcHJvYmxlbSBpbiBtb3N0IERhdGENCj4gPj4gQ2VudGVyIG9yIEludGVybmV0IEV4Y2hh bmdlIHBvaW50IHVzZXMsIGZvciBleGFtcGxlLiBEYXRhIENlbnRlcnMNCj4gPj4gc29tZXRpbWVz IHN1cHBvcnQgOUsganVtYm8gZnJhbWVzIGFuZCB0aGUgbGlrZS4NCj4gPj4NCj4gPj4gSW4gZmFj dCwgaXQgaXMgcHJvYmFibHkgYmFkIHRvIGZvY3VzIHRvbyBtdWNoIG9uIDE0NzAgLS0gdGhhdCBp cyBhDQo+ID4+IHJlcXVpcmVkIG1pbmltdW0gdG8gYmUgc3VyZSB0aGF0IHJlYXNvbmFibGUgc2l6 ZSBsaW5rIHN0YXRlIFBEVXMgY2FuDQo+ID4+IGJlIHN1Y2Nlc3NmdWxseSBmbG9vZGVkIHRocm91 Z2ggdGhlIFRSSUxMIGNhbXB1cyBzbyB0aGF0IHJvdXRpbmcgd2lsbA0KPiA+PiB3b3JrLiBIb3dl dmVyLCBpdCB3b3VsZCBjb21tb25seSBiZSB0aGUgY2FzZSB0aGF0LCBmb3IgdGhlIFRSSUxMDQo+ ID4+IGNhbXB1cyB0byBiZSB1c2VmdWwgaW4gYSBwYXJ0aWN1bGFyIGNhc2UsIGxpbmtzIG5lZWQg dG8gYmUgYWJsZSB0bw0KPiA+PiBjYXJyeSB0aGUgZXhwZWN0ZWQgc2l6ZSBUUklMTCBEYXRhIHBh Y2tldHMuIEZvciBleGFtcGxlLCBpZiB0aGVyZSB3ZXJlDQo+ID4+IHR3byBwYXJ0cyBvZiBhIFRS SUxMIGNhbXB1cyBjb25uZWN0ZWQgYnkgb25lIG9yIGEgZmV3IFRSSUxMIG92ZXIgSVANCj4gPj4g bGlua3MgYW5kIHRoZSBlbmQgc3RhdGlvbnMgaW4gZWFjaCBwYXJ0IHdlcmUgYXNzdW1pbmcgdGhl eSBjb3VsZCB1c2UNCj4gPj4gMTUwMCBieXRlIEV0aGVybmV0IHBhY2tldHMsIHRoZW4gdGhlIFRS SUxMIG92ZXIgSVAgbGlua3Mgd291bGQgbmVlZCB0bw0KPiA+PiBzdXBwb3J0IGFuIE1UVSBiYXNl ZCBvbiAxNTAwICsgVFJJTEwgSGVhZGVyICsgSVAgYW5kIFRSSUxMIG92ZXIgSVANCj4gPj4gZW5j YXBzdWxhdGlvbi4gQW5kIG1vcmUgaWYgc2VjdXJpdHkgd2FzIGJlaW5nIHVzZWQgb3IgdGhlcmUg d2VyZSBhbnkNCj4gPj4gb3RoZXIgcmVhc29ucyBmb3IgYWRkaXRpb25hbCBoZWFkZXJzL2VuY2Fw c3VsYXRpb24uLi4NCj4gPj4NCj4gPj4gPiBTZWN0aW9uIDguNDoNCj4gPj4gPg0KPiA+PiA+ICAg IFBhdGggTVRVIGRpc2NvdmVyeSBbUkZDNDgyMV0gc2hvdWxkIGJlIHVzZWZ1bA0KPiA+PiA+ICAg IGluIGRldGVybWluaW5nIHRoZSBJUCBNVFUgYmV0d2VlbiBhIHBhaXIgb2YgUkJyaWRnZSBwb3J0 cyB3aXRoIElQDQo+ID4+ID4gICAgY29ubmVjdGl2aXR5Lg0KPiA+PiA+DQo+ID4+ID4gVGhlIGlz c3VlIHdpdGggUkZDNDgyMSBpcyB0aGF0IGl0IGhhcyByZXF1aXJlbWVudHMgb24gdGhlIHBhY2tl dGl6YXRpb24NCj4gPj4gbGF5ZXIuDQo+ID4+ID4gVHJpbGwgYXBwZWFycyB0byBoYXZlIHNldmVy YWwgY29tcG9uZW50cyB0aGF0IGFyZSB1c2VmdWwuIEhvd2V2ZXIsIGl0IHdpbGwNCj4gPj4gPiBy ZXF1aXJlIGEgc3BlY2lmaWNhdGlvbiBvZiB0aGUgcHJvY2VkdXJlIHRvIHJlc3VsdCBpbiBhIHVz ZWZ1bCB0b29sLg0KPiA+Pg0KPiA+PiBTZWUgYmVsb3cuDQo+ID4+DQo+ID4+ID4gU2VjdGlvbiA4 LjQ6DQo+ID4+ID4NCj4gPj4gPiAgICBUUklMTCBJUy1JUyBNVFUgUERVcywgYXMgc3BlY2lmaWVk IGluIFNlY3Rpb24gNSBvZiBbUkZDNjMyNV0gYW5kIGluDQo+ID4+ID4gICAgW1JGQzcxNzddLCBj YW4gYmUgdXNlZCB0byBvYnRhaW4gYWRkZWQgYXNzdXJhbmNlIG9mIHRoZSBNVFUgb2YgYQ0KPiA+ PiA+ICAgIGxpbmsuDQo+ID4+ID4NCj4gPj4gPiBZZXMsIHRoYXQgY2FuIGNvbmZpcm0gd29ya2lu ZyBNVFVzIHRoYXQgYXJlIGF0IDE0NzAgb3IgYWJvdmUsIGJ1dA0KPiBhcHBlYXJzDQo+ID4+ID4g cHJldmVudGVkIGZyb20gd29ya2luZyBiZWxvdyAxNDcwPw0KPiA+Pg0KPiA+PiBXaGlsZSB0aGVy ZSBpcyBhIG1pbmltdW0gc2l6ZSBmb3IgVFJJTEwgSVMtSVMgTVRVIFBEVXMsIGRldGVybWluZWQg YnkNCj4gPj4gaGVhZGVyIHNpemUsIGl0IGlzIHdlbGwgYmVsb3cgMTQ3MCwgcHJvYmFibHkgKGRl cGVuZGluZyBvbiB3aGV0aGVyDQo+ID4+IHNlY3VpcnR5IGlzIGluIHVzZSwgZXRjLikgYmVsb3cg MTUwIGJ5dGVzLg0KPiA+Pg0KPiA+PiA+IFRodXMsIGl0IGFwcGVhcnMgdGhhdCB0aGVyZSBpcyBh IGxhY2sgb2YgbWVjaGFuaXNtIGhlcmUgdG8gYWN0dWFsbHkgZ2V0IGENCj4gdmFsaWQNCj4gPj4g PiBhbmQgZnVuY3Rpb25hbCBNVFUgZnJvbSBUUklMTCBpbiB0aGUgY2FzZXMgd2hlcmUgdGhlIFBh dGggTVRVIGlzIGJlbG93DQo+ID4+IDE0NzAuIElmDQo+ID4+ID4gSSBhbSB3cm9uZyBnb29kLCBi dXQgSSB0aGluayB0aGlzIGlzIGFuIGltcG9ydGFudCBwaWVjZSBmb3IgaG93IHRvIGhhbmRsZQ0K PiA+PiB0aGUNCj4gPj4gPiBuZXh0IG1haW4gaXNzdWUuDQo+ID4+DQo+ID4+IEhvdyBhYm91dCBy ZWZlcmVuY2luZyBTZWN0aW9uIDMgb2YNCj4gPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtdHJpbGwtbXR1LW5lZ290aWF0aW9uLTA1DQo+ID4+IHdoaWNoIGlzIGN1cnJl bnRseSBpbiBJRVRGIExhc3QgQ2FsbD8gKFRoZSB3b3JkaW5nIG9mIHRoYXQgc2VjdGlvbiBpcw0K PiA+PiBwcm9iYWJseSBnb2luZyB0byBiZSBpbXByb3ZlZCBiYXNlZCBvbiBhbiBPUFMgcmV2aWV3 IGJ5IEJyaWFuDQo+ID4+IENhcnBlbnRlci4pDQo+ID4+DQo+ID4+ID4gVURQIGVuY2Fwc3VsYXRp b24gYW5kIElQIGZyYWdtZW50cy4NCj4gPj4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4+ID4gSSBzZWUgaXQgYXMgYSBiaWcgaXNzdWUgdGhhdCBVRFAgZW5jYXBzdWxh dGlvbiBpcyB0aGUgbmF0aXZlIG9uZSwgYW5kIHRoYXQNCj4gPj4gPiByZWxpZXMgb24gSVAgZnJh Z21lbnRhdGlvbiBkZXNwaXRlIHRoZSBuZWVkIGZvciByZWxpYWJsZSBmcmFnbWVudGF0aW9uLg0K PiA+PiBXaXRoDQo+ID4+ID4gdGhlIHNldHVwIG9mIGhhdmluZyB0byBzdXBwb3J0IDE0NzAgTVRV IG9uIFRSSUxMIGxldmVsIHNvbWUgcGFja2V0cyB3aWxsDQo+ID4+IGJlDQo+ID4+ID4gZnJhZ21l bnRlZCBpbiBtYW55IGVudmlyb25tZW50cy4gVGhhdCB3aWxsIGxlYWQgdG8gYSBsb3Qgb2YgbG9z c2VzLCBhbmQgYXMNCj4gPj4gPiBkaXNjdXNzZWQgYmVsb3cgYSB2ZXJ5IGJpZyBwcm9ibGVtIHdp dGggbWlkZGxlYm94ZXMuIFRoZSBtYWluIHByb2JsZW0NCj4gPj4gaGVyZSBpcw0KPiA+PiA+IHRo YXQgaWYgb25lIHRyaWVzIHRvIHJlbHkgb24gSVAgZnJhZ21lbnRzIG9uZSB3aWxsIGhhdmUgaXNz dWVzIHdpdGggcGFja2V0cw0KPiA+PiA+IGVuZGluZyB1cCBpbiBibGFjayBob2xlcy4gQW5kIGRp ZmZlcmVudCBwcm9ibGVtcyBkZXBlbmRpbmcgb24gSVB2NCBvcg0KPiA+PiBJUHY2Lg0KPiA+PiA+ IElQdjYgaXMgbGlsa2VseSB0aGUgbGVzc2VyIHByb2JsZW0gYXNzdW1pbmcgdGhhdCBvbmUgaGF2 ZSB3b3JraW5nDQo+IFBNVFVELg0KPiA+PiA+DQo+ID4+ID4gVGhlcmUgYXJlIHNldmVyYWwgd2F5 cyBvdXQgb2YgdGhpcy4NCj4gPj4gPg0KPiA+PiA+IDEuIERldGVjdCBpc3N1ZXMgYW5kIHVzZSBU Q1AgZW5jYXBzdWxhdGlvbiB3aXRoIGNvcnJlY3RseSBzZXQgTVNTIHRvIG5vdA0KPiA+PiBnZXQg SVANCj4gPj4gPiBmcmFnZW1lbnRzIDIuIERldGVybWluZSBNVFUgYW5kIGltcGxlbWVudCBhbiBm cmFnbWVudGF0aW9uDQo+ID4+IG1lY2hhbmlzbSBvbiB0b3Agb2YNCj4gPj4gPiBVRFAuDQo+ID4+ DQo+ID4+IFNvLCBJIGRvbid0IHNlZSB0aGF0IG11Y2ggcHJvYmxlbSB3aXRoIFVEUCBiZWluZyB0 aGUgZ2VuZXJhbCBkZWZhdWx0DQo+ID4+IGNvbnNpc3RlbnQgd2l0aCB0aGUgVFJJTEwgcGhpbG9z b3BoeSBvZiBkZWZhdWx0aW5nIHRvIG5lZWQgemVybyBvcg0KPiA+PiBtaW5pbWFsIGNvbmZpZ3Vy YXRpb24uIFRoZSBkZWZhdWx0IHNob3VsZCBiZSB0byB1c2UgbXVsdGljYXN0IEhlbGxvcw0KPiA+ PiBmb3IgZGlzY292ZXJ5IG9mIG5laWdoYm9ycyB3aGljaCBzdXJlIHBvaW50cyBhdCBVRFAgdG8g bWUuIEhhdmluZyB0bw0KPiA+PiB0cmF2ZXJzZSBhIE5BVCBzaG91bGQgYmUgYSByYXJlIGNhc2Uu IFNpbmNlLCBpbiB0aGUgTkFUIGNhc2UsIHlvdSBoYXZlDQo+ID4+IHRvIGNvbmZpZ3VyZSB0aGlu Z3MgcmVsYXRlZCB0byB0aGUgc3RhdGljIGJpbmRpbmcgYW5kIHRoZSBJUA0KPiA+PiBhZGRyZXNz KGVzKSBvZiBwZWVyKHMpIGFueXdheSB5b3UgY2FuIGFsc28gY29uZmlndXJlIHRvIHVzZSBhDQo+ ID4+IGRpZmZlcmVudCBlbmNhcHN1bGF0aW9uIHRoYW4gVURQLCBzdWNoIGFzIFRDUCwgYXQgdGhl IHNhbWUgdGltZS4gSQ0KPiA+PiBkb24ndCBzZWUgaXQgYXMgbXVjaCBvZiBhIHByb2JsZW0gaWYs IGJ5IGRlZmF1bHQsIFRSSUxMIHdvbid0IG9wZXJhdGUNCj4gPj4gdGhyb3VnaCBhIE5BVC4gSWYg eW91IGFyZSB1c2luZyBVRFAgYW5kIGl0IGZyYWdtZW50cyBhbmQgZnJhZ21lbnRzIGFyZQ0KPiA+ PiBkcm9wcGVkIGF0IGEgTkFULCBwcm9iYWJseSB5b3UgY2FuJ3QgZXhjaGFuZ2UgSGVsbG9zIHNv IHlvdSB3aWxsIG5vdA0KPiA+PiBmb3JtIGFuIGFkamFjZW5jeSBhbmQgYW55dGhpbmcgb24gdGhl IG90aGVyIHNpZGUgb2YgdGhlIE5BVCB3aWxsIG5vdA0KPiA+PiBiZSB2aXNpYmxlLg0KPiA+Pg0K PiA+PiA+IFplcm8gQ2hlY2tzdW06DQo+ID4+ID4gLS0tLS0tLS0tLS0tLS0NCj4gPj4gPg0KPiA+ PiA+IFNlY3Rpb24gNS40Og0KPiA+PiA+DQo+ID4+ID4gVURQIENoZWNrc3VtIC0gYXMgc3BlY2lm aWVkIGluIFtSRkMwNzY4XQ0KPiA+PiA+DQo+ID4+ID4gQ29uc2lkZXJpbmcgdGhlIGZhc3QgcGF0 aCBlbmNhcHN1bGF0aW9uIGRlc2lyZSwgSSBhbSBzdXJwcmlzZWQgdG8gbm90IHNlZQ0KPiA+PiBh bnkNCj4gPj4gPiBtZW50aW9uaW5nIG9mIHVzZSBvZiB6ZXJvIGNoZWNrc3VtIGhlcmUuIFJhaXNp bmcgdGhlIHplcm8gY2hlY2tzdW0gYW5kDQo+ID4+IGZvcndhcmQNCj4gPj4gPiByZWZlcmVuY2Ug d291bGQgYmUgZ29vZCBJIHRoaW5rLg0KPiA+PiA+DQo+ID4+ID4gQW5kIHRoZW4gU2VjdGlvbiA4 LjU6DQo+ID4+ID4NCj4gPj4gPiAgICBUaGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgdXNhZ2Ugb2Yg dGhlIHplcm8gVURQIENoZWNrc3VtIGluIGEgVURQDQo+ID4+ID4gICAgdHVubmVsIHByb3RvY29s IGFyZSBkZXRhaWxlZCBpbiBbUkZDNjkzNl0uIFRoZXNlIHJlcXVpcmVtZW50cyBhcHBseQ0KPiA+ PiA+ICAgIHRvIHRoZSBVRFAgYmFzZWQgVFJJTEwgb3ZlciBJUCBlbmNhcHN1bGF0aW9ucyBzcGVj aWZpZWQgaGVyZWluDQo+ID4+ID4gICAgKG5hdGl2ZSBhbmQgVlhMQU4pLCB3aGljaCBhcmUgYXBw bGljYXRpb25zIG9mIFVEUCB0dW5uZWwuDQo+ID4+ID4NCj4gPj4gPiBJZiB5b3UgYWN0dWFsbHkg aW50ZW5kZWQgdG8gYWxsb3cgemVybyBjaGVja3N1bSwgdGhlbiB5b3UgYWN0dWFsbHkgc2hvdWxk DQo+ID4+ID4gZG9jdW1lbnQgdGhhdCBUcmlsbCBmdWxmaWxscyB0aGUgcmVxdWlyZW1lbnRzIHRo YXQgdGhlIGFwcGxpY2FiaWxpdHkNCj4gc3RhdGVtZW50DQo+ID4+ID4gcmFpc2VzLiBJIGhhdmUg bm90IGFuYWx5emVkIGhvdyB3ZWxsIGl0IG1lZXRzIHRoZXNlIHJlcXVpcmVtZW50cy4NCj4gPj4g Pg0KPiA+PiA+IFBsZWFzZSByZXZpZXcgU2VjdGlvbiA2LjIgb2YgUkZDIDgwODYgZm9yIGV4YW1w bGUgaG93IHRoYXQgY2FuIGJlIGRvbmUuDQo+ID4+DQo+ID4+IE9LLiBXZSdsbCBsb29rIGludG8g aXQuDQo+ID4+DQo+ID4+ID4gVENQIEVuY2Fwc3VsYXRpb24gaXNzdWUNCj4gPj4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiA+DQo+ID4+ID4gU2VjdGlvbiA1LjY6DQo+ID4+ID4NCj4g Pj4gPiBUaGUgVENQIGVuY2Fwc3VsYXRpb24gYXBwZWFyIHRvIGJlIG1pc3NpbmcgYW4gZGVsaW1p dGVyIGZvcm1hdCBhbGxvd2luZw0KPiA+PiBlYWNoDQo+ID4+ID4gaW5kaXZpZHVhbCBUUklMTCBw YWNrZXQvcGF5bG9hZCB0byBiZSByZWFkIG91dCBvZiB0aGUgVENQJ3MgYnl0ZSBzdHJlYW0uDQo+ IEluDQo+ID4+ID4gb3RoZXIgd29yZHMsIGEgbm9ybWFsIGltcGxlbWVudGF0aW9uIGhhcyBubyB3 YXkgb2YgZW5zdXJpbmcgdGhhdCB0aGUNCj4gVENQDQo+ID4+ID4gcGF5bG9hZCBzdGFydHMgd2l0 aCB0aGUgc3RhcnQgb2YgYSBuZXcgVFJJTEwgcGF5bG9hZC4gTXVsdGlwbGUgc21hbGwgVFJJTEwN Cj4gPj4gPiBwYXlsb2FkcyBtYXkgYmUgaW5jbHVkZWQgaW4gdGhlIHNhbWUgVENQIHBheWxvYWQs IGFuZCBhbHNvIG9ubHkgcGFydHMNCj4gYXMNCj4gPj4gVENQIGlzDQo+ID4+ID4gb25lIHdheSBv ZiBkZWFsaW5nIHdpdGggVFJJTEwgcGFja2V0cyB0aGF0IGFyZSBsYXJnZXIgdGhhbiB0aGUNCj4g Pj4gSVArRW5jYXBzdWxhdGlvbg0KPiA+PiA+IE1UVSB0aGF0IGFjdHVhbGx5IHdpbGwgd29yay4N Cj4gPj4gPg0KPiA+PiA+IFRoaXMgY29tbWVudCBpcyBiYXNlZCBvbiB0aGF0IHRoZXJlIGFwcGVh ciB0byBiZSBubyBsZW5ndGggZmllbGRzDQo+IGluY2x1ZGVkDQo+ID4+IGluDQo+ID4+ID4gdGhl IFRSSUxMIGhlYWRlci4gVGhlIG1vc3Qgc3RyYWlnaHQgZm9yd2FyZCBkZWxpbWl0ZXIgaXMgYSAy LWJ5dGUgbGVuZ3RoDQo+ID4+IGZpZWxkDQo+ID4+ID4gZm9yIHRoZSBUUklMTCBwYXlsb2FkIHRv IGJlIGVuY2Fwc3VsYXRlZC4NCj4gPj4NCj4gPj4gUmlnaHQuIEl0IG1pZ2h0IGFsc28gYmUgdXNl ZnVsIHRvIGluY2x1ZGUgc29tZSBzb3J0IG9mIGNoZWNrIGZpZWxkLCBhcw0KPiA+PiBpcyBkb25l IGluIEJHUCwgdG8gZGV0ZWN0IGlmIHlvdSBhcmUgb3V0IG9mIHN5bmMgaW4gcGFyc2luZyB0aGUg VENQDQo+ID4+IHN0cmVhbS4NCj4gPj4NCj4gPj4gQW5vdGhlciBwb2ludCBpcyB0aGF0LCB3aGls ZSB3aXRoIFVEUCBpdCBzZWVtcyBmaW5lIHRvIHNlbmQgcGFja2V0cw0KPiA+PiB3aXRoIGFzc29y dGVkIFFvUywgeW91IGRvbid0IHdhbnQgdG8gZW5jb3VyYWdlIHJlLW9yZGVyaW5nIG9mIFRDUA0K PiA+PiBwYWNrZXRzIGluIGEgc3RyZWFtLiBTbyBpZiBUQ1AgZW5jYXBzdWxhdGlvbiBpcyBiZWlu ZyB1c2VkLCB5b3Ugd2FudA0KPiA+PiB0byB1c2UgdGhlIHNhbWUgRFNDUCB2YWx1ZSBmb3IgdGhl IHBhY2tldHMgaW4gYSBwYXJ0aWN1bGFyIFRDUCBzdHJlYW0uDQo+ID4+IFNvLCBnZW5lcmFsbHks IHlvdSBuZWVkIHRvIGhhdmUgYSBUQ1AgY29ubmVjdGlvbiBwZXIgcHJpb3JpdHkgaGFuZGxpbmcN Cj4gPj4gY2F0ZWdvcnkuIE1hcHBpbmcgdGhlIDggcHJpb3JpdHkgbGV2ZWxzIGludG8gYSBzbWFs bGVyIG51bWJlciBvZg0KPiA+PiBoYW5kbGluZyBjYXRlZ29yaWVzIGlzIGEgbm9ybWFsIHRoaW5n IHRvIGRvIHNvIHlvdSBjZXJ0YWlubHkgZG9uJ3QNCj4gPj4gbmVjZXNzYXJpbHkgbmVlZCA4IFRD UCBjb25uZWN0aW9ucy4gQWRkaW5nIG1hdGVyaWFsIG9uIHRoaXMgc2hvdWxkIG5vdA0KPiA+PiBi ZSB0b28gaGFyZC4NCj4gPj4NCj4gPj4gPiBTZWN0aW9uIDUuNjoNCj4gPj4gPg0KPiA+PiA+IFRD UCBlbmRwb2ludCByZXF1aXJlbWVudHMuIEkgZG8gd29uZGVyIGlmIGFuIGFwcGxpY2F0aW9uIGxp a2UgVFJJTEwgYWN0dWFsDQo+ID4+ID4gd291bGQgbmVlZCB0byBkaXNjdXNzIHBlcmZvcm1hbmNl IGltcGFjdGluZyBpbXBsZW1lbnRhdGlvbiBjaG9pY2VzIG9yDQo+ID4+ID4gbGltaXRhdGlvbnMu IEZvciBleGFtcGxlIHVzZSBvZiBOQUdMRSwgdGhlIHJlcXVpcmVtZW50cyBvbiBidWZmZXIgc2l6 ZXMNCj4gaW4NCj4gPj4gPiByZWxhdGlvbiB0byBCYW5kd2lkdGggZGVsYXkgcHJvZHVjdHMsIGFz IGJ1ZmZlciBtZW1vcnkgaW4gYSBSQnJpZGdlIHdpbGwNCj4gPj4gaW1wYWN0DQo+ID4+ID4gcGVy Zm9ybWFuY2UuDQo+ID4+DQo+ID4+IFdlbGwsIEknbSBub3Qgc3VyZSBob3cgZGVlcGx5IHRoaXMg ZG9jdW1lbnQgc2hvdWxkIGdldCBpbnRvIHN1Y2gNCj4gPj4gcGVyZm9ybWFuY2UgaXNzdWVzLiBX aGF0IGFib3V0IGp1c3Qgc2F5aW5nIHNvbWV0aGluZyBhYm91dA0KPiA+PiBjb25zaWRlcmF0aW9u IGJlaW5nIGdpdmVuIHRvIHR1bmluZyBUQ1AgZm9yIHBlcmZvcm1hbmNlIGFuZCBwb2ludGluZw0K PiA+PiB0byBvbmUgb3IgYSBmZXcgb3RoZXIgUkZDcyB0aGF0IHRhbGsgYWJvdXQgdGhpcz8NCj4g Pj4NCj4gPj4gPiBDb25nZXN0aW9uIENvbnRyb2wNCj4gPj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4gPiBGaXJzdCB0aGFua3MgZm9yIHRoZSBlZmZvcnQgaGVyZS4NCj4gPj4NCj4gPj4gWW91 J3JlIHdlbGNvbWUuDQo+ID4+DQo+ID4+ID4gOC4xLjIgSW4gT3RoZXIgRW52aXJvbm1lbnRzDQo+ ID4+ID4NCj4gPj4gPiAgICBXaGVyZSBVRFAgYmFzZWQgZW5jYXBzdWxhdGlvbiBoZWFkZXJzIGFy ZSB1c2VkIGluIFRSSUxMIG92ZXIgSVAgaW4NCj4gPj4gPiAgICBlbnZpcm9ubWVudHMgb3RoZXIg dGhhbiB0aG9zZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA4LjEuMSwgc3BlY2lmaWMNCj4gPj4gPiAg ICBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtcyBhcmUgY29tbW9ubHkgbmVlZGVkLiAgSG93 ZXZlciwgaWYgdGhlDQo+ID4+ID4gICAgdHJhZmZpYyBiZWluZyBjYXJyaWVkIGJ5IHRoZSBUUklM TCBvdmVyIElQIGxpbmsgaXMgYWxyZWFkeSBjb25nZXN0aW9uDQo+ID4+ID4gICAgY29udHJvbGxl ZCBhbmQgdGhlIHNpemUgYW5kIHZvbGF0aWxpdHkgb2YgdGhlIFRSSUxMIElTLUlTIGxpbmsgc3Rh dGUNCj4gPj4gPiAgICBkYXRhYmFzZSBpcyBsaW1pdGVkLCB0aGVuIHNwZWNpZmljIGNvbmdlc3Rp b24gY29udHJvbCBtYXkgbm90IGJlDQo+ID4+ID4gICAgbmVlZGVkLiBTZWUgW1JGQzgwODVdIFNl Y3Rpb24gMy4xLjExIGZvciBmdXJ0aGVyIGd1aWRhbmNlLg0KPiA+PiA+DQo+ID4+ID4gVGhpcyBp cyBjb3JyZWN0LCBob3dldmVyIG15IHF1ZXN0aW9uIGlzIGlmIHRoZSBSQnJpZGdlcyBoYXZlIGFu eSB3YXkgb2YNCj4gPj4ga25vd2luZw0KPiA+PiA+IHdoaWNoIHRyYWZmaWMgaXMgYWN0dWFsbHkg Y29uZ2VzdGlvbiBjb250cm9sbGVkLCBjb25zaWRlcmluZyB0aGF0IFRSSUxMDQo+ID4+IHByb3Zp ZGVzDQo+ID4+ID4gYW4gbGF5ZXIgMiBhYnN0cmFjdGlvbi4gSSB3b25kZXIgaWYgdGhlcmUgc2hv dWxkIGJlIGFueSB0eXBlIG9mIHdoaXRlIGxpc3Qgb2YNCj4gPj4gPiB0aGUgdHlwZXMgb2YgbGF5 ZXIgMiBwYXlsb2FkcyB0aGF0IGNhbiBiZSBhc3N1bWVkIHRvIGJlIGNvbmdlc3Rpb24NCj4gPj4g Y29udHJvbGxlZCwNCj4gPj4gPiBhbmQgdGh1cyBva2F5IHRvIGZvcndhcmQgb3ZlciBJUCBwYXRo cz8gSSBhbSB3b3JyaWVkIHRoYXQgd2l0aG91dCBhbnkNCj4gPj4gPiByZWNvbW1lbmRhdGlvbiB0 byBwcmV2ZW50IHRyYWZmaWMgdGhhdCBpcyBub3QgY29udHJvbGxlZCB0byBiZSBmb3J3YXJkZWQs DQo+ID4+IGNhbg0KPiA+PiA+IGxlYWQgdG8gY29uZ2VzdGlvbiBpc3N1ZXMuDQo+ID4+ID4NCj4g Pj4gPiBUaGUgb3RoZXIgaXNzdWUgSSB0aGluayBtYXkgZXhpc3QgaXMgdGhlIGlzc3VlIHNlcmlh bCB1bmljYXN0IGVtdWxhdGlvbiBvZg0KPiA+PiA+IGJyb2FkY2FzdC9tdWx0aWNhc3QgY3JlYXRl cy4gQXMgdGhpcyBhbXBsaWZpZXMgdGhlIG91dGdvaW5nIHBhY2tldCByYXRlDQo+IHdpdGgNCj4g Pj4gPiBhIGZhY3RvciBvZiBob3cgbWFueSBhZGRyZXNzZXMgYXJlIGNvbmZpZ3VyZWQgZm9yIHNl cmlhbCB1bmljYXN0IHRoaXMgY2FuDQo+ID4+ID4gYmUgc2lnbmlmaWNhbnQgdHJhZmZpYyBleHBh bnNpb24uIFRodXMsIEkgdGhpbmsgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBhcmUNCj4gPj4g PiBuZWVkZWQgaGVyZSwgYW5kIG1heWJlIHJhdGUgbGltaXRpbmcgb2YgdGhlIGFtb3VudCBvZiB0 cmFmZmljIHRvIGJlDQo+ID4+IG11bHRpY2FzdGVkLg0KPiA+Pg0KPiA+PiBPSy4gV2UgY2FuIHRo aW5rIGFib3V0IHRob3NlIGlzc3Vlcy4NCj4gPj4NCj4gPj4gPiBGbG93IGFuZCBFQ01QDQo+ID4+ ID4gLS0tLS0tLS0tLS0tLQ0KPiA+PiA+DQo+ID4+ID4gU2VjdGlvbiA4LjM6DQo+ID4+ID4NCj4g Pj4gPiBGb3IgZXhhbXBsZSwgZm9yIFRSSUxMDQo+ID4+ID4gICAgRGF0YSwgdGhpcyBlbnRyb3B5 IGZpZWxkIGNvdWxkIGJlIGJhc2VkIG9uIHNvbWUgaGFzaCBvZiB0aGUNCj4gPj4gPiAgICBJbm5l ci5NYWNEQSwgSW5uZXIuTWFjU0EsIGFuZCBJbm5lci5WTEFOIG9yIElubmVyLkZHTC4NCj4gPj4g Pg0KPiA+PiA+IEkgd291bGQgYXBwcmVjaWF0ZSBjbGVhcmVyIHJlZmVyZW5jZXMgdG8gd2hhdCB0 aGVzZSBmaWVsZHMgYXJlLg0KPiA+Pg0KPiA+PiBJbiBhIFRSSUxMIERhdGEgcGFja2V0LCB0aGUg cGF5bG9hZCBhZnRlciB0aGUgVFJJTEwgSGVhZGVyIGxvb2tzIGxpa2UNCj4gPj4gYW4gRXRoZXJu ZXQgZnJhbWUgZXhjZXB0IHRoYXQgdGhlcmUgaXMgYWx3YXlzIGVpdGhlciBhIFZMQU4gdGFnIG9y LA0KPiA+PiBhbHRlcm5hdGl2ZWx5LCB3aGVyZSB0aGUgVkxBTiB0YWcgd291bGQgYmUsIGEgRmlu ZSBHcmFpbmVkIExhYmVsDQo+ID4+IFtSRkM3MTcyXS4gKFRoZSBwcmVjZWRpbmcgaXMgdGhlIHZp ZXcgaW4gdGhlIFRSSUxMIFJGQ3MsIGJ1dCB0aGVyZSBpcw0KPiA+PiBhbiBlcXVpdmFsZW50IGFu ZCBlcXVhbGx5IHZhbGlkIHZpZXcgaW4gd2hpY2ggYWxsIHRoZSBmaWVsZHMgdGhyb3VnaA0KPiA+ PiBhbmQgaW5jbHVkaW5nIHRoZSBWTEFOIG9yIEZHTCB0YWcgYXJlIHBhcnQgb2YgdGhlIFRSSUxM IEhlYWRlci4pIFRoZQ0KPiA+PiBUUklMTCBiYXNlIHByb3RvY29sIHNwZWNpZmljYXRpb24gZm9j dXNlcyBvbiBFdGhlcm5ldCBhcyBhIGxpbmsNCj4gPj4gdGVjaG5vbG9neSBiZXR3ZWVuIFRSSUxM IHN3aXRjaGVzLCBpbiB3aGljaCBjYXNlIHRoZXJlIHdpbGwgYmUgYSBsaW5rDQo+ID4+IGhlYWRl ciBpbmNsdWRpbmcgYW4gT3V0ZXIuTWFjREEgYW5kIE91dGVyLk1hY1NBIGZpZWxkcyBhbmQgcG9z c2libHkgYW4NCj4gPj4gT3V0ZXIuVkxBTiwgYWxsIGJlZm9yZSB0aGUgVFJJTEwgSGVhZGVyLiBT ZWUgRmlndXJlIDEgYW5kIEZpZ3VyZSAyIGluDQo+ID4+IFJGQyA3MTcyLg0KPiA+Pg0KPiA+PiBT b21lIG9mIHRoZSBhYm92ZSBjb3VsZCBiZSBhZGRlZCB0byB0aGUgZHJhZnQgZm9yIGNsYXJpdHku DQo+ID4+DQo+ID4+ID4gSWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGUgaWRlYSBo ZXJlIGlzIHRvIGxvb2sgaW50byB0aGUgaW5uZXINCj4gPj4gPiBsYXllciAyIGZyYW1lcywgYW5k IHVzZSB0aGUgZmxvdyBlcXVpdmFsZW50cyB0aGF0IGV4aXN0cyBvbiB0aGF0IGxldmVsIGFuZA0K PiA+PiA+IGhhc2ggdGhhdCBpbnRvIHZhbHVlIHRoYXQgbWFwcyB0aGUgZmxvd3Mgb250byB0aGUg c291cmNlIHBvcnQgcmFuZ2UuDQo+ID4+DQo+ID4+IFllcy4NCj4gPj4NCj4gPj4gPiBJIHRoaW5r IHRoaXMgdGV4dCBzaG91bGQgaW5jbHVkZSBhIHN1bW1hcnkgb2YgdGhlIHByaW5jaXBsZSBhbmQg ZW5zdXJlIHRvDQo+ID4+ID4gbm90ZSB0aGUgaW1wb3J0YW50IHJlcXVpcmVtZW50IHRoYXQgd2hh dCBpcyBjb25zaWRlcmVkIGZsb3dzIGluIHRoZQ0KPiBpbm5lcg0KPiA+PiA+IG11c3Qgbm90IHJl c3VsdCBpbiBiZWluZyBzdHJpcGVkIG92ZXIgbXVsdGlwbGUgc291cmNlIHBvcnRzIGFzIHRoaXMg bWF5DQo+IGxlYWQNCj4gPj4gdG8NCj4gPj4gPiByZW9yZGVyaW5nIGlzc3VlcyBkdWUgdG8gcGFj a2V0cyB0YWtpbmcgZGlmZmVyZW50IHBhdGhzLg0KPiA+Pg0KPiA+PiBXZWxsLCB3ZSBjYW4gYWRk IHNvbWUgdGV4dC4gQnV0IHdoZW4gd291bGQgdGhlIHJlbGF0aXZlIG9yZGVyaW5nDQo+ID4+IG1h dHRlciBmb3IgdHdvIFRSSUxMIERhdGEgcGFja2V0cyB3aGVyZSB0aGUgdHdvIGlubmVyIG5hdGl2 ZSBwYXlsb2Fkcw0KPiA+PiBoYXZlIGRpZmZlcmVudCB2YWx1ZXMgZm9yIGFueSBvbmUgb3IgbW9y ZSBvZiB0aGVzZSB0aHJlZSBmaWVsZHMNCj4gPj4gKElubmVyLk1hY0RBLCBJbm5lci5NYWNTQSwg YW5kIGlubmVyIFZMQU4vRkdMIHRhZykgPyBJZiBhbnkgb2YgdGhvc2UNCj4gPj4gZmllbGRzIGFy ZSBkaWZmZXJlbnQsIHlvdSBhcmUgdGFsa2luZyBhYm91dCBkaWZmZXJlbnQgc3RyZWFtcy4NCj4g Pj4NCj4gPj4gPiBOQVQgYW5kIFRSSUxMIG92ZXIgSVA6DQo+ID4+ID4gU2VjdGlvbiA4LjU6DQo+ ID4+ID4NCj4gPj4gPiBJZiBvbmUgbGlrZSB0byB1c2UgVFJJTEwgb3ZlciBJUCB0aHJvdWdoIGEg TkFULCB0aGVuIHRoZXJlIGFyZSBzb21lIHZlcnkNCj4gPj4gPiBpbXBvcnRhbnQgY29uc2lkZXJh dGlvbnMgdGhhdCBhcmUgbWlzc2luZy4gRmlyc3QgdGhlIG5lZWQgZm9yIHN0YXRpYw0KPiBiaW5k aW5nDQo+ID4+ID4gY29uZmlndXJhdGlvbnMgb3IgdGhlIG5lZWQgZm9yIGRldGVybWluaW5nIG9u ZXMgZXh0ZXJuYWwgYWRkcmVzcyhlcykgYW5kDQo+ID4+IGJlDQo+ID4+ID4gYWJsZSB0byBjb21t dW5pY2F0ZSB0aGF0IHRvIHRoZSBwZWVyIFJCcmlkZ2VzLCBhbmQgaW4gYWRkaXRpb24gZW5zdXJl DQo+IHRoYXQNCj4gPj4gb25lDQo+ID4+ID4gaGFzIGtlZXAtYWxpdmVzIHRvIHRoYXQgdGhlIE5B VCBiaW5kaW5nIG5ldmVyIHRpbWVzIG91dC4NCj4gPj4NCj4gPj4gSSB0aGluayB0aG9zZSBhcmUg Z29vZCBwb2ludHMuIFRoZXJlIGlzIGFuIGFkZGl0aW9uYWwgcHJvYmxlbSB0aGF0DQo+ID4+IFRS SUxMIEhlbGxvcyBkZXRlY3QgbmVpZ2hib3JzIHdpdGggd2hpY2ggdGhleSBoYXZlIDItd2F5IGNv bm5lY3Rpdml0eQ0KPiA+PiBieSBpbmRpY2F0aW5nLCBpbnNpZGUgdGhlIEhlbGxvcyB0aGF0IGFy ZSBzZW50LCBmcm9tIHdoYXQgbmVpZ2hib3JzDQo+ID4+IEhlbGxvcyBoYXZlIGJlZW4gcmVjZWl2 ZWQgb24gdGhhdCBwb3J0LiBJZiBhIE5BVCBpcyBpbnZvbHZlZCwgdGhlc2UNCj4gPj4gbmVpZ2hi b3IgYWRkcmVzc2VzIGluc2lkZSBIZWxsb3MgbmVlZCB0byBiZSBtYXBwZWQuDQo+ID4+DQo+ID4+ ID4gTmV4dCBpcyB0aGUgaXNzdWUgdGhhdCB0aGVyZSBpcyBhbG1vc3QgemVybyBjaGFuY2Ugb2Yg Z2V0dGluZyBhIElQL1VEUA0KPiA+PiA+IGVuY2Fwc3VsYXRpb24gVFJJTEwgcGF5bG9hZCB0aHJv dWdoIHRoZSBOQVQgaWYgaXQgcmVzdWx0cyBpbiBJUA0KPiA+PiBmcmFnbWVudGF0aW9uLA0KPiA+ PiA+IGFzIE5BVHMgZG9uJ3QgZG8gZGVmcmFnbWVudCBhbmQgcmVmcmFnbWVudGVkIG9uIHRoZSBp bnRlcm5hbCBzaWRlLCBhbmQNCj4gPj4gYW4gSVANCj4gPj4gPiBmcmFnbWVudCBsYWNrcyBVRFAg cG9ydCBhbmQgdGh1cyBjYW4ndCBiZSBtYXRjaGVkIHRvIGJpbmRpbmcuDQo+ID4+DQo+ID4+IFNv IHBlcmhhcHMgdGhlIHJlY29tbWVuZGF0aW9uIHNob3VsZCBiZSB0byBjb25maWd1cmUgdGhlIHBv cnQgdG8gdXNlDQo+ID4+IFRDUCBpZiB0aGVyZSB3aWxsIGJlIGZyYWdtZW50YXRpb24uDQo+ID4+ DQo+ID4+ID4gQWxzbyBpZiB5b3UgbGlrZSB0byBydW4gSVAvRVNQIHRocm91Z2ggYSBOQVQsIHRo ZW4geW91IG1vc3QgbGlrZWx5IG5lZWQgdGhlDQo+ID4+ID4gSVAvVURQL0VTUCBlbmNhcHN1bGF0 aW9uIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk0OCkuIE5vdGUNCj4gdGhhdA0K PiA+PiB0aGlzDQo+ID4+ID4gd2lsbCByZXN0cmljdCB0aGUgTVRVIGV2ZW4gZnVydGhlciBhbmQg dGh1cyBlbnN1cmUgdGhhdCB0aGUgMTQ3MA0KPiA+PiByZXF1aXJlbWVudA0KPiA+PiA+IGNhbm5v dCBiZSBmdWxmaWxsZWQgZXZlbiB3aXRob3V0IGFkZGl0aW9uYWwgdHVubmVscyBvdmVyIGFuIDE1 MDAgYnl0ZXMNCj4gTVRVDQo+ID4+ID4gRXRoZXJuZXQgaW5mcmFzdHJ1Y3R1cmUuDQo+ID4+ID4N Cj4gPj4gPiBJIHdvdWxkIG5vdGUgdGhhdCBhbHNvIGZpcmV3YWxscyBsaWtlbHkgaGF2ZSBpc3N1 ZXMgd2l0aCBJUCBmcmFnbWVudHMgZm9yDQo+IHRoZQ0KPiA+PiA+IHNhbWUgcmVhc29uLCB0aGV5 IHJlcXVpcmUgc2lnbmlmaWNhbnQgYW1vdW50IG9mIHN0YXRlIHRvIGJlIHZlcmlmaWVkIGlmDQo+ IHRoZXkNCj4gPj4gPiBzaG91bGQgYmUgbGV0IHRocm91Z2guDQo+ID4+ID4NCj4gPj4gPiBJbiBn ZW5lcmFsIEkgdGhpbmsgeW91IHNob3VsZCBjcmVhdGUgYSBjb25maWd1cmF0aW9uIHRoYXQgaGFz IGNoYW5jZSB0bw0KPiB3b3JrDQo+ID4+ID4gdGhyb3VnaCBtb3N0IG1pZGRsZWJveGVzLCBidXQg SSB0aGluayB5b3Ugc2hvdWxkIHJlcXVpcmUgc3RhdGljIGJpbmRpbmdzLg0KPiBJDQo+ID4+ID4g dGhpbmsgdGhhdCBjb25maWd1cmF0aW9uIGlzLCBhbmQgZG9uJ3QgbGF1Z2ggbm93LCBidXQNCj4g Pj4gSVAvVURQL0VTUC9UQ1AvVFJJTEwsDQo+ID4+ID4gb3RoZXJ3aXNlIHlvdSB3aWxsIG5vdCBi ZSBhYmxlIHRvIGhhdmUgYm90aCBzZWN1cml0eSBhbmQgcmVsaWFibGUNCj4gPj4gZnJhZ21lbnRh dGlvbg0KPiA+PiA+IG9mIFRSSUxMIHBhY2tldHMuDQo+ID4+DQo+ID4+IE9LLiBUaGFua3MgYWdh aW4gZm9yIHRoaXMgcmV2aWV3LiBJdCBoYXMgcG9pbnRlZCBvdXQgYSBudW1iZXIgb2YNCj4gPj4g cHJvYmxlbXMgYW5kIGluIHRoaW5raW5nIGFib3V0IHRob3NlLCBJIGJlbGlldmUgYSBjb3VwbGUg b2YgZnVydGhlcg0KPiA+PiBwcm9ibGVtcyBoYXZlIGNvbWUgdG8gbWluZCB0aGF0IEkgbWVudGlv bmVkIGFib3ZlLiBXZSdsbCB3b3JrIG9uIGENCj4gPj4gcmV2aXNlZCBkcmFmdC4NCj4gPj4NCj4g Pj4gVGhhbmtzLA0KPiA+PiBEb25hbGQNCj4gPj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KPiA+PiAgRG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsxLTUwOC0zMzMtMjI3MCAoY2Vs bCkNCj4gPj4gIDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0ENCj4gPj4g IGQzZTNlM0BnbWFpbC5jb20NCj4gPj4NCj4gPj4gPiBDaGVlcnMNCj4gPj4gPg0KPiA+PiA+IE1h Z251cyBXZXN0ZXJsdW5kDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+IFRzdi1hcnQgbWFpbGluZyBsaXN0DQo+ID4+IFRzdi1h cnRAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 c3YtYXJ0DQo= From nobody Sat Jul 1 11:04:10 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752E1127342; Sat, 1 Jul 2017 11:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nNj-w13x68mL; Sat, 1 Jul 2017 11:03:57 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 888171201F8; Sat, 1 Jul 2017 11:03:57 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m84so39271311ita.0; Sat, 01 Jul 2017 11:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YPY4SuaFP+9Psn09VAzrOc9z7ISAZ0GTqP2XcK3eHKc=; b=QQvvMQno0aEgsR8P8W/qc0w9Bvt5yxKp2YQ63okbMtbo0TG40PdBaJGwGVVDMnhmei o5aj0T3DTOh3YSmnO9y8C5iOM8IH5V2j8eLXpwELH32nuLA0Mt0WDMjFfl9mskHFt8M9 wHqcuIzgNO80MqR7Snb2k8CK34i1Vyya20lBnvT8Qa+6Lf5xmUwzentQYE75v4RJFABZ fCuKWpusQQRg5bCAac5QQCOF1NSzHp+rJFkF2Nzlfdb/ULBuUkTqOWnKvYvVBH0jSqMy 3UgwZMcajg3ddFbPS9w/dikl46KpKpWzIS/NFxFA165E5/vC37NMlwCgujSq45N0zjww gTAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YPY4SuaFP+9Psn09VAzrOc9z7ISAZ0GTqP2XcK3eHKc=; b=CKElRv+89mhxLXsykn6vodblAo/nmFY4BoaG3OPPUO5XzyNdBmBgQVGsML57OKKKdN eQZzNn0RhRmu0y73uwQBalf5AzxH5jIKGvc8SSFqcgLQJay9cj0IqCw3J9LP6+S7JdIB 6jm2R/u5KW4OkJesqiK9AVSjs6hikQv+Eh+/WJSsrGvk7sp6etT86D63S1Ef8uaBDMk1 Y4Zs4tM4vRWcqPrrtjh2amqMS/Qsxz8eNtk1Q4kiDcmwGf4OAI4dJdzg95I8DmWIuxDI ZYCG2kXmeKnmzlzaIpOiqHMCXixyUeBIvpcmTIZx+LYlDh1VgmnXqXNfW8SdCXmrAZUJ dBLA== X-Gm-Message-State: AIVw112Cw6FkKya6PqJ/nQSLsDe2oe/nlt6r03GtXTLMQ491wyWqRiZD Es54B9jMj+4UfF9AxV+PWbIuEqiRWA== X-Received: by 10.36.3.11 with SMTP id e11mr1848026ite.79.1498932236595; Sat, 01 Jul 2017 11:03:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Sat, 1 Jul 2017 11:03:41 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Sat, 1 Jul 2017 14:03:41 -0400 Message-ID: To: "Black, David" Cc: Magnus Westerlund , "tsv-art@ietf.org" , "draft-ietf-trill-over-ip.all@ietf.org" , IETF Discussion , "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [trill] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 18:04:00 -0000 On Sat, Jul 1, 2017 at 10:53 AM, Black, David wrote: > Also, as noted earlier in this discussion, RFC 7657 explicitly discourage= s use of multiple DSCPs in a single TCP connection. That needs to be refle= cted in the TCP encapsulation text in the trill-over-ip draft - in particul= ar, the current text in Section 4.3 on mapping to DSCPs from TRILL priority= and DEI does not appear to be consistent with RFC 7657 for TCP-based encap= sulation. I'm surprised it only "discourages" rather than "prohibits"... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thanks, --David > >> -----Original Message----- >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >> Sent: Friday, June 30, 2017 9:43 PM >> To: Black, David >> Cc: Magnus Westerlund ; tsv- >> art@ietf.org; draft-ietf-trill-over-ip.all@ietf.org; IETF Discussion >> ; trill@ietf.org >> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-1= 0 - ECN & >> DSCP considerations >> >> Hi David, >> >> On Mon, Jun 26, 2017 at 3:04 PM, Black, David >> wrote: >> > Adding some comments on ECN and DSCP ... >> > >> >> > Section 4.3: >> >> > >> >> > TRILL over IP implementations MUST support setting the DSCP valu= e in >> >> > the outer IP Header of TRILL packets they send by mapping the TR= ILL >> >> > priority and DEI to the DSCP. They MAY support, for a TRILL Data >> >> > packet where the native frame payload is an IP packet, mapping t= he >> >> > DSCP in this inner IP packet to the outer IP Header with the def= ault >> >> > for that mapping being to copy the DSCP without change. >> >> > >> >> > I think it is fine to require that implementations are capable of s= etting >> >> > DSCP values on the outer IP header. However, I fail to see any disc= ussion of >> >> > the potential issues with actually setting the DSCP values. It is o= ne thing to >> >> > do this in an IP back bone use case where one can know and have con= trol >> >> > over the PHB that the DSCP values maps to. But otherwise, over gene= ral internet the >> >> > behavior is not that predictable. One can easily be subject to poli= cers or >> >> > remapping. Also as the actual DSCP code point usage is domain speci= fic this is >> >> > difficult. Priority reversal is likely the least of the problems th= at this can >> >> > run into over general Internet. >> >> >> >> It sounds like appropriate discussion and warnings about these issues >> >> would resolve the above comment. >> > >> > For ECN, see RFC 6040 and draft-ietf-tsvwg-rfc6040update-shim. In par= ticular, >> > copying the inner ECN codepoint to the outer IP header encapsulation w= ithout >> > requiring decapsulation processing as specified in RFC 6040 or the 604= 0update-shim >> > draft can lose congestion indications from the network and hence is wr= ong >> > (it's also wrong wrt RFC 3168, but RFC 6040 and the 6040update-shim dr= afts are >> > better and more current references). >> >> That's a good point. >> >> > For DSCPs, start with RFC 2983 - thinking about the validity (or likel= y validity) >> > of the outer DSCP at the decapsulator may help in choosing whether to >> > recommend a uniform model (e.g., copy DSCP out at ingress, copy back i= n at >> > egress) or a pipe model (e.g., do something reasonable for outer DSCP = at >> > ingress, ignore it on egress) as the implementation default. >> >> I believe the default behavior in the current draft is the best >> default. That sets DSCP based on the same TRILL Header indicia that >> controls default QoS on non-IP links. >> >> > -- DSCP mapping to/from TRILL/Ethernet priorities >> > >> >> The intent in the draft is to reflect the default relative priority o= f >> >> the different priority code points in IEEE Std 802.1Q where priority = 1 >> >> is lower than priority 0. At a quick look, it appears to me that RFC >> >> 2474 requires that 0x001000 be handled as being of a priority not >> >> lower than the priority with which 0x000000 is handled. Yet RFC 3662, >> >> which you point to, seems to suggest using 0x001000 as a lower >> >> priority code point than 0x000000. Given that 3662 not only does not >> >> update 2474 but is only Informational while 2474 is Standards Track, = I >> >> would say that 2474 dominates and that this draft makes the best >> >> assumptions it can about default behavior... >> > >> > Well ... that's a discussion about text in RFCs that are well over a d= ecade >> > old, and in an area (less-than-best-effort service) where the aspirati= ons >> > of at least RFC 3662 weren't realized ... but that RFC is not safe to = ignore, >> > either. >> > >> > In practice, the specification of CS1 for less-than-best-effort servic= e has >> > been promulgated by RFC 4594 rather than RFC 3662, and RFC 4594 has >> > had significant "running code" impact on network design and operation. >> > >> > As Magnus mentioned RFC7657, I strongly suggest starting from the >> > RFC 7657 discussion of this topic in order to figure out what to do. = I'm >> > not sure what to recommend, but I do think that starting from >> > RFC 7657 (rather than RFC 2474 and RFC 3662) is the better approach. >> >> OK. >> >> > FWIW, the TSVWG WG is in the process of figuring out which DSCP >> > to recommend for less-than-best-effort-service in place of CS1 - that'= s >> > likely to be an active topic of discussion in Prague. >> >> I'll try to attend that session. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> > Thanks, --David >> > >> >> -----Original Message----- >> >> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Donald >> >> Eastlake >> >> Sent: Sunday, June 25, 2017 8:07 PM >> >> To: Magnus Westerlund >> >> Cc: tsv-art@ietf.org; draft-ietf-trill-over-ip.all@ietf.org; IETF Dis= cussion >> >> ; trill@ietf.org >> >> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-i= p-10 >> >> >> >> Hi Magnus, >> >> >> >> Thanks for the extensive review. See my responses below. >> >> >> >> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund >> >> wrote: >> >> > >> >> > Reviewer: Magnus Westerlund >> >> > Review result: Not Ready >> >> > >> >> > Early review of draft-ietf-trill-over-ip-10 >> >> > Reviewer: Magnus Westerlund >> >> > Review result: Not Ready >> >> > >> >> > TSV-ART review comments: >> >> > >> >> > I have set this to not ready as there are several issues, some sign= ificant >> that >> >> > could affect the protocol realization significantly. Some may be me >> missing >> >> > things in TRILL, I was not that familiar with it before this review= and I have >> >> > only tried looking up things, not reading the whole earlier specifi= cations. >> So >> >> > don't hesitate to push back and provide pointers to things that can >> resolve >> >> > issues. The authors and the WG clearly have thought about a lot of = issues >> >> and >> >> > dealt with much already. >> >> >> >> OK. Hopefully we can resolve these one way or the other. >> >> >> >> > Diffserv usage >> >> > -------------- >> >> > >> >> > Section 4.3: >> >> > >> >> > TRILL over IP implementations MUST support setting the DSCP valu= e in >> >> > the outer IP Header of TRILL packets they send by mapping the TR= ILL >> >> > priority and DEI to the DSCP. They MAY support, for a TRILL Data >> >> > packet where the native frame payload is an IP packet, mapping t= he >> >> > DSCP in this inner IP packet to the outer IP Header with the def= ault >> >> > for that mapping being to copy the DSCP without change. >> >> > >> >> > I think it is fine to require that implementations are capable of = setting >> >> > DSCP values on the outer IP header. However, I fail to see any disc= ussion >> of >> >> > the potential issues with actually setting the DSCP values. It is o= ne thing >> to >> >> > do this in an IP back bone use case where one can know and have con= trol >> >> over >> >> > the PHB that the DSCP values maps to. But otherwise, over general >> >> internet the >> >> > behavior is not that predictable. One can easily be subject to poli= cers or >> >> > remapping. Also as the actual DSCP code point usage is domain speci= fic >> this >> >> is >> >> > difficult. Priority reversal is likely the least of the problems th= at this can >> >> > run into over general Internet. >> >> >> >> It sounds like appropriate discussion and warnings about these issues >> >> would resolve the above comment. >> >> >> >> > Section 4.3: >> >> > >> >> > The default TRILL priority and DEI to DSCP mapping, which may be >> >> > configured per TRILL over IP port, is an follows. Note that the = DEI >> >> > value does not affect the default mapping and, to provide a >> >> > potentially lower priority service than the default priority 0, >> >> > priority 1 is considered lower priority than 0. So the priority >> >> > sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7= . >> >> > >> >> > TRILL Priority DEI DSCP Field (Binary/decimal) >> >> > -------------- --- ----------------------------- >> >> > 0 0/1 001000 / 8 >> >> > 1 0/1 000000 / 0 >> >> > 2 0/1 010000 / 16 >> >> > 3 0/1 011000 / 24 >> >> > 4 0/1 100000 / 32 >> >> > 5 0/1 101000 / 40 >> >> > 6 0/1 110000 / 48 >> >> > 7 0/1 111000 / 56 >> >> > >> >> > This appear to be an problematic mapping. At least for prio 0 and 1= . As >> >> > priority 1 appears to be intended to be higher than priority 0, it = is >> >> > interesting that it is mapped to CS1, which to quote >> >> > https://datatracker.ietf.org/doc/rfc7657/: >> >> > >> >> > CS1 ('001000') was subsequently designated as the recommended >> >> > codepoint for the Lower Effort (LE) PHB [RFC3662]. >> >> > >> >> > So what is proposed can in a network using default mapping, result = in >> that >> >> you >> >> > get priority 0 to be lower priority than 1. Plus that in some netwo= rks this >> can >> >> > also results in strange remapping that results in a different PHB f= or CS1 >> >> than. >> >> >> >> The intent in the draft is to reflect the default relative priority o= f >> >> the different priority code points in IEEE Std 802.1Q where priority = 1 >> >> is lower than priority 0. At a quick look, it appears to me that RFC >> >> 2474 requires that 0x001000 be handled as being of a priority not >> >> lower than the priority with which 0x000000 is handled. Yet RFC 3662, >> >> which you point to, seems to suggest using 0x001000 as a lower >> >> priority code point than 0x000000. Given that 3662 not only does not >> >> update 2474 but is only Informational while 2474 is Standards Track, = I >> >> would say that 2474 dominates and that this draft makes the best >> >> assumptions it can about default behavior... >> >> >> >> > MTU and Fragmentation >> >> > --------------------- >> >> > >> >> > I think there are two main issue here. The first one is MTUD discov= ery >> >> > of the actual IP path MTU between the ports. That will be needed to >> >> prevent >> >> > a lot of traffic going into MTU black holes. Especially as TRILL re= quries >> >> > 1470 byte support which is likey above a lot of paths. >> >> >> >> Seems like it would depend on the environments where TRILL was used. >> >> For example, I do not think 1470 would be a problem in most Data >> >> Center or Internet Exchange point uses, for example. Data Centers >> >> sometimes support 9K jumbo frames and the like. >> >> >> >> In fact, it is probably bad to focus too much on 1470 -- that is a >> >> required minimum to be sure that reasonable size link state PDUs can >> >> be successfully flooded through the TRILL campus so that routing will >> >> work. However, it would commonly be the case that, for the TRILL >> >> campus to be useful in a particular case, links need to be able to >> >> carry the expected size TRILL Data packets. For example, if there wer= e >> >> two parts of a TRILL campus connected by one or a few TRILL over IP >> >> links and the end stations in each part were assuming they could use >> >> 1500 byte Ethernet packets, then the TRILL over IP links would need t= o >> >> support an MTU based on 1500 + TRILL Header + IP and TRILL over IP >> >> encapsulation. And more if security was being used or there were any >> >> other reasons for additional headers/encapsulation... >> >> >> >> > Section 8.4: >> >> > >> >> > Path MTU discovery [RFC4821] should be useful >> >> > in determining the IP MTU between a pair of RBridge ports with I= P >> >> > connectivity. >> >> > >> >> > The issue with RFC4821 is that it has requirements on the packetiza= tion >> >> layer. >> >> > Trill appears to have several components that are useful. However, = it will >> >> > require a specification of the procedure to result in a useful tool= . >> >> >> >> See below. >> >> >> >> > Section 8.4: >> >> > >> >> > TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and= in >> >> > [RFC7177], can be used to obtain added assurance of the MTU of a >> >> > link. >> >> > >> >> > Yes, that can confirm working MTUs that are at 1470 or above, but >> appears >> >> > prevented from working below 1470? >> >> >> >> While there is a minimum size for TRILL IS-IS MTU PDUs, determined by >> >> header size, it is well below 1470, probably (depending on whether >> >> secuirty is in use, etc.) below 150 bytes. >> >> >> >> > Thus, it appears that there is a lack of mechanism here to actually= get a >> valid >> >> > and functional MTU from TRILL in the cases where the Path MTU is be= low >> >> 1470. If >> >> > I am wrong good, but I think this is an important piece for how to = handle >> >> the >> >> > next main issue. >> >> >> >> How about referencing Section 3 of >> >> https://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-05 >> >> which is currently in IETF Last Call? (The wording of that section is >> >> probably going to be improved based on an OPS review by Brian >> >> Carpenter.) >> >> >> >> > UDP encapsulation and IP fragments. >> >> ---------------------------------- >> >> > I see it as a big issue that UDP encapsulation is the native one, a= nd that >> >> > relies on IP fragmentation despite the need for reliable fragmentat= ion. >> >> With >> >> > the setup of having to support 1470 MTU on TRILL level some packets= will >> >> be >> >> > fragmented in many environments. That will lead to a lot of losses,= and as >> >> > discussed below a very big problem with middleboxes. The main probl= em >> >> here is >> >> > that if one tries to rely on IP fragments one will have issues with= packets >> >> > ending up in black holes. And different problems depending on IPv4 = or >> >> IPv6. >> >> > IPv6 is lilkely the lesser problem assuming that one have working >> PMTUD. >> >> > >> >> > There are several ways out of this. >> >> > >> >> > 1. Detect issues and use TCP encapsulation with correctly set MSS t= o not >> >> get IP >> >> > fragements 2. Determine MTU and implement an fragmentation >> >> mechanism on top of >> >> > UDP. >> >> >> >> So, I don't see that much problem with UDP being the general default >> >> consistent with the TRILL philosophy of defaulting to need zero or >> >> minimal configuration. The default should be to use multicast Hellos >> >> for discovery of neighbors which sure points at UDP to me. Having to >> >> traverse a NAT should be a rare case. Since, in the NAT case, you hav= e >> >> to configure things related to the static binding and the IP >> >> address(es) of peer(s) anyway you can also configure to use a >> >> different encapsulation than UDP, such as TCP, at the same time. I >> >> don't see it as much of a problem if, by default, TRILL won't operate >> >> through a NAT. If you are using UDP and it fragments and fragments ar= e >> >> dropped at a NAT, probably you can't exchange Hellos so you will not >> >> form an adjacency and anything on the other side of the NAT will not >> >> be visible. >> >> >> >> > Zero Checksum: >> >> > -------------- >> >> > >> >> > Section 5.4: >> >> > >> >> > UDP Checksum - as specified in [RFC0768] >> >> > >> >> > Considering the fast path encapsulation desire, I am surprised to n= ot see >> >> any >> >> > mentioning of use of zero checksum here. Raising the zero checksum = and >> >> forward >> >> > reference would be good I think. >> >> > >> >> > And then Section 8.5: >> >> > >> >> > The requirements for the usage of the zero UDP Checksum in a UDP >> >> > tunnel protocol are detailed in [RFC6936]. These requirements ap= ply >> >> > to the UDP based TRILL over IP encapsulations specified herein >> >> > (native and VXLAN), which are applications of UDP tunnel. >> >> > >> >> > If you actually intended to allow zero checksum, then you actually = should >> >> > document that Trill fulfills the requirements that the applicabilit= y >> statement >> >> > raises. I have not analyzed how well it meets these requirements. >> >> > >> >> > Please review Section 6.2 of RFC 8086 for example how that can be d= one. >> >> >> >> OK. We'll look into it. >> >> >> >> > TCP Encapsulation issue >> >> > ----------------------- >> >> > >> >> > Section 5.6: >> >> > >> >> > The TCP encapsulation appear to be missing an delimiter format allo= wing >> >> each >> >> > individual TRILL packet/payload to be read out of the TCP's byte st= ream. >> In >> >> > other words, a normal implementation has no way of ensuring that th= e >> TCP >> >> > payload starts with the start of a new TRILL payload. Multiple smal= l TRILL >> >> > payloads may be included in the same TCP payload, and also only par= ts >> as >> >> TCP is >> >> > one way of dealing with TRILL packets that are larger than the >> >> IP+Encapsulation >> >> > MTU that actually will work. >> >> > >> >> > This comment is based on that there appear to be no length fields >> included >> >> in >> >> > the TRILL header. The most straight forward delimiter is a 2-byte l= ength >> >> field >> >> > for the TRILL payload to be encapsulated. >> >> >> >> Right. It might also be useful to include some sort of check field, a= s >> >> is done in BGP, to detect if you are out of sync in parsing the TCP >> >> stream. >> >> >> >> Another point is that, while with UDP it seems fine to send packets >> >> with assorted QoS, you don't want to encourage re-ordering of TCP >> >> packets in a stream. So if TCP encapsulation is being used, you want >> >> to use the same DSCP value for the packets in a particular TCP stream= . >> >> So, generally, you need to have a TCP connection per priority handlin= g >> >> category. Mapping the 8 priority levels into a smaller number of >> >> handling categories is a normal thing to do so you certainly don't >> >> necessarily need 8 TCP connections. Adding material on this should no= t >> >> be too hard. >> >> >> >> > Section 5.6: >> >> > >> >> > TCP endpoint requirements. I do wonder if an application like TRILL= actual >> >> > would need to discuss performance impacting implementation choices = or >> >> > limitations. For example use of NAGLE, the requirements on buffer s= izes >> in >> >> > relation to Bandwidth delay products, as buffer memory in a RBridge= will >> >> impact >> >> > performance. >> >> >> >> Well, I'm not sure how deeply this document should get into such >> >> performance issues. What about just saying something about >> >> consideration being given to tuning TCP for performance and pointing >> >> to one or a few other RFCs that talk about this? >> >> >> >> > Congestion Control >> >> > ------------------ >> >> > First thanks for the effort here. >> >> >> >> You're welcome. >> >> >> >> > 8.1.2 In Other Environments >> >> > >> >> > Where UDP based encapsulation headers are used in TRILL over IP = in >> >> > environments other than those discussed in Section 8.1.1, specif= ic >> >> > congestion control mechanisms are commonly needed. However, if = the >> >> > traffic being carried by the TRILL over IP link is already conge= stion >> >> > controlled and the size and volatility of the TRILL IS-IS link s= tate >> >> > database is limited, then specific congestion control may not be >> >> > needed. See [RFC8085] Section 3.1.11 for further guidance. >> >> > >> >> > This is correct, however my question is if the RBridges have any wa= y of >> >> knowing >> >> > which traffic is actually congestion controlled, considering that T= RILL >> >> provides >> >> > an layer 2 abstraction. I wonder if there should be any type of whi= te list of >> >> > the types of layer 2 payloads that can be assumed to be congestion >> >> controlled, >> >> > and thus okay to forward over IP paths? I am worried that without a= ny >> >> > recommendation to prevent traffic that is not controlled to be forw= arded, >> >> can >> >> > lead to congestion issues. >> >> > >> >> > The other issue I think may exist is the issue serial unicast emula= tion of >> >> > broadcast/multicast creates. As this amplifies the outgoing packet = rate >> with >> >> > a factor of how many addresses are configured for serial unicast th= is can >> >> > be significant traffic expansion. Thus, I think additional consider= ations are >> >> > needed here, and maybe rate limiting of the amount of traffic to be >> >> multicasted. >> >> >> >> OK. We can think about those issues. >> >> >> >> > Flow and ECMP >> >> > ------------- >> >> > >> >> > Section 8.3: >> >> > >> >> > For example, for TRILL >> >> > Data, this entropy field could be based on some hash of the >> >> > Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. >> >> > >> >> > I would appreciate clearer references to what these fields are. >> >> >> >> In a TRILL Data packet, the payload after the TRILL Header looks like >> >> an Ethernet frame except that there is always either a VLAN tag or, >> >> alternatively, where the VLAN tag would be, a Fine Grained Label >> >> [RFC7172]. (The preceding is the view in the TRILL RFCs, but there is >> >> an equivalent and equally valid view in which all the fields through >> >> and including the VLAN or FGL tag are part of the TRILL Header.) The >> >> TRILL base protocol specification focuses on Ethernet as a link >> >> technology between TRILL switches, in which case there will be a link >> >> header including an Outer.MacDA and Outer.MacSA fields and possibly a= n >> >> Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in >> >> RFC 7172. >> >> >> >> Some of the above could be added to the draft for clarity. >> >> >> >> > If I understand this correctly, the idea here is to look into the i= nner >> >> > layer 2 frames, and use the flow equivalents that exists on that le= vel and >> >> > hash that into value that maps the flows onto the source port range= . >> >> >> >> Yes. >> >> >> >> > I think this text should include a summary of the principle and ens= ure to >> >> > note the important requirement that what is considered flows in the >> inner >> >> > must not result in being striped over multiple source ports as this= may >> lead >> >> to >> >> > reordering issues due to packets taking different paths. >> >> >> >> Well, we can add some text. But when would the relative ordering >> >> matter for two TRILL Data packets where the two inner native payloads >> >> have different values for any one or more of these three fields >> >> (Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those >> >> fields are different, you are talking about different streams. >> >> >> >> > NAT and TRILL over IP: >> >> > Section 8.5: >> >> > >> >> > If one like to use TRILL over IP through a NAT, then there are some= very >> >> > important considerations that are missing. First the need for stati= c >> binding >> >> > configurations or the need for determining ones external address(es= ) and >> >> be >> >> > able to communicate that to the peer RBridges, and in addition ensu= re >> that >> >> one >> >> > has keep-alives to that the NAT binding never times out. >> >> >> >> I think those are good points. There is an additional problem that >> >> TRILL Hellos detect neighbors with which they have 2-way connectivity >> >> by indicating, inside the Hellos that are sent, from what neighbors >> >> Hellos have been received on that port. If a NAT is involved, these >> >> neighbor addresses inside Hellos need to be mapped. >> >> >> >> > Next is the issue that there is almost zero chance of getting a IP/= UDP >> >> > encapsulation TRILL payload through the NAT if it results in IP >> >> fragmentation, >> >> > as NATs don't do defragment and refragmented on the internal side, = and >> >> an IP >> >> > fragment lacks UDP port and thus can't be matched to binding. >> >> >> >> So perhaps the recommendation should be to configure the port to use >> >> TCP if there will be fragmentation. >> >> >> >> > Also if you like to run IP/ESP through a NAT, then you most likely = need the >> >> > IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). Not= e >> that >> >> this >> >> > will restrict the MTU even further and thus ensure that the 1470 >> >> requirement >> >> > cannot be fulfilled even without additional tunnels over an 1500 by= tes >> MTU >> >> > Ethernet infrastructure. >> >> > >> >> > I would note that also firewalls likely have issues with IP fragmen= ts for >> the >> >> > same reason, they require significant amount of state to be verifie= d if >> they >> >> > should be let through. >> >> > >> >> > In general I think you should create a configuration that has chanc= e to >> work >> >> > through most middleboxes, but I think you should require static bin= dings. >> I >> >> > think that configuration is, and don't laugh now, but >> >> IP/UDP/ESP/TCP/TRILL, >> >> > otherwise you will not be able to have both security and reliable >> >> fragmentation >> >> > of TRILL packets. >> >> >> >> OK. Thanks again for this review. It has pointed out a number of >> >> problems and in thinking about those, I believe a couple of further >> >> problems have come to mind that I mentioned above. We'll work on a >> >> revised draft. >> >> >> >> Thanks, >> >> Donald >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> >> 155 Beaver Street, Milford, MA 01757 USA >> >> d3e3e3@gmail.com >> >> >> >> > Cheers >> >> > >> >> > Magnus Westerlund >> >> >> >> _______________________________________________ >> >> Tsv-art mailing list >> >> Tsv-art@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tsv-art From nobody Mon Jul 3 11:57:26 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95296131722; Mon, 3 Jul 2017 11:57:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910824456.22710.9065920751276131603@ietfa.amsl.com> Date: Mon, 03 Jul 2017 11:57:24 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-rbridge-multilevel-07.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:57:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links) Authors : Radia Perlman Donald Eastlake Mingui Zhang Anoop Ghanwani Hongjun Zhai Filename : draft-ietf-trill-rbridge-multilevel-07.txt Pages : 33 Date : 2017-07-03 Abstract: Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network or can they merely be unique within each multilevel area? This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability and makes recommendations in some cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-rbridge-multilevel-07 https://datatracker.ietf.org/doc/html/draft-ietf-trill-rbridge-multilevel-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-rbridge-multilevel-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 14:56:11 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AB8127078; Mon, 3 Jul 2017 14:56:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911896201.22803.1033530657723672739.idtracker@ietfa.amsl.com> Date: Mon, 03 Jul 2017 14:56:02 -0700 Archived-At: Subject: [trill] Ben Campbell's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:56:02 -0000 Ben Campbell has entered the following ballot position for draft-ietf-trill-mtu-negotiation-06: No Objection 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-trill-mtu-negotiation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 2, first paragraph: "This document specifies a new value "Lz" for the acceptable inter- RBridge link MTU size on a local link." Should "acceptable" be "minimum acceptable"? From nobody Tue Jul 4 07:59:46 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAAA13193E; Tue, 4 Jul 2017 07:59:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, skh@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149918038011.16019.7511259728062989110.idtracker@ietfa.amsl.com> Date: Tue, 04 Jul 2017 07:59:40 -0700 Archived-At: Subject: [trill] Suresh Krishnan's No Objection on draft-ietf-trill-arp-optimization-08: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 14:59:40 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-trill-arp-optimization-08: No Objection 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-trill-arp-optimization/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points. From nobody Tue Jul 4 10:15:42 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C561324A0; Tue, 4 Jul 2017 10:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LJAaTZXs6tmi; Tue, 4 Jul 2017 10:15:31 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 091391319A0; Tue, 4 Jul 2017 10:15:17 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m84so74564184ita.0; Tue, 04 Jul 2017 10:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZdqMSF2jgye0iI7TNi+hoWSe1yF+bbp4lI7+2FUntJo=; b=BoOf/WQFWpvliUFSn2Mi8XV/Q78LlmFaQlb+VsPfvJcUiX/5IELem7kFqhOsvNe2om bVHWORU6hhV/mh+bZrMuLvicrY6+2rQ1gAMJkWIIBc8jCPgmBmptoP/fFCue/5gwsgRT EJD4Hmb75M9qO4CXs/jTuhPESDTfiVDLltvspLmCiMBw+fOzZDvUNyshi4oppii8D4hP ONNpW1Yx+mYerjEHeMTWPfJClKrAickRMmYlQnnDfX2Vvwchth4J8+jSczax/KYMW/6o V/HxugALcie13E8IvNpL8vWaOgZit/jKCtVukNQ33rY7tP0F6pZDPZR8HB1Tk6tB1R5o cQDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZdqMSF2jgye0iI7TNi+hoWSe1yF+bbp4lI7+2FUntJo=; b=jP+Z4nleYqmHFsXczjRU6ONK3/6cBLNjdC5htBJEwUHpi/ybWi9599BGZpiCSXnNMf AmCcC9QjS4j1lGrKa0wOQqNarzMnosgwOztJHUggnTDSCWhL9VQv/eqMn9jZAqkKnc4F vY52RLZaKb7P6J7QW9vn/40OwzlVAu3SDrkh94NKOo7TOS8knuzQOlIDXGs8sBYZbnRr EVb/LGOpt2oZzv87NzENDnZVlOZURFDX1g8HSJ5/x4ataH4T5njPrVeNFfRI2JSTEXJm 35S+MfoXJUdPFp6WIAtmVQ6tavYSEhYmGFqUwUmN+0wWadpojfFKNVAWmUMzwFTCi65+ 6ggg== X-Gm-Message-State: AIVw111IXuIqQdU9zYu777/leXrRF4ahRLD+Rtetac9ChOazVUfs8cUK zauMVfuc20B1ZSbug6nosHQb051UWmuY X-Received: by 10.36.3.11 with SMTP id e11mr14611724ite.79.1499188516171; Tue, 04 Jul 2017 10:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Tue, 4 Jul 2017 10:15:00 -0700 (PDT) In-Reply-To: <149870371689.6498.12830215563460223064@ietfa.amsl.com> References: <149870371689.6498.12830215563460223064@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 4 Jul 2017 13:15:00 -0400 Message-ID: To: Dale Worley Cc: "gen-art@ietf.org Review Team" , draft-ietf-trill-arp-optimization.all@ietf.org, IETF Discussion , "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [trill] Genart last call review of draft-ietf-trill-arp-optimization-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 17:15:35 -0000 Hi Dale, Thanks for the review. See below. On Wed, Jun 28, 2017 at 10:35 PM, Dale Worley wrote: > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > Document: draft-ietf-trill-arp-optimization-08 > Reviewer: Dale R. Worley > Review Date: 2017-06-28 > IETF LC End Date: 2017-06-29 > IESG Telechat date: unknown > > Summary: > > This draft is basically ready for publication, but has nits > that should be fixed before publication. > > Abstract > > This document describes mechanisms to optimize the ARP (Address > Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL > campus. > > s/in TRILL campus/in a TRILL campus/ OK. > Perhaps summarize what the optimizations are: > > Each edge RBridge maintains a cache of IP/MAC address/Data Label > bindings that are learned from ARP/ND requests and responses that > pass through it. This cache allows it to avoid flooding an ARP/ND > request by either responding to it directly or by encapsulating it > and unicasting it to the location where it is in use. Wording along those lines sounds like a good addition. > 2 ARP/ND Optimization Requirement and Solution > > (including DHCP or gratuitous ARP_messages). > > s/_// I think the underscore should be replaced by a space rather than the null string. > and should allow an end station to > detect duplicate IP addresses. > > Unless this is a well-known phrase, it would be best if it was clear > whether the end station is detecting that its own IP address is > duplicated, or whether it is detecting that some other station's IP > address is duplicated. This is talking about the end station doing normal DAD by probing for its own IP address. "detect duplicate IP addresses" -> "detect duplication of its IP address". > TRILL already provides an option to disable data-plane learning from > the source MAC address of end-station frames on a per port basis (see > Section 5.3 of [RFC6325]). > > Given how this section is written, shouldn't this option be considered > an option to *enable* data-plane learning? And in particular, doesn't > that imply that TRILL already includes a solution to suppress ARP > flooding? By default RBridges learn the source MAC addresses of the Ethernet frames they receive from attached end stations in a way similar to such data plane learning by bridges. A change in that default, to not learn such MAC addresses requires optional configuration. I don't think just learning MAC addresses is useful for the types of ARP flooding suppression talked about in this document. > Also, what is the meaning of "learning from the source MAC address"? > It seems like you'd want to specify what the learning is *of*, and > then perhaps what it is learned *from*. > > Or is this particular learning of MAC addresses alone, and not of > IP/MAC bindings? If so, then isn't this feature orthogonal to ARP/ND > optimization? As per RFC 6325, RBridge default to data plane learning of MAC addresses but not IP addresses. Although TRILL has ways of arbitrating between conflicting addressing information learned through different paths, it may be useful to disable data plane MAC address learning when a directory is being used or the like. > As a design matter, I'm curious why an RBridge can't learn IP/MAC > bindings by snooping data packets, and only by snooping ARP packets. > I suspect there are good reasons for it, but the naive reader (me) is > left wondering... You can get miscellaneous data packets at line speed so MAC address learning is frequently implemented in hardware. While there is no reason you couldn't do that for IP addresses, if you don't want to require hardware changes from that in most existing implementations, you would learn from ARP/ND in software which is generally practical as they are not normally received that frequently. > 4.1 SEND Considerations > > Secure SEND messages require knowledge of cryptographic keys. Methods > of communicating such keys to RBridges for use in SEND are beyond the > scope of this document. Thus, using the optimizations in this > document, RBridges do not attempt to construct SEND messages and are > generally transparent to them. RBridges only construct ARP, RARP, or > insecure ND messages, as appropriate. > > This doesn't flow quite correctly. The second sentence suggests that > there are known mechanisms for distributing keys to RBridges, but that > this document doesn't describe them. I disagree. Saying "X is beyond the scope of this document" means what it says: that the topic is not further touched on in this document. I do not think it implies that techniques to do X do or do not exist. > The reader then expects that the > third sentence will say that if RBridges are provisioned with keys in > an environment, they can generate SEND responses. But instead, the > real meaning of the second sentence seems to be that there are no such > ways of distributing keys to RBridges and therefore they can't > generate SEND responses. That suggests that the second sentence > should be rephrased: I disagree. I don't think the typical reader would have such an expectation. Even if there were standardized or deployed ways to put such keys on edge RBridges, having said they were out of scope, I would expect that further mechanisms built on such keys would also be out of scope and not covered by the document. > There are no methods of communicating such keys to RBridges for > use in SEND, and thus RBridges cannot construct SEND messages and > must be generally transparent to them. The existing wording goes as far as I think it should. I don't see any reason to make it stronger and more restrictive. > Or perhaps "SEND forbids communicating such keys to RBridges, and > thus...". I don't think SEND says anything about communicating such keys and it seems like a bad idea for a TRILL document to be putting words in SEND's mouth. If there is such a provision in the SEND specification could you point it out to me? > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP > > What is "non-zero IP"? Is this the case discussed in section 4.4 item > (d)? (If so, it also includes "a Neighbor Solicitation for DAD > ... which has the unspecified source address".) Perhaps the property > being described is "Get Sender's IP/MAC Mapping Information from > Non-Address Probe ARP/ND Queries". This is section is talking about getting and handling the IP/MAC mapping information for a local end station by an edge RBridge. An ARP/ND from such a local end station might show a zero source IP address if the end station does not have one or is probing for duplicates. Perhaps the title for the Section should be something like 4.3 Extracting Local End Station IP/MAC Mapping Information and a new first paragraph could be added something like Edge RBridges extract and use information about the correspondence between local end station IP and MAC addresses from the ARP/ND messages those end stations send as described below. An apparent zero source IP address means that the end station is probing for duplicate IP addresses and messages with such a zero source IP address are not used for the extraction of IP/MAC address mapping information. > 4.4 Determine How to Reply to ARP/ND > > It is not essential that all RBridges use the same strategy for which > option to select for a particular ARP/ND query. It is up to the > implementation. > > It appears that the division between options (a), (b), (c), and (d) > are fixed by the draft, so this statement is rather confusing. Also, > "It is up to the implementation." is a bit awkward. Perhaps: > > Within each item, it is an implementation decision which strategies > to use for any particular ARP/ND query falling under that item. OK except "strategy" should be singular. > -- > > Because the edge RBridge might not have an IPv6 address, the > source IP address for such an ND response MUST be that of the > target end station. > > Wouldn't the source IP address for such an ARP response also be that > of the target end station, given that it is a simulated ARP response > from the target end station? That is, why is this MUST specific to > IPv6? ARP messages are not IP messages. They are link local layer 2 messages. Perhaps it could suggest that the source MAC address for an ARP be that of the end station that would normally have sent the ARP but all the information needed is inside the ARP message so there is no need for an ARP implementation to look at any outer addressing of an ARP message, such as MAC addresses on an Ethernet link, and I do not think such implementations look at such outer addresses. Furthermore, when this draft was previously considered by the IESG, we were asked to specify the source IPv6 addresses for ND messages but nothing along those lines was said about ARP messages. Item a.5: "/ND/SEND" -> "ARP/ND/SEND" > b.3. Drop the message if the directory mechanism is used and you > know there should be no response (query based on an non-existent IP > address for example). > > It would be better to phrase this: > > b.3. Drop the message if the directory server gives authoritative > information that the IP address is non-existent. OK. > 4.5 Determine How to Handle the ARP/ND Response > > the target's egress RBridge R2 as discussed in subsection 3.2 item a) > > Really, it's subsection 3.2 item a.2. Yes. > or to flood the request as per [RFC6325] > > Isn't this item a.5? Yes. > When/if the target responds, > > Probably better as "If and when the target responds,". OK. > 5 Handling RARP (Reverse Address Resolution Protocol) Messages > > The title of section 5 starts "Handling" whereas the titles of > sections 6 and 7 start "Handling of". It's probably worth making the > three consistent. OK. > Its use is similar to > > Shouldn't this be "Its processing is similar to" OK. > Normally, it is used to > look up a MAC address to find the corresponding IP address. > > Doesn't this duplicate the third sentence of this paragraph? Yes, that sentence should probably be deleted. > 7 Handling of Duplicate IP Addresses > > Duplicate IP addresses can be detected when an existing active > IP1/MAC1 mapping gets modified. > > Should "IP1/MAC1" be "IP/MAC"? Neither "IP1" nor "MAC1" is used > elsewhere in the document. OK. > Also an edge RBridge may send a query > to the former owner of IP called a DAD-query (Duplicate Address > Detection query). > > This is a bit ambiguous -- is it the query or the former owner that is > called a DAD-query? Better "may send a query called a DAD-query (...) > to the former owner of the IP". OK. > However the following discussion does not specify how the DAD-query is > addressed to the "former owner", and so doesn't specify if the former > owner is defined by the MAC address previously associated with the IP > address or what. The protocol logic seems to require that the > destination MAC is the one previously associated with the IP address > and the queried-for IP must be the IP in question. This should be > spelled out, since the source addressing is specified. OK. > In the case where the former owner replies, a Duplicate Address has > been detected. In this case the querying RBridge SHOULD log the > duplicate so that the network administrator can take appropriate > action. > > What action should the querying RBridge take in regard to its cache? There is no inherent right answer that TRILL can specify when you have duplicate IP assignments. (If there is a directory controlled by an omniscient orchestration system, then the directory should be assumed to be correct and conflicting IP assignments should be ignored.) > 9 Security Considerations > > s/as provide in/as provided in/ (two instances) OK. > 12.1 Normative References > > [DirMech] Dunbar, L., Eastlake 3rd, D., Perlman, R., I. Gashinsky. > and Li Y., TRILL: Edge Directory Assist Mechanisms", > draft-ietf-trill-directory-assist-mechanisms, work in > progress. > > There are unbalanced double-quotes here. That draft has issue as RFC 8171 so the reference should be updated. Thanks again for the review. Although I think a few of your comments are off the mark, most of them will result in improved wording and clarity. Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Tue Jul 4 20:01:43 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0B5129AD2; Tue, 4 Jul 2017 20:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Hjgl-piM4sLL; Tue, 4 Jul 2017 20:01:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8081243FE; Tue, 4 Jul 2017 20:01:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQK76862; Wed, 05 Jul 2017 03:01:36 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 5 Jul 2017 04:01:35 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 5 Jul 2017 11:01:32 +0800 From: "Zhangmingui (Martin)" To: Ben Campbell , The IESG CC: "draft-ietf-trill-mtu-negotiation@ietf.org" , "trill-chairs@ietf.org" , "shares@ndzh.com" , "trill@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT) Thread-Index: AQHS9EcwSpIYmrPjUUS0+/EHzZzqWqJEi33w Date: Wed, 5 Jul 2017 03:01:32 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A65446C0@NKGEML515-MBX.china.huawei.com> References: <149911896201.22803.1033530657723672739.idtracker@ietfa.amsl.com> In-Reply-To: <149911896201.22803.1033530657723672739.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.595C5691.0010, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 647241f5bcc3f339c48580abbe424f7a Archived-At: Subject: Re: [trill] Ben Campbell's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 03:01:43 -0000 SGkgQmVuLA0KDQpZZXMsICJtaW5pbXVtIGFjY2VwdGFibGUiIGlzIGV4YWN0LiBUaGlzIHdpbGwg YmUgaW5jb3Jwb3JhdGVkIGludG8gdGhlIG5leHQgdmVyc2lvbi4NCg0KVGhhbmtzLA0KTWluZ3Vp DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuIENhbXBiZWxsIFtt YWlsdG86YmVuQG5vc3RydW0uY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDA0LCAyMDE3IDU6 NTYgQU0NCj4gVG86IFRoZSBJRVNHDQo+IENjOiBkcmFmdC1pZXRmLXRyaWxsLW10dS1uZWdvdGlh dGlvbkBpZXRmLm9yZzsgdHJpbGwtY2hhaXJzQGlldGYub3JnOw0KPiBzaGFyZXNAbmR6aC5jb207 IHRyaWxsQGlldGYub3JnDQo+IFN1YmplY3Q6IEJlbiBDYW1wYmVsbCdzIE5vIE9iamVjdGlvbiBv biBkcmFmdC1pZXRmLXRyaWxsLW10dS1uZWdvdGlhdGlvbi0wNjoNCj4gKHdpdGggQ09NTUVOVCkN Cj4gDQo+IEJlbiBDYW1wYmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4gZHJhZnQtaWV0Zi10cmlsbC1tdHUtbmVnb3RpYXRpb24tMDY6IE5vIE9iamVj dGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l IGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0 aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0K PiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczov L3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9u cy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0 aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdHJpbGwtbXR1LW5lZ290aWF0aW9uLw0KPiANCj4gDQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IC0gMiwgZmlyc3Qg cGFyYWdyYXBoOiAiVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgdmFsdWUgIkx6IiBmb3Ig dGhlDQo+IGFjY2VwdGFibGUgaW50ZXItDQo+ICAgIFJCcmlkZ2UgbGluayBNVFUgc2l6ZSBvbiBh IGxvY2FsIGxpbmsuIg0KPiANCj4gU2hvdWxkICJhY2NlcHRhYmxlIiBiZSAibWluaW11bSBhY2Nl cHRhYmxlIj8NCj4gDQoNCg== From nobody Wed Jul 5 00:33:09 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F530131A92; Wed, 5 Jul 2017 00:33:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149923998135.3322.6478212107835480805.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 00:33:01 -0700 Archived-At: Subject: [trill] Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 07:33:02 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-trill-mtu-negotiation-06: No Objection 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-trill-mtu-negotiation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Are there implementations of this optimization? Have they shown the expected improvements? The mechanism seems ok, but the introductory text made we wonder, specially the part about "*potentially* improving the efficiency of link utilization and speeding link state convergence." IOW, if the advantages are not really know, then maybe a Standards Track document is premature. I really don't have a strong opinion, so I'm just wondering at this point. Some nits: 1. There are some places where rfc2119 language is used that I think is out of place because it is really just stating a fact or quoting what different documents say (without actually using quotations); IOW, these are really not normative statements defined in this document: - "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU...all RBridges MUST format their LSPs..." - "As specified in [RFC8139], RBridges MUST support..." - "as required by [RFC7780], all RBridges MUST..." 2. From 2.1, these 2 sentences are redundant: "An originatingSNPBufferSize APPsub-TLV occurring in any other fragment MUST be ignored. An originatingSNPBufferSize APPsub-TLV occurring in any other fragment is ignored. " From nobody Wed Jul 5 03:17:25 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6472A129B7F; Wed, 5 Jul 2017 03:17:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-trill-rbridge-multilevel@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149924983936.10408.1174197683468986988.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 03:17:19 -0700 Archived-At: Subject: [trill] Alvaro Retana's No Objection on draft-ietf-trill-rbridge-multilevel-07: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 10:17:19 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-trill-rbridge-multilevel-07: No Objection 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-trill-rbridge-multilevel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document "enumerates and examines alternatives" related to multilevel TRILL. It provides useful information, but I think its publication might be premature given that, for example, the work on unique and aggregated nicknames is still in progress in the WG -- even if that work is stable, there's still a (maybe small) probability of this document falling out of sync. From nobody Wed Jul 5 04:39:01 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8FF129B94; Wed, 5 Jul 2017 04:38:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, skh@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 04:38:54 -0700 Archived-At: Subject: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 11:38:55 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-trill-arp-optimization-08: 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-trill-arp-optimization/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It's not clear to me how the security properties of this mechanism compare to existing TRILL. The text says: Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be easily forged. Therefore the learning of MAC/IP addresses by RBridges from ARP/ND should not be considered as reliable. See Section 4.1 for SEND Considerations. "not considered as reliable" seems suboptimal. You need to cover how this mechanism compares to the non-use of this mechanism. This document seems very sketchy on what you do when you get duplicate IPs. In the case where the former owner replies, a Duplicate Address has been detected. In this case the querying RBridge SHOULD log the duplicate so that the network administrator can take appropriate action. How does logging solve the problem? What do you reply to ARPs with and/or propagate to other nodes? Do you tell the originator of the advertisement you have a duplicate? When a newly connected end-station exchanges messages with a DHCP [RFC2131] server an edge RBridge should snoop them (mainly the DHCPAck message) and store IP/MAC mapping information in its ARP/ND cache and should also send the information out through the TRILL control plane using ESADI. What happens if the attacker sets up a fake DHCP server and pretends to assign addresses to himself? It seems like maybe that's the same as fake ARPs but maybe not. In general, the security considerations need a complete threat analysis per 3552. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 2. plane on the edge RBridges, it should be possible to completely suppress flooding of ARP/ND messages in a TRILL Campus, When all end- station MAC addresses are similarly known, it should be possible to suppress unknown unicast flooding by dropping any unknown unicast received at an edge RBridge. Are these "should be possibles" normative? Descriptive? S 4. This is a sequence of steps, so it would be nice to preface them with a list of the steps. It's also odd to have SEND considerations right in the middle here. 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP Please explain what a non-zero IP is and why it's relevant. This graf also needs an introductory sentence or something before the bullets. S 4.4. It is not essential that all RBridges use the same strategy for which option to select for a particular ARP/ND query. It is up to the implementation. This seems inconsistent with the MUST in arm (b) below, because I can just take some other arm. It's also kind of surprising to be this non-prescriptive. S 8. some other location (MAC/VM Mobility) and gets connected to egde- Nit: edge is mispelled. From nobody Wed Jul 5 06:02:24 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D599D1329EA; Wed, 5 Jul 2017 06:02:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund To: Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org, ietf@ietf.org, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149925973580.17545.6979655005275084891@ietfa.amsl.com> Date: Wed, 05 Jul 2017 06:02:15 -0700 Archived-At: Subject: [trill] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 13:02:16 -0000 Reviewer: Magnus Westerlund Review result: Not Ready This TSV-ART review is influenced by that I did the review of draft-ietf-trill-over-ip. 1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for determining if the UDP encapsulation will work or not. It references in Section 8.4 the old RFC, i.e. RFC 6325, which is updated by draft-ietf-trill-mtu-negotiation. TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in [RFC7177], can be used to obtain added assurance of the MTU of a link. However, this is not quite true, as if the IP path MTU is below 1470 bytes, which is not unheard of, the algorithm in the MTU negotiation draft can't determine it. It will only report the IP path as having an MTU to small when the 1470 bytes probe fail. So, if the trill-over-ip authors want to use this as a mechanism, then the MTU negotiation draft needs to be expanded to have more flexible lower boundaries. However, that appear to affect MTU negotiation quite significant as it needs to separate algorithm for finding MTU, from the different usage of the algorithm with different starting points. Where the normal will have a lower bound of 1470, and be more tightly coupled to Sz when finding Lz. While the Trill-over-IP has a different usage. I think the trill WG needs to decide on how to slice this. If the MTU-negotiation only targets the explicit targets in the current draft and goes forward now. Or if they want to meet trill-over-ip's goals which will require restructuring. 2. Another issue, is that I think the algorithm is a bit short on transmission scheduling recommendations: 1) If RB1 successfully receives the MTU-ack from RB2 to the probe of the value of link-wide Lz within k tries (where k is a configurable parameter whose default is 3), link MTU size is set to the size of link-wide Lz and stop. If I do this test with all three packets back to back at line rate, I could potentially get all probes lost in the same burst loss in router queue or switch fabric. What I think is needed here is a specification on how these probes are transmitted. Spaced in a particular way, or at least minimal distance, and are the additional probes only sent after the previous has been judged to have been lost, which makes it interact with the next issue. 3. This is also unclear on what the criteria is for determining that something is lost: a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello and stop. I fail to see any specification for the criteria when an MTU-ack should be considered to have failed to reach the probing entity. So this appear to require a timeout, and thus a timeout interval. Is the RTT known so that one can define something as lost after N*RTT? Are there possible delays in sending the MTU-ack that are considered okay that can affect this? 4. Section 3, the algorithm in Step 1 is unable to reach the first termination condition (3) "If lowerBound >= upperBound" in some cases. Step 1: RB1 tries to send an MTU-probe padded to the size x. 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: upperBound is set to x and x is set to [(lowerBound + upperBound)/2], rounded up to the nearest integer. 2) If RB1 receives an MTU-ack to a probe of size x from RB2: link MTU size is set to x, lowerBound is set to x and x is set to [(lowerBound + upperBound)/2], rounded up to the nearest integer. 3) If lowerBound >= upperBound or Step 1 has been repeated n times (where n is a configurable parameter whose default value is 5), stop. 4) Repeat Step 1. I run this on the input data: Lower bound = 1470, Upper bound = 9216 and with an MTU of 7935 and gets the following sequence: Lower Upper X 1470 9216 5343 5343 9216 7280 7280 9216 8248 7280 8248 7764 7764 8248 8006 7764 8006 7885 7885 8006 7946 7885 7946 7916 7916 7946 7931 7931 7946 7939 7931 7939 7935 7935 7939 7937 7935 7937 7936 7935 7936 7936 7935 7936 7936 Thus, the termination condition needs to change. The second I notice is that having a limitation on number of steps as 5, results in quite a large gap between upper and lower bound in which the MTU exists in. 5. I frankly gets confused by the application of the binary search. First it will in many case not be run to termination where the actual MTU is determined. Then the result of the upper and lower bound are just used to confirm the Sz value. There are no discussion about using the MTU search to determine a new possible value for Sz. The text is not even explicit that lower bound is the highest known to work Transmission unit size at the time of testing. I think section 3, should conclude in determine some TU value, and if that is Sz or something other appears quite relevant for what to do in the later sections. From nobody Wed Jul 5 06:20:05 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B63131CFB; Wed, 5 Jul 2017 06:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=YAnOchH5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jph099MC 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 dtcEBMMx-2Rd; Wed, 5 Jul 2017 06:20:01 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6B41329E7; Wed, 5 Jul 2017 06:20:01 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DABEC20A5A; Wed, 5 Jul 2017 09:20:00 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 05 Jul 2017 09:20:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=QfMO+lY5xnrrNXjJCa 6YCy8TXmc8tP2D4nNU8JOyuNE=; b=YAnOchH5Q7rTfCi5nxHOEIsQ2vC8GghOe7 6jOfPTcuFKo00JBh3jMI8Nftn8uvJP/NvmMgcQQF/6qMxb5+dyTDqACpgVaUPKGC Y7Mab1kzo3LxkJg+Hn0t3+/VgOgXQQjPm/guAUqD51dbNiVdySl3jrxmqbv3UOIr p9PUyn5QjlUPktTb2tIuofhS0Ar/bzbZERDraA0A19jI8lmVT9UsCIU3HMnJy3oq y/ZFAEr6RbJgOuLsL5pqvYwqCLi06Xdm3VzzbnN7a8uy7oWBUQ7sK5Gn+2KxvurH H32CgeEkGm5RL45eagclMeBIoLodODoEQ8OU/72iJGHDeT/xwb/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=QfMO+lY5xnrrNXjJCa6YCy8TXmc8tP2D4nNU8JOyuNE=; b=Jph099MC HnyswHHcpT4MNJm//V05XTi8hDqz/u8bzGWL4fR9XuUSDMOtti24dTF+mV685Qop Zan7GXw4rpVOVY9bTLBAxroiQ7Zs8qKKhyg5KLRGrTCuB3atoXhBBtavf5fv106G 5+tgqjlXrUYKC3VMt9YicuF13DZ0dusSBuXpKdjJCQ1Pmf6x+zAnU01R9JfL4GhR iy9kqZWFq0M4kNxpzJzG59HbpVFLJwr0JOn9RHlpM3p7Z3o+DgWp213Zd5zu1S8w Ana8MHYr/dxmxk+YShukSUk1Kf4csTf71sCeLW50RhgPWrW73ljIg+Inq+NRCo0P TIAu9BWFfR68vQ== X-ME-Sender: X-Sasl-enc: +C08veerLbialoEbmy4OrN4IAnWH0IsOQfxVW2YQyD4F 1499260800 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.163]) by mail.messagingengine.com (Postfix) with ESMTPA id D3C267E6F1; Wed, 5 Jul 2017 09:19:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149879280768.4678.12635697098775028225@ietfa.amsl.com> Date: Wed, 5 Jul 2017 09:19:58 -0400 Cc: gen-art@ietf.org, draft-ietf-trill-mtu-negotiation.all@ietf.org, trill@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <01DAD991-A219-4A92-B266-BA91C052C38E@cooperw.in> References: <149879280768.4678.12635697098775028225@ietfa.amsl.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [trill] [Gen-art] Genart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 13:20:04 -0000 Brian, thanks for your reviews. Authors, thanks for addressing Brian=E2=80= =99s comments. I have entered a No Objection ballot position. Alissa > On Jun 29, 2017, at 11:20 PM, Brian Carpenter = wrote: >=20 > Reviewer: Brian Carpenter > Review result: Ready >=20 > Gen-ART telechat review of draft-ietf-trill-mtu-negotiation-06 >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-trill-mtu-negotiation-06.txt > Reviewer: Brian Carpenter > Review Date: 2017-06-30 > IETF LC End Date: 2017-06-28 > IESG Telechat date: 2017-07-06 >=20 > Summary: Ready > -------- >=20 > Comment: > -------- >=20 > Thanks for handling my Last Call comments. >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jul 5 06:28:14 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 369DD132A13; Wed, 5 Jul 2017 06:28:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-trill-rbridge-multilevel@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149926129213.13114.7809382263824021799.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 06:28:12 -0700 Archived-At: Subject: [trill] Alissa Cooper's No Objection on draft-ietf-trill-rbridge-multilevel-07: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 13:28:12 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-trill-rbridge-multilevel-07: No Objection 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-trill-rbridge-multilevel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think it would help if the explanation of the assumptions and/or references mentioned in the Gen-ART review could be added. From nobody Wed Jul 5 06:31:11 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50659132A20; Wed, 5 Jul 2017 06:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=czRal8sX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=amKL2xRo 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 LYzPfZyV8yoc; Wed, 5 Jul 2017 06:31:02 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E054132A10; Wed, 5 Jul 2017 06:31:02 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D66F120A6C; Wed, 5 Jul 2017 09:31:01 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 05 Jul 2017 09:31:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ap5lzpGbzgQB62mU6i LpCc1kOD6eu9WX87TrlgkFAuA=; b=czRal8sXDtC+IuKlko8/xmxUNdf7lWpGpJ vxLAgNhRx2xXUoZ7wCSuK8Pffvi0XASO3C87Qqhyxk/Ic9xiUTHi/VAH+Bqh2cda xfdiWQ8LCsjnUoFrG+qoQhwpkytNkadcHM0TexOtbcUJC1JPyBGmhbceaRk4pAb0 CyGeaUAudzSuaUMEOoW5G6OujO4pFQ9O0rr33KsNevfXomc8Hnq5eDdLccNebcpF 6mU/xsG6k+/COMtF5LnTmVweS0F9QJhWw0s8DNltIkgJqdd7ffq6H3kNnpLvQXGv HoOxs1LVKw012MxgK8np+6FU/tyS7N74pwv1oh7RMuAbknqcjWdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ap5lzpGbzgQB62mU6iLpCc1kOD6eu9WX87TrlgkFAuA=; b=amKL2xRo YBiIjYXjTvotoaOgUhpkMKcA/V/qR+0HyEqVq5bzEdqUSGZ6wuArBchivsUbaePp IVzW5Etz0tm2+wBqYYeACVOPcVZXatxUK92x4n+h2KodJuhhqrVFNmkT0H/nzEUg Zorj/cUhUorSarkS1jwIj8HtsOcDLORR2wlAki9+BOYF8SU7K+oIQh0xWo7c/LgD eyc549+HWlDDAKhrVtaRXb1m76ny2iIxp48lXEWFtz93oyzsOyy6Rc/u3L+7KVKQ UBbJJU5N46uB0aPcubtMhNia7tJdrCqSw9PJFsReS5btkdFxUupgdzZDA7flTppb j1vkZfaFI1xGCw== X-ME-Sender: X-Sasl-enc: zxDE316QgubP+j1p/yV4lJGiyrxz83puByEY2n972wMV 1499261461 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.163]) by mail.messagingengine.com (Postfix) with ESMTPA id A54717E8C8; Wed, 5 Jul 2017 09:31:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149926129213.13114.7809382263824021799.idtracker@ietfa.amsl.com> Date: Wed, 5 Jul 2017 09:30:58 -0400 Cc: trill-chairs@ietf.org, shares@ndzh.com, draft-ietf-trill-rbridge-multilevel@ietf.org, trill@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C1B06FA-C453-489A-ABBE-3E372F17D081@cooperw.in> References: <149926129213.13114.7809382263824021799.idtracker@ietfa.amsl.com> To: IESG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [trill] Alissa Cooper's No Objection on draft-ietf-trill-rbridge-multilevel-07: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 13:31:04 -0000 My apologies, I was reviewing the wrong version of this document and I = see that additional text has been added to the -07 to address this. Thanks, Alissa > On Jul 5, 2017, at 9:28 AM, Alissa Cooper wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-trill-rbridge-multilevel-07: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I think it would help if the explanation of the assumptions and/or = references > mentioned in the Gen-ART review could be added. >=20 >=20 From nobody Wed Jul 5 06:32:39 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4CD132049; Wed, 5 Jul 2017 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=nsf6qbkX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MzQVjlgD 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 K3GbGCKFVQA3; Wed, 5 Jul 2017 06:32:32 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E155132A20; Wed, 5 Jul 2017 06:32:32 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E170620680; Wed, 5 Jul 2017 09:32:31 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 05 Jul 2017 09:32:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=YceDgslqDi4ivj02i0 CxrYFlNCXnWnKUi65NT8qD08Y=; b=nsf6qbkXcBaKL0+HnrG1w2Clz9NuPRCJI4 7hvLzWJlPj2QbvhD0T4q5vtQWV0JxewkOK3PeJb/EaBskuzFgK11beNwl2PGCvto /pdCXmibSx8yMhuTozUEyiog8y/Hw3Xy5cQWvVuj2BpGUO0OAlv1noEJhOf1WvTR HGq2NpbJ+ZExqVAvuvqAg6Iy/ZRE7MQDJKjow0gxrstl4KA0ixL6lLzWyBO4bkdZ BiBCppAjVWsK3sTuutrwVfcmqDTzsl/kf6EHs7XQvwz57iRC8wLmlLNo5b1rUMqz 2NgD68hjlVZFWjY7uAoC4TIOXFUynugxxyfJELKyl5YkyyScJyhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=YceDgslqDi4ivj02i0CxrYFlNCXnWnKUi65NT8qD08Y=; b=MzQVjlgD Xll4Ncjz3Me4nXRW+T8ECvmyzjYPHxIjQrq/W+5s4c5p78Oc6dp0ir/JmZIUaUtL 0LYxU34H+0+5tlR/G6YYimsAse/nq2o4VPIppJ3ZhzBKE+nPA3f+JomYQ0ESDGyQ jIagz42nXcETgSTGN8eoogIFq+8Rz55/krkpbEdUuckmmB65bRScDUlzB4HnBsJL P6j20Rw8OA+h3DOOGbZNEt2IGWZg5kXc1QXNQ+A5Tvu9HI/7pSOFTkwR0zxrGatA cuIxc0Hx7VNiggt9qBTFH7JbJzeSR8lq46kpSoLET7WmTS2kfXDvLCHDLymS3r9L ZZMrsRajCjmuOw== X-ME-Sender: X-Sasl-enc: 0jNNQFxRdKcNfijY1CLOZ6qzGG6s4cuKdjE89jpoGEus 1499261551 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.163]) by mail.messagingengine.com (Postfix) with ESMTPA id D55EE7E46B; Wed, 5 Jul 2017 09:32:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149867317753.7558.8752757743866337364@ietfa.amsl.com> Date: Wed, 5 Jul 2017 09:32:29 -0400 Cc: gen-art , draft-ietf-trill-rbridge-multilevel.all@ietf.org, trill@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149867317753.7558.8752757743866337364@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [trill] [Gen-art] Genart last call review of draft-ietf-trill-rbridge-multilevel-06 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 13:32:34 -0000 Stewart, thanks for your review. Donald, thanks for your engagement with = Stewart=E2=80=99s review. I have entered a No Objection ballot position. Alissa > On Jun 28, 2017, at 2:06 PM, Stewart Bryant = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-trill-rbridge-multilevel-?? > Reviewer: Stewart Bryant > Review Date: 2017-06-28 > IETF LC End Date: 2017-06-28 > IESG Telechat date: 2017-07-06 >=20 > Summary: >=20 > This is a well written document. I do however have a concern with the = scaling > text in section 1.2.x, as I think this could be more accessible and = ought to > include discussion of MAC Address scaling. More information below. >=20 > Major issues: None >=20 > Minor issues: The key justification for multi-area is scaling. The = scene is set > in Section 1.2.x. However there are no references, the design size = parameters > are not articulated for each case, and the equations are not derived. = I think > that it would be helpful if the draft either provided some more = explanation of > the scaling equations and the associated input assumptions, or = provided the > assumptions and directed the reader to an accessible text to = understand the > equations. Although there is some discussion on it later there is no = discussion > of the number of addresses to be learned in the single and multi-area = cases and > the impact this has on the LSDB. The number of addresses to be learned = will > impact the ingress RBridge FIB and the FIB update time so this is just = as > significant in understanding the benefit of multi-level as = understanding the > link-state convergence time is. >=20 > Nits/editorial comments: None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jul 5 12:15:53 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B081205F0; Wed, 5 Jul 2017 12:15:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149928214838.19397.15366425287313778494.idtracker@ietfa.amsl.com> Date: Wed, 05 Jul 2017 12:15:48 -0700 Archived-At: Subject: [trill] Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 19:15:48 -0000 Warren Kumari has entered the following ballot position for draft-ietf-trill-mtu-negotiation-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-trill-mtu-negotiation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1: Instead of answering the questions, the Shepherd Writeup just has links to things - for example: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG LC: Passed: https://www.ietf.org/mail-archive/web/trill/current/msg07304.html Discussion: https://www.ietf.org/mail-archive/web/trill/current/msg07210.html This caused me to go investigate further - it seems that there were only 4 comments received during WGLC (excluding the RtgDir review, a short exchange with Julien Meuric). The comments which *were* received largely just fell into the "Support" (with no real discussion) category. The document was adopted 06 March 2015, and then there were a few automated mentions of it (e.g [0], [1]), but I see no real discussion of the draft *in the WG*. It is entirely possible that my search fu is weak today, and that there has been sufficient discussion and review of the draft (or that none was needed because it is so obviously right and pure, but I'd like some reassurance of that), especially because a quick review found multiple readability issues / nits. Note: I'm not holding the discuss on the readability / nits, rather on has the process been followed / is there consensus grounds 2: The document also says that it Updates: 6325, 7177, 7780 - but I don't see clear discussion of the Updates (OLD / NEW). [0]: https://mailarchive.ietf.org/arch/msg/rtg-dir/c863sUajt86YB_d62uWfF5Hd_X4 [1]: https://mailarchive.ietf.org/arch/msg/i-d-announce/p5ROVvvoU0B3S1OA2SY3vebX_b4 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Major: I found much of the document really hard to read - I approve of the concept / see the need for this, but reading the document itself is not well written. Nits: General RFC 6325 says: "4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size In a stable campus, there must ultimately be agreement among all RBridges on the value of "Sz", the minimum acceptable inter-RBridge link size for the campus, for the proper operation of TRILL IS-IS." and this document says: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" " Ok, so Sz is campus-wide -- but, for some reason this document has ~35 instances of "campus-wide Sz" - can you just drop the "campus-wide"? Is there any time the Sz would not be campus-wide? Section 1. "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" to ensure that link state flooding operates properly and all RBridges converge to the same link state." This is really hard to parse - the bit before the hyphen is fine, but then it gets muddled. Perhaps: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called "Sz") to ensure that link state flooding operates properly and all RBridges converge to the same link state." "By calculating and using Lz as specified herein, link-scoped PDUs can be formatted greater than the campus-wide Sz up to the link-wide minimum acceptable inter- RBridge MTU size potentially improving the efficiency of link utilization and speeding link state convergence." "formatted" seems clumsy - perhaps just drop it? Or reorder to be "link-scoped PDUs larger than Sz, up to ... can be used"? O: "The new MTU size testing method specified in this document is backward compatible to the old one." P: "The new MTU size testing method specified in this document is backward compatible with the old one." C: Grammar O: "Link-wide Lz is the minimum Lz supported and agreed between all RBridges on a specific link." P: "Link-wide Lz is the minimum Lz supported and agreed amongst all RBridges on a specific link." C: Between only if two. Section 2. Link-Wide TRILL MTU Size O: "These PDUs are exchanged just on the local link." P: "These PDUs are exchanged only on the local link." O: "They use that flooding to exchange their maximally supportable value of "Lz"." P: "They use that flooding to exchange their maximum supported value of "Lz"." C: Maximally would be an adverb, describing the process of maximizing the flooding (or something). Section 2.1: O: "Lz MAY be reported using a originatingSNPBufferSize TLV that occurs" P: "Lz MAY be reported using an originatingSNPBufferSize TLV that occurs" C: I think. O: "If RB2 sends PDUs formatted in chunk of size 1800, it will be discarded by B1." P: "If RB2 sends PDUs formatted in chunks of size 1800, they will be discarded by B1." C: chunks is plural. Section 6: "The CSNPs and PSNPs MUST be formatted in chunks of size at most the link-wide Lz but are processed normally if received larger than that size." -- why the MUST? Is this supposed to be an instance of the sender being conservative and the receiver liberal? It so, I think it would be better to be much clearer. Section 7: O: "Unlike RBridges, end stations do not participate in the exchange of TRILL IS-IS PDUs, therefore they cannot grasp the traffic link MTU size from a TRILL campus automatically. " C: should be a semicolon and not a comma before therefore, and a comma after therefore. Section 8. Backwards Compatibility O: "This will act properly although it may not be as efficient as it would be if all RBridges on the link are Lz-aware." P: "This will act properly although, it may not be as efficient as it would be if all RBridges on the link are Lz-aware." C: Missing comma. "Then the path MTU can be set as the smallest tested link MTU on this path and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." -- instead: "Then, the path MTU can be set as the smallest tested link MTU on this path; and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." From nobody Wed Jul 5 14:05:08 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0A7131DE0; Wed, 5 Jul 2017 14:04:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Mahesh Jethanandani To: Cc: draft-ietf-trill-arp-optimization.all@ietf.org, ietf@ietf.org, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149928869116.8318.7080669996560577650@ietfa.amsl.com> Date: Wed, 05 Jul 2017 14:04:51 -0700 Archived-At: Subject: [trill] Opsdir last call review of draft-ietf-trill-arp-optimization-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:04:51 -0000 Reviewer: Mahesh Jethanandani Review result: Has Nits I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed:  draft-ietf-trill-arp-optimization-08 Summary: Ready with Nits Document Status: Standard Track General Comments: The abstract of the document says that the draft tries “To reduce the burden on a TRILL campus caused by these multi-destination messages, RBridges MAY implement an "optimized ARP/ND response", as specified herein, when the target's location is known by the ingress RBridge or can be obtained from a directory. This avoids ARP/ND query and answer flooding.” Implementation of this draft will impact the operations of the network. As such careful consideration should be placed on operational and management impact of the draft. The following comments look at the document both from an operational perspective as well as a management perspective. Operational Considerations: Operational considerations include installation and initial setup, migration path, requirements on other protocols, impact on network operations and verification of correct operation. >From an impact on network operations perspective, this draft proposes to reduce the traffic in the network by preventing a network wide broadcast and multicast of messages. As such it should reduce the impact on the network, when operating correctly. In the worst case, that it is not operating or operating incorrectly, these network broadcast and multicast messages will “leak” into the broader network, where they will be treated just as they are in todays network. For this reason, a migration path may not be required, or existing protocols modified to deal with the change. >From a verification of correct operations, it is not clear how one determines that the RBridge is operating correctly beyond observing individual ARP/ND messages. Does it keep track of ARP/ND messages it has intercepted and responded to on the local network, which would have escaped to the broader network? Keeping track of statistics will allow for tracking the operation of what is defined in the draft. Management Considerations: Management considerations include interoperability, fault management, configuration management, accounting, performance and security. >From a configuration management perspective, it is not clear how the configuration of the RBridge is realized. For example, per the draft, RBridge might not verify an IP address if the network manager's policy is to have the network behave, for each Data Label, as if it were a single link and just believe an ARP/ND it receives. If such a configuration is desired, this or an accompanying document needs to define the manageability aspect of RBridge, preferably in the form of a YANG model. >From a accounting perspective, For example, in the draft, RBridge could for generic ARP/ND request seeking the MAC address corresponding to an IP address, if the edge RBridge knows the IP address and corresponding MAC, behavior is as in item (a), otherwise behavior is as in item (b). Behavior for gratuitous ARP and ND Unsolicited Neighbor Advertisements [RFC4861] is given in item (c). And item (d) covers handling of Address Probe ARP Query. Are there specific statistics being maintained for each of these options? Keeping track of individual options allows for capacity management and planning. A run of idnits revealed a few warnings: Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 99 has weird spacing: '...enience along...' -- The document date (April 17, 2017) is 79 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IA-draft' is mentioned on line 390, but not defined == Unused Reference: 'RFC7356' is defined on line 540, but no explicit reference was found in the text == Outdated reference: draft-ietf-trill-directory-assist-mechanisms has been published as RFC 8171 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- From nobody Wed Jul 5 14:21:29 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94019131DEC for ; Wed, 5 Jul 2017 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 vjKJtdOne3rg for ; Wed, 5 Jul 2017 14:21:10 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 B6B5A131DE1 for ; Wed, 5 Jul 2017 14:21:07 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id y70so506341vky.3 for ; Wed, 05 Jul 2017 14:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ypmNCJ5tpUYBBtW6z5rFClnHI6OoFjhfc1gORxAQC5M=; b=B9jkYbMC7HbC/6HaG4yjsdlEnSeS245W5IhoTUZ+l8zqjfDDL5csTJMBdMKtceF97i tgxXnmak5gKGvbywKBkFD4HcjKERXIivO2veBBxzjgOi7nVr9f+oPRXSa5oRjZly9LvN EpFrJSJvld3+s00Es0T7+N6lc3kxxci9E07nD3F3yTik5xWEET08ogFP1LiEhWx6gf9J Z183Ob7TRDgUV351Brl51dWIglPGw4H+HFMJ7lrwPTFh+2RFW/xxN/Tz56tQ2ee+l1CC FEuNjp6fHZ3tQHC0O2MLIdV4SsvvKg3OZrL1l1JLP94G0vkysYEN8Mk6xi39e8VCJhxY pTMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ypmNCJ5tpUYBBtW6z5rFClnHI6OoFjhfc1gORxAQC5M=; b=LpM+VBlhLsMA8PWXr2v0GhXd1vnAGoILqH+K64X7Mwr6UBU9xD6WZ0PJNXT75Bcr3t yh4vYR83U2/FGIZ6P6I4iMtQDx2T6YN8USiiiy/fXgz560mhloh74MNZ9iiClhBtARa+ jGIVCz2fywl3vKEZIbCGsOFST3M4uv/Vd8nXt5jCoU3+OiytDw7MJYJsxzkx4I91/QuK HZhpay0JJ+Z8j8gp/NcGLzK+H98zQspUJxhjafb2jCrlEle0kB5spZeNjbjOx2WgQSjm LvzZfZZ/hlxTNkmyeK47uJuzamlShNb5PDyged9qWqv5F+tVrBKG+XQIFAEuhVbur+6m jipA== X-Gm-Message-State: AIVw111K0lKgDYBxtib3T3yei9ya6lvK8fmYga1EegPEFp2whzfKNMIq /MLTYcrE74JvtT+FbWtDfkHNzRgdMTGy X-Received: by 10.31.75.66 with SMTP id y63mr3967308vka.65.1499289666622; Wed, 05 Jul 2017 14:21:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.165 with HTTP; Wed, 5 Jul 2017 14:20:26 -0700 (PDT) In-Reply-To: <149925973580.17545.6979655005275084891@ietfa.amsl.com> References: <149925973580.17545.6979655005275084891@ietfa.amsl.com> From: Warren Kumari Date: Wed, 5 Jul 2017 17:20:26 -0400 Message-ID: To: Magnus Westerlund Cc: tsv-art@ietf.org, draft-ietf-trill-mtu-negotiation.all@ietf.org, IETF Discuss , trill@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [trill] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:21:12 -0000 I wanted to quickly thank Magnus for this review - it is well thought out, and clear. I usually focus on the OpsDir reviews, but wanted to explicitly call this out as a good one. W On Wed, Jul 5, 2017 at 9:02 AM, Magnus Westerlund wrote: > Reviewer: Magnus Westerlund > Review result: Not Ready > > This TSV-ART review is influenced by that I did the review of > draft-ietf-trill-over-ip. > > 1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for > determining if the UDP encapsulation will work or not. It references in > Section 8.4 the old RFC, i.e. RFC 6325, which is updated by > draft-ietf-trill-mtu-negotiation. > > TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in > [RFC7177], can be used to obtain added assurance of the MTU of a > link. > > However, this is not quite true, as if the IP path MTU is below 1470 > bytes, which is not unheard of, the algorithm in the MTU negotiation > draft can't determine it. It will only report the IP path as having an > MTU to small when the 1470 bytes probe fail. > > So, if the trill-over-ip authors want to use this as a mechanism, then the MTU > negotiation draft needs to be expanded to have more flexible lower > boundaries. However, that appear to affect MTU negotiation quite > significant as it needs to separate algorithm for finding MTU, from the > different usage of the algorithm with different starting points. Where > the normal will have a lower bound of 1470, and be more tightly coupled > to Sz when finding Lz. While the Trill-over-IP has a different usage. > > I think the trill WG needs to decide on how to slice this. If the > MTU-negotiation only targets the explicit targets in the current draft and goes > forward now. Or if they want to meet trill-over-ip's goals which will require > restructuring. > > 2. Another issue, is that I think the algorithm is a bit short on > transmission scheduling recommendations: > > 1) If RB1 successfully receives the MTU-ack from RB2 to the probe of > the value of link-wide Lz within k tries (where k is a > configurable parameter whose default is 3), link MTU size is set > to the size of link-wide Lz and stop. > > If I do this test with all three packets back to back at line rate, I could > potentially get all probes lost in the same burst loss in router queue or > switch fabric. What I think is needed here is a specification on how these > probes are transmitted. Spaced in a particular way, or at least minimal > distance, and are the additional probes only sent after the previous has been > judged to have been lost, which makes it interact with the next issue. > > 3. This is also unclear on what the criteria is for determining that something > is lost: > > a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1 > sets the "failed minimum MTU test" flag for RB2 in RB1's Hello > and stop. > > I fail to see any specification for the criteria when an MTU-ack should be > considered to have failed to reach the probing entity. So this appear to > require a timeout, and thus a timeout interval. Is the RTT known so that one > can define something as lost after N*RTT? Are there possible delays in sending > the MTU-ack that are considered okay that can affect this? > > 4. Section 3, the algorithm in Step 1 is unable to reach the first termination > condition (3) "If lowerBound >= upperBound" in some cases. > > Step 1: RB1 tries to send an MTU-probe padded to the size x. > > 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: > > upperBound is set to x and x is set to [(lowerBound + > upperBound)/2], rounded up to the nearest integer. > > 2) If RB1 receives an MTU-ack to a probe of size x from RB2: > > link MTU size is set to x, lowerBound is set to x and x is set > to [(lowerBound + upperBound)/2], rounded up to the nearest > integer. > > 3) If lowerBound >= upperBound or Step 1 has been repeated n times > (where n is a configurable parameter whose default value is 5), > stop. > > 4) Repeat Step 1. > > I run this on the input data: Lower bound = 1470, Upper bound = 9216 and with > an MTU of 7935 and gets the following sequence: > > Lower Upper X > 1470 9216 5343 > 5343 9216 7280 > 7280 9216 8248 > 7280 8248 7764 > 7764 8248 8006 > 7764 8006 7885 > 7885 8006 7946 > 7885 7946 7916 > 7916 7946 7931 > 7931 7946 7939 > 7931 7939 7935 > 7935 7939 7937 > 7935 7937 7936 > 7935 7936 7936 > 7935 7936 7936 > > Thus, the termination condition needs to change. The second I notice is that > having a limitation on number of steps as 5, results in quite a large gap > between upper and lower bound in which the MTU exists in. > > 5. I frankly gets confused by the application of the binary search. First it > will in many case not be run to termination where the actual MTU is determined. > Then the result of the upper and lower bound are just used to confirm the Sz > value. There are no discussion about using the MTU search to determine a new > possible value for Sz. The text is not even explicit that lower bound is the > highest known to work Transmission unit size at the time of testing. I think > section 3, should conclude in determine some TU value, and if that is Sz or > something other appears quite relevant for what to do in the later sections. > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jul 6 01:48:45 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F80C1287A0; Thu, 6 Jul 2017 01:48:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, skh@ndzh.com, trill@ietf.org, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149933091651.22659.8387226280694049786.idtracker@ietfa.amsl.com> Date: Thu, 06 Jul 2017 01:48:36 -0700 Archived-At: Subject: [trill] Benoit Claise's No Objection on draft-ietf-trill-arp-optimization-08: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 08:48:36 -0000 Benoit Claise has entered the following ballot position for draft-ietf-trill-arp-optimization-08: No Objection 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-trill-arp-optimization/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Can you clarify on which device type you need to enable the following option: TRILL already provides an option to disable data-plane learning from the source MAC address of end-station frames on a per port basis (see Section 5.3 of [RFC6325]). - 1) IP address - indicated protocol address that is normally an IPv4 address in ARP or an IPv6 address in ND. "normally"? I've seen the term "Non-zero IP" later on in the draft Below is Mahesh's OPS DIR review I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-trill-arp-optimization-08 Summary: Ready with Nits Document Status: Standard Track General Comments: The abstract of the document says that the draft tries “To reduce the burden on a TRILL campus caused by these multi-destination messages, RBridges MAY implement an "optimized ARP/ND response", as specified herein, when the target's location is known by the ingress RBridge or can be obtained from a directory. This avoids ARP/ND query and answer flooding.” Implementation of this draft will impact the operations of the network. As such careful consideration should be placed on operational and management impact of the draft. The following comments look at the document both from an operational perspective as well as a management perspective. Operational Considerations: Operational considerations include installation and initial setup, migration path, requirements on other protocols, impact on network operations and verification of correct operation. >From an impact on network operations perspective, this draft proposes to reduce the traffic in the network by preventing a network wide broadcast and multicast of messages. As such it should reduce the impact on the network, when operating correctly. In the worst case, that it is not operating or operating incorrectly, these network broadcast and multicast messages will “leak” into the broader network, where they will be treated just as they are in todays network. For this reason, a migration path may not be required, or existing protocols modified to deal with the change. >From a verification of correct operations, it is not clear how one determines that the RBridge is operating correctly beyond observing individual ARP/ND messages. Does it keep track of ARP/ND messages it has intercepted and responded to on the local network, which would have escaped to the broader network? Keeping track of statistics will allow for tracking the operation of what is defined in the draft. Management Considerations: Management considerations include interoperability, fault management, configuration management, accounting, performance and security. >From a configuration management perspective, it is not clear how the configuration of the RBridge is realized. For example, per the draft, RBridge might not verify an IP address if the network manager's policy is to have the network behave, for each Data Label, as if it were a single link and just believe an ARP/ND it receives. If such a configuration is desired, this or an accompanying document needs to define the manageability aspect of RBridge, preferably in the form of a YANG model. >From a accounting perspective, For example, in the draft, RBridge could for generic ARP/ND request seeking the MAC address corresponding to an IP address, if the edge RBridge knows the IP address and corresponding MAC, behavior is as in item (a), otherwise behavior is as in item (b). Behavior for gratuitous ARP and ND Unsolicited Neighbor Advertisements [RFC4861] is given in item (c). And item (d) covers handling of Address Probe ARP Query. Are there specific statistics being maintained for each of these options? Keeping track of individual options allows for capacity management and planning. A run of idnits revealed a few warnings: Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 99 has weird spacing: '...enience along...' -- The document date (April 17, 2017) is 79 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IA-draft' is mentioned on line 390, but not defined == Unused Reference: 'RFC7356' is defined on line 540, but no explicit reference was found in the text == Outdated reference: draft-ietf-trill-directory-assist-mechanisms has been published as RFC 8171 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. From nobody Thu Jul 6 02:37:00 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B65120721; Thu, 6 Jul 2017 02:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 cCRMg0u4oisq; Thu, 6 Jul 2017 02:36:56 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 2D97E1201F8; Thu, 6 Jul 2017 02:36:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.167; From: "Susan Hares" To: "'Warren Kumari'" , "'The IESG'" Cc: , , References: <149928214838.19397.15366425287313778494.idtracker@ietfa.amsl.com> In-Reply-To: <149928214838.19397.15366425287313778494.idtracker@ietfa.amsl.com> Date: Thu, 6 Jul 2017 05:31:03 -0400 Message-ID: <00b601d2f63a$969e2b90$c3da82b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGTo1zNCZv4yY6Hcg1A2t4aPfsa/aLFKRPQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [trill] Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 09:36:59 -0000 Warren: As the shepherd, thank you for your comments and DISCUSS. Part of this discuss appears to be a process discuss on: 1) What you want to see in the shepherd's report 2) How you want to see discussions represented on the mail list. It is always a pleasure to readjust shepherd's reports to answer the current IESG questions as opposed to the previous year's IESG questions. Shepherd and WG chairs serve to enlighten IESG, and I am glad to provide any details I can for you. Let me provide you the background: 1) 2015 IESG member - So, previous IESG members like to see the mail list comments without any editorializing. Hence, this format 2) Relevant vibrant discussion occurred in face-to-face meetings at IETF meetings. The TRILL WG transition between the INT and RTG WG area and we have been pushing documents through at best possible speed. You will note a steady progression of drafts in the history. Why so lengthy a time? First, the transition of the area required that the RTG-DIR reviews occurred. Until our current Routing ADs revised the RTG-DIR QA review process to be like the OPS-DIR review process, TRILL reviews were simply not being processed. Second, we were getting feedback slowly from other groups. I see interesting feedback from Transport based on the new Transport review system that we may take back to the WG. I am not quite clear on all of Magnus' points - but at least it is substantive reviews. Our previous "no comment" state plus the stall in the review process for 1 year - has a tendency to make WGs stall. As Alia may have mentioned, we are trying to complete all of these drafts and publish these drafts. 3) Finally, we started with 3 companies: Huawei, cisco, and brocade - with pre-standards or standards. Due to business environments, the three companies are now: Huawei, IP-Infusion, and the legacy work in brocade and cisco. So, please let me know what you want in the shepherd's report. If this type of history is useful, I am happy to provide this level of discussion in the shepherd's reports. Or more details on the specific pros/cons of the discussion. 3) updates/news - Again, previous reviews had said this was not useful information. Such statements, is "why include this information?" Tends to make people less interested in including this in the future. Donald Eastlake and other authors who used to include this - stopped putting it in. If you would like the update information as an appendix, we can add it. Thank you for your excellent process questions. Sue Hares -----Original Message----- From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Wednesday, July 5, 2017 3:16 PM To: The IESG Cc: draft-ietf-trill-mtu-negotiation@ietf.org; trill-chairs@ietf.org; shares@ndzh.com; trill@ietf.org Subject: [trill] Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT) Warren Kumari has entered the following ballot position for draft-ietf-trill-mtu-negotiation-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-trill-mtu-negotiation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1: Instead of answering the questions, the Shepherd Writeup just has links to things - for example: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG LC: Passed: https://www.ietf.org/mail-archive/web/trill/current/msg07304.html Discussion: https://www.ietf.org/mail-archive/web/trill/current/msg07210.html This caused me to go investigate further - it seems that there were only 4 comments received during WGLC (excluding the RtgDir review, a short exchange with Julien Meuric). The comments which *were* received largely just fell into the "Support" (with no real discussion) category. The document was adopted 06 March 2015, and then there were a few automated mentions of it (e.g [0], [1]), but I see no real discussion of the draft *in the WG*. It is entirely possible that my search fu is weak today, and that there has been sufficient discussion and review of the draft (or that none was needed because it is so obviously right and pure, but I'd like some reassurance of that), especially because a quick review found multiple readability issues / nits. Note: I'm not holding the discuss on the readability / nits, rather on has the process been followed / is there consensus grounds 2: The document also says that it Updates: 6325, 7177, 7780 - but I don't see clear discussion of the Updates (OLD / NEW). [0]: https://mailarchive.ietf.org/arch/msg/rtg-dir/c863sUajt86YB_d62uWfF5Hd_X4 [1]: https://mailarchive.ietf.org/arch/msg/i-d-announce/p5ROVvvoU0B3S1OA2SY3vebX_ b4 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Major: I found much of the document really hard to read - I approve of the concept / see the need for this, but reading the document itself is not well written. Nits: General RFC 6325 says: "4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size In a stable campus, there must ultimately be agreement among all RBridges on the value of "Sz", the minimum acceptable inter-RBridge link size for the campus, for the proper operation of TRILL IS-IS." and this document says: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" " Ok, so Sz is campus-wide -- but, for some reason this document has ~35 instances of "campus-wide Sz" - can you just drop the "campus-wide"? Is there any time the Sz would not be campus-wide? Section 1. "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" to ensure that link state flooding operates properly and all RBridges converge to the same link state." This is really hard to parse - the bit before the hyphen is fine, but then it gets muddled. Perhaps: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called "Sz") to ensure that link state flooding operates properly and all RBridges converge to the same link state." "By calculating and using Lz as specified herein, link-scoped PDUs can be formatted greater than the campus-wide Sz up to the link-wide minimum acceptable inter- RBridge MTU size potentially improving the efficiency of link utilization and speeding link state convergence." "formatted" seems clumsy - perhaps just drop it? Or reorder to be "link-scoped PDUs larger than Sz, up to ... can be used"? O: "The new MTU size testing method specified in this document is backward compatible to the old one." P: "The new MTU size testing method specified in this document is backward compatible with the old one." C: Grammar O: "Link-wide Lz is the minimum Lz supported and agreed between all RBridges on a specific link." P: "Link-wide Lz is the minimum Lz supported and agreed amongst all RBridges on a specific link." C: Between only if two. Section 2. Link-Wide TRILL MTU Size O: "These PDUs are exchanged just on the local link." P: "These PDUs are exchanged only on the local link." O: "They use that flooding to exchange their maximally supportable value of "Lz"." P: "They use that flooding to exchange their maximum supported value of "Lz"." C: Maximally would be an adverb, describing the process of maximizing the flooding (or something). Section 2.1: O: "Lz MAY be reported using a originatingSNPBufferSize TLV that occurs" P: "Lz MAY be reported using an originatingSNPBufferSize TLV that occurs" C: I think. O: "If RB2 sends PDUs formatted in chunk of size 1800, it will be discarded by B1." P: "If RB2 sends PDUs formatted in chunks of size 1800, they will be discarded by B1." C: chunks is plural. Section 6: "The CSNPs and PSNPs MUST be formatted in chunks of size at most the link-wide Lz but are processed normally if received larger than that size." -- why the MUST? Is this supposed to be an instance of the sender being conservative and the receiver liberal? It so, I think it would be better to be much clearer. Section 7: O: "Unlike RBridges, end stations do not participate in the exchange of TRILL IS-IS PDUs, therefore they cannot grasp the traffic link MTU size from a TRILL campus automatically. " C: should be a semicolon and not a comma before therefore, and a comma after therefore. Section 8. Backwards Compatibility O: "This will act properly although it may not be as efficient as it would be if all RBridges on the link are Lz-aware." P: "This will act properly although, it may not be as efficient as it would be if all RBridges on the link are Lz-aware." C: Missing comma. "Then the path MTU can be set as the smallest tested link MTU on this path and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." -- instead: "Then, the path MTU can be set as the smallest tested link MTU on this path; and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill From nobody Thu Jul 6 03:12:59 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848BE127241; Thu, 6 Jul 2017 03:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 MhuovpX4UdfQ; Thu, 6 Jul 2017 03:12:50 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A626E12702E; Thu, 6 Jul 2017 03:12:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.5.167; From: "Susan Hares" To: "'Eric Rescorla'" , "'The IESG'" Cc: , , , References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> In-Reply-To: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> Date: Thu, 6 Jul 2017 06:06:57 -0400 Message-ID: <004201d2f63f$9ad86090$d08921b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01D2F61E.13CEFDF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG2C0XqA3D6Dqxt00xKejUXJSUYyKKAYDQw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 10:12:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0043_01D2F61E.13CEFDF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Eric:=20 =20 Thank you for your comments and questions. The text of this email = requests clarification on your discuss so that I may aid the authors in = adjusting the draft. I have included my question inline below. =20 Sue Hares =20 -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Wednesday, July 5, 2017 7:39 AM To: The IESG Cc: draft-ietf-trill-arp-optimization@ietf.org; trill-chairs@ietf.org; = skh@ndzh.com; trill@ietf.org Subject: Eric Rescorla's Discuss on = draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) =20 Eric Rescorla has entered the following ballot position for draft-ietf-trill-arp-optimization-08: Discuss =20 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.) =20 =20 Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 > It's not clear to me how the security properties of this mechanism = compare to existing TRILL. The text says: >=20 > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be > easily forged. Therefore the learning of MAC/IP addresses by RBridges > from ARP/ND should not be considered as reliable. See Section 4.1 for > SEND Considerations. =20 > "not considered as reliable" seems suboptimal. You need to cover how = this mechanism compares to the non-use of this mechanism. =20 Question 1: Are you asking how the "ARP/ND" is unreliable? Is this not = documented adequately in the SEND documentation?=20 Are you asking why the learning of MAC/IP addresses by the RBRIDGE using = ARP/ND is not reliable in addition to the issues raised by the SEND = document? =20 =20 > This document seems very sketchy on what you do when you get duplicate = IPs. >=20 > In the case where the former owner replies, a Duplicate Address has > been detected. In this case the querying RBridge SHOULD log the > duplicate so that the network administrator can take appropriate > action. =20 > How does logging solve the problem? Question 2: Logging allows the network management systems to detect the = problem, and determine if SEND should be used or if other security = measures should be taken. Are you looking for other mechanisms outside = of SEND?=20 =20 > What do you reply to ARPs with and/or propagate to other nodes?=20 > Do you tell the originator of the advertisement you have a duplicate? =20 Question 3: Are you specifically asking about the reply to duplicate = address detection ARPs in the first question? Are you looking for a = specific answer to second part of this question. In my understanding of = security (which is limited compared to yours), I would not recommend = responding to the originator of the advertisement that there is a = duplicate since this might aid attacks on the valid originator. =20 Can you provide additional input on what you'd like to see here? =20 =20 =20 > When a newly connected end-station exchanges messages with a DHCP > [RFC2131] server an edge RBridge should snoop them (mainly the > DHCPAck message) and store IP/MAC mapping information in its ARP/ND > cache and should also send the information out through the TRILL > control plane using ESADI. =20 What happens if the attacker sets up a fake DHCP server and pretends to = assign addresses to himself? It seems like maybe that's the same as fake = ARPs but maybe not. =20 In general, the security considerations need a complete threat analysis = per 3552. =20 Question 4: Can you provide someone from the SEC-DIR to provide a review = for a threat analysis per RFC3552. =20 =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 S 2. =20 plane on the edge RBridges, it should be possible to completely suppress flooding of ARP/ND messages in a TRILL Campus, When all end- station MAC addresses are similarly known, it should be possible to suppress unknown unicast flooding by dropping any unknown unicast received at an edge RBridge. =20 Are these "should be possibles" normative? Descriptive? =20 S 4. This is a sequence of steps, so it would be nice to preface them with a = list of the steps. It's also odd to have SEND considerations right in = the middle here. =20 =20 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP Please = explain what a non-zero IP is and why it's relevant. This graf also needs an introductory sentence or something before the = bullets. =20 =20 S 4.4. It is not essential that all RBridges use the same strategy for which option to select for a particular ARP/ND query. It is up to the implementation. =20 This seems inconsistent with the MUST in arm (b) below, because I can = just take some other arm. It's also kind of surprising to be this = non-prescriptive. =20 =20 S 8. some other location (MAC/VM Mobility) and gets connected to egde- =20 Nit: edge is mispelled. =20 =20 ------=_NextPart_000_0043_01D2F61E.13CEFDF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Eric: =

 

Thank you for your comments and questions. = =C2=A0The text of this email requests clarification on your discuss so = that I may aid the authors in adjusting the draft.=C2=A0=C2=A0 I have = included my question inline below.

 

Sue = Hares

 

-----Original Message-----

From: Eric Rescorla [mailto:ekr@rtfm.com]

Sent: Wednesday, July 5, 2017 7:39 = AM

To: The IESG

Cc: draft-ietf-tri= ll-arp-optimization@ietf.org; trill-chairs@ietf.org; skh@ndzh.com; trill@ietf.org

Subject: Eric Rescorla's Discuss on = draft-ietf-trill-arp-optimization-08: (with DISCUSS and = COMMENT)

 

Eric Rescorla has entered the following ballot = position for

draft-ietf-trill-arp-optimization-08: = 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-trill-arp-optimization/

 

 

 

----------------------------------------------------= ------------------

DISCUSS:

----------------------------------------------------= ------------------

 

> = It's not clear to me how the security properties of this mechanism = compare to existing TRILL. The text says:

> 

>=C2=A0 Unless Secure ND (SEND [RFC3971]) is = used, ARP and ND messages can be

>=C2=A0 easily forged. Therefore the learning of = MAC/IP addresses by RBridges

> = from ARP/ND should not be considered as reliable. See Section 4.1 = for

>=C2=A0 SEND = Considerations.

 

> = "not considered as reliable" seems suboptimal. You need to = cover how this mechanism compares to the non-use of this = mechanism.

 

Question 1:=C2=A0 Are you asking how the = "ARP/ND" is unreliable?=C2=A0 Is this not documented = adequately in the SEND documentation?

Are you asking why the learning of MAC/IP addresses = by the RBRIDGE using ARP/ND is not reliable in addition to the issues = raised by the SEND document?=C2=A0=C2=A0

 

> = This document seems very sketchy on what you do when you get duplicate = IPs.

> 

>=C2=A0 In the case where the former owner = replies, a Duplicate Address has

> been detected. In this case the querying = RBridge SHOULD log the

>=C2=A0 = duplicate so that the network administrator can take = appropriate

> = action.

 

> How does logging solve the = problem?

Question 2: Logging = allows the network management systems to detect the problem, and = determine if SEND should be used or if other security measures should be = taken.=C2=A0 Are you looking for other mechanisms outside of SEND? =

 

> What do you reply to ARPs with and/or = propagate to other nodes?

> Do = you tell the originator of the advertisement you have a = duplicate?

 

Question 3: Are you specifically asking about the = reply to duplicate address detection ARPs in the first question? = =C2=A0Are you looking for a specific answer to second part of this = question.=C2=A0 In my understanding of security (which is limited = compared to yours), I would not recommend responding to the originator = of the advertisement that there is a duplicate since this might aid = attacks on the valid originator.=C2=A0=C2=A0

Can you provide additional input on what you'd like = to see here?=C2=A0

 

 

> = When a newly connected end-station exchanges messages with a = DHCP

>=C2=A0 [RFC2131] server = an edge RBridge should snoop them (mainly the

>=C2=A0 DHCPAck message) and store IP/MAC = mapping information in its ARP/ND

>=C2=A0 cache and should also send the = information out through the TRILL

>=C2=A0 control plane using = ESADI.

 

What happens if the attacker sets up a fake DHCP = server and pretends to assign addresses to himself? It seems like maybe = that's the same as fake ARPs but maybe not.

 

In = general, the security considerations need a complete threat analysis per = 3552.

 

Question 4: Can you provide someone from the = SEC-DIR to provide a review for a threat analysis per RFC3552.=C2=A0 =

 

 

 

----------------------------------------------------= ------------------

COMMENT:

----------------------------------------------------= ------------------

 

S = 2.

 

=C2=A0=C2=A0 plane on the edge RBridges, it should = be possible to completely

=C2=A0=C2=A0 suppress flooding of ARP/ND messages = in a TRILL Campus, When all end-

=C2=A0=C2=A0 station MAC addresses are similarly = known, it should be possible to

=C2=A0=C2=A0 suppress unknown unicast flooding by = dropping any unknown unicast

=C2=A0=C2=A0 received at an edge = RBridge.

 

Are these "should be possibles" = normative? Descriptive?

 

S = 4.

This is a sequence of steps, so = it would be nice to preface them with a list of the steps. It's also odd = to have SEND considerations right in the middle here.

 

 

4.3 = Get Sender's IP/MAC Mapping Information for Non-zero IP Please explain = what a non-zero IP is and why it's relevant.

This graf also needs an introductory sentence or = something before the bullets.

 

 

S = 4.4.

=C2=A0=C2=A0 It is not = essential that all RBridges use the same strategy for = which

=C2=A0=C2=A0 option to = select for a particular ARP/ND query. It is up to the

=C2=A0=C2=A0 implementation.

 

This = seems inconsistent with the MUST in arm (b) below, because I can just = take some other arm. It's also kind of surprising to be this = non-prescriptive.

 

 

S = 8.

=C2=A0=C2=A0 some other = location (MAC/VM Mobility) and gets connected to egde-

 

Nit: = edge is mispelled.

 

 

------=_NextPart_000_0043_01D2F61E.13CEFDF0-- From nobody Thu Jul 6 06:07:18 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A653713163C for ; Thu, 6 Jul 2017 06:07:10 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 RvLZzbbrQxqN for ; Thu, 6 Jul 2017 06:07:08 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 43ACF131739 for ; Thu, 6 Jul 2017 06:07:05 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 84so542624ybe.0 for ; Thu, 06 Jul 2017 06:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kS5znJkh3QngGP/93vA4FDyvZzkuEcZfficIkSFSOMY=; b=XPvDJVc4IfFdV3oD5D3eh3pOs5z87HlrecRyJGt35XLceC0qjg3QNSjVTgaJOh/nRi qvmokhEOc0qn3iFBMfMRIPMdLkc4TiztXoFFSQpoKZnUH+mHuUdUkpjJGYJ5UuLicIjh 2rc1RSln78jx++smcJUy57liB8o+zcv0PN4L3SyunylBpj3mV8pzqLtoknfUBAtZjYEu rpOY+q4jt34rFwiJLKPXXzOC29Kcy9ZsIjbEyRYlyhQRXVGcbair0t9VZUKzLcKRg04e Rj6zGEA5aRiXOM5BROcFJwBNSxuiKhvCtd6ipmMXMJ4Y9NjAruJSuprGgaKtLOdOSGsY Z2lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kS5znJkh3QngGP/93vA4FDyvZzkuEcZfficIkSFSOMY=; b=c7PbksKUC76Q6O3p+gOTcsWHCEs4wffDyVF2N1QiAaGzOxc+G8e398xe9TEgkSSZMd F3YOnkHc2ycLGd/Gs03EU67gigo2kmw3N2Lx7iGDFfeqU1fwLfkBqXCykRRWXbLBAvkT 4pWyRqnhqJoHmcXoBZ2eTHesTU6/OsExK2TMj7I4XYMVqkzbq0duahpZmypCnxz20K2F RG9GKK8L6ADCwjx3y9euxlB0qPLonQiKj5Ni8WIR1dZ7fMowy9qN0y3bIzza0E350Yuo y3MZZj4rsohrWvbiNxFl+NRsxyRmncEs/t3ZLWpjRxmOFWgZ2CydEO+s+R7XUs4HTRjX Vffg== X-Gm-Message-State: AIVw111Bt09URnhEqfeb9M/HI4FW4JQFhG7RCfZdY+I0Bq0p8iCSAPS+ jDImAmse43tbi0+mQFvtnrXJZvlLR5el X-Received: by 10.37.48.67 with SMTP id w64mr96825ybw.89.1499346424217; Thu, 06 Jul 2017 06:07:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Thu, 6 Jul 2017 06:06:23 -0700 (PDT) In-Reply-To: <004201d2f63f$9ad86090$d08921b0$@ndzh.com> References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> <004201d2f63f$9ad86090$d08921b0$@ndzh.com> From: Eric Rescorla Date: Thu, 6 Jul 2017 06:06:23 -0700 Message-ID: To: Susan Hares Cc: The IESG , draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, skh@ndzh.com, trill@ietf.org Content-Type: multipart/alternative; boundary="001a114899c4030d5b0553a5cb0f" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 13:07:10 -0000 --001a114899c4030d5b0553a5cb0f Content-Type: text/plain; charset="UTF-8" On Thu, Jul 6, 2017 at 3:06 AM, Susan Hares wrote: > Eric: > > > > Thank you for your comments and questions. The text of this email > requests clarification on your discuss so that I may aid the authors in > adjusting the draft. I have included my question inline below. > > > > Sue Hares > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@rtfm.com ] > > Sent: Wednesday, July 5, 2017 7:39 AM > > To: The IESG > > Cc: draft-ietf-trill-arp-optimization@ietf.org; trill-chairs@ietf.org; > skh@ndzh.com; trill@ietf.org > > Subject: Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: > (with DISCUSS and COMMENT) > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-trill-arp-optimization-08: 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-trill-arp-optimization/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > > It's not clear to me how the security properties of this mechanism > compare to existing TRILL. The text says: > > > > > > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be > > > easily forged. Therefore the learning of MAC/IP addresses by RBridges > > > from ARP/ND should not be considered as reliable. See Section 4.1 for > > > SEND Considerations. > > > > > "not considered as reliable" seems suboptimal. You need to cover how > this mechanism compares to the non-use of this mechanism. > > > > Question 1: Are you asking how the "ARP/ND" is unreliable? Is this not > documented adequately in the SEND documentation? > > Are you asking why the learning of MAC/IP addresses by the RBRIDGE using > ARP/ND is not reliable in addition to the issues raised by the SEND > document? > Sorry, no. I'm saying that "not be considered reliable" is not operationalizable by the implementor. What are they supposed to do with information which is not reliable? More specifically, what is their security posture if they use the mechanism documented in this document versus if they do not? > > How does logging solve the problem? > > Question 2: Logging allows the network management systems to detect the > problem, and determine if SEND should be used or if other security measures > should be taken. Are you looking for other mechanisms outside of SEND? > This seems like it's of limited use if this actually is an attack. My experience with logging systems is that people don't check their logs very often unless they see a lot of errors. I've certainly seen duplicate IPs in small networks plenty of times, and I just ignore them. I assume others do as well. > > What do you reply to ARPs with and/or propagate to other nodes? > > > Do you tell the originator of the advertisement you have a duplicate? > > > > Question 3: Are you specifically asking about the reply to duplicate > address detection ARPs in the first question? Are you looking for a > specific answer to second part of this question. In my understanding of > security (which is limited compared to yours), I would not recommend > responding to the originator of the advertisement that there is a duplicate > since this might aid attacks on the valid originator. > > Can you provide additional input on what you'd like to see here? > I think the spec should take a position on how the implementation should behave when it encounters this situation. My general concern here is that you have a mechanism which has a known security vulnerability but the spec is pretty silent on how you should handle it when you have signs that it is being exploited. > > > > > > When a newly connected end-station exchanges messages with a DHCP > > > [RFC2131] server an edge RBridge should snoop them (mainly the > > > DHCPAck message) and store IP/MAC mapping information in its ARP/ND > > > cache and should also send the information out through the TRILL > > > control plane using ESADI. > > > > What happens if the attacker sets up a fake DHCP server and pretends to > assign addresses to himself? It seems like maybe that's the same as fake > ARPs but maybe not. > > > > In general, the security considerations need a complete threat analysis > per 3552. > > > > Question 4: Can you provide someone from the SEC-DIR to provide a review > for a threat analysis per RFC3552. > It's probably easier if I review it. If you're looking for a collaborator, let me know and I'll see who I can round up. -Ekr > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 2. > > > > plane on the edge RBridges, it should be possible to completely > > suppress flooding of ARP/ND messages in a TRILL Campus, When all end- > > station MAC addresses are similarly known, it should be possible to > > suppress unknown unicast flooding by dropping any unknown unicast > > received at an edge RBridge. > > > > Are these "should be possibles" normative? Descriptive? > > > > S 4. > > This is a sequence of steps, so it would be nice to preface them with a > list of the steps. It's also odd to have SEND considerations right in the > middle here. > > > > > > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP Please explain > what a non-zero IP is and why it's relevant. > > This graf also needs an introductory sentence or something before the > bullets. > > > > > > S 4.4. > > It is not essential that all RBridges use the same strategy for which > > option to select for a particular ARP/ND query. It is up to the > > implementation. > > > > This seems inconsistent with the MUST in arm (b) below, because I can just > take some other arm. It's also kind of surprising to be this > non-prescriptive. > > > > > > S 8. > > some other location (MAC/VM Mobility) and gets connected to egde- > > > > Nit: edge is mispelled. > > > > > --001a114899c4030d5b0553a5cb0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 6, 2017 at 3:06 AM, Susan Hares <shares@ndzh.com> wrote:

Eric:

=C2=A0

Thank you for your comments and que= stions.=C2=A0 The text of this email requests clarification on your discuss= so that I may aid the authors in adjusting the draft.=C2=A0=C2=A0 I have i= ncluded my question inline below.

=C2=A0

Sue Hares

=C2=A0

-----Original Message-----

From: Eric Rescorla [mailto:ekr@rtfm.com]

<= p class=3D"m_-1699063729099180967MsoPlainText">Sent: Wednesday, July 5, 201= 7 7:39 AM

= To: The IESG

Cc: draft-ietf-trill-arp-optimization@ietf.org; trill-chairs@ietf.org;= skh@ndzh.com; trill@ietf.org<= /u>

Subject: Eric Rescor= la's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUS= S and COMMENT)

=C2=A0

Eric Rescorla has entered the following ballot position = for

draft-= ietf-trill-arp-optimization-08: Discuss

=C2=A0

When responding, please keep the subject li= ne intact and reply to all email addresses included in the To and CC lines.= (Feel free to cut this introductory paragraph, however.)

=

=C2=A0

=C2=A0

Please refer to http= s://www.ietf.org/iesg/statement/discuss-criteria.html<= u>

for more informat= ion about IESG DISCUSS and COMMENT positions.

=C2=A0

=C2=A0

The document, along with other ballot positio= ns, can be found here:

https://datatracker.ietf.org/doc/d= raft-ietf-trill-arp-optimization/

=C2=A0

=C2=A0

=C2=A0

----------------------------------------------= ------------------------

DISCUSS:

---------------------------------------------------= -------------------

=C2=A0

> It's not clear to me how the security properties of th= is mechanism compare to existing TRILL. The text says:

>=C2=A0

>=C2=A0 Unless Secure ND (= SEND [RFC3971]) is used, ARP and ND messages can be

>=C2=A0 easily forged. Therefo= re the learning of MAC/IP addresses by RBridges

> from ARP/ND should not be cons= idered as reliable. See Section 4.1 for

>=C2=A0 SEND Considerations.=

=C2=A0

> "not considered = as reliable" seems suboptimal. You need to cover how this mechanism co= mpares to the non-use of this mechanism.

=C2=A0

Question 1:=C2=A0 Are you asking how the= "ARP/ND" is unreliable?=C2=A0 Is this not documented adequately = in the SEND documentation?

Are you asking why the learning of MAC/IP addresses by th= e RBRIDGE using ARP/ND is not reliable in addition to the issues raised by = the SEND document?=C2=A0=C2=A0

Sorry, no. = I'm saying that "not be considered reliable" is not operation= alizable by
the implementor. What are they supposed to do with in= formation which is not
reliable? More specifically, what is their= security posture if they use the mechanism
documented in this do= cument versus if they do not?=C2=A0
=C2=A0

> How does logging solve the problem?<= br>

Question 2: Logging allows th= e network management systems to detect the problem, and determine if SEND s= hould be used or if other security measures should be taken.=C2=A0 Are you = looking for other mechanisms outside of SEND?

<= div>
This seems like it's of limited use if this actually= is an attack. My experience
with logging systems is that people = don't check their logs very often unless
they see a lot of er= rors. I've certainly seen duplicate IPs in small networks
ple= nty of times, and I just ignore them. I assume others do as well.
=C2=A0

> What do you reply to ARPs = with and/or propagate to other nodes?

> Do you tell the originator of the adverti= sement you have a duplicate?

=C2=A0

Question 3: Are you specifically asking about the re= ply to duplicate address detection ARPs in the first question?=C2=A0 Are yo= u looking for a specific answer to second part of this question.=C2=A0 In m= y understanding of security (which is limited compared to yours), I would n= ot recommend responding to the originator of the advertisement that there i= s a duplicate since this might aid attacks on the valid originator.=C2=A0= =C2=A0

Ca= n you provide additional input on what you'd like to see here?=C2=A0

I think the spec should take a position on h= ow the implementation should behave when
it encounters this situa= tion. My general concern here is that you have a mechanism
which = has a known security vulnerability but the spec is pretty silent on how you= should
handle it when you have signs that it is being exploited.=
=C2=A0

=C2=A0=

=C2=A0=

> When a newly c= onnected end-station exchanges messages with a DHCP

>=C2=A0 [RFC2131] server an ed= ge RBridge should snoop them (mainly the

>=C2=A0 DHCPAck message) and store IP/MAC= mapping information in its ARP/ND

>=C2=A0 cache and should also send the informat= ion out through the TRILL

>=C2=A0 control plane using ESADI.

=C2=A0

What happens if the attacker sets = up a fake DHCP server and pretends to assign addresses to himself? It seems= like maybe that's the same as fake ARPs but maybe not.

=C2=A0

<= p class=3D"m_-1699063729099180967MsoPlainText">In general, the security con= siderations need a complete threat analysis per 3552.

=C2=A0

=

Question 4: Can you provide= someone from the SEC-DIR to provide a review for a threat analysis per RFC= 3552.

It's probably easier if I revie= w it. If you're looking for a collaborator, let me know and I'll se= e who I can round up.

-Ekr
=C2=A0

=C2=A0

=C2=A0

=C2=A0

---------------------------------------------------------= -------------

COMMENT:

----------------------------------------------------------------------

=C2=A0

S 2.

<= /u>=C2=A0

=C2=A0= =C2=A0 plane on the edge RBridges, it should be possible to completely

=C2=A0=C2=A0 s= uppress flooding of ARP/ND messages in a TRILL Campus, When all end-=

=C2=A0=C2=A0 sta= tion MAC addresses are similarly known, it should be possible to<= /u>

=C2=A0=C2=A0 suppres= s unknown unicast flooding by dropping any unknown unicast

=C2=A0=C2=A0 received at a= n edge RBridge.

=C2=A0

Are these "should be possibles" normative? Descriptive?=

=C2=A0=

S 4.<= /p>

This is a sequence of st= eps, so it would be nice to preface them with a list of the steps. It's= also odd to have SEND considerations right in the middle here.

=C2=A0<= /p>

=C2=A0

=

4.3 Get Sender's IP/MAC= Mapping Information for Non-zero IP Please explain what a non-zero IP is a= nd why it's relevant.

This graf also needs an introductory sentence or something = before the bullets.

=C2=A0

=C2=A0

S 4.4.

=C2=A0=C2=A0 It is not essential that all RBridges use the same strategy f= or which

= =C2=A0=C2=A0 option to select for a particular ARP/ND query. It is up to th= e

=C2=A0= =C2=A0 implementation.

=C2=A0

This seems inconsistent with the MUST in arm (b) below, because I= can just take some other arm. It's also kind of surprising to be this = non-prescriptive.

=C2=A0

=C2=A0

S 8.

=C2= =A0=C2=A0 some other location (MAC/VM Mobility) and gets connected to egde-=

= =C2=A0

Nit: edge = is mispelled.

=C2=A0

=C2=A0


--001a114899c4030d5b0553a5cb0f-- From nobody Thu Jul 6 13:06:51 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB97131536; Thu, 6 Jul 2017 13:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 TbFctdYDvjSv; Thu, 6 Jul 2017 13:06:31 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 73D9813196C; Thu, 6 Jul 2017 13:05:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.82.124; From: "Susan Hares" To: "'Eric Rescorla'" Cc: "'The IESG'" , , , , References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> <004201d2f63f$9ad86090$d08921b0$@ndzh.com> In-Reply-To: Date: Thu, 6 Jul 2017 16:00:01 -0400 Message-ID: <00d601d2f692$748f9270$5daeb750$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01D2F670.ED80FFB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG2C0XqA3D6Dqxt00xKejUXJSUYyAJG4NftAdyzEX+iX+/9UA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:06:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D7_01D2F670.ED80FFB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric: =20 Thank you for your answers. I will investigate the issues further and = work with the authors to suggest some text. May I or the authors follow = up with additional questions?=20 =20 Sue =20 =20 From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Thursday, July 6, 2017 9:06 AM To: Susan Hares Cc: The IESG; draft-ietf-trill-arp-optimization@ietf.org; = trill-chairs@ietf.org; skh@ndzh.com; trill@ietf.org Subject: Re: Eric Rescorla's Discuss on = draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) =20 =20 =20 On Thu, Jul 6, 2017 at 3:06 AM, Susan Hares wrote: Eric:=20 =20 Thank you for your comments and questions. The text of this email = requests clarification on your discuss so that I may aid the authors in = adjusting the draft. I have included my question inline below. =20 Sue Hares =20 -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Wednesday, July 5, 2017 7:39 AM To: The IESG Cc: draft-ietf-trill-arp-optimization@ietf.org; trill-chairs@ietf.org; = skh@ndzh.com; trill@ietf.org Subject: Eric Rescorla's Discuss on = draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) =20 Eric Rescorla has entered the following ballot position for draft-ietf-trill-arp-optimization-08: Discuss =20 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.) =20 =20 Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. =20 =20 The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ =20 =20 =20 ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =20 > It's not clear to me how the security properties of this mechanism = compare to existing TRILL. The text says: >=20 > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be > easily forged. Therefore the learning of MAC/IP addresses by RBridges > from ARP/ND should not be considered as reliable. See Section 4.1 for > SEND Considerations. =20 > "not considered as reliable" seems suboptimal. You need to cover how = this mechanism compares to the non-use of this mechanism. =20 Question 1: Are you asking how the "ARP/ND" is unreliable? Is this not = documented adequately in the SEND documentation?=20 Are you asking why the learning of MAC/IP addresses by the RBRIDGE using = ARP/ND is not reliable in addition to the issues raised by the SEND = document? =20 Sorry, no. I'm saying that "not be considered reliable" is not = operationalizable by the implementor. What are they supposed to do with information which is = not reliable? More specifically, what is their security posture if they use = the mechanism documented in this document versus if they do not?=20 =20 > How does logging solve the problem? Question 2: Logging allows the network management systems to detect the = problem, and determine if SEND should be used or if other security = measures should be taken. Are you looking for other mechanisms outside = of SEND? =20 This seems like it's of limited use if this actually is an attack. My = experience with logging systems is that people don't check their logs very often = unless they see a lot of errors. I've certainly seen duplicate IPs in small = networks plenty of times, and I just ignore them. I assume others do as well. =20 > What do you reply to ARPs with and/or propagate to other nodes?=20 > Do you tell the originator of the advertisement you have a duplicate? =20 Question 3: Are you specifically asking about the reply to duplicate = address detection ARPs in the first question? Are you looking for a = specific answer to second part of this question. In my understanding of = security (which is limited compared to yours), I would not recommend = responding to the originator of the advertisement that there is a = duplicate since this might aid attacks on the valid originator. =20 Can you provide additional input on what you'd like to see here?=20 I think the spec should take a position on how the implementation should = behave when it encounters this situation. My general concern here is that you have a = mechanism which has a known security vulnerability but the spec is pretty silent = on how you should handle it when you have signs that it is being exploited. =20 =20 =20 > When a newly connected end-station exchanges messages with a DHCP > [RFC2131] server an edge RBridge should snoop them (mainly the > DHCPAck message) and store IP/MAC mapping information in its ARP/ND > cache and should also send the information out through the TRILL > control plane using ESADI. =20 What happens if the attacker sets up a fake DHCP server and pretends to = assign addresses to himself? It seems like maybe that's the same as fake = ARPs but maybe not. =20 In general, the security considerations need a complete threat analysis = per 3552. =20 Question 4: Can you provide someone from the SEC-DIR to provide a review = for a threat analysis per RFC3552.=20 It's probably easier if I review it. If you're looking for a = collaborator, let me know and I'll see who I can round up. =20 -Ekr =20 =20 =20 =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =20 S 2. =20 plane on the edge RBridges, it should be possible to completely suppress flooding of ARP/ND messages in a TRILL Campus, When all end- station MAC addresses are similarly known, it should be possible to suppress unknown unicast flooding by dropping any unknown unicast received at an edge RBridge. =20 Are these "should be possibles" normative? Descriptive? =20 S 4. This is a sequence of steps, so it would be nice to preface them with a = list of the steps. It's also odd to have SEND considerations right in = the middle here. =20 =20 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP Please = explain what a non-zero IP is and why it's relevant. This graf also needs an introductory sentence or something before the = bullets. =20 =20 S 4.4. It is not essential that all RBridges use the same strategy for which option to select for a particular ARP/ND query. It is up to the implementation. =20 This seems inconsistent with the MUST in arm (b) below, because I can = just take some other arm. It's also kind of surprising to be this = non-prescriptive. =20 =20 S 8. some other location (MAC/VM Mobility) and gets connected to egde- =20 Nit: edge is mispelled. =20 =20 =20 ------=_NextPart_000_00D7_01D2F670.ED80FFB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Eric:

 

Thank you for your answers.=C2=A0 =C2=A0I will investigate the issues = further and work with the authors to suggest some text.=C2=A0 May I or = the authors follow up with additional questions? =

 

Sue =C2=A0

 

From:= = Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Thursday, July 6, = 2017 9:06 AM
To: Susan Hares
Cc: The IESG; = draft-ietf-trill-arp-optimization@ietf.org; trill-chairs@ietf.org; = skh@ndzh.com; trill@ietf.org
Subject: Re: Eric Rescorla's = Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and = COMMENT)

 

 

 

On Thu, = Jul 6, 2017 at 3:06 AM, Susan Hares <shares@ndzh.com> = wrote:

Eric:

 

Thank you for your comments = and questions.  The text of this email requests clarification on = your discuss so that I may aid the authors in adjusting the = draft.   I have included my question inline = below.

 

Sue Hares

 

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

From: Eric Rescorla [mailto:ekr@rtfm.com] =

Sent: = Wednesday, July 5, 2017 7:39 AM

To: The IESG

Cc: draft-ietf-trill-arp-optimization@ietf.org; trill-chairs@ietf.org; skh@ndzh.com; trill@ietf.org

Subject: Eric Rescorla's = Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and = COMMENT)

 

Eric Rescorla has entered the = following ballot position for

draft-ietf-trill-arp-optimizati= on-08: 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.ht= ml

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-trill-arp-o= ptimization/

 

 

 

-------------------------------= ---------------------------------------

DISCUSS:

-------------------------------= ---------------------------------------

 

> It's not clear to me how = the security properties of this mechanism compare to existing TRILL. The = text says:

> 

>  Unless Secure ND = (SEND [RFC3971]) is used, ARP and ND messages can be

>  easily forged. = Therefore the learning of MAC/IP addresses by RBridges

> from ARP/ND should not be = considered as reliable. See Section 4.1 for

>  SEND = Considerations.

 

> "not considered as = reliable" seems suboptimal. You need to cover how this mechanism = compares to the non-use of this mechanism.

 

Question 1:  Are you = asking how the "ARP/ND" is unreliable?  Is this not = documented adequately in the SEND documentation?

Are you asking why the = learning of MAC/IP addresses by the RBRIDGE using ARP/ND is not reliable = in addition to the issues raised by the SEND = document?  

Sorry, no. I'm saying that "not be considered = reliable" is not operationalizable by

the implementor. What are they supposed to do with = information which is not

reliable? More specifically, what is their security = posture if they use the mechanism

documented in this document versus if they do = not? 

 

> How does logging solve = the problem?

Question 2: Logging allows the = network management systems to detect the problem, and determine if SEND = should be used or if other security measures should be taken.  Are = you looking for other mechanisms outside of = SEND?

 

This seems like it's of limited use if this actually = is an attack. My experience

with logging systems is that people don't check their = logs very often unless

they see a lot of errors. I've certainly seen = duplicate IPs in small networks

plenty of times, and I just ignore them. I assume = others do as well.

 

> What do you reply to ARPs = with and/or propagate to other nodes?

> Do you tell the = originator of the advertisement you have a duplicate?

 

Question 3: Are you = specifically asking about the reply to duplicate address detection ARPs = in the first question?  Are you looking for a specific answer to = second part of this question.  In my understanding of security = (which is limited compared to yours), I would not recommend responding = to the originator of the advertisement that there is a duplicate since = this might aid attacks on the valid originator.   =

Can you = provide additional input on what you'd like to see = here? 

I think the spec should take a position on how the = implementation should behave when

it encounters this situation. My general concern here = is that you have a mechanism

which has a known security vulnerability but the spec = is pretty silent on how you should

handle it when you have signs that it is being = exploited.

 

 

 

> When a newly connected = end-station exchanges messages with a DHCP

>  [RFC2131] server an = edge RBridge should snoop them (mainly the

>  DHCPAck message) = and store IP/MAC mapping information in its ARP/ND

>  cache and should = also send the information out through the TRILL

>  control plane using = ESADI.

 

What happens if the attacker = sets up a fake DHCP server and pretends to assign addresses to himself? = It seems like maybe that's the same as fake ARPs but maybe = not.

 

In general, the security = considerations need a complete threat analysis per = 3552.

 

Question 4: Can you provide = someone from the SEC-DIR to provide a review for a threat analysis per = RFC3552.

It's probably easier if I review it. If you're looking = for a collaborator, let me know and I'll see who I can round = up.

 

-Ekr

 

 

 

 

-------------------------------= ---------------------------------------

COMMENT:

-------------------------------= ---------------------------------------

 

S 2.

 

   plane on the edge = RBridges, it should be possible to completely

   suppress flooding = of ARP/ND messages in a TRILL Campus, When all end-

   station MAC = addresses are similarly known, it should be possible to

   suppress unknown = unicast flooding by dropping any unknown unicast

   received at an = edge RBridge.

 

Are these "should be = possibles" normative? Descriptive?

 

S 4.

This is a sequence of steps, = so it would be nice to preface them with a list of the steps. It's also = odd to have SEND considerations right in the middle = here.

 

 

4.3 Get Sender's IP/MAC = Mapping Information for Non-zero IP Please explain what a non-zero IP is = and why it's relevant.

This graf also needs an = introductory sentence or something before the bullets.

 

 

S 4.4.

   It is not = essential that all RBridges use the same strategy for = which

   option to select = for a particular ARP/ND query. It is up to the

   = implementation.

 

This seems inconsistent with = the MUST in arm (b) below, because I can just take some other arm. It's = also kind of surprising to be this non-prescriptive.

 

 

S 8.

   some other = location (MAC/VM Mobility) and gets connected to egde-

 

Nit: edge is = mispelled.

 

 

 

------=_NextPart_000_00D7_01D2F670.ED80FFB0-- From nobody Thu Jul 6 13:52:10 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16460131963 for ; Thu, 6 Jul 2017 13:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 9XbG19s87245 for ; Thu, 6 Jul 2017 13:52:06 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002: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 43886131967 for ; Thu, 6 Jul 2017 13:52:02 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id v193so6143494ywg.2 for ; Thu, 06 Jul 2017 13:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6c4MDjwRsnKABGeJlcOvzhplJkM40YmNu79TGP0B8Wk=; b=OmTn05ZKKUcdaIFBDW7MKpaf6ARcbnLU2YjXiIDXQ6usnw9BQmsXOJiCqq+Md2bJoP 0CXDGP89vb+k3zioQG9ZkD6OjF0buQcGDkrCJTJpPKEeqGL3usATJr8P2gH2Y1ecl9Wb b8Q2poH1pU8zZbtqhdjB1VOpJ+GqhfUTGW0kRmVldJ3EWF/TfVVnqjINNuUSjbSVXx9M 1TEaICXnfjPLOCFtp+CSO/bXKWencjNZ1HHRg7VUp0QjNIRuBxONWQ11K6x/KhS1XGJz L6Ufc3Oz9BorStfExbAwxGonoC029VunCjjcKH6zOhcbwk8qwuRsDE/MwDQsrmSFtff9 /cRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6c4MDjwRsnKABGeJlcOvzhplJkM40YmNu79TGP0B8Wk=; b=TUoLN9thkxCmPLV+YFVyKlBYejF12i3j3YRyHAbXhooCnoSsHyPLxx7370AMU5NS7e /4QkYk1t9JlBI1FXBU7fGGX/r59WSRY5/2IcW3OxJ1aBJxzje0u11qU2E5526O1cbliW fyufTsxzJE0HTkeGJyMSlQdkwgzjZQ9mMUvoU8YE7rPtFrjTZKptMRUBHU3HqBJtg4xR BQ8CPPDC2OX03vpI3We+SVapksECD3NNFsDc6DU6Zgr7k5tOFPMHBT+4kAaMWipQSQwd +ns6fbsi+rbnhcCnm3VtowILL+9Dz4KnnAU9eE5KN6fbnKJURN/to4sQnhQq+U+UBewn 5QzQ== X-Gm-Message-State: AKS2vOzdUjPfSwUfnS7V9Zk80ZZDDzhW4PfffnwXWRS2cH9h+8lgSLnr RV0cqZVYcnxpFWW7RRfm1xNNV6L/bfj9 X-Received: by 10.129.109.206 with SMTP id i197mr33396754ywc.24.1499374321497; Thu, 06 Jul 2017 13:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Thu, 6 Jul 2017 13:51:21 -0700 (PDT) In-Reply-To: <00d601d2f692$748f9270$5daeb750$@ndzh.com> References: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com> <004201d2f63f$9ad86090$d08921b0$@ndzh.com> <00d601d2f692$748f9270$5daeb750$@ndzh.com> From: Eric Rescorla Date: Thu, 6 Jul 2017 13:51:21 -0700 Message-ID: To: Susan Hares Cc: The IESG , draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, skh@ndzh.com, trill@ietf.org Content-Type: multipart/alternative; boundary="001a114dd266d18a480553ac49c5" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 20:52:08 -0000 --001a114dd266d18a480553ac49c5 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 6, 2017 at 1:00 PM, Susan Hares wrote: > Eric: > > > > Thank you for your answers. I will investigate the issues further and > work with the authors to suggest some text. May I or the authors follow up > with additional questions? > Please. Let me know if I can help, elaborate, etc. -Ekr > > > Sue > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Thursday, July 6, 2017 9:06 AM > *To:* Susan Hares > *Cc:* The IESG; draft-ietf-trill-arp-optimization@ietf.org; > trill-chairs@ietf.org; skh@ndzh.com; trill@ietf.org > *Subject:* Re: Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: > (with DISCUSS and COMMENT) > > > > > > > > On Thu, Jul 6, 2017 at 3:06 AM, Susan Hares wrote: > > Eric: > > > > Thank you for your comments and questions. The text of this email > requests clarification on your discuss so that I may aid the authors in > adjusting the draft. I have included my question inline below. > > > > Sue Hares > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@rtfm.com ] > > Sent: Wednesday, July 5, 2017 7:39 AM > > To: The IESG > > Cc: draft-ietf-trill-arp-optimization@ietf.org; trill-chairs@ietf.org; > skh@ndzh.com; trill@ietf.org > > Subject: Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: > (with DISCUSS and COMMENT) > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-trill-arp-optimization-08: 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-trill-arp-optimization/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > > It's not clear to me how the security properties of this mechanism > compare to existing TRILL. The text says: > > > > > > Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be > > > easily forged. Therefore the learning of MAC/IP addresses by RBridges > > > from ARP/ND should not be considered as reliable. See Section 4.1 for > > > SEND Considerations. > > > > > "not considered as reliable" seems suboptimal. You need to cover how > this mechanism compares to the non-use of this mechanism. > > > > Question 1: Are you asking how the "ARP/ND" is unreliable? Is this not > documented adequately in the SEND documentation? > > Are you asking why the learning of MAC/IP addresses by the RBRIDGE using > ARP/ND is not reliable in addition to the issues raised by the SEND > document? > > Sorry, no. I'm saying that "not be considered reliable" is not > operationalizable by > > the implementor. What are they supposed to do with information which is not > > reliable? More specifically, what is their security posture if they use > the mechanism > > documented in this document versus if they do not? > > > > > How does logging solve the problem? > > Question 2: Logging allows the network management systems to detect the > problem, and determine if SEND should be used or if other security measures > should be taken. Are you looking for other mechanisms outside of SEND? > > > > This seems like it's of limited use if this actually is an attack. My > experience > > with logging systems is that people don't check their logs very often > unless > > they see a lot of errors. I've certainly seen duplicate IPs in small > networks > > plenty of times, and I just ignore them. I assume others do as well. > > > > > What do you reply to ARPs with and/or propagate to other nodes? > > > Do you tell the originator of the advertisement you have a duplicate? > > > > Question 3: Are you specifically asking about the reply to duplicate > address detection ARPs in the first question? Are you looking for a > specific answer to second part of this question. In my understanding of > security (which is limited compared to yours), I would not recommend > responding to the originator of the advertisement that there is a duplicate > since this might aid attacks on the valid originator. > > Can you provide additional input on what you'd like to see here? > > I think the spec should take a position on how the implementation should > behave when > > it encounters this situation. My general concern here is that you have a > mechanism > > which has a known security vulnerability but the spec is pretty silent on > how you should > > handle it when you have signs that it is being exploited. > > > > > > > > > When a newly connected end-station exchanges messages with a DHCP > > > [RFC2131] server an edge RBridge should snoop them (mainly the > > > DHCPAck message) and store IP/MAC mapping information in its ARP/ND > > > cache and should also send the information out through the TRILL > > > control plane using ESADI. > > > > What happens if the attacker sets up a fake DHCP server and pretends to > assign addresses to himself? It seems like maybe that's the same as fake > ARPs but maybe not. > > > > In general, the security considerations need a complete threat analysis > per 3552. > > > > Question 4: Can you provide someone from the SEC-DIR to provide a review > for a threat analysis per RFC3552. > > It's probably easier if I review it. If you're looking for a collaborator, > let me know and I'll see who I can round up. > > > > -Ekr > > > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 2. > > > > plane on the edge RBridges, it should be possible to completely > > suppress flooding of ARP/ND messages in a TRILL Campus, When all end- > > station MAC addresses are similarly known, it should be possible to > > suppress unknown unicast flooding by dropping any unknown unicast > > received at an edge RBridge. > > > > Are these "should be possibles" normative? Descriptive? > > > > S 4. > > This is a sequence of steps, so it would be nice to preface them with a > list of the steps. It's also odd to have SEND considerations right in the > middle here. > > > > > > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP Please explain > what a non-zero IP is and why it's relevant. > > This graf also needs an introductory sentence or something before the > bullets. > > > > > > S 4.4. > > It is not essential that all RBridges use the same strategy for which > > option to select for a particular ARP/ND query. It is up to the > > implementation. > > > > This seems inconsistent with the MUST in arm (b) below, because I can just > take some other arm. It's also kind of surprising to be this > non-prescriptive. > > > > > > S 8. > > some other location (MAC/VM Mobility) and gets connected to egde- > > > > Nit: edge is mispelled. > > > > > > > --001a114dd266d18a480553ac49c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 6, 2017 at 1:00 PM, Susan Hares <shares@ndzh.com> wrote:

Eric:

=

=C2=A0

Thank you for your = answers.=C2=A0 =C2=A0I will investigate the issues further and work with th= e authors to suggest some text.=C2=A0 May I or the authors follow up with a= dditional questions?


Please. Let me know if I can help, elaborate, etc.

-Ekr
=C2=A0

=

=C2=A0<= u>

Sue =C2= =A0

=C2=A0

Fro= m: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Thursday, July 6,= 2017 9:06 AM
To: Susan Hares
Cc: The IESG; draft-= ietf-trill-arp-optimization@ietf.org; trill-chairs@ietf.org; skh@ndzh.com; trill@ietf.org
Subject: Re: Eric = Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with = DISCUSS and COMMENT)

=C2=A0

= =C2=A0

=C2=A0

<= p class=3D"MsoNormal">On Thu, Jul 6, 2017 at 3:06 AM, Susan Hares <shares@ndzh.com> wro= te:

Eric:

=C2=A0

Thank you for y= our comments and questions.=C2=A0 The text of this email requests clarifica= tion on your discuss so that I may aid the authors in adjusting the draft.= =C2=A0=C2=A0 I have included my question inline below.

=C2=A0<= /u>

Sue Hares

=C2=A0

-----Original Message-----

From: Eric Rescorla [mailto:ekr@rtfm.com]

Sent: Wednesday, July 5, 2017 7:39 AM=

To: The IESG

Cc: draft-ietf-trill-arp-optimi= zation@ietf.org; trill-chairs@ietf.org; skh@ndzh.com; trill@ietf.org

Subject: Eric Rescorla's Discuss on draf= t-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)=

=C2=A0

Eric Rescorla has entered the following ballot position f= or

draft-ietf-trill-arp-optimization-08: Discuss

= =C2=A0

When responding, please keep the subject line intact and r= eply to all email addresses included in the To and CC lines. (Feel free to = cut this introductory paragraph, however.)

=C2=A0

=C2= =A0

Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html

for more information abou= t IESG DISCUSS and COMMENT positions.

=C2=A0

=C2=A0<= /u>

The document, along with other ballot positions, can be found here:<= u>

https://datatracker.ietf.org/doc/draf= t-ietf-trill-arp-optimization/

=C2=A0

<= p class=3D"m_7570586668808156856m-1699063729099180967msoplaintext">=C2=A0

=C2=A0

--------------------------------------------= --------------------------

DISCUSS:

--------------= --------------------------------------------------------

=C2=A0

> It's not clear to me how the security propertie= s of this mechanism compare to existing TRILL. The text says:=

>= ;=C2=A0

>=C2=A0 Unless Secure ND (SEND [RFC3971]) is used, ARP= and ND messages can be

>=C2=A0 easily forged. Therefore the l= earning of MAC/IP addresses by RBridges

> from ARP/ND should n= ot be considered as reliable. See Section 4.1 for

>=C2=A0 SEND= Considerations.

=C2=A0

> "not considered as re= liable" seems suboptimal. You need to cover how this mechanism compare= s to the non-use of this mechanism.

=C2=A0

Question 1:= =C2=A0 Are you asking how the "ARP/ND" is unreliable?=C2=A0 Is th= is not documented adequately in the SEND documentation?

<= p class=3D"m_7570586668808156856m-1699063729099180967msoplaintext">Are you = asking why the learning of MAC/IP addresses by the RBRIDGE using ARP/ND is = not reliable in addition to the issues raised by the SEND document?=C2=A0= =C2=A0

Sorry, no. = I'm saying that "not be considered reliable" is not operation= alizable by

the implemen= tor. What are they supposed to do with information which is not

reliable? More specifically, what i= s their security posture if they use the mechanism

<= div>

documented in this document versus if they do no= t?=C2=A0

=C2=A0

> = How does logging solve the problem?

Question 2: Logging allows th= e network management systems to detect the problem, and determine if SEND s= hould be used or if other security measures should be taken.=C2=A0 Are you = looking for other mechanisms outside of SEND?

=

=C2=A0

This seems like it's of limited use if this act= ually is an attack. My experience

with logging systems is that people don't check their logs ve= ry often unless

they see= a lot of errors. I've certainly seen duplicate IPs in small networks

plenty of times, and I ju= st ignore them. I assume others do as well.

=C2=A0

> What do you reply to ARPs with and/or pr= opagate to other nodes?

> Do you tell the originator of the a= dvertisement you have a duplicate?

=C2=A0

Question 3: A= re you specifically asking about the reply to duplicate address detection A= RPs in the first question?=C2=A0 Are you looking for a specific answer to s= econd part of this question.=C2=A0 In my understanding of security (which i= s limited compared to yours), I would not recommend responding to the origi= nator of the advertisement that there is a duplicate since this might aid a= ttacks on the valid originator.=C2=A0=C2=A0

Can you provide addi= tional input on what you'd like to see here?=C2=A0

I think the spec should t= ake a position on how the implementation should behave when

it encounters this situation. My genera= l concern here is that you have a mechanism

which has a known security vulnerability but the spec i= s pretty silent on how you should

handle it when you have signs that it is being exploited.<= u>

=C2=A0

<= blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">

=C2=A0<= /p>

=C2= =A0

> When a newly connected end-station exchanges messages wi= th a DHCP

>=C2=A0 [RFC2131] server an edge RBridge should snoo= p them (mainly the

>=C2=A0 DHCPAck message) and store IP/MAC m= apping information in its ARP/ND

>=C2=A0 cache and should also= send the information out through the TRILL

>=C2=A0 control pl= ane using ESADI.

=C2=A0

What happens if the attacker se= ts up a fake DHCP server and pretends to assign addresses to himself? It se= ems like maybe that's the same as fake ARPs but maybe not.

= =C2=A0

In general, the security considerations need a complete th= reat analysis per 3552.

=C2=A0

Question 4: Can you prov= ide someone from the SEC-DIR to provide a review for a threat analysis per = RFC3552.

It's probably easier if I review it. If you're looking for a c= ollaborator, let me know and I'll see who I can round up.=

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

=C2=A0

------------= ----------------------------------------------------------=

COMMENT:

-----------------------------------------------= -----------------------

=C2=A0

S 2.<= /p>

=C2= =A0

=C2=A0=C2=A0 plane on the edge RBridges, it should be possibl= e to completely

=C2=A0=C2=A0 suppress flooding of ARP/ND messages= in a TRILL Campus, When all end-

=C2=A0=C2=A0 station MAC addres= ses are similarly known, it should be possible to

=C2=A0=C2=A0 su= ppress unknown unicast flooding by dropping any unknown unicast

= =C2=A0=C2=A0 received at an edge RBridge.

=C2=A0

Are th= ese "should be possibles" normative? Descriptive?

=C2= =A0

S 4.

This is a sequence of steps, so it would be ni= ce to preface them with a list of the steps. It's also odd to have SEND= considerations right in the middle here.

=C2=A0

=C2=A0=

4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP = Please explain what a non-zero IP is and why it's relevant.

T= his graf also needs an introductory sentence or something before the bullet= s.

=C2=A0

=C2=A0

S 4.4.

=C2=A0=C2= =A0 It is not essential that all RBridges use the same strategy for which

=C2=A0=C2=A0 option to select for a particular ARP/ND query. It is= up to the

=C2=A0=C2=A0 implementation.

=C2=A0

This seems inconsistent with the MUST in arm (b) below, because I can jus= t take some other arm. It's also kind of surprising to be this non-pres= criptive.

=C2=A0

=C2=A0

S 8.

=C2=A0= =C2=A0 some other location (MAC/VM Mobility) and gets connected to egde-=

=C2=A0

Nit: edge is mispelled.

=C2=A0

=C2=A0

=C2=A0


--001a114dd266d18a480553ac49c5-- From nobody Fri Jul 7 22:57:08 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E515A12896F; Fri, 7 Jul 2017 22:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0mZkavtUN5Nq; Fri, 7 Jul 2017 22:56:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B01612783A; Fri, 7 Jul 2017 22:56:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQQ27984; Sat, 08 Jul 2017 05:56:54 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 8 Jul 2017 06:56:53 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 8 Jul 2017 13:56:48 +0800 From: "Zhangmingui (Martin)" To: Alvaro Retana , The IESG CC: "draft-ietf-trill-mtu-negotiation@ietf.org" , "trill-chairs@ietf.org" , "shares@ndzh.com" , "trill@ietf.org" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT) Thread-Index: AQHS9WDydUM3ICjtaESynIclWhvByqJJH94E Date: Sat, 8 Jul 2017 05:56:48 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A6546EE6@NKGEML515-MBX.china.huawei.com> References: <149923998135.3322.6478212107835480805.idtracker@ietfa.amsl.com> In-Reply-To: <149923998135.3322.6478212107835480805.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.108.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59607427.004D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9ad46b9b84e80f9f42f3a363bd1428ad Archived-At: Subject: Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 05:57:00 -0000 Hi Alvaro, Thanks for your comments. Please see inline below. ________________________________________ From: Alvaro Retana [aretana@cisco.com] Sent: Wednesday, July 05, 2017 15:33 To: The IESG Cc: draft-ietf-trill-mtu-negotiation@ietf.org; trill-chairs@ietf.org; share= s@ndzh.com; trill@ietf.org Subject: Alvaro Retana's No Objection on draft-ietf-trill-mtu-negotiation-0= 6: (with COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-trill-mtu-negotiation-06: No Objection 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-trill-mtu-negotiation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Are there implementations of this optimization? Have they shown the expect= ed improvements? The mechanism seems ok, but the introductory text made we wonder, specially the part about "*potentially* improving the efficiency of link utilization and speeding link state convergence." IOW, if the advanta= ges are not really know, then maybe a Standards Track document is premature. I really don't have a strong opinion, so I'm just wondering at this point. [Mingui] Only if Lz is larger than Sz, link-scoped PDUs can be formatted gr= eater than Sz. Otherwise, efficiency remains the same. That is why the docu= ment indicate "potentially".=20 Some nits: 1. There are some places where rfc2119 language is used that I think is out= of place because it is really just stating a fact or quoting what different documents say (without actually using quotations); IOW, these are really no= t normative statements defined in this document: - "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU...all RBridges MUST format their LSPs..." - "As specified in [RFC8139], RBridges MUST support..." - "as required by [RFC7780], all RBridges MUST..." [Mingui] Got it. The RFC2119 language has been removed for those occurrence= s. 2. From 2.1, these 2 sentences are redundant: "An originatingSNPBufferSize APPsub-TLV occurring in any other fragment MUST be ignored. An originatingSNPBufferSize APPsub-TLV occurring in any other fragment is igno= red. " [Mingui] One of them has been dropped. Thanks, Mingui= From nobody Fri Jul 7 22:57:31 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09BD12783A; Fri, 7 Jul 2017 22:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UMQFC2IVROa3; Fri, 7 Jul 2017 22:57:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D10C12896F; Fri, 7 Jul 2017 22:57:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJY62493; Sat, 08 Jul 2017 05:57:12 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 8 Jul 2017 06:57:11 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 8 Jul 2017 13:57:05 +0800 From: "Zhangmingui (Martin)" To: Magnus Westerlund , "tsv-art@ietf.org" CC: "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "ietf@ietf.org" , "trill@ietf.org" Thread-Topic: Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 Thread-Index: AQHS9Y7xZDZHsOYJgke3/J9kjsDvXqJJJE3f Date: Sat, 8 Jul 2017 05:57:04 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A6546EF1@NKGEML515-MBX.china.huawei.com> References: <149925973580.17545.6979655005275084891@ietfa.amsl.com> In-Reply-To: <149925973580.17545.6979655005275084891@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.108.158] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59607439.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e7df6c39eabc6c7f3615b22f29a18d90 Archived-At: Subject: Re: [trill] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 05:57:22 -0000 Hi Magnus, Thanks for your careful review. Please see the reponses inline below. ________________________________________ From: Magnus Westerlund [magnus.westerlund@ericsson.com] Sent: Wednesday, July 05, 2017 21:02 To: tsv-art@ietf.org Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org; ietf@ietf.org; trill@iet= f.org Subject: Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 Reviewer: Magnus Westerlund Review result: Not Ready This TSV-ART review is influenced by that I did the review of draft-ietf-trill-over-ip. 1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for determining if the UDP encapsulation will work or not. It references in Section 8.4 the old RFC, i.e. RFC 6325, which is updated by draft-ietf-trill-mtu-negotiation. TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in [RFC7177], can be used to obtain added assurance of the MTU of a link. However, this is not quite true, as if the IP path MTU is below 1470 bytes, which is not unheard of, the algorithm in the MTU negotiation draft can't determine it. It will only report the IP path as having an MTU to small when the 1470 bytes probe fail. [Mingui] I copied the relevant text from RFC 6325.=20 "The desired minimum acceptable inter-RBridge link MTU for the campus, that is, originatingLSPBufferSize. This is a 16-bit unsigned integer number of octets that defaults to 1470 bytes, which is the minimum valid value. Any lower value being advertised by an RBridge is ignored." So the minimum value of Sz would be 1470. IOW, IP path with MTU below 1470 = will not be qualified as an adjaceny of the TRILL network topology. So, if the trill-over-ip authors want to use this as a mechanism, then the = MTU negotiation draft needs to be expanded to have more flexible lower boundaries. However, that appear to affect MTU negotiation quite significant as it needs to separate algorithm for finding MTU, from the different usage of the algorithm with different starting points. Where the normal will have a lower bound of 1470, and be more tightly coupled to Sz when finding Lz. While the Trill-over-IP has a different usage. I think the trill WG needs to decide on how to slice this. If the MTU-negotiation only targets the explicit targets in the current draft and = goes forward now. Or if they want to meet trill-over-ip's goals which will requi= re restructuring. 2. Another issue, is that I think the algorithm is a bit short on transmission scheduling recommendations: 1) If RB1 successfully receives the MTU-ack from RB2 to the probe of the value of link-wide Lz within k tries (where k is a configurable parameter whose default is 3), link MTU size is set to the size of link-wide Lz and stop. If I do this test with all three packets back to back at line rate, I could potentially get all probes lost in the same burst loss in router queue or switch fabric. What I think is needed here is a specification on how these probes are transmitted. Spaced in a particular way, or at least minimal distance, and are the additional probes only sent after the previous has be= en judged to have been lost, which makes it interact with the next issue. [Mingui] This seems an implementation space. However, the document may offe= r recommendations. The being recommended minimum interval between two succe= ssive probes would affect the boot up speed of a TRILL campus. One RTT is a= reasonable value. 3. This is also unclear on what the criteria is for determining that someth= ing is lost: a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello and stop. I fail to see any specification for the criteria when an MTU-ack should be considered to have failed to reach the probing entity. So this appear to require a timeout, and thus a timeout interval. Is the RTT known so that on= e can define something as lost after N*RTT? Are there possible delays in send= ing the MTU-ack that are considered okay that can affect this? [Mingui] Yes, this makes sense. An MTU-ack should be considered to have fai= led two RTT after the probe is sent out. 4. Section 3, the algorithm in Step 1 is unable to reach the first terminat= ion condition (3) "If lowerBound >=3D upperBound" in some cases. [Mingui] This algorithm has been updated through a few rounds of revisions.= Let me insert a few minor updates to the cited text as below. Step 1: RB1 tries to send an MTU-probe padded to the size x. 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: upperBound is set to x and x is set to [(lowerBound + upperBound)/2], rounded up to the nearest integer. [Mingui] s/uppperBound is set to x/uppperBound is set to x-1/ [Mingui] s/rounded up to the nearest integer./rounded down to the nearest i= nteger./ 2) If RB1 receives an MTU-ack to a probe of size x from RB2: link MTU size is set to x, lowerBound is set to x and x is set to [(lowerBound + upperBound)/2], rounded up to the nearest integer. [Mingui] s/rounded up to the nearest integer./rounded down to the nearest i= nteger./ [Mingui] Append one condistion to this step 2): If lowerBound equals upperB= ound-1 then x is set to upperBound. 3) If lowerBound >=3D upperBound or Step 1 has been repeated n times (where n is a configurable parameter whose default value is 5), stop. 4) Repeat Step 1. I run this on the input data: Lower bound =3D 1470, Upper bound =3D 9216 an= d with an MTU of 7935 and gets the following sequence: Lower Upper X 1470 9216 5343 5343 9216 7280 7280 9216 8248 7280 8248 7764 7764 8248 8006 7764 8006 7885 7885 8006 7946 7885 7946 7916 7916 7946 7931 7931 7946 7939 7931 7939 7935 7935 7939 7937 7935 7937 7936 7935 7936 7936 7935 7936 7936 Thus, the termination condition needs to change.=20 [Mingui] After the update of the text, the sequence would become: Lower Upper X 1470 9216 5343 5343 9216 7279 7279 9216 8247 7279 8246 7762 7762 8246 8004 7762 8003 7882 7882 8003 7942 7882 7941 7911 7911 7941 7926 7926 7941 7933 7933 7941 7937 7933 7936 7934 7934 7936 7935 7935 7936 7935 7935 7936 7936 7935 7935 7935 The second I notice is that having a limitation on number of steps as 5,=20 [Mingui] Since the testing might be too resource consuming, implementors su= ggested this limitation. Afterall, the purpose of testing a Lz value is to = improve the efficiency (if Lz > Sz) rather than reach the optimal efficienc= y.=20 results in quite a large gap between upper and lower bound in which the MTU exists in. 5. I frankly gets confused by the application of the binary search. First i= t will in many case not be run to termination where the actual MTU is determi= ned. Then the result of the upper and lower bound are just used to confirm the S= z value. There are no discussion about using the MTU search to determine a ne= w possible value for Sz. [Mingui] Because the MTU search will NOT be used to determine a new possibl= e value for Sz. It is only applicable to Lz.=20 The text is not even explicit that lower bound is the highest known to work Transmission unit size at the time of testing. I thin= k section 3, should conclude in determine some TU value, and if that is Sz or something other appears quite relevant for what to do in the later sections= . [Mingui] As specified in Section 3, =93link MTU size=94 is already set to t= he lower bound. This tested =93link MTU size=94 is the =93TU=94 value. This= value is potentially larger than Sz as explained in the introduction and S= ection 2. Thanks, Mingui= From nobody Fri Jul 7 22:58:50 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7A2129AB8; Fri, 7 Jul 2017 22:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cbn5U86WhqcP; Fri, 7 Jul 2017 22:58:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3342212783A; Fri, 7 Jul 2017 22:58:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQQ28059; Sat, 08 Jul 2017 05:57:45 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 8 Jul 2017 06:57:44 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 8 Jul 2017 13:57:40 +0800 From: "Zhangmingui (Martin)" To: Warren Kumari , The IESG CC: "draft-ietf-trill-mtu-negotiation@ietf.org" , "trill-chairs@ietf.org" , "shares@ndzh.com" , "trill@ietf.org" Thread-Topic: Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT) Thread-Index: AQHS9cMl8ctlSH7CN0m7p0/TQlDq26JJXFaV Date: Sat, 8 Jul 2017 05:57:40 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A6546F05@NKGEML515-MBX.china.huawei.com> References: <149928214838.19397.15366425287313778494.idtracker@ietfa.amsl.com> In-Reply-To: <149928214838.19397.15366425287313778494.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.108.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59607459.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4c92ed0ef594d15ca98aa76286ecad04 Archived-At: Subject: Re: [trill] Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 05:58:49 -0000 Hi Warren, Thanks for the comments. Please see responses inline below.=20 ________________________________________ From: Warren Kumari [warren@kumari.net] Sent: Thursday, July 06, 2017 3:15 To: The IESG Cc: draft-ietf-trill-mtu-negotiation@ietf.org; trill-chairs@ietf.org; share= s@ndzh.com; trill@ietf.org Subject: Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (w= ith DISCUSS and COMMENT) Warren Kumari has entered the following ballot position for draft-ietf-trill-mtu-negotiation-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-trill-mtu-negotiation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1: Instead of answering the questions, the Shepherd Writeup just has links = to things - for example: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG LC: Passed: https://www.ietf.org/mail-archive/web/trill/current/msg07304.html Discussion: https://www.ietf.org/mail-archive/web/trill/current/msg07210.html This caused me to go investigate further - it seems that there were only 4 comments received during WGLC (excluding the RtgDir review, a short exchang= e with Julien Meuric). The comments which *were* received largely just fell i= nto the "Support" (with no real discussion) category. The document was adopted 06 March 2015, and then there were a few automated mentions of it (e.g [0], [1]), but I see no real discussion of the draft *i= n the WG*. It is entirely possible that my search fu is weak today, and that there has been sufficient discussion and review of the draft (or that none was needed because it is so obviously right and pure, but I'd like some reassurance of that), especially because a quick review found multiple readability issues = / nits. Note: I'm not holding the discuss on the readability / nits, rather on has = the process been followed / is there consensus grounds 2: The document also says that it Updates: 6325, 7177, 7780 - but I don't s= ee clear discussion of the Updates (OLD / NEW). [Mingui] The last paragarph of the introdution and the item 2)-b) of Sectio= n 4 do discuss the updates.=20 [0]: https://mailarchive.ietf.org/arch/msg/rtg-dir/c863sUajt86YB_d62uWfF5Hd= _X4 [1]: https://mailarchive.ietf.org/arch/msg/i-d-announce/p5ROVvvoU0B3S1OA2SY3vebX= _b4 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Major: I found much of the document really hard to read - I approve of the concept= / see the need for this, but reading the document itself is not well written. Nits: General RFC 6325 says: "4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size In a stable campus, there must ultimately be agreement among all RBridges on the value of "Sz", the minimum acceptable inter-RBridge link size for the campus, for the proper operation of TRILL IS-IS." and this document says: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" " Ok, so Sz is campus-wide -- but, for some reason this document has ~35 instances of "campus-wide Sz" - can you just drop the "campus-wide"? Is the= re any time the Sz would not be campus-wide? [Mingui] OK. The "campus-wide" will be dropped. Section 1. "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" to ensure that link state flooding operates properly and all RBridges converge to the same link state." This is really hard to parse - the bit before the hyphen is fine, but then = it gets muddled. Perhaps: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called "S= z") to ensure that link state flooding operates properly and all RBridges converge to the same link state." [Mingui] Right. Will be updated as such. "By calculating and using Lz as specified herein, link-scoped PDUs can be formatted greater than the campus-wide Sz up to the link-wide minimum acceptable inter- RBridge MTU size potentially improving the efficiency of link utilization and speeding link state convergence." "formatted" seems clumsy - perhaps just drop it? Or reorder to be "link-sco= ped PDUs larger than Sz, up to ... can be used"? [Mingui] The latter option looks better. O: "The new MTU size testing method specified in this document is backward compatible to the old one." P: "The new MTU size testing method specified i= n this document is backward compatible with the old one." C: Grammar [Mingui] OK. O: "Link-wide Lz is the minimum Lz supported and agreed between all RBridge= s on a specific link." P: "Link-wide Lz is the minimum Lz supported and agreed amongst all RBridges on a specific link." C: Between only if two. [Mingui] Right. Section 2. Link-Wide TRILL MTU Size O: "These PDUs are exchanged just on the local link." P: "These PDUs are exchanged only on the local link." [Mingui] Correct. O: "They use that flooding to exchange their maximally supportable value of "Lz"." P: "They use that flooding to exchange their maximum supported value= of "Lz"." C: Maximally would be an adverb, describing the process of maximizin= g the flooding (or something). [Mingui] Right. Section 2.1: O: "Lz MAY be reported using a originatingSNPBufferSize TLV that occurs" P: "Lz MAY be reported using an originatingSNPBufferSize TLV that occurs" C: I think. [Mingui] Correct. O: "If RB2 sends PDUs formatted in chunk of size 1800, it will be discarded= by B1." P: "If RB2 sends PDUs formatted in chunks of size 1800, they will be discarded by B1." C: chunks is plural. [Mingui] Right. Section 6: "The CSNPs and PSNPs MUST be formatted in chunks of size at most the link-wide Lz but are processed normally if received larger than that size." -- why the MUST? Is this supposed to be an instance of the sender being conservative and the receiver liberal? It so, I think it would be better to be much clearer. [Mingui] Will replace "MUST" with "can". Section 7: O: "Unlike RBridges, end stations do not participate in the exchange of TRILL IS-IS PDUs, therefore they cannot grasp the traffic link MTU size from a TRILL campus automatically. " C: should be a semicolon and not a comma before therefore, and a comma afte= r therefore. [Mingui] Right. Section 8. Backwards Compatibility O: "This will act properly although it may not be as efficient as it would= be if all RBridges on the link are Lz-aware." P: "This will act properly altho= ugh, it may not be as efficient as it would be if all RBridges on the link are Lz-aware." C: Missing comma. [Mingui] Yes. "Then the path MTU can be set as the smallest tested link MTU on this path and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." -- instead: "Then, the path MTU can be set as the smallest tested link MTU on this path= ; and end stations should not generate frames that, when encapsulated as TRIL= L Data packets, exceed this path MTU." [Mingui] OK. Thanks, Mingui= From nobody Mon Jul 10 05:14:05 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EBC127010; Mon, 10 Jul 2017 05:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UoAT-xWubVkn; Mon, 10 Jul 2017 05:13:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 6FB72126BF0; Mon, 10 Jul 2017 05:13:38 -0700 (PDT) X-AuditID: c1b4fb30-aeec49c000001664-3f-59636f71af8d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E5.ED.05732.17F63695; Mon, 10 Jul 2017 14:13:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.352.0; Mon, 10 Jul 2017 14:13:35 +0200 To: "Zhangmingui (Martin)" , "tsv-art@ietf.org" CC: "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "ietf@ietf.org" , "trill@ietf.org" References: <149925973580.17545.6979655005275084891@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E7A6546EF1@NKGEML515-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: <1419a786-f8c4-ad1b-1fb0-9e4562939445@ericsson.com> Date: Mon, 10 Jul 2017 14:13:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4552F0907735844E9204A62BBDD325E7A6546EF1@NKGEML515-MBX.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090101070908000509020904" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7lm5hfnKkwdsnghab/r1msXi2cT6L xfvJ29ksZu1ZxGJxZW4jmwOrR8uRt6weS5b8ZApgiuKySUnNySxLLdK3S+DKuLt/GVPBhA7G iiU3brI2MD4r7GLk5JAQMJGYvWA1UxcjF4eQwBFGiQmdp9khnOWMEs0zX7CAVAkLeElMuXUc qIqDQ0QgRmLi5wyQGmaB1YwSF5dtg2roZ5TYf3AHG0gDm4CFxM0fjWA2r4C9xMTtZ8EGsQio SmzY9ZgRxBYFGnRt5h1WiBpBiZMzn4DVcAqESUw5t4sFYkM3o0TbrP1MIAkhAW2JhqYO1gmM /LOQ9MxCVgeSYBYwk5i3+SEzhK0tsWzhayhbXOLWk/lQNdYSM34dZIOwFSWmdD9kh7BNJV4f /cgIYRtJvNvTyL6AkXMVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmDcHNzy22AH48vnjocY BTgYlXh4y62SI4VYE8uKK3MPMaoAzXm0YfUFRimWvPy8VCUR3hspQGnelMTKqtSi/Pii0pzU 4kOM0hwsSuK8jvsuRAgJpCeWpGanphakFsFkmTg4pRoY9a7L3HGcPy81KPqlx/uqtDid390i 3UZF5zqnBJl7+++cG3XQVP+h+Kmv7EdiTv9bamMVs7L7MEvtkZ4V1w9+nRr0oun5gZZjB1nK vnFWe6TyLEr6xqbpJbN5VUTmxhBfzXleWerNX3aYvf60Uffbd8ZkFSPu2a8m3fFX5P54YI8y zyvpZTP9lFiKMxINtZiLihMB4FzAzaMCAAA= Archived-At: Subject: Re: [trill] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 12:13:43 -0000 --------------ms090101070908000509020904 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Den 2017-07-08 kl. 07:57, skrev Zhangmingui (Martin): > Hi Magnus, > > Thanks for your careful review. Please see the reponses inline below. > > ________________________________________ > From: Magnus Westerlund [magnus.westerlund@ericsson.com] > Sent: Wednesday, July 05, 2017 21:02 > To: tsv-art@ietf.org > Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org; ietf@ietf.org; trill= @ietf.org > Subject: Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 > > Reviewer: Magnus Westerlund > Review result: Not Ready > > This TSV-ART review is influenced by that I did the review of > draft-ietf-trill-over-ip. > > 1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for > determining if the UDP encapsulation will work or not. It references i= n > Section 8.4 the old RFC, i.e. RFC 6325, which is updated by > draft-ietf-trill-mtu-negotiation. > > TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and i= n > [RFC7177], can be used to obtain added assurance of the MTU of a > link. > > However, this is not quite true, as if the IP path MTU is below 1470 > bytes, which is not unheard of, the algorithm in the MTU negotiation > draft can't determine it. It will only report the IP path as having an > MTU to small when the 1470 bytes probe fail. > > [Mingui] I copied the relevant text from RFC 6325. > "The desired minimum acceptable inter-RBridge link MTU for the > campus, that is, originatingLSPBufferSize. This is a 16-bit > unsigned integer number of octets that defaults to 1470 bytes, > which is the minimum valid value. Any lower value being > advertised by an RBridge is ignored." > So the minimum value of Sz would be 1470. IOW, IP path with MTU below 1= 470 will not be qualified as an adjaceny of the TRILL network topology. So this issue (1) is mostly bringing up what I saw as an discrepancy=20 between trill-over-ip and this document. I think it is quite reasonable=20 to push the needed extensions for more generalized IP path MTU discovery = in the Trill context onto the trill-over-ip document. However, I want to = note that from my perspective if one think one can run Trill-over-IP=20 then one better have a mechanism that can do fragmentation and=20 reassembly to handle IP MTUs that will not let trill packets of 1470=20 bytes through as that is quite common, in fact IPv6/UDP/Trill over=20 regular ethernet with 1500 bytes IP MTU is sufficient to fail that=20 criteria. > > So, if the trill-over-ip authors want to use this as a mechanism, then = the MTU > negotiation draft needs to be expanded to have more flexible lower > boundaries. However, that appear to affect MTU negotiation quite > significant as it needs to separate algorithm for finding MTU, from the= > different usage of the algorithm with different starting points. Where > the normal will have a lower bound of 1470, and be more tightly coupled= > to Sz when finding Lz. While the Trill-over-IP has a different usage. > > I think the trill WG needs to decide on how to slice this. If the > MTU-negotiation only targets the explicit targets in the current draft = and goes > forward now. Or if they want to meet trill-over-ip's goals which will r= equire > restructuring. > > 2. Another issue, is that I think the algorithm is a bit short on > transmission scheduling recommendations: > > 1) If RB1 successfully receives the MTU-ack from RB2 to the probe = of > the value of link-wide Lz within k tries (where k is a > configurable parameter whose default is 3), link MTU size is se= t > to the size of link-wide Lz and stop. > > If I do this test with all three packets back to back at line rate, I c= ould > potentially get all probes lost in the same burst loss in router queue = or > switch fabric. What I think is needed here is a specification on how th= ese > probes are transmitted. Spaced in a particular way, or at least minimal= > distance, and are the additional probes only sent after the previous ha= s been > judged to have been lost, which makes it interact with the next issue. > > [Mingui] This seems an implementation space. However, the document may = offer recommendations. The being recommended minimum interval between two= successive probes would affect the boot up speed of a TRILL campus. One = RTT is a reasonable value. Okay, for this there might be some implementation variations. However,=20 it can clearly affect the performance of the implementation so some=20 recommendation are likely good. I also think a spacing of one per RTT is = quite reasonable. However, that leads to the question, how does the=20 sender know what RTT there is? Is there something in the TRILL protocol=20 that will determine the RTT and have a current value? Sorry, I don't=20 have time to digest the whole TRILL suit of specifications. > > 3. This is also unclear on what the criteria is for determining that so= mething > is lost: > > a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB= 1 > sets the "failed minimum MTU test" flag for RB2 in RB1's Hel= lo > and stop. > > I fail to see any specification for the criteria when an MTU-ack should= be > considered to have failed to reach the probing entity. So this appear t= o > require a timeout, and thus a timeout interval. Is the RTT known so tha= t one > can define something as lost after N*RTT? Are there possible delays in = sending > the MTU-ack that are considered okay that can affect this? > > [Mingui] Yes, this makes sense. An MTU-ack should be considered to have= failed two RTT after the probe is sent out. So two questions on this. First, can a receiver know which MTU probe it=20 gets response to, i.e. are there some token or sequence number being=20 acked? Second, 2*RTT appear to be to short to make that conclusion in.=20 The reasons I say so is that there will be networks where the jitter of=20 the path is larger than the RTT sample, thus leading to=20 misinterpretation. Thus, I would recommend a bit more robustness to=20 misinterpretation and likely some minimal value that avoids low latency=20 paths wrongly classify the path. Note, I think it is needed to define=20 what the criteria is for when an MTU is considered lost, just because it = appears that it affects both startup and robustness of the probing. It=20 also becomes a question of what tools in the probes that are used for=20 this, and if you actually need some additional ones. > > 4. Section 3, the algorithm in Step 1 is unable to reach the first term= ination > condition (3) "If lowerBound >=3D upperBound" in some cases. > > [Mingui] This algorithm has been updated through a few rounds of revisi= ons. Let me insert a few minor updates to the cited text as below. > > Step 1: RB1 tries to send an MTU-probe padded to the size x. > > 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: > > upperBound is set to x and x is set to [(lowerBound + > upperBound)/2], rounded up to the nearest integer. > > [Mingui] s/uppperBound is set to x/uppperBound is set to x-1/ > [Mingui] s/rounded up to the nearest integer./rounded down to the neare= st integer./ > > > 2) If RB1 receives an MTU-ack to a probe of size x from RB2: > > link MTU size is set to x, lowerBound is set to x and x is se= t > to [(lowerBound + upperBound)/2], rounded up to the nearest > integer. > > [Mingui] s/rounded up to the nearest integer./rounded down to the neare= st integer./ > [Mingui] Append one condistion to this step 2): If lowerBound equals up= perBound-1 then x is set to upperBound. > > 3) If lowerBound >=3D upperBound or Step 1 has been repeated n time= s > (where n is a configurable parameter whose default value is 5), > stop. > > 4) Repeat Step 1. > > I run this on the input data: Lower bound =3D 1470, Upper bound =3D 921= 6 and with > an MTU of 7935 and gets the following sequence: > > Lower Upper X > 1470 9216 5343 > 5343 9216 7280 > 7280 9216 8248 > 7280 8248 7764 > 7764 8248 8006 > 7764 8006 7885 > 7885 8006 7946 > 7885 7946 7916 > 7916 7946 7931 > 7931 7946 7939 > 7931 7939 7935 > 7935 7939 7937 > 7935 7937 7936 > 7935 7936 7936 > 7935 7936 7936 > > Thus, the termination condition needs to change. > > [Mingui] After the update of the text, the sequence would become: > Lower Upper X > 1470 9216 5343 > 5343 9216 7279 > 7279 9216 8247 > 7279 8246 7762 > 7762 8246 8004 > 7762 8003 7882 > 7882 8003 7942 > 7882 7941 7911 > 7911 7941 7926 > 7926 7941 7933 > 7933 7941 7937 > 7933 7936 7934 > 7934 7936 7935 > 7935 7936 7935 Shouldn't the above line result in that X becomes 7936, as the probe=20 before it succeeds, and then the new additional rule in step (2) then X=20 becomes upper bound. > 7935 7936 7936 > 7935 7935 7935 > > The second I notice is that having a limitation on number of steps as 5= , > > [Mingui] Since the testing might be too resource consuming, implementor= s suggested this limitation. Afterall, the purpose of testing a Lz value = is to improve the efficiency (if Lz > Sz) rather than reach the optimal e= fficiency. Ok. > > results in quite a large gap > between upper and lower bound in which the MTU exists in. > > 5. I frankly gets confused by the application of the binary search. Fir= st it > will in many case not be run to termination where the actual MTU is det= ermined. > Then the result of the upper and lower bound are just used to confirm t= he Sz > value. There are no discussion about using the MTU search to determine = a new > possible value for Sz. > > [Mingui] Because the MTU search will NOT be used to determine a new pos= sible value for Sz. It is only applicable to Lz. > > The text is not even explicit that lower bound is the > highest known to work Transmission unit size at the time of testing. I = think > section 3, should conclude in determine some TU value, and if that is S= z or > something other appears quite relevant for what to do in the later sect= ions. > > [Mingui] As specified in Section 3, =E2=80=9Clink MTU size=E2=80=9D is = already set to the lower bound. This tested =E2=80=9Clink MTU size=E2=80=9D= is the =E2=80=9CTU=E2=80=9D value. This value is potentially larger than= Sz as explained in the introduction and Section 2. > Ok, I think I am getting what the different values are for. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms090101070908000509020904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzA3MTAxMjEzMzNaMC8GCSqGSIb3DQEJBDEiBCBkZp9Bjy09dKpnz9y9 P2u2SFhzoz+4gc1M0v9dU79aWzBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAZinfCAzEixREzQENdGMyuBiBn4LbCzfIbmDFb6oCyE50FH8z BspCndEyYr1U+upoS+n5zExgEWpi/FDM+ULHukKGuv38qBLEL/Yg84pX7IGd0+CGHs7L6Zc7 Pxk9dju2vlsMNiAMSyLcjpmnxcv1ja/5AA/BtI8reCnaWC4Sv56XNBO3mPca6wl06PlRPa7L VjC+O4uLHOeCy/m8qYGnSgDnhAX2hF38NTYXJ4rLxaOypmZ3FlpF68uelny+R1U+16OlGNeD K8XnBI2qG0yf95F1J6jU/GA8/U4wmRc4s0LH8h/FZ0LvKsUFitwBK7yYLUm3nlgQPJ29UHYH fFTEmAAAAAAAAA== --------------ms090101070908000509020904-- From nobody Mon Jul 10 10:11:57 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 316CC131821; Mon, 10 Jul 2017 10:11:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.55.3 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , akatlas@gmail.com, trill-chairs@ietf.org, draft-ietf-trill-rbridge-multilevel@ietf.org, trill@ietf.org, shares@ndzh.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149970671513.3928.4662464575852720458.idtracker@ietfa.amsl.com> Date: Mon, 10 Jul 2017 10:11:55 -0700 Archived-At: Subject: [trill] Document Action: 'Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links)' to Informational RFC (draft-ietf-trill-rbridge-multilevel-07.txt) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 17:11:55 -0000 The IESG has approved the following document: - 'Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links)' (draft-ietf-trill-rbridge-multilevel-07.txt) as Informational RFC This document is the product of the Transparent Interconnection of Lots of Links Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ Technical Summary Extending TRILL to multiple levels has challenges that are not addressed by the already-existing capability of IS-IS to have multiple levels. One issue is with the handling of multi-destination packet distribution trees. Another issue is with TRILL switch nicknames. There have been two proposed approaches. One approach, which we refer to as the "unique nickname" approach, gives unique nicknames to all the TRILL switches in the multilevel campus, either by having the Level-1/Level-2 border TRILL switches advertise which nicknames are not available for assignment in the area, or by partitioning the 16-bit nickname into an "area" field and a "nickname inside the area" field. The other approach, which we refer to as the "aggregated nickname" approach, involves hiding the nicknames within areas, allowing nicknames to be reused in different areas, by having the border TRILL switches rewrite the nickname fields when entering or leaving an area. Each of those approaches has advantages and disadvantages. This informational document suggests allowing a choice of approach in each area. This allows the simplicity of the unique nickname approach in installations in which there is no danger of running out of nicknames and allows the complexity of hiding the nicknames in an area to be phased into larger installations on a per-area basis. Working Group Summary WG has worked on these solutions for 2+ years. The WG consensus had no objections, and support of all key players with comments. WG LC: https://www.ietf.org/mail-archive/web/trill/current/msg07079.html Document Quality Protocol extension has no implementation of this code. Huawei plans to implement this function. Personnel Document shepherd: Susan Hares Responsible AD: Alia Atlas From nobody Wed Jul 12 03:50:30 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32036126B72; Wed, 12 Jul 2017 03:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Yswg3zJgAtN6; Wed, 12 Jul 2017 03:50:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B148E12ECCB; Wed, 12 Jul 2017 03:50:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQY79039; Wed, 12 Jul 2017 10:50:02 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 12 Jul 2017 11:50:02 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 12 Jul 2017 18:49:56 +0800 From: "Zhangmingui (Martin)" To: Magnus Westerlund , "tsv-art@ietf.org" CC: "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "ietf@ietf.org" , "trill@ietf.org" Thread-Topic: Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 Thread-Index: AQHS9Y7xZDZHsOYJgke3/J9kjsDvXqJJJE3fgANWXoCAA4UoSg== Date: Wed, 12 Jul 2017 10:49:55 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A6548A27@NKGEML515-MBX.china.huawei.com> References: <149925973580.17545.6979655005275084891@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E7A6546EF1@NKGEML515-MBX.china.huawei.com>, <1419a786-f8c4-ad1b-1fb0-9e4562939445@ericsson.com> In-Reply-To: <1419a786-f8c4-ad1b-1fb0-9e4562939445@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.110.244] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5965FEDB.0025, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1adcb1bec569771c5316c707b7db5434 Archived-At: Subject: Re: [trill] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 10:50:09 -0000 Hi Magnus,=20 Thanks for your further comments. Please see my responses inline below. ________________________________________ From: Magnus Westerlund [magnus.westerlund@ericsson.com] Sent: Monday, July 10, 2017 20:13 To: Zhangmingui (Martin); tsv-art@ietf.org Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org; ietf@ietf.org; trill@iet= f.org Subject: Re: Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 Den 2017-07-08 kl. 07:57, skrev Zhangmingui (Martin): > Hi Magnus, > > Thanks for your careful review. Please see the reponses inline below. > > ________________________________________ > From: Magnus Westerlund [magnus.westerlund@ericsson.com] > Sent: Wednesday, July 05, 2017 21:02 > To: tsv-art@ietf.org > Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org; ietf@ietf.org; trill@i= etf.org > Subject: Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 > > Reviewer: Magnus Westerlund > Review result: Not Ready > > This TSV-ART review is influenced by that I did the review of > draft-ietf-trill-over-ip. > > 1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for > determining if the UDP encapsulation will work or not. It references in > Section 8.4 the old RFC, i.e. RFC 6325, which is updated by > draft-ietf-trill-mtu-negotiation. > > TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in > [RFC7177], can be used to obtain added assurance of the MTU of a > link. > > However, this is not quite true, as if the IP path MTU is below 1470 > bytes, which is not unheard of, the algorithm in the MTU negotiation > draft can't determine it. It will only report the IP path as having an > MTU to small when the 1470 bytes probe fail. > > [Mingui] I copied the relevant text from RFC 6325. > "The desired minimum acceptable inter-RBridge link MTU for the > campus, that is, originatingLSPBufferSize. This is a 16-bit > unsigned integer number of octets that defaults to 1470 bytes, > which is the minimum valid value. Any lower value being > advertised by an RBridge is ignored." > So the minimum value of Sz would be 1470. IOW, IP path with MTU below 147= 0 will not be qualified as an adjaceny of the TRILL network topology. So this issue (1) is mostly bringing up what I saw as an discrepancy between trill-over-ip and this document. I think it is quite reasonable to push the needed extensions for more generalized IP path MTU discovery in the Trill context onto the trill-over-ip document. However, I want to note that from my perspective if one think one can run Trill-over-IP then one better have a mechanism that can do fragmentation and reassembly to handle IP MTUs that will not let trill packets of 1470 bytes through as that is quite common, in fact IPv6/UDP/Trill over regular ethernet with 1500 bytes IP MTU is sufficient to fail that criteria. [Mingui] I think the MTU for a TRILL-over-IP link with under layer IP-MTU= =3D1470 is actually more than 1470 if fragmentation and reassembly is suppo= rted. This had been explained in paragraph 2 of Section 8.4 in the TRILL ov= er IP draft. > > So, if the trill-over-ip authors want to use this as a mechanism, then th= e MTU > negotiation draft needs to be expanded to have more flexible lower > boundaries. However, that appear to affect MTU negotiation quite > significant as it needs to separate algorithm for finding MTU, from the > different usage of the algorithm with different starting points. Where > the normal will have a lower bound of 1470, and be more tightly coupled > to Sz when finding Lz. While the Trill-over-IP has a different usage. > > I think the trill WG needs to decide on how to slice this. If the > MTU-negotiation only targets the explicit targets in the current draft an= d goes > forward now. Or if they want to meet trill-over-ip's goals which will req= uire > restructuring. > > 2. Another issue, is that I think the algorithm is a bit short on > transmission scheduling recommendations: > > 1) If RB1 successfully receives the MTU-ack from RB2 to the probe of > the value of link-wide Lz within k tries (where k is a > configurable parameter whose default is 3), link MTU size is set > to the size of link-wide Lz and stop. > > If I do this test with all three packets back to back at line rate, I cou= ld > potentially get all probes lost in the same burst loss in router queue or > switch fabric. What I think is needed here is a specification on how thes= e > probes are transmitted. Spaced in a particular way, or at least minimal > distance, and are the additional probes only sent after the previous has = been > judged to have been lost, which makes it interact with the next issue. > > [Mingui] This seems an implementation space. However, the document may of= fer recommendations. The being recommended minimum interval between two suc= cessive probes would affect the boot up speed of a TRILL campus. One RTT is= a reasonable value. Okay, for this there might be some implementation variations. However, it can clearly affect the performance of the implementation so some recommendation are likely good. I also think a spacing of one per RTT is quite reasonable. However, that leads to the question, how does the sender know what RTT there is? Is there something in the TRILL protocol that will determine the RTT and have a current value? Sorry, I don't have time to digest the whole TRILL suit of specifications. [Mingui] I think the typical RTT value should be used as a default but conf= igurable value. Operators can determine and change it by using "ping" tools= . > > 3. This is also unclear on what the criteria is for determining that some= thing > is lost: > > a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1 > sets the "failed minimum MTU test" flag for RB2 in RB1's Hello > and stop. > > I fail to see any specification for the criteria when an MTU-ack should b= e > considered to have failed to reach the probing entity. So this appear to > require a timeout, and thus a timeout interval. Is the RTT known so that = one > can define something as lost after N*RTT? Are there possible delays in se= nding > the MTU-ack that are considered okay that can affect this? > > [Mingui] Yes, this makes sense. An MTU-ack should be considered to have f= ailed two RTT after the probe is sent out. So two questions on this. First, can a receiver know which MTU probe it gets response to, i.e. are there some token or sequence number being acked?=20 [Mingui] No, there is no such thing which would make the test too complicat= ed.=20 Second, 2*RTT appear to be to short to make that conclusion in. The reasons I say so is that there will be networks where the jitter of the path is larger than the RTT sample, thus leading to misinterpretation.=20 [Mingui] The MTU messageas are exchanged between two adjacent RBridges rath= er than a long-haul "path". Note that, even the rare misinterpretation doe= s occur, it will not fail the network. It will merely reduce the room for t= he efficiency improvement. Thus, I would recommend a bit more robustness to misinterpretation and likely some minimal value that avoids low latency paths wrongly classify the path. Note, I think it is needed to define what the criteria is for when an MTU is considered lost, just because it appears that it affects both startup and robustness of the probing. It also becomes a question of what tools in the probes that are used for this, and if you actually need some additional ones. [Mingui] I think the method to detect the optimal RTTs for each link deserv= es a separate document. Thanks, Mingui > > 4. Section 3, the algorithm in Step 1 is unable to reach the first termin= ation > condition (3) "If lowerBound >=3D upperBound" in some cases. > > [Mingui] This algorithm has been updated through a few rounds of revision= s. Let me insert a few minor updates to the cited text as below. > > Step 1: RB1 tries to send an MTU-probe padded to the size x. > > 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: > > upperBound is set to x and x is set to [(lowerBound + > upperBound)/2], rounded up to the nearest integer. > > [Mingui] s/uppperBound is set to x/uppperBound is set to x-1/ > [Mingui] s/rounded up to the nearest integer./rounded down to the nearest= integer./ > > > 2) If RB1 receives an MTU-ack to a probe of size x from RB2: > > link MTU size is set to x, lowerBound is set to x and x is set > to [(lowerBound + upperBound)/2], rounded up to the nearest > integer. > > [Mingui] s/rounded up to the nearest integer./rounded down to the nearest= integer./ > [Mingui] Append one condistion to this step 2): If lowerBound equals uppe= rBound-1 then x is set to upperBound. > > 3) If lowerBound >=3D upperBound or Step 1 has been repeated n times > (where n is a configurable parameter whose default value is 5), > stop. > > 4) Repeat Step 1. > > I run this on the input data: Lower bound =3D 1470, Upper bound =3D 9216 = and with > an MTU of 7935 and gets the following sequence: > > Lower Upper X > 1470 9216 5343 > 5343 9216 7280 > 7280 9216 8248 > 7280 8248 7764 > 7764 8248 8006 > 7764 8006 7885 > 7885 8006 7946 > 7885 7946 7916 > 7916 7946 7931 > 7931 7946 7939 > 7931 7939 7935 > 7935 7939 7937 > 7935 7937 7936 > 7935 7936 7936 > 7935 7936 7936 > > Thus, the termination condition needs to change. > > [Mingui] After the update of the text, the sequence would become: > Lower Upper X > 1470 9216 5343 > 5343 9216 7279 > 7279 9216 8247 > 7279 8246 7762 > 7762 8246 8004 > 7762 8003 7882 > 7882 8003 7942 > 7882 7941 7911 > 7911 7941 7926 > 7926 7941 7933 > 7933 7941 7937 > 7933 7936 7934 > 7934 7936 7935 > 7935 7936 7935 Shouldn't the above line result in that X becomes 7936, as the probe before it succeeds, and then the new additional rule in step (2) then X becomes upper bound. > 7935 7936 7936 > 7935 7935 7935 > > The second I notice is that having a limitation on number of steps as 5, > > [Mingui] Since the testing might be too resource consuming, implementors = suggested this limitation. Afterall, the purpose of testing a Lz value is t= o improve the efficiency (if Lz > Sz) rather than reach the optimal efficie= ncy. Ok. > > results in quite a large gap > between upper and lower bound in which the MTU exists in. > > 5. I frankly gets confused by the application of the binary search. First= it > will in many case not be run to termination where the actual MTU is deter= mined. > Then the result of the upper and lower bound are just used to confirm the= Sz > value. There are no discussion about using the MTU search to determine a = new > possible value for Sz. > > [Mingui] Because the MTU search will NOT be used to determine a new possi= ble value for Sz. It is only applicable to Lz. > > The text is not even explicit that lower bound is the > highest known to work Transmission unit size at the time of testing. I th= ink > section 3, should conclude in determine some TU value, and if that is Sz = or > something other appears quite relevant for what to do in the later sectio= ns. > > [Mingui] As specified in Section 3, =93link MTU size=94 is already set to= the lower bound. This tested =93link MTU size=94 is the =93TU=94 value. Th= is value is potentially larger than Sz as explained in the introduction and= Section 2. > Ok, I think I am getting what the different values are for. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------= From nobody Sun Jul 16 00:33:43 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CA21275AB; Sun, 16 Jul 2017 00:33:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150019041334.8716.6728855895935481389.idtracker@ietfa.amsl.com> Date: Sun, 16 Jul 2017 00:33:33 -0700 Archived-At: Subject: [trill] Warren Kumari's No Objection on draft-ietf-trill-mtu-negotiation-06: (with COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 07:33:33 -0000 Warren Kumari has entered the following ballot position for draft-ietf-trill-mtu-negotiation-06: No Objection 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-trill-mtu-negotiation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ I have removed my DISCUSS after discussing this with Alia. She has reassured me that there has been sufficient discussion on the topic, so I'm a happy camper now... ] Major: I found much of the document really hard to read - I approve of the concept / see the need for this, but reading the document itself is not well written. Nits: General RFC 6325 says: "4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size In a stable campus, there must ultimately be agreement among all RBridges on the value of "Sz", the minimum acceptable inter-RBridge link size for the campus, for the proper operation of TRILL IS-IS." and this document says: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" " Ok, so Sz is campus-wide -- but, for some reason this document has ~35 instances of "campus-wide Sz" - can you just drop the "campus-wide"? Is there any time the Sz would not be campus-wide? Section 1. "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" to ensure that link state flooding operates properly and all RBridges converge to the same link state." This is really hard to parse - the bit before the hyphen is fine, but then it gets muddled. Perhaps: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called "Sz") to ensure that link state flooding operates properly and all RBridges converge to the same link state." "By calculating and using Lz as specified herein, link-scoped PDUs can be formatted greater than the campus-wide Sz up to the link-wide minimum acceptable inter- RBridge MTU size potentially improving the efficiency of link utilization and speeding link state convergence." "formatted" seems clumsy - perhaps just drop it? Or reorder to be "link-scoped PDUs larger than Sz, up to ... can be used"? O: "The new MTU size testing method specified in this document is backward compatible to the old one." P: "The new MTU size testing method specified in this document is backward compatible with the old one." C: Grammar O: "Link-wide Lz is the minimum Lz supported and agreed between all RBridges on a specific link." P: "Link-wide Lz is the minimum Lz supported and agreed amongst all RBridges on a specific link." C: Between only if two. Section 2. Link-Wide TRILL MTU Size O: "These PDUs are exchanged just on the local link." P: "These PDUs are exchanged only on the local link." O: "They use that flooding to exchange their maximally supportable value of "Lz"." P: "They use that flooding to exchange their maximum supported value of "Lz"." C: Maximally would be an adverb, describing the process of maximizing the flooding (or something). Section 2.1: O: "Lz MAY be reported using a originatingSNPBufferSize TLV that occurs" P: "Lz MAY be reported using an originatingSNPBufferSize TLV that occurs" C: I think. O: "If RB2 sends PDUs formatted in chunk of size 1800, it will be discarded by B1." P: "If RB2 sends PDUs formatted in chunks of size 1800, they will be discarded by B1." C: chunks is plural. Section 6: "The CSNPs and PSNPs MUST be formatted in chunks of size at most the link-wide Lz but are processed normally if received larger than that size." -- why the MUST? Is this supposed to be an instance of the sender being conservative and the receiver liberal? It so, I think it would be better to be much clearer. Section 7: O: "Unlike RBridges, end stations do not participate in the exchange of TRILL IS-IS PDUs, therefore they cannot grasp the traffic link MTU size from a TRILL campus automatically. " C: should be a semicolon and not a comma before therefore, and a comma after therefore. Section 8. Backwards Compatibility O: "This will act properly although it may not be as efficient as it would be if all RBridges on the link are Lz-aware." P: "This will act properly although, it may not be as efficient as it would be if all RBridges on the link are Lz-aware." C: Missing comma. "Then the path MTU can be set as the smallest tested link MTU on this path and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." -- instead: "Then, the path MTU can be set as the smallest tested link MTU on this path; and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." -- Original discuss for posterity -- 1: Instead of answering the questions, the Shepherd Writeup just has links to things - for example: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG LC: Passed: https://www.ietf.org/mail-archive/web/trill/current/msg07304.html Discussion: https://www.ietf.org/mail-archive/web/trill/current/msg07210.html This caused me to go investigate further - it seems that there were only 4 comments received during WGLC (excluding the RtgDir review, a short exchange with Julien Meuric). The comments which *were* received largely just fell into the "Support" (with no real discussion) category. The document was adopted 06 March 2015, and then there were a few automated mentions of it (e.g [0], [1]), but I see no real discussion of the draft *in the WG*. It is entirely possible that my search fu is weak today, and that there has been sufficient discussion and review of the draft (or that none was needed because it is so obviously right and pure, but I'd like some reassurance of that), especially because a quick review found multiple readability issues / nits. Note: I'm not holding the discuss on the readability / nits, rather on has the process been followed / is there consensus grounds 2: The document also says that it Updates: 6325, 7177, 7780 - but I don't see clear discussion of the Updates (OLD / NEW). [0]: https://mailarchive.ietf.org/arch/msg/rtg-dir/c863sUajt86YB_d62uWfF5Hd_X4 [1]: https://mailarchive.ietf.org/arch/msg/i-d-announce/p5ROVvvoU0B3S1OA2SY3vebX_b4 From nobody Thu Jul 20 02:55:53 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6756E131BB0; Thu, 20 Jul 2017 02:55:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150054454234.24159.5123401863836338390@ietfa.amsl.com> Date: Thu, 20 Jul 2017 02:55:42 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-address-flush-03.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:55:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links WG of the IETF. Title : TRILL: Address Flush Message Authors : Weiguo Hao Donald E. Eastlake Yizhou Li Mohammed Umair Filename : draft-ietf-trill-address-flush-03.txt Pages : 20 Date : 2017-07-20 Abstract: The TRILL (TRansparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local MAC addresses and edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and edge switch of attachment from the decapsulation of remotely sourced TRILL Data packets. This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting and can assist in achieving more rapid convergence in case of topology or configuration change. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-address-flush-03 https://datatracker.ietf.org/doc/html/draft-ietf-trill-address-flush-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-address-flush-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 21 02:07:33 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDFD129A96 for ; Fri, 21 Jul 2017 02:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BJY348WNxonW for ; Fri, 21 Jul 2017 02:07:31 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 F13E912EB2B for ; Fri, 21 Jul 2017 02:07:30 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id m88so11780326iod.2 for ; Fri, 21 Jul 2017 02:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lzNRIMBnvshIniWqXUqe2pWmFInEjNBKC7XC63QwZxM=; b=IUQvP+PTTT9MJQ3aNBOnwv5XyEO4b5jwJ+YhNnxWYKYuay49/I6SofME+MC6Rpb9mz or6LsAZ8qkUL+ZlONkw0ogv6ZRCuAYQtjuEtmEjdY5whY83pATqCUpljkSOmisCWcYso LjdUqJgrEM+/61dT5PfQ2VqGPrT9zuoUoLzqQWtafpdu7moC+Dw2kCBZe/hK1nKO/bsa xXfCLoGqdOm3ovzL3KFyaK5+2TpXhow0U4S8KjJGBpWkQ9oFFOQRTBdvCzY+H09aXmDw e65SyBAjbaMgF1lywbKffKx+jS9nRkEXOuJVd+ZRLG96VyN7ArejL0Rj2bd5d0WyL0gu /jNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lzNRIMBnvshIniWqXUqe2pWmFInEjNBKC7XC63QwZxM=; b=DLxv2Jw4LgbUJeR6WHOJ2wCkrTQu1j52xDvvxMNQwE3gSNtt8LPfirKIyADC7LDb3C +Hww+tIPAOaznR7lavNxCNUbavNxXOZWMWk0HPNAST6COL87MM6XamWOiqgFP/kDfQZ/ JC4AxO79fbIOqy1saKyTi9bjTGODrVjbux5FiSrSnu+AWQQ6SXdFQ3cJ9laAAzV2+jVL eg3HGoPuPK5sAVYpLQcw8X40JVVZDeWG1FGqUdyKUOJ4cbijCuyiezqkV4IPxhD4vKOD DrWckoMG/FkbFA5ZglsKpSFByceegMxHwFiWrB6w0bLXzYm32QPbayzdq/F44INunliz Jqdg== X-Gm-Message-State: AIVw113qCLOM/WAjCQ/M4IkbcQH/ywd8a2+2X7PoMdAjSx7u7YpRNX/h S+RbmAQtHR5w6LxGCGbLF1IQnlsfDFNaIXI= X-Received: by 10.107.142.146 with SMTP id q140mr6326782iod.77.1500628050236; Fri, 21 Jul 2017 02:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Fri, 21 Jul 2017 02:07:14 -0700 (PDT) From: Donald Eastlake Date: Fri, 21 Jul 2017 05:07:14 -0400 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [trill] Comments on draft-ietf-trill-smart-endnodes X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:07:33 -0000 I support this draft and have the following comments: Technical ------------- It is not made clear how Smart End Nodes learn the Designated VLAN of the link they are on or, considering the paragraph just before the Section 5.2 header, the Appointed Forwarder for a VLAN or the DRB. It seems to me the draft needs to say explicitly that the smart end node snoops on TRILL IS-IS Hellos. Also, it needs to say that a smart end node, when encapsulating traffic in VLAN X, needs to use the nickname of the appointed forwarder for VLAN X, regardless of which edge RBridge it sends the encapsulated frame to, to avoid MAC flip-flop at the egress RBridge. The point paragraph just before the Section 6 header provides two approaches to handling a hybrid local link (a hybrid link is one with both smart and non-smart end nodes on it). As a Proposed Standard and in accordance with TRILL's general design approach, the document needs to select one and make it be the default. Section 6 also has two alternatives and does not seem clear. Presumably there isn't a single link with SE1, RB1, and RB2 on it since that case is well handled by the smart end node using the appointed forwarder nickname regardless of which edge RBridge it sends the encapsulated user data to. So it must be that SE1 is dual ported. If so, probably these ports have different MAC addresses and I'm not sure what the problem is.... I think it is inconsistent that IANA Considerations says "Smart-Hello" while near the start of the draft, the TLV is called "Smart-Parameters". "The mechanism for querying a directory is out of scope for this document." -> "The mechanism for querying a directory is given in [RFC8171]." Editorial ----------- Change ".While when" to ". When" "nicknamae" -> "nickname" There are also some other more minor editorial things I can communicate directly to the principal author. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Fri Jul 21 02:20:05 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE73129A96 for ; Fri, 21 Jul 2017 02:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0jMIiN6IbqvJ for ; Fri, 21 Jul 2017 02:20:02 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 2C5FD126557 for ; Fri, 21 Jul 2017 02:20:02 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id q2so20364790ioe.3 for ; Fri, 21 Jul 2017 02:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aS+jRpAFBR25US1vHIF1jyWq4jQZou079tRvkhQqNEg=; b=JETqwgDbTgGWGcrQHZgFbijDojuMhJhbYy8FWAXCGB8nJXMab1ayVIsxCXP4C7LIPV m4iqXEas6WcwuiECzSZ8WDIBrRuiMwwy46L1BtkMmo+5pXx2rldpqy6bEQhC8v0e/1Vg fQnAnjI5ND3Ynrek2jLKEJnxcIZFCZN1PR3bdK2tYf2xG8awdasf/TpdEg1ObBZHeeb1 lC1uRZSKcN9zVuNrwpX4lnr4ZQJRmqjWSNmf45kBu3QIrFoUtjoPJxEHT3ZFb6SQXPng K5le3zuGtxmwsZZScKAC1KFWB6Kwy2gcIoyR5zh31+BIj4GcMgtiCNuSNKj5hMorSceW Laww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aS+jRpAFBR25US1vHIF1jyWq4jQZou079tRvkhQqNEg=; b=ssYQnfewDujuFB3kbG14vzXVa1QeUKNnNJhGp00kBcW+LMyAtof++ugeQrYgCwNj2/ 9pZHIgJM2AozpYxlV4vfJ9e68uZrofEdHk56v9o/G1jbYpIT2CqNW/nCu4vacdEEriq4 tyZbT1qWksoN3cgBMe7YRciJiwuQf7rIabcGyZrQ3dR95Gpzl5NSlfamWPAArBEmutKj MYd7OZihtqVPIK5vUD7EVavv78lxIkLek3q55MdT9lfX4yaXMUox8/ZFrxkgaDYk4w0j VtphyjSHu0gAVvSUCp8ITBuV1gaq9g/2Mnx8C0liNlH5Ar0rTt+xTPt56QintKGSgv1X 8hdQ== X-Gm-Message-State: AIVw110K4xF8uZR0JBBo0u5vyAHZ649ixxXMDhSeFQKHY5QYqqWPf+a6 7m+ZejS/dW6Ww2umb9IfwU7YesUD+ehZ X-Received: by 10.107.142.146 with SMTP id q140mr6351120iod.77.1500628801458; Fri, 21 Jul 2017 02:20:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Fri, 21 Jul 2017 02:19:45 -0700 (PDT) From: Donald Eastlake Date: Fri, 21 Jul 2017 05:19:45 -0400 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [trill] Comments on draft-ietf-trill-directory-assisted-encap X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:20:04 -0000 I support this draft. See comments below: Technical ------------ To avoid MAC flip-flop at the remote egress RBridge, the TRILL-EN node needs to use the Appointed Forwarder for the encapsulated data frame's VLAN regardless of which edge RBridge it sends it to. This also solves a potential problem with return traffic. If return traffic arrived for egress at other than the Appointed Forwarder, it would be dropped. Editorial ----------- Update references for the issuance of RFC 8171. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Fri Jul 21 02:26:11 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B3B12EB2B for ; Fri, 21 Jul 2017 02:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8lA54OOzerkU for ; Fri, 21 Jul 2017 02:26:09 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 341CF131B5F for ; Fri, 21 Jul 2017 02:26:02 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id h199so4863154ith.0 for ; Fri, 21 Jul 2017 02:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qZFbNv7dMPTh7JzSh+0nklp/QRfTWYLZ+k6OCUZLafU=; b=sO3MVzZrCqryjxhRJN6utmsd5T5nJFNShDI8Z0hk5L2qasgPqjXZfCCQ2qxQfZO8h7 qnJYkK+ywgqiHbCc9B0igs4Yk+apddQTcIcE0pY6EprriZKxcZaGH7ZXmOa3j7zgwnlx MwHnCqHcPcLcBB5ekMTmMvYq1G68VbbnZhVY44OJ0X9Av++MShVCEmXJmjDEI2qeOSad pd/+2SusS7V3l9+RS/j2ydoXtL18S7f/Jm/w/YJmzETqoB78WXUNOaUNP5hpy1j1pbtl cPhrg6wvECgWdrx74YXJvobSNi6MzCxtnHoWx/SNYdZiVXK6hEUGKzXvTvGnNMdBfKLq byBA== 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:from:date :message-id:subject:to; bh=qZFbNv7dMPTh7JzSh+0nklp/QRfTWYLZ+k6OCUZLafU=; b=XmB6PSWa/010snCMQuUeKn9wcm29uqo3kLVUZ+zzsGAAp5Nz6KEY7E5+tKyuK1R5pr Ft+Nd0c59B9FTYSwCk/5lwToXNiubkszkqc78nK6kf8Gnw4JXvoEosBRJ5vnCcHEHjaR kFT2pFR+zneePeDixA5SmW7TT2CycSkJ7bfiZAKXRaeJPaBD4+J6QwJ8nAlwaiuM2Btu E24R1K8kenwIubkog3CUcJQumTQteTzRAsJaYDa1xxw5rUGn4xsECXLrNDLgyfCdWpvA wFZkk6vYE7TTmBywEJIiwSpEhSaN0qW6pvq2N9wvQ7lcGpB8a6ZqRUTYaQEMNgyL8sDJ CraQ== X-Gm-Message-State: AIVw112rMyVDfCCNsD44okOYc/ZW5x6XeiokNXofJrCPUZNo88SWF01B qTn+eH2i2W0jEuDAAjK76iDECEVXnnpJ X-Received: by 10.36.123.83 with SMTP id q80mr76415itc.1.1500629161105; Fri, 21 Jul 2017 02:26:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Fri, 21 Jul 2017 02:25:45 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Fri, 21 Jul 2017 05:25:45 -0400 Message-ID: To: "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [trill] Comments on draft-ietf-trill-smart-endnodes X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:26:10 -0000 Hi, Having just refreshed myself on both the smart-endnode and directory assisted encap drafts, I think the smart-endnode draft should be changed from using native RBridge Channel messages to using the TRILL ES-IS specified in RFC 8171. ES-IS would allow a much larger amount of data to be synchronized between edge-RBridges and smart endnodes, for example if a smart endnode were actually some sort of gateway and was handling a very large number of MAC addresses. Just how to use a native RBridge Channel message, as is currently specified in this draft, seems underspecified and would probably need a state diagram, etc., to be complete. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Jul 21, 2017 at 5:07 AM, Donald Eastlake wrote: > I support this draft and have the following comments: > > Technical > ------------- > > It is not made clear how Smart End Nodes learn the Designated VLAN of > the link they are on or, considering the paragraph just before the > Section 5.2 header, the Appointed Forwarder for a VLAN or the DRB. It > seems to me the draft needs to say explicitly that the smart end node > snoops on TRILL IS-IS Hellos. Also, it needs to say that a smart end > node, when encapsulating traffic in VLAN X, needs to use the nickname > of the appointed forwarder for VLAN X, regardless of which edge > RBridge it sends the encapsulated frame to, to avoid MAC flip-flop at > the egress RBridge. > > The point paragraph just before the Section 6 header provides two > approaches to handling a hybrid local link (a hybrid link is one with > both smart and non-smart end nodes on it). As a Proposed Standard and > in accordance with TRILL's general design approach, the document needs > to select one and make it be the default. > > Section 6 also has two alternatives and does not seem clear. > Presumably there isn't a single link with SE1, RB1, and RB2 on it > since that case is well handled by the smart end node using the > appointed forwarder nickname regardless of which edge RBridge it sends > the encapsulated user data to. So it must be that SE1 is dual ported. > If so, probably these ports have different MAC addresses and I'm not > sure what the problem is.... > > I think it is inconsistent that IANA Considerations says "Smart-Hello" > while near the start of the draft, the TLV is called > "Smart-Parameters". > > "The mechanism for querying a directory is out of scope for this > document." -> "The mechanism for querying a directory is given in > [RFC8171]." > > Editorial > ----------- > > Change ".While when" to ". When" > > "nicknamae" -> "nickname" > > There are also some other more minor editorial things I can > communicate directly to the principal author. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Thu Jul 27 09:43:21 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC24131CCB; Thu, 27 Jul 2017 09:43:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150117379416.11391.3771455030357513655.idtracker@ietfa.amsl.com> Date: Thu, 27 Jul 2017 09:43:14 -0700 Archived-At: Subject: [trill] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?trill-mtu-negotiation-06=3A_=28with_DISCUSS=29?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 16:43:14 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-trill-mtu-negotiation-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-trill-mtu-negotiation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The tsv-art review has raised a number of substantial issues that need to be addressed before publication (big thanks to Magnus Westerlund!). As far as I can see solution to address these issues have been discussed by email but are not reflected in an updated draft yet. I'm holding this discuss till an update occurs. In other words, please update the draft! From nobody Thu Jul 27 23:08:37 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CF21242F7; Thu, 27 Jul 2017 23:08:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150122211556.25205.16611251829260936058@ietfa.amsl.com> Date: Thu, 27 Jul 2017 23:08:35 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-mtu-negotiation-07.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 06:08:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links WG of the IETF. Title : Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation Authors : Mingui Zhang Xudong Zhang Donald E. Eastlake Radia Perlman Somnath Chatterjee Filename : draft-ietf-trill-mtu-negotiation-07.txt Pages : 14 Date : 2017-07-27 Abstract: The base IETF TRILL protocol has a TRILL campus-wide MTU feature, specified in RFC 6325 and RFC 7177, that assures that link state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFC 6325, updates RFC 7177, and updates RFC 7780. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-07 https://datatracker.ietf.org/doc/html/draft-ietf-trill-mtu-negotiation-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-mtu-negotiation-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 27 23:13:47 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F8126B7F; Thu, 27 Jul 2017 23:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ja2-lo1xAMmQ; Thu, 27 Jul 2017 23:13:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093EA131CFB; Thu, 27 Jul 2017 23:13:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSE87577; Fri, 28 Jul 2017 06:13:39 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Jul 2017 07:13:38 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 28 Jul 2017 14:13:33 +0800 From: "Zhangmingui (Martin)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-trill-mtu-negotiation@ietf.org" , "trill-chairs@ietf.org" , "shares@ndzh.com" , "trill@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10cmls?= =?utf-8?Q?l-mtu-negotiation-06:_(with_DISCUSS)?= Thread-Index: AQHTBvd1McRGiLVlR06WLmPp1nuFN6JoneHw Date: Fri, 28 Jul 2017 06:13:33 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A658F272@NKGEML515-MBX.china.huawei.com> References: <150117379416.11391.3771455030357513655.idtracker@ietfa.amsl.com> In-Reply-To: <150117379416.11391.3771455030357513655.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.597AD613.00AD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 73af6b4a2d9424d0992c433cc86009b0 Archived-At: Subject: Re: [trill] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trill-mtu-negotiation-06=3A_=28with_DISCUSS=29?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 06:13:46 -0000 SGkgTWlyamEsDQoNClRoZSAwNyB2ZXJzaW9uIHdhcyByZWFkeSBhbmQgbm93IGl0IGlzIHVwbG9h ZGVkLiBTb2x1dGlvbnMgdG8gYWRkcmVzcyBpc3N1ZXMgcmFpc2VkIGR1cmluZyB0aGUgdHN2LWFy dCByZXZpZXcgYXJlIHJlZmxlY3RlZC4NCg0KVGhhbmtzLA0KTWluZ3VpDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlyamEgS8O8aGxld2luZCBbbWFpbHRvOmlldGZA a3VlaGxld2luZC5uZXRdDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyAxMjo0MyBBTQ0K PiBUbzogVGhlIElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYtdHJpbGwtbXR1LW5lZ290aWF0aW9uQGll dGYub3JnOyB0cmlsbC1jaGFpcnNAaWV0Zi5vcmc7DQo+IHNoYXJlc0BuZHpoLmNvbTsgdHJpbGxA aWV0Zi5vcmcNCj4gU3ViamVjdDogTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi10cmlsbC1tdHUtbmVnb3RpYXRpb24tMDY6ICh3aXRoDQo+IERJU0NVU1MpDQo+IA0KPiBN aXJqYSBLw7xobGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KPiBkcmFmdC1pZXRmLXRyaWxsLW10dS1uZWdvdGlhdGlvbi0wNjogRGlzY3Vzcw0KPiAN Cj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+ IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtdHJpbGwtbXR1LW5lZ290aWF0aW9uLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoZSB0c3YtYXJ0IHJldmlldyBo YXMgcmFpc2VkIGEgbnVtYmVyIG9mIHN1YnN0YW50aWFsIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUN Cj4gYWRkcmVzc2VkIGJlZm9yZSBwdWJsaWNhdGlvbiAoYmlnIHRoYW5rcyB0byBNYWdudXMgV2Vz dGVybHVuZCEpLiBBcyBmYXIgYXMgSQ0KPiBjYW4gc2VlIHNvbHV0aW9uIHRvIGFkZHJlc3MgdGhl c2UgaXNzdWVzIGhhdmUgYmVlbiBkaXNjdXNzZWQgYnkgZW1haWwgYnV0IGFyZQ0KPiBub3QgcmVm bGVjdGVkIGluIGFuIHVwZGF0ZWQgZHJhZnQgeWV0LiBJJ20gaG9sZGluZyB0aGlzIGRpc2N1c3Mg dGlsbCBhbiB1cGRhdGUNCj4gb2NjdXJzLiBJbiBvdGhlciB3b3JkcywgcGxlYXNlIHVwZGF0ZSB0 aGUgZHJhZnQhDQo+IA0KPiANCj4gDQoNCg== From nobody Mon Jul 31 19:37:55 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A63D21200F3; Mon, 31 Jul 2017 19:37:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150155507363.30693.1609849209202574895@ietfa.amsl.com> Date: Mon, 31 Jul 2017 19:37:53 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-multilevel-single-nickname-04.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 02:37:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links WG of the IETF. Title : Transparent Interconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Multilevel Authors : Mingui Zhang Donald E. Eastlake Radia Perlman Margaret Cullen Hongjun Zhai Filename : draft-ietf-trill-multilevel-single-nickname-04.txt Pages : 13 Date : 2017-07-31 Abstract: A major issue in multilevel TRILL is how to manage RBridge nicknames. In this document, the area border RBridge uses a single nickname in both Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-single-nickname/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-multilevel-single-nickname-04 https://datatracker.ietf.org/doc/html/draft-ietf-trill-multilevel-single-nickname-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-multilevel-single-nickname-04 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 Jul 31 23:40:55 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB51131E08 for ; Mon, 31 Jul 2017 23:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 04pK8Vb2vxAK for ; Mon, 31 Jul 2017 23:40:51 -0700 (PDT) Received: from zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D7D1A131D9F for ; Mon, 31 Jul 2017 23:40:50 -0700 (PDT) X-scanvirus: By SEG_CYREN AntiVirus Engine X-scanresult: CLEAN X-MAILFROM: X-RCPTTO: X-FROMIP: 192.168.168.120 X-SEG-Scaned: 1 X-Received: unknown,192.168.168.120,20170801144028 Received: from unknown (HELO out1.zte.com.cn) (192.168.168.120) by localhost with SMTP; 1 Aug 2017 06:40:28 -0000 X-scanvirus: By SEG_CYREN AntiVirus Engine X-scanresult: CLEAN X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20170801143842 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 1 Aug 2017 06:38:42 -0000 Received: from xgxapp01.zte.com.cn ([10.30.14.22]) by mse01.zte.com.cn with SMTP id v716e8vd065381; Tue, 1 Aug 2017 14:40:08 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) Received: from mapi (xgxapp02[null]) by mapi (Zmail) with MAPI id mid71; Tue, 1 Aug 2017 14:40:10 +0800 (CST) Date: Tue, 1 Aug 2017 14:40:10 +0800 (CST) X-Zmail-TransId: 2afa5980224affffffffaf3-1e3eb X-Mailer: Zmail v1.0 Message-ID: <201708011440100059952@zte.com.cn> References: CAF4+nEGK6HTi2jRQkD8pvN4k29b71G5mopg8JuxtkaBy+o1nfg@mail.gmail.com, CAF4+nEE1xtG30nmd3FhXtBPiLjryz9D1PVX-k_btAU8gv_YC1w@mail.gmail.com Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse01.zte.com.cn v716e8vd065381 X-HQIP: 127.0.0.1 X-HQIP: 127.0.0.1 Archived-At: Subject: Re: [trill] =?utf-8?q?Comments_on_draft-ietf-trill-smart-endnodes?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 06:40:53 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksRG9uYWxkDQoNClRoYW5rcyBmb3IgeW91ciBzdWdnZXN0aW9uLiBJIGFncmVlIHRoYXQgdGhl IHNtYXJ0IGVuZG5vZGUgdXNlIHRoZSBUUklMTCBFUy1JUyBpbiBzZWN0aW9uIDUgb2YgUkZDIDgx NzEgYW1vbmcgdGhlIFNtYXJ0IGVuZG5vZGVzIGFuZCBFZGdlIFJCcmlkZ2VzLg0KDQpJIGFtIHVw ZGF0aW5nIHRoZSBzbWFydCBlbmRub2RlIGRyYWZ0IHRvIGEgbmV3IHZlcnNpb24uDQoNClJlZ2Fy ZHMuDQoNCkZhbmd3ZWkuDQoNCg0KDQoNCgogICAgICAgIA0KDQoNCg0KDQoNCg0KDQoNCuWOn+Wn i+mCruS7tg0KDQoNCg0K5Y+R5Lu25Lq677yaIDxkM2UzZTNAZ21haWwuY29tPg0K5pS25Lu25Lq6 77yaIDx0cmlsbEBpZXRmLm9yZz4NCuaXpSDmnJ8g77yaMjAxN+W5tDA35pyIMjHml6UgMTc6MjYN CuS4uyDpopgg77yaUmU6IFt0cmlsbF0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmlsbC1zbWFy dC1lbmRub2Rlcw0KDQoNCg0KDQoNCkhpLA0KDQpIYXZpbmcganVzdCByZWZyZXNoZWQgbXlzZWxm IG9uIGJvdGggdGhlIHNtYXJ0LWVuZG5vZGUgYW5kIGRpcmVjdG9yeQ0KYXNzaXN0ZWQgZW5jYXAg ZHJhZnRzLCBJIHRoaW5rIHRoZSBzbWFydC1lbmRub2RlIGRyYWZ0IHNob3VsZCBiZQ0KY2hhbmdl ZCBmcm9tIHVzaW5nIG5hdGl2ZSBSQnJpZGdlIENoYW5uZWwgbWVzc2FnZXMgdG8gdXNpbmcgdGhl IFRSSUxMDQpFUy1JUyBzcGVjaWZpZWQgaW4gUkZDIDgxNzEuIEVTLUlTIHdvdWxkIGFsbG93IGEg bXVjaCBsYXJnZXIgYW1vdW50IG9mDQpkYXRhIHRvIGJlIHN5bmNocm9uaXplZCBiZXR3ZWVuIGVk Z2UtUkJyaWRnZXMgYW5kIHNtYXJ0IGVuZG5vZGVzLCBmb3INCmV4YW1wbGUgaWYgYSBzbWFydCBl bmRub2RlIHdlcmUgYWN0dWFsbHkgc29tZSBzb3J0IG9mIGdhdGV3YXkgYW5kIHdhcw0KaGFuZGxp bmcgYSB2ZXJ5IGxhcmdlIG51bWJlciBvZiBNQUMgYWRkcmVzc2VzLiBKdXN0IGhvdyB0byB1c2Ug YQ0KbmF0aXZlIFJCcmlkZ2UgQ2hhbm5lbCBtZXNzYWdlLCBhcyBpcyBjdXJyZW50bHkgc3BlY2lm aWVkIGluIHRoaXMNCmRyYWZ0LCBzZWVtcyB1bmRlcnNwZWNpZmllZCBhbmQgd291bGQgcHJvYmFi bHkgbmVlZCBhIHN0YXRlIGRpYWdyYW0sDQpldGMuLCB0byBiZSBjb21wbGV0ZS4NCg0KVGhhbmtz LA0KRG9uYWxkDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogRG9uYWxkIEUuIEVh c3RsYWtlIDNyZCAgICsxLTUwOC0zMzMtMjI3MCAoY2VsbCkNCiAxNTUgQmVhdmVyIFN0cmVldCwg TWlsZm9yZCwgTUEgMDE3NTcgVVNBDQogZDNlM2UzQGdtYWlsLmNvbQ0KDQoNCk9uIEZyaSwgSnVs IDIxLCAyMDE3IGF0IDU6MDcgQU0sIERvbmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbT4g d3JvdGU6DQo+IEkgc3VwcG9ydCB0aGlzIGRyYWZ0IGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgY29t bWVudHM6DQo+DQo+IFRlY2huaWNhbA0KPiAtLS0tLS0tLS0tLS0tDQo+DQo+IEl0IGlzIG5vdCBt YWRlIGNsZWFyIGhvdyBTbWFydCBFbmQgTm9kZXMgbGVhcm4gdGhlIERlc2lnbmF0ZWQgVkxBTiBv Zg0KPiB0aGUgbGluayB0aGV5IGFyZSBvbiBvciwgY29uc2lkZXJpbmcgdGhlIHBhcmFncmFwaCBq dXN0IGJlZm9yZSB0aGUNCj4gU2VjdGlvbiA1LjIgaGVhZGVyLCB0aGUgQXBwb2ludGVkIEZvcndh cmRlciBmb3IgYSBWTEFOIG9yIHRoZSBEUkIuIEl0DQo+IHNlZW1zIHRvIG1lIHRoZSBkcmFmdCBu ZWVkcyB0byBzYXkgZXhwbGljaXRseSB0aGF0IHRoZSBzbWFydCBlbmQgbm9kZQ0KPiBzbm9vcHMg b24gVFJJTEwgSVMtSVMgSGVsbG9zLiBBbHNvLCBpdCBuZWVkcyB0byBzYXkgdGhhdCBhIHNtYXJ0 IGVuZA0KPiBub2RlLCB3aGVuIGVuY2Fwc3VsYXRpbmcgdHJhZmZpYyBpbiBWTEFOIFgsIG5lZWRz IHRvIHVzZSB0aGUgbmlja25hbWUNCj4gb2YgdGhlIGFwcG9pbnRlZCBmb3J3YXJkZXIgZm9yIFZM QU4gWCwgcmVnYXJkbGVzcyBvZiB3aGljaCBlZGdlDQo+IFJCcmlkZ2UgaXQgc2VuZHMgdGhlIGVu Y2Fwc3VsYXRlZCBmcmFtZSB0bywgdG8gYXZvaWQgTUFDIGZsaXAtZmxvcCBhdA0KPiB0aGUgZWdy ZXNzIFJCcmlkZ2UuDQo+DQo+IFRoZSBwb2ludCBwYXJhZ3JhcGgganVzdCBiZWZvcmUgdGhlIFNl Y3Rpb24gNiBoZWFkZXIgcHJvdmlkZXMgdHdvDQo+IGFwcHJvYWNoZXMgdG8gaGFuZGxpbmcgYSBo eWJyaWQgbG9jYWwgbGluayAoYSBoeWJyaWQgbGluayBpcyBvbmUgd2l0aA0KPiBib3RoIHNtYXJ0 IGFuZCBub24tc21hcnQgZW5kIG5vZGVzIG9uIGl0KS4gQXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBh bmQNCj4gaW4gYWNjb3JkYW5jZSB3aXRoIFRSSUxMJ3MgZ2VuZXJhbCBkZXNpZ24gYXBwcm9hY2gs IHRoZSBkb2N1bWVudCBuZWVkcw0KPiB0byBzZWxlY3Qgb25lIGFuZCBtYWtlIGl0IGJlIHRoZSBk ZWZhdWx0Lg0KPg0KPiBTZWN0aW9uIDYgYWxzbyBoYXMgdHdvIGFsdGVybmF0aXZlcyBhbmQgZG9l cyBub3Qgc2VlbSBjbGVhci4NCj4gUHJlc3VtYWJseSB0aGVyZSBpc24ndCBhIHNpbmdsZSBsaW5r IHdpdGggU0UxLCBSQjEsIGFuZCBSQjIgb24gaXQNCj4gc2luY2UgdGhhdCBjYXNlIGlzIHdlbGwg aGFuZGxlZCBieSB0aGUgc21hcnQgZW5kIG5vZGUgdXNpbmcgdGhlDQo+IGFwcG9pbnRlZCBmb3J3 YXJkZXIgbmlja25hbWUgcmVnYXJkbGVzcyBvZiB3aGljaCBlZGdlIFJCcmlkZ2UgaXQgc2VuZHMN Cj4gdGhlIGVuY2Fwc3VsYXRlZCB1c2VyIGRhdGEgdG8uIFNvIGl0IG11c3QgYmUgdGhhdCBTRTEg aXMgZHVhbCBwb3J0ZWQuDQo+IElmIHNvLCBwcm9iYWJseSB0aGVzZSBwb3J0cyBoYXZlIGRpZmZl cmVudCBNQUMgYWRkcmVzc2VzIGFuZCBJJ20gbm90DQo+IHN1cmUgd2hhdCB0aGUgcHJvYmxlbSBp cy4uLi4NCj4NCj4gSSB0aGluayBpdCBpcyBpbmNvbnNpc3RlbnQgdGhhdCBJQU5BIENvbnNpZGVy YXRpb25zIHNheXMgIlNtYXJ0LUhlbGxvIg0KPiB3aGlsZSBuZWFyIHRoZSBzdGFydCBvZiB0aGUg ZHJhZnQsIHRoZSBUTFYgaXMgY2FsbGVkDQo+ICJTbWFydC1QYXJhbWV0ZXJzIi4NCj4NCj4gIlRo ZSBtZWNoYW5pc20gZm9yIHF1ZXJ5aW5nIGEgZGlyZWN0b3J5IGlzIG91dCBvZiBzY29wZSBmb3Ig dGhpcw0KPiBkb2N1bWVudC4iIC0+ICJUaGUgbWVjaGFuaXNtIGZvciBxdWVyeWluZyBhIGRpcmVj dG9yeSBpcyBnaXZlbiBpbg0KPiBbUkZDODE3MV0uIg0KPg0KPiBFZGl0b3JpYWwNCj4gLS0tLS0t LS0tLS0NCj4NCj4gQ2hhbmdlICIuV2hpbGUgd2hlbiIgdG8gIi4gV2hlbiINCj4NCj4gIm5pY2tu YW1hZSIgLT4gIm5pY2tuYW1lIg0KPg0KPiBUaGVyZSBhcmUgYWxzbyBzb21lIG90aGVyIG1vcmUg bWlub3IgZWRpdG9yaWFsIHRoaW5ncyBJIGNhbg0KPiBjb21tdW5pY2F0ZSBkaXJlY3RseSB0byB0 aGUgcHJpbmNpcGFsIGF1dGhvci4NCj4NCj4gVGhhbmtzLA0KPiBEb25hbGQNCj4gPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KPiAgRG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsxLTUw OC0zMzMtMjI3MCAoY2VsbCkNCj4gIDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1 NyBVU0ENCj4gIGQzZTNlM0BnbWFpbC5jb20NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnRyaWxsIG1haWxpbmcgbGlzdA0KdHJpbGxAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJpbGw= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPiA8cD5IaSxEb25hbGQ8L3A+PHA+VGhhbmtzIGZvciB5 b3VyIHN1Z2dlc3Rpb24uIEkgYWdyZWUgdGhhdCB0aGUgc21hcnQgZW5kbm9kZSB1c2UgdGhlIFRS SUxMIEVTLUlTIGluIHNlY3Rpb24gNSBvZiBSRkMgODE3MSBhbW9uZyB0aGUgU21hcnQgZW5kbm9k ZXMgYW5kIEVkZ2UgUkJyaWRnZXMuPC9wPjxwPkkgYW0gdXBkYXRpbmcgdGhlIHNtYXJ0IGVuZG5v ZGUgZHJhZnQgdG8gYSBuZXcgdmVyc2lvbi48L3A+PHA+UmVnYXJkcy48L3A+PHA+RmFuZ3dlaS48 L3A+PGRpdiBjbGFzcz0iek1haWxTaWduIj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxwIHN0eWxlPSJm b250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDcuMHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyB3aWRvd3M6IDE7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6IzU4NTk1Qjtm b250LWZhbWlseTrlvq7ova/pm4Xpu5E7Zm9udC1zaXplOiA3LjBweDsiPjxzcGFuIGNsYXNzPSJz aWduZWRpdCI+PGJyPjwvc3Bhbj48L3NwYW4+CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IGNsYXNzPSJ6aGlzdG9y eVJvdyIgc3R5bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9InpoaXN0b3J5RGVzIiBzdHls ZT0id2lkdGg6IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6IDI4cHg7IGJhY2tncm91 bmQtY29sb3I6ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFsaWduOiBjZW50ZXI7IiBs YW5ndWFnZS1kYXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8L2Rpdj48ZGl2IGlkPSJ6 d3JpdGVIaXN0b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9sLWdyb3VwIHpoaXN0b3J5 UGFuZWwiPjxkaXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0icGFkZGluZzogOHB4OyBi YWNrZ3JvdW5kLWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhp c3RvcnlTZW5kZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVz ZXJOYW1lIj4gJmx0O2QzZTNlM0BnbWFpbC5jb20mZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJv bmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3Bh biBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPiAmbHQ7dHJp bGxAaWV0Zi5vcmcmZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0i SGlzdG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9IiI+MjAxN+W5 tDA35pyIMjHml6UgMTc6MjY8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9 Ikhpc3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVh ZFRpdGxlIj48c3Ryb25nPlJlOiBbdHJpbGxdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHJpbGwt c21hcnQtZW5kbm9kZXM8L3N0cm9uZz48L3NwYW4+PC9kaXY+PC9kaXY+PHAgY2xhc3M9InpoaXN0 b3J5Q29udGVudCI+PGJyPjwvcD48ZGl2PkhpLDxicj48YnI+SGF2aW5nJm5ic3A7anVzdCZuYnNw O3JlZnJlc2hlZCZuYnNwO215c2VsZiZuYnNwO29uJm5ic3A7Ym90aCZuYnNwO3RoZSZuYnNwO3Nt YXJ0LWVuZG5vZGUmbmJzcDthbmQmbmJzcDtkaXJlY3Rvcnk8YnI+YXNzaXN0ZWQmbmJzcDtlbmNh cCZuYnNwO2RyYWZ0cywmbmJzcDtJJm5ic3A7dGhpbmsmbmJzcDt0aGUmbmJzcDtzbWFydC1lbmRu b2RlJm5ic3A7ZHJhZnQmbmJzcDtzaG91bGQmbmJzcDtiZTxicj5jaGFuZ2VkJm5ic3A7ZnJvbSZu YnNwO3VzaW5nJm5ic3A7bmF0aXZlJm5ic3A7UkJyaWRnZSZuYnNwO0NoYW5uZWwmbmJzcDttZXNz YWdlcyZuYnNwO3RvJm5ic3A7dXNpbmcmbmJzcDt0aGUmbmJzcDtUUklMTDxicj5FUy1JUyZuYnNw O3NwZWNpZmllZCZuYnNwO2luJm5ic3A7UkZDJm5ic3A7ODE3MS4mbmJzcDtFUy1JUyZuYnNwO3dv dWxkJm5ic3A7YWxsb3cmbmJzcDthJm5ic3A7bXVjaCZuYnNwO2xhcmdlciZuYnNwO2Ftb3VudCZu YnNwO29mPGJyPmRhdGEmbmJzcDt0byZuYnNwO2JlJm5ic3A7c3luY2hyb25pemVkJm5ic3A7YmV0 d2VlbiZuYnNwO2VkZ2UtUkJyaWRnZXMmbmJzcDthbmQmbmJzcDtzbWFydCZuYnNwO2VuZG5vZGVz LCZuYnNwO2Zvcjxicj5leGFtcGxlJm5ic3A7aWYmbmJzcDthJm5ic3A7c21hcnQmbmJzcDtlbmRu b2RlJm5ic3A7d2VyZSZuYnNwO2FjdHVhbGx5Jm5ic3A7c29tZSZuYnNwO3NvcnQmbmJzcDtvZiZu YnNwO2dhdGV3YXkmbmJzcDthbmQmbmJzcDt3YXM8YnI+aGFuZGxpbmcmbmJzcDthJm5ic3A7dmVy eSZuYnNwO2xhcmdlJm5ic3A7bnVtYmVyJm5ic3A7b2YmbmJzcDtNQUMmbmJzcDthZGRyZXNzZXMu Jm5ic3A7SnVzdCZuYnNwO2hvdyZuYnNwO3RvJm5ic3A7dXNlJm5ic3A7YTxicj5uYXRpdmUmbmJz cDtSQnJpZGdlJm5ic3A7Q2hhbm5lbCZuYnNwO21lc3NhZ2UsJm5ic3A7YXMmbmJzcDtpcyZuYnNw O2N1cnJlbnRseSZuYnNwO3NwZWNpZmllZCZuYnNwO2luJm5ic3A7dGhpczxicj5kcmFmdCwmbmJz cDtzZWVtcyZuYnNwO3VuZGVyc3BlY2lmaWVkJm5ic3A7YW5kJm5ic3A7d291bGQmbmJzcDtwcm9i YWJseSZuYnNwO25lZWQmbmJzcDthJm5ic3A7c3RhdGUmbmJzcDtkaWFncmFtLDxicj5ldGMuLCZu YnNwO3RvJm5ic3A7YmUmbmJzcDtjb21wbGV0ZS48YnI+PGJyPlRoYW5rcyw8YnI+RG9uYWxkPGJy Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+Jm5ic3A7RG9uYWxkJm5ic3A7RS4m bmJzcDtFYXN0bGFrZSZuYnNwOzNyZCZuYnNwOyZuYnNwOyZuYnNwOysxLTUwOC0zMzMtMjI3MCZu YnNwOyhjZWxsKTxicj4mbmJzcDsxNTUmbmJzcDtCZWF2ZXImbmJzcDtTdHJlZXQsJm5ic3A7TWls Zm9yZCwmbmJzcDtNQSZuYnNwOzAxNzU3Jm5ic3A7VVNBPGJyPiZuYnNwO2QzZTNlM0BnbWFpbC5j b208YnI+PGJyPjxicj5PbiZuYnNwO0ZyaSwmbmJzcDtKdWwmbmJzcDsyMSwmbmJzcDsyMDE3Jm5i c3A7YXQmbmJzcDs1OjA3Jm5ic3A7QU0sJm5ic3A7RG9uYWxkJm5ic3A7RWFzdGxha2UmbmJzcDsm bHQ7ZDNlM2UzQGdtYWlsLmNvbSZndDsmbmJzcDt3cm90ZTo8YnI+Jmd0OyZuYnNwO0kmbmJzcDtz dXBwb3J0Jm5ic3A7dGhpcyZuYnNwO2RyYWZ0Jm5ic3A7YW5kJm5ic3A7aGF2ZSZuYnNwO3RoZSZu YnNwO2ZvbGxvd2luZyZuYnNwO2NvbW1lbnRzOjxicj4mZ3Q7PGJyPiZndDsmbmJzcDtUZWNobmlj YWw8YnI+Jmd0OyZuYnNwOy0tLS0tLS0tLS0tLS08YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7SXQmbmJz cDtpcyZuYnNwO25vdCZuYnNwO21hZGUmbmJzcDtjbGVhciZuYnNwO2hvdyZuYnNwO1NtYXJ0Jm5i c3A7RW5kJm5ic3A7Tm9kZXMmbmJzcDtsZWFybiZuYnNwO3RoZSZuYnNwO0Rlc2lnbmF0ZWQmbmJz cDtWTEFOJm5ic3A7b2Y8YnI+Jmd0OyZuYnNwO3RoZSZuYnNwO2xpbmsmbmJzcDt0aGV5Jm5ic3A7 YXJlJm5ic3A7b24mbmJzcDtvciwmbmJzcDtjb25zaWRlcmluZyZuYnNwO3RoZSZuYnNwO3BhcmFn cmFwaCZuYnNwO2p1c3QmbmJzcDtiZWZvcmUmbmJzcDt0aGU8YnI+Jmd0OyZuYnNwO1NlY3Rpb24m bmJzcDs1LjImbmJzcDtoZWFkZXIsJm5ic3A7dGhlJm5ic3A7QXBwb2ludGVkJm5ic3A7Rm9yd2Fy ZGVyJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO1ZMQU4mbmJzcDtvciZuYnNwO3RoZSZuYnNwO0RSQi4m bmJzcDtJdDxicj4mZ3Q7Jm5ic3A7c2VlbXMmbmJzcDt0byZuYnNwO21lJm5ic3A7dGhlJm5ic3A7 ZHJhZnQmbmJzcDtuZWVkcyZuYnNwO3RvJm5ic3A7c2F5Jm5ic3A7ZXhwbGljaXRseSZuYnNwO3Ro YXQmbmJzcDt0aGUmbmJzcDtzbWFydCZuYnNwO2VuZCZuYnNwO25vZGU8YnI+Jmd0OyZuYnNwO3Nu b29wcyZuYnNwO29uJm5ic3A7VFJJTEwmbmJzcDtJUy1JUyZuYnNwO0hlbGxvcy4mbmJzcDtBbHNv LCZuYnNwO2l0Jm5ic3A7bmVlZHMmbmJzcDt0byZuYnNwO3NheSZuYnNwO3RoYXQmbmJzcDthJm5i c3A7c21hcnQmbmJzcDtlbmQ8YnI+Jmd0OyZuYnNwO25vZGUsJm5ic3A7d2hlbiZuYnNwO2VuY2Fw c3VsYXRpbmcmbmJzcDt0cmFmZmljJm5ic3A7aW4mbmJzcDtWTEFOJm5ic3A7WCwmbmJzcDtuZWVk cyZuYnNwO3RvJm5ic3A7dXNlJm5ic3A7dGhlJm5ic3A7bmlja25hbWU8YnI+Jmd0OyZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7YXBwb2ludGVkJm5ic3A7Zm9yd2FyZGVyJm5ic3A7Zm9yJm5ic3A7VkxB TiZuYnNwO1gsJm5ic3A7cmVnYXJkbGVzcyZuYnNwO29mJm5ic3A7d2hpY2gmbmJzcDtlZGdlPGJy PiZndDsmbmJzcDtSQnJpZGdlJm5ic3A7aXQmbmJzcDtzZW5kcyZuYnNwO3RoZSZuYnNwO2VuY2Fw c3VsYXRlZCZuYnNwO2ZyYW1lJm5ic3A7dG8sJm5ic3A7dG8mbmJzcDthdm9pZCZuYnNwO01BQyZu YnNwO2ZsaXAtZmxvcCZuYnNwO2F0PGJyPiZndDsmbmJzcDt0aGUmbmJzcDtlZ3Jlc3MmbmJzcDtS QnJpZGdlLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDtUaGUmbmJzcDtwb2ludCZuYnNwO3BhcmFncmFw aCZuYnNwO2p1c3QmbmJzcDtiZWZvcmUmbmJzcDt0aGUmbmJzcDtTZWN0aW9uJm5ic3A7NiZuYnNw O2hlYWRlciZuYnNwO3Byb3ZpZGVzJm5ic3A7dHdvPGJyPiZndDsmbmJzcDthcHByb2FjaGVzJm5i c3A7dG8mbmJzcDtoYW5kbGluZyZuYnNwO2EmbmJzcDtoeWJyaWQmbmJzcDtsb2NhbCZuYnNwO2xp bmsmbmJzcDsoYSZuYnNwO2h5YnJpZCZuYnNwO2xpbmsmbmJzcDtpcyZuYnNwO29uZSZuYnNwO3dp dGg8YnI+Jmd0OyZuYnNwO2JvdGgmbmJzcDtzbWFydCZuYnNwO2FuZCZuYnNwO25vbi1zbWFydCZu YnNwO2VuZCZuYnNwO25vZGVzJm5ic3A7b24mbmJzcDtpdCkuJm5ic3A7QXMmbmJzcDthJm5ic3A7 UHJvcG9zZWQmbmJzcDtTdGFuZGFyZCZuYnNwO2FuZDxicj4mZ3Q7Jm5ic3A7aW4mbmJzcDthY2Nv cmRhbmNlJm5ic3A7d2l0aCZuYnNwO1RSSUxMJ3MmbmJzcDtnZW5lcmFsJm5ic3A7ZGVzaWduJm5i c3A7YXBwcm9hY2gsJm5ic3A7dGhlJm5ic3A7ZG9jdW1lbnQmbmJzcDtuZWVkczxicj4mZ3Q7Jm5i c3A7dG8mbmJzcDtzZWxlY3QmbmJzcDtvbmUmbmJzcDthbmQmbmJzcDttYWtlJm5ic3A7aXQmbmJz cDtiZSZuYnNwO3RoZSZuYnNwO2RlZmF1bHQuPGJyPiZndDs8YnI+Jmd0OyZuYnNwO1NlY3Rpb24m bmJzcDs2Jm5ic3A7YWxzbyZuYnNwO2hhcyZuYnNwO3R3byZuYnNwO2FsdGVybmF0aXZlcyZuYnNw O2FuZCZuYnNwO2RvZXMmbmJzcDtub3QmbmJzcDtzZWVtJm5ic3A7Y2xlYXIuPGJyPiZndDsmbmJz cDtQcmVzdW1hYmx5Jm5ic3A7dGhlcmUmbmJzcDtpc24ndCZuYnNwO2EmbmJzcDtzaW5nbGUmbmJz cDtsaW5rJm5ic3A7d2l0aCZuYnNwO1NFMSwmbmJzcDtSQjEsJm5ic3A7YW5kJm5ic3A7UkIyJm5i c3A7b24mbmJzcDtpdDxicj4mZ3Q7Jm5ic3A7c2luY2UmbmJzcDt0aGF0Jm5ic3A7Y2FzZSZuYnNw O2lzJm5ic3A7d2VsbCZuYnNwO2hhbmRsZWQmbmJzcDtieSZuYnNwO3RoZSZuYnNwO3NtYXJ0Jm5i c3A7ZW5kJm5ic3A7bm9kZSZuYnNwO3VzaW5nJm5ic3A7dGhlPGJyPiZndDsmbmJzcDthcHBvaW50 ZWQmbmJzcDtmb3J3YXJkZXImbmJzcDtuaWNrbmFtZSZuYnNwO3JlZ2FyZGxlc3MmbmJzcDtvZiZu YnNwO3doaWNoJm5ic3A7ZWRnZSZuYnNwO1JCcmlkZ2UmbmJzcDtpdCZuYnNwO3NlbmRzPGJyPiZn dDsmbmJzcDt0aGUmbmJzcDtlbmNhcHN1bGF0ZWQmbmJzcDt1c2VyJm5ic3A7ZGF0YSZuYnNwO3Rv LiZuYnNwO1NvJm5ic3A7aXQmbmJzcDttdXN0Jm5ic3A7YmUmbmJzcDt0aGF0Jm5ic3A7U0UxJm5i c3A7aXMmbmJzcDtkdWFsJm5ic3A7cG9ydGVkLjxicj4mZ3Q7Jm5ic3A7SWYmbmJzcDtzbywmbmJz cDtwcm9iYWJseSZuYnNwO3RoZXNlJm5ic3A7cG9ydHMmbmJzcDtoYXZlJm5ic3A7ZGlmZmVyZW50 Jm5ic3A7TUFDJm5ic3A7YWRkcmVzc2VzJm5ic3A7YW5kJm5ic3A7SSdtJm5ic3A7bm90PGJyPiZn dDsmbmJzcDtzdXJlJm5ic3A7d2hhdCZuYnNwO3RoZSZuYnNwO3Byb2JsZW0mbmJzcDtpcy4uLi48 YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7SSZuYnNwO3RoaW5rJm5ic3A7aXQmbmJzcDtpcyZuYnNwO2lu Y29uc2lzdGVudCZuYnNwO3RoYXQmbmJzcDtJQU5BJm5ic3A7Q29uc2lkZXJhdGlvbnMmbmJzcDtz YXlzJm5ic3A7IlNtYXJ0LUhlbGxvIjxicj4mZ3Q7Jm5ic3A7d2hpbGUmbmJzcDtuZWFyJm5ic3A7 dGhlJm5ic3A7c3RhcnQmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2RyYWZ0LCZuYnNwO3RoZSZuYnNw O1RMViZuYnNwO2lzJm5ic3A7Y2FsbGVkPGJyPiZndDsmbmJzcDsiU21hcnQtUGFyYW1ldGVycyIu PGJyPiZndDs8YnI+Jmd0OyZuYnNwOyJUaGUmbmJzcDttZWNoYW5pc20mbmJzcDtmb3ImbmJzcDtx dWVyeWluZyZuYnNwO2EmbmJzcDtkaXJlY3RvcnkmbmJzcDtpcyZuYnNwO291dCZuYnNwO29mJm5i c3A7c2NvcGUmbmJzcDtmb3ImbmJzcDt0aGlzPGJyPiZndDsmbmJzcDtkb2N1bWVudC4iJm5ic3A7 LSZndDsmbmJzcDsiVGhlJm5ic3A7bWVjaGFuaXNtJm5ic3A7Zm9yJm5ic3A7cXVlcnlpbmcmbmJz cDthJm5ic3A7ZGlyZWN0b3J5Jm5ic3A7aXMmbmJzcDtnaXZlbiZuYnNwO2luPGJyPiZndDsmbmJz cDtbUkZDODE3MV0uIjxicj4mZ3Q7PGJyPiZndDsmbmJzcDtFZGl0b3JpYWw8YnI+Jmd0OyZuYnNw Oy0tLS0tLS0tLS0tPGJyPiZndDs8YnI+Jmd0OyZuYnNwO0NoYW5nZSZuYnNwOyIuV2hpbGUmbmJz cDt3aGVuIiZuYnNwO3RvJm5ic3A7Ii4mbmJzcDtXaGVuIjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsi bmlja25hbWFlIiZuYnNwOy0mZ3Q7Jm5ic3A7Im5pY2tuYW1lIjxicj4mZ3Q7PGJyPiZndDsmbmJz cDtUaGVyZSZuYnNwO2FyZSZuYnNwO2Fsc28mbmJzcDtzb21lJm5ic3A7b3RoZXImbmJzcDttb3Jl Jm5ic3A7bWlub3ImbmJzcDtlZGl0b3JpYWwmbmJzcDt0aGluZ3MmbmJzcDtJJm5ic3A7Y2FuPGJy PiZndDsmbmJzcDtjb21tdW5pY2F0ZSZuYnNwO2RpcmVjdGx5Jm5ic3A7dG8mbmJzcDt0aGUmbmJz cDtwcmluY2lwYWwmbmJzcDthdXRob3IuPGJyPiZndDs8YnI+Jmd0OyZuYnNwO1RoYW5rcyw8YnI+ Jmd0OyZuYnNwO0RvbmFsZDxicj4mZ3Q7Jm5ic3A7PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7RG9uYWxkJm5ic3A7RS4mbmJzcDtFYXN0bGFrZSZuYnNw OzNyZCZuYnNwOyZuYnNwOyZuYnNwOysxLTUwOC0zMzMtMjI3MCZuYnNwOyhjZWxsKTxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7MTU1Jm5ic3A7QmVhdmVyJm5ic3A7U3RyZWV0LCZuYnNwO01pbGZvcmQsJm5i c3A7TUEmbmJzcDswMTc1NyZuYnNwO1VTQTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7ZDNlM2UzQGdtYWls LmNvbTxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+dHJpbGwmbmJzcDttYWlsaW5nJm5ic3A7bGlzdDxicj50cmlsbEBpZXRmLm9yZzxicj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyaWxsPGJyPjwvZGl2PjxwPjxi cj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD4gPC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====--