From nobody Fri Sep 1 07:27:42 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344B213343C for ; Fri, 1 Sep 2017 07:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40CtBTr5OYxu for ; Fri, 1 Sep 2017 07:27:37 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0129.outbound.protection.outlook.com [104.47.0.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C8813321C for ; Fri, 1 Sep 2017 07:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AQTmJYRvHHw1AXKu2/LJ+hD9oQ6OjAE7Oowl/vojm6g=; b=DollZcRi7KqgPQC0xB9LKxpFtggksRHXJRAIy1aDVg55M4jWDdq7dkpN8/D9rKq698CjjHXM4HkmxfsP0/pAMDspuCycokE4kvnMa+YHVPp3HFzJHJ8wE2Gfq3ys6ntylrUPFiTDpvOVbbcEmwch06rk8Vk2BoXsEf0ki9B52us= Received: from DB3PR07MB0588.eurprd07.prod.outlook.com (10.160.46.139) by DB3PR07MB0537.eurprd07.prod.outlook.com (10.160.44.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Fri, 1 Sep 2017 14:27:33 +0000 Received: from DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::e1d8:4bc:f0e4:63fb]) by DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::e1d8:4bc:f0e4:63fb%15]) with mapi id 15.20.0013.014; Fri, 1 Sep 2017 14:27:32 +0000 From: "Belotti, Sergio (Nokia - IT/Vimercate)" To: Lou Berger , Xufeng Liu , "Igor Bryskin" , "vbeeram@juniper.net" , "tsaad@cisco.com" , "hshah@ciena.com" , OSCAR GONZALEZ DE DIOS , "Italo.Busi@huawei.com" , "carlo.perocchio@ericsson.com" , "Beller, Dieter (Nokia - DE/Stuttgart)" , TEAS WG Thread-Topic: Regarding IPR on draft-ietf-teas-yang-te-topo Thread-Index: AQHTHd5gOrO4lMD9O064a83/8XCpNqKgINXQ Date: Fri, 1 Sep 2017 14:27:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.212.9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0537; 6:Z7rPRdFeHqpqmVbteXoTfawU+zA/z5EZIF7c0LWwn3U4fAFyfLm6E3ge0lkgG9gicCldW520pG+ceBiaTcrwbJLSOB6b0P3WsKXvHWzHXOhGJp0AqKZFtbLV5nQ9qxnk0UY0Um9H+QQ3BLlYeEo0AStSFZ0hTpbkfe1DcN6fdybJbyNYRP2H3o4aElfyuX+Dc7Kv3rP8ScPBJ4KokDVhj/mFN9GNvL4b676+52HbJzlaNDHI4riu1+wPn9BZmAXwwHd9md3ap9oNvm/bjKWKkIsVMJCMuC7lyvfuy8gwtvcJBIWjJ9HluqBTa2j/N1mHw1j234dDMrwBbA52y5DrXQ==; 5:xqxC/l6bxB65jFetYN4PECuXYDuTQ31tiovd1J8xaCZ1pN6jM+gXUF6knNkbV3co5gamc39L48fFhQI6ViwcLGYfWyhT7JnFtD5RPpB0d78inFOHdLxJ10FHUIQpMsuP+VFC1I7tfr1yVnxR++2PDg==; 24:HnzcSsOS9m01EukvmQy34pmATj1RMOEdH3Mx0BS17PPO3W36rWQzy+0zzRxd6VAqxcEqX/JManitPxTSCNez1y7P78Gp4383ffIXxqlrMn8=; 7:gBrm+PYgkv8m7UozMxukxxhP3OcGr+rFtfJtDz1sEKgGRUEBmOIP63xSdB+0WyGA7owvO4dCQPbcZYJglZXtILGjzuSD8el7B74p4DJtnZWyAEniElm973unCJRdqPewAISGCa2hxmuVMyfwjcs65UUaNiNN4hwkEFaf5flF1I3svWpkPZi0mv5hkhVOn3BuorOGp+kXN+rZjEN3fYIfjQOBjWOhcD+5VibjmUDR/QE= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(199003)(189002)(377454003)(13464003)(6306002)(53546010)(99286003)(9686003)(8666007)(55016002)(5250100002)(3846002)(102836003)(14454004)(6116002)(53936002)(2900100001)(106356001)(230783001)(105586002)(2501003)(25786009)(97736004)(86362001)(68736007)(2201001)(478600001)(189998001)(966005)(66066001)(6246003)(229853002)(2950100002)(6506006)(6436002)(101416001)(33656002)(54356999)(1941001)(7416002)(2906002)(76176999)(50986999)(3280700002)(8936002)(305945005)(8676002)(81156014)(81166006)(7736002)(5660300001)(7696004)(3660700001)(74316002)(921003)(1121003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0537; H:DB3PR07MB0588.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: b1bb4690-1b1e-4dda-f896-08d4f1459509 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB3PR07MB0537; x-ms-traffictypediagnostic: DB3PR07MB0537: x-exchange-antispam-report-test: UriScan:(37575265505322)(40392960112811)(138986009662008)(82608151540597)(95692535739014)(21534305686606)(50582790962513); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR07MB0537; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR07MB0537; x-forefront-prvs: 0417A3FFD2 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2017 14:27:31.9859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0537 Archived-At: Subject: Re: [Teas] Regarding IPR on draft-ietf-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 14:27:40 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K DQpUaGFua3MNCnNlcmdpbw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBM b3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBGcmlkYXksIEF1Z3Vz dCAyNSwgMjAxNyAxMDoxMiBQTQ0KVG86IFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwuY29t PjsgSWdvciBCcnlza2luIDxpZ29yLmJyeXNraW5AaHVhd2VpLmNvbT47IHZiZWVyYW1AanVuaXBl ci5uZXQ7IHRzYWFkQGNpc2NvLmNvbTsgaHNoYWhAY2llbmEuY29tOyBPU0NBUiBHT05aQUxFWiBE RSBESU9TIDxvc2Nhci5nb256YWxlemRlZGlvc0B0ZWxlZm9uaWNhLmNvbT47IEl0YWxvLkJ1c2lA aHVhd2VpLmNvbTsgY2FybG8ucGVyb2NjaGlvQGVyaWNzc29uLmNvbTsgQmVsbGVyLCBEaWV0ZXIg KE5va2lhIC0gREUvU3R1dHRnYXJ0KSA8ZGlldGVyLmJlbGxlckBub2tpYS5jb20+OyBCZWxvdHRp LCBTZXJnaW8gKE5va2lhIC0gSVQvVmltZXJjYXRlKSA8c2VyZ2lvLmJlbG90dGlAbm9raWEuY29t PjsgVEVBUyBXRyA8dGVhc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJh ZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wbw0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0K DQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsDQoNCkFyZSB5b3Ug YXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnRzIGlkZW50aWZpZWQgYWJvdmU/ DQoNClBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBS IHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0Kb3INCiJZZXMsIEknbSBhd2FyZSBvZiBJUFIg dGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBk aXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzNjY5 LCA1Mzc4IGFuZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJZiB5ZXMgdG8gdGhlIGFib3Zl LCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0KIk5vLCB0aGUgSVBSIGhh cyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRl IGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5z d2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9j dW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNl IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRv ci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FH RSdTIFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVu ZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1 dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBS IHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJl IGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJl ZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lv biByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwg cGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFu ayB5b3UsDQpURUFTIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGlu IHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KDQoNCg== From nobody Fri Sep 1 14:08:45 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE77413450D for ; Fri, 1 Sep 2017 14:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 kGo73V1M1FbW for ; Fri, 1 Sep 2017 14:08:39 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 D8C4A1344D1 for ; Fri, 1 Sep 2017 14:08:39 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 831971E0668 for ; Fri, 1 Sep 2017 15:08:39 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 4M8c1w00Z2SSUrH01M8fMk; Fri, 01 Sep 2017 15:08:39 -0600 X-Authority-Analysis: v=2.2 cv=F98nTupN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=ri0MzPERGHgdVGHnxEEA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JXLztGdWYoVwCeQmiEEfODIuPH1bcbGjU/5QQOWwZ7o=; b=N9Ir1K8Vl95Bz4WxMr6L5irqf5 bv19d5RwHNCvxk8GffOj3LP6+C1K2STuPI0JUSlDvImtRp4Y2z4WBz8Jahhvi+wdrIzclDhHI97vX T94Qed/TqG8aLZVLT3WYA7xKg; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47504 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dntB6-0032q2-Dl; Fri, 01 Sep 2017 15:08:36 -0600 From: Lou Berger To: TEAS WG Cc: TEAS WG Chairs , draft-ietf-teas-yang-te-topo@ietf.org Message-ID: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Date: Fri, 1 Sep 2017 17:08:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dntB6-0032q2-Dl X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47504 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 21:08:44 -0000 All, This starts a *three* week working group last call on draft-ietf-teas-yang-te-topo-12. This last call is extended due to the size of the document and it being the first YANG model going to LC within the group The working group last call ends on September 22. Please send your comments to the TEAS mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs From nobody Mon Sep 4 00:43:18 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2D31252BA for ; Mon, 4 Sep 2017 00:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.636 X-Spam-Level: X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl8mTiM9KqhM for ; Mon, 4 Sep 2017 00:43:13 -0700 (PDT) Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7351B1200F3 for ; Mon, 4 Sep 2017 00:43:12 -0700 (PDT) Received: from WangajPC (unknown [219.142.69.77]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id EB3396612A2; Mon, 4 Sep 2017 15:43:09 +0800 (CST) From: "Aijun Wang" To: Cc: "'LuHuang'" , "'TEAS WG'" References: <005301d2f16a$c34d5be0$49e813a0$@bri@chinatelecom.cn> <000601d3011f$dd49c690$97dd53b0$@org.cn> In-Reply-To: <000601d3011f$dd49c690$97dd53b0$@org.cn> Date: Mon, 4 Sep 2017 15:43:08 +0800 Message-ID: <00d701d32551$74b08320$5e118960$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01D32594.82D3C320" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLxasJh2iVWKQJsQPmuFVBT/C1CnwPrgXrwCQ3MG1A= Content-Language: zh-cn X-HM-Spam-Status: e1kIGBQJHllBS1VLV1koWUFKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PSo6Sjo4HjorSyhWTEhIUTcq Dk4aFAFVSlVKTktPTkpLQkJLSE9NVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxMWVdZCAFZQUlIQkNMNwY+ X-HM-Tid: 0a5e4bd7d72c9373kuwseb3396612a2 Archived-At: Subject: [Teas] =?gb2312?b?tPC4tDogIENDRFIgc2NlbmFyaW9zLCBzaW11bGF0aW9u?= =?gb2312?b?IGFuZCBzdWdnZXN0aW9ucw==?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 07:43:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01D32594.82D3C320 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, Julien: =20 After the below explanation, do you still have some questions about the = CCDR direction within TEAS WG? As discussed previously in TEAS WG list, most of the TEASer agree PCEP = is the southbound protocol within SDN era. Here we just want to reuse this protocol to solve our TE requirements = for Native IP network, in the combination of centrally/distributed control manner that is different/simpler than current MPLS TE based solution. =20 Wish to hear your opinion/attitude on this topic again. Comments from other experts are also welcome. =20 =20 Best Regards. =20 Aijun Wang Network R&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, = China. =20 =B7=A2=BC=FE=C8=CB: Teas [mailto:teas-bounces@ietf.org] =B4=FA=B1=ED = Aijun Wang =B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA7=D4=C220=C8=D5 14:17 =CA=D5=BC=FE=C8=CB: julien.meuric@orange.com; michael.scharf@nokia.com; = db3546@att.com =B3=AD=CB=CD: 'LuHuang'; 'TEAS WG' =D6=F7=CC=E2: Re: [Teas] CCDR scenarios, simulation and suggestions =20 Hi, Julien, Michael and Deborah: =20 Thanks for your comments on Mr.Huang Lu=A1=AFs presentation(CCDR = Presentation Material = ) about the CCDR on Tuesday Morning=A1=AFs TEAS session. The presentation illustrates the traffic engineering scenarios that we encountered in our native IP network. Traditional solutions to these scenarios are to apply MPLS technologies within the whole network and using RSVP-TE or SR-TE to steer the = traffic. These technologies are valid but they either increase the network/device complexity or we must using the different solutions to cope with the intra-domain/inter-domain traffic engineering requirements. =20 Based on the above situation and the development of SDN concept/related technologies, we want to let the SDN controller do the most complex algorithm, let it instruct the devices for the optimal action, thus to alleviate the burden of the underlay network devices, reduce the = complexity of synchronous signaling between them. =20 The key idea of the draft PCE in Native IP network is to let the PCE/SDN controller instructs the devices on the optimal path via PCEP and keep = the default path calculated by the normal IGP/BGP protocol. We think such solution has more network controllability in global view and thus easy = to accomplish the complex TE requirements in one unified solution. =20 We are also eager to hear more opinions or suggestions on this topic to solve the problem that we encountered. =20 =20 Best Regards. =20 Aijun Wang Network R&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, = China. =20 =B7=A2=BC=FE=C8=CB: Teas [mailto:teas-bounces@ietf.org] =B4=FA=B1=ED = Aijun Wang =B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA6=D4=C230=C8=D5 14:33 =CA=D5=BC=FE=C8=CB: 'TEAS WG' =D6=F7=CC=E2: [Teas] CCDR scenarios, simulation and suggestions =20 Hi,All: =20 We have uploaded the draft about CCDR scenarios, simulation and = suggestions at https://tools.ietf.org/html/draft-wang-teas-ccdr-00.=20 Below is the brief introduction to it, wish to hear more valuable = comments on it. We will also prepare to introduce it at the coming IETF meeting = in Prague. =20 =20 Abstract =20 This document describes the scenarios, simulation and suggestions for the "Centrally Control Dynamic Routing (CCDR)" architecture, which integrates the merit of traditional distributed protocols (IGP/BGP), and the power of centrally control technologies (PCE/SDN) to provide one feasible traffic engineering solution in various complex scenarios for the service provider. =20 Traditional MPLS-TE solution is mainly used in static network planning scenario and is difficult to meet the QoS assurance requirements in real-time traffic network. With the emerge of SDN concept and related technologies, it is possible to simplify the complexity of distributed control protocol, utilize the global view of network condition, give more efficient solution for traffic engineering in various complex scenarios. =20 =20 Best Regards. =20 Aijun Wang Network R&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, = China. =20 ------=_NextPart_000_00D8_01D32594.82D3C320 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Julien:

 

After the = below explanation, do you still have some questions about the CCDR = direction within TEAS WG?

As = discussed previously in TEAS WG list,  most of the TEASer agree = PCEP is the southbound protocol within SDN era.

Here we = just want to reuse this protocol to solve our TE requirements for Native = IP network,  in the combination of centrally/distributed control = manner that is different/simpler than current MPLS TE based = solution.

 

Wish to = hear your opinion/attitude on this topic again.

Comments = from other experts are also welcome.

 

 

Best = Regards.

 

Aijun = Wang

Network R&D and Operation Support = Department

China Telecom Corporation Limited Beijing = Research Institute,Beijing, China.

 

=B7=A2=BC=FE=C8=CB: Teas = [mailto:teas-bounces@ietf.org] =B4=FA=B1=ED = Aijun = Wang
=B7=A2=CB=CD=CA=B1=BC= =E4: 2017=C4=EA7=D4=C220=C8=D5 14:17
=CA=D5=BC=FE=C8=CB: julien.meuric@orange.com; = michael.scharf@nokia.com; db3546@att.com
=B3=AD=CB=CD: 'LuHuang'; 'TEAS = WG'
=D6=F7=CC=E2: Re: [Teas] CCDR scenarios, simulation and = suggestions

 

Hi, Julien, Michael and = Deborah:

 

Thanks for = your comments on Mr.Huang Lu=A1=AFs presentation(CCDR Presentation Material) about the CCDR on Tuesday = Morning=A1=AFs TEAS session.

The = presentation illustrates the traffic engineering scenarios that we = encountered in our native IP network.

Traditional = solutions to these scenarios are to apply MPLS technologies within the = whole network and using RSVP-TE or SR-TE to steer the traffic. These = technologies are valid but they either increase the network/device = complexity or we must using the different solutions to cope with the = intra-domain/inter-domain traffic engineering = requirements.

 

Based on = the above situation and the development of SDN concept/related = technologies, we want to let the SDN controller do the most complex = algorithm, let it instruct the devices for the optimal action, thus to = alleviate the burden of the underlay network devices, reduce the = complexity of synchronous signaling between = them.

 

The key = idea of the draft PCE in = Native IP network is to let the PCE/SDN controller instructs the = devices on the optimal path via PCEP and keep the default path = calculated by the normal IGP/BGP protocol. We think such solution has = more network controllability in global view and thus easy to accomplish = the complex TE requirements in one unified = solution.

 

We are also = eager to hear more opinions or suggestions on this topic to solve the = problem that we encountered.

 

 

Best = Regards.

 

Aijun = Wang

Network R&D and Operation Support = Department

China Telecom Corporation Limited Beijing = Research Institute,Beijing, China.

 

=B7=A2=BC=FE=C8=CB: Teas [mailto:teas-bounces@ietf.org] = =B4=FA=B1=ED = Aijun = Wang
=B7=A2=CB=CD=CA=B1=BC= =E4: 2017=C4=EA6=D4=C230=C8=D5 14:33
=CA=D5=BC=FE=C8=CB: 'TEAS = WG'
=D6=F7=CC=E2: [Teas] CCDR scenarios, simulation and = suggestions

 

Hi,All:

&nbs= p;

We have = uploaded the draft about CCDR scenarios, simulation and suggestions at = https://tool= s.ietf.org/html/draft-wang-teas-ccdr-00.

Below is the brief = introduction to it, wish to hear more valuable comments on it. We will = also prepare to introduce it at the coming IETF meeting in = Prague.

&nbs= p;

&nbs= p;

Abstract<= o:p>

&nbs= p;

 &nb= sp; This document describes the scenarios, simulation and = suggestions

 &nb= sp; for the "Centrally Control Dynamic Routing (CCDR)" = architecture,

 &nb= sp; which integrates the merit of traditional distributed = protocols

 &nb= sp; (IGP/BGP), and the power of centrally control technologies = (PCE/SDN)

 &nb= sp; to provide one feasible traffic engineering solution in = various

 &nb= sp; complex scenarios for the service provider.

&nbs= p;

 &nb= sp; Traditional MPLS-TE solution is mainly used in static = network

 &nb= sp; planning scenario and is difficult to meet the QoS = assurance

 &nb= sp; requirements in real-time traffic network. With the emerge of = SDN

 &nb= sp; concept and related technologies, it is possible to simplify = the

 &nb= sp; complexity of distributed control protocol, utilize the global = view

 &nb= sp; of network condition, give more efficient solution for = traffic

 &nb= sp; engineering in various complex scenarios.

 

 

Best = Regards.

 

Aijun Wang

Network R&D and Operation Support = Department

China Telecom Corporation Limited Beijing Research = Institute,Beijing, China.

 

------=_NextPart_000_00D8_01D32594.82D3C320-- From nobody Mon Sep 4 02:47:42 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E6213248B; Mon, 4 Sep 2017 02:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 7g_pMCOTh7ob; Mon, 4 Sep 2017 02:47:33 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F41126B6E; Mon, 4 Sep 2017 02:47:32 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v849lSEi001546; Mon, 4 Sep 2017 10:47:28 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v849lRIb001523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Sep 2017 10:47:28 +0100 Reply-To: From: "Adrian Farrel" To: "'Elwyn Davies'" , Cc: , , References: <150394826804.19875.11489576374495678242@ietfa.amsl.com> In-Reply-To: <150394826804.19875.11489576374495678242@ietfa.amsl.com> Date: Mon, 4 Sep 2017 10:47:25 +0100 Message-ID: <04bc01d32562$d1429220$73c7b660$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGKGKKrdjo4X1idSejwpVo6v2ubj6M2k29g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23302.006 X-TM-AS-Result: No--13.393-10.0-31-10 X-imss-scan-details: No--13.393-10.0-31-10 X-TMASE-MatchedRID: HXSqh3WYKfunykMun0J1wru9iqQJLR0vt3aeg7g/usAiFs20Vxq/wm49 qzHIwIdXjZ0K7EGsP6YXEaT5uhkwzL7JS94zlW+lbMGKOuLn5FWzWETBQPV38lP0F8diMVluHLI ml6S5nfclpVclvjJJDDHcJ6BoI/5LC2s6EMq6ZtKdVNZaI2n6/zIaJpKzSfrsxSZxKZrfThPoYz vlUu2YlJ5PSOMffyxBslhzcjn859Q6dvNUujrkrxzwnpmtY/+rfS0Ip2eEHny+qryzYw2E8M894 3oc3p3sq7rFUcuGp/EgBwKKRHe+r9/bCv1rzS3NpMUEeBeh7W0RiTtSp1zpJmMjrIr8gQiiERmc 8MHbBtw= Archived-At: Subject: Re: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 09:47:34 -0000 Thanks Elwyn, Clarified in the next revision. Adrian > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Elwyn Davies > Sent: 28 August 2017 20:24 > To: gen-art@ietf.org > Cc: draft-ietf-teas-pce-central-control.all@ietf.org; ietf@ietf.org; teas@ietf.org > Subject: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 > > Reviewer: Elwyn Davies > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-teas-pce-central-control-04 > Reviewer: Elwyn Davies > Review Date: 2017-08-28 > IETF LC End Date: 2017-08-24 > IESG Telechat date: 2017-08-31 > > Summary: Thanks for addressing my Last Call comments on -03. The new version > is ready with one introduced nit. Also I am still of the abstract is somewhat > overlong. > > Nit: > s6, para 2: The SDN term 'northbound' has appeared in the new version. Needs > brief explanation. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Sep 4 02:47:51 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDFC13248B; Mon, 4 Sep 2017 02:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 k7Wu7OoDXmDo; Mon, 4 Sep 2017 02:47:33 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3EBB1321AA; Mon, 4 Sep 2017 02:47:32 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v849lUOT001565; Mon, 4 Sep 2017 10:47:30 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v849lRIc001523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Sep 2017 10:47:29 +0100 Reply-To: From: "Adrian Farrel" To: "'Spencer Dawkins'" , "'The IESG'" Cc: , , , References: <150387138757.9798.12253471138493060140.idtracker@ietfa.amsl.com> In-Reply-To: <150387138757.9798.12253471138493060140.idtracker@ietfa.amsl.com> Date: Mon, 4 Sep 2017 10:47:25 +0100 Message-ID: <04c001d32562$d1e0f500$75a2df00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHpFdamiiXQ6XGMqiH5kHhyjORmaG7ebhA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23302.006 X-TM-AS-Result: No--22.649-10.0-31-10 X-imss-scan-details: No--22.649-10.0-31-10 X-TMASE-MatchedRID: WMT2WRIkHPOnykMun0J1wl2036HHwFm/t3aeg7g/usBqm4kNeln1ttQ/ WYdCGipDCXNLggm34cw03aBufmdwQO6IS6037/ekatGCGdi/nWqoJD1SAoWC8XphbZRDpaPy7x9 p3gUCtaui94DSGm5AhPc8cCahCpb6sEBAuoaUqK/uykw7cfAoIOiZcG9oG7pOQQ1XgvCe7sGgBY 2eafmbnmIHUE1vaSjhHeaVRgmfeSnKJrNcYoG2R1Pjo7D4SFg4d0/IMHz0evn1dSXyfnzLWNO82 lWRIPgzqzK6gNmasNi66rswlFLG/tpUsVk2Y0Y06ivQ8oO6nULDHSNFHFxB87rfxlRjqBJ3HOWW /Rp/isrEwh+FBAsuQV4peeHUfywbQobCGYdVyAQER9Ta+6BEXROySJ0+MHXaHWNaMBkegSfjqdV KHSJibQhLlRep7kgxX7bicKxRIU352SN33UuAALHlqZYrZqdI+gtHj7OwNO0gIa2uM5uk8pRMZU CEHkRt Archived-At: Subject: Re: [Teas] Spencer Dawkins' Yes on draft-ietf-teas-pce-central-control-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 09:47:36 -0000 Thanks Spencer, [snip] > In > = https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-04#sectio= n-3.1.1, > the description is short, which could be fine, but meant I was = guessing at a > lot of high-level details that I could dig out of > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-21 for myself, = but it > might be helpful to include a couple of points, like whether the PCCs = in this > technology are (always?) LSRs participating in the IGP (OSPF or = IS-IS), and > whether the PCEs are (always?) either LSRs or servers also = participating in the > IGP, and whether the IGP is (always?) used to set up LSPs, for readers = who have > a (G)MPLS or MPLS-TE network now, to figure out how it maps at a high = level to > what they already have. I=E2=80=99m guessing from > = https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-21#section-5.5, = but I=E2=80=99m > guessing. I have added... In this mode of operation, the PCE may construct its TED in a = number of ways as=20 described in including (but not = limited to) participating in the IGP or receiving information from a network element = via BGP-LS=20 . > I=E2=80=99m not quite sure what to do with this part of the security = considerations: >=20 > In > short, while the interactions with a PCE-based controller are not > substantially different to those in any other SDN architecture, the > security implications of SDN have not been fully discussed or > described. Therefore, protocol and applicability work around > solutions for this architecture must take proper account of these > concerns. >=20 > It is expected that each new document that is produced for a = specific > use case will also include considerations of the security impacts = of > the use of a PCE-based central controller on the network type and > services being managed. >=20 > If I=E2=80=99m reading this literally, it=E2=80=99s saying that we = haven=E2=80=99t finished discussing > SDN security considerations in general yet, so each new document will = consider > the security impact of a PCE-based central controller on the network = type and > services being managed as an SDN. Is that what was meant? Yes. You read it right. A subtext might be "Don't try to lean on any pre-existing SDN work to = pass the buck on PCE-CC security, because you'll probably fall on your = face." > If I=E2=80=99m reading the manageability considerations section = correctly, perhaps it=E2=80=99s > worth pointing out what the extension story is for the IGPs that will = be used > in some of the technologies discussed earlier in the document, if = that=E2=80=99s part > of this work as well. Yes. Added a sentence to the second paragraph of this section... This may require protocol extensions for the mechanisms listed in this paragraph. Cheers, Adrian From nobody Mon Sep 4 03:18:03 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5A13292E; Mon, 4 Sep 2017 03:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 FkfnvL3z41Xs; Mon, 4 Sep 2017 03:17:55 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB6D1321AA; Mon, 4 Sep 2017 03:17:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v84AHpvm027995; Mon, 4 Sep 2017 11:17:51 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v84AHnXd027985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Sep 2017 11:17:50 +0100 Reply-To: From: "Adrian Farrel" To: "'Ben Campbell'" , "'The IESG'" Cc: , , , References: <150404669791.21588.5843127228175404279.idtracker@ietfa.amsl.com> In-Reply-To: <150404669791.21588.5843127228175404279.idtracker@ietfa.amsl.com> Date: Mon, 4 Sep 2017 11:17:48 +0100 Message-ID: <04ca01d32567$0f6039a0$2e20ace0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIKhpAAAFlTBm1q3r+kJN047KqQ8qI1uCDA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23302.006 X-TM-AS-Result: No--5.961-10.0-31-10 X-imss-scan-details: No--5.961-10.0-31-10 X-TMASE-MatchedRID: y/2oPz6gbvinykMun0J1wvHkpkyUphL9kT7cMJfe6JsoDMZ3xV44iPJs l+USu3BFEsWNhhhdSk1nhucj2oZw/Jx6Ilif8OzGoaP4nSNLOYtUENBIMyKD0bP7qOmy9QBUpph PLgF5DsHcZeCl31+T75Liv6y4vDKVvH9OmaDmUGOJX8rOXYTNKkyjgwn9Mo4vm0gr7bSBDjb+56 dY8RnEnMtP9TaUF0ARyadg+GrpqOyept7UgSEy40hEDfw/93BukteEeVai7TcUnhXZChKvF3iki 0zUgl6qjkX50XjczKxVmSwJdnYLlRHWya/4KnLengIgpj8eDcC063Wh9WVqghziNLWewPgd+gtH j7OwNO2I9t8DSRevIUC/Bzoms68U8isL83ihqJyMyApPmvjFoT5qfcu3KGqnVlxr1FJij9s= Archived-At: Subject: Re: [Teas] Ben Campbell's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 10:17:56 -0000 Thanks Ben, > - The abstract is unusually long, and seems more like an introduction. The > second to last paragraph could almost stand by itself as a useful abstract. Yeah. I've been practicing writing short stories [1],[2]. We seem to be a few lines over the RFC Editor's guidelines so I have trimmed a little for the next rev. > - The terms "southbound" and "northbound" could use definition. (I find these > terms cause lots of confusion, since not everyone draws the diagrams with the > same idea of what goes on top or bottom.) Yes. Elwyn commented about this in his GenArt review. We now have... southbound control protocol (i.e., a control protocol for communicating from the central controller to network elements) ...and... northbound export of YANG-encoded data [I-D.ietf-teas-yang-te-topo] from the network elements to the controller) ...to give an anchor to the meaning. > - 2.1.1: It's probably too late at this point to change it, but I find the use > of "domains" unfortunate. That may be one of the most overloaded terms in the > IETF lexicon, if not in that of the networking crowd at large. Since you > describe them as "partitions", I think "partitions" would have been better. Oh, yes, maybe 10 or 12 years too late for PCE :-) RFC4655 has... A domain is any collection of network elements within a common sphere of address management or path computation responsibility. Examples of domains include IGP areas, Autonomous Systems (ASes), and multiple ASes within a Service Provider network. Domains of path computation responsibility may also exist as sub-domains of areas or ASes. ...and all PCE work since then has leveraged that definition. Actually, you also see that meaning being adopted across TEAS, MPLS, and CCAMP. But I have added a citation at the point where "domain" is introduced. > - 2.1.2, 2nd to last paragraph: "This is nominally a simple task if > there are just two controllers, but can actually be quite complex if > state changes in the network are not to be lost." > > That sentence seems self-contradictory. I don't think it's simple, nominally or > otherwise. I couldn't agree with you more that this is not simple. However, "nominally" it is simple to say "Let's just have the controllers synchronise state by sending updates to each other." This would be funny if it wasn't for the fact that managers (pointy-haired or otherwise) keep saying it! I have seen plenty of projects (including router hardware designs) crash and burn by assuming this simplicity. Thanks, Adrian [1] https://www.amazon.com/Tales-Wood-Adrian-Farrel/dp/1786100924 [2] https://www.amazon.com/More-Tales-Wood-Adrian-Farrel/dp/1786972565 From nobody Mon Sep 4 03:28:33 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A710E126DD9; Mon, 4 Sep 2017 03:28:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150452090663.456.1133414104669557593@ietfa.amsl.com> Date: Mon, 04 Sep 2017 03:28:26 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-pce-central-control-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 10:28:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : An Architecture for Use of PCE and PCEP in a Network with Central Control Authors : Adrian Farrel Quintin Zhao Robin Li Chao Zhou Filename : draft-ietf-teas-pce-central-control-05.txt Pages : 25 Date : 2017-09-04 Abstract: The Path Computation Element (PCE) is a core component of Software Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs) supplying them to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a broader applicability than signaled MPLS traffic engineered networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, service function chaining, and most forms of routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-05 https://datatracker.ietf.org/doc/html/draft-ietf-teas-pce-central-control-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-pce-central-control-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 4 07:10:05 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D270A132A8F; Mon, 4 Sep 2017 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 UW0RmXng7v2Y; Mon, 4 Sep 2017 07:09:48 -0700 (PDT) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) (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 CF025132A8E; Mon, 4 Sep 2017 07:09:47 -0700 (PDT) Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[192.168.0.134]) by b-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1dorhU-0002RF-SG; Mon, 04 Sep 2017 14:46:04 +0100 Date: Mon, 04 Sep 2017 14:45:53 +0100 Message-ID: Importance: normal From: Elwyn Davies To: adrian@olddog.co.uk, gen-art@ietf.org Cc: draft-ietf-teas-pce-central-control.all@ietf.org, ietf@ietf.org, teas@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_920406988092210" Archived-At: Subject: Re: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:09:51 -0000 ----_com.samsung.android.email_920406988092210 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CkhpLCBBZHJpYW4uClR3byBwb2ludHM6LSBJIGRvbid0IHNlZSBhbiBleHBsYW5hdGlvbiBvZiBu b3J0aGJvdW5kIGluIC0wNS4tIEluIHRoZSBuZXcgdGV4dCBhdCB0aGUgZW5kIG9mIHMyLjEuMiBz L3dob2xlIHRoZSBjb250cm9sbGVycy93aGlsZSB0aGUgY29udHJvbGxlcnMvCk90aGVyd2lzZSwg dGhlIGV4dHJhIHRleHQgYW5kIGNoYW5nZXMgbG9vayBoZWxwZnVsLgpCZXN0IHdzaGVzLEVsd3lu CgpTZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0t LS0tLS1Gcm9tOiBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiBEYXRlOiAwNC8w OS8yMDE3ICAxMDo0NyAgKEdNVCswMDowMCkgVG86ICdFbHd5biBEYXZpZXMnIDxlbHd5bmRAZGlh bC5waXBleC5jb20+LCBnZW4tYXJ0QGlldGYub3JnIENjOiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNl bnRyYWwtY29udHJvbC5hbGxAaWV0Zi5vcmcsIGlldGZAaWV0Zi5vcmcsIHRlYXNAaWV0Zi5vcmcg U3ViamVjdDogUkU6IFtUZWFzXSBHZW5hcnQgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWlldGYt dGVhcy1wY2UtY2VudHJhbC1jb250cm9sLTA0IApUaGFua3MgRWx3eW4sCgpDbGFyaWZpZWQgaW4g dGhlIG5leHQgcmV2aXNpb24uCgpBZHJpYW4KCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0K PiBGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RWx3eW4gRGF2aWVzCj4gU2VudDogMjggQXVndXN0IDIwMTcgMjA6MjQKPiBUbzogZ2VuLWFydEBp ZXRmLm9yZwo+IENjOiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC5hbGxAaWV0 Zi5vcmc7IGlldGZAaWV0Zi5vcmc7CnRlYXNAaWV0Zi5vcmcKPiBTdWJqZWN0OiBbVGVhc10gR2Vu YXJ0IHRlbGVjaGF0IHJldmlldyBvZgpkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJv bC0wNAo+IAo+IFJldmlld2VyOiBFbHd5biBEYXZpZXMKPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3 aXRoIE5pdHMKPiAKPiBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlz IGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhCj4gUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3Mg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZAo+IGJ5IHRoZSBJRVNHIGZvciB0aGUg SUVURiBDaGFpci4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIKPiBkb2N1bWVu dCBzaGVwaGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFm dC4KPiAKPiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0Cj4gCj4g PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcT4uCj4gCj4gRG9j dW1lbnQ6IGRyYWZ0LWlldGYtdGVhcy1wY2UtY2VudHJhbC1jb250cm9sLTA0Cj4gUmV2aWV3ZXI6 IEVsd3luIERhdmllcwo+IFJldmlldyBEYXRlOiAyMDE3LTA4LTI4Cj4gSUVURiBMQyBFbmQgRGF0 ZTogMjAxNy0wOC0yNAo+IElFU0cgVGVsZWNoYXQgZGF0ZTogMjAxNy0wOC0zMQo+IAo+IFN1bW1h cnk6IFRoYW5rcyBmb3IgYWRkcmVzc2luZyBteSBMYXN0IENhbGwgY29tbWVudHMgb24gLTAzLsKg IFRoZSBuZXcgdmVyc2lvbgo+IGlzIHJlYWR5IHdpdGggb25lIGludHJvZHVjZWQgbml0LsKgIEFs c28gSSBhbSBzdGlsbCBvZiB0aGUgYWJzdHJhY3QgaXMgc29tZXdoYXQKPiBvdmVybG9uZy4KPiAK PiBOaXQ6Cj4gczYsIHBhcmEgMjogVGhlIFNETiB0ZXJtICdub3J0aGJvdW5kJyBoYXMgYXBwZWFy ZWQgaW4gdGhlIG5ldyB2ZXJzaW9uLiBOZWVkcwo+IGJyaWVmIGV4cGxhbmF0aW9uLgo+IAo+IE1h am9yIGlzc3VlczoKPiAKPiBNaW5vciBpc3N1ZXM6Cj4gCj4gTml0cy9lZGl0b3JpYWwgY29tbWVu dHM6Cj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPiBUZWFzIG1haWxpbmcgbGlzdAo+IFRlYXNAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMKCg== ----_com.samsung.android.email_920406988092210 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pjxicj48L2Rpdj48ZGl2Pkhp LCBBZHJpYW4uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ud28gcG9pbnRzOjwvZGl2PjxkaXY+ LSBJIGRvbid0IHNlZSBhbiBleHBsYW5hdGlvbiBvZiBub3J0aGJvdW5kIGluIC0wNS48L2Rpdj48 ZGl2Pi0gSW4gdGhlIG5ldyB0ZXh0IGF0IHRoZSBlbmQgb2YgczIuMS4yIHMvd2hvbGUgdGhlIGNv bnRyb2xsZXJzL3doaWxlIHRoZSBjb250cm9sbGVycy88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pk90aGVyd2lzZSwgdGhlIGV4dHJhIHRleHQgYW5kIGNoYW5nZXMgbG9vayBoZWxwZnVsLjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+QmVzdCB3c2hlcyw8L2Rpdj48ZGl2PkVsd3luPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48 ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciIGRpcj0iYXV0byI+U2VudCBm cm9tIFNhbXN1bmcgdGFibGV0LjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxk aXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogQWRy aWFuIEZhcnJlbCAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDsgPC9kaXY+PGRpdj5EYXRlOiAw NC8wOS8yMDE3ICAxMDo0NyAgKEdNVCswMDowMCkgPC9kaXY+PGRpdj5UbzogJ0Vsd3luIERhdmll cycgJmx0O2Vsd3luZEBkaWFsLnBpcGV4LmNvbSZndDssIGdlbi1hcnRAaWV0Zi5vcmcgPC9kaXY+ PGRpdj5DYzogZHJhZnQtaWV0Zi10ZWFzLXBjZS1jZW50cmFsLWNvbnRyb2wuYWxsQGlldGYub3Jn LCBpZXRmQGlldGYub3JnLCB0ZWFzQGlldGYub3JnIDwvZGl2PjxkaXY+U3ViamVjdDogUkU6IFtU ZWFzXSBHZW5hcnQgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdGVhcy1wY2UtY2VudHJh bC1jb250cm9sLTA0IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PlRoYW5rcyBFbHd5biw8YnI+ PGJyPkNsYXJpZmllZCBpbiB0aGUgbmV4dCByZXZpc2lvbi48YnI+PGJyPkFkcmlhbjxicj48YnI+ Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IFRlYXMgW21haWx0 bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFbHd5biBEYXZpZXM8YnI+Jmd0 OyBTZW50OiAyOCBBdWd1c3QgMjAxNyAyMDoyNDxicj4mZ3Q7IFRvOiBnZW4tYXJ0QGlldGYub3Jn PGJyPiZndDsgQ2M6IGRyYWZ0LWlldGYtdGVhcy1wY2UtY2VudHJhbC1jb250cm9sLmFsbEBpZXRm Lm9yZzsgaWV0ZkBpZXRmLm9yZzs8YnI+dGVhc0BpZXRmLm9yZzxicj4mZ3Q7IFN1YmplY3Q6IFtU ZWFzXSBHZW5hcnQgdGVsZWNoYXQgcmV2aWV3IG9mPGJyPmRyYWZ0LWlldGYtdGVhcy1wY2UtY2Vu dHJhbC1jb250cm9sLTA0PGJyPiZndDsgPGJyPiZndDsgUmV2aWV3ZXI6IEVsd3luIERhdmllczxi cj4mZ3Q7IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggTml0czxicj4mZ3Q7IDxicj4mZ3Q7IEkg YW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5l cmFsIEFyZWE8YnI+Jmd0OyBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkPGJyPiZndDsgYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRG IENoYWlyLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91cjxicj4mZ3Q7IGRvY3Vt ZW50IHNoZXBoZXJkIG9yIEFEIGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRy YWZ0Ljxicj4mZ3Q7IDxicj4mZ3Q7IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRo ZSBGQVEgYXQ8YnI+Jmd0OyA8YnI+Jmd0OyAmbHQ7aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv Z2VuL3dpa2kvR2VuQXJ0ZmFxJmd0Oy48YnI+Jmd0OyA8YnI+Jmd0OyBEb2N1bWVudDogZHJhZnQt aWV0Zi10ZWFzLXBjZS1jZW50cmFsLWNvbnRyb2wtMDQ8YnI+Jmd0OyBSZXZpZXdlcjogRWx3eW4g RGF2aWVzPGJyPiZndDsgUmV2aWV3IERhdGU6IDIwMTctMDgtMjg8YnI+Jmd0OyBJRVRGIExDIEVu ZCBEYXRlOiAyMDE3LTA4LTI0PGJyPiZndDsgSUVTRyBUZWxlY2hhdCBkYXRlOiAyMDE3LTA4LTMx PGJyPiZndDsgPGJyPiZndDsgU3VtbWFyeTogVGhhbmtzIGZvciBhZGRyZXNzaW5nIG15IExhc3Qg Q2FsbCBjb21tZW50cyBvbiAtMDMuJm5ic3A7IFRoZSBuZXcgdmVyc2lvbjxicj4mZ3Q7IGlzIHJl YWR5IHdpdGggb25lIGludHJvZHVjZWQgbml0LiZuYnNwOyBBbHNvIEkgYW0gc3RpbGwgb2YgdGhl IGFic3RyYWN0IGlzIHNvbWV3aGF0PGJyPiZndDsgb3ZlcmxvbmcuPGJyPiZndDsgPGJyPiZndDsg Tml0Ojxicj4mZ3Q7IHM2LCBwYXJhIDI6IFRoZSBTRE4gdGVybSAnbm9ydGhib3VuZCcgaGFzIGFw cGVhcmVkIGluIHRoZSBuZXcgdmVyc2lvbi4gTmVlZHM8YnI+Jmd0OyBicmllZiBleHBsYW5hdGlv bi48YnI+Jmd0OyA8YnI+Jmd0OyBNYWpvciBpc3N1ZXM6PGJyPiZndDsgPGJyPiZndDsgTWlub3Ig aXNzdWVzOjxicj4mZ3Q7IDxicj4mZ3Q7IE5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOjxicj4mZ3Q7 IDxicj4mZ3Q7IDxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPiZndDsgVGVhcyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBUZWFzQGlldGYub3Jn PGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzPGJyPjxi cj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_920406988092210-- From nobody Mon Sep 4 07:43:06 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17621321A6; Mon, 4 Sep 2017 07:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UszoKYnotpfJ; Mon, 4 Sep 2017 07:42:56 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B518E1321A1; Mon, 4 Sep 2017 07:42:56 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id w204so2837955ywg.3; Mon, 04 Sep 2017 07:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7pNCCkdgCHe0jcxERZP2cPA2TJFc78Qtx0hlnLAM/Ks=; b=fuNpDclmB1fUjrH1YXu+tiONeWQZMHjFsFX3YUI9qhG69MeQ5sSmLejrfVr83T9YJO WP/Fqxy+OXRDWIVu3ttiPDwZlXf1nc/fxuXScn9RDQlZbClg4doz2vmGFpDMmYeLNHJw A8fWzBpFyot1Sv3HrOZNbKYuVP8JsCA4ahyls4dXoMFKnRDgPPIfOaPSxbJgrvUyZfX+ ANxzSMSjPekCBELQl9oglS3Rvcel5rDaspoxJ3cea2hvCtjRwf+yy2Z6FI8+DPq/QM8s qcoL81nE5/IQAViASUikDmljkClce7RBIRXIFeqWApp04DHr9/oQsW2EYgPfFrvDK59a FJBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7pNCCkdgCHe0jcxERZP2cPA2TJFc78Qtx0hlnLAM/Ks=; b=kOrmQfgiwEz8Rw+lPvRWUFBfrKUNWFnbxndpOdCRmH+AuAOx/+rvZz2+zyqPq+vzI4 MrXWGg5lMLfEKSF+TxpcbisaooucqOuL6TGtmD8LZuRCdmHWpL17Rxj8qqNDr/+Pk1J4 uw2sUKhw0RuP9EYlN6k6vpFOrwpVrGy829ShYG/FKXlsXgGJa9Hyhid1BqGldGn/UoPS LSYjyHIuzzqxxNp3U00TYZuYeV2MqOwyIojRyeDrwIYRTsz2uK2O6TVgGFIGcnJM+POk iabTAl+jZOShiiK00uxwyMHEl7Z2l2EjNdk06LU5c0yWxz6rV3bNbZNHdFsGHRxyxL8j zSQQ== X-Gm-Message-State: AHPjjUhDUNdx/vsZ1GTlf/vUlgsc+x5VgwLWrOF8p3gAPQhIXoTAniL6 cd31gF1Akhc9jy7gsaNLUDNpSEgpQQ== X-Google-Smtp-Source: ADKCNb6UsR6FZ4NEGinPmLwMyoNdIqmtUj0lhl4T2H8GZuuG8ECmICZzZm+w0++yn/trJxoBNK5fR/Z2cwuKhJ0UUYY= X-Received: by 10.37.44.69 with SMTP id s66mr694173ybs.75.1504536175689; Mon, 04 Sep 2017 07:42:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Mon, 4 Sep 2017 07:42:55 -0700 (PDT) In-Reply-To: <04c001d32562$d1e0f500$75a2df00$@olddog.co.uk> References: <150387138757.9798.12253471138493060140.idtracker@ietfa.amsl.com> <04c001d32562$d1e0f500$75a2df00$@olddog.co.uk> From: Spencer Dawkins at IETF Date: Mon, 4 Sep 2017 09:42:55 -0500 Message-ID: To: "adrian@olddog.co.uk" Cc: The IESG , draft-ietf-teas-pce-central-control@ietf.org, teas-chairs@ietf.org, "TEAS WG (teas@ietf.org)" , vbeeram@juniper.net Content-Type: multipart/alternative; boundary="001a114321084dc65905585e20db" Archived-At: Subject: Re: [Teas] Spencer Dawkins' Yes on draft-ietf-teas-pce-central-control-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:43:00 -0000 --001a114321084dc65905585e20db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Adrian, On Mon, Sep 4, 2017 at 4:47 AM, Adrian Farrel wrote: > Thanks Spencer, > > [snip] > > > In > > https://tools.ietf.org/html/draft-ietf-teas-pce-central- > control-04#section-3.1.1, > > the description is short, which could be fine, but meant I was guessing > at a > > lot of high-level details that I could dig out of > > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-21 for myself, > but it > > might be helpful to include a couple of points, like whether the PCCs i= n > this > > technology are (always?) LSRs participating in the IGP (OSPF or IS-IS), > and > > whether the PCEs are (always?) either LSRs or servers also participatin= g > in the > > IGP, and whether the IGP is (always?) used to set up LSPs, for readers > who have > > a (G)MPLS or MPLS-TE network now, to figure out how it maps at a high > level to > > what they already have. I=E2=80=99m guessing from > > https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-21#section-5.5, > but I=E2=80=99m > > guessing. > > I have added... > In this mode of operation, the PCE may construct its TED in a > number of ways as > described in including (but not > limited to) participating > in the IGP or receiving information from a network element via > BGP-LS > . > I wouldn't mind more explanation, but this already helps a lot - enough that I understand the text now. > > I=E2=80=99m not quite sure what to do with this part of the security > considerations: > > > > In > > short, while the interactions with a PCE-based controller are not > > substantially different to those in any other SDN architecture, the > > security implications of SDN have not been fully discussed or > > described. Therefore, protocol and applicability work around > > solutions for this architecture must take proper account of these > > concerns. > > > > It is expected that each new document that is produced for a specifi= c > > use case will also include considerations of the security impacts of > > the use of a PCE-based central controller on the network type and > > services being managed. > > > > If I=E2=80=99m reading this literally, it=E2=80=99s saying that we have= n=E2=80=99t finished > discussing > > SDN security considerations in general yet, so each new document will > consider > > the security impact of a PCE-based central controller on the network > type and > > services being managed as an SDN. Is that what was meant? > > Yes. You read it right. > A subtext might be "Don't try to lean on any pre-existing SDN work to pas= s > the buck on PCE-CC security, because you'll probably fall on your face." > Thanks for confirming my worst suspicions. :-) And the subtext for that might be "Spencer hopes someone looks at this exchange and says, you know, we really SHOULD be thinking about SDN security in the general case, what would it take to make that happen?", but that''s not your problem any longer :D > > If I=E2=80=99m reading the manageability considerations section correct= ly, > perhaps it=E2=80=99s > > worth pointing out what the extension story is for the IGPs that will b= e > used > > in some of the technologies discussed earlier in the document, if that= =E2=80=99s > part > > of this work as well. > > Yes. > Added a sentence to the second paragraph of this section... > This may require > protocol extensions for the mechanisms listed in this paragraph. > Perfect. And thanks for all of the above ... Spencer > > Cheers, > Adrian > > --001a114321084dc65905585e20db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Adrian,

On Mon, Sep 4, 2017 at 4:47 AM, Adrian Farrel = <adrian@olddog.= co.uk> wrote:
Thanks Spence= r,

[snip]

> In
> https://tools.i= etf.org/html/draft-ietf-teas-pce-central-control-04#section-3.1.1= ,
> the description is short, which could be fine, but meant I was guessin= g at a
> lot of high-level details that I could dig out of
> https://tools.ietf.org/html/draf= t-ietf-pce-stateful-pce-21 for myself, but it
> might be helpful to include a couple of points, like whether the PCCs = in this
> technology are (always?) LSRs participating in the IGP (OSPF or IS-IS)= , and
> whether the PCEs are (always?) either LSRs or servers also participati= ng in the
> IGP, and whether the IGP is (always?) used to set up LSPs, for readers= who have
> a (G)MPLS or MPLS-TE network now, to figure out how it maps at a high = level to
> what they already have. I=E2=80=99m guessing from
> https://tools.ietf.org/ht= ml/draft-ietf-pce-stateful-pce-21#section-5.5, but I=E2=80=99= m
> guessing.

I have added...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>In this mode of operation, the PCE may= construct its TED in a number of ways as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0described in <xref target=3D&qu= ot;RFC4655"/> including (but not limited to) participating
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the IGP or receiving informatio= n from a network element via BGP-LS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<xref target=3D"RFC7752&qu= ot; />.</t>

I wouldn't min= d more explanation, but this already helps a lot - enough that I understand= the text now.
=C2=A0
> I=E2=80=99m not quite sure what to do with this part of the = security considerations:
>
>=C2=A0 =C2=A0 In
>=C2=A0 =C2=A0 short, while the interactions with a PCE-based controller= are not
>=C2=A0 =C2=A0 substantially different to those in any other SDN archite= cture, the
>=C2=A0 =C2=A0 security implications of SDN have not been fully discusse= d or
>=C2=A0 =C2=A0 described.=C2=A0 Therefore, protocol and applicability wo= rk around
>=C2=A0 =C2=A0 solutions for this architecture must take proper account = of these
>=C2=A0 =C2=A0 concerns.
>
>=C2=A0 =C2=A0 It is expected that each new document that is produced fo= r a specific
>=C2=A0 =C2=A0 use case will also include considerations of the security= impacts of
>=C2=A0 =C2=A0 the use of a PCE-based central controller on the network = type and
>=C2=A0 =C2=A0 services being managed.
>
> If I=E2=80=99m reading this literally, it=E2=80=99s saying that we hav= en=E2=80=99t finished discussing
> SDN security considerations in general yet, so each new document will = consider
> the security impact of a PCE-based central controller on the network t= ype and
> services being managed as an SDN. Is that what was meant?

Yes. You read it right.
A subtext might be "Don't try to lean on any pre-existing SDN work= to pass the buck on PCE-CC security, because you'll probably fall on y= our face."

Thanks for confirming m= y worst suspicions. :-)

And the subtext for that m= ight be "Spencer hopes someone looks at this exchange and says, you kn= ow, we really SHOULD be thinking about SDN security in the general case, wh= at would it take to make that happen?", but that''s not your p= roblem any longer :D
=C2=A0
<= span class=3D"">> If I=E2=80=99m reading the manageability consideration= s section correctly, perhaps it=E2=80=99s
> worth pointing out what the extension story is for the IGPs that will = be used
> in some of the technologies discussed earlier in the document, if that= =E2=80=99s part
> of this work as well.

Yes.
Added a sentence to the second paragraph of this section...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This may require
=C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol extensions for the mechanisms listed i= n this paragraph.

Perfect. And thanks f= or all of the above ...

Spencer
=C2=A0

Cheers,
Adrian


--001a114321084dc65905585e20db-- From nobody Mon Sep 4 09:59:29 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B765126C19; Mon, 4 Sep 2017 09:59:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 mx0RBdqL7h_x; Mon, 4 Sep 2017 09:59:16 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7DFE132CE8; Mon, 4 Sep 2017 09:59:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v84Gx3V0006330; Mon, 4 Sep 2017 17:59:03 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v84Gx1ph006283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Sep 2017 17:59:02 +0100 Reply-To: From: "Adrian Farrel" To: "'Elwyn Davies'" , Cc: , , References: In-Reply-To: Date: Mon, 4 Sep 2017 17:59:00 +0100 Message-ID: <055001d3259f$1b86e750$5294b5f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0551_01D325A7.7D500A40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFPQJ9uAfmyPpSzi7H2PguHhxmKOqOsuiuQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23304.001 X-TM-AS-Result: No--39.197-10.0-31-10 X-imss-scan-details: No--39.197-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtHtvMVN/9JMyhIMDPFEv6UxaL9g24i1ttV4sKInj/osm7+F 5bh4N9c/nwDcrOcCISvBudlKdl9AGu5BG6Mr3NWaknV2Dc7+QbHnFDhXm/j3I87QgtSUcDEy1WJ BvqhSgSkENLaL1ZQGAiFyczyoJ0RqiXDwRBge15rM1jffIgQXhso7mIWzSjiM6yKEyHG4lURMeA WHgRfLNB1uclAMPpFHa/qlTDFTzyPMM0KP1pISrWjZ8q/Oc1nAVQHOr6CvF1YM74Nf6tTB9i7sr eQJNnc7gMcbIURayq2sKEpNuJAwUPDZOKmFLlvIdFmXOeGyE+9imi8LvNfmr4aKwv8Fn/097hK9 01+mC+ARW3Fo+hK3sJbNfgtQUD+kR1vveBQPCRfBtFDYGmaWKrRfRjDbtW6i5DjmdW0+qbGuwVT xTDkELrK2YHb/kidP/PEgL0tqyq50bnu2kHqixLMsPmSZxbpkE7JInT4wddoTjfkO3pb+WD0msI gSyun3H/Z71HJDNaFacyhB9L1ar9+PZq+Z+KYzkdcpJKX5Jwr8BlbXy+O/WnKuL8SC59l3YCowK SvpI+95QzetarMsxEgF6uuiHQ769Z8q6rO+Ih6Ycl4BgqVyk3cF/0kiqyh4DxjBugJBzzwITux6 kRboK/Nt5XZU3wuLk1zNU0ainQZP5mzaUz6wQBD3+0w1DhqK3kR1SkDo278ML9Wb3Qh/ha0QmL2 wrxWPWU8XtC6NtyQqhZrv4f7cO34FjWYN+jMve5NWR5iixe05LRtPnepd1cO/l0Ny5PZ5mg+Op3 qhhyTwpvAauYPakRQAXi4Ga9GRHxPMjOKY7A+DGx/OQ1GV8mgVPcrOkeoTLL+82TohWm+nmxwsc wVeEzsAVzN+Ov/s51hhkcWdulLbz1hTXw72C1/6pS7IuoTZZVZHHJqxW835MQR4E76/Ig== Archived-At: Subject: Re: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 16:59:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0551_01D325A7.7D500A40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Elwyn, =20 -04 has Some of this will be the TED as is normal for a PCE and can be collected using the mechanisms already in place (such as listening to the IGPs, using BGP-LS [RFC7752], or northbound export of YANG- encoded data [I-D.ietf-teas-yang-te-topo]). -05 has Some of this will be the TED as is normal for a PCE and can be collected using the mechanisms already in place (such as listening to the IGPs, using BGP-LS [RFC7752], or northbound export of YANG- encoded data [I-D.ietf-teas-yang-te-topo] from the network elements to the controller). =20 I think that probably gives enough context. =20 Yes, thanks for the typo in 2.1.2. I'll save it for Auth48. =20 A =20 From: Elwyn Davies [mailto:elwynd@dial.pipex.com]=20 Sent: 04 September 2017 14:46 To: adrian@olddog.co.uk; gen-art@ietf.org Cc: draft-ietf-teas-pce-central-control.all@ietf.org; ietf@ietf.org; = teas@ietf.org Subject: RE: [Teas] Genart telechat review of = draft-ietf-teas-pce-central-control-04 =20 =20 Hi, Adrian. =20 Two points: - I don't see an explanation of northbound in -05. - In the new text at the end of s2.1.2 s/whole the controllers/while the = controllers/ =20 Otherwise, the extra text and changes look helpful. =20 Best wshes, Elwyn =20 =20 Sent from Samsung tablet. =20 -------- Original message -------- From: Adrian Farrel =20 Date: 04/09/2017 10:47 (GMT+00:00)=20 To: 'Elwyn Davies' , gen-art@ietf.org=20 Cc: draft-ietf-teas-pce-central-control.all@ietf.org, ietf@ietf.org, = teas@ietf.org=20 Subject: RE: [Teas] Genart telechat review of = draft-ietf-teas-pce-central-control-04=20 =20 Thanks Elwyn, Clarified in the next revision. Adrian > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Elwyn Davies > Sent: 28 August 2017 20:24 > To: gen-art@ietf.org > Cc: draft-ietf-teas-pce-central-control.all@ietf.org; ietf@ietf.org; teas@ietf.org > Subject: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 >=20 > Reviewer: Elwyn Davies > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-teas-pce-central-control-04 > Reviewer: Elwyn Davies > Review Date: 2017-08-28 > IETF LC End Date: 2017-08-24 > IESG Telechat date: 2017-08-31 >=20 > Summary: Thanks for addressing my Last Call comments on -03. The new = version > is ready with one introduced nit. Also I am still of the abstract is = somewhat > overlong. >=20 > Nit: > s6, para 2: The SDN term 'northbound' has appeared in the new version. = Needs > brief explanation. >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas ------=_NextPart_000_0551_01D325A7.7D500A40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Elwyn,

 

-04 = has

=C2=A0=C2=A0 Some of this will be the = TED as is normal for a PCE and can be

=C2=A0=C2=A0collected using the = mechanisms already in place (such as listening = to

=C2=A0=C2=A0 the IGPs, using BGP-LS = [RFC7752], or northbound export of YANG-

=C2=A0=C2=A0 encoded data = [I-D.ietf-teas-yang-te-topo]).

-05 = has

=C2=A0=C2=A0 Some of this will be the = TED as is normal for a PCE and can be

=C2=A0=C2=A0 collected using the = mechanisms already in place (such as listening = to

=C2=A0=C2=A0 the IGPs, using BGP-LS = [RFC7752], or northbound export of YANG-

=C2=A0=C2=A0 encoded data = [I-D.ietf-teas-yang-te-topo] from the network = elements

=C2=A0=C2=A0 to the = controller).

 

I think that probably gives = enough context.

 

Yes, thanks for the typo in = 2.1.2. I'll save it for Auth48.

 

A

 

From: Elwyn Davies = [mailto:elwynd@dial.pipex.com]
Sent: 04 September 2017 = 14:46
To: adrian@olddog.co.uk; gen-art@ietf.org
Cc: = draft-ietf-teas-pce-central-control.all@ietf.org; ietf@ietf.org; = teas@ietf.org
Subject: RE: [Teas] Genart telechat review of = draft-ietf-teas-pce-central-control-04

<= p class=3DMsoNormal> 

 

Hi, Adrian.

 

Two points:

- I don't see an explanation of northbound in = -05.

- In the new text at = the end of s2.1.2 s/whole the controllers/while the = controllers/

 

Otherwise, the extra text and changes look = helpful.

 

Best wshes,

Elwyn

 

 

Sent from Samsung = tablet.

 

-------- Original message = --------

From: = Adrian Farrel <adrian@olddog.co.uk> =

Date: = 04/09/2017 10:47 (GMT+00:00)

To: 'Elwyn Davies' <elwynd@dial.pipex.com>, = gen-art@ietf.org

Cc: = draft-ietf-teas-pce-central-control.all@ietf.org, ietf@ietf.org, = teas@ietf.org

Subject: RE: [Teas] Genart telechat review of = draft-ietf-teas-pce-central-control-04 =

 

Thanks = Elwyn,

Clarified in the next revision.

Adrian

> = -----Original Message-----
> From: Teas = [mailto:teas-bounces@ietf.org] On Behalf Of Elwyn Davies
> Sent: = 28 August 2017 20:24
> To: gen-art@ietf.org
> Cc: = draft-ietf-teas-pce-central-control.all@ietf.org; = ietf@ietf.org;
teas@ietf.org
> Subject: [Teas] Genart telechat = review of
draft-ietf-teas-pce-central-control-04
>
> = Reviewer: Elwyn Davies
> Review result: Ready with Nits
> =
> I am the assigned Gen-ART reviewer for this draft. The General = Area
> Review Team (Gen-ART) reviews all IETF documents being = processed
> by the IESG for the IETF Chair. Please wait for = direction from your
> document shepherd or AD before posting a new = version of the draft.
>
> For more information, please see = the FAQ at
>
> = <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> = Document: draft-ietf-teas-pce-central-control-04
> Reviewer: Elwyn = Davies
> Review Date: 2017-08-28
> IETF LC End Date: = 2017-08-24
> IESG Telechat date: 2017-08-31
>
> = Summary: Thanks for addressing my Last Call comments on -03.  The = new version
> is ready with one introduced nit.  Also I am = still of the abstract is somewhat
> overlong.
>
> = Nit:
> s6, para 2: The SDN term 'northbound' has appeared in the = new version. Needs
> brief explanation.
>
> Major = issues:
>
> Minor issues:
>
> Nits/editorial = comments:
>
>
> = _______________________________________________
> Teas mailing = list
> Teas@ietf.org
> = https://www.ietf.org/mailman/listinfo/teas

------=_NextPart_000_0551_01D325A7.7D500A40-- From nobody Mon Sep 4 14:01:07 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652911320CF; Mon, 4 Sep 2017 14:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAk9ZtmhqgFV; Mon, 4 Sep 2017 14:01:03 -0700 (PDT) Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [81.187.30.51]) (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 3D9EB12426E; Mon, 4 Sep 2017 14:01:03 -0700 (PDT) Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[192.168.0.134]) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1doyNs-0001VZ-34; Mon, 04 Sep 2017 21:54:16 +0100 Date: Mon, 04 Sep 2017 21:54:14 +0100 Message-ID: <21r6makqd3wjckx8ptulkfkg.1504558193773@email.android.com> Importance: normal From: Elwyn Davies To: adrian@olddog.co.uk, gen-art@ietf.org Cc: draft-ietf-teas-pce-central-control.all@ietf.org, ietf@ietf.org, teas@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1049265487762570" Archived-At: Subject: Re: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 21:01:06 -0000 ----_com.samsung.android.email_1049265487762570 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIEFkcmlhbi4KT0ssIGl0J3MgYSBmYWlyIGNvcC4KQ2hlZXJzLEVsd3luCgoKU2VudCBmcm9t IFNhbXN1bmcgdGFibGV0LgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTog QWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4gRGF0ZTogMDQvMDkvMjAxNyAgMTc6 NTkgIChHTVQrMDA6MDApIFRvOiAnRWx3eW4gRGF2aWVzJyA8ZWx3eW5kQGRpYWwucGlwZXguY29t PiwgZ2VuLWFydEBpZXRmLm9yZyBDYzogZHJhZnQtaWV0Zi10ZWFzLXBjZS1jZW50cmFsLWNvbnRy b2wuYWxsQGlldGYub3JnLCBpZXRmQGlldGYub3JnLCB0ZWFzQGlldGYub3JnIFN1YmplY3Q6IFJF OiBbVGVhc10gR2VuYXJ0IHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNl bnRyYWwtY29udHJvbC0wNCAKSGkgRWx3eW4swqAtMDQgaGFzwqDCoCBTb21lIG9mIHRoaXMgd2ls bCBiZSB0aGUgVEVEIGFzIGlzIG5vcm1hbCBmb3IgYSBQQ0UgYW5kIGNhbiBiZSDCoMKgY29sbGVj dGVkIHVzaW5nIHRoZSBtZWNoYW5pc21zIGFscmVhZHkgaW4gcGxhY2UgKHN1Y2ggYXMgbGlzdGVu aW5nIHRvwqDCoCB0aGUgSUdQcywgdXNpbmcgQkdQLUxTIFtSRkM3NzUyXSwgb3Igbm9ydGhib3Vu ZCBleHBvcnQgb2YgWUFORy3CoMKgIGVuY29kZWQgZGF0YSBbSS1ELmlldGYtdGVhcy15YW5nLXRl LXRvcG9dKS4tMDUgaGFzwqDCoCBTb21lIG9mIHRoaXMgd2lsbCBiZSB0aGUgVEVEIGFzIGlzIG5v cm1hbCBmb3IgYSBQQ0UgYW5kIGNhbiBiZcKgwqAgY29sbGVjdGVkIHVzaW5nIHRoZSBtZWNoYW5p c21zIGFscmVhZHkgaW4gcGxhY2UgKHN1Y2ggYXMgbGlzdGVuaW5nIHRvwqDCoCB0aGUgSUdQcywg dXNpbmcgQkdQLUxTIFtSRkM3NzUyXSwgb3Igbm9ydGhib3VuZCBleHBvcnQgb2YgWUFORy3CoMKg IGVuY29kZWQgZGF0YSBbSS1ELmlldGYtdGVhcy15YW5nLXRlLXRvcG9dIGZyb20gdGhlIG5ldHdv cmsgZWxlbWVudHPCoMKgIHRvIHRoZSBjb250cm9sbGVyKS7CoEkgdGhpbmsgdGhhdCBwcm9iYWJs eSBnaXZlcyBlbm91Z2ggY29udGV4dC7CoFllcywgdGhhbmtzIGZvciB0aGUgdHlwbyBpbiAyLjEu Mi4gSSdsbCBzYXZlIGl0IGZvciBBdXRoNDguwqBBwqBGcm9tOiBFbHd5biBEYXZpZXMgW21haWx0 bzplbHd5bmRAZGlhbC5waXBleC5jb21dIApTZW50OiAwNCBTZXB0ZW1iZXIgMjAxNyAxNDo0NgpU bzogYWRyaWFuQG9sZGRvZy5jby51azsgZ2VuLWFydEBpZXRmLm9yZwpDYzogZHJhZnQtaWV0Zi10 ZWFzLXBjZS1jZW50cmFsLWNvbnRyb2wuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyB0ZWFz QGlldGYub3JnClN1YmplY3Q6IFJFOiBbVGVhc10gR2VuYXJ0IHRlbGVjaGF0IHJldmlldyBvZiBk cmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC0wNMKgwqBIaSwgQWRyaWFuLsKgVHdv IHBvaW50czotIEkgZG9uJ3Qgc2VlIGFuIGV4cGxhbmF0aW9uIG9mIG5vcnRoYm91bmQgaW4gLTA1 Li0gSW4gdGhlIG5ldyB0ZXh0IGF0IHRoZSBlbmQgb2YgczIuMS4yIHMvd2hvbGUgdGhlIGNvbnRy b2xsZXJzL3doaWxlIHRoZSBjb250cm9sbGVycy/CoE90aGVyd2lzZSwgdGhlIGV4dHJhIHRleHQg YW5kIGNoYW5nZXMgbG9vayBoZWxwZnVsLsKgQmVzdCB3c2hlcyxFbHd5bsKgwqBTZW50IGZyb20g U2Ftc3VuZyB0YWJsZXQuwqAtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTog QWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4gRGF0ZTogMDQvMDkvMjAxNyAxMDo0 NyAoR01UKzAwOjAwKSBUbzogJ0Vsd3luIERhdmllcycgPGVsd3luZEBkaWFsLnBpcGV4LmNvbT4s IGdlbi1hcnRAaWV0Zi5vcmcgQ2M6IGRyYWZ0LWlldGYtdGVhcy1wY2UtY2VudHJhbC1jb250cm9s LmFsbEBpZXRmLm9yZywgaWV0ZkBpZXRmLm9yZywgdGVhc0BpZXRmLm9yZyBTdWJqZWN0OiBSRTog W1RlYXNdIEdlbmFydCB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi10ZWFzLXBjZS1jZW50 cmFsLWNvbnRyb2wtMDQgwqBUaGFua3MgRWx3eW4sCgpDbGFyaWZpZWQgaW4gdGhlIG5leHQgcmV2 aXNpb24uCgpBZHJpYW4KCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBUZWFz IFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRWx3eW4gRGF2aWVz Cj4gU2VudDogMjggQXVndXN0IDIwMTcgMjA6MjQKPiBUbzogZ2VuLWFydEBpZXRmLm9yZwo+IENj OiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC5hbGxAaWV0Zi5vcmc7IGlldGZA aWV0Zi5vcmc7CnRlYXNAaWV0Zi5vcmcKPiBTdWJqZWN0OiBbVGVhc10gR2VuYXJ0IHRlbGVjaGF0 IHJldmlldyBvZgpkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC0wNAo+IAo+IFJl dmlld2VyOiBFbHd5biBEYXZpZXMKPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHMKPiAK PiBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUg R2VuZXJhbCBBcmVhCj4gUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nIHByb2Nlc3NlZAo+IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4g UGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIKPiBkb2N1bWVudCBzaGVwaGVyZCBv ciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4KPiAKPiBGb3Ig bW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0Cj4gCj4gPGh0dHBzOi8vdHJh Yy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcT4uCj4gCj4gRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtdGVhcy1wY2UtY2VudHJhbC1jb250cm9sLTA0Cj4gUmV2aWV3ZXI6IEVsd3luIERhdmll cwo+IFJldmlldyBEYXRlOiAyMDE3LTA4LTI4Cj4gSUVURiBMQyBFbmQgRGF0ZTogMjAxNy0wOC0y NAo+IElFU0cgVGVsZWNoYXQgZGF0ZTogMjAxNy0wOC0zMQo+IAo+IFN1bW1hcnk6IFRoYW5rcyBm b3IgYWRkcmVzc2luZyBteSBMYXN0IENhbGwgY29tbWVudHMgb24gLTAzLsKgIFRoZSBuZXcgdmVy c2lvbgo+IGlzIHJlYWR5IHdpdGggb25lIGludHJvZHVjZWQgbml0LsKgIEFsc28gSSBhbSBzdGls bCBvZiB0aGUgYWJzdHJhY3QgaXMgc29tZXdoYXQKPiBvdmVybG9uZy4KPiAKPiBOaXQ6Cj4gczYs IHBhcmEgMjogVGhlIFNETiB0ZXJtICdub3J0aGJvdW5kJyBoYXMgYXBwZWFyZWQgaW4gdGhlIG5l dyB2ZXJzaW9uLiBOZWVkcwo+IGJyaWVmIGV4cGxhbmF0aW9uLgo+IAo+IE1ham9yIGlzc3VlczoK PiAKPiBNaW5vciBpc3N1ZXM6Cj4gCj4gTml0cy9lZGl0b3JpYWwgY29tbWVudHM6Cj4gCj4gCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBUZWFzIG1h aWxpbmcgbGlzdAo+IFRlYXNAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RlYXM= ----_com.samsung.android.email_1049265487762570 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkhpLCBBZHJpYW4uPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5PSywgaXQncyBhIGZhaXIgY29wLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+Q2hlZXJzLDwvZGl2PjxkaXY+RWx3eW48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxk aXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGlyPSJhdXRvIj5TZW50IGZy b20gU2Ftc3VuZyB0YWJsZXQuPC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRp dj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBBZHJp YW4gRmFycmVsICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDA0 LzA5LzIwMTcgIDE3OjU5ICAoR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiAnRWx3eW4gRGF2aWVz JyAmbHQ7ZWx3eW5kQGRpYWwucGlwZXguY29tJmd0OywgZ2VuLWFydEBpZXRmLm9yZyA8L2Rpdj48 ZGl2PkNjOiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC5hbGxAaWV0Zi5vcmcs IGlldGZAaWV0Zi5vcmcsIHRlYXNAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBSRTogW1Rl YXNdIEdlbmFydCB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi10ZWFzLXBjZS1jZW50cmFs LWNvbnRyb2wtMDQgPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpIEVsd3luLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi0wNCBoYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOnllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5Tb21lIG9mIHRoaXMgd2lsbCBiZSB0aGUgVEVE IGFzIGlzIG5vcm1hbCBmb3IgYSBQQ0UgYW5kIGNhbiBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGkt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiA8 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPmNvbGxlY3Rl ZCB1c2luZyB0aGUgbWVjaGFuaXNtcyBhbHJlYWR5IGluIHBsYWNlIChzdWNoIGFzIGxpc3Rlbmlu ZyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4m bmJzcDsmbmJzcDsgPC9zcGFuPnRoZSBJR1BzLCB1c2luZyBCR1AtTFMgW1JGQzc3NTJdLCBvciBu b3J0aGJvdW5kIGV4cG9ydCBvZiBZQU5HLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsgPC9zcGFuPmVuY29kZWQgZGF0YSBbSS1E LmlldGYtdGVhcy15YW5nLXRlLXRvcG9dKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj4tMDUgaGFzPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZu YnNwOyA8L3NwYW4+U29tZSBvZiB0aGlzIHdpbGwgYmUgdGhlIFRFRCBhcyBpcyBub3JtYWwgZm9y IGEgUENFIGFuZCBjYW4gYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNw YWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5jb2xsZWN0ZWQgdXNpbmcgdGhlIG1lY2hh bmlzbXMgYWxyZWFkeSBpbiBwbGFjZSAoc3VjaCBhcyBsaXN0ZW5pbmcgdG88bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bh bj50aGUgSUdQcywgdXNpbmcgQkdQLUxTIFtSRkM3NzUyXSwgb3Igbm9ydGhib3VuZCBleHBvcnQg b2YgWUFORy08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnll cyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5lbmNvZGVkIGRhdGEgW0ktRC5pZXRmLXRlYXMteWFuZy10 ZS10b3BvXSBmcm9tIHRoZSBuZXR3b3JrIGVsZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyA8L3NwYW4+dG8gdGhlIGNv bnRyb2xsZXIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgdGhpbmsgdGhhdCBwcm9iYWJseSBnaXZlcyBlbm91Z2ggY29udGV4dC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIHRoYW5rcyBmb3IgdGhlIHR5 cG8gaW4gMi4xLjIuIEknbGwgc2F2ZSBpdCBmb3IgQXV0aDQ4LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1iaWRpLWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij48ZGl2PjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpF Ti1VUyI+IEVsd3luIERhdmllcyBbbWFpbHRvOmVsd3luZEBkaWFsLnBpcGV4LmNvbV0gPGJyPjxi PlNlbnQ6PC9iPiAwNCBTZXB0ZW1iZXIgMjAxNyAxNDo0Njxicj48Yj5Ubzo8L2I+IGFkcmlhbkBv bGRkb2cuY28udWs7IGdlbi1hcnRAaWV0Zi5vcmc8YnI+PGI+Q2M6PC9iPiBkcmFmdC1pZXRmLXRl YXMtcGNlLWNlbnRyYWwtY29udHJvbC5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IHRlYXNA aWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbVGVhc10gR2VuYXJ0IHRlbGVjaGF0IHJl dmlldyBvZiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC0wNDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkhp LCBBZHJpYW4uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+VHdvIHBvaW50czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4tIEkgZG9uJ3Qgc2Vl IGFuIGV4cGxhbmF0aW9uIG9mIG5vcnRoYm91bmQgaW4gLTA1LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPi0gSW4gdGhlIG5ldyB0 ZXh0IGF0IHRoZSBlbmQgb2YgczIuMS4yIHMvd2hvbGUgdGhlIGNvbnRyb2xsZXJzL3doaWxlIHRo ZSBjb250cm9sbGVycy88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5PdGhlcndpc2UsIHRoZSBleHRyYSB0ZXh0 IGFuZCBjaGFuZ2VzIGxvb2sgaGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5CZXN0IHdzaGVzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPkVsd3luPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzU3NTc1NyI+U2VudCBmcm9tIFNhbXN1 bmcgdGFibGV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjpibGFjayI+LS0tLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6YmxhY2siPkZyb206IEFkcmlh biBGYXJyZWwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6YmxhY2siPkRh dGU6IDA0LzA5LzIwMTcgMTA6NDcgKEdNVCswMDowMCkgPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjpibGFjayI+VG86ICdF bHd5biBEYXZpZXMnICZsdDtlbHd5bmRAZGlhbC5waXBleC5jb20mZ3Q7LCBnZW4tYXJ0QGlldGYu b3JnIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDs7Y29sb3I6YmxhY2siPkNjOiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29u dHJvbC5hbGxAaWV0Zi5vcmcsIGlldGZAaWV0Zi5vcmcsIHRlYXNAaWV0Zi5vcmcgPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xv cjpibGFjayI+U3ViamVjdDogUkU6IFtUZWFzXSBHZW5hcnQgdGVsZWNoYXQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtdGVhcy1wY2UtY2VudHJhbC1jb250cm9sLTA0IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPlRoYW5rcyBFbHd5biw8YnI+ PGJyPkNsYXJpZmllZCBpbiB0aGUgbmV4dCByZXZpc2lvbi48YnI+PGJyPkFkcmlhbjxicj48YnI+ Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IFRlYXMgW21haWx0 bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFbHd5biBEYXZpZXM8YnI+Jmd0 OyBTZW50OiAyOCBBdWd1c3QgMjAxNyAyMDoyNDxicj4mZ3Q7IFRvOiBnZW4tYXJ0QGlldGYub3Jn PGJyPiZndDsgQ2M6IGRyYWZ0LWlldGYtdGVhcy1wY2UtY2VudHJhbC1jb250cm9sLmFsbEBpZXRm Lm9yZzsgaWV0ZkBpZXRmLm9yZzs8YnI+dGVhc0BpZXRmLm9yZzxicj4mZ3Q7IFN1YmplY3Q6IFtU ZWFzXSBHZW5hcnQgdGVsZWNoYXQgcmV2aWV3IG9mPGJyPmRyYWZ0LWlldGYtdGVhcy1wY2UtY2Vu dHJhbC1jb250cm9sLTA0PGJyPiZndDsgPGJyPiZndDsgUmV2aWV3ZXI6IEVsd3luIERhdmllczxi cj4mZ3Q7IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggTml0czxicj4mZ3Q7IDxicj4mZ3Q7IEkg YW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5l cmFsIEFyZWE8YnI+Jmd0OyBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkPGJyPiZndDsgYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRG IENoYWlyLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91cjxicj4mZ3Q7IGRvY3Vt ZW50IHNoZXBoZXJkIG9yIEFEIGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRy YWZ0Ljxicj4mZ3Q7IDxicj4mZ3Q7IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRo ZSBGQVEgYXQ8YnI+Jmd0OyA8YnI+Jmd0OyAmbHQ7aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMv Z2VuL3dpa2kvR2VuQXJ0ZmFxJmd0Oy48YnI+Jmd0OyA8YnI+Jmd0OyBEb2N1bWVudDogZHJhZnQt aWV0Zi10ZWFzLXBjZS1jZW50cmFsLWNvbnRyb2wtMDQ8YnI+Jmd0OyBSZXZpZXdlcjogRWx3eW4g RGF2aWVzPGJyPiZndDsgUmV2aWV3IERhdGU6IDIwMTctMDgtMjg8YnI+Jmd0OyBJRVRGIExDIEVu ZCBEYXRlOiAyMDE3LTA4LTI0PGJyPiZndDsgSUVTRyBUZWxlY2hhdCBkYXRlOiAyMDE3LTA4LTMx PGJyPiZndDsgPGJyPiZndDsgU3VtbWFyeTogVGhhbmtzIGZvciBhZGRyZXNzaW5nIG15IExhc3Qg Q2FsbCBjb21tZW50cyBvbiAtMDMuJm5ic3A7IFRoZSBuZXcgdmVyc2lvbjxicj4mZ3Q7IGlzIHJl YWR5IHdpdGggb25lIGludHJvZHVjZWQgbml0LiZuYnNwOyBBbHNvIEkgYW0gc3RpbGwgb2YgdGhl IGFic3RyYWN0IGlzIHNvbWV3aGF0PGJyPiZndDsgb3ZlcmxvbmcuPGJyPiZndDsgPGJyPiZndDsg Tml0Ojxicj4mZ3Q7IHM2LCBwYXJhIDI6IFRoZSBTRE4gdGVybSAnbm9ydGhib3VuZCcgaGFzIGFw cGVhcmVkIGluIHRoZSBuZXcgdmVyc2lvbi4gTmVlZHM8YnI+Jmd0OyBicmllZiBleHBsYW5hdGlv bi48YnI+Jmd0OyA8YnI+Jmd0OyBNYWpvciBpc3N1ZXM6PGJyPiZndDsgPGJyPiZndDsgTWlub3Ig aXNzdWVzOjxicj4mZ3Q7IDxicj4mZ3Q7IE5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOjxicj4mZ3Q7 IDxicj4mZ3Q7IDxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPiZndDsgVGVhcyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBUZWFzQGlldGYub3Jn PGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_1049265487762570-- From nobody Tue Sep 5 11:12:43 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 759D7132E1B; Tue, 5 Sep 2017 11:12:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-teas-pce-central-control@ietf.org, db3546@att.com, Vishnu Beeram , teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150463514847.29774.8271065121186291736.idtracker@ietfa.amsl.com> Date: Tue, 05 Sep 2017 11:12:28 -0700 Archived-At: Subject: [Teas] Document Action: 'An Architecture for Use of PCE and PCEP in a Network with Central Control' to Informational RFC (draft-ietf-teas-pce-central-control-05.txt) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:12:28 -0000 The IESG has approved the following document: - 'An Architecture for Use of PCE and PCEP in a Network with Central Control' (draft-ietf-teas-pce-central-control-05.txt) as Informational RFC This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/ Technical Summary The Path Computation Element (PCE) has become established as a core component of Software Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network for any definition of "optimal" and can also monitor changes in resource availability and traffic demands to update the paths. Conventionally, the PCE has been used to derive paths for MPLS Label Switched Paths (LSPs). These paths are supplied using the Path Computation Element Communication Protocol (PCEP) to the head end of the LSP for signaling in the MPLS network. This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a southbound interface, and introduces the implications for the protocol. This document does not describe the use cases in detail and does not define protocol extensions: that work is left for other documents. Working Group Summary The progress of the document through the WG has been smooth. There was some serious debate before the last call with regards to implications on manageability and on PCEP. The authors addressed all of these concerns by adding relevant text to the document. Document Quality This document has been discussed and reviewed thoroughly by the WG. The base PCE architecture and the PCEP protocol have been implemented. The document that discusses the use-cases for PCE as a central controller is actively being worked on. While there have been no public statements on implementation of this new architecture, the authors are from multiple vendors, and implementation is expected. Personnel Who is the Document Shepherd for this document? Vishnu Pavan Beeram Who is the Responsible Area Director? Deborah Brungard RFC Editor Note text at the end of s2.1.2: s/whole the controllers/while the controllers/ From nobody Fri Sep 8 01:02:02 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37BF132EB9; Fri, 8 Sep 2017 01:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 EC4_aiYSYap2; Fri, 8 Sep 2017 01:01:56 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 AAEB91241F3; Fri, 8 Sep 2017 01:01:55 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-ac-59b24e717fa1 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 06.79.20899.17E42B95; Fri, 8 Sep 2017 10:01:53 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 8 Sep 2017 10:01:52 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+pMW6G2gNFcU2TJIhS+JIkiCgqcQ/dz3ocFW4wjc6FY=; b=CKDJQFsVaPQF31UwotemjKHTX/+MSI0usx6npEW8MwBb+hcpztfKVsg7nU/EBqV19HnOO2l1ojfNRe+kZbEctq/oLtQcea+Tii1DjYeXa5FyKSniKekEzmaJG89+EYe17Ds7fKDEBQTkjgMDMUxi0o37DGpzuqC3PgWKpIex2KA= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0915.eurprd07.prod.outlook.com (10.162.36.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Fri, 8 Sep 2017 08:01:52 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::35e7:e720:5b67:2ea9]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([fe80::35e7:e720:5b67:2ea9%13]) with mapi id 15.20.0035.016; Fri, 8 Sep 2017 08:01:52 +0000 From: Daniele Ceccarelli To: Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTI2aOSG8tGmrAgEquV4apGnqO7aKqqkzA Date: Fri, 8 Sep 2017 08:01:51 +0000 Message-ID: References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.0.200.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0915; 6:W/0OSLl9udNxZj9aKk4K59rYzTJk6XcyN/Qc6hJNnyyyKnb2279qE7R5ER81EHndvmaKkXBVPfM2k1Y76ImjZ/ZAvsPHBRBwKfJuMJ/tBASMI6wetdUkPuQPoiSIYrpHh5a9xBsIoqyhBFtcJIhZWP7U+GMSrDwhZXTpBwyemORtM+FNbGypg5Nef3XBAu+GCtZ8VZRVfCfPeaNvmIfmuMFXssTWWxR7XxaREBXzerUSkfsXkZr2XGjcmw6FDuWeM7AdO3Ef2KQtriM0/lw+bjXw2RG1agl4XRcJanXVkNZ+UnF2ctvw2YvwH+hCdjXrBNi6eVe2dXuoBlq94qtgRw==; 5:sW/QDnKGcEk2xHSjbJr1xAmvL64JqWCIcw30Vj2beVFWDXv+cFRwZgCL+BUlYtg0NWjN+3dvLSdvZBSsPF2jCk3pWtbEdiYKqvH0b/AomlVIGwZFqhCJ5hABIku0/ObYL8PVNUr5kn9t34QP3p+eVOOWDQ0UWOzppgqGqo8pR0k=; 24:45GmSX/itTWQ7ANSGkpNmA5QMCKt4xYc/PYrqeBpAcx9n4weEidvTfcMw+eWxNkOLwYO6Ym785okzmqq5Br8v8AdXhJdeW3MdDkn6EZ/Tp8=; 7:j6fVqZmU4DPt4OEdCIqSqc12gOcgsw6EBdDTvwwEH5rcsoSe+8/SP6E2yDRq04g6nV1WBgsr/RMVknm+32TaJgzLAxivW//sQqxogmFUlAxr1gIrvMt+FshZS66UPj+GR2ZMdOsXLWX8GGwx/Y4PLViZV9285+qE2Y6W94UMpCjWmcT4jOtBHhvfjCMKsPYiqnGYVGdlRnDEbDsZ23v5GApPKqP3E+Q1676IYaL8na0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 06927c83-4a2f-4f86-44ae-08d4f68fdd55 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0915; x-ms-traffictypediagnostic: AM2PR07MB0915: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0915; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0915; x-forefront-prvs: 04244E0DC5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(189002)(13464003)(199003)(6436002)(14454004)(53546010)(5250100002)(6506006)(68736007)(7696004)(54356999)(76176999)(189998001)(5660300001)(8936002)(97736004)(81166006)(8676002)(2950100002)(966005)(81156014)(25786009)(7736002)(478600001)(229853002)(4326008)(86362001)(305945005)(102836003)(6116002)(3846002)(105586002)(106356001)(55016002)(6246003)(99286003)(54906002)(6306002)(9686003)(53936002)(66066001)(33656002)(101416001)(50986999)(2900100001)(230783001)(2906002)(3660700001)(74316002)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0915; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2017 08:01:51.9097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0915 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee692+6Wi6epedD80KgPGZumfTCVcEYhmBGUoCXkysscTme7 Jmkgphg6E1/KxElauhyMLLCm06R0KGJbuMRgZgnNhW8Ns/ygWJrbVejb7/zPec7Ln4cmJbW8 UFqdX8jo8pUaKV9EtaT3JcluXujJiKpcPBa7MbBFxlZVeKnY8scDRGzlupVKpJKNxg0i+WdP Bf8icUWUkM1o1EWMLvJ0lijH1DSHCkz07V+rDqIMLfP1SEgDPgnN6x6kRyJagkcQbA4aSS4Y Q7Cmd/sDCteSUF37R8BlHhAw+qV3940bwXzbh51mNM3HceCxnff1DdrBqqF+wieTuBS+j8b4 5ECsgKk6r4ArSYLGlW0ex9FgGV/1r0ThI2B0vEM+FuNMaH0/7q+R4HjosBv8uhAnQFej3c8I h0P9mw4/kzgEPnvaCe40DMbBCZLjYFic2+JxfBicZsNuTThMttf4TwFsEIDjh3fXFzlYGryI 41S4u9Qq4NhNwLR5t2kEOFc6edwS1+FlpZXY06tG9gbkwsgzB48bYOfBTHMD6TMF8CFYdGXV I5nhv705loOr6SGf4+PQ9XSZNPi9OADjLR7qCaLMKJhlWDZPFR0tZ3TqGyyrzZfnM4U9aOeT DL/ejLOi4XmFDWEaSQPE6+d6MiQ8ZRFbnGdDQJPSILH27I4kzlYWlzA67TXdLQ3D2lAYTUlD xIlvnekSrFIWMrkMU8Do9rIELQwtQ9reib7tzpw2fn/M2kK24K/r05yz0/683PWiT9F9Jkky c+/q/oOz6YELCmuaSRZisWmmJnoDf7NrMe1RgvFv1ZmDGZMyVcpXtzXAUnqKThJqVHrTbAJp 6y6K3Fwaq7kT/eh+3b7p+MjLWeqPKYslky1D3qOCsEuv6s0VdGpas5Ric5QnIkgdq/wH+Hn+ cSADAAA= Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 08:01:59 -0000 Hi Lou, all, i've reviewed the draft and i think it's ready to move on. BR Daniele =20 -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: venerd=EC 1 settembre 2017 23:09 To: TEAS WG Cc: TEAS WG Chairs ; draft-ietf-teas-yang-te-topo@iet= f.org Subject: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 All, This starts a *three* week working group last call on draft-ietf-teas-yang-= te-topo-12. This last call is extended due to the size of the document and= it being the first YANG model going to LC within the group The working group last call ends on September 22. Please send your comments to the TEAS mailing list. Positive comments, e.g., "I've reviewed this document and believe it is rea= dy for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri Sep 8 06:35:39 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4E11321A4; Fri, 8 Sep 2017 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYcM4VX-TzNG; Fri, 8 Sep 2017 06:35:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C4A1321DF; Fri, 8 Sep 2017 06:35:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVA92929; Fri, 08 Sep 2017 13:35:34 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 8 Sep 2017 14:35:32 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML703-CHM.china.huawei.com ([169.254.5.62]) with mapi id 14.03.0301.000; Fri, 8 Sep 2017 06:35:25 -0700 From: Leeyoung To: Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTI2aMBHqAYFwEu06Da3BD5SSNUqKrB70g Date: Fri, 8 Sep 2017 13:35:25 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B40E085@SJCEML702-CHM.china.huawei.com> References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59B29CA6.018A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 84d0d594765f0356ef106b50a0c6fd95 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 13:35:39 -0000 Hi, I read the document and I think it is ready for the WG LC. Thanks, Young -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, September 01, 2017 4:09 PM To: TEAS WG Cc: TEAS WG Chairs ; draft-ietf-teas-yang-te-topo@iet= f.org Subject: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 All, This starts a *three* week working group last call on draft-ietf-teas-yang-= te-topo-12. This last call is extended due to the size of the document and= it being the first YANG model going to LC within the group The working group last call ends on September 22. Please send your comments to the TEAS mailing list. Positive comments, e.g., "I've reviewed this document and believe it is rea= dy for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri Sep 8 06:41:14 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FCC132153; Fri, 8 Sep 2017 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHmUr42luSVu; Fri, 8 Sep 2017 06:41:11 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D5512421A; Fri, 8 Sep 2017 06:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1738; q=dns/txt; s=iport; t=1504878071; x=1506087671; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6WOC07FWwQ/FA2oO9yTFC79ahgtHPiyOBhRBVQ6RIIY=; b=lW0cSYB8RHuWqWeQu4+gUV+TP64b8vZU002GoKwLoC8HuurnuMJ3XOvu me8NtBQSjxViuWALZ5mVYtjKI65HeaGr9vQ+jb4mF0OeSrlx8uWrZK8h5 LDgXRrPPTfkFEJmVdUinIVDR3QhEU9QnlrNqogmaqH9x8htKXgo1no8cs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAwA9nbJZ/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBUicHg3CaQoFxmDoKhT4CGoNxVwECAQEBAQECayiFGAEBAQQ?= =?us-ascii?q?jEToLDAQCAQgOAwMBAgMCJgICAjAVCAgCBAENBYoxq3CCJ4s6AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYENgh2CAoFOgWMrgn2EdYMTMIIxBaB0ApRPghOFZ4p3lH4?= =?us-ascii?q?CERkBgTgBV0FMdxVJEgGHCHaJD4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,361,1500940800"; d="scan'208";a="728919" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2017 13:41:10 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v88Df9gJ015358 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Sep 2017 13:41:09 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Sep 2017 09:41:08 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1263.000; Fri, 8 Sep 2017 09:41:08 -0400 From: "Tarek Saad (tsaad)" To: Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTI2Z/8Eqz1P6qtkSMmvoyB0Jb+qKrCXiA Date: Fri, 8 Sep 2017 13:41:08 +0000 Message-ID: <3A1E0006-4F51-47AE-8B9C-650DCEAE0B5D@cisco.com> References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.240.168] Content-Type: text/plain; charset="utf-8" Content-ID: <3E8B31574EE64F4B9ECF37DF32C8D91A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 13:41:13 -0000 SGksDQoNCkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2ZSBpcyByZWFkeSBm b3IgcHVibGljYXRpb24uDQoNClJlZ2FyZHMsDQpUYXJlaw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NCkRhdGU6IEZyaWRh eSwgU2VwdGVtYmVyIDEsIDIwMTcgYXQgNTowOCBQTQ0KVG86IFRFQVMgV0cgPHRlYXNAaWV0Zi5v cmc+DQpDYzogVEVBUyBXRyBDaGFpcnMgPHRlYXMtY2hhaXJzQGlldGYub3JnPiwgImRyYWZ0LWll dGYtdGVhcy15YW5nLXRlLXRvcG9AaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXRlYXMteWFuZy10ZS10 b3BvQGlldGYub3JnPg0KU3ViamVjdDogV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRlYXMteWFu Zy10ZS10b3BvLTEyDQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNl bnQtVG86IDx4dWZlbmdfbGl1QGphYmlsLmNvbT4sIDxpZ29yLmJyeXNraW5AaHVhd2VpLmNvbT4s IDx2YmVlcmFtQGp1bmlwZXIubmV0PiwgVGFyZWsgU2FhZCA8dHNhYWRAY2lzY28uY29tPiwgPGhz aGFoQGNpZW5hLmNvbT4sIDxvc2Nhci5nb256YWxlemRlZGlvc0B0ZWxlZm9uaWNhLmNvbT4NClJl c2VudC1EYXRlOiBGcmlkYXksIFNlcHRlbWJlciAxLCAyMDE3IGF0IDU6MDggUE0NCg0KICAgIEFs bCwNCiAgICANCiAgICBUaGlzIHN0YXJ0cyBhICp0aHJlZSogd2VlayB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBvbg0KICAgIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8tMTIuICBUaGlzIGxh c3QgY2FsbCBpcw0KICAgIGV4dGVuZGVkIGR1ZSB0byB0aGUgc2l6ZSBvZiB0aGUgZG9jdW1lbnQg YW5kIGl0IGJlaW5nIHRoZQ0KICAgIGZpcnN0IFlBTkcgbW9kZWwgZ29pbmcgdG8gTEMgd2l0aGlu IHRoZSBncm91cA0KICAgIA0KICAgIFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9u IFNlcHRlbWJlciAyMi4NCiAgICBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFT IG1haWxpbmcgbGlzdC4NCiAgICANCiAgICBQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUg cmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQNCiAgICBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBw dWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KICAgIFRoaXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRh bnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KICAgIA0KICAgIFRoYW5rIHlvdSwNCiAgICBURUFTIENo YWlycw0KICAgIA0KDQo= From nobody Fri Sep 8 06:43:40 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5924132153; Fri, 8 Sep 2017 06:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5C5hweQzSr7; Fri, 8 Sep 2017 06:43:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C89412421A; Fri, 8 Sep 2017 06:43:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOE82918; Fri, 08 Sep 2017 13:43:33 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 8 Sep 2017 14:43:32 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML701-CHM.china.huawei.com ([169.254.3.191]) with mapi id 14.03.0301.000; Fri, 8 Sep 2017 06:43:23 -0700 From: Leeyoung To: Leeyoung , Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTI2aMBHqAYFwEu06Da3BD5SSNUqKrB70ggAACKFA= Date: Fri, 8 Sep 2017 13:43:23 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B40E09E@SJCEML702-CHM.china.huawei.com> References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> <7AEB3D6833318045B4AE71C2C87E8E172B40E085@SJCEML702-CHM.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172B40E085@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59B29E86.0012, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a09e35df40322fbf0f147a4620eb5186 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 13:43:39 -0000 Sorry What I meant is it is ready for publication. Young -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Leeyoung Sent: Friday, September 08, 2017 8:35 AM To: Lou Berger ; TEAS WG Cc: TEAS WG Chairs ; draft-ietf-teas-yang-te-topo@iet= f.org Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Hi, I read the document and I think it is ready for the WG LC. Thanks, Young -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, September 01, 2017 4:09 PM To: TEAS WG Cc: TEAS WG Chairs ; draft-ietf-teas-yang-te-topo@iet= f.org Subject: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 All, This starts a *three* week working group last call on draft-ietf-teas-yang-= te-topo-12. This last call is extended due to the size of the document and= it being the first YANG model going to LC within the group The working group last call ends on September 22. Please send your comments to the TEAS mailing list. Positive comments, e.g., "I've reviewed this document and believe it is rea= dy for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri Sep 8 10:45:09 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66934124207; Fri, 8 Sep 2017 10:45:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, Lou Berger , lberger@labn.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150489270537.17188.4985122003542433502.idtracker@ietfa.amsl.com> Date: Fri, 08 Sep 2017 10:45:05 -0700 Archived-At: Subject: [Teas] Last Call: (Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments) to Proposed Standard X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 17:45:05 -0000 The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is growing continually and the onus is on RSVP-TE implementations across the board to keep up with this increasing demand. This document introduces a couple of techniques - "Refresh-Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help RSVP-TE deployments push the envelope on scaling. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2643/ From nobody Mon Sep 11 06:03:52 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1391132199; Mon, 11 Sep 2017 06:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6sjyYExWjmq; Mon, 11 Sep 2017 06:03:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7F5133047; Mon, 11 Sep 2017 06:03:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVF28051; Mon, 11 Sep 2017 13:03:46 +0000 (GMT) Received: from YYZEML702-CHM.china.huawei.com (10.218.33.72) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 11 Sep 2017 14:03:45 +0100 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.16]) by YYZEML702-CHM.china.huawei.com ([169.254.6.93]) with mapi id 14.03.0301.000; Mon, 11 Sep 2017 09:03:41 -0400 From: "Aihuaguo (Aihua Guo, CRC)" To: Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTI2aLA0yQnjnH0kqSVal9WLmIRqKvs4JA Date: Mon, 11 Sep 2017 13:03:40 +0000 Message-ID: References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59B689B2.02A5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.16, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 84d0d594765f0356ef106b50a0c6fd95 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 13:03:52 -0000 Hi Lou, All, As an implementer I have worked closely with the design team making necessa= ry changes and eliminating issues that rose during implementation and verif= ication, and now this model is standing solidly with at least 2+ supporting= implementations coming from different vendors that I am aware of.=20 Therefore, I have reviewed the document and I think it is ready for publica= tion. Thank you. Aihua -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, September 01, 2017 5:09 PM To: TEAS WG Cc: TEAS WG Chairs; draft-ietf-teas-yang-te-topo@ietf.org Subject: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 All, This starts a *three* week working group last call on draft-ietf-teas-yang-= te-topo-12. This last call is extended due to the size of the document and= it being the first YANG model going to LC within the group The working group last call ends on September 22. Please send your comments to the TEAS mailing list. Positive comments, e.g., "I've reviewed this document and believe it is rea= dy for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Sep 11 18:22:43 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E771120724; Mon, 11 Sep 2017 18:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUuz9orssrOe; Mon, 11 Sep 2017 18:22:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC062120720; Mon, 11 Sep 2017 18:22:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOJ85824; Tue, 12 Sep 2017 01:22:21 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 12 Sep 2017 02:22:20 +0100 Received: from DGGEML503-MBX.china.huawei.com ([169.254.9.97]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Tue, 12 Sep 2017 09:22:16 +0800 From: Zhenghaomian To: Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTI2aIQhQCNnLgoUewq4/vZNNZf6Kwgurw Date: Tue, 12 Sep 2017 01:22:16 +0000 Message-ID: References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.57.78.212] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59B736DE.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.9.97, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cbe17876db371db47fc7b1c5227af810 Archived-At: Subject: [Teas] =?gb2312?b?tPC4tDogIFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi10?= =?gb2312?b?ZWFzLXlhbmctdGUtdG9wby0xMg==?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 01:22:42 -0000 SGksIFdHLCANCg0KV2UgaGF2ZSBiZWVuIGludm9sdmVkIHdpdGggaW1wbGVtZW50YXRpb24gb2Yg dGhpcyBtb2RlbCBmcm9tIHRoZSBlbmQgb2YgbGFzdCB5ZWFyLiBEZW1vbnN0cmF0aW9uIGFuZCBt b2RlbCB2ZXJpZmljYXRpb24gaGFzIGJlZW4gZGVwbG95ZWQgZnJvbSBlbXVsYXRpb24gdG8gcGh5 c2ljYWwgZXF1aXBtZW50LCBhbmQgdGhlIG1vZGVsIGl0c2VsZiBpcyBub3cgYmVjb21pbmcgc3Rh YmxlIGFuZCBtYXR1cmUuIFRoaXMgbW9kZWwgaXMgYSBiYXNlIG1vZGVsIGZvciBhbGwgVEUgdGVj aG5pcXVlcywgYW5kIHdlIGJlbGlldmUgaXQgc2hvdWxkIGJlIHRoZSBmb3VuZGF0aW9uIG9mIFlB TkcgbW9kZWxpbmcgd29yayBpbiBURUFTIHdvcmtpbmcgZ3JvdXAuIEl0IHdvdWxkIGFsc28gaW1w YWN0IHRoZSBkZXNpZ24gb2YgdGVjaG5vbG9neS1zcGVjaWZpYyBtb2RlbHMuIA0KDQpXZSBoYXZl IHJldmlld2VkIHRoZSBsYXRlc3QgbW9kZWwsIGNvbnNpZGVyaW5nIHRoZSBtYXR1cml0eSBhbmQg aW1wb3J0YW5jZSBvZiB0aGlzIG1vZGVsLCB3ZSBiZWxpZXZlIGl0J3MgcmVhZHkgZm9yIHB1Ymxp Y2F0aW9uLCB0aGFuayB5b3UuIA0KDQpCZXN0IHdpc2hlcywNCkhhb21pYW4NCg0KLS0tLS3Tyrz+ 1K28/i0tLS0tDQq3orz+yMs6IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddILT6 se0gTG91IEJlcmdlcg0Kt6LLzcqxvOQ6IDIwMTfE6jnUwjLI1SA1OjA5DQrK1bz+yMs6IFRFQVMg V0cNCrOty806IFRFQVMgV0cgQ2hhaXJzOyBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvQGll dGYub3JnDQrW98ziOiBbVGVhc10gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRlYXMteWFuZy10 ZS10b3BvLTEyDQoNCkFsbCwNCg0KVGhpcyBzdGFydHMgYSAqdGhyZWUqIHdlZWsgd29ya2luZyBn cm91cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wby0xMi4gIFRoaXMg bGFzdCBjYWxsIGlzIGV4dGVuZGVkIGR1ZSB0byB0aGUgc2l6ZSBvZiB0aGUgZG9jdW1lbnQgYW5k IGl0IGJlaW5nIHRoZSBmaXJzdCBZQU5HIG1vZGVsIGdvaW5nIHRvIExDIHdpdGhpbiB0aGUgZ3Jv dXANCg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gU2VwdGVtYmVyIDIyLg0K UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgVEVBUyBtYWlsaW5nIGxpc3QuDQoNClBv c2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBi ZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KVGhpcyBp cyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuDQoNClRoYW5rIHlvdSwN ClRFQVMgQ2hhaXJzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQo= From nobody Thu Sep 14 02:01:56 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA22A13219C; Thu, 14 Sep 2017 02:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 t-VuFgWQGIiL; Thu, 14 Sep 2017 02:01:53 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 556071243F6; Thu, 14 Sep 2017 02:01:52 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-9e-59ba457ed73c Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2D.B0.20899.E754AB95; Thu, 14 Sep 2017 11:01:50 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 14 Sep 2017 11:01:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kt9Iv09zm6idKKw6oCPn6Cm8TrUiQ2tJfKBGQLyGZIw=; b=BNnzxDRKCbBfK60r+m3OqBNDxCHGHWsMtPtcq2OONTZRIEPEmWiQCVygFE0n4QfmIumIggaCRl0WEOkP7kDJ1UPMrbGSp8ijksFIDtAP/9WdtFAl2JS4BKmrxvDZGMNhZmvMZEYyY663C3qs37ebQeQ1yVsjs7Iv82b+4+z5B4A= Received: from DB5PR07MB1574.eurprd07.prod.outlook.com (10.165.212.140) by DB5PR07MB0888.eurprd07.prod.outlook.com (10.161.196.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 09:01:44 +0000 Received: from DB5PR07MB1574.eurprd07.prod.outlook.com ([fe80::cde4:8a09:4f9a:78ff]) by DB5PR07MB1574.eurprd07.prod.outlook.com ([fe80::cde4:8a09:4f9a:78ff%14]) with mapi id 15.20.0056.010; Thu, 14 Sep 2017 09:01:42 +0000 From: Carlo Perocchio To: Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTI2aOxlGSfICUDkWFkIHRHE4ksKK0JXbA Date: Thu, 14 Sep 2017 09:01:42 +0000 Message-ID: References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.0.200.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB0888; 6:tAQXW4+vqBxX8FVeYA7R4NzK2rGoKg0HbGRnMBrfNsFHGG5S1PRtbZXNh9DtwH0r8DAc026feBecFPrRs9Ku45F2w/+Jm7aiCUBDeSajn/9anfHoLJRLL8l4vfvBUPavC/lY0LPz1bFqXbQJmrPMhpN0X4xstHyRk0AwDY8i/JnR8KdjRyyE3ZaYwGqc8ZX/FGOKsE+tSI6rPyUV74IqNVaVoaZnI2EB9uwDxB05FfMJrtmdAMJNg02BSK5AOaPC0UZgTRYb7eK7ghcvdcIvncNJ3h+5Z14ptMBQOMxg1RAA1HJSLA2GjnDQJP2eWZuJtKv4MXnbVBjHfUNglBfR/A==; 5:fKoVtJWef/rtXqGSaMeowLz+Cr/92QBYHzlVYKP5KMhDUpQcBFJBJuwZDlKHkrFJ4lsGHfl17HANcYsb+kZrhV88B2C4kLX/+Ud3j7kJPw+UkPYPsQDyE1CY/DwivAu/KsV0jgTNsEKa2ZNAwas0kg==; 24:i6SaPZpjycelLe11frShTEY+o9zIwVNOeUqQDcJ8tYiZ+NNxEVeMisRE6J10rSbYH3Q31RzO6TG42FQaF7uR7VpktuDDguaDk8hKDxg76PA=; 7:+SMnVKEreKIzkIS0ZhSTwWpdmHJOd8tiAKBDAOR+1qF09QGrf5yrA+MZJuRhpDIBKEvXEjspanrTZweDLTsJ2lzX0ov7l32pUmcfiP/DVyvscyftP10D6xyetfVnYdzwjlNZ8eoDkP65y0LfetlSob8RLL+6SojPpVC8v9afLeFdIWgI50MuL8NKVyzz5I0+y4RRf9R5OW7xAJztGyRlccHhBtKLG3qF5xaFj//JYh8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 128eae5d-e995-430b-4a82-08d4fb4f37c8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB0888; x-ms-traffictypediagnostic: DB5PR07MB0888: authentication-results: spf=none (sender IP is ) smtp.mailfrom=carlo.perocchio@ericsson.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(201703131423075)(201703061421075)(201703161042150)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6042181)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0888; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0888; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(199003)(13464003)(189002)(66066001)(6246003)(230783001)(966005)(101416001)(6506006)(6436002)(498600001)(68736007)(6116002)(105586002)(102836003)(106356001)(3846002)(54906002)(3280700002)(6306002)(8936002)(99286003)(55016002)(53936002)(33656002)(2906002)(229853002)(74316002)(25786009)(8676002)(305945005)(7736002)(3660700001)(9686003)(81166006)(189998001)(2950100002)(53546010)(81156014)(2900100001)(86362001)(4326008)(14454004)(54356999)(97736004)(5660300001)(7696004)(76176999)(50986999)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB0888; H:DB5PR07MB1574.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 09:01:42.1850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0888 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec9lnkmLt6X5oAW1EkNzmUUMEy9RZISVUqFR2MiTtzllxzth o2WYUk3RooF5YYmYFjorHWa6GVazFAmUPqi4qZhJUUJqpu3sTOjb7/k//+fyPrwMKS2nfZk0 dQ6rUStVMpEn9Sjh1Z7g4uPmxJAmPSiWzWukolS3QClu1pgJRclSJxVFxRiNy0TMj3ad6Cxx 0TM8mVWl5bGa/RFXPFN7PpqIbIO4YF2/RGvRoEcZYhjAh2BwXlKGPBkp7kdwb6wBCcE7BDMT ixQfUPguCbqVOVLIPCDg5eioO7Aj+Fvxy9lLzIicveZm7xA8e+EwKO3tIvgZJC6G6bcHeXkr jobP9xc8BMtRqPy+TvMWLxwKTwfEvExhfzDXaCmeJfgSvBnopHmW4iPQYDMgnsU4HBorbS5G eBv8/tDimkpiH/jiqHUxYAzG7iFSYG+Ys6/RAu+C4WaD27MDRmrLXS8GfNsDhqvb3Ak5vKhY QMKJYqHmWYHgmSJg5WG52xMIE7estLBEEuh/tok29NJ+AyHUZoDV4S/UWmn41mN099wOT1pP 6VGw4b+1BZbDWHWVSOAgaKyfJw2uU2yB948cVB2impE3x3JcZkpoqJzVpF3luCy1XM3mtCPn F+nr+BPWifpmoy0IM0i2SRIiNydKaWUeV5hpQcCQMi+JX7RTkiQrC4tYTVaSJlfFchbkx1Ay H0lUz3CCFKcoc9gMls1mNRtZghH7ahFnthlnG1WP95IzTEeJXxEdUrj8WuITUNeSv3MyHc08 j3DMJ8bnd9X33zgddsZ0TXY4yRpX2Rq7OX4qsm+IsIynpKtX689fz923tPz1xOLkySllUFWX rrt8sSngU5lNax+NHG8t8Is7d8yUlXw5zrF7tZe4kJ04PZIaa7KjEquM4lKVBwJJDaf8B7Mf UGEeAwAA Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 09:01:55 -0000 Hi, As contributor and as implementer, we have verified the effectiveness of th= e definition also in ACTN context, I've reviewed this document and believe it is ready for publication. Ciao, Carlo. -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: venerd=EC 1 settembre 2017 23:09 To: TEAS WG Cc: TEAS WG Chairs ; draft-ietf-teas-yang-te-topo@iet= f.org Subject: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 All, This starts a *three* week working group last call on draft-ietf-teas-yang-= te-topo-12. This last call is extended due to the size of the document and= it being the first YANG model going to LC within the group The working group last call ends on September 22. Please send your comments to the TEAS mailing list. Positive comments, e.g., "I've reviewed this document and believe it is rea= dy for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Sep 18 13:27:54 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B22BE132D42; Mon, 18 Sep 2017 13:27:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-teas-gmpls-scsi@ietf.org, Vishnu Beeram , teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150576646868.15584.11432199622698676570.idtracker@ietfa.amsl.com> Date: Mon, 18 Sep 2017 13:27:48 -0700 Archived-At: Subject: [Teas] Suresh Krishnan's No Objection on draft-ietf-teas-gmpls-scsi-04: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:27:49 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-teas-gmpls-scsi-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Tue Sep 19 07:53:32 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C64134346; Tue, 19 Sep 2017 07:53:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org, teas-chairs@ietf.org, vbeeram@juniper.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150583280387.11865.12441394410763469646.idtracker@ietfa.amsl.com> Date: Tue, 19 Sep 2017 07:53:23 -0700 Archived-At: Subject: [Teas] Alia Atlas' No Objection on draft-ietf-teas-gmpls-lsp-fastreroute-12: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 14:53:24 -0000 Alia Atlas has entered the following ballot position for draft-ietf-teas-gmpls-lsp-fastreroute-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss concerns. From nobody Tue Sep 19 10:47:56 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 770E4133085; Tue, 19 Sep 2017 10:47:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: Cc: draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf@ietf.org, teas@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150584327542.11740.11895948759881365271@ietfa.amsl.com> Date: Tue, 19 Sep 2017 10:47:55 -0700 Archived-At: Subject: [Teas] Opsdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 17:47:55 -0000 Reviewer: Dan Romascanu Review result: Has Issues This document describes two techniques that improve the scale of deployment of RSVP-TE LSPs. Here are a few issues operations related issues that I recommend to address: 1. The document is titled 'Implementation Recommendations'. As such an RFC 5706 review does not apply. Yet, it aims Standards Track status, and includes a number of protocol extensions and registry definitions. The document mixes protocol extensions, implementation recommendations and recommendations of configuration in deployment. Maybe the title does not really reflect the current content? 2. Section 2.1 includes a number of " RFC2961 Specific" Recommendations. However, it is not clear why these are recommendations. For example, reading RFC 2961, nothing indicates that support for RSVP Refresh Overhead Reduction extensions or the receipt of any RSVP Refresh Overhead Reduction message (as specified in Section 2 of RFC2961) are optional. Moreover, RFC 2961 is also Standards Track. So why do we need 'recommendations' to support sections of a standards-track document? Would not just mentioning RFC 2961 compliance be sufficient? 3. From an operational point of view it is unclear how the recommendations to set the default periodic retransmission interval defined in section 2.1.3 and the configurable refresh interval and the configurable node hello interval defined in section 2.2 are supposed to be implemented. Is this a one time initialization required for every capable node? If so, the capability needs to be confirmed before the re-configuration. This needs to be done for every node? How, if scale is a concern? From nobody Wed Sep 20 13:41:38 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B1F1320B5; Wed, 20 Sep 2017 13:41:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-teas-gmpls-lsp-fastreroute@ietf.org, db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <150594008268.28944.3163465020056121360.idtracker@ietfa.amsl.com> Date: Wed, 20 Sep 2017 13:41:22 -0700 Archived-At: Subject: [Teas] Protocol Action: 'Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs' to Proposed Standard (draft-ietf-teas-gmpls-lsp-fastreroute-12.txt) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 20:41:23 -0000 The IESG has approved the following document: - 'Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs' (draft-ietf-teas-gmpls-lsp-fastreroute-12.txt) as Proposed Standard This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-lsp-fastreroute/ Technical Summary This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling extensions allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these extensions enable the re-direction of bidirectional traffic onto bypass tunnels that ensure co-routedness of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in control-plane. Working Group Summary This document moved from the CCAMP WG to TEAS WG as part of the routing WG changes. There was some serious debate regarding the object-format/procedures defined for co-ordinating bidirectional bypass tunnel assignment between the downstream and upstream PLRs. All concerns raised in regard to this have been addressed by the authors. The document went through three WG Last Calls before being deemed “publication-request” ready as substantial comments were raised during the first and second Last Calls. Document Quality The base (G)MPLS RSVP protocol has been implemented. The procedures discussed in this document are compatible with earlier implementations. While there have been no public statements on implementation, the authors are from multiple vendors, and implementation is expected. Personnel Who is the Document Shepherd for this document? Vishnu Pavan Beeram Who is the Responsible Area Director? Deborah Brungard From nobody Wed Sep 20 23:27:24 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D87D1321A6; Wed, 20 Sep 2017 23:27:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150597523137.24776.3598419805081836880@ietfa.amsl.com> Date: Wed, 20 Sep 2017 23:27:11 -0700 Archived-At: Subject: [Teas] Secdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 06:27:12 -0000 Reviewer: Liang Xia Review result: Ready It's in good shape and well written, and does not introduce any new security issues. Following the security design of RSVP (-TE) is just ok! From nobody Thu Sep 21 06:56:43 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755661321C7; Thu, 21 Sep 2017 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 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 7C7p5b26d5mt; Thu, 21 Sep 2017 06:56:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4432C13420F; Thu, 21 Sep 2017 06:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2198; q=dns/txt; s=iport; t=1506002199; x=1507211799; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=XQETV9g1/OgHt1rPyms8hljSZU3KAw8fBwW3e/WBaDk=; b=cU7BJ83L6KENNCQI0MxGwPBvOtcuuS5dSk2EEbgBfHF3UuWlvjy/retu XRaeyH1jQgEvpyhHKOfbm0dKdunj2bGBT5hqL94K5DIoMOusE8ZYWh2pA hKmavQMPl+uqE3nHSW5Ca0WT2T427HDjBD5Cfd1U8h2WDJtNepuPQaORB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AQDPw8NZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg2+aGoFSIpg8ChgLhRgCGoN5VwECAQEBAQECayiFGAE?= =?us-ascii?q?BAQEDAQEhEToLDAYBCA4DAwECAwImAgQlCxUICgQBDQWKMxCnJ4Inin8BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYEOgh2CAoFRgWQrC4JyhHuDEy+CMQWhEwKUVoI?= =?us-ascii?q?ThWuLAJURAhEZAYE4AVeBDXcVSRIBhwl2iC+BEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,425,1500940800"; d="scan'208";a="6189965" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Sep 2017 13:56:38 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8LDucON008714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Sep 2017 13:56:38 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 21 Sep 2017 08:56:37 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1263.000; Thu, 21 Sep 2017 08:56:37 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTMuFxZGVTthNdA0+owPCz3ihvfQ== Date: Thu, 21 Sep 2017 13:56:37 +0000 Message-ID: <402EFF0B-0D44-4398-9D67-49193BAAB0F0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.240.238] Content-Type: text/plain; charset="utf-8" Content-ID: <6563E6FFE24A3F47ABFB504E7AEE345C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 13:56:41 -0000 SGkgV0csIENoYWlycywNCiAgICANCkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVs aWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uIFRoYW5rcyB0byB0aGUgYXV0aG9ycyBm b3IgdGhlIGdyZWF0IHdvcmsuDQogICAgDQpUaGFua3MsDQpSYWtlc2gNCg0KICAgICAgIA0KICAg IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogTG91IEJlcmdlciA8bGJlcmdl ckBsYWJuLm5ldD4NCiAgICBEYXRlOiBGcmlkYXksIFNlcHRlbWJlciAxLCAyMDE3IGF0IDU6MDgg UE0NCiAgICBUbzogVEVBUyBXRyA8dGVhc0BpZXRmLm9yZz4NCiAgICBDYzogVEVBUyBXRyBDaGFp cnMgPHRlYXMtY2hhaXJzQGlldGYub3JnPiwgImRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG9A aWV0Zi5vcmciIDxkcmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvQGlldGYub3JnPg0KICAgIFN1 YmplY3Q6IFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wby0xMg0KICAg IFJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NCiAgICBSZXNlbnQtVG86IDx4 dWZlbmdfbGl1QGphYmlsLmNvbT4sIDxpZ29yLmJyeXNraW5AaHVhd2VpLmNvbT4sIDx2YmVlcmFt QGp1bmlwZXIubmV0PiwgVGFyZWsgU2FhZCA8dHNhYWRAY2lzY28uY29tPiwgPGhzaGFoQGNpZW5h LmNvbT4sIDxvc2Nhci5nb256YWxlemRlZGlvc0B0ZWxlZm9uaWNhLmNvbT4NCiAgICBSZXNlbnQt RGF0ZTogRnJpZGF5LCBTZXB0ZW1iZXIgMSwgMjAxNyBhdCA1OjA4IFBNDQogICAgDQogICAgICAg IEFsbCwNCiAgICAgICAgDQogICAgICAgIFRoaXMgc3RhcnRzIGEgKnRocmVlKiB3ZWVrIHdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQogICAgICAgIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRv cG8tMTIuICBUaGlzIGxhc3QgY2FsbCBpcw0KICAgICAgICBleHRlbmRlZCBkdWUgdG8gdGhlIHNp emUgb2YgdGhlIGRvY3VtZW50IGFuZCBpdCBiZWluZyB0aGUNCiAgICAgICAgZmlyc3QgWUFORyBt b2RlbCBnb2luZyB0byBMQyB3aXRoaW4gdGhlIGdyb3VwDQogICAgICAgIA0KICAgICAgICBUaGUg d29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBTZXB0ZW1iZXIgMjIuDQogICAgICAgIFBs ZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIFRFQVMgbWFpbGluZyBsaXN0Lg0KICAgICAg ICANCiAgICAgICAgUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYW5kDQogICAgICAgIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u IiwgYXJlIHdlbGNvbWUhDQogICAgICAgIFRoaXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2 ZW4gZnJvbSBhdXRob3JzLg0KICAgICAgICANCiAgICAgICAgVGhhbmsgeW91LA0KICAgICAgICBU RUFTIENoYWlycw0KICAgICAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRlYXMgbWFpbGluZyBsaXN0DQogICAgVGVhc0Bp ZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0K ICAgIA0KDQo= From nobody Fri Sep 22 00:29:25 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418511342AC; Fri, 22 Sep 2017 00:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg4iL6aOwDDB; Fri, 22 Sep 2017 00:29:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE85133187; Fri, 22 Sep 2017 00:29:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPB94149; Fri, 22 Sep 2017 07:29:05 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by LHREML713-CAH.china.huawei.com ([10.201.108.36]) with mapi id 14.03.0301.000; Fri, 22 Sep 2017 08:28:58 +0100 From: Italo Busi To: Lou Berger , TEAS WG CC: TEAS WG Chairs , "draft-ietf-teas-yang-te-topo@ietf.org" Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTJB3AsIz8WpltHEW6GwnSZz6bSqLAoAvQ Date: Fri, 22 Sep 2017 07:28:58 +0000 Message-ID: <91E3A1BD737FDF4FA14118387FF6766B157A344C@lhreml504-mbs> References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.144.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010206.59C4BBC1.0036, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a09e35df40322fbf0f147a4620eb5186 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 07:29:23 -0000 SGkgVEVBUyBjaGFpcnMsDQoNCkFzIGEgY29udHJpYnV0b3IgSSBoYXZlIHJldmlld2VkIHRoZSBk cmFmdCBhbmQgSSB0aGluayBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNClRoYW5rcywg SXRhbG8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21h aWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANClNlbnQ6IHZlbmVyZMOsIDEgc2V0dGVtYnJlIDIwMTcg MjM6MDkNClRvOiBURUFTIFdHDQpDYzogVEVBUyBXRyBDaGFpcnM7IGRyYWZ0LWlldGYtdGVhcy15 YW5nLXRlLXRvcG9AaWV0Zi5vcmcNClN1YmplY3Q6IFtUZWFzXSBXRyBMYXN0IENhbGw6IGRyYWZ0 LWlldGYtdGVhcy15YW5nLXRlLXRvcG8tMTINCg0KQWxsLA0KDQpUaGlzIHN0YXJ0cyBhICp0aHJl ZSogd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10 ZS10b3BvLTEyLiAgVGhpcyBsYXN0IGNhbGwgaXMgZXh0ZW5kZWQgZHVlIHRvIHRoZSBzaXplIG9m IHRoZSBkb2N1bWVudCBhbmQgaXQgYmVpbmcgdGhlIGZpcnN0IFlBTkcgbW9kZWwgZ29pbmcgdG8g TEMgd2l0aGluIHRoZSBncm91cA0KDQpUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBv biBTZXB0ZW1iZXIgMjIuDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBURUFTIG1h aWxpbmcgbGlzdC4NCg0KUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJl IHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9y cy4NCg0KVGhhbmsgeW91LA0KVEVBUyBDaGFpcnMNCg0KDQo= From nobody Fri Sep 22 00:35:30 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA461342C0; Fri, 22 Sep 2017 00:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNlj5MdyGFAW; Fri, 22 Sep 2017 00:35:18 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DCD133187; Fri, 22 Sep 2017 00:35:15 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id d16so1199533ioj.3; Fri, 22 Sep 2017 00:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BJ0YYR+WEEEJsm+umOdqMMGTEPuF1PQJ3/yvwdT6bCo=; b=PQMb9FT6/5SGczbTU1EPUosQnrDc7WFA7E3wwvjFRvxl8gyAVCoCL8zxSSyMJZAa2t UjzrJFVGEStqNwUtGaqkioBVRcGaXS+DyLjINXCRg4gnIiK4mblaONFQYvDcMZkhS6KE ES0LXiN7A3yFUjEKHr9gWaXE6LYJyFNJgqRFLg7fGEfutb05A3WkzGNJe9tWgycJTM82 9GSPzbkETGuo3tJ32NSbHRIubddr2N0OHDpvsS97Y6pfFR1JXUq3E+oxzB9kZLGk4YY9 zd6TQ/y23mNrQK9CVtnVB7c1teuPEKoZwZx+GmUu5lksAiCrjbeU0VyrE4dHmmSpT7uJ 4Qdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BJ0YYR+WEEEJsm+umOdqMMGTEPuF1PQJ3/yvwdT6bCo=; b=XlJIgN+TdOAlsPrxvLyu4tb3tJUpvhs2yeTEFDCaLsRt5lKGSstp55dkL7fNtcY0RS dK+M8lM9IxiBDohWbnT7VlnWSZJuVEMmsWkPFyMdJrozMwwFrUnKm2Q4zEyGJKt3CakJ CqjHkIOTWgBkB6ubRmP76EXISmeld3AIA3O3dmmQmSnnYNy0b8dc1HkzhbW32PEWgdzq xQA3XQj3hLeikigm9gbWpp6iAZ5buIxEsLTQl+zlC77Nf6oBY3hTJqU0fKjeYE48ikcO Me36ln67SmcdATt49E/eX9mK6S0NV0f5l3snIhMjxCxQ5EqAv8NLQFTPY8BQismk69oN Hm7g== X-Gm-Message-State: AHPjjUgC5yEGPqgeMW9kz9A1GYmlU0thLzHoBNF5m68ZaLzeWIYBEJI1 wqiFlgkWUzNd0CK10cYrjKxOTM+XeaBKLdOc6pU= X-Google-Smtp-Source: AOwi7QCKWdNKsdKoLn7VPiSwg9Y3K/YKfrA7RaDvlAe9RLlBS5l9ytTTuZC7QOj+fb1nrtYLcP1eAgonmkuS3xAHymo= X-Received: by 10.107.149.143 with SMTP id x137mr6883847iod.266.1506065714536; Fri, 22 Sep 2017 00:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Fri, 22 Sep 2017 00:35:13 -0700 (PDT) In-Reply-To: <150584327542.11740.11895948759881365271@ietfa.amsl.com> References: <150584327542.11740.11895948759881365271@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Fri, 22 Sep 2017 03:35:13 -0400 Message-ID: To: Dan Romascanu Cc: ops-dir@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf@ietf.org, "teas@ietf.org" Content-Type: multipart/alternative; boundary="001a1140fe74ec6cc20559c23f72" Archived-At: Subject: Re: [Teas] Opsdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 07:35:20 -0000 --001a1140fe74ec6cc20559c23f72 Content-Type: text/plain; charset="UTF-8" Dan, Hi! Thanks for the review! Please see inline for your responses and let us know if they address your concerns. Regards, -Pavan On Tue, Sep 19, 2017 at 1:47 PM, Dan Romascanu wrote: > Reviewer: Dan Romascanu > Review result: Has Issues > > This document describes two techniques that improve the scale of > deployment of > RSVP-TE LSPs. Here are a few issues operations related issues that I > recommend > to address: > > 1. The document is titled 'Implementation Recommendations'. As such an RFC > 5706 > review does not apply. Yet, it aims Standards Track status, and includes a > number of protocol extensions and registry definitions. The document mixes > protocol extensions, implementation recommendations and recommendations of > configuration in deployment. Maybe the title does not really reflect the > current content? > [VPB] Fair point. We'll go ahead and change the title to "Techniques to Improve the Scalability of RSVP-TE Deployments". Would this take care of addressing your concern? > 2. Section 2.1 includes a number of " RFC2961 Specific" Recommendations. > However, it is not clear why these are recommendations. For example, > reading > RFC 2961, nothing indicates that support for RSVP Refresh Overhead > Reduction > extensions or the receipt of any RSVP Refresh Overhead Reduction message > (as > specified in Section 2 of RFC2961) are optional. Moreover, RFC 2961 is also > Standards Track. So why do we need 'recommendations' to support sections > of a > standards-track document? Would not just mentioning RFC 2961 compliance be > sufficient? > [VPB] The flag that indicates "support of 2961" has always been a little vague in terms of what recommendations are mandatory and what are not, resulting in different types of implementation behaviors. The text in Section 2.1 was added to make sure that there is no room for such ambiguities. The discussion in the WG that resulted in this text is captured in the following thread: https://mailarchive.ietf.org/arch/msg/teas/FMGd8Q5mLUA2d3L2jD7bbid2atc > 3. From an operational point of view it is unclear how the recommendations > to > set the default periodic retransmission interval defined in section 2.1.3 > and > the configurable refresh interval and the configurable node hello interval > defined in section 2.2 are supposed to be implemented. Is this a one time > initialization required for every capable node? If so, the capability > needs to > be confirmed before the re-configuration. This needs to be done for every > node? > How, if scale is a concern? > > [VPB] The expectation is that the node comes up with the new recommended default values after an upgrade to a version that supports this draft. Upgrades can be incremental -- not all nodes in the network need to be upgraded at the same time (the procedures in this draft are fully backwards compatible). > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a1140fe74ec6cc20559c23f72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dan, Hi!

Thanks for the r= eview!
Please see inline for your responses and let us know if the= y address your concerns.

Regards,
-Pavan

=

On Tue, Sep 19, 2017 at 1:47 PM, Dan Romascanu <dromasca@gmail.com= > wrote:
Rev= iewer: Dan Romascanu
Review result: Has Issues

This document describes two techniques that improve the scale of deployment= of
RSVP-TE LSPs. Here are a few issues operations related issues that I recomm= end
to address:

1. The document is titled 'Implementation Recommendations'. As such= an RFC 5706
review does not apply. Yet, it aims Standards Track status, and includes a<= br> number of protocol extensions and registry definitions.=C2=A0 The document = mixes
protocol extensions, implementation recommendations and recommendations of<= br> configuration in deployment. Maybe the title does not really reflect the current content?

[VPB] Fair point. We&#= 39;ll go ahead and change the title to "Techniques to Improve the Scal= ability of RSVP-TE Deployments". Would this take care of addressing yo= ur concern?


2. Section 2.1 includes a number of " RFC2961 Specific" Recommend= ations.
However, it is not clear why these are recommendations. For example, readin= g
RFC 2961, nothing indicates that support for RSVP Refresh Overhead Reductio= n
extensions=C2=A0 or the receipt of any RSVP Refresh Overhead Reduction=C2= =A0 message (as
specified in Section 2 of RFC2961) are optional. Moreover, RFC 2961 is also=
Standards Track. So why do we need 'recommendations' to support sec= tions of a
standards-track document? Would not just mentioning RFC 2961 compliance be<= br> sufficient?

[VPB] The flag that indicat= es "support of 2961" has always been a little vague in terms of w= hat recommendations are mandatory and what are not, resulting in different = types of implementation behaviors. The text in Section 2.1 was added to mak= e sure that there is no room for such ambiguities. The discussion in the WG= that resulted in this text is captured in the following thread:
<= div>https://mailarchive.ietf.org/arch/msg/teas/FMGd8Q5mLUA2d3L2jD7b= bid2atc


3. From an operational point of view it is unclear how the recommendations = to
set the default periodic retransmission interval defined in section 2.1.3 a= nd
the configurable refresh interval and the configurable node hello interval<= br> defined in section 2.2 are supposed to be implemented. Is this a one time initialization required for every capable node? If so, the capability needs= to
be confirmed before the re-configuration. This needs to be done for every n= ode?
How, if scale is a concern?


[VPB] The expectation is that the node= comes up with the new recommended default values after an upgrade to a ver= sion that supports this draft. Upgrades can be incremental -- not all nodes= in the network need to be upgraded at the same time (the procedures in thi= s draft are fully backwards compatible).
=C2=A0
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

--001a1140fe74ec6cc20559c23f72-- From nobody Fri Sep 22 02:47:44 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB561342D8; Fri, 22 Sep 2017 02:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjExi0R_tfVH; Fri, 22 Sep 2017 02:47:40 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0120.outbound.protection.outlook.com [104.47.1.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC969133229; Fri, 22 Sep 2017 02:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9RZYXXI4aWbOdc3dHYwDfOb9hr8zgoG4kzxs+7HXsj4=; b=T8baY7i54zLnt29070CChmqTleLRwA8WP3KfuDZcPLmiSXRT3v+qsf/LvnKBFWOWjlsTuvReB6ljA6sCeXXAkkXcDsXD8XvnCEtji7shZnkblaTrGPQw4Rx69DmLpz/unQX3z4y0wZJFUJNAPOg64gOewRrmcjKo6i+ts2QkqtA= Received: from DB3PR07MB0588.eurprd07.prod.outlook.com (10.160.46.139) by DB3PR07MB0586.eurprd07.prod.outlook.com (10.160.46.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 22 Sep 2017 09:47:31 +0000 Received: from DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::1871:c2c4:7a99:37d]) by DB3PR07MB0588.eurprd07.prod.outlook.com ([fe80::1871:c2c4:7a99:37d%16]) with mapi id 15.20.0077.011; Fri, 22 Sep 2017 09:47:31 +0000 From: "Belotti, Sergio (Nokia - IT/Vimercate)" To: Lou Berger , TEAS WG Chairs CC: "draft-ietf-teas-yang-te-topo@ietf.org" , TEAS WG Thread-Topic: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 Thread-Index: AQHTI2aBj+p3sRW3sEiFz1Z2sWTSZqLAx9yw Date: Fri, 22 Sep 2017 09:47:31 +0000 Message-ID: References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.212.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0586; 6:JhOS1NDKTjXbe2QpNIz3kxhopZlCAC59BXXGF3vqzSkcWX3NznW9MNx3mNp/DE00KY/VY5tGD21i2afjxD+1ka5jArFWD6n4uG5+4ux0EZyQcGUumUlCh2el92vZj6s2DfXynFCF1tC91tyH2yWMAxk5aaF5Fi5I2jMEwA8hTliixNso92jfFdf7Cs+yR7d7nyfNnMXT85kb4nNl5lMqmxkahXX7zpLeqGnUdxU1DVlDibm6pUgOSJY155E+UZE9k/td8ry4eRLX+hrlKTWOMzqGURnm/jXpNxgP9imky37ZIzIOPzKqnNYjrG00WrMntviF70IppSt8uFiyBDiXRw==; 5:6/3zBSxaofD92twpWjOu75drYfKVbAin9+XM+eIZtc552QROcBhpUzuN4nO/fuRdWmWW94vnGPcwvXnGi6ndYLtGxGC4UIG6PP7dr6U0y9JPIy/peJZZxffhNk7Hm/2liq9dy41vzbXButxDIlwsxw==; 24:kirwEQ1rQQviecLdS2qKp+TmkghyrXpBOnUZnGFoqvAjIfBWkjBBD6WZK6mLqMSpReHB//nBE6ph01xQODJBochERZqibo5wKtVBgPEJPmA=; 7:EqWgY/eZIXPZ6S4ym7zUQvdl7zzI/ihOHONsADTyRZwJ2K0QkE126N3Qpu0QateWqrOKelxKavqCBsSqBHrm5yfVkpO3m4IpLbsdbMaE02vOCRAwpJsgDvKDagBxw7HdFBqmLadCbjZBD3gSH1ehgAY1waG/tK5kR24IFYc3D6KhuZZBnQlq9+hJh4k0rVW6jjwGHV5MDraV8IT3V2ZD7sA6VhuHB91odUNjD/69t4M= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 91bd79d5-58ff-44bb-9410-08d5019ef207 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB3PR07MB0586; x-ms-traffictypediagnostic: DB3PR07MB0586: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB3PR07MB0586; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB3PR07MB0586; x-forefront-prvs: 0438F90F17 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(346002)(376002)(189002)(377454003)(13464003)(199003)(105586002)(106356001)(316002)(478600001)(2900100001)(97736004)(6506006)(189998001)(8936002)(6116002)(229853002)(102836003)(14454004)(9686003)(55016002)(6246003)(3846002)(110136005)(7736002)(54906003)(4326008)(6306002)(6436002)(305945005)(99286003)(966005)(53936002)(53546010)(74316002)(86362001)(54356999)(2950100002)(68736007)(25786009)(76176999)(50986999)(101416001)(5660300001)(3660700001)(3280700002)(2906002)(7696004)(33656002)(66066001)(81166006)(81156014)(8676002)(230783001)(5250100002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0586; H:DB3PR07MB0588.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2017 09:47:31.7961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0586 Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 09:47:43 -0000 Hello "TEAS Chairs" , As contributor of this draft, I've reviewed this document and believe it is= ready for publication. Thanks Sergio -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, September 01, 2017 11:09 PM To: TEAS WG Cc: TEAS WG Chairs ; draft-ietf-teas-yang-te-topo@iet= f.org Subject: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 All, This starts a *three* week working group last call on draft-ietf-teas-yang-= te-topo-12. This last call is extended due to the size of the document and= it being the first YANG model going to LC within the group The working group last call ends on September 22. Please send your comments to the TEAS mailing list. Positive comments, e.g., "I've reviewed this document and believe it is rea= dy for publication", are welcome! This is useful and important, even from authors. Thank you, TEAS Chairs _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri Sep 22 05:32:49 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7022134338; Fri, 22 Sep 2017 05:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XZC2AiKnP4J; Fri, 22 Sep 2017 05:32:29 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49370134337; Fri, 22 Sep 2017 05:32:29 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id z143so844598qkb.3; Fri, 22 Sep 2017 05:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gsJFBbkGu/fJyaVxhptJfBWe9gWnhTaAFlgQNZkNktw=; b=dwIEnUN0qVy0IND9T0PBbOvcnXVhSGavXaFimRnDrHAEPlqo5/bfWrxjKyG/PJ86HW fJAvC9XPSliLxvCMAwHvUODs2Moide9mw03Ks0uAkXmZPLnPt2+FH/UcZyaBwGhLbx/U cX/WNn9Kp7dsOPdkr3oq0lcVpyaOl8hPfxcxEIy5EFCtvFgwB+51yGdxYXhD6fIW0o5U b1/i8nSX/PgFukvccZejUUtNWutllPls1aT0tV8EP91INhvK362se/9OzVYXBG5WdBS2 ypFkobu/Z9czNCO+Ujr9b00HpY+SZUHsM5HOZ2FQuZB2jaU6Svt1RZmroc1d2YYpteEl KWUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gsJFBbkGu/fJyaVxhptJfBWe9gWnhTaAFlgQNZkNktw=; b=jG8O16NNmbH67hKDvgPRodTc3sDaOQ/FYU4Bo53iWiHHnmKcutF87sY8jadvPm17BK r7iVAm2SGXmDCN8XoKhQBtkd+Qh+mMmoAxPrPLPgcZmXxZx6wABpo+UfJfx/LmryUB2g LiTaaDobzEHWAaJG6smiDpbIdZG0eViUW9FwtoKwdO/9mcAG4XqRELTP1zOeezU2FNFJ DuGrD0A/uNAv13R38dnM+YcvrUIr/wLEee1jDIwrWfqQYzFWfQ7ME87XuS5SB3AbHUT4 kz5jlB0PxE7GsESDotGq6h/McdYvH3+Vm7xybMwXymMZBxHTZlWyM5tX2f+wBUW+t6yk Q5pg== X-Gm-Message-State: AHPjjUgpDw4/tEZ0jWbpo9V8N1iZOcaSSH6GVPMCIvjkzge57MfNxZ9F eOd5nauSeabcC0hADZmcqv9C21sYWFEQwGZJ1FE= X-Google-Smtp-Source: AOwi7QDFVY/iWRRep0it5jksiQ5tUsClbTZsUwcFw1ozBUzx+mdFMGR9bNUhDg+nQ4PyP6FElnSWxjv6w8zo6OqnG1E= X-Received: by 10.55.121.7 with SMTP id u7mr7628652qkc.130.1506083548369; Fri, 22 Sep 2017 05:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.35.242 with HTTP; Fri, 22 Sep 2017 05:32:27 -0700 (PDT) In-Reply-To: References: <150584327542.11740.11895948759881365271@ietfa.amsl.com> From: Dan Romascanu Date: Fri, 22 Sep 2017 15:32:27 +0300 Message-ID: To: Vishnu Pavan Beeram Cc: ops-dir@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf , "teas@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05f74ce719550559c6665d" Archived-At: Subject: Re: [Teas] Opsdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:32:32 -0000 --94eb2c05f74ce719550559c6665d Content-Type: text/plain; charset="UTF-8" Hi Pavan, Thank you for your answer and for addressing my concerns. See in-line. Regards, Dan On Fri, Sep 22, 2017 at 10:35 AM, Vishnu Pavan Beeram wrote: > Dan, Hi! > > Thanks for the review! > Please see inline for your responses and let us know if they address your > concerns. > > Regards, > -Pavan > > > On Tue, Sep 19, 2017 at 1:47 PM, Dan Romascanu wrote: > >> Reviewer: Dan Romascanu >> Review result: Has Issues >> >> This document describes two techniques that improve the scale of >> deployment of >> RSVP-TE LSPs. Here are a few issues operations related issues that I >> recommend >> to address: >> >> 1. The document is titled 'Implementation Recommendations'. As such an >> RFC 5706 >> review does not apply. Yet, it aims Standards Track status, and includes a >> number of protocol extensions and registry definitions. The document >> mixes >> protocol extensions, implementation recommendations and recommendations of >> configuration in deployment. Maybe the title does not really reflect the >> current content? >> > > [VPB] Fair point. We'll go ahead and change the title to "Techniques to > Improve the Scalability of RSVP-TE Deployments". Would this take care of > addressing your concern? > Yes, this would be more clear. Thanks. > >> 2. Section 2.1 includes a number of " RFC2961 Specific" Recommendations. >> However, it is not clear why these are recommendations. For example, >> reading >> RFC 2961, nothing indicates that support for RSVP Refresh Overhead >> Reduction >> extensions or the receipt of any RSVP Refresh Overhead Reduction >> message (as >> specified in Section 2 of RFC2961) are optional. Moreover, RFC 2961 is >> also >> Standards Track. So why do we need 'recommendations' to support sections >> of a >> standards-track document? Would not just mentioning RFC 2961 compliance be >> sufficient? >> > > [VPB] The flag that indicates "support of 2961" has always been a little > vague in terms of what recommendations are mandatory and what are not, > resulting in different types of implementation behaviors. The text in > Section 2.1 was added to make sure that there is no room for such > ambiguities. The discussion in the WG that resulted in this text is > captured in the following thread: > https://mailarchive.ietf.org/arch/msg/teas/FMGd8Q5mLUA2d3L2jD7bbid2atc > Makes sense. Maybe a sentence in the Introduction on tle lines of 'support of 2961 has always been vague, and this document aims bringing the needed clarifications for implementation and deployment' would be useful. > > >> 3. From an operational point of view it is unclear how the >> recommendations to >> set the default periodic retransmission interval defined in section 2.1.3 >> and >> the configurable refresh interval and the configurable node hello interval >> defined in section 2.2 are supposed to be implemented. Is this a one time >> initialization required for every capable node? If so, the capability >> needs to >> be confirmed before the re-configuration. This needs to be done for every >> node? >> How, if scale is a concern? >> >> > [VPB] The expectation is that the node comes up with the new recommended > default values after an upgrade to a version that supports this draft. > Upgrades can be incremental -- not all nodes in the network need to be > upgraded at the same time (the procedures in this draft are fully backwards > compatible). > This is fine. A paragraph that clarifies this on the lines of your second sentence would help. > >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > > --94eb2c05f74ce719550559c6665d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pavan,

Thank you for y= our answer and for addressing my concerns.

See in-line.
<= br>
Regards,

Dan


On Fri, Sep 22, 2017 at 10:35 AM, Vishnu Pavan Bee= ram <vishnupavan@gmail.com> wrote:
Dan, Hi!

T= hanks for the review!
Please see inline for your responses and let= us know if they address your concerns.

Regards,
-Pav= an


On Tue, Sep 19, 2017 at 1:47 PM, Dan Rom= ascanu <dromasca@gmail.com> wrote:
Reviewer: Dan Romascanu
Review result: Has Issues

This document describes two techniques that improve the scale of deployment= of
RSVP-TE LSPs. Here are a few issues operations related issues that I recomm= end
to address:

1. The document is titled 'Implementation Recommendations'. As such= an RFC 5706
review does not apply. Yet, it aims Standards Track status, and includes a<= br> number of protocol extensions and registry definitions.=C2=A0 The document = mixes
protocol extensions, implementation recommendations and recommendations of<= br> configuration in deployment. Maybe the title does not really reflect the current content?

[VPB] Fair poin= t. We'll go ahead and change the title to "Techniques to Improve t= he Scalability of RSVP-TE Deployments". Would this take care of addres= sing your concern?

Yes, this would be more clear. Thanks.



2. Section 2.1 includes a number of " RFC2961 Specific" Recommend= ations.
However, it is not clear why these are recommendations. For example, readin= g
RFC 2961, nothing indicates that support for RSVP Refresh Overhead Reductio= n
extensions=C2=A0 or the receipt of any RSVP Refresh Overhead Reduction=C2= =A0 message (as
specified in Section 2 of RFC2961) are optional. Moreover, RFC 2961 is also=
Standards Track. So why do we need 'recommendations' to support sec= tions of a
standards-track document? Would not just mentioning RFC 2961 compliance be<= br> sufficient?

[VPB] The flag that = indicates "support of 2961" has always been a little vague in ter= ms of what recommendations are mandatory and what are not, resulting in dif= ferent types of implementation behaviors. The text in Section 2.1 was added= to make sure that there is no room for such ambiguities. The discussion in= the WG that resulted in this text is captured in the following thread:
=

Makes sense. Mayb= e a sentence in the Introduction on tle lines of 'support of 2961 has a= lways been vague, and this document aims bringing the needed clarifications= for implementation and deployment' would be useful.



3. From an operational point of view it is unclear how the recommendations = to
set the default periodic retransmission interval defined in section 2.1.3 a= nd
the configurable refresh interval and the configurable node hello interval<= br> defined in section 2.2 are supposed to be implemented. Is this a one time initialization required for every capable node? If so, the capability needs= to
be confirmed before the re-configuration. This needs to be done for every n= ode?
How, if scale is a concern?


[VPB] The expectation is that t= he node comes up with the new recommended default values after an upgrade t= o a version that supports this draft. Upgrades can be incremental -- not al= l nodes in the network need to be upgraded at the same time (the procedures= in this draft are fully backwards compatible).
=

This is fine= . A paragraph that clarifies this on the lines of your second sentence woul= d help.

=C2=A0
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


--94eb2c05f74ce719550559c6665d-- From nobody Fri Sep 22 15:01:50 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA941332DF; Fri, 22 Sep 2017 15:01:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , db3546@att.com, Vishnu Beeram , teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net, draft-ietf-teas-gmpls-scsi@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150611770866.22349.9799623608603249489.idtracker@ietfa.amsl.com> Date: Fri, 22 Sep 2017 15:01:48 -0700 Archived-At: Subject: [Teas] Protocol Action: 'Generalized Interface Switching Capability Descriptor - Switching Capability Specific Information' to Proposed Standard (draft-ietf-teas-gmpls-scsi-04.txt) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 22:01:49 -0000 The IESG has approved the following document: - 'Generalized Interface Switching Capability Descriptor - Switching Capability Specific Information' (draft-ietf-teas-gmpls-scsi-04.txt) as Proposed Standard This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-scsi/ Technical Summary This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) fields. This "Generalized SCSI" can be used with routing protocols that define GMPLS ISCDs, and any specific technology. This document does not modify an existing technology specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. Working Group Summary This document was put together to address comments that were raised during Gen-ART review for draft-ietf-ccamp-ospf-availability-extension. This document has been fairly noncontroversial. Document Quality The base (G)MPLS routing protocols have been implemented. The generic protocol format discussed in this document is compatible with earlier implementations. The first document that would be using the format defined in this document is draft-ietf-ccamp-ospf-availability-extension. While there have been no public statements on implementation, the authors of draft-ietf-ccamp-ospf-availability-extension are from multiple vendors, and implementation is expected. Personnel Who is the Document Shepherd for this document? Vishnu Pavan Beeram Who is the Responsible Area Director? Deborah Brungard From nobody Fri Sep 22 15:06:41 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32235133053; Fri, 22 Sep 2017 15:06:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Elwyn Davies To: Cc: draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150611799315.22445.6055168230107378983@ietfa.amsl.com> Date: Fri, 22 Sep 2017 15:06:33 -0700 Archived-At: Subject: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 22:06:33 -0000 Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-teas-rsvp-te-scaling-rec-06 Reviewer: Elwyn Davies Review Date: 2017-09-22 IETF LC End Date: 2017-09-22 IESG Telechat date: 2017-09-28 Summary: Not ready, primarily because the title and presentation give the impression that the content is really a BCP when it isn't. This conceals the considerable amount of tweaking of RFC 2961 functionality and addition of new RSVP Capabilities described in the document. There are also a couple of minor issues that need to be sorted out. Major issues: Title and way proposals are presented: The document defines two new 'capabilities' for RSVP-TE and is indeed (as specified in the document header) correctly intended for Standards Track status. However the title and the whole of the meat of the document in Section 2 presents the proposals as 'recommendations' which says to me that I am expecting a BCP where a profile of available options from existing standards is recommended as the best choice for implementation and deployment. In my opinion, the title would be better as something like "Additional Capabilities Designed to Improve the Scalability of RSVP-TE Deployments". Whilst the proposals are based on the techniques in RFC 2961, the document *requires* the implementor to conform to rules that were optional and constrains configurable values to different ranges in order to be able to deliver the capabilities defined in the document as well as defining new RSVP extensions modifying some of the behaviour defined in RFC 2961. Thus although some of the rules could be met by choosing particular values within the RFC 2961 set, the use of MUST, tweaking of functionality and variation of ranges takes it well beyond a set of recommendations for RFC 2961 options selections. In view of this Section 1 needs to be written as an introduction to the definitions of the new capabilities rather than advocacy for selection of RFC 2961 options and the implication that the techniques mentioned in the last paragraph of s1 are just a matter of selecting a profile of option values. In actuality new protocol values are introduced and ss2.2 and 2.3 define novel extensions to RSVP beyond what is available for RFC 2961 and requiring modification to basic RFC 2961 functionality.. Minor issues: Interaction with RFC 5063: The document does not explicitly state that an implementation would need to support (at least) the extra capability obect defined in s4.2 of RFC 5063. Some words about interaction with RFC 5063 are probably required in that s4.2.1 of RFC 5063 rather assumes that if there is a capability object, by default its S bit will be set. Behaviour if a node stops setting Refresh-Reduction-Capable bit: The last para of s2 in RFC 2961 discusses behaviour if a node stops setting this bit in messages. What would happen with the extensions defined in this document if this happened while either of the extensions is in use? As a matter of interest, if a peer offers the capabilities defined in this draft, is it possible or sensible for it to stop setting the Refresh-Reduction-Capable bit without stopping offering the extensions? s2.1.3, para 2: As specified, it appears that the 'slower timer' transmission of Path and Resv messages can go on indefinitely if no ack arrives. What puts an end to this repetition? [It may be that I have forgotten how basic RSVP works, but since this is altering the behaviour it would be good to explain how it terminates, and whether this requires any additional modification to timers.] Nits/editorial comments: Abstract: RSVP-TE is not a 'well-known' abbreviation: s/RSVP-TE/RSVP Traffic Engineering (RSVP-TE)/ Abstract and s1, first para: This para is not future proof. Suggest: OLD: The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get deployed is growing continually and there is considerable onus on RSVP-TE implementations across the board to keep up with this increasing demand in scale. NEW: At the time of writing, networks which utilise RSVP Traffic Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are encountering limitations in the ability of implementations to support the growth in the number of LSPs deployed. This document defines two additional RSVP-TE extensions that are intended to reduce the number of messages needed to maintain RSVP-TE soft state in routers and hence allow implementations to support larger scale deployments. ENDS Note: Omit reference from Abstract. s1, para 2: s/under certain/beyond a certain/ s1, para 3: s/makes a set of concrete implementation recommendations/defines two extensions/; s/- push higher/by increasing/; s/maintain LSP state./maintain LSP state by reducing the number of messages needed./ Abstract, para 2 and s1, last para: [Omit reference from Abstract] OLD: This document advocates the use of a couple of techniques - "Refresh- Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - for significantly cutting down the amount of processing cycles required to maintain LSP state. NEW: This document defines two RSVP Capabilities [RFC5063] "Refresh- Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" that will cut down the number of messsages and processing cycles required to maintain LSP state. ENDS s1, last para: Add new penultimate sentence: Note that the "Per-Peer Flow-Control" capability requires the "RI-RSVP" capability as a prerequisite. s1, last para: s/RECOMMENDED/recommended/ - this isn't a recommendation about the protocol on the wire. Subdivision of s2: The issues regarding the nature of the document would be helped by altering s2 into four top level sections, thus: s2: Requirement for RFC 2961 Refresh Overhead Reduction Support and Specific Option Choices (from s2.1) s3: Requirement for RFC 5063 Capability Object support (see Minor Issues above) s4: Refresh-Interval Independent RSVP Capability (from s2.3) s5: Per-Peer RSVP Flow Control Capability (from s2.4) Subsequent major sections then renumbered as s6 onwards. References to s2.x will need to be updated throughout. s2.1 (would be introduction of new s2): OLD: The implementation recommendations discussed in this section are based on the proposals made in [RFC2961] and act as prerequisites for implementing the techniques discussed in Sections 2.2 and 2.3. NEW: The Capabilities defined in Sections 4 and 5 of this document are based on proposals made in [RFC2961]. Implementations of these Capabilities will need to support the RSVP messages and techniques defined in [RFC2961] as set out in Section 2.1 [was 2.1.1] with some minor modifications and alterations to recommended time intervals and iteration counts as defined in the remainder of this section. ENDS s2.1.1, title and para 1 [will be s2.1]: OLD: 2.1.1. Basic Prerequisites An implementation that supports the techniques discussed in Sections 2.2 and 2.3 must meet certain basic prerequisites. NEW: 2.1. Required Functionality from RFC 2961 to be Implemented An implementation that supports the capabiities discussed in Sections 4 and 5 must provide a large subset of the functionality described in [RFC2961] as follows: ENDS s2.1.2, para 2 [will be s2.2]: s/techniques discussed in Sections 2.2 and 2.3/Capabilities defined in Sections 4 and 5/ s2.1.2, para 2: s/MESSAGE ID/MESSAGE_ID/ s2.2, para 1: s/improvement on transmission overhead/improvement of transmission overhead/ s2.2, para 1: s/proposes sufficient recommendations/sets out additional requirements/ s2.2, last bullet: Add a reference to the proposed new Section 3 that discusses the Capability object. s2.2.1, last para: s/set Refresh-Reduction-Capable bit in common header/set the Refresh-Reduction-Capable bit in the common header/ s2.3, para 1: s/set of recommendations/functionality/; s/provide/provides/; s/RSVP-TE control plane congestion/a significant portion of the RSVP-TE control message load/ s2.3.2: s/MESSAGE ID/MESSAGE_ID/ From nobody Mon Sep 25 07:27:01 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 092A7134323; Mon, 25 Sep 2017 07:26:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, Lou Berger , teas-chairs@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150634961899.27517.2676098033688714820.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 07:26:58 -0700 Archived-At: Subject: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:26:59 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) This document seems to do two things: make a series of rfc2961 recommendations, and introduce a couple of new techniques. What is not clear to me is whether the first part is independent of the second. Will the implementation of Section 2.1. ("RFC2961 Specific" Recommendations) provide scaling benefits on their own (i.e. without the new techniques)? If so, please add some text (maybe in the Introduction) to indicate that. (2) As for as the new techniques, it is confusing to me the use of rfc2119 language in Section 2.1.1. (Basic Prerequisites), which reads: An implementation that supports the techniques discussed in Sections 2.2 and 2.3 must meet certain basic prerequisites. ... o It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms... I know that the leading "must" is not an RFC2119 keyword, but it may be confusing with the "SHOULD" used later...specially because it sounds as if (in some cases) it may be ok to not "initiate all RSVP Refresh Overhead Reduction mechanisms" and still use the new mechanisms described later. What are those cases? Maybe the mandatory prerequisites should all be listed in the same sub-section, while other recommendations can be elsewhere. Note also that later in 2.2 and 2.3 the text says that an implementation "MUST support all the recommendations" in 2.1. What does that MUST mean if one of the recommendations is not an absolute requirement? (3) Section 2.1.2 (Making Acknowledgements Mandatory) seems to also be a prerequisite, right? At lease the text says that "an implementation that supports the techniques discussed in Sections 2.2 and 2.3...MUST...". The fact that it is not in the actual prerequisites section may be confusing to some. (4) Section 2.1.3. (Clarifications On Reaching Rapid Retry Limit (Rl)) is (by clarifying and using normative language) making specific changes to rfc2961. Assuming that there is value in 2.1 being used by itself (without the new techniques), why isn't there a formal Update of rfc2961? (5) This reminds me, please use the new RFC2119-related template: please take a look at rfc8174. Nits: s/interval interval/interval When defining the new capability advertisements (in 2.2.1 and 2.3.1), it would be nice to include a reference to rfc5063. Given the specification in the preceding sections, I think that 2.2.2 and 2.3.2 are superfluous. It would be nice to point at the Appendix from the main text. From nobody Mon Sep 25 23:44:56 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB42F124239; Mon, 25 Sep 2017 23:44:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, Lou Berger , teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150640829065.13776.15807950505251240274.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 23:44:50 -0700 Archived-At: Subject: [Teas] Spencer Dawkins' No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 06:44:51 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm confused by this SHOULD. The configurable periodic retransmission interval for this slower timer SHOULD be less than the regular refresh interval. Could you help me understand why someone would want to set the "slower timer" to be shorter than the regular refresh timer? From nobody Tue Sep 26 04:34:14 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AE513301B for ; Tue, 26 Sep 2017 04:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 w8CxDWWKUtm1 for ; Tue, 26 Sep 2017 04:34:10 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 A3491132F65 for ; Tue, 26 Sep 2017 04:34:10 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 4C3AD1E07D3 for ; Tue, 26 Sep 2017 05:34:10 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id EBa61w0092SSUrH01Ba9U4; Tue, 26 Sep 2017 05:34:10 -0600 X-Authority-Analysis: v=2.2 cv=K/VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=6oOWi583SLzXmj8_OnsA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=U+1avwcRh15kaDEJO0OWuYuxIIp70yelIY1UtoHV3Ho=; b=sWensr671ci1/ilnTVurPvm4YV htevCU1ciNDugMSlyAEkMlDVs/PGUt3RpN+fPjEGH18fpTBJEsZaYTTEK20xuSxNH9I6AOSvmWCf4 bBlC/W9ZtKE8lzfgOo5TgUNeB; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:49850 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dwo7q-0031Qq-0h; Tue, 26 Sep 2017 05:34:06 -0600 To: TEAS WG Cc: TEAS WG Chairs , draft-ietf-teas-yang-te-topo@ietf.org References: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> From: Lou Berger Message-ID: Date: Tue, 26 Sep 2017 07:34:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <382461e4-ad21-d103-ae3f-6f94109aa2b7@labn.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dwo7q-0031Qq-0h X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:49850 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Teas] WG Last Call: draft-ietf-teas-yang-te-topo-12 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 11:34:12 -0000 All, The WG LC is complete (at the end of last week). Authors, Please update the draft with any comments you have received during LC and let the WG know what changes have been made. Also, as Shepherd I have some very minor editorial comments that I will send to the authors off-list. Thank you! Lou On 9/1/2017 5:08 PM, Lou Berger wrote: > All, > > This starts a *three* week working group last call on > draft-ietf-teas-yang-te-topo-12. This last call is > extended due to the size of the document and it being the > first YANG model going to LC within the group > > The working group last call ends on September 22. > Please send your comments to the TEAS mailing list. > > Positive comments, e.g., "I've reviewed this document and > believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > TEAS Chairs > From nobody Tue Sep 26 09:47:51 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBEF1342EB; Tue, 26 Sep 2017 09:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkbV3Ey3Phml; Tue, 26 Sep 2017 09:47:35 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABE71342E3; Tue, 26 Sep 2017 09:47:35 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id d16so13352528ioj.3; Tue, 26 Sep 2017 09:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UHiL0MfWfVgSsc/IXjvz1r02ZJa6fqvSz//xWNtKL/0=; b=WEvf2V9Quokgsxs8yp6soznItq53OvCY/GPtlnOUBqepIvVsIA0hNbbwXbsTzLasM8 SGUakarhfZszuLGakfJGlapSDY4exl5hiAdF4Blx3OZtj1ZCl0BXnuv6LDjMNFqDOcID BkCOvZIMv3pEqyX+J7/CCIEU33KKudZ4EgxclkFa7TAEM72RQ8+Nm/GRbBzQAejWnJAa CLi6U268xk83pmKl09sOd2llWCMHwyorx+5coh3j7jfW5LrbWjcAN+HKGlQ//e9UJReQ 3FgAbOL/75zjL/zdi3Y5jY1ANt5yEu6STk8vIpjHt1b0lHdkH06PJbgsYhw6GNMfjdBQ 8DoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UHiL0MfWfVgSsc/IXjvz1r02ZJa6fqvSz//xWNtKL/0=; b=U5BKV2OUvUPc06UwEpl1oBbtsk4fqH2oZPpPzs+s2zJmqo9fsm7NPJmAkXPjgj5Uh8 Eqz1f4mmD4UrwG6Arrd+M62TclCb2PjOJ1Gak+JpQ2Fuolx4uyO4GLTLDcJVny18OPKL 7QKYi1oi7xRUPL6BZHpCLmglrPBLBq8v4/ZtBO+PuNBMDm9kotO7Sp1VXmF3SryWmqvV WeLeYi6dSvm+SOYJTsVaNavNmVf9w4+SkEBIZU5XoSRwZEtFwAq0brSMbnnBImGdK0oK iIls8xGbvrG4yt4kM0Ssn9IAd46QrmZWLycnDMvH1sl3odXIWr9JZ5lJg8E0VaXVvC5a hPaw== X-Gm-Message-State: AHPjjUhWoa5UXWeaaX6yb4gjFz5fjE82hh58OY/UDgbAWrACyKmdSLMZ gW4p7wUG1009giaPGyzDRU0Mdygres6soi3TYsY= X-Google-Smtp-Source: AOwi7QC5nSnWHn3gJBeQjRt7hgLF5Zb9AZJsI7w0qqSvUwO7Ovjd6K9QxYoqAUDoGFatWG6JY2tPInqRjbixYuTK5qk= X-Received: by 10.107.149.143 with SMTP id x137mr16128752iod.266.1506444454924; Tue, 26 Sep 2017 09:47:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Tue, 26 Sep 2017 09:47:34 -0700 (PDT) In-Reply-To: References: <150584327542.11740.11895948759881365271@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Tue, 26 Sep 2017 12:47:34 -0400 Message-ID: To: Dan Romascanu Cc: ops-dir@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf , "teas@ietf.org" Content-Type: multipart/alternative; boundary="001a1140fe749c2dea055a1a6ed9" Archived-At: Subject: Re: [Teas] Opsdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 16:47:38 -0000 --001a1140fe749c2dea055a1a6ed9 Content-Type: text/plain; charset="UTF-8" Please see inline. Regards, -Pavan On Fri, Sep 22, 2017 at 8:32 AM, Dan Romascanu wrote: Snipped.. > > > >> >>> 2. Section 2.1 includes a number of " RFC2961 Specific" Recommendations. >>> However, it is not clear why these are recommendations. For example, >>> reading >>> RFC 2961, nothing indicates that support for RSVP Refresh Overhead >>> Reduction >>> extensions or the receipt of any RSVP Refresh Overhead Reduction >>> message (as >>> specified in Section 2 of RFC2961) are optional. Moreover, RFC 2961 is >>> also >>> Standards Track. So why do we need 'recommendations' to support sections >>> of a >>> standards-track document? Would not just mentioning RFC 2961 compliance >>> be >>> sufficient? >>> >> >> [VPB] The flag that indicates "support of 2961" has always been a little >> vague in terms of what recommendations are mandatory and what are not, >> resulting in different types of implementation behaviors. The text in >> Section 2.1 was added to make sure that there is no room for such >> ambiguities. The discussion in the WG that resulted in this text is >> captured in the following thread: >> https://mailarchive.ietf.org/arch/msg/teas/FMGd8Q5mLUA2d3L2jD7bbid2atc >> > > Makes sense. Maybe a sentence in the Introduction on tle lines of 'support > of 2961 has always been vague, and this document aims bringing the needed > clarifications for implementation and deployment' would be useful. > [Pavan] We'll add some text in 2.1 to make this clear. > >> >> >>> 3. From an operational point of view it is unclear how the >>> recommendations to >>> set the default periodic retransmission interval defined in section >>> 2.1.3 and >>> the configurable refresh interval and the configurable node hello >>> interval >>> defined in section 2.2 are supposed to be implemented. Is this a one time >>> initialization required for every capable node? If so, the capability >>> needs to >>> be confirmed before the re-configuration. This needs to be done for >>> every node? >>> How, if scale is a concern? >>> >>> >> [VPB] The expectation is that the node comes up with the new recommended >> default values after an upgrade to a version that supports this draft. >> Upgrades can be incremental -- not all nodes in the network need to be >> upgraded at the same time (the procedures in this draft are fully backwards >> compatible). >> > > This is fine. A paragraph that clarifies this on the lines of your second > sentence would help. > [Pavan] We will clarify this in the Introduction Section. --001a1140fe749c2dea055a1a6ed9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please see inline.

Regards,
-Pavan

On Fr= i, Sep 22, 2017 at 8:32 AM, Dan Romascanu <dromasca@gmail.com> wrote:

Snipped..




2. Section 2.1 includes a number of " RFC2961 Specific" Recommend= ations.
However, it is not clear why these are recommendations. For example, readin= g
RFC 2961, nothing indicates that support for RSVP Refresh Overhead Reductio= n
extensions=C2=A0 or the receipt of any RSVP Refresh Overhead Reduction=C2= =A0 message (as
specified in Section 2 of RFC2961) are optional. Moreover, RFC 2961 is also=
Standards Track. So why do we need 'recommendations' to support sec= tions of a
standards-track document? Would not just mentioning RFC 2961 compliance be<= br> sufficient?

[VPB] The flag that = indicates "support of 2961" has always been a little vague in ter= ms of what recommendations are mandatory and what are not, resulting in dif= ferent types of implementation behaviors. The text in Section 2.1 was added= to make sure that there is no room for such ambiguities. The discussion in= the WG that resulted in this text is captured in the following thread:
=

Makes sens= e. Maybe a sentence in the Introduction on tle lines of 'support of 296= 1 has always been vague, and this document aims bringing the needed clarifi= cations for implementation and deployment' would be useful.
<= /div>

[Pavan] We'll add som= e text in 2.1 to make this clear.





3. From an operational point of view it is unclear how the recommendations = to
set the default periodic retransmission interval defined in section 2.1.3 a= nd
the configurable refresh interval and the configurable node hello interval<= br> defined in section 2.2 are supposed to be implemented. Is this a one time initialization required for every capable node? If so, the capability needs= to
be confirmed before the re-configuration. This needs to be done for every n= ode?
How, if scale is a concern?


[VPB] The expectation is that t= he node comes up with the new recommended default values after an upgrade t= o a version that supports this draft. Upgrades can be incremental -- not al= l nodes in the network need to be upgraded at the same time (the procedures= in this draft are fully backwards compatible).
=

This = is fine. A paragraph that clarifies this on the lines of your second senten= ce would help.

[Pavan] We will clarify this in the Introduction S= ection.

--001a1140fe749c2dea055a1a6ed9-- From nobody Tue Sep 26 11:01:48 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D371330AE; Tue, 26 Sep 2017 11:01:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, Lou Berger , teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150644890311.20830.6212136664552694640.idtracker@ietfa.amsl.com> Date: Tue, 26 Sep 2017 11:01:43 -0700 Archived-At: Subject: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-t?= =?utf-8?q?eas-rsvp-te-scaling-rec-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:01:43 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-teas-rsvp-te-scaling-rec-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm uncertain what section 2.1.3. actually recommends. My understanding is that it is recommend to still send retransmit some message even if the Rl was reached and to that every 30s basically forever. First of all I think this still needs a termination criteria when to stop to try to retransmit finally. And the I don't understand why this is needed, instead of e.g. just using a larger Rl value? Can you please clarify! ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is actually a extension specification. I would strongly recommend to apply the changes proposed by the gen-art review, and there is also a very detailed list of nits/edits that should probably be applied. Please have a look at that! From nobody Tue Sep 26 22:17:20 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1F1321CB; Tue, 26 Sep 2017 22:17:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, Lou Berger , teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150648943832.24979.8479092732800144290.idtracker@ietfa.amsl.com> Date: Tue, 26 Sep 2017 22:17:18 -0700 Archived-At: Subject: [Teas] Adam Roach's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 05:17:18 -0000 Adam Roach has entered the following ballot position for draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some reservations around certain aspects of the document, but they've largely been captured by other IESG members. I'll reiterate two of them here, phrased as concrete suggestions. Change the title to something more like "Protocol Enhancements to Improve...", and rephrase all uses of the word "recommendation" to instead refer to the techniques described in the document. Clarify that the retransmission of messages described in section 2.1.3 does not continue for years or decades: specify a limit after which retransmission ceases even without an ACK. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - RSVP-TE - RSVP Traffic Engineering - LSR - Label Switching Router From nobody Wed Sep 27 16:13:20 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F616135176; Wed, 27 Sep 2017 16:13:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150655399319.13662.11153250528531965850@ietfa.amsl.com> Date: Wed, 27 Sep 2017 16:13:13 -0700 Archived-At: Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-scaling-rec-07.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 23:13:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF. Title : Techniques to Improve the Scalability of RSVP Traffic Engineering Deployments Authors : Vishnu Pavan Beeram Ina Minei Rob Shakir Dante Pacella Tarek Saad Filename : draft-ietf-teas-rsvp-te-scaling-rec-07.txt Pages : 11 Date : 2017-09-27 Abstract: At the time of writing, networks which utilize RSVP Traffic Engineering (RSVP-TE) Label Switched Paths (LSPs) are encountering limitations in the ability of implementations to support the growth in the number of LSPs deployed. This document defines two techniques, "Refresh-Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-07 https://datatracker.ietf.org/doc/html/draft-ietf-teas-rsvp-te-scaling-rec-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 27 18:17:44 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A00C7135211; Wed, 27 Sep 2017 18:17:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, Lou Berger , teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150656145760.13808.17318350937488343363.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 18:17:37 -0700 Archived-At: Subject: [Teas] Ben Campbell's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-07: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 01:17:38 -0000 Ben Campbell has entered the following ballot position for draft-ietf-teas-rsvp-te-scaling-rec-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Note: The authors revised this draft between the time I reviewed it and transcribed my notes. This is a review of version 06. I will not have time to re-review 07 prior to the telechat to see if my comments still apply.] Substantive: - General: I agree with the "major issues" comments from Elwyn's Gen-ART review. - General: There's a fair amount of 2119 language in this draft that refers to options in prior RFCs. It's not clear which of those are new normative requirements vs restatements of existing requirements. In the former case, this draft would need to update those respective RFCs. In the latter case, this draft should use descriptive language rather than 2119 keywords (unless in the form of direct quotes.) -1, last paragraph: "In order to reap maximum scaling benefits, it is strongly RECOMMENDED that implementations support both the techniques." That statement seems to require updating ... something. Maybe 3209 or 2961? -2.1.3, 2nd paragraph: Does this update RFC 2961? Or if not, is the normative language appropriate here? -2.2, bullet list: Are these new normative requirements or restatements of existing ones? -6: "This document does not introduce new security issues." Please document the reasoning behind that statement. Editorial: -2.1, section title: Why the quotes? -2.2, first bullet: Section 1 already normatively states these. This text effectively says "MUST follow the MUSTs...". (Note that this pattern recurs in several places.) -2.3, first paragraph: "The set of recommendations discussed in this section..." As written, many of those are requirements rather than recommendations. From nobody Wed Sep 27 19:49:01 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91361135269; Wed, 27 Sep 2017 19:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfGOq7gAvQPe; Wed, 27 Sep 2017 19:48:51 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE421344EC; Wed, 27 Sep 2017 19:48:51 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id c195so600257itb.1; Wed, 27 Sep 2017 19:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DKx5gw3lfrER7aud3O5s2UkbQcte/bGtnceDwoAOqjo=; b=hM7QyxwEbMQ5C8NODsnScSTcajFHRcxORj14WIVxg8sCE3177z+ohzRdjEWwDufRIe 6f6vkRfVk7hOGFITmTlzSSg9x972mT5FatjeljcebdKpKKKBInIUgMOrZCQQrT2rstsT +TA9PRZcTgw/LKp3R+rZTm1v8SiquZGmwt7w+xU+fps95J5iufcPEw+SNC2wWKYp4y7S fTwkGnWiAIyn1BcCumIY64Fz+ShMQYlWYr+lDQh9X6c8AvX1mfZgavhnV7XxfB8ANw93 SzDSs9kl51s5M8dtERg3csmnsK5c/sN9U9LaXakvVqVCiV/dykhMLGaQpl8Y1w3y/oxK YjKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DKx5gw3lfrER7aud3O5s2UkbQcte/bGtnceDwoAOqjo=; b=fsENiA9l/NozOU0BBuRIJtJS9iTPAB60+ujLYTGvRzNGkgOIIWUpM6nOmVlP4cED3S P5VuNPXSKFKKFr5WAHaUkMlVGgiwB/jbcc0a7JpGFahzi0WpXV1i9ng6AOhlP4Nh82U1 Ps11rcku/wcrT/eytb2YVjoLrOZy8njEeP9SvQZBKGzSeq/BTK8USFbaNhtPLo0TKq+q 0Vin+ikFA+t9AgNT7z3IZeplcxvidAGMieEBoyFWjgICj8Cf7Pf97Ix7BTaX5GdgSQhn 7eIjwiuT8vFWT9UqGK2GWr8KYjirVei0gAzP/G6qeHkC3llOC59GP6y9FkJ8AVUFPGSt hZBQ== X-Gm-Message-State: AHPjjUhsLzl26ZHJ4ypdX/koQQ5f3s41ujF6YilqUKI0yiIbvqqpf2Oe +xdqECpLz6E/7jkDE47KDysdR6BWvLP2jFl9blg= X-Google-Smtp-Source: AOwi7QAKOvTL3TrMieWyMqV5XcyXdymMP6fIGHcM4oLFs1iYWrDDMUje2c4ee56S1uB0MeqymHJt5pRHyLZljRXRAPw= X-Received: by 10.36.140.77 with SMTP id j74mr3593801itd.95.1506566930885; Wed, 27 Sep 2017 19:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Wed, 27 Sep 2017 19:48:50 -0700 (PDT) In-Reply-To: <150611799315.22445.6055168230107378983@ietfa.amsl.com> References: <150611799315.22445.6055168230107378983@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Wed, 27 Sep 2017 22:48:50 -0400 Message-ID: To: Elwyn Davies Cc: gen-art@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf , "teas@ietf.org" Content-Type: multipart/alternative; boundary="001a1145eee8bef9d3055a36f233" Archived-At: Subject: Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 02:48:55 -0000 --001a1145eee8bef9d3055a36f233 Content-Type: text/plain; charset="UTF-8" Elwyn, Hi! Thanks for the detailed review and the text suggestions. We just posted a new revision (-07) to address the concerns listed below. Please go through the new diffs ( https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-07) and let us know if additional changes are required. Please see inline for further responses (prefixed VPB). Regards, -Pavan On Fri, Sep 22, 2017 at 6:06 PM, Elwyn Davies wrote: > Reviewer: Elwyn Davies > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-teas-rsvp-te-scaling-rec-06 > Reviewer: Elwyn Davies > Review Date: 2017-09-22 > IETF LC End Date: 2017-09-22 > IESG Telechat date: 2017-09-28 > > Summary: Not ready, primarily because the title and presentation give the > impression that the content is really a BCP when it isn't. This conceals > the > considerable amount of tweaking of RFC 2961 functionality and addition of > new > RSVP Capabilities described in the document. There are also a couple of > minor > issues that need to be sorted out. > > Major issues: > Title and way proposals are presented: The document defines two new > 'capabilities' for RSVP-TE and is indeed (as specified in the document > header) > correctly intended for Standards Track status. However the title and the > whole > of the meat of the document in Section 2 presents the proposals as > 'recommendations' which says to me that I am expecting a BCP where a > profile of > available options from existing standards is recommended as the best > choice for > implementation and deployment. In my opinion, the title would be better as > something like "Additional Capabilities Designed to Improve the > Scalability of > RSVP-TE Deployments". Whilst the proposals are based on the techniques in > RFC > 2961, the document *requires* the implementor to conform to rules that were > optional and constrains configurable values to different ranges in order > to be > able to deliver the capabilities defined in the document as well as > defining > new RSVP extensions modifying some of the behaviour defined in RFC 2961. > Thus > although some of the rules could be met by choosing particular values > within > the RFC 2961 set, the use of MUST, tweaking of functionality and variation > of > ranges takes it well beyond a set of recommendations for RFC 2961 options > selections. In view of this Section 1 needs to be written as an > introduction > to the definitions of the new capabilities rather than advocacy for > selection > of RFC 2961 options and the implication that the techniques mentioned in > the > last paragraph of s1 are just a matter of selecting a profile of option > values. > In actuality new protocol values are introduced and ss2.2 and 2.3 define > novel > extensions to RSVP beyond what is available for RFC 2961 and requiring > modification to basic RFC 2961 functionality.. > > [VPB] We changed the title to "Techniques to Improve the Scalability of RSVP-TE Deployments". We also tweaked the text in the introduction section as suggested. Please see if the new set of diffs address the comment above. Minor issues: > Interaction with RFC 5063: The document does not explicitly state that an > implementation would need to support (at least) the extra capability obect > defined in s4.2 of RFC 5063. Some words about interaction with RFC 5063 > are > probably required in that s4.2.1 of RFC 5063 rather assumes that if there > is a > capability object, by default its S bit will be set. > [VPB] The CAPABILITY object in RFC5063 is meant for generic use and can be used even when there are no Graceful Restart extensions in play (even when no GR flags are set). As far as we can tell, there is nothing in RFC5063 that precludes this. We added a reference to RFC5063 when the new Capability flags are introduced. Would this be sufficient to address this concern? > > Behaviour if a node stops setting Refresh-Reduction-Capable bit: The last > para > of s2 in RFC 2961 discusses behaviour if a node stops setting this bit in > messages. What would happen with the extensions defined in this document > if > this happened while either of the extensions is in use? As a matter of > interest, if a peer offers the capabilities defined in this draft, is it > possible or sensible for it to stop setting the Refresh-Reduction-Capable > bit > without stopping offering the extensions? > [VPB] If a peer sets the I or F bit in the CAPABILITY object but does not set the Refresh-Reduction-capable bit, then the corresponding functionality ("RI-RSVP" or "Per-Peer Flow-Control") is not activated for that peer. In other words, resetting the Refresh-Reduction-Capable bit immediately makes the node incapable of supporting the two capabilities discussed in this document. This is covered in Sections 3.1 and 4.1 ( -07 version). > s2.1.3, para 2: As specified, it appears that the 'slower timer' > transmission > of Path and Resv messages can go on indefinitely if no ack arrives. What > puts > an end to this repetition? [It may be that I have forgotten how basic RSVP > works, but since this is altering the behaviour it would be good to > explain how > it terminates, and whether this requires any additional modification to > timers.] > [VPB] There is nothing new about Path and Resv messages getting transmitted indefinitely (this is normal soft-state signaling behavior) -- all that this section does is discuss how these transmissions are paced in the absence of an ack. The slower timer transmission will go on until either an ack is received (at which point the regular "refresh interval" comes into play) or the corresponding LSP instance state is torn down. > Nits/editorial comments: > Abstract: RSVP-TE is not a 'well-known' abbreviation: s/RSVP-TE/RSVP > Traffic > Engineering (RSVP-TE)/ > > Abstract and s1, first para: This para is not future proof. Suggest: > OLD: > The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get > deployed is growing continually and there is considerable onus on > RSVP-TE implementations across the board to keep up with this > increasing demand in scale. > NEW: > At the time of writing, networks which utilise RSVP Traffic Engineering > (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are encountering > limitations > in the ability of implementations to support the growth in the number > of LSPs > deployed. This document defines two additional RSVP-TE extensions that > are intended to reduce the number of messages needed to maintain RSVP-TE > soft state in routers and hence allow implementations to support larger > scale deployments. > ENDS > Note: Omit reference from Abstract. > > [VPB] Fixed in -07 s1, para 2: s/under certain/beyond a certain/ > [VPB] Fixed in -07 > s1, para 3: s/makes a set of concrete implementation > recommendations/defines > two extensions/; s/- push higher/by increasing/; s/maintain LSP > state./maintain > LSP state by reducing the number of messages needed./ > > Abstract, para 2 and s1, last para: [Omit reference from Abstract] > OLD: > This document advocates the use of a couple of techniques - "Refresh- > Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - > for significantly cutting down the amount of processing cycles > required to maintain LSP state. > NEW: > This document defines two RSVP Capabilities [RFC5063] "Refresh- > Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" > that will cut down the number of messsages and processing cycles > required to maintain LSP state. > ENDS > [VPB] Fixed in -07 > s1, last para: Add new penultimate sentence: > Note that the "Per-Peer Flow-Control" capability requires the "RI-RSVP" > capability as a prerequisite. > [VPB] Fixed in -07 > s1, last para: s/RECOMMENDED/recommended/ - this isn't a recommendation > about > the protocol on the wire. > [VPB] Fixed in -07 > Subdivision of s2: The issues regarding the nature of the document would > be > helped by altering s2 into four top level sections, thus: s2: Requirement > for > RFC 2961 Refresh Overhead Reduction Support and Specific Option Choices > (from > s2.1) s3: Requirement for RFC 5063 Capability Object support (see Minor > Issues > above) s4: Refresh-Interval Independent RSVP Capability (from s2.3) s5: > Per-Peer RSVP Flow Control Capability (from s2.4) Subsequent major sections > then renumbered as s6 onwards. References to s2.x will need to be updated > throughout. > [VPB] We subdivided s2 into 3 top level sections. We did not add a separate section for discussing RFC5063 Capability Object support. > s2.1 (would be introduction of new s2): > OLD: > The implementation recommendations discussed in this section are > based on the proposals made in [RFC2961] and act as prerequisites for > implementing the techniques discussed in Sections 2.2 and 2.3. > > NEW: > The Capabilities defined in Sections 4 and 5 of this document are based > on > proposals made in [RFC2961]. Implementations of these Capabilities will > need to support the RSVP messages and techniques defined in [RFC2961] > as set > out in Section 2.1 [was 2.1.1] with > some minor modifications and alterations to recommended time intervals > and > iteration counts as defined in the remainder of this section. > ENDS > > [VPB] Fixed in -07 s2.1.1, title and para 1 [will be s2.1]: > OLD: > 2.1.1. Basic Prerequisites > > An implementation that supports the techniques discussed in Sections > 2.2 and 2.3 must meet certain basic prerequisites. > NEW: > 2.1. Required Functionality from RFC 2961 to be Implemented > > An implementation that supports the capabiities discussed in Sections > 4 and 5 must provide a large subset of the functionality described > in [RFC2961] as follows: > ENDS > [VPB] Fixed in -07 > s2.1.2, para 2 [will be s2.2]: s/techniques discussed in Sections 2.2 and > 2.3/Capabilities defined in Sections 4 and 5/ > [VPB] Fixed in -07 > s2.1.2, para 2: s/MESSAGE ID/MESSAGE_ID/ > [VPB] Fixed in -07 > s2.2, para 1: s/improvement on transmission overhead/improvement of > transmission overhead/ > [VPB] Fixed in -07 > s2.2, para 1: s/proposes sufficient recommendations/sets out additional > requirements/ > [VPB] Fixed in -07 > s2.2, last bullet: Add a reference to the proposed new Section 3 that > discusses > the Capability object. > [VPB] Added a direct reference to RFC5063 > s2.2.1, last para: s/set Refresh-Reduction-Capable bit in common > header/set the > Refresh-Reduction-Capable bit in the common header/ > [VPB] Fixed in -07 > s2.3, para 1: s/set of recommendations/functionality/; > s/provide/provides/; > s/RSVP-TE control plane congestion/a significant portion of the RSVP-TE > control > message load/ > [VPB] Fixed in -07 > s2.3.2: s/MESSAGE ID/MESSAGE_ID/ > [VPB] Fixed in -07 > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a1145eee8bef9d3055a36f233 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Elwyn, Hi!

Thanks for t= he detailed review and the text suggestions. We just posted a new revision = (-07) to address the concerns listed below. Please go through the new diffs= (https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-s= caling-rec-07) and let us know if additional changes are required.

Please see inline for further responses (prefixed VPB)= .

Regards,
-Pavan

<= div class=3D"gmail_quote">On Fri, Sep 22, 2017 at 6:06 PM, Elwyn Davies <elwynd@dial.pipex.com> wrote:
Reviewer: Elwyn Davies
Review result: Not Ready

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.

Document: draft-ietf-teas-rsvp-te-scaling-rec-06
Reviewer: Elwyn Davies
Review Date: 2017-09-22
IETF LC End Date: 2017-09-22
IESG Telechat date: 2017-09-28

Summary: Not ready, primarily because the title and presentation give the impression that the content is really a BCP when it isn't.=C2=A0 This c= onceals the
considerable amount of tweaking of RFC 2961 functionality and addition of n= ew
RSVP Capabilities described in the document.=C2=A0 There are also a couple = of minor
issues that need to be sorted out.

Major issues:
Title and way proposals are presented:=C2=A0 The document defines two new 'capabilities' for RSVP-TE and is indeed (as specified in the docum= ent header)
correctly intended for Standards Track status.=C2=A0 However the title and = the whole
of the meat of the document in Section 2 presents the proposals as
'recommendations' which says to me that I am expecting a BCP where = a profile of
available options from existing standards is recommended as the best choice= for
implementation and deployment.=C2=A0 In my opinion, the title would be bett= er as
something like "Additional Capabilities Designed to Improve the Scalab= ility of
RSVP-TE Deployments".=C2=A0 Whilst the proposals are based on the tech= niques in RFC
2961, the document *requires* the implementor to conform to rules that were=
optional and constrains configurable values to different ranges in order to= be
able to deliver the capabilities defined in the document as well as definin= g
new RSVP extensions modifying some of the behaviour defined in RFC 2961.=C2= =A0 Thus
although some of the rules could be met by choosing particular values withi= n
the RFC 2961 set, the use of MUST, tweaking of functionality and variation = of
ranges takes it well beyond a set of recommendations for RFC 2961 options selections.=C2=A0 In view of this Section 1 needs to be written as an intro= duction
to the definitions of the new capabilities rather than advocacy for selecti= on
of RFC 2961 options and the implication that the techniques mentioned in th= e
last paragraph of s1 are just a matter of selecting a profile of option val= ues.
=C2=A0In actuality new protocol values are introduced and ss2.2 and 2.3 def= ine novel
extensions to RSVP beyond what is available for RFC 2961 and requiring
modification to basic RFC 2961 functionality..


Minor issues:
Interaction with RFC 5063:=C2=A0 The document does not explicitly state tha= t an
implementation would need to support (at least) the extra capability obect<= br> defined in s4.2 of RFC 5063.=C2=A0 Some words about interaction with RFC 50= 63 are
probably required in that s4.2.1 of RFC 5063 rather assumes that if there i= s a
capability object, by default its S bit will be set.
<= br>
[VPB] The CAPABILITY object in RFC5063 is meant for generic u= se and can be used even when there are no Graceful Restart extensions in pl= ay (even when no GR flags are set). As far as we can tell, there is nothing= in RFC5063 that precludes this. We added a reference to RFC5063 when the n= ew Capability flags are introduced. Would this be sufficient to address thi= s concern?
=C2=A0

Behaviour if a node stops setting Refresh-Reduction-Capable bit:=C2=A0 The = last para
of s2 in RFC 2961 discusses behaviour if a node stops setting this bit in messages.=C2=A0 What would happen with the extensions defined in this docum= ent if
this happened while either of the extensions is in use?=C2=A0 As a matter o= f
interest, if a peer offers the capabilities defined in this draft, is it possible or sensible for it to stop setting the Refresh-Reduction-Capable b= it
without stopping offering the extensions?

[VPB]=C2=A0 If a peer sets the I or F bit in the CAPABILITY object but d= oes not set the Refresh-Reduction-capable bit, then the corresponding funct= ionality ("RI-RSVP" or "Per-Peer Flow-Control") is not = activated for that peer. In other words, resetting the Refresh-Reduction-Ca= pable bit immediately makes the node incapable of supporting the two capabi= lities discussed in this document. This is covered in Sections 3.1 and 4.1 = ( -07 version).


s2.1.3, para 2: As specified, it appears that the 'slower timer' tr= ansmission
of Path and Resv messages can go on indefinitely if no ack arrives.=C2=A0 W= hat puts
an end to this repetition?=C2=A0 [It may be that I have forgotten how basic= RSVP
works, but since this is altering the behaviour it would be good to explain= how
it terminates, and whether this requires any additional modification to tim= ers.]



Nits/editorial comments:
Abstract: RSVP-TE is not a 'well-known' abbreviation: s/RSVP-TE/RSV= P Traffic
Engineering (RSVP-TE)/

Abstract and s1, first para:=C2=A0 This para is not future proof.=C2=A0 Sug= gest:
OLD:
=C2=A0 =C2=A0The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSP= s) get
=C2=A0 =C2=A0deployed is growing continually and there is considerable onus= on
=C2=A0 =C2=A0RSVP-TE implementations across the board to keep up with this<= br> =C2=A0 =C2=A0increasing demand in scale.
NEW:
=C2=A0 =C2=A0At the time of writing, networks which utilise RSVP Traffic En= gineering
=C2=A0 =C2=A0(RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are encounteri= ng limitations
=C2=A0 =C2=A0in the ability of implementations to support the growth in the= number of LSPs
=C2=A0 =C2=A0deployed.=C2=A0 This document defines two additional RSVP-TE e= xtensions that
=C2=A0 =C2=A0are intended to reduce the number of messages needed to mainta= in RSVP-TE
=C2=A0 =C2=A0soft state in routers and hence allow implementations to suppo= rt larger
=C2=A0 =C2=A0scale deployments.
ENDS
Note:=C2=A0 Omit reference from Abstract.



s1, para 2: s/under certain/beyond a certain/

[VPB] Fixed in -07


s1, para 3: s/makes a set of concrete implementation recommendations/define= s
two extensions/; s/- push higher/by increasing/; s/maintain LSP state./main= tain
LSP state by reducing the number of messages needed./

Abstract, para 2 and s1, last para:=C2=A0 [Omit reference from Abstract] OLD:
=C2=A0 =C2=A0This document advocates the use of a couple of techniques - &q= uot;Refresh-
=C2=A0 =C2=A0Interval Independent RSVP (RI-RSVP)" and "Per-Peer F= low-Control" -
=C2=A0 =C2=A0for significantly cutting down the amount of processing cycles=
=C2=A0 =C2=A0required to maintain LSP state.
NEW:
=C2=A0 =C2=A0This document defines two RSVP Capabilities [RFC5063] "Re= fresh-
=C2=A0 =C2=A0Interval Independent RSVP (RI-RSVP)" and "Per-Peer F= low-Control"
=C2=A0 =C2=A0that will cut down the number of messsages and processing cycl= es
=C2=A0 =C2=A0required to maintain LSP state.
ENDS

[VPB] Fixed in -07
=

s1, last para: Add new penultimate sentence:
=C2=A0 =C2=A0Note that the "Per-Peer Flow-Control" capability req= uires the "RI-RSVP"
=C2=A0 =C2=A0capability as a prerequisite.

<= div>[VPB] Fixed in -07


s1, last para: s/RECOMMENDED/recommended/ - this isn't a recommendation= about
the protocol on the wire.
=C2=A0
[VPB] Fixed= in -07


Subdivision of s2:=C2=A0 The issues regarding the nature of the document wo= uld be
helped by altering s2 into four top level sections, thus: s2: Requirement f= or
RFC 2961 Refresh Overhead Reduction Support and Specific Option Choices (fr= om
s2.1) s3: Requirement for RFC 5063 Capability Object support (see Minor Iss= ues
above) s4: Refresh-Interval Independent RSVP Capability (from s2.3) s5:
Per-Peer RSVP Flow Control Capability (from s2.4) Subsequent major sections=
then renumbered as s6 onwards. References to s2.x will need to be updated throughout.

[VPB] We subdivided s2 into= 3 top level sections. We did not add a separate section for discussing RFC= 5063 Capability Object support.


s2.1 (would be introduction of new s2):
OLD:
=C2=A0 =C2=A0The implementation recommendations discussed in this section a= re
=C2=A0 =C2=A0based on the proposals made in [RFC2961] and act as prerequisi= tes for
=C2=A0 =C2=A0implementing the techniques discussed in Sections 2.2 and 2.3.=

NEW:
=C2=A0 =C2=A0The Capabilities defined in Sections 4 and 5 of this document = are based on
=C2=A0 =C2=A0proposals made in [RFC2961].=C2=A0 Implementations of these Ca= pabilities will
=C2=A0 =C2=A0need to support the RSVP messages and techniques defined in [R= FC2961] as set
=C2=A0 =C2=A0out in Section 2.1 [was 2.1.1] with
=C2=A0 =C2=A0some minor modifications and alterations to recommended time i= ntervals and
=C2=A0 =C2=A0iteration counts as defined in the remainder of this section.<= br> ENDS


[VPB] Fixed in -07

=
s2.1.1, title and para 1 [will be s2.1]:
OLD:
2.1.1.=C2=A0 Basic Prerequisites

=C2=A0 =C2=A0An implementation that supports the techniques discussed in Se= ctions
=C2=A0 =C2=A02.2 and 2.3 must meet certain basic prerequisites.
NEW:
2.1.=C2=A0 Required Functionality from RFC 2961 to be Implemented

=C2=A0 =C2=A0An implementation that supports the capabiities discussed in S= ections
=C2=A0 =C2=A04 and 5 must provide a large subset of the functionality descr= ibed
=C2=A0 =C2=A0in [RFC2961] as follows:
ENDS

[VPB] Fixed in -07
=

s2.1.2, para 2 [will be s2.2]: s/techniques discussed in Sections 2.2 and 2.3/Capabilities defined in Sections 4 and 5/

[VPB] Fixed in -07


s2.1.2, para 2: s/MESSAGE ID/MESSAGE_ID/

[VPB] Fixed in -07


s2.2, para 1: s/improvement on transmission overhead/improvement of
transmission overhead/

[VPB] Fixed in -= 07


s2.2, para 1: s/proposes sufficient recommendations/sets out additional
requirements/

--001a1145eee8bef9d3055a36f233-- From nobody Wed Sep 27 19:53:40 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBD51344EC; Wed, 27 Sep 2017 19:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdPKuvlNG5Uq; Wed, 27 Sep 2017 19:53:31 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23183133018; Wed, 27 Sep 2017 19:53:31 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 85so638037ith.2; Wed, 27 Sep 2017 19:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4PqLF/ICtDAk5BQsOVSHCHD9EtWx8bV8xCZrdIvDPUo=; b=i0s5DX/a9DxACwijUxdFgdJQ7/4ZqFxqUiqyvwxgdvMOkVReU04AiogSMJZX6HvGTB rlTxgluJsOYgVYTr+aEex7sj5m3wlEYaGvaU6MBLxv2UDaQsRwtEIfu7fu4fdH5P0l2M UFIAnbz2aYVN1l2gkCPKQ45VYPG5vZg6x5QGw71DUb/2YwuRZYegZuas3BZbZQ0DEwSg UJo23EFEqZ7aG4D46TOwwk7gvukdydOOY1lAA8yog5THOM2Liu8MjFuslh5YaTUvVajD eJrAuW0redQ1RYJcBnEAfgZybt6ZMQS1qEdcl2zcmzxiEJPr4EJacyf8clH0RoBBzIle dDgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4PqLF/ICtDAk5BQsOVSHCHD9EtWx8bV8xCZrdIvDPUo=; b=R/STlvtwvvRjszfrEF3KwjcMP3DMcrFjF1eGlNbtM6gRdRV2zyWdRXUk0MALIOts24 ZmGROVB6g+5r4VhwUZ83SFyF72l9bx123f/ikaHmJRjF/YuJjQBVSUPzH0Tn9QUJ8OFD iIbXkcb4JvJj06iavGFyaUGdSLHPM4cHtDZt1hNGs624lg1TO9rhdFITd2YJpdSc7KXX yqutbuLha43dYnZKbiEjVL7HgMNi8G1nWRI0lmYfgv7M4TN7s7yD0QrXPhWKD9IooT4c NMNnO89UJPjpTaveK28gHgR8+AmmpEyYXEBgC+kOonASx9vLsybN2uUIK3NFl+0dh+2N N/9Q== X-Gm-Message-State: AHPjjUiso3SXHgZKNNstVFZs4ccoWe4+wOQ2mrxdGrjcfj/prQHuuJc/ acRYwlOR9P6kfZLVCH5jzAakwGUermR5dZE/5+o= X-Google-Smtp-Source: AOwi7QC1PcMVD2Fk63N8q/pX42Ja0nCXC7wNLVcrXUxDSV7gDF84AXvR4WE1YyjhwhdSD9xM0NL9YglttLBv7jeYwOo= X-Received: by 10.36.0.215 with SMTP id 206mr3918848ita.84.1506567210476; Wed, 27 Sep 2017 19:53:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Wed, 27 Sep 2017 19:53:30 -0700 (PDT) In-Reply-To: <150597523137.24776.3598419805081836880@ietfa.amsl.com> References: <150597523137.24776.3598419805081836880@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Wed, 27 Sep 2017 22:53:30 -0400 Message-ID: To: Liang Xia Cc: secdir@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf , "teas@ietf.org" Content-Type: multipart/alternative; boundary="001a11c141ec692cb1055a37032d" Archived-At: Subject: Re: [Teas] Secdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 02:53:33 -0000 --001a11c141ec692cb1055a37032d Content-Type: text/plain; charset="UTF-8" Liang, Hi! Thanks for the review. We just posted a new revision (-07) to address concerns raised by the Gen-Art reviewer. The new changes (https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te- scaling-rec-07) do not introduce any new security issues. Regards, -Pavan On Thu, Sep 21, 2017 at 2:27 AM, Liang Xia wrote: > Reviewer: Liang Xia > Review result: Ready > > It's in good shape and well written, and does not introduce any new > security issues. > Following the security design of RSVP (-TE) is just ok! > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a11c141ec692cb1055a37032d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Liang, Hi!

Thanks for the review. We just= posted a new revision (-07) to=20 address concerns raised by the Gen-Art reviewer.=C2=A0

<= /div>
The new changes (https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-scaling-rec-07) do = not introduce any new security issues.

Regards,
-Pava= n

On Thu, Se= p 21, 2017 at 2:27 AM, Liang Xia <frank.xialiang@huawei.com>= ; wrote:
Reviewer: Liang Xia
Review result: Ready

It's in good shape and well written, and does not introduce any new sec= urity issues.
Following the security design of RSVP (-TE) is just ok!

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

--001a11c141ec692cb1055a37032d-- From nobody Wed Sep 27 19:55:06 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AF8133018; Wed, 27 Sep 2017 19:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty2KMR6pqgSM; Wed, 27 Sep 2017 19:54:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7D4135273; Wed, 27 Sep 2017 19:54:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPM86063; Thu, 28 Sep 2017 02:54:54 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 28 Sep 2017 03:54:53 +0100 Received: from DGGEML502-MBX.china.huawei.com ([169.254.2.114]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0301.000; Thu, 28 Sep 2017 10:54:47 +0800 From: "Xialiang (Frank)" To: Vishnu Pavan Beeram CC: "secdir@ietf.org" , "draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org" , ietf , "teas@ietf.org" Thread-Topic: [Teas] Secdir last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 Thread-Index: AQHTOAT79wyq37Ms2U2EHIOWFkLxzKLJme6w Date: Thu, 28 Sep 2017 02:54:47 +0000 Message-ID: References: <150597523137.24776.3598419805081836880@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BBA8EE7DGGEML502MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59CC647F.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.114, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9df51ec11beb60e0c8fca80d79259f63 Archived-At: Subject: [Teas] =?utf-8?b?562U5aSNOiAgU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2Yg?= =?utf-8?q?draft-ietf-teas-rsvp-te-scaling-rec-06?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 02:55:00 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BBA8EE7DGGEML502MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R290IGl0LCB0aGFua3MgZm9yIHVwZGF0aW5nIG1lIQ0KDQrlj5Hku7bkuro6IFZpc2hudSBQYXZh biBCZWVyYW0gW21haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb21dDQrlj5HpgIHml7bpl7Q6IDIw MTflubQ55pyIMjjml6UgMTA6NTQNCuaUtuS7tuS6ujogWGlhbGlhbmcgKEZyYW5rKQ0K5oqE6YCB OiBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNjYWxpbmctcmVjLmFs bEBpZXRmLm9yZzsgaWV0ZjsgdGVhc0BpZXRmLm9yZw0K5Li76aKYOiBSZTogW1RlYXNdIFNlY2Rp ciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNjYWxpbmctcmVj LTA2DQoNCkxpYW5nLCBIaSENClRoYW5rcyBmb3IgdGhlIHJldmlldy4gV2UganVzdCBwb3N0ZWQg YSBuZXcgcmV2aXNpb24gKC0wNykgdG8gYWRkcmVzcyBjb25jZXJucyByYWlzZWQgYnkgdGhlIEdl bi1BcnQgcmV2aWV3ZXIuDQoNClRoZSBuZXcgY2hhbmdlcyAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNjYWxpbmctcmVjLTA3KSBkbyBu b3QgaW50cm9kdWNlIGFueSBuZXcgc2VjdXJpdHkgaXNzdWVzLg0KUmVnYXJkcywNCi1QYXZhbg0K DQpPbiBUaHUsIFNlcCAyMSwgMjAxNyBhdCAyOjI3IEFNLCBMaWFuZyBYaWEgPGZyYW5rLnhpYWxp YW5nQGh1YXdlaS5jb208bWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20+PiB3cm90ZToN ClJldmlld2VyOiBMaWFuZyBYaWENClJldmlldyByZXN1bHQ6IFJlYWR5DQoNCkl0J3MgaW4gZ29v ZCBzaGFwZSBhbmQgd2VsbCB3cml0dGVuLCBhbmQgZG9lcyBub3QgaW50cm9kdWNlIGFueSBuZXcg c2VjdXJpdHkgaXNzdWVzLg0KRm9sbG93aW5nIHRoZSBzZWN1cml0eSBkZXNpZ24gb2YgUlNWUCAo LVRFKSBpcyBqdXN0IG9rIQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KVGVhcyBtYWlsaW5nIGxpc3QNClRlYXNAaWV0Zi5vcmc8bWFpbHRvOlRlYXNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12BBA8EE7DGGEML502MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Hb3QgaXQsIHRoYW5rcyBmb3Ig dXBkYXRpbmcgbWUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R 5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBWaXNobnUgUGF2YW4gQmVlcmFtIFttYWls dG86dmlzaG51cGF2YW5AZ21haWwuY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIw MTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVO LVVTIj45PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yODwvc3Bhbj7ml6U8c3BhbiBsYW5n PSJFTi1VUyI+IDEwOjU0PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFhpYWxpYW5nIChGcmFuayk8YnI+DQo8 L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zY2FsaW5n LXJlYy5hbGxAaWV0Zi5vcmc7IGlldGY7IHRlYXNAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li7 6aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6 IFtUZWFzXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10 ZS1zY2FsaW5nLXJlYy0wNjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TGlhbmcsIEhpITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoYW5rcyBmb3IgdGhlIHJldmlldy4gV2UganVzdCBwb3N0ZWQgYSBuZXcgcmV2aXNpb24g KC0wNykgdG8gYWRkcmVzcyBjb25jZXJucyByYWlzZWQgYnkgdGhlIEdlbi1BcnQgcmV2aWV3ZXIu Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIG5ldyBjaGFuZ2VzICg8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUt c2NhbGluZy1yZWMtMDciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi10ZWFzLXJzdnAtdGUtc2NhbGluZy1yZWMtMDc8L2E+KQ0KIGRv IG5vdCBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eSBpc3N1ZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4tUGF2YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBUaHUsIFNlcCAyMSwgMjAxNyBhdCAyOjI3IEFNLCBMaWFuZyBYaWEgJmx0 OzxhIGhyZWY9Im1haWx0bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXZpZXdl cjogTGlhbmcgWGlhPGJyPg0KUmV2aWV3IHJlc3VsdDogUmVhZHk8YnI+DQo8YnI+DQpJdCdzIGlu IGdvb2Qgc2hhcGUgYW5kIHdlbGwgd3JpdHRlbiwgYW5kIGRvZXMgbm90IGludHJvZHVjZSBhbnkg bmV3IHNlY3VyaXR5IGlzc3Vlcy48YnI+DQpGb2xsb3dpbmcgdGhlIHNlY3VyaXR5IGRlc2lnbiBv ZiBSU1ZQICgtVEUpIGlzIGp1c3Qgb2shPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUZWFzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpUZWFzQGlldGYub3JnIj5UZWFzQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhczwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12BBA8EE7DGGEML502MBXchi_-- From nobody Wed Sep 27 20:19:35 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2C21344E7; Wed, 27 Sep 2017 20:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH059DPZr9UR; Wed, 27 Sep 2017 20:19:26 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE173135271; Wed, 27 Sep 2017 20:19:26 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id d192so697343itd.1; Wed, 27 Sep 2017 20:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XgMcrqC38CRxsE8QdYso+mwDWLy8cnBnjM2enJIX0X0=; b=bahycGzUEkzPRJ4Ke+l2lzuSjRAjSmlWm0tZgmw7A0L+V4JQ5Lp6mwST2SK2oLqF5M YxOIM6fl+OfwzjvYktC8bigYyZ6sHJhqyzAVHo1N8ZhGszt7aSrfS/Ncszj4JropkUmu pKZxl0KdlzH0+0QgmlAm0ToWOTA07LAMc6RP+/swVPuEyJODnfB+gbSkzp9K2RsTHDG0 MqXebHnfJe6WiMF0kZ+k4kZ61yvVh/c3DimwkgHSo0tSWMHGUpBes31QrngpiSLRTZLr 7zC6vMJYZ/PDPrdTK6pSTYfRotv9bydxUfd6ctqdRhlsqr9xEDsVzzj25QLXm9FrlN86 +m2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XgMcrqC38CRxsE8QdYso+mwDWLy8cnBnjM2enJIX0X0=; b=bYb3GKrQroabGrfc2OsIYZozP0qsJHqNCSF2nIl3Ve6oGQtsuW1BjoQw3SwbH24Bp2 5nnM3gN8jcnJU8PIgVRNkgiLlSgV4KB/QrYi9qRs2Ki2M+KC8zZCm9UgkKTBNK8Wt8pc +ev/lTj+r0TBR6H4VTU9t/xCt8+MpeVgrISinyuSj8R9WWR3LTfbdU8zdF/GdqsG1OYZ y0a/358bN5Zwb5mouHdo4JKEkhvGjfXuBB+NCcTYZ5QvNDPg/JozaTtXHqRm5F0Fkdw6 6GBMkCDLiQBc9ASgTvfGNwQ2E+oKNLQ+gBMWVOjxFbhpQYRf2kYlHIRBcFFOwly5Eo7L H7Zw== X-Gm-Message-State: AMCzsaUsKLVf5Um/ESB2abKUlqNjZucbttRPfWKJrHcT5HqUnPXA35Pn Nb5/XBgY6+GoIwdH2532yz2BRn95TGrfQ8OT5Ds= X-Google-Smtp-Source: AOwi7QA4eCo3agvKorBiprDS/evJON0kaDGNXGF8r579QDfIaETzk9DjsgOms504+ppYrqYRPLTx8czFk1nYeHjILYY= X-Received: by 10.36.177.9 with SMTP id o9mr1885844itf.44.1506568765978; Wed, 27 Sep 2017 20:19:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Wed, 27 Sep 2017 20:19:25 -0700 (PDT) In-Reply-To: <150634961899.27517.2676098033688714820.idtracker@ietfa.amsl.com> References: <150634961899.27517.2676098033688714820.idtracker@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Wed, 27 Sep 2017 23:19:25 -0400 Message-ID: To: Alvaro Retana Cc: The IESG , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, TEAS WG Chairs , "teas@ietf.org" , Lou Berger Content-Type: multipart/alternative; boundary="089e08230ea4204bdd055a3760de" Archived-At: Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 03:19:30 -0000 --089e08230ea4204bdd055a3760de Content-Type: text/plain; charset="UTF-8" Alvaro, Hi! Thanks for the review. We just posted a new revision (-07) to address the Gen-Art review comments. Please go through the new diffs ( https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-07) and let us know if additional changes are required. Please see inline for further responses (prefixed VPB). Regards, -Pavan On Mon, Sep 25, 2017 at 10:26 AM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (1) This document seems to do two things: make a series of rfc2961 > recommendations, and introduce a couple of new techniques. What is not > clear > to me is whether the first part is independent of the second. Will the > implementation of Section 2.1. ("RFC2961 Specific" Recommendations) provide > scaling benefits on their own (i.e. without the new techniques)? If so, > please > add some text (maybe in the Introduction) to indicate that. > [VPB] The implementation of the RFC2961 specific recommendations (Section 2 in rev -07) alone will not provide any significant improvement to the existing scaling numbers. > (2) As for as the new techniques, it is confusing to me the use of rfc2119 > language in Section 2.1.1. (Basic Prerequisites), which reads: > > An implementation that supports the techniques discussed in Sections > 2.2 and 2.3 must meet certain basic prerequisites. > ... > o It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms... > > I know that the leading "must" is not an RFC2119 keyword, but it may be > confusing with the "SHOULD" used later...specially because it sounds as if > (in > some cases) it may be ok to not "initiate all RSVP Refresh Overhead > Reduction > mechanisms" and still use the new mechanisms described later. What are > those > cases? Maybe the mandatory prerequisites should all be listed in the same > sub-section, while other recommendations can be elsewhere. > > Note also that later in 2.2 and 2.3 the text says that an implementation > "MUST > support all the recommendations" in 2.1. What does that MUST mean if one > of > the recommendations is not an absolute requirement? > [VPB] Please see if the changes in rev -07 address the above comment. > (3) Section 2.1.2 (Making Acknowledgements Mandatory) seems to also be a > prerequisite, right? At lease the text says that "an implementation that > supports the techniques discussed in Sections 2.2 and 2.3...MUST...". The > fact > that it is not in the actual prerequisites section may be confusing to > some. > [VPB] We reshuffled a few sections to address the Gen-Art review comments. Please see if the new narrative takes care of removing this confusion. > (4) Section 2.1.3. (Clarifications On Reaching Rapid Retry Limit (Rl)) is > (by > clarifying and using normative language) making specific changes to > rfc2961. > Assuming that there is value in 2.1 being used by itself (without the new > techniques), why isn't there a formal Update of rfc2961? > [VPB] As stated above, there isn't much value in Section 2 being used by itself. > (5) This reminds me, please use the new RFC2119-related template: please > take a > look at rfc8174. > [VPB] We used the new template in -07 > Nits: > > s/interval interval/interval > [VPB] Fixed in -07 > When defining the new capability advertisements (in 2.2.1 and 2.3.1), it > would > be nice to include a reference to rfc5063. > [VPB] Fixed in -07 > Given the specification in the preceding sections, I think that 2.2.2 and > 2.3.2 > are superfluous. > [VPB] The two "Compatibility" sections were added to address specific WG LC comments. If this continues to be a concern, we can consider rolling the text in these sections into the preceding sections. > It would be nice to point at the Appendix from the main text. > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --089e08230ea4204bdd055a3760de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alvaro, Hi!

Thanks for = the review. We just posted a new revision (-07) to=20 address the Gen-Art review comments. Please go through the new diffs (https://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-teas-rsvp-te-scaling-rec-07) and let us know if additional chang= es are required.

Please see inline for further res= ponses (prefixed VPB).

Regards,
-Pavan



On Mon, Sep 25, 2017= at 10:26 AM, Alvaro Retana <aretana@cisco.com> wrote:
Alvaro Retana has entered t= he following ballot position for
draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection

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


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

(1) This document seems to do two things: make a series of rfc2961
recommendations, and introduce a couple of new techniques.=C2=A0 What is no= t clear
to me is whether the first part is independent of the second.=C2=A0 Will th= e
implementation of Section 2.1. ("RFC2961 Specific" Recommendation= s) provide
scaling benefits on their own (i.e. without the new techniques)?=C2=A0 If s= o, please
add some text (maybe in the Introduction) to indicate that.

[VPB] The implementation of the RFC2961 specific recom= mendations (Section 2 in rev -07) alone will not provide any significant im= provement to the existing scaling numbers.


(2) As for as the new techniques, it is confusing to me the use of rfc2119<= br> language in Section 2.1.1. (Basic Prerequisites), which reads:

=C2=A0 =C2=A0An implementation that supports the techniques discussed in Se= ctions
=C2=A0 =C2=A02.2 and 2.3 must meet certain basic prerequisites.
...
=C2=A0 =C2=A0o=C2=A0 It SHOULD initiate all RSVP Refresh Overhead Reduction= mechanisms...

I know that the leading "must" is not an RFC2119 keyword, but it = may be
confusing with the "SHOULD" used later...specially because it sou= nds as if (in
some cases) it may be ok to not "initiate all RSVP Refresh Overhead Re= duction
mechanisms" and still use the new mechanisms described later.=C2=A0 Wh= at are those
cases?=C2=A0 Maybe the mandatory prerequisites should all be listed in the = same
sub-section, while other recommendations can be elsewhere.

Note also that later in 2.2 and 2.3 the text says that an implementation &q= uot;MUST
support all the recommendations" in 2.1.=C2=A0 What does that MUST mea= n if one of
the recommendations is not an absolute requirement?
[VPB] Please see if the changes in rev -07 address the above c= omment.


(3) Section 2.1.2 (Making Acknowledgements Mandatory) seems to also be a prerequisite, right?=C2=A0 At lease the text says that "an implementat= ion that
supports the techniques discussed in Sections 2.2 and 2.3...MUST...".= =C2=A0 The fact
that it is not in the actual prerequisites section may be confusing to some= .

[VPB] We reshuffled a few sections to= address the Gen-Art review comments. Please see if the new narrative takes= care of removing this confusion.


(4) Section 2.1.3. (Clarifications On Reaching Rapid Retry Limit (Rl)) is (= by
clarifying and using normative language) making specific changes to rfc2961= .
Assuming that there is value in 2.1 being used by itself (without the new techniques), why isn't there a formal Update of rfc2961?

[VPB] As stated above, there isn't much value in = Section 2 being used by itself.


(5) This reminds me, please use the new RFC2119-related template: please ta= ke a
look at rfc8174.

[VPB] We used the new = template in -07


Nits:

s/interval interval/interval

[VPB] Fixe= d in -07


When defining the new capability advertisements (in 2.2.1 and 2.3.1), it wo= uld
be nice to include a reference to rfc5063.

<= div>[VPB] Fixed in -07


Given the specification in the preceding sections, I think that 2.2.2 and 2= .3.2
are superfluous.

[VPB] The two "Co= mpatibility" sections were added to address specific WG LC comments. I= f this continues to be a concern, we can consider rolling the text in these= sections into the preceding sections.


It would be nice to point at the Appendix from the main text.




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

--089e08230ea4204bdd055a3760de-- From nobody Wed Sep 27 20:41:41 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C7B135299; Wed, 27 Sep 2017 20:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, 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 bAF_63fWVnx6; Wed, 27 Sep 2017 20:41:33 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01B413292A; Wed, 27 Sep 2017 20:41:33 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id n69so467037ioi.5; Wed, 27 Sep 2017 20:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9dxpjCGJypdq9kXz3AC9zzygEDSHc5GvPKFSSK+oe0w=; b=ulvl/L2orLdeGCoB38gv8LhI3tlxQ0UksPlVnxLsla6Z8l+RTQ3BZlUdcCv7lD1oUZ 5SjZGixlmw+Er9ZYyYwtb8foARZfSmLwM55nOnYr6bfplKrSz9yi8aNVk35NCCFkJL2/ VtSbxAP3W38BJXDy/uVxtDcqDIeYB6KVZrI24SY1xknkj5yVQPV2dF7WoerAzaoVezd/ qAeI/r4nUH/W6tiQu3V+5bPL/cqOho2rIA/ZFrS9ouAaIWMNqdu04/gWmStsGgA/EeLk ojTQUejlculbatwhNmftT18eSOWkIGDm7CQuweYjZETtKIaK4uwpwFDg9EpWf6ULDVh5 X8iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9dxpjCGJypdq9kXz3AC9zzygEDSHc5GvPKFSSK+oe0w=; b=Emip+glGdXe6uYhyVa3dhpNabzb2qM1qZhQ+H+br47NXTZAX2REeR8M5Wkvd4Sl9W2 e7ZX249dNUvn/iWW5Wqxrn1MNGBvP2bguEKnERnEqzzycYxUbX+yM66ScXx/oZhFGoTv 9NZDjv+Tnkkgb0ioxroU5BB2Wqxj+E0/oQu5hJUOwnL5NBxPA6CknYjM7V+vy/3d7TZg i3Q58c+FCMQ81J/dBL/X5urFBsNRVYMWLx4kmRb/MDwBQJnNGOrCCHu/n5xKWZiPH7lu 079Uq9lqHDUiogNT9Q2AizrDLFQAl6T4QH6CGmt0TyNMz3ZiW/hNvxFAfTduQPXboa5T m5Tg== X-Gm-Message-State: AMCzsaWBLVAtwW0rrrI8pgig4wGGGYKA/4KUz5004cZJqyDCcIudieeK ptMuZfSTkoLaoNR56uB6BTaVkzY8bw7D4Fp8H3I= X-Google-Smtp-Source: AOwi7QBNkcuv1/bA0/EZoNF7x8SoQ+WX+0O0TE2qAvoruyD5+aN5z6IPgGzQnB8ArypG/sK63xiNmy3p3GLBbEJvDgk= X-Received: by 10.107.188.199 with SMTP id m190mr5386064iof.255.1506570093185; Wed, 27 Sep 2017 20:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Wed, 27 Sep 2017 20:41:32 -0700 (PDT) In-Reply-To: <150640829065.13776.15807950505251240274.idtracker@ietfa.amsl.com> References: <150640829065.13776.15807950505251240274.idtracker@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Wed, 27 Sep 2017 23:41:32 -0400 Message-ID: To: Spencer Dawkins Cc: The IESG , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, TEAS WG Chairs , "teas@ietf.org" , Lou Berger Content-Type: multipart/alternative; boundary="94eb2c05d4703bd110055a37af26" Archived-At: Subject: Re: [Teas] Spencer Dawkins' No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 03:41:36 -0000 --94eb2c05d4703bd110055a37af26 Content-Type: text/plain; charset="UTF-8" Spencer, Hi! Thanks for the review. We just posted a new revision (-07) to address the Gen-Art review comments. Please go through the new diffs ( https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-07) and let us know if additional changes are required. Please see inline for response to your comment (prefixed VPB). Regards, -Pavan On Tue, Sep 26, 2017 at 2:44 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm confused by this SHOULD. > > The configurable periodic > retransmission interval for this slower timer SHOULD be less than the > regular refresh interval. > > Could you help me understand why someone would want to set the "slower > timer" > to be shorter than the regular refresh timer? > [VPB] This is because we are advocating the use of a large value for the regular refresh interval (20 mins is the recommended default). On reaching the rapid retry limit (rl) for Path/Resv, we need to keep periodically retransmitting this message at a not so rapid rate (till an ack is received). This retransmission interval cannot be as large as the regular refresh interval and has to be reasonably smaller (30 secs is the recommeded default). > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --94eb2c05d4703bd110055a37af26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Spencer, Hi!

Thanks for= the review. We just posted a new revision (-07) to=20 address the Gen-Art review comments. Please go through the new diffs (https://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-teas-rsvp-te-scaling-rec-07) and let us know if additional chang= es are required.

Please see inline for response to= your comment (prefixed VPB).

Regards,
-Pavan



On Tue, Sep 26, 2017 at 2:44 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
Spencer Dawkins has entered the = following ballot position for
draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection

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


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/d<= wbr>oc/draft-ietf-teas-rsvp-te-scaling-rec/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I'm confused by this SHOULD.

=C2=A0 =C2=A0The configurable periodic
=C2=A0 =C2=A0retransmission interval for this slower timer SHOULD be less t= han the
=C2=A0 =C2=A0regular refresh interval.

Could you help me understand why someone would want to set the "slower= timer"
to be shorter than the regular refresh timer?

[VPB] This is because we are advocating the use of a large value for= the regular refresh interval (20 mins is the recommended default). On reac= hing the rapid retry limit (rl) for Path/Resv, we need to keep periodically= retransmitting this message at a not so rapid rate (till an ack is receive= d). This retransmission interval cannot be as large as the regular refresh = interval and has to be reasonably smaller (30 secs is the recommeded defaul= t).



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

--94eb2c05d4703bd110055a37af26-- From nobody Wed Sep 27 20:45:34 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB3A13529D; Wed, 27 Sep 2017 20:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL9Jo1v_DNBV; Wed, 27 Sep 2017 20:45:26 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA45132F3F; Wed, 27 Sep 2017 20:45:26 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id c195so704185itb.1; Wed, 27 Sep 2017 20:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PKgHPVDUw8dwExhsj8fJm97kNmev4Tl4eRu7qXz6+ds=; b=CQyXCCHQoDosh+6vKMCAfUyZ9NDASBirVActobV6lDq3bNd3QDh2OqXA1erkIJuBmH 9JVbRQM0bQGA4IoFiQr2rive7AzYgNdNbLwT05oQLMV8b1U5gC04P1eCJ75ehSWPxlUv lz79TnxmppR0qMXWe1QOodNsoYTnCI3tgqcdyORNnRMqqnHawrQf1PBUa9YBfPZYh4L+ 5+Ofh+EgLcgCTiLlqYQMxD4dy06gvdVcrXreaXufzdBomSDKKkFptia+t6GVR1EF7K8n k+TBzmDtde3BmLoHRuAkMy8f1BLSc198q8ykAsPDyotmXSbW8aW28NWCeQ72jSbuoTwB FpBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PKgHPVDUw8dwExhsj8fJm97kNmev4Tl4eRu7qXz6+ds=; b=uipR8NmVa/vsNBTQ035G66JRv2cZvuojI1QkVWbV90h81AeOAxisQNpdJaKq43fQqw vA3ceL7D6s8F1+b5q9AK8sYaj8LMQjCsxf7mKZXMlbzqk5+kFRE3fVNIkI/D0YRb9MhO qX9DGp+0YH+v/qWsnfteEgI0cUAA3RG0D6wI2SL8kYHvudX1vOZONB7ayKttPEHFYhiT 2AVf90WjYlNnsItXYcVobfmfi+S/dgr/0GCq8yLU/r/C7oB4+toWflhTMYspIOlTT/0T unJdmPhyJjmNRJdZ8A5u71DLSIM53CJqkJ1ouCRfWHmljQYKVOfH5HKtTS27gR5rpVDa Hh4A== X-Gm-Message-State: AMCzsaV+UbMDbNunHiVB3lClx5F/op/UmUpzci7I82GBbS2356FE7yZc cvbg68Fp+qP/Ezn0Pn6kIW6FP1bUeSMG5clXkWE= X-Google-Smtp-Source: AOwi7QD7c4z/44PTrq8SdTq1XanOELngPOwwXC96j04I66u9jQjXWh/JTv2AbkUV+V3c9mRcy8BU8ftV5pVDHSGm4FI= X-Received: by 10.36.177.9 with SMTP id o9mr1956872itf.44.1506570325946; Wed, 27 Sep 2017 20:45:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Wed, 27 Sep 2017 20:45:25 -0700 (PDT) In-Reply-To: <150644890311.20830.6212136664552694640.idtracker@ietfa.amsl.com> References: <150644890311.20830.6212136664552694640.idtracker@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Wed, 27 Sep 2017 23:45:25 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, TEAS WG Chairs , "teas@ietf.org" , Lou Berger Content-Type: multipart/alternative; boundary="089e08230ea41b76eb055a37bda3" Archived-At: Subject: Re: [Teas] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?teas-rsvp-te-scaling-rec-06=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 03:45:29 -0000 --089e08230ea41b76eb055a37bda3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mirja, Hi! Thanks for the review. We just posted a new revision (-07) to address the Gen-Art review comments. Please go through the new diffs ( https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-scaling-rec-07) and let us know if additional changes are required. Also, please go through the responses provided to the other review comments and let us know if there are still any unanswered questions. Regards, -Pavan On Tue, Sep 26, 2017 at 2:01 PM, Mirja K=C3=BChlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-teas-rsvp-te-scaling-rec-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm uncertain what section 2.1.3. actually recommends. My understanding i= s > that > it is recommend to still send retransmit some message even if the Rl was > reached and to that every 30s basically forever. First of all I think thi= s > still needs a termination criteria when to stop to try to retransmit > finally. > And the I don't understand why this is needed, instead of e.g. just using= a > larger Rl value? Can you please clarify! > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that th= is > reads from time to time like a BCP but is actually a extension > specification. I > would strongly recommend to apply the changes proposed by the gen-art > review, > and there is also a very detailed list of nits/edits that should probably > be > applied. Please have a look at that! > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --089e08230ea41b76eb055a37bda3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mirja, Hi!

Thanks for t= he review. We just posted a new revision (-07) to=20 address the Gen-Art review comments. Please go through the new diffs (https://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-teas-rsvp-te-scaling-rec-07) and let us know if additional chang= es are required.

Also, please go through the = responses provided to the other review comments and let us know if there ar= e still any unanswered questions.

Regards,
-Pavan



On Tue, Sep 26, 2017 at 2:01 PM, Mirja K= =C3=BChlewind <ietf@kuehlewind.net> wrote:
Mirja K=C3=BChlewind has entered the = following ballot position for
draft-ietf-teas-rsvp-te-scaling-rec-06: Discuss

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


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

I'm uncertain what section 2.1.3. actually recommends. My understanding= is that
it is recommend to still send retransmit some message even if the Rl was reached and to that every 30s basically forever. First of all I think this<= br> still needs a termination criteria when to stop to try to retransmit finall= y.
And the I don't understand why this is needed, instead of e.g. just usi= ng a
larger Rl value? Can you please clarify!


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this=
reads from time to time like a BCP but is actually a extension specificatio= n. I
would strongly recommend to apply the changes proposed by the gen-art revie= w,
and there is also a very detailed list of nits/edits that should probably b= e
applied. Please have a look at that!


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

--089e08230ea41b76eb055a37bda3-- From nobody Wed Sep 27 20:47:15 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCAE13529F; Wed, 27 Sep 2017 20:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sibIa05q1G4d; Wed, 27 Sep 2017 20:47:07 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBA813529D; Wed, 27 Sep 2017 20:47:07 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id d192so749611itd.1; Wed, 27 Sep 2017 20:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LlZG/F2Pd80Tv69S1FsBS5qGEzHiJhOjh3dsQ+xwLmo=; b=koZoFgkN66PUZwyh3nCB3VlqFMu7JknQbjcb5EgQ0vwerWYsEM03lpbHfNnnHQ0mMg 3clDNUScjEY97Wwtuljr91ZQNJWfatssiKuo7xttNBxlODU8I0cD4P4O9zJk1keOZysg XQ29ESptK/5vptm87BoRLzcfd5jDxgTHiqCSREq+mUwl0932aiU325XTjDzsPnrlspU4 W9/XDx6npAR1239cQQssrkHopZMRxeTsg2A+FuR8pfqsxSVbaPTQI6zsJISL3R+MKq+f dBRAdPWQvmmiGPlISDPerfxcTTAZGgursYCF92YgPzEUrLuHj/6BnXs+ZQbWXKehvkZX a8/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LlZG/F2Pd80Tv69S1FsBS5qGEzHiJhOjh3dsQ+xwLmo=; b=DmBCXhBvVB2jPCA2WyZ3L43/2AadXzB7LEOHI7hmz33OAblDkje9Hb6+VPVBDyzpZ6 itnAoNlDh+XWf9oOEGaBnWVJ7iEWNWyY7cnC+TvtOjpibocQeIPqYTzki7zKAq/1N2MZ +UYqamtG+YXuRXSfFetHw3nuwJgeo30F8EtfuwmY3TtQTfKTsRgcFY3lX8/utR3Bggpg 1s5ZmJm3SXPlT3cGbrnxp433hgTVtHE0Cn7A8TKXPQKbVneirKO0qzt1EuemI5osA4kd Q/UJ3HP6BH6Zw3AeVdDWIxtJUZOPlbuR1EsHmPbTvbkx7ltPZZijUkly0T8Hj5utZcAD zJvg== X-Gm-Message-State: AHPjjUizjZhshHtmucotKdJYApStpISg2zZoExJBHfqL9T7LJu7NLHJm 4VpvBfXRY/US7WS4AeCLz9sJf3E9nzL+/Xcoa1X9RCwI X-Google-Smtp-Source: AOwi7QBdV4XafBOAUSgSnxHHEzwHyQUnABmpHtNTvoQbggGFLynEQjWEFcp/3USCF/pIQNHcfF4Ixf0xdJqZHQvIsAs= X-Received: by 10.36.140.77 with SMTP id j74mr3735516itd.95.1506570427019; Wed, 27 Sep 2017 20:47:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Wed, 27 Sep 2017 20:47:06 -0700 (PDT) In-Reply-To: <150648943832.24979.8479092732800144290.idtracker@ietfa.amsl.com> References: <150648943832.24979.8479092732800144290.idtracker@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Wed, 27 Sep 2017 23:47:06 -0400 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, TEAS WG Chairs , "teas@ietf.org" , Lou Berger Content-Type: multipart/alternative; boundary="001a1145eee821b7ee055a37c313" Archived-At: Subject: Re: [Teas] Adam Roach's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 03:47:10 -0000 --001a1145eee821b7ee055a37c313 Content-Type: text/plain; charset="UTF-8" Adam, Hi! Thanks for the review. We just posted a new revision (-07) to address the Gen-Art review comments. Please go through the new diffs ( https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-07) and let us know if additional changes are required. Also, please go through the responses provided to the other review comments and let us know if there are still any unanswered questions. Regards, -Pavan On Wed, Sep 27, 2017 at 1:17 AM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have some reservations around certain aspects of the document, but > they've > largely been captured by other IESG members. I'll reiterate two of them > here, > phrased as concrete suggestions. > > Change the title to something more like "Protocol Enhancements to > Improve...", > and rephrase all uses of the word "recommendation" to instead refer to the > techniques described in the document. > > Clarify that the retransmission of messages described in section 2.1.3 > does not > continue for years or decades: specify a limit after which retransmission > ceases even without an ACK. > > Please expand the following acronyms upon first use and in the title; > see https://www.rfc-editor.org/materials/abbrev.expansion.txt for > guidance. > > - RSVP-TE - RSVP Traffic Engineering > - LSR - Label Switching Router > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a1145eee821b7ee055a37c313 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adam, Hi!

Thanks for th= e review. We just posted a new revision (-07) to=20 address the Gen-Art review comments. Please go through the new diffs (https://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-teas-rsvp-te-scaling-rec-07) and let us know if additional chang= es are required.

Also, please go through the responses provided to the other review comments=20 and let us know if there are still any unanswered questions.
=
Regards,
-Pavan

On Wed, Sep 27, 2017 at 1:17 AM, Adam Roach <adam@nostrum.= com> wrote:
Adam Roach has = entered the following ballot position for
draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection

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


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I have some reservations around certain aspects of the document, but they&#= 39;ve
largely been captured by other IESG members. I'll reiterate two of them= here,
phrased as concrete suggestions.

Change the title to something more like "Protocol Enhancements to Impr= ove...",
and rephrase all uses of the word "recommendation" to instead ref= er to the
techniques described in the document.

Clarify that the retransmission of messages described in section 2.1.3 does= not
continue for years or decades: specify a limit after which retransmission ceases even without an ACK.

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materia= ls/abbrev.expansion.txt for guidance.

=C2=A0- RSVP-TE - RSVP Traffic Engineering
=C2=A0- LSR - Label Switching Router


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

--001a1145eee821b7ee055a37c313-- From nobody Wed Sep 27 20:49:45 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BE4135298; Wed, 27 Sep 2017 20:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmkkvhg3v1GU; Wed, 27 Sep 2017 20:49:40 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B0C135269; Wed, 27 Sep 2017 20:49:40 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l15so469784iol.8; Wed, 27 Sep 2017 20:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zjc8h+0dmY9BorAcSGhodOhRb7bsw55kVNUFhb6YHhE=; b=Xllt1FOROyQDSRfgwg6PijQuSDJgpXmVg1mwroqjjpshCq7s7vqfXnUoPtGpPGVtpU bSav3iLnltOIshTmZmBQdsZbzJa+95RK8Ax8xNmh6BG8DMQHI970u5V0g3Azdf++w3Ff NNmwwtchjhp10jOQGoWD6VuHe1n81nz0ZrUEQ+2O6ci4Nef0aQrSK70hf/MlWJKTEvFZ PhKZ/S8RBOstRwVBRQV8gurdWe5D9pott2F8E4Cm2yz1jMAzq9rK2fgeKA6eXgZlRH6V xwP2Q1dW5cshLB54z8anuRuTa8I4nYR7s0HHh59fDyP/TBDU6JwnY7goGSOBl9/8VUhq Ch4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zjc8h+0dmY9BorAcSGhodOhRb7bsw55kVNUFhb6YHhE=; b=eko+G/WVt9a9ZLQZSl5IgB+d52DgxvvSm+FnvH1j8K6oC24DeBnVGt/x7HJBwXMr2C pAIIoalm98/R/s78BRH0v008P0WqgMh3P4FXTNWlnGR5Vnahe5hyRRvzhzUgwSXBZUs2 mBa4cttJyNW/E4qq3qpRSGuQvoWiegxRfpzwM0ZDGrbPo8AZ13WLVVob8uuaWJQ6/XbA sfgrH2iwIhvHt4YQJCuiJSsBkWQ48PqVmWwKqLIJfyLRsrBv3S7+HLj9nCZFaWPesOuG DrULzhFtem/v0mB4T7ifRbNfwg3j908WyxktiBVBQQCmmyzyKcOH8ZWWENbPHDTgzKHN Afig== X-Gm-Message-State: AMCzsaVpmFIPoFaqZpsusoay8zngK9+Ts16AG+rbRKHVLLYJtabjxo4a UPRVnwhCj3+c5KDgVnT+YmV73QmVQfhF7iOxK7fNRs4k X-Google-Smtp-Source: AOwi7QDJ0Lu79DTSREiS0AZEsR2rhszSKgN2DkGQXo/l/x8UUkrztLAZFpJkaMxP9so0ag/AxHIeADqF/OavP7wI+80= X-Received: by 10.107.132.87 with SMTP id g84mr5820290iod.272.1506570579619; Wed, 27 Sep 2017 20:49:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.216 with HTTP; Wed, 27 Sep 2017 20:49:39 -0700 (PDT) In-Reply-To: <150656145760.13808.17318350937488343363.idtracker@ietfa.amsl.com> References: <150656145760.13808.17318350937488343363.idtracker@ietfa.amsl.com> From: Vishnu Pavan Beeram Date: Wed, 27 Sep 2017 23:49:39 -0400 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, TEAS WG Chairs , "teas@ietf.org" , Lou Berger Content-Type: multipart/alternative; boundary="001a113f32883a3679055a37cc44" Archived-At: Subject: Re: [Teas] Ben Campbell's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-07: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 03:49:43 -0000 --001a113f32883a3679055a37cc44 Content-Type: text/plain; charset="UTF-8" Ben, Hi! Thanks for the review. We just posted a new revision (-07) to address the Gen-Art review comments. Please go through the new diffs ( https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-07) and let us know if the new narrative addresses all of your concerns. Regards, -Pavan On Wed, Sep 27, 2017 at 9:17 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-teas-rsvp-te-scaling-rec-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [Note: The authors revised this draft between the time I reviewed it and > transcribed my notes. This is a review of version 06. I will not have time > to > re-review 07 prior to the telechat to see if my comments still apply.] > > Substantive: > > - General: I agree with the "major issues" comments from Elwyn's Gen-ART > review. > > - General: There's a fair amount of 2119 language in this draft that > refers to > options in prior RFCs. It's not clear which of those are new normative > requirements vs restatements of existing requirements. In the former case, > this > draft would need to update those respective RFCs. In the latter case, this > draft should use descriptive language rather than 2119 keywords (unless in > the > form of direct quotes.) > > -1, last paragraph: "In order to reap maximum scaling benefits, it is > strongly RECOMMENDED that implementations support both the > techniques." > > That statement seems to require updating ... something. Maybe 3209 or 2961? > > -2.1.3, 2nd paragraph: Does this update RFC 2961? Or if not, is the > normative > language appropriate here? > > -2.2, bullet list: Are these new normative requirements or restatements of > existing ones? > > -6: "This document does not introduce new security issues." > Please document the reasoning behind that statement. > > Editorial: > > -2.1, section title: Why the quotes? > > -2.2, first bullet: Section 1 already normatively states these. This text > effectively says "MUST follow the MUSTs...". (Note that this pattern > recurs in > several places.) > > -2.3, first paragraph: "The set of recommendations discussed in this > section..." > As written, many of those are requirements rather than recommendations. > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a113f32883a3679055a37cc44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben, Hi!

Thanks for the= review. We just posted a new revision (-07) to=20 address the Gen-Art review comments. Please go through the new diffs (https://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-teas-rsvp-te-scaling-rec-07) and let us know if the new narrativ= e addresses all of your concerns.


R= egards,
-Pavan

On Wed, Sep 27, 2017 at 9:17 PM, Ben Campbell <<= a href=3D"mailto:ben@nostrum.com" target=3D"_blank">ben@nostrum.com>= wrote:
Ben Cam= pbell has entered the following ballot position for
draft-ietf-teas-rsvp-te-scaling-rec-07: No Objection

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


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

[Note: The authors revised this draft between the time I reviewed it and transcribed my notes. This is a review of version 06. I will not have time = to
re-review 07 prior to the telechat to see if my comments still apply.]

Substantive:

- General: I agree with the "major issues" comments from Elwyn= 9;s Gen-ART review.

- General: There's a fair amount of 2119 language in this draft that re= fers to
options in prior RFCs. It's not clear which of those are new normative<= br> requirements vs restatements of existing requirements. In the former case, = this
draft would need to update those respective RFCs. In the latter case, this<= br> draft should use descriptive language rather than 2119 keywords (unless in = the
form of direct quotes.)

-1, last paragraph: "In order to reap maximum scaling benefits, it is<= br> =C2=A0 =C2=A0strongly RECOMMENDED that implementations support both the
=C2=A0 =C2=A0techniques."

That statement seems to require updating ... something. Maybe 3209 or 2961?=

-2.1.3, 2nd paragraph: Does this update RFC 2961?=C2=A0 Or if not, is the n= ormative
language appropriate here?

-2.2, bullet list: Are these new normative requirements or restatements of<= br> existing ones?

-6: "This document does not introduce new security issues."
Please document the reasoning behind that statement.

Editorial:

-2.1, section title: Why the quotes?

-2.2, first bullet: Section 1 already normatively states these. This text effectively says "MUST follow the MUSTs...". (Note that this patt= ern recurs in
several places.)

-2.3, first paragraph: "The set of recommendations discussed in this s= ection..."
As written, many of those are requirements rather than recommendations.


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

--001a113f32883a3679055a37cc44-- From nobody Thu Sep 28 00:04:31 2017 Return-Path: X-Original-To: teas@ietf.org Delivered-To: teas@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C47135247; Thu, 28 Sep 2017 00:04:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, Lou Berger , teas-chairs@ietf.org, lberger@labn.net, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150658226963.13768.11732695217527397352.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 00:04:29 -0700 Archived-At: Subject: [Teas] Suresh Krishnan's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-07: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 07:04:30 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-teas-rsvp-te-scaling-rec-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben that it is not clear which recommendations are from this document and which ones are restatements from other documents. Some of these recommendations originating from this document look like they might be updating RFC2961. Why does this draft not update RFC2961 formally? It was not immediately apparent from the shepherd write up if the WG had considered this. From nobody Thu Sep 28 05:33:36 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0E1134705; Thu, 28 Sep 2017 05:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NmaQTCgIPth; Thu, 28 Sep 2017 05:33:28 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631AA134684; Thu, 28 Sep 2017 05:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7006; q=dns/txt; s=iport; t=1506602008; x=1507811608; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dUML2cw2T4AUOKitSfv9gHpTzqrdRNYw5gDwwSbKOUg=; b=kcf/LUntGwJU9PLkVMxT0zuFUIMkZVGrLbLWg+QT96vbomTT/H5uY420 zDcAF/YNg/WJTNzIiqdguKvFnmZPVQ9mX+ywHPNreBKm9OlnJFVUw1YKs fJUCN3YCS36w6f3sEaga1elxZ7wLRbMkNz6UGgDKssjHZkoshNdz9RfRA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAwDr68xZ/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9tZG4nB4NxmX6BVIhkiCuHUAqFOwIahAZXAQIBAQEBAQJrKIU?= =?us-ascii?q?ZBiNWEAIBCD8DAgICHxEUEQIEDgUfiS5MAxWmdIInJ4cSDYM7AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYMrggKBUYIVC4Jygl6FOS+CMQWYUYgbPAKPZYR5ghOFbos?= =?us-ascii?q?FihCCXIg0AhEZAYE4AVeBDngVWwGFPIFOdod1gRABAQE?= X-IronPort-AV: E=Sophos;i="5.42,450,1500940800"; d="scan'208,217";a="9359576" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Sep 2017 12:33:22 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8SCXLPu016695 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Sep 2017 12:33:21 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 28 Sep 2017 07:33:21 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1320.000; Thu, 28 Sep 2017 07:33:21 -0500 From: "Alvaro Retana (aretana)" To: Vishnu Pavan Beeram CC: The IESG , "draft-ietf-teas-rsvp-te-scaling-rec@ietf.org" , TEAS WG Chairs , "teas@ietf.org" , Lou Berger Thread-Topic: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT) Thread-Index: AQHTNgpbko1OJyOl2Ea54AwTMadvWaLJ+OiAgABXtQA= Date: Thu, 28 Sep 2017 12:33:21 +0000 Message-ID: <7F5E6E3A-04DA-4960-94C2-7E66F960C426@cisco.com> References: <150634961899.27517.2676098033688714820.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_7F5E6E3A04DA496094C27E66F960C426ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 12:33:31 -0000 --_000_7F5E6E3A04DA496094C27E66F960C426ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF2YW46DQoNCkhpIQ0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGUhDQoNCk1heWJlIGEgbml0LCBi dXQgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhhdCB0aGUg cmZjMjk2MSByZWNvbW1lbmRhdGlvbiBieSB0aGVtc2VsdmVzIHdvbuKAmXQgZG8gbXVjaC4NCg0K VGhhbmtzIQ0KDQpBbHZhcm8uDQoNCk9uIDkvMjcvMTcsIDExOjE5IFBNLCAiVmlzaG51IFBhdmFu IEJlZXJhbSIgPHZpc2hudXBhdmFuQGdtYWlsLmNvbTxtYWlsdG86dmlzaG51cGF2YW5AZ21haWwu Y29tPj4gd3JvdGU6DQoNCg0KKDEpIFRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gZG8gdHdvIHRoaW5n czogbWFrZSBhIHNlcmllcyBvZiByZmMyOTYxDQpyZWNvbW1lbmRhdGlvbnMsIGFuZCBpbnRyb2R1 Y2UgYSBjb3VwbGUgb2YgbmV3IHRlY2huaXF1ZXMuICBXaGF0IGlzIG5vdCBjbGVhcg0KdG8gbWUg aXMgd2hldGhlciB0aGUgZmlyc3QgcGFydCBpcyBpbmRlcGVuZGVudCBvZiB0aGUgc2Vjb25kLiAg V2lsbCB0aGUNCmltcGxlbWVudGF0aW9uIG9mIFNlY3Rpb24gMi4xLiAoIlJGQzI5NjEgU3BlY2lm aWMiIFJlY29tbWVuZGF0aW9ucykgcHJvdmlkZQ0Kc2NhbGluZyBiZW5lZml0cyBvbiB0aGVpciBv d24gKGkuZS4gd2l0aG91dCB0aGUgbmV3IHRlY2huaXF1ZXMpPyAgSWYgc28sIHBsZWFzZQ0KYWRk IHNvbWUgdGV4dCAobWF5YmUgaW4gdGhlIEludHJvZHVjdGlvbikgdG8gaW5kaWNhdGUgdGhhdC4N Cg0KW1ZQQl0gVGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBSRkMyOTYxIHNwZWNpZmljIHJlY29t bWVuZGF0aW9ucyAoU2VjdGlvbiAyIGluIHJldiAtMDcpIGFsb25lIHdpbGwgbm90IHByb3ZpZGUg YW55IHNpZ25pZmljYW50IGltcHJvdmVtZW50IHRvIHRoZSBleGlzdGluZyBzY2FsaW5nIG51bWJl cnMuDQoNCg0K --_000_7F5E6E3A04DA496094C27E66F960C426ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5v cm1hbDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28t c3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGF2YW46PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSB1 cGRhdGUhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIGEgbml0LCBidXQgSSB0aGluayBp dCB3b3VsZCBiZSBnb29kIHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhhdCB0aGUgcmZjMjk2MSByZWNv bW1lbmRhdGlvbiBieSB0aGVtc2VsdmVzIHdvbuKAmXQgZG8gbXVjaC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHZhcm8uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOS8yNy8xNywgMTE6MTkgUE0sICZxdW90 O1Zpc2hudSBQYXZhbiBCZWVyYW0mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2aXNobnVwYXZh bkBnbWFpbC5jb20iPnZpc2hudXBhdmFuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluO2ZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFyZCZx dW90OyxzZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KKDEpIFRoaXMgZG9jdW1lbnQgc2VlbXMgdG8g ZG8gdHdvIHRoaW5nczogbWFrZSBhIHNlcmllcyBvZiByZmMyOTYxPGJyPg0KcmVjb21tZW5kYXRp b25zLCBhbmQgaW50cm9kdWNlIGEgY291cGxlIG9mIG5ldyB0ZWNobmlxdWVzLiZuYnNwOyBXaGF0 IGlzIG5vdCBjbGVhcjxicj4NCnRvIG1lIGlzIHdoZXRoZXIgdGhlIGZpcnN0IHBhcnQgaXMgaW5k ZXBlbmRlbnQgb2YgdGhlIHNlY29uZC4mbmJzcDsgV2lsbCB0aGU8YnI+DQppbXBsZW1lbnRhdGlv biBvZiBTZWN0aW9uIDIuMS4gKCZxdW90O1JGQzI5NjEgU3BlY2lmaWMmcXVvdDsgUmVjb21tZW5k YXRpb25zKSBwcm92aWRlPGJyPg0Kc2NhbGluZyBiZW5lZml0cyBvbiB0aGVpciBvd24gKGkuZS4g d2l0aG91dCB0aGUgbmV3IHRlY2huaXF1ZXMpPyZuYnNwOyBJZiBzbywgcGxlYXNlPGJyPg0KYWRk IHNvbWUgdGV4dCAobWF5YmUgaW4gdGhlIEludHJvZHVjdGlvbikgdG8gaW5kaWNhdGUgdGhhdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQm cXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDstd2Via2l0LXN0YW5kYXJkJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5bVlBCXSBU aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIFJGQzI5NjEgc3BlY2lmaWMgcmVjb21tZW5kYXRpb25z IChTZWN0aW9uIDIgaW4gcmV2IC0wNykgYWxvbmUgd2lsbCBub3QgcHJvdmlkZSBhbnkgc2lnbmlm aWNhbnQgaW1wcm92ZW1lbnQgdG8gdGhlIGV4aXN0aW5nIHNjYWxpbmcgbnVtYmVycy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7F5E6E3A04DA496094C27E66F960C426ciscocom_-- From nobody Fri Sep 29 10:50:41 2017 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D0213337F; Fri, 29 Sep 2017 10:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 ZNP7slYlcV8Y; Fri, 29 Sep 2017 10:50:31 -0700 (PDT) Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [81.187.30.51]) (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 56775128D0D; Fri, 29 Sep 2017 10:50:31 -0700 (PDT) Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[192.168.0.128]) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dxzB3-0004et-T6; Fri, 29 Sep 2017 18:34:21 +0100 Date: Fri, 29 Sep 2017 18:34:09 +0100 Message-ID: <8wh65ldo8qkrghsf29x4nukb.1506702288623@email.android.com> Importance: normal From: Elwyn Davies To: Vishnu Pavan Beeram Cc: gen-art@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec.all@ietf.org, ietf , "teas@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_154488561075070" Archived-At: Subject: Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 17:50:39 -0000 ----_com.samsung.android.email_154488561075070 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CgpIaSwgUGF2YW4uCkkndmUgY2hlY2tlZCB0aHJvdWdoIHRoZSBjaGFuZ2VzIGluIC0wNyBhbmQg SSB0aGluayBhbGwgaXMgZ29vZCBhcyByZWdhcmRzIGZpeGluZyB0aGUgJ21ham9yIGlzc3VlJywg cmVzdHVjdHVyaW5nIHMyIGFuZCBmaXhpbmcgdGhlIG5pdHMgLSB0aGFua3MuCkxvb2tpbmcgYXQg dGhlIElFU0cgY29tbWVudHMgSSB0aGluayB5b3UgaGF2ZSBjb3ZlcmVkIG1vc3Qgb2YgdGhlbcKg IGV4Y2VwdCBpdCB3b3VsZCBiZSBnb29kIHRvIHB1dCBhIHBvaW50ZXIgdG8gQXBwZW5kaXggQSBp bnRvIHRoZSBpbnRybyBvZiBzMi7CoApXaXRoIHJlZmVyZW5jZSB0byBBcHBlbmRpeCBBKGQpLCBp dCB3b3VsZCBiZSBoZWxwZnVsIHRvIHMvcGVyaW9kaWMgcmV0cmFuc21pc3Npb24gaW50ZXJ2YWwv UGVyaW9kaWMgUmV0cmFuc21pc3Npb24gSW50ZXJ2YWwvIGFuZCBwb3NzaWJseSBnaXZlIGl0IGEg bmFtZSAoUnByaSBvciBzb21lIHN1Y2gpwqAgaW4gczIuMyBhbmQgQXBwZW5kaXggQShkKS7CoCBB ZGRpbmcgdGhlIG5hbWUgb2YgdGhlIGludGVydmFsIGFmdGVyICJyZXRyYW5zbWlzc2lvbiBvZiB0 aGVzZSBvbiBhIHNsb3dlciB0aW1lciIgbWlndCBtYWsgaXQgY2xlYXJlciBhbHNvLgpIb3dldmVy LMKgIEkgdGhpbmsgeW91IHN0aWxsIG5lZWQgdG8gYWRkcmVzcyBhbGwgdGhyZWUgb2YgdGhlIG1p bm9yIGlzc3VlczotIENhcGFiaWxpdHkgb2JqZWN0OsKgIEEgJ2Jhc2ljJyBpbXBsZW1lbnRhdGlv biBvZiBSRkMgMjIwOS9SRkMzMjA5IHdpbGwgbm90IGluY2x1ZGUgdGhlIFJGQzUwNjMgZXh0ZW5z aW9ucy7CoCBJIHRoaW5rIHlvdSBzaG91bGQgdGhlcmVmb3JlIG1ha2UgaXQgZXhwbGljaXQgdGhh dCBhIHByZXJlcXVpc2l0ZSBmb3IgeW91ciBleHRlbnNpb25zIGlzIGFuIGltcGxlbWVudGF0aW9u IG9mIHRoZSBDYXBhYmlsaXR5IG9iamVjdCBhcyBzcGVjaWZpZWQgaW4gUkZDNTA2MyAobXkgcHJv cG9zYWwgZm9yIHMzKSAsIG1ha2luZyBpdCBjbGVhciB0aGF0IHRoaXMgZG9lcyBub3QgcmVxdWly ZSBhbnkgb2YgdGhlIG90aGVyIGZ1bmN0aW9uYWxpdHkgb2YgUkZDIDUwNjMsIGVzcGVjaWFsbHkg bm8gc3VwcG9ydCBmb3IgdGhlIFMgYml0IGluIHRoZSBDYXBhYmlsaXRpZXMuLcKgIFlvdXIgcmVz cG9uc2UgcmVnYXJkaW5nIHdoYXQgaGFwcGVucyBpZiBhIHBlZXIgaW5pdGlhbGx5IGFja25vd2xl ZGdlcyB0aGF0IGl0IHN1cHBvcnRzIHRoZSBuZXcgY2FwYWJpbGl0aWVzIGJ5IHNldHRpbmcgdGhl IEkvRiBiaXRzIGluIHRoZSBDYXBhYmlsaXR5IGFuZCBzZW5kcyBzb21lIG1lc3NhZ2VzIHdpdGgg dGhlIFJlZnJlc2gtUmVkdWN0aW9uLUNhcGFibGUgYml0IHNldCwgYnV0IHRoZW4gc3RvcHMgc2V0 dGluZyB0aGUgUmVmcmVzaC1SZWR1Y3Rpb24tQ2FwYWJsZSBiaXQgZG9lc24ndCByZWFsbHkgYWRk cmVzcyB0aGUgcHJvYmxlbS7CoCDCoFdvdWxkIHRoaXMgbWVhbiB0aGF0IHRoZSByZWNlaXZlciBz aG91bGQgYXNzdW1lIHRoYXQgdGhlIHBlZXIgY2FuIG5vIGxvbmdlciBzdXBwb3J0IHRoZSBleHRl bnNpb25zP8KgIElzIHRoaXMgYSBwZXJtYW5lbnQgc3RhdGUgb3IgY291bGQgdGhlIHBlZXIgc3Rh cnQgc2V0dGluZyB0aGUgUmVmcmVzaC1SZWR1Y3Rpb24tQ2FwYWJsZSBiaXQgYWdhaW4gYW5kIHJl c3RvcmUgaW5pdGlhbCBmdW5jdGlvbmFsaXR5IC0gb3Igc2hvdWxkIHRoaXMganVzdCBub3QgYmUg YWxsb3dlZC4gSSB0aGluayB5b3UgbmVlZCB0byB0aGluayB0aHJvdWdoIHdoYXQgaGFwcGVzIGlu IHRoZSB2YXJpb3VzIHBvc3NpYmxlIGNhc2VzIGFuZCBleHBsYWluIHdoYXQgYW4gaW1wbGVtZW50 YXRpb24gc2hvdWxkIGRvIGluIGVhY2ggY2FzZS4tIFNvLCBJIGhhdmUgZG9uZSBteSBob21ld29y ayBhbmQgY2hlY2tlZCBiYWNrIG9uIHdoYXQgaGFwcGVucyB3aGVuIHRoZXJlIGlzIG5vIGFja25v d2xlZGdlbWVudCBvZiByZWZyZXNoZXMuIFRoZSByZWxldmFudCBwYXJhbWV0ZXIgaXMgdGhlIGNs ZWFudXAgdGltZS7CoCBIb3dldmVyLCB0aGlzIGxlYXZlcyB1cyB3aXRoIGEgcHJvYmxlbS4uIHRo ZSBjbGVhbnVwIHRpbWUgaXMgdHlwaWNhbGx5IHNldCBhcyBhIG11bHRpcGxlIG9mIHRoZSByZWZy ZXNoIGludGVydmFsICg5IHRpbWVzIHNlZW1zIHRvIGJlIHRoZSBkZWZhdWx0KSAtIGluZGVlZCBJ IHNlZSB0aGF0IHRoZSBpbnRlcmZhY2UgY29uZmlndXJhdGlvbiBvbiBhIEp1bmlwZXIgcm91dGVy ICghKSBhY3R1YWxseSBzZXRzIGl0IGJ5IGFza2luZyBmb3IgdGhlIG11bHRpcGxlIHJhdGhlciB0 aGFuIGFuIGFic29sdXRlIHZhbHVlLsKgIFd0aCB0aGUgbmV3IGRpc3BlbnNhdGlvbiBpbiB0aHMg ZG9jdW1lbnQsIHRoZXJlIGFyZSB0d28gdGltZSBwZXJpb2RzIGludm9sdmVkOsKgIEkgdGhpbmsg eW91IGRvIG5lZWQgdG8gcmVzcGVjaWZ5IGhvdyB0byBjYWxjdWxhdGUgYSBzZW5zaWJsZSBjbGVh bnVwIGludGVydmFsLCBhbmQgbm90ZSB0aGF0IHRoZSByZXRyYW5zbWlzc2lvbnMgd2lsbCB0aGVu IGhhbHQgYWZ0ZXIgdGhpcyBpbnRlcnZhbC4KRG9lcyB0aGlzIGxhc3QgbW9kaWZpY2F0aW9uIGNv bnN0aXR1dGUgYW4gdXBkYXRlIG9mIFJGQyAyMjA5P8KgIEkgYW0gbm90IHN1cmUgLWNvbnN1bHQg eW91ciBBRCEKUmVnYXJkcyxFbHd5bsKgClNlbnQgZnJvbSBTYW1zdW5nIHRhYmxldC4KLS0tLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IFZpc2hudSBQYXZhbiBCZWVyYW0gPHZp c2hudXBhdmFuQGdtYWlsLmNvbT4gRGF0ZTogMjgvMDkvMjAxNyAgMDM6NDggIChHTVQrMDA6MDAp IFRvOiBFbHd5biBEYXZpZXMgPGVsd3luZEBkaWFsLnBpcGV4LmNvbT4gQ2M6IGdlbi1hcnRAaWV0 Zi5vcmcsIGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLXNjYWxpbmctcmVjLmFsbEBpZXRmLm9yZywg aWV0ZiA8aWV0ZkBpZXRmLm9yZz4sIHRlYXNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtUZWFzXSBH ZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zY2FsaW5n LXJlYy0wNiAKRWx3eW4sIEhpIQpUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcgYW5kIHRo ZSB0ZXh0IHN1Z2dlc3Rpb25zLiBXZSBqdXN0IHBvc3RlZCBhIG5ldyByZXZpc2lvbiAoLTA3KSB0 byBhZGRyZXNzIHRoZSBjb25jZXJucyBsaXN0ZWQgYmVsb3cuIFBsZWFzZSBnbyB0aHJvdWdoIHRo ZSBuZXcgZGlmZnMgKGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXRlYXMtcnN2cC10ZS1zY2FsaW5nLXJlYy0wNykgYW5kIGxldCB1cyBrbm93IGlmIGFkZGl0aW9u YWwgY2hhbmdlcyBhcmUgcmVxdWlyZWQuClBsZWFzZSBzZWUgaW5saW5lIGZvciBmdXJ0aGVyIHJl c3BvbnNlcyAocHJlZml4ZWQgVlBCKS4KClJlZ2FyZHMsCi1QYXZhbgoKT24gRnJpLCBTZXAgMjIs IDIwMTcgYXQgNjowNiBQTSwgRWx3eW4gRGF2aWVzIDxlbHd5bmRAZGlhbC5waXBleC5jb20+IHdy b3RlOgpSZXZpZXdlcjogRWx3eW4gRGF2aWVzCgpSZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHkKCgoK SSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdl bmVyYWwgQXJlYQoKUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZAoKYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLsKgIFBs ZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0CgpsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwg Y29tbWVudHMuCgoKCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQK CgoKPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcT4uCgoKCkRv Y3VtZW50OiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zY2FsaW5nLXJlYy0wNgoKUmV2aWV3ZXI6 IEVsd3luIERhdmllcwoKUmV2aWV3IERhdGU6IDIwMTctMDktMjIKCklFVEYgTEMgRW5kIERhdGU6 IDIwMTctMDktMjIKCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxNy0wOS0yOAoKCgpTdW1tYXJ5OiBO b3QgcmVhZHksIHByaW1hcmlseSBiZWNhdXNlIHRoZSB0aXRsZSBhbmQgcHJlc2VudGF0aW9uIGdp dmUgdGhlCgppbXByZXNzaW9uIHRoYXQgdGhlIGNvbnRlbnQgaXMgcmVhbGx5IGEgQkNQIHdoZW4g aXQgaXNuJ3QuwqAgVGhpcyBjb25jZWFscyB0aGUKCmNvbnNpZGVyYWJsZSBhbW91bnQgb2YgdHdl YWtpbmcgb2YgUkZDIDI5NjEgZnVuY3Rpb25hbGl0eSBhbmQgYWRkaXRpb24gb2YgbmV3CgpSU1ZQ IENhcGFiaWxpdGllcyBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LsKgIFRoZXJlIGFyZSBhbHNv IGEgY291cGxlIG9mIG1pbm9yCgppc3N1ZXMgdGhhdCBuZWVkIHRvIGJlIHNvcnRlZCBvdXQuCgoK Ck1ham9yIGlzc3VlczoKClRpdGxlIGFuZCB3YXkgcHJvcG9zYWxzIGFyZSBwcmVzZW50ZWQ6wqAg VGhlIGRvY3VtZW50IGRlZmluZXMgdHdvIG5ldwoKJ2NhcGFiaWxpdGllcycgZm9yIFJTVlAtVEUg YW5kIGlzIGluZGVlZCAoYXMgc3BlY2lmaWVkIGluIHRoZSBkb2N1bWVudCBoZWFkZXIpCgpjb3Jy ZWN0bHkgaW50ZW5kZWQgZm9yIFN0YW5kYXJkcyBUcmFjayBzdGF0dXMuwqAgSG93ZXZlciB0aGUg dGl0bGUgYW5kIHRoZSB3aG9sZQoKb2YgdGhlIG1lYXQgb2YgdGhlIGRvY3VtZW50IGluIFNlY3Rp b24gMiBwcmVzZW50cyB0aGUgcHJvcG9zYWxzIGFzCgoncmVjb21tZW5kYXRpb25zJyB3aGljaCBz YXlzIHRvIG1lIHRoYXQgSSBhbSBleHBlY3RpbmcgYSBCQ1Agd2hlcmUgYSBwcm9maWxlIG9mCgph dmFpbGFibGUgb3B0aW9ucyBmcm9tIGV4aXN0aW5nIHN0YW5kYXJkcyBpcyByZWNvbW1lbmRlZCBh cyB0aGUgYmVzdCBjaG9pY2UgZm9yCgppbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudC7CoCBJ biBteSBvcGluaW9uLCB0aGUgdGl0bGUgd291bGQgYmUgYmV0dGVyIGFzCgpzb21ldGhpbmcgbGlr ZSAiQWRkaXRpb25hbCBDYXBhYmlsaXRpZXMgRGVzaWduZWQgdG8gSW1wcm92ZSB0aGUgU2NhbGFi aWxpdHkgb2YKClJTVlAtVEUgRGVwbG95bWVudHMiLsKgIFdoaWxzdCB0aGUgcHJvcG9zYWxzIGFy ZSBiYXNlZCBvbiB0aGUgdGVjaG5pcXVlcyBpbiBSRkMKCjI5NjEsIHRoZSBkb2N1bWVudCAqcmVx dWlyZXMqIHRoZSBpbXBsZW1lbnRvciB0byBjb25mb3JtIHRvIHJ1bGVzIHRoYXQgd2VyZQoKb3B0 aW9uYWwgYW5kIGNvbnN0cmFpbnMgY29uZmlndXJhYmxlIHZhbHVlcyB0byBkaWZmZXJlbnQgcmFu Z2VzIGluIG9yZGVyIHRvIGJlCgphYmxlIHRvIGRlbGl2ZXIgdGhlIGNhcGFiaWxpdGllcyBkZWZp bmVkIGluIHRoZSBkb2N1bWVudCBhcyB3ZWxsIGFzIGRlZmluaW5nCgpuZXcgUlNWUCBleHRlbnNp b25zIG1vZGlmeWluZyBzb21lIG9mIHRoZSBiZWhhdmlvdXIgZGVmaW5lZCBpbiBSRkMgMjk2MS7C oCBUaHVzCgphbHRob3VnaCBzb21lIG9mIHRoZSBydWxlcyBjb3VsZCBiZSBtZXQgYnkgY2hvb3Np bmcgcGFydGljdWxhciB2YWx1ZXMgd2l0aGluCgp0aGUgUkZDIDI5NjEgc2V0LCB0aGUgdXNlIG9m IE1VU1QsIHR3ZWFraW5nIG9mIGZ1bmN0aW9uYWxpdHkgYW5kIHZhcmlhdGlvbiBvZgoKcmFuZ2Vz IHRha2VzIGl0IHdlbGwgYmV5b25kIGEgc2V0IG9mIHJlY29tbWVuZGF0aW9ucyBmb3IgUkZDIDI5 NjEgb3B0aW9ucwoKc2VsZWN0aW9ucy7CoCBJbiB2aWV3IG9mIHRoaXMgU2VjdGlvbiAxIG5lZWRz IHRvIGJlIHdyaXR0ZW4gYXMgYW4gaW50cm9kdWN0aW9uCgp0byB0aGUgZGVmaW5pdGlvbnMgb2Yg dGhlIG5ldyBjYXBhYmlsaXRpZXMgcmF0aGVyIHRoYW4gYWR2b2NhY3kgZm9yIHNlbGVjdGlvbgoK b2YgUkZDIDI5NjEgb3B0aW9ucyBhbmQgdGhlIGltcGxpY2F0aW9uIHRoYXQgdGhlIHRlY2huaXF1 ZXMgbWVudGlvbmVkIGluIHRoZQoKbGFzdCBwYXJhZ3JhcGggb2YgczEgYXJlIGp1c3QgYSBtYXR0 ZXIgb2Ygc2VsZWN0aW5nIGEgcHJvZmlsZSBvZiBvcHRpb24gdmFsdWVzLgoKwqBJbiBhY3R1YWxp dHkgbmV3IHByb3RvY29sIHZhbHVlcyBhcmUgaW50cm9kdWNlZCBhbmQgc3MyLjIgYW5kIDIuMyBk ZWZpbmUgbm92ZWwKCmV4dGVuc2lvbnMgdG8gUlNWUCBiZXlvbmQgd2hhdCBpcyBhdmFpbGFibGUg Zm9yIFJGQyAyOTYxIGFuZCByZXF1aXJpbmcKCm1vZGlmaWNhdGlvbiB0byBiYXNpYyBSRkMgMjk2 MSBmdW5jdGlvbmFsaXR5Li4KCgoKW1ZQQl0gV2UgY2hhbmdlZCB0aGUgdGl0bGUgdG8gIlRlY2hu aXF1ZXMgdG8gSW1wcm92ZSB0aGUgU2NhbGFiaWxpdHkgb2YgUlNWUC1URSBEZXBsb3ltZW50cyIu IFdlIGFsc28gdHdlYWtlZCB0aGUgdGV4dCBpbiB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24gYXMg c3VnZ2VzdGVkLiBQbGVhc2Ugc2VlIGlmIHRoZSBuZXcgc2V0IG9mIGRpZmZzIGFkZHJlc3MgdGhl IGNvbW1lbnQgYWJvdmUuCiAKCk1pbm9yIGlzc3VlczoKCkludGVyYWN0aW9uIHdpdGggUkZDIDUw NjM6wqAgVGhlIGRvY3VtZW50IGRvZXMgbm90IGV4cGxpY2l0bHkgc3RhdGUgdGhhdCBhbgoKaW1w bGVtZW50YXRpb24gd291bGQgbmVlZCB0byBzdXBwb3J0IChhdCBsZWFzdCkgdGhlIGV4dHJhIGNh cGFiaWxpdHkgb2JlY3QKCmRlZmluZWQgaW4gczQuMiBvZiBSRkMgNTA2My7CoCBTb21lIHdvcmRz IGFib3V0IGludGVyYWN0aW9uIHdpdGggUkZDIDUwNjMgYXJlCgpwcm9iYWJseSByZXF1aXJlZCBp biB0aGF0IHM0LjIuMSBvZiBSRkMgNTA2MyByYXRoZXIgYXNzdW1lcyB0aGF0IGlmIHRoZXJlIGlz IGEKCmNhcGFiaWxpdHkgb2JqZWN0LCBieSBkZWZhdWx0IGl0cyBTIGJpdCB3aWxsIGJlIHNldC4K CltWUEJdIFRoZSBDQVBBQklMSVRZIG9iamVjdCBpbiBSRkM1MDYzIGlzIG1lYW50IGZvciBnZW5l cmljIHVzZSBhbmQgY2FuIGJlIHVzZWQgZXZlbiB3aGVuIHRoZXJlIGFyZSBubyBHcmFjZWZ1bCBS ZXN0YXJ0IGV4dGVuc2lvbnMgaW4gcGxheSAoZXZlbiB3aGVuIG5vIEdSIGZsYWdzIGFyZSBzZXQp LiBBcyBmYXIgYXMgd2UgY2FuIHRlbGwsIHRoZXJlIGlzIG5vdGhpbmcgaW4gUkZDNTA2MyB0aGF0 IHByZWNsdWRlcyB0aGlzLiBXZSBhZGRlZCBhIHJlZmVyZW5jZSB0byBSRkM1MDYzIHdoZW4gdGhl IG5ldyBDYXBhYmlsaXR5IGZsYWdzIGFyZSBpbnRyb2R1Y2VkLiBXb3VsZCB0aGlzIGJlIHN1ZmZp Y2llbnQgdG8gYWRkcmVzcyB0aGlzIGNvbmNlcm4/CsKgCgoKCkJlaGF2aW91ciBpZiBhIG5vZGUg c3RvcHMgc2V0dGluZyBSZWZyZXNoLVJlZHVjdGlvbi1DYXBhYmxlIGJpdDrCoCBUaGUgbGFzdCBw YXJhCgpvZiBzMiBpbiBSRkMgMjk2MSBkaXNjdXNzZXMgYmVoYXZpb3VyIGlmIGEgbm9kZSBzdG9w cyBzZXR0aW5nIHRoaXMgYml0IGluCgptZXNzYWdlcy7CoCBXaGF0IHdvdWxkIGhhcHBlbiB3aXRo IHRoZSBleHRlbnNpb25zIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpZgoKdGhpcyBoYXBwZW5l ZCB3aGlsZSBlaXRoZXIgb2YgdGhlIGV4dGVuc2lvbnMgaXMgaW4gdXNlP8KgIEFzIGEgbWF0dGVy IG9mCgppbnRlcmVzdCwgaWYgYSBwZWVyIG9mZmVycyB0aGUgY2FwYWJpbGl0aWVzIGRlZmluZWQg aW4gdGhpcyBkcmFmdCwgaXMgaXQKCnBvc3NpYmxlIG9yIHNlbnNpYmxlIGZvciBpdCB0byBzdG9w IHNldHRpbmcgdGhlIFJlZnJlc2gtUmVkdWN0aW9uLUNhcGFibGUgYml0Cgp3aXRob3V0IHN0b3Bw aW5nIG9mZmVyaW5nIHRoZSBleHRlbnNpb25zPwoKW1ZQQl3CoCBJZiBhIHBlZXIgc2V0cyB0aGUg SSBvciBGIGJpdCBpbiB0aGUgQ0FQQUJJTElUWSBvYmplY3QgYnV0IGRvZXMgbm90IHNldCB0aGUg UmVmcmVzaC1SZWR1Y3Rpb24tY2FwYWJsZSBiaXQsIHRoZW4gdGhlIGNvcnJlc3BvbmRpbmcgZnVu Y3Rpb25hbGl0eSAoIlJJLVJTVlAiIG9yICJQZXItUGVlciBGbG93LUNvbnRyb2wiKSBpcyBub3Qg YWN0aXZhdGVkIGZvciB0aGF0IHBlZXIuIEluIG90aGVyIHdvcmRzLCByZXNldHRpbmcgdGhlIFJl ZnJlc2gtUmVkdWN0aW9uLUNhcGFibGUgYml0IGltbWVkaWF0ZWx5IG1ha2VzIHRoZSBub2RlIGlu Y2FwYWJsZSBvZiBzdXBwb3J0aW5nIHRoZSB0d28gY2FwYWJpbGl0aWVzIGRpc2N1c3NlZCBpbiB0 aGlzIGRvY3VtZW50LiBUaGlzIGlzIGNvdmVyZWQgaW4gU2VjdGlvbnMgMy4xIGFuZCA0LjEgKCAt MDcgdmVyc2lvbikuIAoKCgoKczIuMS4zLCBwYXJhIDI6IEFzIHNwZWNpZmllZCwgaXQgYXBwZWFy cyB0aGF0IHRoZSAnc2xvd2VyIHRpbWVyJyB0cmFuc21pc3Npb24KCm9mIFBhdGggYW5kIFJlc3Yg bWVzc2FnZXMgY2FuIGdvIG9uIGluZGVmaW5pdGVseSBpZiBubyBhY2sgYXJyaXZlcy7CoCBXaGF0 IHB1dHMKCmFuIGVuZCB0byB0aGlzIHJlcGV0aXRpb24/wqAgW0l0IG1heSBiZSB0aGF0IEkgaGF2 ZSBmb3Jnb3R0ZW4gaG93IGJhc2ljIFJTVlAKCndvcmtzLCBidXQgc2luY2UgdGhpcyBpcyBhbHRl cmluZyB0aGUgYmVoYXZpb3VyIGl0IHdvdWxkIGJlIGdvb2QgdG8gZXhwbGFpbiBob3cKCml0IHRl cm1pbmF0ZXMsIGFuZCB3aGV0aGVyIHRoaXMgcmVxdWlyZXMgYW55IGFkZGl0aW9uYWwgbW9kaWZp Y2F0aW9uIHRvIHRpbWVycy5dCgpbVlBCXcKgIFRoZXJlIGlzIG5vdGhpbmcgbmV3IGFib3V0IFBh dGggYW5kIFJlc3YgbWVzc2FnZXMgZ2V0dGluZyB0cmFuc21pdHRlZCBpbmRlZmluaXRlbHkgKHRo aXMgaXMgbm9ybWFsIHNvZnQtc3RhdGUgc2lnbmFsaW5nIGJlaGF2aW9yKSAtLSBhbGwgdGhhdCB0 aGlzIHNlY3Rpb24gZG9lcyBpcyBkaXNjdXNzIGhvdyB0aGVzZSB0cmFuc21pc3Npb25zIGFyZSBw YWNlZCBpbiB0aGUgYWJzZW5jZSBvZiBhbiBhY2suIFRoZSBzbG93ZXIgdGltZXIgdHJhbnNtaXNz aW9uIHdpbGwgZ28gb24gdW50aWwgZWl0aGVyIGFuIGFjayBpcyByZWNlaXZlZCAoYXQgd2hpY2gg cG9pbnQgdGhlIHJlZ3VsYXIgInJlZnJlc2ggaW50ZXJ2YWwiIGNvbWVzIGludG8gcGxheSkgb3Ig dGhlIGNvcnJlc3BvbmRpbmcgTFNQIGluc3RhbmNlIHN0YXRlIGlzIHRvcm4gZG93bi4gCgoKCgpO aXRzL2VkaXRvcmlhbCBjb21tZW50czoKCkFic3RyYWN0OiBSU1ZQLVRFIGlzIG5vdCBhICd3ZWxs LWtub3duJyBhYmJyZXZpYXRpb246IHMvUlNWUC1URS9SU1ZQIFRyYWZmaWMKCkVuZ2luZWVyaW5n IChSU1ZQLVRFKS8KCgoKQWJzdHJhY3QgYW5kIHMxLCBmaXJzdCBwYXJhOsKgIFRoaXMgcGFyYSBp cyBub3QgZnV0dXJlIHByb29mLsKgIFN1Z2dlc3Q6CgpPTEQ6CgrCoCDCoFRoZSBzY2FsZSBhdCB3 aGljaCBSU1ZQLVRFIFtSRkMzMjA5XSBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgZ2V0CgrC oCDCoGRlcGxveWVkIGlzIGdyb3dpbmcgY29udGludWFsbHkgYW5kIHRoZXJlIGlzIGNvbnNpZGVy YWJsZSBvbnVzIG9uCgrCoCDCoFJTVlAtVEUgaW1wbGVtZW50YXRpb25zIGFjcm9zcyB0aGUgYm9h cmQgdG8ga2VlcCB1cCB3aXRoIHRoaXMKCsKgIMKgaW5jcmVhc2luZyBkZW1hbmQgaW4gc2NhbGUu CgpORVc6CgrCoCDCoEF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIG5ldHdvcmtzIHdoaWNoIHV0aWxp c2UgUlNWUCBUcmFmZmljIEVuZ2luZWVyaW5nCgrCoCDCoChSU1ZQLVRFKSBbUkZDMzIwOV0gTGFi ZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMpIGFyZSBlbmNvdW50ZXJpbmcgbGltaXRhdGlvbnMKCsKg IMKgaW4gdGhlIGFiaWxpdHkgb2YgaW1wbGVtZW50YXRpb25zIHRvIHN1cHBvcnQgdGhlIGdyb3d0 aCBpbiB0aGUgbnVtYmVyIG9mIExTUHMKCsKgIMKgZGVwbG95ZWQuwqAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIHR3byBhZGRpdGlvbmFsIFJTVlAtVEUgZXh0ZW5zaW9ucyB0aGF0CgrCoCDCoGFyZSBp bnRlbmRlZCB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBtZXNzYWdlcyBuZWVkZWQgdG8gbWFpbnRh aW4gUlNWUC1URQoKwqAgwqBzb2Z0IHN0YXRlIGluIHJvdXRlcnMgYW5kIGhlbmNlIGFsbG93IGlt cGxlbWVudGF0aW9ucyB0byBzdXBwb3J0IGxhcmdlcgoKwqAgwqBzY2FsZSBkZXBsb3ltZW50cy4K CkVORFMKCk5vdGU6wqAgT21pdCByZWZlcmVuY2UgZnJvbSBBYnN0cmFjdC4KCgoKW1ZQQl0gRml4 ZWQgaW4gLTA3IAoKczEsIHBhcmEgMjogcy91bmRlciBjZXJ0YWluL2JleW9uZCBhIGNlcnRhaW4v CgpbVlBCXSBGaXhlZCBpbiAtMDcKIAoKCgpzMSwgcGFyYSAzOiBzL21ha2VzIGEgc2V0IG9mIGNv bmNyZXRlIGltcGxlbWVudGF0aW9uIHJlY29tbWVuZGF0aW9ucy9kZWZpbmVzCgp0d28gZXh0ZW5z aW9ucy87IHMvLSBwdXNoIGhpZ2hlci9ieSBpbmNyZWFzaW5nLzsgcy9tYWludGFpbiBMU1Agc3Rh dGUuL21haW50YWluCgpMU1Agc3RhdGUgYnkgcmVkdWNpbmcgdGhlIG51bWJlciBvZiBtZXNzYWdl cyBuZWVkZWQuLwoKCgpBYnN0cmFjdCwgcGFyYSAyIGFuZCBzMSwgbGFzdCBwYXJhOsKgIFtPbWl0 IHJlZmVyZW5jZSBmcm9tIEFic3RyYWN0XQoKT0xEOgoKwqAgwqBUaGlzIGRvY3VtZW50IGFkdm9j YXRlcyB0aGUgdXNlIG9mIGEgY291cGxlIG9mIHRlY2huaXF1ZXMgLSAiUmVmcmVzaC0KCsKgIMKg SW50ZXJ2YWwgSW5kZXBlbmRlbnQgUlNWUCAoUkktUlNWUCkiIGFuZCAiUGVyLVBlZXIgRmxvdy1D b250cm9sIiAtCgrCoCDCoGZvciBzaWduaWZpY2FudGx5IGN1dHRpbmcgZG93biB0aGUgYW1vdW50 IG9mIHByb2Nlc3NpbmcgY3ljbGVzCgrCoCDCoHJlcXVpcmVkIHRvIG1haW50YWluIExTUCBzdGF0 ZS4KCk5FVzoKCsKgIMKgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBSU1ZQIENhcGFiaWxpdGll cyBbUkZDNTA2M10gIlJlZnJlc2gtCgrCoCDCoEludGVydmFsIEluZGVwZW5kZW50IFJTVlAgKFJJ LVJTVlApIiBhbmQgIlBlci1QZWVyIEZsb3ctQ29udHJvbCIKCsKgIMKgdGhhdCB3aWxsIGN1dCBk b3duIHRoZSBudW1iZXIgb2YgbWVzc3NhZ2VzIGFuZCBwcm9jZXNzaW5nIGN5Y2xlcwoKwqAgwqBy ZXF1aXJlZCB0byBtYWludGFpbiBMU1Agc3RhdGUuCgpFTkRTCgpbVlBCXSBGaXhlZCBpbiAtMDcK IAoKCgpzMSwgbGFzdCBwYXJhOiBBZGQgbmV3IHBlbnVsdGltYXRlIHNlbnRlbmNlOgoKwqAgwqBO b3RlIHRoYXQgdGhlICJQZXItUGVlciBGbG93LUNvbnRyb2wiIGNhcGFiaWxpdHkgcmVxdWlyZXMg dGhlICJSSS1SU1ZQIgoKwqAgwqBjYXBhYmlsaXR5IGFzIGEgcHJlcmVxdWlzaXRlLgoKW1ZQQl0g Rml4ZWQgaW4gLTA3CiAKCgoKczEsIGxhc3QgcGFyYTogcy9SRUNPTU1FTkRFRC9yZWNvbW1lbmRl ZC8gLSB0aGlzIGlzbid0IGEgcmVjb21tZW5kYXRpb24gYWJvdXQKCnRoZSBwcm90b2NvbCBvbiB0 aGUgd2lyZS4KwqBbVlBCXSBGaXhlZCBpbiAtMDcgCgoKClN1YmRpdmlzaW9uIG9mIHMyOsKgIFRo ZSBpc3N1ZXMgcmVnYXJkaW5nIHRoZSBuYXR1cmUgb2YgdGhlIGRvY3VtZW50IHdvdWxkIGJlCgpo ZWxwZWQgYnkgYWx0ZXJpbmcgczIgaW50byBmb3VyIHRvcCBsZXZlbCBzZWN0aW9ucywgdGh1czog czI6IFJlcXVpcmVtZW50IGZvcgoKUkZDIDI5NjEgUmVmcmVzaCBPdmVyaGVhZCBSZWR1Y3Rpb24g U3VwcG9ydCBhbmQgU3BlY2lmaWMgT3B0aW9uIENob2ljZXMgKGZyb20KCnMyLjEpIHMzOiBSZXF1 aXJlbWVudCBmb3IgUkZDIDUwNjMgQ2FwYWJpbGl0eSBPYmplY3Qgc3VwcG9ydCAoc2VlIE1pbm9y IElzc3VlcwoKYWJvdmUpIHM0OiBSZWZyZXNoLUludGVydmFsIEluZGVwZW5kZW50IFJTVlAgQ2Fw YWJpbGl0eSAoZnJvbSBzMi4zKSBzNToKClBlci1QZWVyIFJTVlAgRmxvdyBDb250cm9sIENhcGFi aWxpdHkgKGZyb20gczIuNCkgU3Vic2VxdWVudCBtYWpvciBzZWN0aW9ucwoKdGhlbiByZW51bWJl cmVkIGFzIHM2IG9ud2FyZHMuIFJlZmVyZW5jZXMgdG8gczIueCB3aWxsIG5lZWQgdG8gYmUgdXBk YXRlZAoKdGhyb3VnaG91dC4KCltWUEJdIFdlIHN1YmRpdmlkZWQgczIgaW50byAzIHRvcCBsZXZl bCBzZWN0aW9ucy4gV2UgZGlkIG5vdCBhZGQgYSBzZXBhcmF0ZSBzZWN0aW9uIGZvciBkaXNjdXNz aW5nIFJGQzUwNjMgQ2FwYWJpbGl0eSBPYmplY3Qgc3VwcG9ydC4KCgoKczIuMSAod291bGQgYmUg aW50cm9kdWN0aW9uIG9mIG5ldyBzMik6CgpPTEQ6CgrCoCDCoFRoZSBpbXBsZW1lbnRhdGlvbiBy ZWNvbW1lbmRhdGlvbnMgZGlzY3Vzc2VkIGluIHRoaXMgc2VjdGlvbiBhcmUKCsKgIMKgYmFzZWQg b24gdGhlIHByb3Bvc2FscyBtYWRlIGluIFtSRkMyOTYxXSBhbmQgYWN0IGFzIHByZXJlcXVpc2l0 ZXMgZm9yCgrCoCDCoGltcGxlbWVudGluZyB0aGUgdGVjaG5pcXVlcyBkaXNjdXNzZWQgaW4gU2Vj dGlvbnMgMi4yIGFuZCAyLjMuCgoKCk5FVzoKCsKgIMKgVGhlIENhcGFiaWxpdGllcyBkZWZpbmVk IGluIFNlY3Rpb25zIDQgYW5kIDUgb2YgdGhpcyBkb2N1bWVudCBhcmUgYmFzZWQgb24KCsKgIMKg cHJvcG9zYWxzIG1hZGUgaW4gW1JGQzI5NjFdLsKgIEltcGxlbWVudGF0aW9ucyBvZiB0aGVzZSBD YXBhYmlsaXRpZXMgd2lsbAoKwqAgwqBuZWVkIHRvIHN1cHBvcnQgdGhlIFJTVlAgbWVzc2FnZXMg YW5kIHRlY2huaXF1ZXMgZGVmaW5lZCBpbiBbUkZDMjk2MV0gYXMgc2V0CgrCoCDCoG91dCBpbiBT ZWN0aW9uIDIuMSBbd2FzIDIuMS4xXSB3aXRoCgrCoCDCoHNvbWUgbWlub3IgbW9kaWZpY2F0aW9u cyBhbmQgYWx0ZXJhdGlvbnMgdG8gcmVjb21tZW5kZWQgdGltZSBpbnRlcnZhbHMgYW5kCgrCoCDC oGl0ZXJhdGlvbiBjb3VudHMgYXMgZGVmaW5lZCBpbiB0aGUgcmVtYWluZGVyIG9mIHRoaXMgc2Vj dGlvbi4KCkVORFMKCgoKW1ZQQl0gRml4ZWQgaW4gLTA3CiAKCnMyLjEuMSwgdGl0bGUgYW5kIHBh cmEgMSBbd2lsbCBiZSBzMi4xXToKCk9MRDoKCjIuMS4xLsKgIEJhc2ljIFByZXJlcXVpc2l0ZXMK CgoKwqAgwqBBbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIHRoZSB0ZWNobmlxdWVzIGRp c2N1c3NlZCBpbiBTZWN0aW9ucwoKwqAgwqAyLjIgYW5kIDIuMyBtdXN0IG1lZXQgY2VydGFpbiBi YXNpYyBwcmVyZXF1aXNpdGVzLgoKTkVXOgoKMi4xLsKgIFJlcXVpcmVkIEZ1bmN0aW9uYWxpdHkg ZnJvbSBSRkMgMjk2MSB0byBiZSBJbXBsZW1lbnRlZAoKCgrCoCDCoEFuIGltcGxlbWVudGF0aW9u IHRoYXQgc3VwcG9ydHMgdGhlIGNhcGFiaWl0aWVzIGRpc2N1c3NlZCBpbiBTZWN0aW9ucwoKwqAg wqA0IGFuZCA1IG11c3QgcHJvdmlkZSBhIGxhcmdlIHN1YnNldCBvZiB0aGUgZnVuY3Rpb25hbGl0 eSBkZXNjcmliZWQKCsKgIMKgaW4gW1JGQzI5NjFdIGFzIGZvbGxvd3M6CgpFTkRTCgpbVlBCXSBG aXhlZCBpbiAtMDcKIAoKCgpzMi4xLjIsIHBhcmEgMiBbd2lsbCBiZSBzMi4yXTogcy90ZWNobmlx dWVzIGRpc2N1c3NlZCBpbiBTZWN0aW9ucyAyLjIgYW5kCgoyLjMvQ2FwYWJpbGl0aWVzIGRlZmlu ZWQgaW4gU2VjdGlvbnMgNCBhbmQgNS8KCltWUEJdIEZpeGVkIGluIC0wNwogCgoKCnMyLjEuMiwg cGFyYSAyOiBzL01FU1NBR0UgSUQvTUVTU0FHRV9JRC8KCltWUEJdIEZpeGVkIGluIC0wNwogCgoK CnMyLjIsIHBhcmEgMTogcy9pbXByb3ZlbWVudCBvbiB0cmFuc21pc3Npb24gb3ZlcmhlYWQvaW1w cm92ZW1lbnQgb2YKCnRyYW5zbWlzc2lvbiBvdmVyaGVhZC8KCltWUEJdIEZpeGVkIGluIC0wNwog CgoKCnMyLjIsIHBhcmEgMTogcy9wcm9wb3NlcyBzdWZmaWNpZW50IHJlY29tbWVuZGF0aW9ucy9z ZXRzIG91dCBhZGRpdGlvbmFsCgpyZXF1aXJlbWVudHMvCgpbVlBCXSBGaXhlZCBpbiAtMDcKIAoK CgpzMi4yLCBsYXN0IGJ1bGxldDogQWRkIGEgcmVmZXJlbmNlIHRvIHRoZSBwcm9wb3NlZCBuZXcg U2VjdGlvbiAzIHRoYXQgZGlzY3Vzc2VzCgp0aGUgQ2FwYWJpbGl0eSBvYmplY3QuCsKgW1ZQQl0g QWRkZWQgYSBkaXJlY3QgcmVmZXJlbmNlIHRvIFJGQzUwNjMgCgoKCnMyLjIuMSwgbGFzdCBwYXJh OiBzL3NldCBSZWZyZXNoLVJlZHVjdGlvbi1DYXBhYmxlIGJpdCBpbiBjb21tb24gaGVhZGVyL3Nl dCB0aGUKClJlZnJlc2gtUmVkdWN0aW9uLUNhcGFibGUgYml0IGluIHRoZSBjb21tb24gaGVhZGVy LwoKW1ZQQl0gRml4ZWQgaW4gLTA3CiAKCgoKczIuMywgcGFyYSAxOiBzL3NldCBvZiByZWNvbW1l bmRhdGlvbnMvZnVuY3Rpb25hbGl0eS87IHMvcHJvdmlkZS9wcm92aWRlcy87CgpzL1JTVlAtVEUg Y29udHJvbCBwbGFuZSBjb25nZXN0aW9uL2Egc2lnbmlmaWNhbnQgcG9ydGlvbiBvZiB0aGUgUlNW UC1URSBjb250cm9sCgptZXNzYWdlIGxvYWQvCgpbVlBCXSBGaXhlZCBpbiAtMDcKIAoKCgpzMi4z LjI6IHMvTUVTU0FHRSBJRC9NRVNTQUdFX0lELwoKW1ZQQl0gRml4ZWQgaW4gLTA3CiAKCgoKCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVGVhcyBtYWls aW5nIGxpc3QKClRlYXNAaWV0Zi5vcmcKCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGVhcwoKCgo= ----_com.samsung.android.email_154488561075070 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PkhpLCBQYXZhbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkndmUgY2hl Y2tlZCB0aHJvdWdoIHRoZSBjaGFuZ2VzIGluIC0wNyBhbmQgSSB0aGluayBhbGwgaXMgZ29vZCBh cyByZWdhcmRzIGZpeGluZyB0aGUgJ21ham9yIGlzc3VlJywgcmVzdHVjdHVyaW5nIHMyIGFuZCBm aXhpbmcgdGhlIG5pdHMgLSB0aGFua3MuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Mb29raW5n IGF0IHRoZSBJRVNHIGNvbW1lbnRzIEkgdGhpbmsgeW91IGhhdmUgY292ZXJlZCBtb3N0IG9mIHRo ZW0mbmJzcDsgZXhjZXB0IGl0IHdvdWxkIGJlIGdvb2QgdG8gcHV0IGEgcG9pbnRlciB0byBBcHBl bmRpeCBBIGludG8gdGhlIGludHJvIG9mIHMyLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+V2l0aCByZWZlcmVuY2UgdG8gQXBwZW5kaXggQShkKSwgaXQgd291bGQgYmUgaGVscGZ1bCB0 byBzL3BlcmlvZGljIHJldHJhbnNtaXNzaW9uIGludGVydmFsL1BlcmlvZGljIFJldHJhbnNtaXNz aW9uIEludGVydmFsLyBhbmQgcG9zc2libHkgZ2l2ZSBpdCBhIG5hbWUgKFJwcmkgb3Igc29tZSBz dWNoKSZuYnNwOyBpbiBzMi4zIGFuZCBBcHBlbmRpeCBBKGQpLiZuYnNwOyBBZGRpbmcgdGhlIG5h bWUgb2YgdGhlIGludGVydmFsIGFmdGVyICJyZXRyYW5zbWlzc2lvbiBvZiB0aGVzZSBvbiBhIHNs b3dlciB0aW1lciIgbWlndCBtYWsgaXQgY2xlYXJlciBhbHNvLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+SG93ZXZlciwmbmJzcDsgSSB0aGluayB5b3Ugc3RpbGwgbmVlZCB0byBhZGRyZXNzIGFs bCB0aHJlZSBvZiB0aGUgbWlub3IgaXNzdWVzOjwvZGl2PjxkaXY+LSBDYXBhYmlsaXR5IG9iamVj dDombmJzcDsgQSAnYmFzaWMnIGltcGxlbWVudGF0aW9uIG9mIFJGQyAyMjA5L1JGQzMyMDkgd2ls bCBub3QgaW5jbHVkZSB0aGUgUkZDNTA2MyBleHRlbnNpb25zLiZuYnNwOyBJIHRoaW5rIHlvdSBz aG91bGQgdGhlcmVmb3JlIG1ha2UgaXQgZXhwbGljaXQgdGhhdCBhIHByZXJlcXVpc2l0ZSBmb3Ig eW91ciBleHRlbnNpb25zIGlzIGFuIGltcGxlbWVudGF0aW9uIG9mIHRoZSBDYXBhYmlsaXR5IG9i amVjdCBhcyBzcGVjaWZpZWQgaW4gUkZDNTA2MyAobXkgcHJvcG9zYWwgZm9yIHMzKSAsIG1ha2lu ZyBpdCBjbGVhciB0aGF0IHRoaXMgZG9lcyBub3QgcmVxdWlyZSBhbnkgb2YgdGhlIG90aGVyIGZ1 bmN0aW9uYWxpdHkgb2YgUkZDIDUwNjMsIGVzcGVjaWFsbHkgbm8gc3VwcG9ydCBmb3IgdGhlIFMg Yml0IGluIHRoZSBDYXBhYmlsaXRpZXMuPC9kaXY+PGRpdj4tJm5ic3A7IFlvdXIgcmVzcG9uc2Ug cmVnYXJkaW5nIHdoYXQgaGFwcGVucyBpZiBhIHBlZXIgaW5pdGlhbGx5IGFja25vd2xlZGdlcyB0 aGF0IGl0IHN1cHBvcnRzIHRoZSBuZXcgY2FwYWJpbGl0aWVzIGJ5IHNldHRpbmcgdGhlIEkvRiBi aXRzIGluIHRoZSBDYXBhYmlsaXR5IGFuZCBzZW5kcyBzb21lIG1lc3NhZ2VzIHdpdGggdGhlIFJl ZnJlc2gtUmVkdWN0aW9uLUNhcGFibGUgYml0IHNldCwgYnV0IHRoZW4gc3RvcHMgc2V0dGluZyB0 aGUgUmVmcmVzaC1SZWR1Y3Rpb24tQ2FwYWJsZSBiaXQgZG9lc24ndCByZWFsbHkgYWRkcmVzcyB0 aGUgcHJvYmxlbS4mbmJzcDsgJm5ic3A7V291bGQgdGhpcyBtZWFuIHRoYXQgdGhlIHJlY2VpdmVy IHNob3VsZCBhc3N1bWUgdGhhdCB0aGUgcGVlciBjYW4gbm8gbG9uZ2VyIHN1cHBvcnQgdGhlIGV4 dGVuc2lvbnM/Jm5ic3A7IElzIHRoaXMgYSBwZXJtYW5lbnQgc3RhdGUgb3IgY291bGQgdGhlIHBl ZXIgc3RhcnQgc2V0dGluZyB0aGUgUmVmcmVzaC1SZWR1Y3Rpb24tQ2FwYWJsZSBiaXQgYWdhaW4g YW5kIHJlc3RvcmUgaW5pdGlhbCBmdW5jdGlvbmFsaXR5IC0gb3Igc2hvdWxkIHRoaXMganVzdCBu b3QgYmUgYWxsb3dlZC4gSSB0aGluayB5b3UgbmVlZCB0byB0aGluayB0aHJvdWdoIHdoYXQgaGFw cGVzIGluIHRoZSB2YXJpb3VzIHBvc3NpYmxlIGNhc2VzIGFuZCBleHBsYWluIHdoYXQgYW4gaW1w bGVtZW50YXRpb24gc2hvdWxkIGRvIGluIGVhY2ggY2FzZS48L2Rpdj48ZGl2Pi0gU28sIEkgaGF2 ZSBkb25lIG15IGhvbWV3b3JrIGFuZCBjaGVja2VkIGJhY2sgb24gd2hhdCBoYXBwZW5zIHdoZW4g dGhlcmUgaXMgbm8gYWNrbm93bGVkZ2VtZW50IG9mIHJlZnJlc2hlcy4gVGhlIHJlbGV2YW50IHBh cmFtZXRlciBpcyB0aGUgY2xlYW51cCB0aW1lLiZuYnNwOyBIb3dldmVyLCB0aGlzIGxlYXZlcyB1 cyB3aXRoIGEgcHJvYmxlbS4uIHRoZSBjbGVhbnVwIHRpbWUgaXMgdHlwaWNhbGx5IHNldCBhcyBh IG11bHRpcGxlIG9mIHRoZSByZWZyZXNoIGludGVydmFsICg5IHRpbWVzIHNlZW1zIHRvIGJlIHRo ZSBkZWZhdWx0KSAtIGluZGVlZCBJIHNlZSB0aGF0IHRoZSBpbnRlcmZhY2UgY29uZmlndXJhdGlv biBvbiBhIEp1bmlwZXIgcm91dGVyICghKSBhY3R1YWxseSBzZXRzIGl0IGJ5IGFza2luZyBmb3Ig dGhlIG11bHRpcGxlIHJhdGhlciB0aGFuIGFuIGFic29sdXRlIHZhbHVlLiZuYnNwOyBXdGggdGhl IG5ldyBkaXNwZW5zYXRpb24gaW4gdGhzIGRvY3VtZW50LCB0aGVyZSBhcmUgdHdvIHRpbWUgcGVy aW9kcyBpbnZvbHZlZDombmJzcDsgSSB0aGluayB5b3UgZG8gbmVlZCB0byByZXNwZWNpZnkgaG93 IHRvIGNhbGN1bGF0ZSBhIHNlbnNpYmxlIGNsZWFudXAgaW50ZXJ2YWwsIGFuZCBub3RlIHRoYXQg dGhlIHJldHJhbnNtaXNzaW9ucyB3aWxsIHRoZW4gaGFsdCBhZnRlciB0aGlzIGludGVydmFsLjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RG9lcyB0aGlzIGxhc3QgbW9kaWZpY2F0aW9uIGNvbnN0 aXR1dGUgYW4gdXBkYXRlIG9mIFJGQyAyMjA5PyZuYnNwOyBJIGFtIG5vdCBzdXJlIC1jb25zdWx0 IHlvdXIgQUQhPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5SZWdhcmRzLDwvZGl2PjxkaXY+RWx3 eW4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUi PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGlyPSJhdXRvIj5TZW50 IGZyb20gU2Ftc3VuZyB0YWJsZXQuPC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+ PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBW aXNobnUgUGF2YW4gQmVlcmFtICZsdDt2aXNobnVwYXZhbkBnbWFpbC5jb20mZ3Q7IDwvZGl2Pjxk aXY+RGF0ZTogMjgvMDkvMjAxNyAgMDM6NDggIChHTVQrMDA6MDApIDwvZGl2PjxkaXY+VG86IEVs d3luIERhdmllcyAmbHQ7ZWx3eW5kQGRpYWwucGlwZXguY29tJmd0OyA8L2Rpdj48ZGl2PkNjOiBn ZW4tYXJ0QGlldGYub3JnLCBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zY2FsaW5nLXJlYy5hbGxA aWV0Zi5vcmcsIGlldGYgJmx0O2lldGZAaWV0Zi5vcmcmZ3Q7LCB0ZWFzQGlldGYub3JnIDwvZGl2 PjxkaXY+U3ViamVjdDogUmU6IFtUZWFzXSBHZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFm dC1pZXRmLXRlYXMtcnN2cC10ZS1zY2FsaW5nLXJlYy0wNiA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48 L2Rpdj48ZGl2IGRpcj0ibHRyIj48ZGl2PjxkaXY+RWx3eW4sIEhpITwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IGFuZCB0aGUgdGV4dCBzdWdn ZXN0aW9ucy4gV2UganVzdCBwb3N0ZWQgYSBuZXcgcmV2aXNpb24gKC0wNykgdG8gYWRkcmVzcyB0 aGUgY29uY2VybnMgbGlzdGVkIGJlbG93LiBQbGVhc2UgZ28gdGhyb3VnaCB0aGUgbmV3IGRpZmZz ICg8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10 ZWFzLXJzdnAtdGUtc2NhbGluZy1yZWMtMDciPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zY2FsaW5nLXJlYy0wNzwvYT4pIGFuZCBsZXQg dXMga25vdyBpZiBhZGRpdGlvbmFsIGNoYW5nZXMgYXJlIHJlcXVpcmVkLjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+UGxlYXNlIHNlZSBpbmxpbmUgZm9yIGZ1cnRoZXIgcmVzcG9uc2VzIChwcmVm aXhlZCBWUEIpLjxicj48YnI+PC9kaXY+UmVnYXJkcyw8YnI+PC9kaXY+LVBhdmFuPGJyPjxkaXYg Y2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwg U2VwIDIyLCAyMDE3IGF0IDY6MDYgUE0sIEVsd3luIERhdmllcyA8c3BhbiBkaXI9Imx0ciI+Jmx0 OzxhIGhyZWY9Im1haWx0bzplbHd5bmRAZGlhbC5waXBleC5jb20iIHRhcmdldD0iX2JsYW5rIj5l bHd5bmRAZGlhbC5waXBleC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3Jk ZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij5SZXZp ZXdlcjogRWx3eW4gRGF2aWVzPGJyPgpSZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHk8YnI+Cjxicj4K SSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdl bmVyYWwgQXJlYTxicj4KUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nIHByb2Nlc3NlZDxicj4KYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWly LiZuYnNwOyBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdDxicj4KbGlrZSBhbnkgb3Ro ZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxicj4KPGJyPgpGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgRkFRIGF0PGJyPgo8YnI+CiZsdDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0 Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXEiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlPHdicj5uL3dpa2kvR2VuQXJ0ZmFx PC9hPiZndDsuPGJyPgo8YnI+CkRvY3VtZW50OiBkcmFmdC1pZXRmLXRlYXMtcnN2cC10ZS1zY2Fs aW48d2JyPmctcmVjLTA2PGJyPgpSZXZpZXdlcjogRWx3eW4gRGF2aWVzPGJyPgpSZXZpZXcgRGF0 ZTogMjAxNy0wOS0yMjxicj4KSUVURiBMQyBFbmQgRGF0ZTogMjAxNy0wOS0yMjxicj4KSUVTRyBU ZWxlY2hhdCBkYXRlOiAyMDE3LTA5LTI4PGJyPgo8YnI+ClN1bW1hcnk6IE5vdCByZWFkeSwgcHJp bWFyaWx5IGJlY2F1c2UgdGhlIHRpdGxlIGFuZCBwcmVzZW50YXRpb24gZ2l2ZSB0aGU8YnI+Cmlt cHJlc3Npb24gdGhhdCB0aGUgY29udGVudCBpcyByZWFsbHkgYSBCQ1Agd2hlbiBpdCBpc24ndC4m bmJzcDsgVGhpcyBjb25jZWFscyB0aGU8YnI+CmNvbnNpZGVyYWJsZSBhbW91bnQgb2YgdHdlYWtp bmcgb2YgUkZDIDI5NjEgZnVuY3Rpb25hbGl0eSBhbmQgYWRkaXRpb24gb2YgbmV3PGJyPgpSU1ZQ IENhcGFiaWxpdGllcyBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LiZuYnNwOyBUaGVyZSBhcmUg YWxzbyBhIGNvdXBsZSBvZiBtaW5vcjxicj4KaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBzb3J0ZWQg b3V0Ljxicj4KPGJyPgpNYWpvciBpc3N1ZXM6PGJyPgpUaXRsZSBhbmQgd2F5IHByb3Bvc2FscyBh cmUgcHJlc2VudGVkOiZuYnNwOyBUaGUgZG9jdW1lbnQgZGVmaW5lcyB0d28gbmV3PGJyPgonY2Fw YWJpbGl0aWVzJyBmb3IgUlNWUC1URSBhbmQgaXMgaW5kZWVkIChhcyBzcGVjaWZpZWQgaW4gdGhl IGRvY3VtZW50IGhlYWRlcik8YnI+CmNvcnJlY3RseSBpbnRlbmRlZCBmb3IgU3RhbmRhcmRzIFRy YWNrIHN0YXR1cy4mbmJzcDsgSG93ZXZlciB0aGUgdGl0bGUgYW5kIHRoZSB3aG9sZTxicj4Kb2Yg dGhlIG1lYXQgb2YgdGhlIGRvY3VtZW50IGluIFNlY3Rpb24gMiBwcmVzZW50cyB0aGUgcHJvcG9z YWxzIGFzPGJyPgoncmVjb21tZW5kYXRpb25zJyB3aGljaCBzYXlzIHRvIG1lIHRoYXQgSSBhbSBl eHBlY3RpbmcgYSBCQ1Agd2hlcmUgYSBwcm9maWxlIG9mPGJyPgphdmFpbGFibGUgb3B0aW9ucyBm cm9tIGV4aXN0aW5nIHN0YW5kYXJkcyBpcyByZWNvbW1lbmRlZCBhcyB0aGUgYmVzdCBjaG9pY2Ug Zm9yPGJyPgppbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudC4mbmJzcDsgSW4gbXkgb3Bpbmlv biwgdGhlIHRpdGxlIHdvdWxkIGJlIGJldHRlciBhczxicj4Kc29tZXRoaW5nIGxpa2UgIkFkZGl0 aW9uYWwgQ2FwYWJpbGl0aWVzIERlc2lnbmVkIHRvIEltcHJvdmUgdGhlIFNjYWxhYmlsaXR5IG9m PGJyPgpSU1ZQLVRFIERlcGxveW1lbnRzIi4mbmJzcDsgV2hpbHN0IHRoZSBwcm9wb3NhbHMgYXJl IGJhc2VkIG9uIHRoZSB0ZWNobmlxdWVzIGluIFJGQzxicj4KMjk2MSwgdGhlIGRvY3VtZW50ICpy ZXF1aXJlcyogdGhlIGltcGxlbWVudG9yIHRvIGNvbmZvcm0gdG8gcnVsZXMgdGhhdCB3ZXJlPGJy PgpvcHRpb25hbCBhbmQgY29uc3RyYWlucyBjb25maWd1cmFibGUgdmFsdWVzIHRvIGRpZmZlcmVu dCByYW5nZXMgaW4gb3JkZXIgdG8gYmU8YnI+CmFibGUgdG8gZGVsaXZlciB0aGUgY2FwYWJpbGl0 aWVzIGRlZmluZWQgaW4gdGhlIGRvY3VtZW50IGFzIHdlbGwgYXMgZGVmaW5pbmc8YnI+Cm5ldyBS U1ZQIGV4dGVuc2lvbnMgbW9kaWZ5aW5nIHNvbWUgb2YgdGhlIGJlaGF2aW91ciBkZWZpbmVkIGlu IFJGQyAyOTYxLiZuYnNwOyBUaHVzPGJyPgphbHRob3VnaCBzb21lIG9mIHRoZSBydWxlcyBjb3Vs ZCBiZSBtZXQgYnkgY2hvb3NpbmcgcGFydGljdWxhciB2YWx1ZXMgd2l0aGluPGJyPgp0aGUgUkZD IDI5NjEgc2V0LCB0aGUgdXNlIG9mIE1VU1QsIHR3ZWFraW5nIG9mIGZ1bmN0aW9uYWxpdHkgYW5k IHZhcmlhdGlvbiBvZjxicj4KcmFuZ2VzIHRha2VzIGl0IHdlbGwgYmV5b25kIGEgc2V0IG9mIHJl Y29tbWVuZGF0aW9ucyBmb3IgUkZDIDI5NjEgb3B0aW9uczxicj4Kc2VsZWN0aW9ucy4mbmJzcDsg SW4gdmlldyBvZiB0aGlzIFNlY3Rpb24gMSBuZWVkcyB0byBiZSB3cml0dGVuIGFzIGFuIGludHJv ZHVjdGlvbjxicj4KdG8gdGhlIGRlZmluaXRpb25zIG9mIHRoZSBuZXcgY2FwYWJpbGl0aWVzIHJh dGhlciB0aGFuIGFkdm9jYWN5IGZvciBzZWxlY3Rpb248YnI+Cm9mIFJGQyAyOTYxIG9wdGlvbnMg YW5kIHRoZSBpbXBsaWNhdGlvbiB0aGF0IHRoZSB0ZWNobmlxdWVzIG1lbnRpb25lZCBpbiB0aGU8 YnI+Cmxhc3QgcGFyYWdyYXBoIG9mIHMxIGFyZSBqdXN0IGEgbWF0dGVyIG9mIHNlbGVjdGluZyBh IHByb2ZpbGUgb2Ygb3B0aW9uIHZhbHVlcy48YnI+CiZuYnNwO0luIGFjdHVhbGl0eSBuZXcgcHJv dG9jb2wgdmFsdWVzIGFyZSBpbnRyb2R1Y2VkIGFuZCBzczIuMiBhbmQgMi4zIGRlZmluZSBub3Zl bDxicj4KZXh0ZW5zaW9ucyB0byBSU1ZQIGJleW9uZCB3aGF0IGlzIGF2YWlsYWJsZSBmb3IgUkZD IDI5NjEgYW5kIHJlcXVpcmluZzxicj4KbW9kaWZpY2F0aW9uIHRvIGJhc2ljIFJGQyAyOTYxIGZ1 bmN0aW9uYWxpdHkuLjxicj4KPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PltW UEJdIFdlIGNoYW5nZWQgdGhlIHRpdGxlIHRvICJUZWNobmlxdWVzIHRvIEltcHJvdmUgdGhlIFNj YWxhYmlsaXR5IG9mIFJTVlAtVEUgRGVwbG95bWVudHMiLiBXZSBhbHNvIHR3ZWFrZWQgdGhlIHRl eHQgaW4gdGhlIGludHJvZHVjdGlvbiBzZWN0aW9uIGFzIHN1Z2dlc3RlZC4gUGxlYXNlIHNlZSBp ZiB0aGUgbmV3IHNldCBvZiBkaWZmcyBhZGRyZXNzIHRoZSBjb21tZW50IGFib3ZlLjxicj48L2Rp dj48ZGl2PiA8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIw NCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPgpNaW5vciBpc3N1ZXM6PGJyPgpJbnRlcmFjdGlvbiB3 aXRoIFJGQyA1MDYzOiZuYnNwOyBUaGUgZG9jdW1lbnQgZG9lcyBub3QgZXhwbGljaXRseSBzdGF0 ZSB0aGF0IGFuPGJyPgppbXBsZW1lbnRhdGlvbiB3b3VsZCBuZWVkIHRvIHN1cHBvcnQgKGF0IGxl YXN0KSB0aGUgZXh0cmEgY2FwYWJpbGl0eSBvYmVjdDxicj4KZGVmaW5lZCBpbiBzNC4yIG9mIFJG QyA1MDYzLiZuYnNwOyBTb21lIHdvcmRzIGFib3V0IGludGVyYWN0aW9uIHdpdGggUkZDIDUwNjMg YXJlPGJyPgpwcm9iYWJseSByZXF1aXJlZCBpbiB0aGF0IHM0LjIuMSBvZiBSRkMgNTA2MyByYXRo ZXIgYXNzdW1lcyB0aGF0IGlmIHRoZXJlIGlzIGE8YnI+CmNhcGFiaWxpdHkgb2JqZWN0LCBieSBk ZWZhdWx0IGl0cyBTIGJpdCB3aWxsIGJlIHNldC48YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv ZGl2PjxkaXY+W1ZQQl0gVGhlIENBUEFCSUxJVFkgb2JqZWN0IGluIFJGQzUwNjMgaXMgbWVhbnQg Zm9yIGdlbmVyaWMgdXNlIGFuZCBjYW4gYmUgdXNlZCBldmVuIHdoZW4gdGhlcmUgYXJlIG5vIEdy YWNlZnVsIFJlc3RhcnQgZXh0ZW5zaW9ucyBpbiBwbGF5IChldmVuIHdoZW4gbm8gR1IgZmxhZ3Mg YXJlIHNldCkuIEFzIGZhciBhcyB3ZSBjYW4gdGVsbCwgdGhlcmUgaXMgbm90aGluZyBpbiBSRkM1 MDYzIHRoYXQgcHJlY2x1ZGVzIHRoaXMuIFdlIGFkZGVkIGEgcmVmZXJlbmNlIHRvIFJGQzUwNjMg d2hlbiB0aGUgbmV3IENhcGFiaWxpdHkgZmxhZ3MgYXJlIGludHJvZHVjZWQuIFdvdWxkIHRoaXMg YmUgc3VmZmljaWVudCB0byBhZGRyZXNzIHRoaXMgY29uY2Vybj88YnI+PC9kaXY+PGRpdj4mbmJz cDs8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQp O3BhZGRpbmctbGVmdDoxZXgiPgo8YnI+CkJlaGF2aW91ciBpZiBhIG5vZGUgc3RvcHMgc2V0dGlu ZyBSZWZyZXNoLVJlZHVjdGlvbi1DYXBhYmxlIGJpdDombmJzcDsgVGhlIGxhc3QgcGFyYTxicj4K b2YgczIgaW4gUkZDIDI5NjEgZGlzY3Vzc2VzIGJlaGF2aW91ciBpZiBhIG5vZGUgc3RvcHMgc2V0 dGluZyB0aGlzIGJpdCBpbjxicj4KbWVzc2FnZXMuJm5ic3A7IFdoYXQgd291bGQgaGFwcGVuIHdp dGggdGhlIGV4dGVuc2lvbnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlmPGJyPgp0aGlzIGhh cHBlbmVkIHdoaWxlIGVpdGhlciBvZiB0aGUgZXh0ZW5zaW9ucyBpcyBpbiB1c2U/Jm5ic3A7IEFz IGEgbWF0dGVyIG9mPGJyPgppbnRlcmVzdCwgaWYgYSBwZWVyIG9mZmVycyB0aGUgY2FwYWJpbGl0 aWVzIGRlZmluZWQgaW4gdGhpcyBkcmFmdCwgaXMgaXQ8YnI+CnBvc3NpYmxlIG9yIHNlbnNpYmxl IGZvciBpdCB0byBzdG9wIHNldHRpbmcgdGhlIFJlZnJlc2gtUmVkdWN0aW9uLUNhcGFibGUgYml0 PGJyPgp3aXRob3V0IHN0b3BwaW5nIG9mZmVyaW5nIHRoZSBleHRlbnNpb25zPzxicj48L2Jsb2Nr cXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5bVlBCXSZuYnNwOyBJZiBhIHBlZXIgc2V0cyB0aGUg SSBvciBGIGJpdCBpbiB0aGUgQ0FQQUJJTElUWSBvYmplY3QgYnV0IGRvZXMgbm90IHNldCB0aGUg UmVmcmVzaC1SZWR1Y3Rpb24tY2FwYWJsZSBiaXQsIHRoZW4gdGhlIGNvcnJlc3BvbmRpbmcgZnVu Y3Rpb25hbGl0eSAoIlJJLVJTVlAiIG9yICJQZXItUGVlciBGbG93LUNvbnRyb2wiKSBpcyBub3Qg YWN0aXZhdGVkIGZvciB0aGF0IHBlZXIuIEluIG90aGVyIHdvcmRzLCByZXNldHRpbmcgdGhlIFJl ZnJlc2gtUmVkdWN0aW9uLUNhcGFibGUgYml0IGltbWVkaWF0ZWx5IG1ha2VzIHRoZSBub2RlIGlu Y2FwYWJsZSBvZiBzdXBwb3J0aW5nIHRoZSB0d28gY2FwYWJpbGl0aWVzIGRpc2N1c3NlZCBpbiB0 aGlzIGRvY3VtZW50LiBUaGlzIGlzIGNvdmVyZWQgaW4gU2VjdGlvbnMgMy4xIGFuZCA0LjEgKCAt MDcgdmVyc2lvbikuIDxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+Cjxicj4KczIuMS4z LCBwYXJhIDI6IEFzIHNwZWNpZmllZCwgaXQgYXBwZWFycyB0aGF0IHRoZSAnc2xvd2VyIHRpbWVy JyB0cmFuc21pc3Npb248YnI+Cm9mIFBhdGggYW5kIFJlc3YgbWVzc2FnZXMgY2FuIGdvIG9uIGlu ZGVmaW5pdGVseSBpZiBubyBhY2sgYXJyaXZlcy4mbmJzcDsgV2hhdCBwdXRzPGJyPgphbiBlbmQg dG8gdGhpcyByZXBldGl0aW9uPyZuYnNwOyBbSXQgbWF5IGJlIHRoYXQgSSBoYXZlIGZvcmdvdHRl biBob3cgYmFzaWMgUlNWUDxicj4Kd29ya3MsIGJ1dCBzaW5jZSB0aGlzIGlzIGFsdGVyaW5nIHRo ZSBiZWhhdmlvdXIgaXQgd291bGQgYmUgZ29vZCB0byBleHBsYWluIGhvdzxicj4KaXQgdGVybWlu YXRlcywgYW5kIHdoZXRoZXIgdGhpcyByZXF1aXJlcyBhbnkgYWRkaXRpb25hbCBtb2RpZmljYXRp b24gdG8gdGltZXJzLl08YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+W1ZQQl0m bmJzcDsgVGhlcmUgaXMgbm90aGluZyBuZXcgYWJvdXQgUGF0aCBhbmQgUmVzdiBtZXNzYWdlcyBn ZXR0aW5nIHRyYW5zbWl0dGVkIGluZGVmaW5pdGVseSAodGhpcyBpcyBub3JtYWwgc29mdC1zdGF0 ZSBzaWduYWxpbmcgYmVoYXZpb3IpIC0tIGFsbCB0aGF0IHRoaXMgc2VjdGlvbiBkb2VzIGlzIGRp c2N1c3MgaG93IHRoZXNlIHRyYW5zbWlzc2lvbnMgYXJlIHBhY2VkIGluIHRoZSBhYnNlbmNlIG9m IGFuIGFjay4gVGhlIHNsb3dlciB0aW1lciB0cmFuc21pc3Npb24gd2lsbCBnbyBvbiB1bnRpbCBl aXRoZXIgYW4gYWNrIGlzIHJlY2VpdmVkIChhdCB3aGljaCBwb2ludCB0aGUgcmVndWxhciAicmVm cmVzaCBpbnRlcnZhbCIgY29tZXMgaW50byBwbGF5KSBvciB0aGUgY29ycmVzcG9uZGluZyBMU1Ag aW5zdGFuY2Ugc3RhdGUgaXMgdG9ybiBkb3duLiA8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAu OGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDox ZXgiPgo8YnI+Ck5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOjxicj4KQWJzdHJhY3Q6IFJTVlAtVEUg aXMgbm90IGEgJ3dlbGwta25vd24nIGFiYnJldmlhdGlvbjogcy9SU1ZQLVRFL1JTVlAgVHJhZmZp Yzxicj4KRW5naW5lZXJpbmcgKFJTVlAtVEUpLzxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRl ci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPgo8YnI+ CkFic3RyYWN0IGFuZCBzMSwgZmlyc3QgcGFyYTombmJzcDsgVGhpcyBwYXJhIGlzIG5vdCBmdXR1 cmUgcHJvb2YuJm5ic3A7IFN1Z2dlc3Q6PGJyPgpPTEQ6PGJyPgombmJzcDsgJm5ic3A7VGhlIHNj YWxlIGF0IHdoaWNoIFJTVlAtVEUgW1JGQzMyMDldIExhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1Bz KSBnZXQ8YnI+CiZuYnNwOyAmbmJzcDtkZXBsb3llZCBpcyBncm93aW5nIGNvbnRpbnVhbGx5IGFu ZCB0aGVyZSBpcyBjb25zaWRlcmFibGUgb251cyBvbjxicj4KJm5ic3A7ICZuYnNwO1JTVlAtVEUg aW1wbGVtZW50YXRpb25zIGFjcm9zcyB0aGUgYm9hcmQgdG8ga2VlcCB1cCB3aXRoIHRoaXM8YnI+ CiZuYnNwOyAmbmJzcDtpbmNyZWFzaW5nIGRlbWFuZCBpbiBzY2FsZS48YnI+Ck5FVzo8YnI+CiZu YnNwOyAmbmJzcDtBdCB0aGUgdGltZSBvZiB3cml0aW5nLCBuZXR3b3JrcyB3aGljaCB1dGlsaXNl IFJTVlAgVHJhZmZpYyBFbmdpbmVlcmluZzxicj4KJm5ic3A7ICZuYnNwOyhSU1ZQLVRFKSBbUkZD MzIwOV0gTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMpIGFyZSBlbmNvdW50ZXJpbmcgbGltaXRh dGlvbnM8YnI+CiZuYnNwOyAmbmJzcDtpbiB0aGUgYWJpbGl0eSBvZiBpbXBsZW1lbnRhdGlvbnMg dG8gc3VwcG9ydCB0aGUgZ3Jvd3RoIGluIHRoZSBudW1iZXIgb2YgTFNQczxicj4KJm5ic3A7ICZu YnNwO2RlcGxveWVkLiZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIGFkZGl0aW9uYWwg UlNWUC1URSBleHRlbnNpb25zIHRoYXQ8YnI+CiZuYnNwOyAmbmJzcDthcmUgaW50ZW5kZWQgdG8g cmVkdWNlIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgbmVlZGVkIHRvIG1haW50YWluIFJTVlAtVEU8 YnI+CiZuYnNwOyAmbmJzcDtzb2Z0IHN0YXRlIGluIHJvdXRlcnMgYW5kIGhlbmNlIGFsbG93IGlt cGxlbWVudGF0aW9ucyB0byBzdXBwb3J0IGxhcmdlcjxicj4KJm5ic3A7ICZuYnNwO3NjYWxlIGRl cGxveW1lbnRzLjxicj4KRU5EUzxicj4KTm90ZTombmJzcDsgT21pdCByZWZlcmVuY2UgZnJvbSBB YnN0cmFjdC48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5bVlBCXSBG aXhlZCBpbiAtMDc8L2Rpdj48ZGl2PiA8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBz b2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPgpzMSwgcGFyYSAyOiBzL3Vu ZGVyIGNlcnRhaW4vYmV5b25kIGEgY2VydGFpbi88YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv ZGl2PjxkaXY+W1ZQQl0gRml4ZWQgaW4gLTA3PGJyPjwvZGl2PjxkaXY+IDxicj48L2Rpdj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFl eCI+Cjxicj4KczEsIHBhcmEgMzogcy9tYWtlcyBhIHNldCBvZiBjb25jcmV0ZSBpbXBsZW1lbnRh dGlvbiByZWNvbW1lbmRhdGlvbnMvZGVmaW5lczxicj4KdHdvIGV4dGVuc2lvbnMvOyBzLy0gcHVz aCBoaWdoZXIvYnkgaW5jcmVhc2luZy87IHMvbWFpbnRhaW4gTFNQIHN0YXRlLi9tYWludGFpbjxi cj4KTFNQIHN0YXRlIGJ5IHJlZHVjaW5nIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgbmVlZGVkLi88 YnI+Cjxicj4KQWJzdHJhY3QsIHBhcmEgMiBhbmQgczEsIGxhc3QgcGFyYTombmJzcDsgW09taXQg cmVmZXJlbmNlIGZyb20gQWJzdHJhY3RdPGJyPgpPTEQ6PGJyPgombmJzcDsgJm5ic3A7VGhpcyBk b2N1bWVudCBhZHZvY2F0ZXMgdGhlIHVzZSBvZiBhIGNvdXBsZSBvZiB0ZWNobmlxdWVzIC0gIlJl ZnJlc2gtPGJyPgombmJzcDsgJm5ic3A7SW50ZXJ2YWwgSW5kZXBlbmRlbnQgUlNWUCAoUkktUlNW UCkiIGFuZCAiUGVyLVBlZXIgRmxvdy1Db250cm9sIiAtPGJyPgombmJzcDsgJm5ic3A7Zm9yIHNp Z25pZmljYW50bHkgY3V0dGluZyBkb3duIHRoZSBhbW91bnQgb2YgcHJvY2Vzc2luZyBjeWNsZXM8 YnI+CiZuYnNwOyAmbmJzcDtyZXF1aXJlZCB0byBtYWludGFpbiBMU1Agc3RhdGUuPGJyPgpORVc6 PGJyPgombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBSU1ZQIENhcGFiaWxp dGllcyBbUkZDNTA2M10gIlJlZnJlc2gtPGJyPgombmJzcDsgJm5ic3A7SW50ZXJ2YWwgSW5kZXBl bmRlbnQgUlNWUCAoUkktUlNWUCkiIGFuZCAiUGVyLVBlZXIgRmxvdy1Db250cm9sIjxicj4KJm5i c3A7ICZuYnNwO3RoYXQgd2lsbCBjdXQgZG93biB0aGUgbnVtYmVyIG9mIG1lc3NzYWdlcyBhbmQg cHJvY2Vzc2luZyBjeWNsZXM8YnI+CiZuYnNwOyAmbmJzcDtyZXF1aXJlZCB0byBtYWludGFpbiBM U1Agc3RhdGUuPGJyPgpFTkRTPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PltW UEJdIEZpeGVkIGluIC0wNzxicj48L2Rpdj48ZGl2PiA8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1s ZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPgo8YnI+CnMx LCBsYXN0IHBhcmE6IEFkZCBuZXcgcGVudWx0aW1hdGUgc2VudGVuY2U6PGJyPgombmJzcDsgJm5i c3A7Tm90ZSB0aGF0IHRoZSAiUGVyLVBlZXIgRmxvdy1Db250cm9sIiBjYXBhYmlsaXR5IHJlcXVp cmVzIHRoZSAiUkktUlNWUCI8YnI+CiZuYnNwOyAmbmJzcDtjYXBhYmlsaXR5IGFzIGEgcHJlcmVx dWlzaXRlLjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5bVlBCXSBGaXhlZCBp biAtMDc8YnI+PC9kaXY+PGRpdj4gPGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29s aWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGJyPgpzMSwgbGFzdCBwYXJh OiBzL1JFQ09NTUVOREVEL3JlY29tbWVuZGVkLyAtIHRoaXMgaXNuJ3QgYSByZWNvbW1lbmRhdGlv biBhYm91dDxicj4KdGhlIHByb3RvY29sIG9uIHRoZSB3aXJlLjxicj48L2Jsb2NrcXVvdGU+PGRp dj4mbmJzcDs8L2Rpdj48ZGl2PltWUEJdIEZpeGVkIGluIC0wNzwvZGl2PjxkaXY+IDxicj48L2Rp dj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAw cHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1s ZWZ0OjFleCI+Cjxicj4KU3ViZGl2aXNpb24gb2YgczI6Jm5ic3A7IFRoZSBpc3N1ZXMgcmVnYXJk aW5nIHRoZSBuYXR1cmUgb2YgdGhlIGRvY3VtZW50IHdvdWxkIGJlPGJyPgpoZWxwZWQgYnkgYWx0 ZXJpbmcgczIgaW50byBmb3VyIHRvcCBsZXZlbCBzZWN0aW9ucywgdGh1czogczI6IFJlcXVpcmVt ZW50IGZvcjxicj4KUkZDIDI5NjEgUmVmcmVzaCBPdmVyaGVhZCBSZWR1Y3Rpb24gU3VwcG9ydCBh bmQgU3BlY2lmaWMgT3B0aW9uIENob2ljZXMgKGZyb208YnI+CnMyLjEpIHMzOiBSZXF1aXJlbWVu dCBmb3IgUkZDIDUwNjMgQ2FwYWJpbGl0eSBPYmplY3Qgc3VwcG9ydCAoc2VlIE1pbm9yIElzc3Vl czxicj4KYWJvdmUpIHM0OiBSZWZyZXNoLUludGVydmFsIEluZGVwZW5kZW50IFJTVlAgQ2FwYWJp bGl0eSAoZnJvbSBzMi4zKSBzNTo8YnI+ClBlci1QZWVyIFJTVlAgRmxvdyBDb250cm9sIENhcGFi aWxpdHkgKGZyb20gczIuNCkgU3Vic2VxdWVudCBtYWpvciBzZWN0aW9uczxicj4KdGhlbiByZW51 bWJlcmVkIGFzIHM2IG9ud2FyZHMuIFJlZmVyZW5jZXMgdG8gczIueCB3aWxsIG5lZWQgdG8gYmUg dXBkYXRlZDxicj4KdGhyb3VnaG91dC48YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2Pjxk aXY+W1ZQQl0gV2Ugc3ViZGl2aWRlZCBzMiBpbnRvIDMgdG9wIGxldmVsIHNlY3Rpb25zLiBXZSBk aWQgbm90IGFkZCBhIHNlcGFyYXRlIHNlY3Rpb24gZm9yIGRpc2N1c3NpbmcgUkZDNTA2MyBDYXBh YmlsaXR5IE9iamVjdCBzdXBwb3J0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXIt bGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGJyPgpz Mi4xICh3b3VsZCBiZSBpbnRyb2R1Y3Rpb24gb2YgbmV3IHMyKTo8YnI+Ck9MRDo8YnI+CiZuYnNw OyAmbmJzcDtUaGUgaW1wbGVtZW50YXRpb24gcmVjb21tZW5kYXRpb25zIGRpc2N1c3NlZCBpbiB0 aGlzIHNlY3Rpb24gYXJlPGJyPgombmJzcDsgJm5ic3A7YmFzZWQgb24gdGhlIHByb3Bvc2FscyBt YWRlIGluIFtSRkMyOTYxXSBhbmQgYWN0IGFzIHByZXJlcXVpc2l0ZXMgZm9yPGJyPgombmJzcDsg Jm5ic3A7aW1wbGVtZW50aW5nIHRoZSB0ZWNobmlxdWVzIGRpc2N1c3NlZCBpbiBTZWN0aW9ucyAy LjIgYW5kIDIuMy48YnI+Cjxicj4KTkVXOjxicj4KJm5ic3A7ICZuYnNwO1RoZSBDYXBhYmlsaXRp ZXMgZGVmaW5lZCBpbiBTZWN0aW9ucyA0IGFuZCA1IG9mIHRoaXMgZG9jdW1lbnQgYXJlIGJhc2Vk IG9uPGJyPgombmJzcDsgJm5ic3A7cHJvcG9zYWxzIG1hZGUgaW4gW1JGQzI5NjFdLiZuYnNwOyBJ bXBsZW1lbnRhdGlvbnMgb2YgdGhlc2UgQ2FwYWJpbGl0aWVzIHdpbGw8YnI+CiZuYnNwOyAmbmJz cDtuZWVkIHRvIHN1cHBvcnQgdGhlIFJTVlAgbWVzc2FnZXMgYW5kIHRlY2huaXF1ZXMgZGVmaW5l ZCBpbiBbUkZDMjk2MV0gYXMgc2V0PGJyPgombmJzcDsgJm5ic3A7b3V0IGluIFNlY3Rpb24gMi4x IFt3YXMgMi4xLjFdIHdpdGg8YnI+CiZuYnNwOyAmbmJzcDtzb21lIG1pbm9yIG1vZGlmaWNhdGlv bnMgYW5kIGFsdGVyYXRpb25zIHRvIHJlY29tbWVuZGVkIHRpbWUgaW50ZXJ2YWxzIGFuZDxicj4K Jm5ic3A7ICZuYnNwO2l0ZXJhdGlvbiBjb3VudHMgYXMgZGVmaW5lZCBpbiB0aGUgcmVtYWluZGVy IG9mIHRoaXMgc2VjdGlvbi48YnI+CkVORFM8YnI+Cjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+ PC9kaXY+PGRpdj5bVlBCXSBGaXhlZCBpbiAtMDc8YnI+PC9kaXY+PGRpdj4gPGJyPjwvZGl2Pjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw LjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6 MWV4Ij4KczIuMS4xLCB0aXRsZSBhbmQgcGFyYSAxIFt3aWxsIGJlIHMyLjFdOjxicj4KT0xEOjxi cj4KMi4xLjEuJm5ic3A7IEJhc2ljIFByZXJlcXVpc2l0ZXM8YnI+Cjxicj4KJm5ic3A7ICZuYnNw O0FuIGltcGxlbWVudGF0aW9uIHRoYXQgc3VwcG9ydHMgdGhlIHRlY2huaXF1ZXMgZGlzY3Vzc2Vk IGluIFNlY3Rpb25zPGJyPgombmJzcDsgJm5ic3A7Mi4yIGFuZCAyLjMgbXVzdCBtZWV0IGNlcnRh aW4gYmFzaWMgcHJlcmVxdWlzaXRlcy48YnI+Ck5FVzo8YnI+CjIuMS4mbmJzcDsgUmVxdWlyZWQg RnVuY3Rpb25hbGl0eSBmcm9tIFJGQyAyOTYxIHRvIGJlIEltcGxlbWVudGVkPGJyPgo8YnI+CiZu YnNwOyAmbmJzcDtBbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIHRoZSBjYXBhYmlpdGll cyBkaXNjdXNzZWQgaW4gU2VjdGlvbnM8YnI+CiZuYnNwOyAmbmJzcDs0IGFuZCA1IG11c3QgcHJv dmlkZSBhIGxhcmdlIHN1YnNldCBvZiB0aGUgZnVuY3Rpb25hbGl0eSBkZXNjcmliZWQ8YnI+CiZu YnNwOyAmbmJzcDtpbiBbUkZDMjk2MV0gYXMgZm9sbG93czo8YnI+CkVORFM8YnI+PC9ibG9ja3F1 b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+W1ZQQl0gRml4ZWQgaW4gLTA3PGJyPjwvZGl2PjxkaXY+ IDxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7 cGFkZGluZy1sZWZ0OjFleCI+Cjxicj4KczIuMS4yLCBwYXJhIDIgW3dpbGwgYmUgczIuMl06IHMv dGVjaG5pcXVlcyBkaXNjdXNzZWQgaW4gU2VjdGlvbnMgMi4yIGFuZDxicj4KMi4zL0NhcGFiaWxp dGllcyBkZWZpbmVkIGluIFNlY3Rpb25zIDQgYW5kIDUvPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxi cj48L2Rpdj48ZGl2PltWUEJdIEZpeGVkIGluIC0wNzxicj48L2Rpdj48ZGl2PiA8YnI+PC9kaXY+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4 IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVm dDoxZXgiPgo8YnI+CnMyLjEuMiwgcGFyYSAyOiBzL01FU1NBR0UgSUQvTUVTU0FHRV9JRC88YnI+ PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+W1ZQQl0gRml4ZWQgaW4gLTA3PGJyPjwv ZGl2PjxkaXY+IDxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQs MjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+Cjxicj4KczIuMiwgcGFyYSAxOiBzL2ltcHJvdmVt ZW50IG9uIHRyYW5zbWlzc2lvbiBvdmVyaGVhZC9pbXByb3ZlbWVudCBvZjxicj4KdHJhbnNtaXNz aW9uIG92ZXJoZWFkLzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5bVlBCXSBG aXhlZCBpbiAtMDc8YnI+PC9kaXY+PGRpdj4gPGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDox cHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGJyPgpzMi4yLCBw YXJhIDE6IHMvcHJvcG9zZXMgc3VmZmljaWVudCByZWNvbW1lbmRhdGlvbnMvc2V0cyBvdXQgYWRk aXRpb25hbDxicj4KcmVxdWlyZW1lbnRzLzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+ PGRpdj5bVlBCXSBGaXhlZCBpbiAtMDc8YnI+PC9kaXY+PGRpdj4gPGJyPjwvZGl2PjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4K PGJyPgpzMi4yLCBsYXN0IGJ1bGxldDogQWRkIGEgcmVmZXJlbmNlIHRvIHRoZSBwcm9wb3NlZCBu ZXcgU2VjdGlvbiAzIHRoYXQgZGlzY3Vzc2VzPGJyPgp0aGUgQ2FwYWJpbGl0eSBvYmplY3QuPGJy PjwvYmxvY2txdW90ZT48ZGl2PiZuYnNwOzwvZGl2PjxkaXY+W1ZQQl0gQWRkZWQgYSBkaXJlY3Qg cmVmZXJlbmNlIHRvIFJGQzUwNjM8L2Rpdj48ZGl2PiA8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1s ZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPgo8YnI+CnMy LjIuMSwgbGFzdCBwYXJhOiBzL3NldCBSZWZyZXNoLVJlZHVjdGlvbi1DYXBhYmxlIGJpdCBpbiBj b21tb24gaGVhZGVyL3NldCB0aGU8YnI+ClJlZnJlc2gtUmVkdWN0aW9uLUNhcGFibGUgYml0IGlu IHRoZSBjb21tb24gaGVhZGVyLzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5b VlBCXSBGaXhlZCBpbiAtMDc8YnI+PC9kaXY+PGRpdj4gPGJyPjwvZGl2PjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXIt bGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGJyPgpz Mi4zLCBwYXJhIDE6IHMvc2V0IG9mIHJlY29tbWVuZGF0aW9ucy9mdW5jdGlvbmFsaXR5Lzx3YnI+ OyBzL3Byb3ZpZGUvcHJvdmlkZXMvOzxicj4Kcy9SU1ZQLVRFIGNvbnRyb2wgcGxhbmUgY29uZ2Vz dGlvbi9hIHNpZ25pZmljYW50IHBvcnRpb24gb2YgdGhlIFJTVlAtVEUgY29udHJvbDxicj4KbWVz c2FnZSBsb2FkLzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5bVlBCXSBGaXhl ZCBpbiAtMDc8YnI+PC9kaXY+PGRpdj4gPGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHgg c29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGJyPgpzMi4zLjI6IHMv TUVTU0FHRSBJRC9NRVNTQUdFX0lELzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRp dj5bVlBCXSBGaXhlZCBpbiAtMDc8YnI+PC9kaXY+PGRpdj4gPGJyPjwvZGl2PjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3Jk ZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGJy Pgo8YnI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19f X188YnI+ClRlYXMgbWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86VGVhc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPlRlYXNAaWV0Zi5vcmc8L2E+PGJyPgo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMiIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbDx3YnI+aXN0aW5mby90 ZWFzPC9hPjxicj4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2Rpdj4KPC9ib2R5Pjwv aHRtbD4= ----_com.samsung.android.email_154488561075070--