From nobody Tue Jul 2 14:51:04 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82275120169; Tue, 2 Jul 2019 14:51:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Mike McBride via Datatracker To: Cc: draft-ietf-babel-hmac.all@ietf.org, babel@ietf.org, mmcbride7@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Mike McBride Message-ID: <156210426145.23799.16215559699319611305@ietfa.amsl.com> Date: Tue, 02 Jul 2019 14:51:01 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-babel-hmac-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 21:51:02 -0000 Reviewer: Mike McBride Review result: Ready Howdy, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-babel-hmac-07 Reviewer: Mike McBride Review Date: 2 July 2019 IETF LC End Date: 5 July 2019? Intended Status: Standards Track Summary: I reviewed the -00 of this draft back in Sept. 2018. The authors addressed my suggestions. I've now reviewed the -07 version and see no issues. Comments: This document is clearly written and easy to understand and ready to go. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: I still think a terminology section would be helpful in this, and most, ietf drafts but the authors did a good job of defining acronyms throughout the draft. well done. mike From nobody Tue Jul 2 20:27:35 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E94F12014B; Tue, 2 Jul 2019 20:27:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Carlos Pignataro via Datatracker To: Cc: manet@ietf.org, ietf@ietf.org, draft-ietf-manet-dlep-latency-extension.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Carlos Pignataro Message-ID: <156212444727.24005.11059998460216924141@ietfa.amsl.com> Date: Tue, 02 Jul 2019 20:27:27 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-manet-dlep-latency-extension-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 03:27:27 -0000 Reviewer: Carlos Pignataro Review result: Has Nits TL;DR: Reviewer: Carlos Pignataro Review Result: Ready with Nits Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-manet-dlep-latency-extension-04.txt Reviewer: Carlos Pignataro Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This is a well written and straightforward document describing an extension to RFC 8175's Dynamic Link Exchange Protocol (DLEP). The Data Item and Extension Type for Latency Range closely follow the specification of the corresponding Latency information elements from RFC 8175. Minors/Nits for consideration: * It would be useful to expand the DLEP acronym in the Title and Abstract. * Regarding "The use of the Latency Range Extension SHOULD be configurable", an operational comment: What is the default (enabled or disabled)? In what cases does this not need be configurable (i.e., is it a MUST)? * Error checking: what happens if the Latency data item defined in RFC 8175 falls outside the range of the Latency Range data item herein defined? (i.e., I understand that should not happen but I may be wrong). And what if Latency Range is included without Latency being included? * Section 5: s/requests the assignment of 2 values/requests the assignment of two values/ Thanks! Carlos Pignataro. From nobody Wed Jul 3 06:08:50 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7914D12015C; Wed, 3 Jul 2019 06:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 YxL77P-IIuM6; Wed, 3 Jul 2019 06:08:38 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.6]) (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 A0D45120319; Wed, 3 Jul 2019 06:08:37 -0700 (PDT) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta.az-a.eu-central-1.aws.symcld.net id 91/BA-10247-3D8AC1D5; Wed, 03 Jul 2019 13:08:35 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJsWRWlGSWpSXmKPExsUi9LZno+6lFTK xBl83GVlsWdTNYnHyv7PFyTk/mC0WrHnK7sDisWTJT6YAxijWzLyk/IoE1ox3J08wF0x4xljR s+QRWwNjy2PGLkYuDhaBtcwSb09NZAZxhAQmMEk0z//PBOHcY5RYsWo2WxcjJwebgK3EptV3w WwRAU2J/p5bLCBFzAJrGCWuztzMCpIQFrCUWNNxnh2iyE5i0cK7TBC2nsTueQ1gNSwCKhLnp2 9nBrF5BWIlbt7dxAhiMwqISXw/tQasnllAXOLWk/lgtoSAgMSSPeeZIWxRiZeP/7FC1CdJ3H+ 6kBEirigx494cdghbVuLS/G6ouK/E3f+LgI7mALKVJba8iAW5WULgMaPEnf3bWSFqtCS2H58B NT9H4smCyVC96hItH+dB1chI3JnTyQTRPJ1N4sunzWBFQgLJEifmfGaBKJKTWNX7kAWi6AKzx J221ywgm5kF8iROtldDPCwocXLmExaYoW+PzmGewKg5C8nPsxA6ZiHpgAhrSqzfpQ9RrSgxpf shO4StIdE6Zy47svgCRvZVjBZJRZnpGSW5iZk5uoYGBrqGhsa6RrqmxnqJVbqJeqmlusmpeSV FiUBJvcTyYr3iytzknBS9vNSSTYzAFJZSyGS6g7F31hu9Q4ySHExKoryrK2VihfiS8lMqMxKL M+KLSnNSiw8xynBwKEnwSi4HygkWpaanVqRl5gDTKUxagoNHSYS3aSlQmre4IDG3ODMdInWKM ZBjwsu5i5g53v1cDCQ/rloCJL+DyeY7IHLz3KVA8giIFGLJy89LlRLn7QHZIwAyKKM0D24NLE dcYpSVEuZlZGBgEOIpSC3KzSxBlX/FKM7BqCTMOxtkCk9mXgncNa+ADmUCOlQ+Xwrk0JJEhJR UA1PesZXTP+9gmpItmj/xj+qMv7+5DUJ/JgRkfwr4W8F4lkt2s5H1eqkttbG/8x9lsrX8bs10 Kgyw6quq31dT9Dprz261OrFXX2a+9p/QPIO//WXYrMDWpSfltD5pxd6VNAlKWrFm/86VLVH/3 ynVfn7ywuKUesK2PNndfv+t3LcxxPeIc8yZcMpynYSU2WS3dK2dIrPsWaY8PX81PnVKS7iOIM su/uvRqxeaPmr4f+D4Qo39TF2F5S8vnp8qKX+xOGlVx7G7l3/ea11Rxpe88M61RpZ9s99r3PR m+FW+T3zZLPWEF3efVSbuftOhU2p7j/E/Q8z5mA+PDput3iH/2dr9wa04x7vx0wuOBW+059+v xFKckWioxVxUnAgAkvGFBYwEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-226.messagelabs.com!1562159312!102957!1 X-Originating-IP: [18.237.140.177] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.43.9; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 8879 invoked from network); 3 Jul 2019 13:08:33 -0000 Received: from ec2-18-237-140-177.us-west-2.compute.amazonaws.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.177) by server-9.tower-226.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 3 Jul 2019 13:08:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+L8nvQFu3bnolXGlG0OkUmciEew3mN0G6AXGmbBQ+gg=; b=jiiiUX+Z8seSUt816tDt4uBn1P/V00qyQ1PUu9uHHIVDTpp4p0C0YkuBfO2hSmzo0QdAaSIxdzbopy5ynEyb99BaYdKjcS4QKnt8XLGD4kG6Bgh15C5OWruomWw2itrF3LrKtf9xnZBbMbLQh7v05VSa+KqpnrrXSOxrkns5d6s= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB5843.eurprd03.prod.outlook.com (20.179.39.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.17; Wed, 3 Jul 2019 13:08:29 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.2032.019; Wed, 3 Jul 2019 13:08:29 +0000 From: Alexander Vainshtein To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "draft-ietf-babel-applicability.all@ietf.org" , "babel@ietf.org" Thread-Topic: RtgDir review: draft-ietf-babel-applicability-06 Thread-Index: AdUvH5YiygIfUsyWQTGhUP+K9gfY2Q== Date: Wed, 3 Jul 2019 13:08:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06fdcef6-01f6-4d27-9725-08d6ffb78b1f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB5843; x-ms-traffictypediagnostic: AM0PR03MB5843: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(396003)(366004)(376002)(346002)(199004)(51444003)(189003)(66066001)(64756008)(66446008)(66476007)(450100002)(5660300002)(66556008)(7696005)(54906003)(66946007)(54896002)(6306002)(9686003)(7736002)(316002)(73956011)(4326008)(52536014)(86362001)(81156014)(26005)(74316002)(81166006)(76116006)(9326002)(8676002)(55016002)(6506007)(8936002)(5640700003)(53936002)(33656002)(186003)(71200400001)(71190400001)(486006)(6436002)(99286004)(6916009)(25786009)(102836004)(6116002)(790700001)(72206003)(3846002)(14454004)(68736007)(478600001)(14444005)(2501003)(476003)(2906002)(256004)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB5843; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zgT4tTHYQzju2m2j3xQWdNev8pG/0ZDTiEo+YMg05XyG7d7gvfOgBoCkNDAOS5Vt1iHMhVzSg7M27tkWgjEJZrFG/YZDkWnUMRp98h3QZVJy+FgU+khVaTlD5cCpd+LGZoRUMR7c082WCXl3nbFi+tj2zdXOqhzMhHFxkrf3GYWwhwtmHIEOzGMCY+EZSFPNNnErqmKiJociH2WGatqUMSP4oDEfmlWm8ZlBsNBMGZNYvt/OO0VFMmnDjyPApq6vorjISgPlj7S2fKMN+gyJ6h7qdt8mlr6e5N3dmuIHKYhZ3ZVC83CM75ROYLtc39LPM/BuHSBX9nqpEpoQ8ukSyPSC2eVAO94EqWGIKXjyPO0MS/fLH2bqp8SK1PcuYhFk4GzNyrOkK2txT+cjzCxeJ6ZaDQCihtpniI7bJoQsu24= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38283EF2B5AEB53E24AF190D9DFB0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06fdcef6-01f6-4d27-9725-08d6ffb78b1f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 13:08:29.6176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5843 X-CFilter-Loop: Reflected X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-babel-applicability-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 13:08:48 -0000 --_000_AM0PR03MB38283EF2B5AEB53E24AF190D9DFB0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sCgpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBy ZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8g cmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNz IHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9u IHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRl IGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyCgpBbHRob3VnaCB0aGVzZSBjb21t ZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291 bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBv dGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZl IHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRy YWZ0LgoKRG9jdW1lbnQ6IGRyYWZ0LWlldGYtYmFiZWwtYXBwbGljYWJpbGl0eS0wNgpSZXZpZXdl cjogQWxleGFuZGVyICjigJxTYXNoYeKAnSkgVmFpbnNodGVpbgpSZXZpZXcgRGF0ZTogMDMtSnVs LTE5CklFVEYgTEMgRW5kIERhdGU6IDA0LUp1bC0xOQpJbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0 aW9uYWwKClN1bW1hcnk6CgpJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0aGlzIGRv Y3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9u LgoKQ29tbWVudHM6CgpJIGhhdmUgcmV2aWV3ZWQgdGhlIC0wMSB2ZXJzaW9uIG9mIHRoZSBkcmFm dCB0d28gYW5kIGEgaGFsZiB5ZWFycyBhZ28uIFNpbmNlIHRoZW4gdGhlIGRvY3VtZW50IGhhcyB1 bmRlcmdvbmUgbWFzc2l2ZSBjaGFuZ2VzLCBzbyB0aGF0IEkgZmVlbCB0aGF0IEkgaGF2ZSBiZWVu IHJldmlld2luZyBhIG5ldyBkb2N1bWVudC4KT25lIHRoaW5nIHRoYXQgcmVtYWluZWQgdW5jaGFu Z2VkLCBob3dldmVyLCB3YXMgdGhlIHJlYWRpbmVzcyBvZiB0aGUgYXV0aG9yIHRvIGNvb3BlcmF0 ZSB3aXRoIHRoZSByZXZpZXcuICBJIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyBteSBkZWVwIGdyYXRp dHVkZSB0byBKdWxpdXN6IGZvciB0aGF0LgoKVGhlIGRvY3VtZW50IGlzIHZlcnkgd2VsbCB3cml0 dGVuIGFuZCBtYXRjaGVzIG15IHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCBhbiBhcHBsaWNhYmlsaXR5 IHN0YXRlbWVudCBkcmFmdCBmb3IgYSByb3V0aW5nIHByb3RvY29sIHNob3VsZCBiZS4gSXQgaXMg bm90IG9ubHkgZWFzeSBidXQgYWxzbyBpbnRlcmVzdGluZyB0byByZWFkIChhdCBsZWFzdCBmb3Ig bWUpLgoKTW9zdCBvZiB0aGUgaXNzdWVzIEkgYW0gcmFpc2luZyBpbiB0aGlzIHJldmlldyBhcmUg aW4gdGhlIGdyYXkgYXJlYSBiZXR3ZWVuIOKAnG1pbm9y4oCdIGFuZCDigJxuaXTigJ0uIE15IGNs YXNzaWZpY2F0aW9uIGluIHRoaXMgcmV2aWV3IGlzLCB0aGVyZWZvcmUsIGFyYml0cmFyeSB0byBz b21lIGV4dGVudCwgYW5kIHNob3VsZCBiZSB0YWtlbiB3aXRoIGEgZ3JhaW4gb2Ygc2FsdC4KQW5k IGF0IGxlYXN0IHNvbWUgb2YgdGhlc2UgaXNzdWVzIHJlZmxlY3QgbXkgcGVyc29uYWwgY3VyaW9z aXR5LgoKTWFqb3IgSXNzdWVzOiBOb25lIGZvdW5kCgpNaW5vciBJc3N1ZXM6CgoKMS4gICAgICAg VGhlIHRleHQgaW4gU2VjdGlvbiAyLjMgc2F5czog4oCcaW4gb3JkZXIgdG8gY2hlY2sgdGhlIGlu dGVyb3BlcmFiaWxpdHkgb2YgdHdvIGltcGxlbWVudGF0aW9ucyBvZiBCYWJlbCwgaXQgaXMgZW5v dWdoIHRvIHZlcmlmeSB0aGF0IHRoZSBpbnRlcmFjdGlvbiBvZiB0aGUgdHdvIGRvZXMgbm90IHZp b2xhdGUgdGhlIHByb3RvY29sJ3MgYXNzdW1wdGlvbnMu4oCdCgphLiAgICAgICBUaGlzIGxvb2tl ZCBqdXN0IHdyb25nIHRvIG1lIOKAkyB0d28gaW1wbGVtZW50YXRpb25zIG1heSBwcmVzZXJ2ZSBh bGwgdGhlIHByb3RvY29sIGFzc3VtcHRpb25zIGJ1dCBmYWlsIGluIHRoZSBpbnRlcm9wZXJhYmls aXR5IHRlc3QsIGUuZy4sIGJlY2F1c2UgZW5jb2Rpbmcgb2Ygc29tZSBwYXJhbWV0ZXIgaW4gb25l IG9mIHRoZSBQRFVzIGlzIGRpZmZlcmVudAoKYi4gICAgICAgVGhlIGF1dGhvciBoYXMgY29uZmly bWVkIHRoYXQgdGhpcyB3YXMgYWN0dWFsbHkgYSB0eXBvLCBhbmQgaGFzIGFncmVlZCB0byByZW1v dmUgdGhpcyB0ZXh0CgpjLiAgICAgICBUaGlzIGlzIG9uZSBvZiB0aGUgY2FzZXMgd2hlcmUgIGl0 IGlzIGRpZmZpY3VsdCB0byBzYXkgd2hldGhlciB0aGlzIGlzIGEgbWlub3IgaXNzdWUgb3IgYSBu aXQKCjIuICAgICAgIFRoZSBleHBsYW5hdGlvbiBvZiB0aGUgQkFCRUwgYmFzZSBhc3N1bXB0aW9u cyBpbiBTZWN0aW9uIDIuMi4gaXMgdmVyeSB1c2VmdWwuIEhvd2V2ZXIsIGl0IGFzc3VtZXMgdGhh dCB0aGUgcmVhZGVyIGhhcyBhdCBsZWFzdCBzb21lIGludHVpdGl2ZSB1bmRlcnN0YW5kaW5nIG9m IHRoZSDigJxyb3V0aW5nIGFsZ2VicmHigJ0gbm90YXRpb25zLgoKYS4gICAgICAgRGlzY3Vzc2Vk IHRoaXMgcG9pbnQgd2l0aCB0aGUgYXV0aG9yCgpiLiAgICAgICBXZSBoYXZlIGFncmVlZCB0aGF0 IHRoZXJlIGlzIG5vIG5lZWQgdG8gbWFrZSB0aGlzIGRvY3VtZW50IGEgZGV0YWlsZWQgdHV0b3Jp YWwgb24gdGhlIHN1YmplY3QsIG5vciB0byBpbmR1bGdlIGluIEFTQ0lJIGFydCAodGhhdCB3b3Vs ZCBiZSBpbmRpY2F0aXZlIGF0IGJlc3QgaW4gYW55IGNhc2UpCgpjLiAgICAgICBTb21lIHNob3J0 IGV4cGxhbmF0aW9uLCBwb3NzaWJseSBhdWdtZW50ZWQgd2l0aCBJbmZvcm1hdGl2ZSByZWZlcmVu Y2VzIHRvIHRoZSByZWxldmFudCByZXNlYXJjaCBwYXBlcnMsIHdvdWxkIGJlIHN1ZmZpY2llbnQg SU1ITwoKMy4gICAgICAgVGhlIGRyYWZ0IG1lbnRpb25zIDQgaW5kZXBlbmRlbnQgaW1wbGVtZW50 YXRpb25zIG9mIEJBQkVMIGluIFNlY3Rpb24gMi4xLCBidXQgZG9lcyBub3Qgc2F5IGFueXRoaW5n IGFib3V0IHRoZWlyIGludGVyb3BlcmFiaWxpdHkuIFN1Y2ggaW5mb3JtYXRpb24sIGlmIGF2YWls YWJsZSwgc2hvdWxkIGJlIHZlcnkgdXNlZnVsIGZvciB0aGUgcmVhZGVycy4gKElmIG5vIHN1Y2gg aW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGFzIG9mIHRoaXMgbW9tZW50LCBJIHdvdWxkIGFjY2Vw dCB0aGlzKQoKNC4gICAgICAgVGhlIGNvbXBhcmlzb24gYmV0d2VlbiBCQUJFTCBhbmQgSVMtSVMv T1NQRiBpbiBTZWN0aW9uIDIuNC4xIGxhY2tzIGluZm9ybWF0aW9uIGFib3V0IHBvc3NpYmlsaXR5 IG9mIGZhc3QgbG9jYWwgcHJvdGVjdGlvbiBtZWNoYW5pc21zIChhLmsuYS4gSVAgRlJSLCBzZWUs IGUuZy4sIFJGQyA1Mjg2KQoKYS4gICAgICAgRGlzY3Vzc2VkIHRoaXMgcG9pbnQgd2l0aCB0aGUg YXV0aG9yIHNpbmNlIGZyb20gbXkgUE9WIHN1Y2ggaW5mb3JtYXRpb24gY291bGQgYmUgdmFsdWFi bGUgZm9yIHRoZSByZWFkZXJzIHRoYXQgY29uc2lkZXIgZGVwbG95aW5nIEJBQkVMIGluIHRoZWly IG5ldHdvcmtzCgpiLiAgICAgICBVbmZvcnR1bmF0ZWx5LCAgdGhlIGF1dGhvciBjb3VsZCBub3Qg cHJvdmlkZSBhbiBpbW1lZGlhdGUgYW5zd2VyIG9uZSB3YXkgb3IgYW5vdGhlcgoKNS4gICAgICAg TGFzdCBidXQgbm90IGxlYXN0LCBhIGZldyB3b3JkcyBhYm91dCBtYW5hZ2VhYmlsaXR5IG9mIEJB QkVMIHdvdWxkIGJlIHVzZWZ1bCBJTUhPLgoKTml0czoKCjEuICAgICAgIEkgZGlkIG5vdCBydW4g dGhlIG5pdHMgY2hlY2sgb24gdGhlIGRyYWZ0CgoyLiAgICAgICBJIHRoaW5rIHRoYXQgdGhlIHdv cmsg4oCcYXJndWXigJ0gIGluIHRoZSB0ZXh0IGluIFNlY3Rpb24gMSDigJx3ZSBhcmd1ZSB0aGF0 IHRoZXJlIGV4aXN0IG5pY2hlcyB3aGVyZSBCYWJlbCBpcyB1c2VmdWwgYW5kIHRoYXQgYXJlIG5v dCBhZGVxdWF0ZWx5IHNlcnZlZCBieSBtb3JlICBtYXR1cmUgcHJvdG9jb2xz4oCdIGlzIGJ5IGZh ciB0b28gd2VhayAob3IgdG9vIG1vZGVzdD8pLiBGcm9tIG15IFBPViB0aGUgZHJhZnQgZ29lcyBm YXIgYmV5b25kIGFyZ3VpbmcuCgphLiAgICAgICBEaXNjdXNzZWQgdGhpcyBwb2ludCB3aXRoIHRo ZSBhdXRob3IKCmIuICAgICAgIFRoZSBhdXRob3IgYWdyZWVzIHRvIGNoYW5nZSB0aGlzIHRleHQg dG8gYmUgbW9yZSBkZWZpbml0aXZlLAoKSG9wZWZ1bGx5IHRoZXNlIG5vdGVzIHdpbGwgYmUgdXNl ZnVsLgoKUmVnYXJkcywKU2FzaGEKCk9mZmljZTogKzk3Mi0zOTI2NjMwMgpDZWxsOiAgICAgICs5 NzItNTQ5MjY2MzAyCkVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tCgoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0 aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIApDT05G SURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyAKdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5m b3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdp bmFsIAphbmQgYWxsIGNvcGllcyB0aGVyZW9mLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K --_000_AM0PR03MB38283EF2B5AEB53E24AF190D9DFB0AM0PR03MB3828eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KQGZvbnQt ZmFjZQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwKCXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1z aXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOiMwNTYzQzE7 Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Izk1NEY3MjsKCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBk aXYuTXNvUGxhaW5UZXh0Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQgQ2hhciI7CgltYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJ Zm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aAoJe21zby1zdHlsZS1wcmlvcml0eTozNDsKCW1hcmdpbi10b3A6MGNtOwoJbWFyZ2luLXJpZ2h0 OjBjbTsKCW1hcmdpbi1ib3R0b206MGNtOwoJbWFyZ2luLWxlZnQ6MzYuMHB0OwoJbWFyZ2luLWJv dHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMAoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsKCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOwoJbWFy Z2luLXJpZ2h0OjBjbTsKCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOwoJbWFyZ2luLWxlZnQ6 MGNtOwoJZm9udC1zaXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30Kc3Bhbi5QbGFpblRleHRDaGFyCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hh ciI7Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9CnNwYW4uRW1haWxTdHlsZTIxCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOwoJY29sb3I6d2luZG93dGV4dDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7Cglmb250LXNpemU6MTAuMHB0OwoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQpAcGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsKCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQpkaXYuV29yZFNlY3Rpb24x Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQovKiBMaXN0IERlZmluaXRpb25zICovCkBsaXN0IGwwCgl7 bXNvLWxpc3QtaWQ6NjQ0MzEzOTE0OwoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MjA1MDY2MzY4MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGww OmxldmVsMQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwwOmxldmVsMgoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30K QGxpc3QgbDA6bGV2ZWwzCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMDpsZXZlbDQKCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwwOmxldmVsNgoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxp c3QgbDA6bGV2ZWw3Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWw4Cgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQpAbGlzdCBsMDpsZXZlbDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsKCXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0IGwxCgl7bXNvLWxpc3QtaWQ6NzY1MTU1 MzQ3OwoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTMxODYz MDk2MiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwxOmxldmVsMQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsMgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWwzCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4w cHQ7fQpAbGlzdCBsMTpsZXZlbDQKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTps ZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10 YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsNgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDE6bGV2ZWw3Cgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0 ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWw4Cgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZl bDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWIt c3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50 Oi05LjBwdDt9Cm9sCgl7bWFyZ2luLWJvdHRvbTowY207fQp1bAoJe21hcmdpbi1ib3R0b206MGNt O30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4K PC9oZWFkPgo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8 bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5n IERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3Rv cmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0 cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFu ZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LgogVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmll dyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigIto dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPG86cD48 L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3Ug Y291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBj b21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJv dWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcKIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPkRvY3VtZW50OiBkcmFmdC1pZXRmLWJhYmVsLWFwcGxpY2FiaWxpdHktMDY8bzpwPjwv bzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2aWV3ZXI6IEFsZXhhbmRlciAo4oCcU2Fz aGHigJ0pIFZhaW5zaHRlaW48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2 aWV3IERhdGU6IDAzLUp1bC0xOSA8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SUVURiBMQyBFbmQgRGF0ZTogMDQtSnVsLTE5PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbDxvOnA+PC9vOnA+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+U3VtbWFyeTwvYj46PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj5JIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91 dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1 YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Q29tbWVudHM8L2I+OjxiPjxv OnA+PC9vOnA+PC9iPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSByZXZpZXdlZCB0aGUgLTAxIHZlcnNpb24g b2YgdGhlIGRyYWZ0IHR3byBhbmQgYSBoYWxmIHllYXJzIGFnby4gU2luY2UgdGhlbiB0aGUgZG9j dW1lbnQgaGFzIHVuZGVyZ29uZSBtYXNzaXZlIGNoYW5nZXMsIHNvIHRoYXQgSSBmZWVsIHRoYXQg SSBoYXZlIGJlZW4gcmV2aWV3aW5nIGEgbmV3IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbmUgdGhpbmcgdGhhdCByZW1haW5lZCB1bmNoYW5nZWQsIGhvd2V2 ZXIsIHdhcyB0aGUgcmVhZGluZXNzIG9mIHRoZSBhdXRob3IgdG8gY29vcGVyYXRlIHdpdGggdGhl IHJldmlldy4mbmJzcDsgSSB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgbXkgZGVlcCBncmF0aXR1ZGUg dG8gSnVsaXVzeiBmb3IgdGhhdC4KPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1lbnQg aXMgdmVyeSB3ZWxsIHdyaXR0ZW4gYW5kIG1hdGNoZXMgbXkgdW5kZXJzdGFuZGluZyBvZiB3aGF0 IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGRyYWZ0IGZvciBhIHJvdXRpbmcgcHJvdG9jb2wg c2hvdWxkIGJlLiBJdCBpcyBub3Qgb25seSBlYXN5IGJ1dCBhbHNvIGludGVyZXN0aW5nIHRvIHJl YWQgKGF0IGxlYXN0IGZvciBtZSkuPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb3N0IG9mIHRoZSBp c3N1ZXMgSSBhbSByYWlzaW5nIGluIHRoaXMgcmV2aWV3IGFyZSBpbiB0aGUgZ3JheSBhcmVhIGJl dHdlZW4g4oCcbWlub3LigJ0gYW5kIOKAnG5pdOKAnS4gTXkgY2xhc3NpZmljYXRpb24gaW4gdGhp cyByZXZpZXcgaXMsIHRoZXJlZm9yZSwgYXJiaXRyYXJ5IHRvIHNvbWUgZXh0ZW50LCBhbmQgc2hv dWxkIGJlIHRha2VuIHdpdGggYSBncmFpbiBvZiBzYWx0LiZuYnNwOwo8bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGF0IGxlYXN0IHNvbWUgb2YgdGhlc2UgaXNzdWVzIHJl ZmxlY3QgbXkgcGVyc29uYWwgY3VyaW9zaXR5Lgo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPk1h am9yIElzc3VlczwvYj46IE5vbmUgZm91bmQ8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPk1pbm9y IElzc3VlczwvYj46PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5U aGUgdGV4dCBpbiBTZWN0aW9uIDIuMyBzYXlzOiDigJxpbiBvcmRlciB0byBjaGVjayB0aGUgaW50 ZXJvcGVyYWJpbGl0eSBvZiB0d28gaW1wbGVtZW50YXRpb25zIG9mIEJhYmVsLCBpdCBpcyBlbm91 Z2ggdG8gdmVyaWZ5IHRoYXQgdGhlIGludGVyYWN0aW9uIG9mIHRoZSB0d28gZG9lcyBub3Qgdmlv bGF0ZSB0aGUgcHJvdG9jb2wncyBhc3N1bXB0aW9ucy7igJ08bzpwPjwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+CjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5U aGlzIGxvb2tlZCBqdXN0IHdyb25nIHRvIG1lIOKAkyB0d28gaW1wbGVtZW50YXRpb25zIG1heSBw cmVzZXJ2ZSBhbGwgdGhlIHByb3RvY29sIGFzc3VtcHRpb25zIGJ1dCBmYWlsIGluIHRoZSBpbnRl cm9wZXJhYmlsaXR5IHRlc3QsIGUuZy4sIGJlY2F1c2UgZW5jb2Rpbmcgb2Ygc29tZSBwYXJhbWV0 ZXIgaW4gb25lIG9mIHRoZSBQRFVzIGlzIGRpZmZlcmVudDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRo ZSBhdXRob3IgaGFzIGNvbmZpcm1lZCB0aGF0IHRoaXMgd2FzIGFjdHVhbGx5IGEgdHlwbywgYW5k IGhhcyBhZ3JlZWQgdG8gcmVtb3ZlIHRoaXMgdGV4dDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yy48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRoaXMg aXMgb25lIG9mIHRoZSBjYXNlcyB3aGVyZSAmbmJzcDtpdCBpcyBkaWZmaWN1bHQgdG8gc2F5IHdo ZXRoZXIgdGhpcyBpcyBhIG1pbm9yIGlzc3VlIG9yIGEgbml0PG86cD48L286cD48L3A+CjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRoZSBleHBsYW5hdGlvbiBvZiB0 aGUgQkFCRUwgYmFzZSBhc3N1bXB0aW9ucyBpbiBTZWN0aW9uIDIuMi4gaXMgdmVyeSB1c2VmdWwu IEhvd2V2ZXIsIGl0IGFzc3VtZXMgdGhhdCB0aGUgcmVhZGVyIGhhcyBhdCBsZWFzdCBzb21lIGlu dHVpdGl2ZSB1bmRlcnN0YW5kaW5nIG9mIHRoZSDigJxyb3V0aW5nIGFsZ2VicmHigJ0gbm90YXRp b25zLgo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIg bGZvMiI+CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5EaXNjdXNzZWQgdGhpcyBwb2ludCB3aXRoIHRoZSBh dXRob3I8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIg bGZvMiI+CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5XZSBoYXZlIGFncmVlZCB0aGF0IHRoZXJlIGlzIG5v IG5lZWQgdG8gbWFrZSB0aGlzIGRvY3VtZW50IGEgZGV0YWlsZWQgdHV0b3JpYWwgb24gdGhlIHN1 YmplY3QsIG5vciB0byBpbmR1bGdlIGluIEFTQ0lJIGFydCAodGhhdCB3b3VsZCBiZSBpbmRpY2F0 aXZlIGF0IGJlc3QgaW4gYW55IGNhc2UpPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPgo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj5jLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+U29tZSBzaG9ydCBl eHBsYW5hdGlvbiwgcG9zc2libHkgYXVnbWVudGVkIHdpdGggSW5mb3JtYXRpdmUgcmVmZXJlbmNl cyB0byB0aGUgcmVsZXZhbnQgcmVzZWFyY2ggcGFwZXJzLCB3b3VsZCBiZSBzdWZmaWNpZW50IElN SE88bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3Nw YW4+VGhlIGRyYWZ0IG1lbnRpb25zIDQgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIG9mIEJB QkVMIGluIFNlY3Rpb24gMi4xLCBidXQgZG9lcyBub3Qgc2F5IGFueXRoaW5nIGFib3V0IHRoZWly IGludGVyb3BlcmFiaWxpdHkuIFN1Y2ggaW5mb3JtYXRpb24sIGlmIGF2YWlsYWJsZSwgc2hvdWxk IGJlIHZlcnkgdXNlZnVsIGZvciB0aGUgcmVhZGVycy4gKElmIG5vIHN1Y2gKIGluZm9ybWF0aW9u IGlzIGF2YWlsYWJsZSBhcyBvZiB0aGlzIG1vbWVudCwgSSB3b3VsZCBhY2NlcHQgdGhpcyk8bzpw PjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+VGhl IGNvbXBhcmlzb24gYmV0d2VlbiBCQUJFTCBhbmQgSVMtSVMvT1NQRiBpbiBTZWN0aW9uIDIuNC4x IGxhY2tzIGluZm9ybWF0aW9uIGFib3V0IHBvc3NpYmlsaXR5IG9mIGZhc3QgbG9jYWwgcHJvdGVj dGlvbiBtZWNoYW5pc21zIChhLmsuYS4gSVAgRlJSLCBzZWUsIGUuZy4sIFJGQyA1Mjg2KTxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4KPCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+YS48c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBk aXI9IkxUUiI+PC9zcGFuPkRpc2N1c3NlZCB0aGlzIHBvaW50IHdpdGggdGhlIGF1dGhvciBzaW5j ZSBmcm9tIG15IFBPViBzdWNoIGluZm9ybWF0aW9uIGNvdWxkIGJlIHZhbHVhYmxlIGZvciB0aGUg cmVhZGVycyB0aGF0IGNvbnNpZGVyIGRlcGxveWluZyBCQUJFTCBpbiB0aGVpciBuZXR3b3Jrczxv OnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBkaXI9IkxUUiI+PC9zcGFuPlVuZm9ydHVuYXRlbHksJm5ic3A7IHRoZSBhdXRob3IgY291bGQg bm90IHByb3ZpZGUgYW4gaW1tZWRpYXRlIGFuc3dlciBvbmUgd2F5IG9yIGFub3RoZXI8bzpwPjwv bzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj41LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+TGFzdCBi dXQgbm90IGxlYXN0LCBhIGZldyB3b3JkcyBhYm91dCBtYW5hZ2VhYmlsaXR5IG9mIEJBQkVMIHdv dWxkIGJlIHVzZWZ1bCBJTUhPLgo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPk5pdHM8L2I+Ojxv OnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5J IGRpZCBub3QgcnVuIHRoZSBuaXRzIGNoZWNrIG9uIHRoZSBkcmFmdDxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5JIHRoaW5rIHRoYXQgdGhl IHdvcmsg4oCcPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVs bG93Ij5hcmd1ZTwvc3Bhbj7igJ0mbmJzcDsgaW4gdGhlIHRleHQgaW4gU2VjdGlvbiAxIOKAnHdl CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+YXJn dWU8L3NwYW4+IHRoYXQgdGhlcmUgZXhpc3QgbmljaGVzIHdoZXJlIEJhYmVsIGlzIHVzZWZ1bCBh bmQgdGhhdCBhcmUgbm90IGFkZXF1YXRlbHkgc2VydmVkIGJ5IG1vcmUmbmJzcDsgbWF0dXJlIHBy b3RvY29sc+KAnSBpcyBieSBmYXIgdG9vIHdlYWsgKG9yIHRvbyBtb2Rlc3Q/KS4gRnJvbSBteSBQ T1YgdGhlIGRyYWZ0IGdvZXMgZmFyIGJleW9uZCBhcmd1aW5nLgo8bzpwPjwvbzpwPjwvcD4KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvNCI+CjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bh bj5EaXNjdXNzZWQgdGhpcyBwb2ludCB3aXRoIHRoZSBhdXRob3I8bzpwPjwvbzpwPjwvcD4KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvNCI+CjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bh bj5UaGUgYXV0aG9yIGFncmVlcyB0byBjaGFuZ2UgdGhpcyB0ZXh0IHRvIGJlIG1vcmUgZGVmaW5p dGl2ZSw8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvcGVmdWxseSB0aGVzZSBub3RlcyB3aWxsIGJl IHVzZWZ1bC48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNhc2hhPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZmZpY2U6ICYj NDM7OTcyLTM5MjY2MzAyPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNlbGw6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbWFpbDombmJzcDsmbmJzcDsgQWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8YnIgY2xlYXI9ImJvdGgiPgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+CjxCUj4KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3Ig dGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyA8QlI+ CkNPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29t LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIDxCUj4KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBw bGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUg dGhlIG9yaWdpbmFsIDxCUj4KYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi48QlI+Cl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxCUj4KPC9ib2R5Pgo8L2h0bWw+Cgo= --_000_AM0PR03MB38283EF2B5AEB53E24AF190D9DFB0AM0PR03MB3828eurp_-- From nobody Fri Jul 5 05:49:54 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26359120094; Fri, 5 Jul 2019 05:49:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Min Ye via Datatracker To: Cc: draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Min Ye Message-ID: <156233097510.22018.7107165165922007078@ietfa.amsl.com> Date: Fri, 05 Jul 2019 05:49:35 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-babel-dtls-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 12:49:35 -0000 Reviewer: Henning Rogge Review result: Has Issues //resend to RTG DIR list Hi, I was asked by the Routing Directorate to do a last call review of draft-ietf-babel-dtls-06. I like that the draft is quite short, which is a good thing for a security draft. I have found a few question you can consider to address in the final document. Chapter 2.3: I wonder if using DTLS protected unicast Hellos should be mandatory... using unprotected multicast to determine bidirectional reachability looks like a good way to do a cheap denial of service attack. Chapter 2.5: What happens when a node starts a new DTLS connection and there is already one in the neighbor table? This could both be an attempt to attack Babel, a reboot of a node or just a matter of misconfiguration of two nodes. Chapter 3: Different pairs of nodes could select different ciphers, resulting in different MTUs. I assume this is no problem for Babel (could be mentioned in the chapter). Some of the design decisions of regarding the three questions could be mentioned in chapter 5 (Security Implications). Henning Rogge From nobody Sun Jul 7 00:35:54 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3873C12002E; Sun, 7 Jul 2019 00:35:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 vJ7a7-hZVv1R; Sun, 7 Jul 2019 00:35:42 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 6B7751200B6; Sun, 7 Jul 2019 00:35:42 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id d15so10959969qkl.4; Sun, 07 Jul 2019 00:35:42 -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=ZKcKaOIFsOunQKVlcxBeXSubk4xgJohx1OjOYIFscmo=; b=OufLWahi5LWngwJhmT4W9FHubRjN5Oi6HdZbFG4XPI9UMuv+Ru45X8Djcqr+JKAlkb bN2ItxAZi1cz/xlnlcF7GDln45g/puXfgaillcLLRKLwfEiiErAUwqlchs9pCgjt+WCc pD4tgaVkkF7rgoSIur6ELuKkZzUyBHZK8COkPolVCCDkgP3pLTnpqWCtp29t55sZtiiq ijt19+SRR9t77KG/EKfG8EILmiysYgWkyyIPGZE6XSLOOzZyhLoJed4IZAS5nUEgTY11 paza2ZQG2dBqzSr/7imQBQX91ZfiRYDRd/94XfN+5G9FJdSSzOvjvltDUxe58WObmK8O uQIQ== 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=ZKcKaOIFsOunQKVlcxBeXSubk4xgJohx1OjOYIFscmo=; b=adHJtZBogwjL/Qju0YcXBHH2aMqpYRPUZjhGoV/we/Bbmt8IPPiYaJAxnqD9MRICda bSdOT54JryunKXk+W6X1Jk+vcx5OlwiMEamTo2M/26j+CCrfQlv6wU/RnMlTE8XTUzi2 H3M/i7I15evkzSxUItjWAc9ZAkhK89Jx56cWio35cbeyWauhQHSMtFTbgtaAaH6L88sn tBSvWnLwZ+2/UvTaYrSvMLr5vxLO2xeSSkPyZSoKt57pxVSyUZmRNUPcYFooudaeE6oh haNmghxcQSj/r5H81Abhdi+0sin3Jspv/wGkT4TZk9b7b/rsznC18snO4F29nevTbKQy Nsgw== X-Gm-Message-State: APjAAAWnwjXATwXtuW3LTHcIk+05+17UYXnAG/qqPPg6XCf+Y6gkXuCa h9Yhvg8Jho9GFR9K4eiOIiYfTAwdZSQvrcUkyBoc8682Cm4= X-Google-Smtp-Source: APXvYqyFttwCvQO+m+8P27Xk2jlpZ1uCAtFDSz3S+gbHLmT5Z9o00DNkPZFL8pNkJ/oXagHNql5Z26/5/04RKuCnSBQ= X-Received: by 2002:a37:c45:: with SMTP id 66mr9337529qkm.31.1562484941389; Sun, 07 Jul 2019 00:35:41 -0700 (PDT) MIME-Version: 1.0 From: Tal Mizrahi Date: Sun, 7 Jul 2019 10:35:29 +0300 Message-ID: To: draft-ietf-pce-stateful-hpce@ietf.org, rtg-ads@ietf.org, rtg-dir@ietf.org Cc: pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000e6026e058d125fce" Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-hpce X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 07:35:44 -0000 --000000000000e6026e058d125fce Content-Type: text/plain; charset="UTF-8" Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pce-stateful-hpce Reviewer: Tal Mizrahi Review Date: July, 2019 Intended Status: Informational Summary: No issues found. This document is ready for publication. Nits: -Section 1.1. is the only subsection of Section 1. Please consider adding a subsection "Background" that will consist of the text before the current 1.1. -"(previously computed paths" - there is no matching ")" -Section 6.3 - please consider if this should be moved to the security considerations section, or add a reference from the security considerations section to this one. Best regards, Tal. --000000000000e6026e058d125fce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I have been selected as the Routing Director= ate reviewer for this draft. The Routing Directorate seeks to review all ro= uting or routing-related drafts as they pass through IETF last call and IES= G review, and sometimes on special request. The purpose of the review is to= provide assistance to the Routing ADs. For more information about the Rout= ing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<= br>
Although these comments are primarily for the use of the Routing ADs= , it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through dis= cussion or by updating the draft.

Document: draft-ietf-pce-stateful-= hpce
Reviewer: Tal Mizrahi
Review Date: July, 2019
Intended Status= : Informational

Summary:
No issues found. This document is ready= for publication.

Nits:
-Section 1.1. is the only subsection of S= ection 1. Please consider adding a subsection "Background" that w= ill consist of the text before the current 1.1.
-"(previously compu= ted paths" - there is no matching ")"
-Section 6.3 - plea= se consider if this should be moved to the security considerations section,= or add a reference from the security considerations section to this one.

Best regards,
Tal.
--000000000000e6026e058d125fce-- From nobody Sun Jul 7 07:31:49 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4612003E; Sun, 7 Jul 2019 07:31:41 -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, SPF_HELO_NONE=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 BEXSHnGLIy2F; Sun, 7 Jul 2019 07:31:40 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 B2006120048; Sun, 7 Jul 2019 07:31:39 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67EVYSa000749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 Jul 2019 16:31:34 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x67EVY4X024514; Sun, 7 Jul 2019 16:31:34 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 144046FA51; Sun, 7 Jul 2019 16:31:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3SeBjQOAMoKi; Sun, 7 Jul 2019 16:31:35 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A9F686FA4E; Sun, 7 Jul 2019 16:31:34 +0200 (CEST) Date: Sun, 07 Jul 2019 16:31:34 +0200 Message-ID: <877e8tx6ex.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alexander Vainshtein Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-babel-applicability.all@ietf.org" , "babel@ietf.org" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 07 Jul 2019 16:31:34 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 07 Jul 2019 16:31:35 +0200 (CEST) X-Miltered: at korolev with ID 5D220246.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D220246.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D220246.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D220246.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D220246.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D220246.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-babel-applicability-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:31:42 -0000 Dear Sasha, Thank you very much for your review, which has helped me improve the document. > 1. The text in Section 2.3 says: “in order to check the interoperability > of two implementations of Babel, it is enough to verify that the interaction of > the two does not violate the protocol's assumptions.” This has been fixed. > 2. The explanation of the BABEL base assumptions in Section 2.2. is very > useful. However, it assumes that the reader has at least some intuitive > understanding of the “routing algebra” notations. This has been expanded with human-readable comments, and I've added a reference to my favourite paper on the subject (Griffin and Sobrinho, "Metarouting"). > 3. The draft mentions 4 independent implementations of BABEL in Section > 2.1, but does not say anything about their interoperability. Such information, > if available, should be very useful for the readers. (If no such information is > available as of this moment, I would accept this) I have simply added the word "interoperable" to the sentence, which reflects what the authors of the implementations have reported to me. > 4. The comparison between BABEL and IS-IS/OSPF in Section 2.4.1 lacks > information about possibility of fast local protection mechanisms (a.k.a. IP > FRR, see, e.g., RFC 5286) This is an interesting question, and I need to go educate myself on the subject. I didn't add anything on this subject. > 1. I did not run the nits check on the draft I have. > 2. I think that the work “argue” in the text in Section 1 “we argue that > there exist niches where Babel is useful and that are not adequately served by > more mature protocols” is by far too weak (or too modest?). From my POV the > draft goes far beyond arguing. We now *describe* a few niches that are *arguably* not adequately served. Thanks again, -- Juliusz From nobody Sun Jul 7 07:39:02 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF0C120058; Sun, 7 Jul 2019 07:38:52 -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, SPF_HELO_NONE=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 DIfkftXXa4Lb; Sun, 7 Jul 2019 07:38:51 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 5564A12001E; Sun, 7 Jul 2019 07:38:51 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67Eckp9003130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 Jul 2019 16:38:46 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x67Eck9Y026261; Sun, 7 Jul 2019 16:38:47 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 39BDF6FADB; Sun, 7 Jul 2019 16:38:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 1uY5Wb71rl2Z; Sun, 7 Jul 2019 16:38:48 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3B4A86FAD9; Sun, 7 Jul 2019 16:38:48 +0200 (CEST) Date: Sun, 07 Jul 2019 16:38:48 +0200 Message-ID: <875zodx62v.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mike McBride Cc: , draft-ietf-babel-hmac.all@ietf.org, babel@ietf.org In-Reply-To: <156210426145.23799.16215559699319611305@ietfa.amsl.com> References: <156210426145.23799.16215559699319611305@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 07 Jul 2019 16:38:46 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 07 Jul 2019 16:38:47 +0200 (CEST) X-Miltered: at korolev with ID 5D2203F6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D2203F6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D2203F6.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D2203F6.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D2203F6.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D2203F6.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-babel-hmac-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:38:53 -0000 Dear Mike, I do not recall whether I've already replied to your review, sorry if this is a duplicate. > I still think a terminology section would be helpful in this, and most, > ietf drafts but the authors did a good job of defining acronyms > throughout the draft. There are two common styles -- define each term on first use, or provide a terminology section. I happen to prefer the former style, you obviously prefer the latter. With your kind permission, I am going to stick to my preferred style, and therefore not follow your advice. Thanks, -- Juliusz From nobody Sun Jul 7 07:48:49 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1612001E; Sun, 7 Jul 2019 07:48:40 -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, SPF_HELO_NONE=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 0U0j-RvqEHAj; Sun, 7 Jul 2019 07:48:39 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 B382F120048; Sun, 7 Jul 2019 07:48:38 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x67EmXfU005852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 7 Jul 2019 16:48:33 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x67EmXGs028162; Sun, 7 Jul 2019 16:48:33 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2323C6FB27; Sun, 7 Jul 2019 16:48:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id W7tGCly8L7tn; Sun, 7 Jul 2019 16:48:34 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C87FF6FB25; Sun, 7 Jul 2019 16:48:34 +0200 (CEST) Date: Sun, 07 Jul 2019 16:48:34 +0200 Message-ID: <8736jhx5ml.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alexander Vainshtein Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-babel-applicability.all@ietf.org" , "babel@ietf.org" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 07 Jul 2019 16:48:33 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 07 Jul 2019 16:48:33 +0200 (CEST) X-Miltered: at korolev with ID 5D220641.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D220641.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D220641.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D220641.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D220641.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D220641.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-babel-applicability-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:48:41 -0000 I forgot one of your points. > 5. Last but not least, a few words about manageability of BABEL would be > useful IMHO. People are working hard on monitoring and manageability: - Barbara Stark and Mahesh Jethanandani are working on manageability within the IETF framework; - Nexedi are working on dynamic reconfiguration of interfaces by an external cross-layer (2->3) monitoring agent; - a number of people are working on monitoring, both by a human operator and by an external software agent: https://github.com/kerneis/babelweb https://github.com/Vivena/babelweb2 https://github.com/tcatm/mmfd However, none of this work is finished yet, and, given the wide range of application domains of Babel, I do not feel comfortable to give any definite advice about management. I have therefore decided not to say anything in this document. -- Juliusz From nobody Sun Jul 7 07:52:32 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C891120058; Sun, 7 Jul 2019 07:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 u-_ExgRFPnvo; Sun, 7 Jul 2019 07:52:19 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.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 A9B2F12001E; Sun, 7 Jul 2019 07:52:18 -0700 (PDT) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-a.eu-central-1.aws.symcld.net id F1/2E-10067-E17022D5; Sun, 07 Jul 2019 14:52:14 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEJsWRWlGSWpSXmKPExsUi9LZng64cu1K sQddLVovNHRvYLLYs6maxOPnf2WJ+6zI2i5NzfjBbLFjzlN2BzaPlyFtWjyVLfjJ5LN7yljGA OYo1My8pvyKBNWPy4mPsBcv5Kt7u6mBvYHzF3cXIxcEisJZZYuPmnYwgjpBAP5PE9OcX2CCcO 4wSrz7eAHI4OdgEbCU2rb4LZosIqEgsn/aMHaSIWeATo8SPvxvZQRLCQEWPr+5mgSiyk1i08C 4ThG0l8fzDPLA4C1Dzj+8djCA2r0CsxJaDLWBDhQSqJCZPnwlWzymgIfHi3nywGkYBMYnvp9a AxZkFxCVuPZkPZksICEgs2XOeGcIWlXj5+B8rRH2SxP2nCxkh4ooSM+7NYYewZSUuze+GivtK 3FvWA2RzANnKEltexIL8IiHwmFHiY8tKqJlaEmfv7IaypSQWnv8CNSdH4s16iF8kBNQktl87D 3WPjMS2Lx/YIAbNY5N4/amFHeKxZIkTcz5DNchJrOp9yAJRdIFZ4tG+H0wTGHVnIXkOwtaRWL D7ExuErS2xbOFr5lngABOUODnzCcsCRpZVjBZJRZnpGSW5iZk5uoYGBrqGhsa6RrqmxnqJVbq JeqmlusmpeSVFiUBJvcTyYr3iytzknBS9vNSSTYzAJJVSyGS6g7F31hu9Q4ySHExKorwhqfKx QnxJ+SmVGYnFGfFFpTmpxYcYZTg4lCR4c1mVYoUEi1LTUyvSMnOACRMmLcHBoyTCKwuS5i0uS MwtzkyHSJ1itOSY8HLuImaOn7eXAMnmO0BSiCUvPy9VSpw3HKRBAKQhozQPbhwsqV9ilJUS5m VkYGAQ4ilILcrNLEGVf8UozsGoJMybCTKFJzOvBG7rK6CDmIAOmpkiB3JQSSJCSqqBKfvV9T0 GP0UaDizZwWmjaHzvVPcW671X1hm5HXBke/T6C7ds2cp/d360bPK0OmbM6l7945FDQcnuW784 pRue7F90OeYlg9TTC/1a3DYqRT9CT/6ouTkr3ya09h5n0+aMb/kZi5UeKMaLV/9R8fzixvKie eXuor51jpdyumWWXDyz3We/GWP7RI3K7X7dj+rUH+w8/e90A3d4/mfhuNSPYZNFowr/tvLYpM 5sdvWObPhtOYdvb2K6waardRHFh5vLnuS9FPmx0ezP310eH1r27Pwx/9mUqCIv5pTM9xe/nOX 1SN54PGrjlMmTV6muOjs1bnMXL9uCTQ67I925+jW32jzqW22XuDe966NeQUrKHCWW4oxEQy3m ouJEADX9DBNlBAAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-31.tower-226.messagelabs.com!1562511131!114094!1 X-Originating-IP: [18.237.140.176] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.43.9; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 9794 invoked from network); 7 Jul 2019 14:52:13 -0000 Received: from ec2-18-237-140-176.us-west-2.compute.amazonaws.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.176) by server-31.tower-226.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 7 Jul 2019 14:52:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xpWO+x1q+LapCHzw8+mqrXqS157KaoJIYE2yi8vpaho=; b=WRpnf20aePKCwztk+cjZKYcGYJqxVJZrjg/kKmG4vOWQJB0wmvjc9gtlw5td9O+fbOshETg7rNgLSUlH8S4Ys9xRyg4IXM83sIVkAhY+bzHKDNzI6cumxXN3KbRXMUuk0OjC+xJ61HIpP2VXCiJEdlrkUoBzq9jX7f+C/sy5Lns= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB5825.eurprd03.prod.outlook.com (10.255.28.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Sun, 7 Jul 2019 14:52:09 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::29f2:7c6:37cb:8ea7]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::29f2:7c6:37cb:8ea7%3]) with mapi id 15.20.2052.019; Sun, 7 Jul 2019 14:52:09 +0000 From: Alexander Vainshtein To: Juliusz Chroboczek CC: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-babel-applicability.all@ietf.org" , "babel@ietf.org" , Min Ye Thread-Topic: RtgDir review: draft-ietf-babel-applicability-06 Thread-Index: AdUvH5YiygIfUsyWQTGhUP+K9gfY2QFs3b4AAAAHhHA= Date: Sun, 7 Jul 2019 14:52:08 +0000 Message-ID: References: <8736jhx5ml.wl-jch@irif.fr> In-Reply-To: <8736jhx5ml.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a8a2e8b1-30af-4482-1886-08d702eaafc8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB5825; x-ms-traffictypediagnostic: AM0PR03MB5825: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(376002)(136003)(346002)(189003)(199004)(13464003)(186003)(25786009)(53936002)(14454004)(486006)(66066001)(7736002)(72206003)(55016002)(6916009)(26005)(86362001)(476003)(11346002)(305945005)(4326008)(478600001)(8936002)(8676002)(229853002)(9686003)(413944005)(966005)(6306002)(74316002)(316002)(54906003)(71190400001)(33656002)(2906002)(71200400001)(256004)(6436002)(81156014)(66476007)(5660300002)(6116002)(6506007)(3846002)(76116006)(52536014)(102836004)(53546011)(7696005)(64756008)(73956011)(99286004)(81166006)(68736007)(66556008)(66446008)(446003)(6246003)(66946007)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB5825; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2V5OqYRk5/Ai9/zehMX4H594E9xVh688ce9kS6KNzYqTLg4WgL7r7d2INs+p+WlyPpWPudOpp/1BAzZbhYz7uGl7zjx0zee8Bfm3lAYH0EJIOveX6wtgdFvbxZZOJK6t/t/HtIIBLfhj/ZDePeO1bBL6hseJLu8bmKqzQ4K1pT+jQXXwHPdnGk11xPOlXwFDAOnU8vbQL0HRKEpBtTyylc56qzVVS5v9K+YcRN1xFKL4GC7qX5cOlG8DRhofC7mjt3Nbvbk4cb2Z+pIZo021cYZOkQpnF+xy94v8zE8xVh5nPqj9KCjt/JvjOgTwxoOwZ0+qGhjWNpwzKJis60ckuCobT7tLQE3+GifzvowNyRcM+BmgaXpD+fZjet7/oqtSMSVq9NSnuYDD+ZZowEeuFBgz38vJccOFiaA+CPIEEpE= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: a8a2e8b1-30af-4482-1886-08d702eaafc8 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2019 14:52:09.0174 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5825 X-CFilter-Loop: Reflected X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-babel-applicability-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 14:52:22 -0000 Dear Juliusz, Lots of thanks for addressing my review comments so quickly. I have looked up the -07 version and it addresses my review comments to th= e maximum possible extent. In particular, I accept the fact that my question about fast local protect= ion with BABEL cannot be answered without additional investigation: such i= nvestigation is clearly not part of the applicability draft. And I also accept the fact that management aspects of BABEL are still work= in progress. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Juliusz Chroboczek =20 Sent: Sunday, July 7, 2019 5:49 PM To: Alexander Vainshtein Cc: rtg-ads@ietf.org; rtg-dir@ietf.org; draft-ietf-babel-applicability.all= @ietf.org; babel@ietf.org Subject: Re: RtgDir review: draft-ietf-babel-applicability-06 I forgot one of your points. > 5. Last but not least, a few words about manageability of BABEL wo= uld be > useful IMHO.=20 People are working hard on monitoring and manageability: - Barbara Stark and Mahesh Jethanandani are working on manageability within the IETF framework; - Nexedi are working on dynamic reconfiguration of interfaces by an external cross-layer (2->3) monitoring agent; - a number of people are working on monitoring, both by a human operator= and by an external software agent: https://github.com/kerneis/babelweb https://github.com/Vivena/babelweb2 https://github.com/tcatm/mmfd However, none of this work is finished yet, and, given the wide range of a= pplication domains of Babel, I do not feel comfortable to give any definit= e advice about management. I have therefore decided not to say anything i= n this document. -- Juliusz __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Sun Jul 7 20:56:16 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3691200D6; Sun, 7 Jul 2019 20:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 sPZT1fdYdGLt; Sun, 7 Jul 2019 20:56:12 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 7DC1F1200F7; Sun, 7 Jul 2019 20:56:12 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id u19so31957376ior.9; Sun, 07 Jul 2019 20:56:12 -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:content-transfer-encoding; bh=aUMDbXtOn1GCLZbh9xESV/MCTrRJt1EzC+k547/Ca24=; b=D8mkxgOpe8bxw9uLJ1DxpINxuwlbRi80v6MAvEclDz143uiVQs3gxorqwiNo4sdai5 S7sn8t4bLd5gnuoE9E5Ujq/KoNnrh5qSJaBlEzyEvyHZ9+nS2HtQHdiRDSz0ENC96wC5 grkoqtsJsMfBPddSRPm0zXdFd9VZh1gIMP460aNBH6z4DUNpkwzVLAiYV/rAjka0yo+Z EP0HilAw9jMZv2bOj+Nf3U/iaZx45TGW6uiMHIB4/NGcmEAdmSkb6lr5eGnI+1XO+S9m uoqIESJs38ckqKYhwP/TPT7yCC8c/ocofNjKlayP8jTqKrZvul7gQ6pL3lFuRwxdoWDb YPgg== 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:content-transfer-encoding; bh=aUMDbXtOn1GCLZbh9xESV/MCTrRJt1EzC+k547/Ca24=; b=OFxqbBP3Pu1OnM0ejKt8jBSyPcaXeyx2EEHr2+xPUVl5MH/ElMvvo7k7UJmd2+PU/P 3JQ2i0enIosi78iyI1Es7+fjaaERIpFlCd1pE7IE5aIVFqS69OWWPZM7wvpkk9NTkiH/ 5nDmLbUAj3H3LeGfGBmbxYcoXAE9BSYD5ofmYmBDo3iiOsqSbJEjOcsbLK2Wul2tk0qi CGbtQMQacBCVkxq2N1zxFhyh9iquXciqnPdJNVoK//O+ZsjvpVuP5gsY7Yctf6KZvg8u UbgnPG+bWCqrVHqnHJNfIOzo5AAifuWgA+IgILtky+hZV5q+XyLtqCfRyBP+pN/n8wax MCug== X-Gm-Message-State: APjAAAXMmftFdSsgdkH+o3F8L30PZi09A/ZEG3LKZSxhNJMptMk1sfbo e+1/89K7PWSEwzi60092KO5Au2YK1o32a21kT5U= X-Google-Smtp-Source: APXvYqwX/3GeG4gdtNOvOGFb1PM5Xd4cH0P2Fpq2bz+qTs+WvcQQHNx4AaCEP4c1lzH2i/mtejNLYX1XU3N0hXbi3U8= X-Received: by 2002:a6b:c98c:: with SMTP id z134mr12054498iof.276.1562558171499; Sun, 07 Jul 2019 20:56:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Mon, 8 Jul 2019 09:25:35 +0530 Message-ID: To: Tal Mizrahi Cc: draft-ietf-pce-stateful-hpce@ietf.org, "" , rtg-dir@ietf.org, pce@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-hpce X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 03:56:14 -0000 Hi Tal, Thanks for your review. I have made an update handling the nits. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-stateful-hpce-11 Thanks! Dhruv On Sun, Jul 7, 2019 at 1:05 PM Tal Mizrahi wrot= e: > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Ro= uting ADs. For more information about the Routing Directorate, please see h= ttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF Last = Call comments that you receive, and strive to resolve them through discussi= on or by updating the draft. > > Document: draft-ietf-pce-stateful-hpce > Reviewer: Tal Mizrahi > Review Date: July, 2019 > Intended Status: Informational > > Summary: > No issues found. This document is ready for publication. > > Nits: > -Section 1.1. is the only subsection of Section 1. Please consider adding= a subsection "Background" that will consist of the text before the current= 1.1. > -"(previously computed paths" - there is no matching ")" > -Section 6.3 - please consider if this should be moved to the security co= nsiderations section, or add a reference from the security considerations s= ection to this one. > > Best regards, > Tal. From nobody Mon Jul 8 03:52:38 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFEF12014F for ; Mon, 8 Jul 2019 03:52:36 -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, DKIMWL_WL_HIGH=-0.001, 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 (1024-bit key) header.d=ericsson.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 Nal90lFi8y9W for ; Mon, 8 Jul 2019 03:52:33 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760047.outbound.protection.outlook.com [40.107.76.47]) (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 45AB0120157 for ; Mon, 8 Jul 2019 03:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D6L5E2U6NtBJl1UAYZ5iB3Iol4HwAXMwtMol3zCDFz0=; b=Ol1kinkIx7yJBy+bxxXcCJRi64IWa/aAIhYoIF+HZ/D4sM4VSUBPYDYtXruiZDtBnbdCVhQ+o9ny0ss3PlPBbfMo2OaepBeJERWfFsu9kFXRIgK24jTed4XieWWiLwQVm/9hxyGQ7LQu5nVk3S3y7DLVouZvvaAmy20f0HqDYoo= Received: from BN8PR15MB2644.namprd15.prod.outlook.com (20.179.138.27) by BN8PR15MB2580.namprd15.prod.outlook.com (20.179.137.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Mon, 8 Jul 2019 10:52:30 +0000 Received: from BN8PR15MB2644.namprd15.prod.outlook.com ([fe80::155b:861f:389b:3434]) by BN8PR15MB2644.namprd15.prod.outlook.com ([fe80::155b:861f:389b:3434%7]) with mapi id 15.20.2052.020; Mon, 8 Jul 2019 10:52:29 +0000 From: Eric Gray To: "rtg-dir@ietf.org" CC: "Yemin (Amy)" Thread-Topic: Last Call Review of draft-ietf-roll-efficient-npdao Thread-Index: AdUsWXgVYOX7Pfh+Snm71nZC5c50NwASRBbwAjYOxNA= Date: Mon, 8 Jul 2019 10:52:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eric.gray@ericsson.com; x-originating-ip: [2601:85:4680:3329:311c:1753:1012:51d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45a8bd85-cde0-4067-7a96-08d703925f91 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN8PR15MB2580; x-ms-traffictypediagnostic: BN8PR15MB2580: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(39850400004)(366004)(136003)(396003)(189003)(199004)(6116002)(790700001)(81156014)(81166006)(316002)(74316002)(11346002)(2906002)(6916009)(8936002)(8676002)(76116006)(476003)(73956011)(52536014)(66556008)(44832011)(66946007)(54896002)(64756008)(66446008)(66476007)(76176011)(186003)(46003)(7736002)(2351001)(6506007)(53546011)(256004)(86362001)(5660300002)(102836004)(7696005)(486006)(14444005)(25786009)(53936002)(606006)(68736007)(71200400001)(71190400001)(2501003)(966005)(55016002)(6436002)(5640700003)(9686003)(6306002)(2473003)(236005)(446003)(33656002)(14454004)(4326008)(478600001)(99286004)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB2580; H:BN8PR15MB2644.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uRM8No4l1tO2eH+PNxTDFfNDh4m59G3tsCG+quw/X+hcqIpradwcqxMMDVqBQJspggYFKEMawBXUXmw3JeBazJuPkeTOEGxFoqnsRaqAV1TdvF3pbfOOvPM2ToyY/M+rWOx/mL0fe5bdR1MeuOiCtH1kUdTesM85IZbknuVDccevqN7NUCG9biw1xA9oiG+3rNcH2ncCL+ma3CgRCMaui+AV1Qiibnc2sn+Hweuyl2P5K4rXh2J5DLLZSBtj9nwfqdvr/0i4Z65NB9pdBO1U5TXVCygJXnrtnWD9pfEWNiPGCnPk2EZJq8BigGVoenhgmy6vE0zRnt6hgdLDMpcim1C/GRI4vKXkxMktP88YT2dT3ZHoGgVU47pNGV+XsjQnTwhKSk8WUcfpbphfhomQKkNMREG5szclD0BaveplS3E= Content-Type: multipart/alternative; boundary="_000_BN8PR15MB26442BDB30FBB0C4DF23C9C997F60BN8PR15MB2644namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45a8bd85-cde0-4067-7a96-08d703925f91 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 10:52:29.7583 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eric.gray@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2580 Archived-At: Subject: [RTG-DIR] FW: Last Call Review of draft-ietf-roll-efficient-npdao X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 10:52:37 -0000 --_000_BN8PR15MB26442BDB30FBB0C4DF23C9C997F60BN8PR15MB2644namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW15IHBvaW50ZWQgb3V0IHRoYXQgSSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGUgUlRHLURpciBtYWls aW5nIGxpc3QgaW4gdGhpcy4NCg0KSSBnb3QgYSByZXBseSBmcm9tIEFsdmFybywgYW5kIEkgaGFk IGluY2x1ZGVkIHRoZSBST0xMIG1haWxpbmcgbGlzdC4NCg0KSSBhbHNvIHNlbnQgYSBmb2xsb3ct dXAgY29ycmVjdGlvbiBhcyBJIGhhZCBnb3R0ZW4gcGFzdGUgYWxsIG92ZXIgbXlzZWxmLg0KDQot LQ0KRXJpYw0KDQpGcm9tOiBFcmljIEdyYXkNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI3LCAyMDE5 IDEyOjQxIEFNDQpUbzogZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhb0BpZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhb0BpZXRmLm9yZz4NCkNjOiBBbHZh cm8gUmV0YW5hIChhcmV0YW5hKSA8YXJldGFuYUBjaXNjby5jb208bWFpbHRvOmFyZXRhbmFAY2lz Y28uY29tPj47IHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBM YXN0IENhbGwgUmV2aWV3IG9mIGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBkYW8NCg0KSSBo YXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwg cm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElF VEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJl cXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNl IHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRp bmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJl YS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJp bWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1 bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExh c3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUg dGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1 bWVudDogZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbw0KUmV2aWV3ZXI6IEVyaWMgR3Jh eQ0KUmV2aWV3IERhdGU6IDI2IEp1bmUgMjAxOQ0KSUVURiBMQyBFbmQgRGF0ZTogMjYgSnVuZSAy MDE5DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KUGVyaGFw cyBJIGFtIG1pc3Npbmcgc29tZSBzdWJ0bGV0aWVzLCBidXQgdGhpcyBkb2N1bWVudCBsb29rcyBs aWtlIGl0IG1heSBuZWVkIGEgbGl0dGxlIG1vcmUgd29yayBiZWZvcmUgaXQgaXMgcHVibGlzaGVk Lg0KDQpPdmVyYWxsIGNvbW1lbnRzOg0KVGhlIGRvY3VtZW50IGlzIG1vc3RseSB3ZWxsIHdyaXR0 ZW4uDQoNCklzc3VlczoNCg0KSW4gdGhlIGludHJvZHVjdGlvbiwgSSBoYXZlIHNvbWUgdHJvdWJs ZSBwYXJzaW5nIOKAnGFuIG9wdGlvbmFsIG1lc3NhZ2luZ+KAnSDigJMgcGVyaGFwcyBpdCB3YXMg bWVhbnQgdG8ganVzdCBiZSDigJxvcHRpb25hbCBtZXNzYWdpbmc/4oCdDQoNClRoZXJlIGFyZSBk aWZmZXJlbmNlIGJldHdlZW4gdGhlIGFic3RyYWN0ICh3aGljaCBjbGFpbXMgdGhlIGRvY3VtZW50 IGRlc2NyaWJlcyBpc3N1ZXMgd2l0aCBOUERBTykgYW5kIHRoZSBJbnRyb2R1Y3Rpb24gKHdoaWNo IGdvZXMgZnVydGhlciB0byBzYXkgdGhhdCB0aGUgZG9jdW1lbnQgYWxzbyBkaXNjdXNzZXMgcmVx dWlyZW1lbnRzIGFuZCBzcGVjaWZpZXMgYSBuZXcgbWVzc2FnZSBpbnRlbmRlZCB0byBtZWV0IHRo ZSByZXF1aXJlbWVudHMgYW5kIHNvbHZlIHRoZSBwcm9ibGVtcy4NCg0KU28sIGl04oCZcyBhIHBy b2JsZW0gc3RhdGVtZW50LCByZXF1aXJlbWVudHMgZG9jdW1lbnQgYW5kIHNvbHV0aW9uIHNwZWNp ZmljYXRpb24gYWxsIHJvbGxlZCBpbnRvIG9uZS4gIEkgZ3Vlc3MgdGhpcyBpcyBub3QgYSBwcm9i bGVtIGZvciBhbnlvbmUgaW4gdGhlIFdHPw0KDQpUaGUgdGl0bGUgZm9yIHNlY3Rpb24gMS4zIHNo b3VsZCBwcm9iYWJseSBiZSDigJxXaHkgaXMgTlBEQU8gSW1wb3J0YW50LuKAnQ0KDQpJbiB0aGF0 IHNlY3Rpb24sIEkgaGF2ZSB0byB3b25kZXIgaWYgc2F2aW5nIG1lbW9yeSBpcyB0aGUgbW9zdCBp bXBvcnRhbnQgZmFjdG9yIGluIHJlbW92aW5nIHJvdXRlIGluZm9ybWF0aW9uIHRoYXQgaXMgbm8g bG9uZ2VyIHZhbGlkLiAgV2hhdCBhYm91dCBpc3N1ZXMgd2l0aCBmb3J3YXJkaW5nIHBhY2tldHMg dG93YXJkIGRlc3RpbmF0aW9ucyB0aGF0IGNhbiBubyBsb25nZXIgYmUgcmVhY2hlZCBhbG9uZyB0 aGF0IHBhdGg/DQoNClBlcmhhcHMgSSBtaXN1bmRlcnN0YW5kIHRoZSBhcHByb2FjaCwgYnV0IGl0 IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHByb2JsZW1zIG1lbnRpb25lZCBpbiBzZWN0aW9uIDIuMSBz aG91bGQgc2VsZi1yZXNvbHZlLiAgVGhlIGZhY3QgdGhhdCBvbmUgbm9kZSBjYW5ub3Qgc2VuZCBt ZXNzYWdlcyB0byBhbm90aGVyIG5vZGUgdG8gaW5mb3JtIHRoYXQgbm9kZSB0aGF0IGl0IGhhcyBu byBEQU8gaW5mb3JtYXRpb24gc2VlbXMga2luZCBvZiBpcnJlbGV2YW50IGlmIHRoZSBub2RlLCBv ciB0aGUgbGluayBjb25uZWN0aW5nIGl0LCBpcyBubyBsb25nZXIgdGhlcmUuDQoNClBlcmhhcHMg dGhlIGlzc3VlIHlvdeKAmXJlIHJlYWxseSB0cnlpbmcgdG8gZGVzY3JpYmUgaXMgd2l0aCB1bnJl bGlhYmxlIGxpbmtzIGFuZCBub2RlcywgYXMgb3Bwb3NlZCB0byBtaXNzaW5nIGxpbmtzIGFuZCBu b2Rlcz8gIFRoYXQgd291bGQgbWFrZSBzZW5zZSBpbiBhIGxvdy1wb3dlciBhbmQgbG9zc3kgbmV0 d29yay4NCg0KSWYgdGhlIGJlaGF2aW9yIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIuMiBpcyBjb21t b24sIGFuZCBhIG1vcmUgcmVhc29uYWJsZSBiZWhhdmlvciBpcyBub3QgYW50aWNpcGF0ZWQgYnkg dGhlIG9yaWdpbmFsIE5QREFPIHNwZWNpZmljYXRpb24sIHRoYW4gSSBhZ3JlZSB0aGF0IGlzIGEg cHJvYmxlbS4NCg0KSWYgdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBpbiAyLjEgYW5kIDIuMyBkbyBl eGlzdCwgaXQgc2VlbXMgbGlrZWx5IHRoYXQgdGhlIHVuZGVybHlpbmcgaXNzdWUgaXMgcmVhbGx5 IGFib3V0IGFuIGFzc3VtcHRpb24gb2YgcmVsaWFibGUgZGVsaXZlcnkgd2hlcmUgdGhhdCBtaWdo dCBub3QgYmUgdGhlIHJlYWxpdHkuDQoNCkFsbCBvZiB0aGlzIHNhaWQsIHRoZSAzIHJlcXVpcmVt ZW50cyBzZWVtIHJlYXNvbmFibGUgYXQgbGVhc3QgYXMgZmFyIGFzIHRoZXkgZ28uICBUaGVyZSBz ZWVtcyB0byBiZSBhbiBpbXBsaWVkIHJlcXVpcmVtZW50IHRvIGludHJvZHVjZSBhdCBsZWFzdCBz b21lIGxldmVsIG9mIHJlbGlhYmlsaXR5IChhcyBJIHNlZW1zIGludGVuZGVkIGJ5IHByb3ZpZGlu ZyB0aGUgRENPLUFDSykuIEFuZCB0aGVyZSBwcm9iYWJseSBzaG91bGQgYmUgYSByZXF1aXJlbWVu dCB0byBzdXBwb3J0IGNvbXBhdGliaWxpdHkgd2l0aCBkZXBsb3llZCBpbXBsZW1lbnRhdGlvbnMu DQoNCkFGQUlDVCwgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZXNjcmliZSBob3cgbm9kZXMgdXNp bmcgdGhlIG5ld2x5IHNwZWNpZmllZCBtZXNzYWdpbmcgYW5kIGJlaGF2aW9yIHdvdWxkIGJlIGNv bXBhdGlibGUgd2l0aCBkZXBsb3llZCBub2Rlcy4gIE1pbmltYWxseSB0aGUgZG9jdW1lbnQgc2hv dWxkIGJlIGNsZWFyIGlmIHRoZSBpbnRlbnRpb24gaXMgbm90IHRvIHByb3ZpZGUgZm9yIGNvbXBh dGliaWxpdHkuICBUaGVyZSBhcmUgYXQgbGVhc3QgYSBjb3VwbGUgb2YgaW5kaWNhdGlvbnMgdGhh dCB0aGVyZSBpcyBkZXBsb3ltZW50Lg0KDQoNCg0K --_000_BN8PR15MB26442BDB30FBB0C4DF23C9C997F60BN8PR15MB2644namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFteSBwb2ludGVkIG91dCB0aGF0IEkgZm9yZ290 IHRvIGluY2x1ZGUgdGhlIFJURy1EaXIgbWFpbGluZyBsaXN0IGluIHRoaXMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgZ290IGEgcmVwbHkgZnJvbSBBbHZhcm8sIGFuZCBJIGhhZCBpbmNsdWRl ZCB0aGUgUk9MTCBtYWlsaW5nIGxpc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBz ZW50IGEgZm9sbG93LXVwIGNvcnJlY3Rpb24gYXMgSSBoYWQgZ290dGVuIHBhc3RlIGFsbCBvdmVy IG15c2VsZi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkVyaWM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBFcmljIEdyYXkgPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBKdW5lIDI3LCAyMDE5IDEyOjQxIEFNPGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhb0BpZXRmLm9yZyI+ ZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhb0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8 L2I+IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYUBj aXNjby5jb20iPmFyZXRhbmFAY2lzY28uY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cm9s bEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gTGFzdCBD YWxsIFJldmlldyBvZiBkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUg Um91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcg RGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRl ZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2 aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4NCiBUaGUgcHVycG9zZSBvZiB0 aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ug c2VlDQo8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dp a2kvUnRnRGlyIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kv UnRnRGlyPC9hPjxicj4NCjxicj4NCkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJp bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlm IHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBD YWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVt IHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPGJyPg0KPGJyPg0K RG9jdW1lbnQ6IGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBkYW88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJldmlld2VyOiBFcmljIEdyYXk8YnI+DQpSZXZpZXcgRGF0 ZTogMjYgSnVuZSAyMDE5PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTogMjYgSnVuZSAyMDE5PGJyPg0K SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2s8YnI+DQo8YnI+DQpTdW1tYXJ5OjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBJIGFtIG1pc3Npbmcgc29t ZSBzdWJ0bGV0aWVzLCBidXQgdGhpcyBkb2N1bWVudCBsb29rcyBsaWtlIGl0IG1heSBuZWVkIGEg bGl0dGxlIG1vcmUgd29yayBiZWZvcmUgaXQgaXMgcHVibGlzaGVkLjxicj4NCjxicj4NCk92ZXJh bGwgY29tbWVudHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9j dW1lbnQgaXMgbW9zdGx5IHdlbGwgd3JpdHRlbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXNz dWVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgaW50cm9kdWN0aW9uLCBJIGhhdmUg c29tZSB0cm91YmxlIHBhcnNpbmcg4oCcYW4gb3B0aW9uYWwgbWVzc2FnaW5n4oCdIOKAkyBwZXJo YXBzIGl0IHdhcyBtZWFudCB0byBqdXN0IGJlIOKAnG9wdGlvbmFsIG1lc3NhZ2luZz/igJ08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgYWJz dHJhY3QgKHdoaWNoIGNsYWltcyB0aGUgZG9jdW1lbnQgZGVzY3JpYmVzIGlzc3VlcyB3aXRoIE5Q REFPKSBhbmQgdGhlIEludHJvZHVjdGlvbiAod2hpY2ggZ29lcyBmdXJ0aGVyIHRvIHNheSB0aGF0 IHRoZSBkb2N1bWVudCBhbHNvIGRpc2N1c3NlcyByZXF1aXJlbWVudHMgYW5kIHNwZWNpZmllcyBh IG5ldyBtZXNzYWdlIGludGVuZGVkIHRvIG1lZXQNCiB0aGUgcmVxdWlyZW1lbnRzIGFuZCBzb2x2 ZSB0aGUgcHJvYmxlbXMuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgaXTigJlzIGEgcHJv YmxlbSBzdGF0ZW1lbnQsIHJlcXVpcmVtZW50cyBkb2N1bWVudCBhbmQgc29sdXRpb24gc3BlY2lm aWNhdGlvbiBhbGwgcm9sbGVkIGludG8gb25lLiZuYnNwOyBJIGd1ZXNzIHRoaXMgaXMgbm90IGEg cHJvYmxlbSBmb3IgYW55b25lIGluIHRoZSBXRz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IHRpdGxlIGZvciBzZWN0aW9uIDEuMyBzaG91bGQgcHJvYmFibHkgYmUg4oCcV2h5IGlzIE5QREFP IEltcG9ydGFudC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhhdCBzZWN0aW9uLCBJ IGhhdmUgdG8gd29uZGVyIGlmIHNhdmluZyBtZW1vcnkgaXMgdGhlIG1vc3QgaW1wb3J0YW50IGZh Y3RvciBpbiByZW1vdmluZyByb3V0ZSBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vIGxvbmdlciB2YWxp ZC4mbmJzcDsgV2hhdCBhYm91dCBpc3N1ZXMgd2l0aCBmb3J3YXJkaW5nIHBhY2tldHMgdG93YXJk IGRlc3RpbmF0aW9ucyB0aGF0IGNhbiBubyBsb25nZXIgYmUgcmVhY2hlZCBhbG9uZyB0aGF0DQog cGF0aD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBJIG1pc3VuZGVyc3RhbmQgdGhl IGFwcHJvYWNoLCBidXQgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgcHJvYmxlbXMgbWVudGlvbmVk IGluIHNlY3Rpb24gMi4xIHNob3VsZCBzZWxmLXJlc29sdmUuJm5ic3A7IFRoZSBmYWN0IHRoYXQg b25lIG5vZGUgY2Fubm90IHNlbmQgbWVzc2FnZXMgdG8gYW5vdGhlciBub2RlIHRvIGluZm9ybSB0 aGF0IG5vZGUgdGhhdCBpdCBoYXMgbm8gREFPIGluZm9ybWF0aW9uIHNlZW1zDQoga2luZCBvZiBp cnJlbGV2YW50IGlmIHRoZSBub2RlLCBvciB0aGUgbGluayBjb25uZWN0aW5nIGl0LCBpcyBubyBs b25nZXIgdGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhhcHMgdGhlIGlzc3VlIHlv deKAmXJlIHJlYWxseSB0cnlpbmcgdG8gZGVzY3JpYmUgaXMgd2l0aCB1bnJlbGlhYmxlIGxpbmtz IGFuZCBub2RlcywgYXMgb3Bwb3NlZCB0byBtaXNzaW5nIGxpbmtzIGFuZCBub2Rlcz8mbmJzcDsg VGhhdCB3b3VsZCBtYWtlIHNlbnNlIGluIGEgbG93LXBvd2VyIGFuZCBsb3NzeSBuZXR3b3JrLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgYmVoYXZpb3IgZGVzY3JpYmVkIGluIHNlY3Rp b24gMi4yIGlzIGNvbW1vbiwgYW5kIGEgbW9yZSByZWFzb25hYmxlIGJlaGF2aW9yIGlzIG5vdCBh bnRpY2lwYXRlZCBieSB0aGUgb3JpZ2luYWwgTlBEQU8gc3BlY2lmaWNhdGlvbiwgdGhhbiBJIGFn cmVlIHRoYXQgaXMgYSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgcHJv YmxlbXMgZGVzY3JpYmVkIGluIDIuMSBhbmQgMi4zIGRvIGV4aXN0LCBpdCBzZWVtcyBsaWtlbHkg dGhhdCB0aGUgdW5kZXJseWluZyBpc3N1ZSBpcyByZWFsbHkgYWJvdXQgYW4gYXNzdW1wdGlvbiBv ZiByZWxpYWJsZSBkZWxpdmVyeSB3aGVyZSB0aGF0IG1pZ2h0IG5vdCBiZSB0aGUgcmVhbGl0eS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIG9mIHRoaXMgc2FpZCwgdGhlIDMgcmVxdWlyZW1l bnRzIHNlZW0gcmVhc29uYWJsZSBhdCBsZWFzdCBhcyBmYXIgYXMgdGhleSBnby4mbmJzcDsgVGhl cmUgc2VlbXMgdG8gYmUgYW4gaW1wbGllZCByZXF1aXJlbWVudCB0byBpbnRyb2R1Y2UgYXQgbGVh c3Qgc29tZSBsZXZlbCBvZiByZWxpYWJpbGl0eSAoYXMgSSBzZWVtcyBpbnRlbmRlZCBieSBwcm92 aWRpbmcgdGhlIERDTy1BQ0spLiBBbmQgdGhlcmUgcHJvYmFibHkNCiBzaG91bGQgYmUgYSByZXF1 aXJlbWVudCB0byBzdXBwb3J0IGNvbXBhdGliaWxpdHkgd2l0aCBkZXBsb3llZCBpbXBsZW1lbnRh dGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFGQUlDVCwgdGhpcyBkb2N1bWVudCBkb2Vz IG5vdCBkZXNjcmliZSBob3cgbm9kZXMgdXNpbmcgdGhlIG5ld2x5IHNwZWNpZmllZCBtZXNzYWdp bmcgYW5kIGJlaGF2aW9yIHdvdWxkIGJlIGNvbXBhdGlibGUgd2l0aCBkZXBsb3llZCBub2Rlcy4m bmJzcDsgTWluaW1hbGx5IHRoZSBkb2N1bWVudCBzaG91bGQgYmUgY2xlYXIgaWYgdGhlIGludGVu dGlvbiBpcyBub3QgdG8gcHJvdmlkZSBmb3IgY29tcGF0aWJpbGl0eS4mbmJzcDsgVGhlcmUNCiBh cmUgYXQgbGVhc3QgYSBjb3VwbGUgb2YgaW5kaWNhdGlvbnMgdGhhdCB0aGVyZSBpcyBkZXBsb3lt ZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BN8PR15MB26442BDB30FBB0C4DF23C9C997F60BN8PR15MB2644namp_-- From nobody Tue Jul 9 06:35:47 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1777612017C; Tue, 9 Jul 2019 06:35:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ines Robles via Datatracker To: Cc: draft-ietf-pce-stateful-path-protection.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ines Robles Message-ID: <156267933200.15900.568531128971641776@ietfa.amsl.com> Date: Tue, 09 Jul 2019 06:35:32 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-pce-stateful-path-protection-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 13:35:32 -0000 Reviewer: Ines Robles Review result: Ready Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pce-stateful-path-protection-07.txt Reviewer: Ines Robes Review Date: 09-07-2019 IETF LC End Date: -- Intended Status: Standards Track Summary: I believe the draft is technically good. This document is well written. This document specifies a stateful PCEP extension to associate two or more LSPs for the purpose of setting up path protection. I have some minor questions. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: from the tool -> Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Comments/Questions: 1- about "..associate one working LSP with one or more protection LSPs..." --> Is there a limit of numbers of protection LSPs to be associated with one working LSP? 2- About Table 1: PPAG TLV, the name of the flag "S - STANDBY" should be "Secondary" (S) as per Figure 1? Thank you for this document, Ines. From nobody Tue Jul 9 09:50:47 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92B1207CD; Tue, 9 Jul 2019 09:50:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Niven-Jenkins via Datatracker To: Cc: rtg-ads@ietf.org, lsr@ietf.org, draft-ietf-ospf-xaf-te.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ben Niven-Jenkins Message-ID: <156269103739.15887.9615693256719949848@ietfa.amsl.com> Date: Tue, 09 Jul 2019 09:50:37 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-ospf-xaf-te-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:50:38 -0000 Reviewer: Ben Niven-Jenkins Review result: Ready Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-xaf-te-06.txt Reviewer: Ben Niven-Jenkins Review Date: 9th July 2019 IETF LC End Date: 11th July 2019 Intended Status: Standards Track Summary: No issues found. This document is ready for publication. Comments: The document is readable and succinctly addresses the use case outlined. Major issues: No major issues found. Minor issues: No minor issues found. Regards Ben From nobody Wed Jul 10 03:47:30 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B40171201B8; Wed, 10 Jul 2019 03:47:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Susan Hares via Datatracker To: Cc: mpls@ietf.org, ietf@ietf.org, draft-ietf-mpls-rfc8287-len-clarification.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Susan Hares Message-ID: <156275564863.15103.4931244752332574168@ietfa.amsl.com> Date: Wed, 10 Jul 2019 03:47:28 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-mpls-rfc8287-len-clarification-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 10:47:29 -0000 Reviewer: Susan Hares Review result: Ready Status: Ready Summary comment: Nicely written update for a necessary correction to RFC 8287. Comment AD/MPLS chairs: It would be handy to eventually include this with RFC8287 into a single document. Nitss: none Thanks for helping interoperability by making sure the lengths are correct. From nobody Wed Jul 10 04:56:05 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897AD1200A3; Wed, 10 Jul 2019 04:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 SW8hqA8io5SK; Wed, 10 Jul 2019 04:56:00 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.117]) (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 8ED4B12011D; Wed, 10 Jul 2019 04:55:58 -0700 (PDT) Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta.az-b.eu-central-1.aws.symcld.net id 44/D3-10235-53FC52D5; Wed, 10 Jul 2019 11:42:45 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAJsWRWlGSWpSXmKPExsUi9LZnk67JedV Yg/Ud+hYbP99ktni2cT6Lxa2lK1ktFqx5ym7x580rFgdWjyVLfjJ5zH59nTWAKYo1My8pvyKB NeP+jA72ggWcFctb37I0ME7g7GLk4mARWMsssWnKOVYQR0hgIpPEzN2/mCCcu4wSp9p+sXQxc nKwCdhKbFp9lw3EFhHwkPi/8BMjSBGzwE5GiQfHN7OCJIQF4iU+vVnGDlGUILGn9RVUg5HE0k /bwGpYBFQl7m49yAhi8wrESvQv+QxWIyTgLDHn/1TmLkYODk4BF4nfPVwgYUYBMYnvp9Ywgdj MAuISt57MB7MlBAQkluw5zwxhi0q8fPyPFaI+SeL+04WMEHFFiRn35rBD2LISl+Z3Q8V9JXY9 f8UOskpCQFliy4tYkFckBB4zSrS2PYGaryXx6Voz1PwciYU986FsNYn3yy5A1chIbPs2jwmiu YdN4kvLGhaIX5IlTsz5zAJRJCexqvchC0TRBWaJxqMgHRxA32hKrN+lP4FRZxaS32YhZCDCih JTuh+yzwKHlqDEyZlPWBYwsqxitEgqykzPKMlNzMzRNTQw0DU0NNY11TWx1Eus0k3SSy3VTU7 NKylKBErqJZYX6xVX5ibnpOjlpZZsYgQmo5RCVsMdjBOOvNY7xCjJwaQkyltxWjVWiC8pP6Uy I7E4I76oNCe1+BCjDAeHkgTv+3NAOcGi1PTUirTMHGBihElLcPAoifBeB0nzFhck5hZnpkOkT jEac0x4OXcRM8eRuUsXMQux5OXnpUqJ8247C1QqAFKaUZoHNwiWsC8xykoJ8zIyMDAI8RSkFu VmlqDKv2IU52BUEubtBpnCk5lXArfvFdApTECn1EUqgZxSkoiQkmpg2iw651IS+/3vYRG7Zf/ WzzFpVC255P7D9+8P7lDBae2yByvcj8063Lb/a4nFCifjDKsW+yQ7yR08Z0O3/lkofM+wcLVI AJu5zBvti72s69ZXcfXsKDuWaX7fVutOQLDYBl3tG+sClM4VLtxz6s9iTo2LOop6RbI1O1/Of Jo1h5dLIjT4i9ClVX/qqsODbHOeHz7/aP7EldNKUldVdk2IsFl8a4ukgnmguLaDc5mH6/Htvz edn2mo9tRzo7XR1avxczQfm/552cq6YOvNoqjGZ6+m1nE+T5X9USTuKWe02690ybWmj5dP/5p 4Xojj7OYft3zz+mQPfK19dfurQauQ2YPUt05fFEtnKu5aJ6d2WomlOCPRUIu5qDgRAOHWCHNT BAAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-245.messagelabs.com!1562758962!786606!1 X-Originating-IP: [18.237.140.178] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 6087 invoked from network); 10 Jul 2019 11:42:44 -0000 Received: from ec2-18-237-140-178.us-west-2.compute.amazonaws.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.178) by server-11.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 10 Jul 2019 11:42:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MMtTTUzdHU9z5J2hqVtmvk9SlL8Nv/66Vzxf2QzSZ78=; b=UydVH+uKB29/ATaXwJBL+aDbcTuyb5G2ExoL6wmBkxy1k/d03DJ7ABwDhZPIVoBzNx8CZLt410z80a+kFQxCTJzgWqP3p+CP8cFdh+Ye5GxkAYB3CGFcnS/ZI9ubKKyjdbdpGZEGz/Qm63m3jedqMj4itrREkML/XMxShZCg79Q= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB3796.eurprd03.prod.outlook.com (52.135.152.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Wed, 10 Jul 2019 11:42:39 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::29f2:7c6:37cb:8ea7]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::29f2:7c6:37cb:8ea7%3]) with mapi id 15.20.2052.019; Wed, 10 Jul 2019 11:42:39 +0000 From: Alexander Vainshtein To: Susan Hares , "rtg-dir@ietf.org" CC: "mpls@ietf.org" , "ietf@ietf.org" , "draft-ietf-mpls-rfc8287-len-clarification.all@ietf.org" Thread-Topic: [RTG-DIR] Rtgdir last call review of draft-ietf-mpls-rfc8287-len-clarification-02 Thread-Index: AQHVNwzj13pV/9VN9kOPRHmTBAJDNabDr8Pw Date: Wed, 10 Jul 2019 11:42:39 +0000 Message-ID: References: <156275564863.15103.4931244752332574168@ietfa.amsl.com> In-Reply-To: <156275564863.15103.4931244752332574168@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa45b72b-75dd-41c6-4c49-08d7052bb66c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB3796; x-ms-traffictypediagnostic: AM0PR03MB3796: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(136003)(396003)(39860400002)(346002)(13464003)(199004)(189003)(7696005)(76176011)(478600001)(305945005)(52536014)(53546011)(229853002)(66066001)(186003)(6246003)(7736002)(6116002)(6506007)(99286004)(74316002)(25786009)(71200400001)(8676002)(71190400001)(81156014)(102836004)(81166006)(476003)(4326008)(26005)(110136005)(68736007)(66946007)(14444005)(2501003)(11346002)(4744005)(9686003)(316002)(6436002)(54906003)(14454004)(486006)(33656002)(2906002)(53936002)(86362001)(3846002)(5660300002)(66556008)(256004)(66446008)(64756008)(66476007)(446003)(55016002)(76116006)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3796; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: StRfVuA3zDGcm46HZduOojWfoJoaT+cjbongfW91lt58FAHRjVcyJgABBh6qjoYE8f2vPKSmop0qagyoVaCQaf/wHNIh7zB/Uscje1aOKYMnAfYuxq2ymgS+w2JbJ7QGZpPR+cSGAyKAGCZVcTtgkLW+zSx5E+ivaQPj2QdNf9vf4lzllREm8CDu30coIit0f6TYLho2H+gRbDsNX1HCf5mCLQ6vdj98HnvhDagAXSbv+WZC+oov+kItyxz6Fe51K85eAnBEljdT5pQnu09ehNbfrL7ny43ArEoH7ttOAy5lEAU5qu29DLoypDMVwxrZqSH06eVBgaS1ig+6Cthd8N/UGZ+tGovGyaC3uRHoB0cCQ344Cu9EPqqHbSEidj+EqX6IVVoKaacBnIQYSVWsOiiR4pcX+WhopLCIlO5Uubw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa45b72b-75dd-41c6-4c49-08d7052bb66c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 11:42:39.6229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3796 X-CFilter-Loop: Reflected X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-mpls-rfc8287-len-clarification-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 11:56:04 -0000 U3VzYW4sCkxvdHMgb2YgdGhhbmtzIGZvciBhIHBvc2l0aXZlIHJldmlldyEKCgpSZWdhcmRzLApT YXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyCkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDIKRW1h aWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20KCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tCkZyb206IHJ0Zy1kaXIgPHJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIFN1c2FuIEhhcmVzIHZpYSBEYXRhdHJhY2tlcgpTZW50OiBXZWRuZXNkYXksIEp1bHkg MTAsIDIwMTkgMTo0NyBQTQpUbzogcnRnLWRpckBpZXRmLm9yZwpDYzogbXBsc0BpZXRmLm9yZzsg aWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXJmYzgyODctbGVuLWNsYXJpZmljYXRpb24u YWxsQGlldGYub3JnClN1YmplY3Q6IFtSVEctRElSXSBSdGdkaXIgbGFzdCBjYWxsIHJldmlldyBv ZiBkcmFmdC1pZXRmLW1wbHMtcmZjODI4Ny1sZW4tY2xhcmlmaWNhdGlvbi0wMgoKUmV2aWV3ZXI6 IFN1c2FuIEhhcmVzClJldmlldyByZXN1bHQ6IFJlYWR5CgpTdGF0dXM6IFJlYWR5CgpTdW1tYXJ5 IGNvbW1lbnQ6IE5pY2VseSB3cml0dGVuICB1cGRhdGUgZm9yIGEgbmVjZXNzYXJ5IGNvcnJlY3Rp b24gdG8gUkZDIDgyODcuCkNvbW1lbnQgQUQvTVBMUyBjaGFpcnM6ICBJdCB3b3VsZCBiZSBoYW5k eSB0byBldmVudHVhbGx5IGluY2x1ZGUgdGhpcyB3aXRoClJGQzgyODcgaW50byBhIHNpbmdsZSBk b2N1bWVudC4KCk5pdHNzOiBub25lCgpUaGFua3MgZm9yIGhlbHBpbmcgaW50ZXJvcGVyYWJpbGl0 eSBieSBtYWtpbmcgc3VyZSB0aGUgbGVuZ3RocyBhcmUgY29ycmVjdC4KCgoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50 IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIApDT05GSURFTlRJQUwgYW5k IHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyAKdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUt bWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIAphbmQgYWxs IGNvcGllcyB0aGVyZW9mLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K From nobody Mon Jul 15 18:38:37 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97F912016C; Mon, 15 Jul 2019 18:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 GfBKM9zj2PGU; Mon, 15 Jul 2019 18:38:34 -0700 (PDT) Received: from dish-sg.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by ietfa.amsl.com (Postfix) with ESMTP id DFB8B1200DB; Mon, 15 Jul 2019 18:38:30 -0700 (PDT) X-dD-Source: Outbound Received: from zssg-mailmd105.ddreams.local (zssg-mailmd900.ddreams.local [10.160.172.63]) by zssg-mailou102.ddreams.local (Postfix) with ESMTP id 3DEEC12012B; Tue, 16 Jul 2019 10:38:30 +0900 (JST) Received: from zssg-mailmf106.ddreams.local (zssg-mailmf900.ddreams.local [10.160.172.84]) by zssg-mailmd105.ddreams.local (dDREAMS) with ESMTP id <0PUP012C1OK2EE40@dDREAMS>; Tue, 16 Jul 2019 10:38:26 +0900 (JST) Received: from zssg-mailmf106.ddreams.local (unknown [127.0.0.1]) by zssg-mailmf106.ddreams.local (Postfix) with ESMTP id 89C457E603B; Tue, 16 Jul 2019 10:38:26 +0900 (JST) Received: from zssg-mailmf106.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 893128E6063; Tue, 16 Jul 2019 10:38:26 +0900 (JST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 8787E8E605F; Tue, 16 Jul 2019 10:38:26 +0900 (JST) X-IMSS-HAND-OFF-DIRECTIVE: localhost:10026 Received: from zssg-mailmf106.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AB7468E6065; Tue, 16 Jul 2019 10:38:25 +0900 (JST) Received: from zssg-mailua105.ddreams.local (unknown [10.160.172.62]) by zssg-mailmf106.ddreams.local (Postfix) with ESMTP; Tue, 16 Jul 2019 10:38:25 +0900 (JST) Received: from RDSVVDI2579 (unknown [10.171.81.237]) by zssg-mailua105.ddreams.local (dDREAMS) with ESMTPA id <0PUP001Z5OJI2A80@dDREAMS>; Tue, 16 Jul 2019 10:38:16 +0900 (JST) From: Tomonori Takeda Date: Tue, 16 Jul 2019 10:38:06 +0900 Message-id: <001501d53b77$1d9775b0$58c66110$@hco.ntt.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: ja Thread-index: AdU7ds8A6Io6um+YQ0mmwR03HkJwkw== To: rtg-ads@ietf.org Cc: rtg-dir@ietf.org, draft-ietf-pce-lsp-control-request.all@ietf.org, pce@ietf.org X-TM-AS-GCONF: 00 Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-lsp-control-request-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 01:38:36 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pce-lsp-control-request-06.txt Reviewer: Tomonori Takeda Review Date: July 16th, 2019 IETF LC End Date: Not known Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document specifies a PCEP extension by which a PCE can request control of LSP(s) from PCC(s) over the stateful PCEP sessions. The procotol extension is simple, and its operation is well documented, including operation with PCCs that do not support the protocol extension specified in this document. Major Issues: None Minor Issues: None Nits: 1) In Section 2, it states terminologies. Since these terminologies are already defined in other documents, I would suggest to add references. 2) In Section 8.1, it says: "Further, the operator MAY be to be allowed " It should be: "Further, the operator MAY be allowed " Thanks, Tomonori Takeda From nobody Thu Jul 18 18:31:18 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43C4120044; Thu, 18 Jul 2019 18:31:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ciena.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 7HngBb9rzhk2; Thu, 18 Jul 2019 18:31:05 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 2693F12004C; Thu, 18 Jul 2019 18:31:05 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6J1R38S008254; Thu, 18 Jul 2019 21:31:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=06252019; bh=/nn/c1DHBBXQnSIjKjq3LClXBOJ8gQEkaBDt8UmNoNo=; b=Wp1jGjvWa0qUJ9JG1xQ5jO/mFW6XMpwqtmgB/9QGCwARwAZXBRsAsE6EO9+BN6zTdJ44 J+Q3fqN6Sy2IN2NbyqHApWGhscUGp4oVuMNxsugO+ZRM/8yjcIU2tLFWVHqnw9UwtkU2 tZilkzyF8FBIUuXOedQboF4y79DRZaRw1mENPbJxmx3yy/tIAEyfjnbqn2s4+ihyIjoi i/iiOtB9Fcj3mOJeI08/cAz+/Hglg0rcu3hMXauYPYRVOtXI5NnlZDeVzsvbnN+xWUmx qXeQZ2PKvCoI09Sgc/Qn8M46eAHZeqRezw70oaOvuIvaeemtMMkTfGTgwSLHhuMc14hm lw== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp2058.outbound.protection.outlook.com [104.47.42.58]) by mx0b-00103a01.pphosted.com with ESMTP id 2ttv4nt4b2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Jul 2019 21:31:03 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=abjTXqKqsTGpta3+Gy9WZ68vS+VCXko8q0K2768FP5d98jxSkZYy2M4u05TwwKwpgmQdW5u6+qHC+go50AoN7rOFXD9oi335I6641/24ij8hlkvAbjYiF1Wy9OKv/iF6RyuB3qR69jNHv1G7e8H/rlea8bbI9qOIKr3gTuqVcpbsxC7jv8QexmhhjGPAK/K06KztWr4sWIjlB6bor3zrMG5wJqeQ10qFQJuJd3fJpkoVJvBomBdrR5TUNnutZLSGitgmOVHTxkRXiNQ4pxn+zBez5bh0W9esmxFc4V0AgSs+SDEhQ40YRquKS0QCf9hTtg8NUq4gGpAWxFJ6cW/jFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/nn/c1DHBBXQnSIjKjq3LClXBOJ8gQEkaBDt8UmNoNo=; b=P0ZG+evO7/Zij9LdGfLdUrLufb7kfKBOfYe3i8xPH712l8MT5SmSC1rMdz5PhqOdjlM1BFmEbvq/x20CUQxqNTQRgUmK3NiYjn64WdS0cq0GfHkkyTvr+n2H4itObTqlcUr+LsUmctW6Rd8CsMlQmYQVFDqp+aH7YBK/z8Ii7xlYGtDZS0MA8Jsxf3Y1VxRDGe7feZ1KQLHuVSs118PW0qmgBUWVn7wRnnodlu6JewcHVn/HhQlB3E6Vgu2m9hNCb/gY9w9LRGg/nmcNFr8meqMl1/w1jt3tHuq2spRAM9GQ9zjlc1AfqdTD4juNW8oXw2XNp4M1RR1u9kd2WUXP7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ciena.com;dmarc=pass action=none header.from=ciena.com;dkim=pass header.d=ciena.com;arc=none Received: from BYAPR04MB4663.namprd04.prod.outlook.com (52.135.240.14) by BYAPR04MB6021.namprd04.prod.outlook.com (20.178.233.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.11; Fri, 19 Jul 2019 01:31:02 +0000 Received: from BYAPR04MB4663.namprd04.prod.outlook.com ([fe80::9985:9af2:e49b:f63b]) by BYAPR04MB4663.namprd04.prod.outlook.com ([fe80::9985:9af2:e49b:f63b%6]) with mapi id 15.20.2073.012; Fri, 19 Jul 2019 01:31:02 +0000 From: "Shah, Himanshu" To: "" CC: "rtg-dir@ietf.org" , "idr@ietf.org" , "draft-ietf-idr-bgp-extended-messages.all@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review : draft-ietf-idr-bgp-extended-messages-33.txt Thread-Index: AQHVPbeOTTN/1clPqkSBL6jNQBuH4g== Date: Fri, 19 Jul 2019 01:31:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 x-originating-ip: [165.225.38.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: edc3a681-e2d3-4f01-2412-08d70be8c297 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7167020)(7193020); SRVR:BYAPR04MB6021; x-ms-traffictypediagnostic: BYAPR04MB6021: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(136003)(366004)(376002)(396003)(346002)(39860400002)(189003)(199004)(33656002)(7110500001)(14454004)(186003)(66066001)(54906003)(25786009)(53936002)(26005)(2420400007)(15650500001)(64756008)(66446008)(54896002)(236005)(66556008)(790700001)(6116002)(8936002)(9326002)(81156014)(99286004)(5660300002)(7736002)(102836004)(3846002)(36756003)(450100002)(68736007)(606006)(81166006)(478600001)(71200400001)(71190400001)(66946007)(4326008)(486006)(316002)(55236004)(6506007)(476003)(6486002)(2616005)(14444005)(58126008)(256004)(86362001)(6436002)(91956017)(76116006)(2906002)(66476007)(6512007)(8676002)(6306002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR04MB6021; H:BYAPR04MB4663.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YJIuoZ3WSpz86RIj5aeLFOPN/ap2SGYkN4vvb/lzOF/pHiZHfN1z1w35E+k1jOHzPYwKg/BBkJo+7/+559sfhZGGACxrirnCGguiGvAJ30SlGwzBbg1a4+LDpVd5Bg7u2Wp44IQCWOsyps5CpAnUNxZE6NFKbHrJGpdU+UoyG1kJinwj1UfOEZ+8msbn7stZs4GlCCMPKLgBX22PKQQ1/RLZ50KnVjjjuRIJp5RrDhpMHozncvs0xOSgk1ZJYU6T8JJDDDJ8x7slFGnrcuSxspKU2+9wBIGRdSDwRh3QIjZ9YDr3zeOeasXzqKiUFXudpWdnAWE4fNFidTIes4voImq08lKiO/ElYNQTjXizjpbBtbBYVT2togUe3XYdzOyxSgXsRQlPAEgbb22e00n5z4f2SnC+bGJ1Tqh37ig++aE= Content-Type: multipart/alternative; boundary="_000_E14C9916FE094CA385C7441DDE658524cienacom_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-Network-Message-Id: edc3a681-e2d3-4f01-2412-08d70be8c297 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 01:31:01.9079 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hshah@ciena.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB6021 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-19_01:2019-07-18,2019-07-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 impostorscore=0 malwarescore=0 phishscore=0 clxscore=1011 priorityscore=1501 adultscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1904300001 definitions=main-1907190015 Archived-At: Subject: [RTG-DIR] RtgDir review : draft-ietf-idr-bgp-extended-messages-33.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 01:31:08 -0000 --_000_E14C9916FE094CA385C7441DDE658524cienacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0Lg0KVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3Mg dG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZA0KZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kDQpzb21ldGlt ZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHBy b3ZpZGUNCmFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgUm91dGluZw0KRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUNCuKAi2h0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2gg dGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBB RHMsIGl0DQp3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25n IHdpdGggYW55IG90aGVyIElFVEYNCkxhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZl LCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoDQpkaXNjdXNzaW9uIG9yIGJ5IHVw ZGF0aW5nIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1leHRlbmRl ZC1tZXNzYWdlcy0zMy50eHQNClJldmlld2VyOiBIaW1hbnNodSBTaGFoDQpSZXZpZXcgRGF0ZTog MTggSnVseSAyMDE5DQpJRVRGIExDIEVuZCBEYXRlOiBVbmtub3duDQpJbnRlbmRlZCBTdGF0dXM6 IFN0YW5kYXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KDQpJIGhhdmUgc29tZSBzdWdnZXN0aW9ucyB0 byBpbXByb3ZlIHRoZSBkb2N1bWVudCBieSBhZGRpbmcgbW9yZSBjb250ZXh0IHRvIHRoZSBnb2Fs IG9mIHRoaXMgZHJhZnQuDQoNCkNvbW1lbnRzOg0KDQpUaGUgZG9jdW1lbnQgaXMgY29uY2lzZSwg Y2xlYXIgYW5kIGVhc3kgdG8gcmVhZC4NCg0KU2luY2UgdGhpcyBpcyBteSBmaXJzdCByZXZpZXcg YXMgUm91dGluZyBkaXJlY3RvcmF0ZSwgdGhlIHN1Z2dlc3Rpb25zIEkgaGF2ZSwNCmNvdWxkIGJl IG91dC1vZi1zY29wZS4gV2lsbCBsZWF2ZSBhdCB0aGUgZGlzY3JldGlvbiBvZiBBRCBhbmQgYXV0 aG9ycywgaWYgc3VnZ2VzdGlvbnMgYXJlIHdvcnRoIHB1cnN1aW5nIG9yIG5vdC4NCg0KV2hpbGUg SW50cm9kdWN0aW9uIHNlY3Rpb24gYnJpZWZseSBtZW50aW9ucyBuZXdlciBjYXBhYmlsaXRpZXMg YXMgdGhlIHJlYXNvbiBmb3IgZXh0ZW5kZWQNCm1lc3NhZ2Ugc2l6ZSBmb3IgdGhlIEJHUCwgaXQg bWF5IGhlbHAgdGhlIHJlYWRlciB0byBleHBhbmQgb24gdGhlIGFkdmFudGFnZXMgb2YgZXh0ZW5k ZWQgbWVzc2FnZQ0KYXMgY29tcGFyZWQgdG8gY3VycmVudCBsaW1pdGF0aW9uIG9mIDRLIEJHUCBt ZXNzYWdlcy4gIEZvciBtZSwgc3Vic2VxdWVudCByZWFkaW5nIG9mIHRoZQ0KZG9jdW1lbnQgYXMg aXQgdW5kZXJsaW5lcyB0aGUgbWlncmF0aW9uLCBlcnJvciBjYXNlcyBhbmQgc2VjdXJpdHkgcmlz a3MsIHRoZSBhZHZhbnRhZ2VzIG9mDQpleHRlbmRlZCBtZXNzYWdlIHNpemUgc2VlbXMgdG8gZGlz c2lwYXRlLg0KDQpJIGFsc28gc3VnZ2VzdCB0aGF0IGF1dGhvcnMgYWRkcmVzcyBpc3N1ZSBvZiBl eHRlbmRlZCBkZWxheSBhdCB0aGUgcmVjZWl2ZXIgaW4gcHJvY2Vzc2luZyBvZiBsYXJnZSBzaXpl IEJHUA0KbWVzc2FnZXMgd2hpbGUgVENQ4oCZcyByZWxpYWJsZSB0cmFuc3BvcnQgaXMgYnVpbGRp bmcgYSBjb21wbGV0ZSBtZXNzYWdlIHVuZGVyIGNoYWxsZW5naW5nDQpuZXR3b3JrIGNvbmRpdGlv bnMgYW5kIGNvbXBhcmUgdGhhdCBhZ2FpbnN0IHNtYWxsZXIgbWVzc2FnZXMgaW4gZGlzdHJlc3Nl ZCBuZXR3b3JrLg0KDQpJbiBteSB2aWV3LCBtYWtpbmcgYSBzdHJvbmcgY2FzZSBvbiB3aHkgZXh0 ZW5kZWQgbWVzc2FnZSBzaXplLCB3b3VsZCBncmVhdGx5IGFkZCB2YWx1ZS4NCg0KIE1ham9yIElz c3VlczoNCg0KTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KDQpNaW5vciBJc3N1ZXM6DQoNCk5vIG1p bm9yIGlzc3VlcyBmb3VuZC4gUGxlYXNlIG5vdGUgdGhlIHN1Z2dlc3Rpb24gaW4gdGhlIGNvbW1l bnQgc2VjdGlvbiBhYm92ZS4NCg0KTml0czoNCg0KTm9uZS4NCg0KDQoNClRoYW5rcywNCkhpbWFu c2h1DQo= --_000_E14C9916FE094CA385C7441DDE658524cienacom_ Content-Type: text/html; charset="utf-8" Content-ID: <8A265169887A7946953031C7BA1E49A9@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpD b25zb2xhczsNCgljb2xvcjojMDQzMkZGOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6YmxhY2siPkhlbGxvLDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5J IGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBm b3IgdGhpcyBkcmFmdC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNl ZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQ8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdl YmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6Ymxh Y2siPmRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyBy ZXZpZXcsIGFuZDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWdu OnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+c29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4g VGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5h c3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIFJvdXRpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGln bjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPkRpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNv bG9yOmJsYWNrIj7igIs8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0 Zy90cmFjL3dpa2kvUnRnRGlyIiB0aXRsZT0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJl YS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2Zv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dp ZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5BbHRob3VnaCB0aGVzZSBj b21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQ8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iY29sb3I6YmxhY2siPndvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRo ZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu czogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+TGFzdCBDYWxsIGNv bW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91 Z2g8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iY29sb3I6YmxhY2siPmRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Ljwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRv O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Eb2N1bWVudDogZHJhZnQtaWV0 Zi1pZHItYmdwLWV4dGVuZGVkLW1lc3NhZ2VzLTMzLnR4dA0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpi bGFjayI+UmV2aWV3ZXI6IEhpbWFuc2h1IFNoYWg8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRv O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5SZXZpZXcgRGF0ZTogMTggSnVs eSAyMDE5PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5JRVRGIExDIEVuZCBEYXRlOiBVbmtub3duPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRv Oy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9y OmJsYWNrIj5JbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjazwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+U3VtbWFyeTombmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5JIGhhdmUgc29tZSBzdWdnZXN0aW9ucyB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCBieSBhZGRp bmcgbW9yZSBjb250ZXh0IHRvIHRoZSBnb2FsIG9mIHRoaXMgZHJhZnQuJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFj ayI+Q29tbWVudHM6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGRvY3VtZW50IGlzIGNvbmNpc2UsIGNsZWFyIGFu ZCBlYXN5IHRvIHJlYWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImNvbG9yOmJsYWNrIj5TaW5jZSB0aGlzIGlzIG15IGZpcnN0IHJldmlldyBhcyBSb3V0 aW5nIGRpcmVjdG9yYXRlLCB0aGUgc3VnZ2VzdGlvbnMgSSBoYXZlLA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJj b2xvcjpibGFjayI+Y291bGQgYmUgb3V0LW9mLXNjb3BlLiBXaWxsIGxlYXZlIGF0IHRoZSBkaXNj cmV0aW9uIG9mIEFEIGFuZCBhdXRob3JzLCBpZiBzdWdnZXN0aW9ucyBhcmUgd29ydGggcHVyc3Vp bmcgb3Igbm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Y29sb3I6YmxhY2siPldoaWxlIEludHJvZHVjdGlvbiBzZWN0aW9uIGJyaWVmbHkgbWVudGlvbnMg bmV3ZXIgY2FwYWJpbGl0aWVzIGFzIHRoZSByZWFzb24gZm9yIGV4dGVuZGVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJjb2xvcjpibGFjayI+bWVzc2FnZSBzaXplIGZvciB0aGUgQkdQLCBpdCBtYXkgaGVscCB0aGUg cmVhZGVyIHRvIGV4cGFuZCBvbiB0aGUgYWR2YW50YWdlcyBvZiBleHRlbmRlZCBtZXNzYWdlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJjb2xvcjpibGFjayI+YXMgY29tcGFyZWQgdG8gY3VycmVudCBsaW1pdGF0aW9u IG9mIDRLIEJHUCBtZXNzYWdlcy4gJm5ic3A7Rm9yIG1lLCBzdWJzZXF1ZW50IHJlYWRpbmcgb2Yg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+ZG9jdW1lbnQgYXMgaXQgdW5kZXJsaW5lcyB0 aGUgbWlncmF0aW9uLCBlcnJvciBjYXNlcyBhbmQgc2VjdXJpdHkgcmlza3MsIHRoZSBhZHZhbnRh Z2VzIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+ZXh0ZW5kZWQgbWVzc2FnZSBzaXplIHNl ZW1zIHRvIGRpc3NpcGF0ZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iY29sb3I6YmxhY2siPkkgYWxzbyBzdWdnZXN0IHRoYXQgYXV0aG9ycyBhZGRyZXNz IGlzc3VlIG9mIGV4dGVuZGVkIGRlbGF5IGF0IHRoZSByZWNlaXZlciBpbiBwcm9jZXNzaW5nIG9m IGxhcmdlIHNpemUgQkdQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+bWVzc2FnZXMgd2hpbGUg VENQ4oCZcyByZWxpYWJsZSB0cmFuc3BvcnQgaXMgYnVpbGRpbmcgYSBjb21wbGV0ZSBtZXNzYWdl IHVuZGVyIGNoYWxsZW5naW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+bmV0d29yayBjb25k aXRpb25zIGFuZCBjb21wYXJlIHRoYXQgYWdhaW5zdCBzbWFsbGVyIG1lc3NhZ2VzIGluIGRpc3Ry ZXNzZWQgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOmJsYWNrIj5JbiBteSB2aWV3LCBtYWtpbmcgYSBzdHJvbmcgY2FzZSBvbiB3aHkg ZXh0ZW5kZWQgbWVzc2FnZSBzaXplLCB3b3VsZCBncmVhdGx5IGFkZCB2YWx1ZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtNYWpvciBJc3N1ZXM6PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+ Tm8gbWFqb3IgaXNzdWVzIGZvdW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJj b2xvcjpibGFjayI+TWlub3IgSXNzdWVzOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPk5vIG1pbm9yIGlzc3VlcyBmb3Vu ZC4gUGxlYXNlIG5vdGUgdGhlIHN1Z2dlc3Rpb24gaW4gdGhlIGNvbW1lbnQgc2VjdGlvbiBhYm92 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5OaXRzOjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPk5v bmUuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzA0MzJGRiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMwNDMyRkYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMDQzMkZGIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMwNDMyRkYiPkhpbWFu c2h1PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E14C9916FE094CA385C7441DDE658524cienacom_-- From nobody Thu Jul 18 18:34:05 2019 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A33461201E3; Thu, 18 Jul 2019 18:33:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Himanshu Shah via Datatracker To: Cc: idr@ietf.org, draft-ietf-idr-bgp-extended-messages.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Himanshu Shah Message-ID: <156350003058.16320.1706123920028504977@ietfa.amsl.com> Date: Thu, 18 Jul 2019 18:33:50 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir telechat review of draft-ietf-idr-bgp-extended-messages-33 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 01:33:51 -0000 Reviewer: Himanshu Shah Review result: Has Nits Summary: I have some suggestions to improve the document by adding more context to the goal of this draft. Comments: The document is concise, clear and easy to read. Since this is my first review as Routing directorate, the suggestions I have, could be out-of-scope. Will leave at the discretion of AD and authors, if suggestions are worth pursuing or not. While Introduction section briefly mentions newer capabilities as the reason for extended message size for the BGP, it may help the reader to expand on the advantages of extended message as compared to current limitation of 4K BGP messages. For me, subsequent reading of the document as it underlines the migration, error cases and security risks, the advantages of extended message size seems to dissipate. I also suggest that authors address issue of extended delay at the receiver in processing of large size BGP messages while TCP’s reliable transport is building a complete message under challenging network conditions and compare that against smaller messages in distressed network. In my view, making a strong case on why extended message size, would greatly add value. Major Issues: No major issues found. Minor Issues: No minor issues found. Please note the suggestion in the comment section above. Nits: See suggestions in comments section From nobody Thu Jul 18 19:42:56 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0CB120142; Thu, 18 Jul 2019 19:42:54 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 oZMUCzSnx5YR; Thu, 18 Jul 2019 19:42:52 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 5464D120116; Thu, 18 Jul 2019 19:42:52 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6J2dbQl017172; Thu, 18 Jul 2019 19:42:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=BeBUyS2Wf62m87SPIi7LY7aG7X8OhbwY1z4YkH/vQGY=; b=yWHKdMuNJ+fQCrXY781WpJbnXknTtxq4CbGqaQ0331fqos3K+BAEWErqGcKq1Bj9G8W0 yad2/I0lOMFXPlQMnX/BRKdFG1hkYdMf3sZnEHCDEg4gA/fvGwv1nGPtmCXBX9Lq/i9n BPPKIlVjUC9oBIviW9d6gl4ObWgBVOFk3EKLmK8cc2PZcW4zt0TdCYKA0WzfX+ZPAO2P mwpOfpykglUBCX5bm+2Kx4PRDG9wOnCgz9Kft5xU37Sye7XBySTn2c+7FSjvWmwQ73Tu KfteZS4iCITWJgMxeibPPe+qMG3KZSsYBiGhQD5V9FPpIkGvsSrS2JS456ttjH12WQc5 VA== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2051.outbound.protection.outlook.com [104.47.37.51]) by mx0a-00273201.pphosted.com with ESMTP id 2ttx4srn28-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jul 2019 19:42:50 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UpYdC8VCgyv1lxmFbTsFhfne5/WK8DAIeAlqLiJJnEGc5L1VfdtP4a2LcYMXACFk6j0SBOhUJ4m91ecTfyzVHIARmkvxzsQQX+fXiAtWZROBWZ1yk5oPAvACyV9oDKnQXIUTa9HTrBM+046b3C/dIwBS28fz7oe6tbe/Us3grMmgNY1SuqGBSAjCISkNi/TBThSlHEarKY5KnN2IuJ+HC7SimTeJ4dntJlmVO7biWG3MnoB4uHCe44KNaW5SURA8ERdvoWIHg3uwr3vhV3sbzTemCTex9LxL4JUZOypm7Eh64vIjQn7JfwPZLn4T/ZyKKbVnZDgQZUKDVIDb3LmC+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BeBUyS2Wf62m87SPIi7LY7aG7X8OhbwY1z4YkH/vQGY=; b=diD0uhYgvWp6/pG1QB5faGwmZB2KCSOUNbkrO7Yj52qW/OieqvS0osbB3z4b+pCkriBNta2l/QqGP7j0z0UKhkgxYKRNaQhs3wlGTHEjuOOLDtZyJmoDmV/oWuE9AKXL2tBBHMp6BMF/rjQ6dDzbJwmoagZaJ/1q/SKou1yIAqQlyZfM1+iP1Ns7489ye8BJXXJQ5r+13JBJPWOcjzVxUpnGWxOw+ZBDHUDq6HoL2pRyYHZ2VFvVlopZIqXlXYMecotr+hvs+8+0zr55U5Jo1yrXF5mSjJUiokSBgXBka8T5EMihGe8KTiO+ana6B21qH7y8Ne56VM4QTxgG6Lb1RQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=juniper.net;dmarc=pass action=none header.from=juniper.net;dkim=pass header.d=juniper.net;arc=none Received: from BYAPR05MB6470.namprd05.prod.outlook.com (20.178.233.83) by BYAPR05MB6135.namprd05.prod.outlook.com (20.178.55.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.8; Fri, 19 Jul 2019 02:42:47 +0000 Received: from BYAPR05MB6470.namprd05.prod.outlook.com ([fe80::29fb:c356:de9a:ed56]) by BYAPR05MB6470.namprd05.prod.outlook.com ([fe80::29fb:c356:de9a:ed56%7]) with mapi id 15.20.2115.005; Fri, 19 Jul 2019 02:42:47 +0000 From: Ravi Singh To: Routing ADs CC: Routing Directorate , "draft-ietf-ospf-yang@ietf.org" , "ospf@ietf.org" Thread-Topic: RtgDir review: draft-ietf-ospf-yang-23.txt Thread-Index: AdU920QESuA90qdgQTa38PuKoaYVVg== Date: Fri, 19 Jul 2019 02:42:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: beb929b9-f578-499a-9f56-08d70bf2c8ed x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB6135; x-ms-traffictypediagnostic: BYAPR05MB6135: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(346002)(376002)(396003)(136003)(39860400002)(199004)(189003)(6116002)(26005)(790700001)(102836004)(53936002)(68736007)(54906003)(9686003)(186003)(6306002)(486006)(55016002)(6436002)(316002)(6506007)(14444005)(478600001)(71190400001)(25786009)(99286004)(256004)(8676002)(71200400001)(81166006)(81156014)(7696005)(4326008)(3846002)(14454004)(54896002)(7736002)(66066001)(74316002)(6916009)(5660300002)(8936002)(86362001)(52536014)(476003)(66476007)(66446008)(66556008)(2906002)(66946007)(64756008)(9326002)(76116006)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6135; H:BYAPR05MB6470.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Ya6o9s8ImD8ZfUJFCpIXVfYVGGUyGI6bnkU1tu/6xD6G61+H1kXEE3jy5+bsZmGgtV/VyqKymuu5CR50LkAfmqFXIAxHVuZOJjSwJcUpDn10YEuKoVkflUvW22AJE3vkq/uf0AHUTrcemNoYDPL091j2ZFyRHRC8boV7DBoJpqPEBjZPkuF6N+Rnv9BYcsUIdZqPQq1JoF2lAq8MUaoQA97Grwk874CWvu7a+C4dqZfKqHMCjKRzuY0xx3rl+0FICMD6gMrNUd23G9023OK7c5fWIhV7JPu2glA5DKBJ/ddDaFwdDi65hGTamTHQNtafPRNpjEE9R702yGLg6bJspNRXOnvsW/XsuaSTRfxq4uVG0lGLoJMY53IHpSXzb3qQ7eAbjGi9b1N7pC4h5bwh3LXqocdLHFAEdDrRs/7kJkA= Content-Type: multipart/alternative; boundary="_000_BYAPR05MB64709E8C4755E255DD723E94ABCB0BYAPR05MB6470namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: beb929b9-f578-499a-9f56-08d70bf2c8ed X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 02:42:47.5482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ravis@juniper.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6135 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-19_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907190029 Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-ospf-yang-23.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 02:42:55 -0000 --_000_BYAPR05MB64709E8C4755E255DD723E94ABCB0BYAPR05MB6470namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtb3NwZi15YW5nLTIzLnR4dA0KUmV2aWV3 ZXI6IFJhdmkgU2luZ2gNClJldmlldyBEYXRlOiA3LzE4LzIwMTkNCkludGVuZGVkIFN0YXR1czog U3RhbmRhcmRzIFRyYWNrDQoNClN1bW1hcnk6DQpUaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSBy ZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRl cmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLg0KDQpUaGlzIGlzIGEgdmVyeSBjb21wcmVoZW5zaXZl bHkgd3JpdHRlbiBkb2N1bWVudC4NCkhvd2V2ZXIsIHJlYWRpbmcgdGhyb3VnaCBpdCBpcyBhIGJp dCBsYWJvcmlvdXMgZHVlIHRvIHRoZSByZWFsbHkgbGFyZ2UgIyBvZiBjb25maWcgYW5kIG9wZXJh dGlvbmFsIGl0ZW1zIGRlc2NyaWJlZC4NClNvLCBteSByZXZpZXcgd2FzIHByaW1hcmlseSBhaW1l ZCBhdCByZWFkYWJpbGl0eSByYXRoZXIgdGhhbiBjb3JyZWN0bmVzcyBvZiB0aGUgWUFORyBzeW50 YXguDQoNClNwZWNpZmljIGNvbW1lbnRzL3F1ZXJpZXM6DQoxLiAgICAgICBXaGF0IGlzIHRoZSBy ZWFzb25pbmcgZm9yIHN0aWNraW5nIHRoZSBtdWx0aS10b3BvbG9neSBzdWItY29udGFpbmVyKHMp IGF0IHRoZSBzYW1lIGxldmVscyBhcyBhcmVhIGluc3RlYWQgb2YgYXQgdGhlIGxldmVsIG9mIHN1 Yi1jb250YWluZXJzIHVuZGVyIGFyZWEocyk/DQoyLiAgICAgICBQZyAyMzogd2h5IGJvdGggKHBy ZWZpeCAicnQtdHlwZXMiOykgYW5kIChwcmVmaXggImlhbmEtcnQtdHlwZXMiOykgPw0KMy4gICAg ICAgUGcgMjUtMjg6ICJmZWF0dXJlIHR3by1wYXJ0LW1ldHJpYyB7IiBhbmQgImZlYXR1cmUga2V5 LWNoYWluIHsiIG1pZ2h0IGJlIHJlYWRqdXN0ZWQgaW4gb3JkZXIgb2YgbGlzdGluZyB0byBtYWtl IGl0IHRoZSBzYW1lIGFzIHRoYXQgaW4gc2VjdGlvbiAyLjQgZm9yIGEgYml0IG9mIGVuaGFuY2Vk IHJlYWRhYmlsaXR5Lg0KDQpSZWdhcmRzDQpSYXZpDQoNCg0K --_000_BYAPR05MB64709E8C4755E255DD723E94ABCB0BYAPR05MB6470namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMw NTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRG NzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIx Mjg0MzA5MDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI1MDAwNjE5MDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJl Y3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg c2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMg dGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29t ZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4NCiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlz IHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3Ig dGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNv dWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29t bWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3Vn aCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nDQogdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1vc3BmLXlhbmctMjMudHh0PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpZXdlcjogUmF2aSBTaW5naDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2aWV3IERhdGU6IDcvMTgvMjAxOTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMg VHJhY2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VtbWFyeTogPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFkeSBmb3Ig cHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHByaW9y IHRvIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgdmVyeSBj b21wcmVoZW5zaXZlbHkgd3JpdHRlbiBkb2N1bWVudC4gPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ib3dldmVyLCByZWFkaW5nIHRocm91Z2ggaXQgaXMgYSBiaXQgbGFib3Jp b3VzIGR1ZSB0byB0aGUgcmVhbGx5IGxhcmdlICMgb2YgY29uZmlnIGFuZCBvcGVyYXRpb25hbCBp dGVtcyBkZXNjcmliZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tbywg bXkgcmV2aWV3IHdhcyBwcmltYXJpbHkgYWltZWQgYXQgcmVhZGFiaWxpdHkgcmF0aGVyIHRoYW4g Y29ycmVjdG5lc3Mgb2YgdGhlIFlBTkcgc3ludGF4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T cGVjaWZpYyBjb21tZW50cy9xdWVyaWVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzE7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2hhdCBpcyB0aGUgcmVh c29uaW5nIGZvciBzdGlja2luZyB0aGUgbXVsdGktdG9wb2xvZ3kgc3ViLWNvbnRhaW5lcihzKSBh dCB0aGUgc2FtZSBsZXZlbHMgYXMgYXJlYSBpbnN0ZWFkIG9mIGF0IHRoZSBsZXZlbCBvZiBzdWIt Y29udGFpbmVycyB1bmRlciBhcmVhKHMpPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGcgMjM6 IHdoeSBib3RoIChwcmVmaXggJnF1b3Q7cnQtdHlwZXMmcXVvdDs7KSBhbmQgKHByZWZpeCAmcXVv dDtpYW5hLXJ0LXR5cGVzJnF1b3Q7OykgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyNy4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBnIDI1LTI4 OiAmcXVvdDtmZWF0dXJlIHR3by1wYXJ0LW1ldHJpYyB7JnF1b3Q7IGFuZCAmcXVvdDtmZWF0dXJl IGtleS1jaGFpbiB7JnF1b3Q7IG1pZ2h0IGJlIHJlYWRqdXN0ZWQgaW4gb3JkZXIgb2YgbGlzdGlu ZyB0byBtYWtlIGl0IHRoZSBzYW1lIGFzIHRoYXQgaW4gc2VjdGlvbiAyLjQgZm9yIGEgYml0IG9m IGVuaGFuY2VkIHJlYWRhYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SYXZp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRp Y2FsLWFsaWduOm1pZGRsZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR05MB64709E8C4755E255DD723E94ABCB0BYAPR05MB6470namp_-- From nobody Thu Jul 18 19:44:22 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72DF120116; Thu, 18 Jul 2019 19:44:12 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.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 5XI6ao3vRx7U; Thu, 18 Jul 2019 19:44:10 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 8DE1C120142; Thu, 18 Jul 2019 19:44:10 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6J2dXwd003576; Thu, 18 Jul 2019 19:44:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=TQU385cO0AjqyKPUjRGTKQISDbHIvFaGjGzLSS7UeCY=; b=TYuAnbGGqR063co/KYYeknFy1UmqoutWATP3N80fsTBH7FjUI5AWcSwSDHIAZmYfYPHu 8ByYu9v9lA5sxpgAh5LgPjAKstt8jKi79xrf5CyM2Rt87YRp7UGSgvZnS0Bd8xPh548K Erf71D1NkHloFonlBjL2csAB6DK9S7VuuuQy0NjCl39lk4GpafUq6yGcpMwzfzJxCppc eX75wsr4ZCGf035tKLlWF9KWthxyAMlkJ8a4gb2UoOA7TAJlpl7lmmmwLGEERDJx+QQY bjokEqgyMXK3KvLycpkR4KPswcldGMmYYMoqO+N/1rtz3xGAqlO2eSWMLoBGpgLTqU7R Kw== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2053.outbound.protection.outlook.com [104.47.37.53]) by mx0a-00273201.pphosted.com with ESMTP id 2ttytk8f5b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Jul 2019 19:44:10 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PX95g/686BzRmHhEC9LuvTUxhitBYADdqUccjX2OQYmbJ7iAV1IykyM+t0uHVePhyCqD7FRLKbC81HhdLIRfePt1KTg+RhSDYC/sYefHEYnROgEbnEFHfyd4C57/3n9OdL8+SQnsQ7w8D/nf6T2stS7u/nWbwI3CpHnwDxEQxp2WgiOXLZCQ2jfVMsxxvcTZ5oqW9y0RdCU5ffm9dPZNG3w+Jap0Jbfq0c2JAZI0puDALqNTY3C4QGMLqwZmd3X2gKxDnY7OtC2pXAhDjZsSAHsx/oE9OKHHbnwhVZcvdEFazd9g5qMC9QOEx/O5TIeIZnTGRivMucdfUwc3kZ178Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TQU385cO0AjqyKPUjRGTKQISDbHIvFaGjGzLSS7UeCY=; b=oDBjedIdjmMYt4sWHooHKyenUpavla/EL5qiifWu2uAsMTc0OcGfDcz6iGgkoVMAc52XwTvJ0jKtJNy19yu987tGr1jEEtlvF6Man6t1WkBZkR9yUjR5n4TwCGxc+RWfGyocJ7Q2Eu5Img6Hl3G41eC1kTHTGS7ojZGCQt/C/K5yo7ZBPxj+aoahnVTK9FtARkMzBQF4QlXgyFILY9K1QsRaUHJ6IfaJLWtm1wr5PZ9EF9raPsBUcq63c45tVQV3k1KvYcyzmAifn+1wH2xIlfURTluOb+edMG232/f995t6o7UDYE8aU/FQPWMYGjGx62ersJ3Skk0gKAnSc6Toow== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=juniper.net;dmarc=pass action=none header.from=juniper.net;dkim=pass header.d=juniper.net;arc=none Received: from BYAPR05MB6470.namprd05.prod.outlook.com (20.178.233.83) by BYAPR05MB6135.namprd05.prod.outlook.com (20.178.55.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.8; Fri, 19 Jul 2019 02:44:07 +0000 Received: from BYAPR05MB6470.namprd05.prod.outlook.com ([fe80::29fb:c356:de9a:ed56]) by BYAPR05MB6470.namprd05.prod.outlook.com ([fe80::29fb:c356:de9a:ed56%7]) with mapi id 15.20.2115.005; Fri, 19 Jul 2019 02:44:07 +0000 From: Ravi Singh To: Routing ADs CC: Routing Directorate , "draft-ietf-ospf-yang@ietf.org" , "lsr@ietf.org" Thread-Topic: RtgDir review: draft-ietf-ospf-yang-23.txt Thread-Index: AdU920QESuA90qdgQTa38PuKoaYVVgAAHxeg Date: Fri, 19 Jul 2019 02:44:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 28b22b75-7880-4daf-0949-08d70bf2f8a1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB6135; x-ms-traffictypediagnostic: BYAPR05MB6135: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(346002)(376002)(396003)(136003)(39860400002)(199004)(189003)(6116002)(2940100002)(26005)(790700001)(102836004)(53936002)(606006)(68736007)(6246003)(54906003)(9686003)(186003)(6306002)(486006)(55016002)(6436002)(316002)(236005)(6506007)(14444005)(478600001)(71190400001)(229853002)(53546011)(25786009)(99286004)(256004)(8676002)(71200400001)(81166006)(81156014)(7696005)(4326008)(3846002)(14454004)(54896002)(7736002)(66066001)(74316002)(76176011)(6916009)(446003)(5660300002)(8936002)(86362001)(52536014)(476003)(66476007)(66446008)(66556008)(2906002)(66946007)(64756008)(11346002)(76116006)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6135; H:BYAPR05MB6470.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: r3diuG8uqPyotUWuIei+9tUQEXPU/JEp3whUZh/8cndtWSbRVs8YwYqUlOU3uNWY/jx9puMx3aQI9KxOGybRt3uu1hclZY0+N0epXggIgu6ihxfFENUrKTzAoCD4zCBOYGR3WhXGouOOe2zU9284MWqy8shfsFgI0a3QPJv2EOB/2Ibe0+fcvdFMCBSUz3BcWepf3vryyKTWCmqNXqh7V+sEPlt8ojv8xPwSKrizvZCcGSmyo/F4FZmK/ELeU/h8hGQd31EXelBttw1n1052L2vXrbiYzwBncW/RsHSSriWIjk7DBWgt2ZzXrUvKIT0ZZjcDIGrVt9o7WMTIZmzddCyibNU0AJ5QrthPdv4ThPnrmHoqZwbNy7djqtfa4A35B+PSAKUEhLEi6iz/Ri6r4z93TU1tcbDvjEuaZpPvQ3s= Content-Type: multipart/alternative; boundary="_000_BYAPR05MB647024C782C69AEEA55D1B4AABCB0BYAPR05MB6470namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 28b22b75-7880-4daf-0949-08d70bf2f8a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 02:44:07.4470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ravis@juniper.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6135 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-19_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907190029 Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ospf-yang-23.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 02:44:13 -0000 --_000_BYAPR05MB647024C782C69AEEA55D1B4AABCB0BYAPR05MB6470namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KyBsc3JAaWV0Zi5vcmcNCg0KRnJvbTogUmF2aSBTaW5naA0KU2VudDogVGh1cnNkYXksIEp1bHkg MTgsIDIwMTkgNzo0MyBQTQ0KVG86IFJvdXRpbmcgQURzIDxydGctYWRzQHRvb2xzLmlldGYub3Jn Pg0KQ2M6IFJvdXRpbmcgRGlyZWN0b3JhdGUgPHJ0Zy1kaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRm LW9zcGYteWFuZ0BpZXRmLm9yZzsgb3NwZkBpZXRmLm9yZw0KU3ViamVjdDogUnRnRGlyIHJldmll dzogZHJhZnQtaWV0Zi1vc3BmLXlhbmctMjMudHh0DQoNCkhlbGxvLA0KDQpJIGhhdmUgYmVlbiBz ZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFm dC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9y IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNh bGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhl IHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJv dXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3Rv cmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90 cmFjL3dpa2kvUnRnRGlyDQoNCkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlv dSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxs IGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRo cm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQoNCkRvY3VtZW50OiBk cmFmdC1pZXRmLW9zcGYteWFuZy0yMy50eHQNClJldmlld2VyOiBSYXZpIFNpbmdoDQpSZXZpZXcg RGF0ZTogNy8xOC8yMDE5DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KDQpTdW1t YXJ5Og0KVGhpcyBkb2N1bWVudCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBi dXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBwdWJsaWNhdGlv bi4NCg0KVGhpcyBpcyBhIHZlcnkgY29tcHJlaGVuc2l2ZWx5IHdyaXR0ZW4gZG9jdW1lbnQuDQpI b3dldmVyLCByZWFkaW5nIHRocm91Z2ggaXQgaXMgYSBiaXQgbGFib3Jpb3VzIGR1ZSB0byB0aGUg cmVhbGx5IGxhcmdlICMgb2YgY29uZmlnIGFuZCBvcGVyYXRpb25hbCBpdGVtcyBkZXNjcmliZWQu DQpTbywgbXkgcmV2aWV3IHdhcyBwcmltYXJpbHkgYWltZWQgYXQgcmVhZGFiaWxpdHkgcmF0aGVy IHRoYW4gY29ycmVjdG5lc3Mgb2YgdGhlIFlBTkcgc3ludGF4Lg0KDQpTcGVjaWZpYyBjb21tZW50 cy9xdWVyaWVzOg0KMS4gICAgICAgV2hhdCBpcyB0aGUgcmVhc29uaW5nIGZvciBzdGlja2luZyB0 aGUgbXVsdGktdG9wb2xvZ3kgc3ViLWNvbnRhaW5lcihzKSBhdCB0aGUgc2FtZSBsZXZlbHMgYXMg YXJlYSBpbnN0ZWFkIG9mIGF0IHRoZSBsZXZlbCBvZiBzdWItY29udGFpbmVycyB1bmRlciBhcmVh KHMpPw0KMi4gICAgICAgUGcgMjM6IHdoeSBib3RoIChwcmVmaXggInJ0LXR5cGVzIjspIGFuZCAo cHJlZml4ICJpYW5hLXJ0LXR5cGVzIjspID8NCjMuICAgICAgIFBnIDI1LTI4OiAiZmVhdHVyZSB0 d28tcGFydC1tZXRyaWMgeyIgYW5kICJmZWF0dXJlIGtleS1jaGFpbiB7IiBtaWdodCBiZSByZWFk anVzdGVkIGluIG9yZGVyIG9mIGxpc3RpbmcgdG8gbWFrZSBpdCB0aGUgc2FtZSBhcyB0aGF0IGlu IHNlY3Rpb24gMi40IGZvciBhIGJpdCBvZiBlbmhhbmNlZCByZWFkYWJpbGl0eS4NCg0KUmVnYXJk cw0KUmF2aQ0KDQoNCg== --_000_BYAPR05MB647024C782C69AEEA55D1B4AABCB0BYAPR05MB6470namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMw NTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRG NzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjEyODQzMDkwODsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MjUwMDA2MTkwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+JiM0 MzsgbHNyQGlldGYub3JnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJhdmkgU2luZ2ggPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDE4LCAyMDE5IDc6NDMgUE08YnI+DQo8Yj5Ubzo8 L2I+IFJvdXRpbmcgQURzICZsdDtydGctYWRzQHRvb2xzLmlldGYub3JnJmd0Ozxicj4NCjxiPkNj OjwvYj4gUm91dGluZyBEaXJlY3RvcmF0ZSAmbHQ7cnRnLWRpckBpZXRmLm9yZyZndDs7IGRyYWZ0 LWlldGYtb3NwZi15YW5nQGlldGYub3JnOyBvc3BmQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtb3NwZi15YW5nLTIzLnR4dDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmll d2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZp ZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhy b3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3Bl Y2lhbCByZXF1ZXN0Lg0KIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBh c3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLPGEgaHJlZj0iaHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+aHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhl IHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxk IGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVu dHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBk aXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nDQogdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1vc3BmLXlhbmctMjMudHh0PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpZXdlcjogUmF2aSBTaW5naDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2aWV3IERhdGU6IDcvMTgvMjAxOTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJh Y2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VtbWFyeTogPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVi bGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHByaW9yIHRv IHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgdmVyeSBjb21w cmVoZW5zaXZlbHkgd3JpdHRlbiBkb2N1bWVudC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3dldmVyLCByZWFkaW5nIHRocm91Z2ggaXQgaXMgYSBiaXQgbGFib3Jpb3Vz IGR1ZSB0byB0aGUgcmVhbGx5IGxhcmdlICMgb2YgY29uZmlnIGFuZCBvcGVyYXRpb25hbCBpdGVt cyBkZXNjcmliZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgbXkg cmV2aWV3IHdhcyBwcmltYXJpbHkgYWltZWQgYXQgcmVhZGFiaWxpdHkgcmF0aGVyIHRoYW4gY29y cmVjdG5lc3Mgb2YgdGhlIFlBTkcgc3ludGF4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVj aWZpYyBjb21tZW50cy9xdWVyaWVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2hhdCBpcyB0aGUgcmVhc29u aW5nIGZvciBzdGlja2luZyB0aGUgbXVsdGktdG9wb2xvZ3kgc3ViLWNvbnRhaW5lcihzKSBhdCB0 aGUgc2FtZSBsZXZlbHMgYXMgYXJlYSBpbnN0ZWFkIG9mIGF0IHRoZSBsZXZlbCBvZiBzdWItY29u dGFpbmVycyB1bmRlciBhcmVhKHMpPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGcgMjM6IHdo eSBib3RoIChwcmVmaXggJnF1b3Q7cnQtdHlwZXMmcXVvdDs7KSBhbmQgKHByZWZpeCAmcXVvdDtp YW5hLXJ0LXR5cGVzJnF1b3Q7OykgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyNy4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8yO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBnIDI1LTI4OiAm cXVvdDtmZWF0dXJlIHR3by1wYXJ0LW1ldHJpYyB7JnF1b3Q7IGFuZCAmcXVvdDtmZWF0dXJlIGtl eS1jaGFpbiB7JnF1b3Q7IG1pZ2h0IGJlIHJlYWRqdXN0ZWQgaW4gb3JkZXIgb2YgbGlzdGluZyB0 byBtYWtlIGl0IHRoZSBzYW1lIGFzIHRoYXQgaW4gc2VjdGlvbiAyLjQgZm9yIGEgYml0IG9mIGVu aGFuY2VkIHJlYWRhYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5S ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SYXZpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2Fs LWFsaWduOm1pZGRsZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BYAPR05MB647024C782C69AEEA55D1B4AABCB0BYAPR05MB6470namp_-- From nobody Fri Jul 19 09:26:04 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AF4120738; Fri, 19 Jul 2019 09:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 rF6fPoOakymI; Fri, 19 Jul 2019 09:25:59 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 59ED4120845; Fri, 19 Jul 2019 09:25:59 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id k8so34964978edr.11; Fri, 19 Jul 2019 09:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=r4N0hhdnwHykrrT2Z/fCGYQTD75PQgWh0WnAMUfOPWo=; b=Bazn1PvMAHJz9K7p1n/6N/3GdRdpUNagug/4zPR2+5aXsSuxqYD7mLYBji8M5JmlnZ cj4UJkoAGwdcIenl61s9APYACL3XWZ2Inot3yYeyyYVz3gd+HEfFgHJmg9byb/0bRw+B OVpOjRJ8hXUcYNiBR/zdSNbt1b1U44TPStICnEdvu5UJwf+4Urbxp3kb/qI9fX/m236x sZePlDAlthcNBCvl7XS2opmgUTUfrWOrscdMUF7w1NKL+/zftMfoE1fM+zxAJxKS8jTi crIVB5hnX7nlfWg2QB9Xd9M3xJ4CKuArbK5bduL8DeVrVV0Uk1fgxtmK4PdWUS+SnMhy WO2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=r4N0hhdnwHykrrT2Z/fCGYQTD75PQgWh0WnAMUfOPWo=; b=KlA4qHRjncqk1SNhmuHpp4x99xunoYfzq/uz8edJYK8Mv4d+ufbv3FWAU9FcdkHgas sUslcBsFIU7KGKBMGx+HV7TJt2PPgUpUBF+Ni9GNlHEuZDCsWfPe56iY1h3uZkRd0KNp zUSI6Of4T8DPFehMSHCGFQ+t6hd6hgxC2lbtybxsIVe7Q0DhMGnFdjsbwUu54S/U3LOA kqjUcar2tNytWWwG0RNbhgZlkm6NPCY7E/HzoSUl81f0F5QuXx0ppP+CySxs+r/tKXI3 F5TxRxwnvwuNeD3uxdLOyuBhc8xiVGuEZF6YEVlK+jUMKvYZZHVZAZlW3Cq8Jl2SJwGE 4pLQ== X-Gm-Message-State: APjAAAVEl+72BHIUqLho5AztQzl/gqp5bHhMm5BKezhC1DlgMfJ9bj9u GydqmCD3Px/cpHoZexMTiGL7H45ytgCY89YFGVgNt0Db2g8= X-Google-Smtp-Source: APXvYqwa1oBU0tfOxkreI68aytb+fvba2CDCuZOaJv1N9zAwk2nosMeX3zvX/sJGv6UI3x0fc5ahYUUDdfuutHsnMzE= X-Received: by 2002:a50:a5ec:: with SMTP id b41mr46003219edc.52.1563553557988; Fri, 19 Jul 2019 09:25:57 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 19 Jul 2019 09:25:57 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 19 Jul 2019 09:25:57 -0700 Message-ID: To: "Shah, Himanshu" , "" Cc: "draft-ietf-idr-bgp-extended-messages.all@ietf.org" , "idr@ietf.org" , "rtg-dir@ietf.org" Content-Type: multipart/alternative; boundary="000000000000694c62058e0b2ef7" Archived-At: Subject: Re: [RTG-DIR] RtgDir review : draft-ietf-idr-bgp-extended-messages-33.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 16:26:03 -0000 --000000000000694c62058e0b2ef7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Himanshu: Thanks for the review! Alvaro. On July 18, 2019 at 10:31:08 PM, Shah, Himanshu (hshah@ciena.com) wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-idr-bgp-extended-messages-33.txt Reviewer: Himanshu Shah Review Date: 18 July 2019 IETF LC End Date: Unknown Intended Status: Standards Track Summary: I have some suggestions to improve the document by adding more context to the goal of this draft. Comments: The document is concise, clear and easy to read. Since this is my first review as Routing directorate, the suggestions I have, could be out-of-scope. Will leave at the discretion of AD and authors, if suggestions are worth pursuing or not. While Introduction section briefly mentions newer capabilities as the reason for extended message size for the BGP, it may help the reader to expand on the advantages of extended message as compared to current limitation of 4K BGP messages. For me, subsequent reading of the document as it underlines the migration, error cases and security risks, the advantages of extended message size seems to dissipate. I also suggest that authors address issue of extended delay at the receiver in processing of large size BGP messages while TCP=E2=80=99s reliable transport is building a complete mess= age under challenging network conditions and compare that against smaller messages in distressed network. In my view, making a strong case on why extended message size, would greatly add value. Major Issues: No major issues found. Minor Issues: No minor issues found. Please note the suggestion in the comment section above. Nits: None. *Thanks,* *Himanshu* --000000000000694c62058e0b2ef7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Himanshu:

Thanks for the review!

Alvaro.

On July 18,= 2019 at 10:31:08 PM, Shah, Himanshu (hs= hah@ciena.com) wrote:

=

Hello,

=C2=A0

I have been selected as the Rout= ing Directorate reviewer for this draft.=

The Routing Directorate seeks to= review all routing or routing-related

drafts as they pass through IETF= last call and IESG review, and

sometimes on special request. Th= e purpose of the review is to provide

assistance to the Routing ADs. F= or more information about the Routing

Directorate, please see

=E2=80=8Bhttp://trac.too= ls.ietf.org/area/rtg/trac/wiki/RtgDir

=C2=A0

Although these comments are prim= arily for the use of the Routing ADs, it=

would be helpful if you could co= nsider them along with any other IETF

Last Call comments that you rece= ive, and strive to resolve them through<= /span>

discussion or by updating the dr= aft.

=C2=A0

Document: draft-ietf-idr-bgp-ext= ended-messages-33.txt

Reviewer:= Himanshu Shah=C2=A0

Review Date: 18 July 2019=

IETF LC End Date: Unknown=

Intended Status: Standards Track=

=C2=A0

Summary:= =C2=A0

=C2=A0

I have so= me suggestions to improve the document by adding more context to the goal o= f this draft.=C2=A0

=C2=A0

Comments:=

=C2=A0

The docum= ent is concise, clear and easy to read.

=C2=A0

Since thi= s is my first review as Routing directorate, the suggestions I have,

could be = out-of-scope. Will leave at the discretion of AD and authors, if suggestion= s are worth pursuing or not.

=C2=A0

While Int= roduction section briefly mentions newer capabilities as the reason for ext= ended

message s= ize for the BGP, it may help the reader to expand on the advantages of exte= nded message

as compar= ed to current limitation of 4K BGP messages.=C2=A0 For me, subsequent readi= ng of the

document = as it underlines the migration, error cases and security risks, the advanta= ges of

extended = message size seems to dissipate.

=C2=A0

I also su= ggest that authors address issue of extended delay at the receiver in proce= ssing of large size BGP

messages = while TCP=E2=80=99s reliable transport is building a complete message under= challenging

network c= onditions and compare that against smaller messages in distressed network.<= /span>

=C2=A0

In my vie= w, making a strong case on why extended message size, would greatly add val= ue.

=C2=A0

=C2=A0Maj= or Issues:

=C2=A0

No major = issues found.

=C2=A0

Minor Iss= ues:

=C2=A0

No minor = issues found. Please note the suggestion in the comment section above.

=C2=A0

Nits:

=C2=A0

None.=C2= =A0

=C2=A0

= =C2=A0

=C2=A0

Thanks,

Himanshu

--000000000000694c62058e0b2ef7-- From nobody Fri Jul 19 18:36:48 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34118120120 for ; Fri, 19 Jul 2019 18:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfxBXuP02zmy for ; Fri, 19 Jul 2019 18:36:39 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 16A09120121 for ; Fri, 19 Jul 2019 18:36:38 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id v15so35936123eds.9 for ; Fri, 19 Jul 2019 18:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=z4yh64BG5iwvy4L53vE1lewVUCeVttVXnwF3xIy9zKg=; b=Gy54yFD/RivBHY2h2vRwtIE+4E2JTnW67NH50r7gg+ugzjdehlTqng3gNmPP8J7y1Q +DxvYPNqBCPDD7TMhhTk8nSsijGiP/R7ZP0ZDX3AZg1AQW3/JHIQgsEVtKSWEAgCHXRo nGEjO7e0dHbMyH9AvgXCbhv9GKAyzY1fB62p9SFbotblknydeJzprALhnu9GzOHBZGEU rDmllKeyDfjPEmL4j5qLqMaWTHJ9zYlyhTqm0DGcVXUG+tKoihNlIj37rLMtn6QAbvnA zE451nixekdiF+4Ie3HiqCvbsteUEtOglNRoj7SoM9HNKu3U/F2PPXiQ7fuwREwTw+Fj QD/A== 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=z4yh64BG5iwvy4L53vE1lewVUCeVttVXnwF3xIy9zKg=; b=RlOtHHgH7pMgWuy0jE/5l6pKlGVVl2qXYM15873l6/2IUuN0p7ivwZIhF97jkyLINp RXTjWGWIrd1bwKzmC9RsQO/3yQKx/xHC7VW6yVBlKnQ0aIWOg4y6g/ozKVPuqpcH2TSq TzAPOPwxWSgQ7LDTVVQhq0gguJTm4SPZreaHByLZYeVoz0wMcu+uOQODW15p8W76GjDP W6YQw7qJKGkaYCQo/o2I/0ZrxJRg27adp6e+W/fAT8pJW4vUIabDaxCvODwToVNbiZPO x4nQJ7tcNfsNF3vRLTUN+2KXxxrmdAKSf37HW847T8CliaP6RVHbpA5aOXzA4Z7P9Y7f 3Wyw== X-Gm-Message-State: APjAAAWvPhQ8yL4yaNEaBtvVU3dOEm1mJnztBF/o8v3RxGsQJFvKi16+ +94PjaZTxT3HMEc2fwxR1kENoyip2ZjlvC4hrwY= X-Google-Smtp-Source: APXvYqwMi3IeVdmHGCaSLtW1D/nUAfddjs0FpU6OC6yu0mtJqjRsOQtv1qBDmn77eep2a5B529l3+9THJ7kL8SRKsWQ= X-Received: by 2002:a17:906:b6ce:: with SMTP id ec14mr32902996ejb.81.1563586596661; Fri, 19 Jul 2019 18:36:36 -0700 (PDT) MIME-Version: 1.0 From: Stig Venaas Date: Fri, 19 Jul 2019 18:36:25 -0700 Message-ID: To: "" Cc: rtg-dir@ietf.org, draft-ietf-intarea-frag-fragile.all@ietf.org, int-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-intarea-frag-fragile-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 01:36:41 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-intarea-frag-fragile-15.txt Reviewer: Stig Venaas Review Date: 19 July 2019 IETF LC End Date: 19 July 2019 Intended Status: Best Current Practice Summary: No issues found. This document is ready for publication. Comments: The document is in great shape. It is easy to read and of good quality. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: I noticed that in section 2.1 the word "While" is spelled "Whlie". Regards, Stig From nobody Tue Jul 23 12:33:49 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDEE12090C; Tue, 23 Jul 2019 12:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=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=messagingengine.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 nGq2N2e8ol10; Tue, 23 Jul 2019 12:33:37 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E7C12084D; Tue, 23 Jul 2019 12:33:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 85A1261F; Tue, 23 Jul 2019 15:33:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 23 Jul 2019 15:33:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=76vP4D 3jRRMRNNRnjPEbmSY8KOURTZJRL1GYuJd8UKM=; b=cPsihbD6t17CZPV9lpO1Pe /12BkC+bQRUfzlUwUMcpUEdWkzn7Rj+UmzMbvPi4Rq793AiffeFLN54A4vSXjaI0 8yNZ7ZBQWT/IvC45kUrp9SxzOdddzFcz1RNkbFvlMIL9aEQlJNp0d7/3ICPoJfJo zBpIgvGdMoyn0zhnl7sIIA6psK8iqpgYiNxkAbcjOOPLJkNKJFKZMzeq2AGlcE0G 7TRjp0YC+E0CGBziUZgycLyTF3XSuPFR9fUFQNlN2NQPfQmH4xqz8RVtt1ble+eW P+d4dZ/SZZdGjta7b1W6ClTi5upBFa/8GkRlZBDVXlpQNDrPOxi0Oq5f8ER6SDnw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrjeekgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkgggtgffothesthhqgh dtvddtjeenucfhrhhomhepoehruhhsshesrhhifidruhhsqeenucffohhmrghinhepihgv thhfrdhorhhgnecukfhppeefuddrudeffedrudefkedrudeijeenucfrrghrrghmpehmrg hilhhfrhhomheprhhushhssehrihifrdhushenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from RussPC (dhcp-8aa7.meeting.ietf.org [31.133.138.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A67080060; Tue, 23 Jul 2019 15:33:34 -0400 (EDT) From: To: , Cc: , Date: Tue, 23 Jul 2019 15:33:34 -0400 Message-ID: <097e01d5418d$847ee300$8d7ca900$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdVBjP5d4GzHvFj0ReaDFe2tM6C8FA== Content-Language: en-us Archived-At: Subject: [RTG-DIR] RtgDir Early review: draft-ietf-rift-rift-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 19:33:47 -0000 Hello I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D = review of this draft.=20 =E2=80=8Bhttps://datatracker.ietf.org/doc/draft-foo-name/ The routing directorate will, on request from the working group chair, = perform an =E2=80=9Cearly=E2=80=9D review of a draft before it is = submitted for publication to the IESG. The early review can be performed = at any time during the draft=E2=80=99s lifetime as a working group = document. The purpose of the early review depends on the stage that the = document has reached. As this document has recently been adopted by the working group, my = focus for the review is on providing a new perspective on the work, with = the intention of catching any issues early on in the document's life = cycle. For more information about the Routing Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-rift-rift-06 Reviewer: Russ White Review Date: 23 July 2019 Intended Status: Standards Track Summary:=20 I have significant concerns about this document. It needs more work = before being submitted to the IESG. Comments: Overall this draft is very readable, although I have suggested wording = changes below. The protocol described is useful and interesting. I = largely have questions about the structure and wording of the draft, = although there are a couple of technical questions in the comments below = (probably just things I missed the explanation for, however). Structurally, this document almost feels like two different documents. = The first specifies a set of use cases and requirements, while the = second specifies a protocol. I wonder if it wouldn't be better to split = this document into two pieces, making each one more specific, and = possibly a bit easier to read? We might too late in the process to make = such a change -- if so, that's okay, just thought it might be worth = considering. Throughout -- "fat tree," "Clos," and other terms are used in various = places. As a reader, given the different meanings for these terms, I = found this a bit confusing. It might be better to use "spine and leaf" = throughout. Throughout -- the term "folded" has two very different meanings... The = first is a multistage fabric on which traffic flows bi-directionally, = the second is a way of drawing spine and leaf fabrics in blocks. It = might be useful to clarify this from the beginning somehow, so readers = who are expecting one meaning don't misread things because a different = meaning is intended (?). I think it's always used here in the "way of = drawing a spine and leaf fabric" here. =3D=3D Page 9 The definitions of the various forms of TIE might be better if they = clearly differentiated between topology and reachability information = (?). The OSPF router LSA, for instance, contains both kinds of = information. In IS-IS, adjacencies, which are called Node TIES (I think) = are tlv22, while the Prefix TIE would be a tlv128 and 236. I don't think = there is an equivalent separation between topology (reachable neighbors) = and reachability (reachable prefixes) in OSPF.=20 =3D=3D REQ13: "Taking a path through the spine in cases where a shorter path is = available is highly undesirable." This doesn't seem to be related to the previous statements in the = requirement... Not certain this needs to be included? Or maybe it wants = to be someplace else in the list? =3D=3D REQ10 and REQ13 both seem to say the same thing -- although REQ13 is = better worded. Maybe both of these are not needed? =3D=3D REQ15: "...links of a single node having same addresses." -- might be = better as "...links of a single node sharing the same address." =3D=3D REQ18: "...security mechanisms that allow to restrict nodes, especially = leafs without proper credentials from forming three-way adjacencies." Might be better as: "...security mechanisms that allow the operator to restrict nodes, = especially leaf nodes without proper credentials, from forming a = three-way adjacency." =3D=3D PEND2: 500,000 seems way too small for the scale numbers I've heard in = the past -- especially if we are including the underlay protocol running = on the hosts in the mix. If there are 300k ports is at least 1 prefix = per edge port, and potentially 10-15 prefixes per edge port. If you = guess around 20% of the workloads attached to the fabric might be = mobile, then the number here is more likely 1 million at the base, with = a top end of around 2-3 million prefixes. It might be worth adjusting = this number a bit larger (?). =3D=3D Section 5, paragraph after the header "...when "pointing north" and path vector [RFC4271] protocol when = "pointing south". While this is an unusual combination,..." Elsewhere in the document "distance-vector" is used. It might be better = to be consistent? =3D=3D Section 5.1.1 In the first paragraph ("The most singular property..."), omitting = east-west control plane information flow is mentioned twice; could = probably just be once. The first sentence in the second paragraph is a bit of a run-on; might = be best to omit some of this, or break it into two sentences. Second paragraph: "The application of those principle lead to RIFT..." = doesn't seem right. Might be better as: "The application of these = principles lead to RIFT..." =3D=3D Section 5.1.2, paragraph beginning: "Given the difficulty of visualizing = multi plane design which are..." First, this is one long sentence. = Second, what's illustrated looks like a crossbar, but it's not a = crossbar. I find this a little confusing (?). The problem is -- I don't = know of another term to use here. =3D=3D Section 5.1.2, paragraph beginning: "The typical topology for which RIFT = is defined is built of a number P..." This seems to describe a five = stage butterfly or pod-and-spine fabric, but does not seem to describe a = seven stage (?). Overall -- I'm not certain trying to describe these topologies at this = level in a protocol specification draft is all that useful. The = terminology is fluid (used by different people in different ways), and = this depth of explanation does not seem to be useful to describe the = protocol operation. This is one place where splitting the document into = two pieces might be helpful. =3D=3D Paragraph beginning: "It is critical at this junction that the concept = and the picture of..." What is shown is not really a crossbar fabric... = I'm not certain calling this a crossbar is helpful here (?). =3D=3D Section 5.1.4: "This happens naturally in single plane design but needs = additional considerations in multiplane fabrics." When aggregation is = used, as well -- but not when no aggregation of reachability information = is deployed in the fabric. It might be worth adding that qualification = here. =3D=3D Section 5.1.4 Sentence beginning: "In more detail, by reserving two ports on each = Top-of-Fabric node it is possible to connect them together in an = interplane bi-directional ring as illustrated in Figure 13..." I might have missed it, but this document does not seem to address how = traffic will be prevented from flowing through these links. It's = probably important to note either that traffic will flow along these = links, hence they need to be sized appropriately, or how traffic is = prevented from flowing along these links.=20 =3D=3D Section 5.1.5 Sentence beginning: "The effect of a positive disaggregation..." If = positive deaggregation takes place, it could draw all the traffic to the = deaggregated destinations along a small set of links, causing a hot spot = in the fabric. This might be taken care of "naturally" in the way RIFT = does positive deaggregation, but it might be good to explain this in the = document. A more general observation: positive deaggregation, as described in the = document, can potentially cause cascading failures where a group of = links or nodes fail, causing a lot of new information to be pushed into = lower levels rather quickly, which could potentially cause those nodes = to overrun their table or processing space and fail in turn, causing = more information to be dumped into the control plane, etc. It may be = worth connsidering having some form of "hysteresis," timer or other = mechanism to prevent cascading failures of this kind. =3D=3D Section 5.2.2 "All RIFT routers MUST support IPv4 forwarding and MAY support IPv6..." So an IPv6 only fabric is not possible?=20 =3D=3D Section 5.2.6 "After the SPF is run, it is necessary to attach according prefixes." I think this might want to mean -- "After SPF is run, it is necessary to attach the resulting reachability = information in the form of prefixes."=20 (?) =3D=3D Section 5.2.6 It seems like the first and third paragraphs describe the same = procedure? Are both descriptions necessary? =3D=3D Section 5.2.6 "An exemplary implementation..." should probably be "an example = implementation..." ?? =3D=3D Section 5.2.6 "After the positive prefixes are attached and tie-broken, negative = prefixes are attached and used in case of northbound computation, = ideally from the shortest length to the longest." It seems like the prefixes should be "tie-broken" before being attached. = This sentence is generally confusing, perhaps: "After the positive prefixes have been attached, the negative prefixes = will be attached in their prefix-length order (from the shortest to the = longest). These negative prefixes will only be used when computing = northbound reachability." =3D=3D Section 5.2.6 "Observe that despite seeming quite computationally expensive the = operations are only necessary if the only available advertisements for a = prefix are negative since tie-breaking always prefers positive = information for the prefix which stops any kind of recursion since = positive information never inherits next hops." Just because something is not done all that often does not mean it's not = computationally expensive. :-) Maybe something like this would be = better: "Although these operations can be computationally expensive, the overall = load on devices in the network is low because these computations are not = run very often, as positive route advertisements are always preferred = over negative ones. This prevents recursion in most cases because = positive reachability information never inherits next hops." Or something like this? =3D=3D Section 5.2.6 "Negative 2001:db8::/32 entry inherits from" Probably wants to be "The negative 2001:db8::/32 entry..." =3D=3D Section 5.2.6 "Finally, let us look at the case where S3 becomes available again as = default gateway, ..." "...the default gateway..." or "...a default gateway..." =3D=3D Section 5.2.7 "Each RIFT node can optionally operate in zero touch provisioning..." "optionally" is not needed here =3D=3D Section 5.2.7.2 "RIFT identifies each node via a SystemID which is a 64 bits wide = integer. It is relatively simple to derive a, for all practical purposes = collision free, value for each node on startup. For that purpose, a node = MUST use as system ID EUI-64 MA-L format [EUI64] where the = organizationally governed 24 bits can be used to generate system IDs for = multiple RIFT instances running on the system." This seems too wordy -- maybe: "RIFT nodes require a 64 bit SystemID in the EUI-64 MA-L format formed = as described in [EUI64]. The organizationally goverened portion of this = ID (24 bits) can be used to generate multiple IDs if required to = indicate more than one RIFT instance." =3D=3D Section 5.3.1 "Overload Bit MUST be respected..." should be=20 "The overload bit MUST be respected..." =3D=3D Section 5.3.2 "Since the leafs do see only "one hop away" they do not need to run a = full SPF but can simply gather prefix candidates from their neighbors = and build the according routing table." Seems like this should be=20 "Since leaf nodes only have one hop of topology information, they do not = need to run SPF. Instead, they can gather the available prefix = candidates and build the routing table accordingly." =3D=3D Section 5.3.3 "time stamp: With this method, the infrastructure memorizes the..." I think the correct word here is "records," rather than "memorizes" (?) =3D=3D Section 5.3.3 "sequence counter: With this method, a mobile node notifies its = point..." Another problem here is the node might not "know" it has been moved from = one location to another in the fabric, particularly if a layer 2 only = attached process is moved along with it's ARP cache, and something like = the EVPN default MAC is used to enable the move. I don't know if this is = worth mentioning, but it does seem like a case that needs to be thought = about to make certain it works with the process described. =3D=3D Section 5.3.3 "The leaf node MUST advertise a time stamp of the latest sighting..." Is this for all prefixes, or just for prefixes that are somehow marked = or configured as potentially mobile on the fabric? =3D=3D Section 5.3.3 "RIFT also defines an abstract negative clock (ANSC) that compares as = less than any other clock." Does this mean lower priority, or always older than any other clock? It = seems like this means "older" based on 5.3.3.1, but the language could = probably be clearer. =3D=3D Section 5.3.3 One thing not covered here is what happens if some workload moves = between two RIFT fabrics interconnected via some other protocol, such as = BGP. It seems the most obvious solution is to have RIFT treat = redistributed destinations the same as directly attached destinations in = terms of clocks, etc., but this is not called out in the document. It = might be worth mentioning. =3D=3D Section 5.3.3.3 This section seems a little ... muddled? You want to both have the = ability to use only the most recently available versions of any anycast = destination, while also not requiring all the anycast advertisements to = have the same time stamp (?). I'm not certain this section entirely = solves that problem. This sentence might be creating the confusion in my = reading of the section, as I don't really understand what it is saying:=20 "An anycast prefix does not carry a clock or all clock attributes MUST = be the same under the rules of Section 5.3.3.1." MUST be treated the same as prefixes advertised under the rules of = 5.3.3.1? I'm not certain. =3D=3D Section 5.3.3.4 "RIFT is agnostic whether any overlay technology like [MIP, LISP, VxLAN, = NVO3] and the associated signaling is deployed over it. But it is = expected that leaf nodes, and possibly Top-of-Fabric nodes can perform = the according encapsulation." "according" should be "correct," I think.=20 =3D=3D Section 5.3.6.1 "All the multiplications and additions are saturating, i.e. when = exceeding range of the bandwidth type are set to highest possible value = of the type." Maybe better: "If a calculation produces a result exceeding the range of the type, the = result is set to the highest possible value for that type." From nobody Tue Jul 23 13:27:24 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB10E120950; Tue, 23 Jul 2019 13:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=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 kN5_U66O6vty; Tue, 23 Jul 2019 13:27:17 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 C82331203C2; Tue, 23 Jul 2019 13:27:13 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id s49so10309358edb.1; Tue, 23 Jul 2019 13:27:13 -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=GwyPMv1j9avH8Vnfm3Rmt3e1Fpn0qM+URyG5VmS8ZRw=; b=MXAh9Uk/uDFl0zGFzjX9HuNF3HgsVD1uauZHLlCQ5VVtaNVNz/+xIomYbbi+e/hJ27 DXoxPPw+aZpNqb06iApLWOAq8aajEz+McqaLa0tbwHc3px4NCeLXRgk7SlrcAodJa5BF nx06GIcHlycLIfYj1rKPsLQfC174r6MKZX3vCEnzrJEc8ld6MDUABnxhd7XYeWCLMqbW cDrW++MondNQ0UvpII/psj6NLHFBXwOjDE40RCE1uTiCFelHYDc601LeOwckXjejMSrI tRlcL7Dt3eujYTeLeWG9TdcjUdH32Q/LEEwqulTR4yxFbqb8yYM489FeMcY3wyomd59N u9Eg== 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=GwyPMv1j9avH8Vnfm3Rmt3e1Fpn0qM+URyG5VmS8ZRw=; b=V+MNFQvbjMQgpB/oXNJq6M7VxQasVUCj7gcLxBQy2pb/4qbdsOz8rE4U1IdjYgaXiV bdc2/lJ+csUQ8a03JWI2SEeaUjoUl26ojtWP8HUbvL7mjRo2/PHT+4yDWxxK8hd5WZ7i Tzb/BqVatw34Swrk6HJ1lbgfRZ0hb/1x4dzASHcZPIxReLbi+nmsMcKheW4C6ju8eS7o c71VNuF6/J3cxs5DSTWYwsum0RLT7pt7pMrHgZ5kseksXl//RxIASLfRHJa3pBR1mzSF 3OF+76PxF5sMkEXyJDXUa5wDyYSTZeLUeZIkSNMczqhEU8VRplYL+EcYe65xEO5h+ov1 cNNw== X-Gm-Message-State: APjAAAWXBmXHc99TVe2x6x6iKiBXbwoJVvwyNxF+YGXaiu/4/KS0ppEk jerpNPwj9ogy5WCcO/zhySKHOuICbnBCgfGYFDqGZQEECwE= X-Google-Smtp-Source: APXvYqxZ46g02b/rhNnbkW561ppp1yj7jIQ1i0b82DaEKS7fLfQyLIHEGF9gfKQBIEzF1n/kU7H2muf19UY8HUV/U3U= X-Received: by 2002:a50:b87c:: with SMTP id k57mr66624955ede.226.1563913632155; Tue, 23 Jul 2019 13:27:12 -0700 (PDT) MIME-Version: 1.0 References: <097e01d5418d$847ee300$8d7ca900$@riw.us> In-Reply-To: <097e01d5418d$847ee300$8d7ca900$@riw.us> From: Tony Przygienda Date: Tue, 23 Jul 2019 16:26:35 -0400 Message-ID: To: Russ White Cc: rtg-wg-chairs@ietf.org, draft-ietf-rift-rift@ietf.org, rtg-dir@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000810aab058e5f044a" Archived-At: Subject: Re: [RTG-DIR] [Rift] RtgDir Early review: draft-ietf-rift-rift-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:27:22 -0000 --000000000000810aab058e5f044a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable thanks for quick review, Russ. Flew over it. most stuff seems clarification and editorials to me. Let's sit with authors in the bar and go over it, I have -07 pending anyway right after IETF due to the v4/v6 router requirement comments and bruno's interop so this is a great time in fact to file off the last rough edges ... --- tony On Tue, Jul 23, 2019 at 3:33 PM wrote: > Hello > > I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D = review of this > draft. > =E2=80=8Bhttps://datatracker.ietf.org/doc/draft-foo-name/ > > The routing directorate will, on request from the working group chair, > perform an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitt= ed for publication > to the IESG. The early review can be performed at any time during the > draft=E2=80=99s lifetime as a working group document. The purpose of the = early > review depends on the stage that the document has reached. > > As this document has recently been adopted by the working group, my focus > for the review is on providing a new perspective on the work, with the > intention of catching any issues early on in the document's life cycle. > > For more information about the Routing Directorate, please see =E2=80=8B > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Document: draft-ietf-rift-rift-06 > Reviewer: Russ White > Review Date: 23 July 2019 > Intended Status: Standards Track > > Summary: > > I have significant concerns about this document. It needs more work befor= e > being submitted to the IESG. > > Comments: > > Overall this draft is very readable, although I have suggested wording > changes below. The protocol described is useful and interesting. I largel= y > have questions about the structure and wording of the draft, although the= re > are a couple of technical questions in the comments below (probably just > things I missed the explanation for, however). > > Structurally, this document almost feels like two different documents. Th= e > first specifies a set of use cases and requirements, while the second > specifies a protocol. I wonder if it wouldn't be better to split this > document into two pieces, making each one more specific, and possibly a b= it > easier to read? We might too late in the process to make such a change -- > if so, that's okay, just thought it might be worth considering. > > Throughout -- "fat tree," "Clos," and other terms are used in various > places. As a reader, given the different meanings for these terms, I foun= d > this a bit confusing. It might be better to use "spine and leaf" througho= ut. > > Throughout -- the term "folded" has two very different meanings... The > first is a multistage fabric on which traffic flows bi-directionally, the > second is a way of drawing spine and leaf fabrics in blocks. It might be > useful to clarify this from the beginning somehow, so readers who are > expecting one meaning don't misread things because a different meaning is > intended (?). I think it's always used here in the "way of drawing a spin= e > and leaf fabric" here. > > =3D=3D > Page 9 > > The definitions of the various forms of TIE might be better if they > clearly differentiated between topology and reachability information (?). > The OSPF router LSA, for instance, contains both kinds of information. In > IS-IS, adjacencies, which are called Node TIES (I think) are tlv22, while > the Prefix TIE would be a tlv128 and 236. I don't think there is an > equivalent separation between topology (reachable neighbors) and > reachability (reachable prefixes) in OSPF. > > =3D=3D > REQ13: "Taking a path through the spine in cases where a shorter path is > available is highly undesirable." > > This doesn't seem to be related to the previous statements in the > requirement... Not certain this needs to be included? Or maybe it wants t= o > be someplace else in the list? > > =3D=3D > REQ10 and REQ13 both seem to say the same thing -- although REQ13 is > better worded. Maybe both of these are not needed? > > =3D=3D > REQ15: "...links of a single node having same addresses." -- might be > better as "...links of a single node sharing the same address." > > =3D=3D > REQ18: "...security mechanisms that allow to restrict nodes, especially > leafs without proper credentials from forming three-way adjacencies." > > Might be better as: > > "...security mechanisms that allow the operator to restrict nodes, > especially leaf nodes without proper credentials, from forming a three-wa= y > adjacency." > > =3D=3D > PEND2: 500,000 seems way too small for the scale numbers I've heard in th= e > past -- especially if we are including the underlay protocol running on t= he > hosts in the mix. If there are 300k ports is at least 1 prefix per edge > port, and potentially 10-15 prefixes per edge port. If you guess around 2= 0% > of the workloads attached to the fabric might be mobile, then the number > here is more likely 1 million at the base, with a top end of around 2-3 > million prefixes. It might be worth adjusting this number a bit larger (?= ). > > =3D=3D > Section 5, paragraph after the header > > "...when "pointing north" and path vector [RFC4271] protocol when > "pointing south". While this is an unusual combination,..." > > Elsewhere in the document "distance-vector" is used. It might be better t= o > be consistent? > > =3D=3D > Section 5.1.1 > > In the first paragraph ("The most singular property..."), omitting > east-west control plane information flow is mentioned twice; could probab= ly > just be once. > > The first sentence in the second paragraph is a bit of a run-on; might be > best to omit some of this, or break it into two sentences. > > Second paragraph: "The application of those principle lead to RIFT..." > doesn't seem right. Might be better as: "The application of these > principles lead to RIFT..." > > =3D=3D > Section 5.1.2, paragraph beginning: "Given the difficulty of visualizing > multi plane design which are..." First, this is one long sentence. Second= , > what's illustrated looks like a crossbar, but it's not a crossbar. I find > this a little confusing (?). The problem is -- I don't know of another te= rm > to use here. > > =3D=3D > Section 5.1.2, paragraph beginning: "The typical topology for which RIFT > is defined is built of a number P..." This seems to describe a five stage > butterfly or pod-and-spine fabric, but does not seem to describe a seven > stage (?). > > Overall -- I'm not certain trying to describe these topologies at this > level in a protocol specification draft is all that useful. The terminolo= gy > is fluid (used by different people in different ways), and this depth of > explanation does not seem to be useful to describe the protocol operation= . > This is one place where splitting the document into two pieces might be > helpful. > > =3D=3D > Paragraph beginning: "It is critical at this junction that the concept an= d > the picture of..." What is shown is not really a crossbar fabric... I'm n= ot > certain calling this a crossbar is helpful here (?). > > =3D=3D > Section 5.1.4: "This happens naturally in single plane design but needs > additional considerations in multiplane fabrics." When aggregation is use= d, > as well -- but not when no aggregation of reachability information is > deployed in the fabric. It might be worth adding that qualification here. > > =3D=3D > Section 5.1.4 > > Sentence beginning: "In more detail, by reserving two ports on each > Top-of-Fabric node it is possible to connect them together in an interpla= ne > bi-directional ring as illustrated in Figure 13..." > > I might have missed it, but this document does not seem to address how > traffic will be prevented from flowing through these links. It's probably > important to note either that traffic will flow along these links, hence > they need to be sized appropriately, or how traffic is prevented from > flowing along these links. > > =3D=3D > Section 5.1.5 > > Sentence beginning: "The effect of a positive disaggregation..." If > positive deaggregation takes place, it could draw all the traffic to the > deaggregated destinations along a small set of links, causing a hot spot = in > the fabric. This might be taken care of "naturally" in the way RIFT does > positive deaggregation, but it might be good to explain this in the > document. > > A more general observation: positive deaggregation, as described in the > document, can potentially cause cascading failures where a group of links > or nodes fail, causing a lot of new information to be pushed into lower > levels rather quickly, which could potentially cause those nodes to overr= un > their table or processing space and fail in turn, causing more informatio= n > to be dumped into the control plane, etc. It may be worth connsidering > having some form of "hysteresis," timer or other mechanism to prevent > cascading failures of this kind. > > =3D=3D > Section 5.2.2 > > "All RIFT routers MUST support IPv4 forwarding and MAY support IPv6..." > > So an IPv6 only fabric is not possible? > > =3D=3D > Section 5.2.6 > > "After the SPF is run, it is necessary to attach according prefixes." > > I think this might want to mean -- > > "After SPF is run, it is necessary to attach the resulting reachability > information in the form of prefixes." > > (?) > > =3D=3D > Section 5.2.6 > > It seems like the first and third paragraphs describe the same procedure? > Are both descriptions necessary? > > =3D=3D > Section 5.2.6 > > "An exemplary implementation..." should probably be "an example > implementation..." ?? > > =3D=3D > Section 5.2.6 > > "After the positive prefixes are attached and tie-broken, negative > prefixes are attached and used in case of northbound computation, ideally > from the shortest length to the longest." > > It seems like the prefixes should be "tie-broken" before being attached. > This sentence is generally confusing, perhaps: > > "After the positive prefixes have been attached, the negative prefixes > will be attached in their prefix-length order (from the shortest to the > longest). These negative prefixes will only be used when computing > northbound reachability." > > =3D=3D > Section 5.2.6 > > "Observe that despite seeming quite computationally expensive the > operations are only necessary if the only available advertisements for a > prefix are negative since tie-breaking always prefers positive informatio= n > for the prefix which stops any kind of recursion since positive informati= on > never inherits next hops." > > Just because something is not done all that often does not mean it's not > computationally expensive. :-) Maybe something like this would be better: > > "Although these operations can be computationally expensive, the overall > load on devices in the network is low because these computations are not > run very often, as positive route advertisements are always preferred ove= r > negative ones. This prevents recursion in most cases because positive > reachability information never inherits next hops." > > Or something like this? > > =3D=3D > Section 5.2.6 > > "Negative 2001:db8::/32 entry inherits from" > > Probably wants to be "The negative 2001:db8::/32 entry..." > > =3D=3D > Section 5.2.6 > > "Finally, let us look at the case where S3 becomes available again as > default gateway, ..." > > "...the default gateway..." or "...a default gateway..." > > =3D=3D > Section 5.2.7 > > "Each RIFT node can optionally operate in zero touch provisioning..." > > "optionally" is not needed here > > =3D=3D > Section 5.2.7.2 > > "RIFT identifies each node via a SystemID which is a 64 bits wide integer= . > It is relatively simple to derive a, for all practical purposes collision > free, value for each node on startup. For that purpose, a node MUST use a= s > system ID EUI-64 MA-L format [EUI64] where the organizationally governed = 24 > bits can be used to generate system IDs for multiple RIFT instances runni= ng > on the system." > > This seems too wordy -- maybe: > > "RIFT nodes require a 64 bit SystemID in the EUI-64 MA-L format formed as > described in [EUI64]. The organizationally goverened portion of this ID > (24 bits) can be used to generate multiple IDs if required to indicate mo= re > than one RIFT instance." > > =3D=3D > Section 5.3.1 > > "Overload Bit MUST be respected..." > > should be > > "The overload bit MUST be respected..." > > =3D=3D > Section 5.3.2 > > "Since the leafs do see only "one hop away" they do not need to run a ful= l > SPF but can simply gather prefix candidates from their neighbors and buil= d > the according routing table." > > Seems like this should be > > "Since leaf nodes only have one hop of topology information, they do not > need to run SPF. Instead, they can gather the available prefix candidates > and build the routing table accordingly." > > =3D=3D > Section 5.3.3 > > "time stamp: With this method, the infrastructure memorizes the..." > > I think the correct word here is "records," rather than "memorizes" (?) > > =3D=3D > Section 5.3.3 > > "sequence counter: With this method, a mobile node notifies its point..." > > Another problem here is the node might not "know" it has been moved from > one location to another in the fabric, particularly if a layer 2 only > attached process is moved along with it's ARP cache, and something like t= he > EVPN default MAC is used to enable the move. I don't know if this is wort= h > mentioning, but it does seem like a case that needs to be thought about t= o > make certain it works with the process described. > > =3D=3D > Section 5.3.3 > > "The leaf node MUST advertise a time stamp of the latest sighting..." > > Is this for all prefixes, or just for prefixes that are somehow marked or > configured as potentially mobile on the fabric? > > =3D=3D > Section 5.3.3 > > "RIFT also defines an abstract negative clock (ANSC) that compares as les= s > than any other clock." > > Does this mean lower priority, or always older than any other clock? It > seems like this means "older" based on 5.3.3.1, but the language could > probably be clearer. > > =3D=3D > Section 5.3.3 > > One thing not covered here is what happens if some workload moves between > two RIFT fabrics interconnected via some other protocol, such as BGP. It > seems the most obvious solution is to have RIFT treat redistributed > destinations the same as directly attached destinations in terms of clock= s, > etc., but this is not called out in the document. It might be worth > mentioning. > > =3D=3D > Section 5.3.3.3 > > This section seems a little ... muddled? You want to both have the abilit= y > to use only the most recently available versions of any anycast > destination, while also not requiring all the anycast advertisements to > have the same time stamp (?). I'm not certain this section entirely solve= s > that problem. This sentence might be creating the confusion in my reading > of the section, as I don't really understand what it is saying: > > "An anycast prefix does not carry a clock or all clock attributes MUST be > the same under the rules of Section 5.3.3.1." > > MUST be treated the same as prefixes advertised under the rules of > 5.3.3.1? I'm not certain. > > =3D=3D > Section 5.3.3.4 > > "RIFT is agnostic whether any overlay technology like [MIP, LISP, VxLAN, > NVO3] and the associated signaling is deployed over it. But it is expecte= d > that leaf nodes, and possibly Top-of-Fabric nodes can perform the accordi= ng > encapsulation." > > "according" should be "correct," I think. > > =3D=3D > Section 5.3.6.1 > > "All the multiplications and additions are saturating, i.e. when exceedin= g > range of the bandwidth type are set to highest possible value of the type= ." > > Maybe better: > > "If a calculation produces a result exceeding the range of the type, the > result is set to the highest possible value for that type." > > > > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --000000000000810aab058e5f044a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks for quick review, Russ. Flew over it. most stu= ff seems clarification and editorials to me. Let's sit with authors in = the bar and go over it, I have -07 pending anyway right after IETF due to t= he v4/v6 router requirement comments and bruno's interop so this is a g= reat time in fact to file off the last rough edges ...

<= /div>
--- tony


On Tue, Jul 23, 2019 at 3:33 PM= <russ@riw.us> wrote:
Hello

I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re= view of this draft.
=E2=80=8Bhttps://datatracker.ietf.org/doc/draft-fo= o-name/

The routing directorate will, on request from the working group chair, perf= orm an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for= publication to the IESG. The early review can be performed at any time dur= ing the draft=E2=80=99s lifetime as a working group document. The purpose o= f the early review depends on the stage that the document has reached.

As this document has recently been adopted by the working group, my focus f= or the review is on providing a new perspective on the work, with the inten= tion of catching any issues early on in the document's life cycle.

For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r

Document: draft-ietf-rift-rift-06
Reviewer: Russ White
Review Date: 23 July 2019
Intended Status: Standards Track

Summary:

I have significant concerns about this document. It needs more work before = being submitted to the IESG.

Comments:

Overall this draft is very readable, although I have suggested wording chan= ges below. The protocol described is useful and interesting. I largely have= questions about the structure and wording of the draft, although there are= a couple of technical questions in the comments below (probably just thing= s I missed the explanation for, however).

Structurally, this document almost feels like two different documents. The = first specifies a set of use cases and requirements, while the second speci= fies a protocol. I wonder if it wouldn't be better to split this docume= nt into two pieces, making each one more specific, and possibly a bit easie= r to read? We might too late in the process to make such a change -- if so,= that's okay, just thought it might be worth considering.

Throughout -- "fat tree," "Clos," and other terms are u= sed in various places. As a reader, given the different meanings for these = terms, I found this a bit confusing. It might be better to use "spine = and leaf" throughout.

Throughout -- the term "folded" has two very different meanings..= . The first is a multistage fabric on which traffic flows bi-directionally,= the second is a way of drawing spine and leaf fabrics in blocks. It might = be useful to clarify this from the beginning somehow, so readers who are ex= pecting one meaning don't misread things because a different meaning is= intended (?). I think it's always used here in the "way of drawin= g a spine and leaf fabric" here.

=3D=3D
Page 9

The definitions of the various forms of TIE might be better if they clearly= differentiated between topology and reachability information (?). The OSPF= router LSA, for instance, contains both kinds of information. In IS-IS, ad= jacencies, which are called Node TIES (I think) are tlv22, while the Prefix= TIE would be a tlv128 and 236. I don't think there is an equivalent se= paration between topology (reachable neighbors) and reachability (reachable= prefixes) in OSPF.

=3D=3D
REQ13: "Taking a path through the spine in cases where a shorter path = is available is highly undesirable."

This doesn't seem to be related to the previous statements in the requi= rement... Not certain this needs to be included? Or maybe it wants to be so= meplace else in the list?

=3D=3D
REQ10 and REQ13 both seem to say the same thing -- although REQ13 is better= worded. Maybe both of these are not needed?

=3D=3D
REQ15: "...links of a single node having same addresses." -- migh= t be better as "...links of a single node sharing the same address.&qu= ot;

=3D=3D
REQ18: "...security mechanisms that allow to restrict nodes, especiall= y leafs without proper credentials from forming three-way adjacencies."= ;

Might be better as:

"...security mechanisms that allow the operator to restrict nodes, esp= ecially leaf nodes without proper credentials, from forming a three-way adj= acency."

=3D=3D
PEND2: 500,000 seems way too small for the scale numbers I've heard in = the past -- especially if we are including the underlay protocol running on= the hosts in the mix. If there are 300k ports is at least 1 prefix per edg= e port, and potentially 10-15 prefixes per edge port. If you guess around 2= 0% of the workloads attached to the fabric might be mobile, then the number= here is more likely 1 million at the base, with a top end of around 2-3 mi= llion prefixes. It might be worth adjusting this number a bit larger (?).
=3D=3D
Section 5, paragraph after the header

"...when "pointing north" and path vector [RFC4271] protocol= when "pointing south". While this is an unusual combination,...&= quot;

Elsewhere in the document "distance-vector" is used. It might be = better to be consistent?

=3D=3D
Section 5.1.1

In the first paragraph ("The most singular property..."), omittin= g east-west control plane information flow is mentioned twice; could probab= ly just be once.

The first sentence in the second paragraph is a bit of a run-on; might be b= est to omit some of this, or break it into two sentences.

Second paragraph: "The application of those principle lead to RIFT...&= quot; doesn't seem right. Might be better as: "The application of = these principles lead to RIFT..."

=3D=3D
Section 5.1.2, paragraph beginning: "Given the difficulty of visualizi= ng multi plane design which are..." First, this is one long sentence. = Second, what's illustrated looks like a crossbar, but it's not a cr= ossbar. I find this a little confusing (?). The problem is -- I don't k= now of another term to use here.

=3D=3D
Section 5.1.2, paragraph beginning: "The typical topology for which RI= FT is defined is built of a number P..." This seems to describe a five= stage butterfly or pod-and-spine fabric, but does not seem to describe a s= even stage (?).

Overall -- I'm not certain trying to describe these topologies at this = level in a protocol specification draft is all that useful. The terminology= is fluid (used by different people in different ways), and this depth of e= xplanation does not seem to be useful to describe the protocol operation. T= his is one place where splitting the document into two pieces might be help= ful.

=3D=3D
Paragraph beginning: "It is critical at this junction that the concept= and the picture of..." What is shown is not really a crossbar fabric.= .. I'm not certain calling this a crossbar is helpful here (?).

=3D=3D
Section 5.1.4: "This happens naturally in single plane design but need= s additional considerations in multiplane fabrics." When aggregation i= s used, as well -- but not when no aggregation of reachability information = is deployed in the fabric. It might be worth adding that qualification here= .

=3D=3D
Section 5.1.4

Sentence beginning: "In more detail, by reserving two ports on each To= p-of-Fabric node it is possible to connect them together in an interplane b= i-directional ring as illustrated in Figure 13..."

I might have missed it, but this document does not seem to address how traf= fic will be prevented from flowing through these links. It's probably i= mportant to note either that traffic will flow along these links, hence the= y need to be sized appropriately, or how traffic is prevented from flowing = along these links.

=3D=3D
Section 5.1.5

Sentence beginning: "The effect of a positive disaggregation..." = If positive deaggregation takes place, it could draw all the traffic to the= deaggregated destinations along a small set of links, causing a hot spot i= n the fabric. This might be taken care of "naturally" in the way = RIFT does positive deaggregation, but it might be good to explain this in t= he document.

A more general observation: positive deaggregation, as described in the doc= ument, can potentially cause cascading failures where a group of links or n= odes fail, causing a lot of new information to be pushed into lower levels = rather quickly, which could potentially cause those nodes to overrun their = table or processing space and fail in turn, causing more information to be = dumped into the control plane, etc. It may be worth connsidering having som= e form of "hysteresis," timer or other mechanism to prevent casca= ding failures of this kind.

=3D=3D
Section 5.2.2

"All RIFT routers MUST support IPv4 forwarding and MAY support IPv6...= "

So an IPv6 only fabric is not possible?

=3D=3D
Section 5.2.6

"After the SPF is run, it is necessary to attach according prefixes.&q= uot;

I think this might want to mean --

"After SPF is run, it is necessary to attach the resulting reachabilit= y information in the form of prefixes."

(?)

=3D=3D
Section 5.2.6

It seems like the first and third paragraphs describe the same procedure? A= re both descriptions necessary?

=3D=3D
Section 5.2.6

"An exemplary implementation..." should probably be "an exam= ple implementation..." ??

=3D=3D
Section 5.2.6

"After the positive prefixes are attached and tie-broken, negative pre= fixes are attached and used in case of northbound computation, ideally from= the shortest length to the longest."

It seems like the prefixes should be "tie-broken" before being at= tached. This sentence is generally confusing, perhaps:

"After the positive prefixes have been attached, the negative prefixes= will be attached in their prefix-length order (from the shortest to the lo= ngest). These negative prefixes will only be used when computing northbound= reachability."

=3D=3D
Section 5.2.6

"Observe that despite seeming quite computationally expensive the oper= ations are only necessary if the only available advertisements for a prefix= are negative since tie-breaking always prefers positive information for th= e prefix which stops any kind of recursion since positive information never= inherits next hops."

Just because something is not done all that often does not mean it's no= t computationally expensive. :-) Maybe something like this would be better:=

"Although these operations can be computationally expensive, the overa= ll load on devices in the network is low because these computations are not= run very often, as positive route advertisements are always preferred over= negative ones. This prevents recursion in most cases because positive reac= hability information never inherits next hops."

Or something like this?

=3D=3D
Section 5.2.6

"Negative 2001:db8::/32 entry inherits from"

Probably wants to be "The negative 2001:db8::/32 entry..."

=3D=3D
Section 5.2.6

"Finally, let us look at the case where S3 becomes available again as = default gateway, ..."

"...the default gateway..." or "...a default gateway..."= ;

=3D=3D
Section 5.2.7

"Each RIFT node can optionally operate in zero touch provisioning...&q= uot;

"optionally" is not needed here

=3D=3D
Section 5.2.7.2

"RIFT identifies each node via a SystemID which is a 64 bits wide inte= ger. It is relatively simple to derive a, for all practical purposes collis= ion free, value for each node on startup. For that purpose, a node MUST use= as system ID EUI-64 MA-L format [EUI64] where the organizationally governe= d 24 bits can be used to generate system IDs for multiple RIFT instances ru= nning on the system."

This seems too wordy -- maybe:

"RIFT nodes require a 64 bit SystemID in the EUI-64 MA-L format formed= as described in [EUI64]. The organizationally goverened portion of this ID= =C2=A0 (24 bits) can be used to generate multiple IDs if required to indica= te more than one RIFT instance."

=3D=3D
Section 5.3.1

"Overload Bit MUST be respected..."

should be

"The overload bit MUST be respected..."

=3D=3D
Section 5.3.2

"Since the leafs do see only "one hop away" they do not need= to run a full SPF but can simply gather prefix candidates from their neigh= bors and build the according routing table."

Seems like this should be

"Since leaf nodes only have one hop of topology information, they do n= ot need to run SPF. Instead, they can gather the available prefix candidate= s and build the routing table accordingly."

=3D=3D
Section 5.3.3

"time stamp: With this method, the infrastructure memorizes the...&quo= t;

I think the correct word here is "records," rather than "mem= orizes" (?)

=3D=3D
Section 5.3.3

"sequence counter: With this method, a mobile node notifies its point.= .."

Another problem here is the node might not "know" it has been mov= ed from one location to another in the fabric, particularly if a layer 2 on= ly attached process is moved along with it's ARP cache, and something l= ike the EVPN default MAC is used to enable the move. I don't know if th= is is worth mentioning, but it does seem like a case that needs to be thoug= ht about to make certain it works with the process described.

=3D=3D
Section 5.3.3

"The leaf node MUST advertise a time stamp of the latest sighting...&q= uot;

Is this for all prefixes, or just for prefixes that are somehow marked or c= onfigured as potentially mobile on the fabric?

=3D=3D
Section 5.3.3

"RIFT also defines an abstract negative clock (ANSC) that compares as = less than any other clock."

Does this mean lower priority, or always older than any other clock? It see= ms like this means "older" based on 5.3.3.1, but the language cou= ld probably be clearer.

=3D=3D
Section 5.3.3

One thing not covered here is what happens if some workload moves between t= wo RIFT fabrics interconnected via some other protocol, such as BGP. It see= ms the most obvious solution is to have RIFT treat redistributed destinatio= ns the same as directly attached destinations in terms of clocks, etc., but= this is not called out in the document. It might be worth mentioning.

=3D=3D
Section 5.3.3.3

This section seems a little ... muddled? You want to both have the ability = to use only the most recently available versions of any anycast destination= , while also not requiring all the anycast advertisements to have the same = time stamp (?). I'm not certain this section entirely solves that probl= em. This sentence might be creating the confusion in my reading of the sect= ion, as I don't really understand what it is saying:

"An anycast prefix does not carry a clock or all clock attributes MUST= be the same under the rules of Section 5.3.3.1."

MUST be treated the same as prefixes advertised under the rules of 5.3.3.1?= I'm not certain.

=3D=3D
Section 5.3.3.4

"RIFT is agnostic whether any overlay technology like [MIP, LISP, VxLA= N, NVO3] and the associated signaling is deployed over it. But it is expect= ed that leaf nodes, and possibly Top-of-Fabric nodes can perform the accord= ing encapsulation."

"according" should be "correct," I think.

=3D=3D
Section 5.3.6.1

"All the multiplications and additions are saturating, i.e. when excee= ding range of the bandwidth type are set to highest possible value of the t= ype."

Maybe better:

"If a calculation produces a result exceeding the range of the type, t= he result is set to the highest possible value for that type."



_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--000000000000810aab058e5f044a-- From nobody Thu Jul 25 06:41:00 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5678E120043; Thu, 25 Jul 2019 06:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=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 GbsYP5JF6n-b; Thu, 25 Jul 2019 06:40:46 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 4330D12001A; Thu, 25 Jul 2019 06:40:43 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id x19so44355868eda.12; Thu, 25 Jul 2019 06:40:43 -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=oUb1qtgcmU21pwuyMeXdv8hkdKayYjZUgNfEU8GknKQ=; b=dz+L4TXK4BR+fuJqI4QGn6NY8bM9Rwl7gSMO6L0dIemyyWnRZD5z+HwZRT10uPLgTv vXzk1B0vYltXRZnDBBnyMvrKNWBpEiHTxjzrvqsfFu1QVAia9QoQ1/Zmqzhe/BBgBHpy I48MC3Q693IXDwap33KEW06iwFnMqw4h8eBfhSppHWK7Gnqo+InqbvV2QfcQlPxP30+Z +Pv6faZBerj+WhRAFOIsfQnRgYMY5kpjJjl5IC3EETvQq6RWddJB2qYMPDIGu6adq1cN xxgWqjRkb2ZeozYNsnAVk9HCOQPtASll+vf0IJ4ukLnLAGwq7apTnOhu8FAh8DbagUmJ pYYA== 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=oUb1qtgcmU21pwuyMeXdv8hkdKayYjZUgNfEU8GknKQ=; b=gCInfxMYQPxdRhNadsFmuM3LwvmaNrj9A8I8VZ1hwWUHzesfNGMb1hCQVf0qK+az22 e6VYpmAa6No0eKy4aMgdqWdoBvZWAfBNO0FCLs4c/Cc5Y2Bo/2HU4g+/Lut5HAj+EY+v u2o5lygJ+KbGblHg0Evrcg0Npa160K08WtOrTNVEOby1/bE8wJvT56Y0/22TTQGeHfzL 5ESuwPOCs/mNbFjj7CBq0DUachsAZ9M0U+/R1kM5a7NJDYWBEDNy+kOhSKnN5+abkuT8 BUJ+SvD+15cX2nrYJ3E/XG/CI6NDsc78roC8Xx0xLw8SlQz/b/iFivy4mRhsG8jqetdz E4+g== X-Gm-Message-State: APjAAAVZsV4ut5krnJwo1Nzf0nmHwMzsjirw55D5c431dyJZQOraokd+ vIW08br5ocjqGcIIhEGkAhMcwjZ23zC7zQryBe0Fs8Y0TgElFg== X-Google-Smtp-Source: APXvYqzJvujZe67fJBr5mZWS4cKWnbAk8nqmQXFZ82w2PiOXRAN05eZO8ehc3yEQhNMh2qssZWGNKq5VgScp1RsE8SU= X-Received: by 2002:a50:ad0c:: with SMTP id y12mr75646811edc.25.1564062041717; Thu, 25 Jul 2019 06:40:41 -0700 (PDT) MIME-Version: 1.0 References: <097e01d5418d$847ee300$8d7ca900$@riw.us> In-Reply-To: <097e01d5418d$847ee300$8d7ca900$@riw.us> From: Tony Przygienda Date: Thu, 25 Jul 2019 09:40:05 -0400 Message-ID: To: Russ White Cc: rtg-wg-chairs@ietf.org, draft-ietf-rift-rift@ietf.org, rtg-dir@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="000000000000674425058e81923f" Archived-At: Subject: Re: [RTG-DIR] [Rift] RtgDir Early review: draft-ietf-rift-rift-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 13:40:52 -0000 --000000000000674425058e81923f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Meeting minutes of the author/review meet on the comments On Tue, Jul 23, 2019 at 3:33 PM wrote: > Hello > > I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D = review of this > draft. > https://datatracker.ietf.org/doc/draft-foo-name/ > > The routing directorate will, on request from the working group chair, > perform an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitt= ed for publication > to the IESG. The early review can be performed at any time during the > draft=E2=80=99s lifetime as a working group document. The purpose of the = early > review depends on the stage that the document has reached. > > As this document has recently been adopted by the working group, my focus > for the review is on providing a new perspective on the work, with the > intention of catching any issues early on in the document's life cycle. > > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Document: draft-ietf-rift-rift-06 > Reviewer: Russ White > Review Date: 23 July 2019 > Intended Status: Standards Track > > Summary: > > I have significant concerns about this document. It needs more work befor= e > being submitted to the IESG. > > Comments: > > Overall this draft is very readable, although I have suggested wording > changes below. The protocol described is useful and interesting. I largel= y > have questions about the structure and wording of the draft, although the= re > are a couple of technical questions in the comments below (probably just > things I missed the explanation for, however). > > Structurally, this document almost feels like two different documents. Th= e > first specifies a set of use cases and requirements, while the second > specifies a protocol. I wonder if it wouldn't be better to split this > document into two pieces, making each one more specific, and possibly a b= it > easier to read? We might too late in the process to make such a change -- > if so, that's okay, just thought it might be worth considering. > On the intro add sentence "this doc encompasses reqs, secs and specs" > > Throughout -- "fat tree," "Clos," and other terms are used in various > places. As a reader, given the different meanings for these terms, I foun= d > this a bit confusing. It might be better to use "spine and leaf" througho= ut. > Add to glossary: When we use term Clos we mean by it variants of Clos such as multi-plane and what is loosely called Fat Tree and even more generic spine-and-leaf designs. > Throughout -- the term "folded" has two very different meanings... The > first is a multistage fabric on which traffic flows bi-directionally, the > second is a way of drawing spine and leaf fabrics in blocks. It might be > useful to clarify this from the beginning somehow, so readers who are > expecting one meaning don't misread things because a different meaning is > intended (?). I think it's always used here in the "way of drawing a spin= e > and leaf fabric" here. > add to glossary: folded for us is drawing with spines on the top and implicitly assuming bi-directionality on all leafs. > > =3D=3D > Page 9 > > The definitions of the various forms of TIE might be better if they > clearly differentiated between topology and reachability information (?). > The OSPF router LSA, for instance, contains both kinds of information. In > IS-IS, adjacencies, which are called Node TIES (I think) are tlv22, while > the Prefix TIE would be a tlv128 and 236. I don't think there is an > equivalent separation between topology (reachable neighbors) and > reachability (reachable prefixes) in OSPF. > remove the "largely equivalent to OSPF Router LSA" part > > =3D=3D > REQ13: "Taking a path through the spine in cases where a shorter path is > available is highly undesirable." > > This doesn't seem to be related to the previous statements in the > requirement... Not certain this needs to be included? Or maybe it wants t= o > be someplace else in the list? > Split off the sentence > =3D=3D > REQ10 and REQ13 both seem to say the same thing -- although REQ13 is > better worded. Maybe both of these are not needed? > no action > =3D=3D > REQ15: "...links of a single node having same addresses." -- might be > better as "...links of a single node sharing the same address." > > accepted > =3D=3D > REQ18: "...security mechanisms that allow to restrict nodes, especially > leafs without proper credentials from forming three-way adjacencies." > > Might be better as: > > "...security mechanisms that allow the operator to restrict nodes, > especially leaf nodes without proper credentials, from forming a three-wa= y > adjacency." > > accepted =3D=3D > PEND2: 500,000 seems way too small for the scale numbers I've heard in th= e > past -- especially if we are including the underlay protocol running on t= he > hosts in the mix. If there are 300k ports is at least 1 prefix per edge > port, and potentially 10-15 prefixes per edge port. If you guess around 2= 0% > of the workloads attached to the fabric might be mobile, then the number > here is more likely 1 million at the base, with a top end of around 2-3 > million prefixes. It might be worth adjusting this number a bit larger (?= ). > > PEND2 to be killed > =3D=3D > Section 5, paragraph after the header > > "...when "pointing north" and path vector [RFC4271] protocol when > "pointing south". While this is an unusual combination,..." > > Elsewhere in the document "distance-vector" is used. It might be better t= o > be consistent? > > replace with distance vector > =3D=3D > Section 5.1.1 > > In the first paragraph ("The most singular property..."), omitting > east-west control plane information flow is mentioned twice; could probab= ly > just be once. > Consult with Deborah whether we should tighten the prose or make it "looser" ? > The first sentence in the second paragraph is a bit of a run-on; might be > best to omit some of this, or break it into two sentences. > > Second paragraph: "The application of those principle lead to RIFT..." > doesn't seem right. Might be better as: "The application of these > principles lead to RIFT..." > accepted > > =3D=3D > Section 5.1.2, paragraph beginning: "Given the difficulty of visualizing > multi plane design which are..." First, this is one long sentence. Second= , > what's illustrated looks like a crossbar, but it's not a crossbar. I find > this a little confusing (?). The problem is -- I don't know of another te= rm > to use here. > sentence needs splitting crossbar stands > > =3D=3D > Section 5.1.2, paragraph beginning: "The typical topology for which RIFT > is defined is built of a number P..." This seems to describe a five stage > butterfly or pod-and-spine fabric, but does not seem to describe a seven > stage (?). > by a number of "top of fabric" nodes ... > > Overall -- I'm not certain trying to describe these topologies at this > level in a protocol specification draft is all that useful. The terminolo= gy > is fluid (used by different people in different ways), and this depth of > explanation does not seem to be useful to describe the protocol operation= . > This is one place where splitting the document into two pieces might be > helpful. > Word of caution sentence: please follow the glossary tightly, you get lost quickly otherwise ... > > =3D=3D > Paragraph beginning: "It is critical at this junction that the concept an= d > the picture of..." What is shown is not really a crossbar fabric... I'm n= ot > certain calling this a crossbar is helpful here (?). > add crossbar to glossary: physical arrangement of ports in a switching matrix without implying any further scheduling or buffering disciplines > =3D=3D > Section 5.1.4: "This happens naturally in single plane design but needs > additional considerations in multiplane fabrics." When aggregation is use= d, > as well -- but not when no aggregation of reachability information is > deployed in the fabric. It might be worth adding that qualification here. > when aggregation is used > > =3D=3D > Section 5.1.4 > > Sentence beginning: "In more detail, by reserving two ports on each > Top-of-Fabric node it is possible to connect them together in an interpla= ne > bi-directional ring as illustrated in Figure 13..." > > I might have missed it, but this document does not seem to address how > traffic will be prevented from flowing through these links. It's probably > important to note either that traffic will flow along these links, hence > they need to be sized appropriately, or how traffic is prevented from > flowing along these links. > > defect: spec the computation or "the computation has to prevent" . Enhace section 5.2.4 by explaining how ToFs MUST not use the ring @ the top to forward" > =3D=3D > Section 5.1.5 > > Sentence beginning: "The effect of a positive disaggregation..." If > positive deaggregation takes place, it could draw all the traffic to the > deaggregated destinations along a small set of links, causing a hot spot = in > the fabric. This might be taken care of "naturally" in the way RIFT does > positive deaggregation, but it might be good to explain this in the > document. > in the doc already > > A more general observation: positive deaggregation, as described in the > document, can potentially cause cascading failures where a group of links > or nodes fail, causing a lot of new information to be pushed into lower > levels rather quickly, which could potentially cause those nodes to overr= un > their table or processing space and fail in turn, causing more informatio= n > to be dumped into the control plane, etc. It may be worth connsidering > having some form of "hysteresis," timer or other mechanism to prevent > cascading failures of this kind. > positive is NOT transitive hence comment needs no addressing. Clarify maybe once more the fact. > > =3D=3D > Section 5.2.2 > > "All RIFT routers MUST support IPv4 forwarding and MAY support IPv6..." > > So an IPv6 only fabric is not possible? > based on multiple thread router requirements are removed > > =3D=3D > Section 5.2.6 > > "After the SPF is run, it is necessary to attach according prefixes." > > I think this might want to mean -- > > "After SPF is run, it is necessary to attach the resulting reachability > information in the form of prefixes." > > agreed > (?) > > =3D=3D > Section 5.2.6 > > It seems like the first and third paragraphs describe the same procedure? > Are both descriptions necessary? > need to be merged > =3D=3D > Section 5.2.6 > > "An exemplary implementation..." should probably be "an example > implementation..." ?? > > =3D=3D > Section 5.2.6 > > "After the positive prefixes are attached and tie-broken, negative > prefixes are attached and used in case of northbound computation, ideally > from the shortest length to the longest." > > > It seems like the prefixes should be "tie-broken" before being attached. > This sentence is generally confusing, perhaps: > > "After the positive prefixes have been attached, the negative prefixes > will be attached in their prefix-length order (from the shortest to the > longest). These negative prefixes will only be used when computing > northbound reachability." > "Attach all prefixes. Then build next-hop per type. Thne within types tie-break by sequence in the model. if only negative remains run the according algorithm" Special Consideration for securtity Host implementation: suggestion to throttle aggressively, implementation on the ToR to max-prefix/max-state knobbing > > =3D=3D > Section 5.2.6 > > "Observe that despite seeming quite computationally expensive the > operations are only necessary if the only available advertisements for a > prefix are negative since tie-breaking always prefers positive informatio= n > for the prefix which stops any kind of recursion since positive informati= on > never inherits next hops." > > Just because something is not done all that often does not mean it's not > computationally expensive. :-) Maybe something like this would be better: > > "Although these operations can be computationally expensive, the overall > load on devices in the network is low because these computations are not > run very often, as positive route advertisements are always preferred ove= r > negative ones. This prevents recursion in most cases because positive > reachability information never inherits next hops." > > Or something like this? > ack > > =3D=3D > Section 5.2.6 > > "Negative 2001:db8::/32 entry inherits from" > > Probably wants to be "The negative 2001:db8::/32 entry..." > nit > =3D=3D > Section 5.2.6 > > "Finally, let us look at the case where S3 becomes available again as > default gateway, ..." > > "...the default gateway..." or "...a default gateway..." > > ack > =3D=3D > Section 5.2.7 > > "Each RIFT node can optionally operate in zero touch provisioning..." > > "optionally" is not needed here > "RIFT nodes MAY use ZTP or be configured, both modes being mixed in the same instance if desired" remove optionally > > =3D=3D > Section 5.2.7.2 > > "RIFT identifies each node via a SystemID which is a 64 bits wide integer= . > It is relatively simple to derive a, for all practical purposes collision > free, value for each node on startup. For that purpose, a node MUST use a= s > system ID EUI-64 MA-L format [EUI64] where the organizationally governed = 24 > bits can be used to generate system IDs for multiple RIFT instances runni= ng > on the system." > > This seems too wordy -- maybe: > > "RIFT nodes require a 64 bit SystemID in the EUI-64 MA-L format formed as > described in [EUI64]. The organizationally goverened portion of this ID > (24 bits) can be used to generate multiple IDs if required to indicate mo= re > than one RIFT instance." > "As prescribed by EUI ... RIFT nodes MUST form a 64 bit SID > > =3D=3D > Section 5.3.1 > > "Overload Bit MUST be respected..." > > should be > > "The overload bit MUST be respected..." > > ack > =3D=3D > Section 5.3.2 > > "Since the leafs do see only "one hop away" they do not need to run a ful= l > SPF but can simply gather prefix candidates from their neighbors and buil= d > the according routing table." > > Seems like this should be > > "Since leaf nodes only have one hop of topology information, they do not > need to run SPF. Instead, they can gather the available prefix candidates > and build the routing table accordingly." > ack > > =3D=3D > Section 5.3.3 > > "time stamp: With this method, the infrastructure memorizes the..." > > I think the correct word here is "records," rather than "memorizes" (?) > ack > > =3D=3D > Section 5.3.3 > > "sequence counter: With this method, a mobile node notifies its point..." > > Another problem here is the node might not "know" it has been moved from > one location to another in the fabric, particularly if a layer 2 only > attached process is moved along with it's ARP cache, and something like t= he > EVPN default MAC is used to enable the move. I don't know if this is wort= h > mentioning, but it does seem like a case that needs to be thought about t= o > make certain it works with the process described. > > no change necessary > =3D=3D > Section 5.3.3 > > "The leaf node MUST advertise a time stamp of the latest sighting..." > > Is this for all prefixes, or just for prefixes that are somehow marked or > configured as potentially mobile on the fabric? > > A leaf node MAY ... > =3D=3D > Section 5.3.3 > > "RIFT also defines an abstract negative clock (ANSC) that compares as les= s > than any other clock." > > Does this mean lower priority, or always older than any other clock? It > seems like this means "older" based on 5.3.3.1, but the language could > probably be clearer. > > nothing to do > =3D=3D > Section 5.3.3 > > One thing not covered here is what happens if some workload moves between > two RIFT fabrics interconnected via some other protocol, such as BGP. It > seems the most obvious solution is to have RIFT treat redistributed > destinations the same as directly attached destinations in terms of clock= s, > etc., but this is not called out in the document. It might be worth > mentioning. > > no action > =3D=3D > Section 5.3.3.3 > > This section seems a little ... muddled? You want to both have the abilit= y > to use only the most recently available versions of any anycast > destination, while also not requiring all the anycast advertisements to > have the same time stamp (?). I'm not certain this section entirely solve= s > that problem. This sentence might be creating the confusion in my reading > of the section, as I don't really understand what it is saying: > > "An anycast prefix does not carry a clock or all clock attributes MUST be > the same under the rules of Section 5.3.3.1." > > MUST be treated the same as prefixes advertised under the rules of > 5.3.3.1? I'm not certain. > it's complex for a reason. left as that. > > =3D=3D > Section 5.3.3.4 > > "RIFT is agnostic whether any overlay technology like [MIP, LISP, VxLAN, > NVO3] and the associated signaling is deployed over it. But it is expecte= d > that leaf nodes, and possibly Top-of-Fabric nodes can perform the accordi= ng > encapsulation." > > "according" should be "correct," I think. > fine > > =3D=3D > Section 5.3.6.1 > > "All the multiplications and additions are saturating, i.e. when exceedin= g > range of the bandwidth type are set to highest possible value of the type= ." > > Maybe better: > > "If a calculation produces a result exceeding the range of the type, the > result is set to the highest possible value for that type." > > fine > > _______________________________________________ > RIFT mailing list > RIFT@ietf.org > https://www.ietf.org/mailman/listinfo/rift > --000000000000674425058e81923f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Meeting minutes of the author/review meet= on the comments

On Tue, Jul 23, 2019 at 3:33 PM <russ@riw.us> wrote:
Hello

I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re= view of this draft.
https://datatracker.ietf.org/doc/draft-foo-name/=

The routing directorate will, on request from the working group chair, perf= orm an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for= publication to the IESG. The early review can be performed at any time dur= ing the draft=E2=80=99s lifetime as a working group document. The purpose o= f the early review depends on the stage that the document has reached.

As this document has recently been adopted by the working group, my focus f= or the review is on providing a new perspective on the work, with the inten= tion of catching any issues early on in the document's life cycle.

For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-rift-rift-06
Reviewer: Russ White
Review Date: 23 July 2019
Intended Status: Standards Track

Summary:

I have significant concerns about this document. It needs more work before = being submitted to the IESG.

Comments:

Overall this draft is very readable, although I have suggested wording chan= ges below. The protocol described is useful and interesting. I largely have= questions about the structure and wording of the draft, although there are= a couple of technical questions in the comments below (probably just thing= s I missed the explanation for, however).

Structurally, this document almost feels like two different documents. The = first specifies a set of use cases and requirements, while the second speci= fies a protocol. I wonder if it wouldn't be better to split this docume= nt into two pieces, making each one more specific, and possibly a bit easie= r to read? We might too late in the process to make such a change -- if so,= that's okay, just thought it might be worth considering.

On the intro add sentence "this doc encompasses= reqs, secs and specs"
=C2=A0

Throughout -- "fat tree," "Clos," and other terms are u= sed in various places. As a reader, given the different meanings for these = terms, I found this a bit confusing. It might be better to use "spine = and leaf" throughout.

Add to glossary: = When we use term Clos we mean by it variants of Clos such as multi-plane an= d what is loosely called Fat Tree and even more generic spine-and-leaf desi= gns.


Throughout -- the term "folded" has two very different meanings..= . The first is a multistage fabric on which traffic flows bi-directionally,= the second is a way of drawing spine and leaf fabrics in blocks. It might = be useful to clarify this from the beginning somehow, so readers who are ex= pecting one meaning don't misread things because a different meaning is= intended (?). I think it's always used here in the "way of drawin= g a spine and leaf fabric" here.

a= dd to glossary: folded for us is drawing with spines on the top and implici= tly assuming bi-directionality on all leafs.
=C2=A0

=3D=3D
Page 9

The definitions of the various forms of TIE might be better if they clearly= differentiated between topology and reachability information (?). The OSPF= router LSA, for instance, contains both kinds of information. In IS-IS, ad= jacencies, which are called Node TIES (I think) are tlv22, while the Prefix= TIE would be a tlv128 and 236. I don't think there is an equivalent se= paration between topology (reachable neighbors) and reachability (reachable= prefixes) in OSPF.

remove the "<= span style=3D"font-size:16.5px;font-family:monospace">largely equivalent to= OSPF Router LSA" part
=C2=A0

=3D=3D
REQ13: "Taking a path through the spine in cases where a shorter path = is available is highly undesirable."

This doesn't seem to be related to the previous statements in the requi= rement... Not certain this needs to be included? Or maybe it wants to be so= meplace else in the list?

Split off the= sentence


=3D=3D
REQ10 and REQ13 both seem to say the same thing -- although REQ13 is better= worded. Maybe both of these are not needed?

no action


=3D=3D
REQ15: "...links of a single node having same addresses." -- migh= t be better as "...links of a single node sharing the same address.&qu= ot;


accepted
=C2=A0
=3D=3D
REQ18: "...security mechanisms that allow to restrict nodes, especiall= y leafs without proper credentials from forming three-way adjacencies."= ;

Might be better as:

"...security mechanisms that allow the operator to restrict nodes, esp= ecially leaf nodes without proper credentials, from forming a three-way adj= acency."


accepted

=3D=3D
PEND2: 500,000 seems way too small for the scale numbers I've heard in = the past -- especially if we are including the underlay protocol running on= the hosts in the mix. If there are 300k ports is at least 1 prefix per edg= e port, and potentially 10-15 prefixes per edge port. If you guess around 2= 0% of the workloads attached to the fabric might be mobile, then the number= here is more likely 1 million at the base, with a top end of around 2-3 mi= llion prefixes. It might be worth adjusting this number a bit larger (?).

PEND2 to be killed
=C2= =A0
=3D=3D
Section 5, paragraph after the header

"...when "pointing north" and path vector [RFC4271] protocol= when "pointing south". While this is an unusual combination,...&= quot;

Elsewhere in the document "distance-vector" is used. It might be = better to be consistent?


replace with distance vector
=C2=A0
=3D=3D
Section 5.1.1

In the first paragraph ("The most singular property..."), omittin= g east-west control plane information flow is mentioned twice; could probab= ly just be once.

Consult with Deborah w= hether we should tighten the prose or make it "looser" ?


The first sentence in the second paragraph is a bit of a run-on; might be b= est to omit some of this, or break it into two sentences.

Second paragraph: "The application of those principle lead to RIFT...&= quot; doesn't seem right. Might be better as: "The application of = these principles lead to RIFT..."

= accepted
=C2=A0

=3D=3D
Section 5.1.2, paragraph beginning: "Given the difficulty of visualizi= ng multi plane design which are..." First, this is one long sentence. = Second, what's illustrated looks like a crossbar, but it's not a cr= ossbar. I find this a little confusing (?). The problem is -- I don't k= now of another term to use here.

senten= ce needs splitting

crossbar stands
= =C2=A0

=3D=3D
Section 5.1.2, paragraph beginning: "The typical topology for which RI= FT is defined is built of a number P..." This seems to describe a five= stage butterfly or pod-and-spine fabric, but does not seem to describe a s= even stage (?).

by a number of "to= p of fabric" nodes ...
=C2=A0

Overall -- I'm not certain trying to describe these topologies at this = level in a protocol specification draft is all that useful. The terminology= is fluid (used by different people in different ways), and this depth of e= xplanation does not seem to be useful to describe the protocol operation. T= his is one place where splitting the document into two pieces might be help= ful.

Word of caution sentence: please f= ollow the glossary tightly, you get lost quickly otherwise ...
=C2=A0

=3D=3D
Paragraph beginning: "It is critical at this junction that the concept= and the picture of..." What is shown is not really a crossbar fabric.= .. I'm not certain calling this a crossbar is helpful here (?).

add crossbar to glossary:=C2=A0 physical arran= gement of ports in a switching matrix without implying any further scheduli= ng or buffering disciplines


=3D=3D
Section 5.1.4: "This happens naturally in single plane design but need= s additional considerations in multiplane fabrics." When aggregation i= s used, as well -- but not when no aggregation of reachability information = is deployed in the fabric. It might be worth adding that qualification here= .

when aggregation is used
=C2=A0

=3D=3D
Section 5.1.4

Sentence beginning: "In more detail, by reserving two ports on each To= p-of-Fabric node it is possible to connect them together in an interplane b= i-directional ring as illustrated in Figure 13..."

I might have missed it, but this document does not seem to address how traf= fic will be prevented from flowing through these links. It's probably i= mportant to note either that traffic will flow along these links, hence the= y need to be sized appropriately, or how traffic is prevented from flowing = along these links.


defect: spec the computation or "= the computation has to prevent" . Enhace section 5.2.4 by explaining h= ow ToFs MUST not use the ring @ the top to forward"
=C2= =A0
=3D=3D
Section 5.1.5

Sentence beginning: "The effect of a positive disaggregation..." = If positive deaggregation takes place, it could draw all the traffic to the= deaggregated destinations along a small set of links, causing a hot spot i= n the fabric. This might be taken care of "naturally" in the way = RIFT does positive deaggregation, but it might be good to explain this in t= he document.

in the doc already
=C2=A0

A more general observation: positive deaggregation, as described in the doc= ument, can potentially cause cascading failures where a group of links or n= odes fail, causing a lot of new information to be pushed into lower levels = rather quickly, which could potentially cause those nodes to overrun their = table or processing space and fail in turn, causing more information to be = dumped into the control plane, etc. It may be worth connsidering having som= e form of "hysteresis," timer or other mechanism to prevent casca= ding failures of this kind.

positive is= NOT transitive hence comment needs no addressing.

Clarify maybe once more the fact.
=C2=A0

=3D=3D
Section 5.2.2

"All RIFT routers MUST support IPv4 forwarding and MAY support IPv6...= "

So an IPv6 only fabric is not possible?

based on multiple thread router requirements are removed
= =C2=A0

=3D=3D
Section 5.2.6

"After the SPF is run, it is necessary to attach according prefixes.&q= uot;

I think this might want to mean --

"After SPF is run, it is necessary to attach the resulting reachabilit= y information in the form of prefixes."


agreed
=C2=A0
(?)

=3D=3D
Section 5.2.6

It seems like the first and third paragraphs describe the same procedure? A= re both descriptions necessary?

need to= be merged


=3D=3D
Section 5.2.6

"An exemplary implementation..." should probably be "an exam= ple implementation..." ??

=3D=3D
Section 5.2.6

"After the positive prefixes are attached and tie-broken, negative pre= fixes are attached and used in case of northbound computation, ideally from= the shortest length to the longest."
=C2=A0

It seems like the prefixes should be "tie-broken" before being at= tached. This sentence is generally confusing, perhaps:

"After the positive prefixes have been attached, the negative prefixes= will be attached in their prefix-length order (from the shortest to the lo= ngest). These negative prefixes will only be used when computing northbound= reachability."

"Attach all p= refixes. Then build next-hop per type. Thne within types tie-break by seque= nce in the model. if only negative remains run the according algorithm"= ;

Special Consideration for = securtity Host implementation: suggestion to throttle aggressively, impleme= ntation on the ToR to max-prefix/max-state knobbing
=C2=A0

=3D=3D
Section 5.2.6

"Observe that despite seeming quite computationally expensive the oper= ations are only necessary if the only available advertisements for a prefix= are negative since tie-breaking always prefers positive information for th= e prefix which stops any kind of recursion since positive information never= inherits next hops."

Just because something is not done all that often does not mean it's no= t computationally expensive. :-) Maybe something like this would be better:=

"Although these operations can be computationally expensive, the overa= ll load on devices in the network is low because these computations are not= run very often, as positive route advertisements are always preferred over= negative ones. This prevents recursion in most cases because positive reac= hability information never inherits next hops."

Or something like this?

ack
=C2=A0

=3D=3D
Section 5.2.6

"Negative 2001:db8::/32 entry inherits from"

Probably wants to be "The negative 2001:db8::/32 entry..."

nit


=3D=3D
Section 5.2.6

"Finally, let us look at the case where S3 becomes available again as = default gateway, ..."

"...the default gateway..." or "...a default gateway..."= ;

ack
=C2=A0
=3D=3D
Section 5.2.7

"Each RIFT node can optionally operate in zero touch provisioning...&q= uot;

"optionally" is not needed here

"RIFT nodes MAY use ZTP or be configured, both modes being mixed in= the same instance if desired"

remove optiona= lly
=C2=A0

=3D=3D
Section 5.2.7.2

"RIFT identifies each node via a SystemID which is a 64 bits wide inte= ger. It is relatively simple to derive a, for all practical purposes collis= ion free, value for each node on startup. For that purpose, a node MUST use= as system ID EUI-64 MA-L format [EUI64] where the organizationally governe= d 24 bits can be used to generate system IDs for multiple RIFT instances ru= nning on the system."

This seems too wordy -- maybe:

"RIFT nodes require a 64 bit SystemID in the EUI-64 MA-L format formed= as described in [EUI64]. The organizationally goverened portion of this ID= =C2=A0 (24 bits) can be used to generate multiple IDs if required to indica= te more than one RIFT instance."

&= quot;As prescribed by EUI ... RIFT nodes MUST form a 64 bit SID=C2=A0
<= /div>
=C2=A0

=3D=3D
Section 5.3.1

"Overload Bit MUST be respected..."

should be

"The overload bit MUST be respected..."


ack
=C2=A0
=3D=3D
Section 5.3.2

"Since the leafs do see only "one hop away" they do not need= to run a full SPF but can simply gather prefix candidates from their neigh= bors and build the according routing table."

Seems like this should be

"Since leaf nodes only have one hop of topology information, they do n= ot need to run SPF. Instead, they can gather the available prefix candidate= s and build the routing table accordingly."

<= /div>
ack
=C2=A0

=3D=3D
Section 5.3.3

"time stamp: With this method, the infrastructure memorizes the...&quo= t;

I think the correct word here is "records," rather than "mem= orizes" (?)

ack
=C2= =A0

=3D=3D
Section 5.3.3

"sequence counter: With this method, a mobile node notifies its point.= .."

Another problem here is the node might not "know" it has been mov= ed from one location to another in the fabric, particularly if a layer 2 on= ly attached process is moved along with it's ARP cache, and something l= ike the EVPN default MAC is used to enable the move. I don't know if th= is is worth mentioning, but it does seem like a case that needs to be thoug= ht about to make certain it works with the process described.


no change necessary
=C2= =A0
=3D=3D
Section 5.3.3

"The leaf node MUST advertise a time stamp of the latest sighting...&q= uot;

Is this for all prefixes, or just for prefixes that are somehow marked or c= onfigured as potentially mobile on the fabric?


A leaf node MAY ...
=C2= =A0
=3D=3D
Section 5.3.3

"RIFT also defines an abstract negative clock (ANSC) that compares as = less than any other clock."

Does this mean lower priority, or always older than any other clock? It see= ms like this means "older" based on 5.3.3.1, but the language cou= ld probably be clearer.


nothing to do
=C2=A0
=3D=3D
Section 5.3.3

One thing not covered here is what happens if some workload moves between t= wo RIFT fabrics interconnected via some other protocol, such as BGP. It see= ms the most obvious solution is to have RIFT treat redistributed destinatio= ns the same as directly attached destinations in terms of clocks, etc., but= this is not called out in the document. It might be worth mentioning.


no action
=C2=A0
=3D=3D
Section 5.3.3.3

This section seems a little ... muddled? You want to both have the ability = to use only the most recently available versions of any anycast destination= , while also not requiring all the anycast advertisements to have the same = time stamp (?). I'm not certain this section entirely solves that probl= em. This sentence might be creating the confusion in my reading of the sect= ion, as I don't really understand what it is saying:

"An anycast prefix does not carry a clock or all clock attributes MUST= be the same under the rules of Section 5.3.3.1."

MUST be treated the same as prefixes advertised under the rules of 5.3.3.1?= I'm not certain.

it's complex = for a reason. left as that.
=C2=A0

=3D=3D
Section 5.3.3.4

"RIFT is agnostic whether any overlay technology like [MIP, LISP, VxLA= N, NVO3] and the associated signaling is deployed over it. But it is expect= ed that leaf nodes, and possibly Top-of-Fabric nodes can perform the accord= ing encapsulation."

"according" should be "correct," I think.

fine
=C2=A0

=3D=3D
Section 5.3.6.1

"All the multiplications and additions are saturating, i.e. when excee= ding range of the bandwidth type are set to highest possible value of the t= ype."

Maybe better:

"If a calculation produces a result exceeding the range of the type, t= he result is set to the highest possible value for that type."


fine



_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--000000000000674425058e81923f-- From nobody Thu Jul 25 06:41:59 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B53B120073; Thu, 25 Jul 2019 06:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=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 B9kBIKbf8pY7; Thu, 25 Jul 2019 06:41:47 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 B6796120261; Thu, 25 Jul 2019 06:41:43 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id w20so50251498edd.2; Thu, 25 Jul 2019 06:41:43 -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=uDvxWwHakzKd6zOyadV1WAlugRVA33bpwGc2rhaLvMY=; b=uj54h+buiLFQOJqSX4lQ6ULa1n2eHw87D+GU2NGPHZfZW+vc5WoGjY7xxId5PbD19Y VIZFMjyOBZ8rryfumo/NMO+cO8n/6Jqlhb2tDE8ChDyaEIKmd9IbQLYex49ZYIrzooQW rIZ3KVi2G1UgGDrluL1lZ3zVjo0ZQeVx6XR/bKiaR8cHUYUe3aVwIgDha8kKA76blbDJ rh7D63BZtVdq9UOpqFTyMG6A3SvrSaqZA5nGrLxY6UV05R3XzaEfsefJMn+ZX4zC8LTc h2RokByRc6Z3AJVDVg/Dx2uCKTD1G+r++UGiGWYR0MmhzuKOm7qBb27H+jSREV4wFwkI O0eg== 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=uDvxWwHakzKd6zOyadV1WAlugRVA33bpwGc2rhaLvMY=; b=XGuQFHwDJUS7yCBKgSJmikcfnXkTirxm0nn04sKdTOtt1bxvafbyy2IWNXtNLIPLai d61+tLzM+pz6gAWAEoHuBxY2FyNnFSOd1HgkCvX9HAuvc1dLZRE8xSe5cZKbtSgkMBLq xFlhXdCH6PxzXKabgXHcB8SRyIegDHLHLE09rLj8uHdSJdzMby7KZ+pGsWNPARAcyGjB CE2yhJZUYwDtH0idWWtXCajqpfQKSMLPOg+9KFA6sfN/hRqLiLRHkClTaPkUfCa9RxNS fVZaHrz85uVco1Hr+ZmrGFGil0buLlaMU/BaWvEIY1nPE/yagURBk+O3gGaDOKwUwVyx 41xw== X-Gm-Message-State: APjAAAWGSWdceXfhYO+GEHzNgPQWEoZE4t6Up1LdXJj3fy/jsDS3zwPI Z7jjO4MtWJK7mSg6rM99ln5apaku0waQeGc6tGI= X-Google-Smtp-Source: APXvYqxF/145XSDKXvOYJ2HXZ3AmU98UdJbjcJVnOpl1Ubki7fYuaiaJULNWR9UX2JMT8UvDRjC2r4TS+CssN9tyxtk= X-Received: by 2002:a50:b13b:: with SMTP id k56mr79339278edd.192.1564062102154; Thu, 25 Jul 2019 06:41:42 -0700 (PDT) MIME-Version: 1.0 References: <097e01d5418d$847ee300$8d7ca900$@riw.us> In-Reply-To: From: Tony Przygienda Date: Thu, 25 Jul 2019 09:41:06 -0400 Message-ID: To: Russ White Cc: rtg-wg-chairs@ietf.org, draft-ietf-rift-rift@ietf.org, rtg-dir@ietf.org, rift@ietf.org Content-Type: multipart/alternative; boundary="0000000000000173f6058e819654" Archived-At: Subject: Re: [RTG-DIR] [Rift] RtgDir Early review: draft-ietf-rift-rift-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 13:41:53 -0000 --0000000000000173f6058e819654 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BTW, if desired recordings of the ssions on my laptop and I can share them if desired. very tedious, very boring ... On Thu, Jul 25, 2019 at 9:40 AM Tony Przygienda wrote= : > Meeting minutes of the author/review meet on the comments > > On Tue, Jul 23, 2019 at 3:33 PM wrote: > >> Hello >> >> I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D= review of this >> draft. >> https://datatracker.ietf.org/doc/draft-foo-name/ >> >> The routing directorate will, on request from the working group chair, >> perform an =E2=80=9Cearly=E2=80=9D review of a draft before it is submit= ted for publication >> to the IESG. The early review can be performed at any time during the >> draft=E2=80=99s lifetime as a working group document. The purpose of the= early >> review depends on the stage that the document has reached. >> >> As this document has recently been adopted by the working group, my focu= s >> for the review is on providing a new perspective on the work, with the >> intention of catching any issues early on in the document's life cycle. >> >> For more information about the Routing Directorate, please see >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Document: draft-ietf-rift-rift-06 >> Reviewer: Russ White >> Review Date: 23 July 2019 >> Intended Status: Standards Track >> >> Summary: >> >> I have significant concerns about this document. It needs more work >> before being submitted to the IESG. >> >> Comments: >> >> Overall this draft is very readable, although I have suggested wording >> changes below. The protocol described is useful and interesting. I large= ly >> have questions about the structure and wording of the draft, although th= ere >> are a couple of technical questions in the comments below (probably just >> things I missed the explanation for, however). >> >> Structurally, this document almost feels like two different documents. >> The first specifies a set of use cases and requirements, while the secon= d >> specifies a protocol. I wonder if it wouldn't be better to split this >> document into two pieces, making each one more specific, and possibly a = bit >> easier to read? We might too late in the process to make such a change -= - >> if so, that's okay, just thought it might be worth considering. >> > > On the intro add sentence "this doc encompasses reqs, secs and specs" > > >> >> Throughout -- "fat tree," "Clos," and other terms are used in various >> places. As a reader, given the different meanings for these terms, I fou= nd >> this a bit confusing. It might be better to use "spine and leaf" through= out. >> > > Add to glossary: When we use term Clos we mean by it variants of Clos suc= h > as multi-plane and what is loosely called Fat Tree and even more generic > spine-and-leaf designs. > > >> Throughout -- the term "folded" has two very different meanings... The >> first is a multistage fabric on which traffic flows bi-directionally, th= e >> second is a way of drawing spine and leaf fabrics in blocks. It might be >> useful to clarify this from the beginning somehow, so readers who are >> expecting one meaning don't misread things because a different meaning i= s >> intended (?). I think it's always used here in the "way of drawing a spi= ne >> and leaf fabric" here. >> > > add to glossary: folded for us is drawing with spines on the top and > implicitly assuming bi-directionality on all leafs. > > >> >> =3D=3D >> Page 9 >> >> The definitions of the various forms of TIE might be better if they >> clearly differentiated between topology and reachability information (?)= . >> The OSPF router LSA, for instance, contains both kinds of information. I= n >> IS-IS, adjacencies, which are called Node TIES (I think) are tlv22, whil= e >> the Prefix TIE would be a tlv128 and 236. I don't think there is an >> equivalent separation between topology (reachable neighbors) and >> reachability (reachable prefixes) in OSPF. >> > > remove the "largely equivalent to OSPF Router LSA" part > > >> >> =3D=3D >> REQ13: "Taking a path through the spine in cases where a shorter path is >> available is highly undesirable." >> >> This doesn't seem to be related to the previous statements in the >> requirement... Not certain this needs to be included? Or maybe it wants = to >> be someplace else in the list? >> > > Split off the sentence > > >> =3D=3D >> REQ10 and REQ13 both seem to say the same thing -- although REQ13 is >> better worded. Maybe both of these are not needed? >> > > no action > > >> =3D=3D >> REQ15: "...links of a single node having same addresses." -- might be >> better as "...links of a single node sharing the same address." >> >> > accepted > > >> =3D=3D >> REQ18: "...security mechanisms that allow to restrict nodes, especially >> leafs without proper credentials from forming three-way adjacencies." >> >> Might be better as: >> >> "...security mechanisms that allow the operator to restrict nodes, >> especially leaf nodes without proper credentials, from forming a three-w= ay >> adjacency." >> >> > accepted > > =3D=3D >> PEND2: 500,000 seems way too small for the scale numbers I've heard in >> the past -- especially if we are including the underlay protocol running= on >> the hosts in the mix. If there are 300k ports is at least 1 prefix per e= dge >> port, and potentially 10-15 prefixes per edge port. If you guess around = 20% >> of the workloads attached to the fabric might be mobile, then the number >> here is more likely 1 million at the base, with a top end of around 2-3 >> million prefixes. It might be worth adjusting this number a bit larger (= ?). >> >> > PEND2 to be killed > > >> =3D=3D >> Section 5, paragraph after the header >> >> "...when "pointing north" and path vector [RFC4271] protocol when >> "pointing south". While this is an unusual combination,..." >> >> Elsewhere in the document "distance-vector" is used. It might be better >> to be consistent? >> >> > replace with distance vector > > >> =3D=3D >> Section 5.1.1 >> >> In the first paragraph ("The most singular property..."), omitting >> east-west control plane information flow is mentioned twice; could proba= bly >> just be once. >> > > Consult with Deborah whether we should tighten the prose or make it > "looser" ? > > >> The first sentence in the second paragraph is a bit of a run-on; might b= e >> best to omit some of this, or break it into two sentences. >> >> Second paragraph: "The application of those principle lead to RIFT..." >> doesn't seem right. Might be better as: "The application of these >> principles lead to RIFT..." >> > > accepted > > >> >> =3D=3D >> Section 5.1.2, paragraph beginning: "Given the difficulty of visualizing >> multi plane design which are..." First, this is one long sentence. Secon= d, >> what's illustrated looks like a crossbar, but it's not a crossbar. I fin= d >> this a little confusing (?). The problem is -- I don't know of another t= erm >> to use here. >> > > sentence needs splitting > > crossbar stands > > >> >> =3D=3D >> Section 5.1.2, paragraph beginning: "The typical topology for which RIFT >> is defined is built of a number P..." This seems to describe a five stag= e >> butterfly or pod-and-spine fabric, but does not seem to describe a seven >> stage (?). >> > > by a number of "top of fabric" nodes ... > > >> >> Overall -- I'm not certain trying to describe these topologies at this >> level in a protocol specification draft is all that useful. The terminol= ogy >> is fluid (used by different people in different ways), and this depth of >> explanation does not seem to be useful to describe the protocol operatio= n. >> This is one place where splitting the document into two pieces might be >> helpful. >> > > Word of caution sentence: please follow the glossary tightly, you get los= t > quickly otherwise ... > > >> >> =3D=3D >> Paragraph beginning: "It is critical at this junction that the concept >> and the picture of..." What is shown is not really a crossbar fabric... = I'm >> not certain calling this a crossbar is helpful here (?). >> > > add crossbar to glossary: physical arrangement of ports in a switching > matrix without implying any further scheduling or buffering disciplines > > >> =3D=3D >> Section 5.1.4: "This happens naturally in single plane design but needs >> additional considerations in multiplane fabrics." When aggregation is us= ed, >> as well -- but not when no aggregation of reachability information is >> deployed in the fabric. It might be worth adding that qualification here= . >> > > when aggregation is used > > >> >> =3D=3D >> Section 5.1.4 >> >> Sentence beginning: "In more detail, by reserving two ports on each >> Top-of-Fabric node it is possible to connect them together in an interpl= ane >> bi-directional ring as illustrated in Figure 13..." >> >> I might have missed it, but this document does not seem to address how >> traffic will be prevented from flowing through these links. It's probabl= y >> important to note either that traffic will flow along these links, hence >> they need to be sized appropriately, or how traffic is prevented from >> flowing along these links. >> >> > defect: spec the computation or "the computation has to prevent" . Enhace > section 5.2.4 by explaining how ToFs MUST not use the ring @ the top to > forward" > > >> =3D=3D >> Section 5.1.5 >> >> Sentence beginning: "The effect of a positive disaggregation..." If >> positive deaggregation takes place, it could draw all the traffic to the >> deaggregated destinations along a small set of links, causing a hot spot= in >> the fabric. This might be taken care of "naturally" in the way RIFT does >> positive deaggregation, but it might be good to explain this in the >> document. >> > > in the doc already > > >> >> A more general observation: positive deaggregation, as described in the >> document, can potentially cause cascading failures where a group of link= s >> or nodes fail, causing a lot of new information to be pushed into lower >> levels rather quickly, which could potentially cause those nodes to over= run >> their table or processing space and fail in turn, causing more informati= on >> to be dumped into the control plane, etc. It may be worth connsidering >> having some form of "hysteresis," timer or other mechanism to prevent >> cascading failures of this kind. >> > > positive is NOT transitive hence comment needs no addressing. > > Clarify maybe once more the fact. > > >> >> =3D=3D >> Section 5.2.2 >> >> "All RIFT routers MUST support IPv4 forwarding and MAY support IPv6..." >> >> So an IPv6 only fabric is not possible? >> > > based on multiple thread router requirements are removed > > >> >> =3D=3D >> Section 5.2.6 >> >> "After the SPF is run, it is necessary to attach according prefixes." >> >> I think this might want to mean -- >> >> "After SPF is run, it is necessary to attach the resulting reachability >> information in the form of prefixes." >> >> > agreed > > >> (?) >> >> =3D=3D >> Section 5.2.6 >> >> It seems like the first and third paragraphs describe the same procedure= ? >> Are both descriptions necessary? >> > > need to be merged > > >> =3D=3D >> Section 5.2.6 >> >> "An exemplary implementation..." should probably be "an example >> implementation..." ?? >> >> =3D=3D >> Section 5.2.6 >> >> "After the positive prefixes are attached and tie-broken, negative >> prefixes are attached and used in case of northbound computation, ideall= y >> from the shortest length to the longest." >> > > >> >> It seems like the prefixes should be "tie-broken" before being attached. >> This sentence is generally confusing, perhaps: >> > >> "After the positive prefixes have been attached, the negative prefixes >> will be attached in their prefix-length order (from the shortest to the >> longest). These negative prefixes will only be used when computing >> northbound reachability." >> > > "Attach all prefixes. Then build next-hop per type. Thne within types > tie-break by sequence in the model. if only negative remains run the > according algorithm" > > Special Consideration for securtity Host implementation: suggestion to > throttle aggressively, implementation on the ToR to max-prefix/max-state > knobbing > > >> >> =3D=3D >> Section 5.2.6 >> >> "Observe that despite seeming quite computationally expensive the >> operations are only necessary if the only available advertisements for a >> prefix are negative since tie-breaking always prefers positive informati= on >> for the prefix which stops any kind of recursion since positive informat= ion >> never inherits next hops." >> >> Just because something is not done all that often does not mean it's not >> computationally expensive. :-) Maybe something like this would be better= : >> >> "Although these operations can be computationally expensive, the overall >> load on devices in the network is low because these computations are not >> run very often, as positive route advertisements are always preferred ov= er >> negative ones. This prevents recursion in most cases because positive >> reachability information never inherits next hops." >> >> Or something like this? >> > > ack > > >> >> =3D=3D >> Section 5.2.6 >> >> "Negative 2001:db8::/32 entry inherits from" >> >> Probably wants to be "The negative 2001:db8::/32 entry..." >> > > nit > > >> =3D=3D >> Section 5.2.6 >> >> "Finally, let us look at the case where S3 becomes available again as >> default gateway, ..." >> >> "...the default gateway..." or "...a default gateway..." >> >> ack > > >> =3D=3D >> Section 5.2.7 >> >> "Each RIFT node can optionally operate in zero touch provisioning..." >> >> "optionally" is not needed here >> > > "RIFT nodes MAY use ZTP or be configured, both modes being mixed in the > same instance if desired" > > remove optionally > > >> >> =3D=3D >> Section 5.2.7.2 >> >> "RIFT identifies each node via a SystemID which is a 64 bits wide >> integer. It is relatively simple to derive a, for all practical purposes >> collision free, value for each node on startup. For that purpose, a node >> MUST use as system ID EUI-64 MA-L format [EUI64] where the organizationa= lly >> governed 24 bits can be used to generate system IDs for multiple RIFT >> instances running on the system." >> >> This seems too wordy -- maybe: >> >> "RIFT nodes require a 64 bit SystemID in the EUI-64 MA-L format formed a= s >> described in [EUI64]. The organizationally goverened portion of this ID >> (24 bits) can be used to generate multiple IDs if required to indicate m= ore >> than one RIFT instance." >> > > "As prescribed by EUI ... RIFT nodes MUST form a 64 bit SID > > >> >> =3D=3D >> Section 5.3.1 >> >> "Overload Bit MUST be respected..." >> >> should be >> >> "The overload bit MUST be respected..." >> >> > ack > > >> =3D=3D >> Section 5.3.2 >> >> "Since the leafs do see only "one hop away" they do not need to run a >> full SPF but can simply gather prefix candidates from their neighbors an= d >> build the according routing table." >> >> Seems like this should be >> >> "Since leaf nodes only have one hop of topology information, they do not >> need to run SPF. Instead, they can gather the available prefix candidate= s >> and build the routing table accordingly." >> > > ack > > >> >> =3D=3D >> Section 5.3.3 >> >> "time stamp: With this method, the infrastructure memorizes the..." >> >> I think the correct word here is "records," rather than "memorizes" (?) >> > > ack > > >> >> =3D=3D >> Section 5.3.3 >> >> "sequence counter: With this method, a mobile node notifies its point...= " >> >> Another problem here is the node might not "know" it has been moved from >> one location to another in the fabric, particularly if a layer 2 only >> attached process is moved along with it's ARP cache, and something like = the >> EVPN default MAC is used to enable the move. I don't know if this is wor= th >> mentioning, but it does seem like a case that needs to be thought about = to >> make certain it works with the process described. >> >> > no change necessary > > >> =3D=3D >> Section 5.3.3 >> >> "The leaf node MUST advertise a time stamp of the latest sighting..." >> >> Is this for all prefixes, or just for prefixes that are somehow marked o= r >> configured as potentially mobile on the fabric? >> >> > A leaf node MAY ... > > >> =3D=3D >> Section 5.3.3 >> >> "RIFT also defines an abstract negative clock (ANSC) that compares as >> less than any other clock." >> >> Does this mean lower priority, or always older than any other clock? It >> seems like this means "older" based on 5.3.3.1, but the language could >> probably be clearer. >> >> > nothing to do > > >> =3D=3D >> Section 5.3.3 >> >> One thing not covered here is what happens if some workload moves betwee= n >> two RIFT fabrics interconnected via some other protocol, such as BGP. It >> seems the most obvious solution is to have RIFT treat redistributed >> destinations the same as directly attached destinations in terms of cloc= ks, >> etc., but this is not called out in the document. It might be worth >> mentioning. >> >> > no action > > >> =3D=3D >> Section 5.3.3.3 >> >> This section seems a little ... muddled? You want to both have the >> ability to use only the most recently available versions of any anycast >> destination, while also not requiring all the anycast advertisements to >> have the same time stamp (?). I'm not certain this section entirely solv= es >> that problem. This sentence might be creating the confusion in my readin= g >> of the section, as I don't really understand what it is saying: >> >> "An anycast prefix does not carry a clock or all clock attributes MUST b= e >> the same under the rules of Section 5.3.3.1." >> >> MUST be treated the same as prefixes advertised under the rules of >> 5.3.3.1? I'm not certain. >> > > it's complex for a reason. left as that. > > >> >> =3D=3D >> Section 5.3.3.4 >> >> "RIFT is agnostic whether any overlay technology like [MIP, LISP, VxLAN, >> NVO3] and the associated signaling is deployed over it. But it is expect= ed >> that leaf nodes, and possibly Top-of-Fabric nodes can perform the accord= ing >> encapsulation." >> >> "according" should be "correct," I think. >> > > fine > > >> >> =3D=3D >> Section 5.3.6.1 >> >> "All the multiplications and additions are saturating, i.e. when >> exceeding range of the bandwidth type are set to highest possible value = of >> the type." >> >> Maybe better: >> >> "If a calculation produces a result exceeding the range of the type, the >> result is set to the highest possible value for that type." >> >> > fine > > >> >> _______________________________________________ >> RIFT mailing list >> RIFT@ietf.org >> https://www.ietf.org/mailman/listinfo/rift >> > --0000000000000173f6058e819654 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BTW, if desired recordings of the ssions on my laptop and = I can share them if desired. very tedious, very boring ...

On Thu, Jul = 25, 2019 at 9:40 AM Tony Przygienda <tonysietf@gmail.com> wrote:
Meeting minutes of= the author/review meet on the comments

On Tue, Jul 23, 2019 at 3:33 PM = <russ@riw.us> wr= ote:
Hello

I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re= view of this draft.
https://datatracker.ietf.org/doc/draft-foo-name/=

The routing directorate will, on request from the working group chair, perf= orm an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for= publication to the IESG. The early review can be performed at any time dur= ing the draft=E2=80=99s lifetime as a working group document. The purpose o= f the early review depends on the stage that the document has reached.

As this document has recently been adopted by the working group, my focus f= or the review is on providing a new perspective on the work, with the inten= tion of catching any issues early on in the document's life cycle.

For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-rift-rift-06
Reviewer: Russ White
Review Date: 23 July 2019
Intended Status: Standards Track

Summary:

I have significant concerns about this document. It needs more work before = being submitted to the IESG.

Comments:

Overall this draft is very readable, although I have suggested wording chan= ges below. The protocol described is useful and interesting. I largely have= questions about the structure and wording of the draft, although there are= a couple of technical questions in the comments below (probably just thing= s I missed the explanation for, however).

Structurally, this document almost feels like two different documents. The = first specifies a set of use cases and requirements, while the second speci= fies a protocol. I wonder if it wouldn't be better to split this docume= nt into two pieces, making each one more specific, and possibly a bit easie= r to read? We might too late in the process to make such a change -- if so,= that's okay, just thought it might be worth considering.

On the intro add sentence "this doc encompasses= reqs, secs and specs"
=C2=A0

Throughout -- "fat tree," "Clos," and other terms are u= sed in various places. As a reader, given the different meanings for these = terms, I found this a bit confusing. It might be better to use "spine = and leaf" throughout.

Add to glossary: = When we use term Clos we mean by it variants of Clos such as multi-plane an= d what is loosely called Fat Tree and even more generic spine-and-leaf desi= gns.


Throughout -- the term "folded" has two very different meanings..= . The first is a multistage fabric on which traffic flows bi-directionally,= the second is a way of drawing spine and leaf fabrics in blocks. It might = be useful to clarify this from the beginning somehow, so readers who are ex= pecting one meaning don't misread things because a different meaning is= intended (?). I think it's always used here in the "way of drawin= g a spine and leaf fabric" here.

a= dd to glossary: folded for us is drawing with spines on the top and implici= tly assuming bi-directionality on all leafs.
=C2=A0

=3D=3D
Page 9

The definitions of the various forms of TIE might be better if they clearly= differentiated between topology and reachability information (?). The OSPF= router LSA, for instance, contains both kinds of information. In IS-IS, ad= jacencies, which are called Node TIES (I think) are tlv22, while the Prefix= TIE would be a tlv128 and 236. I don't think there is an equivalent se= paration between topology (reachable neighbors) and reachability (reachable= prefixes) in OSPF.

remove the "<= span style=3D"font-size:16.5px;font-family:monospace">largely equivalent to= OSPF Router LSA" part
=C2=A0

=3D=3D
REQ13: "Taking a path through the spine in cases where a shorter path = is available is highly undesirable."

This doesn't seem to be related to the previous statements in the requi= rement... Not certain this needs to be included? Or maybe it wants to be so= meplace else in the list?

Split off the= sentence


=3D=3D
REQ10 and REQ13 both seem to say the same thing -- although REQ13 is better= worded. Maybe both of these are not needed?

no action


=3D=3D
REQ15: "...links of a single node having same addresses." -- migh= t be better as "...links of a single node sharing the same address.&qu= ot;


accepted
=C2=A0
=3D=3D
REQ18: "...security mechanisms that allow to restrict nodes, especiall= y leafs without proper credentials from forming three-way adjacencies."= ;

Might be better as:

"...security mechanisms that allow the operator to restrict nodes, esp= ecially leaf nodes without proper credentials, from forming a three-way adj= acency."


accepted

=3D=3D
PEND2: 500,000 seems way too small for the scale numbers I've heard in = the past -- especially if we are including the underlay protocol running on= the hosts in the mix. If there are 300k ports is at least 1 prefix per edg= e port, and potentially 10-15 prefixes per edge port. If you guess around 2= 0% of the workloads attached to the fabric might be mobile, then the number= here is more likely 1 million at the base, with a top end of around 2-3 mi= llion prefixes. It might be worth adjusting this number a bit larger (?).

PEND2 to be killed
=C2= =A0
=3D=3D
Section 5, paragraph after the header

"...when "pointing north" and path vector [RFC4271] protocol= when "pointing south". While this is an unusual combination,...&= quot;

Elsewhere in the document "distance-vector" is used. It might be = better to be consistent?


replace with distance vector
=C2=A0
=3D=3D
Section 5.1.1

In the first paragraph ("The most singular property..."), omittin= g east-west control plane information flow is mentioned twice; could probab= ly just be once.

Consult with Deborah w= hether we should tighten the prose or make it "looser" ?


The first sentence in the second paragraph is a bit of a run-on; might be b= est to omit some of this, or break it into two sentences.

Second paragraph: "The application of those principle lead to RIFT...&= quot; doesn't seem right. Might be better as: "The application of = these principles lead to RIFT..."

= accepted
=C2=A0

=3D=3D
Section 5.1.2, paragraph beginning: "Given the difficulty of visualizi= ng multi plane design which are..." First, this is one long sentence. = Second, what's illustrated looks like a crossbar, but it's not a cr= ossbar. I find this a little confusing (?). The problem is -- I don't k= now of another term to use here.

senten= ce needs splitting

crossbar stands
= =C2=A0

=3D=3D
Section 5.1.2, paragraph beginning: "The typical topology for which RI= FT is defined is built of a number P..." This seems to describe a five= stage butterfly or pod-and-spine fabric, but does not seem to describe a s= even stage (?).

by a number of "to= p of fabric" nodes ...
=C2=A0

Overall -- I'm not certain trying to describe these topologies at this = level in a protocol specification draft is all that useful. The terminology= is fluid (used by different people in different ways), and this depth of e= xplanation does not seem to be useful to describe the protocol operation. T= his is one place where splitting the document into two pieces might be help= ful.

Word of caution sentence: please f= ollow the glossary tightly, you get lost quickly otherwise ...
=C2=A0

=3D=3D
Paragraph beginning: "It is critical at this junction that the concept= and the picture of..." What is shown is not really a crossbar fabric.= .. I'm not certain calling this a crossbar is helpful here (?).

add crossbar to glossary:=C2=A0 physical arran= gement of ports in a switching matrix without implying any further scheduli= ng or buffering disciplines


=3D=3D
Section 5.1.4: "This happens naturally in single plane design but need= s additional considerations in multiplane fabrics." When aggregation i= s used, as well -- but not when no aggregation of reachability information = is deployed in the fabric. It might be worth adding that qualification here= .

when aggregation is used
=C2=A0

=3D=3D
Section 5.1.4

Sentence beginning: "In more detail, by reserving two ports on each To= p-of-Fabric node it is possible to connect them together in an interplane b= i-directional ring as illustrated in Figure 13..."

I might have missed it, but this document does not seem to address how traf= fic will be prevented from flowing through these links. It's probably i= mportant to note either that traffic will flow along these links, hence the= y need to be sized appropriately, or how traffic is prevented from flowing = along these links.


defect: spec the computation or "= the computation has to prevent" . Enhace section 5.2.4 by explaining h= ow ToFs MUST not use the ring @ the top to forward"
=C2= =A0
=3D=3D
Section 5.1.5

Sentence beginning: "The effect of a positive disaggregation..." = If positive deaggregation takes place, it could draw all the traffic to the= deaggregated destinations along a small set of links, causing a hot spot i= n the fabric. This might be taken care of "naturally" in the way = RIFT does positive deaggregation, but it might be good to explain this in t= he document.

in the doc already
=C2=A0

A more general observation: positive deaggregation, as described in the doc= ument, can potentially cause cascading failures where a group of links or n= odes fail, causing a lot of new information to be pushed into lower levels = rather quickly, which could potentially cause those nodes to overrun their = table or processing space and fail in turn, causing more information to be = dumped into the control plane, etc. It may be worth connsidering having som= e form of "hysteresis," timer or other mechanism to prevent casca= ding failures of this kind.

positive is= NOT transitive hence comment needs no addressing.

Clarify maybe once more the fact.
=C2=A0

=3D=3D
Section 5.2.2

"All RIFT routers MUST support IPv4 forwarding and MAY support IPv6...= "

So an IPv6 only fabric is not possible?

based on multiple thread router requirements are removed
= =C2=A0

=3D=3D
Section 5.2.6

"After the SPF is run, it is necessary to attach according prefixes.&q= uot;

I think this might want to mean --

"After SPF is run, it is necessary to attach the resulting reachabilit= y information in the form of prefixes."


agreed
=C2=A0
(?)

=3D=3D
Section 5.2.6

It seems like the first and third paragraphs describe the same procedure? A= re both descriptions necessary?

need to= be merged


=3D=3D
Section 5.2.6

"An exemplary implementation..." should probably be "an exam= ple implementation..." ??

=3D=3D
Section 5.2.6

"After the positive prefixes are attached and tie-broken, negative pre= fixes are attached and used in case of northbound computation, ideally from= the shortest length to the longest."
=C2=A0

It seems like the prefixes should be "tie-broken" before being at= tached. This sentence is generally confusing, perhaps:

"After the positive prefixes have been attached, the negative prefixes= will be attached in their prefix-length order (from the shortest to the lo= ngest). These negative prefixes will only be used when computing northbound= reachability."

"Attach all p= refixes. Then build next-hop per type. Thne within types tie-break by seque= nce in the model. if only negative remains run the according algorithm"= ;

Special Consideration for = securtity Host implementation: suggestion to throttle aggressively, impleme= ntation on the ToR to max-prefix/max-state knobbing
=C2=A0

=3D=3D
Section 5.2.6

"Observe that despite seeming quite computationally expensive the oper= ations are only necessary if the only available advertisements for a prefix= are negative since tie-breaking always prefers positive information for th= e prefix which stops any kind of recursion since positive information never= inherits next hops."

Just because something is not done all that often does not mean it's no= t computationally expensive. :-) Maybe something like this would be better:=

"Although these operations can be computationally expensive, the overa= ll load on devices in the network is low because these computations are not= run very often, as positive route advertisements are always preferred over= negative ones. This prevents recursion in most cases because positive reac= hability information never inherits next hops."

Or something like this?

ack
=C2=A0

=3D=3D
Section 5.2.6

"Negative 2001:db8::/32 entry inherits from"

Probably wants to be "The negative 2001:db8::/32 entry..."

nit


=3D=3D
Section 5.2.6

"Finally, let us look at the case where S3 becomes available again as = default gateway, ..."

"...the default gateway..." or "...a default gateway..."= ;

ack
=C2=A0
=3D=3D
Section 5.2.7

"Each RIFT node can optionally operate in zero touch provisioning...&q= uot;

"optionally" is not needed here

"RIFT nodes MAY use ZTP or be configured, both modes being mixed in= the same instance if desired"

remove optiona= lly
=C2=A0

=3D=3D
Section 5.2.7.2

"RIFT identifies each node via a SystemID which is a 64 bits wide inte= ger. It is relatively simple to derive a, for all practical purposes collis= ion free, value for each node on startup. For that purpose, a node MUST use= as system ID EUI-64 MA-L format [EUI64] where the organizationally governe= d 24 bits can be used to generate system IDs for multiple RIFT instances ru= nning on the system."

This seems too wordy -- maybe:

"RIFT nodes require a 64 bit SystemID in the EUI-64 MA-L format formed= as described in [EUI64]. The organizationally goverened portion of this ID= =C2=A0 (24 bits) can be used to generate multiple IDs if required to indica= te more than one RIFT instance."

&= quot;As prescribed by EUI ... RIFT nodes MUST form a 64 bit SID=C2=A0
<= /div>
=C2=A0

=3D=3D
Section 5.3.1

"Overload Bit MUST be respected..."

should be

"The overload bit MUST be respected..."


ack
=C2=A0
=3D=3D
Section 5.3.2

"Since the leafs do see only "one hop away" they do not need= to run a full SPF but can simply gather prefix candidates from their neigh= bors and build the according routing table."

Seems like this should be

"Since leaf nodes only have one hop of topology information, they do n= ot need to run SPF. Instead, they can gather the available prefix candidate= s and build the routing table accordingly."

<= /div>
ack
=C2=A0

=3D=3D
Section 5.3.3

"time stamp: With this method, the infrastructure memorizes the...&quo= t;

I think the correct word here is "records," rather than "mem= orizes" (?)

ack
=C2= =A0

=3D=3D
Section 5.3.3

"sequence counter: With this method, a mobile node notifies its point.= .."

Another problem here is the node might not "know" it has been mov= ed from one location to another in the fabric, particularly if a layer 2 on= ly attached process is moved along with it's ARP cache, and something l= ike the EVPN default MAC is used to enable the move. I don't know if th= is is worth mentioning, but it does seem like a case that needs to be thoug= ht about to make certain it works with the process described.


no change necessary
=C2= =A0
=3D=3D
Section 5.3.3

"The leaf node MUST advertise a time stamp of the latest sighting...&q= uot;

Is this for all prefixes, or just for prefixes that are somehow marked or c= onfigured as potentially mobile on the fabric?


A leaf node MAY ...
=C2= =A0
=3D=3D
Section 5.3.3

"RIFT also defines an abstract negative clock (ANSC) that compares as = less than any other clock."

Does this mean lower priority, or always older than any other clock? It see= ms like this means "older" based on 5.3.3.1, but the language cou= ld probably be clearer.


nothing to do
=C2=A0
=3D=3D
Section 5.3.3

One thing not covered here is what happens if some workload moves between t= wo RIFT fabrics interconnected via some other protocol, such as BGP. It see= ms the most obvious solution is to have RIFT treat redistributed destinatio= ns the same as directly attached destinations in terms of clocks, etc., but= this is not called out in the document. It might be worth mentioning.


no action
=C2=A0
=3D=3D
Section 5.3.3.3

This section seems a little ... muddled? You want to both have the ability = to use only the most recently available versions of any anycast destination= , while also not requiring all the anycast advertisements to have the same = time stamp (?). I'm not certain this section entirely solves that probl= em. This sentence might be creating the confusion in my reading of the sect= ion, as I don't really understand what it is saying:

"An anycast prefix does not carry a clock or all clock attributes MUST= be the same under the rules of Section 5.3.3.1."

MUST be treated the same as prefixes advertised under the rules of 5.3.3.1?= I'm not certain.

it's complex = for a reason. left as that.
=C2=A0

=3D=3D
Section 5.3.3.4

"RIFT is agnostic whether any overlay technology like [MIP, LISP, VxLA= N, NVO3] and the associated signaling is deployed over it. But it is expect= ed that leaf nodes, and possibly Top-of-Fabric nodes can perform the accord= ing encapsulation."

"according" should be "correct," I think.

fine
=C2=A0

=3D=3D
Section 5.3.6.1

"All the multiplications and additions are saturating, i.e. when excee= ding range of the bandwidth type are set to highest possible value of the t= ype."

Maybe better:

"If a calculation produces a result exceeding the range of the type, t= he result is set to the highest possible value for that type."


fine



_______________________________________________
RIFT mailing list
RIFT@ietf.org
https://www.ietf.org/mailman/listinfo/rift
--0000000000000173f6058e819654-- From nobody Mon Jul 29 17:37:57 2019 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BAD120059; Mon, 29 Jul 2019 17:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=kEo2tAQv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iuZb0OEm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j6E0y-tf1ef; Mon, 29 Jul 2019 17:37:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021FC120019; Mon, 29 Jul 2019 17:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18651; q=dns/txt; s=iport; t=1564447065; x=1565656665; h=from:to:cc:subject:date:message-id:mime-version; bh=qiy+KxJnz4iVjMDylbUB0LdKtUiaSMLJGqCkwDHMNJQ=; b=kEo2tAQvJDAFAOb+LVWOhtNUMvy6/DN7gyXqxdQA0GmLHE90FFAvkFlQ Z/d9r1PeYEpWK3enhf6wCCKEj4QzdhDr3pGVrkckg1otZH5LXkF/Zutbb MQ13kriI3fBwj4nndwPpBjhzeR09AAVl8dQQo9SkTOxpa3e14E6+D9hXi w=; IronPort-PHdr: =?us-ascii?q?9a23=3AiH+vxBDpYbz8HGXe9y2mUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXETwIfPCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAQCMkD9d/5tdJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBZ4EVL1ADbVUgBAsqhB6DRwONBIJbknyEV4FCgRADVAkBAQEMAQE?= =?us-ascii?q?jCgIBAYRAGYJVIzgTAQMBAQQBAQIBBm2FHgyFSgEBAQEDEhEKEwEBNwERAQg?= =?us-ascii?q?RAwEBASsCBDAdCgQBDQUigwABgR1NAx0BAgyhaAKBOIhgcYEygnoBAQWFDBi?= =?us-ascii?q?CEwmBNIRyhm4XgX+BEScfgkw+glYLAgKBRziCazKCJowygkyEf5Z+CQKCGoV?= =?us-ascii?q?7YIRviEobgi5thjiOO407h0qQDAIEAgQFAg4BAQWBPSohgVhwFTsqAYJBCYI?= =?us-ascii?q?5DBeDToUUhT9yAYEojHIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,324,1559520000"; d="scan'208,217";a="604998482" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2019 00:37:43 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6U0bhOw015237 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2019 00:37:43 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 19:37:43 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 20:37:42 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 29 Jul 2019 19:37:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T/SbUMS1ngy74DiG1xhmmfSNHHik0pjQn1Vw5zMqoMWXjxM/VJ8ceWeCVXgjzruQjokFQHSrNVaUY0o1d6z9rRO8uhqIEiSFVd3RGWM9w/FX457Q2MjvFzc3mXXu31uLoZ21UnnnQ2k1684FOQoNlIsKrIU+fOgufK1EMtD8v0weQtkLbhwjQDpeH49biTPeMn4m7YSAlP0ImuX+UP9kumqlwCBDY2GUSHwmZ4pQAK0IVEwmLsbHqb+apf4g8YbFgD3xmFnT45BR7nNOGidZS5PVZ7lIOUd47BVheD8knaAaD+TKtr1LahxWjezKq3fqol/UcYW1UwoeT7w8ibV5Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qiy+KxJnz4iVjMDylbUB0LdKtUiaSMLJGqCkwDHMNJQ=; b=DA91yi9C7cw2yw20lkUVr3X1qJrofYkriT9mnn0YGHytB3gVlUP7iso5g6t9e9Y7koh/OqLBP9BvIcOHSzXB8dBbz82r+vc1NtzqSbVdcqZnLiFjjRDiK5hTFFlX6IpjWqH5zY2DsqeWR1gn/P4pcxh8QI93/xvrFIi6RUEXF7iXeiduk3teXTye70DFoHYgCRXaJjURoAXP6SkkVWqPRHPA2AG5KWDK+KvwhFksMpLSffki7peJxIK4JC4ji/zcr0MwFaRsnpUUXmajN2eRUDckXFVo/TJVCthOJEDhmgykMJb6bPI6KpGRNHgKT3r8f/qCnZS/hZ+npn3ciSClKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qiy+KxJnz4iVjMDylbUB0LdKtUiaSMLJGqCkwDHMNJQ=; b=iuZb0OEm1k2B+tYaaIKrwUv4MgrfB/so48QTqRr8abqfFOLiHEfTdhLPG9mx7EAPze0JElS/5qWoquVQS8Zbd7ZEF2zRlKDKrXp5iCgiG2Eb9RLhai8ioO8d0WHew9XDoS/jybR4HsM7G35mujpCkVjq9AKwfuabpM+PI/TgtqM= Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB3568.namprd11.prod.outlook.com (20.178.251.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Tue, 30 Jul 2019 00:37:41 +0000 Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::859c:f271:3be2:74e0%3]) with mapi id 15.20.2115.005; Tue, 30 Jul 2019 00:37:41 +0000 From: "Acee Lindem (acee)" To: Ravi Singh , Routing ADs CC: Routing Directorate , "draft-ietf-ospf-yang@ietf.org" , "lsr@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ospf-yang-23.txt Thread-Index: AQHVRm7+MCjGxKXQ2U+eEU7n9zKpyg== Date: Tue, 30 Jul 2019 00:37:41 +0000 Message-ID: <39C97F37-E68C-4D02-AD06-CE4854F79347@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [2001:420:c0c4:1003::98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c5d3138-d33b-4b6e-9773-08d71486213a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3568; x-ms-traffictypediagnostic: MN2PR11MB3568: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(376002)(396003)(136003)(346002)(51914003)(189003)(199004)(6436002)(486006)(33656002)(68736007)(6486002)(2906002)(46003)(2616005)(476003)(14454004)(36756003)(25786009)(256004)(6116002)(14444005)(478600001)(229853002)(99286004)(4326008)(606006)(81156014)(53936002)(6512007)(6306002)(54896002)(6246003)(236005)(71190400001)(71200400001)(5660300002)(186003)(8676002)(76116006)(81166006)(64756008)(66946007)(54906003)(102836004)(66556008)(110136005)(66476007)(8936002)(53546011)(316002)(86362001)(66446008)(6506007)(7736002)(9326002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3568; H:MN2PR11MB4221.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SycLU2USkstF9aXXtqdcqQrkFNofcrSy7sj+zp0hOPXM3+787z382mrG6CQX0gFEd8+ChzCN6d63yZOBYXgH/jTEJLlImyXd85bUKD3QPlmoDaR4tOpI1Gl13MSJl5FL+ku80QTsrfPDHGlCM62Pg36EU3T1oD9/Qw5vZRMig9XP9w71IyEB5OtuTT2wqkf48Dk0fcNdmCLEfDKyVj+guG4D1j8KTojfQO75VZ2TGNahK7zL6Nzpcnv3uvKVi/250470JIKsyV+r/e0Aj7UUR/KsawwgMxyMtTC13FEpDnciWgGgJqN+79Wl0gvLitG8mw3NR7/SDLrZcY9bz4Zt5bMAWLJ4N9hT0AMZ1qmASiI5xk1mjVlb/dQNP1PciM3Pekcl/8pRGApRdydmbdoxgUnpw9h7ykBTWZjbl1bciGE= Content-Type: multipart/alternative; boundary="_000_39C97F37E68C4D02AD06CE4854F79347ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2c5d3138-d33b-4b6e-9773-08d71486213a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2019 00:37:41.0666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: acee@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3568 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ospf-yang-23.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 00:37:48 -0000 --_000_39C97F37E68C4D02AD06CE4854F79347ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmF2aSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJ4oCZdmUgaW5jb3Jwb3JhdGVkIHlv dXIgY29tbWVudHMuIFNlZSBpbmxuZS4NCg0KRnJvbTogcnRnLWRpciA8cnRnLWRpci1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUmF2aSBTaW5naCA8cmF2aXM9NDBqdW5pcGVyLm5ldEBk bWFyYy5pZXRmLm9yZz4NCkRhdGU6IFRodXJzZGF5LCBKdWx5IDE4LCAyMDE5IGF0IDEwOjQ0IFBN DQpUbzogUm91dGluZyBBRHMgPHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc+DQpDYzogUm91dGluZyBE aXJlY3RvcmF0ZSA8cnRnLWRpckBpZXRmLm9yZz4sICJkcmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRm Lm9yZyIgPGRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYub3JnPiwgImxzckBpZXRmLm9yZyIgPGxz ckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQt aWV0Zi1vc3BmLXlhbmctMjMudHh0DQoNCisgbHNyQGlldGYub3JnDQoNCkZyb206IFJhdmkgU2lu Z2gNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE4LCAyMDE5IDc6NDMgUE0NClRvOiBSb3V0aW5nIEFE cyA8cnRnLWFkc0B0b29scy5pZXRmLm9yZz4NCkNjOiBSb3V0aW5nIERpcmVjdG9yYXRlIDxydGct ZGlyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmc7IG9zcGZAaWV0Zi5v cmcNClN1YmplY3Q6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtb3NwZi15YW5nLTIzLnR4dA0K DQpIZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1l cyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJv dmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3VnaCB0aGVz ZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywg aXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRo IGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQg c3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcg dGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1vc3BmLXlhbmctMjMudHh0DQpSZXZp ZXdlcjogUmF2aSBTaW5naA0KUmV2aWV3IERhdGU6IDcvMTgvMjAxOQ0KSW50ZW5kZWQgU3RhdHVz OiBTdGFuZGFyZHMgVHJhY2sNCg0KU3VtbWFyeToNClRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5 IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNp ZGVyZWQgcHJpb3IgdG8gcHVibGljYXRpb24uDQoNClRoaXMgaXMgYSB2ZXJ5IGNvbXByZWhlbnNp dmVseSB3cml0dGVuIGRvY3VtZW50Lg0KSG93ZXZlciwgcmVhZGluZyB0aHJvdWdoIGl0IGlzIGEg Yml0IGxhYm9yaW91cyBkdWUgdG8gdGhlIHJlYWxseSBsYXJnZSAjIG9mIGNvbmZpZyBhbmQgb3Bl cmF0aW9uYWwgaXRlbXMgZGVzY3JpYmVkLg0KU28sIG15IHJldmlldyB3YXMgcHJpbWFyaWx5IGFp bWVkIGF0IHJlYWRhYmlsaXR5IHJhdGhlciB0aGFuIGNvcnJlY3RuZXNzIG9mIHRoZSBZQU5HIHN5 bnRheC4NCg0KU3BlY2lmaWMgY29tbWVudHMvcXVlcmllczoNCjEuICAgICAgIFdoYXQgaXMgdGhl IHJlYXNvbmluZyBmb3Igc3RpY2tpbmcgdGhlIG11bHRpLXRvcG9sb2d5IHN1Yi1jb250YWluZXIo cykgYXQgdGhlIHNhbWUgbGV2ZWxzIGFzIGFyZWEgaW5zdGVhZCBvZiBhdCB0aGUgbGV2ZWwgb2Yg c3ViLWNvbnRhaW5lcnMgdW5kZXIgYXJlYShzKT8NCg0KT1NQRiBNdWx0aS1Ub3BvbG9neSBpcyBu b3QgYSB3aWRlbHkgZGVwbG95ZWQgZmVhdHVyZSBhbmQgdGhhdCBpcyB3aHkgd2UgZGlkIGl0IHdp dGggYXVnbWVudGF0aW9ucy4gSeKAmXZlIHJlbW92ZWQgdGhlIGFyZWEgbGlzdCBmcm9tIHRoZSBp bnN0YW5jZSBsZXZlbCBhdWdtZW50YXRpb24gYW5kIGFkZGVkIGEgc2VwYXJhdGUgYXVnbWVudGF0 aW9uIGF0IHRoZSBhcmVhIGxldmVsLiBUaGlzIGNoYW5nZSB3aWxsIGJlIGluIHRoZSAtMjQgdmVy c2lvbi4NCg0KMi4gICAgICAgUGcgMjM6IHdoeSBib3RoIChwcmVmaXggInJ0LXR5cGVzIjspIGFu ZCAocHJlZml4ICJpYW5hLXJ0LXR5cGVzIjspID8NClRoZXkgYXJlIHR3byBzZXBhcmF0ZSBtb2Rl bHMgaW4gdGhlIFJGQyA4Mjk0LiBUaGUgbGF0dGVyIG1vZHVsZSBpcyBtYWludGFpbmVkIGJ5IElB TkEuDQoNCjMuICAgICAgIFBnIDI1LTI4OiAiZmVhdHVyZSB0d28tcGFydC1tZXRyaWMgeyIgYW5k ICJmZWF0dXJlIGtleS1jaGFpbiB7IiBtaWdodCBiZSByZWFkanVzdGVkIGluIG9yZGVyIG9mIGxp c3RpbmcgdG8gbWFrZSBpdCB0aGUgc2FtZSBhcyB0aGF0IGluIHNlY3Rpb24gMi40IGZvciBhIGJp dCBvZiBlbmhhbmNlZCByZWFkYWJpbGl0eS4NCg0KSSBhZ3JlZS4gSG93ZXZlciwgSeKAmXZlIHJl bW92ZWQgdHdvLXBhcnQgbWV0cmljIGFuZCBpdCB3aWxsIGJlIGluIHRoZSBhdWdtZW50YXRpb24g ZHJhZnQuDQoNClRoYW5rcywNCkFjZWUNCg0KUmVnYXJkcw0KUmF2aQ0KDQoNCg== --_000_39C97F37E68C4D02AD06CE4854F79347ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIxMjg0MzA5MDg7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjI1MDAwNjE5MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJhdmksIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSByZXZpZXcuIEnigJl2ZSBpbmNv cnBvcmF0ZWQgeW91ciBjb21tZW50cy4gU2VlIGlubG5lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5ydGctZGlyICZs dDtydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBSYXZpIFNpbmdoICZs dDtyYXZpcz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UaHVyc2RheSwgSnVseSAxOCwgMjAxOSBhdCAxMDo0NCBQTTxicj4NCjxiPlRvOiA8L2I+Um91 dGluZyBBRHMgJmx0O3J0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5S b3V0aW5nIERpcmVjdG9yYXRlICZsdDtydGctZGlyQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQt aWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtb3NwZi15YW5nQGll dGYub3JnJmd0OywgJnF1b3Q7bHNyQGlldGYub3JnJnF1b3Q7ICZsdDtsc3JAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQt aWV0Zi1vc3BmLXlhbmctMjMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiYjNDM7IGxzckBpZXRmLm9y Zzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PGI+RnJvbTo8L2I+IFJhdmkgU2luZ2ggPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBKdWx5IDE4LCAyMDE5IDc6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvdXRpbmcgQURzICZsdDty dGctYWRzQHRvb2xzLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gUm91dGluZyBEaXJlY3Rv cmF0ZSAmbHQ7cnRnLWRpckBpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYu b3JnOyBvc3BmQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJ0Z0RpciByZXZpZXc6IGRy YWZ0LWlldGYtb3NwZi15YW5nLTIzLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91 dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBk cmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3 LCBhbmQgc29tZXRpbWVzDQogb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUg cmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2Vl IOKAizxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lr aS9SdGdEaXIiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9S dGdEaXI8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHBy aW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBm dWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBM YXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZl IHRoZW0gdGhyb3VnaA0KIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPkRvY3VtZW50OiBkcmFmdC1pZXRmLW9zcGYteWFuZy0yMy50eHQ8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5S ZXZpZXdlcjogUmF2aSBTaW5naDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlJldmlldyBEYXRlOiA3LzE4LzIwMTk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JbnRl bmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlN1bW1hcnk6IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPlRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0 IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJpb3IgdG8gcHVibGljYXRpb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+VGhpcyBpcyBhIHZlcnkgY29tcHJlaGVuc2l2ZWx5IHdyaXR0ZW4g ZG9jdW1lbnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5Ib3dldmVyLCByZWFkaW5nIHRocm91Z2ggaXQgaXMgYSBiaXQgbGFi b3Jpb3VzIGR1ZSB0byB0aGUgcmVhbGx5IGxhcmdlICMgb2YgY29uZmlnIGFuZCBvcGVyYXRpb25h bCBpdGVtcyBkZXNjcmliZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+U28sIG15IHJldmlldyB3YXMgcHJpbWFyaWx5IGFpbWVk IGF0IHJlYWRhYmlsaXR5IHJhdGhlciB0aGFuIGNvcnJlY3RuZXNzIG9mIHRoZSBZQU5HIHN5bnRh eC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5TcGVjaWZpYyBjb21tZW50cy9xdWVyaWVzOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7dmVydGljYWwtYWxpZ246bWlk ZGxlIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2hhdCBpcyB0aGUgcmVhc29uaW5nIGZvciBz dGlja2luZyB0aGUgbXVsdGktdG9wb2xvZ3kgc3ViLWNvbnRhaW5lcihzKSBhdCB0aGUgc2FtZSBs ZXZlbHMgYXMgYXJlYSBpbnN0ZWFkIG9mIGF0IHRoZSBsZXZlbCBvZiBzdWItY29udGFpbmVycyB1 bmRlciBhcmVhKHMpPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246bWlkZGxlIj5PU1BGIE11 bHRpLVRvcG9sb2d5IGlzIG5vdCBhIHdpZGVseSBkZXBsb3llZCBmZWF0dXJlIGFuZCB0aGF0IGlz IHdoeSB3ZSBkaWQgaXQgd2l0aCBhdWdtZW50YXRpb25zLiBJ4oCZdmUgcmVtb3ZlZCB0aGUgYXJl YSBsaXN0IGZyb20gdGhlIGluc3RhbmNlIGxldmVsIGF1Z21lbnRhdGlvbiBhbmQgYWRkZWQgYSBz ZXBhcmF0ZSBhdWdtZW50YXRpb24gYXQgdGhlIGFyZWENCiBsZXZlbC4gVGhpcyBjaGFuZ2Ugd2ls bCBiZSBpbiB0aGUgLTI0IHZlcnNpb24uIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjMuMHB0O3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QZyAyMzogd2h5IGJvdGggKHByZWZpeCAmcXVvdDty dC10eXBlcyZxdW90OzspIGFuZCAocHJlZml4ICZxdW90O2lhbmEtcnQtdHlwZXMmcXVvdDs7KSA/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRp Y2FsLWFsaWduOm1pZGRsZSI+VGhleSBhcmUgdHdvIHNlcGFyYXRlIG1vZGVscyBpbiB0aGUgUkZD IDgyOTQuIFRoZSBsYXR0ZXIgbW9kdWxlIGlzIG1haW50YWluZWQgYnkgSUFOQS4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOm1pZGRs ZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NjMuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv Mjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QZyAyNS0y ODogJnF1b3Q7ZmVhdHVyZSB0d28tcGFydC1tZXRyaWMgeyZxdW90OyBhbmQgJnF1b3Q7ZmVhdHVy ZSBrZXktY2hhaW4geyZxdW90OyBtaWdodCBiZSByZWFkanVzdGVkIGluIG9yZGVyIG9mIGxpc3Rp bmcgdG8gbWFrZSBpdCB0aGUgc2FtZSBhcyB0aGF0IGluIHNlY3Rpb24gMi40IGZvciBhIGJpdCBv ZiBlbmhhbmNlZCByZWFkYWJpbGl0eS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246bWlkZGxlIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjptaWRkbGUi PkkgYWdyZWUuIEhvd2V2ZXIsIEnigJl2ZSByZW1vdmVkIHR3by1wYXJ0IG1ldHJpYyBhbmQgaXQg d2lsbCBiZSBpbiB0aGUgYXVnbWVudGF0aW9uIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246bWlk ZGxlIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dmVydGljYWwtYWxpZ246bWlkZGxlIj5BY2VlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dmVydGljYWwtYWxpZ246 bWlkZGxlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZHM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt2ZXJ0 aWNhbC1hbGlnbjptaWRkbGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmF2aTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_39C97F37E68C4D02AD06CE4854F79347ciscocom_--