From nobody Thu Jun 1 02:17:43 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E11D12EB4F for ; Thu, 1 Jun 2017 02:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 t4Kl1fSxMHnk for ; Thu, 1 Jun 2017 02:17:40 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CFA12127977 for ; Thu, 1 Jun 2017 02:17:39 -0700 (PDT) X-scanvirus: By SEG_CYREN AntiVirus Engine X-scanresult: CLEAN X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20170601170541 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 1 Jun 2017 09:05:41 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id v519AIPE004095; Thu, 1 Jun 2017 17:10:18 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) To: , "Susan Hares" Cc: trill-chairs@ietf.org, draft-ietf-trill-smart-endnodes@ietf.org MIME-Version: 1.0 X-KeepSent: FF3D2BC2:109092E1-48258132:0030113D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: hu.fangwei@zte.com.cn Date: Thu, 1 Jun 2017 17:10:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2017-06-01 17:10:06, Serialize complete at 2017-06-01 17:10:06 Content-Type: multipart/alternative; boundary="=_alternative 0032623448258132_=" X-MAIL: mse01.zte.com.cn v519AIPE004095 X-HQIP: 127.0.0.1 Archived-At: Subject: Re: [trill] WG LC for draft-ietf-trill-smart-endnodes (5/31 to 6/13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 09:17:41 -0000 This is a multipart message in MIME format. --=_alternative 0032623448258132_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksQUxMDQoNClNlZSBiZWxvdy4gUmUtcG9zdGluZyBmb3IgdGhlIHJlY29yZC4NCg0KUmVnYXJk cw0KRmFuZ3dlaQ0KDQotLS0tLSDXqreiyMsguvq3vc6wMTc1NzcyL3VzZXIvenRlX2x0ZCDKsbzk IDIwMTcvMDYvMDEgMTY6NDUgLS0tLS0NCg0Kuvq3vc6wMTc1NzcyL3VzZXIvenRlX2x0ZA0KMjAx Ni8wOC8yOSAwODo0Mw0KDQrK1bz+yMsNCiJTdXNhbiBIYXJlcyIgPHNoYXJlc0BuZHpoLmNvbT4s IA0Ks63LzQ0KdHJpbGxAaWV0Zi5vcmcsICJ0cmlsbCIgPHRyaWxsLWJvdW5jZXNAaWV0Zi5vcmc+ LCB0cmlsbC1jaGFpcnNAaWV0Zi5vcmcNCtb3zOINClJlOiBbdHJpbGxdIFdHIExDIGZvciBkcmFm dC1pZXRmLXRyaWxsLXNtYXJ0LWVuZC1ub2RlcyAoOC8yNiB0byA5LzkpDQoNCg0KDQoNCg0KSGks IEFsbA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSLg0KDQpSZWdhcmRzLg0KRmFuZ3dlaS4N Cg0KDQoNCg0KDQoiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmR6aC5jb20+IA0Kt6K8/sjLOiAgInRy aWxsIiA8dHJpbGwtYm91bmNlc0BpZXRmLm9yZz4NCjIwMTYtMDgtMjYgMTc6NDANCg0KytW8/sjL DQo8dHJpbGxAaWV0Zi5vcmc+DQqzrcvNDQp0cmlsbC1jaGFpcnNAaWV0Zi5vcmcNCtb3zOINClt0 cmlsbF0gV0cgTEMgZm9yIGRyYWZ0LWlldGYtdHJpbGwtc21hcnQtZW5kLW5vZGVzICg4LzI2IHRv IDkvOSkNCg0KDQoNCg0KDQoNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExDIGZvciBkcmFmdC1p ZXRmLXRyaWxsLXNtYXJ0LWVuZC1ub2RlcyAoOC8yNi8yMDE2IA0KdG8gOS85LzIwMTYpLiBUaGUg YXV0aG9ycyBhcmUgYXNrZWQgdG8gaW5kaWNhdGUgd2hldGhlciB0aGV5IGtub3cgb2YgdGhlIA0K SVBSIHJlbGF0aW5nIHRvIHRoaXMgZHJhZnQuIA0KIA0KV0cgcGFydGljaXBhbnRzIGFyZSBhc2tl ZCB0byBjb25zaWRlcjogDQogDQoxKSAgICAgIERvZXMgdGhpcyBkcmFmdCByZWFkeSBmb3IgcHVi bGljYXRpb24/IA0KMikgICAgICBEb2VzIHRoZSBleHRlbnNpb24gb2YgdGhlIFJicmlkZ2UgdG8g c21hcnQtZW5kIG5vZGVzIHNvbHZlIHRoZSANCnByb2JsZW0gb2YgbGVhcm5pbmcgZnJlc2huZXNz IGFuZCBwcm92aWRlIG9mZmxvYWQgZm9yIHRoZSANCmVuY2Fwc3VsYXRpb24vZGVjYXBzdWxhdGlv biBwcm9ibGVtPyANCjMpICAgICAgRG8geW91IGtub3cgb2YgYW55IHBsYW5uZWQgaW1wbGVtZW50 YXRpb25zIG9yIGRlcGxveW1lbnRzPyANCiANClN1ZSBIYXJlcyBhbmQgSm9uIEh1ZHNvbiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJpbGwgbWFpbGlu ZyBsaXN0DQp0cmlsbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmlsbA0KDQoNCg== --=_alternative 0032623448258132_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zPkhpLEFMTDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+U2VlIGJl bG93LiBSZS1wb3N0aW5nIGZvciB0aGUgcmVjb3JkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+RmFuZ3dlaTxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg Y29sb3I9IzgwMDA4MCBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsguvq3vc6wMTc1Nzcy L3VzZXIvenRlX2x0ZA0KyrG85CAyMDE3LzA2LzAxIDE2OjQ1IC0tLS0tPC9mb250Pg0KPGJyPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPrr6t73OsDE3NTc3Mi91c2VyL3p0ZV9sdGQ8L2I+ PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYvMDgvMjkgMDg6 NDM8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7U3VzYW4gSGFyZXMmcXVvdDsgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDssDQo8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPnRyaWxsQGlldGYub3JnLCAmcXVvdDt0cmlsbCZxdW90OyAmbHQ7dHJp bGwtYm91bmNlc0BpZXRmLm9yZyZndDssDQp0cmlsbC1jaGFpcnNAaWV0Zi5vcmc8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbdHJpbGxdIFdHIExDIGZvciBkcmFmdC1pZXRmLXRyaWxsLXNtYXJ0LWVu ZC1ub2Rlcw0KKDgvMjYgdG8gOS85KTwvZm9udD48YSBocmVmPU5vdGVzOi8vSEtNQUlMMDIvNDgy NTc4RjYwMDJCODhEMy9DRDJGMzI1RDg2MEM3NEQxNDgyNTZDNTIwMDQ0NzVGNy82MTYwMDI0QkU2 RjhFMDc2NDgyNTgwMUIwMDM1NDRGMz7BtL3TPC9hPjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBBbGw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJ UFIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdh cmRzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmFuZ3dlaS48 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+JnF1b3Q7U3VzYW4gSGFyZXMmcXVvdDsNCiZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7 PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7Iyzog Jm5ic3A7JnF1b3Q7dHJpbGwmcXVvdDsgJmx0O3RyaWxsLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYtMDgtMjYgMTc6NDA8 L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ Jmx0O3RyaWxsQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+dHJpbGwtY2hhaXJzQGll dGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bdHJpbGxdIFdHIExDIGZvciBkcmFmdC1pZXRmLXRy aWxsLXNtYXJ0LWVuZC1ub2Rlcw0KKDgvMjYgdG8gOS85KTwvZm9udD48L3RhYmxlPg0KPGJyPg0K PHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxl Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGlzIGJlZ2lu cyBhIDIgd2VlayBXRyBMQyBmb3IgZHJhZnQtaWV0Zi10cmlsbC1zbWFydC1lbmQtbm9kZXMNCig4 LzI2LzIwMTYgdG8gOS85LzIwMTYpLiBUaGUgYXV0aG9ycyBhcmUgYXNrZWQgdG8gaW5kaWNhdGUg d2hldGhlciB0aGV5DQprbm93IG9mIHRoZSBJUFIgcmVsYXRpbmcgdG8gdGhpcyBkcmFmdC4gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPldHIHBhcnRpY2lwYW50cyBhcmUgYXNrZWQgdG8g Y29uc2lkZXI6DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+MSkgJm5ic3A7ICZuYnNw OyAmbmJzcDtEb2VzIHRoaXMgZHJhZnQNCnJlYWR5IGZvciBwdWJsaWNhdGlvbj8gPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4yKSAmbmJzcDsgJm5ic3A7ICZuYnNwO0Rv ZXMgdGhlIGV4dGVuc2lvbg0Kb2YgdGhlIFJicmlkZ2UgdG8gc21hcnQtZW5kIG5vZGVzIHNvbHZl IHRoZSBwcm9ibGVtIG9mIGxlYXJuaW5nIGZyZXNobmVzcw0KYW5kIHByb3ZpZGUgb2ZmbG9hZCBm b3IgdGhlIGVuY2Fwc3VsYXRpb24vZGVjYXBzdWxhdGlvbiBwcm9ibGVtPyA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjMpICZuYnNwOyAmbmJzcDsgJm5ic3A7RG8geW91 IGtub3cgb2YgYW55DQpwbGFubmVkIGltcGxlbWVudGF0aW9ucyBvciBkZXBsb3ltZW50cz8gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlN1ZSBIYXJlcyBhbmQgSm9uIEh1ZHNvbiA8L2Zv bnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnRyaWxsIG1haWxpbmcgbGlzdDxicj4NCnRyaWxsQGlldGYub3JnPGJy Pg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyaWxsPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmlsbDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9u dD48L3R0Pg0KPGJyPg0K --=_alternative 0032623448258132_=-- From nobody Thu Jun 1 06:50:25 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C476012EC94; Thu, 1 Jun 2017 06:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.647 X-Spam-Level: *** X-Spam-Status: No, score=3.647 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbik3ALUNXei; Thu, 1 Jun 2017 06:50:22 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE3E129411; Thu, 1 Jun 2017 06:50:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=71.83.15.201; From: "Susan Hares" To: Cc: , "'Alia Atlas'" , Date: Thu, 1 Jun 2017 09:44:44 -0400 Message-ID: <004901d2dadd$3abce050$b036a0f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01D2DABB.B3AB6760" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdLa27YS9/A9LJSbQjmYXxY6FiNvDw== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [trill] 2 week WG LC for draft-ietf-trill-directory-assisted-encap (6/1 to 6/14) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 13:50:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004A_01D2DABB.B3AB6760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC for the draft draft-ietf-trill-directory-assisted-encap which you can find at: https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/ The authors should send in a IPR statement regarding this draft. Even if you have sent in a previous IPR statement, we still need you to submit a IPR statement regarding this version. If all authors do not send in their IPR statement by 6/8, we will pause the WG LC until we receive the IPR statements. However, with the quality of authors on this draft I'm sure we'll get the IPR statements quickly. During this WG last call please consider these questions in your response: 1) Does it help TRILL deployments (data-center, campus, enterprise, etc) to have non-RBridge nodes performing TRILL encapsulation with assistance from a directory service? Do you know of such an deployment? 2) Do you know of any implementations of this draft? 3) Do feel this technology is ready for deployment? 4) Do you feel that this draft is ready of publication? Thank you are working with or all your support on reviewing these TRILL drafts. As a WG we are working to complete IESG publications of all TRILL drafts within 1 year prior the TRILL WG completing its charter. Sue Hares ------=_NextPart_000_004A_01D2DABB.B3AB6760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC for the draft = draft-ietf-trill-directory-assisted-encap which you can find at: =

https://datatracker.ietf.org/doc/draft-ietf-trill-directory-a= ssisted-encap/

 

The authors = should send in a IPR statement regarding this draft.  Even if you = have sent in a previous IPR statement, we still need you to submit a IPR = statement regarding this version.    If all authors do = not send in their IPR statement by  6/8, we will pause the WG LC = until we receive the IPR statements.   However, with the = quality of authors on this draft I’m sure we’ll get the IPR = statements quickly.

 

During this = WG last call please consider these questions in your response: =

 

1)      = Does it help TRILL deployments (data-center, = campus, enterprise, etc) to have non-RBridge nodes performing TRILL = encapsulation with assistance from a directory service? Do you know of = such an deployment?

2)      = Do you know of any implementations of this = draft?

3)      = Do feel this technology is ready for deployment? =

4)      = Do you feel that this draft is ready of = publication?

 

Thank you are working with or all your support on = reviewing these TRILL drafts.  As a WG we are working to complete = IESG publications of all TRILL drafts within 1 year prior the TRILL WG = completing its charter. 

 

Sue Hares =

------=_NextPart_000_004A_01D2DABB.B3AB6760-- From nobody Thu Jun 1 11:49:27 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6626126CD6; Thu, 1 Jun 2017 11:49:25 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 b4cqgKo0gWAd; Thu, 1 Jun 2017 11:49:24 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 1C268124BE8; Thu, 1 Jun 2017 11:49:24 -0700 (PDT) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v51Iedwq023112; Thu, 1 Jun 2017 11:49:21 -0700 Received: from hq1wp-exmb11.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 2aq8r2ha3e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 01 Jun 2017 11:49:20 -0700 Received: from HQ1WP-EXMB13.corp.brocade.com (10.70.20.187) by Hq1wp-exmb11.corp.brocade.com (10.70.20.185) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Jun 2017 11:49:18 -0700 Received: from HQ1WP-EXMB12.corp.brocade.com (10.70.20.186) by HQ1WP-EXMB13.corp.brocade.com (10.70.20.187) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Jun 2017 11:49:18 -0700 Received: from HQ1WP-EXMB12.corp.brocade.com ([fe80::b5c6:be43:7d72:632d]) by HQ1WP-EXMB12.corp.brocade.com ([fe80::b5c6:be43:7d72:632d%20]) with mapi id 15.00.1210.000; Thu, 1 Jun 2017 11:49:18 -0700 From: "R. Parameswaran" To: Susan Hares , "trill@ietf.org" CC: "trill-chairs@ietf.org" , "'Alia Atlas'" Thread-Topic: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) Thread-Index: AdLaVHL3h5KSSYtoRp+Xo96OBSdfkQAsv4rb Date: Thu, 1 Jun 2017 18:49:18 +0000 Message-ID: References: <02b301d2da55$4d43a5c0$e7caf140$@ndzh.com> In-Reply-To: <02b301d2da55$4d43a5c0$e7caf140$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.181.50] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-01_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706010336 Archived-At: Subject: Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 18:49:26 -0000 Hi, Thanks for taking this up. Support as author, not aware of any IPR on this. regards,=20 Ramkumar ________________________________________ From: trill [trill-bounces@ietf.org] on behalf of Susan Hares [shares@ndzh.= com] Sent: Wednesday, May 31, 2017 2:31 PM To: trill@ietf.org Cc: trill-chairs@ietf.org; 'Alia Atlas' Subject: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (= 5/31 to 6/13) This begins a 2 week WG adoption call for draft-rp-trill-parent-selection f= rom 5/31/2017 to 6/13/2017. You can obtain the draft at: https://datatracker.ietf.org/doc/draft-rp-trill-parent-selection/. The authors should indicate if they know of IPR on this draft. This should= be sent to the WG list within 1 week or the WG adoption or we will =93stal= l=94 the WG adoption call waiting for it. (Normally TRILL authors are gre= at at responding =96 so we are running the IPR and WG Adoption call in para= llel). The TRILL WG group should consider on this information draft if: 1) Is the documentation the known problem in the TRILL tree constructi= on mechanism and offers an approach requiring no change to the TRILL protocol in order to solve the problem is a useful for TRILL deployments. 2) Does this draft document this problem? 3) Can we complete this work within 1 year? Sue Hares From nobody Thu Jun 1 21:01:08 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A449E127599; Thu, 1 Jun 2017 21:01:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149637606062.31866.16081237246192802565@ietfa.amsl.com> Date: Thu, 01 Jun 2017 21:01:00 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-resilient-trees-07.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 04:01:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL: Resilient Distribution Trees Authors : Mingui Zhang Tissa Senevirathne Janardhanan Pathangi Ayan Banerjee Anoop Ghanwani Filename : draft-ietf-trill-resilient-trees-07.txt Pages : 21 Date : 2017-06-01 Abstract: The TRILL (Transparent Interconnection of Lots of Links) protocol provides multicast data forwarding based on IS-IS link state routing. Distribution trees are computed based on the link state information through Shortest Path First calculation. When a link on the distribution tree fails, a campus-wide re-convergence of this distribution tree will take place, which can be time consuming and may cause considerable disruption to the ongoing multicast service. This document specifies how to build backup distribution trees to protect links on the primary distribution tree. Since the backup distribution tree is built up ahead of the link failure, when a link on the primary distribution tree fails, the pre-installed backup forwarding table will be utilized to deliver multicast packets without waiting for the campus-wide re-convergence. This minimizes the service disruption. This document updates RFC 6325. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-resilient-trees/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-resilient-trees-07 https://datatracker.ietf.org/doc/html/draft-ietf-trill-resilient-trees-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-resilient-trees-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 2 01:02:58 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72F61314AC for ; Fri, 2 Jun 2017 01:02:56 -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 fZPMeaIQpRW6 for ; Fri, 2 Jun 2017 01:02:55 -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 EB8B31314AB for ; Fri, 2 Jun 2017 01:02:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHT50872; Fri, 02 Jun 2017 08:02:52 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 2 Jun 2017 09:02:51 +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; Fri, 2 Jun 2017 16:02:45 +0800 From: "Zhangmingui (Martin)" To: "trill@ietf.org" Thread-Topic: I-D Action: draft-ietf-trill-resilient-trees-07.txt Thread-Index: AQHS21TrTHIwWlY+bECnlH6ZixFQFKIQ80LQ Date: Fri, 2 Jun 2017 08:02:45 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A64FCC1B@NKGEML515-MBX.china.huawei.com> References: <149637606062.31866.16081237246192802565@ietfa.amsl.com> In-Reply-To: <149637606062.31866.16081237246192802565@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59311BAD.0035, 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: 1c4f88a64c482ffd3fba817b9342887c Archived-At: Subject: Re: [trill] I-D Action: draft-ietf-trill-resilient-trees-07.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 08:02:57 -0000 Hi, This version addresses comments we received from the Routing Directorate QA= review and the Shepherd review. Thanks, Mingui > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, June 02, 2017 12:01 PM > To: i-d-announce@ietf.org > Cc: trill@ietf.org > Subject: I-D Action: draft-ietf-trill-resilient-trees-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Transparent Interconnection of Lots of L= inks of > the IETF. >=20 > Title : TRILL: Resilient Distribution Trees > Authors : Mingui Zhang > Tissa Senevirathne > Janardhanan Pathangi > Ayan Banerjee > Anoop Ghanwani > Filename : draft-ietf-trill-resilient-trees-07.txt > Pages : 21 > Date : 2017-06-01 >=20 > Abstract: > The TRILL (Transparent Interconnection of Lots of Links) protocol > provides multicast data forwarding based on IS-IS link state routing. > Distribution trees are computed based on the link state information > through Shortest Path First calculation. When a link on the > distribution tree fails, a campus-wide re-convergence of this > distribution tree will take place, which can be time consuming and > may cause considerable disruption to the ongoing multicast service. >=20 > This document specifies how to build backup distribution trees to > protect links on the primary distribution tree. Since the backup > distribution tree is built up ahead of the link failure, when a link > on the primary distribution tree fails, the pre-installed backup > forwarding table will be utilized to deliver multicast packets > without waiting for the campus-wide re-convergence. This minimizes > the service disruption. This document updates RFC 6325. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trill-resilient-trees/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-trill-resilient-trees-07 > https://datatracker.ietf.org/doc/html/draft-ietf-trill-resilient-trees-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-resilient-trees-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jun 2 09:47:43 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B258D126CE8 for ; Fri, 2 Jun 2017 09:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no 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 ENeH0p8Jld2u for ; Fri, 2 Jun 2017 09:47:41 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05712126C25 for ; Fri, 2 Jun 2017 09:47:41 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m62so11677566itc.0 for ; Fri, 02 Jun 2017 09:47:40 -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=sRbZaTEYQ/gZmbXrjSCTau7DEiSJLFche/QyuA1fBbs=; b=bc67rom2qjBRD9ukPwLVstBkoGogT4znH4gsH5T06mRMxkkUbtYElOof1i03hEkupD 3OFUMm4gjZfHFlwcUCRDoKXKm/6P7ujmPf+rWVciveq0axMuoNqgjLBWuUDpvvQTaP9G xmEXMpmZ8Ivsq4At/Az3q7jFGYOF4u7cjVHz7FCDqbnqk676+tUOvKVsayOfoW3WYDFE zaHCaa+9mHZuy9Sz3KNsZALXpOyzYOM1mAL9pPuvLTcO6jdNEadiNuJLXCk/pRylJguT M1eDejls3IYEW30sZQ1d7La5MeiArgsbs03i1Nf8tkc1PdDqfP4+ghKoC6yN0LNNyUjI NkPQ== 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=sRbZaTEYQ/gZmbXrjSCTau7DEiSJLFche/QyuA1fBbs=; b=L8Zj1s05YVHOAs44I+cyAxruu23pxJYDoRrOe/8xTf2NZKX54wwwBWHB/QRiF3hx+l E9jcynsUtGY2LoJ4IxkbYC3QBYQTJYkj4M9lp1sYKuI1qxqhjcMtQL3Ddz9aWjYjg4U1 JuOk5iMGNqjR/RfsyEaYrlXUpuImKl8G/2XJZSlcC6LpygjYAeNtD1qoozqo0bM8SAqX ok/Sv2XZzLg1vLOT6nxnMgnWucPI2cB3+vf8dK2EEydY63OCBdNonrAXJZFeKYBgawYb n1fR3yJ04LvB+FV9fMOwsEm/RSveGAqcVFeSWkt9rqpVfomLNZHDS5GGOP9542ASYZVm seBA== X-Gm-Message-State: AODbwcAqp2dotss35VHQ9efoSb+WKbd0meGsmoE2p9FdA6Zj1F8nTpo3 sCUpuo+nRGCYpCmC6FKtaLuAt1gqIA== X-Received: by 10.107.52.19 with SMTP id b19mr8381717ioa.216.1496422060299; Fri, 02 Jun 2017 09:47:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.30 with HTTP; Fri, 2 Jun 2017 09:47:24 -0700 (PDT) In-Reply-To: References: <149626897714.19836.7466806270075160460@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 2 Jun 2017 12:47:24 -0400 Message-ID: To: Joe Touch Cc: "trill@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [trill] I-D Action: draft-ietf-trill-over-ip-10.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 16:47:43 -0000 Hi Joe, On Wed, May 31, 2017 at 6:37 PM, Joe Touch wrote: > > Hi, all, > > I'm confused by the TCP encapsulation shown. > > If you place TRILL in TCP, you cannot ensure that the TRILL packets are a= ligned with the TCP headers. TCP is a bytestream, not message-oriented. > > I.e., you need to assume that TRILL packets could be split across TCP seg= ments or multiple TRILL packets (or portions thereof) could be contained wi= thin a TCP segment. That means you will need a framing protocol that identi= fies the start of TRILL packets, and you should never assume that TRILL pac= kets align with TCP segments. > > If you want to try to assume alignment of some sort, you need to discuss = using RDMA, but that's a much bigger can of worms. Well, although I'm not sure it is all that difficult to do framing through TCP, for example BGP does it, I tend to agree with you. Unless there are comments to the contrary, we can remove this TCP encapsulation. It was an interesting exercise adding it because it revealed several places where the document was unnecessarily restrictive concerning transport. > Finally, regarding the IANA considerations, IMO the distinction between T= RILL data and TRILL control needs to be indicated in-band, not via differen= t port numbers. Ports should be requested only for services that are useful= independently (RFC7605). That's not the TRILL architecture. On Ethernet, TRILL uses two Ethertypes. On PPP, TRILL uses two PPP code points. CAPWAP is another example of this. TRILL control is a use of IS-IS and could be used for other things than TRILL as long as they can be tunneled to the same extent as TRILL. > (frankly, IMO, this system has gone off the rails out of control; you rea= lly ought to treat everything as running over Ethernet using the TRILL shim= and call it a day; the rest should already be sufficiently handled by Ethe= rnet-in-X encapsulation). Doing that wastes 12 or 16 bytes for every TRILL packet and these wasted bytes provide a covert channel which is not good from a security point of view. Designing an encapsulation for a particular transport is generally more efficient and provides better service but the question is whether it is worth the effort or complexity. The existing TRILL RFCs and Charter contemplate designing exactly 4 encapsulations: Ethernet, PPP, pseudowires, and IP. Only IP remains to have be completed. In retrospect, I'm not sure it was worth doing PPP but, in my opinion, Ethernet, pseudowires, and IP are worth it. 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 > Joe > > > > On 5/31/2017 3:24 PM, Donald Eastlake wrote: > > Hi, > > This revision has relatively minor changes to add an optional TCP based e= ncapsulation. > > 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 > > On Wed, May 31, 2017 at 6:16 PM, wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Transparent Interconnection of Lots of = Links of the IETF. >> >> Title : TRILL (Transparent Interconnection of Lots of = Links) over IP >> Authors : Margaret Cullen >> Donald Eastlake >> Mingui Zhang >> Dacheng Zhang >> Filename : draft-ietf-trill-over-ip-10.txt >> Pages : 41 >> Date : 2017-05-31 >> >> Abstract: >> The TRILL (Transparent Interconnection of Lots of Links) protocol >> supports both point-to-point and multi-access links and is designed >> so that a variety of link protocols can be used between TRILL switch >> ports. This document specifies transmission of encapsulated TRILL >> data and TRILL IS-IS over IP (v4 or v6). so as to use an IP network >> as a TRILL link in a unified TRILL campus. This document updates RFC >> 7177 and updates RFC 7178. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-trill-over-ip-10 >> https://datatracker.ietf.org/doc/html/draft-ietf-trill-over-ip-10 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-over-ip-10 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > > From nobody Fri Jun 2 11:43:13 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1173C129A92 for ; Fri, 2 Jun 2017 11:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ujiBjoLzO59a for ; Fri, 2 Jun 2017 11:43:11 -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 1C823129544 for ; Fri, 2 Jun 2017 11:43:11 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v52IgsfF027412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 Jun 2017 11:42:55 -0700 (PDT) To: Donald Eastlake Cc: "trill@ietf.org" References: <149626897714.19836.7466806270075160460@ietfa.amsl.com> From: Joe Touch Message-ID: <40ac03d6-9ad5-5e4a-a4ad-fbcb2003398f@isi.edu> Date: Fri, 2 Jun 2017 11:42:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-MailScanner-ID: v52IgsfF027412 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [trill] I-D Action: draft-ietf-trill-over-ip-10.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 18:43:12 -0000 Hi, Donald, On 6/2/2017 9:47 AM, Donald Eastlake wrote: > Hi Joe, > > On Wed, May 31, 2017 at 6:37 PM, Joe Touch wrote: >> Hi, all, >> >> I'm confused by the TCP encapsulation shown. >> >> If you place TRILL in TCP, you cannot ensure that the TRILL packets are aligned with the TCP headers. TCP is a bytestream, not message-oriented. >> >> I.e., you need to assume that TRILL packets could be split across TCP segments or multiple TRILL packets (or portions thereof) could be contained within a TCP segment. That means you will need a framing protocol that identifies the start of TRILL packets, and you should never assume that TRILL packets align with TCP segments. >> >> If you want to try to assume alignment of some sort, you need to discuss using RDMA, but that's a much bigger can of worms. > Well, although I'm not sure it is all that difficult to do framing > through TCP, for example BGP does it, I tend to agree with you. BGP messages are framed (they include a marker, length, and type), so they can be parsed out of a TCP bytestream. There is no expectation that BGP messages align to segments. > ... >> Finally, regarding the IANA considerations, IMO the distinction between TRILL data and TRILL control needs to be indicated in-band, not via different port numbers. Ports should be requested only for services that are useful independently (RFC7605). > That's not the TRILL architecture. Perhaps, but that represents a flaw in the architecture, not something to be propagated IMO. > On Ethernet, TRILL uses two > Ethertypes. On PPP, TRILL uses two PPP code points. CAPWAP is another > example of this. TRILL control is a use of IS-IS and could be used for > other things than TRILL as long as they can be tunneled to the same > extent as TRILL. Using different port numbers complicates configuration and encourages the potential for separate failures (e.g., one port is blocked but not the other). Whether TRILL control *could* be used in the future independently is less an issue as whether it is specified as such right now. Since you're creating a new shim for IP, you could easily clean this up, and I would encourage considering that, FWIW. > >> (frankly, IMO, this system has gone off the rails out of control; you really ought to treat everything as running over Ethernet using the TRILL shim and call it a day; the rest should already be sufficiently handled by Ethernet-in-X encapsulation). > Doing that wastes 12 or 16 bytes for every TRILL packet and these > wasted bytes provide a covert channel which is not good from a > security point of view. IMO, this perverts the concept of a TRILL campus. If that campus runs over Ethernet (real or virtual, local or extended), then the messages already ought to have those bytes (or need them reconstituted) anyway. If you're really interested in saving bytes, then you should be considering some sort of header compression, which could involve soft-state with header reconstitution at the tunnel egress. The specific encapsulations you're considering already exist for Ethernet. IMO, you're adding only complexity and fragility. Joe From nobody Sat Jun 3 07:54:38 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 387C21286CA; Sat, 3 Jun 2017 07:54:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149650167019.31902.17486569763500037038@ietfa.amsl.com> Date: Sat, 03 Jun 2017 07:54:30 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-transport-over-mpls-05.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 14:54:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL Transparent Transport over MPLS Authors : Mohammed Umair Kingston Smiler Selvaraj Donald E. Eastlake 3rd Lucy Yong Filename : draft-ietf-trill-transport-over-mpls-05.txt Pages : 17 Date : 2017-06-03 Abstract: This document specifies how to interconnect multiple Transparent Interconnection of Lots of links (TRILL) sites with an intervening MPLS network using existing TRILL and VPLS standards. This draft addresses two problems as follows: 1) Providing connection between more than two TRILL sites that are separated by an MPLS provider network. 2) Providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-transport-over-mpls-05 https://datatracker.ietf.org/doc/html/draft-ietf-trill-transport-over-mpls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-transport-over-mpls-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jun 3 07:59:45 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BFE120727 for ; Sat, 3 Jun 2017 07:59:44 -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 (2048-bit key) header.d=ipinfusion.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 FPAFebpxXrxH for ; Sat, 3 Jun 2017 07:59:43 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7A67129BE9 for ; Sat, 3 Jun 2017 07:59:42 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p66so61129823qkf.3 for ; Sat, 03 Jun 2017 07:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipinfusion.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=Q8u0msYfKFGvomd/RgsPCNY8GXqfEBjT3Xxo9sCufcI=; b=SufqCyKVFZzFQvpi9qhiYOQ2PX8jZ5+DNeyfV2OnJMoqEYVZjrOVnDt98zhHktJumL MqYmfARzZrRekdXfFBuXYKf0FvBCdHRVH5aoBjJFGGa3CcfyI8qOe+nB8LwPq26Yu/p0 uVivgFZ/wtbQbx2cLMXw3d8xTm2Erhs2wD4RolgoPGwD0tbO1CUmRltAJ9jiVVd78MIn m+Hu3DO1Ff3lAEOp/Xss7yTVYyvkPT8qGhousJdDiJVd9i6PZSYLqm2BIbLEO81y1stj RBat+chvl8sXu2BHKk0qlE259f8UStR8vjAZtLtUYTGjgqobw/e/vh2TxhvwYlH9JBIG 59Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=Q8u0msYfKFGvomd/RgsPCNY8GXqfEBjT3Xxo9sCufcI=; b=g8fChMLHxCz6etoqtMp8gIZ/YfkI2Nhxi2UJ1gva6Hxqsw0/HEMCiICS1FQQj5RRUa KlafREU/CLCfwkj6pKWJryMvi6PJmRJrWe7aUwPoKDgys8RMyPtzESZMMBh24sWITId0 e8DQmEo0Sq7KLZmNclUnAIUTqQrPlJNzo0zCZw+Ed6hakf+ygon9J2KuHMf+v+cpuNwC kkJVUPqvzl9cLx293babO/Kg3Hl27iKaVq/vF/GyC1qtjbznLsPeHuVAKKW30ovILZr5 bx87pl4x0mCUdMxLpqDv8vqyd7lrihn3FrmAGyqEeROrf4UkdqH3i+Bakelujn9qfu1h iDAw== X-Gm-Message-State: AKS2vOx+dHh2mVv1aThyHazQHVnRh/qIB4hfq7XXcXnaOvwlyNt38mBC zkwxdM5NfjCV/9mPOUDV5tcTn71YcSQ3zaLtK+JqBjC3x6yVGbG+xlVpCj4fBN1MvEE14n8pFyV xMQqsCt/PIV9yTRrAoiG6WBtXSyzRPgNkUbSISyYRYgw1n0JhesN5QKqhGzqmZpTKE3ear+hxwr q6pyfmjeLpBGA= X-Received: by 10.55.34.10 with SMTP id i10mr13840147qki.41.1496501981848; Sat, 03 Jun 2017 07:59:41 -0700 (PDT) From: Mohammed Umair References: <149650167019.31902.17486569763500037038@ietfa.amsl.com> In-Reply-To: <149650167019.31902.17486569763500037038@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ0Kn5dP/TweLECoeSbp7XhSDWbsKDQnr5w Date: Sat, 3 Jun 2017 20:29:40 +0530 Message-ID: <00497410042989747b81b0873566ece3@mail.gmail.com> To: trill@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [trill] I-D Action: draft-ietf-trill-transport-over-mpls-05.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 14:59:45 -0000 Hi, This version addresses comments we received from the Routing Directorate QA review. Regards, Umair -----Original Message----- From: trill [mailto:trill-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Saturday, June 03, 2017 8:25 PM To: i-d-announce@ietf.org Cc: trill@ietf.org Subject: [trill] I-D Action: draft-ietf-trill-transport-over-mpls-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL Transparent Transport over MPLS Authors : Mohammed Umair Kingston Smiler Selvaraj Donald E. Eastlake 3rd Lucy Yong Filename : draft-ietf-trill-transport-over-mpls-05.txt Pages : 17 Date : 2017-06-03 Abstract: This document specifies how to interconnect multiple Transparent Interconnection of Lots of links (TRILL) sites with an intervening MPLS network using existing TRILL and VPLS standards. This draft addresses two problems as follows: 1) Providing connection between more than two TRILL sites that are separated by an MPLS provider network. 2) Providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-transport-over-mpls-05 https://datatracker.ietf.org/doc/html/draft-ietf-trill-transport-over-mpls -05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-transport-over-mpls-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill -- . From nobody Sat Jun 3 08:06:15 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F29129BCA for ; Sat, 3 Jun 2017 08:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: syntax error)" header.d=ipinfusion.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 anHOFEsa7Zcq for ; Sat, 3 Jun 2017 08:06:11 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85362129AEE for ; Sat, 3 Jun 2017 08:06:11 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id f55so76991455qta.3 for ; Sat, 03 Jun 2017 08:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipinfusion.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=KCgdrFZmeUidKMitlJNeV8w94VaawHP1ohPnCoqVcjg=; b=FykzX2HAdrI59/SRiXhwFJPlGJZlAib22gco7Wbs0P1acwNJN2PKu8pg9bXZrsAt22 +ZXEdOuQVfvgixabtNqk650xDYierjiBaaFJtHehGL83ELo9ed/kiuzGHBwuDvfm0K0q qg3kOXImMbufa4QANTPFjORjfWKoUHXEWP8BA0kdL+SQANYjIbDfpbz6Ze+JhrJEEn/l AcMFPMYu+p6vP4ARktVhMMqCcIhj8ItUF2BAqUE/lILyxWgUeo+aV4ZoSd4aul6sSvWm YuvY63cQPb8V5oax3Chsc0TZKvwkjgfEMirM83p5nJkEJpkS89iOdyi1lEK3sl6z0394 RfbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=KCgdrFZmeUidKMitlJNeV8w94VaawHP1ohPnCoqVcjg=; b=P4/cXUlK/1TJNUIRBL6i6wvwB3exBycNbw0pqAeKlAzyU274+EdtMW3iU7JsrxchR2 guzOgZfDNKUkLpx0IcSnPNoH46HPq6RWqJBiYga1kJEMBvOfHVdeFVe1Bb67xb6FcF4k 9XzWTFpsS+0pV/eMNAffOtqOPZNovk94vMXQO9wqeVNbpyaoIDr0jgd0BPnXQa5trO1h fWETrrcNBfCHhIL5/dMXXxBR4/V/RtIPtWghrJYCV35DCvUmAFdspyJcITzfwdItTH60 bwXUXzWkCZPXtIVFRixI9mMOdt3juShCTfynY88T4MjDFHFo6SuJMDgN6fE8sAQf/ZbC El6Q== X-Gm-Message-State: AODbwcCJb4T2Ee5FbYdtu88RdHtZFOQwDy4yCyIidUDNhzuHHQKfkwTY U001ZkJspLNdGVdrCNQ/LIFL7LQcjLvQxyoxj5JQLTeYRq7Yiy8Mf0/XDh5RJnUkN3OosCnEKX8 H4TiPbRgG0QJGnZT35/ck9pP8fQzwkz0iv2u8iHEkOXFisHeSE/3pxGkglRZPAqmu0gTYOZoXIk yVYeHqenI/SYQ= X-Received: by 10.200.47.169 with SMTP id l38mr15618110qta.150.1496502370683; Sat, 03 Jun 2017 08:06:10 -0700 (PDT) From: Mohammed Umair References: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGCA568JvJrW7wv57ie05NblKPEFwJ1BxMKArneO88BoCgfVwIvGuG6AQiH+0KiZLecsA== Date: Sat, 3 Jun 2017 20:36:09 +0530 Message-ID: <3b8de085516fbae32a57d30b3ffcb5ac@mail.gmail.com> To: "Andrew G. Malis" , "Bocci, Matthew (Nokia - GB)" Cc: rtg-dir@ietf.org, draft-ietf-trill-transport-over-mpls@ietf.org, trill@ietf.org, Kingston Smiler Content-Type: multipart/alternative; boundary="001a1137954435e4da05510f9cfa" Archived-At: Subject: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 15:06:13 -0000 --001a1137954435e4da05510f9cfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matthew and Andy, New Version -05 is just posted, Could you look at this version which is intended to resolve your Comments. Regards, Umair *From:* Andrew G. Malis [mailto:agmalis@gmail.com] *Sent:* Tuesday, May 30, 2017 9:21 PM *To:* Mohammed Umair *Cc:* Bocci, Matthew (Nokia - GB); rtg-dir@ietf.org; draft-ietf-trill-transport-over-mpls@ietf.org; trill@ietf.org; Kingston Smiler *Subject:* Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 Umair, You added PBB being out of scope for this document to section 3.4, but it doesn=E2=80=99t say that anywhere else, such as in the introduction or the abstract. Is it really out of scope? The text in section 6 doesn=E2=80=99t scan, the first two sentences should = be joined together by a comma rather than a period and starting a new paragraph. But it still doesn=E2=80=99t make sense to me, because the secon= d part talks about what happens in the VPTS model if there=E2=80=99s a pseudowire = failure, but the first part of the doesn=E2=80=99t say anything about a pseudowire f= ailure in the VPLS model (which, as we noted, doesn=E2=80=99t present a problem if= you=E2=80=99re running spanning tree or H-VPLS with PW redundancy in the VPLS). Cheers, Andy On Mon, May 29, 2017 at 10:31 AM, Mohammed Umair < mohammed.umair2@ipinfusion.com> wrote: Hi Matthew and Andrew, Could you look at version -04 to see if this resolves your comments? My apologies for taking so long. Regards, Umair *From:* trill [mailto:trill-bounces@ietf.org] *On Behalf Of *Andrew G. Mali= s *Sent:* Monday, March 20, 2017 12:40 PM *To:* Kingston Smiler *Cc:* Bocci, Matthew (Nokia - GB); rtg-dir@ietf.org; draft-ietf-trill-transport-over-mpls@ietf.org; trill@ietf.org *Subject:* Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 Kingston, On Sun, Mar 19, 2017 at 4:35 PM, Kingston Smiler wrote: Typically PBB-VPLS is used to avoid exposing the customer MAC in service provider network. In case of TRILL packet over MPLS, already the customer MAC is encapsulated inside the TRILL header. Having said that, do we really need to consider TRILL over PBB-VPLS. PBB (and by extension, PBB-VPLS) is not just used for C-MAC hiding, but also for provider infrastructure scaling, so I would think the answer is yes. Matthew, do you agree? Cheers, Andy . --=20 . --001a1137954435e4da05510f9cfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi= Matthew and Andy,

=C2=A0

New = Version -05 is just posted, Could you look at this version which is intende= d to resolve your Comments.

=C2=A0

Regards,

U= mair

=C2=A0

From: A= ndrew G. Malis [mailto:agmalis@gmail.c= om]
Sent: Tuesday, May 30, 2017 9:21 PM
To: Mohamm= ed Umair
Cc: Bocci, Matthew (Nokia - GB); rtg-dir@ietf.org; draft-ietf-trill-transport-over-mpls@ietf.org;= trill@ietf.org; Kingston Smiler
<= b>Subject: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of = draft-ietf-trill-transport-over-mpls-02

= =C2=A0

Umair,

=C2=A0

You added PBB being out of sco= pe for this document to section 3.4, but it doesn=E2=80=99t say that anywhe= re else, such as in the introduction or the abstract. Is it really out of s= cope?

=C2=A0

The text in section 6 doesn=E2=80=99t scan, the first two sente= nces should be joined together by a comma rather than a period and starting= a new paragraph. But it still doesn=E2=80=99t make sense to me, because th= e second part talks about what happens in the VPTS model if there=E2=80=99s= a pseudowire failure, but the first part of the doesn=E2=80=99t say anythi= ng about a pseudowire failure in the VPLS model (which, as we noted, doesn= =E2=80=99t present a problem if you=E2=80=99re running spanning tree or=C2= =A0H-VPLS with PW redundancy in the VPLS).=C2=A0

=C2=A0

Cheers,

Andy

= =C2=A0

On Mon, May 29, 2017 at 10:31 AM, Moh= ammed Umair <mohammed.umair2@ipinfusion.com> wrote:

Hi Matthew and Andrew,

=C2=A0

Could you look at version -04 to see if this resolves your comments?

My apologies for taking so long.

=C2=A0

Regards,

Umair

=C2=A0

From: trill [mailto:trill-bounces@ietf.org= ] On Behalf Of Andrew G. Malis
Sent: Monday, March 20, 201= 7 12:40 PM
To: Kingston Smiler
Cc: Bocci, Matthew (Noki= a - GB); rtg-dir@ietf= .org; draft-ietf-trill-transport-over-mpls@ietf.org; trill@ietf.org
Subj= ect: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-= ietf-trill-transport-over-mpls-02

=C2=A0

Kingston,

=C2=A0

On Sun, Mar 19, 2017 at 4:35 PM, Kingston Smiler <kingstonsmiler@gmail.com> w= rote:

<Kings= ton>

Typically PBB-VPLS is used to avoid exposing the customer MAC in serv= ice provider network. In case of TRILL packet over MPLS, already the custom= er MAC is encapsulated inside the TRILL header. Having said that, do we rea= lly need to consider TRILL over PBB-VPLS. =C2=A0=C2=A0

</Kingston>=C2= =A0=C2=A0

=C2=A0

PBB = (and by extension, PBB-VPLS) is not just used for C-MAC hiding, but also fo= r provider infrastructure scaling, so I would think the answer is yes. Matt= hew, do you agree?

=C2=A0

Che= ers,

Andy

=C2=A0


.

=C2=A0


. --001a1137954435e4da05510f9cfa-- From nobody Sat Jun 3 08:20:25 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA0912EA6A; Sat, 3 Jun 2017 08:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 NV3QF7DjkpuD; Sat, 3 Jun 2017 08:20:15 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5EB120721; Sat, 3 Jun 2017 08:20:15 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id h4so120895750oib.3; Sat, 03 Jun 2017 08:20:15 -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=8fxklHXlUbrozdUVpK/nOe1oj2rjFLtK69ZY5tbxOxI=; b=udgbhR5xlSnLl3Df4I80ghP1FQA7J+KMTGe9wQUt4CTPH0mrCMIJzpW03vB7AMuAwB uFCo2IJYS9JGi8e+/JS688cxgOem3eh2dhkJnct5DeEQ5wqXcUCYpu/mTU+Ppm5bEq28 t1t1zi4UIpDw5DQmIGxIsm3mxlLZpf5tWTokEcw/XDzIxDw1oKo+ptV4vajf3vA5IqIG Ci9jiPFLId/8DzFUd7lxAwbKPxS0hxK5l5+Ev6sPDtsPnqXkjg5dDowY9WCbY0tCV2rz 5wKp4d9+jkY83YToegFd4j7tb/B9ZiSdXUWakHU6OohFMZlYRHBlo90+ewYDHn0vPcnD +3eg== 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=8fxklHXlUbrozdUVpK/nOe1oj2rjFLtK69ZY5tbxOxI=; b=ofzZEdlWCUvoY4MAVC79tYlX5LoRQh5FBrDxkn9qPhiwKkrKVjWNGjXLM/TIc74Gwb 27wDfbmxuBmbxrRio8dmJ6Efo+T4PrUW1yo0pZxBkjBoqCTV62XFf2NIVB/og2PU/ayh J2YwHxIyJm3lrjGUVGQFZnWTzI3T6moqeuBnKHw+KaR6TQcSnKqhMcvMQv2t01u3KX6z rtGTqhasR5ODQlZWt8MFJzY9VPaCjUZwvEGhyxSBnR4IKzFQXzQKA5rg32m33tQwhoNl uYQsgpjpsqtHj3dNkOzHjVqpISc7YSDOxcQa0YrGtLdbdb+iXvhz4piPpuMQPTGrXWNY R/nA== X-Gm-Message-State: AKS2vOxP0tys1/HBwl8asOw01UP1b8AYVsNkmWZAnc8jo06qSdZ7w08P oU9+EgKpuD0DBkcxy0qx3wahZEIvnw== X-Received: by 10.157.56.225 with SMTP id k30mr7104216ote.152.1496503215131; Sat, 03 Jun 2017 08:20:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.38.162 with HTTP; Sat, 3 Jun 2017 08:19:54 -0700 (PDT) In-Reply-To: <3b8de085516fbae32a57d30b3ffcb5ac@mail.gmail.com> References: <8FA0B47D-32C0-41D0-BBDD-35F430DC44EE@nokia.com> <3b8de085516fbae32a57d30b3ffcb5ac@mail.gmail.com> From: "Andrew G. Malis" Date: Sat, 3 Jun 2017 11:19:54 -0400 Message-ID: To: Mohammed Umair Cc: "Bocci, Matthew (Nokia - GB)" , "rtg-dir@ietf.org" , draft-ietf-trill-transport-over-mpls@ietf.org, "trill@ietf.org" , Kingston Smiler Content-Type: multipart/alternative; boundary="001a11c021588b151105510fceba" Archived-At: Subject: Re: [trill] [RTG-DIR] Routing Area Directorate QA review of draft-ietf-trill-transport-over-mpls-02 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 15:20:17 -0000 --001a11c021588b151105510fceba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Umair, Looks good to me, thanks! Matthew? Cheers, Andy On Sat, Jun 3, 2017 at 11:06 AM, Mohammed Umair < mohammed.umair2@ipinfusion.com> wrote: > Hi Matthew and Andy, > > > > New Version -05 is just posted, Could you look at this version which is > intended to resolve your Comments. > > > > Regards, > > Umair > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Tuesday, May 30, 2017 9:21 PM > *To:* Mohammed Umair > *Cc:* Bocci, Matthew (Nokia - GB); rtg-dir@ietf.org; > draft-ietf-trill-transport-over-mpls@ietf.org; trill@ietf.org; Kingston > Smiler > > *Subject:* Re: [trill] [RTG-DIR] Routing Area Directorate QA review of > draft-ietf-trill-transport-over-mpls-02 > > > > Umair, > > > > You added PBB being out of scope for this document to section 3.4, but it > doesn=E2=80=99t say that anywhere else, such as in the introduction or th= e > abstract. Is it really out of scope? > > > > The text in section 6 doesn=E2=80=99t scan, the first two sentences shoul= d be > joined together by a comma rather than a period and starting a new > paragraph. But it still doesn=E2=80=99t make sense to me, because the sec= ond part > talks about what happens in the VPTS model if there=E2=80=99s a pseudowir= e failure, > but the first part of the doesn=E2=80=99t say anything about a pseudowire= failure > in the VPLS model (which, as we noted, doesn=E2=80=99t present a problem = if you=E2=80=99re > running spanning tree or H-VPLS with PW redundancy in the VPLS). > > > > Cheers, > > Andy > > > > On Mon, May 29, 2017 at 10:31 AM, Mohammed Umair < > mohammed.umair2@ipinfusion.com> wrote: > > Hi Matthew and Andrew, > > > > Could you look at version -04 to see if this resolves your comments? > > My apologies for taking so long. > > > > Regards, > > Umair > > > > *From:* trill [mailto:trill-bounces@ietf.org] *On Behalf Of *Andrew G. > Malis > *Sent:* Monday, March 20, 2017 12:40 PM > *To:* Kingston Smiler > *Cc:* Bocci, Matthew (Nokia - GB); rtg-dir@ietf.org; > draft-ietf-trill-transport-over-mpls@ietf.org; trill@ietf.org > *Subject:* Re: [trill] [RTG-DIR] Routing Area Directorate QA review of > draft-ietf-trill-transport-over-mpls-02 > > > > Kingston, > > > > On Sun, Mar 19, 2017 at 4:35 PM, Kingston Smiler > wrote: > > > > Typically PBB-VPLS is used to avoid exposing the customer MAC in service > provider network. In case of TRILL packet over MPLS, already the customer > MAC is encapsulated inside the TRILL header. Having said that, do we real= ly > need to consider TRILL over PBB-VPLS. > > > > > > PBB (and by extension, PBB-VPLS) is not just used for C-MAC hiding, but > also for provider infrastructure scaling, so I would think the answer is > yes. Matthew, do you agree? > > > > Cheers, > > Andy > > > > > . > > > > . --001a11c021588b151105510fceba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Umair,

Looks good to me, thanks! Matthe= w?

Cheers,
Andy


On Sat, Jun 3, = 2017 at 11:06 AM, Mohammed Umair <mohammed.umair2@ipinfusion.= com> wrote:

Hi Matthew and= Andy,

=C2=A0

New Version -05 = is just posted, Could you look at this version which is intended to resolve= your Comments.

=C2=A0

Regards= ,

Umair<= /p>

=C2=A0

From: Andrew G. Mal= is [mailto:agmalis@g= mail.com]
Sent: Tuesday, May 30, 2017 9:21 PM
To: = Mohammed Umair
Cc: Bocci, Matthew (Nokia - GB); rtg-dir@ietf.org; draft-ie= tf-trill-transport-over-mpls@ietf.org; trill@ietf.org; Kingston Smiler


Subject: Re: [trill] [RTG-DIR] Routing Area D= irectorate QA review of draft-ietf-trill-transport-over-mpls-02
<= /div>

=C2=A0

Umair,

=C2=A0

=

You added PBB being out of scope for this docum= ent to section 3.4, but it doesn=E2=80=99t say that anywhere else, such as = in the introduction or the abstract. Is it really out of scope?

=C2=A0

The t= ext in section 6 doesn=E2=80=99t scan, the first two sentences should be jo= ined together by a comma rather than a period and starting a new paragraph.= But it still doesn=E2=80=99t make sense to me, because the second part tal= ks about what happens in the VPTS model if there=E2=80=99s a pseudowire fai= lure, but the first part of the doesn=E2=80=99t say anything about a pseudo= wire failure in the VPLS model (which, as we noted, doesn=E2=80=99t present= a problem if you=E2=80=99re running spanning tree or=C2=A0H-VPLS with PW r= edundancy in the VPLS).=C2=A0

=C2=A0

Cheers,

Andy

=C2=A0

On Mon, May 29, 2017 at 10:31 AM, Mohammed Umair <mohammed.uma= ir2@ipinfusion.com> wrote:

= Hi Matthew and Andrew,

=C2=A0

= Could you look at version -04 to see if this res= olves your comments?

My apologies for taking so long.

=C2=A0

Regards,

Umair

=C2=A0

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Andrew G. Mal= is
Sent: Monday, March 20, 2017 12:40 PM
To: Kingston S= miler
Cc: Bocci, Matthew (Nokia - GB); rtg-dir@ietf.org; draft-ietf-trill-= transport-over-mpls@ietf.org; trill@ietf.org
Subject: Re: [trill] [RTG-DIR]= Routing Area Directorate QA review of draft-ietf-trill-transport-over= -mpls-02

=C2=A0

Kingston,

=C2=A0

On Sun, Mar 19, 2017 at 4:35 PM, Kingston Smi= ler <kings= tonsmiler@gmail.com> wrote:

<Kingston>

Typically PB= B-VPLS is used to avoid exposing the customer MAC in service provider netwo= rk. In case of TRILL packet over MPLS, already the customer MAC is encapsul= ated inside the TRILL header. Having said that, do we really need to consid= er TRILL over PBB-VPLS. =C2=A0=C2=A0

</Kingston>=C2=A0=C2=A0

=C2=A0

PBB (and by extension, PBB-VPLS) is not just used for C-M= AC hiding, but also for provider infrastructure scaling, so I would think t= he answer is yes. Matthew, do you agree?

=C2=A0

Cheers,

Andy

=C2=A0

=


.

=C2=A0


.

--001a11c021588b151105510fceba-- From nobody Tue Jun 6 11:30:31 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0073129461; Tue, 6 Jun 2017 11:30:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8OYsLqBxa2Z; Tue, 6 Jun 2017 11:30:28 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 0D81D129412; Tue, 6 Jun 2017 11:30:28 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m47so115413960iti.0; Tue, 06 Jun 2017 11:30: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 :cc; bh=+aFPv6S9JCH7aWLmvJSNXqbbnOEB0GnrW/fKHFWTHkA=; b=XYQW+1h0VteFr5lX92dNIUtkg42aGeUurbLMI/t7J0mKB9ZpsLp88HCIzcWoEemG01 to83qTTb8Lpq//y07ECylqwkRihuNTiF3NfbD6HWWBXqGbuAlJ2hL5yWsfNjJs3+Bm/2 N0vLM542+/8GWXLx0QGS4dap3h6KdKIZ73RE9HgRIpyUAaSl28NO6vzdtqChdv4AMyHT EKfZ+QiUvPKtE7/2X9sY3/mN3Rup6hf6GO3Ot3pvQW8X4yLO8qrXYB9jx/uvNI5z7C2f QYFIXlEHTag0lVbC6fXqXvs61QCFjjncPIVVemthNSoal7t9dx/WRmOb7RpkesM58YIW mEYQ== 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=+aFPv6S9JCH7aWLmvJSNXqbbnOEB0GnrW/fKHFWTHkA=; b=sHPhA/zrxjzt4JOvGXKx6ShXbj3hqeV7nV39yVMQggBAJwctkH80s4PhF/yueJAtrN pRYkbVKQr05t+KJdjNNT+2NcC2Zmr9/nWYd3jU6xWrC3U7mzWkD3QnURWErFxCweJnPp nAvEQcRI/QOC/TDtAxKie8Gx/g0PlgWAv7bYPgeOTVX/bE8xOAoTe3ALV1M1CztruU5t 7Y17YkC0W20mPbUJeoQzzIoxqaBt2vPgqg0k1u1u14bfArmBNptcPekJjNN2+HI0B3mp Ck86QNQf/OIkOoNXn7txfoUl/PLZn+XJcgGCwoHAwnQEFa8ZzrF7Yjff9wdexTG9xlEq 9wSg== X-Gm-Message-State: AODbwcAJv0g1QhhKpbPxRpucGqdn5DBBNMFMNQ4JipPTxeWFBx6Eu0r1 KGcoiZ8gqpwKh6imcq8U6ZtrsCyMtyfY X-Received: by 10.36.98.210 with SMTP id d201mr10457918itc.82.1496773827139; Tue, 06 Jun 2017 11:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.30 with HTTP; Tue, 6 Jun 2017 11:30:11 -0700 (PDT) In-Reply-To: <01e101d2da3e$8b73b810$a25b2830$@ndzh.com> References: <01e101d2da3e$8b73b810$a25b2830$@ndzh.com> From: Donald Eastlake Date: Tue, 6 Jun 2017 14:30:11 -0400 Message-ID: To: Susan Hares Cc: "trill@ietf.org" , "trill-chairs@ietf.org" , Alia Atlas Content-Type: multipart/alternative; boundary="001a1144423246dad705514ed0e8" Archived-At: Subject: Re: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 18:30:29 -0000 --001a1144423246dad705514ed0e8 Content-Type: text/plain; charset="UTF-8" Support as an author. I believe this document is ready for publication and will provide facilities useful for improving flow control in TRILL campuses. I am not aware of any IPR in this draft. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, May 31, 2017 at 2:48 PM, Susan Hares wrote: > This begins a 2 week WG LC for draft-ietf-trill-ecn-support which can be > found at: > > https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/. > > > > > > The authors (Donald Eastlake and Bob Biscoe) should indicate whether they > know of any IPR relating to this draft. > > > > The TRILL WG should consider the following questions: > > > > 1) Does this extension of the ECN to TRILL Switches provide for > better > > Flow control of IP packets without packet drops? And is this useful in > TRILL deployments? > > > > 2) Do you believe this document is ready for RFC publication? > > > > Please include the answers to these questions among your comments about > this draft. > > > > Sue Hares > --001a1144423246dad705514ed0e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support as an author. I believe this document is ready for= publication and will provide facilities useful for improving flow control = in TRILL campuses.

I am not aware of any IPR in this dra= ft.

Tha= nks,
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
=C2=A0Donald E. Eastlake 3rd = =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01= 757 USA
=C2=A0d3e3= e3@gmail.com

On Wed, May 31, 2017 at 2:48 PM, Susan Hares= <shares@ndzh.com> wrote:

This be= gins a=C2=A0 2 week WG LC for draft-ietf-trill-ecn-support which can be fou= nd at:

https://d= atatracker.ietf.org/doc/draft-ietf-trill-ecn-support/.

=C2=A0

=C2=A0

The authors (Donald E= astlake and Bob Biscoe) should indicate whether they know of any IPR relati= ng to this draft. =C2=A0=C2=A0

<= /u>=C2=A0

The TRILL WG should consider the= following questions:

=C2= =A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Does this extens= ion of the ECN to TRILL Switches provide for better

Flow co= ntrol of IP packets without packet drops?=C2=A0 And is this useful in TRILL= deployments?

=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Do you believe this document is ready for RFC publ= ication?

=C2=A0

<= p class=3D"MsoNormal">Please include the answers to these questions among y= our comments about this draft.

= =C2=A0

Sue Hares


--001a1144423246dad705514ed0e8-- From nobody Wed Jun 7 06:14:29 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA96F129535; Wed, 7 Jun 2017 06:14:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 hXLWcwIkpUFj; Wed, 7 Jun 2017 06:14:25 -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 AD47D12943B; Wed, 7 Jun 2017 06:14:24 -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=vPvq2dKC7DSFAP1bg0Pv+PfxvQh/ITxhtp5xEiFOY9s=; b=FTj3UcIyXuvMOFbZwhzW7HntE tZbhau2W3bsQaExDK9kc3rhxHR/iiDCy0fGuxw1SPF8BzSE85k+Jxl18t4N/2ExPfg76+GkrDcPQd hTM5XaHuPlMlCl5p3gQHcXb1q/NJU+brTBozu2fNrDJOMaUcfqCkvXb2TiQIXV7lSkLikpaTb6dke dCnQzbp7rdAFr33tBWRDiNzmsL9V8qfk3EcmseJ72kJk7Dikd8ItrC56miZfTDlhOorXtrMiEPm+m /9abMpIrieVumzn3f/P8Ya4mDnyEftYuDUYT5QKI6EKDVyVINOvPr0gwafw2kOIaV1XjdvD2UcEjF z3PPEYOpg==; Received: from [77.88.71.158] (port=59316 helo=[172.16.5.179]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dIan0-0002Di-91; Wed, 07 Jun 2017 14:14:22 +0100 To: Susan Hares , trill@ietf.org Cc: trill-chairs@ietf.org, 'Alia Atlas' References: <01e101d2da3e$8b73b810$a25b2830$@ndzh.com> From: Bob Briscoe Message-ID: Date: Wed, 7 Jun 2017 14:14:21 +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: <01e101d2da3e$8b73b810$a25b2830$@ndzh.com> Content-Type: multipart/alternative; boundary="------------544CDFF533741F71C6982CE8" 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: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 13:14:28 -0000 This is a multi-part message in MIME format. --------------544CDFF533741F71C6982CE8 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sue, list, I know of no IPR relating to this draft. Regards Bob On 31/05/17 19:48, Susan Hares wrote: > > This begins a 2 week WG LC for draft-ietf-trill-ecn-support which can > be found at: > > https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/. > > The authors (Donald Eastlake and Bob Biscoe) should indicate whether > they know of any IPR relating to this draft. > > The TRILL WG should consider the following questions: > > 1)Does this extension of the ECN to TRILL Switches provide for better > > Flow control of IP packets without packet drops? And is this useful > in TRILL deployments? > > 2)Do you believe this document is ready for RFC publication? > > Please include the answers to these questions among your comments > about this draft. > > Sue Hares > > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------544CDFF533741F71C6982CE8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Sue, list,

I know of no IPR relating to this draft.

Regards


Bob

On 31/05/17 19:48, Susan Hares wrote:

This begins a  2 week WG LC for draft-ietf-trill-ecn-support which can be found at:

https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/.

 

 

The authors (Donald Eastlake and Bob Biscoe) should indicate whether they know of any IPR relating to this draft.   

 

The TRILL WG should consider the following questions:

 

1)      Does this extension of the ECN to TRILL Switches provide for better

Flow control of IP packets without packet drops?  And is this useful in TRILL deployments?

 

2)      Do you believe this document is ready for RFC publication?

 

Please include the answers to these questions among your comments about this draft.

 

Sue Hares 



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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------544CDFF533741F71C6982CE8-- From nobody Thu Jun 8 22:01:05 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0B8129420; Thu, 8 Jun 2017 22:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sT0HbM2SMmF; Thu, 8 Jun 2017 22:00:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC520126B7E; Thu, 8 Jun 2017 22:00:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E0587B80DD9; Thu, 8 Jun 2017 22:00:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, trill@ietf.org Message-Id: <20170609050048.E0587B80DD9@rfc-editor.org> Date: Thu, 8 Jun 2017 22:00:48 -0700 (PDT) Archived-At: Subject: [trill] RFC 8139 on Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 05:00:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8139 Title: Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders Author: D. Eastlake 3rd, Y. Li, M. Umair, A. Banerjee, F. Hu Status: Standards Track Stream: IETF Date: June 2017 Mailbox: d3e3e3@gmail.com, liyizhou@huawei.com, mohammed.umair2@ipinfusion.com, ayabaner@cisco.com, hu.fangwei@zte.com.cn Pages: 41 Characters: 95337 Obsoletes: RFC 6439 Updates: RFC 6325, RFC 7177 I-D Tag: draft-ietf-trill-rfc6439bis-05.txt URL: https://www.rfc-editor.org/info/rfc8139 DOI: 10.17487/RFC8139 TRILL (Transparent Interconnection of Lots of Links) supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439. This document is a product of the Transparent Interconnection of Lots of Links Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jun 9 00:20:11 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0425A120726; Fri, 9 Jun 2017 00:20:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149699280296.3003.18326279589854318069@ietfa.amsl.com> Date: Fri, 09 Jun 2017 00:20:03 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-resilient-trees-08.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 07:20:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : TRILL: Resilient Distribution Trees Authors : Mingui Zhang Tissa Senevirathne Janardhanan Pathangi Ayan Banerjee Anoop Ghanwani Filename : draft-ietf-trill-resilient-trees-08.txt Pages : 21 Date : 2017-06-09 Abstract: The TRILL (Transparent Interconnection of Lots of Links) protocol provides multicast data forwarding based on IS-IS link state routing. Distribution trees are computed based on the link state information through Shortest Path First calculation. When a link on the distribution tree fails, a campus-wide re-convergence of this distribution tree will take place, which can be time consuming and may cause considerable disruption to the ongoing multicast service. This document specifies how to build backup distribution trees to protect links on the primary distribution tree. Since the backup distribution tree is built up ahead of the link failure, when a link on the primary distribution tree fails, the pre-installed backup forwarding table will be utilized to deliver multicast packets without waiting for the campus-wide re-convergence. This minimizes the service disruption. This document updates RFC 6325. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-resilient-trees/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-resilient-trees-08 https://datatracker.ietf.org/doc/html/draft-ietf-trill-resilient-trees-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-resilient-trees-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 9 09:33:38 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7985128959; Fri, 9 Jun 2017 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HlFsLmWvpHBy; Fri, 9 Jun 2017 09:33:33 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0137.outbound.protection.outlook.com [104.47.2.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7106127419; Fri, 9 Jun 2017 09:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Dk+irshDK9seAXG3d6WU+aTwrLlDrsNPTJhS0hWeQKI=; b=ZjgXJ8U0vFyvr/2sBNIzevNFt1LeKeILzxwjvuaMHu90EDGUJaleBLvklx+zi8gBzf3PYsN8iWhG0cfNEv4cKynU13bDO5H+5/qHz/4mw+VztMnAKLxGHa4U0TJpPPLHZugy1sDuh7DR/qQ2hsX3rzQ/dPQJlDqMxMUJGZfwMA8= Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) by VI1PR0701MB2111.eurprd07.prod.outlook.com (10.169.136.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Fri, 9 Jun 2017 16:33:29 +0000 Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::70cb:2b35:d9f0:fa11]) by VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::70cb:2b35:d9f0:fa11%17]) with mapi id 15.01.1178.006; Fri, 9 Jun 2017 16:33:30 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: Susan Hares CC: "trill@ietf.org" , "trill-chairs@ietf.org" , "akatlas@gmail.com" , Bob Briscoe Thread-Topic: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13) Thread-Index: AQHS4SVIn8xfoMC1b0iu/cL00zj3naIcsFtQgAAAKtA= Date: Fri, 9 Jun 2017 16:33:29 +0000 Message-ID: References: <01e101d2da3e$8b73b810$a25b2830$@ndzh.com> <11429069-5f33-1a26-32c4-65322d53df02@bobbriscoe.net> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.212.29] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2111; 7:AA/lFnrTfxBbMKMsOaokJgshYmx6xE85wlXnZkANBE6oHdxwuA4rVojPvQ65aImqkGSU0piU/SewPnzsKBtgu5m4tzSphq6vT4nWNuas9cNKxdsCBBGsgfUYqUutOdZ2IDxA+FJzyQw8XLbKQ3LygwZQAkh4vdoluJ6t53wALzjtCql8IDK+5XpXkYWPb+XpdntqJsueW1z+RiAJYEfUtDUOdLTjXqFM9iICIYAfesE35DIP8M0L8xsVv1N52kYAeXrMsDQHkWYjcVdcnKu3HQoGX9ulP03D87tE+ktV20WLZ5LfBUC9Eptghjx8t5/jByUvs8ckExATHvPy/FNBBg== x-ms-office365-filtering-correlation-id: 1b3ff316-72f4-4a36-f621-08d4af55432f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR0701MB2111; x-ms-traffictypediagnostic: VI1PR0701MB2111: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB2111; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB2111; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39840400002)(39850400002)(39450400003)(39860400002)(39410400002)(24454002)(53754006)(7736002)(66066001)(14454004)(966005)(6116002)(3846002)(102836003)(2900100001)(305945005)(53546009)(25786009)(74316002)(38730400002)(478600001)(8936002)(8676002)(5250100002)(5660300001)(86362001)(81166006)(7696004)(55016002)(76176999)(6916009)(39060400002)(2950100002)(6506006)(9686003)(54356999)(2906002)(50986999)(189998001)(6246003)(229853002)(110136004)(230783001)(54906002)(6306002)(4326008)(53936002)(3280700002)(33656002)(99286003)(6436002)(3660700001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2111; H:VI1PR0701MB2126.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 16:33:29.7778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2111 Archived-At: Subject: Re: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:33:36 -0000 Hi all, I reviewed this draft (for the first time) mainly from the point of view of= L4S support. I greatly appreciate the forward vision of supporting upcomin= g ECN functionality, and the flexibility/extensibility of the thrill header= s. Answering question 1: Definitely, L4S ECN marking can drastically improve l= atency and flow control. Following comments related to question 2: I think there is one opportunity not exploited in how L4S ECN is handled: I= f an ingress node is not supporting ECN, a transit node is allowed to add t= he Flags word and mark packets with CCE. In case of L4S this case is not co= vered, and cannot be applied, as NCCE code points are translated by egress = nodes as CE or drop if the inner packet is Not-ECT. I think the solution co= uld be to extent the "Arriving TRILL 3-bit codepoint name" table with an ex= tra NCCE name mapping from TRILL-ECN=3D11 and CCE=3D0. Table 2 needs to hav= e an extra column with rows (not-ECT, ECT(0), CE, CE). This way an L4S tran= sit node can also insert a Flags word and set NCCE with probability p on to= p of CCE with p^2. I saw no other combinations that could lead to this arri= ving situation, and could lead to problems, as current ECN capable transit = nodes never mark NCCE. A typo in section 2: Extesnion should be Extension. Regards, Koen.=20 > On 31/05/17 19:48, Susan Hares wrote: > This begins a=A0 2 week WG LC for draft-ietf-trill-ecn-support which can = be > found at: > https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/. >=20 >=20 > The authors (Donald Eastlake and Bob Biscoe) should indicate whether they > know of any IPR relating to this draft. >=20 > The TRILL WG should consider the following questions: >=20 > 1) Does this extension of the ECN to TRILL Switches provide for better > Flow control of IP packets without packet drops?=A0 And is this useful in= TRILL > deployments? >=20 > 2) Do you believe this document is ready for RFC publication? >=20 > Please include the answers to these questions among your comments about > this draft. >=20 > Sue Hares >=20 >=20 >=20 > _______________________________________________ > trill mailing list > mailto:trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill From nobody Sun Jun 11 13:43:24 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DA8128BA2; Sun, 11 Jun 2017 13:43:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 9uKBrDUInKdL; Sun, 11 Jun 2017 13:43:19 -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 D8FE71267BB; Sun, 11 Jun 2017 13:43:17 -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=id4s83BDlhEIketkszPWWL2cqizZTgtmAfOkLVcz884=; b=5TtinLy5zCqOtSf2eEBBKadI+ /b3oLoSlyYqIaXmeohIKFdy2WKwACJdbhvTE36Mj62Cw1Cft4HxrmtX/q+nIOSoohFd199RAUwL2n qBjJ0W7ZV9rAx743ceRUn4Hcu1eSlKWGxs+5srDX9gRJKmVI8fthujnmBD5Jt5oktmiKLI7qb7rUE 8A5p1tSKANAxr/yulnAWmAsEgRwipB81DsbsoMFyghiBu543RUwdIj/TcKS8Pw2TzDRypeRsxO6a4 KxKqvP0V3S9Vf3fqau0yOgKsyof5KxHOu7U7trMEIxqC/uYhNuOFRJQpXXjF3uywcH+dCBhXupiOm DT/h1ULcQ==; Received: from 167.6.208.46.dyn.plus.net ([46.208.6.167]:52774 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 1dK9hb-0003xL-2R; Sun, 11 Jun 2017 21:43:15 +0100 To: "De Schepper, Koen (Nokia - BE/Antwerp)" Cc: Susan Hares , "trill@ietf.org" , "trill-chairs@ietf.org" , "akatlas@gmail.com" , Donald Eastlake References: <01e101d2da3e$8b73b810$a25b2830$@ndzh.com> <11429069-5f33-1a26-32c4-65322d53df02@bobbriscoe.net> From: Bob Briscoe Message-ID: <96af0bdf-b8fb-ad35-4733-25bd8daa10ef@bobbriscoe.net> Date: Sun, 11 Jun 2017 21:43:13 +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: Content-Type: multipart/alternative; boundary="------------8F0B232D5D9411742DC811AA" 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: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 20:43:22 -0000 This is a multi-part message in MIME format. --------------8F0B232D5D9411742DC811AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Koen, On 09/06/17 17:33, De Schepper, Koen (Nokia - BE/Antwerp) wrote: > Hi all, > > I reviewed this draft (for the first time) mainly from the point of view of L4S support. I greatly appreciate the forward vision of supporting upcoming ECN functionality, and the flexibility/extensibility of the thrill headers. > > Answering question 1: Definitely, L4S ECN marking can drastically improve latency and flow control. > > Following comments related to question 2: > > I think there is one opportunity not exploited in how L4S ECN is handled: If an ingress node is not supporting ECN, a transit node is allowed to add the Flags word and mark packets with CCE. In case of L4S this case is not covered, and cannot be applied, as NCCE code points are translated by egress nodes as CE or drop if the inner packet is Not-ECT. There is a problem in this case, but I don't think you have described it well (I think you have described why your solution would not work with the spec as it stands, rather than describing what is wrong with the spec as it stands). Here's how I would have described the problem: The technique in Appendix A for a transit RBridge to support L4S-ECN takes different actions depending on the last bit of the trill-ECN field, which in turn depends on the trill ingress RBridge having copied the IP-ECN field into the trill-ECN field. However, in a case where the ingress hasn't, the spec says "a transit RBridge "MAY" add a Flags Word itself. But, it would be a layering violation to expect the transit RBridge to look for the IP-ECN field and copy it into the trill-ECN field. The approach in the spec works for standard ECN [RFC3168], i.e. if a transit RBridge creates a flags Word it just initializes the trill-ECN field to not-ECT. But you're right, this doesn't work for L4S. I'm not sure how important this is, because no vendor is likely to implement creation of a Flags word by a transit RBridge anyway (which is why the spec says "MAY"). > I think the solution could be to extent the "Arriving TRILL 3-bit codepoint name" table with an extra NCCE name mapping from TRILL-ECN=11 and CCE=0. Table 2 needs to have an extra column with rows (not-ECT, ECT(0), CE, CE). This way an L4S transit node can also insert a Flags word and set NCCE with probability p on top of CCE with p^2. I saw no other combinations that could lead to this arriving situation, and could lead to problems, as current ECN capable transit nodes never mark NCCE. I have checked and this works in all cases. Even if there is a Flags word, this is better for L4S, because L4S transit RBridges would not need to read the trill-ECN field before marking. So the pseudocode in Appendix A would be simpler, i.e. just: % On TRILL transit if (p > random() ) { mark(NCCE) % likelihood: p if (p > random() ) mark(CCE) % likelihood: p^2 } There is a downside tho: your proposal adds an extra case for the behaviour of all trill egress RBridges. In summary, the tradeoffs with your proposal are: * More complex standards track behaviour for all egress RBridges. * Simpler for transit RBridges to support L4S (which is experimental track) * Makes it possible for transit RBridges that support L4S to add a Flags Word (but unlikely that vendors will do this anyway) Another way to solve this problem would be to just say that an L4S transit RBridge: * MAY create a Flags word, but only if it is willing and able to inspect the inner IP header and copy the IP-ECN field to the trill-ECN field. * Otherwise it has to use Classic drop for packets without a Flags Word. One thing your email made me notice: as it stands, the pseudocode in Appendix A ought to include an outer 'if' block that checks for the Flags Word. But let's see what comments there are on the list before deciding between the alternatives, then we can write the appropriate pseudocode. > > A typo in section 2: Extesnion should be Extension. Thanks for this. While re-reading the draft, I also noticed a few editorial improvements, which I will raise with my co-author. And thanks particularly for pointing out the alternative way of defining the egress behaviour. Cheers Bob > > Regards, > Koen. > > >> On 31/05/17 19:48, Susan Hares wrote: >> This begins a 2 week WG LC for draft-ietf-trill-ecn-support which can be >> found at: >> https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/. >> >> >> The authors (Donald Eastlake and Bob Biscoe) should indicate whether they >> know of any IPR relating to this draft. >> >> The TRILL WG should consider the following questions: >> >> 1) Does this extension of the ECN to TRILL Switches provide for better >> Flow control of IP packets without packet drops? And is this useful in TRILL >> deployments? >> >> 2) Do you believe this document is ready for RFC publication? >> >> Please include the answers to these questions among your comments about >> this draft. >> >> Sue Hares >> >> >> >> _______________________________________________ >> trill mailing list >> mailto:trill@ietf.org >> https://www.ietf.org/mailman/listinfo/trill -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------8F0B232D5D9411742DC811AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Koen,

On 09/06/17 17:33, De Schepper, Koen (Nokia - BE/Antwerp) wrote:
Hi all,

I reviewed this draft (for the first time) mainly from the point of view of L4S support. I greatly appreciate the forward vision of supporting upcoming ECN functionality, and the flexibility/extensibility of the thrill headers.

Answering question 1: Definitely, L4S ECN marking can drastically improve latency and flow control.

Following comments related to question 2:

I think there is one opportunity not exploited in how L4S ECN is handled: If an ingress node is not supporting ECN, a transit node is allowed to add the Flags word and mark packets with CCE. In case of L4S this case is not covered, and cannot be applied, as NCCE code points are translated by egress nodes as CE or drop if the inner packet is Not-ECT.
There is a problem in this case, but I don't think you have described it well (I think you have described why your solution would not work with the spec as it stands, rather than describing what is wrong with the spec as it stands).

Here's how I would have described the problem:
The technique in Appendix A for a transit RBridge to support L4S-ECN takes different actions depending on the last bit of the trill-ECN field, which in turn depends on the trill ingress RBridge having copied the IP-ECN field into the trill-ECN field. However, in a case where the ingress hasn't, the spec says "a transit RBridge "MAY" add a Flags Word itself. But, it would be a layering violation to expect the transit RBridge to look for the IP-ECN field and copy it into the trill-ECN field.

The approach in the spec works for standard ECN [RFC3168], i.e. if a transit RBridge creates a flags Word it just initializes the trill-ECN field to not-ECT. But you're right, this doesn't work for L4S.

I'm not sure how important this is, because no vendor is likely to implement creation of a Flags word by a transit RBridge anyway (which is why the spec says "MAY").

I think the solution could be to extent the "Arriving TRILL 3-bit codepoint name" table with an extra NCCE name mapping from TRILL-ECN=11 and CCE=0. Table 2 needs to have an extra column with rows (not-ECT, ECT(0), CE, CE). This way an L4S transit node can also insert a Flags word and set NCCE with probability p on top of CCE with p^2. I saw no other combinations that could lead to this arriving situation, and could lead to problems, as current ECN capable transit nodes never mark NCCE.
I have checked and this works in all cases.

Even if there is a Flags word, this is better for L4S, because L4S transit RBridges would not need to read the trill-ECN field before marking. So the pseudocode in Appendix A would be simpler, i.e. just:

      % On TRILL transit
      if (p > random() ) {
         mark(NCCE)                     % likelihood: p
         if (p > random() )
            mark(CCE)                   % likelihood: p^2
      }
There is a downside tho: your proposal adds an extra case for the behaviour of all trill egress RBridges.

In summary, the tradeoffs with your proposal are:
* More complex standards track behaviour for all egress RBridges.
* Simpler for transit RBridges to support L4S (which is experimental track)
* Makes it possible for transit RBridges that support L4S to add a Flags Word (but unlikely that vendors will do this anyway)

Another way to solve this problem would be to just say that an L4S transit RBridge:
* MAY create a Flags word, but only if it is willing and able to inspect the inner IP header and copy the IP-ECN field to the trill-ECN field.
* Otherwise it has to use Classic drop for packets without a Flags Word.

One thing your email made me notice: as it stands, the pseudocode in Appendix A ought to include an outer 'if' block that checks for the Flags Word. But let's see what comments there are on the list before deciding between the alternatives, then we can write the appropriate pseudocode.


A typo in section 2: Extesnion should be Extension.
Thanks for this. While re-reading the draft, I also noticed a few editorial improvements, which I will raise with my co-author.

And thanks particularly for pointing out the alternative way of defining the egress behaviour.

Cheers



Bob

Regards,
Koen. 



On 31/05/17 19:48, Susan Hares wrote:
This begins a  2 week WG LC for draft-ietf-trill-ecn-support which can be
found at:
https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/.


The authors (Donald Eastlake and Bob Biscoe) should indicate whether they
know of any IPR relating to this draft.

The TRILL WG should consider the following questions:

1) Does this extension of the ECN to TRILL Switches provide for better
Flow control of IP packets without packet drops?  And is this useful in TRILL
deployments?

2) Do you believe this document is ready for RFC publication?

Please include the answers to these questions among your comments about
this draft.

Sue Hares



_______________________________________________
trill mailing list
mailto:trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------8F0B232D5D9411742DC811AA-- From nobody Sun Jun 11 23:37:17 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194E2128854; Sun, 11 Jun 2017 23:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7j-Pp7ynpJU5; Sun, 11 Jun 2017 23:37:11 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0117.outbound.protection.outlook.com [104.47.2.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E9E127775; Sun, 11 Jun 2017 23:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rmS8ld/WZ/w5FCZmD9ZFGzwcK8ZGiIrZbl3pGwWjaEQ=; b=Srq8AiPyuCxFrp3jog0iplvgyh8QgKfXmA315FKE+NxeHUVPRNCdhttflDkM/EJPY7ujapVgImFHijrOufxSGem/OMzJ9i8HZYkA8nfaSO3lzQhTpbVLV7Bo+aiqvxKd4fyejVK7df3q2+QDRvDlvK7GCk1DexS1QqSwo6Nr1Jg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia-bell-labs.com; Received: from [138.203.133.22] (135.245.212.22) by DB5PR07MB1237.eurprd07.prod.outlook.com (2a01:111:e400:599a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Mon, 12 Jun 2017 06:37:03 +0000 To: Bob Briscoe , "De Schepper, Koen (Nokia - BE/Antwerp)" Cc: "akatlas@gmail.com" , Donald Eastlake , "trill-chairs@ietf.org" , Susan Hares , "trill@ietf.org" References: <01e101d2da3e$8b73b810$a25b2830$@ndzh.com> <11429069-5f33-1a26-32c4-65322d53df02@bobbriscoe.net> <96af0bdf-b8fb-ad35-4733-25bd8daa10ef@bobbriscoe.net> From: Ing-Jyh Tsang Message-ID: <90bbfa26-c05a-be98-f1f6-860fc3b23f02@nokia-bell-labs.com> Date: Mon, 12 Jun 2017 08:36:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <96af0bdf-b8fb-ad35-4733-25bd8daa10ef@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------C4FC39C8CC18126BFFA572B5" Content-Language: en-US X-Originating-IP: [135.245.212.22] X-ClientProxiedBy: VI1PR0802CA0035.eurprd08.prod.outlook.com (2603:10a6:800:a9::21) To DB5PR07MB1237.eurprd07.prod.outlook.com (2a01:111:e400:599a::11) X-MS-Office365-Filtering-Correlation-Id: 27e60f98-5faf-43dd-da7f-08d4b15d7034 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:DB5PR07MB1237; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1237; 3:9GoJynB3WBdr3mHssTV8JG+Y+z1tLp6IhJhfGqxajjqfdeie9BsHK/ylK4znpU/J5B1vlJvfcLsyt6hUQ3R8cjKm92nKPiCt4UklQzi5tX3FRXJ+gF/41AjRSZFrw0RpFVJViWSxBqhIVFnbdqgDxSRKPymIo47eNDmb4X6kBRRUPDTQ56QRnDgc+mmN5cIJags9n4rYY3NJIwPQ//DXrPgbNu6vpGQRaThjF0d8JFzhOfV1I971fp0sbo9Vm4FJohpKnYr4FvkQEeKVfH5mHqmDc7UgnQsUJEgQT+SeDcSnoL/ik8UDbiwpH2sLiHIariDzmS1jFm7WzIeSjfm2cSH0z2tiR/JHov9f1Ym4YBo=; 25:ZoLAIYOKuB2zhgME+tn/JqvfxS5QlOJKWHmQI5O70SoMB0GrDFahMSqcWjtkeXOzY9txTXgDz6ospZwUKunciPTPzCFStENA0s01RLZBSjFPwmkKapsuI91Pr144g3ACOPwgsI7Fh+hsLQc+JaqiECni9UCA96zuijTWHXpA6yNmVKx1soPun/4oRRKx8xuxc0GK5XB7WOkvquxS8Nk6DgEh2J2pZhty/5PBO+PVpJi4IB6fMVH2aZ9a0KYP1tnI/VGdDGjPkAWhSJ15IyB5XSomQcVUDbEeqfMtxVnvozRZMZ0u79KOqOgU+9kEEJY0kCKVxh8z+owzg/wDT9EmtssvVm5eBxx8bqb8XaWEqDtbD+K1r0NOdD+F0vlLIWX7twgfnCiWgZweA39rhNtVb5ZSIhblzaKuAh5H73PguQRlXuZPqD5CJAU8DOqAMnq/yiJjNdU604/vAfyoqSj16ZB0g/5T+UgHhEDJ9wHXTyc= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB5PR07MB1237: X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1237; 31:yKXY6WZN0wWbOnsTDlbmFB/sYKbvXIyfLYrL26I5kIIX51bKyh1sGnR768qTT2RAZXPid2meVO1g3x3I/mk5FOHX+6ty1o9DSi/zajUDuhd4yqahzYj7iM9sOQc0/yL2JsPGtP8+Nez+iAHLqrRJ+0lHZebSgO0UOFsBTN3MBUohzGIovMPz8DurM1wTUq8T0pk+WlYDdwO4sk/AAn15aucfZLlap4rS96YO53UMKsM=; 20:6h1AU+LOsuniSqDEv20Psp5LiQXucWE9Z9uHgXEYxvjW6+NSrjpn6crYqyjAecaocI49RqAL62Kw03WJ+9X/kne2Yyv+/dm13azZK4065NKCuS8kQsQ4JYpI2ZbWMIPf+ABna6kwsdqW87ZKMLe2G0wmaIdyxokvX15j/Ayz1w9hzvOTQ8hnrTUp7+bnHtNzQuhufU553NuL61o/Z5QR0PPCEySjCdlF5dOJ9Ho2BEirnoGS9dZP6id6pnsw4h8IHmRYtF8p1eA1LXDZUn2DCB8dufxrdH+7rAuHHGcznO2mXFZU1yeE1zGWHJma5N1W/GlvWUGtS/OUDpYVtZKh0ycBoFm4kXKhN0ulROiY9dP+nhCz6GXf5xIoemBadoDPUrHEcFdh1b3ltFeoXiplTSgyb8saAIbwsf/cktAgPlXWiGr0AJa9Vz7RRbz6wzkqUC1dtx7ktcJmeiRI81etbp0MDsVrpcOcTowcSUYgODJTybON3r/bL3bbL1rHO9R6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(189930954265078)(49204369933175); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1237; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1237; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5PR07MB1237; 4:regSapXQgR2FoUq3KO3OwUZn6ocbdX3u/cn7nS1FLz?= =?us-ascii?Q?oCVUU5BwZ1Qktw0t/6r7AM1z38Gx//rXZgL31duz0kcCQe3KWGqIupRodFMe?= =?us-ascii?Q?r724qL+6jDnAe9JRKrEAuO6VXh6VcO4klhM3ITY2uQx9eL62wHYWoFevS/P7?= =?us-ascii?Q?qXvft/D+02hSImy2z1s4fu44/yepSYr4aFmK/pKannGSk+OSfP+HFqI3tBqL?= =?us-ascii?Q?hwSmBQzOHhu+hedmkUASkSvU6uF2h/BMau1hfv0Z+QFTOS5rykiKEOdmlaRi?= =?us-ascii?Q?hafiPJ/NQmFywwow0qBVrPrIhiBkJVyVQYz4NwEa+wL9s5qfRwC4rhXqSOLv?= =?us-ascii?Q?b/zHJ/ezDTLDi3bYLAogqKi+PYp1yW/aIar7YjI8qlrrKOQ2cRDNF3QBkIZW?= =?us-ascii?Q?38HIGoSHc0rwcReBFDzeDtcPEmbZmh0Z7z8xLVt8o4XK6OIv3qhT8/RP1aYf?= =?us-ascii?Q?3GXj2q4HM2jQ/DkmGEdVTNzQTZcT3xwAIjjb0jeky4fHu8/cmasOd4G5hi2G?= =?us-ascii?Q?70G6j/CMZgat7wvAyjzRCdaJgTyPd5S4nTbXo9l9AOMmKHBYkE4HnvUGRa1i?= =?us-ascii?Q?OIHFz8xk3lmiTBSwUQ1/ZrJDZVTiwnx3iV6d6ab6NUYNSzm2KbLkZCbQsvJ7?= =?us-ascii?Q?9k1/yGZL8bZzCEmptzamjxq98QGsvFc2TX1TFcNpegvFyFg3nvfET9EyqMdm?= =?us-ascii?Q?NXAvzBLIKehJwm9rWGDBty2UrT37cYL9pxABnZuN08eGYxfX+0seWJbFfxMe?= =?us-ascii?Q?tcn3ZQkcP2rPKlwHQQKFXjfzUjn+SF4z91UTi1t3jKzZLHdeRZAyWI1c0Tnl?= =?us-ascii?Q?cOoqfLgpOwqjpzqNnm1UwB2g2PGOHSsOqgqpCCigSzwXoYiLwt6AEqfY6XXK?= =?us-ascii?Q?kNAv0wF5V5l3BDoe6ybVCVgIcliTeULNZC9ZEjFkn6Sxt+Xhdh/bRkXc/2mh?= =?us-ascii?Q?/zSlsiZpbGbmik3Vnx0CA8dlSgZTZ8/zLBffFOwR5sR5H4MmDIwIOLjQ0qQA?= =?us-ascii?Q?MUNHQmdGnyDuM/sDhixUm8dJ7y5NnmE2IcfXx6rLsa9W3EC3dSaHohWcghPR?= =?us-ascii?Q?13jqq7aXMTwD4IAKKYW25O30aHIRkJGxTX//u2d0RHpR4wsb7k3Y0XktpdpE?= =?us-ascii?Q?6AYw9R5W2HM8/isR/RFPvQuLjz6SwaMF2T+mjDNJyVL7cJyb6KMZD1cRmKzL?= =?us-ascii?Q?6EeWmFmwNZGgZoX5yABOchE+9iD6xbo3aa48vlxCEgoL3t6Bq90qTX5Kg+Vi?= =?us-ascii?Q?03Vq2X9ahsK34J94bB4DgQIt5q2VK3Y29rF3Oc?= X-Forefront-PRVS: 03361FCC43 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39850400002)(39400400002)(39450400003)(39860400002)(39410400002)(39840400002)(53754006)(24454002)(53936002)(66066001)(65956001)(65806001)(7906003)(7736002)(64126003)(236005)(6246003)(33646002)(38730400002)(53376002)(53546009)(4326008)(65826007)(230783001)(25786009)(50986999)(83506001)(84326002)(5660300001)(6116002)(606005)(270700001)(31686004)(8676002)(54356999)(86362001)(2906002)(76176999)(3846002)(189998001)(6486002)(561944003)(966005)(36756003)(93886004)(478600001)(49976008)(54906002)(54896002)(81166006)(229853002)(42186005)(31696002)(4001350100001)(6306002)(2950100002)(6666003)(6636002)(78286005)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1237; H:[138.203.133.22]; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5PR07MB1237; 23:Z+4NrpFOE7bqmaBakfdDJLfGlBSOq4yyIxDKEz2hA?= =?us-ascii?Q?y83DulL4d5YRH43UEuXi9apqmau4AgYx6EodF/v+TNDWX2jt8oRZ+6eWXUnX?= =?us-ascii?Q?b1g9Qvizb22g6gEhSfsexw44RrfZ86Yfioz0BjsVguF2nfLkY9F8tVblupzC?= =?us-ascii?Q?F4iHrTbc0Du3X9C7YbhwFwR9RMHRmGiPwHbPI7EIx/LE55caUzbafvlY+MRY?= =?us-ascii?Q?/Hi2N/umWX8V3cTxc7KWUiSnWOwQMuXPoC/eDVTJaXd8RzXSMmPPITOaFDGz?= =?us-ascii?Q?gJUcF3KzvQ21RE+0O9M/E4ioldu2Xx5DyHiI2py4+ZoRl23QyUfHeXT0nXFw?= =?us-ascii?Q?DHLdckGrP55LceEVZoorWkgeF1kAgTOZ/z8vTsq5LzF83MSe6v7ImMsyk4pT?= =?us-ascii?Q?beMZnNJKoLm8uHh9psekuJ5nuS4nZUgY1MJzL9v1/6aMZbSwmXysvJW7+DWo?= =?us-ascii?Q?IJp1RP9HBqovJNexzYpw+STrIVtweQ5+DploTR9e1zZ+zhVRCfBFu+9qvczp?= =?us-ascii?Q?iz07ngQAu/7zxMxV+Xpt6ukTkd72W5MtpWb42gRiMOgD8Apltw9zBFWlV1Dq?= =?us-ascii?Q?pMPstouYH+kY5nCucYM1yItB1J2ZRox12BpJ6116ZqFj2LF/TnscC/1ZZZqZ?= =?us-ascii?Q?x5j/xs0bZH7iUBTBxYI338upsZCWD0+3n/L8tfOYsRrov80LZCooVd/yXkPe?= =?us-ascii?Q?vYumj7CwnTu4va7eGA0eIBu28zjCjdvhpm6MUCEsdis68XlpDA05YwjyEWCw?= =?us-ascii?Q?3l4Cm9JoXpoxptubDbA9KCpCPLXcZZD59RmgX1uUB/b8gnbgL+b74MRWS1EA?= =?us-ascii?Q?8PMMik8t2eRZpwQ6QPjY2LlVOUJ+F0qpC8Ez28LpckefSMvIyw2FMoRiazdE?= =?us-ascii?Q?wV0ElFwyDUDYAA9cCzIa0IjxP5kFBnm888za17fPaRYMokP4lyG1kYt+iwTs?= =?us-ascii?Q?9n2HjNZeF76gv9c6oqXuXSyMy5R85dyenBdVWAloFvW+vgNInbKiGTa+wtCd?= =?us-ascii?Q?SjYVr+HBfKXQ3i67SbOhRsABjcIGc022/2ifZp8otKxo9VIQqUEJ43kWDlk1?= =?us-ascii?Q?5ozw9u8xPb/JbVx2s++CCfpKEi3mM/Afmmj0mGYFY9Mvz5555aPxz3HL5tjm?= =?us-ascii?Q?x7EqOo+5MJ6wqgctWmDAfMjSW3K0d1sQj0JlIVEvX+33reXjYy82g78OGUPy?= =?us-ascii?Q?g+dyMFmauyakIYS53tbAHjwjglMoGKBGd21fVoWbLm7lH50xgrlklEIRwt33?= =?us-ascii?Q?wloccAYXYdceORCpwtC6HhLiadrbC2jc1/PDl1yOsT7xvSqGKHc2kT/6K8qu?= =?us-ascii?Q?bmLTP3gXnm3d/5nJiKPoxJJb05mhMtYWf0V5vWWUxYHeS7q/y632pjpFJ59+?= =?us-ascii?Q?2aoCcQFcUJ+6CZW27vLZZvPCswzG2siBGdYRfqhLP1z5WaQQjkZhqorhXFcK?= =?us-ascii?Q?PZrdExExzP+fE3S2IHsdBN0+KROCx/NrDzlSIeQbLIwsX5A7eGt06dw80AiT?= =?us-ascii?Q?Ko0hrRyG4qvBQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1237; 6:Y3OGcAN9tAFxlUyFuRFK1o8Xn03vR69aJ2yc0yWOtAlj+L3buLIgQLTwesLJb3im3H5nefz6EVvkJUmPReFAK4Ebzvuu5Jmx+8/5Nor8UfhaAC64vLpKfOKleune04lBve8Hq9vAE+hcCPAY9CPXVv1Vr91DfLRZE8bM4XZ4fcO6jNWaOcfBDxyzizy5anKrT3Xm2znmgDY4NYCKSFOD0WV53Ncv0aJJVtBx+XhFy/S2N+3x1Tg/ddkMLAUu0TMCHyG7QRnlcxHA3ceKCXJU+dyNiKWGEgl0IzcrBiSvvPdzZzd3jh51fwzOBstOzr+Kn+BaoBrVUlkJr310E5FSztfRrHci8tXRUzjmcsoQGmYyoduGXBdLi1+7RmFARglu4jrw8RTscxpMcr+RODvDxKdd4VNKcTdemaj3S9n0ceil1uIJWY5unJhjQMJmq43XrraMSCZZ9WjTIEk3J5vTFvaPBWWAQFM1k2SoPXthA2NvEn+m4kX5JOsk41QucacMtrI8cnl+K41PRP6BVsrN4vhDR9jai2WBoZFUKEj8NRY= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1237; 5:pcub9dq48H95cUw6uvcUNxkflzX6nSpX06nxhRqRcbPirZeiYWuskk4JOrNCyqti19Uy3U4pJ1lqGXDblRfKK3tdAl01qq4AUC9w7rMbKw9iWZ24q7mEg1Wo2Q3t+3H5E1yJFDRaCEdpdxFU7HqSw9w8e70yltAouHWLhvhBSq/6i0bnnbG2FnhoZ8xyPFNWRQdcNfiJ+hPCc6PH2eGW2Vdler6V9MJpAh+FS958DQKt7X4C0bQjEGGMIf5+BUpxvpOfb8zpnsp9jFfLASMmPPIjeh53nJOmUgjJFujr5vZEg07uJZa6PJBSL13mCzNMhGEL9n1w96xJNZ1rWxlDnHMXCUKZCCx8T6BkNPYjLoIO5doBOocyQL1/VtVWASfN+MUKQ/tunbeJu+Cm1+gZM7TGkThqFMvWwbjn1ubKTdXT+yEstnB7IEfMjIAVi+ykqp+JbHab0++vpNfWJheWc2lVIoM4cKB85CzYHikTmQBHuFFLidhn3G7+pB9vvRM9; 24:aBU13+LaKlbAwe/ZP40XQmXrFDEHoCVh4SDtFysfqrnvmVvbKIlwH9lioOoILPDBiiDtMQUWHzLezQwf7g3Mc23AiEIci/uSLu07htBOxM4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1237; 7:a3Y9xmlFOaeypfH4NjC8QyZuTteeDLx0CNxTb8mv9x9/m4umtckGAD1OBRJkT3igRFNcAbRNghLNr3BsJvqJ6Rp5G9lGeNWqKpp1LZjaKfS06fChgBjHovaxUOaEvSMWMKHX/m6hGpLoeD8sR+jkGOd+sp3ZzmymPcM31uW3h5iUB03dPCBO5pbFvPZSE3yzkk97g0Xgle7Q5B/fGxHARfQs0TYVuAd2OybEe+g6cCkVf4fZpCDwXndL2h2dqeRePBgbTb1lh2VS3Zzuq2yFfshPq/ipK0MafufDTf8TYmWKYjE/uHoLGzWuH4BhjnKLpfwvCXYcfDYF+Px58sKtdw== X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2017 06:37:03.0075 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1237 Archived-At: Subject: Re: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 06:37:15 -0000 This is a multi-part message in MIME format. --------------C4FC39C8CC18126BFFA572B5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Bob, all. I definitely support the work done here. ECN and L4S support in TRILL addresses cross layer "control intelligence" benefiting network optimization. On 11/06/2017 22:43, Bob Briscoe wrote: > Koen, > > On 09/06/17 17:33, De Schepper, Koen (Nokia - BE/Antwerp) wrote: >> Hi all, >> >> I reviewed this draft (for the first time) mainly from the point of view of L4S support. I greatly appreciate the forward vision of supporting upcoming ECN functionality, and the flexibility/extensibility of the thrill headers. >> >> Answering question 1: Definitely, L4S ECN marking can drastically improve latency and flow control. >> >> Following comments related to question 2: >> >> I think there is one opportunity not exploited in how L4S ECN is handled: If an ingress node is not supporting ECN, a transit node is allowed to add the Flags word and mark packets with CCE. In case of L4S this case is not covered, and cannot be applied, as NCCE code points are translated by egress nodes as CE or drop if the inner packet is Not-ECT. > There is a problem in this case, but I don't think you have described > it well (I think you have described why your solution would not work > with the spec as it stands, rather than describing what is wrong with > the spec as it stands). > > Here's how I would have described the problem: > The technique in Appendix A for a transit RBridge to support L4S-ECN > takes different actions depending on the last bit of the trill-ECN > field, which in turn depends on the trill ingress RBridge having > copied the IP-ECN field into the trill-ECN field. However, in a case > where the ingress hasn't, the spec says "a transit RBridge "MAY" add a > Flags Word itself. But, it would be a layering violation to expect the > transit RBridge to look for the IP-ECN field and copy it into the > trill-ECN field. > > The approach in the spec works for standard ECN [RFC3168], i.e. if a > transit RBridge creates a flags Word it just initializes the trill-ECN > field to not-ECT. But you're right, this doesn't work for L4S. > > I'm not sure how important this is, because no vendor is likely to > implement creation of a Flags word by a transit RBridge anyway (which > is why the spec says "MAY"). > >> I think the solution could be to extent the "Arriving TRILL 3-bit codepoint name" table with an extra NCCE name mapping from TRILL-ECN=11 and CCE=0. Table 2 needs to have an extra column with rows (not-ECT, ECT(0), CE, CE). This way an L4S transit node can also insert a Flags word and set NCCE with probability p on top of CCE with p^2. I saw no other combinations that could lead to this arriving situation, and could lead to problems, as current ECN capable transit nodes never mark NCCE. > I have checked and this works in all cases. > > Even if there is a Flags word, this is better for L4S, because L4S > transit RBridges would not need to read the trill-ECN field before > marking. So the pseudocode in Appendix A would be simpler, i.e. just: > > % On TRILL transit > if (p > random() ) { > mark(NCCE) % likelihood: p > if (p > random() ) > mark(CCE) % likelihood: p^2 > } > > There is a downside tho: your proposal adds an extra case for the > behaviour of all trill egress RBridges. > > In summary, the tradeoffs with your proposal are: > * More complex standards track behaviour for all egress RBridges. > * Simpler for transit RBridges to support L4S (which is experimental > track) > * Makes it possible for transit RBridges that support L4S to add a > Flags Word (but unlikely that vendors will do this anyway) > > Another way to solve this problem would be to just say that an L4S > transit RBridge: > * MAY create a Flags word, but only if it is willing and able to > inspect the inner IP header and copy the IP-ECN field to the trill-ECN > field. > * Otherwise it has to use Classic drop for packets without a Flags Word. > > One thing your email made me notice: as it stands, the pseudocode in > Appendix A ought to include an outer 'if' block that checks for the > Flags Word. But let's see what comments there are on the list before > deciding between the alternatives, then we can write the appropriate > pseudocode. > >> A typo in section 2: Extesnion should be Extension. > Thanks for this. While re-reading the draft, I also noticed a few > editorial improvements, which I will raise with my co-author. > > And thanks particularly for pointing out the alternative way of > defining the egress behaviour. > > Cheers > > > > Bob >> Regards, >> Koen. >> >> >>> On 31/05/17 19:48, Susan Hares wrote: >>> This begins a 2 week WG LC for draft-ietf-trill-ecn-support which can be >>> found at: >>> https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/. >>> >>> >>> The authors (Donald Eastlake and Bob Biscoe) should indicate whether they >>> know of any IPR relating to this draft. >>> >>> The TRILL WG should consider the following questions: >>> >>> 1) Does this extension of the ECN to TRILL Switches provide for better >>> Flow control of IP packets without packet drops? And is this useful in TRILL >>> deployments? >>> >>> 2) Do you believe this document is ready for RFC publication? >>> >>> Please include the answers to these questions among your comments about >>> this draft. >>> >>> Sue Hares >>> >>> >>> >>> _______________________________________________ >>> trill mailing list >>> mailto:trill@ietf.org >>> https://www.ietf.org/mailman/listinfo/trill > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill --------------C4FC39C8CC18126BFFA572B5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Bob, all.

I definitely support the work done here. ECN and L4S support in TRILL addresses cross layer "control intelligence" benefiting network optimization.


On 11/06/2017 22:43, Bob Briscoe wrote:
Koen,

On 09/06/17 17:33, De Schepper, Koen (Nokia - BE/Antwerp) wrote:
Hi all,

I reviewed this draft (for the first time) mainly from the point of view of L4S support. I greatly appreciate the forward vision of supporting upcoming ECN functionality, and the flexibility/extensibility of the thrill headers.

Answering question 1: Definitely, L4S ECN marking can drastically improve latency and flow control.

Following comments related to question 2:

I think there is one opportunity not exploited in how L4S ECN is handled: If an ingress node is not supporting ECN, a transit node is allowed to add the Flags word and mark packets with CCE. In case of L4S this case is not covered, and cannot be applied, as NCCE code points are translated by egress nodes as CE or drop if the inner packet is Not-ECT.
There is a problem in this case, but I don't think you have described it well (I think you have described why your solution would not work with the spec as it stands, rather than describing what is wrong with the spec as it stands).

Here's how I would have described the problem:
The technique in Appendix A for a transit RBridge to support L4S-ECN takes different actions depending on the last bit of the trill-ECN field, which in turn depends on the trill ingress RBridge having copied the IP-ECN field into the trill-ECN field. However, in a case where the ingress hasn't, the spec says "a transit RBridge "MAY" add a Flags Word itself. But, it would be a layering violation to expect the transit RBridge to look for the IP-ECN field and copy it into the trill-ECN field.

The approach in the spec works for standard ECN [RFC3168], i.e. if a transit RBridge creates a flags Word it just initializes the trill-ECN field to not-ECT. But you're right, this doesn't work for L4S.

I'm not sure how important this is, because no vendor is likely to implement creation of a Flags word by a transit RBridge anyway (which is why the spec says "MAY").

I think the solution could be to extent the "Arriving TRILL 3-bit codepoint name" table with an extra NCCE name mapping from TRILL-ECN=11 and CCE=0. Table 2 needs to have an extra column with rows (not-ECT, ECT(0), CE, CE). This way an L4S transit node can also insert a Flags word and set NCCE with probability p on top of CCE with p^2. I saw no other combinations that could lead to this arriving situation, and could lead to problems, as current ECN capable transit nodes never mark NCCE.
I have checked and this works in all cases.

Even if there is a Flags word, this is better for L4S, because L4S transit RBridges would not need to read the trill-ECN field before marking. So the pseudocode in Appendix A would be simpler, i.e. just:

      % On TRILL transit
      if (p > random() ) {
         mark(NCCE)                     % likelihood: p
         if (p > random() )
            mark(CCE)                   % likelihood: p^2
      }
There is a downside tho: your proposal adds an extra case for the behaviour of all trill egress RBridges.

In summary, the tradeoffs with your proposal are:
* More complex standards track behaviour for all egress RBridges.
* Simpler for transit RBridges to support L4S (which is experimental track)
* Makes it possible for transit RBridges that support L4S to add a Flags Word (but unlikely that vendors will do this anyway)

Another way to solve this problem would be to just say that an L4S transit RBridge:
* MAY create a Flags word, but only if it is willing and able to inspect the inner IP header and copy the IP-ECN field to the trill-ECN field.
* Otherwise it has to use Classic drop for packets without a Flags Word.

One thing your email made me notice: as it stands, the pseudocode in Appendix A ought to include an outer 'if' block that checks for the Flags Word. But let's see what comments there are on the list before deciding between the alternatives, then we can write the appropriate pseudocode.

A typo in section 2: Extesnion should be Extension.
Thanks for this. While re-reading the draft, I also noticed a few editorial improvements, which I will raise with my co-author.

And thanks particularly for pointing out the alternative way of defining the egress behaviour.

Cheers



Bob
Regards,
Koen. 



On 31/05/17 19:48, Susan Hares wrote:
This begins a  2 week WG LC for draft-ietf-trill-ecn-support which can be
found at:
https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/.


The authors (Donald Eastlake and Bob Biscoe) should indicate whether they
know of any IPR relating to this draft.

The TRILL WG should consider the following questions:

1) Does this extension of the ECN to TRILL Switches provide for better
Flow control of IP packets without packet drops?  And is this useful in TRILL
deployments?

2) Do you believe this document is ready for RFC publication?

Please include the answers to these questions among your comments about
this draft.

Sue Hares



_______________________________________________
trill mailing list
mailto:trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


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

--------------C4FC39C8CC18126BFFA572B5-- From nobody Wed Jun 14 10:31:28 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C331200FC; Wed, 14 Jun 2017 10:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 EtRF2dLVX8Uk; Wed, 14 Jun 2017 10:31:25 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 DF905128AB0; Wed, 14 Jun 2017 10:31:21 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id 77so10134745wrb.1; Wed, 14 Jun 2017 10:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=abIHy1OuLrlxdDULDD7OGFyj93TvDGhLoc+Dx7ODeD0=; b=agK9zAdrN1VD7zTAQ1FRMCLHZeIkwR4enKWGlnQBkbMclvnYXazim5myHLYK6ldOce z+Jmn8wXSNlF8Kdl2xiJy7UFiSRnG1a35f0jBSA9w3aTXlDmmYegn4YV8EHQKkNC21yD AbLXZ3N7WUAfY+x7QVrG4DlYdQUyweWw4RTLgQrzS9AgK6KherHGtWKMgvQq2Mr8FIzC QM2Lb8nFSelwdKkwBhsKLHTsu+fj1BKOskhITVQ5vfJAHMfTXXRq4eEH+oJgki5QO4MM daswlrD+NO1brXQ9l4Ocd3KvWeQsv8AImMAoQ8JPnAUeAgB33oQpk1G36DdyXo6paAtE bZAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=abIHy1OuLrlxdDULDD7OGFyj93TvDGhLoc+Dx7ODeD0=; b=Yj21Pw9LVOOcG4eJoNa9xgbxWauJ0x/gplKi65NoPA2sA5f/B9pARIlgyUZn1G1ZPR S+keO6QFVsIJpZvakshO4atHzX7tNlmQ27d7tEp1MWWZOHSimuFOi0pADv+nWptvO/Tt w+xc/+TQPF40YpUqBhUS+XcB6FhsNP66XFf/uN3BhQ9hCtcnjLSCeTIAr1TJmCvmiLkm CRMiEg90IDXuHAWBnE4Z27KWb8Ay/kaeRikEjuOxKzHeKtbaKy66DurFSkCu8BuCa0FV s5CJHShQ1F5BNdrqmwAiNpSDSyP3n0LA2efEDCwCj0DFy7ABY3Y+hxKx0nBsH2N0OAt5 6GDw== X-Gm-Message-State: AKS2vOyzA0KuPSPVUrzffMJlg4jL5IBr9lMrEnmVgbOFaGFPjvSazAqb hGG8d7o2oz03ihH8gYljnzp/DbiR4ylH X-Received: by 10.223.133.167 with SMTP id 36mr894016wrt.86.1497461480258; Wed, 14 Jun 2017 10:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.131.66 with HTTP; Wed, 14 Jun 2017 10:31:19 -0700 (PDT) From: Alia Atlas Date: Wed, 14 Jun 2017 13:31:19 -0400 Message-ID: To: trill@ietf.org, draft-ietf-trill-mtu-negotiation@ietf.org Content-Type: multipart/alternative; boundary="001a1147f6d09885c70551eeeb68" Archived-At: Subject: [trill] progressing draft-ietf-trill-mtu-negotiation X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 17:31:27 -0000 --001a1147f6d09885c70551eeeb68 Content-Type: text/plain; charset="UTF-8" First, I would like to thank the authors - Mingui, Zudong, Donald, Radia, and Somnath - for their work on this document. As is customary, I have done my AD review. For this draft, I have found no issues. I have requested IETF Last Call and scheduled the document for the IESG telechat on July 6. Regards, Alia --001a1147f6d09885c70551eeeb68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
First, I would like to thank the authors - Mingui, Zudong,= Donald, Radia, and Somnath - for their work on this document.

As is customary, I have done my AD review. For this draft, I have fo= und no issues. I have requested IETF Last Call and scheduled the document f= or the IESG telechat on July 6.

Regards,
Alia
--001a1147f6d09885c70551eeeb68-- From nobody Wed Jun 14 10:55:14 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A221201F2; Wed, 14 Jun 2017 10:55:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk CC: shares@ndzh.com, draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, trill@ietf.org, akatlas@gmail.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149746291282.13963.710359692852568435.idtracker@ietfa.amsl.com> Date: Wed, 14 Jun 2017 10:55:12 -0700 Archived-At: Subject: [trill] Last Call: (Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation) to Proposed Standard X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 17:55:13 -0000 The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The base IETF TRILL protocol has a TRILL campus-wide MTU feature, specified in RFC 6325 and RFC 7177, that assures that link state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFC 6325, updates RFC 7177, and updates RFC 7780. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1799/ From nobody Wed Jun 14 12:41:01 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05F1129562; Wed, 14 Jun 2017 12:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 d-Ma76jDMUIX; Wed, 14 Jun 2017 12:40:57 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1CF12EB24; Wed, 14 Jun 2017 12:40:56 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id r103so12467162wrb.0; Wed, 14 Jun 2017 12:40:56 -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=Uj1dZrkukjrjCM10bIyY+QHKvmeHIa1iTAHeg4RgCoY=; b=dCreLexKKSa+0YCQZuNMskx+nk43X44QFgrR8QuyyQoOEloqmrg4jT5etRiYZQehAj AGCM7X32EAP08BeEpdHOhjBGAlR3BugwV3izNwxTJIlC9NFTd7fWm9BP7wbIt+W1NkvT H8KWfU5Fa4jZxpJH0shXXbNnZJJLY67ciwpwo3aywEuOP2kXaEAhsoV9/xe4aXVYFNgM +2uBw3Xe0fho2tP4bSK2YxGzUc5ukjd76J1k/nBxG965ABnw/oxb7vepTkGydL9S9vTD SmFeBworBG3B4M5UT9XeVR3+uxV4D/f8cgydyu3Sovw64K60G+ItU6BjnWj+7Ei4DTju E88Q== 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=Uj1dZrkukjrjCM10bIyY+QHKvmeHIa1iTAHeg4RgCoY=; b=dDnuAKcH5xBykx9MUqrKwDykji0VMjYFa/iKw2as6F4tuuKFyPOEkG0DQ2yglNPiQO bBywS99D6nq1L8MJ38tW88etRabfu+ji+Xr8LPc4phaYksX/LrrJvZRrCMeTnBeqQ01L Pd/UVUV73VT+L2SNunZMv2Y6SzPq2L4lyWHSlaoXeS68BsJLNTZHWiWh+dStrhpRQBDg pZWN7u0mYVTZKBz/C3on8V8X+fOM40Z/8iI7Ri8fOtMwE4k0phAR2zQvAcdSh33YMy1f aO9wX0v2nkFN/kyrEvHy5uDo1e09Wz+lq/JZ3ouAxMQGNzVjtuTR4g6dAzoP2B295am5 19SQ== X-Gm-Message-State: AKS2vOxLO+c6W86DSlOuC/iVTXIG5xQeVxNBmBV2vpxJ6veefe6/u/Xb okv3471M/dylq4Dy4eSYCKTXaFjDnPIX/+8= X-Received: by 10.28.63.209 with SMTP id m200mr1081442wma.40.1497469255197; Wed, 14 Jun 2017 12:40:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.131.66 with HTTP; Wed, 14 Jun 2017 12:40:54 -0700 (PDT) In-Reply-To: References: From: Alia Atlas Date: Wed, 14 Jun 2017 15:40:54 -0400 Message-ID: To: Donald Eastlake Cc: "trill@ietf.org" , draft-ietf-trill-rbridge-multilevel@ietf.org Content-Type: multipart/alternative; boundary="001a114b2fc004ab700551f0bb53" Archived-At: Subject: Re: [trill] AD review of draft-ietf-trill-rbridge-multilevel-04 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 19:41:00 -0000 --001a114b2fc004ab700551f0bb53 Content-Type: text/plain; charset="UTF-8" I have done another AD review of the updated version, draft-ietf-trill-rbridge-multilevel-04. In general, it is much better. I would have preferred to see more operational considerations around transitioning from a single area to a multi-level domain, but at least some concerns are sprinkled in. I'm going to request IETF Last Call on this and target it for the telechat on July 6. Nits: a) Sec 6:"The problem is not avoiding adjacency of avoiding TRILL Data packet transfer between RB1 and RB2." s/of/or b) Sec 6: "The problem stems from end stations being TRILL ignorant so care must be taken that multiple RBridges on a link do not ingress the same frame originated by an end station and so that an RBridge does not ingress a native frame egressed by a different RBridge because it mistakes if for a frame originated by an end station." s/it/the RBridge s/if/the frame c) Sec 6: "if a TRILL switch seems Hellos from lower numbered areas" s/seems/sees Regards, Alia On Mon, Dec 26, 2016 at 5:04 PM, Donald Eastlake wrote: > Hi Alia, > > Thanks for your comments. > > On Tue, Dec 20, 2016 at 7:06 PM, Alia Atlas wrote: > > As is customary, I have done my AD review of > > draft-ietf-trill-rbridge-multilevel-04. First, I would like to > > thank the authors - Radia, Donald, Mingui, Anoop, and Hongjun - for > > their work on this document. > > (The initial author of the draft was Radia and I think the first > version was roughly contemporaneous with the following presentation: > https://www.ietf.org/proceedings/80/slides/trill-4.pdf) > > > From my review, I do have a few high level concerns. In particular, > > this document has the job of guiding future WG work and setting out > > some high-level decisions for the architecture of multi-level TRILL. > > Well, I can imagine a range of Informational documents which, at one > extreme were an abstract exploration of possibilities with pros and > cons for each and having no directive content. At the other extreme > would perhaps be a "framework" document that tightly bounded > subsequent protocol specifications deciding most significant design > issues. This draft started out closer to the abstract end and has > varied some in different version as to how directive it is. The draft > is called "Alternatives..." and does not have "Architecture" or > "Framework" in its title. > > > Unfortunately, there are several areas where the draft isn't willing > > to commit to specific guidance or pick one alternative. If there > > had been vigorous discussion and debate on this, I might have more > > confidence that there are strong reasons that truly justify the > > multiplication of complexity represented in this document. I don't > > see any of that on the list. > > By listing a number of alternatives, the document is not meant to > imply that any significant number of them are to be further specified. > One advantage of documenting a variety of alternatives is to provide > prior art in case of subsequent IPR problems. As far as I can tell, > the WG is only interested in defining one very specific way to do > unique nicknames and one very specific way to do aggregated > nicknames. The current state of these are documented in > draft-ietf-trill-multilevel-unique-nickname and > draft-ietf-trill-multilevel-single-nickname. The "single-nickname" > draft specified an aggregated nickname scheme. > > > I will require an updated draft and discussion before progressing this > > document. > > OK. > > > Major: > > > > a) Sec 2.2.2.2: Unless I'm missing something - this is proposing > > changing the format of the basic TRILL header to accommodate > > multi-level IS-IS, which would impact all hardware implementations > > of TRILL deployed everywhere. The idea of allowing both options > > just makes for yet more complexity, options, and challenges in > > interoperability & troubleshooting! Please don't invent complexity. > > I don't see any discussion on the mailing list around this point and > > the document doesn't emphasize that this is an extremely bad option > > - done to trade-off complexity & storage at the border switches. > > This is definitely an area where operators and vendors need to weigh > > in and silence cannot imply consensus. > > The only path the WG is pursuing for aggregated nicknames does not use > the "swap nickname" method discussed in 2.2.2.2, which is just being > listed as an "alternative". I don't see any problem including your > negative points of this alternative in the draft. > > > b) Sec 7: I would strongly prefer to see a clear trade-off described > > in terms of hardware impact as well as how flag-days for software > > could be avoided. I'm not seeing any considerations given to > > upgrading. I also am not excited that the WG isn't willing to pick > > one approach to go forward with. Multiple approaches mean at least > > twice the pain for implementing, testing, troubleshooting, learning > > the technology, and so on. > > Many upgrading and backward compatibility considerations are > considered throughout the much. I think Section 7 could be improved > along the lines you suggest. > > > c) I expect some section of management/operational considerations > > for how different choices impact the ability to transition from a > > single area to a multi-area solution. > > OK. > > > Minor: > > > > 1) Sec 1.1 item 5: Is the concern about the 16-bit nickname limit > > for trill switches based on the likelihood of collision from picking > > nicknames? I have a hard time picturing a network with over 65,500 > > trill switches and distribution trees that doesn't run into many > > other issues. Please clarify the details of this concern in the > > document. > > The list in Section 1.1 is meant to be a exhaustive list of potential > scaling problems. While I wouldn't think that a single level IS-IS > routed area would be particularly practical with several tens of > thousands of routers, whether they are TRILL switches or some other > kind, it seems to me that with multi-level you might some day have 200 > areas with 500 routers per area, which would required 100,000 > nicknames if they must all be unique. That would be problematic with > 16-bit nicknames and people may be reluctant to adopt technology if > they can foresee limits, even if those limits are pretty far away. > > Furthermore, nicknames are consumed when pseudo-nicknames are used for > the active-active connection of end stations. Using RFC 7781 could, > for example, double the nicknames consumption if there are extensive > active-active edge groups connected to different sets of edge TRILL > switch ports. > > In addition, there might be problems, as suggested in the draft, with > TRILL switches inside a possibly very large number of level 1 areas > all contending campus wide for nicknames -- so you would likely use > some sort of hierarchical method, for example level 1 areas contending > in level 2 for blocks of nicknames and then TRILL switches inside a > level 1 area contending within that area for nicknames within the > block(s) obtained by that area. Of course such hierarchical allocation > leads to further effective loss of nicknames. (RFC 3194) > > So, my opinion is that, overall, it is reasonable to keep the 16-bit > nickname limit in mind and have a solution available that effectively > eliminates that limit. > > > 2) Sec 6: The simple option of having topology constraints to avoid > > having multiple trill switches in different areas connected to the > > same link doesn't seem to have been considered. Please add and > > clarify why a topology constraint is or isn't acceptable > > operationally. As you well know, simplification and ease of > > interoperability are critical criteria for evaluating the options. > > This section can be clarified. > > This section is about end station's logical connectivity to edge TRILL > switches. Multiple topologies could possibly be used to constrain the > logical connectivity between such edge TRILL switches that are > physically connected via a link (TRILL considers a bridged LAN to be a > single link). But end stations don't know anything about TRILL or > IS-IS Areas or multiple topologies. So I don't see how to use > topologies (or areas) to stop an end station from having connectivity > to all edge TRILL switches on the link. > > The problem being discussed in Section 6 is that a frame (particularly > a multi-destination frame, say a broadcast frame) sent by an end > station could be seen by multiple TRILL edge switches even if those > edge switches are in different IS-IS areas and thus multiple copies > could be ingressed by the TRILL campus. A similar problem, causing > looping, might occur if a native frame is egressed by an edge TRILL > switch. On egress the TRILL Header is stripped and the resulting > native frame is appropriate for receipt by an end station. Such a > frame might, if no precautions are taken, be ingressed by one or more > TRILL edge switches in different IS-IS areas. (Existing TRILL takes > care of the case of multiple edge TRILL switch ports on a link with > end stations when those edge TRILL switches can all see each other, as > they would automatically if they are in the same Area/topology, by the > Appointed Forwarder mechanism.) > > I suppose you could tell network managers that if a link has one or > more end stations on it, then all TRILL switch ports on the link must > be in the same IS-IS area, but that seems pretty brittle. TRILL's > design philosophy is to try to protect against accidental > misconfigurations. I also do not think it is desireable to say that > if you want to use multi-level safely, you have to use and configure > multi-topology. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > Regards, > > Alia > --001a114b2fc004ab700551f0bb53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have done another AD review of the updated version,= draft-ietf-trill-rbridge-multilevel-04.

In genera= l, it is much better.=C2=A0 I would have preferred to see more operational = considerations around
transitioning from a single area to a multi= -level domain, but at least some concerns are sprinkled in.

<= /div>
I'm going to request IETF Last Call on this and target it for= the telechat on July 6.

Nits:

a) Se= c 6:"The problem is not avoiding adjacency of avoiding TRILL Data pack= et=C2=A0transfer between RB1 and RB2." =C2=A0 s/of/or
b) Sec 6: "The problem stems from end stations being TRIL= L ignorant so
=C2=A0 =C2=A0care must be taken that multiple RBridges on = a link do not ingress
=C2=A0 =C2=A0the same frame originated by an end s= tation and so that an RBridge
=C2=A0 =C2=A0does not ingress a native fra= me egressed by a different RBridge
=C2=A0 =C2=A0because it mistakes if f= or a frame originated by an end station."
=C2=A0 =C2=A0s/it/the RBri= dge =C2=A0 =C2=A0s/if/the frame

c) Sec 6:=C2=A0&qu= ot;if a TRILL switch seems Hellos=C2=A0from lower numbered areas"
=C2=A0 s/seems/sees

Regards,
Alia<= /div>

On Mon= , Dec 26, 2016 at 5:04 PM, Donald Eastlake <d3e3e3@gmail.com>= wrote:
Hi Alia,

Thanks for your comments.

On Tue, Dec 20, 2016 at 7:06 PM, Alia Atlas <akatlas@gmail.com> wrote:
> As is customary, I have done my AD review of
> draft-ietf-trill-rbridge-multilevel-04.=C2=A0 First, I would like= to
> thank the authors - Radia, Donald, Mingui, Anoop, and Hongjun - for > their work on this document.

(The initial author of the draft was Radia and I think the first
version was roughly contemporaneous with the following presentation:
https://www.ietf.org/proceedings/80/slide= s/trill-4.pdf)

> From my review, I do have a few high level concerns.=C2=A0 In particul= ar,
> this document has the job of guiding future WG work and setting out > some high-level decisions for the architecture of multi-level TRILL.
Well, I can imagine a range of Informational documents which, at one=
extreme were an abstract exploration of possibilities with pros and
cons for each and having no directive content. At the other extreme
would perhaps be a "framework" document that tightly bounded
subsequent protocol specifications deciding most significant design
issues.=C2=A0 This draft started out closer to the abstract end and has
varied some in different version as to how directive it is. The draft
is called "Alternatives..." and does not have "Architecture&= quot; or
"Framework" in its title.

> Unfortunately, there are several areas where the draft isn't willi= ng
> to commit to specific guidance or pick one alternative.=C2=A0 If there=
> had been vigorous discussion and debate on this, I might have more
> confidence that there are strong reasons that truly justify the
> multiplication of complexity represented in this document.=C2=A0 I don= 't
> see any of that on the list.

By listing a number of alternatives, the document is not meant to imply that any significant number of them are to be further specified.
One advantage of documenting a variety of alternatives is to provide
prior art in case of subsequent IPR problems.=C2=A0 As far as I can tell, the WG is only interested in defining one very specific way to do
unique nicknames and one very specific way to do aggregated
nicknames. The current state of these are documented in
draft-ietf-trill-multilevel-unique-nickname and
draft-ietf-trill-multilevel-single-nickname.=C2=A0 The "single-ni= ckname"
draft specified an aggregated nickname scheme.

> I will require an updated draft and discussion before progressing this=
> document.

OK.

> Major:
>
> a) Sec 2.2.2.2: Unless I'm missing something - this is proposing
> changing the format of the basic TRILL header to accommodate
> multi-level IS-IS, which would impact all hardware implementations
> of TRILL deployed everywhere.=C2=A0 The idea of allowing both options<= br> > just makes for yet more complexity, options, and challenges in
> interoperability & troubleshooting!=C2=A0 Please don't invent = complexity.
> I don't see any discussion on the mailing list around this point a= nd
> the document doesn't emphasize that this is an extremely bad optio= n
> - done to trade-off complexity & storage at the border switches. > This is definitely an area where operators and vendors need to weigh > in and silence cannot imply consensus.

The only path the WG is pursuing for aggregated nicknames does not u= se
the "swap nickname" method discussed in 2.2.2.2, which is just be= ing
listed as an "alternative". I don't see any problem including= your
negative points of this alternative in the draft.

> b) Sec 7: I would strongly prefer to see a clear trade-off described > in terms of hardware impact as well as how flag-days for software
> could be avoided.=C2=A0 I'm not seeing any considerations given to=
> upgrading.=C2=A0 I also am not excited that the WG isn't willing t= o pick
> one approach to go forward with.=C2=A0 Multiple approaches mean at lea= st
> twice the pain for implementing, testing, troubleshooting, learning > the technology, and so on.

Many upgrading and backward compatibility considerations are
considered throughout the much. I think Section 7 could be improved
along the lines you suggest.

> c) I expect some section of management/operational considerations
> for how different choices impact the ability to transition from a
> single area to a multi-area solution.

OK.

> Minor:
>
> 1) Sec 1.1 item 5: Is the concern about the 16-bit nickname limit
> for trill switches based on the likelihood of collision from picking > nicknames?=C2=A0 I have a hard time picturing a network with over 65,5= 00
> trill switches and distribution trees that doesn't run into many > other issues.=C2=A0 Please clarify the details of this concern in the<= br> > document.

The list in Section 1.1 is meant to be a exhaustive list of potentia= l
scaling problems.=C2=A0 While I wouldn't think that a single level IS-I= S
routed area would be particularly practical with several tens of
thousands of routers, whether they are TRILL switches or some other
kind, it seems to me that with multi-level you might some day have 200
areas with 500 routers per area, which would required 100,000
nicknames if they must all be unique. That would be problematic with
16-bit nicknames and people may be reluctant to adopt technology if
they can foresee limits, even if those limits are pretty far away.

Furthermore, nicknames are consumed when pseudo-nicknames are used for
the active-active connection of end stations.=C2=A0 Using RFC 7781 could, for example, double the nicknames consumption if there are extensive
active-active edge groups connected to different sets of edge TRILL
switch ports.

In addition, there might be problems, as suggested in the draft, with
TRILL switches inside a possibly very large number of level 1 areas
all contending campus wide for nicknames -- so you would likely use
some sort of hierarchical method, for example level 1 areas contending
in level 2 for blocks of nicknames and then TRILL switches inside a
level 1 area contending within that area for nicknames within the
block(s) obtained by that area. Of course such hierarchical allocation
leads to further effective loss of nicknames. (RFC 3194)

So, my opinion is that, overall, it is reasonable to keep the 16-bit
nickname limit in mind and have a solution available that effectively
eliminates that limit.

> 2) Sec 6: The simple option of having topology constraints to avoid > having multiple trill switches in different areas connected to the
> same link doesn't seem to have been considered.=C2=A0 Please add a= nd
> clarify why a topology constraint is or isn't acceptable
> operationally.=C2=A0 As you well know, simplification and ease of
> interoperability are critical criteria for evaluating the options.

This section can be clarified.

This section is about end station's logical connectivity to edge TRILL<= br> switches.=C2=A0 Multiple topologies could possibly be used to constrain the=
logical connectivity between such edge TRILL switches that are
physically connected via a link (TRILL considers a bridged LAN to be a
single link). But end stations don't know anything about TRILL or
IS-IS Areas or multiple topologies. So I don't see how to use
topologies (or areas) to stop an end station from having connectivity
to all edge TRILL switches on the link.

The problem being discussed in Section 6 is that a frame (particularly
a multi-destination frame, say a broadcast frame) sent by an end
station could be seen by multiple TRILL edge switches even if those
edge switches are in different IS-IS areas and thus multiple copies
could be ingressed by the TRILL campus. A similar problem, causing
looping, might occur if a native frame is egressed by an edge TRILL
switch. On egress the TRILL Header is stripped and the resulting
native frame is appropriate for receipt by an end station.=C2=A0 Such a
frame might, if no precautions are taken, be ingressed by one or more
TRILL edge switches in different IS-IS areas.=C2=A0 (Existing TRILL takes care of the case of multiple edge TRILL switch ports on a link with
end stations when those edge TRILL switches can all see each other, as
they would automatically if they are in the same Area/topology, by the
Appointed Forwarder mechanism.)

I suppose you could tell network managers that if a link has one or
more end stations on it, then all TRILL switch ports on the link must
be in the same IS-IS area, but that seems pretty brittle. TRILL's
design philosophy is to try to protect against accidental
misconfigurations.=C2=A0 I also do not think it is desireable to say that if you want to use multi-level safely, you have to use and configure
multi-topology.

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
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

> Regards,
> Alia

--001a114b2fc004ab700551f0bb53-- From nobody Wed Jun 14 13:52:39 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2889312943D; Wed, 14 Jun 2017 13:52:38 -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 E3wHuN7_Rs-w; Wed, 14 Jun 2017 13:52:36 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1469E126CC4; Wed, 14 Jun 2017 13:52:33 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id r103so14872726wrb.0; Wed, 14 Jun 2017 13:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=36iIzwArJnsEq7rkVVuQh7sU3M3G6qFCR6yjHWc6Y7Y=; b=YVYhP4Y4RCt2dMR3mfUqlfuLvRWn6gkcAeg0AkxIaTApxP5P5F/T5ciOPvGQAzUN1s tCSi654vabgX2qzt17x+bN0OttnrwgFZJiWq7Cxh7ggSIqrkV0SGPAqcB5rzqYTs4Raj Ga99KfZzuCjf1Vmc/0OFafXAZeVCiJoDteEKBIo5aZpUxLi1dxR+LLDOgCdrDuaP5JCO SVLNvuktH0tRpqbj0dxuV5KUjvKwIEq5DUzf+T5gcXL2VNRQAJjCWZNXQ0JB5wAQ8MB/ tnOkPy8nwEbF08d24n1DPKD0cPgrkFMTfTtE/PbAWQpNdlC4Zr1k0ND+3VdeBjjZ0yCd Xf5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=36iIzwArJnsEq7rkVVuQh7sU3M3G6qFCR6yjHWc6Y7Y=; b=n3qAdt/rnA0ieqWlzyykcHxeIZyYW8bjNMrWleimEc0V1Jn5y0j3N9EGahn9/cHWll ysklsLJwx0MKnsYuoWhJVxVo69f/mFQsBmGoZoBhg1VGa0PsW83MFzATgxx1/m/epAZ3 XMBfDldblb0dbxtvLuTe9vZjVkQnn7EpE+yOJg5dk5Bd4uK0zTZ3hPrlxhEbB54/4eOl cJBA+S8yUfSYY7po9BvzlUH1IRsT6ha6Aop69KlttWN9uQUtot4CzIbO+kc9B8UwmM3p KXTAGcOUiAiBRbmjbbMvXvXO35T7FtXAjwsfIT5vfWyY4rAb3595/V/k9Zh3WuiQ6nHb k9GQ== X-Gm-Message-State: AKS2vOyp3Rmz1ZuLbRQqP/t/o5DCuth1fpOKEt5aJqBh/wZDnU5oHHu1 F2VDtlOplh7JyTaLWE7SAJWSq08n555P/UI= X-Received: by 10.28.208.207 with SMTP id h198mr1273740wmg.40.1497473551294; Wed, 14 Jun 2017 13:52:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.131.66 with HTTP; Wed, 14 Jun 2017 13:52:30 -0700 (PDT) From: Alia Atlas Date: Wed, 14 Jun 2017 16:52:30 -0400 Message-ID: To: trill@ietf.org, draft-ietf-trill-centralized-replication@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19319815e6b80551f1bbc1" Archived-At: Subject: [trill] AD review of draft-ietf-trill-centralized-replication-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 20:52:38 -0000 --94eb2c19319815e6b80551f1bbc1 Content-Type: text/plain; charset="UTF-8" As is customary, I have done my AD review of draft-ietf-trill-centralized-replication-08. First, I would like to thank the authors - Weiguo Hao, Yizhou Li, Muhammad Durrani, Sujay Gupta, and Andrew Qu - for their work on this document. I do have a few concerns that need to be addressed before the document can proceed to IETF Last Call. If the authors can address them very rapidly (this week), then I have time for an IETF Last Call and putting the draft on the IESG Telechat of July 6. 1) In Sec 3, it says"In this case, the RPF calculation on each RBridge should use the centralized node as the ingress RBridge instead of the real ingress virtual RBridge to perform the calculation." In Sec 7, it says"The egress nickname in the multi-destination TRILL Header is the nick5 and the ingress nickname is still P-nick." >From scanning RFC6325, I am reminded that the egress nickname indicates the destination tree. I don't see clearly specified here how the RBridge determines which RPF calculation to use for a particular frame.... In Sec 11,"A C-nickname is a specialized pseudo-nickname for which transit RBridges perform a different RPF check algorithm for TRILL data packets with the C-nickname in the ingress nickname field." If I follow the logic here, an RBridge is intended to install a different RPF interface-set for each C-nickname - but what that RPF interface-set is will also be dependent upon the egress nickname specified?? Does this turn the look-up from a simple ingress nickname (16 bit) to interface-set into a something more complicated? I guess it could be a recursive lookup, where if the ingress nickname is a C-nickname, then the RPF interface-set is looked up again from the egress name instead? If I am correct, then this is a definite change in fast-path forwarding behavior and should be described extremely clearly - which it is not. I don't think that Sec 8 helps in guessing which distribution tree will be used. 2) In Sec 10:"In this case, an edge group using CMT [RFC7783] MUST NOT set the C- nickname flag on the pseudo-nickname it is using." Given that an implementation support RFC7783 may not support this document, please clarify in the document how it is that an implementation conformant to RFC7783 is guaranteed to not set the C-nickname flag. 3) Sec 11:" When active-active edge RBridges use centralized replication to nickname and the C-nickname is used as ingress nickname in the TRILL header for the unicast TRILL encapsulation of BUM traffic." I have no idea what this sentence fragment means. 4) Sec 12: There is a claim of no new security concerns, but this basically gives a device the ability to advertise an R-nickname and get all/some of the BUM traffic unicast to it - where that device could modify, block, or respond to the BUM traffic and the rest of the campus - except for the local neighbors of ingress RBridge would have no idea this was happening! I think that some discussion of exactly what security mechanisms for IS-IS ensure that a device injecting an R-nickname is trusted would be helpful as well as articulating the potential impact. Regards, Alia --94eb2c19319815e6b80551f1bbc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As is customary, I have done my AD review of=C2=A0dra= ft-ietf-trill-centralized-replication-08. First, I would like to thank the = authors -=C2=A0Weiguo Hao, Yizhou Li, Muhammad Durrani, Sujay Gupta, and An= drew Qu - for their work on this document.

I do ha= ve a few concerns that need to be addressed before the document can proceed= to IETF Last Call.=C2=A0 If the authors can address them very rapidly (thi= s week), then I have time for an IETF Last Call and putting the draft on th= e IESG Telechat of July 6.


1) In Se= c 3, it says"In this case, the RPF calculation on each RBridge should = use the centralized node as the=C2=A0ingress RBridge instead of the real in= gress virtual RBridge to perform the calculation."
In Se= c 7, it says"The egress nickname in the multi-destination TRILL=C2=A0H= eader is the nick5 and the ingress nickname is still P-nick."

From scanning RFC6325, I am reminded that the egress n= ickname indicates the destination tree. =C2=A0 I don't see clearly spec= ified here how the RBridge determines which RPF calculation to use for a pa= rticular frame.... =C2=A0

In Sec 11,"A C-nick= name is a=C2=A0specialized pseudo-nickname for which transit RBridges perfo= rm a=C2=A0different RPF check algorithm for TRILL data packets with the C-n= ickname in the ingress nickname field."

If I = follow the logic here, an RBridge is intended to install a different RPF in= terface-set for each C-nickname - but what that RPF interface-set is will a= lso be dependent upon the egress nickname specified?? =C2=A0 =C2=A0 Does th= is turn the look-up from a simple ingress nickname (16 bit) to interface-se= t into a something more complicated? =C2=A0
I guess it could be a= recursive lookup, where if the ingress nickname is a C-nickname, then the = RPF interface-set is looked up again from the egress name instead?=C2=A0

If I am correct, then this is a definite change in f= ast-path forwarding behavior and should be described extremely clearly - wh= ich it is not.

I don't think that Sec 8 helps = in guessing which distribution tree will be used.

= 2) In Sec 10:"In this case, an edge group using CMT [RFC7783] MUST NOT= set the C-
=C2=A0 =C2=A0nickname flag on the pseudo-nickname it is usin= g."=C2=A0
Given that an implementation support RFC7783 m= ay not support this document, please
clarify in the document how = it is that an implementation conformant to RFC7783 is guaranteed to not set= the C-nickname flag.

3) Sec 11:" When active= -active edge RBridges use centralized replication to
=C2=A0 =C2=A0nickna= me and the C-nickname is used as ingress nickname in the TRILL
=C2=A0 = =C2=A0header for the unicast TRILL encapsulation of BUM traffic."
<= /div>

I have no idea what this sentence fragment means.<= /div>

4) Sec 12: There is a claim of no new security con= cerns, but this basically gives a device the ability to advertise an R-nick= name and get all/some of the BUM traffic unicast to it - where that device = could modify, block, or respond to the BUM traffic and the rest of the camp= us - except for the local neighbors of ingress RBridge would have no idea t= his was happening! =C2=A0 I think that some discussion of exactly what secu= rity mechanisms for IS-IS ensure that a device injecting an R-nickname is t= rusted would be helpful as well as articulating the potential impact.
=

=C2=A0Regards,
Alia
--94eb2c19319815e6b80551f1bbc1-- From nobody Wed Jun 14 14:42:24 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8EF1243F3; Wed, 14 Jun 2017 14:42:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk CC: shares@ndzh.com, trill-chairs@ietf.org, trill@ietf.org, draft-ietf-trill-rbridge-multilevel@ietf.org, akatlas@gmail.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149747653603.14024.7165373679028041136.idtracker@ietfa.amsl.com> Date: Wed, 14 Jun 2017 14:42:16 -0700 Archived-At: Subject: [trill] Last Call: (Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links)) to Informational RFC X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 21:42:16 -0000 The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network or can they merely be unique within each multilevel area? This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability and makes recommendations in some cases. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1579/ https://datatracker.ietf.org/ipr/1813/ From nobody Thu Jun 15 10:32:37 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA11293D8; Thu, 15 Jun 2017 10:32:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund To: Cc: trill@ietf.org, ietf@ietf.org, draft-ietf-trill-over-ip.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149754795560.13109.17521244075940607817@ietfa.amsl.com> Date: Thu, 15 Jun 2017 10:32:35 -0700 Archived-At: Subject: [trill] Tsvart early review of draft-ietf-trill-over-ip-10 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 17:32:36 -0000 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 significant 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 specifications. 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. Diffserv usage -------------- Section 4.3: TRILL over IP implementations MUST support setting the DSCP value in the outer IP Header of TRILL packets they send by mapping the TRILL priority and DEI to the DSCP. They MAY support, for a TRILL Data packet where the native frame payload is an IP packet, mapping the DSCP in this inner IP packet to the outer IP Header with the default 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 discussion of the potential issues with actually setting the DSCP values. It is one thing to do this in an IP back bone use case where one can know and have control 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 policers or remapping. Also as the actual DSCP code point usage is domain specific this is difficult. Priority reversal is likely the least of the problems that this can run into over general Internet. 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 networks this can also results in strange remapping that results in a different PHB for CS1 than. MTU and Fragmentation --------------------- I think there are two main issue here. The first one is MTUD discovery 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 requries 1470 byte support which is likey above a lot of paths. Section 8.4: Path MTU discovery [RFC4821] should be useful in determining the IP MTU between a pair of RBridge ports with IP connectivity. The issue with RFC4821 is that it has requirements on the packetization 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. 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? 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 below 1470. If I am wrong good, but I think this is an important piece for how to handle the next main issue. UDP encapsulation and IP fragments. I see it as a big issue that UDP encapsulation is the native one, and that relies on IP fragmentation despite the need for reliable fragmentation. 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 problem 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 to not get IP fragements 2. Determine MTU and implement an fragmentation mechanism on top of UDP. Zero Checksum: -------------- Section 5.4: UDP Checksum - as specified in [RFC0768] Considering the fast path encapsulation desire, I am surprised to not 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 apply 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 applicability 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 done. TCP Encapsulation issue ----------------------- Section 5.6: The TCP encapsulation appear to be missing an delimiter format allowing each individual TRILL packet/payload to be read out of the TCP's byte stream. In other words, a normal implementation has no way of ensuring that the TCP payload starts with the start of a new TRILL payload. Multiple small TRILL payloads may be included in the same TCP payload, and also only parts 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 length field for the TRILL payload to be encapsulated. 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 sizes in relation to Bandwidth delay products, as buffer memory in a RBridge will impact performance. Congestion Control ------------------ First thanks for the effort here. 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, specific congestion control mechanisms are commonly needed. However, if the traffic being carried by the TRILL over IP link is already congestion controlled and the size and volatility of the TRILL IS-IS link state 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 anyway of knowing which traffic is actually congestion controlled, considering that TRILL provides an layer 2 abstraction. I wonder if there should be any type of white 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 any recommendation to prevent traffic that is not controlled to be forwarded, can lead to congestion issues. The other issue I think may exist is the issue serial unicast emulation of broadcast/multicast creates. As this amplifies the outgoing packet rate with a factor of how many addresses are configured for serial unicast this can be significant traffic expansion. Thus, I think additional considerations are needed here, and maybe rate limiting of the amount of traffic to be multicasted. 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. If I understand this correctly, the idea here is to look into the inner layer 2 frames, and use the flow equivalents that exists on that level and hash that into value that maps the flows onto the source port range. I think this text should include a summary of the principle and ensure 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. 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 static binding configurations or the need for determining ones external address(es) and be able to communicate that to the peer RBridges, and in addition ensure that one has keep-alives to that the NAT binding never times out. 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. 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). Note 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 bytes MTU Ethernet infrastructure. I would note that also firewalls likely have issues with IP fragments for the same reason, they require significant amount of state to be verified if they should be let through. In general I think you should create a configuration that has chance to work through most middleboxes, but I think you should require static bindings. 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. Cheers Magnus Westerlund From nobody Thu Jun 15 12:18:24 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71B127866; Thu, 15 Jun 2017 12:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 DNawt8VJOYdG; Thu, 15 Jun 2017 12:18:21 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c: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 D498B127078; Thu, 15 Jun 2017 12:18:17 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id d73so7178400wma.0; Thu, 15 Jun 2017 12:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Mf24AS8v2rFNhxOYl2otxyc5a/wgTNbUeWSas1JhAKc=; b=tgism3InqoFVx51kfeeeKfE8ukQcXynAWg9QPJyA24kUjcXqRLCkNk3d3R34owUiq+ PMysmtUA7tgbxjnWBDbNs4Tmqwn02k618Uk7L2o97HxT7faH87v3nYlk3MiqhKuxjV9V 8ZtFxgvrSJy22I44zkJ4frDSlahqUW4sAfGvUsDyONB1HF6g9ES1b6D1yAmyQouuJbaw P5qIgGDJicNAVUrtJ29eLZ++hwgRM/GrGsb/A/NoGPPUS+is9Umm40iZdmAG2OucB+lX GlTR/PmCsfEG7Z9UiW7d+dZ7+QUPw2A/fVMTTiVAoVLCfOD/sdQ4BtMSILEriHKZ6Lj4 q5WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Mf24AS8v2rFNhxOYl2otxyc5a/wgTNbUeWSas1JhAKc=; b=iRRkEbsJfC9Rqu7NHZdiMOx1N6hBqLz8bfPnugs7R3OFaqgAvp2vujao/XgyL1CyG5 Ofwo2lJWHYYkXxV6+xSUyYYmaAemLmV+gnZ8mMSc3a6kJUvOXIxQRqXzh31HqonJj8dF 7e1nDio6QcDOf8RUmFnQgmjfnDFfk+59O9fnWpwJ1ulpeG2U1HctJCbpslDxeoo74W19 mdYLlV4itFx5Bn/bWiy/st5kwb8Inb9OYa0+QE5hQOGzi4Fg0f/oAfz2YFazXm3M/+LL MQ9LGBhWx3mQSOFnQL67Slrb1uJXU9HINlipKIyeL+t7p93ku4bu2rAWvij/2++nNKrI LVYg== X-Gm-Message-State: AKS2vOw/+McVRSRfhSYZAtpSFMVuQvBci4fT2XniAFoVYaAL1mdzT/Y/ 2E7TXRthrkYJLR3RjyOi10gveR5dH9d/ X-Received: by 10.28.194.198 with SMTP id s189mr4657847wmf.123.1497554296162; Thu, 15 Jun 2017 12:18:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.131.66 with HTTP; Thu, 15 Jun 2017 12:18:15 -0700 (PDT) From: Alia Atlas Date: Thu, 15 Jun 2017 15:18:15 -0400 Message-ID: To: trill@ietf.org, draft-ietf-trill-arp-optimization@ietf.org Content-Type: multipart/alternative; boundary="001a1148cf78dad32605520487f4" Archived-At: Subject: [trill] AD review and progressing of draft-ietf-trill-arp-optimization-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 19:18:23 -0000 --001a1148cf78dad32605520487f4 Content-Type: text/plain; charset="UTF-8" First, I'd like to thank the authors for handling the technical concerns seen by the IESG during the last review process. As is customary, I have done my AD review of this draft. I do not have any issues that need to be addressed. I have requested IETF Last Call and scheduled this for the July 7 telechat, though it might get moved to after IETF 99 depending upon the document load for that telechat. Regards, Alia --001a1148cf78dad32605520487f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
First, I'd like to thank the authors for handling the = technical concerns seen by the IESG during the last review process.
As is customary, I have done my AD review of this draft.=C2=A0 = I do not have any issues that need to be addressed.=C2=A0 I have requested = IETF Last Call and scheduled this for the July 7 telechat, though it might = get moved to after IETF 99 depending upon the document load for that telech= at.

Regards,
Alia
--001a1148cf78dad32605520487f4-- From nobody Thu Jun 15 12:28:20 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D23E120227; Thu, 15 Jun 2017 12:28:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, trill@ietf.org, skh@ndzh.com, akatlas@gmail.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149755489935.11277.14947378865395083552.idtracker@ietfa.amsl.com> Date: Thu, 15 Jun 2017 12:28:19 -0700 Archived-At: Subject: [trill] Last Call: (TRILL: ARP/ND Optimization) to Proposed Standard X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 19:28:19 -0000 The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL: ARP/ND Optimization' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes mechanisms to optimize the ARP (Address Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL campus. Such optimization reduces packet flooding over a TRILL campus. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2896/ From nobody Thu Jun 15 18:41:04 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB631205D3; Thu, 15 Jun 2017 18:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbIhhADBRqc7; Thu, 15 Jun 2017 18:41:01 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C58A1205F1; Thu, 15 Jun 2017 18:41:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.176.217; From: "Susan Hares" To: "'Alia Atlas'" , , References: In-Reply-To: Date: Thu, 15 Jun 2017 21:35:16 -0400 Message-ID: <009401d2e640$cef6ec70$6ce4c550$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0095_01D2E61F.47E5E8B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG8N/SWgZxRDREmSSAmvkV9PdQ1dKJUEYsw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [trill] AD review and progressing of draft-ietf-trill-arp-optimization-08 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 01:41:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0095_01D2E61F.47E5E8B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alia:=20 =20 Thank you for the review and the heads up that = draft-ietf-trill-arp-optimization-08.txt may move to the August = telechat.=20 =20 Sue=20 =20 From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Thursday, June 15, 2017 3:18 PM To: trill@ietf.org; draft-ietf-trill-arp-optimization@ietf.org Subject: [trill] AD review and progressing of = draft-ietf-trill-arp-optimization-08 =20 First, I'd like to thank the authors for handling the technical concerns = seen by the IESG during the last review process. =20 As is customary, I have done my AD review of this draft. I do not have = any issues that need to be addressed. I have requested IETF Last Call = and scheduled this for the July 7 telechat, though it might get moved to = after IETF 99 depending upon the document load for that telechat. =20 Regards, Alia ------=_NextPart_000_0095_01D2E61F.47E5E8B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Alia:

 

Thank you for the review and the heads up that = draft-ietf-trill-arp-optimization-08.txt may move to the August = telechat.

 

Sue

 

From:= = trill [mailto:trill-bounces@ietf.org] On Behalf Of Alia = Atlas
Sent: Thursday, June 15, 2017 3:18 PM
To: = trill@ietf.org; = draft-ietf-trill-arp-optimization@ietf.org
Subject: [trill] AD = review and progressing of = draft-ietf-trill-arp-optimization-08

 

First, = I'd like to thank the authors for handling the technical concerns seen = by the IESG during the last review process.

 

As is customary, I have done my AD review of this = draft.  I do not have any issues that need to be addressed.  I = have requested IETF Last Call and scheduled this for the July 7 = telechat, though it might get moved to after IETF 99 depending upon the = document load for that telechat.

 

Regards,

Alia

------=_NextPart_000_0095_01D2E61F.47E5E8B0-- From nobody Thu Jun 15 18:45:08 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87A8128B91; Thu, 15 Jun 2017 18:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NznLSlYVxRF3; Thu, 15 Jun 2017 18:44:58 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62831205D3; Thu, 15 Jun 2017 18:44:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.176.217; From: "Susan Hares" To: "'Magnus Westerlund'" , Cc: , , , "'Alia Atlas'" , "'Jon Hudson'" References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> In-Reply-To: <149754795560.13109.17521244075940607817@ietfa.amsl.com> Date: Thu, 15 Jun 2017 21:39:10 -0400 Message-ID: <00a301d2e641$5a6cfb00$0f46f100$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMe5Py4K7gCbNISswrkrRWdm5LSqIziw8g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 01:45:01 -0000 Magnus:=20 Thank you for the very careful review. Please let me chat with the = authors regarding this document. It make take some time, but each of = your points will be responded to by the authors.=20 Sue Hares=20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Thursday, June 15, 2017 1:33 PM To: tsv-art@ietf.org Cc: trill@ietf.org; ietf@ietf.org; draft-ietf-trill-over-ip.all@ietf.org Subject: Tsvart early review of draft-ietf-trill-over-ip-10 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 = significant 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 specifications. 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. Diffserv usage -------------- Section 4.3: TRILL over IP implementations MUST support setting the DSCP value in the outer IP Header of TRILL packets they send by mapping the TRILL priority and DEI to the DSCP. They MAY support, for a TRILL Data packet where the native frame payload is an IP packet, mapping the DSCP in this inner IP packet to the outer IP Header with the default 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 = discussion of the potential issues with actually setting the DSCP = values. It is one thing to do this in an IP back bone use case where one = can know and have control 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 policers or remapping. Also as the actual = DSCP code point usage is domain specific this is difficult. Priority = reversal is likely the least of the problems that this can run into over = general Internet. 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 = networks this can also results in strange remapping that results in a = different PHB for CS1 than. MTU and Fragmentation --------------------- I think there are two main issue here. The first one is MTUD discovery = 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 = requries 1470 byte support which is likey above a lot of paths. Section 8.4: Path MTU discovery [RFC4821] should be useful in determining the IP MTU between a pair of RBridge ports with IP connectivity. The issue with RFC4821 is that it has requirements on the packetization = 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. 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? 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 = below 1470. If I am wrong good, but I think this is an important piece = for how to handle the next main issue. UDP encapsulation and IP fragments. I see it as a big issue that UDP encapsulation is the native one, and = that relies on IP fragmentation despite the need for reliable = fragmentation. 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 problem 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 to not = get IP fragements 2. Determine MTU and implement an fragmentation = mechanism on top of UDP. Zero Checksum: -------------- Section 5.4: UDP Checksum - as specified in [RFC0768] Considering the fast path encapsulation desire, I am surprised to not = 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 apply 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 = applicability 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 done. TCP Encapsulation issue ----------------------- Section 5.6: The TCP encapsulation appear to be missing an delimiter format allowing = each individual TRILL packet/payload to be read out of the TCP's byte = stream. In other words, a normal implementation has no way of ensuring = that the TCP payload starts with the start of a new TRILL payload. = Multiple small TRILL payloads may be included in the same TCP payload, = and also only parts 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 length field for the TRILL payload to be encapsulated. 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 sizes in relation to Bandwidth delay products, as buffer memory = in a RBridge will impact performance. Congestion Control ------------------ First thanks for the effort here. 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, specific congestion control mechanisms are commonly needed. However, if the traffic being carried by the TRILL over IP link is already congestion controlled and the size and volatility of the TRILL IS-IS link state 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 anyway of = knowing which traffic is actually congestion controlled, considering = that TRILL provides an layer 2 abstraction. I wonder if there should be = any type of white 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 any recommendation to prevent traffic = that is not controlled to be forwarded, can lead to congestion issues. The other issue I think may exist is the issue serial unicast emulation = of broadcast/multicast creates. As this amplifies the outgoing packet = rate with a factor of how many addresses are configured for serial = unicast this can be significant traffic expansion. Thus, I think = additional considerations are needed here, and maybe rate limiting of = the amount of traffic to be multicasted. 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. If I understand this correctly, the idea here is to look into the inner = layer 2 frames, and use the flow equivalents that exists on that level = and hash that into value that maps the flows onto the source port range. I think this text should include a summary of the principle and ensure = 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. 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 static = binding configurations or the need for determining ones external = address(es) and be able to communicate that to the peer RBridges, and in = addition ensure that one has keep-alives to that the NAT binding never = times out. 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. 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). Note = 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 bytes MTU Ethernet infrastructure. I would note that also firewalls likely have issues with IP fragments = for the same reason, they require significant amount of state to be = verified if they should be let through. In general I think you should create a configuration that has chance to = work through most middleboxes, but I think you should require static = bindings. 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. Cheers Magnus Westerlund From nobody Fri Jun 16 09:47:13 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4BA1295A0; Fri, 16 Jun 2017 09:47:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149763163213.665.11787484307467115379@ietfa.amsl.com> Date: Fri, 16 Jun 2017 09:47:12 -0700 Archived-At: Subject: [trill] I-D Action: draft-ietf-trill-rbridge-multilevel-06.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:47:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links) Authors : Radia Perlman Donald Eastlake Mingui Zhang Anoop Ghanwani Hongjun Zhai Filename : draft-ietf-trill-rbridge-multilevel-06.txt Pages : 33 Date : 2017-06-16 Abstract: Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network or can they merely be unique within each multilevel area? This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability and makes recommendations in some cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trill-rbridge-multilevel-06 https://datatracker.ietf.org/doc/html/draft-ietf-trill-rbridge-multilevel-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-rbridge-multilevel-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 19 03:01:12 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BBA124D6C; Mon, 19 Jun 2017 03:01:11 -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, 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 C8Ls0KxCGmEG; Mon, 19 Jun 2017 03:01:08 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27FA126DEE; Mon, 19 Jun 2017 03:01:02 -0700 (PDT) Received: from [192.168.0.2] (c213-89-111-155.bredband.comhem.se [213.89.111.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 55E5D180155A; Mon, 19 Jun 2017 12:01:01 +0200 (CEST) To: rtg-dir@ietf.org, trill-chairs@ietf.org, draft-ietf-trill-ecn-support@ietf.org References: Cc: trill@ietf.org, "'Yemin (Amy'" From: Loa Andersson Message-ID: <44ca7760-b1c8-cf98-2e8c-2ad47fa6d3c5@pi.nu> Date: Mon, 19 Jun 2017 12:00:59 +0200 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: [trill] QA review of draft-ietf-trill-ecn-support X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 10:01:11 -0000 Authors, Working Group, Sorry for the late reply. I've been asked to re-review the document since it is (was) in working group last call. I've reviewed again I find that - my earlier comments has been satisfactorily addressed - I have no further comments on this document - I believe we are ready to ask for publication. /Loa On 2017-01-21 06:02, Loa Andersson wrote: > Authors, > > I have been asked to do a Routing Area Directorate QA review of > draft-ietf-trill-ecn-support. > > Caveat - I'm not a congestion control expert, and this will show up in > my comments. The place where I ask for clarifications might be perfectly > clear for a reader that is up to speed in the area. > > Summary: > > I think the document is on the right track, for a reader not an expert > in the area there are a lot of abbreviations that are not properly > expanded. I also think that it would be a good idea to more clearly > make the the case why the document is needed (abstract and/or > introduction). > > After a while I stop trying to distinguish between "Minor issues" and > "Nits" and placed everything as Minor Issues. I guess I could have > done everything as Nits :). > > Other than the Comment/Minor Issues I find the document pretty solid, > though I sometimes found it hard to parse sentences. > If you want I can take a look at that aspect once what is in this > review has been addressed. > > > Comments: > > Last paragraph of the Introduction > ---------------------------------- > > Whichever RBridges do not support ECN, this > specification ensures congestion notification will propagate safely > to Destination because the packet will be dropped if explicit > congestion notification cannot be propagated and drop is itself an > implicit form of congestion notification. > > Is this logic really watertight? What if the packet is dropped because > of a checksum error? > > > > Major Issues: > > > Minor Issues: > > Abstract > -------- > I find the Abstract a bit meager, a little more context would be good. > > Maybe lead with some short words about what ECN is good for. > > And maybe use this from the Introduction: > > This specification provides for any ECN marking in the traffic at the > ingress to be copied into the TRILL Extension Header Flags Word. It > also enables congestion marking by a congested RBridge such as RBn or > RB1 above in the TRILL Header Extension Flags Word [RFC7179]. > > ECNencapGuide > ------------- > > This reference has expired, probably not a problem since Bob is a > co-author of both documents. > > TRILL Header > ------------ > > Referred to in section in the Introduction, I think a reference would be > good. > > The ECN Specific Extended Header Flags > -------------------------------------- > > The pictures is less than intuitive, it took me quite some time de-code it. > I did the following: > Critical (?) flags > 0 - CRHbH (no expansion found in document) > 1 - CRItE (no expansion found in document) > 2 - CRRsv (no expansion found in document) > > CHbH flags (Critical Hop by Hop flags - no expansion found in document) > 3 - unassigned > 4 - unassigned > 5 - unassigned > 6 - unassigned > 7 - CRCAF (no expansion found in document) > > NCHbH flags = Non-Critical Hop-by-Hop flags > 8 - NCCAF (no expansion found in document) > 9 - unassigned > 10 - unassigned > 11 - unassigned > ------------------------------------------- > 12 - ECN = Explicit Congestion Notification > 13 (two bit flags) > ------------------------------------------- > > CRSV flags (no expansion found in document) > ------------------------------------------- > 14 - Ext Hop Cnt (no expansion found in document) > 15 three bit field > 16 > ------------------------------------------ > > NCRSV flags (no expansion found in document) > 17 - unassigned > 18 - unassigned > 19 - unassigned > 20 - unassigned > ------------------------------------------ > > CItE flags = Critical Ingress-to-Egress > ------------------------------------------ > 21 - unassigned > 22 - unassigned > 23 - unassigned > 24 - unassigned > 25 - unassigned > 26 - CCE = Critical Congestion Experienced > ------------------------------------------ > > NCItE flags = Non Critical Ingress-to-Egress > -------------------------------------------- > 27 - Ext Clr (no expansion found in document) > 28 two bit field > -------------------------------------------- > 29 - unassigned > 30 - unassigned > 31 - unassigned > > Multi-bit flags > --------------- > > In the context I've been active "flags" are one bit, if there are > multiple bits they are called fields. I understand that in the context > this is written there are multiple bit flags. > > Bit 11 and 12 > ------------- > > Bit 11 and 12 has the following code points: > > Binary Name Meaning > ------ ------- ----------------------------------- > 00 Not-ECT Not ECN-Capable Transport > 01 ECT(1) ECN-Capable Transport (1) > 10 ECT(0) ECN-Capable Transport (0) > 11 NCCE Non-Critical Congestion Experienced > > Table 1. TRILL-ECN Field Codepoints > > There is no good explanation what ECT(0) and ECT(1) means, even though > it is (page 9) said that "ECT(1) as a lesser severity level, termed the > Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is > a higher severity level, but this should be clearly spelled out. > > RFC 3168 does not make the distinction between ECT(0) and ECT(1), but > says that it will be done in future RFCs; since this is about 3000 RFCs > ago it might have happened but I couldn't find it. If this has been done > I think a reference would be good. > > Code Point 0b11 > --------------- > The text above Table 1 says: > OLD > "However codepoint 11 is called Non-Critical Congestion Experienced > (NCCE)..." > I think this should be: > However code point 0b11 is called Non-Critical Congestion Experienced > (NCCE)..." > > The text further says that the code point is call NCCE to distinguish > it from Congestion Experienced in IP. The question I have is why it is > necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10? > > ECN SUpport > ----------- > > The first paragraph has "logically" at three places, what would be the > difference if these "logically" are dropped? > > > First sentence in sectuion 3.1 > ------------------------------ > > The sentence says: > "The ingress behavior is as follows:" > > I would say > "The behavior of an ingress RBridge is as follows:" > or even > "The behavior of an ingress RBridge MUST be as follows:" > > cleared vs set to zero > ---------------------- > The last sub-bullet in the first main bullet of section 3.1 says: > "ensure the CCE flag is cleared to zero (Flags Word bit 26)." I would > have used "cleared" or "swt to zero". > > First line section 3,2 > ---------------------- > s/ahow/shown > Caveat I normally don't English grammar reviews, but sometimes I can't > stop myself :) > > Second line first main bullet in section 3.2 > -------------------------------------------- > > I prefer the format "guidelines in RFC 7567 [RFC7567]" > > Third sub-bullet in the third main bullet of section 3.2 > --------------------------------------------------------- > > It says: > "+ set the TRILL-ECN field to Not-ECT (00);" > > Here you use "field" instead of "flag", which is fine, but the document > should be consistent. Either: > + set the TRILL-ECN field to Not-ECT (0b00); > or > + set the TRILL-ECN flag to Not-ECT (0b00); > > Egress ECN Support > ------------------ > First sentence: > "If the egress RBridge does not support ECN, it will ignore bits 12 > and 13 of any Flags Word that is present, because it does not contain > any special ECN logic." > > in "it will ignore" what does "it" refer to? > > SHould it be: > > "If the egress RBridge does not support ECN, the RBridge will ignore > the TRILL-ECN field (bits 12 and 13) if a Flags Word that is > present, because it has no ECN logic." > > TRILL Support for ECN Variants > ------------------------------ > The sedond sentence of section four says: > > Section 3 specifies interworking between TRILL and the original > standardized form of ECN in IP [RFC3168]. > > RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to > RFC 3168 or does the updates come into plan. IF the updates are in > scope I think the sentence should say: > > Section 3 specifies interworking between TRILL and the original > standardized form of ECN in IP RFC 3168 [RFC3168], and the updates > in RFC4310 [RFC4301] and RFC 6040 [6040]. > > > > > > Nits: > > Codepoints > ---------- > at several places "codepoint(s)" I think the words IANA and the > RFC Editor use is "code point(s)" > > > > /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jun 19 12:56:43 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542A3129494; Mon, 19 Jun 2017 12:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, 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 aW6nrjiYcaf6; Mon, 19 Jun 2017 12:56:32 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E8F127B52; Mon, 19 Jun 2017 12:56:32 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id m47so2003214iti.1; Mon, 19 Jun 2017 12:56:32 -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=SmiXoWlFzRx7yYrvJ6z03gAbI4cNhIkWt80bJP/jKSo=; b=a6cROIBac7aCesE+QSovVgvos8ic7xWEE4aZ02mH19T9gv1xkLi1BNGp8VNRRrJ/V+ GHiJRnUO38WN8XT6q2tHrnXqX25vjcj9pCA0m5WznwZpqERb5q/VAJVR912/pZu2JNdl uQYDZSQw6mhkg2Z59OCs5SvlDfk2ZUqQVDNC8FzHXP2cMfywXbCupgqNfPNbfFSAFLwv +WLvYF6ATcPzNzskuRffAu10RV8A0mQEf3eCkG7su4FpZnTMTM6gk6cRvvy4wFMtx2vA 19eFNUr/W9FDx1wVPfuixNpNggDVibq/wxo0E3o2B26aE+3nN2u+f8kdUwp5Aps1vk7Y b+Hg== 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=SmiXoWlFzRx7yYrvJ6z03gAbI4cNhIkWt80bJP/jKSo=; b=rueW9Z4SurvhzIwhhmTuMC2r3EaKPJt/4AZ0w+6O5qKGt0rPPG9WfQ1+sk0okyg3wt /fLvIz69xk6c7OgFA/8+bM00s9p1a+GIHz1XCQuE4+yvaKnanGflMM+G4tEuHWUWY75V FClD3ic9vgGBhupbq769fy9qbyPD97RYkLv8yCIJU4tX9Ia4IbYS3zblXOgHMbEjIuZm aHgbrwvErn7+s0y2ltSV74uAxaNnBCMPWiC2Gn6q9d4W3lTXrwQq/KuFltG6SL0oBNAZ wPeIyty45e5/GDJR9kGudQqUhhSeDJFigQ96n6QRrcIqxOAA2qASo/aJYnTaXXQT+03r g5yw== X-Gm-Message-State: AKS2vOwKVCWFhEkNE+g6JECOnwzrFJmMwQo6gT2JpFOcUCvmZME59X7K LTnWPppmd57TOEFZclElRKchJk3UPA== X-Received: by 10.36.112.20 with SMTP id f20mr459874itc.104.1497902192097; Mon, 19 Jun 2017 12:56:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.152 with HTTP; Mon, 19 Jun 2017 12:56:16 -0700 (PDT) In-Reply-To: <44ca7760-b1c8-cf98-2e8c-2ad47fa6d3c5@pi.nu> References: <44ca7760-b1c8-cf98-2e8c-2ad47fa6d3c5@pi.nu> From: Donald Eastlake Date: Mon, 19 Jun 2017 15:56:16 -0400 Message-ID: To: Loa Andersson Cc: "rtg-dir@ietf.org" , "trill-chairs@ietf.org" , draft-ietf-trill-ecn-support@ietf.org, "trill@ietf.org" , "Yemin (Amy" Content-Type: multipart/alternative; boundary="001a113f890211a9c3055255888d" Archived-At: Subject: Re: [trill] QA review of draft-ietf-trill-ecn-support X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 19:56:36 -0000 --001a113f890211a9c3055255888d Content-Type: text/plain; charset="UTF-8" Hi Loa, Thanks for the update. Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jun 19, 2017 at 6:00 AM, Loa Andersson wrote: > Authors, Working Group, > > Sorry for the late reply. > > I've been asked to re-review the document since it is (was) in working > group last call. > > I've reviewed again > > I find that > - my earlier comments has been satisfactorily addressed > - I have no further comments on this document > - I believe we are ready to ask for publication. > > /Loa > > > On 2017-01-21 06:02, Loa Andersson wrote: > >> Authors, >> >> I have been asked to do a Routing Area Directorate QA review of >> draft-ietf-trill-ecn-support. >> >> Caveat - I'm not a congestion control expert, and this will show up in >> my comments. The place where I ask for clarifications might be perfectly >> clear for a reader that is up to speed in the area. >> >> Summary: >> >> I think the document is on the right track, for a reader not an expert >> in the area there are a lot of abbreviations that are not properly >> expanded. I also think that it would be a good idea to more clearly >> make the the case why the document is needed (abstract and/or >> introduction). >> >> After a while I stop trying to distinguish between "Minor issues" and >> "Nits" and placed everything as Minor Issues. I guess I could have >> done everything as Nits :). >> >> Other than the Comment/Minor Issues I find the document pretty solid, >> though I sometimes found it hard to parse sentences. >> If you want I can take a look at that aspect once what is in this >> review has been addressed. >> >> >> Comments: >> >> Last paragraph of the Introduction >> ---------------------------------- >> >> Whichever RBridges do not support ECN, this >> specification ensures congestion notification will propagate safely >> to Destination because the packet will be dropped if explicit >> congestion notification cannot be propagated and drop is itself an >> implicit form of congestion notification. >> >> Is this logic really watertight? What if the packet is dropped because >> of a checksum error? >> >> >> >> Major Issues: >> >> >> Minor Issues: >> >> Abstract >> -------- >> I find the Abstract a bit meager, a little more context would be good. >> >> Maybe lead with some short words about what ECN is good for. >> >> And maybe use this from the Introduction: >> >> This specification provides for any ECN marking in the traffic at the >> ingress to be copied into the TRILL Extension Header Flags Word. It >> also enables congestion marking by a congested RBridge such as RBn or >> RB1 above in the TRILL Header Extension Flags Word [RFC7179]. >> >> ECNencapGuide >> ------------- >> >> This reference has expired, probably not a problem since Bob is a >> co-author of both documents. >> >> TRILL Header >> ------------ >> >> Referred to in section in the Introduction, I think a reference would be >> good. >> >> The ECN Specific Extended Header Flags >> -------------------------------------- >> >> The pictures is less than intuitive, it took me quite some time de-code >> it. >> I did the following: >> Critical (?) flags >> 0 - CRHbH (no expansion found in document) >> 1 - CRItE (no expansion found in document) >> 2 - CRRsv (no expansion found in document) >> >> CHbH flags (Critical Hop by Hop flags - no expansion found in document) >> 3 - unassigned >> 4 - unassigned >> 5 - unassigned >> 6 - unassigned >> 7 - CRCAF (no expansion found in document) >> >> NCHbH flags = Non-Critical Hop-by-Hop flags >> 8 - NCCAF (no expansion found in document) >> 9 - unassigned >> 10 - unassigned >> 11 - unassigned >> ------------------------------------------- >> 12 - ECN = Explicit Congestion Notification >> 13 (two bit flags) >> ------------------------------------------- >> >> CRSV flags (no expansion found in document) >> ------------------------------------------- >> 14 - Ext Hop Cnt (no expansion found in document) >> 15 three bit field >> 16 >> ------------------------------------------ >> >> NCRSV flags (no expansion found in document) >> 17 - unassigned >> 18 - unassigned >> 19 - unassigned >> 20 - unassigned >> ------------------------------------------ >> >> CItE flags = Critical Ingress-to-Egress >> ------------------------------------------ >> 21 - unassigned >> 22 - unassigned >> 23 - unassigned >> 24 - unassigned >> 25 - unassigned >> 26 - CCE = Critical Congestion Experienced >> ------------------------------------------ >> >> NCItE flags = Non Critical Ingress-to-Egress >> -------------------------------------------- >> 27 - Ext Clr (no expansion found in document) >> 28 two bit field >> -------------------------------------------- >> 29 - unassigned >> 30 - unassigned >> 31 - unassigned >> >> Multi-bit flags >> --------------- >> >> In the context I've been active "flags" are one bit, if there are >> multiple bits they are called fields. I understand that in the context >> this is written there are multiple bit flags. >> >> Bit 11 and 12 >> ------------- >> >> Bit 11 and 12 has the following code points: >> >> Binary Name Meaning >> ------ ------- ----------------------------------- >> 00 Not-ECT Not ECN-Capable Transport >> 01 ECT(1) ECN-Capable Transport (1) >> 10 ECT(0) ECN-Capable Transport (0) >> 11 NCCE Non-Critical Congestion Experienced >> >> Table 1. TRILL-ECN Field Codepoints >> >> There is no good explanation what ECT(0) and ECT(1) means, even though >> it is (page 9) said that "ECT(1) as a lesser severity level, termed the >> Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is >> a higher severity level, but this should be clearly spelled out. >> >> RFC 3168 does not make the distinction between ECT(0) and ECT(1), but >> says that it will be done in future RFCs; since this is about 3000 RFCs >> ago it might have happened but I couldn't find it. If this has been done >> I think a reference would be good. >> >> Code Point 0b11 >> --------------- >> The text above Table 1 says: >> OLD >> "However codepoint 11 is called Non-Critical Congestion Experienced >> (NCCE)..." >> I think this should be: >> However code point 0b11 is called Non-Critical Congestion Experienced >> (NCCE)..." >> >> The text further says that the code point is call NCCE to distinguish >> it from Congestion Experienced in IP. The question I have is why it is >> necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10? >> >> ECN SUpport >> ----------- >> >> The first paragraph has "logically" at three places, what would be the >> difference if these "logically" are dropped? >> >> >> First sentence in sectuion 3.1 >> ------------------------------ >> >> The sentence says: >> "The ingress behavior is as follows:" >> >> I would say >> "The behavior of an ingress RBridge is as follows:" >> or even >> "The behavior of an ingress RBridge MUST be as follows:" >> >> cleared vs set to zero >> ---------------------- >> The last sub-bullet in the first main bullet of section 3.1 says: >> "ensure the CCE flag is cleared to zero (Flags Word bit 26)." I would >> have used "cleared" or "swt to zero". >> >> First line section 3,2 >> ---------------------- >> s/ahow/shown >> Caveat I normally don't English grammar reviews, but sometimes I can't >> stop myself :) >> >> Second line first main bullet in section 3.2 >> -------------------------------------------- >> >> I prefer the format "guidelines in RFC 7567 [RFC7567]" >> >> Third sub-bullet in the third main bullet of section 3.2 >> --------------------------------------------------------- >> >> It says: >> "+ set the TRILL-ECN field to Not-ECT (00);" >> >> Here you use "field" instead of "flag", which is fine, but the document >> should be consistent. Either: >> + set the TRILL-ECN field to Not-ECT (0b00); >> or >> + set the TRILL-ECN flag to Not-ECT (0b00); >> >> Egress ECN Support >> ------------------ >> First sentence: >> "If the egress RBridge does not support ECN, it will ignore bits 12 >> and 13 of any Flags Word that is present, because it does not contain >> any special ECN logic." >> >> in "it will ignore" what does "it" refer to? >> >> SHould it be: >> >> "If the egress RBridge does not support ECN, the RBridge will ignore >> the TRILL-ECN field (bits 12 and 13) if a Flags Word that is >> present, because it has no ECN logic." >> >> TRILL Support for ECN Variants >> ------------------------------ >> The sedond sentence of section four says: >> >> Section 3 specifies interworking between TRILL and the original >> standardized form of ECN in IP [RFC3168]. >> >> RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to >> RFC 3168 or does the updates come into plan. IF the updates are in >> scope I think the sentence should say: >> >> Section 3 specifies interworking between TRILL and the original >> standardized form of ECN in IP RFC 3168 [RFC3168], and the updates >> in RFC4310 [RFC4301] and RFC 6040 [6040]. >> >> >> >> >> >> Nits: >> >> Codepoints >> ---------- >> at several places "codepoint(s)" I think the words IANA and the >> RFC Editor use is "code point(s)" >> >> >> >> /Loa >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a113f890211a9c3055255888d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Loa,

Thanks for the update.

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
=C2=A0Do= nald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Stre= et, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Mon, Jun 19, 2017 at 6:00 AM, Loa Anderss= on <loa= @pi.nu> wrote:
Authors, Wor= king Group,

Sorry for the late reply.

I've been asked to re-review the document since it is (was) in working<= br> group last call.

I've reviewed again

I find that
- my earlier comments has been satisfactorily addressed
- I have no further comments on this document
- I believe we are ready to ask for publication.

/Loa


On 2017-01-21 06:02, Loa Andersson wrote:
Authors,

I have been asked to do a Routing Area Directorate QA review of
draft-ietf-trill-ecn-support.

Caveat - I'm not a congestion control expert, and this will show up in<= br> my comments. The place where I ask for clarifications might be perfectly clear for a reader that is up to speed in the area.

Summary:

I think the document is on the right track, for a reader not an expert
in the area there are a lot of abbreviations that are not properly
expanded. I also think that it would be a good idea to more clearly
make the the case why the document is needed (abstract and/or
introduction).

After a while I stop trying to distinguish between "Minor issues"= and
"Nits" and placed everything as Minor Issues. I guess I could hav= e
done everything as Nits :).

Other than the Comment/Minor Issues I find the document pretty solid,
though I sometimes found it hard to parse sentences.
If you want I can take a look at that aspect once what is in this
review has been addressed.


Comments:

Last paragraph of the Introduction
----------------------------------

=C2=A0 =C2=A0Whichever RBridges do not support ECN, this
=C2=A0 =C2=A0specification ensures congestion notification will propagate s= afely
=C2=A0 =C2=A0to Destination because the packet will be dropped if explicit<= br> =C2=A0 =C2=A0congestion notification cannot be propagated and drop is itsel= f an
=C2=A0 =C2=A0implicit form of congestion notification.

Is this logic really watertight? What if the packet is dropped because
of a checksum error?



Major Issues:


Minor Issues:

Abstract
--------
I find the Abstract a bit meager, a little more context would be good.

=C2=A0 =C2=A0Maybe lead with some short words about what ECN is good for.
And maybe use this from the Introduction:

=C2=A0 =C2=A0This specification provides for any ECN marking in the traffic= at the
=C2=A0 =C2=A0ingress to be copied into the TRILL Extension Header Flags Wor= d. It
=C2=A0 =C2=A0also enables congestion marking by a congested RBridge such as= RBn or
=C2=A0 =C2=A0RB1 above in the TRILL Header Extension Flags Word [RFC7179].<= br>
ECNencapGuide
-------------

This reference has expired, probably not a problem since Bob is a
co-author of both documents.

TRILL Header
------------

Referred to in section in the Introduction, I think a reference would be good.

The ECN Specific Extended Header Flags
--------------------------------------

The pictures is less than intuitive, it took me quite some time de-code it.=
I did the following:
Critical (?) flags
=C2=A00 - CRHbH (no expansion found in document)
=C2=A01 - CRItE (no expansion found in document)
=C2=A02 - CRRsv (no expansion found in document)

CHbH flags (Critical Hop by Hop flags - no expansion found in document)
=C2=A03 - unassigned
=C2=A04 - unassigned
=C2=A05 - unassigned
=C2=A06 - unassigned
=C2=A07 - CRCAF (no expansion found in document)

NCHbH flags =3D Non-Critical Hop-by-Hop flags
=C2=A08 - NCCAF (no expansion found in document)
=C2=A09 - unassigned
10 - unassigned
11 - unassigned
-------------------------------------------
12 - ECN =3D Explicit Congestion Notification
13=C2=A0 =C2=A0(two bit flags)
-------------------------------------------

CRSV flags (no expansion found in document)
-------------------------------------------
14 - Ext Hop Cnt (no expansion found in document)
15=C2=A0 =C2=A0three bit field
16
------------------------------------------

NCRSV flags (no expansion found in document)
17 - unassigned
18 - unassigned
19 - unassigned
20 - unassigned
------------------------------------------

CItE flags =3D Critical Ingress-to-Egress
------------------------------------------
21 - unassigned
22 - unassigned
23 - unassigned
24 - unassigned
25 - unassigned
26 - CCE =3D Critical Congestion Experienced
------------------------------------------

NCItE flags =3D Non Critical Ingress-to-Egress
--------------------------------------------
27 - Ext Clr (no expansion found in document)
28=C2=A0 =C2=A0two bit field
--------------------------------------------
29 - unassigned
30 - unassigned
31 - unassigned

Multi-bit flags
---------------

In the context I've been active "flags" are one bit, if there= are
multiple bits they are called fields. I understand that in the context
this is written there are multiple bit flags.

Bit 11 and 12
-------------

Bit 11 and 12 has the following code points:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Binary=C2=A0 Name=C2=A0 =C2=A0 =C2=A0Mea= ning
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ------=C2=A0 -------=C2=A0 -------------= ----------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 00=C2=A0 =C2=A0 =C2=A0Not-ECT Not= ECN-Capable Transport
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 01=C2=A0 =C2=A0 =C2=A0ECT(1)=C2= =A0 ECN-Capable Transport (1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10=C2=A0 =C2=A0 =C2=A0ECT(0)=C2= =A0 ECN-Capable Transport (0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11=C2=A0 =C2=A0 =C2=A0NCCE=C2=A0 = =C2=A0 Non-Critical Congestion Experienced

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Table= 1. TRILL-ECN Field Codepoints

There is no good explanation what ECT(0) and ECT(1) means, even though
it is (page 9) said that "ECT(1) as a lesser severity level, termed th= e
Threshold-Marked (ThM) codepoint". It could be inferred that ECT(0) is=
a higher severity level, but this should be clearly spelled out.

RFC 3168 does not make the distinction between ECT(0) and ECT(1), but
says that it will be done in future RFCs; since this is about 3000 RFCs
ago it might have happened but I couldn't find it. If this has been don= e
I think a reference would be good.

Code Point 0b11
---------------
The text above Table 1 says:
OLD
"However codepoint 11 is called Non-Critical Congestion Experienced (NCCE)..."
I think this should be:
However code point 0b11 is called Non-Critical Congestion Experienced
(NCCE)..."

The text further says that the code point is call NCCE to distinguish
it from Congestion Experienced in IP. The question I have is why it is
necessary to distinguish code point 0b11, but not 0b00, 0b01 and 0b10?

ECN SUpport
-----------

The first paragraph has "logically" at three places, what would b= e the
difference if these "logically" are dropped?


First sentence in sectuion 3.1
------------------------------

The sentence says:
"The ingress behavior is as follows:"

I would say
"The behavior of an ingress RBridge is as follows:"
or even
"The behavior of an ingress RBridge MUST be as follows:"

cleared vs set to zero
----------------------
The last sub-bullet in the first main bullet of section 3.1 says:
"ensure the CCE flag is cleared to zero (Flags Word bit 26)." I w= ould
have used "cleared" or "swt to zero".

First line section 3,2
----------------------
s/ahow/shown
Caveat I normally don't English grammar reviews, but sometimes I can= 9;t
stop myself :)

Second line first main bullet in section 3.2
--------------------------------------------

I prefer the format "guidelines in RFC 7567 [RFC7567]"

Third sub-bullet in the third main bullet of section 3.2
---------------------------------------------------------

It says:
"+=C2=A0 set the TRILL-ECN field to Not-ECT (00);"

Here you use "field" instead of "flag", which is fine, = but the document
should be consistent. Either:
+=C2=A0 set the TRILL-ECN field to Not-ECT (0b00);
or
+=C2=A0 set the TRILL-ECN flag to Not-ECT (0b00);

Egress ECN Support
------------------
First sentence:
=C2=A0 "If the egress RBridge does not support ECN, it will ignore bit= s 12
=C2=A0 =C2=A0and 13 of any Flags Word that is present, because it does not = contain
=C2=A0 =C2=A0any special ECN logic."

in "it will ignore" what does "it" refer to?

SHould it be:

=C2=A0 "If the egress RBridge does not support ECN, the RBridge will i= gnore
=C2=A0 =C2=A0the TRILL-ECN field (bits 12 and 13) if a Flags Word that is =C2=A0 =C2=A0present, because it has no ECN logic."

TRILL Support for ECN Variants
------------------------------
The sedond sentence of section four says:

=C2=A0 =C2=A0Section 3 specifies interworking between TRILL and the origina= l
=C2=A0 =C2=A0standardized form of ECN in IP [RFC3168].

RFC 3168 is updated by RFC 4301, RFC 6040, does section 3 relate to
RFC 3168 or does the updates come into plan. IF the updates are in
scope I think the sentence should say:

=C2=A0 =C2=A0Section 3 specifies interworking between TRILL and the origina= l
=C2=A0 =C2=A0standardized form of ECN in IP RFC 3168 [RFC3168], and the upd= ates
=C2=A0 =C2=A0in RFC4310 [RFC4301] and RFC 6040 [6040].





Nits:

Codepoints
----------
at several places "codepoint(s)" I think the words IANA and the RFC Editor use is "code point(s)"



/Loa

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--001a113f890211a9c3055255888d-- From nobody Tue Jun 20 07:01:12 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190E912EC5A; Tue, 20 Jun 2017 07:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 bJuNbUk1j2LJ; Tue, 20 Jun 2017 07:00:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBF112EC53; Tue, 20 Jun 2017 07:00:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 90125B81F91; Tue, 20 Jun 2017 07:00:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, trill@ietf.org Message-Id: <20170620140033.90125B81F91@rfc-editor.org> Date: Tue, 20 Jun 2017 07:00:33 -0700 (PDT) Archived-At: Subject: [trill] RFC 8171 on Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 14:01:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8171 Title: Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms Author: D. Eastlake 3rd, L. Dunbar, R. Perlman, Y. Li Status: Standards Track Stream: IETF Date: June 2017 Mailbox: d3e3e3@gmail.com, ldunbar@huawei.com, radia@alum.mit.edu, liyizhou@huawei.com Pages: 55 Characters: 130232 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-trill-directory-assist-mechanisms-12.txt URL: https://www.rfc-editor.org/info/rfc8171 DOI: 10.17487/RFC8171 This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi-destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. This document is a product of the Transparent Interconnection of Lots of Links Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jun 20 18:08:36 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8B5131667 for ; Tue, 20 Jun 2017 18:08:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38owCY9NRJoz for ; Tue, 20 Jun 2017 18:08:33 -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 E39AA1200E5 for ; Tue, 20 Jun 2017 18:08:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPN24031; Wed, 21 Jun 2017 01:08:31 +0000 (GMT) Received: from DGGEMI402-HUB.china.huawei.com (10.3.17.135) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 21 Jun 2017 02:08:30 +0100 Received: from DGGEMI501-MBS.china.huawei.com ([169.254.2.135]) by dggemi402-hub.china.huawei.com ([10.3.17.135]) with mapi id 14.03.0301.000; Wed, 21 Jun 2017 09:08:24 +0800 From: zhangdacheng To: "trill@ietf.org" Thread-Topic: =?gb2312?B?cmWjulRoZSBUUklMTCBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXRy?= =?gb2312?B?aWxsLWdyb3VwLWtleWluZyBpbiBzdGF0ZSAiQ2FsbCBGb3IgQWRvcHRpb24g?= =?gb2312?Q?By_WG_Issued"?= Thread-Index: AdLqKlhB1o3fsoIeTbOe3vhYbOf8fg== Date: Wed, 21 Jun 2017 01:08:23 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C224201601774@dggemi501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: multipart/alternative; boundary="_000_879E76B64CF340468BF5E4DE504C224201601774dggemi501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5949C70F.0042, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 55af0826eebee2797e1b2ccf9dc537e5 Archived-At: Subject: [trill] =?gb2312?b?cmWjulRoZSBUUklMTCBXRyBoYXMgcGxhY2VkIGRyYWZ0?= =?gb2312?b?LWVhc3RsYWtlLXRyaWxsLWdyb3VwLWtleWluZyBpbiBzdGF0ZSAiQ2FsbCBG?= =?gb2312?b?b3IgQWRvcHRpb24gQnkgV0cgSXNzdWVkIg==?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 01:08:35 -0000 --_000_879E76B64CF340468BF5E4DE504C224201601774dggemi501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgYWRvcHRpb24uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCiAgKiAgIEZyb206IElFVEYgU2VjcmV0YXJpYXQgPGlldGYtc2VjcmV0YXJpYXQtcmVwbHkg YXQgaWV0Zi5vcmc8bWFpbHRvOmlldGYtc2VjcmV0YXJpYXQtcmVwbHlARE9NQUlOLkhJRERFTj4+ DQogICogICBUbzogPHRyaWxsLWNoYWlycyBhdCBpZXRmLm9yZzxtYWlsdG86dHJpbGwtY2hhaXJz QERPTUFJTi5ISURERU4+PiwgPGRyYWZ0LWVhc3RsYWtlLXRyaWxsLWdyb3VwLWtleWluZyBhdCBp ZXRmLm9yZzxtYWlsdG86ZHJhZnQtZWFzdGxha2UtdHJpbGwtZ3JvdXAta2V5aW5nQERPTUFJTi5I SURERU4+PiwgPHRyaWxsIGF0IGlldGYub3JnPG1haWx0bzp0cmlsbEBET01BSU4uSElEREVOPj4N CiAgKiAgIERhdGU6IFdlZCwgMzEgTWF5IDIwMTcgMTQ6Mzg6NTUgLTA3MDANCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhlIFRSSUxMIFdHIGhhcyBwbGFjZWQgZHJhZnQt ZWFzdGxha2UtdHJpbGwtZ3JvdXAta2V5aW5nIGluIHN0YXRlDQoNCkNhbGwgRm9yIEFkb3B0aW9u IEJ5IFdHIElzc3VlZCAoZW50ZXJlZCBieSBTdXNhbiBIYXJlcykNCg0KDQoNClRoZSBkb2N1bWVu dCBpcyBhdmFpbGFibGUgYXQNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZWFzdGxha2UtdHJpbGwtZ3JvdXAta2V5aW5nLw0KDQoNCg0K --_000_879E76B64CF340468BF5E4DE504C224201601774dggemi501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support the adoption.

 

The TRILL WG has placed draft-eastlake-trill-grou=
p-keying in state 
Call For Adoption By WG Issued (entered by Susan =
Hares)
 
The document is available at

https://datatracker.ietf.org/doc/draft-eastl=
ake-trill-group-keying/


 


 
--_000_879E76B64CF340468BF5E4DE504C224201601774dggemi501mbschi_-- From nobody Tue Jun 20 19:04:27 2017 Return-Path: X-Original-To: trill@ietf.org Delivered-To: trill@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BF412E054; Tue, 20 Jun 2017 19:04:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trill@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149801066030.15473.6885426856882546502@ietfa.amsl.com> Date: Tue, 20 Jun 2017 19:04:20 -0700 Archived-At: Subject: [trill] I-D Action: draft-eastlake-trill-group-keying-02.txt X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 02:04:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF. Title : A Group Keying Protocol Author : Donald E. Eastlake Filename : draft-eastlake-trill-group-keying-02.txt Pages : 27 Date : 2017-06-20 Abstract: This document specifies a general group keying protocol. It also provides use profiles for the application of this group keying protocol to multi-destination TRILL Extended RBridge Channel message security and TRILL over IP packet security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-eastlake-trill-group-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-eastlake-trill-group-keying-02 https://datatracker.ietf.org/doc/html/draft-eastlake-trill-group-keying-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-eastlake-trill-group-keying-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 21 00:32:18 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA9E12ECF0; Wed, 21 Jun 2017 00:32:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHV93tZeaVyB; Wed, 21 Jun 2017 00:32:14 -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 454031316BA; Wed, 21 Jun 2017 00:32:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIX42387; Wed, 21 Jun 2017 07:32:08 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 21 Jun 2017 08:31:21 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 21 Jun 2017 15:31:15 +0800 From: "Zhangmingui (Martin)" To: Susan Hares , "trill@ietf.org" CC: "trill-chairs@ietf.org" , "draft-ietf-trill-smart-endnodes@ietf.org" Thread-Topic: [trill] WG LC for draft-ietf-trill-smart-endnodes (5/31 to 6/13) Thread-Index: AdLaEjpykTlVpOFeSmqGocrS0LmYrQQTaqFg Date: Wed, 21 Jun 2017 07:31:15 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A65365DC@NKGEML515-MBX.china.huawei.com> References: <010e01d2da17$93a4cdc0$baee6940$@ndzh.com> In-Reply-To: <010e01d2da17$93a4cdc0$baee6940$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E7A65365DCNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.594A20FA.0107, 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: 6069cc1a4b21a3187559d33a9e17595e Archived-At: Subject: Re: [trill] WG LC for draft-ietf-trill-smart-endnodes (5/31 to 6/13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 07:32:17 -0000 --_000_4552F0907735844E9204A62BBDD325E7A65365DCNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This draft specifies a useful solution and it is ready for publication. Support. Thanks, Mingui From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, May 31, 2017 10:10 PM To: trill@ietf.org Cc: trill-chairs@ietf.org; draft-ietf-trill-smart-endnodes@ietf.org Subject: [trill] WG LC for draft-ietf-trill-smart-endnodes (5/31 to 6/13) This begins a 2 week WG LC for draft-ietf-trill-smart-endnodes, and you can= see the draft at: https://datatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/ Due to my errors, this WG LC has been delayed. We will be running this WG = LC in parallel with the IPR call. The authors (Radia, Fangwei, Donald, Kes= ava, Ting) should send their IPR statements by 6/5. If the IPR statements a= re not received, we will need to extend the WG LC. For this WG, please consider the following questions: 1) Does the draft-ietf-trill-smart-endnodes provide a good solution fo= r the problem of the size and freshness of the endnode learning table in ed= ge RBridges by allowing endnodes to volunteer for endnode learning and enca= psulation/decapsulation? 2) Do you know of any situations where deployment of this technology w= ill be helpful? 3) Is this technology and this draft ready for IESG publication? Sue Hares --_000_4552F0907735844E9204A62BBDD325E7A65365DCNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft specifies a useful solution and it is ready for public= ation.

Support.

 

Thanks,

Mingui

From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Wednesday, May 31, 2017 10:10 PM
To: trill@ietf.org
Cc: trill-chairs@ietf.org; draft-ietf-trill-smart-endnodes@ietf.org<= br> Subject: [trill] WG LC for draft-ietf-trill-smart-endnodes (5/31 to = 6/13)

 

This begins a 2 week WG LC for = draft-ietf-trill-smart-endnodes, and you can  see the draft at:

https://datatracker.ietf.org= /doc/draft-ietf-trill-smart-endnodes/

 

Due to my errors, this WG LC ha= s been delayed.  We will be running this WG LC in parallel with the IP= R call.  The authors (Radia, Fangwei, Donald, Kesava, Ting) should sen= d their IPR statements by 6/5. If the IPR statements are not received, we will need to extend the WG LC.

 

For this WG, please consider th= e following questions:

 

1) &nbs= p;    Does the draft-ietf-tri= ll-smart-endnodes provide a good solution for the problem of the size and f= reshness of the endnode learning table in edge RBridges by allowing endnode= s to volunteer for endnode learning and encapsulation/decapsulation?

2) &nbs= p;    Do you know of any situ= ations where deployment of this technology will be helpful?

3) &nbs= p;    Is this technology and = this draft ready for IESG publication?

 

Sue Hares

--_000_4552F0907735844E9204A62BBDD325E7A65365DCNKGEML515MBXchi_-- From nobody Wed Jun 21 02:27:06 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DBC131C7F for ; Wed, 21 Jun 2017 02:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DmGxEkxAx0Pg for ; Wed, 21 Jun 2017 02:26:54 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 17737131C56 for ; Wed, 21 Jun 2017 02:26:52 -0700 (PDT) X-scanvirus: By SEG_CYREN AntiVirus Engine X-scanresult: CLEAN X-MAILFROM: X-RCPTTO: X-FROMIP: 10.30.3.20 X-SEG-Scaned: 1 X-Received: unknown,10.30.3.20,20170621171941 Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 21 Jun 2017 09:19:41 -0000 Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id v5L9QdGf040849; Wed, 21 Jun 2017 17:26:39 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) Received: from njxapp01.zte.com.cn ([10.41.132.200]) by njhub02.zte.com.cn (IBM Domino Release 9.0.1FP5) with SMTP id 2017062117263562-3006208 ; Wed, 21 Jun 2017 17:26:35 +0800 Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 21 Jun 2017 17:26:40 +0800 (CST) Date: Wed, 21 Jun 2017 17:26:40 +0800 (CST) X-Zmail-TransId: 2afb594a3bd00ba-d640d X-Mailer: Zmail v1.0 Message-ID: <201706211726403746151@zte.com.cn> Mime-Version: 1.0 From: To: , X-MIMETrack: Itemize by SMTP Server on NJHUB02/server/zte_ltd(Release 9.0.1FP5|November 22, 2015) at 2017/06/21 17:26:35, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2017-06-21 17:26:31, Serialize complete at 2017-06-21 17:26:31 X-TNEFEvaluated: 1 Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse01.zte.com.cn v5L9QdGf040849 X-HQIP: 127.0.0.1 Archived-At: Subject: Re: [trill] =?utf-8?q?=C2=A0_WG_LC_for_draft-ietf-trill-smart-endnod?= =?utf-8?q?es_=285/31_to_6/13=29?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 09:27:00 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8" WWVzL3N1cHBvcnQuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUmFuDQoNCg0KDQoNCg0KDQoNCu+8 je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8je+8 je+8je+8je+8je+8je+8je+8je+8je+8je+8jQ0KDQrljp/lp4vpgq7ku7blj5Hku7bkurrvvJog PHNoYXJlc0BuZHpoLmNvbT7mlLbku7bkurrvvJo8dHJpbGxAaWV0Zi5vcmc+5oqE6YCB5Lq677ya PHRyaWxsLWNoYWlyc0BpZXRmLm9yZz4gPGRyYWZ0LWlldGYtdHJpbGwtc21hcnQtZW5kbm9kZXNA aWV0Zi5vcmc+5pelIOacnyDvvJoyMDE35bm0MDXmnIgzMeaXpSAyMjoxNeS4uyDpopgg77yaW3Ry aWxsXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi10cmlsbC1zbWFydC1lbmRub2RlcyAgKDUvMzEgdG8g Ni8xMykNCg0KDQoNCg0KDQpUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMQyBmb3IgZHJhZnQtaWV0 Zi10cmlsbC1zbWFydC1lbmRub2RlcywgYW5kIHlvdSBjYW4gIHNlZSB0aGUgZHJhZnQgYXQ6DQoN Cg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmlsbC1zbWFy dC1lbmRub2Rlcy8NCg0KDQogDQoNCg0KRHVlIHRvIG15IGVycm9ycywgdGhpcyBXRyBMQyBoYXMg YmVlbiBkZWxheWVkLiAgV2Ugd2lsbCBiZSBydW5uaW5nIHRoaXMgV0cgTEMgaW4gcGFyYWxsZWwg d2l0aCB0aGUgSVBSIGNhbGwuICBUaGUgYXV0aG9ycyAoUmFkaWEsIEZhbmd3ZWksIERvbmFsZCwg S2VzYXZhLCBUaW5nKSBzaG91bGQgc2VuZCB0aGVpciBJUFIgc3RhdGVtZW50cyBieSA2LzUuIElm IHRoZSBJUFIgc3RhdGVtZW50cyBhcmUgbm90IHJlY2VpdmVkLCB3ZSB3aWxsIG5lZWQgdG8gZXh0 ZW5kIHRoZSBXRyBMQy4NCg0KDQogDQoNCg0KRm9yIHRoaXMgV0csIHBsZWFzZSBjb25zaWRlciB0 aGUgZm9sbG93aW5nIHF1ZXN0aW9uczoNCg0KDQogDQoNCg0KMSkgICAgICBEb2VzIHRoZSBkcmFm dC1pZXRmLXRyaWxsLXNtYXJ0LWVuZG5vZGVzIHByb3ZpZGUgYSBnb29kIHNvbHV0aW9uIGZvciB0 aGUgcHJvYmxlbSBvZiB0aGUgc2l6ZSBhbmQgZnJlc2huZXNzIG9mIHRoZSBlbmRub2RlIGxlYXJu aW5nIHRhYmxlIGluIGVkZ2UgUkJyaWRnZXMgYnkgYWxsb3dpbmcgZW5kbm9kZXMgdG8gdm9sdW50 ZWVyIGZvciBlbmRub2RlIGxlYXJuaW5nIGFuZCBlbmNhcHN1bGF0aW9uL2RlY2Fwc3VsYXRpb24/ DQoNCg0KMikgICAgICBEbyB5b3Uga25vdyBvZiBhbnkgc2l0dWF0aW9ucyB3aGVyZSBkZXBsb3lt ZW50IG9mIHRoaXMgdGVjaG5vbG9neSB3aWxsIGJlIGhlbHBmdWw/DQoNCg0KMykgICAgICBJcyB0 aGlzIHRlY2hub2xvZ3kgYW5kIHRoaXMgZHJhZnQgcmVhZHkgZm9yIElFU0cgcHVibGljYXRpb24/ DQoNCg0KIA0KDQoNClN1ZSBIYXJlcw== --=====_003_next===== Content-Transfer-Encoding: base64 Content-Type: text/html ; charset="UTF-8" PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPiA8cD5ZZXMvc3VwcG9ydC48YnI+PC9wPjxwPjxicj48 L3A+PHA+UmVnYXJkcyw8L3A+PHA+UmFuPC9wPjxwPjxicj48L3A+PHA+PGJyPjwvcD48cD7vvI3v vI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3v vI3vvI3vvI3vvI3vvI3vvI3vvI3vvI3vvI08L3A+PHA+5Y6f5aeL6YKu5Lu2PHNwYW4gbGFuZ3Vh Z2UtZGF0YT0iSGlzdG9yeVNlbmRlclR4dCIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7 b3V0bGluZTogMHB4ICFpbXBvcnRhbnQ7Zm9udC13ZWlnaHQ6IDcwMCI+5Y+R5Lu25Lq677yaPC9z cGFuPjxzcGFuIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94O291dGxpbmU6IDBweCAhaW1w b3J0YW50O3BhZGRpbmc6IDBweCA1cHg7b3ZlcmZsb3c6IGhpZGRlbjt0ZXh0LW92ZXJmbG93OiBl bGxpcHNpcztkaXNwbGF5OiBpbmxpbmUiPiZuYnNwOyZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7Ozwv c3Bhbj48c3BhbiBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5VE9UeHQiIHN0eWxlPSJib3gtc2l6aW5n OiBib3JkZXItYm94O291dGxpbmU6IDBweCAhaW1wb3J0YW50O2ZvbnQtd2VpZ2h0OiA3MDAiPuaU tuS7tuS6uu+8mjwvc3Bhbj48c3BhbiBjbGFzcz0iIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVy LWJveDtvdXRsaW5lOiAwcHggIWltcG9ydGFudDtkaXNwbGF5OiBpbmxpbmUiPiZsdDt0cmlsbEBp ZXRmLm9yZyZndDs7PC9zcGFuPjxzcGFuIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlDQ1R4dCIgc3R5 bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7b3V0bGluZTogMHB4ICFpbXBvcnRhbnQ7Zm9udC13 ZWlnaHQ6IDcwMCI+5oqE6YCB5Lq677yaPC9zcGFuPjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJib3gt c2l6aW5nOiBib3JkZXItYm94O291dGxpbmU6IDBweCAhaW1wb3J0YW50O2Rpc3BsYXk6IGlubGlu ZSI+Jmx0O3RyaWxsLWNoYWlyc0BpZXRmLm9yZyZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSIiIHN0 eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94O291dGxpbmU6IDBweCAhaW1wb3J0YW50O2Rpc3Bs YXk6IGlubGluZSI+Jm5ic3A7Jmx0O2RyYWZ0LWlldGYtdHJpbGwtc21hcnQtZW5kbm9kZXNAaWV0 Zi5vcmcmZ3Q7Ozwvc3Bhbj48c3BhbiBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5RGF0ZVR4dCIgc3R5 bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7b3V0bGluZTogMHB4ICFpbXBvcnRhbnQ7Zm9udC13 ZWlnaHQ6IDcwMCI+5pelIOacnyDvvJo8L3NwYW4+PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImJveC1z aXppbmc6IGJvcmRlci1ib3g7b3V0bGluZTogMHB4ICFpbXBvcnRhbnQiPjIwMTflubQwNeaciDMx 5pelIDIyOjE1PC9zcGFuPjxzcGFuIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlTdWJqZWN0VHh0IiBz dHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDtvdXRsaW5lOiAwcHggIWltcG9ydGFudDtmb250 LXdlaWdodDogNzAwIj7kuLsg6aKYIO+8mjwvc3Bhbj48c3BhbiBzdHlsZT0iYm94LXNpemluZzog Ym9yZGVyLWJveDtmb250LXdlaWdodDogNjAwO291dGxpbmU6IDBweCAhaW1wb3J0YW50Ij48c3Bh biBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDtvdXRsaW5lOiAwcHggIWltcG9ydGFudCI+ W3RyaWxsXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi10cmlsbC1zbWFydC1lbmRub2RlcyAmbmJzcDso NS8zMSB0byA2LzEzKTwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3Jk ZXItYm94O21hcmdpbi10b3A6IDBweDttYXJnaW4tYm90dG9tOiAwcHg7cGFkZGluZzogOHB4IDI0 cHg7bGluZS1oZWlnaHQ6IDI0cHg7bWluLWhlaWdodDogMTRweDtmb250LWZhbWlseTogQXJpYWws IOWui+S9kywgJ01pY3Jvc29mdCBZYWhlaScsICdMdWNpZGEgR3JhbmRlJywgVmVyZGFuYSwgTHVj aWRhLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7Zm9udC1zaXplOiAxNnB4O3doaXRlLXNwYWNlOiBu b3JtYWw7b3V0bGluZTogMHB4ICFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpIj48YnIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7b3V0bGluZTogMHB4 ICFpbXBvcnRhbnQiPjwvcD48cCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDttYXJnaW4t dG9wOiAwcHg7bWFyZ2luLWJvdHRvbTogMHB4O21pbi1oZWlnaHQ6IDE0cHg7b3V0bGluZTogMHB4 ICFpbXBvcnRhbnQiPlRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExDIGZvciBkcmFmdC1pZXRmLXRy aWxsLXNtYXJ0LWVuZG5vZGVzLCBhbmQgeW91IGNhbiZuYnNwOyBzZWUgdGhlIGRyYWZ0IGF0Ojwv cD48cCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDttYXJnaW4tdG9wOiAwcHg7bWFyZ2lu LWJvdHRvbTogMHB4O21pbi1oZWlnaHQ6IDE0cHg7b3V0bGluZTogMHB4ICFpbXBvcnRhbnQiPjxh IHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDtvdXRsaW5lOiAw cHggIWltcG9ydGFudDtjb2xvcjogcmdiKDAsIDAsIDI1NSk7Y3Vyc29yOiBwb2ludGVyO2JhY2tn cm91bmQtY29sb3I6IHRyYW5zcGFyZW50IiBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXRyaWxsLXNtYXJ0LWVuZG5vZGVzLyI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmlsbC1zbWFydC1lbmRub2Rlcy88L2E+PC9w PjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94O21hcmdpbi10b3A6IDBweDttYXJnaW4t Ym90dG9tOiAwcHg7bWluLWhlaWdodDogMTRweDtvdXRsaW5lOiAwcHggIWltcG9ydGFudCI+Jm5i c3A7PC9wPjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94O21hcmdpbi10b3A6IDBweDtt YXJnaW4tYm90dG9tOiAwcHg7bWluLWhlaWdodDogMTRweDtvdXRsaW5lOiAwcHggIWltcG9ydGFu dCI+RHVlIHRvIG15IGVycm9ycywgdGhpcyBXRyBMQyBoYXMgYmVlbiBkZWxheWVkLiZuYnNwOyBX ZSB3aWxsIGJlIHJ1bm5pbmcgdGhpcyBXRyBMQyBpbiBwYXJhbGxlbCB3aXRoIHRoZSBJUFIgY2Fs bC4mbmJzcDsgVGhlIGF1dGhvcnMgKFJhZGlhLCBGYW5nd2VpLCBEb25hbGQsIEtlc2F2YSwgVGlu Zykgc2hvdWxkIHNlbmQgdGhlaXIgSVBSIHN0YXRlbWVudHMgYnkgNi81LiBJZiB0aGUgSVBSIHN0 YXRlbWVudHMgYXJlIG5vdCByZWNlaXZlZCwgd2Ugd2lsbCBuZWVkIHRvIGV4dGVuZCB0aGUgV0cg TEMuPC9wPjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94O21hcmdpbi10b3A6IDBweDtt YXJnaW4tYm90dG9tOiAwcHg7bWluLWhlaWdodDogMTRweDtvdXRsaW5lOiAwcHggIWltcG9ydGFu dCI+Jm5ic3A7PC9wPjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94O21hcmdpbi10b3A6 IDBweDttYXJnaW4tYm90dG9tOiAwcHg7bWluLWhlaWdodDogMTRweDtvdXRsaW5lOiAwcHggIWlt cG9ydGFudCI+Rm9yIHRoaXMgV0csIHBsZWFzZSBjb25zaWRlciB0aGUgZm9sbG93aW5nIHF1ZXN0 aW9uczo8L3A+PHAgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7bWFyZ2luLXRvcDogMHB4 O21hcmdpbi1ib3R0b206IDBweDttaW4taGVpZ2h0OiAxNHB4O291dGxpbmU6IDBweCAhaW1wb3J0 YW50Ij4mbmJzcDs8L3A+PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJib3gtc2l6 aW5nOiBib3JkZXItYm94O21hcmdpbi10b3A6IDBweDttYXJnaW4tYm90dG9tOiAwcHg7bWluLWhl aWdodDogMTRweDtvdXRsaW5lOiAwcHggIWltcG9ydGFudCI+PHNwYW4gc3R5bGU9ImJveC1zaXpp bmc6IGJvcmRlci1ib3g7b3V0bGluZTogMHB4ICFpbXBvcnRhbnQiPjEpPHNwYW4gc3R5bGU9ImJv eC1zaXppbmc6IGJvcmRlci1ib3g7Zm9udC1zdHJldGNoOiBub3JtYWw7Zm9udC1zaXplOiAxNnB4 O2xpbmUtaGVpZ2h0OiBub3JtYWw7Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nO291dGxp bmU6IDBweCAhaW1wb3J0YW50Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 L3NwYW4+PC9zcGFuPkRvZXMgdGhlIGRyYWZ0LWlldGYtdHJpbGwtc21hcnQtZW5kbm9kZXMgcHJv dmlkZSBhIGdvb2Qgc29sdXRpb24gZm9yIHRoZSBwcm9ibGVtIG9mIHRoZSBzaXplIGFuZCBmcmVz aG5lc3Mgb2YgdGhlIGVuZG5vZGUgbGVhcm5pbmcgdGFibGUgaW4gZWRnZSBSQnJpZGdlcyBieSBh bGxvd2luZyBlbmRub2RlcyB0byB2b2x1bnRlZXIgZm9yIGVuZG5vZGUgbGVhcm5pbmcgYW5kIGVu Y2Fwc3VsYXRpb24vZGVjYXBzdWxhdGlvbj88L3A+PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94O21hcmdpbi10b3A6IDBweDttYXJnaW4tYm90 dG9tOiAwcHg7bWluLWhlaWdodDogMTRweDtvdXRsaW5lOiAwcHggIWltcG9ydGFudCI+PHNwYW4g c3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7b3V0bGluZTogMHB4ICFpbXBvcnRhbnQiPjIp PHNwYW4gc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7Zm9udC1zdHJldGNoOiBub3JtYWw7 Zm9udC1zaXplOiAxNnB4O2xpbmUtaGVpZ2h0OiBub3JtYWw7Zm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nO291dGxpbmU6IDBweCAhaW1wb3J0YW50Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPkRvIHlvdSBrbm93IG9mIGFueSBzaXR1YXRpb25z IHdoZXJlIGRlcGxveW1lbnQgb2YgdGhpcyB0ZWNobm9sb2d5IHdpbGwgYmUgaGVscGZ1bD88L3A+ PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94 O21hcmdpbi10b3A6IDBweDttYXJnaW4tYm90dG9tOiAwcHg7bWluLWhlaWdodDogMTRweDtvdXRs aW5lOiAwcHggIWltcG9ydGFudCI+PHNwYW4gc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7 b3V0bGluZTogMHB4ICFpbXBvcnRhbnQiPjMpPHNwYW4gc3R5bGU9ImJveC1zaXppbmc6IGJvcmRl ci1ib3g7Zm9udC1zdHJldGNoOiBub3JtYWw7Zm9udC1zaXplOiAxNnB4O2xpbmUtaGVpZ2h0OiBu b3JtYWw7Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nO291dGxpbmU6IDBweCAhaW1wb3J0 YW50Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPklz IHRoaXMgdGVjaG5vbG9neSBhbmQgdGhpcyBkcmFmdCByZWFkeSBmb3IgSUVTRyBwdWJsaWNhdGlv bj88L3A+PHAgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7bWFyZ2luLXRvcDogMHB4O21h cmdpbi1ib3R0b206IDBweDttaW4taGVpZ2h0OiAxNHB4O291dGxpbmU6IDBweCAhaW1wb3J0YW50 Ij4mbmJzcDs8L3A+PHAgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7bWFyZ2luLXRvcDog MHB4O21hcmdpbi1ib3R0b206IDBweDttaW4taGVpZ2h0OiAxNHB4O291dGxpbmU6IDBweCAhaW1w b3J0YW50Ij5TdWUgSGFyZXM8L3A+PHA+PGJyPjwvcD48cD48YnI+PC9wPjxwPjxicj48L3A+PC9k aXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Wed Jun 21 13:20:12 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CD1129484; Wed, 21 Jun 2017 13:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4xQtTnZcWVh; Wed, 21 Jun 2017 13:20:09 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E505A129493; Wed, 21 Jun 2017 13:20:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.170.81; From: "Susan Hares" To: Cc: , "'Donald Eastlake'" , Date: Wed, 21 Jun 2017 16:14:09 -0400 Message-ID: <013201d2eaca$f131c5b0$d3955110$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0133_01D2EAA9.6A2296B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdLqyqV3MKnGSw9VSV+9DPaY0fDHVA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [trill] IPR call for draft-ietf-trill-p2mp-bfd X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:20:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0133_01D2EAA9.6A2296B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Minqui, Santosh, and Vengad: It appears we did not complete our IPR call for draft-ietf-trill-p2mp-bfd. You please respond this email with your IPR statement about draft-ietf-tyrill-p2mp-bfd? Thank you, Sue Hares ------=_NextPart_000_0133_01D2EAA9.6A2296B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Minqui, =
Santosh, and  Vengad: =

 

It appears we did = not complete our IPR call for draft-ietf-trill-p2mp-bfd.   You = please respond this email with your IPR statement about = draft-ietf-tyrill-p2mp-bfd?

 

Thank you, =

Sue Hares =  

------=_NextPart_000_0133_01D2EAA9.6A2296B0-- From nobody Wed Jun 21 17:54:52 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36E129329; Wed, 21 Jun 2017 17:54:50 -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, HTML_MESSAGE=0.001, 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 VE0CYec4Lp-q; Wed, 21 Jun 2017 17:54:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868DB128D19; Wed, 21 Jun 2017 17:54:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPP11444; Thu, 22 Jun 2017 00:54:40 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 22 Jun 2017 01:54:39 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Wed, 21 Jun 2017 17:54:33 -0700 From: Linda Dunbar To: "shares@ndzh.com" , "trill-chairs@ietf.org" , "trill@ietf.org" Thread-Topic: Re: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13 Thread-Index: AdLq8fG9NByAWQX0R5C1vezVOArd3A== Date: Thu, 22 Jun 2017 00:54:32 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6593D3CAF@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.194.184.2] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6593D3CAFSJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.594B1550.00C5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 42098556a12f186f01bc339d23a20f0b Archived-At: Subject: Re: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13 X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 00:54:50 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F6593D3CAFSJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Linda ________________________________ * From: "Susan Hares" > * To: > * Cc: >, "'= Alia Atlas'" > * Date: Wed, 31 May 2017 14:48:50 -0400 This begins a 2 week WG LC for draft-ietf-trill-ecn-support which can be f= ound at: https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/. The authors (Donald Eastlake and Bob Biscoe) should indicate whether they k= now of any IPR relating to this draft. The TRILL WG should consider the following questions: 1) Does this extension of the ECN to TRILL Switches provide for better Flow control of IP packets without packet drops? And is this useful in TRI= LL deployments? 2) Do you believe this document is ready for RFC publication? Please include the answers to these questions among your comments about thi= s draft. Sue Hares Huawei USA IP Technology Lab 5340 Legacy Drive, Plano, TX 75024 Tel: +1 469-277 - 5840 Fax: +1 469 -277 - 5900 --_000_4A95BA014132FF49AE685FAB4B9F17F6593D3CAFSJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Linda

 

 

 

 

This begins a  2 week WG LC for draft-ietf-trill-ecn-supp= ort which can be found at:

https://datatracker.ietf.org/doc/dr= aft-ietf-trill-ecn-support/.

 

 

The authors (Donald Eastlake and Bob Biscoe) should indicate w= hether they know of any IPR relating to this draft.   

 

The TRILL WG should consider the following questions:

 

1)      Does this extension of the ECN to TRILL Switches provide for bet= ter

Flow control of IP packets without packet drops?  And is = this useful in TRILL deployments?

 

2)      Do you believe this document is ready for RFC publication?

 

Please include the answers to these questions among your comme= nts about this draft.

 

Sue Hares

 

Huawei USA IP Te= chnology Lab

5340 Legacy Driv= e,

Plano, TX 75024<= o:p>

Tel: +1 469-= 277 - 5840

Fax: +1 469 = -277 - 5900

 

--_000_4A95BA014132FF49AE685FAB4B9F17F6593D3CAFSJCEML702CHMchi_-- From nobody Wed Jun 21 18:27:27 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84D1120721; Wed, 21 Jun 2017 18:27:24 -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, HTML_MESSAGE=0.001, 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 FP6F2aJFnoqf; Wed, 21 Jun 2017 18:27:21 -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 5B6B212943B; Wed, 21 Jun 2017 18:27:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIY87242; Thu, 22 Jun 2017 01:27:18 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 22 Jun 2017 02:27:17 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 22 Jun 2017 09:27:10 +0800 From: "Zhangmingui (Martin)" To: Susan Hares , "trill@ietf.org" CC: "trill-chairs@ietf.org" , "'Donald Eastlake'" , "draft-ietf-trill-p2mp-bfd@ietf.org" Thread-Topic: IPR call for draft-ietf-trill-p2mp-bfd Thread-Index: AdLqyqV3MKnGSw9VSV+9DPaY0fDHVAAK5ndw Date: Thu, 22 Jun 2017 01:27:10 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A6537D2A@NKGEML515-MBX.china.huawei.com> References: <013201d2eaca$f131c5b0$d3955110$@ndzh.com> In-Reply-To: <013201d2eaca$f131c5b0$d3955110$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E7A6537D2ANKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.594B1CF6.0135, 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: def5108cebb68777f8ebd5e0643fca0a Archived-At: Subject: Re: [trill] IPR call for draft-ietf-trill-p2mp-bfd X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:27:25 -0000 --_000_4552F0907735844E9204A62BBDD325E7A6537D2ANKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For this draft, I am not aware of any IPR that needs to be disclosed. Thanks, Mingui From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, June 22, 2017 4:14 AM To: trill@ietf.org Cc: trill-chairs@ietf.org; 'Donald Eastlake'; draft-ietf-trill-p2mp-bfd@iet= f.org Subject: IPR call for draft-ietf-trill-p2mp-bfd Minqui, Santosh, and Vengad: It appears we did not complete our IPR call for draft-ietf-trill-p2mp-bfd. = You please respond this email with your IPR statement about draft-ietf-ty= rill-p2mp-bfd? Thank you, Sue Hares --_000_4552F0907735844E9204A62BBDD325E7A6537D2ANKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For this draft, I am not aware of any IPR that needs to be disclo= sed.

 

Thanks,

Mingui

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Thursday, June 22, 2017 4:14 AM
To: trill@ietf.org
Cc: trill-chairs@ietf.org; 'Donald Eastlake'; draft-ietf-trill-p2mp-= bfd@ietf.org
Subject: IPR call for draft-ietf-trill-p2mp-bfd

 

Minqui, Santosh, and  Vengad: 
 

It appears we did not complete = our IPR call for draft-ietf-trill-p2mp-bfd.   You please respond = this email with your IPR statement about draft-ietf-tyrill-p2mp-bfd?

 

Thank you,

Sue Hares  

--_000_4552F0907735844E9204A62BBDD325E7A6537D2ANKGEML515MBXchi_-- From nobody Wed Jun 21 20:24:33 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0DC1294A4; Wed, 21 Jun 2017 20:24:31 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMyttOxnNy81; Wed, 21 Jun 2017 20:24:29 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 015B5126CD6; Wed, 21 Jun 2017 20:24:27 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m47so13535214iti.0; Wed, 21 Jun 2017 20:24:26 -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=A+0VWFQkmcThNAlb/G9a3PdK3L62Vs7S61UQ218T6qA=; b=qqAyYA8YLJdCGItOBEW8EuKoFeFUMe9TTvYtrESt2nC7MUueUSooTEVF45jbpxo7NY 4NhFVU4Ie/Cp2bcfp7G5F/7gFKt6bVCzWKvIk6uGOWJFU+gWx8MuwFItRcUxBkI/fI4s enwZ8Vw3wR7kKS7SuJXCTb6IlrAIriVgikRWWPF3Z+Zx8HkZDWdCycXibVRCb0af7mMa 3O3bN/gpNoaV+ZMrruvpQr87nGgY9+MKKkgCuJrzHJnqaz0mjlETB65Z7NUlWPzjjQr1 GR3qFIZik8ZgTx+xqDfB61gv2vz5PPCgWKQpQJ4k9/gDnZKdqQIemhza8BjBb4YAdELZ B8kw== 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=A+0VWFQkmcThNAlb/G9a3PdK3L62Vs7S61UQ218T6qA=; b=BHJFcrQu7bIy3oFa13uHr0OeCa47yfsuHosgkK+va5G+2jUzcJ9dfwlrMUqbrW0j2O 3EF/jUjcjYEaTpm7dNUN6OT82IbCYZVnbNrSCEO2gOvCPvfcgePbV0JbzH3IbB4P2oDm Yd7QBLHosLO8UM5UT0+Wr3VRlO9FH/c0yE3nEUGRK1yoM+Vj3Wt2/l75ToRGAriVbZHW eb+kZjkaWWCFHZ4GUMqkVvor0JiNEaGOPhKE0yD45iHewHBJPU5bfVAuRHhgKSWGlXgS 6YrrA0gQLlmObn7vhczk4NMwTiQObrKVGKIjgDc2fzCApWxwHIuas9Hpcd8b31YQZ4jx 8dWA== X-Gm-Message-State: AKS2vOwrHKlP0L/B43thh+1w+yvJ2O0cJkEDMi6joJi3dS1pKpoiMM5W H8qVbobf0taea8CWWQVkNcwNcIXwXQ== X-Received: by 10.36.53.70 with SMTP id k67mr21372ita.79.1498101866445; Wed, 21 Jun 2017 20:24:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.152 with HTTP; Wed, 21 Jun 2017 20:24:11 -0700 (PDT) In-Reply-To: <02b301d2da55$4d43a5c0$e7caf140$@ndzh.com> References: <02b301d2da55$4d43a5c0$e7caf140$@ndzh.com> From: Donald Eastlake Date: Wed, 21 Jun 2017 23:24:11 -0400 Message-ID: To: Susan Hares Cc: "trill@ietf.org" , "trill-chairs@ietf.org" , Alia Atlas Content-Type: multipart/alternative; boundary="001a114abeec964e0f05528405c8" Archived-At: Subject: Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 03:24:32 -0000 --001a114abeec964e0f05528405c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I support the adoption of this draft. It does not require any protocol changes and should provide the means to improve the stability of TRILL distribution trees. The draft is simple enough that I believe we can complete the work within a year. 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 On Wed, May 31, 2017 at 5:31 PM, Susan Hares wrote: > This begins a 2 week WG adoption call for draft-rp-trill-parent-selection > from 5/31/2017 to 6/13/2017. You can obtain the draft at: > > https://datatracker.ietf.org/doc/draft-rp-trill-parent-selection/. > > > > The authors should indicate if they know of IPR on this draft. This > should be sent to the WG list within 1 week or the WG adoption or we will > =E2=80=9Cstall=E2=80=9D the WG adoption call waiting for it. (Normally = TRILL authors are > great at responding =E2=80=93 so we are running the IPR and WG Adoption c= all in > parallel). > > > > The TRILL WG group should consider on this information draft if: > > > > > > 1) Is the documentation the known problem in the TRILL tree > construction mechanism and offers an approach requiring no change to the > TRILL > > protocol in order to solve the problem is a useful for TRILL deployments. > > 2) Does this draft document this problem? > > 3) Can we complete this work within 1 year? > > > > > > Sue Hares > > > > > --001a114abeec964e0f05528405c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a114abeec964e0f05528405c8-- From nobody Wed Jun 21 22:04:29 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FC1127A90; Wed, 21 Jun 2017 22:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dPPGZ3u69fCG; Wed, 21 Jun 2017 22:04:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EB21200CF; Wed, 21 Jun 2017 22:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4690; q=dns/txt; s=iport; t=1498107866; x=1499317466; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y6YEyyy6KtdNDOFUUJiMvWlm8bgFTmyqoLDcYgWmTJ0=; b=JnYmTah8qzejbzsP0DBf08ZSxdNVkZsRV8PrFGGX3wShXWssmKJgzuBG I71Cu/Q3H1TOjPNjgZkJqWKrvEu5eqiS7CInfJ6sKZgSKggZBLK6KPMNM Z/ovOEujUbUxyLihQqqtzqZw/7zb7TmR8M1gE5Z5F+vLzhwSJ3TNIGQ9n c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAACfTktZ/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9pYoENB41+kV6ILIgihSqCEYYkAoJ2PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMdEEwQAgEIDgMEAQEoByERFAkIAQEEDgUIiUBMAxWtVoczDYQmAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYZthFA0gleBZBIBUoU+BZ4oOwKOeYReghKFSIo?= =?us-ascii?q?+i1+JNgEfOH8LdBWFVhyBZnaHLYEjgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,371,1493683200"; d="scan'208,217";a="259128820" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jun 2017 05:04:25 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5M54P18005768 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Jun 2017 05:04:25 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 22 Jun 2017 00:04:25 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Thu, 22 Jun 2017 00:04:25 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Susan Hares CC: "trill-chairs@ietf.org" , "'Donald Eastlake'" , "draft-ietf-trill-p2mp-bfd@ietf.org" , "trill@ietf.org" Thread-Topic: IPR call for draft-ietf-trill-p2mp-bfd Thread-Index: AdLqyqV3MKnGSw9VSV+9DPaY0fDHVAASkZkQ Date: Thu, 22 Jun 2017 05:04:24 +0000 Message-ID: <1a7f335863df43f0a0bedba8586be615@XCH-RCD-020.cisco.com> References: <013201d2eaca$f131c5b0$d3955110$@ndzh.com> In-Reply-To: <013201d2eaca$f131c5b0$d3955110$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.25.136] Content-Type: multipart/alternative; boundary="_000_1a7f335863df43f0a0bedba8586be615XCHRCD020ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [trill] IPR call for draft-ietf-trill-p2mp-bfd X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 05:04:28 -0000 --_000_1a7f335863df43f0a0bedba8586be615XCHRCD020ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Susan, Am not aware of any IPR related to this draft. Thanks Prasad From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, June 22, 2017 1:44 AM To: trill@ietf.org Cc: trill-chairs@ietf.org; 'Donald Eastlake' ; draft-ietf= -trill-p2mp-bfd@ietf.org Subject: IPR call for draft-ietf-trill-p2mp-bfd Minqui, Santosh, and Vengad: It appears we did not complete our IPR call for draft-ietf-trill-p2mp-bfd. = You please respond this email with your IPR statement about draft-ietf-ty= rill-p2mp-bfd? Thank you, Sue Hares --_000_1a7f335863df43f0a0bedba8586be615XCHRCD020ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Susan,

  Am not aware of= any IPR related to this draft.

Thanks

Prasad

 

From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, June 22, 2017 1:44 AM
To: trill@ietf.org
Cc: trill-chairs@ietf.org; 'Donald Eastlake' <d3e3e3@gmail.com>= ;; draft-ietf-trill-p2mp-bfd@ietf.org
Subject: IPR call for draft-ietf-trill-p2mp-bfd

 

Minqui, Santosh, and  Vengad: <=
/o:p>
 

It appears we did not complete our IPR call for draf= t-ietf-trill-p2mp-bfd.   You please respond this email with your = IPR statement about draft-ietf-tyrill-p2mp-bfd?

 

Thank you,

Sue Hares  

--_000_1a7f335863df43f0a0bedba8586be615XCHRCD020ciscocom_-- From nobody Thu Jun 22 02:07:21 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA868128B8E; Thu, 22 Jun 2017 02:07:15 -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, HTML_MESSAGE=0.001, 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 gNSkH3WDE6vk; Thu, 22 Jun 2017 02:07:09 -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 20C5D128B51; Thu, 22 Jun 2017 02:07:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIZ45928; Thu, 22 Jun 2017 09:07:05 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 22 Jun 2017 10:07:05 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 22 Jun 2017 17:06:57 +0800 From: Haoweiguo To: Susan Hares , "trill@ietf.org" CC: "trill-chairs@ietf.org" , "draft-ietf-trill-smart-endnodes@ietf.org" Thread-Topic: [trill] WG LC for draft-ietf-trill-smart-endnodes (5/31 to 6/13) Thread-Index: AQHS2kBAfy91VNupB0eCiHTtJI/UxKIwt9kg Date: Thu, 22 Jun 2017 09:06:57 +0000 Message-ID: References: <010e01d2da17$93a4cdc0$baee6940$@ndzh.com> In-Reply-To: <010e01d2da17$93a4cdc0$baee6940$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.23.94] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB55173366094448nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.594B88BA.0085, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 963306f606ff3a537f733f87dca64a71 Archived-At: Subject: [trill] =?gb2312?b?tPC4tDogIFdHIExDIGZvciBkcmFmdC1pZXRmLXRyaWxs?= =?gb2312?b?LXNtYXJ0LWVuZG5vZGVzICAoNS8zMSB0byA2LzEzKQ==?= X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 09:07:16 -0000 --_000_DD5FC8DE455C3348B94340C0AB55173366094448nkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCB0aGUgYWRvcHRpb24uDQp3ZWlndW8NCg0Kt6K8/sjLOiBTdXNhbiBIYXJlcyBbbWFp bHRvOnNoYXJlc0BuZHpoLmNvbV0NCreiy83KsbzkOiAyMDE3xOo11MIzMcjVIDIyOjEwDQrK1bz+ yMs6IHRyaWxsQGlldGYub3JnDQqzrcvNOiB0cmlsbC1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtdHJpbGwtc21hcnQtZW5kbm9kZXNAaWV0Zi5vcmcNCtb3zOI6IFt0cmlsbF0gV0cgTEMgZm9y IGRyYWZ0LWlldGYtdHJpbGwtc21hcnQtZW5kbm9kZXMgKDUvMzEgdG8gNi8xMykNCg0KVGhpcyBi ZWdpbnMgYSAyIHdlZWsgV0cgTEMgZm9yIGRyYWZ0LWlldGYtdHJpbGwtc21hcnQtZW5kbm9kZXMs IGFuZCB5b3UgY2FuICBzZWUgdGhlIGRyYWZ0IGF0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi10cmlsbC1zbWFydC1lbmRub2Rlcy8NCg0KRHVlIHRvIG15IGVy cm9ycywgdGhpcyBXRyBMQyBoYXMgYmVlbiBkZWxheWVkLiAgV2Ugd2lsbCBiZSBydW5uaW5nIHRo aXMgV0cgTEMgaW4gcGFyYWxsZWwgd2l0aCB0aGUgSVBSIGNhbGwuICBUaGUgYXV0aG9ycyAoUmFk aWEsIEZhbmd3ZWksIERvbmFsZCwgS2VzYXZhLCBUaW5nKSBzaG91bGQgc2VuZCB0aGVpciBJUFIg c3RhdGVtZW50cyBieSA2LzUuIElmIHRoZSBJUFIgc3RhdGVtZW50cyBhcmUgbm90IHJlY2VpdmVk LCB3ZSB3aWxsIG5lZWQgdG8gZXh0ZW5kIHRoZSBXRyBMQy4NCg0KRm9yIHRoaXMgV0csIHBsZWFz ZSBjb25zaWRlciB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczoNCg0KDQoxKSAgICAgIERvZXMgdGhl IGRyYWZ0LWlldGYtdHJpbGwtc21hcnQtZW5kbm9kZXMgcHJvdmlkZSBhIGdvb2Qgc29sdXRpb24g Zm9yIHRoZSBwcm9ibGVtIG9mIHRoZSBzaXplIGFuZCBmcmVzaG5lc3Mgb2YgdGhlIGVuZG5vZGUg bGVhcm5pbmcgdGFibGUgaW4gZWRnZSBSQnJpZGdlcyBieSBhbGxvd2luZyBlbmRub2RlcyB0byB2 b2x1bnRlZXIgZm9yIGVuZG5vZGUgbGVhcm5pbmcgYW5kIGVuY2Fwc3VsYXRpb24vZGVjYXBzdWxh dGlvbj8NCg0KMikgICAgICBEbyB5b3Uga25vdyBvZiBhbnkgc2l0dWF0aW9ucyB3aGVyZSBkZXBs b3ltZW50IG9mIHRoaXMgdGVjaG5vbG9neSB3aWxsIGJlIGhlbHBmdWw/DQoNCjMpICAgICAgSXMg dGhpcyB0ZWNobm9sb2d5IGFuZCB0aGlzIGRyYWZ0IHJlYWR5IGZvciBJRVNHIHB1YmxpY2F0aW9u Pw0KDQpTdWUgSGFyZXMNCg== --_000_DD5FC8DE455C3348B94340C0AB55173366094448nkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support the adoption.

weiguo

 

=B7=A2=BC=FE=C8=CB: Susan H= ares [mailto:shares@ndzh.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2017=C4=EA5=D4=C231=C8=D5 22:10
=CA=D5=BC=FE=C8=CB: trill@ietf.org
=B3=AD=CB=CD: trill-chairs@ietf.org; draft-ietf-trill-smart-endnodes@ietf.org
=D6=F7=CC=E2: [trill] WG LC for draft-ietf-trill-smart-endnodes (5/31 to 6/13)

 

This begins a 2 week WG LC for = draft-ietf-trill-smart-endnodes, and you can  see the draft at:

https://datatracker.ietf.org= /doc/draft-ietf-trill-smart-endnodes/

 

Due to my errors, this WG LC ha= s been delayed.  We will be running this WG LC in parallel with the IP= R call.  The authors (Radia, Fangwei, Donald, Kesava, Ting) should sen= d their IPR statements by 6/5. If the IPR statements are not received, we will need to extend the WG LC.

 

For this WG, please consider th= e following questions:

 

1) &nbs= p;    Does the draft-ietf-tri= ll-smart-endnodes provide a good solution for the problem of the size and f= reshness of the endnode learning table in edge RBridges by allowing endnode= s to volunteer for endnode learning and encapsulation/decapsulation?

2) &nbs= p;    Do you know of any situ= ations where deployment of this technology will be helpful?

3) &nbs= p;    Is this technology and = this draft ready for IESG publication?

 

Sue Hares

--_000_DD5FC8DE455C3348B94340C0AB55173366094448nkgeml513mbxchi_-- From agrawalsameer@gmail.com Thu Jun 22 10:27:53 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C37F129AF9 for ; Thu, 22 Jun 2017 10:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 TmIXgbcgLrw4 for ; Thu, 22 Jun 2017 10:27:51 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 6565A1293F2 for ; Thu, 22 Jun 2017 10:27:51 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id h134so18962601iof.2 for ; Thu, 22 Jun 2017 10:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7Qbl0/TnJXOalqv25J+K2XzNnJNei7AvlTnlMpDe+sw=; b=YcFt+E1XmrxU/6TvBXg3yIFEge2Sb3uTgf2xKpOC6b1LdwEDqRO2jti0ZUNG/YQaeQ LzZ02jLVtDkVZV4Sly4iGJFwcxlsca2f5Xkh+HCW6uQ6xbVak0188kXJcE2XqGAH5W1H Gfrs4t3OBnfzRFz7pz+xMn2S/AaX5q4znh7XD0X/Jf8rdFtFLqUOcd8OJPiZIebM88ol W8HRan1I0u7raxZ0HrYhnCsuzDMTorvxf4+oXIaPldlJzQxLXYgrQ7bdCVQGpktmn28I kLDWxlD9XvIB0ZWWy6uaw3yNOCS9BA3SqQHJHpo0kLG3U7iskFEWdMjbd4equgRObgid uHRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7Qbl0/TnJXOalqv25J+K2XzNnJNei7AvlTnlMpDe+sw=; b=Dpl+lQq4RrZld1nAitBfIcm2S2aZ6yfXwOunFoKfeiO97PEfPx6njZFJ9hI8aCQUU7 L0HPMzt2JQgV68Wz2+sU+ozH0opqYEnzjOYexKLZRkAq72vkoQqNCGKkW4YEvB3VBl+x 5bBvyCygCovA7WkMx+d++TGmVnv9fl88HAaQSeT8Ky3kyb8sK5nqUx3/Rtqq+6yeeT7u 7mtuvEh6/4UXAs0wSzHZ7ULKeA2pz4iLs3N0i/jXSVw+8semwmxBLdFiMaFkNU+/cJ0s 69XoWauPVp9rwZ9LAnNmwm31QCEchFPqlhdQ8UZXSxR5RkeTdJ3aHKIMhVSQ3not6jIP NjJA== X-Gm-Message-State: AKS2vOyh5D9srjJQionT6MrYgPQBhYlMYu5rr95Q1C1+UdgBdYGXdC8i TrLS5ljrxwbTTbNsgG3bBTrazYmW1nLY X-Received: by 10.107.166.130 with SMTP id p124mr3412080ioe.15.1498152470612; Thu, 22 Jun 2017 10:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.36.206 with HTTP; Thu, 22 Jun 2017 10:27:50 -0700 (PDT) From: Sameer Agrawal Date: Thu, 22 Jun 2017 10:27:50 -0700 Message-ID: To: trill@ietf.org Content-Type: multipart/alternative; boundary="001a11351554d4b6ae05528fcd54" Archived-At: Subject: Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 17:29:51 -0000 --001a11351554d4b6ae05528fcd54 Content-Type: text/plain; charset="UTF-8" Hi,I support this draft. Thanks, Sameer Agrawal [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) "Susan Hares" Wed, 31 May 2017 21:37 UTCShow header This begins a 2 week WG adoption call for draft-rp-trill-parent-selection from 5/31/2017 to 6/13/2017. You can obtain the draft at: https://datatracker.ietf.org/doc/draft-rp-trill-parent-selection/. The authors should indicate if they know of IPR on this draft. This should be sent to the WG list within 1 week or the WG adoption or we will "stall" the WG adoption call waiting for it. (Normally TRILL authors are great at responding - so we are running the IPR and WG Adoption call in parallel). The TRILL WG group should consider on this information draft if: 1) Is the documentation the known problem in the TRILL tree construction mechanism and offers an approach requiring no change to the TRILL protocol in order to solve the problem is a useful for TRILL deployments. 2) Does this draft document this problem? 3) Can we complete this work within 1 year? Sue Hares Replies: - Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) "R. Parameswaran" - Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) Donald Eastlake --001a11351554d4b6ae05528fcd54 Content-Type: text/html; charset="UTF-8"

Hi,

I support this draft.

Thanks,

Sameer Agrawal

[trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13)

"Susan Hares" <shares@ndzh.com> Wed, 31 May 2017 21:37 UTCShow header 

This begins a 2 week WG adoption call for draft-rp-trill-parent-selection
from 5/31/2017 to 6/13/2017.  You can obtain the draft at:  

https://datatracker.ietf.org/doc/draft-rp-trill-parent-selection/.

 

The authors should indicate if they know of IPR on this draft.  This should
be sent to the WG list within 1 week or the WG adoption or we will "stall"
the WG adoption call waiting for it.   (Normally TRILL authors are great at
responding - so we are running the IPR and WG Adoption call in parallel). 

 

The TRILL WG group should consider on this information draft if: 

 

 

1)      Is the documentation the known problem in the TRILL tree
construction mechanism and offers an approach requiring no change to the
TRILL 

protocol in order to solve the problem is a useful for TRILL deployments.

2)      Does this draft document this problem? 

3)      Can we complete this work within 1 year? 

 

 

Sue Hares
--001a11351554d4b6ae05528fcd54-- From ncao007@gmail.com Thu Jun 22 11:01:10 2017 Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75670129B17 for ; Thu, 22 Jun 2017 11:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sst7NydAn2oh for ; Thu, 22 Jun 2017 11:01:08 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC12129420 for ; Thu, 22 Jun 2017 11:01:08 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id p187so13341668oif.3 for ; Thu, 22 Jun 2017 11:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=7IuIICeEqWUYRx1QrAoNFfzq2ErS/+7bd01XuT2oDn0=; b=Mvj4lM41zC5ZyuKxRwNPnzqNSTwu/SUEE5fH784DhRyP4NufEzPRc8dyOlrLTLNPLR vSfFRkHl3QNp80NAFFo1d2He7+6DUVLsFp2X8k+kYGool6TJA9jjo6ThQe3NelfPkHdk pqdz88EDXwA/4EiH6M5QHWvFjL/rIpSR0Fmigu2H0Xv7B1RBSMjJ54JhWnO1Jdb27Skx Lmg2XAKEC0AuiCe0p8IflFS4iaXUHeKdDciPTPkXwrQpbcQ5M8hsa4AcFcYimpFoc/Jk wj4dqpkPkobBruXyD/Rpa4AzxNaMFSbA9Gtsvg0s9Q9xiUg+zpeb7gEv9YzICC0siv0X Thmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=7IuIICeEqWUYRx1QrAoNFfzq2ErS/+7bd01XuT2oDn0=; b=KgMVUKh7ypmQrs0H7TECD4GDDsn7rOzrIfx48vxS/pp82ytjZAmY5m4S4sAgGcntS5 ZtuC26H1FYc7LVBq02BsuVpaQJyC/Uhk1w+RGnWuaa1QsB6v3JuoHf5W4AVAO6P91nGf /XaR+9RTNtf9Gqb22V2LJlAyEXQ8QfIq8g5IOCHuecu9NFxZCzod2rZfN7Xgsqk2Qaq+ EwiUlh/DWaKgxPgGT3UKqfOeR7ycQqoE6kWJ28mWwl9z2sgz+cKUxbcpZfb0NH4ZZ2lz 4a3DwU+50AgdBZFuD0uUcU+a0oHkLDQaPCsxSj97bu4a51M7KVwWURW+iWdMyjODU7nB DzFg== X-Gm-Message-State: AKS2vOxunOJLw5lCdF7aFZ4U3zTHYhBHk2mMSgj3wxJy7FeEA+0MEuW6 I8EBTuyucVzHlSMx2DQV4uRzxLJqkOX7 X-Received: by 10.202.61.68 with SMTP id k65mr1723972oia.180.1498154467074; Thu, 22 Jun 2017 11:01:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.6.137 with HTTP; Thu, 22 Jun 2017 11:01:06 -0700 (PDT) From: Nelson Cao Date: Thu, 22 Jun 2017 11:01:06 -0700 Message-ID: To: trill@ietf.org Cc: Nelson Cao Content-Type: multipart/alternative; boundary="001a113ccae2d43d15055290446c" Archived-At: Subject: Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 18:01:50 -0000 --001a113ccae2d43d15055290446c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I support the adoption of this draft. Thanks, Nelson [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13) "Susan Hares" Wed, 31 May 2017 21:37 UTCShow header This begins a 2 week WG adoption call for draft-rp-trill-parent-selection from 5/31/2017 to 6/13/2017. You can obtain the draft at: https://datatracker.ietf.org/doc/draft-rp-trill-parent-selection/ . The authors should indicate if they know of IPR on this draft. This should be sent to the WG list within 1 week or the WG adoption or we will "stall" the WG adoption call waiting for it. (Normally TRILL authors are great at responding - so we are running the IPR and WG Adoption call in parallel). The TRILL WG group should consider on this information draft if: 1) Is the documentation the known problem in the TRILL tree construction mechanism and offers an approach requiring no change to the TRILL protocol in order to solve the problem is a useful for TRILL deployments. 2) Does this draft document this problem? 3) Can we complete this work within 1 year? Sue Hares --001a113ccae2d43d15055290446c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi,
I support the adoption of this draft.<=
/span>
Thanks,
Nelson



[trill] 2 week Adoption
call for draft-rp-trill-parent-selection (5/31 to 6/13)=




"Susa=
n Hares" Wed, 31 May 2017 21:37 UTCShow header



This begins a 2 week WG adoption call =
for draft-rp-trill-parent-selection
<=
pre style=3D"margin-bottom:7.5pt;background-image:initial;background-positi=
on:initial;background-size:initial;background-repeat:initial;background-ori=
gin:initial;background-clip:initial">from 5/31/2017 to 6/13/2017.=C2=A0 You can obtain the dr=
aft at: =C2=A0
=C2=A0
htt=
ps://datatracker.ietf.org/doc/draft-rp-trill-parent-selection/.<=
span>
 
=C2=A0
= 
=C2=A0
The authors should indicate if they know of IPR on t=
his draft.=C2=A0 This should
be sent to the WG list within 1 week or the WG adoption or we w=
ill "stall"
the WG adoption call waiting for it.=C2=A0=C2=A0 (Normally TRILL autho=
rs are great at
r=
esponding - so we are running the IPR and WG Adoption call in parallel). 
=
=C2=A0
=C2=A0
=C2=A0
The TRILL WG group should consider on this infor=
mation draft if: 
=C2=A0
=C2=A0
<=
span style=3D"font-family:Consolas;color:rgb(51,51,51)">=C2=A0=

=C2=A0
=C2=A0=

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is the documenta=
tion the known problem in the TRILL tree
construction mechanism and offers an approach requi=
ring no change to the
TRILL 
=C2=A0
protocol in ord=
er to solve the problem is a useful for TRILL deployments.
 
2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Does this draft=
 document this problem? 
=C2=A0
=
3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Can we complete this work within 1 year? <=
span>
=C2=A0
=C2=A0<=
/pre>
=C2=A0
=C2=A0
=C2=A0
Sue Hares 


--001a113ccae2d43d15055290446c--


From mriyaz@gmail.com  Thu Jun 22 13:17:03 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B13D1270FC for ; Thu, 22 Jun 2017 13:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Hr1B4TwQCyfP for ; Thu, 22 Jun 2017 13:17:01 -0700 (PDT)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81473126D46 for ; Thu, 22 Jun 2017 13:17:01 -0700 (PDT)
Received: by mail-yb0-x235.google.com with SMTP id f192so7991437yba.2 for ; Thu, 22 Jun 2017 13:17:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=GKxcTiWKpdbVYfbjmBcrQOKo+AjwdlSbtn9PQkZ/VXw=; b=axhDN3VM36+0lXxlJZtOFLMzRM8wAmPkFmP2x2HRMEvogyHcyeX2bzPzvOBASTZGvT +BbnukCDhBB6YD9RK5U3aNbLbxZoKnBem/5sMJRDyMjmBuueT33VLMZo4biuYR0mlctY mWIREsh6V/T6gOgtmxPX/UcSY4VmZDYYHRvvrxE859568O9z980oWpd5D14aZe5wmVzU p+h0QY3efUFYEwLtrHPO+q+JRWxN2QOVjGwiXdMhZPrnd/2v8J37FcVoU3lsjk9YqphC esVTl+Uz7Xellf/ErFmBblTARBF+2rN0OwHKD1mOjNz9j2P2+nQUWLoQ4Gvi4+ClnAMl kqdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GKxcTiWKpdbVYfbjmBcrQOKo+AjwdlSbtn9PQkZ/VXw=; b=EgYS/BTgyEvT0cKlIPCP7xoXiOm8TZXnDpPLjAz5XQGEynGmlyZ+aZP9n9U6ZJTOKU ZwWM4ibVipPd/GHyy4XUcZaU9TPiD+M1XmLZIpGGea7Q1AcyGKw7MaabfvGPXDVuif0o /pdFBDxZMS8PfsC8MHGRoxsUUY8rBZya2Fhk/sWHCW7446+VINmX+gULFSz9X4+h2zFa UzOTaT5iH4iCOGknbIaGTwrBjExN3A3YK/rMIT6t4HEnSYwVkcb6Qg10ggbNjucdmXGI XBaAkaSykEwi41IlNNwe+qM55QgspSqD8MhZij56NztuL0PoyawDThCZSsjwY1epTVbC DpsA==
X-Gm-Message-State: AKS2vOzXSWYJY0FNcdh83COOd28E51gelfTuQffeqiS4fIcQJwBKni82 otkVRncDt9D/n43b1iGbPMKzION7z2/yEIg=
X-Received: by 10.37.173.6 with SMTP id y6mr3324785ybi.117.1498162620464; Thu, 22 Jun 2017 13:17:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.231.193 with HTTP; Thu, 22 Jun 2017 13:17:00 -0700 (PDT)
From: Mohamed Riyaz 
Date: Thu, 22 Jun 2017 13:17:00 -0700
Message-ID: 
To: trill@ietf.org
Content-Type: multipart/alternative; boundary="f403045da416cf2e290552922a33"
Archived-At: 
Subject: Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Jun 2017 20:17:26 -0000

--f403045da416cf2e290552922a33
Content-Type: text/plain; charset="UTF-8"

 Hello,

Support this draft.

Thanks
-Riyaz


Sameer Agrawal  Thu, 22 June 2017 17:27 UTCShow
header 

 Hi,I support this draft.

Thanks,

Sameer Agrawal
[trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to
6/13)

"Susan Hares"  ; Wed, 31 May 2017
21:37 UTCShow header


This begins a 2 week WG adoption call for draft-rp-trill-parent-selection
from 5/31/2017 to 6/13/2017.  You can obtain the draft
at:https://datatracker.ietf.org/doc/draft-rp-trill-parent-selection/.



The authors should indicate if they know of IPR on this draft.  This should
be sent to the WG list within 1 week or the WG adoption or we will "stall"
the WG adoption call waiting for it.   (Normally TRILL authors are great at
responding - so we are running the IPR and WG Adoption call in parallel).



The TRILL WG group should consider on this information draft if:





1)      Is the documentation the known problem in the TRILL tree
construction mechanism and offers an approach requiring no change to the
TRILL

protocol in order to solve the problem is a useful for TRILL deployments.

2)      Does this draft document this problem?

3)      Can we complete this work within 1 year?





Sue Hares






Replies:

   - Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection
   (5/31 to 6/13)
   
   "R. Parameswaran" 
;
   - Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection
   (5/31 to 6/13)
   
   Donald Eastlake  ;



-- 
Thanks
-Riyaz

"My interest is in the future because I am going to spend the rest of my
life there."

--f403045da416cf2e290552922a33
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



      Hello,

Support this draft.=


Thank=
s
-Riyaz


Sameer Agrawal <ag=
rawalsameer@gmail.com>
      Thu, 22 June  2017 1=
7:27 UTCShow he=
ader
   =20
   =20
    

     =20
          
 Hi,I support this draft.

Thanks,

Sameer Agrawal
[trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to
6/13)

"Susan Hares" <share=
s@ndzh.com>; Wed, 31 May 2017 21:37 UTCShow header
<https://mailarchive.ietf.org/arch/search/?email_list=
=3Dtrill#>

This begins a 2 week WG adoption call for draft-rp-trill-parent-selection
from 5/31/2017 to 6/13/2017.  You can obtain the draft at:
https://datatracker.ietf.org/doc/draft-rp-trill-parent-=
selection/.



The authors should indicate if they know of IPR on this draft.  This should
be sent to the WG list within 1 week or the WG adoption or we will "st=
all"
the WG adoption call waiting for it.   (Normally TRILL authors are great at
responding - so we are running the IPR and WG Adoption call in parallel).



The TRILL WG group should consider on this information draft if:





1)      Is the documentation the known problem in the TRILL tree
construction mechanism and offers an approach requiring no change to the
TRILL

protocol in order to solve the problem is a useful for TRILL deployments.

2)      Does this draft document this problem?

3)      Can we complete this work within 1 year?





Sue Hares






Replies:

   - Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection
   (5/31 to 6/13)
   <https://mailarchive.ietf.org/arch/msg/t=
rill/LKPOCPjwo1fiyLsuSLvVuJcWU1o>
   "R. Parameswaran" <Ramkumar.Parameswaran@brocade.com>;
   - Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection
   (5/31 to 6/13)
   <https://mailarchive.ietf.org/arch/msg/t=
rill/deFJ0zWDa_tz4A3hEbfLKsjQAJk>
   Donald Eastlake <d3e3e3@gm=
ail.com>;


     =20
    

    

     =20
    

=20


      

       =20
       =20
      
=20

            =20
        =20
    =20

   =20
   =20


=20
















-- 
Thanks
-Riya=
z

"My interest is in the future because I am going to spend the=
 rest of my life there."




--f403045da416cf2e290552922a33--


From nobody Thu Jun 22 20:49:56 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0643126C23 for ; Thu, 22 Jun 2017 20:49:54 -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 56mCeC2k3jCk for ; Thu, 22 Jun 2017 20:49:53 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFB51241FC for ; Thu, 22 Jun 2017 20:49:53 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id h134so25674767iof.2 for ; Thu, 22 Jun 2017 20:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=LWUPLPqvCYFqRXJTaDbwYdq7oCORLEko5wXca8Nk/oE=; b=rcPaR4PZ5TOpnuAbR+DMACGZnFKAMt/TfUHLBw9qt3X3XLivTGffD5DUabtF+9EKOx h8PlW+PMnNr7G/8S2wyAEMRZiAyHQKrSWKFtClJgKxNvUrx1kt3n3DSaOgAbSdkDbghH g1BMzmMid4DsmkQQ+wfhgpmHN0weOKCsv+B3pCCG1wteUpo89yq3Mv8mYrTguapsKvVx JHiji1bt1Q/qxhhTFmxbBONJFaZxdChrBHQT907JSQgneWb8PiT2/2P7SXhA4wVq8JEo TpA6mY+OOy3i9JDMgTMX5730xIsydOvgQCjqbbTokoFBMgZuM5EEEszckddK76tBKbJa W/5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LWUPLPqvCYFqRXJTaDbwYdq7oCORLEko5wXca8Nk/oE=; b=YUCdq1QZpaoGwXB+m9Yg7TSX2vFhZknXHF1Xjav9h4Lp3hf/FsLWOpVnzPmc+Oa45c ypxckvJXa2A5ePojqbkF3ahz9/e3JLRNA4zyBRTZql+DLRpUV6+GuH2uid9wn6DkFlqx fLL5nveTUgZuACdWTfh04IgSN9yl6lworcMpW0HTF+G8q0Z6di7Ze9fGRSsxoXGMnURq 5pqfaGenIw6rF+Bp1ajzEG1O4EY9sR0NyYjFUZGWE51pp6+1+dICESk83KA/gREk2xz3 46Z+Jasy/nSzQc5rCT6ltEUi9KpoBvlHqxcCeiw3RtWzR33uiR9ouZsRhnvpycC7bCrl 0EPw==
X-Gm-Message-State: AKS2vOyXVzpniPX7r3Tbf/1/NI3oKfcoz9wf1hxfNH6d2pgujS07PR0d T1+gCZzTdspcB81lTfiuJamhTxK14vAL
X-Received: by 10.107.156.17 with SMTP id f17mr5584738ioe.9.1498189792592; Thu, 22 Jun 2017 20:49:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Thu, 22 Jun 2017 20:49:36 -0700 (PDT)
From: Donald Eastlake 
Date: Thu, 22 Jun 2017 23:49:36 -0400
Message-ID: 
To: "trill@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [trill] Call for TRILL Presentations
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jun 2017 03:49:55 -0000

Hi,

If you would like to present to the TRILL WG meeting at the upcoming
IETF meeting in Prague, Czech Republic, please contact trill-chair at
ietf.org or post to this list by replying to this email.

Arrangements can be made for remote presentations.

Thanks,
Donald (TRILL WG Secretary)
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


From nobody Fri Jun 23 03:01:51 2017
Return-Path: 
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F731274D0; Fri, 23 Jun 2017 03:01:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Will LIU 
To: 
Cc: draft-ietf-trill-rbridge-multilevel.all@ietf.org, ietf@ietf.org, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149821210292.17338.9570586170242114506@ietfa.amsl.com>
Date: Fri, 23 Jun 2017 03:01:42 -0700
Archived-At: 
Subject: [trill] Opsdir last call review of draft-ietf-trill-rbridge-multilevel-06
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jun 2017 10:01:43 -0000

Reviewer: Will LIU
Review result: Ready

I have reviewed draft-ietf-trill-rbridge-multilevel-06 as part of the
Operational directorate's ongoing effort to review all IETF documents being
processed by the IESG.  These comments were written with the intent of
improving the operational aspects of the IETF drafts. Comments that are not
addressed in last call may be included in AD reviews during the IESG review. 
Document editors and WG chairs should treat these comments just like any other
last call comments.

"This informational document enumerates and examines alternatives based on a
number of factors including backward compatibility, simplicity, and scalability
and makes recommendations in some cases.""

The document was well written, and I didn't find any nit in it. The RFC editor
might modify and place the copyright part in the usual position.

My overall view of the document is 'Ready' for publication.



From nobody Fri Jun 23 08:40:34 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA8F12951F; Fri, 23 Jun 2017 08:40:26 -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 BfhQEQWJtIVb; Fri, 23 Jun 2017 08:40:24 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4679C1243FE; Fri, 23 Jun 2017 08:40:21 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id h64so4866651iod.0; Fri, 23 Jun 2017 08:40:21 -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=B+e85MCCzZCOvt7x6/pIg5lk9YbxaFBz3ciI08Ivtrg=; b=pobUC3BL+Cvk0RmiFGLCC0TzIs4uaHDMINhh5RJv9DiId6MeKzVXkbVkn2hxTF3lYP o0Z3KMc/7098LICf/klpjvqR6XDWddIcN6f72S56i1JgXcwlef6ex2QaCTXSPX6i4bKt NQdV/1D3mPKMt8roMfcL81lmLKXTo/SqmbWZRCFaOlzwbwD96odfzEyPCUI6MhczWEbG AvEifricfeS+yuhod4uepJLfB/DedKEnvJHDoq36cemF5bOR59yBU/mrg3vG+i4A0a0S yVDAfagVP8XG1jnSt9KB+5OD6qtV9vl06g9xpaHnUiX4poXp7gbin8cCoYYvJJfl1QFQ vimw==
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=B+e85MCCzZCOvt7x6/pIg5lk9YbxaFBz3ciI08Ivtrg=; b=NxtWweE97j+boUu1KZ/Rk6z5wxw41lxDZRNVptHWbjKJjLkhfwVevlj4w4HnrRSIf1 /6eLFqPTqoNowfA75sJo5xjSdXqx1byFmSmWEgrVTYfe096V3A4xyTpEbtnzygz1fpA3 nMd5e04dPFe3qazKVjMNmoJpAfpbFfTseNcecUrDiHyT/+l63DCOD9VB4ry07jhD6gUj BapbKNJckKAjfWJRpFwBjMEahFm0Twp5FJU4ZAAr0teTT67QRGbcXj+mjkpNGs72p6YL Z1Y0hoiI2hkZ+BrOzAvawObpPD4987td1jy/ifUWn0roMF//LEX7ayzXtxCdJEMhX3/j hMjQ==
X-Gm-Message-State: AKS2vOwXd6wSjXSQUUM+wqAtg6cXHkj5sfenBNZ3hikXR7OO1PtwvhJB 7mW9ZX1k2ShyYNb+Bw9e8lsxS857cQ==
X-Received: by 10.107.4.19 with SMTP id 19mr7739764ioe.95.1498232420499; Fri, 23 Jun 2017 08:40:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Fri, 23 Jun 2017 08:40:04 -0700 (PDT)
In-Reply-To: <149821210292.17338.9570586170242114506@ietfa.amsl.com>
References: <149821210292.17338.9570586170242114506@ietfa.amsl.com>
From: Donald Eastlake 
Date: Fri, 23 Jun 2017 11:40:04 -0400
Message-ID: 
To: Will LIU 
Cc: "ops-dir@ietf.org" , draft-ietf-trill-rbridge-multilevel.all@ietf.org,  IETF Discussion , "trill@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [trill] Opsdir last call review of draft-ietf-trill-rbridge-multilevel-06
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jun 2017 15:40:26 -0000

Hi Will,

Thanks for your review.

Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Fri, Jun 23, 2017 at 6:01 AM, Will LIU  wrote:
> Reviewer: Will LIU
> Review result: Ready
>
> I have reviewed draft-ietf-trill-rbridge-multilevel-06 as part of the
> Operational directorate's ongoing effort to review all IETF documents being
> processed by the IESG.  These comments were written with the intent of
> improving the operational aspects of the IETF drafts. Comments that are not
> addressed in last call may be included in AD reviews during the IESG review.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
>
> "This informational document enumerates and examines alternatives based on a
> number of factors including backward compatibility, simplicity, and scalability
> and makes recommendations in some cases.""
>
> The document was well written, and I didn't find any nit in it. The RFC editor
> might modify and place the copyright part in the usual position.
>
> My overall view of the document is 'Ready' for publication.
>
>


From nobody Fri Jun 23 14:28:13 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9812943E for ; Fri, 23 Jun 2017 14:28:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66PAr_23o90k for ; Fri, 23 Jun 2017 14:28:10 -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 B776F1293EE for ; Fri, 23 Jun 2017 14:28:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJC04465; Fri, 23 Jun 2017 21:28:07 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 23 Jun 2017 22:28:06 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000;  Fri, 23 Jun 2017 14:28:02 -0700
From: Linda Dunbar 
To: Sameer Agrawal , "trill@ietf.org" 
Thread-Topic: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13)
Thread-Index: AQHS63zfwAAS8yrZCECT/yTaBIuBFqIy+CEw
Date: Fri, 23 Jun 2017 21:28:02 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6593D685B@SJCEML702-CHM.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.218.137.148]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6593D685BSJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.594D87E7.0103, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1a50d1881a3d69e443a079324a333900
Archived-At: 
Subject: Re: [trill] 2 week Adoption call for draft-rp-trill-parent-selection (5/31 to 6/13)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jun 2017 21:28:12 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F6593D685BSJCEML702CHMchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U3VwcG9ydC4NCg0KTGluZGEgRHVuYmFyDQoNClt0cmlsbF0gMiB3ZWVrIEFkb3B0aW9uIGNhbGwg
Zm9yIGRyYWZ0LXJwLXRyaWxsLXBhcmVudC1zZWxlY3Rpb24gKDUvMzEgdG8gNi8xMykNCg0KIlN1
c2FuIEhhcmVzIiA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PiBXZWQs
IDMxIE1heSAyMDE3IDIxOjM3IFVUQ1Nob3cgaGVhZGVyPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0
Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9dHJpbGw+DQoNClRoaXMgYmVnaW5zIGEgMiB3
ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXJwLXRyaWxsLXBhcmVudC1zZWxlY3Rpb24N
Cg0KZnJvbSA1LzMxLzIwMTcgdG8gNi8xMy8yMDE3LiAgWW91IGNhbiBvYnRhaW4gdGhlIGRyYWZ0
IGF0Og0KDQoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnAtdHJp
bGwtcGFyZW50LXNlbGVjdGlvbi8uDQoNCg0KDQoNCg0KDQoNClRoZSBhdXRob3JzIHNob3VsZCBp
bmRpY2F0ZSBpZiB0aGV5IGtub3cgb2YgSVBSIG9uIHRoaXMgZHJhZnQuICBUaGlzIHNob3VsZA0K
DQpiZSBzZW50IHRvIHRoZSBXRyBsaXN0IHdpdGhpbiAxIHdlZWsgb3IgdGhlIFdHIGFkb3B0aW9u
IG9yIHdlIHdpbGwgInN0YWxsIg0KDQp0aGUgV0cgYWRvcHRpb24gY2FsbCB3YWl0aW5nIGZvciBp
dC4gICAoTm9ybWFsbHkgVFJJTEwgYXV0aG9ycyBhcmUgZ3JlYXQgYXQNCg0KcmVzcG9uZGluZyAt
IHNvIHdlIGFyZSBydW5uaW5nIHRoZSBJUFIgYW5kIFdHIEFkb3B0aW9uIGNhbGwgaW4gcGFyYWxs
ZWwpLg0KDQoNCg0KDQoNCg0KDQpUaGUgVFJJTEwgV0cgZ3JvdXAgc2hvdWxkIGNvbnNpZGVyIG9u
IHRoaXMgaW5mb3JtYXRpb24gZHJhZnQgaWY6DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KMSkgICAg
ICBJcyB0aGUgZG9jdW1lbnRhdGlvbiB0aGUga25vd24gcHJvYmxlbSBpbiB0aGUgVFJJTEwgdHJl
ZQ0KDQpjb25zdHJ1Y3Rpb24gbWVjaGFuaXNtIGFuZCBvZmZlcnMgYW4gYXBwcm9hY2ggcmVxdWly
aW5nIG5vIGNoYW5nZSB0byB0aGUNCg0KVFJJTEwNCg0KDQoNCnByb3RvY29sIGluIG9yZGVyIHRv
IHNvbHZlIHRoZSBwcm9ibGVtIGlzIGEgdXNlZnVsIGZvciBUUklMTCBkZXBsb3ltZW50cy4NCg0K
DQoNCjIpICAgICAgRG9lcyB0aGlzIGRyYWZ0IGRvY3VtZW50IHRoaXMgcHJvYmxlbT8NCg0KDQoN
CjMpICAgICAgQ2FuIHdlIGNvbXBsZXRlIHRoaXMgd29yayB3aXRoaW4gMSB5ZWFyPw0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNClN1ZSBIYXJlcw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJlcGxpZXM6
DQoNCiAgKiAgIFJlOiBbdHJpbGxdIDIgd2VlayBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1ycC10
cmlsbC1wYXJlbnQtc2VsZWN0aW9uICg1LzMxIHRvIDYvMTMpPGh0dHBzOi8vbWFpbGFyY2hpdmUu
aWV0Zi5vcmcvYXJjaC9tc2cvdHJpbGwvTEtQT0NQandvMWZpeUxzdVNMdlZ1SmNXVTFvPg0KIlIu
IFBhcmFtZXN3YXJhbiIgPFJhbWt1bWFyLlBhcmFtZXN3YXJhbkBicm9jYWRlLmNvbTxtYWlsdG86
UmFta3VtYXIuUGFyYW1lc3dhcmFuQGJyb2NhZGUuY29tPj4NCiAgKiAgIFJlOiBbdHJpbGxdIDIg
d2VlayBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1ycC10cmlsbC1wYXJlbnQtc2VsZWN0aW9uICg1
LzMxIHRvIDYvMTMpPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHJpbGwv
ZGVGSjB6V0RhX3R6NEEzaEViZkxLc2pRQUprPg0KRG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21h
aWwuY29tPG1haWx0bzpkM2UzZTNAZ21haWwuY29tPj4NCg==

--_000_4A95BA014132FF49AE685FAB4B9F17F6593D685BSJCEML702CHMchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1
IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh
bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7
fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp
di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpo
Mw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIENo
YXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox
My41cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJZm9udC13ZWln
aHQ6Ym9sZDt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi
SGVhZGluZyA0IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo
dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K
CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7
DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijt9DQpzcGFuLkhlYWRpbmczQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAzIENo
YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDMi
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjRE
Nzg7fQ0KcC5nbWFpbC1tc2ctaGVhZGVyLCBsaS5nbWFpbC1tc2ctaGVhZGVyLCBkaXYuZ21haWwt
bXNnLWhlYWRlcg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tc2ctaGVhZGVyOw0KCW1zby1tYXJn
aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5nbWFpbC1waXBlDQoJe21zby1z
dHlsZS1uYW1lOmdtYWlsLXBpcGU7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t
c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6
Q29uc29sYXM7fQ0Kc3Bhbi5IZWFkaW5nNENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcg
NCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGlu
ZyA0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjoj
MkU3NEI1Ow0KCWZvbnQtc3R5bGU6aXRhbGljO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx
LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q
IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4NzMxMDQyNTI7
DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05ODMxMzQxNzA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu
MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww
OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s
ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy
LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl
dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl
bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp
bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N
Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3VwcG9ydC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+TGluZGEgRHVuYmFyPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxk
aXY+DQo8ZGl2IGlkPSJnbWFpbC1tc2ctYm9keSI+DQo8aDM+W3RyaWxsXSAyIHdlZWsgQWRvcHRp
b24gY2FsbCBmb3IgZHJhZnQtcnAtdHJpbGwtcGFyZW50LXNlbGVjdGlvbiAoNS8zMSB0byA2LzEz
KTxvOnA+PC9vOnA+PC9oMz4NCjxwIGNsYXNzPSJnbWFpbC1tc2ctaGVhZGVyIiBpZD0iZ21haWwt
bXNnLWluZm8iPjxzcGFuIGNsYXNzPSJnbWFpbC1waXBlIj4mcXVvdDtTdXNhbiBIYXJlcyZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9h
PiZndDs8L3NwYW4+DQo8c3BhbiBjbGFzcz0iZ21haWwtcGlwZSI+V2VkLCAzMSBNYXkgMjAxNyAy
MTozNyBVVEM8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo
L3NlYXJjaC8/ZW1haWxfbGlzdD10cmlsbCIgaWQ9ImdtYWlsLXRvZ2dsZS1tc2ctaGVhZGVyIj5T
aG93IGhlYWRlcjwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0iZ21haWwtbXNnLXBheWxv
YWQiPg0KPHByZT5UaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFm
dC1ycC10cmlsbC1wYXJlbnQtc2VsZWN0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+ZnJvbSA1
LzMxLzIwMTcgdG8gNi8xMy8yMDE3LiZuYnNwOyBZb3UgY2FuIG9idGFpbiB0aGUgZHJhZnQgYXQ6
Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJwLXRy
aWxsLXBhcmVudC1zZWxlY3Rpb24vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC1ycC10cmlsbC1wYXJlbnQtc2VsZWN0aW9uLzwvYT4uPG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBhdXRob3JzIHNob3VsZCBpbmRpY2F0
ZSBpZiB0aGV5IGtub3cgb2YgSVBSIG9uIHRoaXMgZHJhZnQuJm5ic3A7IFRoaXMgc2hvdWxkPG86
cD48L286cD48L3ByZT4NCjxwcmU+YmUgc2VudCB0byB0aGUgV0cgbGlzdCB3aXRoaW4gMSB3ZWVr
IG9yIHRoZSBXRyBhZG9wdGlvbiBvciB3ZSB3aWxsICZxdW90O3N0YWxsJnF1b3Q7PG86cD48L286
cD48L3ByZT4NCjxwcmU+dGhlIFdHIGFkb3B0aW9uIGNhbGwgd2FpdGluZyBmb3IgaXQuJm5ic3A7
Jm5ic3A7IChOb3JtYWxseSBUUklMTCBhdXRob3JzIGFyZSBncmVhdCBhdDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPnJlc3BvbmRpbmcgLSBzbyB3ZSBhcmUgcnVubmluZyB0aGUgSVBSIGFuZCBXRyBB
ZG9wdGlvbiBjYWxsIGluIHBhcmFsbGVsKS4gPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBUUklMTCBXRyBncm91cCBzaG91bGQgY29uc2lkZXIg
b24gdGhpcyBpbmZvcm1hdGlvbiBkcmFmdCBpZjogPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT4xKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJ
cyB0aGUgZG9jdW1lbnRhdGlvbiB0aGUga25vd24gcHJvYmxlbSBpbiB0aGUgVFJJTEwgdHJlZTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbnN0cnVjdGlvbiBtZWNoYW5pc20gYW5kIG9mZmVycyBh
biBhcHByb2FjaCByZXF1aXJpbmcgbm8gY2hhbmdlIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPlRSSUxMIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPnByb3RvY29sIGluIG9yZGVyIHRvIHNvbHZlIHRoZSBwcm9ibGVtIGlzIGEgdXNlZnVs
IGZvciBUUklMTCBkZXBsb3ltZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT4yKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEb2Vz
IHRoaXMgZHJhZnQgZG9jdW1lbnQgdGhpcyBwcm9ibGVtPyA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4zKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBDYW4gd2UgY29tcGxldGUgdGhpcyB3b3JrIHdpdGhpbiAxIHllYXI/IDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U3VlIEhhcmVzIDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2IGlkPSJnbWFpbC1tZXNzYWdlLXRocmVhZCI+DQo8aDQ+UmVwbGllczo8bzpwPjwvbzpwPjwv
aDQ+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww
IGxldmVsMSBsZm8xIj4NCjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj
aC9tc2cvdHJpbGwvTEtQT0NQandvMWZpeUxzdVNMdlZ1SmNXVTFvIj5SZTogW3RyaWxsXSAyIHdl
ZWsgQWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtcnAtdHJpbGwtcGFyZW50LXNlbGVjdGlvbiAoNS8z
MSB0byA2LzEzKTwvYT48YnI+DQomcXVvdDtSLiBQYXJhbWVzd2FyYW4mcXVvdDsgJmx0OzxhIGhy
ZWY9Im1haWx0bzpSYW1rdW1hci5QYXJhbWVzd2FyYW5AYnJvY2FkZS5jb20iPlJhbWt1bWFyLlBh
cmFtZXN3YXJhbkBicm9jYWRlLmNvbTwvYT4mZ3Q7DQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8YSBocmVmPSJodHRwczov
L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3RyaWxsL2RlRkoweldEYV90ejRBM2hFYmZM
S3NqUUFKayI+UmU6IFt0cmlsbF0gMiB3ZWVrIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXJwLXRy
aWxsLXBhcmVudC1zZWxlY3Rpb24gKDUvMzEgdG8gNi8xMyk8L2E+PGJyPg0KRG9uYWxkIEVhc3Rs
YWtlICZsdDs8YSBocmVmPSJtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbSI+ZDNlM2UzQGdtYWlsLmNv
bTwvYT4mZ3Q7IDxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_4A95BA014132FF49AE685FAB4B9F17F6593D685BSJCEML702CHMchi_--


From nobody Fri Jun 23 17:15:09 2017
Return-Path: 
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BF012EB5A; Fri, 23 Jun 2017 17:07:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: akatlas@gmail.com, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149826283488.7840.3726108768442890027.idtracker@ietfa.amsl.com>
Date: Fri, 23 Jun 2017 17:07:14 -0700
Archived-At: 
Subject: [trill] trill - Requested session has been scheduled for IETF 99
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jun 2017 00:07:15 -0000

Dear Donald Eastlake,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

trill Session 1 (1:00:00)
    Friday, Afternoon Session II 1150-1320
    Room Name: Karlin III size: 60
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Transparent Interconnection of Lots of Links
Area Name: Routing Area
Session Requester: Donald Eastlake

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 30
Conflicts to Avoid: 
 First Priority: saag netconf netmod bess isis
 Second Priority: sfc spring sidr babel i2rs idr
 Third Priority: intarea lpwan dnsop grow i2nsf


People who must be present:
  Susan Hares
  Donald E. Eastlake 3rd
  Alia Atlas
  Jon Hudson

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Fri Jun 23 18:33:02 2017
Return-Path: 
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F05601250B8; Fri, 23 Jun 2017 18:32:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Brian Carpenter 
To: 
Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org, trill@ietf.org, brian.e.carpenter@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149826797586.7852.1637929087755767570@ietfa.amsl.com>
Date: Fri, 23 Jun 2017 18:32:55 -0700
Archived-At: 
Subject: [trill] Genart last call review of draft-ietf-trill-mtu-negotiation-05
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jun 2017 01:32:56 -0000

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-trill-mtu-negotiation-05

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-trill-mtu-negotiation-05.txt
Reviewer: Brian Carpenter
Review Date: 2017-06-24
IETF LC End Date: 2017-06-28
IESG Telechat date: 2017-07-06

Summary: Ready with issues
--------

Minor issues: 
-------------

> 2. Link-Wide TRILL MTU Size
...
>   ...RBridges MUST support the Extended L1 Circuit-Scoped
>   (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to
>   exchange their maximally supportable value of "Lz".

Where does that value come from? Is it configured, derived from
the interface in some way, or discovered?

> 2.1. Operations
>
>   Lz is reported using a originatingSNPBufferSize TLV that MUST occur
>   in fragment zero of the RBridge's E-L1CS FS-LSP. An
>   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>   is ignored.

Is that really what you mean? I thought Lz was an optional extra. So I think
you mean:

2.1. Operations

   Lz MAY be reported using a originatingSNPBufferSize TLV that occurs
   in fragment zero of the RBridge's E-L1CS FS-LSP. An
   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
   MUST be ignored.

> 3. Link MTU Size Testing
...
>   Step 0:
...
>      b) Link MTU size is set to 1470, lowerBound is set to 1470,
>         upperBound is set to the link-wide Lz, linkMtuSize is set to
>         [(lowerBound + upperBound)/2] (Operation "[...]" returns the
>         fraction-rounded-up integer.).  

This is confusing. "linkMtuSize" was defined as a local variable.
But what is "Link MTU size"? Is that another local variable?
If so, how is it different from "linkMtuSize"?
It is used again in part 2) of step 2 below.

Also, I assume "Lz" is the value previously agreed among the nodes,
but that should be made clear to the reader.

Nits:
-----

> 1. Introduction
...
>   topology. While in this document, a new RECOMMENDED link-wide minimum
>   inter-RBridge MTU size, Lz, is specified. By calculating a using Lz
>   as specified herein, link-scoped PDUs can be formatted greater than
>   the campus-wide Sz up to the link-wide minimum acceptable inter-
>   RBridge MTU size potentially improving the efficiency of link
>   utilization and speeding link state convergence.

I cannot parse those two sentences. What does the "While" refer to? 
What does "By calculating a using Lz" mean?

> 3. Link MTU Size Testing
...
>      b) Link MTU size is set to 1470, lowerBound is set to 1470,
>         upperBound is set to the link-wide Lz, linkMtuSize is set to
>         [(lowerBound + upperBound)/2] (Operation "[...]" returns the
>         fraction-rounded-up integer.).  

This would be easier to understand:

3. Link MTU Size Testing
...
      b) Link MTU size is set to 1470, lowerBound is set to 1470,
         upperBound is set to the link-wide Lz, linkMtuSize is set to
         [(lowerBound + upperBound)/2], rounded up to the nearest integer.

Repeat this in the following two cases; a normal reader will not
remember the rounding rule:

...
   1) If RB1 fails to receive an MTU-ack from RB2 after k tries: 

         upperBound is set to linkMtuSize and linkMtuSize is set to
         [(lowerBound + upperBound)/2], rounded up to the nearest integer.

   2) If RB1 receives an MTU-ack to a probe of size linkMtuSize from
      RB2:

         link MTU size is set to linkMtuSize, lowerBound is set to
         linkMtuSize and linkMtuSize is set to [(lowerBound +
         upperBound)/2], rounded up to the nearest integer.

--



From nobody Sun Jun 25 17:08:02 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D25126CC4; Sun, 25 Jun 2017 17:07:33 -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 uxaoUzQECrL6; Sun, 25 Jun 2017 17:07:30 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BE4124217; Sun, 25 Jun 2017 17:07:30 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id b205so31637831itg.1; Sun, 25 Jun 2017 17:07:30 -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=VsF13UUI8Adxncjmvg7IEhE9NYx7hp7x9Of78C4O/wk=; b=YUDdjbDup6DWDq2H5HmDhW/A+bI7BEZ2rXQ4ACctQHKlRW2mP1VU2RCjYagQ84nJtX j0j3h/Mv/IuDj7DFzjneLeyZi1ew55NxiLM0Qm5Igsn8DS6/TSFwxOy3O1mC8/81Lz7R 3907/zwSqNrGb1JnAcZbA+On6DgPpqSFW8+pT2X4U8JLySY5rq39+ghFpJU7kh47mqI6 Pdgbi+HxrCRaIAk4Wv3uRyk1oSyqYH2GTFf4sCDFOmGriUsjU0rUiNgmC60PeDncDbFX TXYbB9Fg3KrtWL66vH+967mgUmRp4AkPVKOYZF8dXoxWsTElZ/lPSpv0guaBZbfsHp7C fdYA==
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=VsF13UUI8Adxncjmvg7IEhE9NYx7hp7x9Of78C4O/wk=; b=Ui010ZSJ5F/BF0T0w+7mEY4Ekti8TDfPWg9bMs/EKdAi8o0PyAUiQfH9HCpTn9YwCm 1A8qnanDxW48VXVbsSVl8YrXIWItJSJDiWSXZfyKkX5LJ8tJ5za/rqRAd2A7nkMXL5sj XDnNWNTYqBtB42tRLGvGuKLN+dwFoGKLq+n8aIwMatxp8OVz3QCWNNxlNSvhzRV/D9G+ KS/iMajnZ0XqUt86r2yUHceSEz2IdwvWU0WRTrmBu9zsDFBCIYT2iQDDUAcWUDwBCpTf ylKF22+xH/TYsKHuVySPLJxOYk7MKQ8mdAJce7q3C/6r2HqfNPcZQlExsDeyD2U1mYg7 4iQg==
X-Gm-Message-State: AKS2vOy6dcYcUcjZH59F/aNjUSe4YzXDzbS62Axzi8K/39/gaAaaJf3d 73n0WRs01PKhGVe1wTXBzgeLslkWzA==
X-Received: by 10.36.20.137 with SMTP id 131mr21713650itg.104.1498435649336; Sun, 25 Jun 2017 17:07:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Sun, 25 Jun 2017 17:07:13 -0700 (PDT)
In-Reply-To: <149754795560.13109.17521244075940607817@ietfa.amsl.com>
References: <149754795560.13109.17521244075940607817@ietfa.amsl.com>
From: Donald Eastlake 
Date: Sun, 25 Jun 2017 20:07:13 -0400
Message-ID: 
To: Magnus Westerlund 
Cc: tsv-art@ietf.org, "trill@ietf.org" , IETF Discussion , draft-ietf-trill-over-ip.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jun 2017 00:07:34 -0000

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 significant 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 specifications. 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 value in
>    the outer IP Header of TRILL packets they send by mapping the TRILL
>    priority and DEI to the DSCP. They MAY support, for a TRILL Data
>    packet where the native frame payload is an IP packet, mapping the
>    DSCP in this inner IP packet to the outer IP Header with the default
>    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 discussion of
> the potential issues with actually setting the DSCP values. It is one thing to
> do this in an IP back bone use case where one can know and have control 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 policers or
> remapping. Also as the actual DSCP code point usage is domain specific this is
> difficult. Priority reversal is likely the least of the problems that 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 networks this can
> also results in strange remapping that results in a different PHB for CS1 than.

The intent in the draft is to reflect the default relative priority of
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 discovery
> 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 requries
> 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 were
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 to
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 IP
>    connectivity.
>
> The issue with RFC4821 is that it has requirements on the packetization 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 below 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, and that
> relies on IP fragmentation despite the need for reliable fragmentation. 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 problem 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 to 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 have
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 are
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 not 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 apply
>    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 applicability 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 done.

OK. We'll look into it.

> TCP Encapsulation issue
> -----------------------
>
> Section 5.6:
>
> The TCP encapsulation appear to be missing an delimiter format allowing each
> individual TRILL packet/payload to be read out of the TCP's byte stream. In
> other words, a normal implementation has no way of ensuring that the TCP
> payload starts with the start of a new TRILL payload. Multiple small TRILL
> payloads may be included in the same TCP payload, and also only parts 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 length field
> for the TRILL payload to be encapsulated.

Right. It might also be useful to include some sort of check field, as
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 handling
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 not
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 sizes 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, specific
>    congestion control mechanisms are commonly needed.  However, if the
>    traffic being carried by the TRILL over IP link is already congestion
>    controlled and the size and volatility of the TRILL IS-IS link state
>    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 way of knowing
> which traffic is actually congestion controlled, considering that TRILL provides
> an layer 2 abstraction. I wonder if there should be any type of white 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 any
> recommendation to prevent traffic that is not controlled to be forwarded, can
> lead to congestion issues.
>
> The other issue I think may exist is the issue serial unicast emulation of
> broadcast/multicast creates. As this amplifies the outgoing packet rate with
> a factor of how many addresses are configured for serial unicast this can
> be significant traffic expansion. Thus, I think additional considerations 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 an
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 inner
> layer 2 frames, and use the flow equivalents that exists on that level 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 ensure 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 static binding
> configurations or the need for determining ones external address(es) and be
> able to communicate that to the peer RBridges, and in addition ensure 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). Note 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 bytes MTU
> Ethernet infrastructure.
>
> I would note that also firewalls likely have issues with IP fragments for the
> same reason, they require significant amount of state to be verified if they
> should be let through.
>
> In general I think you should create a configuration that has chance to work
> through most middleboxes, but I think you should require static bindings. 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
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> Cheers
>
> Magnus Westerlund


From nobody Mon Jun 26 10:16:21 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D4C12EB0C; Mon, 26 Jun 2017 10:16:14 -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 7L-oEZXtGeLI; Mon, 26 Jun 2017 10:16:12 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0BDB1129BC4; Mon, 26 Jun 2017 10:16:12 -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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v5QHFGGQ023397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Jun 2017 10:15:18 -0700 (PDT)
To: Donald Eastlake , Magnus Westerlund 
Cc: tsv-art@ietf.org, draft-ietf-trill-over-ip.all@ietf.org, IETF Discussion , "trill@ietf.org" 
References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> 
From: Joe Touch 
Message-ID: <7cc18878-970a-efbe-8488-a4110b9b24e9@isi.edu>
Date: Mon, 26 Jun 2017 10:15:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
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: [trill] Tsvart early review of draft-ietf-trill-over-ip-10
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jun 2017 17:16:14 -0000

Hi, Donald,


On 6/25/2017 5:07 PM, Donald Eastlake wrote:
> 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 significant 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 specifications. 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.
>
> ...
>> TCP Encapsulation issue
>> -----------------------
>>
>> Section 5.6:
>>
>> The TCP encapsulation appear to be missing an delimiter format allowing each
>> individual TRILL packet/payload to be read out of the TCP's byte stream. In
>> other words, a normal implementation has no way of ensuring that the TCP
>> payload starts with the start of a new TRILL payload. Multiple small TRILL
>> payloads may be included in the same TCP payload, and also only parts 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 length field
>> for the TRILL payload to be encapsulated.
> Right. It might also be useful to include some sort of check field, as
> is done in BGP, to detect if you are out of sync in parsing the TCP
> stream.

There is nothing in BGP that ever assumes that TCP write boundaries are
preserved. BGP uses markers and length fields to create message
boundaries in TCP's bytestream. The same is needed here.

Note that BGP also never claims to craft TCP packets by 'encapsulating'
a BGP message in a TCP segment. That part of this document needs to be
removed - it not how TCP is ever used.

> 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,
Again - please, NO. NEVER use this term.

> you want
> to use the same DSCP value for the packets in a particular TCP stream.
Again, this is nonsensical. TCP would set a DSCP for the connection,
never in different ways for individual segments of a connection.


> So, generally, you need to have a TCP connection per priority handling
> 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 not
> be too hard.
Perhaps, but please - again, please - omit any mention or implication
that this occurs via encapsulation.

If you want to use TCP, please use it properly.

>
>> 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 sizes 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?
Because your use of TCP (even if changed to describe it correctly) isn't
listed in those TCP RFCs.

And it's not so simple - NAGLE helps performance for interactive systems
that use single-byte messages (e.g., telnet) and reduces the number of
outstanding "less than full" segments. When used for encapsulation,
turning NAGLE off is the right thing for multibyte messages (e.g., TRILL
messages) and can avoid the "gathering" delay (200 ms stalls when there
isn't enough source data - i.e., incoming TRILL packets - to keep up
with the outgoing segments), but could also generate a large number of
small segments (which can interfere with segment-based congestion
control, vs. ABC).

Unless you want a very poorly performing result, *THIS* is what you need
to drill down into.

Joe


From nobody Mon Jun 26 11:42:55 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E70E129B17; Mon, 26 Jun 2017 11:42:54 -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 7MvGN6U9DXCD; Mon, 26 Jun 2017 11:42:52 -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 3A49E1270AC; Mon, 26 Jun 2017 11:42:52 -0700 (PDT)
Received: from [128.9.184.87] ([128.9.184.87]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v5QIgIg6009301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Jun 2017 11:42:18 -0700 (PDT)
From: Joe Touch 
To: Donald Eastlake , Magnus Westerlund 
Cc: tsv-art@ietf.org, "trill@ietf.org" , IETF Discussion , draft-ietf-trill-over-ip.all@ietf.org
References: <149754795560.13109.17521244075940607817@ietfa.amsl.com>  <7cc18878-970a-efbe-8488-a4110b9b24e9@isi.edu>
Message-ID: 
Date: Mon, 26 Jun 2017 11:42:16 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <7cc18878-970a-efbe-8488-a4110b9b24e9@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: [trill] Tsvart early review of draft-ietf-trill-over-ip-10
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jun 2017 18:42:54 -0000

PS - the idea that TCP segments within a single connection should ever
have different DSCPs is a good example of why it's a bad idea to even
'think' of TRILL over TCP as direct encapsulation. I.e., that concept is
inherently hazardous and should be avoided.

Joe


On 6/26/2017 10:15 AM, Joe Touch wrote:
> Hi, Donald,
>
>
> On 6/25/2017 5:07 PM, Donald Eastlake wrote:
>> 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 significant 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 specifications. 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.
>>
>> ...
>>> TCP Encapsulation issue
>>> -----------------------
>>>
>>> Section 5.6:
>>>
>>> The TCP encapsulation appear to be missing an delimiter format allowing each
>>> individual TRILL packet/payload to be read out of the TCP's byte stream. In
>>> other words, a normal implementation has no way of ensuring that the TCP
>>> payload starts with the start of a new TRILL payload. Multiple small TRILL
>>> payloads may be included in the same TCP payload, and also only parts 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 length field
>>> for the TRILL payload to be encapsulated.
>> Right. It might also be useful to include some sort of check field, as
>> is done in BGP, to detect if you are out of sync in parsing the TCP
>> stream.
> There is nothing in BGP that ever assumes that TCP write boundaries are
> preserved. BGP uses markers and length fields to create message
> boundaries in TCP's bytestream. The same is needed here.
>
> Note that BGP also never claims to craft TCP packets by 'encapsulating'
> a BGP message in a TCP segment. That part of this document needs to be
> removed - it not how TCP is ever used.
>
>> 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,
> Again - please, NO. NEVER use this term.
>
>> you want
>> to use the same DSCP value for the packets in a particular TCP stream.
> Again, this is nonsensical. TCP would set a DSCP for the connection,
> never in different ways for individual segments of a connection.
>
>
>> So, generally, you need to have a TCP connection per priority handling
>> 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 not
>> be too hard.
> Perhaps, but please - again, please - omit any mention or implication
> that this occurs via encapsulation.
>
> If you want to use TCP, please use it properly.
>
>>> 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 sizes 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?
> Because your use of TCP (even if changed to describe it correctly) isn't
> listed in those TCP RFCs.
>
> And it's not so simple - NAGLE helps performance for interactive systems
> that use single-byte messages (e.g., telnet) and reduces the number of
> outstanding "less than full" segments. When used for encapsulation,
> turning NAGLE off is the right thing for multibyte messages (e.g., TRILL
> messages) and can avoid the "gathering" delay (200 ms stalls when there
> isn't enough source data - i.e., incoming TRILL packets - to keep up
> with the outgoing segments), but could also generate a large number of
> small segments (which can interfere with segment-based congestion
> control, vs. ABC).
>
> Unless you want a very poorly performing result, *THIS* is what you need
> to drill down into.
>
> Joe
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill


From nobody Mon Jun 26 12:04:52 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8C112EB4E; Mon, 26 Jun 2017 12:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=AD7Fxyvr; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=FF2f19Ti
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 m4Op5HaFwkEn; Mon, 26 Jun 2017 12:04:21 -0700 (PDT)
Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 7B24512EB49; Mon, 26 Jun 2017 12:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498503366; x=1530039366; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=7bmGUcIENJgAQDkTWPpxmp8xiAPCp4TMP1NJbeM6UJc=; b=AD7Fxyvrh2yR3CukEi/prueBDU/aTOv7GDaNgsswj/K5/hJkdKHjMTjR NXeuMFxA4adPXt2GCj/zsUTG6qgz1idXJ3x6dfKOOtboQeWrHOcyex3d7 7O9mJWC9+5B5QtuY1UZqEt6zgI7ApD/hS7x/ulTE4qYwpwrVYPSmoWrc3 8=;
Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2017 13:56:05 -0500
From: "Black, David" 
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 00:58:23 +0600
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5QJ4Eha028332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jun 2017 15:04:16 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v5QJ4Eha028332
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498503857; bh=/mK0Pk3Pm349kX4HfoBi5jS0hoQ=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FF2f19Ti1xflbQL+i+1RtceV/iWfJ4WizRAgHxFtCVqjwA75/w30WkAF305E28D5M /KQ9WHRqXS57qlSSPo4pUtbGtrZbhjm/H8sPneSQG5zg2ri84sfk+F1mjd1oPQtbJs jEkSqRSHPsjFQuOpV1QYdmfPFqUK1NWYqSbTQQxY=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v5QJ4Eha028332
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 26 Jun 2017 15:03:47 -0400
Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5QJ41AM001658 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 26 Jun 2017 15:04:02 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0352.000; Mon, 26 Jun 2017 15:04:01 -0400
To: Donald Eastlake , Magnus Westerlund 
CC: "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: AdLurvO3SYOqL32fRKuavuJggYEWYw==
Date: Mon, 26 Jun 2017 19:04:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.238.44.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
Archived-At: 
Subject: Re: [trill] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jun 2017 19:04:25 -0000

Adding some comments on ECN and DSCP ...

> > Section 4.3:
> >
> >    TRILL over IP implementations MUST support setting the DSCP value in
> >    the outer IP Header of TRILL packets they send by mapping the TRILL
> >    priority and DEI to the DSCP. They MAY support, for a TRILL Data
> >    packet where the native frame payload is an IP packet, mapping the
> >    DSCP in this inner IP packet to the outer IP Header with the default
> >    for that mapping being to copy the DSCP without change.
> >
> > I think it is fine to require that implementations are capable of setti=
ng
> > DSCP values on the outer IP header. However, I fail to see any discussi=
on of
> > the potential issues with actually setting the DSCP values. It is one t=
hing to
> > do this in an IP back bone use case where one can know and have control
> > 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 policers=
 or
> > remapping. Also as the actual DSCP code point usage is domain specific =
this is
> > difficult. Priority reversal is likely the least of the problems that t=
his can
> > run into over general Internet.
>=20
> 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 particul=
ar,
copying the inner ECN codepoint to the outer IP header encapsulation withou=
t
requiring decapsulation processing as specified in RFC 6040 or the 6040upda=
te-shim
draft can lose congestion indications from the network and hence is wrong
(it's also wrong wrt RFC 3168, but RFC 6040 and the 6040update-shim drafts =
are
better and more current references).

For DSCPs, start with RFC 2983 - thinking about the validity (or likely val=
idity)
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 in at
egress) or a pipe model (e.g., do something reasonable for outer DSCP at
ingress, ignore it on egress) as the implementation default.

-- DSCP mapping to/from TRILL/Ethernet priorities

> The intent in the draft is to reflect the default relative priority of
> 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 decade
old, and in an area (less-than-best-effort service) where the aspirations
of at least RFC 3662 weren't realized ... but that RFC is not safe to ignor=
e,
either.

In practice, the specification of CS1 for less-than-best-effort service 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.

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.=20

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 Discuss=
ion
> ; trill@ietf.org
> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10
>=20
> Hi Magnus,
>=20
> Thanks for the extensive review. See my responses below.
>=20
> 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 signific=
ant that
> > could affect the protocol realization significantly. Some may be me mis=
sing
> > 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 specificati=
ons. So
> > don't hesitate to push back and provide pointers to things that can res=
olve
> > issues. The authors and the WG clearly have thought about a lot of issu=
es
> and
> > dealt with much already.
>=20
> OK. Hopefully we can resolve these one way or the other.
>=20
> > Diffserv usage
> > --------------
> >
> > Section 4.3:
> >
> >    TRILL over IP implementations MUST support setting the DSCP value in
> >    the outer IP Header of TRILL packets they send by mapping the TRILL
> >    priority and DEI to the DSCP. They MAY support, for a TRILL Data
> >    packet where the native frame payload is an IP packet, mapping the
> >    DSCP in this inner IP packet to the outer IP Header with the default
> >    for that mapping being to copy the DSCP without change.
> >
> > I think it is fine to require that implementations are capable  of sett=
ing
> > DSCP values on the outer IP header. However, I fail to see any discussi=
on of
> > the potential issues with actually setting the DSCP values. It is one t=
hing to
> > do this in an IP back bone use case where one can know and have control
> 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 policers=
 or
> > remapping. Also as the actual DSCP code point usage is domain specific =
this
> is
> > difficult. Priority reversal is likely the least of the problems that t=
his can
> > run into over general Internet.
>=20
> It sounds like appropriate discussion and warnings about these issues
> would resolve the above comment.
>=20
> > 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 t=
hat
> you
> > get priority 0 to be lower priority than 1. Plus that in some networks =
this can
> > also results in strange remapping that results in a different PHB for C=
S1
> than.
>=20
> The intent in the draft is to reflect the default relative priority of
> 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...
>=20
> > MTU and Fragmentation
> > ---------------------
> >
> > I think there are two main issue here. The first one is MTUD discovery
> > 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 requri=
es
> > 1470 byte support which is likey above a lot of paths.
>=20
> 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.
>=20
> 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 were
> 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 to
> 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...
>=20
> > Section 8.4:
> >
> >    Path MTU discovery [RFC4821] should be useful
> >    in determining the IP MTU between a pair of RBridge ports with IP
> >    connectivity.
> >
> > The issue with RFC4821 is that it has requirements on the packetization
> layer.
> > Trill appears to have several components that are useful. However, it w=
ill
> > require a specification of the procedure to result in a useful tool.
>=20
> See below.
>=20
> > 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 appea=
rs
> > prevented from working below 1470?
>=20
> 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.
>=20
> > 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 below
> 1470. If
> > I am wrong good, but I think this is an important piece for how to hand=
le
> the
> > next main issue.
>=20
> 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.)
>=20
> > UDP encapsulation and IP fragments.
>   ----------------------------------
> > I see it as a big issue that UDP encapsulation is the native one, and t=
hat
> > relies on IP fragmentation despite the need for reliable fragmentation.
> With
> > the setup of having to support 1470 MTU on TRILL level some packets wil=
l
> 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 problem
> here is
> > that if one tries to rely on IP fragments one will have issues with pac=
kets
> > 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 to no=
t
> get IP
> > fragements 2. Determine MTU and implement an fragmentation
> mechanism on top of
> > UDP.
>=20
> 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 have
> 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 are
> 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.
>=20
> > Zero Checksum:
> > --------------
> >
> > Section 5.4:
> >
> > UDP Checksum - as specified in [RFC0768]
> >
> > Considering the fast path encapsulation desire, I am surprised to not s=
ee
> 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 apply
> >    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 shou=
ld
> > document that Trill fulfills the requirements that the applicability st=
atement
> > 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 done.
>=20
> OK. We'll look into it.
>=20
> > TCP Encapsulation issue
> > -----------------------
> >
> > Section 5.6:
> >
> > The TCP encapsulation appear to be missing an delimiter format allowing
> each
> > individual TRILL packet/payload to be read out of the TCP's byte stream=
. In
> > other words, a normal implementation has no way of ensuring that the TC=
P
> > payload starts with the start of a new TRILL payload. Multiple small TR=
ILL
> > payloads may be included in the same TCP payload, and also only parts a=
s
> 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 inclu=
ded
> in
> > the TRILL header. The most straight forward delimiter is a 2-byte lengt=
h
> field
> > for the TRILL payload to be encapsulated.
>=20
> Right. It might also be useful to include some sort of check field, as
> is done in BGP, to detect if you are out of sync in parsing the TCP
> stream.
>=20
> 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 handling
> 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 not
> be too hard.
>=20
> > Section 5.6:
> >
> > TCP endpoint requirements. I do wonder if an application like TRILL act=
ual
> > would need to discuss performance impacting implementation choices or
> > limitations. For example use of NAGLE, the requirements on buffer sizes=
 in
> > relation to Bandwidth delay products, as buffer memory in a RBridge wil=
l
> impact
> > performance.
>=20
> 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?
>=20
> > Congestion Control
> > ------------------
> > First thanks for the effort here.
>=20
> You're welcome.
>=20
> > 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, specific
> >    congestion control mechanisms are commonly needed.  However, if the
> >    traffic being carried by the TRILL over IP link is already congestio=
n
> >    controlled and the size and volatility of the TRILL IS-IS link state
> >    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 way of
> knowing
> > which traffic is actually congestion controlled, considering that TRILL
> provides
> > an layer 2 abstraction. I wonder if there should be any type of white l=
ist 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 any
> > recommendation to prevent traffic that is not controlled to be forwarde=
d,
> can
> > lead to congestion issues.
> >
> > The other issue I think may exist is the issue serial unicast emulation=
 of
> > broadcast/multicast creates. As this amplifies the outgoing packet rate=
 with
> > a factor of how many addresses are configured for serial unicast this c=
an
> > be significant traffic expansion. Thus, I think additional consideratio=
ns are
> > needed here, and maybe rate limiting of the amount of traffic to be
> multicasted.
>=20
> OK. We can think about those issues.
>=20
> > 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.
>=20
> 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 an
> Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in
> RFC 7172.
>=20
> Some of the above could be added to the draft for clarity.
>=20
> > If I understand this correctly, the idea here is to look into the inner
> > layer 2 frames, and use the flow equivalents that exists on that level =
and
> > hash that into value that maps the flows onto the source port range.
>=20
> Yes.
>=20
> > I think this text should include a summary of the principle and ensure =
to
> > note the important requirement that what is considered flows in the inn=
er
> > must not result in being striped over multiple source ports as this may=
 lead
> to
> > reordering issues due to packets taking different paths.
>=20
> 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.
>=20
> > NAT and TRILL over IP:
> > Section 8.5:
> >
> > If one like to use TRILL over IP through a NAT, then there are some ver=
y
> > important considerations that are missing. First the need for static bi=
nding
> > configurations or the need for determining ones external address(es) an=
d
> be
> > able to communicate that to the peer RBridges, and in addition ensure t=
hat
> one
> > has keep-alives to that the NAT binding never times out.
>=20
> 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.
>=20
> > 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.
>=20
> So perhaps the recommendation should be to configure the port to use
> TCP if there will be fragmentation.
>=20
> > 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). Note th=
at
> this
> > will restrict the MTU even further and thus ensure that the 1470
> requirement
> > cannot be fulfilled even without additional tunnels over an 1500 bytes =
MTU
> > Ethernet infrastructure.
> >
> > I would note that also firewalls likely have issues with IP fragments f=
or the
> > same reason, they require significant amount of state to be verified if=
 they
> > should be let through.
> >
> > In general I think you should create a configuration that has chance to=
 work
> > through most middleboxes, but I think you should require static binding=
s. 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.
>=20
> 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.
>=20
> 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
>=20
> > Cheers
> >
> > Magnus Westerlund
>=20
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art


From nobody Mon Jun 26 20:03:00 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5147128896; Mon, 26 Jun 2017 20:02:52 -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 xKg0B8nQ-tAD; Mon, 26 Jun 2017 20:02:50 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC8A128854; Mon, 26 Jun 2017 20:02:50 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id z62so10926960ioi.3; Mon, 26 Jun 2017 20:02:50 -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=xk3loawHtrRMTl5VZ0TK1CSeuPzglTz6W37yDd7eJC0=; b=dPQnZkwASPlKAuPArYjDZ9E0Drz3F+8iY5aLfwNCO9aIbQA6XMu+Vu0iNmDfj9duKr tg2v6AolHqZavdRFQJSS/m5wimjHGukZGaD3vUOz2cz/cgrDZ+SLNDcV4VH9meAcxZhp /2q+Bx2Vk9ZaDJ1IfvP6nzj8zS2DTVoZTWKWbkz6ZpXPhXyTRSdybAZ7Y1KsIzC01mc2 B0nQn1E/OTCe8AcRbNTf7BnqZWvRy43svdX/ljY5ufpoEuAPK5LwpI0BebuwDtz+Z+si 3kRnmT1RNH9PVWyiDu+tourp3Hq5XJNSi2fNnm2CpPANcamgpU1oz8QR+3vAjDNlXQeR Wsag==
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=xk3loawHtrRMTl5VZ0TK1CSeuPzglTz6W37yDd7eJC0=; b=Gc7Rb+WYQPBcWn0VBOhev2anvCgQY44ehQkhzAS1AaomffB/nPT0InUDu3wWcT1Lr3 h++yd1091/s7h2e8vMgvBdLVKb5NhNHMRxqVGcaYMig4KJPoi61B7zlgtP6+3gC5Ry/j tHRaRBeaXNNqAt1oEwCEhVuMViyH6uzhNVfUmjEZkDicPIUX8Ska1FxhZ14d41aJJAdB QJiVoQkzpuI5JhMH6v04bwd8o/riyTWy2b8JHjD5tFeSuD5NmzprwE6RIMpvfreaJfkW UFqEYrnaUFRdmO0xeWlNr0lYJiLOcrOB9kjE1Tn2j3uy+j2F6yi1BjYMFc4kEKCmPWX2 VZNg==
X-Gm-Message-State: AKS2vOwb3bBOkRjkIRySJsgtit7noINY+IyOvn5A3cF1P6sIhxq3dkh7 gVmtBNkAnUAjxIT2gq4meT3de7QGew==
X-Received: by 10.107.31.209 with SMTP id f200mr4626629iof.231.1498532569237;  Mon, 26 Jun 2017 20:02:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Mon, 26 Jun 2017 20:02:33 -0700 (PDT)
In-Reply-To: <149826797586.7852.1637929087755767570@ietfa.amsl.com>
References: <149826797586.7852.1637929087755767570@ietfa.amsl.com>
From: Donald Eastlake 
Date: Mon, 26 Jun 2017 23:02:33 -0400
Message-ID: 
To: Brian Carpenter 
Cc: "gen-art@ietf.org Review Team" , draft-ietf-trill-mtu-negotiation.all@ietf.org,  "trill@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [trill] Genart last call review of draft-ietf-trill-mtu-negotiation-05
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 03:02:53 -0000

Hi Brian,

Thanks for the comments. See below.

On Fri, Jun 23, 2017 at 9:32 PM, Brian Carpenter
 wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
>
> Gen-ART Last Call review of draft-ietf-trill-mtu-negotiation-05
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-trill-mtu-negotiation-05.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-06-24
> IETF LC End Date: 2017-06-28
> IESG Telechat date: 2017-07-06
>
> Summary: Ready with issues
> --------
>
> Minor issues:
> -------------
>
>> 2. Link-Wide TRILL MTU Size
> ...
>>   ...RBridges MUST support the Extended L1 Circuit-Scoped
>>   (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to
>>   exchange their maximally supportable value of "Lz".
>
> Where does that value come from? Is it configured, derived from
> the interface in some way, or discovered?

It's somewhat similar to the originatingL1LSPBufferSize which is
talked about in Section 5 of RFC 7780, except that there is no reason
to worry about coordinating across the TRILL campus. How about adding
wording something like:

      The originatingSNPBufferSize for a port is the minimum of the
following two quantities, but not less than 1470 bytes: (1) the
maximum MTU of the port and (2) the maximum LSP size that the TRILL
IS-IS implementation can handle,

>> 2.1. Operations
>>
>>   Lz is reported using a originatingSNPBufferSize TLV that MUST occur
>>   in fragment zero of the RBridge's E-L1CS FS-LSP. An
>>   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>>   is ignored.
>
> Is that really what you mean? I thought Lz was an optional extra. So I think
> you mean:
>
> 2.1. Operations
>
>    Lz MAY be reported using a originatingSNPBufferSize TLV that occurs
>    in fragment zero of the RBridge's E-L1CS FS-LSP. An
>    originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>    MUST be ignored.

Yes, the "MUST" was just in reference to being in fragment zero, not
that it has to occur, so your wording seems better.

>> 3. Link MTU Size Testing
> ...
>>   Step 0:
> ...
>>      b) Link MTU size is set to 1470, lowerBound is set to 1470,
>>         upperBound is set to the link-wide Lz, linkMtuSize is set to
>>         [(lowerBound + upperBound)/2] (Operation "[...]" returns the
>>         fraction-rounded-up integer.).
>
> This is confusing. "linkMtuSize" was defined as a local variable.
> But what is "Link MTU size"? Is that another local variable?
> If so, how is it different from "linkMtuSize"?
> It is used again in part 2) of step 2 below.

I don't want to say anything about that before checking with the primary author.

> Also, I assume "Lz" is the value previously agreed among the nodes,
> but that should be made clear to the reader.
>
> Nits:
> -----
>
>> 1. Introduction
> ...
>>   topology. While in this document, a new RECOMMENDED link-wide minimum
>>   inter-RBridge MTU size, Lz, is specified. By calculating a using Lz
>>   as specified herein, link-scoped PDUs can be formatted greater than
>>   the campus-wide Sz up to the link-wide minimum acceptable inter-
>>   RBridge MTU size potentially improving the efficiency of link
>>   utilization and speeding link state convergence.
>
> I cannot parse those two sentences. What does the "While" refer to?
> What does "By calculating a using Lz" mean?

I believe the sentences should be

"... In this document, a new RECOMMENDED link-wide minimum
inter-RBridge MTU size, Lz, is specified. By calculating and using Lz
as specified herein, ..."

>> 3. Link MTU Size Testing
> ...
>>      b) Link MTU size is set to 1470, lowerBound is set to 1470,
>>         upperBound is set to the link-wide Lz, linkMtuSize is set to
>>         [(lowerBound + upperBound)/2] (Operation "[...]" returns the
>>         fraction-rounded-up integer.).
>
> This would be easier to understand:
>
> 3. Link MTU Size Testing
> ...
>       b) Link MTU size is set to 1470, lowerBound is set to 1470,
>          upperBound is set to the link-wide Lz, linkMtuSize is set to
>          [(lowerBound + upperBound)/2], rounded up to the nearest integer.

OK.

> Repeat this in the following two cases; a normal reader will not
> remember the rounding rule:
>
> ...
>    1) If RB1 fails to receive an MTU-ack from RB2 after k tries:
>
>          upperBound is set to linkMtuSize and linkMtuSize is set to
>          [(lowerBound + upperBound)/2], rounded up to the nearest integer.
>
>    2) If RB1 receives an MTU-ack to a probe of size linkMtuSize from
>       RB2:
>
>          link MTU size is set to linkMtuSize, lowerBound is set to
>          linkMtuSize and linkMtuSize is set to [(lowerBound +
>          upperBound)/2], rounded up to the nearest integer.

That seems reasonable.

> --

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


From nobody Tue Jun 27 01:07:13 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE1C12942F; Tue, 27 Jun 2017 01:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tykkvG6ZCu7n; Tue, 27 Jun 2017 01:07:02 -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 AC33212009C; Tue, 27 Jun 2017 01:07:01 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJG46933; Tue, 27 Jun 2017 08:06:59 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 09:06:58 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 27 Jun 2017 16:06:53 +0800
From: "Zhangmingui (Martin)" 
To: Donald Eastlake , Brian Carpenter 
CC: "gen-art@ietf.org Review Team" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" 
Thread-Topic: Genart last call review of draft-ietf-trill-mtu-negotiation-05
Thread-Index: AQHS7InVClNR32nha0euui7y5iJWUKI3hHSAgAC9CWA=
Date: Tue, 27 Jun 2017 08:06:53 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7A653E64C@NKGEML515-MBX.china.huawei.com>
References: <149826797586.7852.1637929087755767570@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.146.93]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59521223.0118, 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: 8b6f24d469e6592969633280401ed865
Archived-At: 
Subject: Re: [trill] Genart last call review of draft-ietf-trill-mtu-negotiation-05
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 08:07:06 -0000

SGkgQnJpYW4gYW5kIERvbmFsZCwNCg0KVGhhbmtzIGEgbG90IGZvciB0aGUgY29tbWVudHMuIFBs
ZWFzZSBzZWUgdGhlIHJlc3BvbnNlcyBhcyBpbmxpbmUgYmVsb3cuDQoNCj4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRG9uYWxkIEVhc3RsYWtlIFttYWlsdG86ZDNlM2UzQGdt
YWlsLmNvbV0NCj4gU2VudDogVHVlc2RheSwgSnVuZSAyNywgMjAxNyAxMTowMyBBTQ0KPiBUbzog
QnJpYW4gQ2FycGVudGVyDQo+IENjOiBnZW4tYXJ0QGlldGYub3JnIFJldmlldyBUZWFtOyBkcmFm
dC1pZXRmLXRyaWxsLW10dS1uZWdvdGlhdGlvbi5hbGxAaWV0Zi5vcmc7DQo+IHRyaWxsQGlldGYu
b3JnDQo+IFN1YmplY3Q6IFJlOiBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRm
LXRyaWxsLW10dS1uZWdvdGlhdGlvbi0wNQ0KPiANCj4gSGkgQnJpYW4sDQo+IA0KPiBUaGFua3Mg
Zm9yIHRoZSBjb21tZW50cy4gU2VlIGJlbG93Lg0KPiANCj4gT24gRnJpLCBKdW4gMjMsIDIwMTcg
YXQgOTozMiBQTSwgQnJpYW4gQ2FycGVudGVyDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j
b20+IHdyb3RlOg0KPiA+IFJldmlld2VyOiBCcmlhbiBDYXJwZW50ZXINCj4gPiBSZXZpZXcgcmVz
dWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KPiA+DQo+ID4gR2VuLUFSVCBMYXN0IENhbGwgcmV2aWV3
IG9mIGRyYWZ0LWlldGYtdHJpbGwtbXR1LW5lZ290aWF0aW9uLTA1DQo+ID4NCj4gPiBJIGFtIHRo
ZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBB
cmVhDQo+ID4gUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRz
IGJlaW5nIHByb2Nlc3NlZCBieQ0KPiA+IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBs
ZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UNCj4gPiBhbnkgb3RoZXIgbGFzdCBj
YWxsIGNvbW1lbnRzLg0KPiA+DQo+ID4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUg
dGhlIEZBUSBhdA0KPiA+IDxodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9hcmVhL2dlbi90cmFj
L3dpa2kvR2VuQXJ0ZmFxPi4NCj4gPg0KPiA+IERvY3VtZW50OiBkcmFmdC1pZXRmLXRyaWxsLW10
dS1uZWdvdGlhdGlvbi0wNS50eHQNCj4gPiBSZXZpZXdlcjogQnJpYW4gQ2FycGVudGVyDQo+ID4g
UmV2aWV3IERhdGU6IDIwMTctMDYtMjQNCj4gPiBJRVRGIExDIEVuZCBEYXRlOiAyMDE3LTA2LTI4
DQo+ID4gSUVTRyBUZWxlY2hhdCBkYXRlOiAyMDE3LTA3LTA2DQo+ID4NCj4gPiBTdW1tYXJ5OiBS
ZWFkeSB3aXRoIGlzc3Vlcw0KPiA+IC0tLS0tLS0tDQo+ID4NCj4gPiBNaW5vciBpc3N1ZXM6DQo+
ID4gLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4+IDIuIExpbmstV2lkZSBUUklMTCBNVFUgU2l6ZQ0K
PiA+IC4uLg0KPiA+PiAgIC4uLlJCcmlkZ2VzIE1VU1Qgc3VwcG9ydCB0aGUgRXh0ZW5kZWQgTDEg
Q2lyY3VpdC1TY29wZWQNCj4gPj4gICAoRS1MMUNTKSBmbG9vZGluZyBzY29wZSBMU1AgKEZTLUxT
UCkuIFRoZXkgdXNlIHRoYXQgZmxvb2RpbmcgdG8NCj4gPj4gICBleGNoYW5nZSB0aGVpciBtYXhp
bWFsbHkgc3VwcG9ydGFibGUgdmFsdWUgb2YgIkx6Ii4NCj4gPg0KPiA+IFdoZXJlIGRvZXMgdGhh
dCB2YWx1ZSBjb21lIGZyb20/IElzIGl0IGNvbmZpZ3VyZWQsIGRlcml2ZWQgZnJvbSB0aGUNCj4g
PiBpbnRlcmZhY2UgaW4gc29tZSB3YXksIG9yIGRpc2NvdmVyZWQ/DQo+IA0KPiBJdCdzIHNvbWV3
aGF0IHNpbWlsYXIgdG8gdGhlIG9yaWdpbmF0aW5nTDFMU1BCdWZmZXJTaXplIHdoaWNoIGlzIHRh
bGtlZCBhYm91dCBpbg0KPiBTZWN0aW9uIDUgb2YgUkZDIDc3ODAsIGV4Y2VwdCB0aGF0IHRoZXJl
IGlzIG5vIHJlYXNvbiB0byB3b3JyeSBhYm91dA0KPiBjb29yZGluYXRpbmcgYWNyb3NzIHRoZSBU
UklMTCBjYW1wdXMuIEhvdyBhYm91dCBhZGRpbmcgd29yZGluZyBzb21ldGhpbmcNCj4gbGlrZToN
Cj4gDQo+ICAgICAgIFRoZSBvcmlnaW5hdGluZ1NOUEJ1ZmZlclNpemUgZm9yIGEgcG9ydCBpcyB0
aGUgbWluaW11bSBvZiB0aGUgZm9sbG93aW5nDQo+IHR3byBxdWFudGl0aWVzLCBidXQgbm90IGxl
c3MgdGhhbiAxNDcwIGJ5dGVzOiAoMSkgdGhlIG1heGltdW0gTVRVIG9mIHRoZSBwb3J0DQo+IGFu
ZCAoMikgdGhlIG1heGltdW0gTFNQIHNpemUgdGhhdCB0aGUgVFJJTEwgSVMtSVMgaW1wbGVtZW50
YXRpb24gY2FuIGhhbmRsZSwNCg0KW01pbmd1aV0gT0suDQoNCj4gDQo+ID4+IDIuMS4gT3BlcmF0
aW9ucw0KPiA+Pg0KPiA+PiAgIEx6IGlzIHJlcG9ydGVkIHVzaW5nIGEgb3JpZ2luYXRpbmdTTlBC
dWZmZXJTaXplIFRMViB0aGF0IE1VU1Qgb2NjdXINCj4gPj4gICBpbiBmcmFnbWVudCB6ZXJvIG9m
IHRoZSBSQnJpZGdlJ3MgRS1MMUNTIEZTLUxTUC4gQW4NCj4gPj4gICBvcmlnaW5hdGluZ1NOUEJ1
ZmZlclNpemUgQVBQc3ViLVRMViBvY2N1cnJpbmcgaW4gYW55IG90aGVyIGZyYWdtZW50DQo+ID4+
ICAgaXMgaWdub3JlZC4NCj4gPg0KPiA+IElzIHRoYXQgcmVhbGx5IHdoYXQgeW91IG1lYW4/IEkg
dGhvdWdodCBMeiB3YXMgYW4gb3B0aW9uYWwgZXh0cmEuIFNvIEkNCj4gPiB0aGluayB5b3UgbWVh
bjoNCj4gPg0KPiA+IDIuMS4gT3BlcmF0aW9ucw0KPiA+DQo+ID4gICAgTHogTUFZIGJlIHJlcG9y
dGVkIHVzaW5nIGEgb3JpZ2luYXRpbmdTTlBCdWZmZXJTaXplIFRMViB0aGF0IG9jY3Vycw0KPiA+
ICAgIGluIGZyYWdtZW50IHplcm8gb2YgdGhlIFJCcmlkZ2UncyBFLUwxQ1MgRlMtTFNQLiBBbg0K
PiA+ICAgIG9yaWdpbmF0aW5nU05QQnVmZmVyU2l6ZSBBUFBzdWItVExWIG9jY3VycmluZyBpbiBh
bnkgb3RoZXIgZnJhZ21lbnQNCj4gPiAgICBNVVNUIGJlIGlnbm9yZWQuDQoNCltNaW5ndWldIE9L
Lg0KDQo+IA0KPiBZZXMsIHRoZSAiTVVTVCIgd2FzIGp1c3QgaW4gcmVmZXJlbmNlIHRvIGJlaW5n
IGluIGZyYWdtZW50IHplcm8sIG5vdCB0aGF0IGl0IGhhcw0KPiB0byBvY2N1ciwgc28geW91ciB3
b3JkaW5nIHNlZW1zIGJldHRlci4NCj4gDQo+ID4+IDMuIExpbmsgTVRVIFNpemUgVGVzdGluZw0K
PiA+IC4uLg0KPiA+PiAgIFN0ZXAgMDoNCj4gPiAuLi4NCj4gPj4gICAgICBiKSBMaW5rIE1UVSBz
aXplIGlzIHNldCB0byAxNDcwLCBsb3dlckJvdW5kIGlzIHNldCB0byAxNDcwLA0KPiA+PiAgICAg
ICAgIHVwcGVyQm91bmQgaXMgc2V0IHRvIHRoZSBsaW5rLXdpZGUgTHosIGxpbmtNdHVTaXplIGlz
IHNldCB0bw0KPiA+PiAgICAgICAgIFsobG93ZXJCb3VuZCArIHVwcGVyQm91bmQpLzJdIChPcGVy
YXRpb24gIlsuLi5dIiByZXR1cm5zIHRoZQ0KPiA+PiAgICAgICAgIGZyYWN0aW9uLXJvdW5kZWQt
dXAgaW50ZWdlci4pLg0KPiA+DQo+ID4gVGhpcyBpcyBjb25mdXNpbmcuICJsaW5rTXR1U2l6ZSIg
d2FzIGRlZmluZWQgYXMgYSBsb2NhbCB2YXJpYWJsZS4NCj4gPiBCdXQgd2hhdCBpcyAiTGluayBN
VFUgc2l6ZSI/IElzIHRoYXQgYW5vdGhlciBsb2NhbCB2YXJpYWJsZT8NCj4gPiBJZiBzbywgaG93
IGlzIGl0IGRpZmZlcmVudCBmcm9tICJsaW5rTXR1U2l6ZSI/DQo+ID4gSXQgaXMgdXNlZCBhZ2Fp
biBpbiBwYXJ0IDIpIG9mIHN0ZXAgMiBiZWxvdy4NCj4gDQo+IEkgZG9uJ3Qgd2FudCB0byBzYXkg
YW55dGhpbmcgYWJvdXQgdGhhdCBiZWZvcmUgY2hlY2tpbmcgd2l0aCB0aGUgcHJpbWFyeQ0KPiBh
dXRob3IuDQoNCltNaW5ndWldIEFzIHNwZWNpZmllZCBpbiB0aGUgdGV4dCBsZWFkaW5nIHRoZSBT
dGVwcywgImxpbmtNdHVTaXplIiBpcyBhIGxvY2FsIGludGVnZXIgdmFyaWFibGUgZm9yIGEgc3Bl
Y2lmaWMgUkJyaWRnZSB3aGlsZSAibGluayBNVFUgc2l6ZSIgaXMgbm90IGEgdmFyaWFibGUgYnV0
IGEgdmFsdWUgdGhhdCBpcyBhZ3JlZWQgYnkgdHdvIGNvbm5lY3RlZCBSQnJpZGdlcy4gVG8gYXZv
aWQgdGhlIGNvbmZ1c2lvbiwgSSBjaGFuZ2VkICJsaW5rTXR1U2l6ZSIgdG8gIlgiIGFuZCBhZGQg
dGhlIHRleHQgdG8gZXhwbGFpbiB0aGF0IGxpbmsgTVRVIHNpemUgaXMgYSB2YWx1ZSB0aGF0IGlz
IGFncmVlZCBieSB0d28gY29ubmVjdGVkIFJCcmlkZ2VzLg0KDQo+IA0KPiA+IEFsc28sIEkgYXNz
dW1lICJMeiIgaXMgdGhlIHZhbHVlIHByZXZpb3VzbHkgYWdyZWVkIGFtb25nIHRoZSBub2RlcywN
Cj4gPiBidXQgdGhhdCBzaG91bGQgYmUgbWFkZSBjbGVhciB0byB0aGUgcmVhZGVyLg0KDQpbTWlu
Z3VpXSBBZ3JlZS4gQWRkZWQgdGhlIHdvcmQgImFncmVlZCIgaW4gU2VjdGlvbiAyLg0KDQo+ID4N
Cj4gPiBOaXRzOg0KPiA+IC0tLS0tDQo+ID4NCj4gPj4gMS4gSW50cm9kdWN0aW9uDQo+ID4gLi4u
DQo+ID4+ICAgdG9wb2xvZ3kuIFdoaWxlIGluIHRoaXMgZG9jdW1lbnQsIGEgbmV3IFJFQ09NTUVO
REVEIGxpbmstd2lkZQ0KPiBtaW5pbXVtDQo+ID4+ICAgaW50ZXItUkJyaWRnZSBNVFUgc2l6ZSwg
THosIGlzIHNwZWNpZmllZC4gQnkgY2FsY3VsYXRpbmcgYSB1c2luZyBMeg0KPiA+PiAgIGFzIHNw
ZWNpZmllZCBoZXJlaW4sIGxpbmstc2NvcGVkIFBEVXMgY2FuIGJlIGZvcm1hdHRlZCBncmVhdGVy
IHRoYW4NCj4gPj4gICB0aGUgY2FtcHVzLXdpZGUgU3ogdXAgdG8gdGhlIGxpbmstd2lkZSBtaW5p
bXVtIGFjY2VwdGFibGUgaW50ZXItDQo+ID4+ICAgUkJyaWRnZSBNVFUgc2l6ZSBwb3RlbnRpYWxs
eSBpbXByb3ZpbmcgdGhlIGVmZmljaWVuY3kgb2YgbGluaw0KPiA+PiAgIHV0aWxpemF0aW9uIGFu
ZCBzcGVlZGluZyBsaW5rIHN0YXRlIGNvbnZlcmdlbmNlLg0KPiA+DQo+ID4gSSBjYW5ub3QgcGFy
c2UgdGhvc2UgdHdvIHNlbnRlbmNlcy4gV2hhdCBkb2VzIHRoZSAiV2hpbGUiIHJlZmVyIHRvPw0K
PiA+IFdoYXQgZG9lcyAiQnkgY2FsY3VsYXRpbmcgYSB1c2luZyBMeiIgbWVhbj8NCj4gDQo+IEkg
YmVsaWV2ZSB0aGUgc2VudGVuY2VzIHNob3VsZCBiZQ0KPiANCj4gIi4uLiBJbiB0aGlzIGRvY3Vt
ZW50LCBhIG5ldyBSRUNPTU1FTkRFRCBsaW5rLXdpZGUgbWluaW11bSBpbnRlci1SQnJpZGdlDQo+
IE1UVSBzaXplLCBMeiwgaXMgc3BlY2lmaWVkLiBCeSBjYWxjdWxhdGluZyBhbmQgdXNpbmcgTHog
YXMgc3BlY2lmaWVkIGhlcmVpbiwgLi4uIg0KDQpbTWluZ3VpXSBPSy4NCg0KPiANCj4gPj4gMy4g
TGluayBNVFUgU2l6ZSBUZXN0aW5nDQo+ID4gLi4uDQo+ID4+ICAgICAgYikgTGluayBNVFUgc2l6
ZSBpcyBzZXQgdG8gMTQ3MCwgbG93ZXJCb3VuZCBpcyBzZXQgdG8gMTQ3MCwNCj4gPj4gICAgICAg
ICB1cHBlckJvdW5kIGlzIHNldCB0byB0aGUgbGluay13aWRlIEx6LCBsaW5rTXR1U2l6ZSBpcyBz
ZXQgdG8NCj4gPj4gICAgICAgICBbKGxvd2VyQm91bmQgKyB1cHBlckJvdW5kKS8yXSAoT3BlcmF0
aW9uICJbLi4uXSIgcmV0dXJucyB0aGUNCj4gPj4gICAgICAgICBmcmFjdGlvbi1yb3VuZGVkLXVw
IGludGVnZXIuKS4NCj4gPg0KPiA+IFRoaXMgd291bGQgYmUgZWFzaWVyIHRvIHVuZGVyc3RhbmQ6
DQo+ID4NCj4gPiAzLiBMaW5rIE1UVSBTaXplIFRlc3RpbmcNCj4gPiAuLi4NCj4gPiAgICAgICBi
KSBMaW5rIE1UVSBzaXplIGlzIHNldCB0byAxNDcwLCBsb3dlckJvdW5kIGlzIHNldCB0byAxNDcw
LA0KPiA+ICAgICAgICAgIHVwcGVyQm91bmQgaXMgc2V0IHRvIHRoZSBsaW5rLXdpZGUgTHosIGxp
bmtNdHVTaXplIGlzIHNldCB0bw0KPiA+ICAgICAgICAgIFsobG93ZXJCb3VuZCArIHVwcGVyQm91
bmQpLzJdLCByb3VuZGVkIHVwIHRvIHRoZSBuZWFyZXN0DQo+IGludGVnZXIuDQo+IA0KPiBPSy4N
Cj4gDQo+ID4gUmVwZWF0IHRoaXMgaW4gdGhlIGZvbGxvd2luZyB0d28gY2FzZXM7IGEgbm9ybWFs
IHJlYWRlciB3aWxsIG5vdA0KPiA+IHJlbWVtYmVyIHRoZSByb3VuZGluZyBydWxlOg0KDQpbTWlu
Z3VpXSBDaGFuZ2VkIHRocmVlIG9jY3VycmVuY2VzIGluIHRoZSBkb2N1bWVudC4NCg0KDQo+ID4N
Cj4gPiAuLi4NCj4gPiAgICAxKSBJZiBSQjEgZmFpbHMgdG8gcmVjZWl2ZSBhbiBNVFUtYWNrIGZy
b20gUkIyIGFmdGVyIGsgdHJpZXM6DQo+ID4NCj4gPiAgICAgICAgICB1cHBlckJvdW5kIGlzIHNl
dCB0byBsaW5rTXR1U2l6ZSBhbmQgbGlua010dVNpemUgaXMgc2V0IHRvDQo+ID4gICAgICAgICAg
Wyhsb3dlckJvdW5kICsgdXBwZXJCb3VuZCkvMl0sIHJvdW5kZWQgdXAgdG8gdGhlIG5lYXJlc3QN
Cj4gaW50ZWdlci4NCj4gPg0KPiA+ICAgIDIpIElmIFJCMSByZWNlaXZlcyBhbiBNVFUtYWNrIHRv
IGEgcHJvYmUgb2Ygc2l6ZSBsaW5rTXR1U2l6ZSBmcm9tDQo+ID4gICAgICAgUkIyOg0KPiA+DQo+
ID4gICAgICAgICAgbGluayBNVFUgc2l6ZSBpcyBzZXQgdG8gbGlua010dVNpemUsIGxvd2VyQm91
bmQgaXMgc2V0IHRvDQo+ID4gICAgICAgICAgbGlua010dVNpemUgYW5kIGxpbmtNdHVTaXplIGlz
IHNldCB0byBbKGxvd2VyQm91bmQgKw0KPiA+ICAgICAgICAgIHVwcGVyQm91bmQpLzJdLCByb3Vu
ZGVkIHVwIHRvIHRoZSBuZWFyZXN0IGludGVnZXIuDQo+IA0KPiBUaGF0IHNlZW1zIHJlYXNvbmFi
bGUuDQo+IA0KPiA+IC0tDQo+IA0KPiBUaGFua3MsDQo+IERvbmFsZA0KPiA9PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09DQo+ICBEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMz
My0yMjcwIChjZWxsKQ0KPiAgMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVT
QSAgZDNlM2UzQGdtYWlsLmNvbQ0KDQoNCg0KVGhhbmtzLA0KTWluZ3VpDQo=


From nobody Tue Jun 27 09:05:19 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C5A129B94 for ; Tue, 27 Jun 2017 09:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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); dkim=pass (2048-bit key) header.d=outlook.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 5qGjyQzZWASC for ; Tue, 27 Jun 2017 09:05:16 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255046.outbound.protection.outlook.com [40.92.255.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15070129ABD for ; Tue, 27 Jun 2017 09:05:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=04QWfYkVk/CjREHX5VFeWBYtDljxemaudbKiosoZsf0=; b=RPflWkY53tfQkjD2Np0jGLpglgl6a/kIR+pLFahSKBy/kDXC5SbWOQuXTPi74fP8x/yjRBdipHPf5qTbOwm37ue4v9WKEuGIwCZRyEssDublDLDYhJyAlq7H5nk3AYoMwejrJMPAjQdLvB4wVcxfElznhFxpOTRMIU+2VtQrMhWNh0+SSIRTkeLbOddMck/GYYjmKkBuvtsGSMhoAwjzQFyUGnnz/fel0xQJx+C/eC3gwbZbSl+IySZTopTEDG1+vPucM/lu7jDj9M4+1CW8VI1MFdB5inrMUjo/j/MN3NESH6U3/mROVoUoBzsd6Brh3TiOI/G27eJqC6cxhvJqeA==
Received: from PU1APC01FT033.eop-APC01.prod.protection.outlook.com (10.152.252.60) by PU1APC01HT007.eop-APC01.prod.protection.outlook.com (10.152.252.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1157.12; Tue, 27 Jun 2017 16:05:11 +0000
Received: from SG2PR0201MB2256.apcprd02.prod.outlook.com (10.152.252.59) by PU1APC01FT033.mail.protection.outlook.com (10.152.252.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.9 via Frontend Transport; Tue, 27 Jun 2017 16:05:10 +0000
Received: from SG2PR0201MB2256.apcprd02.prod.outlook.com ([fe80::2da4:5020:edfc:f769]) by SG2PR0201MB2256.apcprd02.prod.outlook.com ([fe80::2da4:5020:edfc:f769%18]) with mapi id 15.01.1199.019; Tue, 27 Jun 2017 16:05:10 +0000
From: =?gb2312?B?ucsgyNY=?= 
To: "trill@ietf.org" 
CC: "shares@ndzh.com" 
Thread-Topic: RE:[trill] WG LC for draft-ietf-trill-smart-endnodes  (5/31 to 6/13)
Thread-Index: AQHS714as5emQ18bxkeHCpOuoK3dig==
Date: Tue, 27 Jun 2017 16:05:09 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ndzh.com; dkim=none (message not signed) header.d=none;ndzh.com; dmarc=none action=none header.from=outlook.com;
x-incomingtopheadermarker: OriginalChecksum:81AD944C43675F1DCA096C8ECF7D2405E6F598B232348333C6C6A3CEF88D4A56; UpperCasedChecksum:4EC08C91A80EE4447A97E85A048AD123F4E1251B0DF8686A087867E6998A4965; SizeAsReceived:7187; Count:43
x-tmn: [+5sSQFK5LfyLI2ubR9ya80Zw7uMYmu4LSl3fwyUn1Zo=]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT007; 7:MHtk7ykeviEiBKvT0foVVzPtrQ630/hzzLO/s+xqX31k8jd2NGwPUvIRXR1/gRSlziTuSUmGScKgn39URrAZgmJPdnPk0qkoD4K4l8EXNgHIts8YtaxcQTl7syLPebcD7B8cIoE7NN/Q2kKlSUkaveRMI9KJdjJukbsJjcpWl/hckgHg5QUuZyB/dBtf6eq4f7jcofD4Ews2jZ6JWrGhOtuEhyEzhqS0eMu3/4lm+RBoqVGd9neSlOseAdV2IsFAuJkW+xcMtO0eomr/hqwgyB6AWjP+pvo6vaaVN7eck8fX09U2H8yL+o8uQLez7ihpT0jv0G353bx+GMG5vak1MvAfMeBffPtj75bAGRs5BqpYGihZmhdf1caAm3HTIvAbhsC6PKTtNBNg1q42Yl7VGLiyvJQjEQpl6a5K6FY4e/HMECOI2qJLM5WOTC8akWg4Xu0xlp/5XNE/tQEH2owGT4ZTWM7FXJzWyUsrlTKef7grLgeppMcgdSMJTU0+OXJ5NefBUaqVsiaqXgBoJMMrU1uGXkMNkNgULqkWSp4rgSJVapgQ4HQ2T4g6lqyMYmdVZxmWW6mZhlhwhhSlRGAlIe/ILcyo1mwc4VGsPHxwIgcRBKBI6HRBcErkm8OJtYegZ6jBUFpPJEVtoNIswyFtYUFBbAv1UzYiu+PBERy7FIrtMd5v2Ubu0gmViuC9ZSNM4ef51HoxYYpetoqxHj9Was4S2ZXbHMOyHbkA/Fv36hqoHsvslqlNbRI3xCvdg0QiTPH0KUdcCCFTegDLhTgbSQ==
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT007; H:SG2PR0201MB2256.apcprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; 
x-ms-traffictypediagnostic: PU1APC01HT007:
x-ms-office365-filtering-correlation-id: 79659472-859f-4842-2c41-08d4bd7649d9
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:PU1APC01HT007; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:PU1APC01HT007; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:PU1APC01HT007; 
x-forefront-prvs: 0351D213B3
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SG2PR0201MB2256FBE061D417E57EF181DE8BDC0SG2PR0201MB2256_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2017 16:05:09.9780 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT007
Archived-At: 
Subject: Re: [trill] WG LC for draft-ietf-trill-smart-endnodes (5/31 to 6/13)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 16:05:18 -0000

--_000_SG2PR0201MB2256FBE061D417E57EF181DE8BDC0SG2PR0201MB2256_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGksIGRlYXIgYWxsLg0KDQpJIHdvbmRlciB3aGV0aGVyIGl0J3Mgc3RpbGwgaW4gdGltZSB0byBz
aG93IG15IG9waW5pb24gb24gTEMgb2YgdGhpcyBkcmFmdC4gQWZ0ZXIgY29tbXVuaWNhdGlvbiB3
aXRoIGF1dGhvcnMsIEkgdGhpbmsgaXQgd29ya3Mgb24gdGhlIHByb2JsZW0gb2Ygc2l6ZSBhbmQg
ZnJlc2huZXNzIG9mIGVuZG5vZGUgbGVhcm5pbmcgdGFibGUgaW4gZWRnZSBSQnMgaW4gdGhlIFRy
aWxsIGRvbWFpbiBieSBzbWFydCBlbmRub2RlcyBwcm92aWRlZC4gU28gSSBzdXBwb3J0IG9uIHRo
ZSBhZG9wdGlvbi4NCg0KDQpHdSBSb25nDQoNCtStyrzTyrz+DQq3orz+yMujuiA8c2hhcmVzQG5k
emguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PjsNCsrVvP7Iy6O6IDx0cmlsbEBpZXRmLm9y
ZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+PjsNCrOty83Iy6O6IDx0cmlsbC1jaGFpcnNAaWV0Zi5v
cmc8bWFpbHRvOnRyaWxsLWNoYWlyc0BpZXRmLm9yZz4+OyA8ZHJhZnQtaWV0Zi10cmlsbC1zbWFy
dC1lbmRub2Rlc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10cmlsbC1zbWFydC1lbmRub2Rl
c0BpZXRmLm9yZz4+Ow0KyNUgxtogo7oyMDE3xOowNdTCMzHI1SAyMjoxNQ0K1vcgzOIgo7pbdHJp
bGxdIFdHIExDIGZvciBkcmFmdC1pZXRmLXRyaWxsLXNtYXJ0LWVuZG5vZGVzICAoNS8zMSB0byA2
LzEzKQ0KDQoNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExDIGZvciBkcmFmdC1pZXRmLXRyaWxs
LXNtYXJ0LWVuZG5vZGVzLCBhbmQgeW91IGNhbiAgc2VlIHRoZSBkcmFmdCBhdDoNCmh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJpbGwtc21hcnQtZW5kbm9kZXMv
DQoNCkR1ZSB0byBteSBlcnJvcnMsIHRoaXMgV0cgTEMgaGFzIGJlZW4gZGVsYXllZC4gIFdlIHdp
bGwgYmUgcnVubmluZyB0aGlzIFdHIExDIGluIHBhcmFsbGVsIHdpdGggdGhlIElQUiBjYWxsLiAg
VGhlIGF1dGhvcnMgKFJhZGlhLCBGYW5nd2VpLCBEb25hbGQsIEtlc2F2YSwgVGluZykgc2hvdWxk
IHNlbmQgdGhlaXIgSVBSIHN0YXRlbWVudHMgYnkgNi81LiBJZiB0aGUgSVBSIHN0YXRlbWVudHMg
YXJlIG5vdCByZWNlaXZlZCwgd2Ugd2lsbCBuZWVkIHRvIGV4dGVuZCB0aGUgV0cgTEMuDQoNCkZv
ciB0aGlzIFdHLCBwbGVhc2UgY29uc2lkZXIgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQoNCg0K
ICAxLiAgRG9lcyB0aGUgZHJhZnQtaWV0Zi10cmlsbC1zbWFydC1lbmRub2RlcyBwcm92aWRlIGEg
Z29vZCBzb2x1dGlvbiBmb3IgdGhlIHByb2JsZW0gb2YgdGhlIHNpemUgYW5kIGZyZXNobmVzcyBv
ZiB0aGUgZW5kbm9kZSBsZWFybmluZyB0YWJsZSBpbiBlZGdlIFJCcmlkZ2VzIGJ5IGFsbG93aW5n
IGVuZG5vZGVzIHRvIHZvbHVudGVlciBmb3IgZW5kbm9kZSBsZWFybmluZyBhbmQgZW5jYXBzdWxh
dGlvbi9kZWNhcHN1bGF0aW9uPw0KICAyLiAgRG8geW91IGtub3cgb2YgYW55IHNpdHVhdGlvbnMg
d2hlcmUgZGVwbG95bWVudCBvZiB0aGlzIHRlY2hub2xvZ3kgd2lsbCBiZSBoZWxwZnVsPw0KICAz
LiAgSXMgdGhpcyB0ZWNobm9sb2d5IGFuZCB0aGlzIGRyYWZ0IHJlYWR5IGZvciBJRVNHIHB1Ymxp
Y2F0aW9uPw0KDQpTdWUgSGFyZXMNCg0K

--_000_SG2PR0201MB2256FBE061D417E57EF181DE8BDC0SG2PR0201MB2256_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable










Hi, dear all.


I wonder whether it's still in time to show my opinion on LC of thi=
s draft. After communication with authors, I think it works on the
 problem of size and freshness of endnode learning table in edge RBs in the=
 Trill domain by
smart endnodes provided. So I support on the adoption.







Gu Rong










=D4=AD=CA=BC=D3=CA=BC=FE=



=B7=A2=BC=FE=C8=CB=A3=BA <share=
s@ndzh.com>;

=CA=D5=BC=FE=C8=CB=A3=BA <trill@=
ietf.org>;


=B3=AD=CB=CD=C8=CB=A3=BA <trill-chairs@ietf.org>;
 <draft-ietf=
-trill-smart-endnodes@ietf.org>;<=
o:p>


=C8=D5 =C6=DA =A3=BA2017=
=C4=EA05=D4=C231=C8=D5
 22:15


=D6=F7 =CC=E2 =A3=BA[trill] WG LC for dr=
aft-ietf-trill-smart-endnodes  (5/31 to 6/13)


 


This begins a 2 week WG LC for =
draft-ietf-trill-smart-endnodes, and you can  see the draft at:


https://da=
tatracker.ietf.org/doc/draft-ietf-trill-smart-endnodes/


 


Due to my errors, this WG LC ha=
s been delayed.  We will be running this WG LC in parallel with the IP=
R call.  The authors (Radia, Fangwei, Donald, Kesava, Ting) should sen=
d their IPR statements by 6/5. If the IPR statements
 are not received, we will need to extend the WG LC.


 


For this WG, please consider th=
e following questions:


 


    

  1. Does the draft-ietf-trill-smart-endnodes provide a=
 good solution for the problem of the size and freshness of the endnode lea=
rning table in edge RBridges by allowing endnodes to volunteer for endnode =
learning and encapsulation/decapsulation?
  2. Do you know of any situations where deployment of this techno=
logy will be helpful?
  3. Is thi=
s technology and this draft ready for IESG publication?


 


Sue Hares










--_000_SG2PR0201MB2256FBE061D417E57EF181DE8BDC0SG2PR0201MB2256_--


From nobody Tue Jun 27 10:13:26 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820C812EA53; Tue, 27 Jun 2017 10:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Wz8GK2vFBeYK; Tue, 27 Jun 2017 10:13:14 -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 E0BA012EA67; Tue, 27 Jun 2017 10:13:11 -0700 (PDT)
X-AuditID: c1b4fb25-eedff700000016ef-ab-595292257858
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.46.05871.52292595; Tue, 27 Jun 2017 19:13:10 +0200 (CEST)
Received: from ESESSMB103.ericsson.se ([169.254.3.195]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 27 Jun 2017 19:13:09 +0200
From: Magnus Westerlund 
To: Donald Eastlake 
CC: "tsv-art@ietf.org" , "trill@ietf.org" ,  IETF Discussion , "draft-ietf-trill-over-ip.all@ietf.org" 
Thread-Topic: Tsvart early review of draft-ietf-trill-over-ip-10
Thread-Index: AQHS7hA1g07jSLuZY0i4jyhkqH3mRw==
Date: Tue, 27 Jun 2017 17:13:09 +0000
Message-ID: <52E4A8FC978E0241AE652516E24CAF0029AC2251@ESESSMB103.ericsson.se>
References: <149754795560.13109.17521244075940607817@ietfa.amsl.com> 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_52E4A8FC978E0241AE652516E24CAF0029AC2251ESESSMB103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2J7uK7apKBIg44mbouD2zUtPn+dxm7x bON8Fov3k7ezWczas4jFgdVj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MrovTiZteBcO3PF y/3VDYwPdjF1MXJySAiYSHTfOApkc3EICRxhlNh9sJ8dwlnCKNGwuJEVpIpNwELi5o9GNhBb REBN4vXyBSwgRcwChxgljqzoBOrg4BAWsJe4skwMosZBYuHadnYIW0+ipX8fG0gJi4CqxJGX ESBhXgFficW/30Et7maUmPxkLdhFjAKyEve/32MBsZkFxCVuPZkPdamAxJI955khbFGJl4// sYLMlBBQkpi2NQ2iPF/i/e5+Joj5ghInZz5hmcAoPAvJpFlIymYhKYOI60gs2P2JDcLWlli2 8DUzjH3mwGMmZPEFjOyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj6+CW36o7GC+/cTzE KMDBqMTDu6EtKFKINbGsuDIXGGYczEoivPm9QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8jvsu RAgJpCeWpGanphakFsFkmTg4pRoYU5fo+p9+8ivfbMqGOHvpqMYn/lprbhpNMlkg8nS7mOux NWdnWh9b4C/wZZfn1suLf9xrmRKXOt3oQsa/U94FtutFH2ct8jq3vZTp217vgLMXli8wzu5Y mh48j0mlvE5/Q2Yid1zypxP7jR5zbH1yWk9iq8VEL/aC9CN3unhYTp1x2LvPWfnfciWW4oxE Qy3mouJEAGT7B/mqAgAA
Archived-At: 
Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 17:13:17 -0000

--_000_52E4A8FC978E0241AE652516E24CAF0029AC2251ESESSMB103erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Donald,

After having read your response I think there is an important question abou=
t the applicability of this document that affects several of the issues bel=
ow and what solution you need. That is the question of what type of paths o=
ne expect to get Trill over IP working over. Because if the target is gener=
al Internet and also through middleboxes such as NATs and Firewall (Not int=
ending to block) then there are a lot more work to ensure this. If you for =
example changes the applicability to require any on path middleboxes to ful=
fill certain requirements things can be more easily addressed.


Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:

Hi Magnus,

Thanks for the extensive review. See my responses below.

On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
 wro=
te:



Diffserv usage
--------------

Section 4.3:

   TRILL over IP implementations MUST support setting the DSCP value in
   the outer IP Header of TRILL packets they send by mapping the TRILL
   priority and DEI to the DSCP. They MAY support, for a TRILL Data
   packet where the native frame payload is an IP packet, mapping the
   DSCP in this inner IP packet to the outer IP Header with the default
   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 discussion o=
f
the potential issues with actually setting the DSCP values. It is one thing=
 to
do this in an IP back bone use case where one can know and have control ove=
r
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 policers or
remapping. Also as the actual DSCP code point usage is domain specific this=
 is
difficult. Priority reversal is likely the least of the problems that this =
can
run into over general Internet.



It sounds like appropriate discussion and warnings about these issues
would resolve the above comment.

I would note that the choice of encapsulation here do becomes important. Yo=
ur's and Joe Touch's observation that for TCP, you can only have a single D=
SCP marking per TCP connection for example. For others, see the discussion =
in Section 5.1 of https://datatracker.ietf.org/doc/rfc7657/ on this issue.

David Black also raised an important question if one should treat this as a=
 tunnel with a single predictable behavior or let the inner networks markin=
g show through. Establishing a tunnel with a single PHB has less risk of ru=
nning into issues than multiple different markings.







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 networks this=
 can
also results in strange remapping that results in a different PHB for CS1 t=
han.



The intent in the draft is to reflect the default relative priority of
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...

David Black provide a good answer on this.






MTU and Fragmentation
---------------------

I think there are two main issue here. The first one is MTUD discovery
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 requries
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 were
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 to
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...

Yes, and over general Internet you should be happy if you get 1500 bytes of=
 IP MTU, it may easily be lower with a couple of additional tunnel headers.=
 Thus, what you say is the goal is not feasible without a solution that sup=
ports fragmentation and reassembly, enabling one TRILL packet to be sent in=
 multiple IP packets. The re-assembly do requires buffering and not somethi=
ng to easily perform on a router fast path. And attempting to use IP fragme=
ntation is likely doomed if you have any type of NAT or Firewall in the way=
.

This points to a dedicated solution or using a transport protocol that supp=
orts carrying arbitrary data sizes, like TCP or SCTP. And you need to use t=
he byte-stream API of TCP to achieve this.






Section 8.4:

   Path MTU discovery [RFC4821] should be useful
   in determining the IP MTU between a pair of RBridge ports with IP
   connectivity.

The issue with RFC4821 is that it has requirements on the packetization lay=
er.
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.

Okay, if you say so, it was not obvious from the spec that is was allowed t=
o probe for paths with lesser MTUs than 1470.






Thus, it appears that there is a lack of mechanism here to actually get a v=
alid
and functional MTU from TRILL in the cases where the Path MTU is below 1470=
. If
I am wrong good, but I think this is an important piece for how to handle t=
he
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.)

I looked at this, and it appears to have the same issue, that it can't prob=
e for MTU values below 1470.


   2) RB1 tries to send an MTU-probe padded to the size 1470.

      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.


But, the algorithm clearly performs a binary search for the MTU. If
one look at RFC 4821 one will notice that there are some additional conside=
rations
there how to make the probing better and robuster. But, cleary Trill has so=
me other
criterias for what is a success. Verification that Sz works appears suffici=
ent,
and there are no need to probe further upwards.








UDP encapsulation and IP fragments.


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


I see it as a big issue that UDP encapsulation is the native one, and that
relies on IP fragmentation despite the need for reliable fragmentation. Wit=
h
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 problem 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 to not ge=
t 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 have
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 are
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.

Yes, but this is the issue of applicability and documenting that applicabil=
ity. I don't know what goals and requirements that exist for Trill. If the =
WG are fine with some restrictions, then document them and focus on solving=
 the issues that must be solved.

You can clearly choose to require TCP for cases where the IP MTU is insuffi=
cient for carrying the Sz sized trill packets between the RBs using UDP.






Zero Checksum:
--------------

Section 5.4:

UDP Checksum - as specified in [RFC0768]

Considering the fast path encapsulation desire, I am surprised to not see a=
ny
mentioning of use of zero checksum here. Raising the zero checksum and forw=
ard
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 apply
   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 applicability statem=
ent
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 done.



OK. We'll look into it.



TCP Encapsulation issue
-----------------------

Section 5.6:

The TCP encapsulation appear to be missing an delimiter format allowing eac=
h
individual TRILL packet/payload to be read out of the TCP's byte stream. In
other words, a normal implementation has no way of ensuring that the TCP
payload starts with the start of a new TRILL payload. Multiple small TRILL
payloads may be included in the same TCP payload, and also only parts as TC=
P is
one way of dealing with TRILL packets that are larger than the IP+Encapsula=
tion
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 length fi=
eld
for the TRILL payload to be encapsulated.



Right. It might also be useful to include some sort of check field, as
is done in BGP, to detect if you are out of sync in parsing the TCP
stream.

As you need to actually perform re-assembly, the solution is to use the byt=
e stream semantics the TCP API provides and have a framing for each packet.




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 handling
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 not
be too hard.

Yes, agreed it is a possibility and points into possible considerations tha=
t David raised.






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 sizes in
relation to Bandwidth delay products, as buffer memory in a RBridge will im=
pact
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?

As Joe said, these are important considerations. If your intention is to en=
able this to run at substantial fractions of line rates of the interfaces. =
Then this do require considerations.






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, specific
   congestion control mechanisms are commonly needed.  However, if the
   traffic being carried by the TRILL over IP link is already congestion
   controlled and the size and volatility of the TRILL IS-IS link state
   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 way of kno=
wing
which traffic is actually congestion controlled, considering that TRILL pro=
vides
an layer 2 abstraction. I wonder if there should be any type of white list =
of
the types of layer 2 payloads that can be assumed to be congestion controll=
ed,
and thus okay to forward over IP paths? I am worried that without any
recommendation to prevent traffic that is not controlled to be forwarded, c=
an
lead to congestion issues.

The other issue I think may exist is the issue serial unicast emulation of
broadcast/multicast creates. As this amplifies the outgoing packet rate wit=
h
a factor of how many addresses are configured for serial unicast this can
be significant traffic expansion. Thus, I think additional considerations a=
re
needed here, and maybe rate limiting of the amount of traffic to be multica=
sted.



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 an
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 inner
layer 2 frames, and use the flow equivalents that exists on that level 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 ensure 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 lea=
d 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.

Okay, then this is very straightforward.






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 static bindin=
g
configurations or the need for determining ones external address(es) and be
able to communicate that to the peer RBridges, and in addition ensure 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.

Yes, and the question is how that can be handled, by the receiver of the pa=
cket, or if the sender needs to determine what address it uses and provide =
that in the HELLOs. If the first is possible that can simplify a lot.






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 fragmentati=
on,
as NATs don't do defragment and refragmented on the internal side, and an I=
P
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.


Yes, I think that are likely the simplest solution for you.





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). Note that t=
his
will restrict the MTU even further and thus ensure that the 1470 requiremen=
t
cannot be fulfilled even without additional tunnels over an 1500 bytes MTU
Ethernet infrastructure.

I would note that also firewalls likely have issues with IP fragments for t=
he
same reason, they require significant amount of state to be verified if the=
y
should be let through.

In general I think you should create a configuration that has chance to wor=
k
through most middleboxes, but I think you should require static bindings. 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 fragmenta=
tion
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.





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

--_000_52E4A8FC978E0241AE652516E24CAF0029AC2251ESESSMB103erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi Donald,



After having read your response I think there is an important question abou=
t the applicability of this document that affects several of the issues bel=
ow and what solution you need. That is the question of what type of paths o=
ne expect to get Trill over IP working
 over. Because if the target is general Internet and also through middlebox=
es such as NATs and Firewall (Not intending to block) then there are a lot =
more work to ensure this. If you for example changes the applicability to r=
equire any on path middleboxes to
 fulfill certain requirements things can be more easily addressed. 





Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:






Hi Magnus,=0A=
=0A=
Thanks for the extensive review. See my responses below.=0A=
=0A=
On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund=0A=
<magnus.westerlund@ericsson.com> wrote:=0A=







Diffserv usage=0A=
--------------=0A=
=0A=
Section 4.3:=0A=
=0A=
   TRILL over IP implementations MUST support setting the DSCP value in=0A=
   the outer IP Header of TRILL packets they send by mapping the TRILL=0A=
   priority and DEI to the DSCP. They MAY support, for a TRILL Data=0A=
   packet where the native frame payload is an IP packet, mapping the=0A=
   DSCP in this inner IP packet to the outer IP Header with the default=0A=
   for that mapping being to copy the DSCP without change.=0A=
=0A=
I think it is fine to require that implementations are capable  of setting=
=0A=
DSCP values on the outer IP header. However, I fail to see any discussion o=
f=0A=
the potential issues with actually setting the DSCP values. It is one thing=
 to=0A=
do this in an IP back bone use case where one can know and have control ove=
r=0A=
the PHB that the DSCP values maps to. But otherwise, over general internet =
the=0A=
behavior is not that predictable. One can easily be subject to policers or=
=0A=
remapping. Also as the actual DSCP code point usage is domain specific this=
 is=0A=
difficult. Priority reversal is likely the least of the problems that this =
can=0A=
run into over general Internet.=0A=





=0A=
It sounds like appropriate discussion and warnings about these issues=0A=
would resolve the above comment.





I would note that the choice of encapsulation here do becomes important. Yo=
ur's and Joe Touch's observation that for TCP, you can only have a single D=
SCP marking per TCP connection for example. For others, see the discussion =
in Section 5.1 of

https://datatracker.ietf.org/doc/rfc7657/ on this issue. 



David Black also raised an important question if one should treat this as a=
 tunnel with a single predictable behavior or let the inner networks markin=
g show through. Establishing a tunnel with a single PHB has less risk of ru=
nning into issues than multiple
 different markings. 








=0A=
=0A=





Section 4.3:=0A=
=0A=
   The default TRILL priority and DEI to DSCP mapping, which may be=0A=
   configured per TRILL over IP port, is an follows. Note that the DEI=0A=
   value does not affect the default mapping and, to provide a=0A=
   potentially lower priority service than the default priority 0,=0A=
   priority 1 is considered lower priority than 0. So the priority=0A=
   sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7.=0A=
=0A=
      TRILL Priority  DEI  DSCP Field (Binary/decimal)=0A=
      --------------  ---  -----------------------------=0A=
                  0   0/1  001000 / 8=0A=
                  1   0/1  000000 / 0=0A=
                  2   0/1  010000 / 16=0A=
                  3   0/1  011000 / 24=0A=
                  4   0/1  100000 / 32=0A=
                  5   0/1  101000 / 40=0A=
                  6   0/1  110000 / 48=0A=
                  7   0/1  111000 / 56=0A=
=0A=
This appear to be an problematic mapping. At least for prio 0 and 1. As=0A=
priority 1 appears to be intended to be higher than priority 0, it is=0A=
interesting that it is mapped to CS1, which to quote=0A=
https://datatracker.ietf.org/doc/rfc7657/:=0A=
=0A=
CS1 ('001000') was subsequently designated as the recommended=0A=
      codepoint for the Lower Effort (LE) PHB [RFC3662].=0A=
=0A=
So what is proposed can in a network using default mapping, result in that =
you=0A=
get priority 0 to be lower priority than 1. Plus that in some networks this=
 can=0A=
also results in strange remapping that results in a different PHB for CS1 t=
han.=0A=





=0A=
The intent in the draft is to reflect the default relative priority of=0A=
the different priority code points in IEEE Std 802.1Q where priority 1=0A=
is lower than priority 0. At a quick look, it appears to me that RFC=0A=
2474 requires that 0x001000 be handled as being of a priority not=0A=
lower than the priority with which 0x000000 is handled. Yet RFC 3662,=0A=
which you point to, seems to suggest using 0x001000 as a lower=0A=
priority code point than 0x000000. Given that 3662 not only does not=0A=
update 2474 but is only Informational while 2474 is Standards Track, I=0A=
would say that 2474 dominates and that this draft makes the best=0A=
assumptions it can about default behavior...





David Black provide a good answer on this. 






=0A=
=0A=





MTU and Fragmentation=0A=
---------------------=0A=
=0A=
I think there are two main issue here. The first one is MTUD discovery=0A=
of the actual IP path MTU between the ports. That will be needed to prevent=
=0A=
a lot of traffic going into MTU black holes. Especially as TRILL requries=
=0A=
1470 byte support which is likey above a lot of paths.=0A=





=0A=
Seems like it would depend on the environments where TRILL was used.=0A=
For example, I do not think 1470 would be a problem in most Data=0A=
Center or Internet Exchange point uses, for example. Data Centers=0A=
sometimes support 9K jumbo frames and the like.=0A=
=0A=
In fact, it is probably bad to focus too much on 1470 -- that is a=0A=
required minimum to be sure that reasonable size link state PDUs can=0A=
be successfully flooded through the TRILL campus so that routing will=0A=
work. However, it would commonly be the case that, for the TRILL=0A=
campus to be useful in a particular case, links need to be able to=0A=
carry the expected size TRILL Data packets. For example, if there were=0A=
two parts of a TRILL campus connected by one or a few TRILL over IP=0A=
links and the end stations in each part were assuming they could use=0A=
1500 byte Ethernet packets, then the TRILL over IP links would need to=0A=
support an MTU based on 1500 + TRILL Header + IP and TRILL over IP=
=0A=
encapsulation. And more if security was being used or there were any=0A=
other reasons for additional headers/encapsulation...





Yes, and over general Internet you should be happy if you get 1500 bytes of=
 IP MTU, it may easily be lower with a couple of additional tunnel headers.=
 Thus, what you say is the goal is not feasible without a solution that sup=
ports fragmentation and reassembly,
 enabling one TRILL packet to be sent in multiple IP packets. The re-assemb=
ly do requires buffering and not something to easily perform on a router fa=
st path. And attempting to use IP fragmentation is likely doomed if you hav=
e any type of NAT or Firewall in
 the way. 



This points to a dedicated solution or using a transport protocol that supp=
orts carrying arbitrary data sizes, like TCP or SCTP. And you need to use t=
he byte-stream API of TCP to achieve this.







=0A=
=0A=





Section 8.4:=0A=
=0A=
   Path MTU discovery [RFC4821] should be useful=0A=
   in determining the IP MTU between a pair of RBridge ports with IP=0A=
   connectivity.=0A=
=0A=
The issue with RFC4821 is that it has requirements on the packetization lay=
er.=0A=
Trill appears to have several components that are useful. However, it will=
=0A=
require a specification of the procedure to result in a useful tool.=0A=





=0A=
See below.=0A=
=0A=





Section 8.4:=0A=
=0A=
   TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in=0A=
   [RFC7177], can be used to obtain added assurance of the MTU of a=0A=
   link.=0A=
=0A=
Yes, that can confirm working MTUs that are at 1470 or above, but appears=
=0A=
prevented from working below 1470?=0A=





=0A=
While there is a minimum size for TRILL IS-IS MTU PDUs, determined by=0A=
header size, it is well below 1470, probably (depending on whether=0A=
secuirty is in use, etc.) below 150 bytes.





Okay, if you say so, it was not obvious from the spec that is was allowed t=
o probe for paths with lesser MTUs than 1470.







=0A=
=0A=





Thus, it appears that there is a lack of mechanism here to a=
ctually get a valid=0A=
and functional MTU from TRILL in the cases where the Path MTU is below 1470=
. If=0A=
I am wrong good, but I think this is an important piece for how to handle t=
he=0A=
next main issue.=0A=





=0A=
How about referencing Section 3 of=0A=
https://tools.ietf.org/html/draft-ietf-tri=
ll-mtu-negotiation-05=0A=
which is currently in IETF Last Call? (The wording of that section is=0A=
probably going to be improved based on an OPS review by Brian=0A=
Carpenter.)





I looked at this, and it appears to have the same issue, that it can't prob=
e for MTU values below 1470.





   2) RB1 tries to send an MTU-probe padded to the s=
ize 1470.=0A=
=0A=
      a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1=0A=
         sets the "failed minimum MTU test" flag for RB2 in RB1's=
 Hello=0A=
         and stop.=0A=
=0A=
=0A=
But, the algorithm clearly performs a binary search for the MTU. If =0A=
one look at RFC 4821 one will notice that there are some additional conside=
rations=0A=
there how to make the probing better and robuster. But, cleary Trill has so=
me other=0A=
criterias for what is a success. Verification that Sz works appears suffici=
ent, =0A=
and there are no need to probe further upwards. =0A=









=0A=
=0A=





UDP encapsulation and IP fragments.=0A=





  ----------------------------------=0A=





I see it as a big issue that UDP encapsulation is the native=
 one, and that=0A=
relies on IP fragmentation despite the need for reliable fragmentation. Wit=
h=0A=
the setup of having to support 1470 MTU on TRILL level some packets will be=
=0A=
fragmented in many environments. That will lead to a lot of losses, and as=
=0A=
discussed below a very big problem with middleboxes. The main problem here =
is=0A=
that if one tries to rely on IP fragments one will have issues with packets=
=0A=
ending up in black holes. And different problems depending on IPv4 or IPv6.=
=0A=
IPv6 is lilkely the lesser problem assuming that one have working PMTUD.=0A=
=0A=
There are several ways out of this.=0A=
=0A=
1. Detect issues and use TCP encapsulation with correctly set MSS to not ge=
t IP=0A=
fragements 2. Determine MTU and implement an fragmentation mechanism on top=
 of=0A=
UDP.=0A=





=0A=
So, I don't see that much problem with UDP being the general default=0A=
consistent with the TRILL philosophy of defaulting to need zero or=0A=
minimal configuration. The default should be to use multicast Hellos=0A=
for discovery of neighbors which sure points at UDP to me. Having to=0A=
traverse a NAT should be a rare case. Since, in the NAT case, you have=0A=
to configure things related to the static binding and the IP=0A=
address(es) of peer(s) anyway you can also configure to use a=0A=
different encapsulation than UDP, such as TCP, at the same time. I=0A=
don't see it as much of a problem if, by default, TRILL won't operate=0A=
through a NAT. If you are using UDP and it fragments and fragments are=0A=
dropped at a NAT, probably you can't exchange Hellos so you will not=0A=
form an adjacency and anything on the other side of the NAT will not=0A=
be visible.





Yes, but this is the issue of applicability and documenting that applicabil=
ity. I don't know what goals and requirements that exist for Trill. If the =
WG are fine with some restrictions, then document them and focus on solving=
 the issues that must be solved.




You can clearly choose to require TCP for cases where the IP MTU is insuffi=
cient for carrying the Sz sized trill packets between the RBs using UDP.







=0A=
=0A=





Zero Checksum:=0A=
--------------=0A=
=0A=
Section 5.4:=0A=
=0A=
UDP Checksum - as specified in [RFC0768]=0A=
=0A=
Considering the fast path encapsulation desire, I am surprised to not see a=
ny=0A=
mentioning of use of zero checksum here. Raising the zero checksum and forw=
ard=0A=
reference would be good I think.=0A=
=0A=
And then Section 8.5:=0A=
=0A=
   The requirements for the usage of the zero UDP Checksum in a UDP=0A=
   tunnel protocol are detailed in [RFC6936]. These requirements apply=0A=
   to the UDP based TRILL over IP encapsulations specified herein=0A=
   (native and VXLAN), which are applications of UDP tunnel.=0A=
=0A=
If you actually intended to allow zero checksum, then you actually should=
=0A=
document that Trill fulfills the requirements that the applicability statem=
ent=0A=
raises. I have not analyzed how well it meets these requirements.=0A=
=0A=
Please review Section 6.2 of RFC 8086 for example how that can be done.=0A=





=0A=
OK. We'll look into it.=0A=
=0A=





TCP Encapsulation issue=0A=
-----------------------=0A=
=0A=
Section 5.6:=0A=
=0A=
The TCP encapsulation appear to be missing an delimiter format allowing eac=
h=0A=
individual TRILL packet/payload to be read out of the TCP's byte stream. In=
=0A=
other words, a normal implementation has no way of ensuring that the TCP=0A=
payload starts with the start of a new TRILL payload. Multiple small TRILL=
=0A=
payloads may be included in the same TCP payload, and also only parts as TC=
P is=0A=
one way of dealing with TRILL packets that are larger than the IP+Encap=
sulation=0A=
MTU that actually will work.=0A=
=0A=
This comment is based on that there appear to be no length fields included =
in=0A=
the TRILL header. The most straight forward delimiter is a 2-byte length fi=
eld=0A=
for the TRILL payload to be encapsulated.=0A=





=0A=
Right. It might also be useful to include some sort of check field, as=0A=
is done in BGP, to detect if you are out of sync in parsing the TCP=0A=
stream.





As you need to actually perform re-assembly, the solution is to use the byt=
e stream semantics the TCP API provides and have a framing for each packet.







=0A=
=0A=
Another point is that, while with UDP it seems fine to send packets=0A=
with assorted QoS, you don't want to encourage re-ordering of TCP=0A=
packets in a stream. So if TCP encapsulation is being used, you want=0A=
to use the same DSCP value for the packets in a particular TCP stream.=0A=
So, generally, you need to have a TCP connection per priority handling=0A=
category. Mapping the 8 priority levels into a smaller number of=0A=
handling categories is a normal thing to do so you certainly don't=0A=
necessarily need 8 TCP connections. Adding material on this should not=0A=
be too hard.





Yes, agreed it is a possibility and points into possible considerations tha=
t David raised.







=0A=
=0A=





Section 5.6:=0A=
=0A=
TCP endpoint requirements. I do wonder if an application like TRILL actual=
=0A=
would need to discuss performance impacting implementation choices or=0A=
limitations. For example use of NAGLE, the requirements on buffer sizes in=
=0A=
relation to Bandwidth delay products, as buffer memory in a RBridge will im=
pact=0A=
performance.=0A=





=0A=
Well, I'm not sure how deeply this document should get into such=0A=
performance issues. What about just saying something about=0A=
consideration being given to tuning TCP for performance and pointing=0A=
to one or a few other RFCs that talk about this?





As Joe said, these are important considerations. If your intention is to en=
able this to run at substantial fractions of line rates of the interfaces. =
Then this do require considerations.







=0A=
=0A=





Congestion Control=0A=
------------------=0A=
First thanks for the effort here.=0A=





=0A=
You're welcome.=0A=
=0A=





8.1.2 In Other Environments=0A=
=0A=
   Where UDP based encapsulation headers are used in TRILL over IP in=0A=
   environments other than those discussed in Section 8.1.1, specific=0A=
   congestion control mechanisms are commonly needed.  However, if the=0A=
   traffic being carried by the TRILL over IP link is already congestion=0A=
   controlled and the size and volatility of the TRILL IS-IS link state=0A=
   database is limited, then specific congestion control may not be=0A=
   needed. See [RFC8085] Section 3.1.11 for further guidance.=0A=
=0A=
This is correct, however my question is if the RBridges have any way of kno=
wing=0A=
which traffic is actually congestion controlled, considering that TRILL pro=
vides=0A=
an layer 2 abstraction. I wonder if there should be any type of white list =
of=0A=
the types of layer 2 payloads that can be assumed to be congestion controll=
ed,=0A=
and thus okay to forward over IP paths? I am worried that without any=0A=
recommendation to prevent traffic that is not controlled to be forwarded, c=
an=0A=
lead to congestion issues.=0A=
=0A=
The other issue I think may exist is the issue serial unicast emulation of=
=0A=
broadcast/multicast creates. As this amplifies the outgoing packet rate wit=
h=0A=
a factor of how many addresses are configured for serial unicast this can=
=0A=
be significant traffic expansion. Thus, I think additional considerations a=
re=0A=
needed here, and maybe rate limiting of the amount of traffic to be multica=
sted.=0A=





=0A=
OK. We can think about those issues.=0A=
=0A=





Flow and ECMP=0A=
-------------=0A=
=0A=
Section 8.3:=0A=
=0A=
For example, for TRILL=0A=
   Data, this entropy field could be based on some hash of the=0A=
   Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL.=0A=
=0A=
I would appreciate clearer references to what these fields are.=0A=





=0A=
In a TRILL Data packet, the payload after the TRILL Header looks like=0A=
an Ethernet frame except that there is always either a VLAN tag or,=0A=
alternatively, where the VLAN tag would be, a Fine Grained Label=0A=
[RFC7172]. (The preceding is the view in the TRILL RFCs, but there is=0A=
an equivalent and equally valid view in which all the fields through=0A=
and including the VLAN or FGL tag are part of the TRILL Header.) The=0A=
TRILL base protocol specification focuses on Ethernet as a link=0A=
technology between TRILL switches, in which case there will be a link=0A=
header including an Outer.MacDA and Outer.MacSA fields and possibly an=0A=
Outer.VLAN, all before the TRILL Header. See Figure 1 and Figure 2 in=0A=
RFC 7172.=0A=
=0A=
Some of the above could be added to the draft for clarity.=0A=
=0A=





If I understand this correctly, the idea here is to look int=
o the inner=0A=
layer 2 frames, and use the flow equivalents that exists on that level and=
=0A=
hash that into value that maps the flows onto the source port range.=0A=





=0A=
Yes.=0A=
=0A=





I think this text should include a summary of the principle =
and ensure to=0A=
note the important requirement that what is considered flows in the inner=
=0A=
must not result in being striped over multiple source ports as this may lea=
d to=0A=
reordering issues due to packets taking different paths.=0A=





=0A=
Well, we can add some text. But when would the relative ordering=0A=
matter for two TRILL Data packets where the two inner native payloads=0A=
have different values for any one or more of these three fields=0A=
(Inner.MacDA, Inner.MacSA, and inner VLAN/FGL tag) ? If any of those=0A=
fields are different, you are talking about different streams.





Okay, then this is very straightforward. 






=0A=
=0A=





NAT and TRILL over IP:=0A=
Section 8.5:=0A=
=0A=
If one like to use TRILL over IP through a NAT, then there are some very=0A=
important considerations that are missing. First the need for static bindin=
g=0A=
configurations or the need for determining ones external address(es) and be=
=0A=
able to communicate that to the peer RBridges, and in addition ensure that =
one=0A=
has keep-alives to that the NAT binding never times out.=0A=





=0A=
I think those are good points. There is an additional problem that=0A=
TRILL Hellos detect neighbors with which they have 2-way connectivity=0A=
by indicating, inside the Hellos that are sent, from what neighbors=0A=
Hellos have been received on that port. If a NAT is involved, these=0A=
neighbor addresses inside Hellos need to be mapped.





Yes, and the question is how that can be handled, by the receiver of the pa=
cket, or if the sender needs to determine what address it uses and provide =
that in the HELLOs. If the first is possible that can simplify a lot.







=0A=
=0A=





Next is the issue that there is almost zero chance of gettin=
g a IP/UDP=0A=
encapsulation TRILL payload through the NAT if it results in IP fragmentati=
on,=0A=
as NATs don't do defragment and refragmented on the internal side, and an I=
P=0A=
fragment lacks UDP port and thus can't be matched to binding.=0A=





=0A=
So perhaps the recommendation should be to configure the port to use=0A=
TCP if there will be fragmentation.=0A=






Yes, I think that are likely the simplest solution for you. 






=0A=





Also if you like to run IP/ESP through a NAT, then you most =
likely need the=0A=
IP/UDP/ESP encapsulation (https://tools.ietf.org/html/rfc3948). No=
te that this=0A=
will restrict the MTU even further and thus ensure that the 1470 requiremen=
t=0A=
cannot be fulfilled even without additional tunnels over an 1500 bytes MTU=
=0A=
Ethernet infrastructure.=0A=
=0A=
I would note that also firewalls likely have issues with IP fragments for t=
he=0A=
same reason, they require significant amount of state to be verified if the=
y=0A=
should be let through.=0A=
=0A=
In general I think you should create a configuration that has chance to wor=
k=0A=
through most middleboxes, but I think you should require static bindings. I=
=0A=
think that configuration is, and don't laugh now, but IP/UDP/ESP/TCP/TRILL,=
=0A=
otherwise you will not be able to have both security and reliable fragmenta=
tion=0A=
of TRILL packets.=0A=





=0A=
OK. Thanks again for this review. It has pointed out a number of=0A=
problems and in thinking about those, I believe a couple of further=0A=
problems have come to mind that I mentioned above. We'll work on a=0A=
revised draft.=0A=
=0A=
=0A=





=0A=
Cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Media Technologies, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_52E4A8FC978E0241AE652516E24CAF0029AC2251ESESSMB103erics_--


From nobody Tue Jun 27 13:58:19 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3762E12EB22; Tue, 27 Jun 2017 13:58:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ggvuSVQKK7b4; Tue, 27 Jun 2017 13:58:01 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 7F07312706D; Tue, 27 Jun 2017 13:58:00 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id c73so22260690pfk.2; Tue, 27 Jun 2017 13:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8VmdHyhm89IzUbC3qV1TwYD8e6xl47fAo7vqc/TYvDA=; b=RppYG5iKVv78nrR3iGRwfNPkanWUQjnBbLl/GGPLfaw9WR6jG1+fb74WD1Lu6biod0 3obs9XvxuPNUUwZZ0Og4fcE0dA0L9F1ET61cH6SnD5QN+g7zs7zgMsgEWholz9Ildr3Y seXHxOyyyKj4b8A7vGGlZnxw++feMQL2ic+3BT5hbND/eDMvlCO0dItaOj/5XNRkkyND hpV6HBqHEMHy0W960c5SF6orn3KDbOOE2MY7+d2jQw+ruRBop6ZmpCiK79MAOyCk7UM0 z/QAarv/bKqKZCHGnK6sMTM1iUlWiMEvxoTrEZwsxUmam0sGCH8cNYAkosbjyJbH+dyP LYcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8VmdHyhm89IzUbC3qV1TwYD8e6xl47fAo7vqc/TYvDA=; b=ExrHcF7gu65L1th0+1dVJke6RWW4b26V78saQzeFONT5nyyVgk3LPzXUfSr+sJuG8X GZZy00+AiXRhOZaCSGNxvNn/8to/wHNskjkXuYcKEolg2mXcS+DtYd8mRQCoQ2L/PXmW 8QcJf+ONdvB5AUPl0bFbWQC3VYk5qnmrFeiK5RQf8rV/LxUd3nSvF+f8bucP2adN1QqB cnO8cLD4OWGu8c6Gyc5UQNVLIk3Vhfy5ftt7qlQIof3DSdUyae/XOkilV5ScrP7tE/Aj ktWo4PAnWrcxlbTM97HigEvcKeypMHsDvagKVtcRf+cBZ5bNoOlWSFzOIv4vbiFh9yCc XCdw==
X-Gm-Message-State: AKS2vOzxt2Ojm9T18lK5UQwAQufwVFTJZPjrHjj/v5MpjilhuNeDAnuu i9muFSG64Mufgpny
X-Received: by 10.99.117.11 with SMTP id q11mr7017450pgc.179.1498597079815; Tue, 27 Jun 2017 13:57:59 -0700 (PDT)
Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id x25sm315142pfi.58.2017.06.27.13.57.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 13:57:59 -0700 (PDT)
To: "Zhangmingui (Martin)" , Donald Eastlake 
Cc: "gen-art@ietf.org Review Team" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" 
References: <149826797586.7852.1637929087755767570@ietfa.amsl.com>  <4552F0907735844E9204A62BBDD325E7A653E64C@NKGEML515-MBX.china.huawei.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <793ddc9a-db6c-9c16-48c2-79f728af6484@gmail.com>
Date: Wed, 28 Jun 2017 08:58:01 +1200
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: <4552F0907735844E9204A62BBDD325E7A653E64C@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [trill] Genart last call review of draft-ietf-trill-mtu-negotiation-05
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jun 2017 20:58:04 -0000

Thanks, all those changes seem good to me. If I am asked to review
the next version for the IESG telechat, I expect to say "Ready".

Regards
   Brian

On 27/06/2017 20:06, Zhangmingui (Martin) wrote:
> Hi Brian and Donald,
> 
> Thanks a lot for the comments. Please see the responses as inline below.
> 
>> -----Original Message-----
>> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
>> Sent: Tuesday, June 27, 2017 11:03 AM
>> To: Brian Carpenter
>> Cc: gen-art@ietf.org Review Team; draft-ietf-trill-mtu-negotiation.all@ietf.org;
>> trill@ietf.org
>> Subject: Re: Genart last call review of draft-ietf-trill-mtu-negotiation-05
>>
>> Hi Brian,
>>
>> Thanks for the comments. See below.
>>
>> On Fri, Jun 23, 2017 at 9:32 PM, Brian Carpenter
>>  wrote:
>>> Reviewer: Brian Carpenter
>>> Review result: Ready with Issues
>>>
>>> Gen-ART Last Call review of draft-ietf-trill-mtu-negotiation-05
>>>
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed by
>>> the IESG for the IETF Chair.  Please treat these comments just like
>>> any other last call comments.
>>>
>>> For more information, please see the FAQ at
>>> .
>>>
>>> Document: draft-ietf-trill-mtu-negotiation-05.txt
>>> Reviewer: Brian Carpenter
>>> Review Date: 2017-06-24
>>> IETF LC End Date: 2017-06-28
>>> IESG Telechat date: 2017-07-06
>>>
>>> Summary: Ready with issues
>>> --------
>>>
>>> Minor issues:
>>> -------------
>>>
>>>> 2. Link-Wide TRILL MTU Size
>>> ...
>>>>   ...RBridges MUST support the Extended L1 Circuit-Scoped
>>>>   (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to
>>>>   exchange their maximally supportable value of "Lz".
>>>
>>> Where does that value come from? Is it configured, derived from the
>>> interface in some way, or discovered?
>>
>> It's somewhat similar to the originatingL1LSPBufferSize which is talked about in
>> Section 5 of RFC 7780, except that there is no reason to worry about
>> coordinating across the TRILL campus. How about adding wording something
>> like:
>>
>>       The originatingSNPBufferSize for a port is the minimum of the following
>> two quantities, but not less than 1470 bytes: (1) the maximum MTU of the port
>> and (2) the maximum LSP size that the TRILL IS-IS implementation can handle,
> 
> [Mingui] OK.
> 
>>
>>>> 2.1. Operations
>>>>
>>>>   Lz is reported using a originatingSNPBufferSize TLV that MUST occur
>>>>   in fragment zero of the RBridge's E-L1CS FS-LSP. An
>>>>   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>>>>   is ignored.
>>>
>>> Is that really what you mean? I thought Lz was an optional extra. So I
>>> think you mean:
>>>
>>> 2.1. Operations
>>>
>>>    Lz MAY be reported using a originatingSNPBufferSize TLV that occurs
>>>    in fragment zero of the RBridge's E-L1CS FS-LSP. An
>>>    originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>>>    MUST be ignored.
> 
> [Mingui] OK.
> 
>>
>> Yes, the "MUST" was just in reference to being in fragment zero, not that it has
>> to occur, so your wording seems better.
>>
>>>> 3. Link MTU Size Testing
>>> ...
>>>>   Step 0:
>>> ...
>>>>      b) Link MTU size is set to 1470, lowerBound is set to 1470,
>>>>         upperBound is set to the link-wide Lz, linkMtuSize is set to
>>>>         [(lowerBound + upperBound)/2] (Operation "[...]" returns the
>>>>         fraction-rounded-up integer.).
>>>
>>> This is confusing. "linkMtuSize" was defined as a local variable.
>>> But what is "Link MTU size"? Is that another local variable?
>>> If so, how is it different from "linkMtuSize"?
>>> It is used again in part 2) of step 2 below.
>>
>> I don't want to say anything about that before checking with the primary
>> author.
> 
> [Mingui] As specified in the text leading the Steps, "linkMtuSize" is a local integer variable for a specific RBridge while "link MTU size" is not a variable but a value that is agreed by two connected RBridges. To avoid the confusion, I changed "linkMtuSize" to "X" and add the text to explain that link MTU size is a value that is agreed by two connected RBridges.
> 
>>
>>> Also, I assume "Lz" is the value previously agreed among the nodes,
>>> but that should be made clear to the reader.
> 
> [Mingui] Agree. Added the word "agreed" in Section 2.
> 
>>>
>>> Nits:
>>> -----
>>>
>>>> 1. Introduction
>>> ...
>>>>   topology. While in this document, a new RECOMMENDED link-wide
>> minimum
>>>>   inter-RBridge MTU size, Lz, is specified. By calculating a using Lz
>>>>   as specified herein, link-scoped PDUs can be formatted greater than
>>>>   the campus-wide Sz up to the link-wide minimum acceptable inter-
>>>>   RBridge MTU size potentially improving the efficiency of link
>>>>   utilization and speeding link state convergence.
>>>
>>> I cannot parse those two sentences. What does the "While" refer to?
>>> What does "By calculating a using Lz" mean?
>>
>> I believe the sentences should be
>>
>> "... In this document, a new RECOMMENDED link-wide minimum inter-RBridge
>> MTU size, Lz, is specified. By calculating and using Lz as specified herein, ..."
> 
> [Mingui] OK.
> 
>>
>>>> 3. Link MTU Size Testing
>>> ...
>>>>      b) Link MTU size is set to 1470, lowerBound is set to 1470,
>>>>         upperBound is set to the link-wide Lz, linkMtuSize is set to
>>>>         [(lowerBound + upperBound)/2] (Operation "[...]" returns the
>>>>         fraction-rounded-up integer.).
>>>
>>> This would be easier to understand:
>>>
>>> 3. Link MTU Size Testing
>>> ...
>>>       b) Link MTU size is set to 1470, lowerBound is set to 1470,
>>>          upperBound is set to the link-wide Lz, linkMtuSize is set to
>>>          [(lowerBound + upperBound)/2], rounded up to the nearest
>> integer.
>>
>> OK.
>>
>>> Repeat this in the following two cases; a normal reader will not
>>> remember the rounding rule:
> 
> [Mingui] Changed three occurrences in the document.
> 
> 
>>>
>>> ...
>>>    1) If RB1 fails to receive an MTU-ack from RB2 after k tries:
>>>
>>>          upperBound is set to linkMtuSize and linkMtuSize is set to
>>>          [(lowerBound + upperBound)/2], rounded up to the nearest
>> integer.
>>>
>>>    2) If RB1 receives an MTU-ack to a probe of size linkMtuSize from
>>>       RB2:
>>>
>>>          link MTU size is set to linkMtuSize, lowerBound is set to
>>>          linkMtuSize and linkMtuSize is set to [(lowerBound +
>>>          upperBound)/2], rounded up to the nearest integer.
>>
>> That seems reasonable.
>>
>>> --
>>
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA  d3e3e3@gmail.com
> 
> 
> 
> Thanks,
> Mingui
> 


From nobody Wed Jun 28 00:46:33 2017
Return-Path: 
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9078F129649; Wed, 28 Jun 2017 00:46:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149863598454.18181.1549052359425113543@ietfa.amsl.com>
Date: Wed, 28 Jun 2017 00:46:24 -0700
Archived-At: 
Subject: [trill] I-D Action: draft-ietf-trill-mtu-negotiation-06.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 07:46:25 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF.

        Title           : Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation
        Authors         : Mingui Zhang
                          Xudong Zhang
                          Donald E. Eastlake
                          Radia Perlman
                          Somnath Chatterjee
	Filename        : draft-ietf-trill-mtu-negotiation-06.txt
	Pages           : 15
	Date            : 2017-06-28

Abstract:
   The base IETF TRILL protocol has a TRILL campus-wide MTU feature,
   specified in RFC 6325 and RFC 7177, that assures that link state
   changes can be successfully flooded throughout the campus while being
   able to take advantage of a campus-wide capability to support jumbo
   packets. This document specifies recommended updates to that MTU
   feature to take advantage, for appropriate link-local packets, of
   link-local MTUs that exceed the TRILL campus MTU. In addition, it
   specifies an efficient algorithm for local MTU testing. This document
   updates RFC 6325, updates RFC 7177, and updates RFC 7780.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-06
https://datatracker.ietf.org/doc/html/draft-ietf-trill-mtu-negotiation-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-mtu-negotiation-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Jun 28 00:48:52 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A0412EB69 for ; Wed, 28 Jun 2017 00:48:51 -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 M_oyg_n19sng for ; Wed, 28 Jun 2017 00:48:49 -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 C9C5B12EB4A for ; Wed, 28 Jun 2017 00:48:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPY74167; Wed, 28 Jun 2017 07:48:46 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 28 Jun 2017 08:48:38 +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; Wed, 28 Jun 2017 15:48:20 +0800
From: "Zhangmingui (Martin)" 
To: "trill@ietf.org" 
Thread-Topic: I-D Action: draft-ietf-trill-mtu-negotiation-06.txt
Thread-Index: AQHS7+K2W6JRAoyZzkK1LfnaTsPPWqI55biw
Date: Wed, 28 Jun 2017 07:48:20 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7A653F183@NKGEML515-MBX.china.huawei.com>
References: <149863598454.18181.1549052359425113543@ietfa.amsl.com>
In-Reply-To: <149863598454.18181.1549052359425113543@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.146.93]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59535F5F.0064, 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: 30117a411a95940e6c7c25c80155c32d
Archived-At: 
Subject: Re: [trill] I-D Action: draft-ietf-trill-mtu-negotiation-06.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 07:48:51 -0000

Hi,

This version addresses the comments we received during the IETF Last Call.

Thanks,
Mingui

> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Wednesday, June 28, 2017 3:46 PM
> To: i-d-announce@ietf.org
> Cc: trill@ietf.org
> Subject: I-D Action: draft-ietf-trill-mtu-negotiation-06.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Transparent Interconnection of Lots of L=
inks of
> the IETF.
>=20
>         Title           : Transparent Interconnection of Lots of Links
> (TRILL): MTU Negotiation
>         Authors         : Mingui Zhang
>                           Xudong Zhang
>                           Donald E. Eastlake
>                           Radia Perlman
>                           Somnath Chatterjee
> 	Filename        : draft-ietf-trill-mtu-negotiation-06.txt
> 	Pages           : 15
> 	Date            : 2017-06-28
>=20
> Abstract:
>    The base IETF TRILL protocol has a TRILL campus-wide MTU feature,
>    specified in RFC 6325 and RFC 7177, that assures that link state
>    changes can be successfully flooded throughout the campus while being
>    able to take advantage of a campus-wide capability to support jumbo
>    packets. This document specifies recommended updates to that MTU
>    feature to take advantage, for appropriate link-local packets, of
>    link-local MTUs that exceed the TRILL campus MTU. In addition, it
>    specifies an efficient algorithm for local MTU testing. This document
>    updates RFC 6325, updates RFC 7177, and updates RFC 7780.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-trill-mtu-negotiation-06
> https://datatracker.ietf.org/doc/html/draft-ietf-trill-mtu-negotiation-06
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-trill-mtu-negotiation-06
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From nobody Wed Jun 28 11:06:19 2017
Return-Path: 
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93946129AF3; Wed, 28 Jun 2017 11:06:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stewart Bryant 
To: 
Cc: draft-ietf-trill-rbridge-multilevel.all@ietf.org, ietf@ietf.org, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149867317753.7558.8752757743866337364@ietfa.amsl.com>
Date: Wed, 28 Jun 2017 11:06:17 -0700
Archived-At: 
Subject: [trill] Genart last call review of draft-ietf-trill-rbridge-multilevel-06
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 18:06:17 -0000

Reviewer: Stewart Bryant
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-trill-rbridge-multilevel-??
Reviewer: Stewart Bryant
Review Date: 2017-06-28
IETF LC End Date: 2017-06-28
IESG Telechat date: 2017-07-06

Summary:

This is a well written document. I do however have a concern with the scaling
text in section 1.2.x, as I think this could be more accessible and ought to
include discussion of MAC Address scaling. More information below.

Major issues: None

Minor issues: The key justification for multi-area is scaling. The scene is set
in Section 1.2.x. However there are no references, the design size parameters
are not articulated for each case, and the equations are not derived. I think
that it would be helpful if the draft either provided some more explanation of
the scaling equations and the associated input assumptions, or provided the
assumptions and  directed the reader to an accessible text to understand the
equations. Although there is some discussion on it later there is no discussion
of the number of addresses to be learned in the single and multi-area cases and
the impact this has on the LSDB. The number of addresses to be learned will
impact the ingress RBridge FIB and the FIB update time so this is just as
significant in understanding the benefit of multi-level as understanding the
link-state convergence time is.

Nits/editorial comments: None



From nobody Wed Jun 28 13:19:23 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9212EB00; Wed, 28 Jun 2017 13:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSMSNhDNlL2Q; Wed, 28 Jun 2017 13:19:07 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E8C12EB05; Wed, 28 Jun 2017 13:19:05 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id v202so35569875itb.0; Wed, 28 Jun 2017 13:19:05 -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=xAUGIIhww8QT0s6y90rqIPdu3xXAMovnCzTIixHqShU=; b=WqpyuUXOeGDkXoY6II/66v6y+m+G/j1rNPxWN6BLH4VLErWPy3WYiD9UCnv/ldWjrl SR4TysPO6O74N6u6gEreIqM3r+eEWans51sCl7N9HQSdBnXwMXPl5Ka3IA4IyJKVlEKO TAf0L0AYzj12aMZnqmDylEy9EsuWdVvQpo5Lcuks1zUO2YE6QbRJr1nXkGNlsOLijI/I Om+2G0/D4tkWqfN69FlQil5WnQ3i2trRlBfZZYMdtEVEMe69zh17Gcgqu2aWq8CXnEcC cGpGKvRjPejjy2Eu0UHtDwwjFuEm4kuuMJDiCUmGhdMGH/6iouM8/panVLcVYqNqsw7c azvQ==
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=xAUGIIhww8QT0s6y90rqIPdu3xXAMovnCzTIixHqShU=; b=gFTerYevfzo8Xc1gz0ehQ9Wz/xT1dKvRecnI18B5/oeacfwQuvYyCOiBPVv2FDhFkm FhXlrDw4dmPuw2dYOOdqoJlK7G564fC3G6X7EFOhgHDEFP7V5qrelybnzdwvkIkdHQ4A vVlf6yqTPlkbTm0nSO1eb+bmzE8eW5mJYQvnBYBG6x4kxHWjhqYV5ij/1P0yUnZfYv2J 3GGpTy/Zw9C8No9Tj/jCOmbsQu34Y5aoJjFPcR0T3vCxje2t5euP4/9BifXm89vOQjQY iuOctLye8mWw9sqBfvUoyHe8bXZB0KIxQbChViL6VvOOVeY0aOMm/ZkmyOb/MYz9rPA3 GcwQ==
X-Gm-Message-State: AKS2vOyyIpakUjOMR1DWykScecMPhLcN0HSsJhUyqYpFXpLR4xpaLGKV LEwZFTINuTwUAG0WU8z1PNkhm8sv+g==
X-Received: by 10.36.3.11 with SMTP id e11mr8808369ite.79.1498681144981; Wed, 28 Jun 2017 13:19:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Wed, 28 Jun 2017 13:18:49 -0700 (PDT)
In-Reply-To: <149867317753.7558.8752757743866337364@ietfa.amsl.com>
References: <149867317753.7558.8752757743866337364@ietfa.amsl.com>
From: Donald Eastlake 
Date: Wed, 28 Jun 2017 16:18:49 -0400
Message-ID: 
To: Stewart Bryant 
Cc: "gen-art@ietf.org Review Team" , draft-ietf-trill-rbridge-multilevel.all@ietf.org,  IETF Discussion , "trill@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [trill] Genart last call review of draft-ietf-trill-rbridge-multilevel-06
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Jun 2017 20:19:10 -0000

Hi Stewart,

Thanks for the comments. See below.

On Wed, Jun 28, 2017 at 2:06 PM, Stewart Bryant
 wrote:
> Reviewer: Stewart Bryant
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-trill-rbridge-multilevel-??
> Reviewer: Stewart Bryant
> Review Date: 2017-06-28
> IETF LC End Date: 2017-06-28
> IESG Telechat date: 2017-07-06
>
> Summary:
>
> This is a well written document. I do however have a concern with the scaling
> text in section 1.2.x, as I think this could be more accessible and ought to
> include discussion of MAC Address scaling. More information below.
>
> Major issues: None
>
> Minor issues: The key justification for multi-area is scaling. The scene is set
> in Section 1.2.x. However there are no references, the design size parameters
> are not articulated for each case, and the equations are not derived. I think
> that it would be helpful if the draft either provided some more explanation of
> the scaling equations and the associated input assumptions, or provided the
> assumptions and  directed the reader to an accessible text to understand the
> equations.

A reference and some further exposition of the assumptions made with
the way the equations were arrived at could be added.

>                     Although there is some discussion on it later there is no discussion
> of the number of addresses to be learned in the single and multi-area cases and
> the impact this has on the LSDB. The number of addresses to be learned will
> impact the ingress RBridge FIB and the FIB update time so this is just as
> significant in understanding the benefit of multi-level as understanding the
> link-state convergence time is.

The number of MAC (actually MAC/VLAN or MAC/FGL) addresses to be
learned by an edge TRILL switch is not affected by whether the TRILL
campus uses single or multilevel IS-IS. This number of MAC address
learned is the seventh scaling problem listed in Section 1.1 which
states that multilevel TRILL IS-IS helps only with the other six
problems. This point, that multilevel doesn't help here, could be
emphasized more but I don't think I see much point in this document in
going into details such as the scaling considerations of data plane
MAC address learning (which is the default in TRILL) or control plan
MAC address learning (which does not use the core LSDB but rather Data
Label scoped ESADI link stat databases).

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> Nits/editorial comments: None
>
>


From nobody Wed Jun 28 19:35:30 2017
Return-Path: 
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C4B1270A3; Wed, 28 Jun 2017 19:35:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dale Worley 
To: 
Cc: draft-ietf-trill-arp-optimization.all@ietf.org, ietf@ietf.org, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149870371689.6498.12830215563460223064@ietfa.amsl.com>
Date: Wed, 28 Jun 2017 19:35:16 -0700
Archived-At: 
Subject: [trill] Genart last call review of draft-ietf-trill-arp-optimization-08
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jun 2017 02:35:17 -0000

Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

Document:  draft-ietf-trill-arp-optimization-08
Reviewer:  Dale R. Worley
Review Date:  2017-06-28
IETF LC End Date:  2017-06-29
IESG Telechat date:  unknown

Summary:

       This draft is basically ready for publication, but has nits
       that should be fixed before publication.

   Abstract

   This document describes mechanisms to optimize the ARP (Address
   Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
   campus.

s/in TRILL campus/in a TRILL campus/

Perhaps summarize what the optimizations are:

   Each edge RBridge maintains a cache of IP/MAC address/Data Label
   bindings that are learned from ARP/ND requests and responses that
   pass through it.  This cache allows it to avoid flooding an ARP/ND
   request by either responding to it directly or by encapsulating it
   and unicasting it to the location where it is in use.

   2 ARP/ND Optimization Requirement and Solution

   (including DHCP or gratuitous ARP_messages).

s/_//

   and should allow an end station to
   detect duplicate IP addresses.

Unless this is a well-known phrase, it would be best if it was clear
whether the end station is detecting that its own IP address is
duplicated, or whether it is detecting that some other station's IP
address is duplicated.

   TRILL already provides an option to disable data-plane learning from
   the source MAC address of end-station frames on a per port basis (see
   Section 5.3 of [RFC6325]).

Given how this section is written, shouldn't this option be considered
an option to *enable* data-plane learning?  And in particular, doesn't
that imply that TRILL already includes a solution to suppress ARP
flooding?

Also, what is the meaning of "learning from the source MAC address"?
It seems like you'd want to specify what the learning is *of*, and
then perhaps what it is learned *from*.

Or is this particular learning of MAC addresses alone, and not of
IP/MAC bindings?  If so, then isn't this feature orthogonal to ARP/ND
optimization?

As a design matter, I'm curious why an RBridge can't learn IP/MAC
bindings by snooping data packets, and only by snooping ARP packets.
I suspect there are good reasons for it, but the naive reader (me) is
left wondering...

   4.1 SEND Considerations

   Secure SEND messages require knowledge of cryptographic keys. Methods
   of communicating such keys to RBridges for use in SEND are beyond the
   scope of this document. Thus, using the optimizations in this
   document, RBridges do not attempt to construct SEND messages and are
   generally transparent to them. RBridges only construct ARP, RARP, or
   insecure ND messages, as appropriate.

This doesn't flow quite correctly.  The second sentence suggests that
there are known mechanisms for distributing keys to RBridges, but that
this document doesn't describe them.  The reader then expects that the
third sentence will say that if RBridges are provisioned with keys in
an environment, they can generate SEND responses.  But instead, the
real meaning of the second sentence seems to be that there are no such
ways of distributing keys to RBridges and therefore they can't
generate SEND responses.  That suggests that the second sentence
should be rephrased:

    There are no methods of communicating such keys to RBridges for
    use in SEND, and thus RBridges cannot construct SEND messages and
    must be generally transparent to them.

Or perhaps "SEND forbids communicating such keys to RBridges, and
thus...".

   4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP 

What is "non-zero IP"?  Is this the case discussed in section 4.4 item
(d)?  (If so, it also includes "a Neighbor Solicitation for DAD
... which has the unspecified source address".)  Perhaps the property
being described is "Get Sender's IP/MAC Mapping Information from
Non-Address Probe ARP/ND Queries".

   4.4 Determine How to Reply to ARP/ND

   It is not essential that all RBridges use the same strategy for which
   option to select for a particular ARP/ND query. It is up to the
   implementation.

It appears that the division between options (a), (b), (c), and (d)
are fixed by the draft, so this statement is rather confusing.  Also,
"It is up to the implementation." is a bit awkward.  Perhaps:

   Within each item, it is an implementation decision which strategies
   to use for any particular ARP/ND query falling under that item.

--

     Because the edge RBridge might not have an IPv6 address, the
     source IP address for such an ND response MUST be that of the
     target end station.

Wouldn't the source IP address for such an ARP response also be that
of the target end station, given that it is a simulated ARP response
from the target end station?  That is, why is this MUST specific to
IPv6?

     b.3. Drop the message if the directory mechanism is used and you
     know there should be no response (query based on an non-existent IP
     address for example).

It would be better to phrase this:

     b.3. Drop the message if the directory server gives authoritative
     information that the IP address is non-existent.

   4.5 Determine How to Handle the ARP/ND Response

   the target's egress RBridge R2 as discussed in subsection 3.2 item a)

Really, it's subsection 3.2 item a.2.

   or to flood the request as per [RFC6325]

Isn't this item a.5?

   When/if the target responds, 

Probably better as "If and when the target responds,".

   5 Handling RARP (Reverse Address Resolution Protocol) Messages

The title of section 5 starts "Handling" whereas the titles of
sections 6 and 7 start "Handling of".  It's probably worth making the
three consistent.

   Its use is similar to

Shouldn't this be "Its processing is similar to"

   Normally, it is used to
   look up a MAC address to find the corresponding IP address.

Doesn't this duplicate the third sentence of this paragraph?

   7 Handling of Duplicate IP Addresses

   Duplicate IP addresses can be detected when an existing active
   IP1/MAC1 mapping gets modified.

Should "IP1/MAC1" be "IP/MAC"?  Neither "IP1" nor "MAC1" is used
elsewhere in the document.

   Also an edge RBridge may send a query
   to the former owner of IP called a DAD-query (Duplicate Address
   Detection query).

This is a bit ambiguous -- is it the query or the former owner that is
called a DAD-query?  Better "may send a query called a DAD-query (...)
to the former owner of the IP".

However the following discussion does not specify how the DAD-query is
addressed to the "former owner", and so doesn't specify if the former
owner is defined by the MAC address previously associated with the IP
address or what.  The protocol logic seems to require that the
destination MAC is the one previously associated with the IP address
and the queried-for IP must be the IP in question.  This should be
spelled out, since the source addressing is specified.

   In the case where the former owner replies, a Duplicate Address has
   been detected. In this case the querying RBridge SHOULD log the
   duplicate so that the network administrator can take appropriate
   action.

What action should the querying RBridge take in regard to its cache?

   9 Security Considerations

s/as provide in/as provided in/ (two instances)

   12.1 Normative References

   [DirMech] Dunbar, L., Eastlake 3rd, D., Perlman, R., I. Gashinsky.
              and Li Y., TRILL: Edge Directory Assist Mechanisms",
              draft-ietf-trill-directory-assist-mechanisms, work in
              progress.

There are unbalanced double-quotes here.



From nobody Thu Jun 29 01:50:43 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F75012ECBA; Thu, 29 Jun 2017 01:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 PMMTSUfUni2B; Thu, 29 Jun 2017 01:50:39 -0700 (PDT)
Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 780CC12ECB7; Thu, 29 Jun 2017 01:50:39 -0700 (PDT)
Received: by mail-wr0-x242.google.com with SMTP id z45so36295626wrb.2; Thu, 29 Jun 2017 01:50:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language; bh=ESk3ySkqEj005jJJy4hBXIOzjgz3B+cnr4Kr5kBvBxo=; b=VSqgzYVcV+A8jnqfwYmYlLFak2zJxkne+xecxZs7SZ3BYX5J41+UBEI3NWba9Pu4A5 IwdgnNYJuZ6OS2Ns1XxYWHhWJMF+MGJVlUo4kedrANKQnMnZ9LLByUtmWfD2ff2pehQT KUyi3UeVNDtL3TA4n3jaU2grG60RB9nuaWWNNXIzYILvLOVAD01xDxH5TTyqKbZVrc9a Xox6xNcy1AFr9RmyIQgQGtIxDTqLyn4UqF7QXqmXNW3yqbd8FPkk1JySxDXUhFLEZ9O3 o/H1Sk7UBQa/XGdqdH4yBZI93u6v3zDL0/bOB0N4iLsOD1kddpQHEAr1BFpV8Lbzvdfc hs1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language; bh=ESk3ySkqEj005jJJy4hBXIOzjgz3B+cnr4Kr5kBvBxo=; b=BeAlE10RtqrA2qTfBxIarx0o8dMnIbmsb7xakbBXdh7yqj77TMzdvWS3N1BLymmfc3 bb8apOJrqWx48TGKk0WofbIH3bzbDvfxycfItq8pBtYm21NTjolQa18kZMhHO+jXN3da h2z6kpDdUKS30gaMtuftn6AuUYjjjxL5wUEykCHDfjw26PCwNHOJYp1OY65zormtpma1 THkglpU9/y10CtE81bXGTuM5CqHtfX+bd/VBoQUOgJuvKw6nmuBFYzciOBz0/jT3cBdc giXPOFmnNkWL7DpD7saVtmh8fgKoxrIzPMd4UAVsGbvd2+LTT1i8OblvgLSKs0Qhmc2b /xEw==
X-Gm-Message-State: AKS2vOzmra33DUCs/5C2Vs7Bq2Lv45CplZqpoAVBJbvuIN0+7k03bHHu CXaPPpRN46w7DjKQ0n0=
X-Received: by 10.223.139.87 with SMTP id v23mr21380889wra.145.1498726237689;  Thu, 29 Jun 2017 01:50:37 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id i65sm710382wmf.20.2017.06.29.01.50.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 01:50:37 -0700 (PDT)
To: d3e3e3@gmail.com
Cc: General Area Review Team , draft-ietf-trill-rbridge-multilevel.all@ietf.org, IETF Discussion , trill@ietf.org
From: Stewart Bryant 
Message-ID: <58bdb2db-3833-feaa-ced0-eeee68ca5581@gmail.com>
Date: Thu, 29 Jun 2017 09:50:34 +0100
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: multipart/alternative; boundary="------------BF40CDDA72214BF8EEC99F56"
Content-Language: en-GB
Archived-At: 
Subject: Re: [trill] Genart last call review of draft-ietf-trill-rbridge-multilevel-06
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Jun 2017 08:50:41 -0000

This is a multi-part message in MIME format.
--------------BF40CDDA72214BF8EEC99F56
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

>                     Although there is some discussion on it later there is no discussion
> of the number of addresses to be learned in the single and multi-area cases and
> the impact this has on the LSDB. The number of addresses to be learned will
> impact the ingress RBridge FIB and the FIB update time so this is just as
> significant in understanding the benefit of multi-level as understanding the
> link-state convergence time is.

The number of MAC (actually MAC/VLAN or MAC/FGL) addresses to be
learned by an edge TRILL switch is not affected by whether the TRILL
campus uses single or multilevel IS-IS. This number of MAC address
learned is the seventh scaling problem listed in Section 1.1 which
states that multilevel TRILL IS-IS helps only with the other six
problems. This point, that multilevel doesn't help here, could be
emphasized more but I don't think I see much point in this document in
going into details such as the scaling considerations of data plane
MAC address learning (which is the default in TRILL) or control plan
MAC address learning (which does not use the core LSDB but rather Data
Label scoped ESADI link stat databases).

SB> I think the important point is either to demonstrate that the
SB> that the control plane problem you address is the dominant factor in convergence
SB> and that the MAC component (including FIB update) is not significant,
SB> or to point to a solution that makes the data plane element comparable
SB> to the improved control plane. Otherwise there is surely no point in
SB> making these significant changes to the control plane.

- Stewart



--------------BF40CDDA72214BF8EEC99F56
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
>                     Although there is some discussion on it later there is no discussion
> of the number of addresses to be learned in the single and multi-area cases and
> the impact this has on the LSDB. The number of addresses to be learned will
> impact the ingress RBridge FIB and the FIB update time so this is just as
> significant in understanding the benefit of multi-level as understanding the
> link-state convergence time is.

The number of MAC (actually MAC/VLAN or MAC/FGL) addresses to be
learned by an edge TRILL switch is not affected by whether the TRILL
campus uses single or multilevel IS-IS. This number of MAC address
learned is the seventh scaling problem listed in Section 1.1 which
states that multilevel TRILL IS-IS helps only with the other six
problems. This point, that multilevel doesn't help here, could be
emphasized more but I don't think I see much point in this document in
going into details such as the scaling considerations of data plane
MAC address learning (which is the default in TRILL) or control plan
MAC address learning (which does not use the core LSDB but rather Data
Label scoped ESADI link stat databases).

SB> I think the important point is either to demonstrate that the
SB> that the control plane problem you address is the dominant factor in convergence
SB> and that the MAC component (including FIB update) is not significant,
SB> or to point to a solution that makes the data plane element comparable
SB> to the improved control plane. Otherwise there is surely no point in 
SB> making these significant changes to the control plane.

- Stewart




  


--------------BF40CDDA72214BF8EEC99F56--


From nobody Thu Jun 29 19:17:34 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9686C129B74; Thu, 29 Jun 2017 19:17:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6RkVZ3UiUKa; Thu, 29 Jun 2017 19:17:28 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 192E4129A9C; Thu, 29 Jun 2017 19:17:28 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id h64so17142728iod.0; Thu, 29 Jun 2017 19:17: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 :cc; bh=9HzTNkMcvS4yzHxXwMLFDr5N1hX/InMnh6UtABvknZQ=; b=cU9RcUu81fqYMMvQm2x3a351VexCv6V57sGeWcEoRYJBaOkVcNQkJ4/vzCtswoSpAm KnsLeunRxq35kOVy94kCTSxU8vCdGlhzr1LR03jh9SNVZUmvxHp/IPoBNp1sxIG7S2zJ dIqv+c9yivSThgBpsmlwuCu99U6ZwychrTq8uHVies20ZqQU6LvALSoQmgUkeX/c0ESp 9n/nNsJ/CLrsOKfbP/uUkPNFsAQ4wLx+LiANlP8HDpMfSMj3p4I886WWm052DIjUNm32 ndyl3K+hV4N08cDo+z46mC31xHdgd4szz7mEI397TeHo7gsxGu+b30nGcF2jRvRBcHA2 aYgg==
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=9HzTNkMcvS4yzHxXwMLFDr5N1hX/InMnh6UtABvknZQ=; b=YH3tOH0M7TYV6QYYuCKlIhOaRIFjFVoYbhSTU3eB5HphECY9VRCJoDUWVvFRDJlu25 nOLgROR81AELoyXAwTnG0mmAk/XHF2sr+JhidtVmQtC6gHmutId+FUk0l+PEljUTFDrd Pk0N/w7NOxADwbvCZV/PkvYz1IKB7nY0QS7+0/EmoNP+uItjyOQfAhThXAao/bJQLInP kxAscNA3jHDY5tiAUuOid6+i0HYvsMVVXTmbbd9yz+JJhpgvbN3NLtbR120qvsA4TvJ2 /qMKw7BFM77lFimQkKf6cy+PnpjNulRdDo/M2Zwqkqngg1dFhGgyJHIhmJ2kyC+/a6+S fsfA==
X-Gm-Message-State: AKS2vOzXjnKvZYeCUqn1jE1EHkMjQClbddNVhIqncF0v0b3a0rhw1F64 v07e1vpZARpuNqJ5AR2WKM2FgVIKiQ==
X-Received: by 10.107.156.83 with SMTP id f80mr20165783ioe.9.1498789047319; Thu, 29 Jun 2017 19:17:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Thu, 29 Jun 2017 19:17:11 -0700 (PDT)
In-Reply-To: <52E4A8FC978E0241AE652516E24CAF0029AC2251@ESESSMB103.ericsson.se>
References: <149754795560.13109.17521244075940607817@ietfa.amsl.com>  <52E4A8FC978E0241AE652516E24CAF0029AC2251@ESESSMB103.ericsson.se>
From: Donald Eastlake 
Date: Thu, 29 Jun 2017 22:17:11 -0400
Message-ID: 
To: Magnus Westerlund 
Cc: "tsv-art@ietf.org" , "trill@ietf.org" ,  IETF Discussion , "draft-ietf-trill-over-ip.all@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1141bcbec246930553240434"
Archived-At: 
Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 02:17:32 -0000

--001a1141bcbec246930553240434
Content-Type: text/plain; charset="UTF-8"

HI Magnus,

On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Hi Donald,
>
> After having read your response I think there is an important question
> about the applicability of this document that affects several of the issues
> below and what solution you need. That is the question of what type of
> paths one expect to get Trill over IP working over. Because if the target
> is general Internet and also through middleboxes such as NATs and Firewall
> (Not intending to block) then there are a lot more work to ensure this. If
> you for example changes the applicability to require any on path
> middleboxes to fulfill certain requirements things can be more easily
> addressed.
>

The use cases in the document support communication over the general
Internet in the brach office case but that does not necessarily imply
NATs/Firewalls.

Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:
>
> Hi Magnus,
>
> Thanks for the extensive review. See my responses below.
>
> On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund  wrote:
>
>
> Diffserv usage
> --------------
>
> Section 4.3:
>
>    TRILL over IP implementations MUST support setting the DSCP value in
>    the outer IP Header of TRILL packets they send by mapping the TRILL
>    priority and DEI to the DSCP. They MAY support, for a TRILL Data
>    packet where the native frame payload is an IP packet, mapping the
>    DSCP in this inner IP packet to the outer IP Header with the default
>    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 discussion of
> the potential issues with actually setting the DSCP values. It is one thing to
> do this in an IP back bone use case where one can know and have control 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 policers or
> remapping. Also as the actual DSCP code point usage is domain specific this is
> difficult. Priority reversal is likely the least of the problems that this can
> run into over general Internet.
>
> It sounds like appropriate discussion and warnings about these issues
> would resolve the above comment.
>
> I would note that the choice of encapsulation here do becomes important.
> Your's and Joe Touch's observation that for TCP, you can only have a single
> DSCP marking per TCP connection for example. For others, see the discussion
> in Section 5.1 of https://datatracker.ietf.org/doc/rfc7657/ on this
> issue.
>

Well, if a TRILL over IP implementation using TCP transport wants to have
more than one priority category for traffic where there might be one or
more intervening IP routers, which would be the normal case, it would just
need a TCP connection per priority category. Mapping the 8 priority levels
into a smaller number of categories is a routine thing to do. Note that the
base TRILL protocol specification (RFC 6325) says:

   RBridges are not required to implement any
   particular number of distinct priority levels but may treat one or

   more adjacent priority levels in the same fashion.


> David Black also raised an important question if one should treat this as
> a tunnel with a single predictable behavior or let the inner networks
> marking show through. Establishing a tunnel with a single PHB has less risk
> of running into issues than multiple different markings.
>

It is an implementation choice whether to have a single PHB or eight, one
per priority level, or something in between.

> 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 quotehttps://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 networks this can
> also results in strange remapping that results in a different PHB for CS1 than.
>
> The intent in the draft is to reflect the default relative priority of
> 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...
>
>
> David Black provide a good answer on this.
>

I'll reply to him.

> MTU and Fragmentation
> ---------------------
>
> I think there are two main issue here. The first one is MTUD discovery
> 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 requries
> 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 were
> 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 to
> 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...
>
>
> Yes, and over general Internet you should be happy if you get 1500 bytes
> of IP MTU, it may easily be lower with a couple of additional tunnel
> headers. Thus, what you say is the goal is not feasible without a solution
> that supports fragmentation and reassembly, enabling one TRILL packet to be
> sent in multiple IP packets. The re-assembly do requires buffering and not
> something to easily perform on a router fast path. And attempting to use IP
> fragmentation is likely doomed if you have any type of NAT or Firewall in
> the way.
>
> This points to a dedicated solution or using a transport protocol that
> supports carrying arbitrary data sizes, like TCP or SCTP. And you need to
> use the byte-stream API of TCP to achieve this.
>

OK.

> Section 8.4:
>
>    Path MTU discovery [RFC4821] should be useful
>    in determining the IP MTU between a pair of RBridge ports with IP
>    connectivity.
>
> The issue with RFC4821 is that it has requirements on the packetization 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.
>
>
> Okay, if you say so, it was not obvious from the spec that is was allowed
> to probe for paths with lesser MTUs than 1470.
>
> 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 below 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 ofhttps://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.)
>
> I looked at this, and it appears to have the same issue, that it can't
> probe for MTU values below 1470.
>

I think the thing was that, before TRILL over IP, it would not have been
useful to determine an MTU below 1470. But there is no particular problem
in constructing a smaller MTU-probe PDUs and an RBridge receiving such a
PDU is generally required to respond with an equal length MTU-ack.

>    2) RB1 tries to send an MTU-probe padded to the size 1470.
>
>       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.
>
>
> But, the algorithm clearly performs a binary search for the MTU. If
> one look at RFC 4821 one will notice that there are some additional considerations
> there how to make the probing better and robuster. But, cleary Trill has some other
> criterias for what is a success. Verification that Sz works appears sufficient,
> and there are no need to probe further upwards.
>
> UDP encapsulation and IP fragments.
>
>   ----------------------------------
>
> I see it as a big issue that UDP encapsulation is the native one, and that
> relies on IP fragmentation despite the need for reliable fragmentation. 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 problem 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 to 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 have
> 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 are
> 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.
>
>
> Yes, but this is the issue of applicability and documenting that
> applicability. I don't know what goals and requirements that exist for
> Trill. If the WG are fine with some restrictions, then document them and
> focus on solving the issues that must be solved.
>
> You can clearly choose to require TCP for cases where the IP MTU is
> insufficient for carrying the Sz sized trill packets between the RBs using
> UDP.
>

OK.

> Zero Checksum:
> --------------
>
> Section 5.4:
>
> UDP Checksum - as specified in [RFC0768]
>
> Considering the fast path encapsulation desire, I am surprised to not 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 apply
>    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 applicability 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 done.
>
> OK. We'll look into it.
>
>
> TCP Encapsulation issue
> -----------------------
>
> Section 5.6:
>
> The TCP encapsulation appear to be missing an delimiter format allowing each
> individual TRILL packet/payload to be read out of the TCP's byte stream. In
> other words, a normal implementation has no way of ensuring that the TCP
> payload starts with the start of a new TRILL payload. Multiple small TRILL
> payloads may be included in the same TCP payload, and also only parts 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 length field
> for the TRILL payload to be encapsulated.
>
> Right. It might also be useful to include some sort of check field, as
> is done in BGP, to detect if you are out of sync in parsing the TCP
> stream.
>
> As you need to actually perform re-assembly, the solution is to use the
> byte stream semantics the TCP API provides and have a framing for each
> packet.
>

Of course.

My point was that the framing might usefully have some sort of flag field,
like the BGP framing has, so that there was a good chance of detecting if
the parsing of the byte stream into frames has gotten out of synch.

> 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 handling
> 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 not
> be too hard.
>
>
> Yes, agreed it is a possibility and points into possible considerations
> that David raised.
>
> 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 sizes 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?
>
>
> As Joe said, these are important considerations. If your intention is to
> enable this to run at substantial fractions of line rates of the
> interfaces. Then this do require considerations.
>

I see.

> 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, specific
>    congestion control mechanisms are commonly needed.  However, if the
>    traffic being carried by the TRILL over IP link is already congestion
>    controlled and the size and volatility of the TRILL IS-IS link state
>    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 way of knowing
> which traffic is actually congestion controlled, considering that TRILL provides
> an layer 2 abstraction. I wonder if there should be any type of white 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 any
> recommendation to prevent traffic that is not controlled to be forwarded, can
> lead to congestion issues.
>
> The other issue I think may exist is the issue serial unicast emulation of
> broadcast/multicast creates. As this amplifies the outgoing packet rate with
> a factor of how many addresses are configured for serial unicast this can
> be significant traffic expansion. Thus, I think additional considerations 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 an
> 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 inner
> layer 2 frames, and use the flow equivalents that exists on that level 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 ensure 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.
>
>
> Okay, then this is very straightforward.
>
> 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 static binding
> configurations or the need for determining ones external address(es) and be
> able to communicate that to the peer RBridges, and in addition ensure 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.
>
> Yes, and the question is how that can be handled, by the receiver of the
> packet, or if the sender needs to determine what address it uses and
> provide that in the HELLOs. If the first is possible that can simplify a
> lot.
>

I'm not sure. this would require a little detailed design work.

> 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.
>
> Yes, I think that are likely the simplest solution for you.
>

OK

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

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). Note 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 bytes MTU
> Ethernet infrastructure.
>
> I would note that also firewalls likely have issues with IP fragments for the
> same reason, they require significant amount of state to be verified if they
> should be let through.
>
> In general I think you should create a configuration that has chance to work
> through most middleboxes, but I think you should require static bindings. 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.
>
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287 <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile +46 73 0949079 <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>

--001a1141bcbec246930553240434
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


HI Magnus,

On Tue, Jun 27, 2017 at 1:13 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:







Hi Donald,



After having read your response I think there is an important question abou=
t the applicability of this document that affects several of the issues bel=
ow and what solution you need. That is the question of what type of paths o=
ne expect to get Trill over IP working
 over. Because if the target is general Internet and also through middlebox=
es such as NATs and Firewall (Not intending to block) then there are a lot =
more work to ensure this. If you for example changes the applicability to r=
equire any on path middleboxes to
 fulfill certain requirements things can be more easily addressed. 

The use cases in the document support =
communication over the general Internet in the brach office case but that d=
oes not necessarily imply NATs/Firewalls.

<=
span class=3D"gmail-m_-2274122840677479759gmail-">
Den 2017-06-26 kl. 02:07, skrev Donald Eastlake:






Hi Magnus,

Thanks for the extensive review. See my responses below.

On Thu, Jun 15, 2017 at 1:32 PM, Magnus Westerlund
<magnus.westerlund@ericsson.com> wrote:







Diffserv usage
--------------

Section 4.3:

   TRILL over IP implementations MUST support setting the DSCP value in
   the outer IP Header of TRILL packets they send by mapping the TRILL
   priority and DEI to the DSCP. They MAY support, for a TRILL Data
   packet where the native frame payload is an IP packet, mapping the
   DSCP in this inner IP packet to the outer IP Header with the default
   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 discussion o=
f
the potential issues with actually setting the DSCP values. It is one thing=
 to
do this in an IP back bone use case where one can know and have control ove=
r
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 policers or
remapping. Also as the actual DSCP code point usage is domain specific this=
 is
difficult. Priority reversal is likely the least of the problems that this =
can
run into over general Internet.





It sounds like appropriate discussion and warnings about these issues
would resolve the above comment.

I would note that the choice of encapsulation here do becomes important. Yo=
ur's and Joe Touch's observation that for TCP, you can only have a =
single DSCP marking per TCP connection for example. For others, see the dis=
cussion in Section 5.1 of

https://datatracker.ietf.org/doc/rfc7657/ on this issue. 

Well, if a TRILL over IP implementation u=
sing TCP transport wants to have more than one priority category for traffi=
c where there might be one or more intervening IP routers, which would be t=
he normal case, it would just need a TCP connection per priority category. =
Mapping the 8 priority levels into a smaller number of categories is a rout=
ine thing to do. Note that the base TRILL protocol specification (RFC 6325)=
 says:

   RBridges are not required to implement any
   particular number of distinct priority levels but may treat one or=C2=A0=

=C2=A0 =C2=A0more adjacent priority levels in the=
 same fashion.
=C2=A0

David Black also raised an important question if one should treat this as a=
 tunnel with a single predictable behavior or let the inner networks markin=
g show through. Establishing a tunnel with a single PHB has less risk of ru=
nning into issues than multiple
 different markings.=C2=A0

It is an i=
mplementation choice whether to have a single PHB or eight, one per priorit=
y level, or something in between.=C2=A0








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 networks this=
 can
also results in strange remapping that results in a different PHB for CS1 t=
han.





The intent in the draft is to reflect the default relative priority of
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...





David Black provide a good answer on this. 
=C2=A0
I'll reply to him.








MTU and Fragmentation
---------------------

I think there are two main issue here. The first one is MTUD discovery
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 requries
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 were
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 to
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...





Yes, and over general Internet you should be happy if you get 1500 bytes of=
 IP MTU, it may easily be lower with a couple of additional tunnel headers.=
 Thus, what you say is the goal is not feasible without a solution that sup=
ports fragmentation and reassembly,
 enabling one TRILL packet to be sent in multiple IP packets. The re-assemb=
ly do requires buffering and not something to easily perform on a router fa=
st path. And attempting to use IP fragmentation is likely doomed if you hav=
e any type of NAT or Firewall in
 the way. 



This points to a dedicated solution or using a transport protocol that supp=
orts carrying arbitrary data sizes, like TCP or SCTP. And you need to use t=
he byte-stream API of TCP to achieve this.

=C2=A0
OK.








Section 8.4:

   Path MTU discovery [RFC4821] should be useful
   in determining the IP MTU between a pair of RBridge ports with IP
   connectivity.

The issue with RFC4821 is that it has requirements on the packetization lay=
er.
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.





Okay, if you say so, it was not obvious from the spec that is was allowed t=
o probe for paths with lesser MTUs than 1470.









Thus, it appears that there is a lack of mechanism here to actually ge=
t a valid
and functional MTU from TRILL in the cases where the Path MTU is below 1470=
. If
I am wrong good, but I think this is an important piece for how to handle t=
he
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.)

I looked at this, and it appears to have the same issue, that it can't =
probe for MTU values below 1470.


I think the thing was that, befo=
re TRILL over IP, it would not have been useful to determine an MTU below 1=
470. But there is no particular problem in constructing a smaller MTU-probe=
 PDUs and an RBridge receiving such a PDU is generally required to respond =
with an equal length MTU-ack.=C2=A0


   2) RB1 tries to send an MTU-probe padded to the size 1470.

      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&#=
39;s Hello
         and stop.


But, the algorithm clearly performs a binary search for the MTU. If=20
one look at RFC 4821 one will notice that there are some additional conside=
rations
there how to make the probing better and robuster. But, cleary Trill has so=
me other
criterias for what is a success. Verification that Sz works appears suffici=
ent,=20
and there are no need to probe further upwards. 








UDP encapsulation and IP fragments.





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





I see it as a big issue that UDP encapsulation is the native one, and =
that
relies on IP fragmentation despite the need for reliable fragmentation. Wit=
h
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 problem 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 to not ge=
t 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 defau=
lt
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 have
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 opera=
te
through a NAT. If you are using UDP and it fragments and fragments are
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.





Yes, but this is the issue of applicability and documenting that applicabil=
ity. I don't know what goals and requirements that exist for Trill. If =
the WG are fine with some restrictions, then document them and focus on sol=
ving the issues that must be solved.




You can clearly choose to require TCP for cases where the IP MTU is insuffi=
cient for carrying the Sz sized trill packets between the RBs using UDP.=C2=
=A0
=C2=A0
OK.








Zero Checksum:
--------------

Section 5.4:

UDP Checksum - as specified in [RFC0768]

Considering the fast path encapsulation desire, I am surprised to not see a=
ny
mentioning of use of zero checksum here. Raising the zero checksum and forw=
ard
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 apply
   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 applicability statem=
ent
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 done.





OK. We'll look into it.






TCP Encapsulation issue
-----------------------

Section 5.6:

The TCP encapsulation appear to be missing an delimiter format allowing eac=
h
individual TRILL packet/payload to be read out of the TCP's byte stream=
. In
other words, a normal implementation has no way of ensuring that the TCP
payload starts with the start of a new TRILL payload. Multiple small TRILL
payloads may be included in the same TCP payload, and also only parts as TC=
P is
one way of dealing with TRILL packets that are larger than the IP+Encapsula=
tion
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 length fi=
eld
for the TRILL payload to be encapsulated.





Right. It might also be useful to include some sort of check field, as
is done in BGP, to detect if you are out of sync in parsing the TCP
stream.

As you need to actually perform re-assembly, the solution is to use the byt=
e stream semantics the TCP API provides and have a framing for each packet.

=C2=A0
Of course.

My point was that the framing might usefully have some sort of flag field=
, like the BGP framing has, so that there was a good chance of detecting if=
 the parsing of the byte stream into frames has gotten out of synch.
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
<=
span class=3D"gmail-m_-2274122840677479759gmail-">



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 handling
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 not
be too hard.





Yes, agreed it is a possibility and points into possible considerations tha=
t David raised.











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 sizes in
relation to Bandwidth delay products, as buffer memory in a RBridge will im=
pact
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?





As Joe said, these are important considerations. If your intention is to en=
able this to run at substantial fractions of line rates of the interfaces. =
Then this do require considerations.=C2=A0

I see.=C2=A0
<=
div bgcolor=3D"#FFFFFF">








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, specific
   congestion control mechanisms are commonly needed.  However, if the
   traffic being carried by the TRILL over IP link is already congestion
   controlled and the size and volatility of the TRILL IS-IS link state
   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 way of kno=
wing
which traffic is actually congestion controlled, considering that TRILL pro=
vides
an layer 2 abstraction. I wonder if there should be any type of white list =
of
the types of layer 2 payloads that can be assumed to be congestion controll=
ed,
and thus okay to forward over IP paths? I am worried that without any
recommendation to prevent traffic that is not controlled to be forwarded, c=
an
lead to congestion issues.

The other issue I think may exist is the issue serial unicast emulation of
broadcast/multicast creates. As this amplifies the outgoing packet rate wit=
h
a factor of how many addresses are configured for serial unicast this can
be significant traffic expansion. Thus, I think additional considerations a=
re
needed here, and maybe rate limiting of the amount of traffic to be multica=
sted.





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 an
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 inne=
r
layer 2 frames, and use the flow equivalents that exists on that level 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 ensure=
 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 lea=
d 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.





Okay, then this is very straightforward. 










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 static bindin=
g
configurations or the need for determining ones external address(es) and be
able to communicate that to the peer RBridges, and in addition ensure 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.

Yes, and the question is how that can be handled, by the receiver of the pa=
cket, or if the sender needs to determine what address it uses and provide =
that in the HELLOs. If the first is possible that can simplify a lot.

=C2=A0
I'm not sure. this would requi=
re a little detailed design work.








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 fragmentati=
on,
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.

Yes, I think that are likely the simplest solution for you. 

OK=C2=A0

Thanks,<=
/div>
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
=C2=A0Donald E. Eastlake =
3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milfor=
d, MA 01757 USA

Al=
so 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)=
. Note that this
will restrict the MTU even further and thus ensure that the 1470 requiremen=
t
cannot be fulfilled even without additional tunnels over an 1500 bytes MTU
Ethernet infrastructure.

I would note that also firewalls likely have issues with IP fragments for t=
he
same reason, they require significant amount of state to be verified if the=
y
should be let through.

In general I think you should create a configuration that has chance to wor=
k
through most middleboxes, but I think you should require static bindings. I
think that configuration is, and don't laugh now, but IP/UDP/ESP/TCP/TR=
ILL,
otherwise you will not be able to have both security and reliable fragmenta=
tion
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.







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.c=
om
-----------------------------------------------------------------=
-----








--001a1141bcbec246930553240434--


From nobody Thu Jun 29 20:20:09 2017
Return-Path: 
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E8C1201F8; Thu, 29 Jun 2017 20:20:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Brian Carpenter 
To: 
Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149879280768.4678.12635697098775028225@ietfa.amsl.com>
Date: Thu, 29 Jun 2017 20:20:07 -0700
Archived-At: 
Subject: [trill] Genart telechat review of draft-ietf-trill-mtu-negotiation-06
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 03:20:08 -0000

Reviewer: Brian Carpenter
Review result: Ready

Gen-ART telechat review of draft-ietf-trill-mtu-negotiation-06

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-trill-mtu-negotiation-06.txt
Reviewer: Brian Carpenter
Review Date: 2017-06-30
IETF LC End Date: 2017-06-28
IESG Telechat date: 2017-07-06

Summary: Ready
--------

Comment:
--------

Thanks for handling my Last Call comments.


From nobody Fri Jun 30 00:52:32 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65917126E3A; Fri, 30 Jun 2017 00:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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] 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 LIve2-jfNRDu; Fri, 30 Jun 2017 00:52:28 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD91126C22; Fri, 30 Jun 2017 00:52:19 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id h134so19959945iof.2; Fri, 30 Jun 2017 00:52:19 -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=ibY1CmAj2jILWoMY19yYRJg7PDvTA/He+3y/Kc3NS2E=; b=cIQrJPt830XSqxnT0SVSOke061y+E6AvT9uFUg+nKGqDwa9TIPzkQghTHIhLsAIWnb CpakMSZWJqde8D+ACA9zeXPQrUzqulK1eLoTzjhY/5DiXDRvk2QBi1IdEiidALg3G+L6 mGH+VEMRSYOkQ/Mfgkw58bZrdNMUBKSpmKyZlbq9k64zBT9DnBTlLjmx7xOBlOXfQEnC 7PvD7J6VhjP2rGWDP1GX1lxEG8dJbuqFcYlogTVb+gjTqxWf8Q67P1+AQOIqpOngpNbi yPp6wg6FXkmbizHMjrnuNaoFPYR4nWar4WkWwzGtNgJZAd3Bx8wKCilnXZ8rgg/YfUTI XfNw==
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=ibY1CmAj2jILWoMY19yYRJg7PDvTA/He+3y/Kc3NS2E=; b=Lo9JoYWkdZNdloiCOBCpSWOM1ZBmMP9RsCNtAEyBb6q1Gc9V1HtryH+dS39H3Usoi/ ZP9mOii/r9zVNlLlD517GggAti4PvWzgX1dh8fa85KRR7iC5zIn9zw0HWDagPTx+Y4mq EJX7WgOeabj7BUTvkYi6KY6Zauewvvur+WKG0E/yc3nECZIl9m6h3eNK4iR5Pdkd+KfY pYYV7199GbU4vt1wB2AL/MhTfTppbFTG5PmYYYhmd1i065OdPA31iGCyu/cvQ4Q8aEvt /ejt7svEZAr+ZFebKptQbqTWSVY3mTcM5ucSoiqf/ElR4ftFBfUuNSaPtF00nArLFTJ1 uWFg==
X-Gm-Message-State: AKS2vOzHcl4742kVOH3AqPflMCXyE/+WsnHmlbUe2liz0gqO+2mNIRP7 YiSHM+Pz2l1aNTKsLT1ZIttQ8Vb2Qw==
X-Received: by 10.107.5.133 with SMTP id 127mr20800764iof.50.1498809138429; Fri, 30 Jun 2017 00:52:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.39.149 with HTTP; Fri, 30 Jun 2017 00:52:17 -0700 (PDT)
In-Reply-To: <4552F0907735844E9204A62BBDD325E7A6537D2A@NKGEML515-MBX.china.huawei.com>
References: <013201d2eaca$f131c5b0$d3955110$@ndzh.com> <4552F0907735844E9204A62BBDD325E7A6537D2A@NKGEML515-MBX.china.huawei.com>
From: Santosh P K 
Date: Fri, 30 Jun 2017 13:22:17 +0530
Message-ID: 
To: "Zhangmingui (Martin)" 
Cc: Susan Hares , "trill@ietf.org" ,  "trill-chairs@ietf.org" , Donald Eastlake ,  "draft-ietf-trill-p2mp-bfd@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113efd3e484e75055328b2e6"
Archived-At: 
Subject: Re: [trill] IPR call for draft-ietf-trill-p2mp-bfd
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 07:52:31 -0000

--001a113efd3e484e75055328b2e6
Content-Type: text/plain; charset="UTF-8"

Hello Susan,
      I am not aware of any IPR related to this document.

Thanks
Santosh P K

On Thu, Jun 22, 2017 at 6:57 AM, Zhangmingui (Martin) <
zhangmingui@huawei.com> wrote:

> For this draft, I am not aware of any IPR that needs to be disclosed.
>
>
>
> Thanks,
>
> Mingui
>
>
>
> *From:* Susan Hares [mailto:shares@ndzh.com]
> *Sent:* Thursday, June 22, 2017 4:14 AM
> *To:* trill@ietf.org
> *Cc:* trill-chairs@ietf.org; 'Donald Eastlake'; draft-ietf-trill-p2mp-bfd@
> ietf.org
> *Subject:* IPR call for draft-ietf-trill-p2mp-bfd
>
>
>
> Minqui, Santosh, and  Vengad:
>
>
>
> It appears we did not complete our IPR call for draft-ietf-trill-p2mp-bfd.
>   You please respond this email with your IPR statement about
> draft-ietf-tyrill-p2mp-bfd?
>
>
>
> Thank you,
>
> Sue Hares
>

--001a113efd3e484e75055328b2e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Susan,
=C2=A0 =C2=A0 =C2=A0 I am not aware of an=
y IPR related to this document.=C2=A0

Thanks
=

Santosh P K=C2=A0

On Thu, Jun 22, 2017 at 6:57 AM, Zhangmingui (Martin) <zhangmingui@huawei.com> wrote:











For this draft, I am not aware of any IPR that needs to be disclo=
sed.



=C2=A0


Thanks,


Mingui


=C2=A0








From: Susan Hares [mailto:shares@ndzh.com]


Sent: Thursday, June 22, 2017 4:14 AM

To: trill@ietf.o=
rg

Cc: trill=
-chairs@ietf.org; 'Donald Eastlake'; draft-ietf-trill-p2mp-bfd@ietf.org

Subject: IPR call for draft-ietf-trill-p2mp-bfd=







=C2=A0


Minqui, Santosh, and=C2=A0 Vengad: 


=C2=A0

It appears we did not complete =
our IPR call for draft-ietf-trill-p2mp-bfd. =C2=A0=C2=A0You please respond =
this email with your IPR statement about draft-ietf-tyrill-p2mp-bfd?



=C2=A0


Thank you, 


Sue Hares =C2=A0<=
/span>












--001a113efd3e484e75055328b2e6--


From nobody Fri Jun 30 13:18:39 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538B9127076 for ; Fri, 30 Jun 2017 13:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 uWi5Pq289M9x for ; Fri, 30 Jun 2017 13:18:35 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 219AB12E957 for ; Fri, 30 Jun 2017 13:18:35 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id q86so72062195pfl.3 for ; Fri, 30 Jun 2017 13:18:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=5p+uWnzFuJWtD59Mm5ZGUNIb19jn47eAhtht/fBRs6s=; b=O1LSpMw/XYbdUCn2aUzAzQKEXKKYx0e7FlO4Q+7KEeaq1m+j8Ty9a3Vd1uh12bP1Y6 KQ4koJoU6au7+FCixu/fyhyKsFSvL+rqrN6fYsrubFYetIV6O5DmT4UZ9VSxY0oa5tLM mOMn69m6LbWJs1+NafLHKG+YPNpGVmHJKBuF3aaafjGMXPmjb5M+ygH4PxuceU8qQXSo NeLm2xAAxn47VPLIPtiv8EttvTq4wtn8Y2HTjHbdG/DToXngLeSbqGpXZgJj/JMHTTb5 S0Lxpl+eAhyM9wpA+jE5kb/mDskQIUxK9Nw3qtAnt8u24T6HU2nqBiFCmIqpyv/UuKLE vQVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5p+uWnzFuJWtD59Mm5ZGUNIb19jn47eAhtht/fBRs6s=; b=gPZ9+GOS1dMjQSO00hnYSZyfl8kHncnzr7XRo8NOoM9ImtidaElQl09Tbbj2v/fEyo 5sUQWmu2p0sB9l1CEnusyZZCs8D+8uNzMCN643989wTW5aaFh2tQv7rDFpsO7ycV6gc/ VzNR/DYXHNLGqTYVcna3sat61AyYFPOZbMtV+awsNnP0ZvkQtU80lJuOOpUNx4W49dx7 H8nsp8900eyp+lrVjNzMP2usuW3OExFzck1+IR16M3h3ho7wR7QUWghJQSpqFb+i73wy 8gea6Hu49EK6xU5j68OMlpJdYdu88bZT5Gh4zW0zokGth7ZDT4I3642Myg43xjn0x8IH 2Gjg==
X-Gm-Message-State: AKS2vOwrGb1xuaviCzH6c6vO+7DiEfZjdT9mTb9Awq+xmgnyVMKSsoV5 iKHHx9PyFs8+xEOjEm8w0icANebsYw==
X-Received: by 10.84.234.22 with SMTP id m22mr8367889plk.268.1498853914438; Fri, 30 Jun 2017 13:18:34 -0700 (PDT)
MIME-Version: 1.0
From: Tina Tsou 
Date: Fri, 30 Jun 2017 20:18:23 +0000
Message-ID: 
To: "trill@ietf.org" 
Cc: "tina.tsou@arm.com" 
Content-Type: multipart/alternative; boundary="f403043601ce23f05e0553331f3c"
Archived-At: 
Subject: [trill] [nvo3] Poll for WG adoption and IPR call for draft-sarikaya-nvo3-vmm-dmm-pmip-11
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jun 2017 20:18:37 -0000

--f403043601ce23f05e0553331f3c
Content-Type: text/plain; charset="UTF-8"

Dear all,

I support adoption of this draft as WG draft, as it describes well the
protocols about virtual machine mobility currently in use in the industry.


"Bocci, Matthew (Nokia - GB)"  Tue, 13 June 2017
15:19 UTCShow header


This email begins a two week poll for adoption of
draft-sarikaya-nvo3-vmm-dmm-pmip-11 in the NVO3 working group.

Please review the draft and send any comments to the NVO3 list.
Please also indicate whether you support adoption of the draft as an
NVO3 working group document.

Simultaneously, we are also poling for any IPR that may apply to the draft.

Authors and contributors, are you aware of any IPR that applies to this draft?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
If you are listed as a document author or contributor, please respond to
this email stating of whether or not you are aware of any relevant
IPR. The response needs to be sent to the NVO3 WG mailing list. The
document will not advance to the next stage until a response
has been received from each author and each contributor.

This poll closes on Wednesday 28th June 2017.

Regards

Matthew and Sam


-- 
Thank you, Tina

--f403043601ce23f05e0553331f3c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear all,

I support adoption of this draft as =
WG draft, as it describes well the protocols about virtual machine mobility=
 currently in use in the industry.


"Bocci, Matthew (Nok=
ia - GB)" <matthew.bocci@nokia.com>=C2=A0Tue, 13 June 20=
17 15:19 UTCShow header
This email begins a two week poll for adoption of draft-sarikaya-nvo3-=
vmm-dmm-pmip-11 in the NVO3 working group.

Please review the draft and send any comments to the NVO3 list.
Please also indicate whether you support adoption of the draft as an NVO3 w=
orking group document.

Simultaneously, we are also poling for any IPR that may apply to the draft.

Authors and contributors, are you aware of any IPR that applies to this dra=
ft?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs 3979, 4879, 3669 and 5378 for more details)?
If you are listed as a document author or contributor, please respond to
this email stating of whether or not you are aware of any relevant
IPR. The response needs to be sent to the NVO3 WG mailing list. The
document will not advance to the next stage until a response
has been received from each author and each contributor.

This poll closes on Wednesday 28th June 2017.

Regards

Matthew and Sam


-- 


Thank you,
Tina


--f403043601ce23f05e0553331f3c--


From nobody Fri Jun 30 18:43:36 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADE012EC5C; Fri, 30 Jun 2017 18:43:35 -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 eTvYNoVfK8wD; Fri, 30 Jun 2017 18:43:31 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 EE95512EABA; Fri, 30 Jun 2017 18:43:30 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id r36so32633421ioi.1; Fri, 30 Jun 2017 18:43:30 -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=QgV41TXIZD7Vk5O6hFiAunE+DHtrdZuP08ULzeYh1Nk=; b=mY/uoT/MQLktf5kK42lyLAPk6UexxqDAuE6kufCOUSfUFrOR2DkqXLVcHgpK5phQDZ ygRDioA3PnCQ5X8TsCQaJqilQ/XJgMOPt4GC0Yaz0m/rp9c5sVeI/N0HNLNYyTBEWbWQ iPhieu5dBFmV1m/NaUcvflcbvtmRW1dJt/bllGT9qy3I0scxamL+L2q89CXXuXntVa/c 2nvm7pm3IpxbCsLJ4VGq569bP3VerCTsssAcIAn7DNYbdHLOyYhf4hrvtqV5EN/yTcGv PGaElgH+sHIzPfkzRQaeTJEWDAZrIzoulU2sKtotkj57iJNuD8pMO6KTi4FfFlsJQlv7 XaYg==
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=QgV41TXIZD7Vk5O6hFiAunE+DHtrdZuP08ULzeYh1Nk=; b=FloA/PSF+3c5n3Ke5DTqpuHKpNVs7SZZ85pREe+9cW+lGr0P3OfvAOwJvJtQflQHlr UsIZZjorojjls9NYm7PlAXET4vhltPu9T7PoDZ5h+5XO4+cqb/4yLtumVPycGTXAnpq1 EqUbWt5JHrdxfqB8+nQ5ITs92gtiY09ZmaNSvWsZUH/QbNXrGcj3JU8MeBG9gyUloAm4 RzQylW0ZWhe6uQ5AOIynOgm4+8UP9zOfktayOPrqBHN437V2YH9N33wLU7x1jqXhwJW0 glKaqbiaFr1PptggNoCcrppnE/DI/5efy0UKDI7A4p2e/kcMcZLWLFhqCtQeWfgnt3M9 bXjQ==
X-Gm-Message-State: AKS2vOy4DKCSO0528qbab4hmP2UqDYpAVx5fVh+2jZz0eZAayWkt8Veg 4XOKErF5v5FpcWwO05uCTHXGZkxtXKo5
X-Received: by 10.107.156.83 with SMTP id f80mr25274248ioe.9.1498873410069; Fri, 30 Jun 2017 18:43:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Fri, 30 Jun 2017 18:43:13 -0700 (PDT)
In-Reply-To: 
References: 
From: Donald Eastlake 
Date: Fri, 30 Jun 2017 21:43:13 -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"
Archived-At: 
Subject: Re: [trill] [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-10 - ECN & DSCP considerations
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Jul 2017 01:43:35 -0000

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 value in
>> >    the outer IP Header of TRILL packets they send by mapping the TRILL
>> >    priority and DEI to the DSCP. They MAY support, for a TRILL Data
>> >    packet where the native frame payload is an IP packet, mapping the
>> >    DSCP in this inner IP packet to the outer IP Header with the default
>> >    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 discussion of
>> > the potential issues with actually setting the DSCP values. It is one thing to
>> > do this in an IP back bone use case where one can know and have control
>> > 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 policers or
>> > remapping. Also as the actual DSCP code point usage is domain specific this is
>> > difficult. Priority reversal is likely the least of the problems that 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 particular,
> copying the inner ECN codepoint to the outer IP header encapsulation without
> requiring decapsulation processing as specified in RFC 6040 or the 6040update-shim
> draft can lose congestion indications from the network and hence is wrong
> (it's also wrong wrt RFC 3168, but RFC 6040 and the 6040update-shim drafts are
> better and more current references).

That's a good point.

> For DSCPs, start with RFC 2983 - thinking about the validity (or likely 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 in 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 of
>> 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 decade
> old, and in an area (less-than-best-effort service) where the aspirations
> 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 service 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
===============================
 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 Discussion
>> ; trill@ietf.org
>> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-trill-over-ip-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 significant 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 specifications. 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 value in
>> >    the outer IP Header of TRILL packets they send by mapping the TRILL
>> >    priority and DEI to the DSCP. They MAY support, for a TRILL Data
>> >    packet where the native frame payload is an IP packet, mapping the
>> >    DSCP in this inner IP packet to the outer IP Header with the default
>> >    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 discussion of
>> > the potential issues with actually setting the DSCP values. It is one thing to
>> > do this in an IP back bone use case where one can know and have control
>> 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 policers or
>> > remapping. Also as the actual DSCP code point usage is domain specific this
>> is
>> > difficult. Priority reversal is likely the least of the problems that 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 networks this can
>> > also results in strange remapping that results in a different PHB for CS1
>> than.
>>
>> The intent in the draft is to reflect the default relative priority of
>> 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 discovery
>> > 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 requries
>> > 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 were
>> 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 to
>> 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 IP
>> >    connectivity.
>> >
>> > The issue with RFC4821 is that it has requirements on the packetization
>> 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 below
>> 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, and that
>> > relies on IP fragmentation despite the need for reliable fragmentation.
>> 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 problem
>> 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 to 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 have
>> 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 are
>> 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 not 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 apply
>> >    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 applicability 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 done.
>>
>> OK. We'll look into it.
>>
>> > TCP Encapsulation issue
>> > -----------------------
>> >
>> > Section 5.6:
>> >
>> > The TCP encapsulation appear to be missing an delimiter format allowing
>> each
>> > individual TRILL packet/payload to be read out of the TCP's byte stream. In
>> > other words, a normal implementation has no way of ensuring that the TCP
>> > payload starts with the start of a new TRILL payload. Multiple small TRILL
>> > payloads may be included in the same TCP payload, and also only parts 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 length
>> field
>> > for the TRILL payload to be encapsulated.
>>
>> Right. It might also be useful to include some sort of check field, as
>> 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 handling
>> 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 not
>> 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 sizes 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, specific
>> >    congestion control mechanisms are commonly needed.  However, if the
>> >    traffic being carried by the TRILL over IP link is already congestion
>> >    controlled and the size and volatility of the TRILL IS-IS link state
>> >    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 way of
>> knowing
>> > which traffic is actually congestion controlled, considering that TRILL
>> provides
>> > an layer 2 abstraction. I wonder if there should be any type of white 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 any
>> > recommendation to prevent traffic that is not controlled to be forwarded,
>> can
>> > lead to congestion issues.
>> >
>> > The other issue I think may exist is the issue serial unicast emulation of
>> > broadcast/multicast creates. As this amplifies the outgoing packet rate with
>> > a factor of how many addresses are configured for serial unicast this can
>> > be significant traffic expansion. Thus, I think additional considerations 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 an
>> 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 inner
>> > layer 2 frames, and use the flow equivalents that exists on that level 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 ensure 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 static binding
>> > configurations or the need for determining ones external address(es) and
>> be
>> > able to communicate that to the peer RBridges, and in addition ensure 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). Note 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 bytes MTU
>> > Ethernet infrastructure.
>> >
>> > I would note that also firewalls likely have issues with IP fragments for the
>> > same reason, they require significant amount of state to be verified if they
>> > should be let through.
>> >
>> > In general I think you should create a configuration that has chance to work
>> > through most middleboxes, but I think you should require static bindings. 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
>> ===============================
>>  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 Fri Jun 30 18:55:30 2017
Return-Path: 
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1650131508 for ; Fri, 30 Jun 2017 18:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 db1Hie7YUQVU for ; Fri, 30 Jun 2017 18:55:26 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D09A1200F3 for ; Fri, 30 Jun 2017 18:55:26 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id e7so74872635pfk.0 for ; Fri, 30 Jun 2017 18:55:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m9yXE1gxYYVq4d4em+j2802sgGAr13VwpqDhfeB8SHU=; b=qxJoEQ58nTbXzlBMHtl+Qq/6hLID0es2hPuEqAW5X6hqpRZ6ihtLmarsec1e4vofRu Q98/ksbrLSRMupQGu+AGrgVqex2UjQ5CeTOx3Xfk5CEjwofdZtGorBrusO4GoyUj5Ou1 nO7penhvrzcEzcDlH3MeaUmH6PuoC++wnbtQ98GYqUc2Pj/qDiYwiEF4P0JMYO7RK31e LRuzE0FQCzmFBxgQbfGZPOZ3VUvInLcHMtyjyJb/9BfzFplQT9s5FlOpbztadbcQfj9x e2QizhONY5D0phZDec0VdBHhhlxf1wXwNVcMTsDia2+dWjzY+/lcmTM86zHF4hGYo+yY gN0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m9yXE1gxYYVq4d4em+j2802sgGAr13VwpqDhfeB8SHU=; b=JeF5Cz/PKzO0hoR2bo4AlGqa3YhEaetKUZMapJx8pazqrfM/yE5W2aAj3oguAKw9A0 ZANrHG/7FdQEH/9pdGZEq5Uxwqy9FlRG5YkfJzg5F61IchL5kyKrV1hD6FYpaVHiqu3A FYfqThDTzoa+M6g4rbMkXv7dUbh3zfQZZUFq9W3W/p1yNloXfLRqDRtPnP0ACXIH2r0u pJPLJCqOPIxq5xKBmXzuBGejh/v4rKIcz+MPqJ+1TF6HpUeNlWUylwFK0gLvFwlQwmnL QEN/iUCwDSRp08KWuNEdz8LsRO0sbGWsv2OMe9/9OIlCZfsVry8sEHiRVy3cvEV7BwZq II4w==
X-Gm-Message-State: AKS2vOxz8jgjAUL1yj8cOOAK1z8PbQr+IhrBaHxyki4QUFswW5axT251 P1FV+jd2VpHjh28KVMVjVJxlDPtXPQ==
X-Received: by 10.99.98.193 with SMTP id w184mr23777164pgb.155.1498874125466;  Fri, 30 Jun 2017 18:55:25 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Tina Tsou 
Date: Sat, 01 Jul 2017 01:55:15 +0000
Message-ID: 
To: "trill@ietf.org" 
Cc: "tina.tsou@arm.com" 
Content-Type: multipart/alternative; boundary="94eb2c11bc02cfbf8f055337d338"
Archived-At: 
Subject: Re: [trill] [nvo3] Poll for WG adoption and IPR call for draft-sarikaya-nvo3-vmm-dmm-pmip-11
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Jul 2017 01:55:28 -0000

--94eb2c11bc02cfbf8f055337d338
Content-Type: text/plain; charset="UTF-8"

Dear all,

Sorry, I meant to send to nvo3. My big fingers.

Pls just ignore the previous email.

On Fri, Jun 30, 2017 at 1:18 PM Tina Tsou  wrote:

> Dear all,
>
> I support adoption of this draft as WG draft, as it describes well the
> protocols about virtual machine mobility currently in use in the industry.
>
>
> "Bocci, Matthew (Nokia - GB)"  Tue, 13 June 2017
> 15:19 UTCShow header
> 
>
> This email begins a two week poll for adoption of draft-sarikaya-nvo3-vmm-dmm-pmip-11 in the NVO3 working group.
>
> Please review the draft and send any comments to the NVO3 list.
> Please also indicate whether you support adoption of the draft as an NVO3 working group document.
>
> Simultaneously, we are also poling for any IPR that may apply to the draft.
>
> Authors and contributors, are you aware of any IPR that applies to this draft?
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> If you are listed as a document author or contributor, please respond to
> this email stating of whether or not you are aware of any relevant
> IPR. The response needs to be sent to the NVO3 WG mailing list. The
> document will not advance to the next stage until a response
> has been received from each author and each contributor.
>
> This poll closes on Wednesday 28th June 2017.
>
> Regards
>
> Matthew and Sam
>
>
> --
> Thank you, Tina
>
-- 
Thank you, Tina

--94eb2c11bc02cfbf8f055337d338
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear all,

Sorry, I meant to send to nvo3. My big fingers.

Pls just ignore the previous email.
=

On Fri, Jun 30, 2017 at 1:18 PM Tina Ts=
ou <tinatsou6@gmail.com> w=
rote:
Dear all,

I support adoption of this draft as WG draft, as it describes wel=
l the protocols about virtual machine mobility currently in use in the indu=
stry.


"Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia=
.com>=C2=A0Tue, 13 June 2017 15:19 UTCShow hea=
der
This email begins a two week poll for adoption of =
draft-sarikaya-nvo3-vmm-dmm-pmip-11 in the NVO3 working group.

Please review the draft and send any comments to the NVO3 list.
Please also indicate whether you support adoption of the draft as an NVO3 w=
orking group document.

Simultaneously, we are also poling for any IPR that may apply to the draft.

Authors and contributors, are you aware of any IPR that applies to this dra=
ft?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs 3979, 4879, 3669 and 5378 for more details)?
If you are listed as a document author or contributor, please respond to
this email stating of whether or not you are aware of any relevant
IPR. The response needs to be sent to the NVO3 WG mailing list. The
document will not advance to the next stage until a response
has been received from each author and each contributor.

This poll closes on Wednesday 28th June 2017.

Regards

Matthew and Sam


-- 


Thank you,
Tina
-- 


Thank you,
Tina


--94eb2c11bc02cfbf8f055337d338--


Hi,

I support the adoption of this draf=
t.

It does not require any protocol changes and sh=
ould provide the means to improve the stability of TRILL distribution trees=
.

The draft is simple enough that I believe we can=
 complete the work within a year.

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
=C2=A0Donald E. Eastlake 3rd =
=C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757=
 USA
=C2=A0d3e3e3@=
gmail.com


On Wed, May 31, 2017 at 5:31 PM, Susan Hares=
 <shares@ndzh.com> wrote:
This begins a 2 week WG adop=
tion call for draft-rp-trill-parent-selection from 5/31/2017 to 6/13/2=
017.=C2=A0 You can obtain the draft at: =C2=A0
https://datatracker.ietf.org/doc/draf=
t-rp-trill-parent-selection/.
=C2=A0
The authors should indic=
ate if they know of IPR on this draft.=C2=A0 This should be sent to the WG =
list within 1 week or the WG adoption or we will =E2=80=9Cstall=E2=80=9D th=
e WG adoption call waiting for it.=C2=A0=C2=A0 (Normally TRILL authors are =
great at responding =E2=80=93 so we are running the IPR and WG Adoption cal=
l in parallel). 
=C2=A0
The TRILL WG group should consider on this inf=
ormation draft if: 
=C2=A0
=C2=A0
1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is the documentation the known problem in the TRILL tree construction =
mechanism and offers an approach requiring no change to the TRILL 
protocol in or=
der to solve the problem is a useful for TRILL deployments.
2)=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Does this draft document this problem? <=
u>
=
3)=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Can we complete this work within 1 year? =

=C2=A0
=C2=A0
Sue Hares 
=
=C2=A0
=C2=A0