From nobody Sat Jul 1 07:53:48 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@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: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team 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:02 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@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: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team 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 Sun Jul 2 13:56:06 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD252129AE3 for ; Sun, 2 Jul 2017 13:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 AgxLhA0soBmi for ; Sun, 2 Jul 2017 13:56:00 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 B5EB7129AAD for ; Sun, 2 Jul 2017 13:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wXM4r0jQmsUKz/GXqeqlel3SnSu0oEOfwqU37yyE6M4=; b=64Tnn6CEbAjwFY5ZSiCKfvMiT Fh3dDNRZRC6dtXgzOi67SscvRJlmppN7MoItzicgHGsOy/0PozYyXgb1lbu+KcZShdagUUqY9k4ym 6g2h67V1iUvlWJUBCZqSZ4Id/qTq1EWXHpXZ40Fpbp94IvtJxdOhXtlSY3X5ue7CPyZLtMA/yDnKz oGtyycPu5cTrd/kjXR8vnqIffmi7SK37x44liZp0I3fXiK3doqhyN6zKn0lrnKDhRYTZTHT0vLr3y iQ6jOv3IHkPsrk4KuxSlmPJbdpqPSVsoulhgQtndhDGVBxan93lGCsXR/IiFKBVmRe2vx+UpbWcAV vI1YDPXaQ==; Received: from [31.185.128.124] (port=33508 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dRluP-0003tV-Ve; Sun, 02 Jul 2017 21:55:58 +0100 To: "Mirja Kuehlewind (IETF)" , Martin Stiemerling Cc: Joe Touch , tsv-art@ietf.org References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> <81eb8115-23cc-f9af-5e6f-de63508c8406@isi.edu> <1f121338-a249-fca1-bfef-c16a571b1652@isi.edu> From: Bob Briscoe Message-ID: Date: Sun, 2 Jul 2017 21:55:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1f121338-a249-fca1-bfef-c16a571b1652@isi.edu> Content-Type: multipart/alternative; boundary="------------4804FB3978E5BCA4D5D985C6" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 20:56:05 -0000 This is a multi-part message in MIME format. --------------4804FB3978E5BCA4D5D985C6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I could also check it before your telechat. Does "next Thursday" mean 6 Jul or 13 Jul? I will assume 13 Jul unless otherwise stated. Bob On 30/06/17 21:59, Joe Touch wrote: > I can do a short check next Wed, if that helps. It wouldn't hurt to ask > Fred to check it too. > > Joe > > > On 6/30/2017 1:14 PM, Mirja Kuehlewind (IETF) wrote: >> The document is on the telechat agenda for next Thursday, so in two weeks is too late. I read the doc already and didn’t see any issue. So a short check might be enough… >> >> Mirja >> >> >>> Am 30.06.2017 um 18:03 schrieb Joe Touch : >>> >>> Hi, all, >>> >>> I'm familiar with both TRILL and MTU issues ;-) >>> >>> However, I'm out for the next two weeks; the soonest I could do this >>> would likely be as the IETF begins... >>> >>> Joe >>> >>> >>> On 6/30/2017 3:47 AM, Martin Stiemerling wrote: >>>> Hi, >>>> >>>> I wonder who could and would volunteer to do the tsv-art review for >>>> draft-ietf-trill-mtu-negotiation-06 ? >>>> >>>> Thanks, >>>> >>>> Martin >>>> >>>> _______________________________________________ >>>> Tsv-art mailing list >>>> Tsv-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tsv-art >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------4804FB3978E5BCA4D5D985C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I could also check it before your telechat.
Does "next Thursday" mean 6 Jul or 13 Jul? I will assume 13 Jul unless otherwise stated.


Bob

On 30/06/17 21:59, Joe Touch wrote:
I can do a short check next Wed, if that helps. It wouldn't hurt to ask
Fred to check it too.

Joe


On 6/30/2017 1:14 PM, Mirja Kuehlewind (IETF) wrote:

The document is on the telechat agenda for next Thursday, so in two weeks is too late. I read the doc already and didn’t see any issue. So a short check might be enough…

Mirja



Am 30.06.2017 um 18:03 schrieb Joe Touch <touch@isi.edu>:

Hi, all,

I'm familiar with both TRILL and MTU issues ;-)

However, I'm out for the next two weeks; the soonest I could do this
would likely be as the IETF begins...

Joe


On 6/30/2017 3:47 AM, Martin Stiemerling wrote:

Hi,

I wonder who could and would volunteer to do the tsv-art review for
draft-ietf-trill-mtu-negotiation-06 ?

