From nobody Wed Mar 1 08:58:46 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2841295F5; Wed, 1 Mar 2017 08:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.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 YwT51nby81rg; Wed, 1 Mar 2017 08:58:40 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0103.outbound.protection.outlook.com [104.47.38.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CEC1294EB; Wed, 1 Mar 2017 08:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6cDWrm/ddEsnTQM37YS2kqqLFcgDpfZ9IhwKYZfikvA=; b=VrbQIQDNWHlM20LOugJLuahN9oEsNRahjyc4JjojtqnOTkWqUzmwYMjUt+5zLPa5FgeLrKoopf1qcUcX0g5ldi1RHeoeU1+sg2Yed7w2i6fTNgXuWfxPRgp1w0tkP+ggYj51GRTUMWIVzco0ZnsTpakktHTihD6COVKult59u0Q= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1912.namprd02.prod.outlook.com (10.163.75.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 1 Mar 2017 16:58:34 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0933.020; Wed, 1 Mar 2017 16:58:34 +0000 From: Jonathan Hardwick To: Alia Atlas , "draft-ietf-sfc-control-plane@ietf.org" Thread-Topic: Routing directorate review of draft-ietf-sfc-control-plane-08 Thread-Index: AdKSn4ZLvk7rfcNvTmOExgofvam6/A== Date: Wed, 1 Mar 2017 16:58:33 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [86.132.75.121] x-ms-office365-filtering-correlation-id: 11dacaac-3c2c-47e7-3393-08d460c43279 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0201MB1912; x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1912; 7:twe3ZbbMFEGfajEcfOWN4MBt/oPEPolzYEPviNVR2c3YVwLANYq7Z2CESoRQShrCyiuKtGO3RyiG5CeMo9yeCGg7xPO5KoU7sQZXcfk6HmNJyQTYxFnKpDeO614JotnnqDbrHlbUYcYGJLbXwQc7E0+kVq/l2SaI1GnzL52cofKCNn+wsbNyXZasmsHLu+0wfvvQd2fLfiiU6Eywv/BoKrVcnHeLwfC59c6B5/4GtOh1fjpIwDPa4barw52GGhVYil5+deZpzHWIfFbFg68c5mk/ZfbpJOaQMaSP7aMDndpu20I1PAEw4iJr/IGta0FYowQ8TlqG30JJmCapcc0Q+A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:BY2PR0201MB1912; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1912; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(81166006)(86362001)(6306002)(25786008)(102836003)(55016002)(54906002)(606005)(99286003)(6116002)(3846002)(39060400002)(53936002)(3280700002)(122556002)(54896002)(9686003)(8936002)(790700001)(4326008)(236005)(7696004)(6506006)(2501003)(5890100001)(5660300001)(6436002)(77096006)(8676002)(33656002)(2900100001)(50986999)(9326002)(54356999)(7736002)(7906003)(189998001)(92566002)(74316002)(230783001)(3660700001)(2906002)(38730400002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1912; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910AC92526AF0E351F7F6A884290BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 16:58:33.8367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1912 Archived-At: Cc: "rtg-dir@ietf.org" , "sfc@ietf.org" Subject: [sfc] Routing directorate review of draft-ietf-sfc-control-plane-08 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:58:44 -0000 --_000_BY2PR0201MB1910AC92526AF0E351F7F6A884290BY2PR0201MB1910_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8NCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIHJvdXRpbmcgZGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXNmYy1jb250cm9sLXBsYW5lLw0KDQpUaGUgUm91dGluZyBEaXJlY3RvcmF0 ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBh cyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBz b21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LCBhcyBpbiB0aGlzIGNhc2UuIFRoZSBwdXJwb3Nl IG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFE cy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0Rpcg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZS0wOC50eHQN ClJldmlld2VyOiBKb25hdGhhbiBIYXJkd2ljaw0KUmV2aWV3IERhdGU6IDEgTWFyY2ggMjAxNw0K SW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlvbmFsDQoNClN1bW1hcnkNCkkgaGF2ZSBzaWduaWZp Y2FudCBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQgdGhhdCB0aGUg Um91dGluZyBBRHMgZGlzY3VzcyB0aGVzZSBpc3N1ZXMgZnVydGhlciB3aXRoIHRoZSBhdXRob3Jz Lg0KDQpDb21tZW50cw0KDQpEb2N1bWVudCBTY29wZQ0KVGhpcyBkb2N1bWVudCBhaW1zIHRvIGRl c2NyaWJlIHRoZSByZXF1aXJlbWVudHMgdGhhdCB0aGUgU0ZDIGRhdGEgcGxhbmUgaGFzIG9uIHRo ZSBjb250cm9sIHBsYW5lLg0KDQpNeSBtYWpvciBjb25jZXJuIHdpdGggdGhpcyBkb2N1bWVudCBp cyB0aGF0IGl0cyBzY29wZSBpcyB0b28gbmFycm93LiAgV2l0aG91dCBnaXZpbmcgYSBjb250cm9s IHBsYW5lIGFyY2hpdGVjdHVyZSwgdGhpcyBkb2N1bWVudOKAmXMgdXNlZnVsbmVzcyBpcyBxdWl0 ZSBsaW1pdGVkLg0KDQpUaGUgZG9jdW1lbnQgaXMgcHJlc3VtYWJseSB1c2VmdWwgdG8gcGVvcGxl IHdvcmtpbmcgd2l0aGluIHRoZSBTRkMgV0cgYXMgYSBjaGVja2xpc3Qgb2YgdGhlaXIgcmVxdWly ZW1lbnRzLiAgSSBhc3N1bWUgKGFuZCBob3BlKSB0aGF0IFNGQyB3aWxsIGluIGZ1dHVyZSBwdWJs aXNoIGEgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgdGhhdCB3aWxsIHNhdGlzZnkgdGhlc2Ug cmVxdWlyZW1lbnRzLg0KDQpTcGVha2luZyB3aXRoIG15IGltcGxlbWVudGVyIGhhdCBvbiwgdGhp cyBkb2N1bWVudCBpcyBub3QgdXNlZnVsIHRvIG1lIGFzIGl0IGRvZXMgbm90IGRlc2NyaWJlIGFu eXRoaW5nIHRoYXQgSSBjYW4gaW1wbGVtZW50LiAgSXQgZG9lcyBub3QgZGVzY3JpYmUgd2hhdCB0 aGUgY29udHJvbCBwbGFuZSBsb29rcyBsaWtlLCB3aGF0IGJ1aWxkaW5nIGJsb2NrcyB0byB1c2Us IGV0Yy4NCg0KU3BlYWtpbmcgd2l0aCBteSBJRVRGIFdHIGNoYWlyIGhhdCBvbiwgdGhpcyBkb2N1 bWVudCBpcyBub3QgdXNlZnVsIHRvIG1lIGFzIGl0IGdpdmVzIG5vIHN0ZWVyIGFzIHRvIHdoYXQg cHJvdG9jb2xzIHdpbGwgYmUgZW1wbG95ZWQsIG9yIGhvdy4gIFRoaXMgaXMgY2F1c2luZyBkaWZm aWN1bHRpZXMgZm9yIG90aGVyIHdvcmtpbmcgZ3JvdXBzLiAgRm9yIGV4YW1wbGUsIHNvbWVvbmUg cmVjZW50bHkgY2FtZSB0byB0aGUgUENFIFdHIHdpdGggYSBkcmFmdCBkZXNjcmliaW5nIGFuIFNG QyBjb250cm9sIHBsYW5lIGltcGxlbWVudGVkIHdpdGggUENFUC4gIEkgaGF2ZSBubyBpZGVhIGlm IHRoZSBTRkMgV0cgd2FudHMgdG8gdXNlIFBDRVAgaW4gaXRzIGNvbnRyb2wgcGxhbmUsIHNvIEkg YW0gdW5hYmxlIHRvIGFkb3B0IHNhaWQgZHJhZnQuICBNZWFud2hpbGUsIHRoZXJlIGlzIGEgZHJh ZnQgaW4gQkVTUyB0aGF0IGRvY3VtZW50cyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IFNGQyBjb250 cm9sIHBsYW5lLCBhbmQgdGhlcmUgbWF5IGJlIG90aGVycy4gIFdlIGFyZSBpbiBhIGNvbmZ1c2lu ZyBzaXR1YXRpb24gYW5kIHRoZSBwcm9wb3NhbHMgYXJlIHByb2xpZmVyYXRpbmcuICBUaGUgU0ZD IHdvcmtpbmcgZ3JvdXAgbmVlZHMgdG8gc3RlZXIgdGhlIHByb3RvY29sIGRldmVsb3BtZW50IHdv cmssIGJ1dCB0aGlzIGRvY3VtZW50IGlzIGNvbXBsZXRlbHkgc2lsZW50IG9uIGl0Lg0KDQpBcyBz dWNoLCBJIGFtIG5vdCBzdXJlIHRoYXQgaXQgaXMgd29ydGggdGhlIElFVEYgcHVibGlzaGluZyB0 aGlzIGRvY3VtZW50IGFzIGl0IHN0YW5kcy4gIEhvd2V2ZXIsIEkgZG8gdmVyeSBtdWNoIGVuY291 cmFnZSB0aGUgU0ZDIHdvcmtpbmcgZ3JvdXAgdG8gY29udGludWUgdGhlaXIgd29yayBvbiB0aGUg Y29udHJvbCBwbGFuZSBhbmQgdG8gZGV2ZWxvcCBhbiBhcmNoaXRlY3R1cmUgd2hpY2ggZGVzY3Jp YmVzIGl0Lg0KDQpJZiB3ZSBkbyBnbyBhaGVhZCBhbmQgcHVibGlzaCB0aGlzLCB0aGVuIEkgYmVs aWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQgYmUgcmVzdHJ1Y3R1cmVkIGFuZCBtYWRlIG11 Y2ggYnJpZWZlci4NCg0KRG9jdW1lbnQgQ29udGVudA0KVGhlIGRvY3VtZW50IHN0cmF5cyBpbnRv IGRpc2N1c3Npb25zIG9mIG1hbmFnZW1lbnQgcGxhbmUgb3BlcmF0aW9uIGFuZCByZXF1aXJlbWVu dHMuICBGb3IgZXhhbXBsZSwgYWxsIG9mIHNlY3Rpb24gNC4zIHRhbGtzIGFib3V0IG1hbmFnZW1l bnQgcGxhbmUgb3BlcmF0aW9uIGFuZCBkb2VzIG5vdCBtYWtlIGl0IGNsZWFyIHdoYXQgdGhlIGlt cGxpY2F0aW9ucyBmb3IgdGhlIGNvbnRyb2wgcGxhbmUgYXJlLiAgSSByZWNvbW1lbmQgdGhhdCB0 aGUgZG9jdW1lbnQgaXMgcmV2aWV3ZWQgd2l0aGluIFNGQyBhbmQgYW55dGhpbmcgdGhhdCBkb2Vz IG5vdCB0YWxrIGFib3V0IGEgY2xlYXIgY29udHJvbCBwbGFuZSBpbXBsaWNhdGlvbiBpcyB0YWtl biBvdXQuDQoNClRoZSBkb2N1bWVudCBmcmVxdWVudGx5IGRpZ3Jlc3NlcyBpbnRvIGdpdmluZyBs aXN0cyBvZiBleGFtcGxlcy4gIEZvciBleGFtcGxlLCBzZWN0aW9uIDMuMy4xLCAzLjMuMywgNC40 LCA0LjcsIDQuOC4gIFRoaXMgaXMgbm90IGEgaGVscGZ1bCB3YXkgdG8gY2FwdHVyZSByZXF1aXJl bWVudHMuICBJbnN0ZWFkIG9mIGdpdmluZyBvcGVuIGVuZGVkIGxpc3RzLCB0aGUgZG9jdW1lbnQg c2hvdWxkIGRpc3RpbCBhIHNldCBvZiByZXF1aXJlbWVudHMgb3V0IG9mIHRoZSBrbm93biBleGFt cGxlcywgYW5kIHN0YXRlIHRoZSByZXF1aXJlbWVudHMgaW5zdGVhZC4NCg0KU29tZSBvZiB0aGUg cGFzc2FnZXMgaW4gdGhlIGRvY3VtZW50IGZlbHQgc3VwZXJmbHVvdXMuDQoNCkEpICAgICBTZWN0 aW9uIDMuMi4gIEkgdGhpbmsgdGhpcyBzZWN0aW9uIGFkZHMgbm90aGluZy4NCg0KQikgICAgIFRo ZSBsaXN0IG9mIOKAnGZ1bmN0aW9uYWwgb2JqZWN0aXZlc+KAnSBpbiAzLjMuMS4NCg0KQykgICAg IFNlY3Rpb24gNC4zLCB3aGVyZSwgYXMgc3RhdGVkIGFib3ZlLCBJIGRvbuKAmXQgc2VlIHRoZSBy ZWxldmFuY2UuDQoNCkQpICAgICBTZWN0aW9uIDQuNS4gIFRoaXMganVzdCBzZWVtcyB0byBiZSBz YXlpbmcgdGhhdCB0aGUgY29udHJvbCBwbGFuZSBuZWVkcyB0byBiZSBhYmxlIHRvIG1vZGlmeSBT RkNzLiAgSSBkb27igJl0IGZpbmQgdGhhdCBzdXJwcmlzaW5nLiAgSeKAmWQgYmUgaGFwcGllciBp ZiB0aGlzIHdhcyByZXdyaXR0ZW4gdG8gdGFsayBhYm91dCB3aGF0IHRoZSBjb250cm9sIHBsYW5l IG11c3QgZG8uDQoNClRoZSBkb2N1bWVudCBpcyBsYXJnZWx5IHdyaXR0ZW4gaW4gdGhlIHBhc3Np dmUgdm9pY2UsIHdoaWNoIG1ha2VzIHVuZGVyc3RhbmRpbmcgaXQgcXVpdGUgaGFyZC4gIFRvIHRh a2UgYW4gZXhhbXBsZSwgaW4gc2VjdGlvbiA0LjcuDQoNCk9MRCAocGFzc2l2ZSB2b2ljZSkNCiAg IExpdmVuZXNzIHN0YXR1cyByZWNvcmRzIGZvciBhbGwgU0YgaW5zdGFuY2VzLCBhbmQgc2Vydmlj ZSBmdW5jdGlvbg0KICAgY2hhaW5zIChpbmNsdWRpbmcgdGhlIFNGUHMgYm91bmQgdG8gYSBnaXZl biBjaGFpbikgYXJlIG1haW50YWluZWQgYnkNCiAgIHRoZSBTRkMgQ29udHJvbC4NCk5FVyAoYWN0 aXZlIHZvaWNlKQ0KDQogICBUaGUgU0ZDIGNvbnRyb2wgcGxhbmUgbXVzdCBtb25pdG9yIHRoZSBs aXZlbmVzcyBvZiBhbGwgU0YgaW5zdGFuY2VzLCBhbmQgYWxsIHNlcnZpY2UgZnVuY3Rpb24NCg0K ICAgY2hhaW5zIChpbmNsdWRpbmcgdGhlIFNGUHMgYm91bmQgdG8gYSBnaXZlbiBjaGFpbikuDQoN CkkgcmVjb21tZW5kIHRoYXQgYW4gRW5nbGlzaCBzcGVha2VyIG92ZXJoYXVscyB0aGUgdGV4dCBh bmQgcmVwbGFjZXMgdGhlIHBhc3NpdmUgdm9pY2Ugd2l0aCB0aGUgYWN0aXZlIHZvaWNlLg0KDQpE b2N1bWVudCBTdHJ1Y3R1cmUNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB0aGUgZG9jdW1lbnQg c2VwYXJhdGVzIGNoYXB0ZXIgMiDigJxHZW5lcmljIENvbnNpZGVyYXRpb25z4oCdIGFuZCBjaGFw dGVyIDQg4oCcQWRkaXRpb25hbCBjb25zaWRlcmF0aW9uc+KAnS4gIFRoZXkgYWxsIGp1c3QgbG9v ayBsaWtlIHJlcXVpcmVtZW50cyB0byBtZS4gIEkgd291bGQgcHV0IGNoYXB0ZXIgMyBmaXJzdCwg dGhlbiBtZXJnZSBjaGFwdGVycyAyIGFuZCA0LCBhbmQgdHJ5IHRvIGRpc3RpbCB0aGUgcmVzdWx0 aW5nIHRleHQgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KRGV0YWlsZWQgY29tbWVudHMNCg0KU2Vj dGlvbiAyLjIuDQpUaGUgbGlzdCBvZiBpbmZvcm1hdGlvbiBwcm92aWRlZCBwcmlvciB0byBib290 c3RyYXBwaW5nIGluY2x1ZGVzIOKAnFNGcyBzZXJ2aWNlZCBieSBlYWNoIFNGRuKAnSBidXQgdGhl IGluZm9ybWF0aW9uIGNvbGxlY3RlZCBkdXJpbmcgYm9vdHN0cmFwcGluZyBpbmNsdWRlcyDigJxU aGUgbGlzdCBvZiBTRkZzIGFuZCB0aGUgU0ZzIHRoYXQgYXJlIGF0dGFjaGVkIHRv4oCdLiAgQXJl buKAmXQgdGhleSB0aGUgc2FtZSB0aGluZz8NCg0KU2VjdGlvbiAzLjENCnMvIFNlY3Rpb24gMy4z LjIgc3BlY2lmaWVzIHN1Y2ggaW50ZXJmYWNlLi8gU2VjdGlvbiAzLjMuMiBzcGVjaWZpZXMgdGhp cyBpbnRlcmZhY2UuLw0KVGhlIGZpbmFsIHBhcmFncmFwaCBmZWVscyBvdXQgb2YgcGxhY2UgaW4g dGhpcyBzZWN0aW9uLg0KDQpTZWN0aW9uIDMuMg0Kcy9kdXJpbmcgbmV0d29yayBhdHRhY2htZW50 IHBoYXNlL2R1cmluZyB0aGUgbmV0d29yayBhdHRhY2htZW50IHBoYXNlLw0Kcy9Cb3RoIGNlbnRy YWxpemVkIGFuZCBkaXN0cmlidXRlZCBtZWNoYW5pc20vQm90aCBjZW50cmFsaXplZCBhbmQgZGlz dHJpYnV0ZWQgbWVjaGFuaXNtcy8NCg0KU2VjdGlvbiAzLjMuMQ0K4oCcVGhlIFNGQyBjb250cm9s IHBsYW5lIHNob3VsZCBiZSByZXNwb25zaWJsZeKAnSAgV2hhdCBkbyB5b3UgbWVhbiDigJxzaG91 bGQgYmXigJ0/ICBSZXNwb25zaWJpbGl0eSBzaG91bGQgYmUgY2xlYXJseSBhc3NpZ25lZC4NCuKA nOKApmJlIHBhcnQgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb24gZGlzY292ZXJ5IHByb2NlZHVyZeKA nSBXaGF0IGlzIHRoYXQ/ICBGaXJzdCBtZW50aW9uIG9mIGl0Lg0K4oCcbWVhbnMgdG8gcmVkdWNl IGNsYXNzaWZpY2F0aW9uIGxvb2t1cCB0aW1lIOKApiBzaG91bGQgYmUgc3VwcG9ydGVkIGJ5IHRo ZSBTRkMgY29udHJvbCBwbGFuZeKAnSDigJMgV2h5PyAgSXNu4oCZdCB0aGF0IGEgam9iIGZvciB0 aGUgY2xhc3NpZmllciB0byBsb2NhbGx5IG9wdGltaXplPw0Kcy90aGFua3MgdG8gdGhlIGludm9j YXRpb24gb2YvYnkgaW52b2tpbmcvDQpzL2RvZXMgbm90IGNvbnZleSB0aGF0IHNlbWFudGljcy8g ZG9lcyBub3QgY29udmV5IHRob3NlIHNlbWFudGljcy8NCnMvdHJ1c3QgYW4gZXhpc3RpbmcgU0ZD IGluZm9ybWF0aW9uLyB0cnVzdCBleGlzdGluZyBTRkMgaW5mb3JtYXRpb24gLw0Kcy9jb25maWd1 cmFibGUgcGFyYW1ldGVyL2NvbmZpZ3VyYWJsZSBwYXJhbWV0ZXJzLw0KDQpTZWN0aW9uIDMuMy4y DQpzL1N1Y2ggdGFibGUvVGhpcyB0YWJsZS8NCnMvU3VjaCBpbnN0cnVjdCB0eXBpY2FsbHkvVGhp cyB0eXBpY2FsbHkvDQrigJxncm91cHMgb2YgZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgU0ZzIOKA piBtYXkgYmUgdXNlZCBmb3IgbG9hZC1iYWxhbmNpbmcgcHVycG9zZXPigJ0gIFdoYXQgaXMgdGhl IHJlbGV2YW5jZSB0byB0aGUgY29udHJvbCBwbGFuZSB0aGF0IHRoZXkgbWF5IGJlIHVzZWQgZm9y IGxvYWQgYmFsYW5jaW5nPyAgV2hlbiB5b3Ugc2F5IOKAnG1heSBiZSB1c2Vk4oCdIGRvIHlvdSBt ZWFuIGluIGFsbCBjaXJjdW1zdGFuY2VzLCBvciBkbyB5b3UgbWVhbiBvbmx5IGluIHNvbWUgY2ly Y3Vtc3RhbmNlcz8NCuKAnEJ5IGRlZmF1bHQsIGFuIFNGRiByZWxpZXMgb24gbGVnYWN5IHByb2Nl c3NpbmcgZm9yIGZvcndhcmRpbmcgdGhlc2UgcGFja2V0cy7igJ0gIERvZXMg4oCcbGVnYWN5IHBy b2Nlc3NpbmfigJ0gbWVhbiBmb3J3YXJkaW5nIHVzaW5nIGV4aXN0aW5nIG5ldHdvcmsgaGVhZGVy cz8gIEkgd291bGQgbm90IGNhbGwgdGhhdCDigJxsZWdhY3nigJ0uDQoNClNlY3Rpb24gMy4zLjMN CuKAnFNGcyBtYXkgbmVlZCB0byBvdXRwdXQgc29tZSBwcm9jZXNzaW5nIHJlc3VsdHMgb2YgcGFj a2V0c+KAnSBpcyB0b28gd29vbGx5Lg0K4oCcVGhlIFNGQyBjb250cm9sIG5lZWRzIHRoZSBhYm92 ZSBzdGF0dXMgaW5mb3JtYXRpb24gZm9yIHZhcmlvdXMgdGFza3PigJ0gaXMgYWxzbyB0b28gd29v bGx5Lg0KSW4gdGhpcyBzZWN0aW9uIHdoZXJlIHlvdSBzYXkgKG11bHRpcGxlIHRpbWVzKSDigJxh IGNvbnRleHQgaW5mb3JtYXRpb27igJ0gZG8geW91IG1lYW4g4oCcdGhlIGNvbnRleHQgaGVhZGVy cyBpbiB0aGUgTlNI4oCdPyAgVGhlIGxhdHRlciB3b3VsZCBiZSBjbGVhcmVyLg0K4oCcTm90ZSB0 aGF0IGEgY29udGV4dCBtYXkgYmUgbWFuZGF0b3J5IGZvciAiY2hhaW4gMSIsIGJ1dCBvcHRpb25h bCBmb3IgImNoYWluIDIiLuKAnSAgU3VyZSwgYnV0IHdoYXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMg b2YgdGhpcyBmb3IgdGhlIGNvbnRyb2wgcGxhbmU/DQrigJxNdWx0aXBsZSBTRnMgbWF5IGJlIGxv Y2F0ZWQgd2l0aGluIHRoZSBzYW1lIHBoeXNpY2FsIG5vZGUsIGJ1dCBubyBTRkYgaXMgZW5hYmxl ZCBpbiB0aGF0IHNhbWUgbm9kZSwgbWVhbnMgdG8gdW5hbWJpZ3VvdXNseSBmb3J3YXJkIHRoZSB0 cmFmZmljIGZyb20gdGhlIFNGRiB0byB0aGUgYXBwcm9wcmlhdGUgU0YgbXVzdCBiZSBzdXBwb3J0 ZWQu4oCdIOKAkyBJIGNhbuKAmXQgcGFyc2UgdGhpcyBzZW50ZW5jZS4NCuKAnENvbmNyZXRlbHks IGVhY2ggU0YgbXVzdCBoYXZlIGEgdW5pcXVlIGxvY2F0b3IgZm9yIHVuYW1iaWd1b3VzIGZvcndh cmRpbmcuICBUaGlzIGxvY2F0b3IgbWF5IGJlIGNvbmZpZ3VyZWQgdXNpbmcgdGhpcyBpbnRlcmZh Y2Uu4oCdICBUaGlzIHNvdW5kcyBsaWtlIGEgZGVzY3JpcHRpb24gb2YgbWFuYWdlbWVudCBwbGFu ZSBmdW5jdGlvbiwgbm90IGNvbnRyb2wgcGxhbmUgZnVuY3Rpb24uICBXaGF0IGltcGxpY2F0aW9u cyBkb2VzIHRoZSBsb2NhdG9yIGhhdmUgZm9yIHRoZSBjb250cm9sIHBsYW5lPw0K4oCcU3BlY2lh bCBjYXJlIHNob3VsZCBiZSBjb25zaWRlcmVkIHRvIGF2b2lkIHRoYXQgaW5zdHJ1Y3Rpb25zIHBy b3ZpZGVkIHRvIGRpc3RpbmN0IFNGcyBsZWFkIHRvIGxvb3BzLuKAnSAgUmV3cml0ZSB0byBzYXkg d2hhdCB0aGUgY29udHJvbCBwbGFuZSBtdXN0IGRvIHRvIGF2b2lkIG9yIG1pdGlnYXRlIGxvb3Bz Lg0KDQpTZWN0aW9uIDQuMQ0Kcy92YXJpZXR5IGlmIG1lY2hhbmlzbXMvdmFyaWV0eSBvZiBtZWNo YW5pc21zLw0KDQpTZWN0aW9uIDQuMg0Kcy9ib3RoIGRpcmVjdGlvbiBvZi9ib3RoIGRpcmVjdGlv bnMgb2YvDQpXaGF0IGRvZXMg4oCcZnVsbCBjaGFpbiBzeW1tZXRyeeKAnSBtZWFuPw0KDQpTZWN0 aW9uIDQuNA0Kcy8gYWNjb21tb2RhdGUgc3VjaCBjb250ZXh0LyBhY2NvbW1vZGF0ZSB0aGlzLw0K VGhpcyBzZWN0aW9uIGdpdmVzIGEgY291cGxlIG9mIGV4YW1wbGVzLiAgQXJlIHlvdSBnaXZpbmcg YSBzdWJzZXQgb2YgYWxsIHBvc3NpYmxlIG9wdGlvbnM/ICBBcmUgeW91IHNheWluZyB0aGUgY29u dHJvbCBwbGFuZSBjYW4gZG8gZWl0aGVyLCBvciBib3RoLCBvciBzb21ldGltZXMgb25lIGFuZCBz b21ldGltZXMgdGhlIG90aGVyPw0KDQpTZWN0aW9uIDQuNg0K4oCcU3BlY2lmaWMgY3JpdGVyaWEg dG8gc2VuZCB1bnNvbGljaXRlZCBub3RpZmljYXRpb25zIHRvIGEgQ29udHJvbCBFbGVtZW50IHNo b3VsZCBiZSBmaW5lIHR1bmVkIGJ5IHRoZSBjb250cm9sIHBsYW5l4oCdICBXaGF0IGRvIHlvdSBt ZWFuIGJ5IOKAnGZpbmUgdHVuZWTigJ0/ICBXaGF0IGRvZXMgdGhlIGNvbnRyb2wgcGxhbmUgYWN0 dWFsbHkgbmVlZCB0byBkbz8NCg0KU2VjdGlvbiA0LjcNCnMvbGl2ZWxpbmVzcy9saXZlbmVzcy8N CuKAnFRoZSBjbGFzc2lmaWVyIG1heSBiZSBub3RpZmllZCBieSB0aGUgY29udHJvbCBwbGFuZeKA nSDigJMgTm90aWZpZWQgb2Ygd2hhdD8NCuKAnFRoZSBhYmlsaXR5IG9mIGFuIFNGQyBDb250cm9s IEVsZW1lbnQgdG8gY2hlY2sgdGhlIGxpdmVuZXNzIG9mIGVhY2ggU0YgcHJlc2VudCBpbiBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWluIGhhcyBzZXZlcmFsIGFkdmFudGFnZXPigKbigJ0g4oCTIEFkdmFu dGFnZXMgb3ZlciB3aGF0PyAgRG8geW91IGp1c3QgbWVhbiBpdCBoYXMgc2V2ZXJhbCDigJxmZWF0 dXJlc+KAnT8gIFdoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgbGlzdGluZyB0aG9zZSBmZWF0dXJlcz8g IFdoYXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMgZm9yIHRoZSBjb250cm9sIHBsYW5lPyAgQXJlIHlv dSBnaXZpbmcgYSBsaXN0IG9mIHRoaW5ncyB0aGUgY29udHJvbCBwbGFuZSBtdXN0IGRvPw0K4oCc Q29udHJvbCBFbGVtZW50cyBtYXkgYmUgZmVkIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkgd2l0aCBp bnB1dHMgZnJvbSB0aGVzZSBtZWNoYW5pc21zLuKAnSDigJMgV2hhdCBkbyB5b3UgbWVhbiBieSBk aXJlY3RseSB2ZXJzdXMgaW5kaXJlY3RseT8gIElzIHRoaXMgcGFydCBvZiBvbmUgb2YgdGhlIEN4 IGludGVyZmFjZXM/DQoNClNlY3Rpb24gNC44DQrigJxFdmVuIGlmIHNldHRpbmcgdGhlIGRhdGEg Y29sbGVjdGlvbiBjeWNsZSBpcyBkZXBsb3ltZW50LXNwZWNpZmljLCBpdCBpcyByZWNvbW1lbmRl ZCB0byBzdXBwb3J0IGR5bmFtaWMgbWVhbnPigKbigJ0gIFdoYXQgZG8geW91IG1lYW4gYnkg4oCc ZHluYW1pYyBtZWFuc+KAnT8NCg0KU2VjdGlvbiA0LjkNCuKAnEJvdGggc2hvcnQgYW5kIGxvbmcg bGlmZXRpbWVzIG1heSBiZSBhc3NpZ25lZC7igJ0g4oCTIElzIG5vdCByZWFsbHkgYSB1c2VmdWwg c3RhdGVtZW50LiAgV2hhdCBhcmUgdGhlIGltcGxpY2F0aW9ucyBmb3IgdGhlIGNvbnRyb2wgcGxh bmU/ICBBIHVzZWZ1bCBzdGF0ZW1lbnQgd291bGQgaW5jbHVkZSB3aGF0IHVuaXRzIHRoZXNlIGxp ZmV0aW1lcyBzaG91bGQgYmUgY29udmV5ZWQgaW4sIGFuZCB0aGVpciB2YWxpZCByYW5nZS4NCg0K U2VjdGlvbiA0LjEwLjENCnMvY2hhbmdlcyBzaG91bGQgbW9uaXRvcmVkL2NoYW5nZXMgc2hvdWxk IGJlIG1vbml0b3JlZC8NCnMvb3ZlcmxhZGVkL292ZXJsb2FkZWQvDQpJbiB0aGUgcHJvY2VkdXJl cyBmb3IgU0ZQIGFkanVzdG1lbnQsIHBsZWFzZSBnaXZlIG1vcmUgZGV0YWlsIG9uIHRoZSBjb250 cm9sIHBsYW5lIHJlcXVpcmVtZW50cyBmb3Ig4oCcUmVwbGFjZSB0YXJnZXQgU0YgaW5zdGFuY2Vz IChlLmcuLCBpbiBhIGZhaWx1cmUgb3Igb3ZlcmxhZGVkKSB3aXRoIG5ld2x5IHNlbGVjdGVkIG9u ZXMu4oCdICBIb3cgaXMgdGhpcyB0byBiZSBkb25lPyAgSSBhc3N1bWUgbWFrZSBiZWZvcmUgYnJl YWsgaXMgcmVxdWlyZWQuICBBcmUgdGhlcmUgYW55IG90aGVyIGNvbnRyb2wgcGxhbmUgcmVxdWly ZW1lbnRzPw0KDQpTZWN0aW9uIDQuMTAuMw0KUGxlYXNlIGV4cGxhaW4gd2hhdCB5b3UgbWVhbiBi eSDigJxyZWdpb25hbCByZXN0b3JhdGlvbuKAnS4NCkl0IGlzbuKAmXQgY2xlYXIgdG8gbWUgd2hh dCB0aGUgZmlyc3QgMyBwYXJhZ3JhcGhzIGluIHRoaXMgc2VjdGlvbiBoYXZlIHRvIGRvIHdpdGgg dGhlIGZpbmFsIHR3bywgYnV0IHBlcmhhcHMgaWYgSSB1bmRlcnN0b29kIHdoYXQg4oCccmVnaW9u YWwgcmVzdG9yYXRpb27igJ0gbWVhbnQgaXQgd291bGQgYmUgY2xlYXJlci4NCg0KDQo= --_000_BY2PR0201MB1910AC92526AF0E351F7F6A884290BY2PR0201MB1910_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLUdCO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDU2NDg3ODU1Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo5OTM5MjcwMzIg LTIwODI1MTUxNiAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3 NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS11cHBlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFc KSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoyMDEzMDcwMjQ1Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTY1NTU3MDI4IDEzNDgwNzU3NSAx MzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2 NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSByb3V0aW5n IGRpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLWNvbnRyb2wtcGxhbmUvPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJv dXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRG IGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1 ZXN0LCBhcyBpbiB0aGlzIGNhc2UuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJv dmlkZSBhc3Npc3RhbmNlIHRvDQogdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigIs8YSBocmVmPSJo dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIj5odHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFu ZS0wOC50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJldmlld2VyOiBK b25hdGhhbiBIYXJkd2ljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2 aWV3IERhdGU6IDEgTWFyY2ggMjAxNzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlvbmFsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjx1PlN1bW1hcnk8bzpwPjwvbzpwPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhh dmUgc2lnbmlmaWNhbnQgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVjb21tZW5k IHRoYXQgdGhlIFJvdXRpbmcgQURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0 aGUgYXV0aG9ycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+Q29tbWVudHM8bzpwPjwvbzpw PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjx1PkRvY3VtZW50IFNjb3BlPG86cD48L286cD48L3U+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVudCBhaW1zIHRvIGRlc2NyaWJlIHRoZSBy ZXF1aXJlbWVudHMgdGhhdCB0aGUgU0ZDIGRhdGEgcGxhbmUgaGFzIG9uIHRoZSBjb250cm9sIHBs YW5lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBtYWpvciBjb25jZXJuIHdpdGggdGhpcyBk b2N1bWVudCBpcyB0aGF0IGl0cyBzY29wZSBpcyB0b28gbmFycm93LiZuYnNwOyBXaXRob3V0IGdp dmluZyBhIGNvbnRyb2wgcGxhbmUgYXJjaGl0ZWN0dXJlLCB0aGlzIGRvY3VtZW504oCZcyB1c2Vm dWxuZXNzIGlzIHF1aXRlIGxpbWl0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkb2N1 bWVudCBpcyBwcmVzdW1hYmx5IHVzZWZ1bCB0byBwZW9wbGUgd29ya2luZyB3aXRoaW4gdGhlIFNG QyBXRyBhcyBhIGNoZWNrbGlzdCBvZiB0aGVpciByZXF1aXJlbWVudHMuJm5ic3A7IEkgYXNzdW1l IChhbmQgaG9wZSkgdGhhdCBTRkMgd2lsbCBpbiBmdXR1cmUgcHVibGlzaCBhIGNvbnRyb2wgcGxh bmUgYXJjaGl0ZWN0dXJlIHRoYXQgd2lsbCBzYXRpc2Z5IHRoZXNlIHJlcXVpcmVtZW50cy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlYWtpbmcgd2l0aCBteSBpbXBsZW1lbnRlciBoYXQgb24s IHRoaXMgZG9jdW1lbnQgaXMgbm90IHVzZWZ1bCB0byBtZSBhcyBpdCBkb2VzIG5vdCBkZXNjcmli ZSBhbnl0aGluZyB0aGF0IEkgY2FuIGltcGxlbWVudC4mbmJzcDsgSXQgZG9lcyBub3QgZGVzY3Jp YmUgd2hhdCB0aGUgY29udHJvbCBwbGFuZSBsb29rcyBsaWtlLCB3aGF0IGJ1aWxkaW5nIGJsb2Nr cyB0byB1c2UsIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlYWtpbmcgd2l0aCBteSBJ RVRGIFdHIGNoYWlyIGhhdCBvbiwgdGhpcyBkb2N1bWVudCBpcyBub3QgdXNlZnVsIHRvIG1lIGFz IGl0IGdpdmVzIG5vIHN0ZWVyIGFzIHRvIHdoYXQgcHJvdG9jb2xzIHdpbGwgYmUgZW1wbG95ZWQs IG9yIGhvdy4mbmJzcDsgVGhpcyBpcyBjYXVzaW5nIGRpZmZpY3VsdGllcyBmb3Igb3RoZXIgd29y a2luZyBncm91cHMuJm5ic3A7IEZvciBleGFtcGxlLCBzb21lb25lIHJlY2VudGx5IGNhbWUgdG8N CiB0aGUgUENFIFdHIHdpdGggYSBkcmFmdCBkZXNjcmliaW5nIGFuIFNGQyBjb250cm9sIHBsYW5l IGltcGxlbWVudGVkIHdpdGggUENFUC4mbmJzcDsgSSBoYXZlIG5vIGlkZWEgaWYgdGhlIFNGQyBX RyB3YW50cyB0byB1c2UgUENFUCBpbiBpdHMgY29udHJvbCBwbGFuZSwgc28gSSBhbSB1bmFibGUg dG8gYWRvcHQgc2FpZCBkcmFmdC4mbmJzcDsgTWVhbndoaWxlLCB0aGVyZSBpcyBhIGRyYWZ0IGlu IEJFU1MgdGhhdCBkb2N1bWVudHMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudA0KIFNGQyBjb250cm9s IHBsYW5lLCBhbmQgdGhlcmUgbWF5IGJlIG90aGVycy4mbmJzcDsgV2UgYXJlIGluIGEgY29uZnVz aW5nIHNpdHVhdGlvbiBhbmQgdGhlIHByb3Bvc2FscyBhcmUgcHJvbGlmZXJhdGluZy4mbmJzcDsg VGhlIFNGQyB3b3JraW5nIGdyb3VwIG5lZWRzIHRvIHN0ZWVyIHRoZSBwcm90b2NvbCBkZXZlbG9w bWVudCB3b3JrLCBidXQgdGhpcyBkb2N1bWVudCBpcyBjb21wbGV0ZWx5IHNpbGVudCBvbiBpdC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgc3VjaCwgSSBhbSBub3Qgc3VyZSB0aGF0IGl0IGlz IHdvcnRoIHRoZSBJRVRGIHB1Ymxpc2hpbmcgdGhpcyBkb2N1bWVudCBhcyBpdCBzdGFuZHMuJm5i c3A7IEhvd2V2ZXIsIEkgZG8gdmVyeSBtdWNoIGVuY291cmFnZSB0aGUgU0ZDIHdvcmtpbmcgZ3Jv dXAgdG8gY29udGludWUgdGhlaXIgd29yayBvbiB0aGUgY29udHJvbCBwbGFuZSBhbmQgdG8gZGV2 ZWxvcCBhbiBhcmNoaXRlY3R1cmUgd2hpY2ggZGVzY3JpYmVzDQogaXQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklmIHdlIGRvIGdvIGFoZWFkIGFuZCBwdWJsaXNoIHRoaXMsIHRoZW4gSSBiZWxp ZXZlIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBiZSByZXN0cnVjdHVyZWQgYW5kIG1hZGUgbXVj aCBicmllZmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT5Eb2N1bWVudCBDb250ZW50PG86 cD48L286cD48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRvY3VtZW50IHN0cmF5 cyBpbnRvIGRpc2N1c3Npb25zIG9mIG1hbmFnZW1lbnQgcGxhbmUgb3BlcmF0aW9uIGFuZCByZXF1 aXJlbWVudHMuJm5ic3A7IEZvciBleGFtcGxlLCBhbGwgb2Ygc2VjdGlvbiA0LjMgdGFsa3MgYWJv dXQgbWFuYWdlbWVudCBwbGFuZSBvcGVyYXRpb24gYW5kIGRvZXMgbm90IG1ha2UgaXQgY2xlYXIg d2hhdCB0aGUgaW1wbGljYXRpb25zIGZvciB0aGUgY29udHJvbCBwbGFuZSBhcmUuJm5ic3A7IEkN CiByZWNvbW1lbmQgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmV2aWV3ZWQgd2l0aGluIFNGQyBhbmQg YW55dGhpbmcgdGhhdCBkb2VzIG5vdCB0YWxrIGFib3V0IGEgY2xlYXIgY29udHJvbCBwbGFuZSBp bXBsaWNhdGlvbiBpcyB0YWtlbiBvdXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkb2N1 bWVudCBmcmVxdWVudGx5IGRpZ3Jlc3NlcyBpbnRvIGdpdmluZyBsaXN0cyBvZiBleGFtcGxlcy4m bmJzcDsgRm9yIGV4YW1wbGUsIHNlY3Rpb24gMy4zLjEsIDMuMy4zLCA0LjQsIDQuNywgNC44LiZu YnNwOyBUaGlzIGlzIG5vdCBhIGhlbHBmdWwgd2F5IHRvIGNhcHR1cmUgcmVxdWlyZW1lbnRzLiZu YnNwOyBJbnN0ZWFkIG9mIGdpdmluZyBvcGVuIGVuZGVkIGxpc3RzLCB0aGUgZG9jdW1lbnQgc2hv dWxkIGRpc3RpbCBhIHNldA0KIG9mIHJlcXVpcmVtZW50cyBvdXQgb2YgdGhlIGtub3duIGV4YW1w bGVzLCBhbmQgc3RhdGUgdGhlIHJlcXVpcmVtZW50cyBpbnN0ZWFkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Tb21lIG9mIHRoZSBwYXNzYWdlcyBpbiB0aGUgZG9jdW1lbnQgZmVsdCBzdXBlcmZs dW91cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+QSk8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U2VjdGlvbiAzLjIuJm5ic3A7IEkgdGhpbmsg dGhpcyBzZWN0aW9uIGFkZHMgbm90aGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+Qik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIGxp c3Qgb2Yg4oCcZnVuY3Rpb25hbCBvYmplY3RpdmVz4oCdIGluIDMuMy4xLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj5DKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5TZWN0aW9uIDQuMywgd2hlcmUsIGFzIHN0YXRlZCBhYm92ZSwgSSBkb27igJl0 IHNlZSB0aGUgcmVsZXZhbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5EKTxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TZWN0aW9uIDQuNS4m bmJzcDsgVGhpcyBqdXN0IHNlZW1zIHRvIGJlIHNheWluZyB0aGF0IHRoZSBjb250cm9sIHBsYW5l IG5lZWRzIHRvIGJlIGFibGUgdG8gbW9kaWZ5IFNGQ3MuJm5ic3A7IEkgZG9u4oCZdCBmaW5kIHRo YXQgc3VycHJpc2luZy4mbmJzcDsgSeKAmWQgYmUgaGFwcGllciBpZiB0aGlzIHdhcyByZXdyaXR0 ZW4gdG8gdGFsayBhYm91dCB3aGF0IHRoZSBjb250cm9sIHBsYW5lIG11c3QgZG8uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBkb2N1bWVudCBpcyBsYXJnZWx5IHdyaXR0ZW4gaW4gdGhlIHBh c3NpdmUgdm9pY2UsIHdoaWNoIG1ha2VzIHVuZGVyc3RhbmRpbmcgaXQgcXVpdGUgaGFyZC4mbmJz cDsgVG8gdGFrZSBhbiBleGFtcGxlLCBpbiBzZWN0aW9uIDQuNy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T0xEIChwYXNzaXZlIHZvaWNlKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOyZuYnNwOyBM aXZlbmVzcyBzdGF0dXMgcmVjb3JkcyBmb3IgYWxsIFNGIGluc3RhbmNlcywgYW5kIHNlcnZpY2Ug ZnVuY3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7Jm5ic3A7IGNoYWlucyAoaW5j bHVkaW5nIHRoZSBTRlBzIGJvdW5kIHRvIGEgZ2l2ZW4gY2hhaW4pIGFyZSBtYWludGFpbmVkIGJ5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOyZuYnNwOyB0aGUgU0ZDIENvbnRyb2wuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TkVXIChhY3RpdmUgdm9p Y2UpPG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGUgU0ZDIGNvbnRyb2wgcGxh bmUgbXVzdCBtb25pdG9yIHRoZSBsaXZlbmVzcyBvZiBhbGwgU0YgaW5zdGFuY2VzLCBhbmQgYWxs IHNlcnZpY2UgZnVuY3Rpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2hh aW5zIChpbmNsdWRpbmcgdGhlIFNGUHMgYm91bmQgdG8gYSBnaXZlbiBjaGFpbikuPG86cD48L286 cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSByZWNvbW1lbmQgdGhhdCBhbiBFbmdsaXNoIHNwZWFrZXIgb3Zl cmhhdWxzIHRoZSB0ZXh0IGFuZCByZXBsYWNlcyB0aGUgcGFzc2l2ZSB2b2ljZSB3aXRoIHRoZSBh Y3RpdmUgdm9pY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PkRvY3VtZW50IFN0cnVjdHVy ZTxvOnA+PC9vOnA+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB1bmRl cnN0YW5kIHdoeSB0aGUgZG9jdW1lbnQgc2VwYXJhdGVzIGNoYXB0ZXIgMiDigJxHZW5lcmljIENv bnNpZGVyYXRpb25z4oCdIGFuZCBjaGFwdGVyIDQg4oCcQWRkaXRpb25hbCBjb25zaWRlcmF0aW9u c+KAnS4mbmJzcDsgVGhleSBhbGwganVzdCBsb29rIGxpa2UgcmVxdWlyZW1lbnRzIHRvIG1lLiZu YnNwOyBJIHdvdWxkIHB1dCBjaGFwdGVyIDMgZmlyc3QsIHRoZW4gbWVyZ2UgY2hhcHRlcnMgMiBh bmQgNCwgYW5kIHRyeQ0KIHRvIGRpc3RpbCB0aGUgcmVzdWx0aW5nIHRleHQgYXMgbXVjaCBhcyBw b3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+RGV0YWlsZWQgY29tbWVudHM8bzpw PjwvbzpwPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMi4yLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxpc3Qgb2YgaW5mb3JtYXRpb24gcHJvdmlkZWQgcHJpb3Ig dG8gYm9vdHN0cmFwcGluZyBpbmNsdWRlcyDigJxTRnMgc2VydmljZWQgYnkgZWFjaCBTRkbigJ0g YnV0IHRoZSBpbmZvcm1hdGlvbiBjb2xsZWN0ZWQgZHVyaW5nIGJvb3RzdHJhcHBpbmcgaW5jbHVk ZXMg4oCcVGhlIGxpc3Qgb2YgU0ZGcyBhbmQgdGhlIFNGcyB0aGF0IGFyZSBhdHRhY2hlZCB0b+KA nS4mbmJzcDsgQXJlbuKAmXQgdGhleSB0aGUgc2FtZSB0aGluZz88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U2VjdGlvbiAzLjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnMv IFNlY3Rpb24gMy4zLjIgc3BlY2lmaWVzIHN1Y2ggaW50ZXJmYWNlLi8gU2VjdGlvbiAzLjMuMiBz cGVjaWZpZXMgdGhpcyBpbnRlcmZhY2UuLzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGZpbmFsIHBhcmFncmFwaCBmZWVscyBvdXQgb2YgcGxhY2UgaW4gdGhpcyBzZWN0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDMuMjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+cy9kdXJpbmcgbmV0d29yayBhdHRhY2htZW50IHBoYXNlL2R1 cmluZyB0aGUgbmV0d29yayBhdHRhY2htZW50IHBoYXNlLzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+cy9Cb3RoIGNlbnRyYWxpemVkIGFuZCBkaXN0cmlidXRlZCBtZWNoYW5p c20vQm90aCBjZW50cmFsaXplZCBhbmQgZGlzdHJpYnV0ZWQgbWVjaGFuaXNtcy88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAzLjMuMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+4oCcVGhlIFNGQyBjb250cm9sIHBsYW5lIHNob3VsZCBiZSByZXNwb25zaWJsZeKA nSAmbmJzcDtXaGF0IGRvIHlvdSBtZWFuIOKAnHNob3VsZCBiZeKAnT8mbmJzcDsgUmVzcG9uc2li aWxpdHkgc2hvdWxkIGJlIGNsZWFybHkgYXNzaWduZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj7igJzigKZiZSBwYXJ0IG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGRpc2Nv dmVyeSBwcm9jZWR1cmXigJ0gV2hhdCBpcyB0aGF0PyZuYnNwOyBGaXJzdCBtZW50aW9uIG9mIGl0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcbWVhbnMgdG8gcmVkdWNl IGNsYXNzaWZpY2F0aW9uIGxvb2t1cCB0aW1lIOKApiBzaG91bGQgYmUgc3VwcG9ydGVkIGJ5IHRo ZSBTRkMgY29udHJvbCBwbGFuZeKAnSDigJMgV2h5PyZuYnNwOyBJc27igJl0IHRoYXQgYSBqb2Ig Zm9yIHRoZSBjbGFzc2lmaWVyIHRvIGxvY2FsbHkgb3B0aW1pemU/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5zL3RoYW5rcyB0byB0aGUgaW52b2NhdGlvbiBvZi9ieSBpbnZv a2luZy88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnMvZG9lcyBub3QgY29u dmV5IHRoYXQgc2VtYW50aWNzLyBkb2VzIG5vdCBjb252ZXkgdGhvc2Ugc2VtYW50aWNzLzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cy90cnVzdCBhbiBleGlzdGluZyBTRkMg aW5mb3JtYXRpb24vIHRydXN0IGV4aXN0aW5nIFNGQyBpbmZvcm1hdGlvbiAvPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zL2NvbmZpZ3VyYWJsZSBwYXJhbWV0ZXIvY29uZmln dXJhYmxlIHBhcmFtZXRlcnMvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMy4zLjI8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnMvU3VjaCB0YWJsZS9UaGlzIHRh YmxlLzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cy9TdWNoIGluc3RydWN0 IHR5cGljYWxseS9UaGlzIHR5cGljYWxseS88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPuKAnGdyb3VwcyBvZiBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCBTRnMg4oCmIG1heSBi ZSB1c2VkIGZvciBsb2FkLWJhbGFuY2luZyBwdXJwb3Nlc+KAnSZuYnNwOyBXaGF0IGlzIHRoZSBy ZWxldmFuY2UgdG8gdGhlIGNvbnRyb2wgcGxhbmUgdGhhdCB0aGV5IG1heSBiZSB1c2VkIGZvciBs b2FkIGJhbGFuY2luZz8mbmJzcDsgV2hlbiB5b3Ugc2F5IOKAnG1heSBiZSB1c2Vk4oCdIGRvIHlv dSBtZWFuIGluIGFsbCBjaXJjdW1zdGFuY2VzLCBvciBkbw0KIHlvdSBtZWFuIG9ubHkgaW4gc29t ZSBjaXJjdW1zdGFuY2VzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCc QnkgZGVmYXVsdCwgYW4gU0ZGIHJlbGllcyBvbiBsZWdhY3kgcHJvY2Vzc2luZyBmb3IgZm9yd2Fy ZGluZyB0aGVzZSBwYWNrZXRzLuKAnSZuYnNwOyBEb2VzIOKAnGxlZ2FjeSBwcm9jZXNzaW5n4oCd IG1lYW4gZm9yd2FyZGluZyB1c2luZyBleGlzdGluZyBuZXR3b3JrIGhlYWRlcnM/Jm5ic3A7IEkg d291bGQgbm90IGNhbGwgdGhhdCDigJxsZWdhY3nigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNlY3Rpb24gMy4zLjM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFNG cyBtYXkgbmVlZCB0byBvdXRwdXQgc29tZSBwcm9jZXNzaW5nIHJlc3VsdHMgb2YgcGFja2V0c+KA nSBpcyB0b28gd29vbGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCc VGhlIFNGQyBjb250cm9sIG5lZWRzIHRoZSBhYm92ZSBzdGF0dXMgaW5mb3JtYXRpb24gZm9yIHZh cmlvdXMgdGFza3PigJ0gaXMgYWxzbyB0b28gd29vbGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gdGhpcyBzZWN0aW9uIHdoZXJlIHlvdSBzYXkgKG11bHRpcGxlIHRp bWVzKSDigJxhIGNvbnRleHQgaW5mb3JtYXRpb27igJ0gZG8geW91IG1lYW4g4oCcdGhlIGNvbnRl eHQgaGVhZGVycyBpbiB0aGUgTlNI4oCdPyZuYnNwOyBUaGUgbGF0dGVyIHdvdWxkIGJlIGNsZWFy ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxOb3RlIHRoYXQgYSBj b250ZXh0IG1heSBiZSBtYW5kYXRvcnkgZm9yICZxdW90O2NoYWluIDEmcXVvdDssIGJ1dCBvcHRp b25hbCBmb3IgJnF1b3Q7Y2hhaW4gMiZxdW90Oy7igJ0mbmJzcDsgU3VyZSwgYnV0IHdoYXQgYXJl IHRoZSBpbXBsaWNhdGlvbnMgb2YgdGhpcyBmb3IgdGhlIGNvbnRyb2wgcGxhbmU/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxNdWx0aXBsZSBTRnMgbWF5IGJlIGxvY2F0 ZWQgd2l0aGluIHRoZSBzYW1lIHBoeXNpY2FsIG5vZGUsIGJ1dCBubyBTRkYgaXMgZW5hYmxlZCBp biB0aGF0IHNhbWUgbm9kZSwgbWVhbnMgdG8gdW5hbWJpZ3VvdXNseSBmb3J3YXJkIHRoZSB0cmFm ZmljIGZyb20gdGhlIFNGRiB0byB0aGUgYXBwcm9wcmlhdGUgU0YgbXVzdCBiZSBzdXBwb3J0ZWQu 4oCdIOKAkyBJIGNhbuKAmXQgcGFyc2UgdGhpcyBzZW50ZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPuKAnENvbmNyZXRlbHksIGVhY2ggU0YgbXVzdCBoYXZlIGEgdW5p cXVlIGxvY2F0b3IgZm9yIHVuYW1iaWd1b3VzIGZvcndhcmRpbmcuJm5ic3A7IFRoaXMgbG9jYXRv ciBtYXkgYmUgY29uZmlndXJlZCB1c2luZyB0aGlzIGludGVyZmFjZS7igJ0mbmJzcDsgVGhpcyBz b3VuZHMgbGlrZSBhIGRlc2NyaXB0aW9uIG9mIG1hbmFnZW1lbnQgcGxhbmUgZnVuY3Rpb24sIG5v dCBjb250cm9sIHBsYW5lIGZ1bmN0aW9uLiZuYnNwOyBXaGF0IGltcGxpY2F0aW9ucw0KIGRvZXMg dGhlIGxvY2F0b3IgaGF2ZSBmb3IgdGhlIGNvbnRyb2wgcGxhbmU/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxTcGVjaWFsIGNhcmUgc2hvdWxkIGJlIGNvbnNpZGVyZWQg dG8gYXZvaWQgdGhhdCBpbnN0cnVjdGlvbnMgcHJvdmlkZWQgdG8gZGlzdGluY3QgU0ZzIGxlYWQg dG8gbG9vcHMu4oCdJm5ic3A7IFJld3JpdGUgdG8gc2F5IHdoYXQgdGhlIGNvbnRyb2wgcGxhbmUg bXVzdCBkbyB0byBhdm9pZCBvciBtaXRpZ2F0ZSBsb29wcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2VjdGlvbiA0LjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnMvdmFy aWV0eSBpZiBtZWNoYW5pc21zL3ZhcmlldHkgb2YgbWVjaGFuaXNtcy88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2VjdGlvbiA0LjI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnMvYm90aCBkaXJlY3Rpb24gb2YvYm90aCBkaXJlY3Rpb25zIG9mLzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkb2VzIOKAnGZ1bGwgY2hhaW4gc3ltbWV0cnnigJ0g bWVhbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiA0LjQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnMvIGFjY29tbW9kYXRlIHN1Y2ggY29udGV4dC8gYWNjb21t b2RhdGUgdGhpcy88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2Vj dGlvbiBnaXZlcyBhIGNvdXBsZSBvZiBleGFtcGxlcy4mbmJzcDsgQXJlIHlvdSBnaXZpbmcgYSBz dWJzZXQgb2YgYWxsIHBvc3NpYmxlIG9wdGlvbnM/Jm5ic3A7IEFyZSB5b3Ugc2F5aW5nIHRoZSBj b250cm9sIHBsYW5lIGNhbiBkbyBlaXRoZXIsIG9yIGJvdGgsIG9yIHNvbWV0aW1lcyBvbmUgYW5k IHNvbWV0aW1lcyB0aGUgb3RoZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gNC42 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxTcGVjaWZpYyBjcml0ZXJp YSB0byBzZW5kIHVuc29saWNpdGVkIG5vdGlmaWNhdGlvbnMgdG8gYSBDb250cm9sIEVsZW1lbnQg c2hvdWxkIGJlIGZpbmUgdHVuZWQgYnkgdGhlIGNvbnRyb2wgcGxhbmXigJ0mbmJzcDsgV2hhdCBk byB5b3UgbWVhbiBieSDigJxmaW5lIHR1bmVk4oCdPyZuYnNwOyBXaGF0IGRvZXMgdGhlIGNvbnRy b2wgcGxhbmUgYWN0dWFsbHkgbmVlZCB0byBkbz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Vj dGlvbiA0Ljc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnMvbGl2ZWxpbmVz cy9saXZlbmVzcy88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFRoZSBj bGFzc2lmaWVyIG1heSBiZSBub3RpZmllZCBieSB0aGUgY29udHJvbCBwbGFuZeKAnSDigJMgTm90 aWZpZWQgb2Ygd2hhdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFRo ZSBhYmlsaXR5IG9mIGFuIFNGQyBDb250cm9sIEVsZW1lbnQgdG8gY2hlY2sgdGhlIGxpdmVuZXNz IG9mIGVhY2ggU0YgcHJlc2VudCBpbiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGhhcyBzZXZlcmFs IGFkdmFudGFnZXPigKbigJ0g4oCTIEFkdmFudGFnZXMgb3ZlciB3aGF0PyZuYnNwOyBEbyB5b3Ug anVzdCBtZWFuIGl0IGhhcyBzZXZlcmFsIOKAnGZlYXR1cmVz4oCdPyZuYnNwOyBXaGF0IGlzIHRo ZSBwdXJwb3NlIG9mIGxpc3RpbmcgdGhvc2UNCiBmZWF0dXJlcz8mbmJzcDsgV2hhdCBhcmUgdGhl IGltcGxpY2F0aW9ucyBmb3IgdGhlIGNvbnRyb2wgcGxhbmU/Jm5ic3A7IEFyZSB5b3UgZ2l2aW5n IGEgbGlzdCBvZiB0aGluZ3MgdGhlIGNvbnRyb2wgcGxhbmUgbXVzdCBkbz88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnENvbnRyb2wgRWxlbWVudHMgbWF5IGJlIGZlZCBk aXJlY3RseSBvciBpbmRpcmVjdGx5IHdpdGggaW5wdXRzIGZyb20gdGhlc2UgbWVjaGFuaXNtcy7i gJ0g4oCTIFdoYXQgZG8geW91IG1lYW4gYnkgZGlyZWN0bHkgdmVyc3VzIGluZGlyZWN0bHk/Jm5i c3A7IElzIHRoaXMgcGFydCBvZiBvbmUgb2YgdGhlIEN4IGludGVyZmFjZXM/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNlY3Rpb24gNC44PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj7igJxFdmVuIGlmIHNldHRpbmcgdGhlIGRhdGEgY29sbGVjdGlvbiBjeWNsZSBpcyBkZXBs b3ltZW50LXNwZWNpZmljLCBpdCBpcyByZWNvbW1lbmRlZCB0byBzdXBwb3J0IGR5bmFtaWMgbWVh bnPigKbigJ0mbmJzcDsgV2hhdCBkbyB5b3UgbWVhbiBieSDigJxkeW5hbWljIG1lYW5z4oCdPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDQuOTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+4oCcQm90aCBzaG9ydCBhbmQgbG9uZyBsaWZldGltZXMgbWF5IGJlIGFz c2lnbmVkLuKAnSDigJMgSXMgbm90IHJlYWxseSBhIHVzZWZ1bCBzdGF0ZW1lbnQuJm5ic3A7IFdo YXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMgZm9yIHRoZSBjb250cm9sIHBsYW5lPyZuYnNwOyBBIHVz ZWZ1bCBzdGF0ZW1lbnQgd291bGQgaW5jbHVkZSB3aGF0IHVuaXRzIHRoZXNlIGxpZmV0aW1lcyBz aG91bGQgYmUgY29udmV5ZWQgaW4sIGFuZCB0aGVpciB2YWxpZCByYW5nZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2VjdGlvbiA0LjEwLjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnMvY2hhbmdlcyBzaG91bGQgbW9uaXRvcmVkL2NoYW5nZXMgc2hvdWxkIGJlIG1vbml0 b3JlZC88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnMvb3ZlcmxhZGVkL292 ZXJsb2FkZWQvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgcHJv Y2VkdXJlcyBmb3IgU0ZQIGFkanVzdG1lbnQsIHBsZWFzZSBnaXZlIG1vcmUgZGV0YWlsIG9uIHRo ZSBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyBmb3Ig4oCcUmVwbGFjZSB0YXJnZXQgU0YgaW5z dGFuY2VzIChlLmcuLCBpbiBhIGZhaWx1cmUgb3Igb3ZlcmxhZGVkKSB3aXRoIG5ld2x5IHNlbGVj dGVkIG9uZXMu4oCdJm5ic3A7IEhvdyBpcyB0aGlzIHRvIGJlIGRvbmU/Jm5ic3A7IEkgYXNzdW1l IG1ha2UgYmVmb3JlDQogYnJlYWsgaXMgcmVxdWlyZWQuJm5ic3A7IEFyZSB0aGVyZSBhbnkgb3Ro ZXIgY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNl Y3Rpb24gNC4xMC4zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ug ZXhwbGFpbiB3aGF0IHlvdSBtZWFuIGJ5IOKAnHJlZ2lvbmFsIHJlc3RvcmF0aW9u4oCdLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXNu4oCZdCBjbGVhciB0byBtZSB3 aGF0IHRoZSBmaXJzdCAzIHBhcmFncmFwaHMgaW4gdGhpcyBzZWN0aW9uIGhhdmUgdG8gZG8gd2l0 aCB0aGUgZmluYWwgdHdvLCBidXQgcGVyaGFwcyBpZiBJIHVuZGVyc3Rvb2Qgd2hhdCDigJxyZWdp b25hbCByZXN0b3JhdGlvbuKAnSBtZWFudCBpdCB3b3VsZCBiZSBjbGVhcmVyLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_BY2PR0201MB1910AC92526AF0E351F7F6A884290BY2PR0201MB1910_-- From nobody Wed Mar 1 23:16:17 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0821294A0; Wed, 1 Mar 2017 23:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRwFuqIw_jFz; Wed, 1 Mar 2017 23:16:09 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E2C12943C; Wed, 1 Mar 2017 23:16:09 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 6789710061F; Thu, 2 Mar 2017 08:16:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4311E180067; Thu, 2 Mar 2017 08:16:07 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Thu, 2 Mar 2017 08:16:06 +0100 From: To: Jonathan Hardwick , Alia Atlas , "draft-ietf-sfc-control-plane@ietf.org" Thread-Topic: Routing directorate review of draft-ietf-sfc-control-plane-08 Thread-Index: AdKSn4ZLvk7rfcNvTmOExgofvam6/AAgVL7w Date: Thu, 2 Mar 2017 07:16:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E1B1DC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E1B1DCOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] Routing directorate review of draft-ietf-sfc-control-plane-08 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 07:16:11 -0000 --_000_787AE7BB302AE849A7480A190F8B933009E1B1DCOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uYXRoYW4sDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4NCg0KVGhlIFdHIGlzIGN1 cnJlbnRseSBkaXNjdXNzaW5nIGhvdyB0byBwcm9ncmVzcyB0aGlzIHdvcms6IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDU0MzcuaHRtbC4gSeKA mW0gbm90IHN1cmUgaWYgdGhlIGRvY3VtZW50IHdpbGwgYmUgbWFpbnRhaW5lZC4NCg0KSeKAmWQg bGlrZSB0byBub3RlIHRoYXQgdGhlIGRvY3VtZW50IHNjb3BlIHJlZmxlY3RzIHdoYXQgdGhlIFdH IHdhbnRlZCB0byBzZWUgaW4gdGhpcyBkb2N1bWVudC4gSW4gcGFydGljdWxhciwgdGhlIGRvY3Vt ZW50IGlzIG5vdCBtaXNzaW9uZWQgdG8gZGVmaW5lIGEgcHJvdG9jb2wsIGEgcHJvdG9jb2wgZXh0 ZW5zaW9uLCBvciB0b3VjaCBvbiB0aGUgaW50ZXJuYWwgc3RydWN0dXJlIG9mIGNvbnRyb2wgZWxl bWVudHMgKGNmLCB0aGUgY2hhcnRlciBleGNlcnB0IGJlbG93KS4NCg0KPT09PT09PT09PT09PT0N CkFsbCBwcm90b2NvbCBleHRlbnNpb24gd29yaw0KcmVzdWx0aW5nIGZyb20gdGhlc2UgcmVxdWly ZW1lbnRzIHNob3VsZCBiZSBjYXJyaWVkIG91dCBpbiB0aGUNCndvcmtpbmcgZ3JvdXAgcmVzcG9u c2libGUgZm9yIHRoZSBwcm90b2NvbCBiZWluZyBtb2RpZmllZCBpbg0KY29vcmRpbmF0aW9uIHdp dGggdGhpcyB3b3JraW5nIGdyb3VwLCBidXQgbWF5IGJlIGRvbmUgaW4gdGhpcyB3b3JraW5nDQpn cm91cCB1bmRlciBhIHJldmlzZWQgY2hhcnRlciBhZnRlciBhZ3JlZW1lbnQgd2l0aCBhbGwgdGhl IHJlbGV2YW50DQpXRyBjaGFpcnMgYW5kIHJlc3BvbnNpYmxlIEFEcy4NCj09PT09PT09PQ0KDQpU aGUgZG9jdW1lbnQgZGVmaW5lcyBhIENQIGFyY2hpdGVjdHVyZSB0aGF0IGNhbiBiZSBpbXBsZW1l bnRlZCB3aXRoIGNlbnRyYWxpemVkIGFuZCBkaXN0cmlidXRlZCBDUCBwcm90b2NvbHMgd2l0aCBh IHBhcnRpY3VsYXIgZm9jdXMgb24gdGhlIOKAnHJlcXVpcmVtZW50cyBmb3IgY29udmV5aW5nIGlu Zm9ybWF0aW9uIGJldHdlZW4gY29udHJvbCBvciBtYW5hZ2VtZW50IGVsZW1lbnRzIGFuZCBTRkMg aW1wbGVtZW50YXRpb24gcG9pbnRz4oCdIChTRkMgY2hhcnRlcikuDQoNCkFzIHBlciB5b3VyIHF1 ZXN0aW9uIHJlbGF0ZWQgdG8gUENFLCBJIHJlaXRlcmF0ZSB0aGUgcG9zaXRpb24gb2YgdGhlIFNG QyBXRyBhcyBJIHVuZGVyc3Rvb2QgaXQgd2hlbiBhY3RpbmcgYXMgYW4gZWRpdG9yIG9mIHRoaXMg ZG9jdW1lbnQ6DQoNCsK3ICAgICAgICAgSXQgaXMgTk9UIHRoZSBnb2FsIG9mIHRoaXMgcmVxdWly ZW1lbnRzIGRvY3VtZW50IHRvIG1hbmRhdGUgdGhlIHVzZSBvZiBQQ0UsIEJHUCwgUkFESVVTLCBl dGMuDQoNCsK3ICAgICAgICAgQWxzbywgdGhpcyBkb2N1bWVudCBpcyBOT1QgZW50aXRsZWQgdG8g bWFuZGF0ZSB3aGV0aGVyIG9uZSBzaW5nbGUgcHJvdG9jb2wgb3IgbWFueSBwcm90b2NvbHMgd2ls bCBiZSB1c2VkLg0KDQpUaGFuayB5b3UgYWdhaW4gZm9yIHRoZSByZXZpZXcuIEl0IGlzIGFsd2F5 cyBpbnN0cnVjdGl2ZSB0byBoYXZlIGV4dGVybmFsIGV5ZXMgb24gYSBkb2N1bWVudC4NCg0KQ2hl ZXJzLA0KTWVkDQoNCkRlIDogSm9uYXRoYW4gSGFyZHdpY2sgW21haWx0bzpKb25hdGhhbi5IYXJk d2lja0BtZXRhc3dpdGNoLmNvbV0NCkVudm95w6kgOiBtZXJjcmVkaSAxIG1hcnMgMjAxNyAxNzo1 OQ0Kw4AgOiBBbGlhIEF0bGFzOyBkcmFmdC1pZXRmLXNmYy1jb250cm9sLXBsYW5lQGlldGYub3Jn DQpDYyA6IHNmY0BpZXRmLm9yZzsgcnRnLWRpckBpZXRmLm9yZw0KT2JqZXQgOiBSb3V0aW5nIGRp cmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1jb250cm9sLXBsYW5lLTA4DQoNCkhl bGxvDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSByb3V0aW5nIGRpcmVjdG9yYXRlIHJl dmlld2VyIGZvciB0aGlzIGRyYWZ0Lg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZS8NCg0KVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg c2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMg dGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29t ZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdCwgYXMgaW4gdGhpcyBjYXNlLiBUaGUgcHVycG9zZSBv ZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMu IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVh c2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9S dGdEaXINCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtc2ZjLWNvbnRyb2wtcGxhbmUtMDgudHh0DQpS ZXZpZXdlcjogSm9uYXRoYW4gSGFyZHdpY2sNClJldmlldyBEYXRlOiAxIE1hcmNoIDIwMTcNCklu dGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbA0KDQpTdW1tYXJ5DQpJIGhhdmUgc2lnbmlmaWNh bnQgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVjb21tZW5kIHRoYXQgdGhlIFJv dXRpbmcgQURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycy4N Cg0KQ29tbWVudHMNCg0KRG9jdW1lbnQgU2NvcGUNClRoaXMgZG9jdW1lbnQgYWltcyB0byBkZXNj cmliZSB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgdGhlIFNGQyBkYXRhIHBsYW5lIGhhcyBvbiB0aGUg Y29udHJvbCBwbGFuZS4NCg0KTXkgbWFqb3IgY29uY2VybiB3aXRoIHRoaXMgZG9jdW1lbnQgaXMg dGhhdCBpdHMgc2NvcGUgaXMgdG9vIG5hcnJvdy4gIFdpdGhvdXQgZ2l2aW5nIGEgY29udHJvbCBw bGFuZSBhcmNoaXRlY3R1cmUsIHRoaXMgZG9jdW1lbnTigJlzIHVzZWZ1bG5lc3MgaXMgcXVpdGUg bGltaXRlZC4NCg0KVGhlIGRvY3VtZW50IGlzIHByZXN1bWFibHkgdXNlZnVsIHRvIHBlb3BsZSB3 b3JraW5nIHdpdGhpbiB0aGUgU0ZDIFdHIGFzIGEgY2hlY2tsaXN0IG9mIHRoZWlyIHJlcXVpcmVt ZW50cy4gIEkgYXNzdW1lIChhbmQgaG9wZSkgdGhhdCBTRkMgd2lsbCBpbiBmdXR1cmUgcHVibGlz aCBhIGNvbnRyb2wgcGxhbmUgYXJjaGl0ZWN0dXJlIHRoYXQgd2lsbCBzYXRpc2Z5IHRoZXNlIHJl cXVpcmVtZW50cy4NCg0KU3BlYWtpbmcgd2l0aCBteSBpbXBsZW1lbnRlciBoYXQgb24sIHRoaXMg ZG9jdW1lbnQgaXMgbm90IHVzZWZ1bCB0byBtZSBhcyBpdCBkb2VzIG5vdCBkZXNjcmliZSBhbnl0 aGluZyB0aGF0IEkgY2FuIGltcGxlbWVudC4gIEl0IGRvZXMgbm90IGRlc2NyaWJlIHdoYXQgdGhl IGNvbnRyb2wgcGxhbmUgbG9va3MgbGlrZSwgd2hhdCBidWlsZGluZyBibG9ja3MgdG8gdXNlLCBl dGMuDQoNClNwZWFraW5nIHdpdGggbXkgSUVURiBXRyBjaGFpciBoYXQgb24sIHRoaXMgZG9jdW1l bnQgaXMgbm90IHVzZWZ1bCB0byBtZSBhcyBpdCBnaXZlcyBubyBzdGVlciBhcyB0byB3aGF0IHBy b3RvY29scyB3aWxsIGJlIGVtcGxveWVkLCBvciBob3cuICBUaGlzIGlzIGNhdXNpbmcgZGlmZmlj dWx0aWVzIGZvciBvdGhlciB3b3JraW5nIGdyb3Vwcy4gIEZvciBleGFtcGxlLCBzb21lb25lIHJl Y2VudGx5IGNhbWUgdG8gdGhlIFBDRSBXRyB3aXRoIGEgZHJhZnQgZGVzY3JpYmluZyBhbiBTRkMg Y29udHJvbCBwbGFuZSBpbXBsZW1lbnRlZCB3aXRoIFBDRVAuICBJIGhhdmUgbm8gaWRlYSBpZiB0 aGUgU0ZDIFdHIHdhbnRzIHRvIHVzZSBQQ0VQIGluIGl0cyBjb250cm9sIHBsYW5lLCBzbyBJIGFt IHVuYWJsZSB0byBhZG9wdCBzYWlkIGRyYWZ0LiAgTWVhbndoaWxlLCB0aGVyZSBpcyBhIGRyYWZ0 IGluIEJFU1MgdGhhdCBkb2N1bWVudHMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBTRkMgY29udHJv bCBwbGFuZSwgYW5kIHRoZXJlIG1heSBiZSBvdGhlcnMuICBXZSBhcmUgaW4gYSBjb25mdXNpbmcg c2l0dWF0aW9uIGFuZCB0aGUgcHJvcG9zYWxzIGFyZSBwcm9saWZlcmF0aW5nLiAgVGhlIFNGQyB3 b3JraW5nIGdyb3VwIG5lZWRzIHRvIHN0ZWVyIHRoZSBwcm90b2NvbCBkZXZlbG9wbWVudCB3b3Jr LCBidXQgdGhpcyBkb2N1bWVudCBpcyBjb21wbGV0ZWx5IHNpbGVudCBvbiBpdC4NCg0KQXMgc3Vj aCwgSSBhbSBub3Qgc3VyZSB0aGF0IGl0IGlzIHdvcnRoIHRoZSBJRVRGIHB1Ymxpc2hpbmcgdGhp cyBkb2N1bWVudCBhcyBpdCBzdGFuZHMuICBIb3dldmVyLCBJIGRvIHZlcnkgbXVjaCBlbmNvdXJh Z2UgdGhlIFNGQyB3b3JraW5nIGdyb3VwIHRvIGNvbnRpbnVlIHRoZWlyIHdvcmsgb24gdGhlIGNv bnRyb2wgcGxhbmUgYW5kIHRvIGRldmVsb3AgYW4gYXJjaGl0ZWN0dXJlIHdoaWNoIGRlc2NyaWJl cyBpdC4NCg0KSWYgd2UgZG8gZ28gYWhlYWQgYW5kIHB1Ymxpc2ggdGhpcywgdGhlbiBJIGJlbGll dmUgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIGJlIHJlc3RydWN0dXJlZCBhbmQgbWFkZSBtdWNo IGJyaWVmZXIuDQoNCkRvY3VtZW50IENvbnRlbnQNClRoZSBkb2N1bWVudCBzdHJheXMgaW50byBk aXNjdXNzaW9ucyBvZiBtYW5hZ2VtZW50IHBsYW5lIG9wZXJhdGlvbiBhbmQgcmVxdWlyZW1lbnRz LiAgRm9yIGV4YW1wbGUsIGFsbCBvZiBzZWN0aW9uIDQuMyB0YWxrcyBhYm91dCBtYW5hZ2VtZW50 IHBsYW5lIG9wZXJhdGlvbiBhbmQgZG9lcyBub3QgbWFrZSBpdCBjbGVhciB3aGF0IHRoZSBpbXBs aWNhdGlvbnMgZm9yIHRoZSBjb250cm9sIHBsYW5lIGFyZS4gIEkgcmVjb21tZW5kIHRoYXQgdGhl IGRvY3VtZW50IGlzIHJldmlld2VkIHdpdGhpbiBTRkMgYW5kIGFueXRoaW5nIHRoYXQgZG9lcyBu b3QgdGFsayBhYm91dCBhIGNsZWFyIGNvbnRyb2wgcGxhbmUgaW1wbGljYXRpb24gaXMgdGFrZW4g b3V0Lg0KDQpUaGUgZG9jdW1lbnQgZnJlcXVlbnRseSBkaWdyZXNzZXMgaW50byBnaXZpbmcgbGlz dHMgb2YgZXhhbXBsZXMuICBGb3IgZXhhbXBsZSwgc2VjdGlvbiAzLjMuMSwgMy4zLjMsIDQuNCwg NC43LCA0LjguICBUaGlzIGlzIG5vdCBhIGhlbHBmdWwgd2F5IHRvIGNhcHR1cmUgcmVxdWlyZW1l bnRzLiAgSW5zdGVhZCBvZiBnaXZpbmcgb3BlbiBlbmRlZCBsaXN0cywgdGhlIGRvY3VtZW50IHNo b3VsZCBkaXN0aWwgYSBzZXQgb2YgcmVxdWlyZW1lbnRzIG91dCBvZiB0aGUga25vd24gZXhhbXBs ZXMsIGFuZCBzdGF0ZSB0aGUgcmVxdWlyZW1lbnRzIGluc3RlYWQuDQoNClNvbWUgb2YgdGhlIHBh c3NhZ2VzIGluIHRoZSBkb2N1bWVudCBmZWx0IHN1cGVyZmx1b3VzLg0KDQpBKSAgICAgU2VjdGlv biAzLjIuICBJIHRoaW5rIHRoaXMgc2VjdGlvbiBhZGRzIG5vdGhpbmcuDQoNCkIpICAgICBUaGUg bGlzdCBvZiDigJxmdW5jdGlvbmFsIG9iamVjdGl2ZXPigJ0gaW4gMy4zLjEuDQoNCkMpICAgICBT ZWN0aW9uIDQuMywgd2hlcmUsIGFzIHN0YXRlZCBhYm92ZSwgSSBkb27igJl0IHNlZSB0aGUgcmVs ZXZhbmNlLg0KDQpEKSAgICAgU2VjdGlvbiA0LjUuICBUaGlzIGp1c3Qgc2VlbXMgdG8gYmUgc2F5 aW5nIHRoYXQgdGhlIGNvbnRyb2wgcGxhbmUgbmVlZHMgdG8gYmUgYWJsZSB0byBtb2RpZnkgU0ZD cy4gIEkgZG9u4oCZdCBmaW5kIHRoYXQgc3VycHJpc2luZy4gIEnigJlkIGJlIGhhcHBpZXIgaWYg dGhpcyB3YXMgcmV3cml0dGVuIHRvIHRhbGsgYWJvdXQgd2hhdCB0aGUgY29udHJvbCBwbGFuZSBt dXN0IGRvLg0KDQpUaGUgZG9jdW1lbnQgaXMgbGFyZ2VseSB3cml0dGVuIGluIHRoZSBwYXNzaXZl IHZvaWNlLCB3aGljaCBtYWtlcyB1bmRlcnN0YW5kaW5nIGl0IHF1aXRlIGhhcmQuICBUbyB0YWtl IGFuIGV4YW1wbGUsIGluIHNlY3Rpb24gNC43Lg0KDQpPTEQgKHBhc3NpdmUgdm9pY2UpDQogICBM aXZlbmVzcyBzdGF0dXMgcmVjb3JkcyBmb3IgYWxsIFNGIGluc3RhbmNlcywgYW5kIHNlcnZpY2Ug ZnVuY3Rpb24NCiAgIGNoYWlucyAoaW5jbHVkaW5nIHRoZSBTRlBzIGJvdW5kIHRvIGEgZ2l2ZW4g Y2hhaW4pIGFyZSBtYWludGFpbmVkIGJ5DQogICB0aGUgU0ZDIENvbnRyb2wuDQpORVcgKGFjdGl2 ZSB2b2ljZSkNCg0KICAgVGhlIFNGQyBjb250cm9sIHBsYW5lIG11c3QgbW9uaXRvciB0aGUgbGl2 ZW5lc3Mgb2YgYWxsIFNGIGluc3RhbmNlcywgYW5kIGFsbCBzZXJ2aWNlIGZ1bmN0aW9uDQoNCiAg IGNoYWlucyAoaW5jbHVkaW5nIHRoZSBTRlBzIGJvdW5kIHRvIGEgZ2l2ZW4gY2hhaW4pLg0KDQpJ IHJlY29tbWVuZCB0aGF0IGFuIEVuZ2xpc2ggc3BlYWtlciBvdmVyaGF1bHMgdGhlIHRleHQgYW5k IHJlcGxhY2VzIHRoZSBwYXNzaXZlIHZvaWNlIHdpdGggdGhlIGFjdGl2ZSB2b2ljZS4NCg0KRG9j dW1lbnQgU3RydWN0dXJlDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgdGhlIGRvY3VtZW50IHNl cGFyYXRlcyBjaGFwdGVyIDIg4oCcR2VuZXJpYyBDb25zaWRlcmF0aW9uc+KAnSBhbmQgY2hhcHRl ciA0IOKAnEFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnPigJ0uICBUaGV5IGFsbCBqdXN0IGxvb2sg bGlrZSByZXF1aXJlbWVudHMgdG8gbWUuICBJIHdvdWxkIHB1dCBjaGFwdGVyIDMgZmlyc3QsIHRo ZW4gbWVyZ2UgY2hhcHRlcnMgMiBhbmQgNCwgYW5kIHRyeSB0byBkaXN0aWwgdGhlIHJlc3VsdGlu ZyB0ZXh0IGFzIG11Y2ggYXMgcG9zc2libGUuDQoNCkRldGFpbGVkIGNvbW1lbnRzDQoNClNlY3Rp b24gMi4yLg0KVGhlIGxpc3Qgb2YgaW5mb3JtYXRpb24gcHJvdmlkZWQgcHJpb3IgdG8gYm9vdHN0 cmFwcGluZyBpbmNsdWRlcyDigJxTRnMgc2VydmljZWQgYnkgZWFjaCBTRkbigJ0gYnV0IHRoZSBp bmZvcm1hdGlvbiBjb2xsZWN0ZWQgZHVyaW5nIGJvb3RzdHJhcHBpbmcgaW5jbHVkZXMg4oCcVGhl IGxpc3Qgb2YgU0ZGcyBhbmQgdGhlIFNGcyB0aGF0IGFyZSBhdHRhY2hlZCB0b+KAnS4gIEFyZW7i gJl0IHRoZXkgdGhlIHNhbWUgdGhpbmc/DQoNClNlY3Rpb24gMy4xDQpzLyBTZWN0aW9uIDMuMy4y IHNwZWNpZmllcyBzdWNoIGludGVyZmFjZS4vIFNlY3Rpb24gMy4zLjIgc3BlY2lmaWVzIHRoaXMg aW50ZXJmYWNlLi8NClRoZSBmaW5hbCBwYXJhZ3JhcGggZmVlbHMgb3V0IG9mIHBsYWNlIGluIHRo aXMgc2VjdGlvbi4NCg0KU2VjdGlvbiAzLjINCnMvZHVyaW5nIG5ldHdvcmsgYXR0YWNobWVudCBw aGFzZS9kdXJpbmcgdGhlIG5ldHdvcmsgYXR0YWNobWVudCBwaGFzZS8NCnMvQm90aCBjZW50cmFs aXplZCBhbmQgZGlzdHJpYnV0ZWQgbWVjaGFuaXNtL0JvdGggY2VudHJhbGl6ZWQgYW5kIGRpc3Ry aWJ1dGVkIG1lY2hhbmlzbXMvDQoNClNlY3Rpb24gMy4zLjENCuKAnFRoZSBTRkMgY29udHJvbCBw bGFuZSBzaG91bGQgYmUgcmVzcG9uc2libGXigJ0gIFdoYXQgZG8geW91IG1lYW4g4oCcc2hvdWxk IGJl4oCdPyAgUmVzcG9uc2liaWxpdHkgc2hvdWxkIGJlIGNsZWFybHkgYXNzaWduZWQuDQrigJzi gKZiZSBwYXJ0IG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGRpc2NvdmVyeSBwcm9jZWR1cmXigJ0g V2hhdCBpcyB0aGF0PyAgRmlyc3QgbWVudGlvbiBvZiBpdC4NCuKAnG1lYW5zIHRvIHJlZHVjZSBj bGFzc2lmaWNhdGlvbiBsb29rdXAgdGltZSDigKYgc2hvdWxkIGJlIHN1cHBvcnRlZCBieSB0aGUg U0ZDIGNvbnRyb2wgcGxhbmXigJ0g4oCTIFdoeT8gIElzbuKAmXQgdGhhdCBhIGpvYiBmb3IgdGhl IGNsYXNzaWZpZXIgdG8gbG9jYWxseSBvcHRpbWl6ZT8NCnMvdGhhbmtzIHRvIHRoZSBpbnZvY2F0 aW9uIG9mL2J5IGludm9raW5nLw0Kcy9kb2VzIG5vdCBjb252ZXkgdGhhdCBzZW1hbnRpY3MvIGRv ZXMgbm90IGNvbnZleSB0aG9zZSBzZW1hbnRpY3MvDQpzL3RydXN0IGFuIGV4aXN0aW5nIFNGQyBp bmZvcm1hdGlvbi8gdHJ1c3QgZXhpc3RpbmcgU0ZDIGluZm9ybWF0aW9uIC8NCnMvY29uZmlndXJh YmxlIHBhcmFtZXRlci9jb25maWd1cmFibGUgcGFyYW1ldGVycy8NCg0KU2VjdGlvbiAzLjMuMg0K cy9TdWNoIHRhYmxlL1RoaXMgdGFibGUvDQpzL1N1Y2ggaW5zdHJ1Y3QgdHlwaWNhbGx5L1RoaXMg dHlwaWNhbGx5Lw0K4oCcZ3JvdXBzIG9mIGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50IFNGcyDigKYg bWF5IGJlIHVzZWQgZm9yIGxvYWQtYmFsYW5jaW5nIHB1cnBvc2Vz4oCdICBXaGF0IGlzIHRoZSBy ZWxldmFuY2UgdG8gdGhlIGNvbnRyb2wgcGxhbmUgdGhhdCB0aGV5IG1heSBiZSB1c2VkIGZvciBs b2FkIGJhbGFuY2luZz8gIFdoZW4geW91IHNheSDigJxtYXkgYmUgdXNlZOKAnSBkbyB5b3UgbWVh biBpbiBhbGwgY2lyY3Vtc3RhbmNlcywgb3IgZG8geW91IG1lYW4gb25seSBpbiBzb21lIGNpcmN1 bXN0YW5jZXM/DQrigJxCeSBkZWZhdWx0LCBhbiBTRkYgcmVsaWVzIG9uIGxlZ2FjeSBwcm9jZXNz aW5nIGZvciBmb3J3YXJkaW5nIHRoZXNlIHBhY2tldHMu4oCdICBEb2VzIOKAnGxlZ2FjeSBwcm9j ZXNzaW5n4oCdIG1lYW4gZm9yd2FyZGluZyB1c2luZyBleGlzdGluZyBuZXR3b3JrIGhlYWRlcnM/ ICBJIHdvdWxkIG5vdCBjYWxsIHRoYXQg4oCcbGVnYWN54oCdLg0KDQpTZWN0aW9uIDMuMy4zDQri gJxTRnMgbWF5IG5lZWQgdG8gb3V0cHV0IHNvbWUgcHJvY2Vzc2luZyByZXN1bHRzIG9mIHBhY2tl dHPigJ0gaXMgdG9vIHdvb2xseS4NCuKAnFRoZSBTRkMgY29udHJvbCBuZWVkcyB0aGUgYWJvdmUg c3RhdHVzIGluZm9ybWF0aW9uIGZvciB2YXJpb3VzIHRhc2tz4oCdIGlzIGFsc28gdG9vIHdvb2xs eS4NCkluIHRoaXMgc2VjdGlvbiB3aGVyZSB5b3Ugc2F5IChtdWx0aXBsZSB0aW1lcykg4oCcYSBj b250ZXh0IGluZm9ybWF0aW9u4oCdIGRvIHlvdSBtZWFuIOKAnHRoZSBjb250ZXh0IGhlYWRlcnMg aW4gdGhlIE5TSOKAnT8gIFRoZSBsYXR0ZXIgd291bGQgYmUgY2xlYXJlci4NCuKAnE5vdGUgdGhh dCBhIGNvbnRleHQgbWF5IGJlIG1hbmRhdG9yeSBmb3IgImNoYWluIDEiLCBidXQgb3B0aW9uYWwg Zm9yICJjaGFpbiAyIi7igJ0gIFN1cmUsIGJ1dCB3aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zIG9m IHRoaXMgZm9yIHRoZSBjb250cm9sIHBsYW5lPw0K4oCcTXVsdGlwbGUgU0ZzIG1heSBiZSBsb2Nh dGVkIHdpdGhpbiB0aGUgc2FtZSBwaHlzaWNhbCBub2RlLCBidXQgbm8gU0ZGIGlzIGVuYWJsZWQg aW4gdGhhdCBzYW1lIG5vZGUsIG1lYW5zIHRvIHVuYW1iaWd1b3VzbHkgZm9yd2FyZCB0aGUgdHJh ZmZpYyBmcm9tIHRoZSBTRkYgdG8gdGhlIGFwcHJvcHJpYXRlIFNGIG11c3QgYmUgc3VwcG9ydGVk LuKAnSDigJMgSSBjYW7igJl0IHBhcnNlIHRoaXMgc2VudGVuY2UuDQrigJxDb25jcmV0ZWx5LCBl YWNoIFNGIG11c3QgaGF2ZSBhIHVuaXF1ZSBsb2NhdG9yIGZvciB1bmFtYmlndW91cyBmb3J3YXJk aW5nLiAgVGhpcyBsb2NhdG9yIG1heSBiZSBjb25maWd1cmVkIHVzaW5nIHRoaXMgaW50ZXJmYWNl LuKAnSAgVGhpcyBzb3VuZHMgbGlrZSBhIGRlc2NyaXB0aW9uIG9mIG1hbmFnZW1lbnQgcGxhbmUg ZnVuY3Rpb24sIG5vdCBjb250cm9sIHBsYW5lIGZ1bmN0aW9uLiAgV2hhdCBpbXBsaWNhdGlvbnMg ZG9lcyB0aGUgbG9jYXRvciBoYXZlIGZvciB0aGUgY29udHJvbCBwbGFuZT8NCuKAnFNwZWNpYWwg Y2FyZSBzaG91bGQgYmUgY29uc2lkZXJlZCB0byBhdm9pZCB0aGF0IGluc3RydWN0aW9ucyBwcm92 aWRlZCB0byBkaXN0aW5jdCBTRnMgbGVhZCB0byBsb29wcy7igJ0gIFJld3JpdGUgdG8gc2F5IHdo YXQgdGhlIGNvbnRyb2wgcGxhbmUgbXVzdCBkbyB0byBhdm9pZCBvciBtaXRpZ2F0ZSBsb29wcy4N Cg0KU2VjdGlvbiA0LjENCnMvdmFyaWV0eSBpZiBtZWNoYW5pc21zL3ZhcmlldHkgb2YgbWVjaGFu aXNtcy8NCg0KU2VjdGlvbiA0LjINCnMvYm90aCBkaXJlY3Rpb24gb2YvYm90aCBkaXJlY3Rpb25z IG9mLw0KV2hhdCBkb2VzIOKAnGZ1bGwgY2hhaW4gc3ltbWV0cnnigJ0gbWVhbj8NCg0KU2VjdGlv biA0LjQNCnMvIGFjY29tbW9kYXRlIHN1Y2ggY29udGV4dC8gYWNjb21tb2RhdGUgdGhpcy8NClRo aXMgc2VjdGlvbiBnaXZlcyBhIGNvdXBsZSBvZiBleGFtcGxlcy4gIEFyZSB5b3UgZ2l2aW5nIGEg c3Vic2V0IG9mIGFsbCBwb3NzaWJsZSBvcHRpb25zPyAgQXJlIHlvdSBzYXlpbmcgdGhlIGNvbnRy b2wgcGxhbmUgY2FuIGRvIGVpdGhlciwgb3IgYm90aCwgb3Igc29tZXRpbWVzIG9uZSBhbmQgc29t ZXRpbWVzIHRoZSBvdGhlcj8NCg0KU2VjdGlvbiA0LjYNCuKAnFNwZWNpZmljIGNyaXRlcmlhIHRv IHNlbmQgdW5zb2xpY2l0ZWQgbm90aWZpY2F0aW9ucyB0byBhIENvbnRyb2wgRWxlbWVudCBzaG91 bGQgYmUgZmluZSB0dW5lZCBieSB0aGUgY29udHJvbCBwbGFuZeKAnSAgV2hhdCBkbyB5b3UgbWVh biBieSDigJxmaW5lIHR1bmVk4oCdPyAgV2hhdCBkb2VzIHRoZSBjb250cm9sIHBsYW5lIGFjdHVh bGx5IG5lZWQgdG8gZG8/DQoNClNlY3Rpb24gNC43DQpzL2xpdmVsaW5lc3MvbGl2ZW5lc3MvDQri gJxUaGUgY2xhc3NpZmllciBtYXkgYmUgbm90aWZpZWQgYnkgdGhlIGNvbnRyb2wgcGxhbmXigJ0g 4oCTIE5vdGlmaWVkIG9mIHdoYXQ/DQrigJxUaGUgYWJpbGl0eSBvZiBhbiBTRkMgQ29udHJvbCBF bGVtZW50IHRvIGNoZWNrIHRoZSBsaXZlbmVzcyBvZiBlYWNoIFNGIHByZXNlbnQgaW4gc2Vydmlj ZSBmdW5jdGlvbiBjaGFpbiBoYXMgc2V2ZXJhbCBhZHZhbnRhZ2Vz4oCm4oCdIOKAkyBBZHZhbnRh Z2VzIG92ZXIgd2hhdD8gIERvIHlvdSBqdXN0IG1lYW4gaXQgaGFzIHNldmVyYWwg4oCcZmVhdHVy ZXPigJ0/ICBXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIGxpc3RpbmcgdGhvc2UgZmVhdHVyZXM/ICBX aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zIGZvciB0aGUgY29udHJvbCBwbGFuZT8gIEFyZSB5b3Ug Z2l2aW5nIGEgbGlzdCBvZiB0aGluZ3MgdGhlIGNvbnRyb2wgcGxhbmUgbXVzdCBkbz8NCuKAnENv bnRyb2wgRWxlbWVudHMgbWF5IGJlIGZlZCBkaXJlY3RseSBvciBpbmRpcmVjdGx5IHdpdGggaW5w dXRzIGZyb20gdGhlc2UgbWVjaGFuaXNtcy7igJ0g4oCTIFdoYXQgZG8geW91IG1lYW4gYnkgZGly ZWN0bHkgdmVyc3VzIGluZGlyZWN0bHk/ICBJcyB0aGlzIHBhcnQgb2Ygb25lIG9mIHRoZSBDeCBp bnRlcmZhY2VzPw0KDQpTZWN0aW9uIDQuOA0K4oCcRXZlbiBpZiBzZXR0aW5nIHRoZSBkYXRhIGNv bGxlY3Rpb24gY3ljbGUgaXMgZGVwbG95bWVudC1zcGVjaWZpYywgaXQgaXMgcmVjb21tZW5kZWQg dG8gc3VwcG9ydCBkeW5hbWljIG1lYW5z4oCm4oCdICBXaGF0IGRvIHlvdSBtZWFuIGJ5IOKAnGR5 bmFtaWMgbWVhbnPigJ0/DQoNClNlY3Rpb24gNC45DQrigJxCb3RoIHNob3J0IGFuZCBsb25nIGxp ZmV0aW1lcyBtYXkgYmUgYXNzaWduZWQu4oCdIOKAkyBJcyBub3QgcmVhbGx5IGEgdXNlZnVsIHN0 YXRlbWVudC4gIFdoYXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMgZm9yIHRoZSBjb250cm9sIHBsYW5l PyAgQSB1c2VmdWwgc3RhdGVtZW50IHdvdWxkIGluY2x1ZGUgd2hhdCB1bml0cyB0aGVzZSBsaWZl dGltZXMgc2hvdWxkIGJlIGNvbnZleWVkIGluLCBhbmQgdGhlaXIgdmFsaWQgcmFuZ2UuDQoNClNl Y3Rpb24gNC4xMC4xDQpzL2NoYW5nZXMgc2hvdWxkIG1vbml0b3JlZC9jaGFuZ2VzIHNob3VsZCBi ZSBtb25pdG9yZWQvDQpzL292ZXJsYWRlZC9vdmVybG9hZGVkLw0KSW4gdGhlIHByb2NlZHVyZXMg Zm9yIFNGUCBhZGp1c3RtZW50LCBwbGVhc2UgZ2l2ZSBtb3JlIGRldGFpbCBvbiB0aGUgY29udHJv bCBwbGFuZSByZXF1aXJlbWVudHMgZm9yIOKAnFJlcGxhY2UgdGFyZ2V0IFNGIGluc3RhbmNlcyAo ZS5nLiwgaW4gYSBmYWlsdXJlIG9yIG92ZXJsYWRlZCkgd2l0aCBuZXdseSBzZWxlY3RlZCBvbmVz LuKAnSAgSG93IGlzIHRoaXMgdG8gYmUgZG9uZT8gIEkgYXNzdW1lIG1ha2UgYmVmb3JlIGJyZWFr IGlzIHJlcXVpcmVkLiAgQXJlIHRoZXJlIGFueSBvdGhlciBjb250cm9sIHBsYW5lIHJlcXVpcmVt ZW50cz8NCg0KU2VjdGlvbiA0LjEwLjMNClBsZWFzZSBleHBsYWluIHdoYXQgeW91IG1lYW4gYnkg 4oCccmVnaW9uYWwgcmVzdG9yYXRpb27igJ0uDQpJdCBpc27igJl0IGNsZWFyIHRvIG1lIHdoYXQg dGhlIGZpcnN0IDMgcGFyYWdyYXBocyBpbiB0aGlzIHNlY3Rpb24gaGF2ZSB0byBkbyB3aXRoIHRo ZSBmaW5hbCB0d28sIGJ1dCBwZXJoYXBzIGlmIEkgdW5kZXJzdG9vZCB3aGF0IOKAnHJlZ2lvbmFs IHJlc3RvcmF0aW9u4oCdIG1lYW50IGl0IHdvdWxkIGJlIGNsZWFyZXIuDQoNCg0K --_000_787AE7BB302AE849A7480A190F8B933009E1B1DCOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1M IENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFy Z2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxD YXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnAuSFRNTFByZWZvcm1h dHRlZCwgbGkuSFRNTFByZWZvcm1hdHRlZCwgZGl2LkhUTUxQcmVmb3JtYXR0ZWQNCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjMxNjMwMzkzNjsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NTgyODkxNjIgLTU2NzYz MTk0NiA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5NyA2Nzg5NTI5OSA2Nzg5NTMwMSA2Nzg5NTI5 NyA2Nzg5NTI5OSA2Nzg5NTMwMTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjQ7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBKb25hdGhhbiwNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3Ug Zm9yIHRoZSByZXZpZXcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+VGhlIFdHIGlzIGN1cnJlbnRseSBkaXNjdXNzaW5nIGhvdyB0byBwcm9ncmVz cyB0aGlzIHdvcms6DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3NmYy9jdXJyZW50L21zZzA1NDM3Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDU0MzcuaHRtbDwvYT4uIEnigJltIG5vdCBzdXJl IGlmIHRoZSBkb2N1bWVudCB3aWxsIGJlIG1haW50YWluZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPknigJlkIGxpa2UgdG8gbm90ZSB0aGF0IHRo ZSBkb2N1bWVudCBzY29wZSByZWZsZWN0cyB3aGF0IHRoZSBXRyB3YW50ZWQgdG8gc2VlIGluIHRo aXMgZG9jdW1lbnQuIEluIHBhcnRpY3VsYXIsIHRoZSBkb2N1bWVudCBpcyBub3QgbWlzc2lvbmVk IHRvIGRlZmluZSBhIHByb3RvY29sLA0KIGEgcHJvdG9jb2wgZXh0ZW5zaW9uLCBvciB0b3VjaCBv biB0aGUgaW50ZXJuYWwgc3RydWN0dXJlIG9mIGNvbnRyb2wgZWxlbWVudHMgKGNmLCB0aGUgY2hh cnRlciBleGNlcnB0IGJlbG93KS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj49PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QWxs IHByb3RvY29sIGV4dGVuc2lvbiB3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5yZXN1bHRpbmcg ZnJvbSB0aGVzZSByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGNhcnJpZWQgb3V0IGluIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+d29ya2luZyBncm91cCByZXNwb25zaWJsZSBmb3IgdGhlIHByb3Rv Y29sIGJlaW5nIG1vZGlmaWVkIGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5jb29yZGluYXRpb24g d2l0aCB0aGlzIHdvcmtpbmcgZ3JvdXAsIGJ1dCBtYXkgYmUgZG9uZSBpbiB0aGlzIHdvcmtpbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPmdyb3VwIHVuZGVyIGEgcmV2aXNlZCBjaGFydGVyIGFmdGVy IGFncmVlbWVudCB3aXRoIGFsbCB0aGUgcmVsZXZhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldH IGNoYWlycyBhbmQgcmVzcG9uc2libGUgQURzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT09PT09 PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRo ZSBkb2N1bWVudCBkZWZpbmVzIGEgQ1AgYXJjaGl0ZWN0dXJlIHRoYXQgY2FuIGJlIGltcGxlbWVu dGVkIHdpdGggY2VudHJhbGl6ZWQgYW5kIGRpc3RyaWJ1dGVkIENQIHByb3RvY29scyB3aXRoIGEg cGFydGljdWxhciBmb2N1cyBvbiB0aGUg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5yZXF1 aXJlbWVudHMNCiBmb3IgY29udmV5aW5nIGluZm9ybWF0aW9uIGJldHdlZW4gY29udHJvbCBvciBt YW5hZ2VtZW50IGVsZW1lbnRzIGFuZCBTRkMgaW1wbGVtZW50YXRpb24gcG9pbnRz4oCdIChTRkMg Y2hhcnRlcik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4uDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QXMgcGVyIHlv dXIgcXVlc3Rpb24gcmVsYXRlZCB0byBQQ0UsIEkgcmVpdGVyYXRlIHRoZSBwb3NpdGlvbiBvZiB0 aGUgU0ZDIFdHIGFzIEkgdW5kZXJzdG9vZCBpdCB3aGVuIGFjdGluZyBhcyBhbiBlZGl0b3Igb2Yg dGhpcyBkb2N1bWVudDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+SXQgaXMgTk9UIHRoZSBnb2FsIG9mIHRoaXMgcmVxdWlyZW1lbnRz IGRvY3VtZW50IHRvIG1hbmRhdGUgdGhlIHVzZSBvZiBQQ0UsIEJHUCwgUkFESVVTLCBldGMuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkFsc28sIHRoaXMgZG9jdW1lbnQgaXMgTk9UIGVudGl0bGVkIHRvIG1hbmRhdGUgd2hldGhlciBv bmUgc2luZ2xlIHByb3RvY29sIG9yIG1hbnkgcHJvdG9jb2xzIHdpbGwgYmUgdXNlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IGFn YWluIGZvciB0aGUgcmV2aWV3LiBJdCBpcyBhbHdheXMgaW5zdHJ1Y3RpdmUgdG8gaGF2ZSBleHRl cm5hbCBleWVzIG9uIGEgZG9jdW1lbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOkZSIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj4gSm9uYXRoYW4gSGFyZHdpY2sgW21haWx0bzpK b25hdGhhbi5IYXJkd2lja0BtZXRhc3dpdGNoLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6 PC9iPiBtZXJjcmVkaSAxIG1hcnMgMjAxNyAxNzo1OTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQWxp YSBBdGxhczsgZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZUBpZXRmLm9yZzxicj4NCjxiPkNj Jm5ic3A7OjwvYj4gc2ZjQGlldGYub3JnOyBydGctZGlyQGlldGYub3JnPGJyPg0KPGI+T2JqZXQm bmJzcDs6PC9iPiBSb3V0aW5nIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1j b250cm9sLXBsYW5lLTA4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkhlbGxvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGhhdmUg YmVlbiBzZWxlY3RlZCBhcyB0aGUgcm91dGluZyBkaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhp cyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtc2ZjLWNvbnRyb2wtcGxhbmUvPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+VGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9y IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNh bGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdCwgYXMg aW4gdGhpcyBjYXNlLiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUNCiBh c3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLPGEgaHJlZj0iaHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+aHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPkRvY3VtZW50OiBkcmFmdC1pZXRmLXNmYy1jb250cm9sLXBsYW5lLTA4LnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij5SZXZpZXdlcjogSm9uYXRoYW4gSGFyZHdpY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+UmV2aWV3IERhdGU6IDEgTWFyY2gg MjAxNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj5JbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PHNwYW4gbGFuZz0i RU4tR0IiPlN1bW1hcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgaGF2ZSBzaWduaWZpY2FudCBjb25jZXJucyBhYm91 dCB0aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQgdGhhdCB0aGUgUm91dGluZyBBRHMgZGlzY3Vz cyB0aGVzZSBpc3N1ZXMgZnVydGhlciB3aXRoIHRoZSBhdXRob3JzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48c3BhbiBsYW5nPSJF Ti1HQiI+Q29tbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIGxhbmc9IkVOLUdCIj5Eb2N1bWVudCBTY29wZTxv OnA+PC9vOnA+PC9zcGFuPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+VGhpcyBkb2N1bWVudCBhaW1zIHRvIGRlc2NyaWJlIHRoZSByZXF1aXJlbWVudHMg dGhhdCB0aGUgU0ZDIGRhdGEgcGxhbmUgaGFzIG9uIHRoZSBjb250cm9sIHBsYW5lLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+TXkgbWFqb3IgY29uY2VybiB3aXRoIHRoaXMgZG9jdW1lbnQgaXMgdGhhdCBp dHMgc2NvcGUgaXMgdG9vIG5hcnJvdy4mbmJzcDsgV2l0aG91dCBnaXZpbmcgYSBjb250cm9sIHBs YW5lIGFyY2hpdGVjdHVyZSwgdGhpcyBkb2N1bWVudOKAmXMgdXNlZnVsbmVzcyBpcyBxdWl0ZSBs aW1pdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhlIGRvY3VtZW50IGlzIHByZXN1bWFibHkgdXNl ZnVsIHRvIHBlb3BsZSB3b3JraW5nIHdpdGhpbiB0aGUgU0ZDIFdHIGFzIGEgY2hlY2tsaXN0IG9m IHRoZWlyIHJlcXVpcmVtZW50cy4mbmJzcDsgSSBhc3N1bWUgKGFuZCBob3BlKSB0aGF0IFNGQyB3 aWxsIGluIGZ1dHVyZSBwdWJsaXNoIGEgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgdGhhdCB3 aWxsIHNhdGlzZnkgdGhlc2UgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+U3BlYWtp bmcgd2l0aCBteSBpbXBsZW1lbnRlciBoYXQgb24sIHRoaXMgZG9jdW1lbnQgaXMgbm90IHVzZWZ1 bCB0byBtZSBhcyBpdCBkb2VzIG5vdCBkZXNjcmliZSBhbnl0aGluZyB0aGF0IEkgY2FuIGltcGxl bWVudC4mbmJzcDsgSXQgZG9lcyBub3QgZGVzY3JpYmUgd2hhdCB0aGUgY29udHJvbCBwbGFuZSBs b29rcyBsaWtlLCB3aGF0IGJ1aWxkaW5nIGJsb2NrcyB0byB1c2UsIGV0Yy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPlNwZWFraW5nIHdpdGggbXkgSUVURiBXRyBjaGFpciBoYXQgb24sIHRoaXMgZG9jdW1l bnQgaXMgbm90IHVzZWZ1bCB0byBtZSBhcyBpdCBnaXZlcyBubyBzdGVlciBhcyB0byB3aGF0IHBy b3RvY29scyB3aWxsIGJlIGVtcGxveWVkLCBvciBob3cuJm5ic3A7IFRoaXMgaXMgY2F1c2luZyBk aWZmaWN1bHRpZXMgZm9yIG90aGVyIHdvcmtpbmcgZ3JvdXBzLiZuYnNwOyBGb3IgZXhhbXBsZSwg c29tZW9uZQ0KIHJlY2VudGx5IGNhbWUgdG8gdGhlIFBDRSBXRyB3aXRoIGEgZHJhZnQgZGVzY3Jp YmluZyBhbiBTRkMgY29udHJvbCBwbGFuZSBpbXBsZW1lbnRlZCB3aXRoIFBDRVAuJm5ic3A7IEkg aGF2ZSBubyBpZGVhIGlmIHRoZSBTRkMgV0cgd2FudHMgdG8gdXNlIFBDRVAgaW4gaXRzIGNvbnRy b2wgcGxhbmUsIHNvIEkgYW0gdW5hYmxlIHRvIGFkb3B0IHNhaWQgZHJhZnQuJm5ic3A7IE1lYW53 aGlsZSwgdGhlcmUgaXMgYSBkcmFmdCBpbiBCRVNTIHRoYXQgZG9jdW1lbnRzIGENCiBjb21wbGV0 ZWx5IGRpZmZlcmVudCBTRkMgY29udHJvbCBwbGFuZSwgYW5kIHRoZXJlIG1heSBiZSBvdGhlcnMu Jm5ic3A7IFdlIGFyZSBpbiBhIGNvbmZ1c2luZyBzaXR1YXRpb24gYW5kIHRoZSBwcm9wb3NhbHMg YXJlIHByb2xpZmVyYXRpbmcuJm5ic3A7IFRoZSBTRkMgd29ya2luZyBncm91cCBuZWVkcyB0byBz dGVlciB0aGUgcHJvdG9jb2wgZGV2ZWxvcG1lbnQgd29yaywgYnV0IHRoaXMgZG9jdW1lbnQgaXMg Y29tcGxldGVseSBzaWxlbnQgb24gaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5BcyBzdWNoLCBJIGFt IG5vdCBzdXJlIHRoYXQgaXQgaXMgd29ydGggdGhlIElFVEYgcHVibGlzaGluZyB0aGlzIGRvY3Vt ZW50IGFzIGl0IHN0YW5kcy4mbmJzcDsgSG93ZXZlciwgSSBkbyB2ZXJ5IG11Y2ggZW5jb3VyYWdl IHRoZSBTRkMgd29ya2luZyBncm91cCB0byBjb250aW51ZSB0aGVpciB3b3JrIG9uIHRoZSBjb250 cm9sIHBsYW5lIGFuZCB0byBkZXZlbG9wIGFuIGFyY2hpdGVjdHVyZQ0KIHdoaWNoIGRlc2NyaWJl cyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPklmIHdlIGRvIGdvIGFoZWFkIGFuZCBwdWJsaXNoIHRo aXMsIHRoZW4gSSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBiZSByZXN0cnVjdHVy ZWQgYW5kIG1hZGUgbXVjaCBicmllZmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48c3BhbiBsYW5nPSJFTi1HQiI+RG9jdW1lbnQg Q29udGVudDxvOnA+PC9vOnA+PC9zcGFuPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+VGhlIGRvY3VtZW50IHN0cmF5cyBpbnRvIGRpc2N1c3Npb25zIG9m IG1hbmFnZW1lbnQgcGxhbmUgb3BlcmF0aW9uIGFuZCByZXF1aXJlbWVudHMuJm5ic3A7IEZvciBl eGFtcGxlLCBhbGwgb2Ygc2VjdGlvbiA0LjMgdGFsa3MgYWJvdXQgbWFuYWdlbWVudCBwbGFuZSBv cGVyYXRpb24gYW5kIGRvZXMgbm90IG1ha2UgaXQgY2xlYXIgd2hhdCB0aGUgaW1wbGljYXRpb25z IGZvciB0aGUgY29udHJvbA0KIHBsYW5lIGFyZS4mbmJzcDsgSSByZWNvbW1lbmQgdGhhdCB0aGUg ZG9jdW1lbnQgaXMgcmV2aWV3ZWQgd2l0aGluIFNGQyBhbmQgYW55dGhpbmcgdGhhdCBkb2VzIG5v dCB0YWxrIGFib3V0IGEgY2xlYXIgY29udHJvbCBwbGFuZSBpbXBsaWNhdGlvbiBpcyB0YWtlbiBv dXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgZG9jdW1lbnQgZnJlcXVlbnRseSBkaWdyZXNzZXMg aW50byBnaXZpbmcgbGlzdHMgb2YgZXhhbXBsZXMuJm5ic3A7IEZvciBleGFtcGxlLCBzZWN0aW9u IDMuMy4xLCAzLjMuMywgNC40LCA0LjcsIDQuOC4mbmJzcDsgVGhpcyBpcyBub3QgYSBoZWxwZnVs IHdheSB0byBjYXB0dXJlIHJlcXVpcmVtZW50cy4mbmJzcDsgSW5zdGVhZCBvZiBnaXZpbmcgb3Bl biBlbmRlZCBsaXN0cywgdGhlIGRvY3VtZW50DQogc2hvdWxkIGRpc3RpbCBhIHNldCBvZiByZXF1 aXJlbWVudHMgb3V0IG9mIHRoZSBrbm93biBleGFtcGxlcywgYW5kIHN0YXRlIHRoZSByZXF1aXJl bWVudHMgaW5zdGVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNvbWUgb2YgdGhlIHBhc3NhZ2VzIGlu IHRoZSBkb2N1bWVudCBmZWx0IHN1cGVyZmx1b3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNw YW4gbGFuZz0iRU4tR0IiPkEpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPlNlY3Rpb24gMy4yLiZuYnNwOyBJIHRoaW5rIHRoaXMgc2VjdGlvbiBhZGRzIG5vdGhp bmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+Qik8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+VGhlIGxpc3Qgb2Yg4oCcZnVuY3Rp b25hbCBvYmplY3RpdmVz4oCdIGluIDMuMy4xLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4g bGFuZz0iRU4tR0IiPkMpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPlNlY3Rpb24gNC4zLCB3aGVyZSwgYXMgc3RhdGVkIGFib3ZlLCBJIGRvbuKAmXQgc2VlIHRo ZSByZWxldmFuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+RCk8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+U2VjdGlvbiA0LjUu Jm5ic3A7IFRoaXMganVzdCBzZWVtcyB0byBiZSBzYXlpbmcgdGhhdCB0aGUgY29udHJvbCBwbGFu ZSBuZWVkcyB0byBiZSBhYmxlIHRvIG1vZGlmeSBTRkNzLiZuYnNwOyBJIGRvbuKAmXQgZmluZCB0 aGF0IHN1cnByaXNpbmcuJm5ic3A7IEnigJlkIGJlIGhhcHBpZXIgaWYgdGhpcyB3YXMgcmV3cml0 dGVuIHRvIHRhbGsgYWJvdXQgd2hhdCB0aGUgY29udHJvbCBwbGFuZSBtdXN0IGRvLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+VGhlIGRvY3VtZW50IGlzIGxhcmdlbHkgd3JpdHRlbiBpbiB0aGUgcGFzc2l2 ZSB2b2ljZSwgd2hpY2ggbWFrZXMgdW5kZXJzdGFuZGluZyBpdCBxdWl0ZSBoYXJkLiZuYnNwOyBU byB0YWtlIGFuIGV4YW1wbGUsIGluIHNlY3Rpb24gNC43LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+T0xE IChwYXNzaXZlIHZvaWNlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5i c3A7Jm5ic3A7IExpdmVuZXNzIHN0YXR1cyByZWNvcmRzIGZvciBhbGwgU0YgaW5zdGFuY2VzLCBh bmQgc2VydmljZSBmdW5jdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+ Jm5ic3A7Jm5ic3A7IGNoYWlucyAoaW5jbHVkaW5nIHRoZSBTRlBzIGJvdW5kIHRvIGEgZ2l2ZW4g Y2hhaW4pIGFyZSBtYWludGFpbmVkIGJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj4mbmJzcDsmbmJzcDsgdGhlIFNGQyBDb250cm9sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5ORVcgKGFjdGl2ZSB2b2lj ZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsm bmJzcDsgVGhlIFNGQyBjb250cm9sIHBsYW5lIG11c3QgbW9uaXRvciB0aGUgbGl2ZW5lc3Mgb2Yg YWxsIFNGIGluc3RhbmNlcywgYW5kIGFsbCBzZXJ2aWNlIGZ1bmN0aW9uPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgY2hhaW5zIChp bmNsdWRpbmcgdGhlIFNGUHMgYm91bmQgdG8gYSBnaXZlbiBjaGFpbikuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPkkgcmVjb21tZW5kIHRoYXQgYW4gRW5nbGlzaCBzcGVha2VyIG92ZXJoYXVscyB0aGUg dGV4dCBhbmQgcmVwbGFjZXMgdGhlIHBhc3NpdmUgdm9pY2Ugd2l0aCB0aGUgYWN0aXZlIHZvaWNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48dT48c3BhbiBsYW5nPSJFTi1HQiI+RG9jdW1lbnQgU3RydWN0dXJlPG86cD48L286cD48L3Nw YW4+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5JIGRv buKAmXQgdW5kZXJzdGFuZCB3aHkgdGhlIGRvY3VtZW50IHNlcGFyYXRlcyBjaGFwdGVyIDIg4oCc R2VuZXJpYyBDb25zaWRlcmF0aW9uc+KAnSBhbmQgY2hhcHRlciA0IOKAnEFkZGl0aW9uYWwgY29u c2lkZXJhdGlvbnPigJ0uJm5ic3A7IFRoZXkgYWxsIGp1c3QgbG9vayBsaWtlIHJlcXVpcmVtZW50 cyB0byBtZS4mbmJzcDsgSSB3b3VsZCBwdXQgY2hhcHRlciAzIGZpcnN0LCB0aGVuIG1lcmdlIGNo YXB0ZXJzDQogMiBhbmQgNCwgYW5kIHRyeSB0byBkaXN0aWwgdGhlIHJlc3VsdGluZyB0ZXh0IGFz IG11Y2ggYXMgcG9zc2libGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIGxhbmc9IkVOLUdCIj5EZXRhaWxlZCBjb21tZW50 czxvOnA+PC9vOnA+PC9zcGFuPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlY3Rpb24gMi4yLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgbGlzdCBvZiBp bmZvcm1hdGlvbiBwcm92aWRlZCBwcmlvciB0byBib290c3RyYXBwaW5nIGluY2x1ZGVzIOKAnFNG cyBzZXJ2aWNlZCBieSBlYWNoIFNGRuKAnSBidXQgdGhlIGluZm9ybWF0aW9uIGNvbGxlY3RlZCBk dXJpbmcgYm9vdHN0cmFwcGluZyBpbmNsdWRlcyDigJxUaGUgbGlzdCBvZiBTRkZzIGFuZCB0aGUg U0ZzIHRoYXQgYXJlIGF0dGFjaGVkIHRv4oCdLiZuYnNwOyBBcmVu4oCZdCB0aGV5DQogdGhlIHNh bWUgdGhpbmc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0aW9uIDMuMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5zLyBTZWN0aW9u IDMuMy4yIHNwZWNpZmllcyBzdWNoIGludGVyZmFjZS4vIFNlY3Rpb24gMy4zLjIgc3BlY2lmaWVz IHRoaXMgaW50ZXJmYWNlLi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhlIGZpbmFsIHBhcmFncmFwaCBmZWVscyBvdXQgb2Yg cGxhY2UgaW4gdGhpcyBzZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+U2VjdGlvbiAzLjI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+cy9kdXJpbmcgbmV0d29yayBhdHRhY2htZW50IHBoYXNlL2R1cmluZyB0aGUgbmV0d29yayBh dHRhY2htZW50IHBoYXNlLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5zL0JvdGggY2VudHJhbGl6ZWQgYW5kIGRpc3RyaWJ1dGVk IG1lY2hhbmlzbS9Cb3RoIGNlbnRyYWxpemVkIGFuZCBkaXN0cmlidXRlZCBtZWNoYW5pc21zLzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+U2VjdGlvbiAzLjMuMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj7igJxUaGUgU0ZDIGNvbnRyb2wg cGxhbmUgc2hvdWxkIGJlIHJlc3BvbnNpYmxl4oCdICZuYnNwO1doYXQgZG8geW91IG1lYW4g4oCc c2hvdWxkIGJl4oCdPyZuYnNwOyBSZXNwb25zaWJpbGl0eSBzaG91bGQgYmUgY2xlYXJseSBhc3Np Z25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+4oCc4oCmYmUgcGFydCBvZiB0aGUgc2VydmljZSBmdW5jdGlvbiBkaXNjb3Zl cnkgcHJvY2VkdXJl4oCdIFdoYXQgaXMgdGhhdD8mbmJzcDsgRmlyc3QgbWVudGlvbiBvZiBpdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+4oCcbWVhbnMgdG8gcmVkdWNlIGNsYXNzaWZpY2F0aW9uIGxvb2t1cCB0aW1lIOKApiBz aG91bGQgYmUgc3VwcG9ydGVkIGJ5IHRoZSBTRkMgY29udHJvbCBwbGFuZeKAnSDigJMgV2h5PyZu YnNwOyBJc27igJl0IHRoYXQgYSBqb2IgZm9yIHRoZSBjbGFzc2lmaWVyIHRvIGxvY2FsbHkgb3B0 aW1pemU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPnMvdGhhbmtzIHRvIHRoZSBpbnZvY2F0aW9uIG9mL2J5IGludm9raW5nLzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj5zL2RvZXMgbm90IGNvbnZleSB0aGF0IHNlbWFudGljcy8gZG9lcyBub3QgY29udmV5IHRo b3NlIHNlbWFudGljcy88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+cy90cnVzdCBhbiBleGlzdGluZyBTRkMgaW5mb3JtYXRpb24v IHRydXN0IGV4aXN0aW5nIFNGQyBpbmZvcm1hdGlvbiAvPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPnMvY29uZmlndXJhYmxlIHBh cmFtZXRlci9jb25maWd1cmFibGUgcGFyYW1ldGVycy88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlY3Rp b24gMy4zLjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+cy9TdWNoIHRhYmxlL1RoaXMgdGFibGUvPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPnMvU3VjaCBpbnN0 cnVjdCB0eXBpY2FsbHkvVGhpcyB0eXBpY2FsbHkvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPuKAnGdyb3VwcyBvZiBmdW5jdGlv bmFsbHkgZXF1aXZhbGVudCBTRnMg4oCmIG1heSBiZSB1c2VkIGZvciBsb2FkLWJhbGFuY2luZyBw dXJwb3Nlc+KAnSZuYnNwOyBXaGF0IGlzIHRoZSByZWxldmFuY2UgdG8gdGhlIGNvbnRyb2wgcGxh bmUgdGhhdCB0aGV5IG1heSBiZSB1c2VkIGZvciBsb2FkIGJhbGFuY2luZz8mbmJzcDsgV2hlbiB5 b3Ugc2F5IOKAnG1heSBiZSB1c2Vk4oCdIGRvIHlvdSBtZWFuIGluIGFsbCBjaXJjdW1zdGFuY2Vz LA0KIG9yIGRvIHlvdSBtZWFuIG9ubHkgaW4gc29tZSBjaXJjdW1zdGFuY2VzPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj7igJxC eSBkZWZhdWx0LCBhbiBTRkYgcmVsaWVzIG9uIGxlZ2FjeSBwcm9jZXNzaW5nIGZvciBmb3J3YXJk aW5nIHRoZXNlIHBhY2tldHMu4oCdJm5ic3A7IERvZXMg4oCcbGVnYWN5IHByb2Nlc3NpbmfigJ0g bWVhbiBmb3J3YXJkaW5nIHVzaW5nIGV4aXN0aW5nIG5ldHdvcmsgaGVhZGVycz8mbmJzcDsgSSB3 b3VsZCBub3QgY2FsbCB0aGF0IOKAnGxlZ2FjeeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlY3Rp b24gMy4zLjM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+4oCcU0ZzIG1heSBuZWVkIHRvIG91dHB1dCBzb21lIHByb2Nlc3Npbmcg cmVzdWx0cyBvZiBwYWNrZXRz4oCdIGlzIHRvbyB3b29sbHkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPuKAnFRoZSBTRkMgY29u dHJvbCBuZWVkcyB0aGUgYWJvdmUgc3RhdHVzIGluZm9ybWF0aW9uIGZvciB2YXJpb3VzIHRhc2tz 4oCdIGlzIGFsc28gdG9vIHdvb2xseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SW4gdGhpcyBzZWN0aW9uIHdoZXJlIHlvdSBz YXkgKG11bHRpcGxlIHRpbWVzKSDigJxhIGNvbnRleHQgaW5mb3JtYXRpb27igJ0gZG8geW91IG1l YW4g4oCcdGhlIGNvbnRleHQgaGVhZGVycyBpbiB0aGUgTlNI4oCdPyZuYnNwOyBUaGUgbGF0dGVy IHdvdWxkIGJlIGNsZWFyZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPuKAnE5vdGUgdGhhdCBhIGNvbnRleHQgbWF5IGJlIG1h bmRhdG9yeSBmb3IgJnF1b3Q7Y2hhaW4gMSZxdW90OywgYnV0IG9wdGlvbmFsIGZvciAmcXVvdDtj aGFpbiAyJnF1b3Q7LuKAnSZuYnNwOyBTdXJlLCBidXQgd2hhdCBhcmUgdGhlIGltcGxpY2F0aW9u cyBvZiB0aGlzIGZvciB0aGUgY29udHJvbCBwbGFuZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+4oCcTXVsdGlwbGUgU0ZzIG1h eSBiZSBsb2NhdGVkIHdpdGhpbiB0aGUgc2FtZSBwaHlzaWNhbCBub2RlLCBidXQgbm8gU0ZGIGlz IGVuYWJsZWQgaW4gdGhhdCBzYW1lIG5vZGUsIG1lYW5zIHRvIHVuYW1iaWd1b3VzbHkgZm9yd2Fy ZCB0aGUgdHJhZmZpYyBmcm9tIHRoZSBTRkYgdG8gdGhlIGFwcHJvcHJpYXRlIFNGIG11c3QgYmUg c3VwcG9ydGVkLuKAnSDigJMgSSBjYW7igJl0IHBhcnNlIHRoaXMNCiBzZW50ZW5jZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ 4oCcQ29uY3JldGVseSwgZWFjaCBTRiBtdXN0IGhhdmUgYSB1bmlxdWUgbG9jYXRvciBmb3IgdW5h bWJpZ3VvdXMgZm9yd2FyZGluZy4mbmJzcDsgVGhpcyBsb2NhdG9yIG1heSBiZSBjb25maWd1cmVk IHVzaW5nIHRoaXMgaW50ZXJmYWNlLuKAnSZuYnNwOyBUaGlzIHNvdW5kcyBsaWtlIGEgZGVzY3Jp cHRpb24gb2YgbWFuYWdlbWVudCBwbGFuZSBmdW5jdGlvbiwgbm90IGNvbnRyb2wgcGxhbmUgZnVu Y3Rpb24uJm5ic3A7DQogV2hhdCBpbXBsaWNhdGlvbnMgZG9lcyB0aGUgbG9jYXRvciBoYXZlIGZv ciB0aGUgY29udHJvbCBwbGFuZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+4oCcU3BlY2lhbCBjYXJlIHNob3VsZCBiZSBjb25z aWRlcmVkIHRvIGF2b2lkIHRoYXQgaW5zdHJ1Y3Rpb25zIHByb3ZpZGVkIHRvIGRpc3RpbmN0IFNG cyBsZWFkIHRvIGxvb3BzLuKAnSZuYnNwOyBSZXdyaXRlIHRvIHNheSB3aGF0IHRoZSBjb250cm9s IHBsYW5lIG11c3QgZG8gdG8gYXZvaWQgb3IgbWl0aWdhdGUgbG9vcHMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj5TZWN0aW9uIDQuMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5zL3ZhcmlldHkgaWYgbWVjaGFuaXNtcy92YXJpZXR5IG9m IG1lY2hhbmlzbXMvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0aW9uIDQuMjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5zL2JvdGgg ZGlyZWN0aW9uIG9mL2JvdGggZGlyZWN0aW9ucyBvZi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+V2hhdCBkb2VzIOKAnGZ1bGwg Y2hhaW4gc3ltbWV0cnnigJ0gbWVhbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlY3Rpb24gNC40PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPnMvIGFjY29tbW9kYXRlIHN1Y2ggY29udGV4dC8gYWNjb21tb2RhdGUgdGhpcy88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ VGhpcyBzZWN0aW9uIGdpdmVzIGEgY291cGxlIG9mIGV4YW1wbGVzLiZuYnNwOyBBcmUgeW91IGdp dmluZyBhIHN1YnNldCBvZiBhbGwgcG9zc2libGUgb3B0aW9ucz8mbmJzcDsgQXJlIHlvdSBzYXlp bmcgdGhlIGNvbnRyb2wgcGxhbmUgY2FuIGRvIGVpdGhlciwgb3IgYm90aCwgb3Igc29tZXRpbWVz IG9uZSBhbmQgc29tZXRpbWVzIHRoZSBvdGhlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlY3Rpb24g NC42PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPuKAnFNwZWNpZmljIGNyaXRlcmlhIHRvIHNlbmQgdW5zb2xpY2l0ZWQgbm90aWZp Y2F0aW9ucyB0byBhIENvbnRyb2wgRWxlbWVudCBzaG91bGQgYmUgZmluZSB0dW5lZCBieSB0aGUg Y29udHJvbCBwbGFuZeKAnSZuYnNwOyBXaGF0IGRvIHlvdSBtZWFuIGJ5IOKAnGZpbmUgdHVuZWTi gJ0/Jm5ic3A7IFdoYXQgZG9lcyB0aGUgY29udHJvbCBwbGFuZSBhY3R1YWxseSBuZWVkIHRvIGRv PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+U2VjdGlvbiA0Ljc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+cy9saXZlbGluZXNzL2xpdmVu ZXNzLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj7igJxUaGUgY2xhc3NpZmllciBtYXkgYmUgbm90aWZpZWQgYnkgdGhlIGNvbnRy b2wgcGxhbmXigJ0g4oCTIE5vdGlmaWVkIG9mIHdoYXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPuKAnFRoZSBhYmlsaXR5IG9m IGFuIFNGQyBDb250cm9sIEVsZW1lbnQgdG8gY2hlY2sgdGhlIGxpdmVuZXNzIG9mIGVhY2ggU0Yg cHJlc2VudCBpbiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGhhcyBzZXZlcmFsIGFkdmFudGFnZXPi gKbigJ0g4oCTIEFkdmFudGFnZXMgb3ZlciB3aGF0PyZuYnNwOyBEbyB5b3UganVzdCBtZWFuIGl0 IGhhcyBzZXZlcmFsIOKAnGZlYXR1cmVz4oCdPyZuYnNwOyBXaGF0IGlzIHRoZSBwdXJwb3NlDQog b2YgbGlzdGluZyB0aG9zZSBmZWF0dXJlcz8mbmJzcDsgV2hhdCBhcmUgdGhlIGltcGxpY2F0aW9u cyBmb3IgdGhlIGNvbnRyb2wgcGxhbmU/Jm5ic3A7IEFyZSB5b3UgZ2l2aW5nIGEgbGlzdCBvZiB0 aGluZ3MgdGhlIGNvbnRyb2wgcGxhbmUgbXVzdCBkbz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+4oCcQ29udHJvbCBFbGVtZW50 cyBtYXkgYmUgZmVkIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkgd2l0aCBpbnB1dHMgZnJvbSB0aGVz ZSBtZWNoYW5pc21zLuKAnSDigJMgV2hhdCBkbyB5b3UgbWVhbiBieSBkaXJlY3RseSB2ZXJzdXMg aW5kaXJlY3RseT8mbmJzcDsgSXMgdGhpcyBwYXJ0IG9mIG9uZSBvZiB0aGUgQ3ggaW50ZXJmYWNl cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlY3Rpb24gNC44PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPuKAnEV2ZW4gaWYgc2V0dGlu ZyB0aGUgZGF0YSBjb2xsZWN0aW9uIGN5Y2xlIGlzIGRlcGxveW1lbnQtc3BlY2lmaWMsIGl0IGlz IHJlY29tbWVuZGVkIHRvIHN1cHBvcnQgZHluYW1pYyBtZWFuc+KApuKAnSZuYnNwOyBXaGF0IGRv IHlvdSBtZWFuIGJ5IOKAnGR5bmFtaWMgbWVhbnPigJ0/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TZWN0 aW9uIDQuOTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj7igJxCb3RoIHNob3J0IGFuZCBsb25nIGxpZmV0aW1lcyBtYXkgYmUgYXNz aWduZWQu4oCdIOKAkyBJcyBub3QgcmVhbGx5IGEgdXNlZnVsIHN0YXRlbWVudC4mbmJzcDsgV2hh dCBhcmUgdGhlIGltcGxpY2F0aW9ucyBmb3IgdGhlIGNvbnRyb2wgcGxhbmU/Jm5ic3A7IEEgdXNl ZnVsIHN0YXRlbWVudCB3b3VsZCBpbmNsdWRlIHdoYXQgdW5pdHMgdGhlc2UgbGlmZXRpbWVzIHNo b3VsZCBiZSBjb252ZXllZCBpbiwNCiBhbmQgdGhlaXIgdmFsaWQgcmFuZ2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj5TZWN0aW9uIDQuMTAuMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5zL2NoYW5nZXMgc2hvdWxkIG1vbml0b3JlZC9j aGFuZ2VzIHNob3VsZCBiZSBtb25pdG9yZWQvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPnMvb3ZlcmxhZGVkL292ZXJsb2FkZWQv PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPkluIHRoZSBwcm9jZWR1cmVzIGZvciBTRlAgYWRqdXN0bWVudCwgcGxlYXNlIGdpdmUg bW9yZSBkZXRhaWwgb24gdGhlIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIGZvciDigJxSZXBs YWNlIHRhcmdldCBTRiBpbnN0YW5jZXMgKGUuZy4sIGluIGEgZmFpbHVyZSBvciBvdmVybGFkZWQp IHdpdGggbmV3bHkgc2VsZWN0ZWQgb25lcy7igJ0mbmJzcDsgSG93IGlzIHRoaXMgdG8gYmUgZG9u ZT8mbmJzcDsgSQ0KIGFzc3VtZSBtYWtlIGJlZm9yZSBicmVhayBpcyByZXF1aXJlZC4mbmJzcDsg QXJlIHRoZXJlIGFueSBvdGhlciBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPlNlY3Rpb24gNC4xMC4zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlBsZWFzZSBleHBsYWluIHdoYXQgeW91IG1l YW4gYnkg4oCccmVnaW9uYWwgcmVzdG9yYXRpb27igJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkl0IGlzbuKAmXQgY2xlYXIg dG8gbWUgd2hhdCB0aGUgZmlyc3QgMyBwYXJhZ3JhcGhzIGluIHRoaXMgc2VjdGlvbiBoYXZlIHRv IGRvIHdpdGggdGhlIGZpbmFsIHR3bywgYnV0IHBlcmhhcHMgaWYgSSB1bmRlcnN0b29kIHdoYXQg 4oCccmVnaW9uYWwgcmVzdG9yYXRpb27igJ0gbWVhbnQgaXQgd291bGQgYmUgY2xlYXJlci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933009E1B1DCOPEXCLILMA3corp_-- From nobody Thu Mar 2 16:47:55 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837A11296A0 for ; Thu, 2 Mar 2017 16:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 mstU3TlwI1wO for ; Thu, 2 Mar 2017 16:47:53 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AF012969C for ; Thu, 2 Mar 2017 16:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=788; q=dns/txt; s=iport; t=1488502073; x=1489711673; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tYMH94flSyHtg51q9l+lhJD1xjqvZU6v/vB6PeMR9yQ=; b=COfkl1Yi3KT54AIdJGo1OyFj2vHuT8zcLhbu7qno4YBgScvd+khoNsK6 8avzjFMbJZPfuaGKp3pzQR71pddIOX9Gmo5ALXBCy1FSaUwXDLNnkd/Ag Avo1QR3499l7pUFbHHWB9k0VRRaD3KicxuWiitnIg2kEoyvCReeMHZLiX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAQDcvLhY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1CBageNYJFKH5U1gg2GIgKCUD8YAQIBAQEBAQEBYh0LhHABAQE?= =?us-ascii?q?DATo/BQsCAQgYHhAyJQEBBA4FGYlZCLQ5iwwBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdhkyCBQiCYoQmEQEMEIVlAQScKQGSMYF7iHaGLpM2AR84eQhUFU8Bhjt1hy+?= =?us-ascii?q?BIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,234,1484006400"; d="scan'208";a="391347060" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2017 00:47:48 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v230llwg031885 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2017 00:47:48 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Mar 2017 18:47:47 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Thu, 2 Mar 2017 18:47:47 -0600 From: "Paul Quinn (paulq)" To: "adrian@olddog.co.uk" Thread-Topic: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt Thread-Index: AdKRRHVLY7SkxborSRGHk+YoYh/yhACpZwSA Date: Fri, 3 Mar 2017 00:47:47 +0000 Message-ID: <280A6DAE-EF14-4B43-8958-376696099956@cisco.com> References: <027d01d29144$d743bcb0$85cb3610$@olddog.co.uk> In-Reply-To: <027d01d29144$d743bcb0$85cb3610$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.17.231] Content-Type: text/plain; charset="us-ascii" Content-ID: <715CC652BCE011448A6F1E95E8559EBE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 00:47:54 -0000 > On Feb 27, 2017, at 4:59 PM, Adrian Farrel wrote: >=20 > Hi all, >=20 > Many thanks to Paul for the updated revision. This makes life a lot > easier. >=20 > Herewith a review. I suspect some points I've raised are tracked in > email threads or tickets, or in the minutes from the interim. That's > OK: I just read and scribbled in a continuous stream of consciousness. >=20 > A bit of a wood/trees scenario here and I can't promise I have caught > every concern on this pass. >=20 > Thanks to all for the work that has gone before and which makes this > detailed review possible. >=20 Thank you very much for the thoughtful review. I wanted to make sure I ack= 'd it, and let you know I'll get a reply out the week of March 13. =20 Paul From nobody Fri Mar 3 16:01:29 2017 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FE3129690; Fri, 3 Mar 2017 15:55:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533502.15846.11891369390425956416.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:35 -0800 Archived-At: Cc: sfc@ietf.org, akatlas@gmail.com Subject: [sfc] sfc - Requested session has been scheduled for IETF 98 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:35 -0000 Dear Joel Halpern, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sfc Session 1 (2:00:00) Tuesday, Afternoon Session III 1640-1840 Room Name: Zurich D size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Service Function Chaining Area Name: Routing Area Session Requester: Joel Halpern Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: spring sdnrg rtgwg nvo3 mpls lisp idr i2rs bess supa quic Second Priority: anima People who must be present: Joel M. Halpern Jim Guichard Alia Atlas Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Mon Mar 6 03:57:50 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BF6129656 for ; Mon, 6 Mar 2017 03:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=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 Ybw-EExGRiBA for ; Mon, 6 Mar 2017 03:57:48 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20093.outbound.protection.outlook.com [40.107.2.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02576129645 for ; Mon, 6 Mar 2017 03:57:47 -0800 (PST) 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=6MjsnPn1sJN/GVzUXncNCfSDxGV2ImykcAYX0YDsst4=; b=UttB2BNSmy7iulVvxB/Q+fpwcDylvvnavIOlzJnjUQKi4JUqJglz8wk0sFt38/oCvTAWNCyYYXJI8zAir5cB7ZmFcw0cnXCiK8i+rxJ8anbXTKQWPaFcqLmKB3BEoFKRHTu49feJQSFizDQaT+ewETIfOVKvcFf/+NgK8t0b09Q= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; Received: from [192.168.1.5] (86.247.3.219) by VI1PR0701MB2480.eurprd07.prod.outlook.com (10.168.139.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Mon, 6 Mar 2017 11:57:45 +0000 References: To: From: Martin Vigoureux X-Forwarded-Message-Id: Message-ID: Date: Mon, 6 Mar 2017 12:57:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [86.247.3.219] X-ClientProxiedBy: DB6PR0801CA0061.eurprd08.prod.outlook.com (10.169.219.29) To VI1PR0701MB2480.eurprd07.prod.outlook.com (10.168.139.17) X-MS-Office365-Filtering-Correlation-Id: afe9b63d-9c81-4bd9-bd24-08d4648800c3 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:VI1PR0701MB2480; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2480; 3:uYKhPvFulEUBJx6IRCvYtbQIyCs4BOmk8p5py6ChXAmnKzyxQmt8PS5+zcmpVBva7tpNbaPd8vqN171Io8U9gP+E++vSCPjTeKVQGF0+XrbsVI8ls7/ey3UzNQkFxfYEQFVkkt+p5JO2Wjue2TwMWsEk4Uus3rLNe9zG/2Dwkb32/1z/YitXNxgQmIJSZGPeG3xeWY83OSq4VubpxCGuQvC6yYQgLFocRgtZiS5FFwBa/d936cadfvJpgv5fLV6XtPhqIVJqHBzHaUGhRLiIcLvrEYbBvZ4eXRLToxnBUhg=; 25:0Kbos6Hwbkn3bq4vXlDYRRVQWJ0xy5FI2DbTG3L4xno2K1zf1WXLaNLs4E65dLBSF6B4qFKaFNmBpAeysjTgrEjH7bpwikGuttg3lcQ7CFluqLcdofFV2qMrGezjsNyvyQQlNKloJ15662Tl4UQbgVNNPzN56Le0ouV7/DXHew8Aj+NSLs9QGKQMoSOlvm89jyyMI96CyUm6WTqv6E0MNjOXw8hSLyHQjlgAVMW5RES8dHzAhwwThE7Gx5zyP3v+Bi6Q+8vJYrGmIZcydcKRt5tx5m0Vm6t9yUhpCes4/cUOGF/l69xP5TuJu6PPlAojcTvYtOvGG0+xoIi6YmojVonGLASwuYRrXsa1k6dMyZzHxVZ+mWZ0vTIPoHHOzPfgWr4BG9mHksoQozJC8T+76Is9uC7vGmXiLn7t0wU/7+qurKZCShKC9ueUYysbHRHFAPyHa6GsRe4GP2tQwpN3sA== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2480; 31:nDOQZhZbzulYpYVm4cdI6eP0/OWLCT2K2ZrJWn/aL33RxPvfJ6gvoGUXQ6edce/4y2syISzFdV29zn3qJszfMDZm58AoxJp7ZEpnmY0bbRr60R7E+RT3TBHhWF+NiHuSxG5l6xyWqlRZwqMRjJJ9uUszupy5SMLP5B2kHXziHYhJiFol9AhItVN1uLYzkVAkBmnqEZNKxHpp3p2+s+JAPfeJvw+eNKUxmNbC8ntjbD/yZ87CK/XskAJT7nWy/0C6XVNhPNaoOtcfLUq/pIghF8Gm6da84KK/Jq4nsQbx5pI=; 20:bKW7gZtZc/67DN2dAenN9W+EEmw43uEY9/afZFsdWu6f2GQMJq9ABskN5uQvWCpHScOogtNEmv6AiYjFZAnMnBx2jg70oYprbU/UGjrXYm74hj5MFsWI8c0UWC5is+U85dH8mGnPiOEry2+qMDdkPZE45VH20RCdf9LX01dsNoBAy3vUuRFiMIpPVJ60ntdfan472Wza87MTiEbpWxDfcCFt1bsksut631WJvFjbMxS0agqXpupWU/5NTqpLj40595S+RWaFF5wDlnttELWMMe3mEX/Qy2dTE++IAA41VQ1FNY4cw3fgFfgz9VF6kOROETtHaVzgJMjXsxo7HHr/qEBqYIXxLzEARkOGobeVPSh83bx6Pk1WrYqicZA2jIgslL8ntR3tHtAxGPvcI51OqHb9Ix3Kk+Y9ZgEXSAnaAXRevkcWozPFjceWd/VSVZ3fi0Yh9LDJ5k70bBp/bnlBW+Ek0mbP/3AsuLI+nknHW2kSOPiON5T4YyR48gKN3FUA X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:VI1PR0701MB2480; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2480; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2480; 4:A+62MCNkz0znLJbSRI49LRIxTOHsDsm3tJ6CBqLQJSvry0epi5KPetxVOmRjgTw6XfxUbTUy9cYg6mRaHIgwgXTZ4sIwtxL0n29YkJcXzgJ9Glimpye8rk4MlFptGbmK//5EZ8niYzG8MjM01t4xyT9qvyPLQ9utNUfN0TEyYGzkylsvmq0uy+5VrJEV8/R1AU81iiqJfz5Cs18vqPAAPttKdWvyBwCvLZ1SuiZVwKd3ymZ57msFoRmKAzp/QyrYcg0lLNjQ5Fg6wTYdXcUch1hO93ITH2x35fPjmSylk3RoqcjPKPcMQuBNMB5Q1XOOQY82tB0lFZ4FjRxu9v0Yif+yaKOsdOcrKUuPTnDEusJPJyobkJq+8tZxSwuCAauEkS1RZ7LdolhxIorSeXJoQ0lAvWWefKNHtvNk4VzJT+dPstxQkxJlxVjyRJHx2AoyOEXYabXBGit6xsmJVr3xTIZKAayzDcatrCCmjjY39QUNOxc5JcplWL8YVhSZPKK/ImadfjUXMWSfn3sGCQWhIOugIZbRlgKFm6UDfFSfnIW4498v9VU8UEc9u53AUUL3TxHKUxf7XMwAj126du4W59grMqpmxfpJOh5+fZSmIPFunhXjIMP55h5rIPccwcKhwQg0sOlbTYenTQA5oQOFAjNpny9nE7KarOIsa5oaEhi++16ICU5A4FL47P3d3wzHaZzCDBUmnwV28qFBugcmlQ== X-Forefront-PRVS: 0238AEEDB0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39860400002)(39450400003)(39410400002)(39850400002)(39840400002)(8676002)(7736002)(117156001)(36756003)(5660300001)(230783001)(50986999)(33646002)(76176999)(53936002)(450100001)(92566002)(81166006)(42186005)(54356999)(2351001)(189998001)(25786008)(4001350100001)(47776003)(31696002)(2870700001)(6666003)(83506001)(229853002)(6486002)(2473003)(110136004)(6306002)(305945005)(2950100002)(38730400002)(86362001)(50466002)(65956001)(6116002)(77096006)(65806001)(66066001)(6916009)(3846002)(23746002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2480; H:[192.168.1.5]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR0701MB2480; 23:gpVctUNNlv7xGb0YwhBcWy+MLBQEHRd7sn6?= =?Windows-1252?Q?YIbvMvhPHUzmMZQwwIHk00K+Rn+HmFwLSOYpJr4mKOgRsSo350f7cz8N?= =?Windows-1252?Q?dr+WlmyoyvSgd8pxvwB+y+iKN0Vs9zE4np2b/4X4KWtMgUKrbs/xx271?= =?Windows-1252?Q?0NpBM+ij+QhP/5LctMMYjXvRBTlNIW3ovXZzxkpt5Dfbl4+qXKZA6vou?= =?Windows-1252?Q?KhLEy1yYey58L6reP6Xajheev0/qHAEgzE3h2TIyp63V6da82j2YWuQL?= =?Windows-1252?Q?J7t9dD3n+UagmehHUuAooGWqfNu4GJ3jgvBGm9LIVM+wZsRHA1pT3ymi?= =?Windows-1252?Q?Lym/xNPxqcZg60lK7M2MXko0Q2VWcFzs92iM2CRT+T6ViiKUj8hEBPFC?= =?Windows-1252?Q?hGTpRdTq8eeeE736tvcPsV26yOdYScugiGgg+qpAotIL/r8ZxmWzjhhI?= =?Windows-1252?Q?aUmJaUMo/pi6bEk2iO3ILz8jcc1cm72cq3amPmC5699u4VmSootSQ9zA?= =?Windows-1252?Q?TfiK3uEcRUZM7hybCSX1VJnE5pUvvHd499wPV5Abzqm9L29MmLqXBoGk?= =?Windows-1252?Q?71st7rKSepG2vk6duh9Pz1UBLWgsJwe8yFqD6supl76ccjvgxaD51SIW?= =?Windows-1252?Q?cVGXDEcWBqwqzzYDeRrlHQPBhoerEGPZ+8g47KEorJVmc7riS6A/q2IA?= =?Windows-1252?Q?S+4wiPfo7TiFGgSw6qYnHUxDF73ghNm+5mZFLsWOP6WBHHPF6ijAusMS?= =?Windows-1252?Q?ERxMdr4gV0QCLSyzwetz4sEfXax8GWuh0l56TfBkCt2q0B2rx6nvzpxy?= =?Windows-1252?Q?4Q+kchgyY8W18peE/dzIKxJKK8G5tRH0U9MQLCGHqjxzDN3p0BsUDOgU?= =?Windows-1252?Q?gkgz96sHk5x1FbholqjYpms7yUQmXjGckUH/l3W+RmzTpUO22jE4+ep6?= =?Windows-1252?Q?taN8c9tPVyz3NZJqgBBFz3KfZIwdHKafDcGHsL59N97ZHD1EsU40AT3G?= =?Windows-1252?Q?CXsUjoaCVyAF33TEyKrz4BwZPV+Zrx+cODP4s3rjI7Uzh2hdxzz4Voj0?= =?Windows-1252?Q?RdQgx0OC5xBWOngaYWXY26LbRsrUbETyxYSo/LE6ikA68q3q0blDCZ6F?= =?Windows-1252?Q?8Tl7vi3bVJPGNGh7WQHn0WH5jgY5n+1LFz1j2IxhjpX8nX1hr9ax+/U2?= =?Windows-1252?Q?u5fdTbW3V/j7Jt5y0Dl0GbuOxXr1O/uUzCvaqlWNvJeeCoeOV7cM+WVD?= =?Windows-1252?Q?IdXA8rG5H/0sTWfYY9X3M2BrDqYxeTOsqgrnT3iOkTBmCPcS3zE6rgMI?= =?Windows-1252?Q?fDFF1qJ1A2nFlUJIZnSx6quYkDJkhA+hAW0BXZ9gJT4t9XA4xx0K8511?= =?Windows-1252?Q?7KRwZTfkskzr0f5vhGLSCveMMhLkcBrx7ew=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2480; 6:r9uPyrqv+MikPd4yAF+rKroVyiL7JEYgcoKS4PlmonfkkVVqZ76cmJd8iQBT84N1QRbYdCnKOrR5O5NbJ7G6tn9jn1iFikfLw93M0Dq6xN6zyaawQltg0W9Nc7/Gs6hfZjJUnxDZjlnER7rKIQKxpcuio2FN2G3fV3V97LVo3x4gCZufFUUd9/gwMfmaN9y4FHKT0J65SbbXX6TOSitp0ZcjllRaqMzSmfamnrRCAp9etQbmHiGvQ4TgsEr/4ecerWRi6vLg0G94aKeFfHXTzi8+zh8vpgg7VzLjpcJMSM36i5PjwOZkuWJ4AN/j2LnhQHDHqow6VEPE5Gy+KRMV2T2ZF70JwusRjIQubgslX5gKq+9BgSflckDt1ZCieDuXXkymqNaNqo1pwut2fKEJprJ5HCAWogz5fWdUhb6/QLM=; 5:8n+3h+HGS5NFg54SpyDyotTCgcDTlAYFHO6I2CNG62LSYJmTsAZ5aXWGraXmyx2MKc5RFTf1+bufAByo05KuinZb6Mf3K3/0rrwOt6yZfKOSUkXm+mYdUBXFDIUef11Y+fMV8NQPCw74m2B/zgLVfQ3wOswdaesresJ8jHrKhRs=; 24:YcE5Vxf8zjst6JCN54sflWI7aHd+5O4KjkKNqWPOS82YZnSZr6/Cc5Hj383b8OKU0kzO/4WcOZh0PgWsvZBg/Q3PeQhUlOSh0KPPO65EYhY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2480; 7:bCipERwRAOsAtokcbzLLZi2EnJmZq+Fm0LzvSJYTO+fcPsA93yzJr05gal+eAT1P4QSwnHYOV1MdOzOC36GgzvFbE9X9ixlHQT8wn3gzoZ9PRYDD1l258DHxHEBeWWAxl6Y38+2+oLekKdUqJKCMmWoSqxwkBF1F9V9NOUD+eXJQx+5qfPh8LrdZ8rGMkHF8etMI/pgcZCmQ42fzyZb8iBZiG1UqYPWalK0kwqdwfcGXav+kcOVkgbJNUkxyREdudXzCt34yChCW+oD1usjjNCZ/W+O8grGs0nGgM4vBlvK55GLeXyvw4G18oON/F/YpzGMfxORnYgmWm+eK1OaNRQ== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2017 11:57:45.5188 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2480 Archived-At: Subject: [sfc] Fwd: [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 11:57:49 -0000 Hello, please be aware of this call for adoption that we have just started in BESS. To the extent possible please express your support/opposition/comments on the BESS WG mailing list. Thank you -m -------- Message transféré -------- Sujet : [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane Date : Mon, 6 Mar 2017 12:55:28 +0100 De : Martin Vigoureux Pour : bess@ietf.org Copie à : draft-mackie-bess-nsh-bgp-control-plane@ietf.org Hello working group, This email starts a two-week call for adoption on draft-mackie-bess-nsh-bgp-control-plane-04 [1] as a Working Group Document. Please state on the list if you support the adoption or not (in both cases, please also state the reasons). This poll runs until *the 19th of March*. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an Author or Contributor of this Document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors. IPR has been disclosed against this Document [2]. If you are not listed as an Author or Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thank you Martin & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-mackie-bess-nsh-bgp-control-plane _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Tue Mar 7 08:22:05 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E01129503 for ; Tue, 7 Mar 2017 08:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5844_BHq9OB for ; Tue, 7 Mar 2017 08:18:39 -0800 (PST) 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 465901294E4 for ; Tue, 7 Mar 2017 08:18:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIL74995; Tue, 07 Mar 2017 16:18:31 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Mar 2017 16:18:31 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Tue, 7 Mar 2017 08:18:18 -0800 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: Call for Chicago SFC WG Agenda Topics Thread-Index: AdKXXRzYmrhE9WwQR+OO/e1IlwwePg== Date: Tue, 7 Mar 2017 16:18:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.11] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DBEF8FSJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58BEDD58.0243, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d260f65644d07494fbca56a3ab16783f Archived-At: Subject: [sfc] Call for Chicago SFC WG Agenda Topics X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:18:41 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DBEF8FSJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings WG: Our meeting in Chicago is fast approaching. As always the goal of the meeti= ng will be to make the best use of our F2F time. With that in mind we welco= me requests for agenda time. As we construct the meeting agenda our focus will be on selecting presentat= ions that best further the work of the WG, and this generally means focusin= g on key charter deliverables and topics with important open issues to reso= lve. When requesting agenda time please consider what you think the WG shou= ld do with its content, for example: - Does the document/presentation have useful content that should b= e moved into an existing WG document or progress on its own merit - Does the content have a good basis for one of the WG documents p= er the charter - Should the document content be merged with one or more other doc= uments so that a combined document could become a WG document ** Please send your agenda slot request to the SFC WG chairs before March 2= 1st, 9am EST ** The request must include the name of the draft or topic to be presented, ti= me for the presentation requested, and the presenter. Thanks! Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DBEF8FSJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings WG:

 

Our meeting in Chicago is fast approaching. As alway= s the goal of the meeting will be to make the best use of our F2F time. Wit= h that in mind we welcome requests for agenda time.

 

As we construct the meeting agenda our focus will be= on selecting presentations that best further the work of the WG, and this = generally means focusing on key charter deliverables and topics with import= ant open issues to resolve. When requesting agenda time please consider what you think the WG should do with its conte= nt, for example:

 

-     &= nbsp;    Does the document/presentation have useful content = that should be moved into an existing WG document or progress on its own me= rit

-     &= nbsp;    Does the content have a good basis for one of the W= G documents per the charter

-     &= nbsp;    Should the document content be merged with one or m= ore other documents so that a combined document could become a WG document<= o:p>

 

** Please send your agenda slot request to the SFC W= G chairs before March 21st, 9am EST **

 

The request must include the name of the draft or to= pic to be presented, time for the presentation requested, and the presenter= .

 

Thanks!

 

Jim & Joel

 

 

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DBEF8FSJCEML701CHMchina_-- From nobody Thu Mar 9 07:58:38 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AE0129407 for ; Thu, 9 Mar 2017 07:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 HpCL1y6NjWFT for ; Thu, 9 Mar 2017 07:58:30 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 DF779129496 for ; Thu, 9 Mar 2017 07:58:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C586C663FC9 for ; Thu, 9 Mar 2017 07:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1489075110; bh=sVl1L2GY72XuT63goCb5D7k5k0px2JrL1Qrx/TdnNX4=; h=To:From:Subject:Date:From; b=Di8SrLw4V6rp0ZuQlwoEyNmT3aLi/j1BfXbpt1pPz1cKDI7xym6jZ6NOSS9+9uJNc VrUPAG5cPpm3EehK1I0WTXE8wtZTB/G4pYOm+rwxFG58DRW9kINlbdwydVINpqrWZK 1IklRq6e+ZL1jcu91p1CKWggR+UnG9zBkTCG69fA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6F2B01C0381 for ; Thu, 9 Mar 2017 07:58:30 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: <32c75352-2a8c-cd16-dc01-983042ac5c1f@joelhalpern.com> Date: Thu, 9 Mar 2017 10:58:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Meeting planning for Chicago X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:58:37 -0000 We have gotten a few requests for time for the meeting. If you have something you think it would help the working group for you to present, please let us know. More importantly, after talking with Alia, we would like to use part of the time in Chicago(1/2?) for small group discussions. The idea would be to describe the topics, and break into groups of people interested in discussing / brainstorm / working quickly on those topics. To do so, we need topics. Rather than the chairs spelling out the topics, we are asking you. What topics do you think would benefit from discussion by a small teams of interested people? Thank you, Joel and Jim From nobody Fri Mar 10 17:09:09 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68059129459 for ; Fri, 10 Mar 2017 17:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8IGneJRkLxY for ; Fri, 10 Mar 2017 17:09:05 -0800 (PST) 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 10330129495 for ; Fri, 10 Mar 2017 17:09:04 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIR07778; Sat, 11 Mar 2017 01:09:02 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 11 Mar 2017 01:09:01 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Fri, 10 Mar 2017 17:08:48 -0800 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ Thread-Index: AdKaAvtNNSWYw7aaSNm4qBBsSJ7p6w== Date: Sat, 11 Mar 2017 01:08:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.213] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC0171SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.58C34E2E.00BD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3c2cb0947ee1f6ae0f398430807f4675 Archived-At: Subject: [sfc] Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 01:09:07 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC0171SJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings WG, This message begins a two week call for WG adoption of the document https:/= /datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ ending 24th March 2017. Please respond to the SFC mailing list with any statements of approval or d= isapproval. Please note: 1. This is not WG last call. The document is not final and the WG is= expected to modify the content until there is WG consensus that the conten= t is solid. Therefore, please don't oppose adoption just because you want t= o see changes to its content. 2. If you have objections to adoption of the document, please state = your reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those iss= ues and we can begin a dialog about how best to address them. Yours, Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC0171SJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings WG,

 

This message begins a two week call for WG adoption = of the document https://datatracker.ietf.org/doc/draft-kumar-sfc-= offloads/ ending 24th March 2017.

 

Please respond to the SFC mailing list with any stat= ements of approval or disapproval.

 

Please note:

 

1.     &= nbsp;  This is not WG last call. The document is no= t final and the WG is expected to modify the content until there is WG cons= ensus that the content is solid. Therefore, please don’t oppose adopt= ion just because you want to see changes to its content.

2.     &= nbsp;  If you have objections to adoption of the do= cument, please state your reasons why, and explain what it would take to ad= dress your concerns.

3.     &= nbsp;  If you have issues with the content, by all = means raise those issues and we can begin a dialog about how best to addres= s them.

 

Yours,

 

Jim & Joel

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC0171SJCEML701CHMchina_-- From nobody Fri Mar 10 18:22:09 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B57812950E; Fri, 10 Mar 2017 18:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.19 X-Spam-Level: * X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=0.001, RCVD_IN_XBL=0.375, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO8waCd6ResP; Fri, 10 Mar 2017 18:21:55 -0800 (PST) Received: from uocyb.mail.ru (24-205-251-42.static.snlo.ca.charter.com [24.205.251.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCA0129569; Fri, 10 Mar 2017 18:21:35 -0800 (PST) From: "bensons" To: agenda@ietf.org, "wgchairs-bounces" , "draft-ghanwani-nvo3-mcast-framework" , "IETF-Draft Submission Queue via RT" , "sfc" , "pcn" , "secdir" Date: Fri, 10 Mar 2017 22:20:52 -0400 Message-ID: <1117415111.20170311052052@queuefull.net> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01488FA7.1DE13791" Content-Language: en MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] =?utf-8?q?crazy!?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 02:22:00 -0000 ------=_NextPart_000_0007_01488FA7.1DE13791 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IGZyaWVuZCwgDQoNCg0KSSd2ZSBqdXN0IHNlZW4gc29tZXRoaW5nIHJlYWxseSBjcmF6eSwg anVzdCB0YWtlIGEgIGxvb2sgIGF0IHRoYXQsIHlvdSdyZSBnb2luZyB0byBiZSBzdXJwcmlzZWQg IGh0dHA6Ly9mb2xsb3cuYmV0dGVyYmx1bnQuY29tLzQ4NDkNCg0KV2lzaGVzLCBiZW5zb25zDQoN Cg== ------=_NextPart_000_0007_01488FA7.1DE13791 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hey friend,

 

 

I've just seen something really crazy, just take a look at that, y= ou're going to be surprised message

 

Wishes, bensons

------=_NextPart_000_0007_01488FA7.1DE13791-- From nobody Sat Mar 11 06:18:11 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05016129501 for ; Sat, 11 Mar 2017 06:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[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 jmpG3ohCswpc for ; Sat, 11 Mar 2017 06:18:09 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2007129461 for ; Sat, 11 Mar 2017 06:18:08 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id 126so62705415oig.3 for ; Sat, 11 Mar 2017 06:18:08 -0800 (PST) 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=Y6INivuuSkW4XvnCbBCWa2Ix6x3P70QCrYIt4A1FDo4=; b=IsUW+L0t6zYfO70zbAwyV0bmmSImMX/UYty1gPlpv+aYHdZhTV1t17uez3Ku3K0+N0 EYeQfBZ+MJ1MKmWbfTBgO2X/X7vcovfiK+JEvHw4Gu3shNJEQxYeqbxfsearUJA9hFXB X3ZZDzWchP64mdAXVFr6W/uRaKUuSuNqjphEECAK9+2R6U0Midu1hRJj5pOswexxZ2OU uDatHilh/LDh5VrxGQpG79wWgLniXj5fY0DvCRi2bDXh5jdLIfIrAZUc5pQSvHhk1WL8 SJT3lFBSfxEoo0sFJ4X+NQoHTjUw8A4YQy3qbdu5Nbqg4l1D2ISqulkmrPISZn3Mk+hl DXHA== 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=Y6INivuuSkW4XvnCbBCWa2Ix6x3P70QCrYIt4A1FDo4=; b=cS6MTj4ZHJRcvp34wXvpo6DY1BXtIotU4z71dwBY/4dfNKhOx/bH7+PEWztUJ54jrv XEaJ62nVoKC76yAvJ8N5YRa9J6EUK0VO7/VFZqsyZVI+8ewaXh6Q03IlfVRlYTwLCaGi dQ/iqsxTJ+XmkADI9WwS1+LsV79AwHUeo5rBM+TQSFR9DNiCdvDYiBwGPK0x86oeHrIT iNDm/eWCUTvBJ1OhzAdH2qj4OWpjZJXmhJzfoijx5jb1UfoaX54H90+99bZ4fsiQR6Ov kQvJ46GHRpC+AOll8krRhZ02HGLOOPjE0+5W+5uGFTmpDx6LSU5DV2UG/nJ5rXV7hjp6 PSVQ== X-Gm-Message-State: AMke39lU8pqaemN58Quq7YyWRyPAEE+wakS2SB6Vagumb31OUv3SimBirV8HUqHoWwDfgHZJG+YZ+WN2UlebOg== X-Received: by 10.202.183.138 with SMTP id h132mr11101252oif.95.1489241888283; Sat, 11 Mar 2017 06:18:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.85.229 with HTTP; Sat, 11 Mar 2017 06:17:47 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Sat, 11 Mar 2017 09:17:47 -0500 Message-ID: To: James N Guichard Content-Type: multipart/alternative; boundary=001a113ce1eebc63a1054a7525de Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 14:18:10 -0000 --001a113ce1eebc63a1054a7525de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support WG adoption of this draft. It looks very useful. Cheers, Andy On Fri, Mar 10, 2017 at 8:08 PM, James N Guichard < james.n.guichard@huawei.com> wrote: > Greetings WG, > > > > This message begins a two week call for WG adoption of the document > https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ ending 24th > March 2017. > > > > Please respond to the SFC mailing list with any statements of approval or > disapproval. > > > > Please note: > > > > 1. This is not WG last call. The document is not final and the WG > is expected to modify the content until there is WG consensus that the > content is solid. Therefore, please don=E2=80=99t oppose adoption just be= cause you > want to see changes to its content. > > 2. If you have objections to adoption of the document, please > state your reasons why, and explain what it would take to address your > concerns. > > 3. If you have issues with the content, by all means raise those > issues and we can begin a dialog about how best to address them. > > > > Yours, > > > > Jim & Joel > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --001a113ce1eebc63a1054a7525de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support WG adoption of this draft. It looks very useful.=

Cheers,
Andy


On Fri, Mar 10, 2017 at= 8:08 PM, James N Guichard <james.n.guichard@huawei.com><= /span> wrote:

Greetings WG,

=C2=A0

This message begins a two week call for WG adoption = of the document https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ ending 24th March 20= 17.

=C2=A0

Please respond to the SFC mailing list with any stat= ements of approval or disapproval.

=C2=A0

Please note:

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 This is not WG last call. The document is not f= inal and the WG is expected to modify the content until there is WG consens= us that the content is solid. Therefore, please don=E2=80=99t oppose adopti= on just because you want to see changes to its content.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 If you have objections to adoption of the docum= ent, please state your reasons why, and explain what it would take to addre= ss your concerns.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 If you have issues with the content, by all mea= ns raise those issues and we can begin a dialog about how best to address t= hem.

=C2=A0

Yours,

=C2=A0

Jim & Joel

=C2=A0

=C2=A0


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


--001a113ce1eebc63a1054a7525de-- From nobody Sat Mar 11 15:34:43 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAEB12966A for ; Sat, 11 Mar 2017 15:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 XYWVxJlyqIh6 for ; Sat, 11 Mar 2017 15:34:40 -0800 (PST) Received: from nm3-vm1.bullet.mail.ne1.yahoo.com (nm3-vm1.bullet.mail.ne1.yahoo.com [98.138.91.53]) (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 BAF56129666 for ; Sat, 11 Mar 2017 15:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1489275280; bh=CZq1PZKkDim6H2YFjV0hnep4YgTviknWCZxHLwkO7Y4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=B+lo0q6DIDB8EBxs2S20UUOiNVBI8UhNTLvaOeV2t5l6pppM1np8II9I3jFsg+gwobtke4FHLk9LXJrlpBEgBLt/iBcQPWVPbzsXvc4O1BSEPlO9yEBijjojumCHkzu7/hiT6Ju/Zett5HmKf5Mjh+5UwG/azP98n5318d9IGt+XXC+q9Zx8VLGdLxlvwtQvteItf5W/SCQni45Rohigwmie2V2n3w54X1Yl6PRNa/wFnGsH0dlpzO0DnL8Q85gh9RBCJyUDhaCQFsBWUySGJDejXoKBQnXqz889PBGazbKJjnPMFEIe8TIdClsniM8nM+DJbkMRiz4iyGRCj4Z13g== Received: from [98.138.101.132] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 11 Mar 2017 23:34:40 -0000 Received: from [98.138.104.112] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 11 Mar 2017 23:34:40 -0000 Received: from [127.0.0.1] by smtp221.mail.ne1.yahoo.com with NNFMP; 11 Mar 2017 23:34:40 -0000 X-Yahoo-Newman-Id: 91790.71024.bm@smtp221.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cFjiOcAVM1ktSlHF.o78h0ncFapLhpSx97cRrinTP51V_dj 280EXsYB8lBrvFyxPzb9q9B8dfwtlBmx3qR.Bbs6rI3bUQRvnZHDBsEowBhn vPgRFZ4o_w_aWLZjqUyQ2Psta1pvTh_8r13AOnSIT3BQOpyrylDuIYO0l62z adLVCh8GseGYJVNuUtzvsmVr80tPlL3bLHooNRlwVLrtR_LduSQAI6OyjwDE vwsizJC41b8kkorg7Bt8KOe6GP0aqtEe8WS5RLgt3.PZJrn05g49LTkeetgm lbKmUcghce6J5WqztiPJ8F_0m5LSbfFvszAUx8Oq2APaAGxsVE47c78bPoP. RMwuY8rXpKY_pzRPQuCR8tAjDY6mPYBWBwdWKTybZIg3KF1GHPJT.NgtXi4S ldzoHC4R.LFLiZXl0fqoUyWhcgG6Lm3ggI8PSsz5ITM3e9Z.m6YilRAVJNgb V_OPpeHct2B8hq6K59upJc.v8AymcXlDGy4pPID6ISmYzwO3mD1FLEM2JjpG 6NJYVunWqSbncLJVBHgZXdp9iq3q6jF6gFU8Xpt.zXWzSX72Mc_0ekYmBZiC VpZ1QsW5vWg-- X-Yahoo-SMTP: fs7iLCSswBBDBLcI2rgu6.1JrA-- Content-Type: multipart/alternative; boundary=Apple-Mail-CF512EB5-5A38-4287-B462-FC2D6CAC84AD Mime-Version: 1.0 (1.0) From: Sumandra Majee X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Sat, 11 Mar 2017 15:34:38 -0800 Content-Transfer-Encoding: 7bit Message-Id: <2A405A44-45F4-48BB-BA3B-8B05975ED800@yahoo.com> References: To: James N Guichard Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 23:34:42 -0000 --Apple-Mail-CF512EB5-5A38-4287-B462-FC2D6CAC84AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Support=20 Sent from my iPhone > On Mar 10, 2017, at 5:08 PM, James N Guichard wrote: >=20 > Greetings WG, > =20 > This message begins a two week call for WG adoption of the document https:= //datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ ending 24th March 2017.= > =20 > Please respond to the SFC mailing list with any statements of approval or d= isapproval. > =20 > Please note: > =20 > 1. This is not WG last call. The document is not final and the WG i= s expected to modify the content until there is WG consensus that the conten= t is solid. Therefore, please don=E2=80=99t oppose adoption just because you= want to see changes to its content. > 2. If you have objections to adoption of the document, please state= your reasons why, and explain what it would take to address your concerns. > 3. If you have issues with the content, by all means raise those is= sues and we can begin a dialog about how best to address them. > =20 > Yours, > =20 > Jim & Joel > =20 > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-CF512EB5-5A38-4287-B462-FC2D6CAC84AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Support 

Sent from my iPho= ne

On Mar 10, 2017, at 5:08 PM, James N Guichard <james.n.guichard@huawei.com> wro= te:

=

Greetings WG,

 

This message begins a two week call for WG adoption o= f the document https://datatracker.ietf.org/doc/draft-kumar-sfc-of= floads/ ending 24th March 2017.

 

Please respond to the SFC mailing list with any state= ments of approval or disapproval.

 

Please note:

 

1.     &= nbsp;  This is not WG last call. The document is= not final and the WG is expected to modify the content until there is WG co= nsensus that the content is solid. Therefore, please don=E2=80=99t oppose ad= option just because you want to see changes to its content.

2.     &= nbsp;  If you have objections to adoption of the= document, please state your reasons why, and explain what it would take to a= ddress your concerns.

3.     &= nbsp;  If you have issues with the content, by a= ll means raise those issues and we can begin a dialog about how best to addr= ess them.

 

Yours,

 

Jim & Joel

 

 

____________________= ___________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/lis= tinfo/sfc
= --Apple-Mail-CF512EB5-5A38-4287-B462-FC2D6CAC84AD-- From nobody Mon Mar 13 09:26:20 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8678E129411 for ; Mon, 13 Mar 2017 09:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 LCd58EYJhZeJ for ; Mon, 13 Mar 2017 09:26:17 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 9E31C1293E9 for ; Mon, 13 Mar 2017 09:26:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 87D757C19B9 for ; Mon, 13 Mar 2017 09:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1489422373; bh=IvXmUirtPK+mdMYXPSBT+zvknvLZltYB9bXoy5EaBPc=; h=To:From:Subject:Date:From; b=CwST4RTfhcBv5jnc6gDgfBS1A4YQjGkra2O6OP24neMWgV0OvFAOdMbyJhFCVeyKT ngnvuhN1bF8hq20yC0thY03xk0T5BefTs2yZFP8CU/KpVrv5gUj9vyWSIZJ50GX5Sw LnyfcDq3kg8g9J/zEXyePgMkIYzGInzqcVfAiPBo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 32A597C19B8 for ; Mon, 13 Mar 2017 09:26:13 -0700 (PDT) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Mon, 13 Mar 2017 12:26:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Chicago Meeting planning X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:26:18 -0000 1) We need a minute taker. I know some folks had volunteered earlier. if you are still willing, or if someone else is willing, please speak up. 2) We need to know if there are more agenda items people would like us to include. 3) If there are ideas forsmall group discusions, please tell the list about those ideas. Thank you, Joel From nobody Mon Mar 13 17:19:29 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADCD12964F for ; Mon, 13 Mar 2017 17:19:26 -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 FjUb83wHkDgX for ; Mon, 13 Mar 2017 17:19:25 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772DE129562 for ; Mon, 13 Mar 2017 17:19:25 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id 126so85738478oig.3 for ; Mon, 13 Mar 2017 17:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HPjzIcqnHE+/qFce1H72q792EmesuLMLnzANXx1j/4o=; b=EO7EZZyEgj7xLiXzMgSqjmF75/zLplKNA06Rdb7j2j4uogRGLngdTbmaumTiY+eni5 Ia2ESxFYPIQY769HfMezO4DVvI0z9bJX4kTMPbitqJXGOiINiH7gkfgmmHKKPI7qiSvH g6sjUA2K4V158or5nnlg8cOm7zlIiw1JXzEP07kvEm+n0V25twQEw9RZw/lrnfeViUNK MIUqrZn/RLCUP9l71OQYJOor6ShNM8Feho2ks8Woyc5qdo+zvL9tCcBpcHcWFbe2Z2QO yOPPmweJy6mcJRtMklyCt3q599RJ1FnPtGdnXPx2A6zcuzyE4PL4bvgM/ZmD9vC3fut6 uang== 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=HPjzIcqnHE+/qFce1H72q792EmesuLMLnzANXx1j/4o=; b=TW26OLaY12mwVIuYtVhmCuvbf79jKqzXeVXc+rLOjocjFy8cEWX1b3CYLaNdE/kLzw +cY7sW7qu6xQJeKh+lmu6KBiorvUWx0/W1AqTK7WvOOpXkmd1q04hxKhYR9ajewx2kH3 IWFsaW6+ghEbsYZMqFk3tOJCLDsGB5r4g5uoV1U6LFJIlPSWRyQ1D62G5WKavdXOAj7A oWn6200TVUR2d/Dp8p37cO2RWxw9f8e1u6lo4BAFjoYHF2W36MY5BuCSRpRgU1S9Kxrb WEsmd+6usA/ctIdEubTiebd/eqH3AleExCc+lEJYbt9bYaAu/8VnHWq4hvaW2xXNw+jR gM6w== X-Gm-Message-State: AMke39ntUGOsA4trGe6AbTFBzp0UQ8fmaDae/kQ44Ckua+qBSxCJd3oFoP2mnSCS62fMknQbcPcPCC3aPgtxhA== X-Received: by 10.202.181.135 with SMTP id e129mr19290695oif.124.1489450764760; Mon, 13 Mar 2017 17:19:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Mon, 13 Mar 2017 17:19:24 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Mon, 13 Mar 2017 17:19:24 -0700 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113cbe4cbe7dbd054aa5c741 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Chicago Meeting planning X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 00:19:27 -0000 --001a113cbe4cbe7dbd054aa5c741 Content-Type: text/plain; charset=UTF-8 Hi Joel, would appreciate the opportunty to give the update to SFC WG on: - OAM Header for use in Overlay Networks draft-ooamdt-rtgwg-ooam-header - Echo Request and Echo Reply for Overlay Networks draft-ooamdt-rtgwg-demand-cc-cv It should be 20 min for both and I'll send slides next week. Regards, Greg On Mon, Mar 13, 2017 at 9:26 AM, Joel M. Halpern wrote: > 1) We need a minute taker. I know some folks had volunteered earlier. if > you are still willing, or if someone else is willing, please speak up. > > 2) We need to know if there are more agenda items people would like us to > include. > > 3) If there are ideas forsmall group discusions, please tell the list > about those ideas. > > Thank you, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a113cbe4cbe7dbd054aa5c741 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,
would appreciate the opportunty to give the u= pdate to SFC WG on:
  • OAM Header for use in Overlay Network= s=C2=A0draft-ooamdt-rtgwg-ooam-header
  • Echo Request and Echo Rep= ly for Overlay Networks=C2=A0draft-ooamdt-rtgwg-demand-cc-cv
It sh= ould be 20 min for both and I'll send slides next week.

<= /div>
Regards,
Greg
On Mon, Mar 13, 2017 at 9:26 AM, Joel M. Halper= n <jmh@joelhalpern.com> wrote:
1) We need a minute taker.=C2=A0 I know some folks had volunteered e= arlier. if you are still willing, or if someone else is willing, please spe= ak up.

2) We need to know if there are more agenda items people would like us to i= nclude.

3) If there are ideas forsmall group discusions, please tell the list about= those ideas.

Thank you,
Joel

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

--001a113cbe4cbe7dbd054aa5c741-- From nobody Tue Mar 14 11:30:34 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697F91279E8 for ; Tue, 14 Mar 2017 11:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 a0W-FwGEzgJH for ; Tue, 14 Mar 2017 11:30:31 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 2766B126B72 for ; Tue, 14 Mar 2017 11:30:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 0CE1ED5DD0D for ; Tue, 14 Mar 2017 11:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1489516231; bh=pomZO58ZUu8DyrAx6w2Utv8tnt8Lpp5/7X+aV+4hFi0=; h=To:From:Subject:Date:From; b=A1IXx75ShzQgvufR6QLhp7gcBMDa0IPbPHdBMncq+MxV3diaf+qUjoykdXkL3oNc1 5qQozYanF6tLVOpt6LMmwTol52cf4mR/RUS5dWyp4lUfycXq5cT4t9KLdXP52xf/Y5 ciZRyRLVlX3A2aOqhd+0N/nFDMYJpvgFX8k4Aa3w= X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id AA5C2D5DCDE for ; Tue, 14 Mar 2017 11:30:30 -0700 (PDT) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Tue, 14 Mar 2017 14:30:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] WG Last call - Hierarchical SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:30:32 -0000 This is a last call for: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 Please respond to the list as to whether you see problems with this, you think it is done, or any other input for the WG. Due to the run up to the IETF, we will let this run until April 7. Yours, Joel & Jim From nobody Tue Mar 14 11:47:08 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB639128CD5 for ; Tue, 14 Mar 2017 11:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBp5K4cfMdoo for ; Tue, 14 Mar 2017 11:47:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0FA1289C3 for ; Tue, 14 Mar 2017 11:47:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIW40477; Tue, 14 Mar 2017 18:47:01 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Mar 2017 18:47:00 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Tue, 14 Mar 2017 11:46:47 -0700 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: Removal of C-bit from https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ Thread-Index: AdKc8bbl7fEE8hXMRQSDzIo3NWGcyw== Date: Tue, 14 Mar 2017 18:46:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.218] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC1155SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.58C83AA6.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e073dabbfe8dc793c0f61f2f44ad7280 Archived-At: Subject: [sfc] Removal of C-bit from https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 18:47:07 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC1155SJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG, Having reviewed the WG mailing list comments for removal of the C-bit from = the NSH document (both the base header and optional TLVs), the chairs feel = comfortable calling WG consensus for this change. NSH document editors, please remove any reference to the C-bit from https:/= /datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ and post a new revision when = able. Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC1155SJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG,

 

Having reviewed the WG mailing list comments for rem= oval of the C-bit from the NSH document (both the base header and optional = TLVs), the chairs feel comfortable calling WG consensus for this change.

 

NSH document editors, please remove any reference to= the C-bit from https://da= tatracker.ietf.org/doc/draft-ietf-sfc-nsh/ and post a new revision when= able.

 

Jim & Joel

 

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC1155SJCEML701CHMchina_-- From nobody Tue Mar 14 12:43:31 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933A2129A9D for ; Tue, 14 Mar 2017 12:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 T3dA8zChiwPV for ; Tue, 14 Mar 2017 12:43:26 -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 43A21129A72 for ; Tue, 14 Mar 2017 12:43:04 -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 v2EJh1B8024028; Tue, 14 Mar 2017 19:43:01 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2EJgufh023949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Mar 2017 19:43:01 GMT Reply-To: From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: In-Reply-To: Date: Tue, 14 Mar 2017 19:42:58 -0000 Message-ID: <056c01d29cfb$3275c8f0$97615ad0$@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: AQEofRGfDIay+LW5FAE2aWoNuD+K+qLo+8NA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22942.001 X-TM-AS-Result: No--8.667-10.0-31-10 X-imss-scan-details: No--8.667-10.0-31-10 X-TMASE-MatchedRID: H0/uSqZo4D5fsB4HYR80Zp21GZGE81yG+pkYmVlzZ8uKvtIv3yXJCfkU my1Y1jH8mJwWfVMno2LmVl4D8eu/xAcSBA/LYDihsyNb+yeIRAoZMrfQmeij5Qzvg1/q1MH2Wq8 3kQ8NcpAPWUkB5Hp/uWsVIHEKo/MpJtllgBC70fm7vYqkCS0dLzFFLhGUD8AWnSPw4pGdVDyRZ+ gzTRpU1W/s2eocV1AZATCK3iz0XmW1UAN2vPuTMhes/RxhysDbQa2sDHLkQ07sUpOz15WOuMNUZ qLXyeOu1OXJbkTuIUDQShZCC3qtX/B0BomJXTnpf598+KnsMOg4gG1vqBBN+K/FMdJb10vOZ5pY gzoki0OqxScIF8+D9uomZxSR0RE+g1bTfeKwz7DPmshbRFtLmFK6+0HOVoSoV6KWY8jugmWRpyv nn7VRvzpObK2FRWL14xfvBf6ttd/LIr1irshncjDfgfM3Zc/R7+pIlQkyFUqen0qBdy7fjEMn3S PMGgugPdJs51vPe8l+AmSEJ+YYOdcUNjoF7YuVy18e5+drKgYbTwzYj2zQut2VQFX+cuxS5YcOu ccmINGAtLwzDtz37HhN6S2cQldPYAmall7++5RHFWsq1vzd1H0tCKdnhB58vqq8s2MNhPB9j2Gw zTE3vSq2rl3dzGQ1Y7IgXGzIUjRo7PI2iLDVlgU7GFPFBEpm13t8o06KH70aDfyusftuAw== Archived-At: Subject: Re: [sfc] WG Last call - Hierarchical SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 19:43:30 -0000 All, I'm not very excited by hSFC. So far we haven't been able to come up with examples of very long chains and while they may one day be found it seems premature to do work on hSFC. I do agree that the use cases shown can be solved with hSFC, but I also don't see use cases as insoluble using other approaches. So please take this as a "publish it if you must" level of support :-) But anyway, here are a few comments from reading the latest revision. Cheers, Adrian Seven authors will probably give the AD heartburn. --- I'm surprised to see this last called when it has normative references to one document that the still needs work before it can go to a second WG last call, and another document that the WG is debating abandoning. --- The introduction contains the reasonable note... Note: in this document, the notion of the "path" of a packet is the series of SF instances traversed by a packet. The means of delivering packets between SFs (i.e., the forwarding mechanisms enforced in the underlying network) are not relevant to the discussion. Why, then, does the document go on to discuss SFFs? --- We were explicitly told in the WG that an SFF cannot make assumptions based on the transport tunnel used to deliver a packet to the SFF. 3.1.1 seems to be counter to this. I would be happy to hear that 3.1.1 is a valid approach, but if so then the WG needs to agree that an SFF *can* make determinations based on the transport tunnel. In particular, it can tell whether a packet has arrived from another SFF, from an SF, or from a classifier. --- It is all very well for section 3.1 to describe 5 perfectly achievable approaches to hSFC, but in order to achieve interop, the head and tail ends of a lower layer SFC need to use the same mechanism. That means that the mechanism either has to be determined through the control plane or exposed by examination of the data plane. Furthermore, the implication is that all implementations have to support all five mechanisms. Saying that this document "sets expectations for control planes" is all very well, but by keeping so many options and punting on the details you are making it unlikely that a workable solution will be standardised. Following the principle that "options are bad" can't we manage to cut this list down to just one method (or worst case, two)? Why do we need five mechanisms? (I note that option 3 is "free" with reclassification, while option 4 is already defined in the NSH spec.) --- Section 9.2 seems to be out of date. Indeed, some of the hSFC approaches here include "reclassification" in a way that would stop the SI being used to detect loops. So we need to invoke the TTL. But how will the TTL be used? Will the lower layer SPF inherit the TTL from the higher layer, or will it reset it? Will the higher layer SFP be updated according to the TTL of the lower layer? Can two lower layer SFPs be stitched together without a "hop" in the higher layer? More work needed on loops, I think. > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 14 March 2017 18:30 > To: sfc@ietf.org > Subject: [sfc] WG Last call - Hierarchical SFC > > This is a last call for: > https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 > > Please respond to the list as to whether you see problems with this, you > think it is done, or any other input for the WG. > > Due to the run up to the IETF, we will let this run until April 7. From nobody Tue Mar 14 13:00:35 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D83D13147E for ; Tue, 14 Mar 2017 13:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdk8DIoLdWKh for ; Tue, 14 Mar 2017 13:00:29 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D633813147D for ; Tue, 14 Mar 2017 13:00:22 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id u108so130997127wrb.3 for ; Tue, 14 Mar 2017 13:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=JEA9fdYZx6YOgtT9uZrG/X5qCTJtB2RK+8r0Bbcb7v8=; b=qw9WeLTil6s+Den3S9ZiEQcdC8kWANW9kz/6t+DlOGSHT+hTEzqkrQ9IZ6w6l8xcnQ ZDiVl/bjLvQlDrKsufN88qE5g40n8dgdSgMald7WPXU6CkpxG1Fx7ysrvd1xYUQ5be6S +LCUq/evNa8u2BEAdezEUroSV0I3hU2eHt2Xj4lz2i+7i2PPZ2IhS5wnmy2l5DM9ARMA MJ2MUibuy41cqm6klD4P/lOf0oNTONgkC0W4sUGtgobOCHKvqWv3Zfv1no5ntua2isD0 WhDDn+k34c2XabVRnOhnxUydkFzgm0lpzdyhlXjxZ7tlmKa2G1jmtOlWQrs2Wg+s2SIJ QmCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=JEA9fdYZx6YOgtT9uZrG/X5qCTJtB2RK+8r0Bbcb7v8=; b=e9u35RFT+7hXVrcvNsZGzGu5k89WJOqMtENpYObSTTRBIvBGhFl5Q0x9Uj2uWOcYyY snxQ/CQwgMhAanT7sjM1UjKUEhGHjS7TvVrcyI7ZOmqJ7fNwJyaUPY+zUzrDAg5BMyXo gF6lEl4lzRGmiJxB6U0QBCvAw+ZV/gW2SpbA9fcS0IwPd4M50muQ8HojmMJ2hNRpIIgp hAW8pVgsYrKUQVezgHPTpg1OwZjBu4OSQljqGgOLLZqpoLxDlJK3/y5XKCLpM1DBmFlW UzLlBfgMcA/qINMqP4KKauULNNw8PeBT7s3Oxfh00WOZXDoi949HQSLBh9SanVACW5JT 78vQ== X-Gm-Message-State: AMke39nL4iMKcl6j/Q001Da+xs+RYj7lqVY2AWQ3Zq3hy/uOFCi03jEp1IaU1s/hjD4loD+Y4tB7WWwBMDpJEw== X-Received: by 10.223.134.44 with SMTP id 41mr34521991wrv.26.1489521621333; Tue, 14 Mar 2017 13:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.130.19 with HTTP; Tue, 14 Mar 2017 13:00:20 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: References: From: Behcet Sarikaya Date: Tue, 14 Mar 2017 15:00:20 -0500 Message-ID: To: "Andrew G. Malis" Cc: James N Guichard , "sfc@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sfc] Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 20:00:31 -0000 On Sat, Mar 11, 2017 at 8:17 AM, Andrew G. Malis wrote: > I support WG adoption of this draft. It looks very useful. > +1 I think that author affiliations need to be updated. Regards, Behcet > Cheers, > Andy > > > On Fri, Mar 10, 2017 at 8:08 PM, James N Guichard > wrote: >> >> Greetings WG, >> >> >> >> This message begins a two week call for WG adoption of the document >> https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ ending 24th M= arch >> 2017. >> >> >> >> Please respond to the SFC mailing list with any statements of approval o= r >> disapproval. >> >> >> >> Please note: >> >> >> >> 1. This is not WG last call. The document is not final and the WG >> is expected to modify the content until there is WG consensus that the >> content is solid. Therefore, please don=E2=80=99t oppose adoption just b= ecause you >> want to see changes to its content. >> >> 2. If you have objections to adoption of the document, please sta= te >> your reasons why, and explain what it would take to address your concern= s. >> >> 3. If you have issues with the content, by all means raise those >> issues and we can begin a dialog about how best to address them. >> >> >> >> Yours, >> >> >> >> Jim & Joel >> >> >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Mar 15 07:31:59 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223691315A2 for ; Wed, 15 Mar 2017 07:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruibsBkNoy1A for ; Wed, 15 Mar 2017 07:31:56 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4574E1315A0 for ; Wed, 15 Mar 2017 07:31:56 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id C43E9604CB; Wed, 15 Mar 2017 15:31:54 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id A65AE160182; Wed, 15 Mar 2017 15:31:54 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 15:31:54 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG Last call - Hierarchical SFC Thread-Index: AQHSnPEUz8weBXRZNUKjN8IF618Z/6GV9A1Q Date: Wed, 15 Mar 2017 14:31:53 +0000 Message-ID: <24607_1489588314_58C9505A_24607_16395_4_88132E969123D14D9BD844E1CD516EDE141D80EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG Last call - Hierarchical SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:31:58 -0000 Hello WG, I think the hSFC draft is in good shape and should be moved forward.=20 I've also read Adrian's (introductory) comments on the draft and it seems t= o me that the hSFC approach isn't only meant to address potential issues ra= ised by the operation of "long" chains, whatever makes a chain long.=20 Organizational matters can be instrumental too, so that hSFC can help servi= ce providers in better mastering resource usage in various regions of a SFC= domain, e.g., according to a typical access/backhaul/core taxonomy possibl= y distorted by the market coverage - residential/enterprise/wholesale/mobil= e, let alone the scope of the connectivity service associated to a given SF= C: for example, IoT services that are deployed at the scale of a city or a = region and which may involve specific interconnect design schemes may becom= e iconic beneficiaries of hSFC, but that's another use case argument. There may be other approaches that address such use cases/organizational co= nsiderations, but I think hSFC can facilitate the corresponding SFC design = and operation. Cheers, Christian.=20 -----Message d'origine----- De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern Envoy=E9=A0: mardi 14 mars 2017 19:30 =C0=A0: sfc@ietf.org Objet=A0: [sfc] WG Last call - Hierarchical SFC This is a last call for: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 Please respond to the list as to whether you see problems with this, you th= ink it is done, or any other input for the WG. Due to the run up to the IETF, we will let this run until April 7. Yours, Joel & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Mar 15 07:52:30 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C4E1315C3 for ; Wed, 15 Mar 2017 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQC088LokbEo for ; Wed, 15 Mar 2017 07:52:28 -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 D10FC1315BD for ; Wed, 15 Mar 2017 07:52:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIX86131; Wed, 15 Mar 2017 14:52:22 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Mar 2017 14:52:20 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Wed, 15 Mar 2017 07:52:10 -0700 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: SFC WG Agenda for Chicago Thread-Index: AdKdm3i/Pkf9DHdRQHGDSsALnDwvLg== Importance: high X-Priority: 1 Date: Wed, 15 Mar 2017 14:52:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.89] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC1C8ESJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58C95526.00FE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 675f1e030ca46a116668dbde7d88067b Archived-At: Subject: [sfc] SFC WG Agenda for Chicago X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:52:30 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC1C8ESJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: Just a quick reminder that we are still looking for agenda items for the up= coming SFC WG meeting in Chicago. If you have a specific presentation or id= eas for small group discussion please let the chairs know asap so that we c= an finalize an agenda. Thank you! Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC1C8ESJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

Just a quick reminder that we are still looking for = agenda items for the upcoming SFC WG meeting in Chicago. If you have a spec= ific presentation or ideas for small group discussion please let the chairs= know asap so that we can finalize an agenda.

 

Thank you!

 

Jim & Joel

 

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DC1C8ESJCEML701CHMchina_-- From nobody Mon Mar 20 10:53:13 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12B0131617 for ; Mon, 20 Mar 2017 10:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5-HaG3sgikl for ; Mon, 20 Mar 2017 10:53:07 -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 2D72D13157E for ; Mon, 20 Mar 2017 10:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32412; q=dns/txt; s=iport; t=1490032353; x=1491241953; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1OJto4uN0N8J7wNaYh1MA4OaQNwdZl4fvFXmg8wBYns=; b=SF4lqggeDB7GgmSfxM5JGQwQ614L/YCrI/V752V5f9XDtqNuJjrQQvfJ 5GIWLbBophkFl6TWGlmhJuNjC8vj5kGo7qiyxGsUq+ck5s3yv4S7e2j22 WDhV6MWF7DHGpBfYYVfvYkZUo5XQ9ydP1qfJDqRcyz0doI0uX5LpDa1D6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQBhFtBY/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgycqgWsHjWuRXZVDgg6CRwGDWgKDDj8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECARoNEy0HBAcFCwIBCBgVCRAyJQEBBA4FGYlfCKpaOopGAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYZOggWBYYEJhCUBEQEMED+CdYIxBY9djHABkkKBe4Uog1a?= =?us-ascii?q?GMohQiwcBHzh8CFgVQREBhEIDHYFjdYcuBQIIF4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,195,1486425600"; d="scan'208";a="399909337" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2017 17:52:31 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2KHqVVr014962 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Mar 2017 17:52:31 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 20 Mar 2017 12:52:30 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Mon, 20 Mar 2017 12:52:30 -0500 From: "Paul Quinn (paulq)" To: Adrian Farrel CC: "sfc@ietf.org" Thread-Topic: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt Thread-Index: AdKRRHVLY7SkxborSRGHk+YoYh/yhAQiDDYA Date: Mon, 20 Mar 2017 17:52:30 +0000 Message-ID: References: <027d01d29144$d743bcb0$85cb3610$@olddog.co.uk> In-Reply-To: <027d01d29144$d743bcb0$85cb3610$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.237.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 17:53:12 -0000 Hi Adrian, > On Feb 27, 2017, at 4:59 PM, Adrian Farrel wrote: >=20 > Hi all, >=20 > Many thanks to Paul for the updated revision. This makes life a lot > easier. >=20 > Herewith a review. I suspect some points I've raised are tracked in > email threads or tickets, or in the minutes from the interim. That's > OK: I just read and scribbled in a continuous stream of consciousness. >=20 > A bit of a wood/trees scenario here and I can't promise I have caught > every concern on this pass. >=20 > Thanks to all for the work that has gone before and which makes this > detailed review possible. >=20 Again, thank you for the great review! =20 > Cheers, > Adrian >=20 > --- >=20 > Requirements Language should not show as a numbered section. > If you're using XML use within rather than
. >=20 > --- >=20 > NSH needs to be expanded on first use in the body of the document (in > the Introduction). >=20 > --- >=20 > Throughout the document you need to look at the use of "NSH". It is > often missing an article (sometimes definite, sometimes indefinite). >=20 > --- PQ> Will update accordingly. =20 >=20 > In section 2 >=20 > NSH defines a new service plane protocol specifically for the > creation of dynamic service chains and is composed of the following > elements: >=20 > 1. Service Function Path identification >=20 > 2. Transport independent service function chain >=20 > 3. Per-packet network and service metadata or optional variable > type-length-value (TLV) metadata. >=20 > Not sure about the middle of these 3. Isn't that a feature (which is > fine to talk about somewhere) not one of the components? I think the > component missing from the list is the SI. So you might write: PQ> That's a fair point, so, for #2, perhaps: 2. Indication of location within a Service Function Path. =20 I think the concept of location is more accurate than progress. >=20 > 2. Indication of the progress along the Service Function Path. >=20 > And I have some trouble parsing the third item. I think you mean=20 > network and service metadata that is per-packet (although that is > perhaps a given as the NSH is also per packet). And I think you mean > that the metadata is optional, fixed length, or TLV-based. How about: >=20 > 3. Network and service metadata that may be optionally included > per packet and that may be fixed length or constructed from > type-length-value objects (TLVs). >=20 PQ> Let's simplify even more:=20 3. Optional, per packet metadata (fixed length or TLV). > --- >=20 > Why do you point to 7665 for the definition of "Classifier" but then > define "Service Classifier" to mean (AFAICS) exactly the same thing? >=20 > --- PQ> The definition in NSH provides important NSH-centric details that aren= 't in 7665. =20 >=20 > In 2.3 I think point 4 is a use case of metadata and so should be part > of point 3. >=20 PQ> That works for me. > --- >=20 > 3.1 > s/draft/document/ >=20 > --- PQ> Thanks. >=20 > Wondering whether "Context Headers" should be "Context Header" > throughout. >=20 PQ> Given that we've merged the figure into one "blob" this probably makes= sense. > --- >=20 > 3.1 >=20 > An NSH is composed of a 4-byte (all references to bytes in this draft > refer to 8-bit bytes, or octets) Base Header, a 4-byte Service Path > Header and Context Headers, as shown in Figure 1 below. >=20 > s/and Context/and optional Context/ >=20 > --- >=20 > 3.1 > Service Path Header: provide path identification and location within >=20 > s/provide/provides/ >=20 > --- PQ> Done. >=20 > 3.2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Obviously, we have discussed the reformatting of the Base Header and > ended up with=20 >=20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Ver|O| TTL | Length |R|R|R|R|MD Type| Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > Need to: > - Add a description of the TTL field (lots of mailing list discussion) PQ> AFAIK, the chairs haven't called consensus here. Once they convey tha= t, we'll update accordingly. > - Delete the C-bit PQ> I just saw consensus around that, so the next version will reflect the= change. > - Update the descriptions of Reserved bits > - Update the description of MD Type PQ> I believe you mean the updates that reflect TTL if/when added? =20 >=20 > --- >=20 > 3.2 >=20 > Version: The version field is used to ensure backward compatibility > going forward with future NSH updates. It MUST be set to 0x0 by the > sender, in this first revision of NSH. Given the widespread > implementation of existing hardware that uses the first nibble after > an MPLS label stack for ECMP decision processing, this document > reserves version 01 and this value MUST NOT be used in future > versions of the protocol. Please see [RFC7325] for further > discussion of MPLS-related forwarding requirements. >=20 > I believe this text is presuming the NSH-in-MPLS encapsulation. I don't > think it should do that, but if it does we have to look at the first > nibble not just the first two bits. >=20 > Now, as 4385 points out, if the first nibble is 4 or 6, IPv4 or IPv6 > will be assumed. So 0b0100 or 0b0110 accounts for you reserving version > 1 (just in case the C bit is 0 and for any value of the O bit). So far, > so good! >=20 > But 4385 defines a first nibble of 0000 to mean "here is a control word" > and that would mean you needed to reserve version 0 as well :-( >=20 > So my advice here would be that encapsulation in MPLS is not in scope=20 > for this document, and you should not play with reserving version > numbers. PQ> That is where we started, but there was a lot of discussion on the lis= t about the potential for conflict. I have to go dig up the threads but I'= m hoping that some of the folks who expressed concern here will weigh in. >=20 > --- >=20 > 3.2 >=20 > There's been a long thread on the text about the O-bit. >=20 > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). >=20 > First para OK. >=20 > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. >=20 > SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable > parameter to enable forwarding received SFC OAM packets unmodified to > the next element in the chain. Such behavior may be acceptable for a > subset of OAM functions, but can result in unexpected outcomes for > others, thus it is recommended to analyze the impact of forwarding an > OAM packet for all OAM functions prior to enabling this behavior. > The configurable parameter MUST be disabled by default. >=20 > These paras are controversial as discarding OAM packets (rather than > passing them through) can also result in unexpected outcomes. Consider, > if you will, simple end-to-end ping functions. >=20 > (Also s/Classifer/Classifier/ twice) >=20 > There is also a mismatch of "SHALL" and "MAY". >=20 > I would like this text to read... >=20 > =3D=3D=3D > SF/SFF/SFC Proxy/Classifer implementations that do not support SFC > OAM procedures, SHALL ignore the setting of the O-bit and SHALL > attempt to process the packet as normal. > =3D=3D=3D >=20 > ...but I could live with... >=20 > =3D=3D=3D =20 > SF/SFF/SFC Proxy/Classifer implementations that do not support SFC > OAM procedures SHOULD discard packets with O-bit set, but MAY > support a configurable parameter to enable forwarding received SFC > OAM packets unmodified to the next element in the chain. > =3D=3D=3D >=20 PQ> I can live with this as well, however, I think we need to chairs to ma= ke a final call about how the WG has opted to move forward wrt OAM. > For non OAM packets, the O-bit MUST be cleared and MUST NOT be > modified along the SFP. >=20 > This paragraph needs simple clarification as follows >=20 > =3D=3D=3D=20 > The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM > packets. The O-bit MUST NOT be modified along the SFP. > =3D=3D=3D >=20 > --- >=20 > 3.2 >=20 > C-bit is being retired as discussed. >=20 > --- >=20 PQ> Indeed. > 3.2 >=20 > Length: total length, in 4-byte words, of NSH including the Base > Header, the Service Path Header and the context headers or optional > variable length metadata. The Length MUST be of value 0x6 for MD > Type equal to 0x1 and MUST be of value 0x2 or greater for MD Type > equal to 0x2. The NSH header length MUST be an integer number of 4 > bytes. The length field indicates the "end" of NSH and where the > original packet/frame begins. >=20 > There is no "or optional variable length metadata." That is exactly what > the context headers are, and the context headers are optional. And the > last sentence is a little too much. So... PQ> We tried to draw a distinction between the mandatory fixed vs. tlv hea= ders. I can see how it's not clear in the above text. >=20 > Length: total length, in 4-byte words, of the NSH including the Base > Header, the Service Path Header, and any Context Headers. It the=20 > MD Type is 0x1, the Length MUST be 0x6. If the MD Type is 0x2, the > Length MUST be 0x2 or greater. The actual NSH header length MUST be > an integer multiple of 4 bytes and is padded if necessary.=20 >=20 PQ> That works for me. > --- >=20 > 3.2 >=20 > MD Type: indicates the format of NSH beyond the mandatory Base Header > and the Service Path Header. MD Type defines the format of the > metadata being carried. Please see IANA Considerations section > below. >=20 > Maybe "...indicates the format of the metadata carried in the Context=20 > Headers..." PQ> I think the current text is more explicit. Do you have a specific con= cern? >=20 > NSH defines two MD types: >=20 > s/NSH/This document/ > s/types/Type values/ PQ> Will update accordingly. >=20 > 0x1 - which indicates that the format of the header includes fixed > length context headers (see Figure 4 below). >=20 > 0x2 - which does not mandate any headers beyond the Base Header and > Service Path Header, but may contain optional variable length context > information. >=20 > Add "...not defined in this specification." >=20 PQ> Will update. > --- >=20 > 3.2 >=20 > Next Protocol: indicates the protocol type of the encapsulated data. > NSH does not alter the inner payload, and the semantics on the inner > protocol remain unchanged due to NSH service function chaining. > Please see IANA Considerations section below. >=20 > s/due to/by/ >=20 > This draft defines the following Next Protocol values: >=20 > s/draft/document/ >=20 > 0x1 : IPv4 > 0x2 : IPv6 > 0x3 : Ethernet > 0x4: NSH > 0x5: MPLS >=20 > Fix formatting >=20 > 0x6-0xFD: Unassigned > 0xFE-0xFF: Experimental >=20 > Suggest to delete the last two lines as they are not protocols, but info > for the IANA Considerations section. PQ> Will update to reflect all of the above. >=20 > --- >=20 > 3.3 >=20 > Service Path Identifier (SPI): identifies a service path. > Participating nodes MUST use this identifier for Service Function > Path selection. The initial classifier MUST set the appropriate SPI > for a given classification result. >=20 > Both uses of "MUST" are unnecessary and the words could be deleted=20 > without loss of meaning or tightness of specification. PQ> New text: Service Path Identifier (SPI): identifies a service path. Participating nodes use this identifier for Service Function Path selection. The initial classifier MUST set the appropriate SPI for a given classification result. >=20 > --- >=20 > 3.3 >=20 > Service Index (SI): provides location within the SFP. The initial > classifier for a given SFP SHOULD set the SI to 255, however the > control plane MAY configure the initial value of SI as appropriate > (i.e. taking into account the length of the service function path). > Service Index MUST be decremented by Service Functions or by SFC > Proxy nodes after performing required services and the new > decremented SI value MUST be used in the egress NSH packet. The > initial Classifier MUST send the packet to the first SFF in the > identified SFP for forwarding along an SFP. If re-classification > occurs, and that re-classification results in a new SPI, the > (re)classifier is, in effect, the initial classifier for the > resultant SPI. >=20 > What you are saying, I think is that the initial classifier MUST set > the SI equal to the first SI in the SFP. This SHOULD be 255, but an > SFP MAY be configured to start at a lower SI value. PQ> Correct. >=20 > s/decremented/decremented by one/ (reference the endless email threads) >=20 PQ> Will be updated. > --- >=20 > 3.3 >=20 > SI SHOULD be used in conjunction with Service Path Identifier for > Service Function Path Selection and for determining the next SFF/SF > in the path. >=20 > What is the variation to this "SHOULD"? PQ> I suspect this is a vestige from an earlier option where the path ID w= as considered sufficient in some cases: a SFF could, in principle, use the = path ID to select the next SFF if, for example, there were no SFs, or could= opt to send packets to a re-classifier based on path alone. Having said t= hat, I'm not sure there's much need to those cases. Do others? >=20 > In addition to indicating > the location within a Service Function Path, SI can be used for > service plane loop detection. >=20 > I think that, although this might still be true, the TTL will be more > helpful for loop detection and we should strike this text. >=20 PQ> Once we finalize the TTL details, I agree this'll be cleaned up. > --- >=20 > 3.4 > I suggest deleting Figure 4. It does not differ from the information in=20 > Figures 1, 2, and 3, and risks not being kept up-to-date with those > figures. >=20 > OTOH, you should say here that Length has a specific value. >=20 PQ> I think figure 4 provides a very concrete representation of a type-1 h= eader so it probably makes sense to keep it. I do agree: length should ref= lect the specific value. > --- >=20 > 3.4 >=20 > When the Base Header specifies MD Type =3D 0x1, four Context Headers, > 4-byte each, MUST be added immediately following the Service Path > Header, as per Figure 4. Context Headers that carry no metadata MUST > be set to zero. >=20 > I think this is adding new and strange meaning to "Context Header". > See previous comments, but why is a Context Header suddenly a 4-byte > thing? Why is this not 3 3-byte Context Headers followed by 1 7-byte > Context Header? Or more realistically, why not just talk about "Up to > 16 bytes of metadata carried in the 16 byte Context Header that follows > the Base Header. Any context Header bytes not used to carry metadata > MUST be set to zero." PQ> This text should have been changed, it's out of date. We've moved to = a single 16 byte "blob" -- as per figure 4 -- and this text should reflect = that. >=20 > --- >=20 > 3.4 >=20 > OLD > This specification does not make any assumption about the content > placed in the mandatory context field of the NSH header, and does not > describe the structure or meaning of the included metadata. > NEW > This specification does not make any assumptions about the content of > the 16 byte Context Header that must be present when the MD Type=20 > field is set to 1, and does not describe the structure or meaning of > the included metadata. > END >=20 PQ> New text will be added. > --- >=20 > 3.4 >=20 > Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is > configured for mandatory use of metadata but does not yet receive the > data semantics for the mandatory context field, it MUST NOT process > the packet and MUST log at least once per the SPI for which a > mandatory metadata is missing. >=20 > There seem to be some assumptions here: > - An SF having mandatory use of metadata is a config item and can't be > an implementation thing (i.e., you are not allowing an SF that must > always use metadata). PQ> The text covers the case where the SF needs metadata (let's say for po= licy enforcement) but does not (yet) know how to parse the metadata. I don't see any implication on config vs = implementation. =20 > - You are assuming that the semantics for the metadata are always=20 > dynamically installed in the SF and not known a priori. >=20 PQ> There was no intent to imply that, perhaps the easiest way to clarify:= "...not yet receive..." --> "...not yet know..." (or something similar) > I don't think you should make those restrictions (although, obviously, > we should allow them as options). >=20 > You also seem to be assuming that a non-SFC-aware SF can receive a=20 > packet with an NSH and metadata and will somehow manage to parse the NSH > and find the metadata that it doesn't understand. Frankly, I think this > document talks only about SFC-aware SFs and SFC proxies. Other SFs are > by definition not in scope as they will never receive an NSH (except for > a bug that will reasonably cause the SF to drop the packet - or crash). >=20 PQ> I don't see that conveyed. The text is just unambiguous about an SFC-= SF. It makes not claims about others. =20 > Finally "must not process" is ambiguous. I think you mean "must discard" >=20 PQ> Fair point. > So, maybe... >=20 > An SF or SFC Proxy that does not know the format or semantics of the=20 > Context Header for an NSH with MD Type 1 MUST discard any packet with > such an NSH (i.e., MUST NOT ignore the metadata that it cannot=20 > process), and MUST log the event at least once per the SPI for which > the event occurs (subject to thresholding). PQ> This works for me. >=20 > --- >=20 > 3.5 >=20 > Again, Figure 5 is de trop.=20 > You also need to discuss the value of the Length field. PQ> Again, I think being explicit with figures helps the reader. Updating= length field makes sense.=20 >=20 > --- >=20 > 3.5 >=20 > This section has the usual confusion of whether there are multiple > context headers (each of variable length), multiple variable length > metadata, a single variable length context header (also called a=20 > variable context header) containing metadata, or whatever. >=20 PQ> I re-read it several times, and although it's a bit clumsy, I'm not su= re it's confusing. > Figure 6, for example, shows one piece of variable length metadata > in an encoding element labelled "Variable Context Headers". PQ> I agree, I'll update the figure to show a better representation of the = structure. That will probably help with the 3.5 text. >=20 > This is made more confusing in the context of 3.4 where you have=20 > the concept of 4 byte context headers. >=20 > Later, in 3.5.1, you call it a TLV. >=20 > I wish we could sort out this language. >=20 > I think what you are trying to say is that the Context Header (singular) > can contain zero, one, or multiple metadata elements each encoded as a > TLV as shown in Figure 6. >=20 > --- PQ> I'll take a pass at cleaning it up. >=20 > 3.5.1 >=20 > Discussions on the list about the sizing of the Metadata Class and=20 > Type fields, the deprecation of the C-bit, the naming of the Type field > (which looks like Metadata Type which is easily confused with MD Type), > and the deprecation of the split ranges of the Type field. >=20 > --- PQ> Yup, will update accordingly once we finish the discussions. >=20 > 3.5.1 >=20 > If multiple instances of the same TLV are included in an NSH packet, > but the definition of that TLV does not allow for it, the SFC-aware > SF MUST NOT process the packet and MUST log at least once per the SPI > for which multiple instances of that TLV is supplied. >=20 > This is OK, but I prefer the more usual (and future-proof)... >=20 > If multiple instances of the same TLV are included in an NSH packet, > but the definition of that TLV does not allow for it, the SFC-aware > SF MUST process first instance and ignore subsequent instances. >=20 > --- PQ> Barring objection from the list, that's fine with me. >=20 > 4. >=20 > NSH-aware nodes are the only nodes that MAY alter the content of the > NSH headers. >=20 > s/MAY/may/ PQ> Thanks. >=20 > Is there a difference between an "SFC-aware node" and an "NSH-aware > node"? >=20 > Isn't this sentence silly? "Only nodes that can understand the content > of the NSH can change the content of the NSH" >=20 PQ> I agree. Barring objection, will remove. > --- >=20 > 4. > Bullet 1 >=20 > OLD > At the end of a service function path, a SFF, MUST be > the last node operating on the service header and MUST remove it. > NEW > At the end of a service function path, a SFF, MUST be > the last node operating on the service header and MUST remove it > before forwarding or delivering the encapsulated packet. > END >=20 PQ> I think that's a good clarification but I fear the last part is confus= ing since I think of post-NSH the packet being un-encapsulated (unless I'm = missing something you are trying to convey): "...and MUST remove it before forwarding or delivering the un-encapsulated= packet." > --- >=20 > 4. > Bullet 1 >=20 > Multiple logical classifiers may exist within a given service > path. >=20 > How so "logical"? Are they or are they not "classifiers"? > (Multiple occurrences in this bullet.) PQ> Logical in the sense that they need not be distinct classifiers. We'v= e been consistent with the concept that classifiers, SFFs, etc. are logical= : they can be co-mingled or distinct. =20 >=20 > --- >=20 > 4. > Bullet 1 >=20 > OLD > Non-initial classifiers may re-classify data and that re- > classification MAY result in a new Service Function Path. > NEW > Non-initial classifiers may re-classify data and that re- > classification MAY result in a the packet being assigned to a > different Service Function Path. > END PQ> Minor tweak: Non-initial classifiers may re-classify data and that re-classification MA= Y result in the selection a different Service Function Path. >=20 > --- >=20 > 4. >=20 > 2. Select service path: The Service Path Header provides service > chain information and is used by SFFs to determine correct > service path selection. SFFs MUST use the Service Path Header > for selecting the next SF or SFF in the service path. >=20 > It is probably a minor point, but the Service Path Header provides > service *path* information and not service chain information. >=20 PQ> Worth fixing, thanks. > --- >=20 > 4. >=20 > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > service index. If an SFF receives a packet with an SPI and SI > that do not correspond to a valid next hop in a valid Service > Function Path, that packet MUST be dropped by the SFF. >=20 > Non-NSH-aware SFs will, of course, either not see NSHs or barf. So it is > enough to say "SFs" (you have already defined the abbreviation). >=20 > Say "decrement the service index by one". >=20 PQ> Thanks. > --- >=20 > 4. > Bullet 3 >=20 > Classifier(s) MAY update Context Headers if new/updated context > is available. >=20 > s/Classifier(s)/Classifiers/ >=20 PQ> Will update. > --- >=20 > 4. > Bullet 3 >=20 > If an SFC proxy is in use (acting on behalf of a non-NSH-aware > service function for NSH actions), then the proxy MUST update > Service Index and MAY update contexts. When an SFC proxy > receives an NSH-encapsulated packet, it MUST remove the NSH > headers before forwarding it to an NSH unaware SF. When the SFC > Proxy receives a packet back from an NSH unaware SF, it MUST re- > encapsulates it with the correct NSH, and MUST decrement the > Service Index. >=20 > I think "update contexts" means "update the metadata carried in the > Context Header. This does not say whether a proxy can add a Context > Header if one is not already present, or whether it can add a metadata > TLV, or remove one. >=20 PQ> Correct, this means update the existing contexts. I believe we decided= that only classifiers can add/remove (but as per a point above, those clas= sifiers are logical and can be "part' of an SF). I need to go back and che= ck the archives. Joel might remember since I think we talked about it. > Decide on "non-NSH-aware", "NSH unaware", "non-SFC-aware". >=20 > Say "decrement the service index by one". PQ> Will update. >=20 > --- >=20 > 4. >=20 > 4. Service policy selection: Service Function instances derive > policy (i.e. service actions such as permit or deny) selection > and enforcement from the service header. Metadata shared in the > service header can provide a range of service-relevant > information such as traffic classification. Service functions > SHOULD use NSH to select local service policy. >=20 > "Service Function instance" is not properly defined in 7665 and not > previously mentioned in this document. OTOH, the term could usefully be > used in 7.1 para 2. PQ> I think we can simplify and change service function instance to servic= e function. =20 >=20 > s/service header/NSH/ (twice) PQ> Thanks. >=20 > Does the last sentence add anything? It appears to say what the previous > sentences say, but the "SHOULD" is ambiguous. Suggest deleting it. PQ> Perhaps remove it, and beef up the first a bit. Let me fiddle with it= . >=20 > --- >=20 > In Figure 8 >=20 > - "Select Service Function Path" is ambiguous. Isn't the SFF bound by=20 > the SPI and so cannot select the path, only use the one it is > instructed to use? OTOH, the Classifier is responsible for determining > which path to use. PQ> That's a fair point. The intent was to convey the forwarding aspect o= f the SFF. Update: "Forward NSH Packets" >=20 > - Surely the SFC proxy can update the Context Header as in bullet 3, > above. >=20 PQ> Yes. > - Might an SFC proxy also select service policy for an NSH-unaware SF? PQ> I'm not sure what you mean. The proxy maps the packet to a local conn= ection. The proxy doesn't have any service policy insight. >=20 > --- >=20 > 5. >=20 > The presence of NSH is > indicated via protocol type or other indicator in the outer > encapsulation. >=20 > You are prejudging the "encapsulation of NSH" work that is to be done. > You may be largely correct, but not always. We should omit this text. PQ> Must there not be some form of indicator -- explicit or otherwise? >=20 > --- >=20 > 7.1 >=20 > This indirection -- path ID to overlay -- creates a true service > plane. That is the SFF/SF topology is constructed without impacting > the network topology but more importantly service plane only > participants (i.e. most SFs) need not be part of the network overlay > topology and its associated infrastructure (e.g. control plane, > routing tables, etc.). As mentioned above, an existing overlay > topology may be used provided it offers the requisite connectivity. >=20 > There is a lot hidden or implied in this paragraph. But consider an SF > that is somehow remote from the SFF. The SFF knows how to send to the > SF over the underlay network. But does the SF know how to send back to > the SFF? In some underlay technologies you can just reverse the=20 > encapsulation addresses. In others, you can't. >=20 > Perhaps the relationship between SF and SFF is configured (i.e., known > a priori)? >=20 > Now consider an SF that is used on multiple SFPs. And consider further > that the SF might be reachable from different SFFs on the different=20 > SFPs. Now selecting the return path becomes a challenge. >=20 > Maybe "most SFs" is the clue. Maybe "some SFs" participate in the=20 > control plane and routing tables.=20 >=20 > Perhaps this could be clearer. PQ> We can add something down the lines of: SF need to be able to return a= packet to the appropriate SFF when service processing is complete. This c= an be via the over or under-lay and in some case require additional configu= ration on the SF. >=20 > --- >=20 > 8.1 >=20 > NSH > itself does not provide privacy functions, rather it relies on the > transport/overlay layer. An operator can select the appropriate > transport to ensure the confidentially (and other security) > considerations are met. >=20 > I think you are making a big leap to decide what the metadata documents > will define. >=20 PQ> See below. > You are also failing to consider metadata that needs to be kept private > between the SF at SI 250 and the SF at SI 240 when there are other SFs > in between. PQ> I don't think that's prohibited in the text above: pick the right tran= sport. >=20 > I suggest replacing this paragraph with something like... >=20 > This specification does not provide any privacy or security functions=20 > for the NSH. Hop-by-hop security and privacy can be achieved by using > features of the underlay (transport) connections. Metadata privacy=20 > and security considerations are a matter for the documents that=20 > define metadata formats, encodings, and TLVs. PQ> I'm fine with the last sentence. >=20 > --- >=20 > 8.2 >=20 > Why do you not consider imposing metadata at a subsequent point along > the path? This would happen, for example, if one SF needed to convey > information to another SF for a packet that did not already have=20 > metadata. PQ> We do, it's a core use case and depicted in figure 15 and described in= 8.2, bullet 1. >=20 > --- >=20 > 12 >=20 > Obviously the IANA stuff needs updating to reflect changes elsewhere: >=20 > 12.2.1 The C bit has gone and the reserved bits have moved. >=20 > 12.2.2 See my comment on section 3.2 >=20 > 12.2.3 The size of the MD Type registry is reduced. > Allowing one experimental code point looks like enough to me. >=20 PQ> Will update all three. > 12.2.4 There is a thread about this. > The registry has to indicate that MD Class 0 has been assigned > by this document for "IETF use". > The advice to DEs needs to be supplied. > The size of the range of classes may be reduced to allow an=20 > increase in the number of "types" >=20 > Missing registry for "types" within the MD Class 0 > The same thread applies. > (I recall there was also action from the interim) > The registry will be empty but should be created in this doc > The name of this registry is confusable with "MD type" > The size of the range may be increases as the MD class range is > reduced. PQ> I'll go re-read the thread.= From nobody Mon Mar 20 11:22:36 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A60B13164F for ; Mon, 20 Mar 2017 11:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9Z1Uvo5CzCn for ; Mon, 20 Mar 2017 11:22:32 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0640513164C for ; Mon, 20 Mar 2017 11:22:32 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 20 Mar 2017 14:22:30 -0400 From: Dave Dolson To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] WG Last call - Hierarchical SFC Thread-Index: AQHSnPEUE97eZ5iRfU6n20AFwjV95KGU/4kAgAkIDMA= Date: Mon, 20 Mar 2017 18:22:29 +0000 Message-ID: References: <056c01d29cfb$3275c8f0$97615ad0$@olddog.co.uk> In-Reply-To: <056c01d29cfb$3275c8f0$97615ad0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG Last call - Hierarchical SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 18:22:34 -0000 Adrian, Thank you for reading and providing suggestions. Please see inline comments [DD] For those who wish to follow along or make pull requests, collaboration is = occurring on github: https://github.com/dcdolson/draft-dolson-sfc-hierarchi= cal I'm going to track issues there. -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, March 14, 2017 3:43 PM To: 'Joel M. Halpern'; sfc@ietf.org Subject: Re: [sfc] WG Last call - Hierarchical SFC All, I'm not very excited by hSFC. So far we haven't been able to come up with examples of very long chains and while they may one day be found it seems premature to do work on hSFC. I do agree that the use cases shown can be solved with hSFC, but I also don't see use cases as=20 insoluble using other approaches. So please take this as a "publish it if you must" level of support :-) But anyway, here are a few comments from reading the latest revision. Cheers, Adrian Seven authors will probably give the AD heartburn. [DD] Why? How is this usually handled? --- I'm surprised to see this last called when it has normative references to one document that the still needs work before it can go to a second WG last call, and another document that the WG is debating abandoning. [DD] I would expect the RFC editor to queue this behind I-D.ietf-sfc-nsh?=20 [DD] As for I-D.ietf-sfc-control-plane, if it is abandoned, we need to expl= ain some concepts within hSFC. --- The introduction contains the reasonable note... Note: in this document, the notion of the "path" of a packet is the series of SF instances traversed by a packet. The means of delivering packets between SFs (i.e., the forwarding mechanisms enforced in the underlying network) are not relevant to the discussion.=09 Why, then, does the document go on to discuss SFFs? [DD] We should choose whether to make this agnostic about technology or emb= race NSH. --- We were explicitly told in the WG that an SFF cannot make assumptions=20 based on the transport tunnel used to deliver a packet to the SFF. 3.1.1 seems to be counter to this. I would be happy to hear that 3.1.1 is a valid approach, but if so then the WG needs to agree that an SFF *can* make determinations based on the transport tunnel. In particular, it can tell whether a packet has=20 arrived from another SFF, from an SF, or from a classifier. [DD] It is intended that the packets are returned to the higher layer only = at the *termination* of the lower-level chain. I think we can probably clar= ify this better by saying the IBN is about classification and termination (= the start and end of chains), not the middle. Does that help? --- It is all very well for section 3.1 to describe 5 perfectly achievable approaches to hSFC, but in order to achieve interop, the head and tail ends of a lower layer SFC need to use the same mechanism. That means that the mechanism either has to be determined through the control plane or exposed by examination of the data plane. Furthermore, the=20 implication is that all implementations have to support all five=20 mechanisms. Saying that this document "sets expectations for control planes" is all very well, but by keeping so many options and punting on the details you are making it unlikely that a workable solution will be=20 standardised. Following the principle that "options are bad" can't we manage to cut this list down to just one method (or worst case, two)? Why do we need five mechanisms? [DD] I wouldn't mind reducing this, but keep in mind that being both the st= art and end of the sub-domain, the IBN actually do something proprietary. P= erhaps we should be defining the schemes in terms of requirements at the SF= s? (e.g., supporting nested NSH, respecting reserved metadata...) Maybe ot= hers can make suggestions. (I note that option 3 is "free" with reclassification, while option 4 is already defined in the NSH spec.) [DD] I don't see the IBN as doing only "reclassification". It is important = that we view the sub-domain as being independently administered. --- Section 9.2 seems to be out of date. Indeed, some of the hSFC approaches here include "reclassification" in=20 a way that would stop the SI being used to detect loops. So we need to invoke the TTL. But how will the TTL be used? Will the lower layer SPF inherit the TTL from the higher layer, or will it reset it? Will the higher layer SFP be updated according to the TTL of the lower layer? Can two lower layer SFPs be stitched together without a "hop" in the=20 higher layer? More work needed on loops, I think. [DD] Waiting for I-D.ietf-sfc-nsh to be updated with the TTL. Yes, TTL prop= agation rules would need to be defined. > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 14 March 2017 18:30 > To: sfc@ietf.org > Subject: [sfc] WG Last call - Hierarchical SFC >=20 > This is a last call for: > https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 >=20 > Please respond to the list as to whether you see problems with this, you > think it is done, or any other input for the WG. >=20 > Due to the run up to the IETF, we will let this run until April 7. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Mar 20 11:59:11 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19A8128C83 for ; Mon, 20 Mar 2017 11:59:10 -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 pFxACAltAga9 for ; Mon, 20 Mar 2017 11:59:07 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 0AD86128D40 for ; Mon, 20 Mar 2017 11:59:07 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n11so71103838wma.1 for ; Mon, 20 Mar 2017 11:59:06 -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=OjmHdHcCl1Maf0gWB9M7tzgNjBwRJbPwymh6dT0OeGI=; b=sqaJYVqdx9/vwu2jMNvofNfAFKYzLo7s4BsesB2/qDG2mOKA8NOuivNdY9ICdduQxA Yw81NcgMFh5DkVIbCMlVzviIEl9Dv0SJYVYWkkeGQDLnfAX6aE42hjRX3rq6+QB9kPk2 8E+Mvjjan7KMGOW9B2JS2nO+FYfDd2WR6xSNX3Nxpywf5YXQcVD9EHgwYoHim4PXSxnD hJ2UIIvsK5Rc/Hqr7YQI6mPwztfn2wN0accuDRxr2ZW+yXPJEv5EqwtFBhZXuDwum+Sg Px1V3eoLlBBL3qr3m0i9XvdTIxMaBOCLzdiWUG7JWr/5mOVm9MUmxHkTfhXSqHqRTuyC wTbQ== 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=OjmHdHcCl1Maf0gWB9M7tzgNjBwRJbPwymh6dT0OeGI=; b=pmT7ZhB5epJEvUy+aMUm9UF7ukGG0U9OhfQw3n/prOK4AEXVjMlH0QOUC6kdLkqJcR x8mkprKZPKiz69+lqe76RgJa95HSD8/6ndO0UaU5oXWv15CFxJxoLXF3dujX8oHYqkfO hngylnMwNE1+IbWuTfTGtHd0rmVxJSfJSYsUHaXwQzcBHSdRRAejW4ln/cW/nVlHoSJX uRIR2rlo2747E66rKqnvuR4ZX4L10u4JuhqFLfMVsSblop68Z2iIk5jZk5lLJqvKaIdC dlWskFtJwxRRhPaVtphiTHElE6/x9JA18nye63RaDOTDcJ4KKp8jjA4qtlXokO2pAGJ/ Ef2A== X-Gm-Message-State: AFeK/H0n+SqqngfXcp6tbvvjAKeS0clWKhB+a9MqMPjwL1gSod1YbTvvwj9Kq4iP7tFtpkaz2ALGF8lTkSI4PA== X-Received: by 10.28.30.79 with SMTP id e76mr11420649wme.96.1490036345332; Mon, 20 Mar 2017 11:59:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.145.69 with HTTP; Mon, 20 Mar 2017 11:59:04 -0700 (PDT) In-Reply-To: References: <056c01d29cfb$3275c8f0$97615ad0$@olddog.co.uk> From: Alia Atlas Date: Mon, 20 Mar 2017 14:59:04 -0400 Message-ID: To: Dave Dolson Cc: "adrian@olddog.co.uk" , "Joel M. Halpern" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a114b2de411085b054b2e1f36 Archived-At: Subject: Re: [sfc] WG Last call - Hierarchical SFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 18:59:10 -0000 --001a114b2de411085b054b2e1f36 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 20, 2017 at 2:22 PM, Dave Dolson wrote: > Adrian, > Thank you for reading and providing suggestions. > > Please see inline comments [DD] > > For those who wish to follow along or make pull requests, collaboration is > occurring on github: https://github.com/dcdolson/ > draft-dolson-sfc-hierarchical > I'm going to track issues there. > > > -Dave > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, March 14, 2017 3:43 PM > To: 'Joel M. Halpern'; sfc@ietf.org > Subject: Re: [sfc] WG Last call - Hierarchical SFC > > All, > > I'm not very excited by hSFC. So far we haven't been able to come up > with examples of very long chains and while they may one day be found > it seems premature to do work on hSFC. I do agree that the use cases > shown can be solved with hSFC, but I also don't see use cases as > insoluble using other approaches. > > So please take this as a "publish it if you must" level of support :-) > > But anyway, here are a few comments from reading the latest revision. > > Cheers, > Adrian > > Seven authors will probably give the AD heartburn. > [DD] Why? How is this usually handled? > [Alia] Except in unusual and well explained circumstances, I will not advance a document with more than 5 editors/authors. This is standard IETF-wide policy. If there are a large number of authors, then the WG Chairs usually encourage appointing one or two editors and the remainder are thanked as contributors. Regards, Alia > --- > > I'm surprised to see this last called when it has normative references > to one document that the still needs work before it can go to a second > WG last call, and another document that the WG is debating abandoning. > [DD] I would expect the RFC editor to queue this behind I-D.ietf-sfc-nsh? > [DD] As for I-D.ietf-sfc-control-plane, if it is abandoned, we need to > explain some concepts within hSFC. > > --- > > The introduction contains the reasonable note... > Note: in this document, the notion of the "path" of a packet is > the series of SF instances traversed by a packet. The means of > delivering packets between SFs (i.e., the forwarding mechanisms > enforced in the underlying network) are not relevant to the > discussion. > Why, then, does the document go on to discuss SFFs? > [DD] We should choose whether to make this agnostic about technology or > embrace NSH. > > --- > > We were explicitly told in the WG that an SFF cannot make assumptions > based on the transport tunnel used to deliver a packet to the SFF. > > 3.1.1 seems to be counter to this. > > I would be happy to hear that 3.1.1 is a valid approach, but if so then > the WG needs to agree that an SFF *can* make determinations based on the > transport tunnel. In particular, it can tell whether a packet has > arrived from another SFF, from an SF, or from a classifier. > > [DD] It is intended that the packets are returned to the higher layer only > at the *termination* of the lower-level chain. I think we can probably > clarify this better by saying the IBN is about classification and > termination (the start and end of chains), not the middle. Does that help? > > > --- > > It is all very well for section 3.1 to describe 5 perfectly achievable > approaches to hSFC, but in order to achieve interop, the head and tail > ends of a lower layer SFC need to use the same mechanism. That means > that the mechanism either has to be determined through the control plane > or exposed by examination of the data plane. Furthermore, the > implication is that all implementations have to support all five > mechanisms. > > Saying that this document "sets expectations for control planes" is > all very well, but by keeping so many options and punting on the details > you are making it unlikely that a workable solution will be > standardised. > > Following the principle that "options are bad" can't we manage to cut > this list down to just one method (or worst case, two)? > > Why do we need five mechanisms? > [DD] I wouldn't mind reducing this, but keep in mind that being both the > start and end of the sub-domain, the IBN actually do something proprietary. > Perhaps we should be defining the schemes in terms of requirements at the > SFs? (e.g., supporting nested NSH, respecting reserved metadata...) Maybe > others can make suggestions. > > (I note that option 3 is "free" with reclassification, while option 4 > is already defined in the NSH spec.) > [DD] I don't see the IBN as doing only "reclassification". It is important > that we view the sub-domain as being independently administered. > > --- > > Section 9.2 seems to be out of date. > Indeed, some of the hSFC approaches here include "reclassification" in > a way that would stop the SI being used to detect loops. So we need to > invoke the TTL. But how will the TTL be used? Will the lower layer SPF > inherit the TTL from the higher layer, or will it reset it? Will the > higher layer SFP be updated according to the TTL of the lower layer? > Can two lower layer SFPs be stitched together without a "hop" in the > higher layer? > > More work needed on loops, I think. > [DD] Waiting for I-D.ietf-sfc-nsh to be updated with the TTL. Yes, TTL > propagation rules would need to be defined. > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > > Sent: 14 March 2017 18:30 > > To: sfc@ietf.org > > Subject: [sfc] WG Last call - Hierarchical SFC > > > > This is a last call for: > > https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 > > > > Please respond to the list as to whether you see problems with this, you > > think it is done, or any other input for the WG. > > > > Due to the run up to the IETF, we will let this run until April 7. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a114b2de411085b054b2e1f36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 20, 2017 at 2:22 PM, Dave Dolson <ddolson@sandvine.com<= /a>> wrote:
Adrian,
Thank you for reading and providing suggestions.

Please see inline comments [DD]

For those who wish to follow along or make pull requests, collaboration is = occurring on github: https://github.com/dcd= olson/draft-dolson-sfc-hierarchical
I'm going to track issues there.


-Dave


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Adrian Farrel
Sent: Tuesday, March 14, 2017 3:43 PM
To: 'Joel M. Halpern'; sfc@ietf.org=
Subject: Re: [sfc] WG Last call - Hierarchical SFC

All,

I'm not very excited by hSFC. So far we haven't been able to come u= p
with examples of very long chains and while they may one day be found
it seems premature to do work on hSFC. I do agree that the use cases
shown can be solved with hSFC, but I also don't see use cases as
insoluble using other approaches.

So please take this as a "publish it if you must" level of suppor= t :-)

But anyway, here are a few comments from reading the latest revision.

Cheers,
Adrian

Seven authors will probably give the AD heartburn.
[DD] Why? How is this usually handled?

[Alia] Except in unusual and well explained circumstances, I will no= t advance
a document with more than 5 editors/authors.=C2=A0 This= is standard IETF-wide policy.
If there are a large number of aut= hors, then the WG Chairs usually encourage
appointing one or two = editors and the remainder are thanked as contributors.

=
Regards,
Alia
=C2=A0
---

I'm surprised to see this last called when it has normative references<= br> to one document that the still needs work before it can go to a second
WG last call, and another document that the WG is debating abandoning.
[DD] I would expect the RFC editor to queue this behind I-D.ietf-sfc= -nsh?
[DD] As for I-D.ietf-sfc-control-plane, if it is abandoned, we need to expl= ain some concepts within hSFC.

---

The introduction contains the reasonable note...
=C2=A0 =C2=A0 =C2=A0 Note: in this document, the notion of the "path&q= uot; of a packet is
=C2=A0 =C2=A0 =C2=A0 the series of SF instances traversed by a packet.=C2= =A0 The means of
=C2=A0 =C2=A0 =C2=A0 delivering packets between SFs (i.e., the forwarding m= echanisms
=C2=A0 =C2=A0 =C2=A0 enforced in the underlying network) are not relevant t= o the
=C2=A0 =C2=A0 =C2=A0 discussion.
Why, then, does the document go on to discuss SFFs?
[DD] We should choose whether to make this agnostic about technology= or embrace NSH.

---

We were explicitly told in the WG that an SFF cannot make assumptions
based on the transport tunnel used to deliver a packet to the SFF.

3.1.1 seems to be counter to this.

I would be happy to hear that 3.1.1 is a valid approach, but if so then
the WG needs to agree that an SFF *can* make determinations based on the transport tunnel. In particular, it can tell whether a packet has
arrived from another SFF, from an SF, or from a classifier.

[DD] It is intended that the packets are returned to the higher laye= r only at the *termination* of the lower-level chain. I think we can probab= ly clarify this better by saying the IBN is about classification and termin= ation (the start and end of chains), not the middle. Does that help?


---

It is all very well for section 3.1 to describe 5 perfectly achievable
approaches to hSFC, but in order to achieve interop, the head and tail
ends of a lower layer SFC need to use the same mechanism. That means
that the mechanism either has to be determined through the control plane or exposed by examination of the data plane. Furthermore, the
implication is that all implementations have to support all five
mechanisms.

Saying that this document "sets expectations for control planes" = is
all very well, but by keeping so many options and punting on the details you are making it unlikely that a workable solution will be
standardised.

Following the principle that "options are bad" can't we manag= e to cut
this list down to just one method (or worst case, two)?

Why do we need five mechanisms?
[DD] I wouldn't mind reducing this, but keep in mind that being = both the start and end of the sub-domain, the IBN actually do something pro= prietary. Perhaps we should be defining the schemes in terms of requirement= s at the SFs? (e.g., supporting nested NSH, respecting reserved metadata...= )=C2=A0 Maybe others can make suggestions.

(I note that option 3 is "free" with reclassification, while opti= on 4
is already defined in the NSH spec.)
[DD] I don't see the IBN as doing only "reclassification&qu= ot;. It is important that we view the sub-domain as being independently adm= inistered.

---

Section 9.2 seems to be out of date.
Indeed, some of the hSFC approaches here include "reclassification&quo= t; in
a way that would stop the SI being used to detect loops. So we need to
invoke the TTL. But how will the TTL be used? Will the lower layer SPF
inherit the TTL from the higher layer, or will it reset it? Will the
higher layer SFP be updated according to the TTL of the lower layer?
Can two lower layer SFPs be stitched together without a "hop" in = the
higher layer?

More work needed on loops, I think.
[DD] Waiting for I-D.ietf-sfc-nsh to be updated with the TTL. Yes, T= TL propagation rules would need to be defined.



> -----Original Message-----
> From: sfc [mailto:sfc-bounces@= ietf.org] On Behalf Of Joel M. Halpern
> Sent: 14 March 2017 18:30
> To: sfc@ietf.org
> Subject: [sfc] WG Last call - Hierarchical SFC
>
> This is a last call for:
> https://tools.ietf.org/html/draf= t-ietf-sfc-hierarchical-02
>
> Please respond to the list as to whether you see problems with this, y= ou
> think it is done, or any other input for the WG.
>
> Due to the run up to the IETF, we will let this run until April 7.

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

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

--001a114b2de411085b054b2e1f36-- From nobody Tue Mar 21 05:31:09 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B509129851 for ; Tue, 21 Mar 2017 05:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 YIOLx0iy_GXF for ; Tue, 21 Mar 2017 05:31:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FB2129810 for ; Tue, 21 Mar 2017 05:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3580; q=dns/txt; s=iport; t=1490099465; x=1491309065; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LPlh6wV+U1r+k3XtSvTV1E9sTtBuTpcVYKNACf8yDGE=; b=Eb6yHZ+MeR6IbwXnHdDFeKtPIFO6MOLUfeBtVjc1ZoNXxA7PQRb1DYGb nBRdirJs5RLAFTCCNNIh2clEQ5v/Wu0UncxAZaStlgV7WxJhEC4ggePxI prZyCEM3cG5kVJPc6O3OpcMBs8bM3U/Pgh2OSFLXvaN+YCdlEKDlR5nKi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAgDnG9FY/4sNJK1EGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNRYYEKB4NbihCRPx+IEo0ygg4qhXgCGoJxPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBIxFFBQsCAQgSBgICJgICAh8RFQIOAgQOBYlsAw0IDjGqH4Imh?= =?us-ascii?q?0ENgwQBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuFQ4IFCIJigTyBFUaBJxaDBi6?= =?us-ascii?q?CMQWJHRGHfIpqOgGOE4QygXuFKIoKimqIcwEfOBVvWBUYKREBhEUNEIFjdQETi?= =?us-ascii?q?CCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,198,1486425600"; d="scan'208";a="226001460" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2017 12:31:04 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2LCV3i1016359 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Mar 2017 12:31:04 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Mar 2017 08:31:03 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 21 Mar 2017 08:31:03 -0400 From: "Carlos Pignataro (cpignata)" To: RFC Errata System CC: "Joel M. Halpern" , Alia Atlas , Deborah Brungard , "Alvaro Retana (aretana)" , James N Guichard , "mphaneendra@gmail.com" , "sfc@ietf.org" Thread-Topic: [Technical Errata Reported] RFC7665 (4974) Thread-Index: AQHSojyHsWWY1YTYtkGdHTzXuUzu7qGffJeA Date: Tue, 21 Mar 2017 12:31:03 +0000 Message-ID: <29F54793-8F6B-450E-8927-C566623EBB09@cisco.com> References: <20170321121314.1D1F6B816C9@rfc-editor.org> In-Reply-To: <20170321121314.1D1F6B816C9@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.188] Content-Type: text/plain; charset="utf-8" Content-ID: <5706B86FC9976E4396BCC99C07364017@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] [Technical Errata Reported] RFC7665 (4974) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 12:31:07 -0000 SSBkbyBub3QgYmVsaWV2ZSB0aGlzIGVkaXQgaXMgbmVjZXNzYXJ5Lg0KDQpUaGUgc2VudGVuY2Ug c3RhcnRzIHdpdGgg4oCcQSBub24tZXhoYXVzdGl2ZSBsaXN04oCdLCB3aGljaCBzZXRzIHRoZSB0 b25lIGFuZCBjb250ZXh0IGZvciB0aGUgZW51bWVyYXRpb24gb2YgYWJzdHJhY3Qgc2VydmljZSBm dW5jdGlvbnMuDQoNClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg0KPiBPbiBNYXIgMjEsIDIwMTcs IGF0IDg6MTMgQU0sIFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3Jn PiB3cm90ZToNCj4gDQo+IFRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJt aXR0ZWQgZm9yIFJGQzc2NjUsDQo+ICJTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIEFy Y2hpdGVjdHVyZSIuDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCj4gaHR0cDovL3d3 dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9NzY2NSZlaWQ9NDk3NA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVHlwZTogVGVjaG5p Y2FsDQo+IFJlcG9ydGVkIGJ5OiBQaGFuZWVuZHJhIE1hbmRhIDxtcGhhbmVlbmRyYUBnbWFpbC5j b20+DQo+IA0KPiBTZWN0aW9uOiAxLjQNCj4gDQo+IE9yaWdpbmFsIFRleHQNCj4gLS0tLS0tLS0t LS0tLQ0KPiBPbmUgb3IgbW9yZSBzZXJ2aWNlIGZ1bmN0aW9ucyBjYW4gYmUgaW52b2x2ZWQgaW4g dGhlIGRlbGl2ZXJ5IG9mDQo+IGFkZGVkLXZhbHVlIHNlcnZpY2VzLiAgQSBub24tZXhoYXVzdGl2 ZSBsaXN0IG9mIGFic3RyYWN0IHNlcnZpY2UNCj4gZnVuY3Rpb25zIGluY2x1ZGVzOiBmaXJld2Fs bHMsIFdBTiBhbmQgYXBwbGljYXRpb24gYWNjZWxlcmF0aW9uLA0KPiBEZWVwIFBhY2tldCBJbnNw ZWN0aW9uIChEUEkpLCBMYXdmdWwgSW50ZXJjZXB0IChMSSksIHNlcnZlciBsb2FkDQo+IGJhbGFu Y2luZywgTkFUNDQgW1JGQzMwMjJdLCBOQVQ2NCBbUkZDNjE0Nl0sIE5QVHY2IFtSRkM2Mjk2XSwN Cj4gSE9TVF9JRCBpbmplY3Rpb24sIEhUVFAgSGVhZGVyIEVucmljaG1lbnQgZnVuY3Rpb25zLCBh bmQgVENQDQo+IG9wdGltaXplci4NCj4gDQo+IENvcnJlY3RlZCBUZXh0DQo+IC0tLS0tLS0tLS0t LS0tDQo+IE9uZSBvciBtb3JlIHNlcnZpY2UgZnVuY3Rpb25zIGNhbiBiZSBpbnZvbHZlZCBpbiB0 aGUgZGVsaXZlcnkgb2YNCj4gYWRkZWQtdmFsdWUgc2VydmljZXMuICBBIG5vbi1leGhhdXN0aXZl IGxpc3Qgb2YgYWJzdHJhY3Qgc2VydmljZQ0KPiBmdW5jdGlvbnMgaW5jbHVkZXM6IGZpcmV3YWxs cywgV0FOIGFuZCBhcHBsaWNhdGlvbiBhY2NlbGVyYXRpb24sDQo+IERlZXAgUGFja2V0IEluc3Bl Y3Rpb24gKERQSSksIExhd2Z1bCBJbnRlcmNlcHQgKExJKSwgc2VydmVyIGxvYWQNCj4gYmFsYW5j aW5nLCBOQVQ0NCBbUkZDMzAyMl0sIE5BVDY0IFtSRkM2MTQ2XSwgTlBUdjYgW1JGQzYyOTZdLA0K PiBIT1NUX0lEIGluamVjdGlvbiwgSFRUUCBIZWFkZXIgRW5yaWNobWVudCBmdW5jdGlvbnMsIFRD UA0KPiBvcHRpbWl6ZXIsIFBhcmVudGFsIGNvbnRyb2wgZXRjLg0KPiANCj4gTm90ZXMNCj4gLS0t LS0NCj4gUGFyZW50YWwgY29udHJvbCBjYW4gYmUgYWRkZWQgaW4gdGhlIG5vbi1leGhhdXN0aXZl IGxpc3Qgb2YgYWJzdHJhY3Qgc2VydmljZSBmdW5jdGlvbnMuIEFsc28gdGhpcyBsaXN0IGNhbm5v dCBiZSBmaXhlZCwgc28gZXRjIGFuIGJlIGFkZGVkIGF0IHRoZSBlbmQgb2YgdGhlIGxpc3QuDQo+ IA0KPiBJbnN0cnVjdGlvbnM6DQo+IC0tLS0tLS0tLS0tLS0NCj4gVGhpcyBlcnJhdHVtIGlzIGN1 cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UNCj4gdXNl ICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVyaWZpZWQgb3IN Cj4gcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBh cnR5ICANCj4gY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVw b3J0LCBpZiBuZWNlc3NhcnkuIA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gUkZDNzY2NSAoZHJhZnQtaWV0Zi1zZmMtYXJjaGl0ZWN0dXJlLTExKQ0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUaXRsZSAgICAgICAgICAg ICAgIDogU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmUNCj4gUHVi bGljYXRpb24gRGF0ZSAgICA6IE9jdG9iZXIgMjAxNQ0KPiBBdXRob3IocykgICAgICAgICAgIDog Si4gSGFscGVybiwgRWQuLCBDLiBQaWduYXRhcm8sIEVkLg0KPiBDYXRlZ29yeSAgICAgICAgICAg IDogSU5GT1JNQVRJT05BTA0KPiBTb3VyY2UgICAgICAgICAgICAgIDogU2VydmljZSBGdW5jdGlv biBDaGFpbmluZw0KPiBBcmVhICAgICAgICAgICAgICAgIDogUm91dGluZw0KPiBTdHJlYW0gICAg ICAgICAgICAgIDogSUVURg0KPiBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KDQo= From nobody Tue Mar 21 07:16:37 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4668712997E; Tue, 21 Mar 2017 07:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X_hdLTn8d42; Tue, 21 Mar 2017 07:16:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19465129975; Tue, 21 Mar 2017 07:16:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1482CB81D3C; Tue, 21 Mar 2017 07:16:19 -0700 (PDT) To: mphaneendra@gmail.com, jmh@joelhalpern.com, cpignata@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: akatlas@juniper.net, iesg@ietf.org, sfc@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170321141619.1482CB81D3C@rfc-editor.org> Date: Tue, 21 Mar 2017 07:16:19 -0700 (PDT) Archived-At: Subject: [sfc] [Errata Rejected] RFC7665 (4974) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 14:16:31 -0000 The following errata report has been rejected for RFC7665, "Service Function Chaining (SFC) Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7665&eid=4974 -------------------------------------- Status: Rejected Type: Technical Reported by: Phaneendra Manda Date Reported: 2017-03-21 Rejected by: Alia Atlas (IESG) Section: 1.4 Original Text ------------- One or more service functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, and TCP optimizer. Corrected Text -------------- One or more service functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, TCP optimizer, Parental control etc. Notes ----- Parental control can be added in the non-exhaustive list of abstract service functions. Also this list cannot be fixed, so etc an be added at the end of the list. --VERIFIER NOTES-- The list specifically says that it is non-exhaustive. Adding more examples and an etc is not needed. -------------------------------------- RFC7665 (draft-ietf-sfc-architecture-11) -------------------------------------- Title : Service Function Chaining (SFC) Architecture Publication Date : October 2015 Author(s) : J. Halpern, Ed., C. Pignataro, Ed. Category : INFORMATIONAL Source : Service Function Chaining Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Mar 21 11:44:45 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC70129C6E for ; Tue, 21 Mar 2017 11:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 huxizlU231jc for ; Tue, 21 Mar 2017 11:44:42 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 612F812778D for ; Tue, 21 Mar 2017 11:44:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 477C8A200B9 for ; Tue, 21 Mar 2017 11:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1490121881; bh=WBt5Y5Q+28A8QNXkqbe4xGGxUgLtmFTroQ04qmAPOoc=; h=To:From:Subject:Date:From; b=rLHFyhoJLRIqCUa86rX01tRijuND7mx++277qiVa3ZxP0TKeNSnw58Cd/QCw45uWp /8HNXbNNJeGrMc/+QQN2705kol/dZn+aLj1op5ggaQtzAGDiRjf0e2YSSXneqXD5xv g3BaeS0eIBtZbXkmt0V3Rl8+qgvUH65wvre2bWKk= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E73A7A200BB for ; Tue, 21 Mar 2017 11:44:40 -0700 (PDT) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Tue, 21 Mar 2017 14:44:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Chicago Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 18:44:44 -0000 As you can see at https://www.ietf.org/proceedings/98/agenda/agenda-98-sfc-01 We have posted the proposed agenda, giving time to all those who asked. This is a very light agenda. If there are other topics that the WG would benefit from seeing presented, please let us know. We also have time for discussion on open issues in front of the working group. If there are other topics folks feel we should discuss, it would be helpful to know in advance (but not required.) Yours, Joel From nobody Wed Mar 22 08:07:08 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9DA12989F for ; Wed, 22 Mar 2017 07:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_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 WpGMl1BoqWt3 for ; Wed, 22 Mar 2017 07:28:39 -0700 (PDT) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (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 1DB8C12426E for ; Wed, 22 Mar 2017 07:28:39 -0700 (PDT) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP; 22 Mar 2017 07:28:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,205,1486454400"; d="scan'208";a="79841308" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by fmsmga006.fm.intel.com with ESMTP; 22 Mar 2017 07:28:37 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by irsmsx110.ger.corp.intel.com (163.33.3.25) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 22 Mar 2017 14:28:14 +0000 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.107]) by irsmsx111.ger.corp.intel.com ([169.254.2.242]) with mapi id 14.03.0248.002; Wed, 22 Mar 2017 14:28:14 +0000 From: "Duarte Cardoso, Igor" To: "Paul Quinn (paulq)" , Adrian Farrel CC: "sfc@ietf.org" Thread-Topic: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt Thread-Index: AdKRRHVLY7SkxborSRGHk+YoYh/yhAQiDDYAAFLY2NA= Date: Wed, 22 Mar 2017 14:28:14 +0000 Deferred-Delivery: Wed, 22 Mar 2017 14:27:41 +0000 Message-ID: References: <027d01d29144$d743bcb0$85cb3610$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmFkNWNkNWUtODE3Yi00MDhjLWJlMDQtNGUyYzdkZjc1NWZlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJuWVprZVljMVlQUzNjb2ZMWHEwOGpUa25pY21ZYlQ0SFJEODdxV2gyVmJvPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 14:28:44 -0000 Hi SFC WG, I have some trivial corrections to suggest about the latest draft: After page 18, line 25: Replace "invalid service function path" with "invalid service function pat= hs" Replace "discarded" with "discarded." After page 24, line 6: Replace "the confidentially (and other security) considerations are met" w= ith "confidentiality (and other security) considerations are met" after 27, line 8: Replace "NSH metadata authenticity and confidentially" with "NSH metadata = authenticity and confidentiality" Best regards, Igor. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Monday, March 20, 2017 5:53 PM To: Adrian Farrel Cc: sfc@ietf.org Subject: Re: [sfc] Detailed review of draft-ietf-sfc-nsh-12.txt Hi Adrian, > On Feb 27, 2017, at 4:59 PM, Adrian Farrel wrote: >=20 > Hi all, >=20 > Many thanks to Paul for the updated revision. This makes life a lot=20 > easier. >=20 > Herewith a review. I suspect some points I've raised are tracked in=20 > email threads or tickets, or in the minutes from the interim. That's > OK: I just read and scribbled in a continuous stream of consciousness. >=20 > A bit of a wood/trees scenario here and I can't promise I have caught=20 > every concern on this pass. >=20 > Thanks to all for the work that has gone before and which makes this=20 > detailed review possible. >=20 Again, thank you for the great review! =20 > Cheers, > Adrian >=20 > --- >=20 > Requirements Language should not show as a numbered section. > If you're using XML use within rather than
. >=20 > --- >=20 > NSH needs to be expanded on first use in the body of the document (in=20 > the Introduction). >=20 > --- >=20 > Throughout the document you need to look at the use of "NSH". It is=20 > often missing an article (sometimes definite, sometimes indefinite). >=20 > --- PQ> Will update accordingly. =20 >=20 > In section 2 >=20 > NSH defines a new service plane protocol specifically for the > creation of dynamic service chains and is composed of the following > elements: >=20 > 1. Service Function Path identification >=20 > 2. Transport independent service function chain >=20 > 3. Per-packet network and service metadata or optional variable > type-length-value (TLV) metadata. >=20 > Not sure about the middle of these 3. Isn't that a feature (which is=20 > fine to talk about somewhere) not one of the components? I think the=20 > component missing from the list is the SI. So you might write: PQ> That's a fair point, so, for #2, perhaps: 2. Indication of location within a Service Function Path. =20 I think the concept of location is more accurate than progress. >=20 > 2. Indication of the progress along the Service Function Path. >=20 > And I have some trouble parsing the third item. I think you mean=20 > network and service metadata that is per-packet (although that is=20 > perhaps a given as the NSH is also per packet). And I think you mean=20 > that the metadata is optional, fixed length, or TLV-based. How about: >=20 > 3. Network and service metadata that may be optionally included > per packet and that may be fixed length or constructed from > type-length-value objects (TLVs). >=20 PQ> Let's simplify even more:=20 3. Optional, per packet metadata (fixed length or TLV). > --- >=20 > Why do you point to 7665 for the definition of "Classifier" but then=20 > define "Service Classifier" to mean (AFAICS) exactly the same thing? >=20 > --- PQ> The definition in NSH provides important NSH-centric details that aren= 't in 7665. =20 >=20 > In 2.3 I think point 4 is a use case of metadata and so should be part=20 > of point 3. >=20 PQ> That works for me. > --- >=20 > 3.1 > s/draft/document/ >=20 > --- PQ> Thanks. >=20 > Wondering whether "Context Headers" should be "Context Header" > throughout. >=20 PQ> Given that we've merged the figure into one "blob" this probably makes= sense. > --- >=20 > 3.1 >=20 > An NSH is composed of a 4-byte (all references to bytes in this draft > refer to 8-bit bytes, or octets) Base Header, a 4-byte Service Path > Header and Context Headers, as shown in Figure 1 below. >=20 > s/and Context/and optional Context/ >=20 > --- >=20 > 3.1 > Service Path Header: provide path identification and location within >=20 > s/provide/provides/ >=20 > --- PQ> Done. >=20 > 3.2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Obviously, we have discussed the reformatting of the Base Header and=20 > ended up with >=20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Ver|O| TTL | Length |R|R|R|R|MD Type| Next Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > Need to: > - Add a description of the TTL field (lots of mailing list discussion) PQ> AFAIK, the chairs haven't called consensus here. Once they convey tha= t, we'll update accordingly. > - Delete the C-bit PQ> I just saw consensus around that, so the next version will reflect the= change. > - Update the descriptions of Reserved bits > - Update the description of MD Type PQ> I believe you mean the updates that reflect TTL if/when added? =20 >=20 > --- >=20 > 3.2 >=20 > Version: The version field is used to ensure backward compatibility > going forward with future NSH updates. It MUST be set to 0x0 by the > sender, in this first revision of NSH. Given the widespread > implementation of existing hardware that uses the first nibble after > an MPLS label stack for ECMP decision processing, this document > reserves version 01 and this value MUST NOT be used in future > versions of the protocol. Please see [RFC7325] for further > discussion of MPLS-related forwarding requirements. >=20 > I believe this text is presuming the NSH-in-MPLS encapsulation. I=20 > don't think it should do that, but if it does we have to look at the=20 > first nibble not just the first two bits. >=20 > Now, as 4385 points out, if the first nibble is 4 or 6, IPv4 or IPv6=20 > will be assumed. So 0b0100 or 0b0110 accounts for you reserving=20 > version > 1 (just in case the C bit is 0 and for any value of the O bit). So=20 > far, so good! >=20 > But 4385 defines a first nibble of 0000 to mean "here is a control word" > and that would mean you needed to reserve version 0 as well :-( >=20 > So my advice here would be that encapsulation in MPLS is not in scope=20 > for this document, and you should not play with reserving version=20 > numbers. PQ> That is where we started, but there was a lot of discussion on the lis= t about the potential for conflict. I have to go dig up the threads but I'= m hoping that some of the folks who expressed concern here will weigh in. >=20 > --- >=20 > 3.2 >=20 > There's been a long thread on the text about the O-bit. >=20 > O bit: Setting this bit indicates an Operations, Administration, and > Maintenance (OAM) packet. The actual packet format and processing of > SFC OAM messages is outside the scope of this specification (see [I- > D.ietf-sfc-oam-framework]). >=20 > First para OK. >=20 > SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC > OAM procedures, SHALL discard packets with O-bit set. >=20 > SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable > parameter to enable forwarding received SFC OAM packets unmodified to > the next element in the chain. Such behavior may be acceptable for a > subset of OAM functions, but can result in unexpected outcomes for > others, thus it is recommended to analyze the impact of forwarding an > OAM packet for all OAM functions prior to enabling this behavior. > The configurable parameter MUST be disabled by default. >=20 > These paras are controversial as discarding OAM packets (rather than=20 > passing them through) can also result in unexpected outcomes.=20 > Consider, if you will, simple end-to-end ping functions. >=20 > (Also s/Classifer/Classifier/ twice) >=20 > There is also a mismatch of "SHALL" and "MAY". >=20 > I would like this text to read... >=20 > =3D=3D=3D > SF/SFF/SFC Proxy/Classifer implementations that do not support SFC > OAM procedures, SHALL ignore the setting of the O-bit and SHALL > attempt to process the packet as normal. > =3D=3D=3D >=20 > ...but I could live with... >=20 > =3D=3D=3D =20 > SF/SFF/SFC Proxy/Classifer implementations that do not support SFC > OAM procedures SHOULD discard packets with O-bit set, but MAY > support a configurable parameter to enable forwarding received SFC > OAM packets unmodified to the next element in the chain. > =3D=3D=3D >=20 PQ> I can live with this as well, however, I think we need to chairs to ma= ke a final call about how the WG has opted to move forward wrt OAM. > For non OAM packets, the O-bit MUST be cleared and MUST NOT be > modified along the SFP. >=20 > This paragraph needs simple clarification as follows >=20 > =3D=3D=3D=20 > The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM > packets. The O-bit MUST NOT be modified along the SFP. > =3D=3D=3D >=20 > --- >=20 > 3.2 >=20 > C-bit is being retired as discussed. >=20 > --- >=20 PQ> Indeed. > 3.2 >=20 > Length: total length, in 4-byte words, of NSH including the Base > Header, the Service Path Header and the context headers or optional > variable length metadata. The Length MUST be of value 0x6 for MD > Type equal to 0x1 and MUST be of value 0x2 or greater for MD Type > equal to 0x2. The NSH header length MUST be an integer number of 4 > bytes. The length field indicates the "end" of NSH and where the > original packet/frame begins. >=20 > There is no "or optional variable length metadata." That is exactly=20 > what the context headers are, and the context headers are optional.=20 > And the last sentence is a little too much. So... PQ> We tried to draw a distinction between the mandatory fixed vs. tlv hea= ders. I can see how it's not clear in the above text. >=20 > Length: total length, in 4-byte words, of the NSH including the Base > Header, the Service Path Header, and any Context Headers. It the=20 > MD Type is 0x1, the Length MUST be 0x6. If the MD Type is 0x2, the > Length MUST be 0x2 or greater. The actual NSH header length MUST be > an integer multiple of 4 bytes and is padded if necessary.=20 >=20 PQ> That works for me. > --- >=20 > 3.2 >=20 > MD Type: indicates the format of NSH beyond the mandatory Base Header > and the Service Path Header. MD Type defines the format of the > metadata being carried. Please see IANA Considerations section > below. >=20 > Maybe "...indicates the format of the metadata carried in the Context=20 > Headers..." PQ> I think the current text is more explicit. Do you have a specific con= cern? >=20 > NSH defines two MD types: >=20 > s/NSH/This document/ > s/types/Type values/ PQ> Will update accordingly. >=20 > 0x1 - which indicates that the format of the header includes fixed > length context headers (see Figure 4 below). >=20 > 0x2 - which does not mandate any headers beyond the Base Header and > Service Path Header, but may contain optional variable length context > information. >=20 > Add "...not defined in this specification." >=20 PQ> Will update. > --- >=20 > 3.2 >=20 > Next Protocol: indicates the protocol type of the encapsulated data. > NSH does not alter the inner payload, and the semantics on the inner > protocol remain unchanged due to NSH service function chaining. > Please see IANA Considerations section below. >=20 > s/due to/by/ >=20 > This draft defines the following Next Protocol values: >=20 > s/draft/document/ >=20 > 0x1 : IPv4 > 0x2 : IPv6 > 0x3 : Ethernet > 0x4: NSH > 0x5: MPLS >=20 > Fix formatting >=20 > 0x6-0xFD: Unassigned > 0xFE-0xFF: Experimental >=20 > Suggest to delete the last two lines as they are not protocols, but=20 > info for the IANA Considerations section. PQ> Will update to reflect all of the above. >=20 > --- >=20 > 3.3 >=20 > Service Path Identifier (SPI): identifies a service path. > Participating nodes MUST use this identifier for Service Function > Path selection. The initial classifier MUST set the appropriate SPI > for a given classification result. >=20 > Both uses of "MUST" are unnecessary and the words could be deleted=20 > without loss of meaning or tightness of specification. PQ> New text: Service Path Identifier (SPI): identifies a service path. Participating nodes use this identifier for Service Function Path selection. The initial classifier MUST set the appropriate SPI for a given classification result. >=20 > --- >=20 > 3.3 >=20 > Service Index (SI): provides location within the SFP. The initial > classifier for a given SFP SHOULD set the SI to 255, however the > control plane MAY configure the initial value of SI as appropriate > (i.e. taking into account the length of the service function path). > Service Index MUST be decremented by Service Functions or by SFC > Proxy nodes after performing required services and the new > decremented SI value MUST be used in the egress NSH packet. The > initial Classifier MUST send the packet to the first SFF in the > identified SFP for forwarding along an SFP. If re-classification > occurs, and that re-classification results in a new SPI, the > (re)classifier is, in effect, the initial classifier for the > resultant SPI. >=20 > What you are saying, I think is that the initial classifier MUST set=20 > the SI equal to the first SI in the SFP. This SHOULD be 255, but an=20 > SFP MAY be configured to start at a lower SI value. PQ> Correct. >=20 > s/decremented/decremented by one/ (reference the endless email=20 > threads) >=20 PQ> Will be updated. > --- >=20 > 3.3 >=20 > SI SHOULD be used in conjunction with Service Path Identifier for > Service Function Path Selection and for determining the next SFF/SF > in the path. >=20 > What is the variation to this "SHOULD"? PQ> I suspect this is a vestige from an earlier option where the path ID w= as considered sufficient in some cases: a SFF could, in principle, use the = path ID to select the next SFF if, for example, there were no SFs, or could= opt to send packets to a re-classifier based on path alone. Having said t= hat, I'm not sure there's much need to those cases. Do others? >=20 > In addition to indicating > the location within a Service Function Path, SI can be used for > service plane loop detection. >=20 > I think that, although this might still be true, the TTL will be more=20 > helpful for loop detection and we should strike this text. >=20 PQ> Once we finalize the TTL details, I agree this'll be cleaned up. > --- >=20 > 3.4 > I suggest deleting Figure 4. It does not differ from the information=20 > in Figures 1, 2, and 3, and risks not being kept up-to-date with those=20 > figures. >=20 > OTOH, you should say here that Length has a specific value. >=20 PQ> I think figure 4 provides a very concrete representation of a type-1 h= eader so it probably makes sense to keep it. I do agree: length should ref= lect the specific value. > --- >=20 > 3.4 >=20 > When the Base Header specifies MD Type =3D 0x1, four Context Headers, > 4-byte each, MUST be added immediately following the Service Path > Header, as per Figure 4. Context Headers that carry no metadata MUST > be set to zero. >=20 > I think this is adding new and strange meaning to "Context Header". > See previous comments, but why is a Context Header suddenly a 4-byte=20 > thing? Why is this not 3 3-byte Context Headers followed by 1 7-byte=20 > Context Header? Or more realistically, why not just talk about "Up to > 16 bytes of metadata carried in the 16 byte Context Header that=20 > follows the Base Header. Any context Header bytes not used to carry=20 > metadata MUST be set to zero." PQ> This text should have been changed, it's out of date. We've moved to = a single 16 byte "blob" -- as per figure 4 -- and this text should reflect = that. >=20 > --- >=20 > 3.4 >=20 > OLD > This specification does not make any assumption about the content > placed in the mandatory context field of the NSH header, and does not > describe the structure or meaning of the included metadata. > NEW > This specification does not make any assumptions about the content of > the 16 byte Context Header that must be present when the MD Type=20 > field is set to 1, and does not describe the structure or meaning of > the included metadata. > END >=20 PQ> New text will be added. > --- >=20 > 3.4 >=20 > Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is > configured for mandatory use of metadata but does not yet receive the > data semantics for the mandatory context field, it MUST NOT process > the packet and MUST log at least once per the SPI for which a > mandatory metadata is missing. >=20 > There seem to be some assumptions here: > - An SF having mandatory use of metadata is a config item and can't be =20 > an implementation thing (i.e., you are not allowing an SF that must =20 > always use metadata). PQ> The text covers the case where the SF needs metadata (let's say for=20 PQ> policy enforcement) but does not (yet) know how to parse the metadata. I don't see any implication on config vs = implementation. =20 > - You are assuming that the semantics for the metadata are always =20 > dynamically installed in the SF and not known a priori. >=20 PQ> There was no intent to imply that, perhaps the easiest way to=20 PQ> clarify: "...not yet receive..." --> "...not yet know..." (or=20 PQ> something similar) > I don't think you should make those restrictions (although, obviously,=20 > we should allow them as options). >=20 > You also seem to be assuming that a non-SFC-aware SF can receive a=20 > packet with an NSH and metadata and will somehow manage to parse the=20 > NSH and find the metadata that it doesn't understand. Frankly, I think=20 > this document talks only about SFC-aware SFs and SFC proxies. Other=20 > SFs are by definition not in scope as they will never receive an NSH=20 > (except for a bug that will reasonably cause the SF to drop the packet - = or crash). >=20 PQ> I don't see that conveyed. The text is just unambiguous about an SFC-= SF. It makes not claims about others. =20 > Finally "must not process" is ambiguous. I think you mean "must discard" >=20 PQ> Fair point. > So, maybe... >=20 > An SF or SFC Proxy that does not know the format or semantics of the=20 > Context Header for an NSH with MD Type 1 MUST discard any packet with > such an NSH (i.e., MUST NOT ignore the metadata that it cannot=20 > process), and MUST log the event at least once per the SPI for which > the event occurs (subject to thresholding). PQ> This works for me. >=20 > --- >=20 > 3.5 >=20 > Again, Figure 5 is de trop.=20 > You also need to discuss the value of the Length field. PQ> Again, I think being explicit with figures helps the reader. Updating= length field makes sense.=20 >=20 > --- >=20 > 3.5 >=20 > This section has the usual confusion of whether there are multiple=20 > context headers (each of variable length), multiple variable length=20 > metadata, a single variable length context header (also called a=20 > variable context header) containing metadata, or whatever. >=20 PQ> I re-read it several times, and although it's a bit clumsy, I'm not su= re it's confusing. > Figure 6, for example, shows one piece of variable length metadata in=20 > an encoding element labelled "Variable Context Headers". PQ> I agree, I'll update the figure to show a better representation of the = structure. That will probably help with the 3.5 text. >=20 > This is made more confusing in the context of 3.4 where you have the=20 > concept of 4 byte context headers. >=20 > Later, in 3.5.1, you call it a TLV. >=20 > I wish we could sort out this language. >=20 > I think what you are trying to say is that the Context Header=20 > (singular) can contain zero, one, or multiple metadata elements each=20 > encoded as a TLV as shown in Figure 6. >=20 > --- PQ> I'll take a pass at cleaning it up. >=20 > 3.5.1 >=20 > Discussions on the list about the sizing of the Metadata Class and=20 > Type fields, the deprecation of the C-bit, the naming of the Type=20 > field (which looks like Metadata Type which is easily confused with MD=20 > Type), and the deprecation of the split ranges of the Type field. >=20 > --- PQ> Yup, will update accordingly once we finish the discussions. >=20 > 3.5.1 >=20 > If multiple instances of the same TLV are included in an NSH packet, > but the definition of that TLV does not allow for it, the SFC-aware > SF MUST NOT process the packet and MUST log at least once per the SPI > for which multiple instances of that TLV is supplied. >=20 > This is OK, but I prefer the more usual (and future-proof)... >=20 > If multiple instances of the same TLV are included in an NSH packet, > but the definition of that TLV does not allow for it, the SFC-aware > SF MUST process first instance and ignore subsequent instances. >=20 > --- PQ> Barring objection from the list, that's fine with me. >=20 > 4. >=20 > NSH-aware nodes are the only nodes that MAY alter the content of the > NSH headers. >=20 > s/MAY/may/ PQ> Thanks. >=20 > Is there a difference between an "SFC-aware node" and an "NSH-aware=20 > node"? >=20 > Isn't this sentence silly? "Only nodes that can understand the content=20 > of the NSH can change the content of the NSH" >=20 PQ> I agree. Barring objection, will remove. > --- >=20 > 4. > Bullet 1 >=20 > OLD > At the end of a service function path, a SFF, MUST be > the last node operating on the service header and MUST remove it. > NEW > At the end of a service function path, a SFF, MUST be > the last node operating on the service header and MUST remove it > before forwarding or delivering the encapsulated packet. > END >=20 PQ> I think that's a good clarification but I fear the last part is confus= ing since I think of post-NSH the packet being un-encapsulated (unless I'm = missing something you are trying to convey): "...and MUST remove it before forwarding or delivering the un-encapsulated= packet." > --- >=20 > 4. > Bullet 1 >=20 > Multiple logical classifiers may exist within a given service > path. >=20 > How so "logical"? Are they or are they not "classifiers"? > (Multiple occurrences in this bullet.) PQ> Logical in the sense that they need not be distinct classifiers. We'v= e been consistent with the concept that classifiers, SFFs, etc. are logical= : they can be co-mingled or distinct. =20 >=20 > --- >=20 > 4. > Bullet 1 >=20 > OLD > Non-initial classifiers may re-classify data and that re- > classification MAY result in a new Service Function Path. > NEW > Non-initial classifiers may re-classify data and that re- > classification MAY result in a the packet being assigned to a > different Service Function Path. > END PQ> Minor tweak: Non-initial classifiers may re-classify data and that re-classification MA= Y result in the selection a different Service Function Path. >=20 > --- >=20 > 4. >=20 > 2. Select service path: The Service Path Header provides service > chain information and is used by SFFs to determine correct > service path selection. SFFs MUST use the Service Path Header > for selecting the next SF or SFF in the service path. >=20 > It is probably a minor point, but the Service Path Header provides=20 > service *path* information and not service chain information. >=20 PQ> Worth fixing, thanks. > --- >=20 > 4. >=20 > 3. Update NSH: NSH-aware service functions (SF) MUST decrement the > service index. If an SFF receives a packet with an SPI and SI > that do not correspond to a valid next hop in a valid Service > Function Path, that packet MUST be dropped by the SFF. >=20 > Non-NSH-aware SFs will, of course, either not see NSHs or barf. So it=20 > is enough to say "SFs" (you have already defined the abbreviation). >=20 > Say "decrement the service index by one". >=20 PQ> Thanks. > --- >=20 > 4. > Bullet 3 >=20 > Classifier(s) MAY update Context Headers if new/updated context > is available. >=20 > s/Classifier(s)/Classifiers/ >=20 PQ> Will update. > --- >=20 > 4. > Bullet 3 >=20 > If an SFC proxy is in use (acting on behalf of a non-NSH-aware > service function for NSH actions), then the proxy MUST update > Service Index and MAY update contexts. When an SFC proxy > receives an NSH-encapsulated packet, it MUST remove the NSH > headers before forwarding it to an NSH unaware SF. When the SFC > Proxy receives a packet back from an NSH unaware SF, it MUST re- > encapsulates it with the correct NSH, and MUST decrement the > Service Index. >=20 > I think "update contexts" means "update the metadata carried in the=20 > Context Header. This does not say whether a proxy can add a Context=20 > Header if one is not already present, or whether it can add a metadata=20 > TLV, or remove one. >=20 PQ> Correct, this means update the existing contexts. I believe we decided= that only classifiers can add/remove (but as per a point above, those clas= sifiers are logical and can be "part' of an SF). I need to go back and che= ck the archives. Joel might remember since I think we talked about it. > Decide on "non-NSH-aware", "NSH unaware", "non-SFC-aware". >=20 > Say "decrement the service index by one". PQ> Will update. >=20 > --- >=20 > 4. >=20 > 4. Service policy selection: Service Function instances derive > policy (i.e. service actions such as permit or deny) selection > and enforcement from the service header. Metadata shared in the > service header can provide a range of service-relevant > information such as traffic classification. Service functions > SHOULD use NSH to select local service policy. >=20 > "Service Function instance" is not properly defined in 7665 and not=20 > previously mentioned in this document. OTOH, the term could usefully=20 > be used in 7.1 para 2. PQ> I think we can simplify and change service function instance to servic= e function. =20 >=20 > s/service header/NSH/ (twice) PQ> Thanks. >=20 > Does the last sentence add anything? It appears to say what the=20 > previous sentences say, but the "SHOULD" is ambiguous. Suggest deleting i= t. PQ> Perhaps remove it, and beef up the first a bit. Let me fiddle with it= . >=20 > --- >=20 > In Figure 8 >=20 > - "Select Service Function Path" is ambiguous. Isn't the SFF bound by =20 > the SPI and so cannot select the path, only use the one it is =20 > instructed to use? OTOH, the Classifier is responsible for determining =20 > which path to use. PQ> That's a fair point. The intent was to convey the forwarding aspect o= f the SFF. Update: "Forward NSH Packets" >=20 > - Surely the SFC proxy can update the Context Header as in bullet 3, =20 > above. >=20 PQ> Yes. > - Might an SFC proxy also select service policy for an NSH-unaware SF? PQ> I'm not sure what you mean. The proxy maps the packet to a local conn= ection. The proxy doesn't have any service policy insight. >=20 > --- >=20 > 5. >=20 > The presence of NSH is > indicated via protocol type or other indicator in the outer > encapsulation. >=20 > You are prejudging the "encapsulation of NSH" work that is to be done. > You may be largely correct, but not always. We should omit this text. PQ> Must there not be some form of indicator -- explicit or otherwise? >=20 > --- >=20 > 7.1 >=20 > This indirection -- path ID to overlay -- creates a true service > plane. That is the SFF/SF topology is constructed without impacting > the network topology but more importantly service plane only > participants (i.e. most SFs) need not be part of the network overlay > topology and its associated infrastructure (e.g. control plane, > routing tables, etc.). As mentioned above, an existing overlay > topology may be used provided it offers the requisite connectivity. >=20 > There is a lot hidden or implied in this paragraph. But consider an SF=20 > that is somehow remote from the SFF. The SFF knows how to send to the=20 > SF over the underlay network. But does the SF know how to send back to=20 > the SFF? In some underlay technologies you can just reverse the=20 > encapsulation addresses. In others, you can't. >=20 > Perhaps the relationship between SF and SFF is configured (i.e., known=20 > a priori)? >=20 > Now consider an SF that is used on multiple SFPs. And consider further=20 > that the SF might be reachable from different SFFs on the different=20 > SFPs. Now selecting the return path becomes a challenge. >=20 > Maybe "most SFs" is the clue. Maybe "some SFs" participate in the=20 > control plane and routing tables. >=20 > Perhaps this could be clearer. PQ> We can add something down the lines of: SF need to be able to return a= packet to the appropriate SFF when service processing is complete. This c= an be via the over or under-lay and in some case require additional configu= ration on the SF. >=20 > --- >=20 > 8.1 >=20 > NSH > itself does not provide privacy functions, rather it relies on the > transport/overlay layer. An operator can select the appropriate > transport to ensure the confidentially (and other security) > considerations are met. >=20 > I think you are making a big leap to decide what the metadata=20 > documents will define. >=20 PQ> See below. > You are also failing to consider metadata that needs to be kept=20 > private between the SF at SI 250 and the SF at SI 240 when there are=20 > other SFs in between. PQ> I don't think that's prohibited in the text above: pick the right tran= sport. >=20 > I suggest replacing this paragraph with something like... >=20 > This specification does not provide any privacy or security functions=20 > for the NSH. Hop-by-hop security and privacy can be achieved by using > features of the underlay (transport) connections. Metadata privacy=20 > and security considerations are a matter for the documents that=20 > define metadata formats, encodings, and TLVs. PQ> I'm fine with the last sentence. >=20 > --- >=20 > 8.2 >=20 > Why do you not consider imposing metadata at a subsequent point along=20 > the path? This would happen, for example, if one SF needed to convey=20 > information to another SF for a packet that did not already have=20 > metadata. PQ> We do, it's a core use case and depicted in figure 15 and described in= 8.2, bullet 1. >=20 > --- >=20 > 12 >=20 > Obviously the IANA stuff needs updating to reflect changes elsewhere: >=20 > 12.2.1 The C bit has gone and the reserved bits have moved. >=20 > 12.2.2 See my comment on section 3.2 >=20 > 12.2.3 The size of the MD Type registry is reduced. > Allowing one experimental code point looks like enough to me. >=20 PQ> Will update all three. > 12.2.4 There is a thread about this. > The registry has to indicate that MD Class 0 has been assigned > by this document for "IETF use". > The advice to DEs needs to be supplied. > The size of the range of classes may be reduced to allow an=20 > increase in the number of "types" >=20 > Missing registry for "types" within the MD Class 0 > The same thread applies. > (I recall there was also action from the interim) > The registry will be empty but should be created in this doc > The name of this registry is confusable with "MD type" > The size of the range may be increases as the MD class range is > reduced. PQ> I'll go re-read the thread. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Mar 23 08:12:42 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AD71296F2 for ; Thu, 23 Mar 2017 08:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzlqvzZAKRzo for ; Thu, 23 Mar 2017 08:12:40 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 ED51F129490 for ; Thu, 23 Mar 2017 08:12:39 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id 81so28699858pgh.3 for ; Thu, 23 Mar 2017 08:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version :content-transfer-encoding:content-disposition; bh=6tnR3u//Y57kmrNyogFjNJ8uiU4IVxUSXCRidpazMZk=; b=Ts5efWhVgL9YwI2BZXjwfyxtJO/iYZMyo1iG95xonqtNbNtZHg/91Hre28r3w57o1R 4SvaHcmmlsQ5jBKnRzKGFnQaAODE/YdM5OzuICghxK+FKb6N6rjK9uPX6FrdOhPthYUS 9dbHe5w7q9KmKkCr8APzcU+be7E13zoz/W0S/UTaCdN/PYSKqIT+dGrokztYApAwrVYs aXud/LOEFIJmAE/mOONA7u8C3ekD4kdh8ic+oPZxdqNK1WfuvJTE9TxMvxJqRwj9ibmg jgvN0/7jN6lTdkjs1Tb+oyISEyJ29EEvXTbryJwHtFJZL8Y9M7BSemKiZUqsdoPyGQJT ONwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-transfer-encoding:content-disposition; bh=6tnR3u//Y57kmrNyogFjNJ8uiU4IVxUSXCRidpazMZk=; b=O03q8sl+5bni6np770Bf4nLfKpp5Ji4X4L4yv3unv3Z+BambD6cH1PiBbxAIsHyrtK qXiO606FlZvr915wj0Nr3CNq6pmpujBR18v1PBIi2w1IniQygrhKQp6p2hy//h/8b+9o yMbt5/lFunOR/96RUgVjleAFhT86kJUooeI5DYhTX9QnYADornIyFC5UZONhiqurqdu1 f279zqCCOBv5tXjcGSmdJ2ePE3NIyr5eE3DhkmvUwGBi6OPF8/fRFsO12jQYJKVHHIjz 91hXj9sd9yQK3xbBLWF1UzFeVaNefm0VmP2O/Sm6RpyQJt6nY5w8T1KuQDK4CXcQqSnf ifHQ== X-Gm-Message-State: AFeK/H3PhHs8O3HrwVMZT7lBqpgp5vgRTbtbOcUKqx6BjY1W834KXHDoiEBL+Sn0Lha2YA== X-Received: by 10.99.144.65 with SMTP id a62mr3461799pge.151.1490281959347; Thu, 23 Mar 2017 08:12:39 -0700 (PDT) Received: from LLIOK4RX6E0B076 ([103.251.128.66]) by smtp.gmail.com with ESMTPSA id l71sm11070468pga.7.2017.03.23.08.12.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 08:12:38 -0700 (PDT) Date: Thu, 23 Mar 2017 23:15:16 +0800 From: "lizho.jin" To: sfc , paulq , "uri.elzur" Message-ID: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> X-Mailer: PC MailMaster/3.3.1.1013 (Windows 7) MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: [sfc] Doubt about draft-ietf-sfc-nsh-12 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:12:41 -0000
Hi Authors,
I have a doubt with fo= llowing description:
   Next Protocol=
: indicates the protocol type of the encapsulated data.
   NSH does not alter the inner payload, and the semantics on the inner
   protocol remain unchanged due to NSH service function chaining.
   Please see IANA Considerations section below.

It says NSH does not alter the inner payload, but wha=
t if the S=46 is NAT,
then the =
payload will be changed, right=3F

Regards
Lizhong
<=21--=F0=9F=98=80-->
From nobody Thu Mar 23 08:24:15 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934312943C for ; Thu, 23 Mar 2017 08:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 QSOGSpqLsFLS for ; Thu, 23 Mar 2017 08:24:06 -0700 (PDT) Received: from mailb2-alt.tigertech.net (mailb2-alt.tigertech.net [74.114.91.144]) (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 9F2BC1297CF for ; Thu, 23 Mar 2017 08:24:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5C6741C0CE3; Thu, 23 Mar 2017 08:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1490282645; bh=414WpYcnNtNFXvN0OuV17u3QqUdc1uVW5Lrb/7hWTAI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kmN53akbyb1u32aIWKqHJjl9lgEM7MRylhw93Jzwe5+2M3ZosbagbzcWAXepOO762 OVPHOYsqyEJQbHhbIxaHmh+w0FIvBSJ/pWsaCd4e/Q+N1O61zWARxXTsIfwwl52r3w wK5EMH9h/u0IUZOqKb7DmhIWcpm5Y8huCMX7KjLo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BCB80521B49; Thu, 23 Mar 2017 08:24:04 -0700 (PDT) To: "lizho.jin" , sfc , paulq , "uri.elzur" References: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> From: "Joel M. Halpern" Message-ID: <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> Date: Thu, 23 Mar 2017 11:24:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Doubt about draft-ietf-sfc-nsh-12 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:24:11 -0000 The content of the inner payload may change. Lots of service functions change the content. NAT, HTTP annotators, ... THe semantics of the inner protocol (TCP is still TCP,...) remain the same. if the semantics are changing, then the service function terminates one chain and starts another. Yours, Joel On 3/23/17 11:15 AM, lizho.jin wrote: > Hi Authors, > I have a doubt with following description: > > Next Protocol: indicates the protocol type of the encapsulated data. > NSH does not alter the inner payload, and the semantics on the inner > protocol remain unchanged due to NSH service function chaining. > Please see IANA Considerations section below. > > It says NSH does not alter the inner payload, but what if the SF is NAT, > > then the payload will be changed, right? > > Regards > > Lizhong > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Mar 23 08:30:54 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC45B12948E for ; Thu, 23 Mar 2017 08:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF8AtZ3kdGjb for ; Thu, 23 Mar 2017 08:30:52 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB231270FC for ; Thu, 23 Mar 2017 08:30:52 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 23 Mar 2017 11:30:50 -0400 From: Kyle Larose To: "Joel M. Halpern" , lizho.jin , sfc , paulq , uri.elzur Thread-Topic: [sfc] Doubt about draft-ietf-sfc-nsh-12 Thread-Index: AQHSo+fuTeiD2XxbtEWnHWdHrsxQ7qGizj+A//+95bA= Date: Thu, 23 Mar 2017 15:30:49 +0000 Message-ID: References: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> In-Reply-To: <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.51] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Doubt about draft-ietf-sfc-nsh-12 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:30:54 -0000 Hi, > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, March 23, 2017 11:24 AM > To: lizho.jin; sfc; paulq; uri.elzur > Subject: Re: [sfc] Doubt about draft-ietf-sfc-nsh-12 >=20 > The content of the inner payload may change. Lots of service functions > change the content. NAT, HTTP annotators, ... > THe semantics of the inner protocol (TCP is still TCP,...) remain the sam= e. > if the semantics are changing, then the service function terminates one > chain and starts another. >=20 I interpret the beginning of the text to mean that the act of encapsulating= the packet in an NSH header does not require that the inner payload be changed at all. This does not mean that service functions cannot change it; it only means t= hat implementers of the NSH protocol need not do something special to the packet to push the encapsulat= ion. > Yours, > Joel >=20 > On 3/23/17 11:15 AM, lizho.jin wrote: > > Hi Authors, > > I have a doubt with following description: > > > > Next Protocol: indicates the protocol type of the encapsulated data. > > NSH does not alter the inner payload, and the semantics on the inner > > protocol remain unchanged due to NSH service function chaining. > > Please see IANA Considerations section below. > > > > It says NSH does not alter the inner payload, but what if the SF is > > NAT, > > > > then the payload will be changed, right? > > > > Regards > > > > Lizhong > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Mar 23 08:52:33 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA1127078 for ; Thu, 23 Mar 2017 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ_5LKUD6bmH for ; Thu, 23 Mar 2017 08:52:30 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 71DF0126C23 for ; Thu, 23 Mar 2017 08:52:30 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id g2so36901556pge.2 for ; Thu, 23 Mar 2017 08:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding:content-disposition; bh=NuwvLcoZNRgVRkJaWQPKV428fR9tk0LLlFMmWfzxP3k=; b=aUZbBtvwbnFTCtggLsVOMHF4NiCARjHOUucoUu0Wr8VkKC8XfcfJ7HqgcxCJNiH2pU GIKlyS1DvYw6IXcn9iVt97Tb4feGkdK+WhZNt/UxVeQzqI4ljWdxIoiYS04/Ito0QReb PJOWH7vJc7nOfC3qNDTzlIW4DA68dKE0aTGrPgpbBNxZj0BPG4FStwOxEIBpYumRIFyA I25OtIyeTX3qjCQ3fe4SgXPWYy6XLGOq1wkAzQYeZdoWFmsHeYNFOCOWC83+F9L5Hon/ MiwR1kh30L4M/6q/WwnygLUmbSpuFHwsKv65cC4GXdadmz3o8HhXuj73q7PWtzR26hEM 8yOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding :content-disposition; bh=NuwvLcoZNRgVRkJaWQPKV428fR9tk0LLlFMmWfzxP3k=; b=UXEWS/byikwnn/h1JhaLX0l2TSi4zfaRyP8gx2ksU1xb4+fegp6nWkmJdQoyEBfREi urMsMQETVhTWq5Ri6i417L5b4Jk+LdT+1L0NQttEQUM5kYri8IW3FrOPw8HPcs181tNA C+HlDpV8a6pjtvmcZk/IgH8e/EJEOcWMJLd3MmWkyqmi3v/m1q+1nfPFz53XCxC8SQsh IANrztOwhcVK3OmvFjJLthLMVdW8xLd59LszczkzW+uTnw9RjzFFe+muSZN4imj4d42L BaXizZxXRvrnaQ4QlPR0fl8uwWTOWLMJdCaT7TDnR2BhEw7SeFj0tjSQd0xSTY4AvKUZ 9fuw== X-Gm-Message-State: AFeK/H3Btr3fUI4F1zzNQmKKUpwMnQ/sW1DhOXBcSe+6hVhiFMF80i3XdlwEvToerGgGyQ== X-Received: by 10.84.232.67 with SMTP id f3mr3467977pln.42.1490284350095; Thu, 23 Mar 2017 08:52:30 -0700 (PDT) Received: from LLIOK4RX6E0B076 ([103.251.128.66]) by smtp.gmail.com with ESMTPSA id n7sm11169604pfn.0.2017.03.23.08.52.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 08:52:29 -0700 (PDT) Date: Thu, 23 Mar 2017 23:55:15 +0800 From: "lizho.jin" To: "Joel M. Halpern" Cc: sfc , paulq , "uri.elzur" Message-ID: <905ED664-B5EC-434C-A823-99C68761E254@gmail.com> In-Reply-To: <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> References: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> X-Mailer: PC MailMaster/3.3.1.1013 (Windows 7) MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [sfc] Doubt about draft-ietf-sfc-nsh-12 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:52:32 -0000
Joel,
Thanks for the reply. See inline = below.

Regards
Lizhong

On 03/= 23/2017 23:24=EF=BC=8CJoel M. Halpern<jmh=40joelhalpern.com> wrote=EF=BC=9A
The content of the inner payload may c= hange.  Lots of service functions 
change the content.  NAT, HTTP annotato= rs, ...
THe semantics of the inner protocol (TC= P is still TCP,...) remain the 
same.  if the semantics are changing,&n= bsp;then the service function 
terminates one chain and starts another.&nbs= p;
=5BLizhong=5D then do you mean, a service chain is represe= nted not only by the SPI, but also the Next protocol=3F There does exist = some case to change the Next protocol after function process.

Yours,
Joel

On 3/23/17 11:15 AM, lizho.jin wrote:
> Hi Authors,
> I have a doubt with following = ;description:
>
>    Next Protocol: indicates t= he protocol type of the encapsulated data.
>    NSH does not alter th= e inner payload, and the semantics on = the inner
>    protocol remain unchanged = due to NSH service function chaining.
>    Please see IANA Considerat= ions section below.
>
> It says NSH does not alter th= e inner payload, but what if the S=46&= nbsp;is NAT,
>
> then the payload will be changed,&= nbsp;right=3F
>
> Regards
>
> Lizhong
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> sfc mailing list
> sfc=40ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
<=21--=F0=9F=98=80-->
From nobody Thu Mar 23 08:58:20 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6D812956A for ; Thu, 23 Mar 2017 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 uarP08eIeYLa for ; Thu, 23 Mar 2017 08:58:09 -0700 (PDT) Received: from mailb2-alt.tigertech.net (mailb2-alt.tigertech.net [74.114.91.144]) (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 BE0F3126C23 for ; Thu, 23 Mar 2017 08:58:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A9AC830A712; Thu, 23 Mar 2017 08:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1490284688; bh=jwibBtIgo9g81fWJJZ8mu0Pnkj2a5QSzM0EdeKKKppM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gHQzIys69u0+qVkgbdCJ++3vwQ392jFaePe2Yn21gAKyaZMiik8kl80Tri5W2bXaq UiAMKeMUNQ/JPXyvRdtoH8jNQPwUAxbuGG7gMwtCsz2bMDimwt+8QO5TToOD4k6cLF MG70vZreG06m+JViyhCghY24UpXdGM0vZLnJCEV4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 12BB430A704; Thu, 23 Mar 2017 08:58:07 -0700 (PDT) To: "lizho.jin" References: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> <905ED664-B5EC-434C-A823-99C68761E254@gmail.com> Cc: sfc , paulq , "uri.elzur" From: "Joel M. Halpern" Message-ID: Date: Thu, 23 Mar 2017 11:58:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <905ED664-B5EC-434C-A823-99C68761E254@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Doubt about draft-ietf-sfc-nsh-12 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:58:18 -0000 No, the service function path is does not consider the next_protocol field at all. SFC as a data plane behavior does not care what the next protocol is (except possibly for the case of OAM shims, and even those do not change the path). I am not quite sure how you got there from my response. Again ignoring OAM, as Kyle correctly notes, an SFF does not look at or modify the next protocol field. It may use the carried packet for laod balancing in some implementations, but that is outside not mandated by NSH. It is possible that both Kyle and I are misunderstanding your question. Yours, Joel On 3/23/17 11:55 AM, lizho.jin wrote: > Joel, > Thanks for the reply. See inline below. > > Regards > Lizhong > > On 03/23/2017 23:24，Joel M. Halpern > wrote： > > The content of the inner payload may change. Lots of service functions > > change the content. NAT, HTTP annotators, ... > THe semantics of the inner protocol (TCP is still TCP,...) remain the > same. if the semantics are changing, then the service function > terminates one chain and starts another. > > [Lizhong] then do you mean, a service chain is represented not only > by the SPI, but also the Next protocol? There does exist some case > to change the Next protocol after function process. > > Yours, > Joel > > On 3/23/17 11:15 AM, lizho.jin wrote: > > Hi Authors, > > I have a doubt with following description: > > > > Next Protocol: indicates the protocol type of the encapsulated data. > > > NSH does not alter the inner payload, and the semantics on the inner > > > protocol remain unchanged due to NSH service function chaining. > > Please see IANA Considerations section below. > > > > It says NSH does not alter the inner payload, but what if the SF is NAT, > > > > > then the payload will be changed, right? > > > > Regards > > > > Lizhong > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > From nobody Thu Mar 23 09:17:22 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2230012985B for ; Thu, 23 Mar 2017 09:17:19 -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 8oO0BtB7tUvT for ; Thu, 23 Mar 2017 09:17:15 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C111297E1 for ; Thu, 23 Mar 2017 09:17:15 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id r203so62867966oib.3 for ; Thu, 23 Mar 2017 09:17: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=VAUKDAEgKfwq5urT5j3t1MTERaR3uWU+G6HWL5kcrXg=; b=aP/RJZLV1OQSqCUy2i+lrtdRV10WSqpt4ooV5vVvgK/vBrpr4CLX5sX+3sOY9D3YcS xoaz9kGwFo0YsH0RU+7aME6OvFycUresXB1vxJyQFBnwG1lGceaPTJGhqzALeN4f8Ggm +rXpDp9nKjNhmtbMHoutTRc5DWxaRPgwo4/d4p4JnbXs1Sy25g/M2riPF49SCX6YgFbw tc+snSoiiXdLfYr4qJoZES7crSqx9Ft2c/tg8lxyHviLAcweY+uGWMlWjNeTBcgEvsCb JISFHTa9EGEAE3CiNtaKf5CZ+SzBsOsOw/U16E6FI+w0qnDZqD1FP6GFmeL4PkZjKKf8 cYDg== 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=VAUKDAEgKfwq5urT5j3t1MTERaR3uWU+G6HWL5kcrXg=; b=hoEqI58yscvULwZhIyXGydMeoQVkXvhcHqEEQmD14Rz18hwRyAwrRfgzYDNXzUpRap vpkkQzXWxgGn6kZicPGXZtzYT9sNILe2ZcUaXeirxSP5lsckWFidBcV4u3cgwg0I/z5I RSOH/7/47vZbtysW1g6IJ5qE8mCFc7ZStZ1bSJpf5p358kczwQjfkTcz2aLhKHYeEz5c rJ06wptLbpBcaV1q5dI5mBag6gHQ3Lg+JqO4r1asHRuJafGjrtFPYjStyU9iMYpy4TBO ApZ7H3myIIAr0wbn3tg1xdV0JcvUt+2cfsYaqlVcf2AXI6nwM7Ue9Hd0vzh1SWO1WfZN YhSQ== X-Gm-Message-State: AFeK/H0HZwymBplGKx7UurL6cwcnpcVbRnT3t2QCo7sCJPZWkKbp9XqxkyM0dyVbUaUuecrV+WemexL8gFotcw== X-Received: by 10.202.196.79 with SMTP id u76mr2047079oif.44.1490285835226; Thu, 23 Mar 2017 09:17:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Thu, 23 Mar 2017 09:17:14 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Thu, 23 Mar 2017 11:17:14 -0500 Message-ID: To: James N Guichard Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c17b32d2960b054b68359a Archived-At: Subject: Re: [sfc] Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:17:19 -0000 --001a11c17b32d2960b054b68359a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Authors, WG Chairs, et. al, I've read the draft and think that it addresses practical scenario, offers viable solution and expresses it all in well-written form. Hence I support its adoption by SFC WG. But I find the draft to be in quite unusual, at least in my experience at IETF, situation in regard to IPR disclosures. It has two disclosures with different licencing clauses: - a covenant not to assert or royalty bearing licensee; - RAND with possible royalty/fee to implementers. I'm not, by far, an IPR expert but, as I recall, IETF is striving to advance solutions that do not bear imposition of royalty fee on an implementer. I think that it would be helpful to get clarification, expert opinion perhaps, on relationship of both IPR claims and the solution defined in the draft. Regards, Greg On Fri, Mar 10, 2017 at 7:08 PM, James N Guichard < james.n.guichard@huawei.com> wrote: > Greetings WG, > > > > This message begins a two week call for WG adoption of the document > https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ ending 24th > March 2017. > > > > Please respond to the SFC mailing list with any statements of approval or > disapproval. > > > > Please note: > > > > 1. This is not WG last call. The document is not final and the WG > is expected to modify the content until there is WG consensus that the > content is solid. Therefore, please don=E2=80=99t oppose adoption just be= cause you > want to see changes to its content. > > 2. If you have objections to adoption of the document, please > state your reasons why, and explain what it would take to address your > concerns. > > 3. If you have issues with the content, by all means raise those > issues and we can begin a dialog about how best to address them. > > > > Yours, > > > > Jim & Joel > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --001a11c17b32d2960b054b68359a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors, WG Chairs, et. al,
I've read the dra= ft and think that it addresses practical scenario, offers viable solution a= nd expresses it all in well-written form. Hence I support its adoption by S= FC WG.
But I find the draft to be in quite unusual, at least in m= y experience at IETF, situation in regard to IPR disclosures. It has two disclosures with different licencing clauses:<= /div>
  • a covenant no= t to assert or royalty bearing licensee;
  • RAND with possible royalty/fee to implementers= .
I'm = not, by far, an IPR expert but, as I recall, IETF is striving to advance so= lutions that do not bear imposition of royalty fee on an implementer. I thi= nk that it would be helpful to get clarification, expert opinion perhaps, o= n relationship of both IPR claims and the solution defined in the draft.

Regards,
Greg
<= div class=3D"gmail_extra">
On Fri, Mar 10, 20= 17 at 7:08 PM, James N Guichard <james.n.guichard@huawei.com= > wrote:

Greetings WG,

=C2=A0

This message begins a two week call for WG adoption = of the document https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ ending 24th March 20= 17.

=C2=A0

Please respond to the SFC mailing list with any stat= ements of approval or disapproval.

=C2=A0

Please note:

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 This is not WG last call. The document is not f= inal and the WG is expected to modify the content until there is WG consens= us that the content is solid. Therefore, please don=E2=80=99t oppose adopti= on just because you want to see changes to its content.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 If you have objections to adoption of the docum= ent, please state your reasons why, and explain what it would take to addre= ss your concerns.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 If you have issues with the content, by all mea= ns raise those issues and we can begin a dialog about how best to address t= hem.

=C2=A0

Yours,

=C2=A0

Jim & Joel

=C2=A0

=C2=A0


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


--001a11c17b32d2960b054b68359a-- From nobody Thu Mar 23 09:29:06 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D816112997E for ; Thu, 23 Mar 2017 09:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 vp6S1tDfwO_v for ; Thu, 23 Mar 2017 09:29:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 54701129865 for ; Thu, 23 Mar 2017 09:29:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id ED7DEAE012A; Thu, 23 Mar 2017 09:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1490286541; bh=uHQIBfyi3GC2fPKuZDgK7F+F+G1CpN59WKupOPPCvFI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=TWKxnOcIjiDTGVWCQP0eI6Uk5kEbp74DYdW6IY0Xal+WTjKPxC/N1lFXo4FCjXUeo P2947BuZpPy4+7WxyXoYqYG5/yYBlaRVkRp/PHNzehz3rfuItyNsuh0tMuP2EyRiuT t+HQnabEMxDgpOZllIlHKjU8ly9Hs619IwuNiO3g= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48B7D24B481; Thu, 23 Mar 2017 09:29:01 -0700 (PDT) To: Greg Mirsky , James N Guichard References: Cc: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: <7cf3f074-ebda-2ffa-ae05-386f13a7048e@joelhalpern.com> Date: Thu, 23 Mar 2017 12:29:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Call for adoption https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:29:05 -0000 The IETF rules on IPR are quite explicit. We must not (and will not) seek or get for the IETF expert opinion on the meaning or applicability of claimed IPR. Individual participants are of course free to use their own resources to help them form an opinion, but the WG can not do that. Also, the IETF policy is that we require disclosure. Working group participants may have preferences for different solutions based on those disclosure, but the IETF does not have a formal policy to prefer one or another. There are common preferences among within the community. Net: calling attention to the IPR disclosures is reasonable and sensible. Asking the WG to actually form an opinion on applicability is not permitted. Whether the terms one or more IPR claims state affects our decisions on what to use is up to the WG as individual members. Yours, Joel PS: The above statement applies without regard to the content of the IPR claims. I have not looked at who is making the claims or what they are claiming. On 3/23/17 12:17 PM, Greg Mirsky wrote: > Dear Authors, WG Chairs, et. al, > I've read the draft and think that it addresses practical scenario, > offers viable solution and expresses it all in well-written form. Hence > I support its adoption by SFC WG. > But I find the draft to be in quite unusual, at least in my experience > at IETF, situation in regard to IPR disclosures. It has two disclosures > > with different licencing clauses: > > * a covenant not to assert or royalty bearing licensee; > * RAND with possible royalty/fee to implementers. > > I'm not, by far, an IPR expert but, as I recall, IETF is striving to > advance solutions that do not bear imposition of royalty fee on an > implementer. I think that it would be helpful to get clarification, > expert opinion perhaps, on relationship of both IPR claims and the > solution defined in the draft. > > Regards, > Greg > > On Fri, Mar 10, 2017 at 7:08 PM, James N Guichard > > wrote: > > Greetings WG,____ > > __ __ > > This message begins a two week call for WG adoption of the document > https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ > ending > 24^th March 2017.____ > > __ __ > > Please respond to the SFC mailing list with any statements of > approval or disapproval.____ > > __ __ > > Please note:____ > > __ __ > > __1. __This is not WG last call. The document is not final > and the WG is expected to modify the content until there is WG > consensus that the content is solid. Therefore, please don’t oppose > adoption just because you want to see changes to its content.____ > > __2. __If you have objections to adoption of the document, > please state your reasons why, and explain what it would take to > address your concerns.____ > > __3. __If you have issues with the content, by all means > raise those issues and we can begin a dialog about how best to > address them.____ > > __ __ > > Yours,____ > > __ __ > > Jim & Joel____ > > __ __ > > __ __ > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Mar 23 19:18:20 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBFC129464 for ; Thu, 23 Mar 2017 19:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2a7zzQa-gmF for ; Thu, 23 Mar 2017 19:18:16 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA95D12940C for ; Thu, 23 Mar 2017 19:18:16 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 20so882138pfk.2 for ; Thu, 23 Mar 2017 19:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iSnUIUwMmzZJ5tw6qZ5sbPRbzZFDs3arJXrEegvbmD4=; b=D9N4UrpWyS6IpdCEh3igeJZ6szCXb1FsEVkw3CiEQF1SfctdhywYygL3ojO6VkvLmr bV0kU6I90ZOzR6JNI+5Gu+BFmDhpVnLkz1fh0uTSIB4deE60LqAOk41ys3QoSOpO268+ inFAfJjUyCg0cxwdjPZPr+mPsYqrZOS1sdPZhpYmioJpCEtttsKisecvMnWS4Ips09UU 0m9H525fmiYmz4rQZSQqrpWEuoqzMzU3p17W71izGJ9v6A8m7LL5F3XVmGgjUaUKRMek mO9odsqKbsjrZWH3liKlXUp3xicUae83cwq8jxHp+RczB0C7a7eijvfgZ/rQk+t9ntPC bkpA== 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=iSnUIUwMmzZJ5tw6qZ5sbPRbzZFDs3arJXrEegvbmD4=; b=dA/gM6HPh4hub8NUURoh0cdMWD8hnal+AMBfEIayQiq3IWAm/NUjaWuqDg/ZyLvTI7 Rjv4ImKcB9EOtAOwwBi3Jbv7CiaMmSUe8b8UmRBkxtd1Lr+yQiE/JNCB8Pd9fJeZWRG3 PQFYh6rdRT30aFPwabhujV23U6+nuSK9HGr0izs1/DJPtNG5aVyVeSR9T1cIZy4NIV3s JvwUbYIRrxgTuydVkIB6U4aXVd1YCTWDTD34s+SKl3XOz2jnYRrJxlxwqIRe4DICjjMx DVbuDYN2GRj0bTlJMUCKywq1FneXyipYTpPaW4nSfTFm+NUtCoTeXqV+pOE1VPpAG24x XiJg== X-Gm-Message-State: AFeK/H3hSFww/KfCFGViH1wNukYVEjN8FvH4+8gKOJvG3H7YZ9NzyRQuextjhbEn7Q8y2bMidDKIpkg/GqWDHw== X-Received: by 10.98.95.197 with SMTP id t188mr6419854pfb.150.1490321896393; Thu, 23 Mar 2017 19:18:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.130 with HTTP; Thu, 23 Mar 2017 19:18:15 -0700 (PDT) In-Reply-To: References: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> <905ED664-B5EC-434C-A823-99C68761E254@gmail.com> From: Lizhong Jin Date: Fri, 24 Mar 2017 10:18:15 +0800 Message-ID: To: "Joel M. Halpern" Cc: sfc , paulq , "uri.elzur" Content-Type: multipart/alternative; boundary=94eb2c0456a43c5186054b709bb1 Archived-At: Subject: Re: [sfc] Doubt about draft-ietf-sfc-nsh-12 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 02:18:19 -0000 --94eb2c0456a43c5186054b709bb1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, "if the semantics are changing, then the service function terminates one chain and starts another." That's why I thought SFC care about the next protocol (the semantics you are referring is next protocol). Anyway I got the actual meaning of the sentence in SFC draft. Thanks Joel and Kyle for the clarification. Regards Lizhong On Thu, Mar 23, 2017 at 11:58 PM, Joel M. Halpern wrote: > No, the service function path is does not consider the next_protocol fiel= d > at all. SFC as a data plane behavior does not care what the next protoco= l > is (except possibly for the case of OAM shims, and even those do not chan= ge > the path). > > I am not quite sure how you got there from my response. > > Again ignoring OAM, as Kyle correctly notes, an SFF does not look at or > modify the next protocol field. It may use the carried packet for laod > balancing in some implementations, but that is outside not mandated by NS= H. > > It is possible that both Kyle and I are misunderstanding your question. > > Yours, > Joel > > On 3/23/17 11:55 AM, lizho.jin wrote: > >> Joel, >> Thanks for the reply. See inline below. >> >> Regards >> Lizhong >> >> On 03/23/2017 23:24=EF=BC=8CJoel M. Halpern >> wrote=EF=BC=9A >> >> >> The content of the inner payload may change. Lots of service >> functions >> >> change the content. NAT, HTTP annotators, ... >> THe semantics of the inner protocol (TCP is still TCP,...) remain th= e >> same. if the semantics are changing, then the service function >> terminates one chain and starts another. >> >> [Lizhong] then do you mean, a service chain is represented not only >> by the SPI, but also the Next protocol? There does exist some case >> to change the Next protocol after function process. >> >> Yours, >> Joel >> >> On 3/23/17 11:15 AM, lizho.jin wrote: >> > Hi Authors, >> > I have a doubt with following description: >> > >> > Next Protocol: indicates the protocol type of the encapsulated >> data. >> >> > NSH does not alter the inner payload, and the semantics on the >> inner >> >> > protocol remain unchanged due to NSH service function chaining. >> > Please see IANA Considerations section below. >> > >> > It says NSH does not alter the inner payload, but what if the SF i= s >> NAT, >> >> > >> > then the payload will be changed, right? >> > >> > Regards >> > >> > Lizhong >> > >> > >> > >> > _______________________________________________ >> > sfc mailing list >> > sfc@ietf.org >> > https://www.ietf.org/mailman/listinfo/sfc >> > >> >> --94eb2c0456a43c5186054b709bb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
"if the semantics are changing, then= the service function
=C2=A0 =C2=A0 terminates one chain and starts another."
That&= #39;s why I thought SFC care about the next protocol (the semantics you are= referring is next protocol).
Anyway I got the actual meaning= of the sentence in SFC draft. Thanks Joel and Kyle for the clarification.<= br>
Regards
Lizhong


On Thu, Mar= 23, 2017 at 11:58 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
No, the serv= ice function path is does not consider the next_protocol field at all.=C2= =A0 SFC as a data plane behavior does not care what the next protocol is (e= xcept possibly for the case of OAM shims, and even those do not change the = path).

I am not quite sure how you got there from my response.

Again ignoring OAM, as Kyle correctly notes, an SFF does not look at or mod= ify the next protocol field.=C2=A0 It may use the carried packet for laod b= alancing in some implementations, but that is outside not mandated by NSH.<= br>
It is possible that both Kyle and I are misunderstanding your question.

Yours,
Joel

On 3/23/17 11:55 AM, lizho.jin wrote:
Joel,
Thanks for the reply. See inline below.

Regards
Lizhong

On 03/23/2017 23:24=EF=BC=8CJoel M. Halpern<jmh@joelhalpern.com>
 <mailto:jmh@joe= lhalpern.com> wrote=EF=BC=9A


=C2=A0 =C2=A0 The content of the inner payload may change.=C2=A0 Lots of se= rvice functions

=C2=A0 =C2=A0 change the content.=C2=A0 NAT, HTTP annotators, ...
=C2=A0 =C2=A0 THe semantics of the inner protocol (TCP is still TCP,...) re= main the
=C2=A0 =C2=A0 same.=C2=A0 if the semantics are changing, then the service f= unction
=C2=A0 =C2=A0 terminates one chain and starts another.

=C2=A0 =C2=A0 [Lizhong] then do you mean, a service chain is represented no= t only
=C2=A0 =C2=A0 by the SPI, but also the Next protocol? There does exist some= case
=C2=A0 =C2=A0 to change the Next protocol after function process.

=C2=A0 =C2=A0 Yours,
=C2=A0 =C2=A0 Joel

=C2=A0 =C2=A0 On 3/23/17 11:15 AM, lizho.jin wrote:
=C2=A0 =C2=A0 > Hi Authors,
=C2=A0 =C2=A0 > I have a doubt with following description:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Next Protocol: indicates the protocol type = of the encapsulated data.

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 NSH does not alter the inner payload, and t= he semantics on the inner

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 protocol remain unchanged due to NSH servic= e function chaining.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Please see IANA Considerations section belo= w.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > It says NSH does not alter the inner payload, but what i= f the SF is NAT,

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > then the payload will be changed, right?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regards
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lizhong
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > sfc mailing list
=C2=A0 =C2=A0 > sfc@ie= tf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listin= fo/sfc
=C2=A0 =C2=A0 >


--94eb2c0456a43c5186054b709bb1-- From nobody Fri Mar 24 03:02:16 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77734129624 for ; Fri, 24 Mar 2017 03:02:14 -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_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 ki7N6Nc0GZ3Y for ; Fri, 24 Mar 2017 03:02:12 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0137.outbound.protection.outlook.com [104.47.2.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D399D129636 for ; Fri, 24 Mar 2017 03:02:11 -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=lWV2jIU9458pyfGiEzqQ9bpp/n0CbGbl5DZpIYpBk4s=; b=CxW5p6rQAAhC8Fe1lVIG/5BAL19INC+CP/hj+Hh/lpmYWNBz1S9W5vpYwXM1Nl909H7bE9xjeSDptVofSJt3FkzGulAnfXp9XRuM2ZbhU+kGRQZBYPGCnHPxuO3yJO0tjML1I/OMr64of8CDXaJBFxUP68TJ0xVEslCrQ4meqGk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; Received: from [192.168.1.5] (90.92.95.79) by AM5PR0701MB2467.eurprd07.prod.outlook.com (10.169.153.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 24 Mar 2017 10:02:09 +0000 To: References: From: Martin Vigoureux Message-ID: <9cdf37cc-a5b3-0b75-1359-f33b57ce6d05@nokia.com> Date: Fri, 24 Mar 2017 11:02:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [90.92.95.79] X-ClientProxiedBy: DB6PR0801CA0053.eurprd08.prod.outlook.com (10.169.219.21) To AM5PR0701MB2467.eurprd07.prod.outlook.com (10.169.153.135) X-MS-Office365-Filtering-Correlation-Id: 54770e9b-500a-469b-87a7-08d4729cd61e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM5PR0701MB2467; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2467; 3:YOJoMPN7rsp75bBAGMFpQSCDdqQOCknh6y21EvkDTegzUQkEu6TgFBme0ve2loImbTswVGgz7p3mptnPNbhf72NkBI6HdDKCIQhJF6OzNAbSO8PXLUPwcO36fDSNpC/NEOH+TtEaEfSRXEAr9x/BvIRCOk6Ll0Fcq6i8fss6iAT1PXdSqk3Et95KpK4sgR63NmCp8Ltu2j6h4yN3BCiT8rr1c+IC8hyOW5vghzSwp/Qj62JHw+KGzBuEWs54XbO2hx1dOhqp8Y1bzuYGhR2Qm9nT0BzKting8hblUZQJl2I=; 25:HAqacD3sUAyWvzgeL4sN71tRmSfmrZamI1YnTAfoYugaq1tGG3tyr8g7RflHmebOMSqonqudU2mwVxqApx+xmeuKPlf1s7blW72bTVTSAPIdUU4JhnZsEMvco5OZ/+WhI96CEd9pVCs+Frbj+kBUUM0/Q24nCVLpicb8sRb+vCK59Jz8vv+VKyOjUx1U3ZFNpTZTcem0+Mj2ODqbo6Ez1cdz6pQ9KDC+KoLdafUU8gMjB4CYRReaEXoOvjd0+J0HhnRVCfZMD7nMJ/vcBw/yBrjKLBGGVvVieYTwilOXIFw6guCuaLOB9C27uABQG0ctstDzW5Y5r3Mqhe6zNMGFJ1IeRRfIj8BvHkr5Vo99zx3s7FAupImM6vnf7Rn97L97vEP5D9NamUDcrXhEBwCokcaGASUChtnilY5ptVZkEq7wXMLt7JJso+eANqYF6H72B8BEs58XAPYwuRdSzF+KdA== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2467; 31:3PjEvz1Gd2DxDjKtU9N6cp+qcVZlwNBZNnbJjdN12RbenH7lXGM3c//COjzoNO/juf8uGx+V8Lz5H9U4OSZnTGGDP4/3sqPwjdUKsI2F8Di/dJhmxkpWxoqf4wU8Znhp9uTrylhhm1KYT3zrE2yUgdRv2fnhxrCUnglprTpLTS8s8yRAMO/Glvf1ZlqRWwkVQM+KnU0rO2UwIyr7MOMVZGJ1Te1QdSpDIKENFr60r2akF4WVMPxUhNfJBmdt/VJlQ0J7N9Q8OlnFSlmKXcRzQA==; 20:NtY/cOomXfPOiCrq9kK5ONtedKnOaiJRy2FtHEfpUWzEibqWCOpqybb5MkH7RPaTWabnxJYTqT+mrqE1JyvNw8rhG4+HR0LxeKcYIF8Hsyq7DyAj1FP04dtMgH4bh7Bl6WdowGXGB/VgdVi2slYT/eoZ071sx/idoIvkWcqi48MXAQbrzNaml7qNNvNgwhyLr3YUcZHesogbrZEtGBPLali5Kg+2BMj1/gZwnggxu3hajf/+CZehyjQDQ6LLBICb2P9+L4iyF9L+Eq+FiAhU6wQ1v7X4xJgaLnl7cGhf7dHlRK+CyJgSf7HNs/kUwTaStu4fwZinwF6WtfkVhc95TdgmSVHwBJ92/tWoulotcRcAgCPomxmo+EvHnen8qI8cXzY7/lQHPlaYpdZmoRrF5EVOXiPm/bI/S2VfFK6Xk44hCGdD2JO7O6+9u3tpfEkSaV4Kmg73fn3PerYdnpUWLM3mp01kJGvuZ2AG0C7LuChkuE++abYWJhbhtDfL+fSr X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:AM5PR0701MB2467; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2467; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2467; 4:7KaZ2r2w/MBiW57JcIU2hfc7XTfLlZGPh4SgfrV+UqsF1+dvbCCqQtTNoo3dlt6a83lXtoVbWwmfuIantgq3z2gs5Q8VcytWMhb6Sh7Nr/85VQoUa0IPoNMc5u7jbmT1nND4tpqro9Dfa0w4tAJ23U5aPgh55nPHGldDUHsQI1x73+BbLocD+ZF6mvnJjqVTgAIkXrmQ6RiIzw92uiqjAOM5N9N4Hby/HbJLPHlvGgSicxF6A4oMm5ppLTVtDmK+EJmaR/4dvWGzBXSgajeMOZMZbHIz/KTnFFHGbzUbezGgoAEgWIwCH+j4f27Qy7LHBLwEXCrVLx7PzIazLfLpvZBCY8skvcTDhHlpbCUIolmmOTdW2NbPwZgzLjMGe6CjsQzkAYLYNgZortcT0TTbDLDVqnOUQSzoILlhhSz/nEp3oPajk6qzCj+6Z4RmBFyAjK5JiKvARFINc1o6fIfjQIgodR5IasySO46RKf6eaLB8jNJGhPi2YL62Qet9TQpBAPA+uyHvgiwfZ4KRYcqeIA6Se6LzsVmJVjK2pC2mXmVj4XyESkeC9Ga2gqQUYbUmiLvoNZDtZ2jz8Nx7jaQhSimMtOBzNTlC+3gVB657D4bo2c1V1Begs8uc2PgsqTSXyOd6HjiyViMEecX5X/8XFc1cgexhsMpsb227rB/os/p/bbQlInFCJy/8BuLRT6oOod5JfWTDpW2UBEv3CEHyQA== X-Forefront-PRVS: 0256C18696 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(6116002)(33646002)(38730400002)(3846002)(2351001)(83506001)(90366009)(23746002)(77096006)(6486002)(42186005)(6306002)(110136004)(6666003)(6246003)(6916009)(230783001)(2950100002)(117156001)(36756003)(65826007)(25786009)(54356999)(305945005)(31696002)(229853002)(65806001)(2870700001)(86362001)(47776003)(7736002)(5660300001)(53936002)(65956001)(189998001)(66066001)(50986999)(64126003)(8676002)(76176999)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2467; H:[192.168.1.5]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM5PR0701MB2467; 23:w+6U6s9+661qR45XUkumSHm7iUpnKvDZafn?= =?Windows-1252?Q?ys1Ec/3v1lztrYKq3Z+y/Ro3El7AQLOOURPVytyxa+1szr06hKen4T+0?= =?Windows-1252?Q?W7a5QlORhDvbhZ8jS/H4DtsqhQEF5niJHJ1jzeRjjtw+o3zxSd/9wWFF?= =?Windows-1252?Q?mCXUsV1U3VZJ6fJNi3e90mATFdTdTx0GS+Vwep0R7va7gAoXKV2lSm3d?= =?Windows-1252?Q?zGwCHKElEsYOeAU8LctAVvDBtbIad/3X0b8qkpkkxwggT6JWw2lwKSGk?= =?Windows-1252?Q?EYHU4YFadThD+Kb1TAHMl/sYEk4/TLyO4BvNMnCAbQ4bP4s+8nxmPuOp?= =?Windows-1252?Q?NJ+zbasNF0RPoyrKPQBBMZFuGhzx4lUMWXhuvGqnYSr5EDytE9jkmXVA?= =?Windows-1252?Q?QnvSIsnLAOBcjm2Ovk6kEfD+JeauhILQ0dco7OwX3HhX6xGWzDKHoUJC?= =?Windows-1252?Q?Mg8qYjgsoU5teKe6uYTRxB9Mrtmrjw7JnTOyswr9x8hT+K8jnYS05cCO?= =?Windows-1252?Q?Jr+K6Nh6GvCwiJOdE4lEcGx+sb+ht8vonbnX+L/IhJhXhHUIJRmjTxcx?= =?Windows-1252?Q?FcZeq2X1v/Fba0iWzWHbj8cDCcnOiw3c0BRz7l1iGLTtljJiR5nhu9oh?= =?Windows-1252?Q?xjrDWqmKIgdQJEZxuJOqJfjRrxvp86EN/PkxUB1z4UC2Bg1r2UR7fzLL?= =?Windows-1252?Q?V/eio/hekTPZa+MuyDoj8qa7O7xSMuajWT6+83JdTVYCwObsmu6JZudG?= =?Windows-1252?Q?Df73lHb5eLuHEEiCwDYZNtJD3PWP8xiD36suNhCxElMDPEu5VcZPn3M7?= =?Windows-1252?Q?3IR+/sh+7IkFpVAk3ynVBQljvx8xUyoIlQPBk7LjWCcZeInd2OK1p85o?= =?Windows-1252?Q?CpTSDTrNuwFttekDZ3aXjp0KW18SSvfQe31DFRuVe01OrLffKlGL1Yv3?= =?Windows-1252?Q?bp05C4i9clTekfu25rpMZMXuPodeCxrJqiP1rKWMuywP0g0HYBEYMBrr?= =?Windows-1252?Q?xJeA7Dcn1vnp2zAtVtnrt+vM+L5GOAmDifdOIyHMB188qld0RMSli0GY?= =?Windows-1252?Q?jCTg7U6oJHZzxulQQQyn0fKAMxmc08xxVuewhHrxz3k2vCyKFGj8se8y?= =?Windows-1252?Q?amTAKO0yv9PZTl3IPr4UGZS3aud4qTDkBrUo0EFyq0ZKNIClX6EmYPwi?= =?Windows-1252?Q?J8Y+RtJcGWKvMlZUET5ga9dHE70lvJr/42Bbz+Lt2zzxT8nXunR8TQdT?= =?Windows-1252?Q?HDOw6KetgwqzWH5Mwv9NSId+fuBfRBaLrPfkB0gVJ3HnV8GEkgU+xG+x?= =?Windows-1252?Q?RQ4mw?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2467; 6:tRIfBMGtZYsMLrtilDdxGFfe8ULzjVhQkQzjqK01mtTYUHTlacDdPLmcD78h4170/Xhf/HFRm3MmN/TV5meHfBP1Gz+wDLWMFV1ZZuHO2X2Fx10+O4Q2SbxiZpynYY63eF804V1kDJy9w8uuAvnnXNdnZjwwPLOO4Se1009AYdrgcxccCd7kXne4fmi44DxL3E/ojUFJjvuNFni+EAWeSOEYx6hvtB0eUP00d2Ft3NpauU02B7Yc47577d30cn0Xa254NTmHFgC8kftZvjO+ehggW6l+5+n1E2d4yyppH8y68rS6S331nmf25m6TlycPVlJxNZN4VTljPOWtK3IO9wEJuE5IkieOkxhwh0rMWv+JqSrKvpAQv2ujOkq3tycbQTF/Tgs74STSJGEyq5wAvdE5A8kKMYr9UTK3ddXA6Ec=; 5:n7Ssmxy+tPMheOhS4M5aNr9eeeuCtN6jivZwr+1DFRpEXfQ6iVnrOjljmrUClq328dc2YTD84H/zM6qQtCS0uONlXJfwbHLGh+HFkPyxkNl1uFvKBcd/V8Ul/lPG26jarrRKo9fmUgWwQXBigkVDYA==; 24:NSOWLRSUzIfee6HTBh2r5iBSMUzBWzJhnPZTk/xsvyGXC1CNmMREKJue8t4fh/wy9DIegRSvxb4iRpFGm0LrLebWzoFFoAtotCDKcAczxGU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2467; 7:wb/Tt47RvPQKxXDY5CZ0vJYbbiJyhr6bXyJMzvdRiFyr8n7DyVj+EmJsXxk9KqTigiIswPmvx/QiKIyaY+aKkZppLL/mkBWTDBROsr9QLyrcv0ht8o7cjjaTvdMOC/QdwrqM8LOahdhP7E3as8MPK2LQL9MxkBfKlQq0Qe79u2u8dlqMGlxbGL9rfPrFIShUjWsKFuogLaEzbNzbLV94sbHtkAk/WKddgSg56ma5BG0Mnx0XrvZ7bB4WxTa0w2MHApyJhD+/7EF6C+BovR9hWItg4kMwwUowV+HvRS11XhOID06wGOTVakbzzuawC0g+KC5jgmfF2AXPv9mQG9CpeA== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2017 10:02:09.7290 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2467 Archived-At: Subject: Re: [sfc] Fwd: [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 10:02:15 -0000 Hello, just to let you know that we have adopted the Document in BESS. -m Le 06/03/2017 à 12:57, Martin Vigoureux a écrit : > Hello, > > please be aware of this call for adoption that we have just started in > BESS. > > To the extent possible please express your support/opposition/comments > on the BESS WG mailing list. > > Thank you > > -m > > > -------- Message transféré -------- > Sujet : [bess] Call for adoption: draft-mackie-bess-nsh-bgp-control-plane > Date : Mon, 6 Mar 2017 12:55:28 +0100 > De : Martin Vigoureux > Pour : bess@ietf.org > Copie à : draft-mackie-bess-nsh-bgp-control-plane@ietf.org > > Hello working group, > > This email starts a two-week call for adoption on > draft-mackie-bess-nsh-bgp-control-plane-04 [1] as a Working Group Document. > > Please state on the list if you support the adoption or not (in both > cases, please also state the reasons). > > This poll runs until *the 19th of March*. > > We are also polling for knowledge of any undisclosed IPR that applies > to this Document, to ensure that IPR has been disclosed in compliance > with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more > details). > If you are listed as an Author or Contributor of this Document please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR. The Document won't progress without answers > from all the Authors and Contributors. > > IPR has been disclosed against this Document [2]. > > If you are not listed as an Author or Contributor, then please > explicitly respond only if you are aware of any IPR that has not yet > been disclosed in conformance with IETF rules. > > Thank you > > Martin & Thomas > bess chairs > > [1] > https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/ > [2] > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-mackie-bess-nsh-bgp-control-plane > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Sat Mar 25 06:38:56 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADC512945D for ; Sat, 25 Mar 2017 06:38: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0thF3mN579e for ; Sat, 25 Mar 2017 06:38:52 -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 57ACC129454 for ; Sat, 25 Mar 2017 06:38:51 -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 DDL96277; Sat, 25 Mar 2017 13:38:49 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 25 Mar 2017 13:38:48 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Sat, 25 Mar 2017 06:38:39 -0700 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: Presentation material for upcoming Chicago meeting Thread-Index: AdKlbMUbtONV6rPARa+DKCuPHqG57A== Importance: high X-Priority: 1 Date: Sat, 25 Mar 2017 13:38:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.59] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DCC680SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58D672E9.0252, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 78b5d5eac2796e616a2a42d0a0b39c96 Archived-At: Subject: [sfc] Presentation material for upcoming Chicago meeting X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 13:38:54 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DCC680SJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: If you will be presenting at the upcoming SFC WG meeting in Chicago please = forward your slides to the chairs by Monday 9am EST at the latest. Thanks! Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DCC680SJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

If you will be presenting at the upcoming SFC WG mee= ting in Chicago please forward your slides to the chairs by Monday 9am EST = at the latest.

 

Thanks!

 

Jim & Joel

 

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DCC680SJCEML701CHMchina_-- From nobody Mon Mar 27 04:38:11 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59891297C4 for ; Tue, 21 Mar 2017 05:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LA7w0dkjAoq for ; Tue, 21 Mar 2017 05:13:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CDB1297E6 for ; Tue, 21 Mar 2017 05:13:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1D1F6B816C9; Tue, 21 Mar 2017 05:13:14 -0700 (PDT) To: jmh@joelhalpern.com, cpignata@cisco.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, james.n.guichard@huawei.com, jmh@joelhalpern.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: mphaneendra@gmail.com, sfc@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170321121314.1D1F6B816C9@rfc-editor.org> Date: Tue, 21 Mar 2017 05:13:14 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 27 Mar 2017 04:38:10 -0700 Subject: [sfc] [Technical Errata Reported] RFC7665 (4974) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 12:13:19 -0000 The following errata report has been submitted for RFC7665, "Service Function Chaining (SFC) Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7665&eid=4974 -------------------------------------- Type: Technical Reported by: Phaneendra Manda Section: 1.4 Original Text ------------- One or more service functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, and TCP optimizer. Corrected Text -------------- One or more service functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, TCP optimizer, Parental control etc. Notes ----- Parental control can be added in the non-exhaustive list of abstract service functions. Also this list cannot be fixed, so etc an be added at the end of the list. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7665 (draft-ietf-sfc-architecture-11) -------------------------------------- Title : Service Function Chaining (SFC) Architecture Publication Date : October 2015 Author(s) : J. Halpern, Ed., C. Pignataro, Ed. Category : INFORMATIONAL Source : Service Function Chaining Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Mar 29 07:11:48 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72674129533 for ; Wed, 29 Mar 2017 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMEN1qhSk0Ea for ; Wed, 29 Mar 2017 07:11:44 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1199E129524 for ; Wed, 29 Mar 2017 07:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=739; q=dns/txt; s=iport; t=1490796704; x=1492006304; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=M0vOXglx24aZmLEjbFSpLTB4Iv0U1vR8Ofj/hBb1Du8=; b=ORRtYXzfCm8aCs/c7L6txcBQzvoOHwNLaIMjPHW2ZXcZ1SACmtgJZmDy Ls5fgN7bojGGZG6IhG+4N/HP2w62fCdGkuwgYzAqssp34/w3mfP5oMj6B dSX6gerk9Ul/13bomT95fcpKwuJAoMgB5wbb6796yjH95PREfuRtVOFUK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AQBEwNtY/4wNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyorgXONbKcfgg6GIoM7PxgBAgEBAQEBAQFrHQuFVj8SAT5CJgEEDg2?= =?us-ascii?q?KArAaikYBAQEBAQEEAQEBAQEBIpV2BY9hjH8BgVSQcoIFhSqKDWKTBwEfOIEEW?= =?us-ascii?q?RWHGYkegQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,241,1486425600"; d="scan'208";a="401715130" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 14:11:27 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2TEBQgt006938 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 14:11:27 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 09:11:26 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 09:11:26 -0500 From: "Roberta Maglione (robmgl)" To: "S.Majee@f5.com" CC: "sfc@ietf.org" Thread-Topic: About minimal controller requirement Thread-Index: AdKolGPWzh3ZTy5aSjm/YaInEB+SBA== Date: Wed, 29 Mar 2017 14:11:26 +0000 Message-ID: <56cc619cf45e40bbaeb746e21eb4cd10@XCH-RCD-009.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.219.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] About minimal controller requirement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:11:46 -0000 Hello Sumandra, I listened to your presentation in sfc yesterday and I have a comment: in slide 3, as part of the minimal configuration requirements you listed th= e SF Name. I agree with you that SF name is needed for the configuration, b= ut when we first looked at this problem what we thought it would be useful= for the controller to have is an additional level of abstraction for Serv= ice Function type. The reason for this is because there could be multiple = instances of the same SF type and the controller may be able to choose whic= h instance to use to build a specific chain. The concept of "service funct= ion type" is also part of the bgp/bess nsh draft. Please let me know what you think. Thanks Roberta From nobody Thu Mar 30 12:37:04 2017 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308E8127863 for ; Thu, 30 Mar 2017 12:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=f5.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 6dtz0bD8j-dy for ; Thu, 30 Mar 2017 12:37:01 -0700 (PDT) Received: from mail15.f5.com (mail15.f5.com [104.219.107.14]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F6A1293F3 for ; Thu, 30 Mar 2017 12:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=f5; t=1490902621; x=1522438621; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OqDnzQALZK+vzW8HvxPBY6H2vaNH2pAXV+l3ZdAwyoY=; b=sT17Vv/xSVbMtZAE7yrqbgqeOAE2kwhyVkr8Mx+/w2NmLRqvSDak6n1A kddChwHXUUzXQtMz/oMSEJqwM+2TDmlN0a5eooOvqc+aFb21/xX6zyGEK fSRjRizQiPP21UonVYyXm1l0qvXYaIdAqEAlT71C6oM+QI+KSP7nt5nZx vRjl/l4+GiuPX59YhchgwuNiQhZd8AU6+PHDnnZMMoyhx/gG5k8q9QfB1 S/iwhc/Z8FgDKdWHNLzHqkm6ur6H7hxSTpAWpkgSnNfb/FZciDZ9nfgXR bHwl4gwfWwu7QQJE1UPunOyzZH/RcpeI872jDXXqnLJE8RAQH6ydttZqP A==; X-IronPort-AV: E=McAfee;i="5800,7501,8483"; a="4738073" X-IronPort-AV: E=Sophos;i="5.36,248,1486454400"; d="scan'208";a="4738073" Received: from sv5ccpems05.olympus.f5net.com (HELO owa.f5.com) ([172.23.209.16]) by mail.f5net.com with ESMTP/TLS/AES256-SHA256; 30 Mar 2017 12:37:00 -0700 Received: from SV5CCPEMS01.olympus.F5Net.com (172.23.209.12) by SV5CCPEMS05.olympus.F5Net.com (172.23.209.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 30 Mar 2017 12:36:58 -0700 Received: from SV5CCPEMS01.olympus.F5Net.com ([fe80::8cea:a209:8eb7:c2ab]) by SV5CCPEMS01.olympus.F5Net.com ([fe80::8cea:a209:8eb7:c2ab%19]) with mapi id 15.01.0669.032; Thu, 30 Mar 2017 12:36:58 -0700 From: Sumandra Majee To: "Roberta Maglione (robmgl)" CC: "sfc@ietf.org" Thread-Topic: About minimal controller requirement Thread-Index: AdKolGPWzh3ZTy5aSjm/YaInEB+SBAA+JtqA Date: Thu, 30 Mar 2017 19:36:58 +0000 Message-ID: <02CCDC97-F606-4546-B997-C09E3282222A@f5.com> References: <56cc619cf45e40bbaeb746e21eb4cd10@XCH-RCD-009.cisco.com> In-Reply-To: <56cc619cf45e40bbaeb746e21eb4cd10@XCH-RCD-009.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [172.23.251.193] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] About minimal controller requirement X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:37:03 -0000 SGVsbG8sDQoNClRoYW5rcyBmb3IgeW91ciBpbnB1dC4gSSBub3RpY2VkIHRoZSBTRiB0eXBlIGlu IHRoZSBiZ3AgbnNoIGRyYWZ0IGFuZCBrZWVwaW5nIHVwIHdpdGggbWluaW1hbCBjb250cm9sbGVy L2NvbmZpZyByZXF1aXJlbWVudCwgd2h5IHdvdWxkIGNvbnRyb2xsZXIgbmVlZCB0byBrbm93IHRo ZSB0eXBlIG9mIHNlcnZpY2UuDQoNCkhhdmluZyBzYWlkIHRoYXQsIEkgYWdyZWUgaXQgaXMgdXNl ZnVsIGFuZCBhIGZ1bGwtZmxlZGdlZCBvcmNoZXN0cmF0b3IgY2FuIHVzZSB0aGlzIHRvIGNyZWF0 ZSBkeW5hbWljIHNlcnZpY2UgY2hhaW5zIG9uIGRlbWFuZCBiYXNlZCBmdW5jdGlvbmFsaXR5LiBT byBpZiBhIGNoYWluIHJlcXVpcmVzIA0KRlcgPC0+IFRDUC1PUFQ8LT5OQVQgdGhlbiBvbmUgY2Fu IGNvbm5lY3QgdGhvc2UgdHlwZXMgYXBwcm9wcmlhdGVseS4gQnV0IHRoZW4sDQphKSBIb3cgZG9l cyB0aGUgY29udHJvbGxlciBrbm93IGl0IGlmIGl0IGlzIHByb3Blcmx5IGNvbmZpZ3VyZWQsIGlz IHRoZSB0eXBlIGF2YWlsYWJsZSBvbmNlIHRoZSBicmljayBib290cyB1cCBpbnRvIGEg4oCccHJv cGVy4oCdIG1vZGU/DQpiKSBXaGF0IHdvdWxkIGJlIHRoZSB0eXBlIG9mIGEgbXVsdGkgZnVuY3Rp b24gZGV2aWNlLiBBZHZhbmNlZCBMNyBkZXZpY2VzIGFyZSB0Y3Atb3B0K2FkYyttYW55IG90aGVy IGZ1bmN0aW9uc+KApiBzbyBpcyBpdCBhIG11bHRpIGZ1bmN0aW9uIHR5cGUuIElmIHRoZSBhbnN3 ZXIgaXMgeWVzIHRoZW4gaXQgaXMgYSBzZXQgb2YgdHlwZS4gDQpjKSBIYXZpbmcgYSB0eXBlIG1l YW5zIHlldCBhbm90aGVyIHNlbWFudGljcyB0byBkZWFsIHdpdGgsIGFnYWluIGZyb20gdGhlIGJh cmUgbWluaW1hbCByZXF1aXJlbWVudCBpdCBtaWdodCBiZSBub24tZXNzZW50aWFsIGJ1dCB1c2Vm dWwgaW5mb3JtYXRpb24uDQoNClRob3VnaHRzPw0KDQpPbiAzLzI5LzE3LCA3OjExIEFNLCAiUm9i ZXJ0YSBNYWdsaW9uZSAocm9ibWdsKSIgPHJvYm1nbEBjaXNjby5jb20+IHdyb3RlOg0KDQogICAg SGVsbG8gU3VtYW5kcmEsDQogICAgSSBsaXN0ZW5lZCB0byB5b3VyIHByZXNlbnRhdGlvbiBpbiBz ZmMgeWVzdGVyZGF5IGFuZCBJIGhhdmUgYSBjb21tZW50Og0KICAgIGluIHNsaWRlIDMsIGFzIHBh cnQgb2YgdGhlIG1pbmltYWwgY29uZmlndXJhdGlvbiByZXF1aXJlbWVudHMgeW91IGxpc3RlZCB0 aGUgU0YgTmFtZS4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IFNGIG5hbWUgaXMgbmVlZGVkIGZvciB0 aGUgY29uZmlndXJhdGlvbiwgYnV0IHdoZW4gd2UgZmlyc3QgbG9va2VkIGF0IHRoaXMgcHJvYmxl bSB3aGF0IHdlIHRob3VnaHQgIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIGNvbnRyb2xsZXIg dG8gaGF2ZSBpcyBhbiBhZGRpdGlvbmFsIGxldmVsIG9mIGFic3RyYWN0aW9uICBmb3IgU2Vydmlj ZSBGdW5jdGlvbiB0eXBlLiBUaGUgcmVhc29uIGZvciB0aGlzIGlzIGJlY2F1c2UgdGhlcmUgY291 bGQgYmUgbXVsdGlwbGUgIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBTRiB0eXBlIGFuZCB0aGUgY29u dHJvbGxlciBtYXkgYmUgYWJsZSB0byBjaG9vc2Ugd2hpY2ggaW5zdGFuY2UgdG8gdXNlIHRvIGJ1 aWxkIGEgc3BlY2lmaWMgY2hhaW4uIFRoZSBjb25jZXB0IG9mICAic2VydmljZSBmdW5jdGlvbiB0 eXBlIiBpcyBhbHNvIHBhcnQgb2YgdGhlIGJncC9iZXNzIG5zaCBkcmFmdC4NCiAgICBQbGVhc2Ug bGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsuDQogICAgVGhhbmtzDQogICAgUm9iZXJ0YQ0KICAg IA0KICAgIA0KDQo=