Thanks,

 Martin

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------4804FB3978E5BCA4D5D985C6-- From nobody Mon Jul 3 07:08:55 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EE212EB78 for ; Mon, 3 Jul 2017 07:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 Qw0he6YTArth for ; Mon, 3 Jul 2017 07:08:52 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 20A28129AF1 for ; Mon, 3 Jul 2017 07:08:51 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-0b-595a4ff2e5a2 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.F0.07915.2FF4A595; Mon, 3 Jul 2017 16:08:50 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.352.0; Mon, 3 Jul 2017 16:08:49 +0200 To: Martin Stiemerling , "tsv-art@ietf.org" References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> From: Magnus Westerlund Message-ID: <73c2f0b5-4e90-0e74-c26b-23040835e19a@ericsson.com> Date: Mon, 3 Jul 2017 16:08:49 +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: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080909020101050405000305" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2J7lO4n/6hIg+1XJS0mPZ3GZDFrzyIW ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSuj9/h5xoLt7hXbr7axNzC+c+hi5OSQEDCR 2LDoI1MXIxeHkMARRomV5+6ygySEBJYxShw8Iw5iCwt4STyddYARxBYRCJHYsWkjM0SNjcSW AzNYQWw2AQuJmz8a2UBsXgF7iUmfZ4LNYRFQkXjStQysV1QgRuLazDusEDWCEidnPmEBsTkF bCW+Xl3CCnIEs0A3o8TSuxugFmhLNDR1sE5g5JuFpGcWsjqQBLOAmcS8zQ+hbG2JZQtfQ9ni EreezGeCsK0lZvw6yAZhK0pM6X7IDmGbSrw++pERwjaSeLenkX0BI+cqRtHi1OKk3HQjY73U oszk4uL8PL281JJNjMDQP7jlt+oOxstvHA8xCnAwKvHw8vhGRQqxJpYVV+YeYlQBmvNow+oL jFIsefl5qUoivHH6QGnelMTKqtSi/Pii0pzU4kOM0hwsSuK8jvsuRAgJpCeWpGanphakFsFk mTg4pRoYjd3/6R26yp/JFmKhrWbfe29leFJNRGlZu/KDx1IL7x6aeyDw9uLFXzb0ik6d2bZ4 7fkye7mzhtsUbUPPuQaxq9jF1ZUqrypeId+XcXvph0f1H5WZjLmWte67m8u28KvjR+8fO1RV H+cGpF8KFk5wlkp9HyT6Z9ppHsnDa//kqM5cO2HBj68uSizFGYmGWsxFxYkAT6Aq+oUCAAA= Archived-At: Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 14:08:54 -0000 --------------ms080909020101050405000305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Den 2017-06-30 kl. 12:47, skrev Martin Stiemerling: > Hi, > > I wonder who could and would volunteer to do the tsv-art review for > draft-ietf-trill-mtu-negotiation-06 ? > Hi, I am not doing a full review, but something for the ADs and the reviewer = to consider is the issues that I have found with the relation between=20 draft-ietf-trill-over-ip-10 and this document. 1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for=20 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=20 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=20 bytes, which is not unheard of, the algorithm in the MTU negotiation=20 draft can't determine it. It will only report the IP path as having an=20 MTU to small when the 1470 bytes probe fail. So, if the Trill authors want to use this as a mechanism, then the MTU=20 negotiation draft needs to be expanded to have more flexible lower=20 boundaries. However, that appear to affect MTU negotiation quite=20 significant as it needs to seperate algorithm for finding MTU, from the=20 different usage of the algorithm with different starting points. Where=20 the normal will have a lower bound of 1470, and be more tightly coupled=20 to Sz when finding Lz. While the Trill-over-IP has a different usage. This can also result in the need to discuss if binary searching is good=20 enough? 2. Another issue, is that I think the algorithm is a bit short on=20 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. 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. No discussion of X*RTT, or timeout values that one uses to determine=20 when a probe is lost. 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 ---------------------------------------------------------------------- --------------ms080909020101050405000305 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 SIb3DQEJBTEPFw0xNzA3MDMxNDA4NDlaMC8GCSqGSIb3DQEJBDEiBCCdCR9j+V2bnNfhSAbH LSio28HJooZwSheL95ounxLTYTBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAbxhXWWOmS2WSypVGlPPAR3LhPZmmfig7cRHqi8VSER4bjfwz /7ZrvM4HHPBsuEyeoSGpa8eLJG/KmnaSSB6HRnheokPiaSuW9G0iwUxV09dPvo3XVEy/O1OQ tvfjZtZvGsNd7swocKMRm6mVQ2Xqy+CeEHbyHYg2+WacFVqdA0YsLEHKoO1of109pQ9l4riP suJPeh+OUN85Lz3q2c24hgSpRR7b2HvSmTeT60tPthKy1+rRwBaFwuewQYvO6yTWSMVqkJjm 7obb6EMTw/B/L8j7Zh5cHnse6W+UarBvhUktwb0p7SD6djDZDTmrISiq5y28zk/wofSrKbsG wUsqfAAAAAAAAA== --------------ms080909020101050405000305-- From nobody Mon Jul 3 08:07:45 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9DF131667 for ; Mon, 3 Jul 2017 08:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 8OtF353GiNe8 for ; Mon, 3 Jul 2017 08:07:41 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07631131661 for ; Mon, 3 Jul 2017 08:07:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=WuOVtbtgYo5RTHfLQtrPzQ8HjQ18AlSU3SJUHBj0KLsQ3r/DpDAhvG7ely0vRNGERLg7UY8Eam7H4vmvXwt/elxaWWuymZfvhoFd2KWHvKGEn5HGDsTKptUzGi5XqHFdn/mh/HD3XdNvxQRfQ5Cx++wAS9jDqd/Q64f64o+SeCc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 25996 invoked from network); 3 Jul 2017 17:07:34 +0200 Received: from unknown (HELO ?10.50.1.84?) (195.1.147.78) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 Jul 2017 17:07:34 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <73c2f0b5-4e90-0e74-c26b-23040835e19a@ericsson.com> Date: Mon, 3 Jul 2017 17:07:32 +0200 Cc: Martin Stiemerling , "tsv-art@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <21298DB7-BAD0-4489-BBAE-714DC68EC986@kuehlewind.net> References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> <73c2f0b5-4e90-0e74-c26b-23040835e19a@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170703150734.25990.72457@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 15:07:44 -0000 Hi Magnus, thanks for the feedback! I wasn=E2=80=99t aware of issue 1 and missed = the issues in 2. Can we assign you as the official tsv-art reviewer and = you send the review directly to the respective mailing list(s)? Regarding issue 1, I think that good to raise now but might rather be a = discuss point on the other doc later evtl. On issue 2, Spencer, can you maybe file a discuss on this given I have = put in my ballot already; otherwise I can also change my ballot... Mirja > Am 03.07.2017 um 16:08 schrieb Magnus Westerlund = : >=20 > Den 2017-06-30 kl. 12:47, skrev Martin Stiemerling: >> Hi, >>=20 >> I wonder who could and would volunteer to do the tsv-art review for >> draft-ietf-trill-mtu-negotiation-06 ? >>=20 >=20 > Hi, >=20 > I am not doing a full review, but something for the ADs and the = reviewer to consider is the issues that I have found with the relation = between draft-ietf-trill-over-ip-10 and this document. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > So, if the Trill 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 seperate 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. >=20 > This can also result in the need to discuss if binary searching is = good enough? >=20 >=20 > 2. Another issue, is that I think the algorithm is a bit short on = transmission scheduling recommendations: >=20 > 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. >=20 > 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. >=20 > 3. This is also unclear on what the criteria is for determining that = something is lost: >=20 > 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. >=20 > No discussion of X*RTT, or timeout values that one uses to determine = when a probe is lost. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Wed Jul 5 06:02:17 2017 Return-Path: X-Original-To: tsv-art@ietf.org Delivered-To: tsv-art@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: [Tsv-art] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Review Team 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 11:02:45 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6849B131D98 for ; Wed, 5 Jul 2017 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 PIZkZgCsJ9uH for ; Wed, 5 Jul 2017 11:02:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 300EF131D80 for ; Wed, 5 Jul 2017 11:02:38 -0700 (PDT) Received: from [128.9.184.181] ([128.9.184.181]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v65I1ZrG029253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Jul 2017 11:01:36 -0700 (PDT) From: Joe Touch To: "Mirja Kuehlewind (IETF)" Cc: Martin Stiemerling , tsv-art@ietf.org References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> <81eb8115-23cc-f9af-5e6f-de63508c8406@isi.edu> <1f121338-a249-fca1-bfef-c16a571b1652@isi.edu> Message-ID: <9af55d80-4937-e50a-13fb-93e1c017c9ea@isi.edu> Date: Wed, 5 Jul 2017 11:01:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1f121338-a249-fca1-bfef-c16a571b1652@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 18:02:39 -0000 Here's a quick summary - it's not thorough enough to post as a TSVART review, though. Joe ------ This document describes a mechanism to discover the MTUs of what transport considers a link layer, notably when its links can support messages larger than the IPv4 and IPv6 minimums. This document focuses on link MTUs. It considers fragmentation and reassembly only for E-L1CS FS-LSP, which is effectively an application layer protocol running directly over the link layer. It isn't clear to me whether this doc is applying INT-area best practices or terminology correctly, but this is a TSV review. IMO, this doc should be more clear that it is determining a "link layer" value, which is not necessarily related to the network layer MTU (which is determined by the receiver's reassembly limit) or the transport MTU (which depends on whether transport uses the network reassembly MTU, link hop MTU, or some other transport reassembly limit). IMO, the doc should also be more clear about what to do with this information - i.e., that it updates the "link MTU", which may or may not be propagated up the stack. I'm a bit uncomfortable with "link MTU size SHOULD be tested, in Sec 2.1 - especially because that recommendation comes after showing a case where the link MTU is calculated incorrectly. IMO, before a link overrides the default MTU, it **MUST** be confirmed BEFORE changing it - especially because network and transport mechanisms to track MTU often assume that link MTUs do not change (for a given link) and that they are reported correctly. I.e., overall, I would suggest that the impact of this doc on MTU discovery and use should be included. Other issues: - the term "port MTU" is introduced in 2.1 but never defined - I don't agree with the security considerations conclusion; this appears to create a new attack vector (report false MTUs to create black holes). Joe From nobody Wed Jul 5 12:19:02 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A95C131479 for ; Wed, 5 Jul 2017 12:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ljdCn678aZIG for ; Wed, 5 Jul 2017 12:18:59 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 4C18A1205F0 for ; Wed, 5 Jul 2017 12:18:59 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id v193so31065131ywg.2 for ; Wed, 05 Jul 2017 12:18:59 -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=skL98gfuiPNLO3/0vV8G0ztfyLTbchlDZFg2ccn4C9I=; b=jeGTfjIzOnfvqA+FPMDAUFcY9hn7kw0aoiMVtInVSC+0xgW+1Nuf3AIOb5uZTh/mYT DaV9xN2ODcx/3afo1wDHSoYalQe3P9TNOvitHt8ze4+N6G8ELadILaQZNEBdiObkGmlo njzyXvmg5OutSZrMLzW8guWiNJmefN7zJgthgrOZ8suAbGVZhxfRbCBDuo49rbiTampi Z3IjYc4nblEMr34hPzOV0pF2P81JzB/4QzdDwJzgKryI8YYAjsXASyZrEVTsjxIRB2l8 PaO2Aut9TKwmY2V84UYu9ur/H+RGwPeNUVKZfpxqQI42nijAIAh2BzPPrSDU7Ntak4Za HM4g== 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=skL98gfuiPNLO3/0vV8G0ztfyLTbchlDZFg2ccn4C9I=; b=HArTpZAXkKQ7UWtbu9Z47CzvgMEmmznY5wj06X2wKZ3KjgoGaCaWcb1s1Tlxre4wPX eMX3V2aFSUqs9U1Tm5FVF6Evygt7t7mRJIiuH8y2sIaq0snl7bxwEM6EyesDdt/K1Luo Ql0pCaN79u9u5dagXyCBDHacsWK6aDcpp0s7CU/Wv8b5XmGML92KzozgLlifOU50icHJ fexzQAxNLeHGg3HOPaaW9BsQB7BZUGMnOrXBSIscIUWeJ66VPYxcyVaz0YLHs7glrszq wP8/qiiG14WAOTctKphmONBjWW86Sof1WOlDxkxxzWL3UIfrbXZmW/wS7nImfEbpaMZn romw== X-Gm-Message-State: AKS2vOw0fEzcgTCYc0o0AvHRNAsFvRgFRZqyD5obKioCYrOSsjKnTzl/ CcX67IuhiU3xZA9jugVtJSMYk+dFuA== X-Received: by 10.13.219.67 with SMTP id d64mr35890703ywe.21.1499282338413; Wed, 05 Jul 2017 12:18:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Wed, 5 Jul 2017 12:18:57 -0700 (PDT) Received: by 10.37.91.137 with HTTP; Wed, 5 Jul 2017 12:18:57 -0700 (PDT) In-Reply-To: <9af55d80-4937-e50a-13fb-93e1c017c9ea@isi.edu> References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> <81eb8115-23cc-f9af-5e6f-de63508c8406@isi.edu> <1f121338-a249-fca1-bfef-c16a571b1652@isi.edu> <9af55d80-4937-e50a-13fb-93e1c017c9ea@isi.edu> From: Spencer Dawkins at IETF Date: Wed, 5 Jul 2017 14:18:57 -0500 Message-ID: To: Joe Touch Cc: tsv-art@ietf.org, Mirja Kuehlewind , Martin Stiemerling Content-Type: multipart/alternative; boundary="001a114fc25c33059b055396dfdb" Archived-At: Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 19:19:01 -0000 --001a114fc25c33059b055396dfdb Content-Type: text/plain; charset="UTF-8" I hit Defer, to let us get organized. Thanks for the help! Spencer On Jul 5, 2017 13:02, "Joe Touch" wrote: > Here's a quick summary - it's not thorough enough to post as a TSVART > review, though. > > Joe > > ------ > > This document describes a mechanism to discover the MTUs of what > transport considers a link layer, notably when its links can support > messages larger than the IPv4 and IPv6 minimums. > > This document focuses on link MTUs. It considers fragmentation and > reassembly only for E-L1CS FS-LSP, which is effectively an application > layer protocol running directly over the link layer. > > It isn't clear to me whether this doc is applying INT-area best > practices or terminology correctly, but this is a TSV review. > > IMO, this doc should be more clear that it is determining a "link layer" > value, which is not necessarily related to the network layer MTU (which > is determined by the receiver's reassembly limit) or the transport MTU > (which depends on whether transport uses the network reassembly MTU, > link hop MTU, or some other transport reassembly limit). > > IMO, the doc should also be more clear about what to do with this > information - i.e., that it updates the "link MTU", which may or may not > be propagated up the stack. > > I'm a bit uncomfortable with "link MTU size SHOULD be tested, in Sec 2.1 > - especially because that recommendation comes after showing a case > where the link MTU is calculated incorrectly. IMO, before a link > overrides the default MTU, it **MUST** be confirmed BEFORE changing it - > especially because network and transport mechanisms to track MTU often > assume that link MTUs do not change (for a given link) and that they are > reported correctly. > > I.e., overall, I would suggest that the impact of this doc on MTU > discovery and use should be included. > > Other issues: > > - the term "port MTU" is introduced in 2.1 but never defined > - I don't agree with the security considerations conclusion; this > appears to create a new attack vector (report false MTUs to create black > holes). > > Joe > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > --001a114fc25c33059b055396dfdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I hit Defer, to let us get organized. Thanks for the help= !

Spencer

On Jul 5, 2017 13:02, &quo= t;Joe Touch" <touch@isi.edu>= ; wrote:
Here's = a quick summary - it's not thorough enough to post as a TSVART
review, though.

Joe

------

This document describes a mechanism to discover the MTUs of what
transport considers a link layer, notably when its links can support
messages larger than the IPv4 and IPv6 minimums.

This document focuses on link MTUs. It considers fragmentation and
reassembly only for E-L1CS FS-LSP, which is effectively an application
layer protocol running directly over the link layer.

It isn't clear to me whether this doc is applying INT-area best
practices or terminology correctly, but this is a TSV review.

IMO, this doc should be more clear that it is determining a "link laye= r"
value, which is not necessarily related to the network layer MTU (which
is determined by the receiver's reassembly limit) or the transport MTU<= br> (which depends on whether transport uses the network reassembly MTU,
link hop MTU, or some other transport reassembly limit).

IMO, the doc should also be more clear about what to do with this
information - i.e., that it updates the "link MTU", which may or = may not
be propagated up the stack.

I'm a bit uncomfortable with "link MTU size SHOULD be tested, in S= ec 2.1
- especially because that recommendation comes after showing a case
where the link MTU is calculated incorrectly. IMO, before a link
overrides the default MTU, it **MUST** be confirmed BEFORE changing it - especially because network and transport mechanisms to track MTU often
assume that link MTUs do not change (for a given link) and that they are reported correctly.

I.e., overall, I would suggest that the impact of this doc on MTU
discovery and use should be included.

Other issues:

- the term "port MTU" is introduced in 2.1 but never defined
- I don't agree with the security considerations conclusion; this
appears to create a new attack vector (report false MTUs to create black holes).

Joe

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art<= br>
--001a114fc25c33059b055396dfdb-- From nobody Wed Jul 5 14:21:11 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753F7131DE3 for ; Wed, 5 Jul 2017 14:21:09 -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=ham 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 cQfoB8pnuQkc for ; Wed, 5 Jul 2017 14:21:07 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 9B2231316A5 for ; Wed, 5 Jul 2017 14:21:07 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id 191so467716vko.2 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=dA+Pg5oRSFltbpoCLBZLJjs6P9bJw8AudiVDsflzSNuEr4nNUZwPbGu+Tm93T3mC4g V0d60ZWRulvkkbMwYk2l+y5XvmfldKLfs0tBO+uH2c4Ao2l4RdoNBVYhrzjzceeHE2ia 3J69VuAD7aXv9oWSfWqmA81183YVXPgPcBLFArPq53ffoQbci7zfdnUg/QFzHfToDYLi bE9r+l5ArTq98VuAYquuU/YDhJjudYGfIF+kD6dlE8ITWn+/lKFs9odtQ1OCALKCwujo 8/C0Iqoyvm0bEEUFYyinxZM03wh6QA185D0nbchFZN9PSWpnlxvZEGOb6/QHfWjqVWOW axhA== X-Gm-Message-State: AIVw111Pm4A3FNggtbuzwlPj3Q0UL9P+H9yWeroxDe6PWubLwTL16Gl1 ZIXV1kKoy9YNtgJokmWgPKFHKvzLGS7r 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: [Tsv-art] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:21:09 -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 Fri Jul 7 22:57:50 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@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: [Tsv-art] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team 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 Mon Jul 10 05:13:51 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@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: [Tsv-art] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team 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 07:23:32 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68479131794; Mon, 10 Jul 2017 07:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bB2pwZNlALDt; Mon, 10 Jul 2017 07:23:28 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 C335E127078; Mon, 10 Jul 2017 07:23:28 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id f194so28448998yba.3; Mon, 10 Jul 2017 07:23:28 -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; bh=coGWIlzgVYzPpl2xJoHeXW5PVUi1ZNHwjsFAO6XXUy4=; b=AIirU38Dhi5wQ+ui73VSURq9/vIwJ8ADU8/Bi0XMB5hzp9ITGojJsRQ2hg9Nr875d2 Lcep9N9OhmNy7rsD0XavP3OliK82wUTws43sKKYgcI+e8a23fhREiRHINw7/L5ETV7IK wWUav7d021hYnMX9ENpBgLYhF6oh9WeMBkPXU9QPqOut8Vh8TrQaanqy8K2VnjPIoxoI kOmrwaNUs3knV5m2VevwL8sbljGjTNr5vE3JctR/bO09suhf8GKIKFc4cxkV6rGClLDs xfdd8DB5/DyWhmgBSxB1DFbk5MObonKBy9dFU43pIUd/6c9Xx9pCRXmd7zFNjmCr1xQg eYCg== 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; bh=coGWIlzgVYzPpl2xJoHeXW5PVUi1ZNHwjsFAO6XXUy4=; b=fAZfgHShpT8YaLsx068eTyWOLu4SXNaT7AENm/EfUZMoQ4MTpqSDx+r4sZ+/bkkykT IQGDrQJpFuXT6PfQIPE2mGwWzgPX2k59Th6wAA1IMCT5NRXWyy/G7EfPxsoLRM1g1hio n/OoCBlkfpsaLpYMlGLFummBH/ppP3t5uVQcyFndNwCVYz20ZaxTCtflrP4BLfZF+wJi CYuCOpCcD8aCT9oMQXJCou5cr8u7+W/nFVaiRPySao9+WAGsQ1raXcST9w8SmRBASmfn urml+hb8HN2R70L4v5GoPQdfr/Q/VTtS/N3Z11xiHhntDbUmNvbM/fyoSx2O6QADKc2p fqAA== X-Gm-Message-State: AIVw110AN2kiAsSYU4yTpB5NENdU/JnJEZVswQJWNLQtJpRyLF6lZx6c 8RCmkQPo0nitbhkXqi7WnSjTOGuvBw== X-Received: by 10.37.230.197 with SMTP id d188mr15639797ybh.37.1499696607680; Mon, 10 Jul 2017 07:23:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.91.137 with HTTP; Mon, 10 Jul 2017 07:23:27 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Mon, 10 Jul 2017 09:23:27 -0500 Message-ID: To: tsv-art@ietf.org, "tsv-chairs@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0afb0a9268a10553f753dd" Archived-At: Subject: Re: [Tsv-art] TSV Dinner at IETF 99 in Prague X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 14:23:30 -0000 --94eb2c0afb0a9268a10553f753dd Content-Type: text/plain; charset="UTF-8" Dear TSV Chairs and Area Review Team, On Wed, Jun 14, 2017 at 10:36 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Dear TSV Chairs and TSV Area Review Team, > > We will be gathering for our usual TSV Chairs/TSV ART dinner on Monday > evening in Prague. > > Please let us know if you are able to join us, by July 13 (Thursday before > IETF week), so we can arrange a suitable venue. > > The participation poll is at http://doodle.com/poll/qrvm7nqwe2s84uky. > > Please let us know via poll comments if you have any dietary restrictions > we should know about when planning the event. > > Thanks! > > Spencer and Mirja > Mirja and I will be making our reservation this coming Friday (July 14). If you plan to join us, please RSVP on Doodle before then, so we'll have a semi-accurate headcount! Thanks, Spencer --94eb2c0afb0a9268a10553f753dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TSV Chairs and Area Review Team,=C2=A0

On Wed, Jun 14, 2017 at 10:36 AM= , Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com&g= t; wrote:
Dear TS= V Chairs and TSV Area Review Team,

We will be gathering for our usu= al TSV Chairs/TSV ART dinner on Monday evening in Prague.

Please let= us know if you are able to join us, by July 13 (Thursday before IETF week)= , so we can arrange a suitable venue.

The particip= ation poll is at http://doodle.com/poll/qrvm7nqwe2s84uky.

Please let us know via poll comments if you have any dietar= y restrictions we should know about when planning the event.

=
Thanks!

Spencer and Mirja

Mirja and I will be making our reservation t= his coming Friday (July 14). If you plan to join us, please RSVP on Doodle = before then, so we'll have a semi-accurate headcount!

Thanks,

Spencer=C2=A0

--94eb2c0afb0a9268a10553f753dd-- From nobody Wed Jul 12 03:50:17 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@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: [Tsv-art] Tsvart telechat review of draft-ietf-trill-mtu-negotiation-06 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team 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 Wed Jul 12 12:32:01 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEC413174E for ; Wed, 12 Jul 2017 12:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 Q-LfWogedq_G for ; Wed, 12 Jul 2017 12:31:58 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 6E63C13178B for ; Wed, 12 Jul 2017 12:31:57 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id m84so22090123ita.0 for ; Wed, 12 Jul 2017 12:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=oHGRqePB1OUsUGDn/C9Ynk0KIjCPq0q8jCNsOyOhgLs=; b=R551lvfVRyO9+zpg7EdqGQ+kLcYDjUnJrnhHqNWn+MHcEmGLSGJoLP2Wp45DhiUXoh Tn1kkh/NYUKhP8pJ08+38BN544ZH2qwFs0LKlVu66Rll73Ohb4ub91bGTUVQOQj8G/Ub M+5w2U4DxoXc9QnKV5XKbsHciS4LnsNCWt+tUhyLjn8trv7abU50VZeWVNubVfov/+rs SS0fRN96QLpCp3MUEG4wKGCeppwhptyiS3woo+Nn4hsAsLP0QxePFcHxO7KKwaGpY8Cq 3f2KakJO0cwaRQKzD36YAjdZhZyMrZNyBmPTKn1QmAbAbRxaRV+9eJ7hrUHCi17pwlDT rAMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oHGRqePB1OUsUGDn/C9Ynk0KIjCPq0q8jCNsOyOhgLs=; b=EbyFaoHwTJmJJsZhDpDe2wFQqs7zcbBIFQNK14dYMxCkStvGtpfArpKhUkmQX7CNmO NwbNX0SxsUBm59x6Rnn2cNkNQXIoPfbdT+zsOGrMqvwAmqg7m7+II9DF0FaVOU5vTr4D 6Tly3r+P+Ioepu9Q8t4PvzZG3Wr2B1fae0sI1bhKTymjEZVt0tXnjjjnka/M4gooycjt 7qL7wwIFqr8GqAk8v8WLrskYy7Zn+1NliNX+115Ui8If6X7Di8QmeM6txA+C5PAtBHVl NvRqMhPlck3DHWZU71On8Eh9nwp51egY7+kMr+BalRoj20nfgEdXLwPEwvpYH2M8Aj5W Ir3Q== X-Gm-Message-State: AIVw111p0VL/o3bifsG0wYMG/tPIvriby11FqAyAt9LNuBnLkeaIU6y5 RYx6t7TfW1qA0+mgGKgiHg== X-Received: by 10.107.173.15 with SMTP id w15mr161759ioe.99.1499887916458; Wed, 12 Jul 2017 12:31:56 -0700 (PDT) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id b24sm1954109iod.11.2017.07.12.12.31.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jul 2017 12:31:55 -0700 (PDT) To: tsv-art@ietf.org References: From: Wesley Eddy Message-ID: <67476ec5-2e50-bd27-de97-16aaabc9c078@mti-systems.com> Date: Wed, 12 Jul 2017 15:31:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 19:32:00 -0000 On 7/1/2017 2:03 PM, Donald Eastlake wrote: > On Sat, Jul 1, 2017 at 10:53 AM, Black, David wrote: >> Also, as noted earlier in this discussion, RFC 7657 explicitly discourages use of multiple DSCPs in a single TCP connection. That needs to be reflected in the TCP encapsulation text in the trill-over-ip draft - in particular, 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 encapsulation. > I'm surprised it only "discourages" rather than "prohibits"... > > RFC 1122 section 4.2.4.2 might be of interest. It says that TOS "SHOULD" be able to change during TCP connection lifetime. The example given there is an SMTP connection whose nature might change during its lifetime. I'm not saying whether or not this is really still a sensible concern, just pointing it out. The change from TOS to DSCP terminology and semantics didn't make any change here as far as I can tell. From nobody Thu Jul 13 05:42:53 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5EA131A67 for ; Thu, 13 Jul 2017 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 PIsOA6PGTAxG for ; Thu, 13 Jul 2017 05:42:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 D4B1E12EC13 for ; Thu, 13 Jul 2017 05:42:49 -0700 (PDT) Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6DCfj2d017223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 05:42:04 -0700 (PDT) To: Wesley Eddy , tsv-art@ietf.org References: <67476ec5-2e50-bd27-de97-16aaabc9c078@mti-systems.com> From: Joe Touch Message-ID: <1dcb8ba7-5403-435f-9637-1b2cdf2f5247@isi.edu> Date: Thu, 13 Jul 2017 05:41:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <67476ec5-2e50-bd27-de97-16aaabc9c078@mti-systems.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 12:42:51 -0000 Hi, Wes (et al.), On 7/12/2017 12:31 PM, Wesley Eddy wrote: > On 7/1/2017 2:03 PM, Donald Eastlake wrote: >> On Sat, Jul 1, 2017 at 10:53 AM, Black, David >> wrote: >>> Also, as noted earlier in this discussion, RFC 7657 explicitly >>> discourages use of multiple DSCPs in a single TCP connection. That >>> needs to be reflected in the TCP encapsulation text in the >>> trill-over-ip draft - in particular, 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 encapsulation. >> I'm surprised it only "discourages" rather than "prohibits"... >> >> > > RFC 1122 section 4.2.4.2 might be of interest. > > It says that TOS "SHOULD" be able to change during TCP connection > lifetime. The example given there is an SMTP connection whose nature > might change during its lifetime. > > I'm not saying whether or not this is really still a sensible concern, > just pointing it out. > > The change from TOS to DSCP terminology and semantics didn't make any > change here as far as I can tell. Agreed, but only on that point. My interpretation of the relevant RFC1122 text is that it's OK for a TCP session to "shift" from one TOS (or DSCP) to another when the nature of its transfer changes. I would expect those changes to be infrequent and atypical. I would not expect a single TCP connection to issue individual segments with TOS (or DSCP) values that change nearly every segment, which would be the consequence of copying those values from the payload of encapsulated traffic. Furthermore, it would be impossible to determine the appropriate DSCP values when a segment contains all or part of more than one encapsulated packet with different values. Joe From nobody Thu Jul 13 05:59:42 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B22D13167F for ; Thu, 13 Jul 2017 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 27L19k0bdBqz for ; Thu, 13 Jul 2017 05:59:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 95E8312EB99 for ; Thu, 13 Jul 2017 05:59:38 -0700 (PDT) Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6DCxCpR021454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 05:59:23 -0700 (PDT) From: Joe Touch To: Wesley Eddy , tsv-art@ietf.org References: <67476ec5-2e50-bd27-de97-16aaabc9c078@mti-systems.com> <1dcb8ba7-5403-435f-9637-1b2cdf2f5247@isi.edu> Message-ID: Date: Thu, 13 Jul 2017 05:59:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1dcb8ba7-5403-435f-9637-1b2cdf2f5247@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 12:59:40 -0000 Two additional points that are very important for this doc: 1) RFC1122 admits there might not even be an API to make such a change after a connection has been established, so trill-over-IP cannot rely on it and must explain what to do if that API is not supported. 2) RFC1122 mentions this as an API issue - there is NO way that TCP can know which trill packets will end up in a given TCP segment from the existing TCP API, thus it would never be clear how or when to make such a TOS/DSCP change unless it was persistent and relatively stable (again, that's the intent AFAICT from the RFC1122 text). Using TCP is *never* merely a matter of "throw on a TCP header". Joe On 7/13/2017 5:41 AM, Joe Touch wrote: > Hi, Wes (et al.), > > > On 7/12/2017 12:31 PM, Wesley Eddy wrote: >> On 7/1/2017 2:03 PM, Donald Eastlake wrote: >>> On Sat, Jul 1, 2017 at 10:53 AM, Black, David >>> wrote: >>>> Also, as noted earlier in this discussion, RFC 7657 explicitly >>>> discourages use of multiple DSCPs in a single TCP connection. That >>>> needs to be reflected in the TCP encapsulation text in the >>>> trill-over-ip draft - in particular, 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 encapsulation. >>> I'm surprised it only "discourages" rather than "prohibits"... >>> >>> >> RFC 1122 section 4.2.4.2 might be of interest. >> >> It says that TOS "SHOULD" be able to change during TCP connection >> lifetime. The example given there is an SMTP connection whose nature >> might change during its lifetime. >> >> I'm not saying whether or not this is really still a sensible concern, >> just pointing it out. >> >> The change from TOS to DSCP terminology and semantics didn't make any >> change here as far as I can tell. > Agreed, but only on that point. > > My interpretation of the relevant RFC1122 text is that it's OK for a TCP > session to "shift" from one TOS (or DSCP) to another when the nature of > its transfer changes. I would expect those changes to be infrequent and > atypical. > > I would not expect a single TCP connection to issue individual segments > with TOS (or DSCP) values that change nearly every segment, which would > be the consequence of copying those values from the payload of > encapsulated traffic. Furthermore, it would be impossible to determine > the appropriate DSCP values when a segment contains all or part of more > than one encapsulated packet with different values. > > Joe > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Thu Jul 13 06:41:30 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039C6131A6F for ; Thu, 13 Jul 2017 06:41:29 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-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 Kc5gUgS9VMZ8 for ; Thu, 13 Jul 2017 06:41:27 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 38B5C131699 for ; Thu, 13 Jul 2017 06:41:27 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id m68so39330690ith.1 for ; Thu, 13 Jul 2017 06:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=UbBz/BauU5SvgRHrEIXEp1ICLdyYWOjivpvZJe9qIdk=; b=kWS5i9j8FLF8efgb0GLCmQrr6ZOEB7TnvBdEg1G92ONuS/aZmz58QuEjlqDPxmT1Tr nC6HXYx8+vqcQFV7UVs3T8Wd0UNY0edyPTafJzVZm66X3Cji1UTMhzbjspgGWqFrOR9T KQM+v6r4+jk3FBpI0Yyw3sQoZEMu3bm1nCFACEHGPngbOmtXFLzWMMlpL8rox/JD5bw9 QU6OwXSao5cczbimY34LPmZDh91F8dTuwCJv9aFzQUK3QPVGiBHP/sSbXGK+9ADqtGjn N7fuGkknNy4HPU0ACeiKBaP2LRRSKBSEhXMt64E00M4SBrmImyusK1VBIaMNMgb8PnMO FocQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=UbBz/BauU5SvgRHrEIXEp1ICLdyYWOjivpvZJe9qIdk=; b=pS6dwPxxWTkMVM2XUcU42k8kV/kSEc4F7NS4UDUw1HkgCTCfVFmlPjCgJ+JqN1/wKo YNAflGYmLaf169P0jVHgbNScYR1G0qTKDvjOqRYFY+pC2K9ll570ZkCAzgsp8oZ0xYBK kaUF7doNJs2RbHxQR5phU+lDt+eKHcbcVS8CPNSh472gkuRAFVt+KxUWNfis9Zss9tAB a6KM5nDQBH2/44EvB+HkYoBJDfnYD+LZY09hMmiDbRsv/uLqhcD4fD10Stbm6eSQr3MO qKLZOFmPuOEtWGp7TVKr5S/gCAclMpraStD+ys7lW8MvzEZoLJ4YMNSC3eGZBHeZ3+8p dENA== X-Gm-Message-State: AIVw110C0tiLyugihosqJamAvlyLveMVQoBJjPuDtUM1xIOkDES0MRes wVOPnzaXPzIswii2P72WAQ== X-Received: by 10.36.58.6 with SMTP id m6mr26706392itm.43.1499953286312; Thu, 13 Jul 2017 06:41:26 -0700 (PDT) Received: from [192.168.1.105] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id i139sm2740960iti.17.2017.07.13.06.41.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jul 2017 06:41:25 -0700 (PDT) To: Joe Touch , tsv-art@ietf.org References: <67476ec5-2e50-bd27-de97-16aaabc9c078@mti-systems.com> <1dcb8ba7-5403-435f-9637-1b2cdf2f5247@isi.edu> From: Wesley Eddy Message-ID: <52bbffe7-0f6d-dfc0-dcc0-b0eb491f9aa9@mti-systems.com> Date: Thu, 13 Jul 2017 09:41:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 13:41:29 -0000 I agree on all points, and with the absurdity of trying to change DSCP on a TCP connection per encapsulated packet. If the DSCP values used for a TCP connection change over time, it should be "coarse grained" (e.g. with say hundreds or thousands of segments in between changes) and not anywhere near per-segment. But while obvious to us, I don't think this is in any RFC to be quoted. On 7/13/2017 8:59 AM, Joe Touch wrote: > Two additional points that are very important for this doc: > > 1) RFC1122 admits there might not even be an API to make such a change > after a connection has been established, so trill-over-IP cannot rely on > it and must explain what to do if that API is not supported. > > 2) RFC1122 mentions this as an API issue - there is NO way that TCP can > know which trill packets will end up in a given TCP segment from the > existing TCP API, thus it would never be clear how or when to make such > a TOS/DSCP change unless it was persistent and relatively stable (again, > that's the intent AFAICT from the RFC1122 text). > > Using TCP is *never* merely a matter of "throw on a TCP header". > > Joe > > > On 7/13/2017 5:41 AM, Joe Touch wrote: >> Hi, Wes (et al.), >> >> >> On 7/12/2017 12:31 PM, Wesley Eddy wrote: >>> On 7/1/2017 2:03 PM, Donald Eastlake wrote: >>>> On Sat, Jul 1, 2017 at 10:53 AM, Black, David >>>> wrote: >>>>> Also, as noted earlier in this discussion, RFC 7657 explicitly >>>>> discourages use of multiple DSCPs in a single TCP connection. That >>>>> needs to be reflected in the TCP encapsulation text in the >>>>> trill-over-ip draft - in particular, 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 encapsulation. >>>> I'm surprised it only "discourages" rather than "prohibits"... >>>> >>>> >>> RFC 1122 section 4.2.4.2 might be of interest. >>> >>> It says that TOS "SHOULD" be able to change during TCP connection >>> lifetime. The example given there is an SMTP connection whose nature >>> might change during its lifetime. >>> >>> I'm not saying whether or not this is really still a sensible concern, >>> just pointing it out. >>> >>> The change from TOS to DSCP terminology and semantics didn't make any >>> change here as far as I can tell. >> Agreed, but only on that point. >> >> My interpretation of the relevant RFC1122 text is that it's OK for a TCP >> session to "shift" from one TOS (or DSCP) to another when the nature of >> its transfer changes. I would expect those changes to be infrequent and >> atypical. >> >> I would not expect a single TCP connection to issue individual segments >> with TOS (or DSCP) values that change nearly every segment, which would >> be the consequence of copying those values from the payload of >> encapsulated traffic. Furthermore, it would be impossible to determine >> the appropriate DSCP values when a segment contains all or part of more >> than one encapsulated packet with different values. >> >> Joe >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art From nobody Thu Jul 13 08:48:08 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3203C12702E for ; Thu, 13 Jul 2017 08:48:03 -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 (1024-bit key) header.d=dell.com header.b=iPfynnFl; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=ohJFEsY+ 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 ipAsMgzTO84U for ; Thu, 13 Jul 2017 08:48:01 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 3B4CF127B57 for ; Thu, 13 Jul 2017 08:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1499960878; x=1531496878; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uNbQpENX7q/eU+Lgx1NDCz+EdBOQbJx20Z/1AtpHlAg=; b=iPfynnFluy/DZnpV2emi+HNBHudEhG88/pwBFrMsnHEVgoGcThV1V2E/ DFBYHpYWmultcn9nw3TBaS259qHhjiZLRnNZhfpRWy5L5s0g/BHKbUZ5t bPNh4SsTq+CbUBChmaY0LVLt15Q8anK70Dlygj2803+zXmsKAoJhbM9Zm E=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2017 10:47:57 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2017 21:47:56 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6DFlsoL013604 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Jul 2017 11:47:55 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v6DFlsoL013604 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1499960875; bh=7+KdRPImTLTpG8ePpXtT/HBB6Xc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ohJFEsY+HqZNLEy5cg3Z+nUUQg757wI9y9f6Tl52OkmkCNSOGnwS6UiGmbmgwhk3/ KVk09cu+5e/iDZETwA57Ytc+57uJkReFFuEKHBQcpgRnBvYlQPqlaKMROBE7D+076w S/hTjaiHjLP/YTJtaXkT1dp8LlMaxMQ8KrvHki4Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v6DFlsoL013604 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd03.lss.emc.com (RSA Interceptor); Thu, 13 Jul 2017 11:47:33 -0400 Received: from MXHUB316.corp.emc.com (MXHUB316.corp.emc.com [10.146.3.94]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v6DFlXIW008435 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 13 Jul 2017 11:47:34 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB316.corp.emc.com ([10.146.3.94]) with mapi id 14.03.0352.000; Thu, 13 Jul 2017 11:47:33 -0400 To: Wesley Eddy , "tsv-art@ietf.org" Thread-Topic: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations Thread-Index: AdLurvO3SYOqL32fRKuavuJggYEWYwDffoiAABLbSJAAD2LGgAIsSVsAACP3IQAAAJwqAAABeZgAAAQXn8A= Date: Thu, 13 Jul 2017 15:47:31 +0000 Message-ID: References: <67476ec5-2e50-bd27-de97-16aaabc9c078@mti-systems.com> <1dcb8ba7-5403-435f-9637-1b2cdf2f5247@isi.edu> <52bbffe7-0f6d-dfc0-dcc0-b0eb491f9aa9@mti-systems.com> In-Reply-To: <52bbffe7-0f6d-dfc0-dcc0-b0eb491f9aa9@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.21.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 15:48:03 -0000 > -----Original Message----- > From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Wesley Eddy > Sent: Thursday, July 13, 2017 9:41 AM > To: Joe Touch ; tsv-art@ietf.org > Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10= - ECN & > DSCP considerations >=20 > I agree on all points, and with the absurdity of trying to change DSCP > on a TCP connection per encapsulated packet. If the DSCP values used > for a TCP connection change over time, it should be "coarse grained" > (e.g. with say hundreds or thousands of segments in between changes) and > not anywhere near per-segment. >=20 > But while obvious to us, I don't think this is in any RFC to be quoted. [David>] RFC 7657 - this is discussed in sections 5.1 & 5.3 and summarized = as a bullet point in section 6. >=20 >=20 > On 7/13/2017 8:59 AM, Joe Touch wrote: > > Two additional points that are very important for this doc: > > > > 1) RFC1122 admits there might not even be an API to make such a change > > after a connection has been established, so trill-over-IP cannot rely o= n > > it and must explain what to do if that API is not supported. > > > > 2) RFC1122 mentions this as an API issue - there is NO way that TCP can > > know which trill packets will end up in a given TCP segment from the > > existing TCP API, thus it would never be clear how or when to make such > > a TOS/DSCP change unless it was persistent and relatively stable (again= , > > that's the intent AFAICT from the RFC1122 text). > > > > Using TCP is *never* merely a matter of "throw on a TCP header". > > > > Joe > > > > > > On 7/13/2017 5:41 AM, Joe Touch wrote: > >> Hi, Wes (et al.), > >> > >> > >> On 7/12/2017 12:31 PM, Wesley Eddy wrote: > >>> On 7/1/2017 2:03 PM, Donald Eastlake wrote: > >>>> On Sat, Jul 1, 2017 at 10:53 AM, Black, David > >>>> wrote: > >>>>> Also, as noted earlier in this discussion, RFC 7657 explicitly > >>>>> discourages use of multiple DSCPs in a single TCP connection. That > >>>>> needs to be reflected in the TCP encapsulation text in the > >>>>> trill-over-ip draft - in particular, 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 encapsulation. > >>>> I'm surprised it only "discourages" rather than "prohibits"... > >>>> > >>>> > >>> RFC 1122 section 4.2.4.2 might be of interest. > >>> > >>> It says that TOS "SHOULD" be able to change during TCP connection > >>> lifetime. The example given there is an SMTP connection whose nature > >>> might change during its lifetime. > >>> > >>> I'm not saying whether or not this is really still a sensible concern= , > >>> just pointing it out. > >>> > >>> The change from TOS to DSCP terminology and semantics didn't make any > >>> change here as far as I can tell. > >> Agreed, but only on that point. > >> > >> My interpretation of the relevant RFC1122 text is that it's OK for a T= CP > >> session to "shift" from one TOS (or DSCP) to another when the nature o= f > >> its transfer changes. I would expect those changes to be infrequent an= d > >> atypical. > >> > >> I would not expect a single TCP connection to issue individual segment= s > >> with TOS (or DSCP) values that change nearly every segment, which woul= d > >> be the consequence of copying those values from the payload of > >> encapsulated traffic. Furthermore, it would be impossible to determine > >> the appropriate DSCP values when a segment contains all or part of mor= e > >> than one encapsulated packet with different values. > >> > >> Joe > >> > >> _______________________________________________ > >> Tsv-art mailing list > >> Tsv-art@ietf.org > >> https://www.ietf.org/mailman/listinfo/tsv-art >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Thu Jul 13 09:05:39 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B68E1316ED for ; Thu, 13 Jul 2017 09:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 BHUhM-Zudehd for ; Thu, 13 Jul 2017 09:05:37 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 7EC4113144E for ; Thu, 13 Jul 2017 09:05:37 -0700 (PDT) Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v6DG5Q4s012372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 09:05:28 -0700 (PDT) To: "Black, David" , Wesley Eddy , "tsv-art@ietf.org" References: <67476ec5-2e50-bd27-de97-16aaabc9c078@mti-systems.com> <1dcb8ba7-5403-435f-9637-1b2cdf2f5247@isi.edu> <52bbffe7-0f6d-dfc0-dcc0-b0eb491f9aa9@mti-systems.com> From: Joe Touch Message-ID: <70c1492c-58ea-3cbc-752c-170f3bf9707a@isi.edu> Date: Thu, 13 Jul 2017 09:05:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------62EA9FCDF3C92891B6DDB004" Content-Language: en-US X-MailScanner-ID: v6DG5Q4s012372 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 16:05:39 -0000 This is a multi-part message in MIME format. --------------62EA9FCDF3C92891B6DDB004 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/13/2017 8:47 AM, Black, David wrote: >> I agree on all points, and with the absurdity of trying to change DSCP >> on a TCP connection per encapsulated packet. If the DSCP values used >> for a TCP connection change over time, it should be "coarse grained" >> (e.g. with say hundreds or thousands of segments in between changes) and >> not anywhere near per-segment. >> >> But while obvious to us, I don't think this is in any RFC to be quoted. > [David>] RFC 7657 - this is discussed in sections 5.1 & 5.3 and summarized as a bullet point in section 6. Those sections reinforce the idea that it SHOULD NOT be changed, but don't explain (AFAICT) the conditions under which it might be safe or appropriate to change it (e.g., over longer timescales). Joe --------------62EA9FCDF3C92891B6DDB004 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 7/13/2017 8:47 AM, Black, David wrote:
I agree on all points, and with the absurdity of trying to change DSCP
on a TCP connection per encapsulated packet.  If the DSCP values used
for a TCP connection change over time, it should be "coarse grained"
(e.g. with say hundreds or thousands of segments in between changes) and
not anywhere near per-segment.

But while obvious to us, I don't think this is in any RFC to be quoted.

[David>] RFC 7657 - this is discussed in sections 5.1 & 5.3 and summarized as a bullet point in section 6.
Those sections reinforce the idea that it SHOULD NOT be changed, but don't explain (AFAICT) the conditions under which it might be safe or appropriate to change it (e.g., over longer timescales).

Joe
--------------62EA9FCDF3C92891B6DDB004-- From nobody Sat Jul 15 14:10:28 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1AC12F26C; Sat, 15 Jul 2017 14:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 JpPc7bUHz248; Sat, 15 Jul 2017 14:10:25 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 BCB82129B06; Sat, 15 Jul 2017 14:10:25 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l21so36256802ywb.1; Sat, 15 Jul 2017 14:10:25 -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=Fv2Xqr0Fudt3CMRkr8qipfUVUQo312v9Bz1csYuUvvs=; b=uCinfI6+k+RH0DoqLgDCQE2+Pg1Sh9Sc3qbIaKaWTv5a+mFu0PaFIdG9ZfPePjdIBW qtCnmR8YuaD5JJusWz/EbZTyfOvJFvAxnbs7XfedAwjfYAygI+NhDSiD/ypFP8ct7Nxa WB7TCPdgIstVg7uSRPHffmYEFEfedS4JL5olvs1sDju9CL2BWs7cZriQibhMLB/DOKH7 oYgm572noMjtNmwQ5yj47U463z6AN2fz0LvEAe0RJO5bS1xISY1y9EAM9H1fetcNWw+v JOLxOJYET3GkCVDG0GVtHtei/pN/khiLPZ9djYZOFVTQt1LaHUxajMSAjLtHHpP821Ug dtXA== 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=Fv2Xqr0Fudt3CMRkr8qipfUVUQo312v9Bz1csYuUvvs=; b=nMsLIrZ+cTGHqBibPkRnE9KyOei540s4+AfkwjZMcMDQgYsHrcMgI0wU5gBiPHJQxh SNpltpHpvt/iQR5U+/jSk3tan0P9BUFsUAnf1bTrugJ2Dsc30UiyCnAuUoTWphhVjpoR VOI5y4H3gOzhJB6+xW6yhogK3FF09vQ+YzoBFoj0kFHq34pdFhoemz5qYTNKSNup03KN HRH3krasj4gTxIWmk5ROXm/H8q9a42ZLbvaS9YLXN3uM1DKMXmNET3QDTLcQr7XMjKn3 xBh+2yBU9Ki9KfY2LNuABNbHdeWoiBCJTi1jcRbwk//FChj0mP3q19aAbpvb9rV5R3IG 7vCw== X-Gm-Message-State: AIVw1128cHc3n8hsA7Fir+KasQzi9/rlK78bQ1/yJOES3/5edcMK7K9X JmTllymollrO1Whrkyv9Hv8sc0KJOt43jv0= X-Received: by 10.129.76.214 with SMTP id z205mr12016852ywa.273.1500153024740; Sat, 15 Jul 2017 14:10:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.101 with HTTP; Sat, 15 Jul 2017 14:10:24 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Sat, 15 Jul 2017 16:10:24 -0500 Message-ID: To: tsv-art@ietf.org, "tsv-chairs@ietf.org" Cc: "gonzalo.camarillo@ericsson.com" Content-Type: multipart/alternative; boundary="001a113f1d10260c1705546198fe" Archived-At: Subject: Re: [Tsv-art] TSV Dinner at IETF 99 in Prague X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 21:10:27 -0000 --001a113f1d10260c1705546198fe Content-Type: text/plain; charset="UTF-8" Dear TSV Chairs and Reviewers, We now have a reservation for Monday evening for the TSV Dinner. We'll be at Pivovar Narodni. It's a brewery, I believe. The address is Narodni 8 , Prague, Czech Republic. The last working group session on Monday ends at 18:40. I'd suggest that we meet at the IETF Registration desk on LL at 1900. We've had a few folks who RSVPed and can't come, so if you haven't RSVPed and would like to come, we can accommodate that - but please let Mirja and Spencer know that you're coming! The Google translation of the German tripadvisor page is https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.tripadvisor.de%2FRestaurant_Review-g274707-d8380743-Reviews-Pivovar_Narodni-Prague_Bohemia.html&edit-text= I look forward to seeing you there! Spencer and Mirja --001a113f1d10260c1705546198fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TSV Chairs and Reviewers,

We now have a r= eservation for Monday evening for the TSV Dinner.

We'll be at Pi= vovar Narodni.=C2=A0It's a brewery, I believe.

The address is Na= rodni 8 , Prague, Czech Republic.

The last working group sess= ion on Monday ends at 18:40. I'd suggest that we meet at the IETF Regis= tration desk on LL at 1900.

We've had a few fo= lks who RSVPed and can't come, so if you haven't RSVPed and would l= ike to come, we can accommodate that - but please let Mirja and Spencer kno= w that you're coming!


I look forward to see= ing you there!

Spencer and Mirja
--001a113f1d10260c1705546198fe-- From nobody Mon Jul 17 09:37:32 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B03131A88 for ; Mon, 17 Jul 2017 09:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 66Z8HO_T5BXv for ; Mon, 17 Jul 2017 09:37:29 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679CE131B4E for ; Mon, 17 Jul 2017 09:37:29 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id d136so12416109qkg.3 for ; Mon, 17 Jul 2017 09:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UquZrWsJUt387D/EsCbBf0qq+ma4TnzUjqh36s+JnxI=; b=FeJPUmB24a1q3yiKsex/aTqPVTvMT91aLRHe43gLg0C0RzDdPQ9KC/YEm/L/5wKC1p EBl47YqabP7gtWadGhdAs+VYDb1qK2AtTFaT131NXQCoj6lqlNo1E4DDcYTSHq8Dhk7q qtniK+DZ4XKtcZalqD7I+qSLGMeCMiJ/IG5Lo= 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=UquZrWsJUt387D/EsCbBf0qq+ma4TnzUjqh36s+JnxI=; b=Hl25O175s6inI5oRWfM7kIGaL3Fkelk7Ye9fBj50mUPrvg3Vd5ZcwQ/jOHn7rPbfqL 5X5MaLoGmGWCAuujUW67QvIumbevWMULhxTETmoIMLbHNFBfkMTCbwp54ASCX7c1dGKM 8qW6MS4m0Rut2ieM1+/6nyJTs6wcmhVLoq02EqIuDiJmKACsM7NLXOsVWz0ZjyCf2xG0 /poysI/wRyR/l9mROo1c35a7AcZe6+7Frx+IB09FrPTTLH3ue6j0KwzQgJOfuLwwm5db VULmm6YUAWnQAAYPMtkPA8t2Y9+6sUOQZ9K63TmsmMJ7gQQumFHAH4ZcGPqf20fK96dQ na7w== X-Gm-Message-State: AIVw110fNuP3dqnKhu3Bx6haYcMCDNgm6GpiXgZORKlfLBGoYx4F7PaK shz6LogWurjqZnGHakD/dR0iTJQi7ma2 X-Received: by 10.55.72.206 with SMTP id v197mr2870026qka.133.1500309448372; Mon, 17 Jul 2017 09:37:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Mon, 17 Jul 2017 09:37:27 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:8060:f380:6359:225d] In-Reply-To: References: From: Kyle Rose Date: Mon, 17 Jul 2017 18:37:27 +0200 Message-ID: To: Spencer Dawkins at IETF Cc: tsv-art@ietf.org, "tsv-chairs@ietf.org" , "gonzalo.camarillo@ericsson.com" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Tsv-art] TSV Dinner at IETF 99 in Prague X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:37:31 -0000 Whoever wants to walk from the Hilton to the restaurant: Please meet in the lobby at 6:45. As I write this, that is 9 minutes away. It's a 30+ minute walk, so we won't wait too long. Kyle On Sat, Jul 15, 2017 at 11:10 PM, Spencer Dawkins at IETF wrote: > Dear TSV Chairs and Reviewers, > > We now have a reservation for Monday evening for the TSV Dinner. > > We'll be at Pivovar Narodni. It's a brewery, I believe. > > The address is Narodni 8 , Prague, Czech Republic. > > The last working group session on Monday ends at 18:40. I'd suggest that we > meet at the IETF Registration desk on LL at 1900. > > We've had a few folks who RSVPed and can't come, so if you haven't RSVPed > and would like to come, we can accommodate that - but please let Mirja and > Spencer know that you're coming! > > The Google translation of the German tripadvisor page is > https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.tripadvisor.de%2FRestaurant_Review-g274707-d8380743-Reviews-Pivovar_Narodni-Prague_Bohemia.html&edit-text= > > I look forward to seeing you there! > > Spencer and Mirja From nobody Mon Jul 17 11:11:18 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A1F129AF6; Mon, 17 Jul 2017 11:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 oPFIVhOkq6Ol; Mon, 17 Jul 2017 11:11:15 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF0912EB5D; Mon, 17 Jul 2017 11:11:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,375,1496127600"; d="asc'?scan'208";a="206368178" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx143-out.netapp.com with ESMTP; 17 Jul 2017 10:44:56 -0700 Received: from VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Jul 2017 11:05:51 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Mon, 17 Jul 2017 11:05:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Uee1lpFNNa8T7nlnTLCTSnMtRYHR54JGaR1PkQ1z5TM=; b=Mf48+nCqguc3Yu9tdq/BOyD+sBvJGY+bllsJscbgt8kwlkrZYfOEFdKfAAFtkfbkHZYi/KFCdv1WJzr+vxBDyWBZIMb9jZsYHuObMwBJEHMGw/g5XyxRy9pF/Wmg99DzyQT7x/oy6y2DoR/L5Nmz7pEv0wLMmJPfRugJ8S/1rzE= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 18:05:58 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1261.024; Mon, 17 Jul 2017 18:05:57 +0000 From: "Eggert, Lars" To: Kyle Rose CC: Spencer Dawkins at IETF , "tsv-art@ietf.org" , "tsv-chairs@ietf.org" , Gonzalo Camarillo Thread-Topic: TSV Dinner at IETF 99 in Prague Thread-Index: AQHS5SQS8mzqsH1RKUq5pJOaOTnjYaJNReiAgAhNXACAAthngIAAGLkA Date: Mon, 17 Jul 2017 18:05:57 +0000 Message-ID: <320D7E0C-B4DE-4176-9BE9-B01E481623BD@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: krose.org; dkim=none (message not signed) header.d=none;krose.org; dmarc=none action=none header.from=netapp.com; x-originating-ip: [2001:67c:370:128:d5b2:1370:ce4b:fc03] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 7:RLhCnRXqu/5qR2mzxBr70OYfIVWmXZUpRZ6v+UHcqpIlRSYwT75+OJ7bNztZuBDipDfwlxIpUa1T3z8O19ROeU+crGcjN9YQW4tf6E+kf2OYTzP0XONKJpjj8t/mVLRVYzFUcVjB0F4QCbWjRfLUwVqME8a2QmooWj6Vka1OlbCHF0U3eWP4H4TxPqipWYtupH+MyfF9svv9VoKvBRA/NNpPqHnBetfZCF3AK8VQn22pi+7kjRbJ+39K3a5KDtW0wI/3Dgd4pE1+3prSBJoPvs7sXVEwVRoi17TbHvrpbNfm7DOLvfqApo9tTxYyvK9SFxwbgakJKB8Lfbyx8bfODYmpL9kB5iuoLgrQ5NFePb7my8ZmtzagYl5/Pz/s4ArxP6qoEty4cjGl1/17ypgtR/xIy2L1JJ0HYV3abTE00eVhSC1GklKOPhtvouJ7ofAee43kuad+Y6dA5crekbUBreH3yMcp3DOvcqFiJ++1KXYr9NnpJWAld49hfNYX6Nt8pgNhiAJG9BMHQUHj8HIB1aS9DNjThl3Rj8RCePXpSL1WY8Nok1/IP1SmNg55VElmTQNP+VBq0kDk/LLgg3WrEoGXNxq2JOaW5ILVMB8u3CPota/wufRsUfuZdXAAUIqYB7SP/Kn25v3pj0V6XacGLoQgWhu6cn+VSXbyAZw6+k7qpLnwvtxsRu+rVaoB9zSUzZKXbPsQjR0v7QxgW/yRKMZi5ZOP9rZsHua3w+KWtgsfBIl5RBy2u6ZBw6adgM9/QsG1M3G5W9TrCyTD1rlNXK1Enr9UpnXAsX7VtORgZJY= x-ms-office365-filtering-correlation-id: 75670da1-6b32-4c54-140c-08d4cd3e79b4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-exchange-antispam-report-test: UriScan:(236129657087228); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1764; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39410400002)(39400400002)(39450400003)(39840400002)(53936002)(189998001)(6246003)(6916009)(6486002)(110136004)(8936002)(38730400002)(77096006)(25786009)(2950100002)(81166006)(6512007)(229853002)(82746002)(36756003)(8676002)(7736002)(99286003)(478600001)(6506006)(83716003)(54906002)(50226002)(305945005)(86362001)(102836003)(2900100001)(6116002)(39060400002)(33656002)(14454004)(6436002)(93886004)(558084003)(2906002)(76176999)(4326008)(5660300001)(50986999)(99936001)(3660700001)(57306001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_0A8DB5A3-873A-4C2C-9E08-E3D2E95C2210"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 18:05:57.8843 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [Tsv-art] TSV Dinner at IETF 99 in Prague X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 18:11:16 -0000 --Apple-Mail=_0A8DB5A3-873A-4C2C-9E08-E3D2E95C2210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In case anyone is still at the hotel, I will leave by car to dinner = soon. Unicast email if you want to join. Lars --Apple-Mail=_0A8DB5A3-873A-4C2C-9E08-E3D2E95C2210 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlls/IQACgkQVLXDCb9w wVcgvw//cpF6EbVx5QpBdExdB5sJvAFtr6zO6Z4s8YWOhK6TYlG7vzjfH18i0E85 jzoU7YWBoaxWHzjq+6hyZp23A9D2zn/LKdDdSd6bjBZlbtTs1ftNLQAbZ8HPGpF+ xUEwUc4uLYe2TjzuG5ZQuaP0josRsT9p+phMDt2NsZTEp16IhPKvBrpuuN+tR8NL MHfdy0v8eSA5WyG2rP03YvIH5L0aBXpZ1gBek2BMwcgWMskIoyhG70eywI2LCTdN 6s6nNQahO+2/miJiUugu108JbFxWbKcVlR0fj/1cHJJehrN12eFmkwKnkDLAU7Az K7+mSwab/Ke7pSLBqThnGwW5kmLEp6/DF58e8DZ+m4QswdQqDgSmi9g7LhXdTNGb BrNBhAlIL/fQzNwE97IJ6qt5YF56emk6WrIujpG4S0WKwx5xuXxcaC1wkslAW3QA vFPGXqAMyqYKxAd2Vi1clrsDUFBiASYiWf44RZVRtTmYgbIwuL8YxsUgHW0CMD32 wLjOVGNO4tde8Y1ePY4lHAyYUaZ5xDQt63NSGwj848btr7mW06PaDWgkTnpEIKT+ cHb5hAMjfA9G5EQQTCFor4tjEpVlXju1rkjn3hniXw8nO4qDDYg6ih2EGTehbpZZ 9/jD4I9Eatm2+x+dptTD3arbgEYHqt0Hz4SQE6BOx/i6iIbaiiA= =+4cm -----END PGP SIGNATURE----- --Apple-Mail=_0A8DB5A3-873A-4C2C-9E08-E3D2E95C2210-- From nobody Wed Jul 19 11:17:21 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D18C131B22 for ; Wed, 19 Jul 2017 11:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 nbqD4n6Rs2LI for ; Wed, 19 Jul 2017 11:17:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 8F33C131B0A for ; Wed, 19 Jul 2017 11:17:18 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JIGt62015263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 11:16:56 -0700 (PDT) To: "tsv-art@ietf.org" From: Joe Touch Message-ID: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> Date: Wed, 19 Jul 2017 11:16:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [Tsv-art] do we need a checklist or guidelines? X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:17:20 -0000 Hi, all, I'm seeing increasingly bizzare attempts to modify TCP. We currently have two requirements for TCP mods, AFAICT: a) passes TSV-chair, TSV-ART, and possibly TCPM, TSVWG, etc. review b) includes "TCP-friendliness" (mostly for congestion control) I propose it's time for some new criteria, as follows. Can others let me know if this would be useful to document somehow, whether formally as an ID or at least as a TSV-ART checklist? c) compliant with existing TCP requirements, notably: 1) compatible with already-defined TCP options 2) fail-safe fallback to legacy endpoints (notably not requiring a new connection attempt with different parameters) Criteria "c)" is currently under "attack" (imo) by some in the LWIP and MPTCP groups, the former which hasn't addressed this issue at all and the latter appears to be actively rejecting it. Thoughts? I'd be glad to write this up further, with justification. Joe From nobody Wed Jul 19 11:34:27 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E2512EAB0 for ; Wed, 19 Jul 2017 11:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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=nokia.onmicrosoft.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 hPY2I0vB9P2V for ; Wed, 19 Jul 2017 11:34:24 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0118.outbound.protection.outlook.com [104.47.1.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4193712711E for ; Wed, 19 Jul 2017 11:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1FaG88g5Lt0PoY3InyjIRjds7tp6adzPj/jsRLkeBHw=; b=llsLN1+NloANRMzD3HfG6xwCzhLFoHf6Kmh0W8GGkmopn0owNdxSi1HvKg1e7q4VfHsQ4PSoXXeKfASwfCM7xsipPgR4k7O1BKoVJVlnf10Qhz7M/U478psPQvahhJx1h7Z1Pc8/dH1QYnX+9phWubBQNfDmsxz9DosZXFSZbEI= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB1732.eurprd07.prod.outlook.com (10.167.215.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Wed, 19 Jul 2017 18:34:21 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736%17]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 18:34:21 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch , "tsv-art@ietf.org" Thread-Topic: [Tsv-art] do we need a checklist or guidelines? Thread-Index: AQHTALtFBAZ49Bcp60qQWG3Q9X9CmqJbdiGQ Date: Wed, 19 Jul 2017 18:34:21 +0000 Message-ID: References: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> In-Reply-To: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isi.edu; dkim=none (message not signed) header.d=none;isi.edu; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1732; 7:Uuu5WHo8fpWfbPr19fLGjPihGo+6Wbjzu2IJYLZMI2N7SD3DpVSbqqQ96i7p5Q9FbV+o3p2CeZkLPege9vHUaPLiyOebcel9fmQWMvK0OevKgiYgpXv78wmLTwkQqytDNcY+1AtlskbdgFbeYJj/QwAhmaPIRz1YJuuW+rZmSZIM2iGnx2Vbflgvd7rMY8yj5egXLV4NBE5EqcjJVBXaSnby3stHgF+8C+Qka2USFOKJIx3nJ7YkFONPQLFDCGGI0qt7/9LW8fQKNuT/EUNvY7l97HEygRwYpBAJ3NJk9LJQJZG/V6BfoyrPtm+FOGCzOQ28ipCOF5RIV/7XiI+Hzn3FfU7lwaV4+7iIMTegefEfTDyZRyQ1cT64i+whlRqHAUxhKM8znaHFsfd594MN6U2JBDb7ocYZ71Fnp/+XrChq+GVXkFcd0ca6BxX6GY7Pv2MpdEn7FkpLoO3P0CU5ZO8XN3CzSQov7sp/lgaSmIC0/LM1DDDBDAY7mWb0iC6pxGtVdMHeU0WbCN0oDv/111+Z82znuaTNfCTlVQW3VxFKFGptcWkAiSCkmfUsljOjMF/Eb8ZMJ/9LQ4bCvlO44eZgMd9YXBCz70Vfrc10Vn4oPD+04prbSwo++5E8ZxXpjJOCDNOOOC+ZnQwJfA+AdAaHoEQbv9lVU9JKRr8VwMgvhL7ODsK6x6vv1t6VWzjP1lPhcr84UnS1WikDPZXKT/0i01WbGbxHmYIGst/XtdSYFr+WvnnvqLk4826FJNT+Ps8R5TGzZWjyWKQvHFxCfLYNt9Qjdx/kWmOJc+wBwuY= x-ms-office365-filtering-correlation-id: cca5dbb3-6d8f-4384-d155-08d4ced4c5ca x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB1732; x-ms-traffictypediagnostic: AM5PR0701MB1732: x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(148574349560750); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB1732; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB1732; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(39400400002)(13464003)(377454003)(57704003)(38730400002)(8676002)(3280700002)(33656002)(3660700001)(5250100002)(8936002)(2906002)(2501003)(81166006)(50986999)(9686003)(305945005)(7736002)(76176999)(6306002)(5660300001)(74316002)(53936002)(54356999)(6436002)(6246003)(6506006)(2171002)(55016002)(86362001)(99286003)(7696004)(66066001)(478600001)(25786009)(14454004)(2900100001)(229853002)(53546010)(189998001)(2950100002)(3846002)(6116002)(102836003)(966005)(23603002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1732; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 18:34:21.1468 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1732 Archived-At: Subject: Re: [Tsv-art] do we need a checklist or guidelines? X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:34:26 -0000 l deal with the LWIG document (to ensure TCPM review) and as of now I don't= think I need any formal checklist for that specific document.=20 Also, we decided to publish documents such as DCTCP for somewhat controlled= environments. I am not sure if DCTCP would really meet requirement b). So = this sort of list may be non-trivial. Michael > -----Original Message----- > From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Wednesday, July 19, 2017 8:17 PM > To: tsv-art@ietf.org > Subject: [Tsv-art] do we need a checklist or guidelines? >=20 > Hi, all, >=20 > I'm seeing increasingly bizzare attempts to modify TCP. >=20 > We currently have two requirements for TCP mods, AFAICT: >=20 > a) passes TSV-chair, TSV-ART, and possibly TCPM, TSVWG, etc. review >=20 > b) includes "TCP-friendliness" (mostly for congestion control) >=20 > I propose it's time for some new criteria, as follows. Can others let me = know > if this would be useful to document somehow, whether formally as an ID or > at least as a TSV-ART checklist? >=20 > c) compliant with existing TCP requirements, notably: >=20 > 1) compatible with already-defined TCP options >=20 > 2) fail-safe fallback to legacy endpoints (notably not requiring = a new > connection attempt with different parameters) >=20 > Criteria "c)" is currently under "attack" (imo) by some in the LWIP and M= PTCP > groups, the former which hasn't addressed this issue at all and the latte= r > appears to be actively rejecting it. >=20 > Thoughts? >=20 > I'd be glad to write this up further, with justification. >=20 > Joe >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Wed Jul 19 12:53:16 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418CF126C83 for ; Wed, 19 Jul 2017 12:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 pisz-LTDHbip for ; Wed, 19 Jul 2017 12:53:14 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 46BD2126B7F for ; Wed, 19 Jul 2017 12:53:14 -0700 (PDT) Received: from [128.9.184.233] ([128.9.184.233]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6JJodhm010820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Jul 2017 12:50:40 -0700 (PDT) To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "tsv-art@ietf.org" References: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> From: Joe Touch Message-ID: Date: Wed, 19 Jul 2017 12:50:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] do we need a checklist or guidelines? X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 19:53:15 -0000 On 7/19/2017 11:34 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > l deal with the LWIG document (to ensure TCPM review) and as of now I don't think I need any formal checklist for that specific document. I just posted a related request for clarification to LWIG. Can you contact me directly with your thoughts on that? > Also, we decided to publish documents such as DCTCP for somewhat controlled environments. Sure - OK, so the list below needs some tweaking, of course. It needs to be "relatively friendly to TCPs in the same environment", at least. Joe From nobody Thu Jul 20 01:25:26 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3F912EC48 for ; Thu, 20 Jul 2017 01:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 Wn30P50aJX5Z for ; Thu, 20 Jul 2017 01:25:14 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0120.outbound.protection.outlook.com [104.47.1.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6A61318A0 for ; Thu, 20 Jul 2017 01:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FBgmTZ0o8Xcx6OvaOFh8q6iTMf7mEgLpF5QYXG7gIiY=; b=HNrtsyQ7vHfuVZDpIGxMsrLpBap8+RZV3maqElT6vjbumN3IrT9Md4tLeB2EWvln3J2VCw63C0s6+HxeY6vdcYRhl8XBmd50DWGahDi4zRbZTKo4I4da+Pj7ZQUDsU7UKHclPzs8UtgLlGq6Izvumu0kQ/8AlUQ779++XK09oaQ= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2641.eurprd07.prod.outlook.com (10.173.92.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 08:25:11 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::b4f5:bfaf:bef6:e736%17]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 08:25:11 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch , "tsv-art@ietf.org" Thread-Topic: [Tsv-art] do we need a checklist or guidelines? Thread-Index: AQHTALtFBAZ49Bcp60qQWG3Q9X9CmqJbdiGQgAAY/YCAANHjkA== Date: Thu, 20 Jul 2017 08:25:11 +0000 Message-ID: References: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isi.edu; dkim=none (message not signed) header.d=none;isi.edu; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2641; 7:JkaOPYpADDue6vDi9NfEyuj8q33nv77BPTkYL2xsB2NdDkzY2ngFodjsn4qNPYoQxS3J+VsaFj1KcpBU/jT0aNHByHXWMrKEzhvfSaX0FuVSXrZwgPfbCRJXFKh3+OT0DoNCpRigwiq2dbjlqpW5hAlp2VIgyj4oXzA7DCKHDIVTi2mHdIdwhLSOOwW3N2gLrj4Y8QpR4xhPrAz6HoGHj5cUnOC5OVwskvuysvGuEQ0ds4yOQ36pNIr1lGNicmKYeAeisZFxGAE5UIbJnfkzrgg+mU4sWQCRLL3O4Fh0w3lJ5gC0WNMO6Ia3fSuo5xYDkvuWegdDngOjx6Tf58V8lAwgXZnN4UIX2IcbxEII9yVhuiD8mT7DJ2dlAn7o+llwUqfjxHXveCaepowe7eZ3VwP/nRadAyKjeFBPgY7Lt29ucIXEQZJFc3v2Y51ipRuxjneQMcklVhOtFeBPL08cxvLDPwzDLIOjMgKBKsbJBaMb2hBi5W1rvwC91B7YKFRqQP4oDrs+PwmNlYOHfoC5PmD57tC2FEos+rCBV2Q8OAQXq+ONwVvrBdRW56bSsVb9lvtMfsn9vIdxwdJ9fHB6nMWkBrH1LUnXiVhMK7EaNnqA+iZfpw5tKMLki8wE641uDgGjoZiicB0Ofcq1Ip3VKtzs/L0aYSJ+RcczKW+Cdw1g31KcsMSVekVt2uxZTtllwAHZd3zCC1lilgZRi2oxWfQoLBns5tk5xis26yJYbkkhGHmxIxGl9zzCy3TWDkGC0zYZtFGgbr6CSVtt9lOpG+nOT3UATtjg0sBcgCELaVs= x-ms-office365-filtering-correlation-id: 7df5244b-cf27-436d-c1e3-08d4cf48d6c8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2641; x-ms-traffictypediagnostic: AM5PR0701MB2641: x-exchange-antispam-report-test: UriScan:(278178393323532)(236129657087228)(82608151540597)(48057245064654); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(2017060910075)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2641; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2641; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39410400002)(39840400002)(39850400002)(39400400002)(13464003)(57704003)(24454002)(377454003)(66066001)(305945005)(7736002)(6506006)(478600001)(6436002)(2906002)(86362001)(8936002)(25786009)(2950100002)(3280700002)(229853002)(74316002)(53546010)(9686003)(8676002)(81166006)(3846002)(50986999)(76176999)(6116002)(54356999)(102836003)(99286003)(14454004)(38730400002)(2501003)(7696004)(5660300001)(6246003)(5250100002)(2900100001)(3660700001)(2171002)(189998001)(33656002)(53936002)(55016002)(23603002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2641; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 08:25:11.2908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2641 Archived-At: Subject: Re: [Tsv-art] do we need a checklist or guidelines? X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:25:16 -0000 VGhlIG1haW4gYXV0aG9yIGhhcyBhbHJlYWR5IHJlcGxpZWQgdG8geW91ciByZXZpZXc7IEkgc3Vn Z2VzdCB0byBkaXNjdXNzIG9uIHRoZSBMV0lHIGxpc3QuDQoNClRoZSBkb2N1bWVudCB3aWxsIGhh dmUgdG8gZXZvbHZlIGFuZCBpbXByb3ZlLCBidXQgSSB0aGluayB3ZSBoYXZlIGVub3VnaCBtZWFu cyB0byBlbnN1cmUgVENQTSByZXZpZXcuDQoNCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+ IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxOSwgMjAxNyA5OjUxIFBNDQo+IFRvOiBTY2hhcmYsIE1p Y2hhZWwgKE5va2lhIC0gREUvU3R1dHRnYXJ0KSA8bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPjsg dHN2LQ0KPiBhcnRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtUc3YtYXJ0XSBkbyB3ZSBuZWVk IGEgY2hlY2tsaXN0IG9yIGd1aWRlbGluZXM/DQo+IA0KPiANCj4gDQo+IE9uIDcvMTkvMjAxNyAx MTozNCBBTSwgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFL1N0dXR0Z2FydCkgd3JvdGU6DQo+ ID4gbCBkZWFsIHdpdGggdGhlIExXSUcgZG9jdW1lbnQgKHRvIGVuc3VyZSBUQ1BNIHJldmlldykg YW5kIGFzIG9mIG5vdyBJDQo+IGRvbid0IHRoaW5rIEkgbmVlZCBhbnkgZm9ybWFsIGNoZWNrbGlz dCBmb3IgdGhhdCBzcGVjaWZpYyBkb2N1bWVudC4NCj4gSSBqdXN0IHBvc3RlZCBhIHJlbGF0ZWQg cmVxdWVzdCBmb3IgY2xhcmlmaWNhdGlvbiB0byBMV0lHLiBDYW4geW91IGNvbnRhY3QgbWUNCj4g ZGlyZWN0bHkgd2l0aCB5b3VyIHRob3VnaHRzIG9uIHRoYXQ/DQo+IA0KPiA+IEFsc28sIHdlIGRl Y2lkZWQgdG8gcHVibGlzaCBkb2N1bWVudHMgc3VjaCBhcyBEQ1RDUCBmb3Igc29tZXdoYXQNCj4g Y29udHJvbGxlZCBlbnZpcm9ubWVudHMuDQo+IFN1cmUgLSBPSywgc28gdGhlIGxpc3QgYmVsb3cg bmVlZHMgc29tZSB0d2Vha2luZywgb2YgY291cnNlLiBJdCBuZWVkcyB0byBiZQ0KPiAicmVsYXRp dmVseSBmcmllbmRseSB0byBUQ1BzIGluIHRoZSBzYW1lIGVudmlyb25tZW50IiwgYXQgbGVhc3Qu DQo+IA0KPiBKb2UNCg== From nobody Thu Jul 20 05:22:25 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10807131C2A for ; Thu, 20 Jul 2017 05:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 QUTS1sewqU-2 for ; Thu, 20 Jul 2017 05:22:21 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A44131C28 for ; Thu, 20 Jul 2017 05:22:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=XLDvHrrvCDEpGOdC9rkIrkdd4jDbt1XW6xMyAF/ihVLatubi6aN6NdO+r3dd8nnRIil1iZtp+Lgyr1U1+56n4Vu651wUdbeBlwOrpsRTIaSKP4cVUvjlnkVn2zPm4f3bPpVTlRpDxu8vIXMym/fUUiENh3dkDijpVO4WYiop2cM=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 13543 invoked from network); 20 Jul 2017 14:22:17 +0200 Received: from dhcp-80db.meeting.ietf.org (31.133.128.219) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Jul 2017 14:22:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> Date: Thu, 20 Jul 2017 14:22:16 +0200 Cc: "tsv-art@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170720122217.13538.78087@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Tsv-art] do we need a checklist or guidelines? X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:22:23 -0000 Hi Joe, I would say that the points under c) are usually already discussed and = considered in the IETF (in tcpm where we sooner or later have all these = proposals presented at least once). However, I don=E2=80=99t see a need = to further formalize anything here because I don=E2=80=99t see how this = could help. I also think that =E2=80=9Eattack=E2=80=9C is really not the right word = here. People are free and should be encouraged to bring their idea to = the IETF/tcpm and then have a discussion with the experts there figuring = out if their proposed solution is the right approach or if there are = other better alternatives. Just trying to send these people away = doesn=E2=80=99t help. Mirja > Am 19.07.2017 um 20:16 schrieb Joe Touch : >=20 > Hi, all, >=20 > I'm seeing increasingly bizzare attempts to modify TCP. >=20 > We currently have two requirements for TCP mods, AFAICT: >=20 > a) passes TSV-chair, TSV-ART, and possibly TCPM, TSVWG, etc. review >=20 > b) includes "TCP-friendliness" (mostly for congestion control) >=20 > I propose it's time for some new criteria, as follows. Can others let = me > know if this would be useful to document somehow, whether formally as = an > ID or at least as a TSV-ART checklist? >=20 > c) compliant with existing TCP requirements, notably: >=20 > 1) compatible with already-defined TCP options >=20 > 2) fail-safe fallback to legacy endpoints (notably not = requiring > a new connection attempt with different parameters) >=20 > Criteria "c)" is currently under "attack" (imo) by some in the LWIP = and > MPTCP groups, the former which hasn't addressed this issue at all and > the latter appears to be actively rejecting it. >=20 > Thoughts? >=20 > I'd be glad to write this up further, with justification. >=20 > Joe >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Thu Jul 20 07:28:46 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA3A13146C for ; Thu, 20 Jul 2017 07:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 dFIzfVPsQsEA for ; Thu, 20 Jul 2017 07:28:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 23CBD13188F for ; Thu, 20 Jul 2017 07:28:35 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6KERXHW005113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jul 2017 07:27:43 -0700 (PDT) To: "Mirja Kuehlewind (IETF)" Cc: "tsv-art@ietf.org" References: <44b6345c-359b-65b3-d71e-3210f676fbbc@isi.edu> From: Joe Touch Message-ID: <33fa433f-52bf-172a-9151-c7dd8153407a@isi.edu> Date: Thu, 20 Jul 2017 07:27:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] do we need a checklist or guidelines? X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:28:45 -0000 On 7/20/2017 5:22 AM, Mirja Kuehlewind (IETF) wrote: > Hi Joe, > > I would say that the points under c) are usually already discussed and considered in the IETF (in tcpm where we sooner or later have all these proposals presented at least once). However, I don’t see a need to further formalize anything here because I don’t see how this could help. > > I also think that „attack“ is really not the right word here. People are free and should be encouraged to bring their idea to the IETF/tcpm and then have a discussion with the experts there figuring out if their proposed solution is the right approach or if there are other better alternatives. Just trying to send these people away doesn’t help. The issue is similar to security considerations, congestion issues with UDP, etc - the community *is* extending and adapting TCP and certainly we're providing feedback, but that feedback would be a lot more efficient if the community knew what our expectations were, IMO. Especially when some of these requests for transport analysis happen in days/hours before IESG review, as is too often the case. Joe