From nobody Sun Dec 3 21:29:00 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F57B126B72 for ; Sun, 3 Dec 2017 21:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oxrVaA66cTw for ; Sun, 3 Dec 2017 21:28:56 -0800 (PST) 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 17497124D37 for ; Sun, 3 Dec 2017 21:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56084; q=dns/txt; s=iport; t=1512365336; x=1513574936; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SFpnX61ZeACyQ3QrjGsngzGz8mBDHASdpOC7UhHaQH0=; b=DCMXtGwZT+Ren40mMb19/uQUkuk9ZpHyNMJ0ZXoFOIwNY7Zv6mlE4CaW SHTNfKjdzl0YY72bmp8QNyiuhjvhXKSdHtVEDShsMMRiDs/2b9oRGiMW0 9CzVLYlJCI6/fYS0QaSd1wFIqzEgTcG0iL6ldklQmw1hh+r5N/5Ex9hix I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AADy2yRa/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJweDeIogjnSBfYh0jg2CEgMKGAEKhRgCGoURPxgBAQE?= =?us-ascii?q?BAQEBAQFrHQuFIgEBAQQBASFLGwIBCBEDAQIhAQYDAgICHwYLFAkIAgQTCYk1T?= =?us-ascii?q?AMVEKdigicmhwkNgxgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhUtUgmspgXSBDoF?= =?us-ascii?q?JgRASOYFWETYWgl8xgjIFmTqIdT0Ch3KDa4Q4hHqTVo07iGUCERkBgTkBHzmBT?= =?us-ascii?q?W8VOioBgX4JgkkMEIFneIdMgTOBFAEBAQ?= X-IronPort-AV: E=Sophos; i="5.45,357,1508803200"; d="scan'208,217"; a="39807245" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Dec 2017 05:28:44 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vB45Sibo025275 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Dec 2017 05:28:44 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 4 Dec 2017 00:28:43 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Mon, 4 Dec 2017 00:28:43 -0500 From: "Marc Portoles Comeras (mportole)" To: "lisp@ietf.org" Thread-Topic: [lisp] RFC6830bis and multiprotocol support Thread-Index: AQHTaWH+PD7Ok2jFlUCIS7iQFH0MsqMsRiaAgAAAeICAAAMCgIAABGQAgAAAxgCAAAG6gIAAG+mAgABbWgCAAANegIAAJbCAgAAhTQCAAE/GgIAAOKYAgAVoAAA= Date: Mon, 4 Dec 2017 05:28:43 +0000 Message-ID: <035D7D09-C4A9-4E14-A4DB-4BED6498F41D@cisco.com> References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <5f8210ab-3281-2686-c8df-e584173ab481@cisco.com> <53CFBDF2-3DF5-4A1A-B90D-4209FD251571@gmail.com> <646859C5-7A0A-479F-8FB8-E37DF6742DE3@gmail.com> <13f18cab-7017-0af3-6da6-074aed8cb24f@ac.upc.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.32.170] Content-Type: multipart/alternative; boundary="_000_035D7D09C4A94E14A4DB4BED6498F41Dciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 05:28:59 -0000 --_000_035D7D09C4A94E14A4DB4BED6498F41Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG9vLg0KVGhpcyBleHRlbnNpb24gZW5hYmxlcyB0aGUgcG9zc2liaWxpdHkgdG8gY2Fycnkg TDIgcGFja2V0cyBhbmQgcHJvdmlkZXMgYSBwYXRoIHRvIGNvbXBsZXRlbHkgc3VwcG9ydCB0aGUg ZWlkLW1vYmlsaXR5IGRyYWZ0Lg0KDQpNYXJjDQoNCkZyb206IGxpc3AgPGxpc3AtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mICJWaW5hIEVybWFnYW4gKHZlcm1hZ2FuKSIgPHZlcm1hZ2Fu QGNpc2NvLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBOb3ZlbWJlciAzMCwgMjAxNyBhdCAxMDo1NSBB TQ0KVG86ICJsaXNwQGlldGYub3JnIiA8bGlzcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbGlz cF0gUkZDNjgzMGJpcyBhbmQgbXVsdGlwcm90b2NvbCBzdXBwb3J0DQoNCisxIG9uIHByb3Bvc2Vk IGV4dGVuc2lvbi4NCg0KVGhpcyB3b3VsZCBlbmFibGUgTElTUCB0byBjYXJyeSBMMiBwYXlsb2Fk IGFuZCBOU0ggYXMgd2VsbCwgd2hpY2ggYXJlIGFsbCBpbXBsZW1lbnRlZCBpbiBGRC5pbyAoVlBQ KSBhbmQgYW5kIGludGVyb3BlcmFibGUgd2l0aCBPREwgTWFwcGluZyBTZXJ2ZXIuDQoNCkJlc3Qs DQpWaW5hDQoNCkZyb206IGxpc3AgPGxpc3AtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bGlzcC1i b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lA Z21haWwuY29tPG1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tPj4NCkRhdGU6IFRodXJzZGF5LCBO b3ZlbWJlciAzMCwgMjAxNyBhdCA3OjMyIEFNDQpUbzogQWxiZXJ0IENhYmVsbG9zIDxhbGJlcnQu Y2FiZWxsb3NAZ21haWwuY29tPG1haWx0bzphbGJlcnQuY2FiZWxsb3NAZ21haWwuY29tPj4NCkNj OiAibGlzcEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz4iIDxsaXNwQGlldGYub3JnPG1h aWx0bzpsaXNwQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbGlzcF0gUkZDNjgzMGJpcyBhbmQg bXVsdGlwcm90b2NvbCBzdXBwb3J0DQoNCisxIGhlcmUgdG9vLiBJIGNhbiBkbyBhbiBpbXBsYW50 YXRpb24gc28gSSBjYW4gaW50ZXJvcGVyYXRlIHdpdGggdGhlIG90aGVyIGltcGxlbWVudGF0aW9u cy4NCg0KRGlubw0KDQpPbiBOb3YgMzAsIDIwMTcsIGF0IDI6NDYgQU0sIEFsYmVydCBDYWJlbGxv cyA8YWxiZXJ0LmNhYmVsbG9zQGdtYWlsLmNvbTxtYWlsdG86YWxiZXJ0LmNhYmVsbG9zQGdtYWls LmNvbT4+IHdyb3RlOg0KSGkgYWxsDQoNClN1cHBvcnQgcHJvcG9zZWQgNjgzMGJpcyBleHRlbnNp b24uDQoNClRoaXMgaXMgaW5kZWVkIGltcGxtZW1lbnRlZCBpbiBPT1IuDQoNCkFsYmVydA0KDQpP biBUaHUsIE5vdiAzMCwgMjAxNyBhdCA5OjQ3IEFNLCBBbGJlcnQgTMOzcGV6IDxhbG9wZXpAYWMu dXBjLmVkdTxtYWlsdG86YWxvcGV6QGFjLnVwYy5lZHU+PiB3cm90ZToNCisxDQoNCkkgYWxzbyBz dXBwb3J0IGV4dGVuZGluZyBSRkMgNjgzMGJpcyBhcyBzdWdnZXN0ZWQuIFdlIGhhdmUgYW4gaW5p dGlhbCBpbXBsZW1lbnRhdGlvbiBvZiBMSVNQLUdQRSBpbiBPT1IgYW5kIHdlIHRoaW5rIHRoaXMg ZXh0ZW5zaW9uIGNvdWxkIGJlIHJlYWxseSB1c2VmdWwuDQoNCkFsYmVydCBMw7NwZXoNCg0KDQoN CkVsIDMwLzExLzE3IGEgbGVzIDA3OjMyLCBGbG9yaW4gQ29yYXMgaGEgZXNjcml0Og0KKzENCg0K VGhlIExJU1AgaW1wbGVtZW50YXRpb24gaW4gRkQuaW88aHR0cDovL0ZELmlvPiBWUFAgbWFrZXMg dXNlIG9mIGl0IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gRXRoZXJuZXQsIElQIGFuZCBOU0ggcGF5 bG9hZHMuDQoNCkZsb3Jpbg0KDQoNCk9uIE5vdiAyOSwgMjAxNywgYXQgMTA6MjAgUE0sIFZpY3Rv ciBNb3Jlbm8gKHZpbW9yZW5vKSA8dmltb3Jlbm9AY2lzY28uY29tPG1haWx0bzp2aW1vcmVub0Bj aXNjby5jb20+PiB3cm90ZToNCg0KSeKAmW0gc3Ryb25nbHkgc3VwcG9ydGl2ZSBvZiB0aGlzIHBy b3Bvc2FsIGFzIGl0IGNvbXBsZXRlcyB0aGUgbmVjZXNzYXJ5IHNwZWNpZmljYXRpb25zIHRvIHN1 cHBvcnQgdGhlIEwyIHNlcnZpY2VzIHByb3Bvc2VkIGluIHRoZSBlaWQtbW9iaWxpdHkgZHJhZnQu DQpWaWN0b3INCg0KT24gTm92IDI5LCAyMDE3LCBhdCA0OjU0IFBNLCBGYWJpbyBNYWlubyAoZm1h aW5vKSA8Zm1haW5vQGNpc2NvLmNvbTxtYWlsdG86Zm1haW5vQGNpc2NvLmNvbT4+IHdyb3RlOg0K c291bmRzIGdvb2QuDQoNCkZhYmlvDQoNCk9uIDExLzI5LzE3IDM6MTMgUE0sIERpbm8gRmFyaW5h Y2NpIHdyb3RlOg0KDQpJ4oCZZCBhbHNvIGFkZCBiZWZvcmUgdGhlIGxhc3Qgc2VudGVuY2U6DQoN CklmIHRoZSBOLWJpdCBhbmQgVi1iaXQgYXJlIDAgd2hlbiB0aGUgUC1iaXQgaXMgc2V0LCB0aGUg bWlkZGxlIDE2LWJpdHMgYXJlIHNldCB0byAwLg0KDQpEaW5vDQoNCk9uIE5vdiAyOSwgMjAxNywg YXQgMzowNyBQTSwgRmFiaW8gTWFpbm8gPGZtYWlub0BjaXNjby5jb208bWFpbHRvOmZtYWlub0Bj aXNjby5jb20+PiB3cm90ZToNCg0KT24gMTEvMjkvMTcgMzowNSBQTSwgRGlubyBGYXJpbmFjY2kg d3JvdGU6DQpIb3cgYWJvdXQgdGhpcyB3b3JkaW5nIEZhYmlvOg0KDQpQOiBUaGUgUC1iaXQgaXMg dGhlIE5leHQgUHJvdG9jb2wgYml0LiBXaGVuIHNldCwgdGhlIGxvdy1vcmRlciA4IGJpdHMgaXMg dXNlZCBmb3IgdGhlIE5leHQgUHJvdG9jb2wgZmllbGQuIFdoZW4gdGhlIE4tYml0IGlzIGFsc28g c2V0IHdpdGggdGhlIFAtYml0LCB0aGUgTm9uY2UgZmllbGQgaXMgdGhlIG1pZGRsZSAxNiBiaXRz LiBXaGVuIHRoZSBWIGJpdCBpcyBhbHNvIHNldCB3aXRoIHRoZSBQLWJpdCwgdGhlIFZlcnNpb24g ZmllbGQgaXMgdGhlIG1pZGRsZSAxNiBiaXRzLiBEZXRhaWxzIG9uIE5leHQgUHJvdG9jb2wgZmll bGQgdXNhZ2UgYXJlIGRlc2NyaWJlZCBpbiBbZHJhZnQtbGV3aXMtbGlzcC1ncGVdLg0KDQpDb21t ZW50cz8NCm11Y2ggYmV0dGVyLg0KDQpUaGFua3MsDQpGYWJpbw0KDQpEaW5vDQoNCk9uIE5vdiAy OSwgMjAxNywgYXQgMjo0OSBQTSwgRmFiaW8gTWFpbm8gPGZtYWlub0BjaXNjby5jb208bWFpbHRv OmZtYWlub0BjaXNjby5jb20+PiB3cm90ZToNCg0KRGVmaW5pdGlvbiBvZiB0aGUgUCBiaXQgd2ls bCBsb29rIGxpa2U6DQoNCiAgIFA6IFRoZSBQLWJpdCBpcyB0aGUgTmV4dCBQcm90b2NvbCBiaXQu IFdoZW4gdGhpcyBiaXQgaXMgc2V0IHRvDQogICAgICAxLCBOb25jZSBsZW5ndGgsIHdoZW4gdXNl ZCwgaXMgbGltaXRlZCB0byAxNiBiaXRzIGFuZCB0aGUgbGVuZ2h0DQogICAgICBvZiB0aGUgU291 cmNlIGFuZCBEZXN0aW5hdGlvbiBNYXAtVmVyc2lvbiBmaWVsZHMsIHdoZW4gdXNlZCwgaXMgbGlt aXRlZA0KICAgICAgdG8gOCBiaXRzLiBSZWZlciB0byBbZHJhZnQtbGV3aXMtbGlzcC1ncGVdIGZv ciBtb3JlIGRldGFpbHMuDQogICAgICBUaGUgUC1iaXQgaXMgc2V0IHRvIDEgdG8gaW5kaWNhdGUg dGhlIHByZXNlbmNlIG9mIHRoZSA4IGJpdCBOZXh0IFByb3RvY29sIGZpZWxkIGVuY29kZWQgYXM6 DQoNCg0KDQpEbyB5b3UgdGhpbmsgdGhlIG92ZXJhbGwgcHJvcG9zZWQgZXh0ZW5zaW9uIG1ha2Vz IHNlbnNlPw0KDQpUaGFua3MsDQpGYWJpbw0KDQpPbiAxMS8yOS8xNyAyOjM4IFBNLCBGYWJpbyBN YWlubyB3cm90ZToNCk9uIDExLzI5LzE3IDI6MzYgUE0sIERpbm8gRmFyaW5hY2NpIHdyb3RlOg0K VGhlIHVzZSBvZiB0aGUgUC1iaXQgaXMgbm90IGNvbXBhdGlibGUgd2l0aCB0aGUgTWFwLVZlcnNp b25pbmcgZmVhdHVyZSwgYnV0IGFuIGVxdWl2YWxlbnQgZnVuY3Rpb24gY2FuIGJlIHNwZWNpZmll ZCAoaWYgbmVlZGVkKSB3aXRoIGEgTmV4dC1Qcm90b2NvbCBzaGltIGhlYWRlci4gSSBjYW4gYWRk IHRleHQgdG8gdGhlIExJU1AtR1BFIGRyYWZ0IHRvIHJlZmxlY3QgdGhhdC4NCldlbGwgaXQgY291 bGQgYmUuIEp1c3QgbGlrZSB5b3UgZGlkIHdpdGggdGhlIE5vbmNlIGZpZWxkLiBNYWtlIHRoZSBW ZXJzaW9uIGZpZWxkIHRoZSBtaWRkbGUgMTYtYml0cy4gU28gViBhbmQgUCBjYW4gYmUgc2V0IGF0 IHRoZSBzYW1lIGFzIHdlbGwgYXMgTiBhbmQgUC4NCg0KRGlubw0KDQpHb29kIHBvaW50LCBzaG9y dGVuaW5nIHZlcnNpb25zIHRvIDggYml0cy4uLg0KDQpTZWVtcyBmaW5lIHRvIG1lLg0KDQoNCkZh YmlvDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpsaXNwIG1haWxpbmcgbGlzdA0KbGlzcEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxpc3AgbWFpbGluZyBsaXN0 DQpsaXNwQGlldGYub3JnPG1haWx0bzpsaXNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmxpc3AgbWFpbGluZyBsaXN0DQpsaXNwQGlldGYub3JnPG1h aWx0bzpsaXNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9saXNwDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bGlzcCBtYWlsaW5nIGxpc3QNCmxpc3BAaWV0Zi5vcmc8bWFpbHRvOmxpc3BAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbGlzcCBtYWlsaW5n IGxpc3QNCg0KbGlzcEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbGlzcCBtYWlsaW5nIGxpc3QNCmxpc3BAaWV0Zi5v cmc8bWFpbHRvOmxpc3BAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpc3ANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmxpc3AgbWFpbGluZyBsaXN0DQpsaXNwQGlldGYub3JnPG1haWx0bzpsaXNwQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQo= --_000_035D7D09C4A94E14A4DB4BED6498F41Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4E1E2E259A86AB4389F7E48CF738CED2@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpQTWluZ0xpVTsNCglwYW5vc2UtMToyIDIgNSAwIDAgMCAwIDAg MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m IzQzOzEgdG9vLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZXh0 ZW5zaW9uIGVuYWJsZXMgdGhlIHBvc3NpYmlsaXR5IHRvIGNhcnJ5IEwyIHBhY2tldHMgYW5kIHBy b3ZpZGVzIGEgcGF0aCB0byBjb21wbGV0ZWx5IHN1cHBvcnQgdGhlIGVpZC1tb2JpbGl0eSBkcmFm dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyYzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5saXNwICZsdDtsaXNw LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtWaW5hIEVybWFnYW4gKHZl cm1hZ2FuKSZxdW90OyAmbHQ7dmVybWFnYW5AY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UaHVyc2RheSwgTm92ZW1iZXIgMzAsIDIwMTcgYXQgMTA6NTUgQU08YnI+DQo8Yj5UbzogPC9i PiZxdW90O2xpc3BAaWV0Zi5vcmcmcXVvdDsgJmx0O2xpc3BAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbbGlzcF0gUkZDNjgzMGJpcyBhbmQgbXVsdGlwcm90b2NvbCBzdXBw b3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiYjNDM7MSBvbiBwcm9wb3NlZCBleHRlbnNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhpcyB3b3VsZCBlbmFibGUgTElTUCB0byBjYXJyeSBMMiBw YXlsb2FkIGFuZCBOU0ggYXMgd2VsbCwgd2hpY2ggYXJlIGFsbCBpbXBsZW1lbnRlZCBpbiBGRC5p byAoVlBQKSBhbmQgYW5kIGludGVyb3BlcmFibGUgd2l0aCBPREwgTWFwcGluZyBTZXJ2ZXIuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QmVzdCw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5WaW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmxpc3Ag Jmx0OzxhIGhyZWY9Im1haWx0bzpsaXNwLWJvdW5jZXNAaWV0Zi5vcmciPmxpc3AtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaW5vIEZhcmluYWNjaSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20iPmZhcmluYWNjaUBnbWFpbC5jb208L2E+Jmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMzAsIDIwMTcgYXQgNzozMiBBTTxi cj4NCjxiPlRvOiA8L2I+QWxiZXJ0IENhYmVsbG9zICZsdDs8YSBocmVmPSJtYWlsdG86YWxiZXJ0 LmNhYmVsbG9zQGdtYWlsLmNvbSI+YWxiZXJ0LmNhYmVsbG9zQGdtYWlsLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyI+bGlzcEBp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3JnIj5saXNw QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtsaXNwXSBSRkM2ODMw YmlzIGFuZCBtdWx0aXByb3RvY29sIHN1cHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mIzQzOzEgaGVyZSB0b28uIEkg Y2FuIGRvIGFuIGltcGxhbnRhdGlvbiBzbyBJIGNhbiBpbnRlcm9wZXJhdGUgd2l0aCB0aGUgb3Ro ZXIgaW1wbGVtZW50YXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkRpbm88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8YnI+DQpPbiBO b3YgMzAsIDIwMTcsIGF0IDI6NDYgQU0sIEFsYmVydCBDYWJlbGxvcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFsYmVydC5jYWJlbGxvc0BnbWFpbC5jb20iPmFsYmVydC5jYWJlbGxvc0BnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaSBhbGwgPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlN1cHBvcnQgcHJvcG9zZWQgNjgzMGJp cyBleHRlbnNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+VGhpcyBpcyBpbmRlZWQgaW1wbG1lbWVudGVkIGluIE9PUi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbGJlcnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiBUaHUsIE5vdiAzMCwgMjAxNyBhdCA5OjQ3IEFN LCBBbGJlcnQgTMOzcGV6ICZsdDs8YSBocmVmPSJtYWlsdG86YWxvcGV6QGFjLnVwYy5lZHUiIHRh cmdldD0iX2JsYW5rIj5hbG9wZXpAYWMudXBjLmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiYjNDM7MSZuYnNwOyA8YnI+DQo8YnI+DQpJIGFsc28gc3Vw cG9ydCBleHRlbmRpbmcgUkZDIDY4MzBiaXMgYXMgc3VnZ2VzdGVkLiBXZSBoYXZlIGFuIGluaXRp YWwgaW1wbGVtZW50YXRpb24gb2YgTElTUC1HUEUgaW4gT09SIGFuZCB3ZSB0aGluayB0aGlzIGV4 dGVuc2lvbiBjb3VsZCBiZSByZWFsbHkgdXNlZnVsLjxicj4NCjxicj4NCkFsYmVydCBMw7NwZXo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUmcXVvdDssc2VyaWYiPjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj5FbCAzMC8xMS8xNyBhIGxlcyAwNzozMiwgRmxvcmlu IENvcmFzIGhhIGVzY3JpdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mIzQzOzEgPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBMSVNQIGltcGxlbWVudGF0 aW9uIGluIDxhIGhyZWY9Imh0dHA6Ly9GRC5pbyIgdGFyZ2V0PSJfYmxhbmsiPg0KRkQuaW88L2E+ Jm5ic3A7VlBQIG1ha2VzIHVzZSBvZiBpdCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIEV0aGVybmV0 LCBJUCBhbmQgTlNIIHBheWxvYWRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPkZsb3JpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5PbiBOb3YgMjksIDIwMTcsIGF0IDEwOjIwIFBNLCBWaWN0b3IgTW9yZW5vICh2aW1v cmVubykgJmx0OzxhIGhyZWY9Im1haWx0bzp2aW1vcmVub0BjaXNjby5jb20iIHRhcmdldD0iX2Js YW5rIj52aW1vcmVub0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 MTIuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KSeKAmW0gc3Ryb25nbHkgc3VwcG9ydGl2ZSBvZiB0 aGlzIHByb3Bvc2FsIGFzIGl0IGNvbXBsZXRlcyB0aGUgbmVjZXNzYXJ5IHNwZWNpZmljYXRpb25z IHRvIHN1cHBvcnQgdGhlIEwyIHNlcnZpY2VzIHByb3Bvc2VkIGluIHRoZSBlaWQtbW9iaWxpdHkg ZHJhZnQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5WaWN0b3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+ DQo8YnI+DQpPbiBOb3YgMjksIDIwMTcsIGF0IDQ6NTQgUE0sIEZhYmlvIE1haW5vIChmbWFpbm8p ICZsdDs8YSBocmVmPSJtYWlsdG86Zm1haW5vQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZt YWlub0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnNvdW5k cyBnb29kLjxicj4NCjxicj4NCkZhYmlvPGJyPg0KPGJyPg0KT24gMTEvMjkvMTcgMzoxMyBQTSwg RGlubyBGYXJpbmFjY2kgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5J4oCZZCBhbHNvIGFkZCBi ZWZvcmUgdGhlIGxhc3Qgc2VudGVuY2U6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPklmIHRoZSBOLWJpdCBhbmQgVi1iaXQgYXJlIDAgd2hlbiB0aGUg UC1iaXQgaXMgc2V0LCB0aGUgbWlkZGxlIDE2LWJpdHMgYXJlIHNldCB0byAwLjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5EaW5vPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gTm92IDI5LCAyMDE3 LCBhdCAzOjA3IFBNLCBGYWJpbyBNYWlubyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZtYWlub0BjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj5mbWFpbm9AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiAxMS8yOS8xNyAzOjA1IFBNLCBEaW5vIEZhcmlu YWNjaSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Ib3cg YWJvdXQgdGhpcyB3b3JkaW5nIEZhYmlvOjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlA6IFRoZSBQLWJpdCBpcyB0aGUgTmV4dCBQ cm90b2NvbCBiaXQuIFdoZW4gc2V0LCB0aGUgbG93LW9yZGVyIDggYml0cyBpcyB1c2VkIGZvciB0 aGUgTmV4dCBQcm90b2NvbCBmaWVsZC4gV2hlbiB0aGUgTi1iaXQgaXMgYWxzbyBzZXQgd2l0aCB0 aGUgUC1iaXQsIHRoZSBOb25jZSBmaWVsZCBpcyB0aGUgbWlkZGxlIDE2IGJpdHMuIFdoZW4gdGhl IFYgYml0IGlzIGFsc28NCiBzZXQgd2l0aCB0aGUgUC1iaXQsIHRoZSBWZXJzaW9uIGZpZWxkIGlz IHRoZSBtaWRkbGUgMTYgYml0cy4gRGV0YWlscyBvbiBOZXh0IFByb3RvY29sIGZpZWxkIHVzYWdl IGFyZSBkZXNjcmliZWQgaW4gW2RyYWZ0LWxld2lzLWxpc3AtZ3BlXS48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db21tZW50cz88 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+bXVj aCBiZXR0ZXIuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3MsPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkZhYmlvPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkRpbm88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIE5vdiAyOSwgMjAxNywgYXQgMjo0OSBQTSwgRmFiaW8gTWFp bm8gJmx0OzxhIGhyZWY9Im1haWx0bzpmbWFpbm9AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ Zm1haW5vQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5EZWZpbml0aW9uIG9mIHRoZSBQIGJpdCB3aWxsIGxvb2sgbGlrZTo8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7UDog VGhlIFAtYml0IGlzIHRoZSBOZXh0IFByb3RvY29sIGJpdC4gV2hlbiB0aGlzIGJpdCBpcyBzZXQg dG88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzEs IE5vbmNlIGxlbmd0aCwgd2hlbiB1c2VkLCBpcyBsaW1pdGVkIHRvIDE2IGJpdHMgYW5kIHRoZSBs ZW5naHQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O29mIHRoZSBTb3VyY2UgYW5kIERlc3RpbmF0aW9uIE1hcC1WZXJzaW9uIGZpZWxkcywgd2hlbiB1 c2VkLCBpcyBsaW1pdGVkPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt0byA4IGJpdHMuIFJlZmVyIHRvIFtkcmFmdC1sZXdpcy1saXNwLWdwZV0gZm9y IG1vcmUgZGV0YWlscy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO1RoZSBQLWJpdCBpcyBzZXQgdG8gMSB0byBpbmRpY2F0ZSB0aGUgcHJlc2VuY2Ug b2YgdGhlIDggYml0IE5leHQgUHJvdG9jb2wgZmllbGQgZW5jb2RlZCBhczo8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkRvIHlvdSB0aGluayB0aGUgb3ZlcmFsbCBwcm9wb3NlZCBleHRlbnNp b24gbWFrZXMgc2Vuc2U/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkZhYmlvPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPk9uIDExLzI5LzE3IDI6MzggUE0sIEZhYmlvIE1haW5vIHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5PbiAxMS8yOS8xNyAyOjM2IFBNLCBEaW5vIEZhcmluYWNjaSB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSB1c2Ugb2YgdGhlIFAtYml0IGlz IG5vdCBjb21wYXRpYmxlIHdpdGggdGhlIE1hcC1WZXJzaW9uaW5nIGZlYXR1cmUsIGJ1dCBhbiBl cXVpdmFsZW50IGZ1bmN0aW9uIGNhbiBiZSBzcGVjaWZpZWQgKGlmIG5lZWRlZCkgd2l0aCBhIE5l eHQtUHJvdG9jb2wgc2hpbSBoZWFkZXIuIEkgY2FuIGFkZCB0ZXh0IHRvIHRoZSBMSVNQLUdQRSBk cmFmdCB0byByZWZsZWN0IHRoYXQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2VsbCBpdCBjb3VsZCBiZS4gSnVzdCBsaWtl IHlvdSBkaWQgd2l0aCB0aGUgTm9uY2UgZmllbGQuIE1ha2UgdGhlIFZlcnNpb24gZmllbGQgdGhl IG1pZGRsZSAxNi1iaXRzLiBTbyBWIGFuZCBQIGNhbiBiZSBzZXQgYXQgdGhlIHNhbWUgYXMgd2Vs bCBhcyBOIGFuZCBQLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkRpbm88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+R29vZCBwb2ludCwgc2hvcnRlbmluZyB2ZXJzaW9ucyB0byA4IGJpdHMuLi48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlNlZW1zIGZpbmUgdG8gbWUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RmFiaW88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPmxpc3AgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bGlzcEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmxpc3AgbWFpbGluZyBsaXN0PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmxpc3BAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3AiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3A8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbGlzcCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxpc3BA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9saXNwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9saXNwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmxpc3Ag bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5saXNwQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGlzcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPmxpc3AgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bGlzcEBpZXRmLm9yZzwvYT48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3AiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3A8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmxpc3AgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxpc3BAaWV0Zi5vcmciPmxpc3BAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNw IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s aXNwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbGlzcCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86bGlzcEBpZXRmLm9yZyI+bGlzcEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3AiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_035D7D09C4A94E14A4DB4BED6498F41Dciscocom_-- From isidor.kouvelas@gmail.com Tue Dec 5 08:52:10 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3760412956C for ; Tue, 5 Dec 2017 08:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 ngjqourV9K0d for ; Tue, 5 Dec 2017 08:52:08 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B6C12949D for ; Tue, 5 Dec 2017 08:52:08 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id 9so2507932wme.4 for ; Tue, 05 Dec 2017 08:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=9S6EFgMVKoWDdW56uznWm4/HlCT/FKEGk4T+OJHp11M=; b=JyPnac+Y5ZqsNBI7zJ4EWnhIQm2JGd3G92i741CdF+GGAxKaudPxML+GI7fGtGKT0Z LGO4km0JJnuY2MTR0M/ASiMMWMx/d0TMGk+gafKnft+fYOmkS/2MT2OBy2oFNKg4xbKW OQzTQukZ9BstHClaMAa6o2d78AKT88AP5//tWUbfST/2014foRJzq5rBausvX3kvLBkM M/GDzX7Xl127uA5R22d/tDD5REuusMejHa4R4UY+uknpMYKzLzYdgHgL94lr3ZrkxmJX H4SlSoRulwLf/atOWbJUqjFPhlyA8N7wmkCq5WkWdYz88g1ReaKDdsaPGkW1g3Aqx3WX S8rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=9S6EFgMVKoWDdW56uznWm4/HlCT/FKEGk4T+OJHp11M=; b=BqEvWbyfPOZFusp+yKEodoiKp0oUI7Dyd6ZKKTk909dsQwhWUIKZzTn87qwqRtF8ee 5yGbuNGF6P2aS4w71+0BnjuTq5L/pZbfgpUg+jmTOdE8dIlcVR3QlPgjWGkYPJZwf/pv SQyXOZ2EeC8OLEG73lOvSgFRcfqE+bI9VWY4lVnfIYeGPvfA6xnzFxFmG4H/hDBglPuj HxjU5nCRgC5Rqa5JRY7aZkG/LM6QKueX0Ynu4a7NoOQ67K65qTMxaxaDLcD4FO8kgXpa 5cCIsoX68/fbelwHBu7gNiN3i0I1b9Xk/u0Kjn8EdVDkANj4vDxVJvscXP1RpVpPrzp4 QU0A== X-Gm-Message-State: AKGB3mIVBS3f5IkA29JI16/pGzEOPbfzCUCnLlVkFF8nFK0aigrTb8yr cZCtoRaiZWBjQ4EsaBq2MlxF3TXk X-Google-Smtp-Source: AGs4zMaJ2gPtVvbL9+rU1RDh364Q0eFiSTXcuJOoJaxFelMES4F4dX/PY2rs60aQcwASOVz6k9Wmlg== X-Received: by 10.28.192.24 with SMTP id q24mr6083797wmf.98.1512492726423; Tue, 05 Dec 2017 08:52:06 -0800 (PST) Received: from [192.168.3.44] (ppp-2-86-156-141.home.otenet.gr. [2.86.156.141]) by smtp.gmail.com with ESMTPSA id q13sm550711wrg.97.2017.12.05.08.52.04 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Dec 2017 08:52:05 -0800 (PST) Sender: Isidor Kouvelas From: isidor@kouvelas.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> Date: Tue, 5 Dec 2017 18:52:03 +0200 To: lisp@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 16:57:53 -0000 As discussed in Singapore, the authors of = draft-kouvelas-lisp-map-server-reliable-transport are looking for = working-group adoption of the draft. The proposed solution replaces the = UDP based control plane LISP communication between xTRs and Map-Servers = with a reliable transport session. This is done to eliminate the = periodic messaging and improve scaling by leveraging the reliability and = flow-controlled communication over the reliable transport. The draft was first presented to the WG at IETF 91, and has been fairly = stable since then. We would like to receive any comments you may have. thanks Isidor= From nobody Tue Dec 5 10:12:41 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAB4126579 for ; Tue, 5 Dec 2017 10:12:39 -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, FREEMAIL_FROM=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 nb07_5yEX1lg for ; Tue, 5 Dec 2017 10:12:38 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA6912009C for ; Tue, 5 Dec 2017 10:12:38 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id m25so688793pgv.12 for ; Tue, 05 Dec 2017 10:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PZaZavH/oyHClKACYkNC2xg6PbUWRxfTLUv3syhlbXU=; b=iTEgJDAxfXSrLfTQxoHUslocsj0N8EFHshxWdl+t1+LLGkkM3MqnRg6fjFLXfHGaCU 6eaWPcHg0awryJ1o4M6GcMxx9DCGXtmbNBZrpPCyFU0jpD1yhbMDpSNSQhFpbokUmYEg fUGxpmWpPgmtQTlsWj0G17NvSm4rnwt9g2zn3K9FMk7/Im8NMdjVaWXs+NqR+Nl1bigQ XOc8nHodtDtCj+bfFonuI7c/uw2qPOnnVtbFv9e5Vaz80LTcsk+fP+2r/wBjNhRDapcH w3hFiMhRvFRStMcLbZrPKROnT/JY2Lmfr2PHumrCWP/tKicv7nCohivAd+fqbwCscTH5 3LjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PZaZavH/oyHClKACYkNC2xg6PbUWRxfTLUv3syhlbXU=; b=EwbLYjQSnzpWSqP1bTuu1Q+om9SBvHeYIijkTglShUNCB4KN9k41ZFFtzFYtAc4JKM UWHdY0lS9Ad3HWc+EUeDyTW+TrSvR6p1rXObqO9FdfIHkSThhkMc0d1PXxSU90OkWhSJ jwhmZl3mwYp7MO9ZSIO1+/7EEciNxtnlraATlU3xXNnsqfPnPObZs7ZcNk1gLZN/YVVZ wNxkvLJwbKpI28TtLcLfhq1u9VolBpcjRyJqkl1tHaDqcszVQ/cMTLgAQpw9kpF1EQjI xjBz3ZoeCkoK5I20CzoxAKVLLRhyEyH64fWE4uxNBkd8IxnhbwnOGIqz25aUqaInu04L m0Wg== X-Gm-Message-State: AJaThX5M5DT0fu5Nxr6bJQxVryzohEwBI8HWIiZu9EYtPqyss7eqwQZf TdJ/jCC7EacN1x+YuNz1xX9e2OhL X-Google-Smtp-Source: AGs4zMYyDY9CwafMPzCTZ9D98eBYCtSjnbMxZHqd53O1qHnQlaWven6cMzDNGjgeHNXqXkd5muGGUw== X-Received: by 10.159.231.20 with SMTP id w20mr19901616plq.398.1512497557870; Tue, 05 Dec 2017 10:12:37 -0800 (PST) Received: from ?IPv6:2600:380:7731:4b80:3cc1:eed5:98cc:3d90? ([2600:380:7731:4b80:3cc1:eed5:98cc:3d90]) by smtp.gmail.com with ESMTPSA id v82sm1163330pfd.111.2017.12.05.10.12.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 10:12:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (15B202) In-Reply-To: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> Date: Tue, 5 Dec 2017 10:12:36 -0800 Cc: lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> To: isidor@kouvelas.net Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 18:12:40 -0000 > draft-kouvelas-lisp-map-server-reliable-transport are looking for working-= group adoption of the draft. The proposed solution replaces the UDP based co= ntrol Augments. We cannot remove UDP since there is too much deployment. And TCP i= s not always needed. And there is startup latency with the 3 way TCP handsha= ke. This will slow mobile handoffs.=20 I also brought up at the WG that we should consider other transport layers t= hat are more secure than TCP by itself. Since your draft doesn=E2=80=99t spe= c how to use TLS with TCP, QUIC may be a more lightweight, efficient and sec= ure alternative.=20 > plane LISP communication between xTRs and Map-Servers with a reliable tran= sport session. This is done to eliminate the periodic messaging and improve s= caling by You can eliminate the periodic overhead by sending Map-Registers less often a= nd solicited Map-Notifies as acks. And you can test for map-server reachabil= ity with RLOC-probes.=20 The only reason I bring this up is to disclose that we have existing mechani= sms to provide reliability.=20 And rather than have a completely new message parsing format, we could make t= his proposal simpler by using existing messages that are sent over ANY trans= port. I have made this comment before.=20 Note we did this in the PIM WG where existing messages are sent over TCP or S= CTP.=20 Dino= From nobody Tue Dec 5 10:44:15 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EFD129549 for ; Tue, 5 Dec 2017 10:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3Pu1Ae_4hRe for ; Tue, 5 Dec 2017 10:44:12 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A3512708C for ; Tue, 5 Dec 2017 10:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2179; q=dns/txt; s=iport; t=1512499452; x=1513709052; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=/6GT2ZjlRraowzXIEpFOJez1jRRIYFF+GMXENka7l4c=; b=K2nEyIlqaC3rExgzjCeVxF+34sVfGheD0zy2CdPo8fWlCNcknVzcEpMB 5jbb1/WQ8y5dTLF+x7jM3+UorsBjRxFHUpK/cclMhRMW7v9AMhApfbfeP 4w8gu1i7NBvPklHSRTECR/mrJ1XiC87W0OfkPmU7fiPWw13BwWocCaPw7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AAB56CZa/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9Zm4nhACKII57gU4vlwIUggEKGAuFGAKFSD8YAQEBAQEBAQE?= =?us-ascii?q?BayiFIgEBAQECAQEBIQ8BBTYbCxgCAiYCAicwEwYCAQEXigAIEKlSgieKWwEBA?= =?us-ascii?q?QEGAQEBAQEeBYEPgjmCCoFWgWkpgwKEZRURYoJJgmMFkxqPXJUTjAuHTZZRgTo?= =?us-ascii?q?fOYFNMhoIGxU6gimCUhwZgW8gN4digkcBAQE?= X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="scan'208";a="40116338" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Dec 2017 18:44:11 +0000 Received: from [10.155.70.219] (dhcp-10-155-70-219.cisco.com [10.155.70.219]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vB5IiAmr000809 for ; Tue, 5 Dec 2017 18:44:11 GMT To: lisp@ietf.org References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> From: Fabio Maino Message-ID: <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> Date: Tue, 5 Dec 2017 10:44:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 18:44:14 -0000 On 12/5/17 10:12 AM, Dino Farinacci wrote: >> draft-kouvelas-lisp-map-server-reliable-transport are looking for working-group adoption of the draft. The proposed solution replaces the UDP based control > Augments. We cannot remove UDP since there is too much deployment. And TCP is not always needed. And there is startup latency with the 3 way TCP handshake. This will slow mobile handoffs. Right, augment rather than replace. I believe there's no intention to replace UDP. The draft actually relies on UDP registration to bootstrap the TCP channel, and to ensure backward compatibility. > > I also brought up at the WG that we should consider other transport layers that are more secure than TCP by itself. Since your draft doesn’t spec how to use TLS with TCP, QUIC may be a more lightweight, efficient and secure alternative. QUIC would be an interesting option as well, probably worth of another draft and possibly not limited to registration messages only. I see this as a point optimization to the registration protocol, that might be orthogonal to other transport-related mechanisms. In my experience this has proved to be very effective in scalability of large LISP deployments, especially with the increased volume of registration data. Fabio > >> plane LISP communication between xTRs and Map-Servers with a reliable transport session. This is done to eliminate the periodic messaging and improve scaling by > You can eliminate the periodic overhead by sending Map-Registers less often and solicited Map-Notifies as acks. And you can test for map-server reachability with RLOC-probes. > > The only reason I bring this up is to disclose that we have existing mechanisms to provide reliability. > > And rather than have a completely new message parsing format, we could make this proposal simpler by using existing messages that are sent over ANY transport. I have made this comment before. > > Note we did this in the PIM WG where existing messages are sent over TCP or SCTP. > > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Dec 5 10:52:23 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14BA129649 for ; Tue, 5 Dec 2017 10:52:21 -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, FREEMAIL_FROM=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 GjzegehcPPh2 for ; Tue, 5 Dec 2017 10:52:20 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BCC129440 for ; Tue, 5 Dec 2017 10:52:08 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id f12so779522pgo.5 for ; Tue, 05 Dec 2017 10:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YFTOo6th80m5Gyr4jMIrVkxyjxu4ujtnsgtPJ6Bvw28=; b=sM/3OwOJpm4n9jsP6mB3rIZljIcPKXQEgyQtoO2yCPG9XOvxIz9QYyj/HYTvVIkqjo yzfPJO78OQ529vPZMh8jiE6lVHgmqLUPuCZp3EKv/qiV9oKiCUFs18QiLHZlO5zrXjlL KWs2oNkaaecAIeoRJGpDtDmrD3+/YRX3bVfeQbVQxH0pSdqzpoINp694sk8cwo3WTfO6 3h72Z2g99ywfr3wzxpt++xjklRECQtAw3O/IkZwAEqlmEzPbKpxIVGXOm0GIO0755W9R TvRbXiX0YnvI0ZSmaWG7WLQcYcDebwLyRKojWEGKjvp2RLu8KZU8J9A4r1WW4y5T0A1j zYXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YFTOo6th80m5Gyr4jMIrVkxyjxu4ujtnsgtPJ6Bvw28=; b=DF5HT/OUTpNf9kOV0VYyCjhM/FFRtiWZOrW9v5BMvQT3t2hxyX3Ku2maX8b00gMCnd 0gTNTa+wGUDFHxpsR2IK8XvhvOsnDTYDImNwjw+pU1HN9KOh0orkNhZ3LvNDgiz+fViO JrmMhOTZ2wbSMt+kW2uPtj45KEBRO3ovQc092FlhyrdGTMM2mtiQcPBzPxHkGrkQZ/pb CBQri3ceS+rPPKwf44N+pGAKwqC8kTkNJduV5OIrZ4fPlczxuvM/6xZl7UVaYIQCXnGz RPFZTwxX8RDKGTnzrma3BlxvrWDvNmyUiG/Ov1UnUSi/xAJ4NZX0KF9jKTlcYeSgMJfy 1Wjw== X-Gm-Message-State: AKGB3mIPov+s/XwzjeGDj1uHZRoKKSb+OKr9GalEB0XETqyllAFW+7B3 aVGFCXAGQstUNv39xhHDNDwYnb6g X-Google-Smtp-Source: AGs4zMbfd8Y3CgfzKOkNL8/3glrmmIvfWQUL/rRRDjZ8tGCm00hKFSTf/abJdHH/ensvSY4jVoZJxQ== X-Received: by 10.98.152.25 with SMTP id q25mr3559172pfd.58.1512499927357; Tue, 05 Dec 2017 10:52:07 -0800 (PST) Received: from ?IPv6:2600:380:7731:4b80:3cc1:eed5:98cc:3d90? ([2600:380:7731:4b80:3cc1:eed5:98cc:3d90]) by smtp.gmail.com with ESMTPSA id z2sm1073169pfh.39.2017.12.05.10.52.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 10:52:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (15B202) In-Reply-To: <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> Date: Tue, 5 Dec 2017 10:52:05 -0800 Cc: lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> To: Fabio Maino Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 18:52:22 -0000 > registration protocol, that might be orthogonal to other transport-relate= d mechanisms. In my experience this has proved to be very effective in scala= bility of large LISP deployments, especially with the increased volume of re= gistration data. I agree it=E2=80=99s a point solution for registration. Then why did you nee= d to have a general format.=20 I could support this draft if it was simplified to spec how to use Map-Regis= ters in TCP and nothing more.=20 The only thing I would add is how to use TLS so encryption is supported. Mor= e and more requirements are coming up for protecting the privacy of location= information. And since Map-Registers carry RLOCs (and potential Geo-Coordna= tes) that information needs to be protected.=20 Dino= From nobody Tue Dec 5 12:06:28 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D33412025C for ; Tue, 5 Dec 2017 12:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT36ij18rPlf for ; Tue, 5 Dec 2017 12:06:19 -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 71DF2126DCA for ; Tue, 5 Dec 2017 12:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1930; q=dns/txt; s=iport; t=1512504379; x=1513713979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HY3swOVJQOS9aiJmkTi2vkTCdzyVrYdoBGgPyEApWMY=; b=HdMhNvTex9RqaLALtrQ8w5N4MmzP7gNoDgIqK35ybKJKGO03Enun5i/s 6lj4PKq2whi88O4EOujCQQi/io4TgwPpYgwf3l48fu6BmlLjIfc4K7gsS JkhAdY5NzYrz0oTa8z1SKpULFHH/nmKPUac9fQWHrN725EKudnMBql4nM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgCd+yZa/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9Zm4nB4N5mRuBfYh0jg6CFQoYC4UYAhqFLkEWAQEBAQEBAQE?= =?us-ascii?q?BayiFIgEBAQECAQEBIRE6CwULAgEIGAICJgICAh8GCxUQAgQOBRuJcAMNCBCpQ?= =?us-ascii?q?oInhzcNgw4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhEWBVoFpKQuCd4JrgiA?= =?us-ascii?q?WgxUxgjIFojk9ApAXhHqTWI0+iGYCERkBgTkBJQEygU1vFToqAYF+glIcGYFOe?= =?us-ascii?q?IkPgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,365,1508803200"; d="scan'208";a="40698188" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Dec 2017 20:06:18 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vB5K6IR1006172 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Dec 2017 20:06:18 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Dec 2017 14:06:18 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1320.000; Tue, 5 Dec 2017 14:06:18 -0600 From: "Johnson Leong (joleong)" To: Dino Farinacci CC: "Fabio Maino (fmaino)" , "lisp@ietf.org" Thread-Topic: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption Thread-Index: AQHTbeo9EtGVHwDVv0CpzXF7TtVp96M1cgIAgAAI1ACAAAI0gIAAFL8A Date: Tue, 5 Dec 2017 20:06:17 +0000 Message-ID: References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> In-Reply-To: <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> 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.154.160.248] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 20:06:21 -0000 SGkgRGlubywNCg0KQSBsYXJnZSBwb3J0aW9uIG9mIHRoaXMgZHJhZnQgZGlzY3Vzc2VzIHRoZSBz dGF0ZSBtYWNoaW5lIHJlcXVpcmVkIGZvciBUQ1AgYW5kIGhvdyB0byBlbnN1cmUgdGhlIE1TIGFu ZCB4VFIgYXJlIGluIHN5bmMuICBXZSBsaXRlcmFsbHkgcmV1c2UgdGhlIGVudGlyZSBVRFAgbWFw LXJlZ2lzdGVyIGNvZGUsIHdlIGp1c3Qgd3JhcCB0aGF0IG1lc3NhZ2UgYXJvdW5kIHRoZSBMSVNQ IFRDUCBoZWFkZXIgc28gdGhlcmUncyBhIGxvdCBvZiBjb2RlIHJldXNlLiAgRmluYWxseSwgdGhp cyBkcmFmdCBpcyBub3QgbWVhbnQgdG8gcmVwbGFjZSBVRFAgcmVnaXN0ZXIgYnV0IGluIHNvbWUg b2Ygb3VyIHVzZSBjYXNlcyBUQ1Agd291bGQgc2NhbGUgYmV0dGVyIHRvIGF2b2lkIHRoZSBwZXJp b2RpYyByZWdpc3RyYXRpb24uDQoNCi1Kb2huc29uDQoNCj4gT24gRGVjIDUsIDIwMTcsIGF0IDEw OjUyIEFNLCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0K Pj4gcmVnaXN0cmF0aW9uIHByb3RvY29sLCB0aGF0IG1pZ2h0IGJlIG9ydGhvZ29uYWwgdG8gb3Ro ZXIgdHJhbnNwb3J0LXJlbGF0ZWQgbWVjaGFuaXNtcy4gSW4gbXkgZXhwZXJpZW5jZSB0aGlzIGhh cyBwcm92ZWQgdG8gYmUgdmVyeSBlZmZlY3RpdmUgaW4gc2NhbGFiaWxpdHkgb2YgbGFyZ2UgTElT UCBkZXBsb3ltZW50cywgZXNwZWNpYWxseSB3aXRoIHRoZSBpbmNyZWFzZWQgdm9sdW1lIG9mIHJl Z2lzdHJhdGlvbiBkYXRhLg0KPiANCj4gSSBhZ3JlZSBpdOKAmXMgYSBwb2ludCBzb2x1dGlvbiBm b3IgcmVnaXN0cmF0aW9uLiBUaGVuIHdoeSBkaWQgeW91IG5lZWQgdG8gaGF2ZSBhIGdlbmVyYWwg Zm9ybWF0LiANCj4gDQo+IEkgY291bGQgc3VwcG9ydCB0aGlzIGRyYWZ0IGlmIGl0IHdhcyBzaW1w bGlmaWVkIHRvIHNwZWMgaG93IHRvIHVzZSBNYXAtUmVnaXN0ZXJzIGluIFRDUCBhbmQgbm90aGlu ZyBtb3JlLiANCj4gDQo+IFRoZSBvbmx5IHRoaW5nIEkgd291bGQgYWRkIGlzIGhvdyB0byB1c2Ug VExTIHNvIGVuY3J5cHRpb24gaXMgc3VwcG9ydGVkLiBNb3JlIGFuZCBtb3JlIHJlcXVpcmVtZW50 cyBhcmUgY29taW5nIHVwIGZvciBwcm90ZWN0aW5nIHRoZSBwcml2YWN5IG9mIGxvY2F0aW9uIGlu Zm9ybWF0aW9uLiBBbmQgc2luY2UgTWFwLVJlZ2lzdGVycyBjYXJyeSBSTE9DcyAoYW5kIHBvdGVu dGlhbCBHZW8tQ29vcmRuYXRlcykgdGhhdCBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBwcm90ZWN0 ZWQuIA0KPiANCj4gRGlubw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBsaXNwIG1haWxpbmcgbGlzdA0KPiBsaXNwQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KDQo= From nobody Tue Dec 5 16:25:32 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77DE128B4E for ; Tue, 5 Dec 2017 16:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxgOKY51TP-k for ; Tue, 5 Dec 2017 16:25:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53CF1279EB for ; Tue, 5 Dec 2017 16:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3856; q=dns/txt; s=iport; t=1512519929; x=1513729529; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O+okUg9TjBNNcwD0qxkzD4GkLOQwAb6N7dorOE09i/A=; b=AqEUyaGSieeVW+oATd/Ox17o/Gs8sSCDua30Ec73k8r3NuAciO0JqyZO bx1SHMMRMVLcYBxn4LpMmiEBCvG0Xnq3stm+AQ0LJSqOwfuJXizqIcnrQ gZYCVXQU8W7zrEghxnq/KnCoGqIbpQjMhzoPh/Qa+HjBNN8F1G4ekuvim E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAwBdOCda/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOL2ZuJweDe5kcgVcmiHSODoIVChgLhRgCGoUuQBcBAQEBAQE?= =?us-ascii?q?BAQFrKFcBhEoBAQEDAQEBIRE6CxACAQgYAgImAgICHwYLFRACBAENBRuJcAMNC?= =?us-ascii?q?BCpbYInhzkNgw4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgjuCClSCaykLgne?= =?us-ascii?q?Ca4IgFoMVMYIyBaI5PQKQF4R6k1iNPohmAhEZAYE5ASABN4FNbxU6KgGBfoJSH?= =?us-ascii?q?BmBTniHHYFxgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,365,1508803200"; d="scan'208";a="327092366" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2017 00:25:28 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vB60PSfV015266 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 00:25:28 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Dec 2017 19:25:27 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Tue, 5 Dec 2017 19:25:27 -0500 From: "Marc Portoles Comeras (mportole)" To: "Johnson Leong (joleong)" , Dino Farinacci CC: "lisp@ietf.org" Thread-Topic: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption Thread-Index: AQHTbeo9leq2xF5iHkW7tPGXEoJPSqM1YT4AgAAI1ACAAAI0gIAAFLuAgABIaYA= Date: Wed, 6 Dec 2017 00:25:27 +0000 Message-ID: <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.32.56] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 00:25:32 -0000 RGlubywNCg0KSW4gYWRkaXRpb24gdG8gdGhlIHByZXZpb3VzIGFyZ3VtZW50cyB0aGVyZSBhcmUg cGFydGljdWxhciB1c2UtY2FzZXMgd2hlcmUgdGhlIHVzZSBvZiByZWxpYWJsZSB0cmFuc3BvcnQg c2ltcGxpZmllZCB0aGUgZGVwbG95bWVudCBvZiBMSVNQLg0KIA0KQXMgYW4gZXhhbXBsZSwgdGhl IG1vbWVudCB3ZSBzdGFydGVkIHNjYWxpbmcgZGF0YWNlbnRlcnMgdG8gc3VwcG9ydCAxMHMgb2Yg dGhvdXNhbmRzIG9mIGhvc3RzLCB0aGUgdXNlIG9mIGEgcmVsaWFibGUgdHJhbnNwb3J0IGhlbHBl ZCBhIGxvdCB0aGUgbWFuYWdlbWVudCBvZiBzY2FsZTogDQpPbiBvbmUgc2lkZSBpdCByZWR1Y2Vz IHRoZSBhbW91bnQgb2Ygc2lnbmFsaW5nIHdoZW4gbm90aGluZyBjaGFuZ2VzLCBzaW5jZSB3ZSB1 c2UgVENQIHN0YXRlIGFzIGFuIGluZGljYXRpb24gdGhhdCB4VFJzIGFuZCB0aGUgTVMgYXJlIGlu IHN5bmMgYW5kIHRoZXJlIGlzIG5vIG5lZWQgdG8gZGVhbCB3aXRoIHRoZSBvcHRpbWl6YXRpb24g b2YgdGhlIHJlZnJlc2ggbG9naWMgKHBlcmlvZGljIG9yIHBhY2VkKS4gDQpPbiB0aGUgb3RoZXIg c2lkZSwgd2l0aCByZWxpYWJsZSB0cmFuc3BvcnQgd2Ugb2ZmbG9hZCB0aGUgcmVsaWFibGUgZGVs aXZlcnkgb2YgaW5mb3JtYXRpb24gKGFuZCBjb25nZXN0aW9uIGNvbnRyb2wpIGZyb20gTElTUCB0 byBhbm90aGVyIHByb2Nlc3MgKFRDUCkgdGhhdCBpcyBlbnRpcmVseSBkZXZvdGVkIGFuZCBkZXNp Z25lZCBmb3IgdGhpcy4gRm9yIGV4YW1wbGUsIHN1cHBvcnRpbmcgZXZlbnRzIGxpa2UgbWFzcyBW TSBtb3ZlcyByZWx5aW5nIHB1cmVseSBvbiBMSVNQIGJhc2VkIEFDa3MgYmVjYW1lIHZlcnkgY2hh bGxlbmdpbmcsIGFzIHdlIGVuZGVkIHVwIGhhdmluZyB0byBkZWFsIHdpdGggY29uZ2VzdGlvbiBl dmVudHMgcmVsYXRlZCB0byB0aGUgc2lnbmFsaW5nIGxvYWQgZ2VuZXJhdGVkLiBUaGUgdXNlIG9m IHRoZSByZWxpYWJsZSB0cmFuc3BvcnQgbGFyZ2VseSBzaW1wbGlmaWVkIHRoZSBwcm9ibGVtLg0K DQpNYXJjDQoNCk9uIDEyLzUvMTcsIDEyOjA2IFBNLCAibGlzcCBvbiBiZWhhbGYgb2YgSm9obnNv biBMZW9uZyAoam9sZW9uZykiIDxsaXNwLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpv bGVvbmdAY2lzY28uY29tPiB3cm90ZToNCg0KICAgIEhpIERpbm8sDQogICAgDQogICAgQSBsYXJn ZSBwb3J0aW9uIG9mIHRoaXMgZHJhZnQgZGlzY3Vzc2VzIHRoZSBzdGF0ZSBtYWNoaW5lIHJlcXVp cmVkIGZvciBUQ1AgYW5kIGhvdyB0byBlbnN1cmUgdGhlIE1TIGFuZCB4VFIgYXJlIGluIHN5bmMu ICBXZSBsaXRlcmFsbHkgcmV1c2UgdGhlIGVudGlyZSBVRFAgbWFwLXJlZ2lzdGVyIGNvZGUsIHdl IGp1c3Qgd3JhcCB0aGF0IG1lc3NhZ2UgYXJvdW5kIHRoZSBMSVNQIFRDUCBoZWFkZXIgc28gdGhl cmUncyBhIGxvdCBvZiBjb2RlIHJldXNlLiAgRmluYWxseSwgdGhpcyBkcmFmdCBpcyBub3QgbWVh bnQgdG8gcmVwbGFjZSBVRFAgcmVnaXN0ZXIgYnV0IGluIHNvbWUgb2Ygb3VyIHVzZSBjYXNlcyBU Q1Agd291bGQgc2NhbGUgYmV0dGVyIHRvIGF2b2lkIHRoZSBwZXJpb2RpYyByZWdpc3RyYXRpb24u DQogICAgDQogICAgLUpvaG5zb24NCiAgICANCiAgICA+IE9uIERlYyA1LCAyMDE3LCBhdCAxMDo1 MiBBTSwgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5jb20+IHdyb3RlOg0KICAgID4g DQogICAgPj4gcmVnaXN0cmF0aW9uIHByb3RvY29sLCB0aGF0IG1pZ2h0IGJlIG9ydGhvZ29uYWwg dG8gb3RoZXIgdHJhbnNwb3J0LXJlbGF0ZWQgbWVjaGFuaXNtcy4gSW4gbXkgZXhwZXJpZW5jZSB0 aGlzIGhhcyBwcm92ZWQgdG8gYmUgdmVyeSBlZmZlY3RpdmUgaW4gc2NhbGFiaWxpdHkgb2YgbGFy Z2UgTElTUCBkZXBsb3ltZW50cywgZXNwZWNpYWxseSB3aXRoIHRoZSBpbmNyZWFzZWQgdm9sdW1l IG9mIHJlZ2lzdHJhdGlvbiBkYXRhLg0KICAgID4gDQogICAgPiBJIGFncmVlIGl04oCZcyBhIHBv aW50IHNvbHV0aW9uIGZvciByZWdpc3RyYXRpb24uIFRoZW4gd2h5IGRpZCB5b3UgbmVlZCB0byBo YXZlIGEgZ2VuZXJhbCBmb3JtYXQuIA0KICAgID4gDQogICAgPiBJIGNvdWxkIHN1cHBvcnQgdGhp cyBkcmFmdCBpZiBpdCB3YXMgc2ltcGxpZmllZCB0byBzcGVjIGhvdyB0byB1c2UgTWFwLVJlZ2lz dGVycyBpbiBUQ1AgYW5kIG5vdGhpbmcgbW9yZS4gDQogICAgPiANCiAgICA+IFRoZSBvbmx5IHRo aW5nIEkgd291bGQgYWRkIGlzIGhvdyB0byB1c2UgVExTIHNvIGVuY3J5cHRpb24gaXMgc3VwcG9y dGVkLiBNb3JlIGFuZCBtb3JlIHJlcXVpcmVtZW50cyBhcmUgY29taW5nIHVwIGZvciBwcm90ZWN0 aW5nIHRoZSBwcml2YWN5IG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uLiBBbmQgc2luY2UgTWFwLVJl Z2lzdGVycyBjYXJyeSBSTE9DcyAoYW5kIHBvdGVudGlhbCBHZW8tQ29vcmRuYXRlcykgdGhhdCBp bmZvcm1hdGlvbiBuZWVkcyB0byBiZSBwcm90ZWN0ZWQuIA0KICAgID4gDQogICAgPiBEaW5vDQog ICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg ID4gbGlzcCBtYWlsaW5nIGxpc3QNCiAgICA+IGxpc3BAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KICAgIA0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbGlzcCBtYWlsaW5nIGxp c3QNCiAgICBsaXNwQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9saXNwDQogICAgDQoNCg== From nobody Tue Dec 5 17:56:54 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8568D126557 for ; Tue, 5 Dec 2017 17:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, 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 EOzxMyEqD_2i for ; Tue, 5 Dec 2017 17:56:50 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 5505F124217 for ; Tue, 5 Dec 2017 17:56:50 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id q20so1549667pgv.2 for ; Tue, 05 Dec 2017 17:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k9kP7TIqL+VxKWLP2UJ44zy0KQwJjdv8Mfp39NEr0bY=; b=fgpD7Vk5LQUpzE4YKVfMZOe1iRLSlO+OdGArJ2xQI32b+X8aQwC+acFDoeI6e3Sz1b kAYDeRgNr4WMcNAxBH4twAVJz1wvQcNjqqSk5yFwe4rhLyAWIsa3rl51CBAuRzJg6d/V 2sxHQcHRoQuJHzY9yMtY1nYbE1bftkqey0PS/mLthMbr0X8bsV4rrdl2Ls0h1dEgHzQ2 MB4WlEV09uHprc45zL5SrCaHDXTV0ulhCtO+T3fOz8WEg6wZt3LsH+dZdefZDBH5fG/0 HCJSfK38Pp/7q5dNXKUg0r4WmWEVSDaVpK8WZFeNnp7xnsMk7Vg71P5os1lzvByBEM4v MTvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k9kP7TIqL+VxKWLP2UJ44zy0KQwJjdv8Mfp39NEr0bY=; b=tvM1Ty64Q0OY5zEkoXRO7BUX8bTxS77hUZIU1YJxsjmZzaYFHynp7A90sKqh5ZJ3tz aCoiQMv/XjHAgxGF9P9EeH3dL/PZ9WOIER/UfCXinLITjGAlExBlcpbXd75K6dLMjSbR CYdSKnceFsLwtN4b2Zh5wEww7RKH7Ycu3M+sDLMk+Z7CLjSeFKMWxQCEgEuaPyARl3AD 33WG+6O1rNbR3eHmiv3Pcnz7BkjpzuQm8qUZh70NSo7Sbi777r5sYq0+cbL2o6WCiFpp ydYS/I7YbADnEln+Da+UUwjgPsyWZz1zSIVpnL8OnaL/V5ZJhYO8c2aCYdhL85lNXlEV nBkg== X-Gm-Message-State: AJaThX7WsPQSxXYmaXgumTG+FBqQOOCOJhWInie0xxsaOVl2MzWP0hxP iAZO05lZRpgeFI0t1NR+NQIN+hJj X-Google-Smtp-Source: AGs4zMZApeDkjSYP8DTLI28OAeQM9u0LsT1yqCJQa7za7l+EZEAzwYExVMPrd6UuiZXrgwD0SVE4vg== X-Received: by 10.99.123.21 with SMTP id w21mr19245886pgc.67.1512525409728; Tue, 05 Dec 2017 17:56:49 -0800 (PST) Received: from [10.203.198.85] ([64.79.144.10]) by smtp.gmail.com with ESMTPSA id b6sm1924047pfe.57.2017.12.05.17.56.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 17:56:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> Date: Tue, 5 Dec 2017 17:56:46 -0800 Cc: Johnson Leong , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> To: "Marc Portoles Comeras (mportole)" X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 01:56:52 -0000 > Dino, >=20 > In addition to the previous arguments there are particular use-cases = where the use of reliable transport simplified the deployment of LISP. I understand its advantages. I am examining its costs. > As an example, the moment we started scaling datacenters to support = 10s of thousands of hosts, the use of a reliable transport helped a lot = the management of scale:=20 > On one side it reduces the amount of signaling when nothing changes, = since we use TCP state as an indication that xTRs and the MS are in sync = and there is no need to deal with the optimization of the refresh logic = (periodic or paced).=20 LISP (the application), does not know that itself, the xTR, is in sync = with the map-server. The packets can be in flight or being retransmitted = due to loss. But if a Map-Register is sent with a nonce and no = Map-Notify is returned the xTR knows for sure the two are in sync. I=E2=80=99d argue you may it worse. TCP does provide reliability but so = does LISP itself. And the only reason the messages are periodic is = because the spec said to send every 1 minute and timeout every 3 = minutes. You can make it 1000 minutes and timeout every 3000 minutes.=20 So let=E2=80=99s keep periiodic overhead, reliability, and staying in = sync as separate issues. > On the other side, with reliable transport we offload the reliable = delivery of information (and congestion control)=20 I understand that. But you can=E2=80=99t say TCP is keeping you in sync, = because you have removed detail from the applicationis. > from LISP to another process (TCP) that is entirely devoted and = designed for this. For example, supporting events like mass VM moves = relying purely on LISP based ACks became very challenging, as we ended = up having to deal with congestion events related to the signaling load = generated. The use of the reliable transport largely simplified the = problem. LISP can pack all those EID-records in a Map-Register just like TCP = does. And if you want per nonce acks, you pack them in IP packets <=3D = 65535 bytes. TCP will have to do that as well. And guess what. What if there is an RLOC-change and you already gave the = last one to TCP and can=E2=80=99t pull it back. If you were waiting for = an ack and a new RLOC-change came in (during a lossy case), you = wouldn=E2=80=99t have to retransmit the old information wastily. So keep = the =E2=80=9Cretransmission queue=E2=80=9D in LISP has its advantages. Dino >=20 > Marc >=20 > On 12/5/17, 12:06 PM, "lisp on behalf of Johnson Leong (joleong)" = wrote: >=20 > Hi Dino, >=20 > A large portion of this draft discusses the state machine required = for TCP and how to ensure the MS and xTR are in sync. We literally = reuse the entire UDP map-register code, we just wrap that message around = the LISP TCP header so there's a lot of code reuse. Finally, this draft = is not meant to replace UDP register but in some of our use cases TCP = would scale better to avoid the periodic registration. >=20 > -Johnson >=20 >> On Dec 5, 2017, at 10:52 AM, Dino Farinacci = wrote: >>=20 >>> registration protocol, that might be orthogonal to other = transport-related mechanisms. In my experience this has proved to be = very effective in scalability of large LISP deployments, especially with = the increased volume of registration data. >>=20 >> I agree it=E2=80=99s a point solution for registration. Then why did = you need to have a general format.=20 >>=20 >> I could support this draft if it was simplified to spec how to use = Map-Registers in TCP and nothing more.=20 >>=20 >> The only thing I would add is how to use TLS so encryption is = supported. More and more requirements are coming up for protecting the = privacy of location information. And since Map-Registers carry RLOCs = (and potential Geo-Coordnates) that information needs to be protected.=20= >>=20 >> Dino >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 From nobody Wed Dec 6 08:36:49 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCEB124F57 for ; Wed, 6 Dec 2017 08:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaTQBlWARMJg for ; Wed, 6 Dec 2017 08:36:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B4D1205F1 for ; Wed, 6 Dec 2017 08:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8486; q=dns/txt; s=iport; t=1512578205; x=1513787805; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WmEavqDnKbYjPb5Gyan2Vdgq4WUawIc04r2biZuk/bw=; b=f+OCI4CTYf6UdZTv0bQNDMh7TfzQkQfuU2/I0HESWf86mFWr2Y3qcPra fW/N+yewt4vSGa3Q4Dq/oZC3EOOzx6Ebc9SLExuXfr9oxQhlZoLw8Vl/Y hvcXgv/TGM+uC2+Afxya3tNcaz8gp9vW6hdwbZfFX6ITegvEjsRdlvyYF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQAZHCha/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOL2ZuJweDe4ogjnyBVyaIdI4RFIIBChgLhRgCGoU6PxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUiAQEBAwEBASEROgsQAgEIGAICJgICAh8GCxUQAgQOBRuJcAMNC?= =?us-ascii?q?BCpAIInhzkNgw4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhE1UgmspC4J3gmu?= =?us-ascii?q?CHgIWgxUxgjIFokA9ApAchHuTW40+iGgCERkBgTkBHzmBTm8VOioBgX6CTwMcG?= =?us-ascii?q?YFOeIhWgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,368,1508803200"; d="scan'208";a="318809655" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2017 16:36:44 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vB6GahwL020613 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 16:36:44 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 11:36:43 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Wed, 6 Dec 2017 11:36:42 -0500 From: "Marc Portoles Comeras (mportole)" To: Dino Farinacci CC: "Johnson Leong (joleong)" , "lisp@ietf.org" Thread-Topic: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption Thread-Index: AQHTbeo9leq2xF5iHkW7tPGXEoJPSqM1YT4AgAAI1ACAAAI0gIAAFLuAgABIaYCAABmEAIAA9doA Date: Wed, 6 Dec 2017 16:36:42 +0000 Message-ID: References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> In-Reply-To: <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.45] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 16:36:47 -0000 RGlubywNCg0KICA+ICAgIExJU1AgKHRoZSBhcHBsaWNhdGlvbiksIGRvZXMgbm90IGtub3cgdGhh dCBpdHNlbGYsIHRoZSB4VFIsIGlzIGluIHN5bmMgd2l0aCB0aGUgbWFwLXNlcnZlci4gVGhlIHBh Y2tldHMgY2FuIGJlIGluIGZsaWdodCBvciBiZWluZyByZXRyYW5zbWl0dGVkIGR1ZSB0byBsb3Nz LiBCdXQgaWYgYSBNYXAtUmVnaXN0ZXIgaXMgc2VudCB3aXRoIGEgbm9uY2UgYW5kIG5vIE1hcC1O b3RpZnkgaXMgcmV0dXJuZWQgdGhlIHhUUiBrbm93cyBmb3Igc3VyZSB0aGUgdHdvIGFyZSBpbiBz eW5jLg0KDQpBbiBhcHBsaWNhdGlvbiAoYW5kIExJU1AgaW4gdGhpcyBjYXNlKSBzaG91bGQgYWx3 YXlzIGJlIGFibGUgdG8ga25vdyB0aGUgc3RhdGUgb2YgYSAoVENQKSBzb2NrZXQgdGhhdCBpdCBo YXMgb3BlbmVkIHdpdGggYSBzZXJ2ZXIuIEnigJltIG5vdCBlbnRpcmVseSBzdXJlIHdoeSB3ZSB3 b3VsZCBub3Qgd2FudCB0byB1c2UgdGhpcyBpbmZvcm1hdGlvbi4gDQpCZXNpZGVzLCB0aGUgcmVs aWFibGUgdHJhbnNwb3J0IHNlc3Npb24gZG9lcyBub3QgaW52YWxpZGF0ZSB0aGUgdXNlIG9mIG5v bmNlcyBhbmQgTWFwLU5vdGlmaWVzIGFzIGFuIGluZGljYXRpb24gdGhhdCB0aGUgTVMgaGFzIGNv bXBsZXRlbHkgcmVjZWl2ZWQgdGhlIGluZm9ybWF0aW9uLCB0aGUganVzdCByZWx5IG9uIHRoZSBU Q1Agc3RhdGUgdG8ga25vdyB0aGF0IG5vdGhpbmcgaGFzIGNoYW5nZWQuDQoNCiAgPiAgSeKAmWQg YXJndWUgeW91IG1heSBpdCB3b3JzZS4gVENQIGRvZXMgcHJvdmlkZSByZWxpYWJpbGl0eSBidXQg c28gZG9lcyBMSVNQIGl0c2VsZi4gQW5kIHRoZSBvbmx5IHJlYXNvbiB0aGUgbWVzc2FnZXMgYXJl IHBlcmlvZGljIGlzIGJlY2F1c2UgdGhlIHNwZWMgc2FpZCB0byBzZW5kIGV2ZXJ5IDEgbWludXRl IGFuZCB0aW1lb3V0IGV2ZXJ5IDMgbWludXRlcy4gWW91IGNhbiBtYWtlIGl0IDEwMDAgbWludXRl cyBhbmQgdGltZW91dCBldmVyeSAzMDAwIG1pbnV0ZXMuDQoNCkFuZCB0aGlzIHNvdW5kcyBhcyB3 ZSB3b3VsZCBtYWtlIHRoZSBwcm90b2NvbCB2ZXJ5IGNvbXBsaWNhdGVkIHRvIHVzZSAob3IgY29k ZSksIGFzIHRoaXMgd291bGQgbGVhZCB1cyB0byBoYXZlIHRvIGNvZGUvY29uZmlndXJlIGEgc3Bl Y2lmaWMgcmVnaXN0cmF0aW9uIHBhdHRlcm4vbG9naWMgZm9yIGV2ZXJ5IHVzZSBjYXNlIHRoYXQg d2Ugd2FudCB0byBzdXBwb3J0LiBOb3Qgc2F5aW5nIHdlIGNhbm5vdCwgYnV0IGl0IHNvdW5kcyBs aWtlIHJlLWltcGxlbWVudGluZyBUQ1AgOykNCg0KICA+ICBMSVNQIGNhbiBwYWNrIGFsbCB0aG9z ZSBFSUQtcmVjb3JkcyBpbiBhIE1hcC1SZWdpc3RlciBqdXN0IGxpa2UgVENQIGRvZXMuIEFuZCBp ZiB5b3Ugd2FudCBwZXIgbm9uY2UgYWNrcywgeW91IHBhY2sgdGhlbSBpbiBJUCBwYWNrZXRzIDw9 IDY1NTM1IGJ5dGVzLiBUQ1Agd2lsbCBoYXZlIHRvIGRvIHRoYXQgYXMgd2VsbC4NCg0KVGhpcyBp cyBleGFjdGx5IHRoZSBwb2ludCwgd2hpbGUgTElTUCBzaWduYWxpbmcgYWxsb3dzIGl0IHdlIGRv buKAmXQgbmVlZCB0byByZS1pbXBsZW1lbnQgZXZlcnkgVENQIGZlYXR1cmUgaW4gTElTUCwgYXMg VENQIGNhbiBhbHJlYWR5IHByb3ZpZGUgaXQuDQoNCiAgPiAgQW5kIGd1ZXNzIHdoYXQuIFdoYXQg aWYgdGhlcmUgaXMgYW4gUkxPQy1jaGFuZ2UgYW5kIHlvdSBhbHJlYWR5IGdhdmUgdGhlIGxhc3Qg b25lIHRvIFRDUCBhbmQgY2Fu4oCZdCBwdWxsIGl0IGJhY2suIElmIHlvdSB3ZXJlIHdhaXRpbmcg Zm9yIGFuIGFjayBhbmQgYSBuZXcgUkxPQy1jaGFuZ2UgY2FtZSBpbiAoZHVyaW5nIGEgbG9zc3kg Y2FzZSksIHlvdSB3b3VsZG7igJl0IGhhdmUgdG8gcmV0cmFuc21pdCB0aGUgb2xkIGluZm9ybWF0 aW9uIHdhc3RpbHkuIFNvIGtlZXAgdGhlIOKAnHJldHJhbnNtaXNzaW9uIHF1ZXVl4oCdIGluIExJ U1AgaGFzIGl0cyBhZHZhbnRhZ2VzLg0KICAgIA0KSeKAmW0gbm90IHN1cmUgdGhpcyBpcyBzbyBl YXN5LiBVRFAsIGp1c3QgbGlrZSBUQ1AgdXNlcyB0aGUgUkxPQyAoSVApIGFzIHBhcnQgb2YgdGhl IOKAnHNlc3Npb24gaWRlbnRpZmllcuKAnSBhbmQgdGhlIG5vbmNlIGlzIHBlci1wYWNrZXQsIG5v dCBwZXItc2Vzc2lvbi4gVGhlIG1vbWVudCB0aGUgUkxPQyBjaGFuZ2VzIG9uIHRoZSB4VFIsIHRo ZSBNUyBkb2VzIG5vdCBrbm93IHRoYXQgdGhlIHhUUiBpcyB0aGUgc2FtZSBzbyB3ZeKAmWQgbmVl ZCBhIHJldHJhbnNtaXNzaW9uIHByb2Nlc3MuDQoNCk1hcmMNCg0KT24gMTIvNS8xNywgNTo1NyBQ TSwgIkRpbm8gRmFyaW5hY2NpIiA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICA+ IERpbm8sDQogICAgPiANCiAgICA+IEluIGFkZGl0aW9uIHRvIHRoZSBwcmV2aW91cyBhcmd1bWVu dHMgdGhlcmUgYXJlIHBhcnRpY3VsYXIgdXNlLWNhc2VzIHdoZXJlIHRoZSB1c2Ugb2YgcmVsaWFi bGUgdHJhbnNwb3J0IHNpbXBsaWZpZWQgdGhlIGRlcGxveW1lbnQgb2YgTElTUC4NCiAgICANCiAg ICBJIHVuZGVyc3RhbmQgaXRzIGFkdmFudGFnZXMuIEkgYW0gZXhhbWluaW5nIGl0cyBjb3N0cy4N CiAgICANCiAgICA+IEFzIGFuIGV4YW1wbGUsIHRoZSBtb21lbnQgd2Ugc3RhcnRlZCBzY2FsaW5n IGRhdGFjZW50ZXJzIHRvIHN1cHBvcnQgMTBzIG9mIHRob3VzYW5kcyBvZiBob3N0cywgdGhlIHVz ZSBvZiBhIHJlbGlhYmxlIHRyYW5zcG9ydCBoZWxwZWQgYSBsb3QgdGhlIG1hbmFnZW1lbnQgb2Yg c2NhbGU6IA0KICAgID4gT24gb25lIHNpZGUgaXQgcmVkdWNlcyB0aGUgYW1vdW50IG9mIHNpZ25h bGluZyB3aGVuIG5vdGhpbmcgY2hhbmdlcywgc2luY2Ugd2UgdXNlIFRDUCBzdGF0ZSBhcyBhbiBp bmRpY2F0aW9uIHRoYXQgeFRScyBhbmQgdGhlIE1TIGFyZSBpbiBzeW5jIGFuZCB0aGVyZSBpcyBu byBuZWVkIHRvIGRlYWwgd2l0aCB0aGUgb3B0aW1pemF0aW9uIG9mIHRoZSByZWZyZXNoIGxvZ2lj IChwZXJpb2RpYyBvciBwYWNlZCkuIA0KICAgIA0KICAgIExJU1AgKHRoZSBhcHBsaWNhdGlvbiks IGRvZXMgbm90IGtub3cgdGhhdCBpdHNlbGYsIHRoZSB4VFIsIGlzIGluIHN5bmMgd2l0aCB0aGUg bWFwLXNlcnZlci4gVGhlIHBhY2tldHMgY2FuIGJlIGluIGZsaWdodCBvciBiZWluZyByZXRyYW5z bWl0dGVkIGR1ZSB0byBsb3NzLiBCdXQgaWYgYSBNYXAtUmVnaXN0ZXIgaXMgc2VudCB3aXRoIGEg bm9uY2UgYW5kIG5vIE1hcC1Ob3RpZnkgaXMgcmV0dXJuZWQgdGhlIHhUUiBrbm93cyBmb3Igc3Vy ZSB0aGUgdHdvIGFyZSBpbiBzeW5jLg0KICAgIA0KICAgIEnigJlkIGFyZ3VlIHlvdSBtYXkgaXQg d29yc2UuIFRDUCBkb2VzIHByb3ZpZGUgcmVsaWFiaWxpdHkgYnV0IHNvIGRvZXMgTElTUCBpdHNl bGYuIEFuZCB0aGUgb25seSByZWFzb24gdGhlIG1lc3NhZ2VzIGFyZSBwZXJpb2RpYyBpcyBiZWNh dXNlIHRoZSBzcGVjIHNhaWQgdG8gc2VuZCBldmVyeSAxIG1pbnV0ZSBhbmQgdGltZW91dCBldmVy eSAzIG1pbnV0ZXMuIFlvdSBjYW4gbWFrZSBpdCAxMDAwIG1pbnV0ZXMgYW5kIHRpbWVvdXQgZXZl cnkgMzAwMCBtaW51dGVzLiANCiAgICANCiAgICBTbyBsZXTigJlzIGtlZXAgcGVyaWlvZGljIG92 ZXJoZWFkLCByZWxpYWJpbGl0eSwgYW5kIHN0YXlpbmcgaW4gc3luYyBhcyBzZXBhcmF0ZSBpc3N1 ZXMuDQogICAgDQogICAgPiBPbiB0aGUgb3RoZXIgc2lkZSwgd2l0aCByZWxpYWJsZSB0cmFuc3Bv cnQgd2Ugb2ZmbG9hZCB0aGUgcmVsaWFibGUgZGVsaXZlcnkgb2YgaW5mb3JtYXRpb24gKGFuZCBj b25nZXN0aW9uIGNvbnRyb2wpIA0KICAgIA0KICAgIEkgdW5kZXJzdGFuZCB0aGF0LiBCdXQgeW91 IGNhbuKAmXQgc2F5IFRDUCBpcyBrZWVwaW5nIHlvdSBpbiBzeW5jLCBiZWNhdXNlIHlvdSBoYXZl IHJlbW92ZWQgZGV0YWlsIGZyb20gdGhlIGFwcGxpY2F0aW9uaXMuDQogICAgDQogICAgPiBmcm9t IExJU1AgdG8gYW5vdGhlciBwcm9jZXNzIChUQ1ApIHRoYXQgaXMgZW50aXJlbHkgZGV2b3RlZCBh bmQgZGVzaWduZWQgZm9yIHRoaXMuIEZvciBleGFtcGxlLCBzdXBwb3J0aW5nIGV2ZW50cyBsaWtl IG1hc3MgVk0gbW92ZXMgcmVseWluZyBwdXJlbHkgb24gTElTUCBiYXNlZCBBQ2tzIGJlY2FtZSB2 ZXJ5IGNoYWxsZW5naW5nLCBhcyB3ZSBlbmRlZCB1cCBoYXZpbmcgdG8gZGVhbCB3aXRoIGNvbmdl c3Rpb24gZXZlbnRzIHJlbGF0ZWQgdG8gdGhlIHNpZ25hbGluZyBsb2FkIGdlbmVyYXRlZC4gVGhl IHVzZSBvZiB0aGUgcmVsaWFibGUgdHJhbnNwb3J0IGxhcmdlbHkgc2ltcGxpZmllZCB0aGUgcHJv YmxlbS4NCiAgICANCkRpbm8NCiAgICANCiAgICA+IA0KICAgID4gTWFyYw0KICAgID4gDQogICAg PiBPbiAxMi81LzE3LCAxMjowNiBQTSwgImxpc3Agb24gYmVoYWxmIG9mIEpvaG5zb24gTGVvbmcg KGpvbGVvbmcpIiA8bGlzcC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqb2xlb25nQGNp c2NvLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgIEhpIERpbm8sDQogICAgPiANCiAgICA+ ICAgIEEgbGFyZ2UgcG9ydGlvbiBvZiB0aGlzIGRyYWZ0IGRpc2N1c3NlcyB0aGUgc3RhdGUgbWFj aGluZSByZXF1aXJlZCBmb3IgVENQIGFuZCBob3cgdG8gZW5zdXJlIHRoZSBNUyBhbmQgeFRSIGFy ZSBpbiBzeW5jLiAgV2UgbGl0ZXJhbGx5IHJldXNlIHRoZSBlbnRpcmUgVURQIG1hcC1yZWdpc3Rl ciBjb2RlLCB3ZSBqdXN0IHdyYXAgdGhhdCBtZXNzYWdlIGFyb3VuZCB0aGUgTElTUCBUQ1AgaGVh ZGVyIHNvIHRoZXJlJ3MgYSBsb3Qgb2YgY29kZSByZXVzZS4gIEZpbmFsbHksIHRoaXMgZHJhZnQg aXMgbm90IG1lYW50IHRvIHJlcGxhY2UgVURQIHJlZ2lzdGVyIGJ1dCBpbiBzb21lIG9mIG91ciB1 c2UgY2FzZXMgVENQIHdvdWxkIHNjYWxlIGJldHRlciB0byBhdm9pZCB0aGUgcGVyaW9kaWMgcmVn aXN0cmF0aW9uLg0KICAgID4gDQogICAgPiAgICAtSm9obnNvbg0KICAgID4gDQogICAgPj4gT24g RGVjIDUsIDIwMTcsIGF0IDEwOjUyIEFNLCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWls LmNvbT4gd3JvdGU6DQogICAgPj4gDQogICAgPj4+IHJlZ2lzdHJhdGlvbiBwcm90b2NvbCwgdGhh dCBtaWdodCBiZSBvcnRob2dvbmFsIHRvIG90aGVyIHRyYW5zcG9ydC1yZWxhdGVkIG1lY2hhbmlz bXMuIEluIG15IGV4cGVyaWVuY2UgdGhpcyBoYXMgcHJvdmVkIHRvIGJlIHZlcnkgZWZmZWN0aXZl IGluIHNjYWxhYmlsaXR5IG9mIGxhcmdlIExJU1AgZGVwbG95bWVudHMsIGVzcGVjaWFsbHkgd2l0 aCB0aGUgaW5jcmVhc2VkIHZvbHVtZSBvZiByZWdpc3RyYXRpb24gZGF0YS4NCiAgICA+PiANCiAg ICA+PiBJIGFncmVlIGl04oCZcyBhIHBvaW50IHNvbHV0aW9uIGZvciByZWdpc3RyYXRpb24uIFRo ZW4gd2h5IGRpZCB5b3UgbmVlZCB0byBoYXZlIGEgZ2VuZXJhbCBmb3JtYXQuIA0KICAgID4+IA0K ICAgID4+IEkgY291bGQgc3VwcG9ydCB0aGlzIGRyYWZ0IGlmIGl0IHdhcyBzaW1wbGlmaWVkIHRv IHNwZWMgaG93IHRvIHVzZSBNYXAtUmVnaXN0ZXJzIGluIFRDUCBhbmQgbm90aGluZyBtb3JlLiAN CiAgICA+PiANCiAgICA+PiBUaGUgb25seSB0aGluZyBJIHdvdWxkIGFkZCBpcyBob3cgdG8gdXNl IFRMUyBzbyBlbmNyeXB0aW9uIGlzIHN1cHBvcnRlZC4gTW9yZSBhbmQgbW9yZSByZXF1aXJlbWVu dHMgYXJlIGNvbWluZyB1cCBmb3IgcHJvdGVjdGluZyB0aGUgcHJpdmFjeSBvZiBsb2NhdGlvbiBp bmZvcm1hdGlvbi4gQW5kIHNpbmNlIE1hcC1SZWdpc3RlcnMgY2FycnkgUkxPQ3MgKGFuZCBwb3Rl bnRpYWwgR2VvLUNvb3JkbmF0ZXMpIHRoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgcHJvdGVj dGVkLiANCiAgICA+PiANCiAgICA+PiBEaW5vDQogICAgPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+PiBsaXNwIG1haWxpbmcgbGlzdA0KICAg ID4+IGxpc3BAaWV0Zi5vcmcNCiAgICA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpc3ANCiAgICA+IA0KICAgID4gICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgIGxpc3AgbWFpbGluZyBsaXN0DQogICAgPiAg ICBsaXNwQGlldGYub3JnDQogICAgPiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpc3ANCiAgICA+IA0KICAgID4gDQogICAgDQogICAgDQoNCg== From nobody Wed Dec 6 11:17:27 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EA6127871 for ; Wed, 6 Dec 2017 11:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, 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 m-Gl38gYmgWW for ; Wed, 6 Dec 2017 11:17:24 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA4F126CC4 for ; Wed, 6 Dec 2017 11:17:24 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id w7so2635317pgv.6 for ; Wed, 06 Dec 2017 11:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z1Lyk45zYsfW/5AEvzcq0c4w1eyWZocpgugqo3U3qr0=; b=NADhT4IIP7yYXfJ0l8+RT9mQ3sHrRrcN1H8ZSTtUl00aapxcMgqxndc1DfB7iulSxo QS6+E6G0qXAp+lKj0xv6r3bZ2LUCco7nknl8y6gowU9A35TN/Sg7L+Bj2Ythw+mOJHyr Y2lc7cSFJBzzn5UbcLCfydMhEncVJEhA3YD0kbwjT2rjSZvs6alv5APkArWpO5ELkama eYMWii3vokXf8DVv6aqyCekEpNRHTZb0pTZ5dkLbCygRRLIDeDpgoUGT6+VYxdDzpgN2 IdlhCYdE/eLsO2YJwcjPuowMV3zAT09IZsDMh7LvJiqbZt64YVsXocW5JGEWnvtqKvPv V/7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z1Lyk45zYsfW/5AEvzcq0c4w1eyWZocpgugqo3U3qr0=; b=o86nId1g7DiAoGCCVRZrCPBQEZnHMpZMviCEGp9BN2jfbVe0UykHDzeY54O9TrcdqM zkYK4Kdl6juVtclfRWmvwwKRksk91NqYdPb/OwLhX/XF+VeVnPTzax9o97NECNChjrOg dKY9JS5M6Jg0UmKTB3v1ErIU7oetsSTXZbGEN29JoZ/C9kWowul2nVvk2oPrgR3uyhaH nxf/AhVFUJZcEf5vWzCEwgUJlUxAWlCLF0CLGxypwnFhlgdKGky1QzDMaOoupTluOJsF uhRtB1AJtzlSTBz/ICOOFwV9EZq+0s2boQiGMS1sfKRhwPPFRfFFHgTXrJqMLCG1j2Ej E68Q== X-Gm-Message-State: AKGB3mI96sjhryloGev7VMynJOYJ22fMA1kT1kAdILav9G0jbNMDO4FM eBfWo2sk5nGZogOgE8Bhw4U= X-Google-Smtp-Source: AGs4zMawL/0b2MmoTKbh888yDM/LW8mSG1eD6GilW51DMud1E6CZlB2oEbdQl+o4tWNtGRyMu0Fniw== X-Received: by 10.101.100.136 with SMTP id e8mr6894497pgv.248.1512587843175; Wed, 06 Dec 2017 11:17:23 -0800 (PST) Received: from [10.203.198.85] ([64.79.144.10]) by smtp.gmail.com with ESMTPSA id 84sm5881929pfp.180.2017.12.06.11.17.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 11:17:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: Date: Wed, 6 Dec 2017 11:17:20 -0800 Cc: Johnson Leong , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> To: "Marc Portoles Comeras (mportole)" X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 19:17:26 -0000 > Dino, >=20 >> LISP (the application), does not know that itself, the xTR, is in = sync with the map-server. The packets can be in flight or being = retransmitted due to loss. But if a Map-Register is sent with a nonce = and no Map-Notify is returned the xTR knows for sure the two are in = sync. >=20 > An application (and LISP in this case) should always be able to know = the state of a (TCP) socket that it has opened with a server. I=E2=80=99m = not entirely sure why we would not want to use this information.=20 All an app knows is the socket it has opened and any port it has = bind()=E2=80=99ed to. It doesn=E2=80=99t know the connection state in = terms of what packets have been sent and what has been ack=E2=80=99ed. = There IS NOT enough information to do anything useful. > Besides, the reliable transport session does not invalidate the use of = nonces and Map-Notifies as an indication that the MS has completely = received the information, the just rely on the TCP state to know that = nothing has changed. Right, so you have duplicate functionality. That isn=E2=80=99t = efficient. >> I=E2=80=99d argue you may it worse. TCP does provide reliability but = so does LISP itself. And the only reason the messages are periodic is = because the spec said to send every 1 minute and timeout every 3 = minutes. You can make it 1000 minutes and timeout every 3000 minutes. >=20 > And this sounds as we would make the protocol very complicated to use = (or code), as this would lead us to have to code/configure a specific = registration pattern/logic for every use case that we want to support. = Not saying we cannot, but it sounds like re-implementing TCP ;) You already have that code or you aren=E2=80=99t implementing = Map-Register acks corrrectly. And changing a timer is really a constant = change in the code. And what is spec=E2=80=99ed today in LISP proper is = much simpler than TCP, it is not reimplementing it. But let's not drift from the point. The spec is written in a general way = to solve only sending Map-Registers reliably. I suggest the text not = mislead the reader to think this is a general new packet format for = anything. When people judge which protocols they want to deploy, the people that = do the due diligence will look at the protocol specs and see how much = mechanism is designed in. And they make judgement decisions about using = the protocol. I know of at least 2 vendors that said =E2=80=9CI implemented pages = 47-50 of the EVPN spec=E2=80=9D. ;-) In LISP. we want to make sure what we spec is what is used and not = ignored or considered optional. So please document the specific use-case = you want to implement. And I=E2=80=99d suggest making the draft name = draft-*-lisp-reliable-registers. >> LISP can pack all those EID-records in a Map-Register just like TCP = does. And if you want per nonce acks, you pack them in IP packets <=3D = 65535 bytes. TCP will have to o that as well. >=20 > This is exactly the point, while LISP signaling allows it we don=E2=80=99= t need to re-implement every TCP feature in LISP, as TCP can already = provide it. You don=E2=80=99t need to.=20 >> And guess what. What if there is an RLOC-change and you already gave = the last one to TCP and can=E2=80=99t pull it back. If you were waiting = for an ack and a new RLOC-change came in (during a lossy case), you = wouldn=E2=80=99t have to retransmit the old information wastily. So keep = the =E2=80=9Cretransmission queue=E2=80=9D in LISP has its advantages. >=20 > I=E2=80=99m not sure this is so easy. UDP, just like TCP uses the RLOC = (IP) as part of the =E2=80=9Csession identifier=E2=80=9D and the nonce = is per-packet, not per-session. The moment the RLOC changes on the xTR, = the MS does not know that the xTR is the same so we=E2=80=99d need a = retransmission process. I=E2=80=99m not talking about when the xTR changes, I=E2=80=99m talking = about an address on an interface on the same xTR changes since it was = DHCP=E2=80=99ed to the xTR or behind a NAT. But for the LISP-MN case, = the xTR is moving and its RLOCs are changing. You couple this with = pubsub and the extra Map-Registers with old RLOCs has a ripple effect = where then the Map-Server sends Map-Notify messages to all the = subscribers, then followed by another set of Map-Notifies with the new = RLOC-set. That is a lot of (unnecessary) messaging and processing. We have to think about the implications of any one draft on the ENTIRE = LISP architecture. It must work efficiently as one holistic distributed = system. Dino >=20 > Marc >=20 > On 12/5/17, 5:57 PM, "Dino Farinacci" wrote: >=20 >> Dino, >>=20 >> In addition to the previous arguments there are particular use-cases = where the use of reliable transport simplified the deployment of LISP. >=20 > I understand its advantages. I am examining its costs. >=20 >> As an example, the moment we started scaling datacenters to support = 10s of thousands of hosts, the use of a reliable transport helped a lot = the management of scale:=20 >> On one side it reduces the amount of signaling when nothing changes, = since we use TCP state as an indication that xTRs and the MS are in sync = and there is no need to deal with the optimization of the refresh logic = (periodic or paced).=20 >=20 > LISP (the application), does not know that itself, the xTR, is in = sync with the map-server. The packets can be in flight or being = retransmitted due to loss. But if a Map-Register is sent with a nonce = and no Map-Notify is returned the xTR knows for sure the two are in = sync. >=20 > I=E2=80=99d argue you may it worse. TCP does provide reliability = but so does LISP itself. And the only reason the messages are periodic = is because the spec said to send every 1 minute and timeout every 3 = minutes. You can make it 1000 minutes and timeout every 3000 minutes.=20 >=20 > So let=E2=80=99s keep periiodic overhead, reliability, and staying = in sync as separate issues. >=20 >> On the other side, with reliable transport we offload the reliable = delivery of information (and congestion control)=20 >=20 > I understand that. But you can=E2=80=99t say TCP is keeping you in = sync, because you have removed detail from the applicationis. >=20 >> from LISP to another process (TCP) that is entirely devoted and = designed for this. For example, supporting events like mass VM moves = relying purely on LISP based ACks became very challenging, as we ended = up having to deal with congestion events related to the signaling load = generated. The use of the reliable transport largely simplified the = problem. >=20 > Dino >=20 >>=20 >> Marc >>=20 >> On 12/5/17, 12:06 PM, "lisp on behalf of Johnson Leong (joleong)" = wrote: >>=20 >> Hi Dino, >>=20 >> A large portion of this draft discusses the state machine required = for TCP and how to ensure the MS and xTR are in sync. We literally = reuse the entire UDP map-register code, we just wrap that message around = the LISP TCP header so there's a lot of code reuse. Finally, this draft = is not meant to replace UDP register but in some of our use cases TCP = would scale better to avoid the periodic registration. >>=20 >> -Johnson >>=20 >>> On Dec 5, 2017, at 10:52 AM, Dino Farinacci = wrote: >>>=20 >>>> registration protocol, that might be orthogonal to other = transport-related mechanisms. In my experience this has proved to be = very effective in scalability of large LISP deployments, especially with = the increased volume of registration data. >>>=20 >>> I agree it=E2=80=99s a point solution for registration. Then why did = you need to have a general format.=20 >>>=20 >>> I could support this draft if it was simplified to spec how to use = Map-Registers in TCP and nothing more.=20 >>>=20 >>> The only thing I would add is how to use TLS so encryption is = supported. More and more requirements are coming up for protecting the = privacy of location information. And since Map-Registers carry RLOCs = (and potential Geo-Coordnates) that information needs to be protected.=20= >>>=20 >>> Dino >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 >>=20 >=20 >=20 >=20 From nobody Wed Dec 6 11:44:20 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19C2128959 for ; Wed, 6 Dec 2017 11:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MAk2eoaZf0I for ; Wed, 6 Dec 2017 11:44:16 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD48127873 for ; Wed, 6 Dec 2017 11:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12296; q=dns/txt; s=iport; t=1512589456; x=1513799056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RePtEijnWzEzv4FRjeoMz8leQ50SnoZr9BYD5Ib0xOU=; b=WJJ+n1RDmy4Uxih9+QIhFinLdxkZLL+n9+FbmEJAo/VbXzbW0IwuA7Uw ldrq9r+nPj7TmBrPhsyY81qY8friWE8Pkr2RCPc8uDQSNTpRhelIenuju Tu4+d1IhmkI8EFBuq/Fwqe/2GRuRTGDiAjusn0eT/zrKd4UmtbkdcD4Pq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAACERyha/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOL2ZuJweDe4ogjnuBfYh0jhEUggEKGAuFGAIahTo/GAEBAQE?= =?us-ascii?q?BAQEBAWsohSIBAQEDAQEBIRE6CwULAgEIEgYCAiYCAgIfBgsVAg4CBA4FG4lwA?= =?us-ascii?q?w0IEKh3gieHOQ2DDgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+ETYFWgWgBKYM?= =?us-ascii?q?CgmuCHgIWgxUxgjIFkgiQOD0CkByEe4IWhhGLNI0+iGgCERkBgTkBHzmBTm8VO?= =?us-ascii?q?ioBgX6CTwMcGYFOeIhYgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,369,1508803200"; d="scan'208";a="41186908" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2017 19:44:14 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vB6JiEnm007261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 19:44:14 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 13:44:14 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1320.000; Wed, 6 Dec 2017 13:44:13 -0600 From: "Johnson Leong (joleong)" To: Dino Farinacci CC: "Marc Portoles Comeras (mportole)" , "lisp@ietf.org" Thread-Topic: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption Thread-Index: AQHTbeo9EtGVHwDVv0CpzXF7TtVp96M1cgIAgAAI1ACAAAI0gIAAFL8AgABIZYCAABmDAIAA9doAgAAs4gCAAAeGAA== Date: Wed, 6 Dec 2017 19:44:13 +0000 Message-ID: <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> In-Reply-To: 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.154.161.8] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 19:44:19 -0000 RGlubywNCg0KV2hhdCB3ZSdyZSB0cnlpbmcgdG8gY29udmV5IGlzIHRoYXQgYnkgdXNpbmcgVENQ IGl0IGFsbG93cyB1cyB0byBhY2hpZXZlIHJlbGlhYmlsaXR5IHdoaWNoIHNpZ25pZmljYW50bHkg c2ltcGxpZmllcyB0aGUgY29kZSBhbmQgZXJyb3IgaGFuZGxpbmcuICBPbmUgY2FuIGFjaGlldmUg dGhlIHNhbWUgd2l0aCBVRFAgd2l0aCBhY2sgYW5kIHJldHJ5IGJ1dCBpdCB3b3VsZCBiZSByZWlt cGxlbWVudGluZyB3aGF0IFRDUCBhbHJlYWR5IG9mZmVycyBhbmQgdGhpcyBhZGRlZCBjb21wbGV4 aXR5IHR5cGljYWxseSBtYWtlcyB0aGUgY29kZSBlcnJvciBwcm9uZS4NCg0KQW5vdGhlciBiZW5l Zml0IHdpdGggVENQIGlzIGNvbmdlc3Rpb24gY29udHJvbCwgd2l0aCBVRFAgaWYgd2Ugc2VuZCBh IG1hcC1yZWdpc3RlciBhbmQgd2UgZG9uJ3QgZ2V0IGFuIGFjayB0aGVuIHdlIHJldHJ5LiAgV2hh dCBpZiB0aGUgTVMgaXMgZnVsbHkgc3Vic2NyaWJlZCB0aGVuIHRoaXMgY2FuIGxlYWQgdG8gY29u c3RhbnQgcmV0cnkuICBZb3UgY2FuIGltcG9zZSBiYWNrb2ZmIG1lY2hhbmlzbSBidXQgdWx0aW1h dGVseSB0aGlzIHdvdWxkIGFmZmVjdCBjb252ZXJnZW5jZS4NCg0KLUpvaG5zb24NCg0KPiBPbiBE ZWMgNiwgMjAxNywgYXQgMTE6MTcgQU0sIERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwu Y29tPiB3cm90ZToNCj4gDQo+PiBEaW5vLA0KPj4gDQo+Pj4gIExJU1AgKHRoZSBhcHBsaWNhdGlv biksIGRvZXMgbm90IGtub3cgdGhhdCBpdHNlbGYsIHRoZSB4VFIsIGlzIGluIHN5bmMgd2l0aCB0 aGUgbWFwLXNlcnZlci4gVGhlIHBhY2tldHMgY2FuIGJlIGluIGZsaWdodCBvciBiZWluZyByZXRy YW5zbWl0dGVkIGR1ZSB0byBsb3NzLiBCdXQgaWYgYSBNYXAtUmVnaXN0ZXIgaXMgc2VudCB3aXRo IGEgbm9uY2UgYW5kIG5vIE1hcC1Ob3RpZnkgaXMgcmV0dXJuZWQgdGhlIHhUUiBrbm93cyBmb3Ig c3VyZSB0aGUgdHdvIGFyZSBpbiBzeW5jLg0KPj4gDQo+PiBBbiBhcHBsaWNhdGlvbiAoYW5kIExJ U1AgaW4gdGhpcyBjYXNlKSBzaG91bGQgYWx3YXlzIGJlIGFibGUgdG8ga25vdyB0aGUgc3RhdGUg b2YgYSAoVENQKSBzb2NrZXQgdGhhdCBpdCBoYXMgb3BlbmVkIHdpdGggYSBzZXJ2ZXIuIEnigJlt IG5vdCBlbnRpcmVseSBzdXJlIHdoeSB3ZSB3b3VsZCBub3Qgd2FudCB0byB1c2UgdGhpcyBpbmZv cm1hdGlvbi4gDQo+IA0KPiBBbGwgYW4gYXBwIGtub3dzIGlzIHRoZSBzb2NrZXQgaXQgaGFzIG9w ZW5lZCBhbmQgYW55IHBvcnQgaXQgaGFzIGJpbmQoKeKAmWVkIHRvLiBJdCBkb2VzbuKAmXQga25v dyB0aGUgY29ubmVjdGlvbiBzdGF0ZSBpbiB0ZXJtcyBvZiB3aGF0IHBhY2tldHMgaGF2ZSBiZWVu IHNlbnQgYW5kIHdoYXQgaGFzIGJlZW4gYWNr4oCZZWQuIFRoZXJlIElTIE5PVCBlbm91Z2ggaW5m b3JtYXRpb24gdG8gZG8gYW55dGhpbmcgdXNlZnVsLg0KPiANCj4+IEJlc2lkZXMsIHRoZSByZWxp YWJsZSB0cmFuc3BvcnQgc2Vzc2lvbiBkb2VzIG5vdCBpbnZhbGlkYXRlIHRoZSB1c2Ugb2Ygbm9u Y2VzIGFuZCBNYXAtTm90aWZpZXMgYXMgYW4gaW5kaWNhdGlvbiB0aGF0IHRoZSBNUyBoYXMgY29t cGxldGVseSByZWNlaXZlZCB0aGUgaW5mb3JtYXRpb24sIHRoZSBqdXN0IHJlbHkgb24gdGhlIFRD UCBzdGF0ZSB0byBrbm93IHRoYXQgbm90aGluZyBoYXMgY2hhbmdlZC4NCj4gDQo+IFJpZ2h0LCBz byB5b3UgaGF2ZSBkdXBsaWNhdGUgZnVuY3Rpb25hbGl0eS4gVGhhdCBpc27igJl0IGVmZmljaWVu dC4NCj4gDQo+Pj4gSeKAmWQgYXJndWUgeW91IG1heSBpdCB3b3JzZS4gVENQIGRvZXMgcHJvdmlk ZSByZWxpYWJpbGl0eSBidXQgc28gZG9lcyBMSVNQIGl0c2VsZi4gQW5kIHRoZSBvbmx5IHJlYXNv biB0aGUgbWVzc2FnZXMgYXJlIHBlcmlvZGljIGlzIGJlY2F1c2UgdGhlIHNwZWMgc2FpZCB0byBz ZW5kIGV2ZXJ5IDEgbWludXRlIGFuZCB0aW1lb3V0IGV2ZXJ5IDMgbWludXRlcy4gWW91IGNhbiBt YWtlIGl0IDEwMDAgbWludXRlcyBhbmQgdGltZW91dCBldmVyeSAzMDAwIG1pbnV0ZXMuDQo+PiAN Cj4+IEFuZCB0aGlzIHNvdW5kcyBhcyB3ZSB3b3VsZCBtYWtlIHRoZSBwcm90b2NvbCB2ZXJ5IGNv bXBsaWNhdGVkIHRvIHVzZSAob3IgY29kZSksIGFzIHRoaXMgd291bGQgbGVhZCB1cyB0byBoYXZl IHRvIGNvZGUvY29uZmlndXJlIGEgc3BlY2lmaWMgcmVnaXN0cmF0aW9uIHBhdHRlcm4vbG9naWMg Zm9yIGV2ZXJ5IHVzZSBjYXNlIHRoYXQgd2Ugd2FudCB0byBzdXBwb3J0LiBOb3Qgc2F5aW5nIHdl IGNhbm5vdCwgYnV0IGl0IHNvdW5kcyBsaWtlIHJlLWltcGxlbWVudGluZyBUQ1AgOykNCj4gDQo+ IFlvdSBhbHJlYWR5IGhhdmUgdGhhdCBjb2RlIG9yIHlvdSBhcmVu4oCZdCBpbXBsZW1lbnRpbmcg TWFwLVJlZ2lzdGVyIGFja3MgY29ycnJlY3RseS4gQW5kIGNoYW5naW5nIGEgdGltZXIgaXMgcmVh bGx5IGEgY29uc3RhbnQgY2hhbmdlIGluIHRoZSBjb2RlLiBBbmQgd2hhdCBpcyBzcGVj4oCZZWQg dG9kYXkgaW4gTElTUCBwcm9wZXIgaXMgbXVjaCBzaW1wbGVyIHRoYW4gVENQLCBpdCBpcyBub3Qg cmVpbXBsZW1lbnRpbmcgaXQuDQo+IA0KPiBCdXQgbGV0J3Mgbm90IGRyaWZ0IGZyb20gdGhlIHBv aW50LiBUaGUgc3BlYyBpcyB3cml0dGVuIGluIGEgZ2VuZXJhbCB3YXkgdG8gc29sdmUgb25seSBz ZW5kaW5nIE1hcC1SZWdpc3RlcnMgcmVsaWFibHkuIEkgc3VnZ2VzdCB0aGUgdGV4dCBub3QgbWlz bGVhZCB0aGUgcmVhZGVyIHRvIHRoaW5rIHRoaXMgaXMgYSBnZW5lcmFsIG5ldyBwYWNrZXQgZm9y bWF0IGZvciBhbnl0aGluZy4NCj4gDQo+IFdoZW4gcGVvcGxlIGp1ZGdlIHdoaWNoIHByb3RvY29s cyB0aGV5IHdhbnQgdG8gZGVwbG95LCB0aGUgcGVvcGxlIHRoYXQgZG8gdGhlIGR1ZSBkaWxpZ2Vu Y2Ugd2lsbCBsb29rIGF0IHRoZSBwcm90b2NvbCBzcGVjcyBhbmQgc2VlIGhvdyBtdWNoIG1lY2hh bmlzbSBpcyBkZXNpZ25lZCBpbi4gQW5kIHRoZXkgbWFrZSBqdWRnZW1lbnQgZGVjaXNpb25zIGFi b3V0IHVzaW5nIHRoZSBwcm90b2NvbC4NCj4gDQo+IEkga25vdyBvZiBhdCBsZWFzdCAyIHZlbmRv cnMgdGhhdCBzYWlkIOKAnEkgaW1wbGVtZW50ZWQgcGFnZXMgNDctNTAgb2YgdGhlIEVWUE4gc3Bl Y+KAnS4gIDstKQ0KPiANCj4gSW4gTElTUC4gd2Ugd2FudCB0byBtYWtlIHN1cmUgd2hhdCB3ZSBz cGVjIGlzIHdoYXQgaXMgdXNlZCBhbmQgbm90IGlnbm9yZWQgb3IgY29uc2lkZXJlZCBvcHRpb25h bC4gU28gcGxlYXNlIGRvY3VtZW50IHRoZSBzcGVjaWZpYyB1c2UtY2FzZSB5b3Ugd2FudCB0byBp bXBsZW1lbnQuIEFuZCBJ4oCZZCBzdWdnZXN0IG1ha2luZyB0aGUgZHJhZnQgbmFtZSBkcmFmdC0q LWxpc3AtcmVsaWFibGUtcmVnaXN0ZXJzLg0KPiANCj4+PiBMSVNQIGNhbiBwYWNrIGFsbCB0aG9z ZSBFSUQtcmVjb3JkcyBpbiBhIE1hcC1SZWdpc3RlciBqdXN0IGxpa2UgVENQIGRvZXMuIEFuZCBp ZiB5b3Ugd2FudCBwZXIgbm9uY2UgYWNrcywgeW91IHBhY2sgdGhlbSBpbiBJUCBwYWNrZXRzIDw9 IDY1NTM1IGJ5dGVzLiBUQ1Agd2lsbCBoYXZlIHRvIG8gdGhhdCBhcyB3ZWxsLg0KPj4gDQo+PiBU aGlzIGlzIGV4YWN0bHkgdGhlIHBvaW50LCB3aGlsZSBMSVNQIHNpZ25hbGluZyBhbGxvd3MgaXQg d2UgZG9u4oCZdCBuZWVkIHRvIHJlLWltcGxlbWVudCBldmVyeSBUQ1AgZmVhdHVyZSBpbiBMSVNQ LCBhcyBUQ1AgY2FuIGFscmVhZHkgcHJvdmlkZSBpdC4NCj4gDQo+IFlvdSBkb27igJl0IG5lZWQg dG8uIA0KPiANCj4+PiBBbmQgZ3Vlc3Mgd2hhdC4gV2hhdCBpZiB0aGVyZSBpcyBhbiBSTE9DLWNo YW5nZSBhbmQgeW91IGFscmVhZHkgZ2F2ZSB0aGUgbGFzdCBvbmUgdG8gVENQIGFuZCBjYW7igJl0 IHB1bGwgaXQgYmFjay4gSWYgeW91IHdlcmUgd2FpdGluZyBmb3IgYW4gYWNrIGFuZCBhIG5ldyBS TE9DLWNoYW5nZSBjYW1lIGluIChkdXJpbmcgYSBsb3NzeSBjYXNlKSwgeW91IHdvdWxkbuKAmXQg aGF2ZSB0byByZXRyYW5zbWl0IHRoZSBvbGQgaW5mb3JtYXRpb24gd2FzdGlseS4gU28ga2VlcCB0 aGUg4oCccmV0cmFuc21pc3Npb24gcXVldWXigJ0gaW4gTElTUCBoYXMgaXRzIGFkdmFudGFnZXMu DQo+PiANCj4+IEnigJltIG5vdCBzdXJlIHRoaXMgaXMgc28gZWFzeS4gVURQLCBqdXN0IGxpa2Ug VENQIHVzZXMgdGhlIFJMT0MgKElQKSBhcyBwYXJ0IG9mIHRoZSDigJxzZXNzaW9uIGlkZW50aWZp ZXLigJ0gYW5kIHRoZSBub25jZSBpcyBwZXItcGFja2V0LCBub3QgcGVyLXNlc3Npb24uIFRoZSBt b21lbnQgdGhlIFJMT0MgY2hhbmdlcyBvbiB0aGUgeFRSLCB0aGUgTVMgZG9lcyBub3Qga25vdyB0 aGF0IHRoZSB4VFIgaXMgdGhlIHNhbWUgc28gd2XigJlkIG5lZWQgYSByZXRyYW5zbWlzc2lvbiBw cm9jZXNzLg0KPiANCj4gSeKAmW0gbm90IHRhbGtpbmcgYWJvdXQgd2hlbiB0aGUgeFRSIGNoYW5n ZXMsIEnigJltIHRhbGtpbmcgYWJvdXQgYW4gYWRkcmVzcyBvbiBhbiBpbnRlcmZhY2Ugb24gdGhl IHNhbWUgeFRSIGNoYW5nZXMgc2luY2UgaXQgd2FzIERIQ1DigJllZCB0byB0aGUgeFRSIG9yIGJl aGluZCBhIE5BVC4gQnV0IGZvciB0aGUgTElTUC1NTiBjYXNlLCB0aGUgeFRSIGlzIG1vdmluZyBh bmQgaXRzIFJMT0NzIGFyZSBjaGFuZ2luZy4gWW91IGNvdXBsZSB0aGlzIHdpdGggcHVic3ViIGFu ZCB0aGUgZXh0cmEgTWFwLVJlZ2lzdGVycyB3aXRoIG9sZCBSTE9DcyBoYXMgYSByaXBwbGUgZWZm ZWN0IHdoZXJlIHRoZW4gdGhlIE1hcC1TZXJ2ZXIgc2VuZHMgTWFwLU5vdGlmeSBtZXNzYWdlcyB0 byBhbGwgdGhlIHN1YnNjcmliZXJzLCB0aGVuIGZvbGxvd2VkIGJ5IGFub3RoZXIgc2V0IG9mIE1h cC1Ob3RpZmllcyB3aXRoIHRoZSBuZXcgUkxPQy1zZXQuIFRoYXQgaXMgYSBsb3Qgb2YgKHVubmVj ZXNzYXJ5KSBtZXNzYWdpbmcgYW5kIHByb2Nlc3NpbmcuDQo+IA0KPiBXZSBoYXZlIHRvIHRoaW5r IGFib3V0IHRoZSBpbXBsaWNhdGlvbnMgb2YgYW55IG9uZSBkcmFmdCBvbiB0aGUgRU5USVJFIExJ U1AgYXJjaGl0ZWN0dXJlLiBJdCBtdXN0IHdvcmsgZWZmaWNpZW50bHkgYXMgb25lIGhvbGlzdGlj IGRpc3RyaWJ1dGVkIHN5c3RlbS4NCj4gDQo+IERpbm8NCj4gDQo+PiANCj4+IE1hcmMNCj4+IA0K Pj4gT24gMTIvNS8xNywgNTo1NyBQTSwgIkRpbm8gRmFyaW5hY2NpIiA8ZmFyaW5hY2NpQGdtYWls LmNvbT4gd3JvdGU6DQo+PiANCj4+PiBEaW5vLA0KPj4+IA0KPj4+IEluIGFkZGl0aW9uIHRvIHRo ZSBwcmV2aW91cyBhcmd1bWVudHMgdGhlcmUgYXJlIHBhcnRpY3VsYXIgdXNlLWNhc2VzIHdoZXJl IHRoZSB1c2Ugb2YgcmVsaWFibGUgdHJhbnNwb3J0IHNpbXBsaWZpZWQgdGhlIGRlcGxveW1lbnQg b2YgTElTUC4NCj4+IA0KPj4gICBJIHVuZGVyc3RhbmQgaXRzIGFkdmFudGFnZXMuIEkgYW0gZXhh bWluaW5nIGl0cyBjb3N0cy4NCj4+IA0KPj4+IEFzIGFuIGV4YW1wbGUsIHRoZSBtb21lbnQgd2Ug c3RhcnRlZCBzY2FsaW5nIGRhdGFjZW50ZXJzIHRvIHN1cHBvcnQgMTBzIG9mIHRob3VzYW5kcyBv ZiBob3N0cywgdGhlIHVzZSBvZiBhIHJlbGlhYmxlIHRyYW5zcG9ydCBoZWxwZWQgYSBsb3QgdGhl IG1hbmFnZW1lbnQgb2Ygc2NhbGU6IA0KPj4+IE9uIG9uZSBzaWRlIGl0IHJlZHVjZXMgdGhlIGFt b3VudCBvZiBzaWduYWxpbmcgd2hlbiBub3RoaW5nIGNoYW5nZXMsIHNpbmNlIHdlIHVzZSBUQ1Ag c3RhdGUgYXMgYW4gaW5kaWNhdGlvbiB0aGF0IHhUUnMgYW5kIHRoZSBNUyBhcmUgaW4gc3luYyBh bmQgdGhlcmUgaXMgbm8gbmVlZCB0byBkZWFsIHdpdGggdGhlIG9wdGltaXphdGlvbiBvZiB0aGUg cmVmcmVzaCBsb2dpYyAocGVyaW9kaWMgb3IgcGFjZWQpLiANCj4+IA0KPj4gICBMSVNQICh0aGUg YXBwbGljYXRpb24pLCBkb2VzIG5vdCBrbm93IHRoYXQgaXRzZWxmLCB0aGUgeFRSLCBpcyBpbiBz eW5jIHdpdGggdGhlIG1hcC1zZXJ2ZXIuIFRoZSBwYWNrZXRzIGNhbiBiZSBpbiBmbGlnaHQgb3Ig YmVpbmcgcmV0cmFuc21pdHRlZCBkdWUgdG8gbG9zcy4gQnV0IGlmIGEgTWFwLVJlZ2lzdGVyIGlz IHNlbnQgd2l0aCBhIG5vbmNlIGFuZCBubyBNYXAtTm90aWZ5IGlzIHJldHVybmVkIHRoZSB4VFIg a25vd3MgZm9yIHN1cmUgdGhlIHR3byBhcmUgaW4gc3luYy4NCj4+IA0KPj4gICBJ4oCZZCBhcmd1 ZSB5b3UgbWF5IGl0IHdvcnNlLiBUQ1AgZG9lcyBwcm92aWRlIHJlbGlhYmlsaXR5IGJ1dCBzbyBk b2VzIExJU1AgaXRzZWxmLiBBbmQgdGhlIG9ubHkgcmVhc29uIHRoZSBtZXNzYWdlcyBhcmUgcGVy aW9kaWMgaXMgYmVjYXVzZSB0aGUgc3BlYyBzYWlkIHRvIHNlbmQgZXZlcnkgMSBtaW51dGUgYW5k IHRpbWVvdXQgZXZlcnkgMyBtaW51dGVzLiBZb3UgY2FuIG1ha2UgaXQgMTAwMCBtaW51dGVzIGFu ZCB0aW1lb3V0IGV2ZXJ5IDMwMDAgbWludXRlcy4gDQo+PiANCj4+ICAgU28gbGV04oCZcyBrZWVw IHBlcmlpb2RpYyBvdmVyaGVhZCwgcmVsaWFiaWxpdHksIGFuZCBzdGF5aW5nIGluIHN5bmMgYXMg c2VwYXJhdGUgaXNzdWVzLg0KPj4gDQo+Pj4gT24gdGhlIG90aGVyIHNpZGUsIHdpdGggcmVsaWFi bGUgdHJhbnNwb3J0IHdlIG9mZmxvYWQgdGhlIHJlbGlhYmxlIGRlbGl2ZXJ5IG9mIGluZm9ybWF0 aW9uIChhbmQgY29uZ2VzdGlvbiBjb250cm9sKSANCj4+IA0KPj4gICBJIHVuZGVyc3RhbmQgdGhh dC4gQnV0IHlvdSBjYW7igJl0IHNheSBUQ1AgaXMga2VlcGluZyB5b3UgaW4gc3luYywgYmVjYXVz ZSB5b3UgaGF2ZSByZW1vdmVkIGRldGFpbCBmcm9tIHRoZSBhcHBsaWNhdGlvbmlzLg0KPj4gDQo+ Pj4gZnJvbSBMSVNQIHRvIGFub3RoZXIgcHJvY2VzcyAoVENQKSB0aGF0IGlzIGVudGlyZWx5IGRl dm90ZWQgYW5kIGRlc2lnbmVkIGZvciB0aGlzLiBGb3IgZXhhbXBsZSwgc3VwcG9ydGluZyBldmVu dHMgbGlrZSBtYXNzIFZNIG1vdmVzIHJlbHlpbmcgcHVyZWx5IG9uIExJU1AgYmFzZWQgQUNrcyBi ZWNhbWUgdmVyeSBjaGFsbGVuZ2luZywgYXMgd2UgZW5kZWQgdXAgaGF2aW5nIHRvIGRlYWwgd2l0 aCBjb25nZXN0aW9uIGV2ZW50cyByZWxhdGVkIHRvIHRoZSBzaWduYWxpbmcgbG9hZCBnZW5lcmF0 ZWQuIFRoZSB1c2Ugb2YgdGhlIHJlbGlhYmxlIHRyYW5zcG9ydCBsYXJnZWx5IHNpbXBsaWZpZWQg dGhlIHByb2JsZW0uDQo+PiANCj4+IERpbm8NCj4+IA0KPj4+IA0KPj4+IE1hcmMNCj4+PiANCj4+ PiBPbiAxMi81LzE3LCAxMjowNiBQTSwgImxpc3Agb24gYmVoYWxmIG9mIEpvaG5zb24gTGVvbmcg KGpvbGVvbmcpIiA8bGlzcC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqb2xlb25nQGNp c2NvLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gIEhpIERpbm8sDQo+Pj4gDQo+Pj4gIEEgbGFyZ2Ug cG9ydGlvbiBvZiB0aGlzIGRyYWZ0IGRpc2N1c3NlcyB0aGUgc3RhdGUgbWFjaGluZSByZXF1aXJl ZCBmb3IgVENQIGFuZCBob3cgdG8gZW5zdXJlIHRoZSBNUyBhbmQgeFRSIGFyZSBpbiBzeW5jLiAg V2UgbGl0ZXJhbGx5IHJldXNlIHRoZSBlbnRpcmUgVURQIG1hcC1yZWdpc3RlciBjb2RlLCB3ZSBq dXN0IHdyYXAgdGhhdCBtZXNzYWdlIGFyb3VuZCB0aGUgTElTUCBUQ1AgaGVhZGVyIHNvIHRoZXJl J3MgYSBsb3Qgb2YgY29kZSByZXVzZS4gIEZpbmFsbHksIHRoaXMgZHJhZnQgaXMgbm90IG1lYW50 IHRvIHJlcGxhY2UgVURQIHJlZ2lzdGVyIGJ1dCBpbiBzb21lIG9mIG91ciB1c2UgY2FzZXMgVENQ IHdvdWxkIHNjYWxlIGJldHRlciB0byBhdm9pZCB0aGUgcGVyaW9kaWMgcmVnaXN0cmF0aW9uLg0K Pj4+IA0KPj4+ICAtSm9obnNvbg0KPj4+IA0KPj4+PiBPbiBEZWMgNSwgMjAxNywgYXQgMTA6NTIg QU0sIERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiB3cm90ZToNCj4+Pj4gDQo+ Pj4+PiByZWdpc3RyYXRpb24gcHJvdG9jb2wsIHRoYXQgbWlnaHQgYmUgb3J0aG9nb25hbCB0byBv dGhlciB0cmFuc3BvcnQtcmVsYXRlZCBtZWNoYW5pc21zLiBJbiBteSBleHBlcmllbmNlIHRoaXMg aGFzIHByb3ZlZCB0byBiZSB2ZXJ5IGVmZmVjdGl2ZSBpbiBzY2FsYWJpbGl0eSBvZiBsYXJnZSBM SVNQIGRlcGxveW1lbnRzLCBlc3BlY2lhbGx5IHdpdGggdGhlIGluY3JlYXNlZCB2b2x1bWUgb2Yg cmVnaXN0cmF0aW9uIGRhdGEuDQo+Pj4+IA0KPj4+PiBJIGFncmVlIGl04oCZcyBhIHBvaW50IHNv bHV0aW9uIGZvciByZWdpc3RyYXRpb24uIFRoZW4gd2h5IGRpZCB5b3UgbmVlZCB0byBoYXZlIGEg Z2VuZXJhbCBmb3JtYXQuIA0KPj4+PiANCj4+Pj4gSSBjb3VsZCBzdXBwb3J0IHRoaXMgZHJhZnQg aWYgaXQgd2FzIHNpbXBsaWZpZWQgdG8gc3BlYyBob3cgdG8gdXNlIE1hcC1SZWdpc3RlcnMgaW4g VENQIGFuZCBub3RoaW5nIG1vcmUuIA0KPj4+PiANCj4+Pj4gVGhlIG9ubHkgdGhpbmcgSSB3b3Vs ZCBhZGQgaXMgaG93IHRvIHVzZSBUTFMgc28gZW5jcnlwdGlvbiBpcyBzdXBwb3J0ZWQuIE1vcmUg YW5kIG1vcmUgcmVxdWlyZW1lbnRzIGFyZSBjb21pbmcgdXAgZm9yIHByb3RlY3RpbmcgdGhlIHBy aXZhY3kgb2YgbG9jYXRpb24gaW5mb3JtYXRpb24uIEFuZCBzaW5jZSBNYXAtUmVnaXN0ZXJzIGNh cnJ5IFJMT0NzIChhbmQgcG90ZW50aWFsIEdlby1Db29yZG5hdGVzKSB0aGF0IGluZm9ybWF0aW9u IG5lZWRzIHRvIGJlIHByb3RlY3RlZC4gDQo+Pj4+IA0KPj4+PiBEaW5vDQo+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IGxpc3AgbWFpbGlu ZyBsaXN0DQo+Pj4+IGxpc3BAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9saXNwDQo+Pj4gDQo+Pj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4gIGxpc3AgbWFpbGluZyBsaXN0DQo+Pj4gIGxpc3BA aWV0Zi5vcmcNCj4+PiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNw DQo+Pj4gDQo+Pj4gDQo+PiANCj4+IA0KPj4gDQo+IA0KDQo= From nobody Wed Dec 6 12:18:01 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C399A12426E for ; Wed, 6 Dec 2017 12:17:56 -0800 (PST) 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_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 TxwSFWatjzRM for ; Wed, 6 Dec 2017 12:17:54 -0800 (PST) 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 BAAB4124207 for ; Wed, 6 Dec 2017 12:17:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9DCE6AE01EF; Wed, 6 Dec 2017 12:17:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1512591474; bh=DdAOQW98y9jWRhYpC7qDDAtGmTmRztUy+rxz4yrDBS4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=noaMa0rpt1w0y9X95n8EZ4pYh8/e953i9RhZxn9NFdjiJ46SoNGv2/FY1WhwBiCo9 ytCf+8BFkBux4LXKBpbOMhmPKTvOdXx/Q9qEGdUsvT4ZQdr3APc3CotXuhFXb6yJKg /kFr7hWFETrMhLWYfv2IEkdTU2dMgfzo3x26Ah/c= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 E3EED240A33; Wed, 6 Dec 2017 12:17:53 -0800 (PST) To: "Johnson Leong (joleong)" , Dino Farinacci Cc: "lisp@ietf.org" References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> From: "Joel M. Halpern" Message-ID: <52034017-790a-d040-c608-4004a6747dcd@joelhalpern.com> Date: Wed, 6 Dec 2017 15:17:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 20:17:57 -0000 Johnson, I think your example may cause more problems. I am not sure what you mean by "over-subscribed". But if the xTR sends a registration over TCP, and gets no answer, it is going to asume that it is properly registerd. If the registration has not been received due to the receiver not reading his TCP queue (because he is over-subscribed) that is a bad result. Yours, Joel On 12/6/17 2:44 PM, Johnson Leong (joleong) wrote: > Dino, > > What we're trying to convey is that by using TCP it allows us to achieve reliability which significantly simplifies the code and error handling. One can achieve the same with UDP with ack and retry but it would be reimplementing what TCP already offers and this added complexity typically makes the code error prone. > > Another benefit with TCP is congestion control, with UDP if we send a map-register and we don't get an ack then we retry. What if the MS is fully subscribed then this can lead to constant retry. You can impose backoff mechanism but ultimately this would affect convergence. > > -Johnson > >> On Dec 6, 2017, at 11:17 AM, Dino Farinacci wrote: >> >>> Dino, >>> >>>> LISP (the application), does not know that itself, the xTR, is in sync with the map-server. The packets can be in flight or being retransmitted due to loss. But if a Map-Register is sent with a nonce and no Map-Notify is returned the xTR knows for sure the two are in sync. >>> >>> An application (and LISP in this case) should always be able to know the state of a (TCP) socket that it has opened with a server. I’m not entirely sure why we would not want to use this information. >> >> All an app knows is the socket it has opened and any port it has bind()’ed to. It doesn’t know the connection state in terms of what packets have been sent and what has been ack’ed. There IS NOT enough information to do anything useful. >> >>> Besides, the reliable transport session does not invalidate the use of nonces and Map-Notifies as an indication that the MS has completely received the information, the just rely on the TCP state to know that nothing has changed. >> >> Right, so you have duplicate functionality. That isn’t efficient. >> >>>> I’d argue you may it worse. TCP does provide reliability but so does LISP itself. And the only reason the messages are periodic is because the spec said to send every 1 minute and timeout every 3 minutes. You can make it 1000 minutes and timeout every 3000 minutes. >>> >>> And this sounds as we would make the protocol very complicated to use (or code), as this would lead us to have to code/configure a specific registration pattern/logic for every use case that we want to support. Not saying we cannot, but it sounds like re-implementing TCP ;) >> >> You already have that code or you aren’t implementing Map-Register acks corrrectly. And changing a timer is really a constant change in the code. And what is spec’ed today in LISP proper is much simpler than TCP, it is not reimplementing it. >> >> But let's not drift from the point. The spec is written in a general way to solve only sending Map-Registers reliably. I suggest the text not mislead the reader to think this is a general new packet format for anything. >> >> When people judge which protocols they want to deploy, the people that do the due diligence will look at the protocol specs and see how much mechanism is designed in. And they make judgement decisions about using the protocol. >> >> I know of at least 2 vendors that said “I implemented pages 47-50 of the EVPN spec”. ;-) >> >> In LISP. we want to make sure what we spec is what is used and not ignored or considered optional. So please document the specific use-case you want to implement. And I’d suggest making the draft name draft-*-lisp-reliable-registers. >> >>>> LISP can pack all those EID-records in a Map-Register just like TCP does. And if you want per nonce acks, you pack them in IP packets <= 65535 bytes. TCP will have to o that as well. >>> >>> This is exactly the point, while LISP signaling allows it we don’t need to re-implement every TCP feature in LISP, as TCP can already provide it. >> >> You don’t need to. >> >>>> And guess what. What if there is an RLOC-change and you already gave the last one to TCP and can’t pull it back. If you were waiting for an ack and a new RLOC-change came in (during a lossy case), you wouldn’t have to retransmit the old information wastily. So keep the “retransmission queue” in LISP has its advantages. >>> >>> I’m not sure this is so easy. UDP, just like TCP uses the RLOC (IP) as part of the “session identifier” and the nonce is per-packet, not per-session. The moment the RLOC changes on the xTR, the MS does not know that the xTR is the same so we’d need a retransmission process. >> >> I’m not talking about when the xTR changes, I’m talking about an address on an interface on the same xTR changes since it was DHCP’ed to the xTR or behind a NAT. But for the LISP-MN case, the xTR is moving and its RLOCs are changing. You couple this with pubsub and the extra Map-Registers with old RLOCs has a ripple effect where then the Map-Server sends Map-Notify messages to all the subscribers, then followed by another set of Map-Notifies with the new RLOC-set. That is a lot of (unnecessary) messaging and processing. >> >> We have to think about the implications of any one draft on the ENTIRE LISP architecture. It must work efficiently as one holistic distributed system. >> >> Dino >> >>> >>> Marc >>> >>> On 12/5/17, 5:57 PM, "Dino Farinacci" wrote: >>> >>>> Dino, >>>> >>>> In addition to the previous arguments there are particular use-cases where the use of reliable transport simplified the deployment of LISP. >>> >>> I understand its advantages. I am examining its costs. >>> >>>> As an example, the moment we started scaling datacenters to support 10s of thousands of hosts, the use of a reliable transport helped a lot the management of scale: >>>> On one side it reduces the amount of signaling when nothing changes, since we use TCP state as an indication that xTRs and the MS are in sync and there is no need to deal with the optimization of the refresh logic (periodic or paced). >>> >>> LISP (the application), does not know that itself, the xTR, is in sync with the map-server. The packets can be in flight or being retransmitted due to loss. But if a Map-Register is sent with a nonce and no Map-Notify is returned the xTR knows for sure the two are in sync. >>> >>> I’d argue you may it worse. TCP does provide reliability but so does LISP itself. And the only reason the messages are periodic is because the spec said to send every 1 minute and timeout every 3 minutes. You can make it 1000 minutes and timeout every 3000 minutes. >>> >>> So let’s keep periiodic overhead, reliability, and staying in sync as separate issues. >>> >>>> On the other side, with reliable transport we offload the reliable delivery of information (and congestion control) >>> >>> I understand that. But you can’t say TCP is keeping you in sync, because you have removed detail from the applicationis. >>> >>>> from LISP to another process (TCP) that is entirely devoted and designed for this. For example, supporting events like mass VM moves relying purely on LISP based ACks became very challenging, as we ended up having to deal with congestion events related to the signaling load generated. The use of the reliable transport largely simplified the problem. >>> >>> Dino >>> >>>> >>>> Marc >>>> >>>> On 12/5/17, 12:06 PM, "lisp on behalf of Johnson Leong (joleong)" wrote: >>>> >>>> Hi Dino, >>>> >>>> A large portion of this draft discusses the state machine required for TCP and how to ensure the MS and xTR are in sync. We literally reuse the entire UDP map-register code, we just wrap that message around the LISP TCP header so there's a lot of code reuse. Finally, this draft is not meant to replace UDP register but in some of our use cases TCP would scale better to avoid the periodic registration. >>>> >>>> -Johnson >>>> >>>>> On Dec 5, 2017, at 10:52 AM, Dino Farinacci wrote: >>>>> >>>>>> registration protocol, that might be orthogonal to other transport-related mechanisms. In my experience this has proved to be very effective in scalability of large LISP deployments, especially with the increased volume of registration data. >>>>> >>>>> I agree it’s a point solution for registration. Then why did you need to have a general format. >>>>> >>>>> I could support this draft if it was simplified to spec how to use Map-Registers in TCP and nothing more. >>>>> >>>>> The only thing I would add is how to use TLS so encryption is supported. More and more requirements are coming up for protecting the privacy of location information. And since Map-Registers carry RLOCs (and potential Geo-Coordnates) that information needs to be protected. >>>>> >>>>> Dino >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> >>> >>> >>> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Wed Dec 6 12:26:03 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25721200FC for ; Wed, 6 Dec 2017 12:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0mhDryFBYra for ; Wed, 6 Dec 2017 12:26:00 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26CD124207 for ; Wed, 6 Dec 2017 12:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13918; q=dns/txt; s=iport; t=1512591959; x=1513801559; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rbmZafbyf2+yVvNXwYOVzT4k9WEmZhFrOoyg1iC3OsE=; b=HMz/P1Ey63PsMGt/vpZocfPNzoRD+Yo6aH3b5qEbemWOIHSouFbzu0mb 9ARaoYGNi1su1qASsO6NR+mU2jgFLprdv1aAtfjxrEJ0slWgvggPc5VGa JChzglfhdk50JTl/S04cmbjxRl2zDfWeBt4uSw+WGGZYHVfAPnWRCiTVe M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQCQUSha/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOL2ZwJweDe4ogjnuBVyaIdI4RFIIBChgLhRgCGoU6PxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUiAQEBAwEBASEROgsFCwIBCBIGAgImAgICHwYLFQIOAgQOBRuJc?= =?us-ascii?q?AMNCBCpEYInhzkNgxABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhE2BVoFoASk?= =?us-ascii?q?LgneCa4IeAhaDFTGCMgWSCJA4PQKQHIR7ghaGEYs0jT6IaAIRGQGBOQEfOYFOb?= =?us-ascii?q?xU6KgGBfoJPAxwZgU54hyUHgSyBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,369,1508803200"; d="scan'208";a="40667305" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2017 20:25:58 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vB6KPwoe017422 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 20:25:58 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 14:25:58 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1320.000; Wed, 6 Dec 2017 14:25:57 -0600 From: "Johnson Leong (joleong)" To: "Joel M. Halpern" CC: Dino Farinacci , "lisp@ietf.org" Thread-Topic: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption Thread-Index: AQHTbeo9EtGVHwDVv0CpzXF7TtVp96M1cgIAgAAI1ACAAAI0gIAAFL8AgABIZYCAABmDAIAA9doAgAAs4gCAAAeGAIAACWMAgAACRgA= Date: Wed, 6 Dec 2017 20:25:57 +0000 Message-ID: <97356212-F979-4263-894D-1BE7297675CC@cisco.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> <52034017-790a-d040-c608-4004a6747dcd@joelhalpern.com> In-Reply-To: <52034017-790a-d040-c608-4004a6747dcd@joelhalpern.com> 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.154.161.8] Content-Type: text/plain; charset="utf-8" Content-ID: <945ABA7D7FB8844CBBC6FE89BAB33A99@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 20:26:02 -0000 Sm9lbCwNCg0KSWYgdGhlcmUncyBmbG93IGNvbnRyb2wgYmV0d2VlbiB0aGUgeFRSIGFuZCBNUyB0 aGVuIHRoZSB4VFIgd291bGRuJ3QgYXR0ZW1wdCB0byBzZW5kIHRoZSByZWdpc3RlciBpZiB0aGUg TVMgY2Fubm90IGtlZXAgdXAuICBEZXBlbmRpbmcgb24geW91ciBpbXBsZW1lbnRhdGlvbiB0aGUg eFRSIGNhbiBzdG9wIGJ1aWxkaW5nIHJlZ2lzdHJhdGlvbiBtZXNzYWdlIHVudGlsIGZsb3cgY29u dHJvbCBpcyBvZmYgd2l0aCB0aGUgTVMuDQoNCi1Kb2huc29uDQoNCj4gT24gRGVjIDYsIDIwMTcs IGF0IDEyOjE3IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3Rl Og0KPiANCj4gPHNwZWFraW5nIHdpdGhvdXQgaGF0cy4+DQo+IEpvaG5zb24sIEkgdGhpbmsgeW91 ciBleGFtcGxlIG1heSBjYXVzZSBtb3JlIHByb2JsZW1zLg0KPiBJIGFtIG5vdCBzdXJlIHdoYXQg eW91IG1lYW4gYnkgIm92ZXItc3Vic2NyaWJlZCIuDQo+IEJ1dCBpZiB0aGUgeFRSIHNlbmRzIGEg cmVnaXN0cmF0aW9uIG92ZXIgVENQLCBhbmQgZ2V0cyBubyBhbnN3ZXIsIGl0IGlzIGdvaW5nIHRv IGFzdW1lIHRoYXQgaXQgaXMgcHJvcGVybHkgcmVnaXN0ZXJkLiAgSWYgdGhlIHJlZ2lzdHJhdGlv biBoYXMgbm90IGJlZW4gcmVjZWl2ZWQgZHVlIHRvIHRoZSByZWNlaXZlciBub3QgcmVhZGluZyBo aXMgVENQIHF1ZXVlIChiZWNhdXNlIGhlIGlzIG92ZXItc3Vic2NyaWJlZCkgdGhhdCBpcyBhIGJh ZCByZXN1bHQuDQo+IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gT24gMTIvNi8xNyAyOjQ0IFBN LCBKb2huc29uIExlb25nIChqb2xlb25nKSB3cm90ZToNCj4+IERpbm8sDQo+PiBXaGF0IHdlJ3Jl IHRyeWluZyB0byBjb252ZXkgaXMgdGhhdCBieSB1c2luZyBUQ1AgaXQgYWxsb3dzIHVzIHRvIGFj aGlldmUgcmVsaWFiaWxpdHkgd2hpY2ggc2lnbmlmaWNhbnRseSBzaW1wbGlmaWVzIHRoZSBjb2Rl IGFuZCBlcnJvciBoYW5kbGluZy4gIE9uZSBjYW4gYWNoaWV2ZSB0aGUgc2FtZSB3aXRoIFVEUCB3 aXRoIGFjayBhbmQgcmV0cnkgYnV0IGl0IHdvdWxkIGJlIHJlaW1wbGVtZW50aW5nIHdoYXQgVENQ IGFscmVhZHkgb2ZmZXJzIGFuZCB0aGlzIGFkZGVkIGNvbXBsZXhpdHkgdHlwaWNhbGx5IG1ha2Vz IHRoZSBjb2RlIGVycm9yIHByb25lLg0KPj4gQW5vdGhlciBiZW5lZml0IHdpdGggVENQIGlzIGNv bmdlc3Rpb24gY29udHJvbCwgd2l0aCBVRFAgaWYgd2Ugc2VuZCBhIG1hcC1yZWdpc3RlciBhbmQg d2UgZG9uJ3QgZ2V0IGFuIGFjayB0aGVuIHdlIHJldHJ5LiAgV2hhdCBpZiB0aGUgTVMgaXMgZnVs bHkgc3Vic2NyaWJlZCB0aGVuIHRoaXMgY2FuIGxlYWQgdG8gY29uc3RhbnQgcmV0cnkuICBZb3Ug Y2FuIGltcG9zZSBiYWNrb2ZmIG1lY2hhbmlzbSBidXQgdWx0aW1hdGVseSB0aGlzIHdvdWxkIGFm ZmVjdCBjb252ZXJnZW5jZS4NCj4+IC1Kb2huc29uDQo+Pj4gT24gRGVjIDYsIDIwMTcsIGF0IDEx OjE3IEFNLCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4g DQo+Pj4+IERpbm8sDQo+Pj4+IA0KPj4+Pj4gIExJU1AgKHRoZSBhcHBsaWNhdGlvbiksIGRvZXMg bm90IGtub3cgdGhhdCBpdHNlbGYsIHRoZSB4VFIsIGlzIGluIHN5bmMgd2l0aCB0aGUgbWFwLXNl cnZlci4gVGhlIHBhY2tldHMgY2FuIGJlIGluIGZsaWdodCBvciBiZWluZyByZXRyYW5zbWl0dGVk IGR1ZSB0byBsb3NzLiBCdXQgaWYgYSBNYXAtUmVnaXN0ZXIgaXMgc2VudCB3aXRoIGEgbm9uY2Ug YW5kIG5vIE1hcC1Ob3RpZnkgaXMgcmV0dXJuZWQgdGhlIHhUUiBrbm93cyBmb3Igc3VyZSB0aGUg dHdvIGFyZSBpbiBzeW5jLg0KPj4+PiANCj4+Pj4gQW4gYXBwbGljYXRpb24gKGFuZCBMSVNQIGlu IHRoaXMgY2FzZSkgc2hvdWxkIGFsd2F5cyBiZSBhYmxlIHRvIGtub3cgdGhlIHN0YXRlIG9mIGEg KFRDUCkgc29ja2V0IHRoYXQgaXQgaGFzIG9wZW5lZCB3aXRoIGEgc2VydmVyLiBJ4oCZbSBub3Qg ZW50aXJlbHkgc3VyZSB3aHkgd2Ugd291bGQgbm90IHdhbnQgdG8gdXNlIHRoaXMgaW5mb3JtYXRp b24uDQo+Pj4gDQo+Pj4gQWxsIGFuIGFwcCBrbm93cyBpcyB0aGUgc29ja2V0IGl0IGhhcyBvcGVu ZWQgYW5kIGFueSBwb3J0IGl0IGhhcyBiaW5kKCnigJllZCB0by4gSXQgZG9lc27igJl0IGtub3cg dGhlIGNvbm5lY3Rpb24gc3RhdGUgaW4gdGVybXMgb2Ygd2hhdCBwYWNrZXRzIGhhdmUgYmVlbiBz ZW50IGFuZCB3aGF0IGhhcyBiZWVuIGFja+KAmWVkLiBUaGVyZSBJUyBOT1QgZW5vdWdoIGluZm9y bWF0aW9uIHRvIGRvIGFueXRoaW5nIHVzZWZ1bC4NCj4+PiANCj4+Pj4gQmVzaWRlcywgdGhlIHJl bGlhYmxlIHRyYW5zcG9ydCBzZXNzaW9uIGRvZXMgbm90IGludmFsaWRhdGUgdGhlIHVzZSBvZiBu b25jZXMgYW5kIE1hcC1Ob3RpZmllcyBhcyBhbiBpbmRpY2F0aW9uIHRoYXQgdGhlIE1TIGhhcyBj b21wbGV0ZWx5IHJlY2VpdmVkIHRoZSBpbmZvcm1hdGlvbiwgdGhlIGp1c3QgcmVseSBvbiB0aGUg VENQIHN0YXRlIHRvIGtub3cgdGhhdCBub3RoaW5nIGhhcyBjaGFuZ2VkLg0KPj4+IA0KPj4+IFJp Z2h0LCBzbyB5b3UgaGF2ZSBkdXBsaWNhdGUgZnVuY3Rpb25hbGl0eS4gVGhhdCBpc27igJl0IGVm ZmljaWVudC4NCj4+PiANCj4+Pj4+IEnigJlkIGFyZ3VlIHlvdSBtYXkgaXQgd29yc2UuIFRDUCBk b2VzIHByb3ZpZGUgcmVsaWFiaWxpdHkgYnV0IHNvIGRvZXMgTElTUCBpdHNlbGYuIEFuZCB0aGUg b25seSByZWFzb24gdGhlIG1lc3NhZ2VzIGFyZSBwZXJpb2RpYyBpcyBiZWNhdXNlIHRoZSBzcGVj IHNhaWQgdG8gc2VuZCBldmVyeSAxIG1pbnV0ZSBhbmQgdGltZW91dCBldmVyeSAzIG1pbnV0ZXMu IFlvdSBjYW4gbWFrZSBpdCAxMDAwIG1pbnV0ZXMgYW5kIHRpbWVvdXQgZXZlcnkgMzAwMCBtaW51 dGVzLg0KPj4+PiANCj4+Pj4gQW5kIHRoaXMgc291bmRzIGFzIHdlIHdvdWxkIG1ha2UgdGhlIHBy b3RvY29sIHZlcnkgY29tcGxpY2F0ZWQgdG8gdXNlIChvciBjb2RlKSwgYXMgdGhpcyB3b3VsZCBs ZWFkIHVzIHRvIGhhdmUgdG8gY29kZS9jb25maWd1cmUgYSBzcGVjaWZpYyByZWdpc3RyYXRpb24g cGF0dGVybi9sb2dpYyBmb3IgZXZlcnkgdXNlIGNhc2UgdGhhdCB3ZSB3YW50IHRvIHN1cHBvcnQu IE5vdCBzYXlpbmcgd2UgY2Fubm90LCBidXQgaXQgc291bmRzIGxpa2UgcmUtaW1wbGVtZW50aW5n IFRDUCA7KQ0KPj4+IA0KPj4+IFlvdSBhbHJlYWR5IGhhdmUgdGhhdCBjb2RlIG9yIHlvdSBhcmVu 4oCZdCBpbXBsZW1lbnRpbmcgTWFwLVJlZ2lzdGVyIGFja3MgY29ycnJlY3RseS4gQW5kIGNoYW5n aW5nIGEgdGltZXIgaXMgcmVhbGx5IGEgY29uc3RhbnQgY2hhbmdlIGluIHRoZSBjb2RlLiBBbmQg d2hhdCBpcyBzcGVj4oCZZWQgdG9kYXkgaW4gTElTUCBwcm9wZXIgaXMgbXVjaCBzaW1wbGVyIHRo YW4gVENQLCBpdCBpcyBub3QgcmVpbXBsZW1lbnRpbmcgaXQuDQo+Pj4gDQo+Pj4gQnV0IGxldCdz IG5vdCBkcmlmdCBmcm9tIHRoZSBwb2ludC4gVGhlIHNwZWMgaXMgd3JpdHRlbiBpbiBhIGdlbmVy YWwgd2F5IHRvIHNvbHZlIG9ubHkgc2VuZGluZyBNYXAtUmVnaXN0ZXJzIHJlbGlhYmx5LiBJIHN1 Z2dlc3QgdGhlIHRleHQgbm90IG1pc2xlYWQgdGhlIHJlYWRlciB0byB0aGluayB0aGlzIGlzIGEg Z2VuZXJhbCBuZXcgcGFja2V0IGZvcm1hdCBmb3IgYW55dGhpbmcuDQo+Pj4gDQo+Pj4gV2hlbiBw ZW9wbGUganVkZ2Ugd2hpY2ggcHJvdG9jb2xzIHRoZXkgd2FudCB0byBkZXBsb3ksIHRoZSBwZW9w bGUgdGhhdCBkbyB0aGUgZHVlIGRpbGlnZW5jZSB3aWxsIGxvb2sgYXQgdGhlIHByb3RvY29sIHNw ZWNzIGFuZCBzZWUgaG93IG11Y2ggbWVjaGFuaXNtIGlzIGRlc2lnbmVkIGluLiBBbmQgdGhleSBt YWtlIGp1ZGdlbWVudCBkZWNpc2lvbnMgYWJvdXQgdXNpbmcgdGhlIHByb3RvY29sLg0KPj4+IA0K Pj4+IEkga25vdyBvZiBhdCBsZWFzdCAyIHZlbmRvcnMgdGhhdCBzYWlkIOKAnEkgaW1wbGVtZW50 ZWQgcGFnZXMgNDctNTAgb2YgdGhlIEVWUE4gc3BlY+KAnS4gIDstKQ0KPj4+IA0KPj4+IEluIExJ U1AuIHdlIHdhbnQgdG8gbWFrZSBzdXJlIHdoYXQgd2Ugc3BlYyBpcyB3aGF0IGlzIHVzZWQgYW5k IG5vdCBpZ25vcmVkIG9yIGNvbnNpZGVyZWQgb3B0aW9uYWwuIFNvIHBsZWFzZSBkb2N1bWVudCB0 aGUgc3BlY2lmaWMgdXNlLWNhc2UgeW91IHdhbnQgdG8gaW1wbGVtZW50LiBBbmQgSeKAmWQgc3Vn Z2VzdCBtYWtpbmcgdGhlIGRyYWZ0IG5hbWUgZHJhZnQtKi1saXNwLXJlbGlhYmxlLXJlZ2lzdGVy cy4NCj4+PiANCj4+Pj4+IExJU1AgY2FuIHBhY2sgYWxsIHRob3NlIEVJRC1yZWNvcmRzIGluIGEg TWFwLVJlZ2lzdGVyIGp1c3QgbGlrZSBUQ1AgZG9lcy4gQW5kIGlmIHlvdSB3YW50IHBlciBub25j ZSBhY2tzLCB5b3UgcGFjayB0aGVtIGluIElQIHBhY2tldHMgPD0gNjU1MzUgYnl0ZXMuIFRDUCB3 aWxsIGhhdmUgdG8gbyB0aGF0IGFzIHdlbGwuDQo+Pj4+IA0KPj4+PiBUaGlzIGlzIGV4YWN0bHkg dGhlIHBvaW50LCB3aGlsZSBMSVNQIHNpZ25hbGluZyBhbGxvd3MgaXQgd2UgZG9u4oCZdCBuZWVk IHRvIHJlLWltcGxlbWVudCBldmVyeSBUQ1AgZmVhdHVyZSBpbiBMSVNQLCBhcyBUQ1AgY2FuIGFs cmVhZHkgcHJvdmlkZSBpdC4NCj4+PiANCj4+PiBZb3UgZG9u4oCZdCBuZWVkIHRvLg0KPj4+IA0K Pj4+Pj4gQW5kIGd1ZXNzIHdoYXQuIFdoYXQgaWYgdGhlcmUgaXMgYW4gUkxPQy1jaGFuZ2UgYW5k IHlvdSBhbHJlYWR5IGdhdmUgdGhlIGxhc3Qgb25lIHRvIFRDUCBhbmQgY2Fu4oCZdCBwdWxsIGl0 IGJhY2suIElmIHlvdSB3ZXJlIHdhaXRpbmcgZm9yIGFuIGFjayBhbmQgYSBuZXcgUkxPQy1jaGFu Z2UgY2FtZSBpbiAoZHVyaW5nIGEgbG9zc3kgY2FzZSksIHlvdSB3b3VsZG7igJl0IGhhdmUgdG8g cmV0cmFuc21pdCB0aGUgb2xkIGluZm9ybWF0aW9uIHdhc3RpbHkuIFNvIGtlZXAgdGhlIOKAnHJl dHJhbnNtaXNzaW9uIHF1ZXVl4oCdIGluIExJU1AgaGFzIGl0cyBhZHZhbnRhZ2VzLg0KPj4+PiAN Cj4+Pj4gSeKAmW0gbm90IHN1cmUgdGhpcyBpcyBzbyBlYXN5LiBVRFAsIGp1c3QgbGlrZSBUQ1Ag dXNlcyB0aGUgUkxPQyAoSVApIGFzIHBhcnQgb2YgdGhlIOKAnHNlc3Npb24gaWRlbnRpZmllcuKA nSBhbmQgdGhlIG5vbmNlIGlzIHBlci1wYWNrZXQsIG5vdCBwZXItc2Vzc2lvbi4gVGhlIG1vbWVu dCB0aGUgUkxPQyBjaGFuZ2VzIG9uIHRoZSB4VFIsIHRoZSBNUyBkb2VzIG5vdCBrbm93IHRoYXQg dGhlIHhUUiBpcyB0aGUgc2FtZSBzbyB3ZeKAmWQgbmVlZCBhIHJldHJhbnNtaXNzaW9uIHByb2Nl c3MuDQo+Pj4gDQo+Pj4gSeKAmW0gbm90IHRhbGtpbmcgYWJvdXQgd2hlbiB0aGUgeFRSIGNoYW5n ZXMsIEnigJltIHRhbGtpbmcgYWJvdXQgYW4gYWRkcmVzcyBvbiBhbiBpbnRlcmZhY2Ugb24gdGhl IHNhbWUgeFRSIGNoYW5nZXMgc2luY2UgaXQgd2FzIERIQ1DigJllZCB0byB0aGUgeFRSIG9yIGJl aGluZCBhIE5BVC4gQnV0IGZvciB0aGUgTElTUC1NTiBjYXNlLCB0aGUgeFRSIGlzIG1vdmluZyBh bmQgaXRzIFJMT0NzIGFyZSBjaGFuZ2luZy4gWW91IGNvdXBsZSB0aGlzIHdpdGggcHVic3ViIGFu ZCB0aGUgZXh0cmEgTWFwLVJlZ2lzdGVycyB3aXRoIG9sZCBSTE9DcyBoYXMgYSByaXBwbGUgZWZm ZWN0IHdoZXJlIHRoZW4gdGhlIE1hcC1TZXJ2ZXIgc2VuZHMgTWFwLU5vdGlmeSBtZXNzYWdlcyB0 byBhbGwgdGhlIHN1YnNjcmliZXJzLCB0aGVuIGZvbGxvd2VkIGJ5IGFub3RoZXIgc2V0IG9mIE1h cC1Ob3RpZmllcyB3aXRoIHRoZSBuZXcgUkxPQy1zZXQuIFRoYXQgaXMgYSBsb3Qgb2YgKHVubmVj ZXNzYXJ5KSBtZXNzYWdpbmcgYW5kIHByb2Nlc3NpbmcuDQo+Pj4gDQo+Pj4gV2UgaGF2ZSB0byB0 aGluayBhYm91dCB0aGUgaW1wbGljYXRpb25zIG9mIGFueSBvbmUgZHJhZnQgb24gdGhlIEVOVElS RSBMSVNQIGFyY2hpdGVjdHVyZS4gSXQgbXVzdCB3b3JrIGVmZmljaWVudGx5IGFzIG9uZSBob2xp c3RpYyBkaXN0cmlidXRlZCBzeXN0ZW0uDQo+Pj4gDQo+Pj4gRGlubw0KPj4+IA0KPj4+PiANCj4+ Pj4gTWFyYw0KPj4+PiANCj4+Pj4gT24gMTIvNS8xNywgNTo1NyBQTSwgIkRpbm8gRmFyaW5hY2Np IiA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gRGlubywNCj4+Pj4+ IA0KPj4+Pj4gSW4gYWRkaXRpb24gdG8gdGhlIHByZXZpb3VzIGFyZ3VtZW50cyB0aGVyZSBhcmUg cGFydGljdWxhciB1c2UtY2FzZXMgd2hlcmUgdGhlIHVzZSBvZiByZWxpYWJsZSB0cmFuc3BvcnQg c2ltcGxpZmllZCB0aGUgZGVwbG95bWVudCBvZiBMSVNQLg0KPj4+PiANCj4+Pj4gICBJIHVuZGVy c3RhbmQgaXRzIGFkdmFudGFnZXMuIEkgYW0gZXhhbWluaW5nIGl0cyBjb3N0cy4NCj4+Pj4gDQo+ Pj4+PiBBcyBhbiBleGFtcGxlLCB0aGUgbW9tZW50IHdlIHN0YXJ0ZWQgc2NhbGluZyBkYXRhY2Vu dGVycyB0byBzdXBwb3J0IDEwcyBvZiB0aG91c2FuZHMgb2YgaG9zdHMsIHRoZSB1c2Ugb2YgYSBy ZWxpYWJsZSB0cmFuc3BvcnQgaGVscGVkIGEgbG90IHRoZSBtYW5hZ2VtZW50IG9mIHNjYWxlOg0K Pj4+Pj4gT24gb25lIHNpZGUgaXQgcmVkdWNlcyB0aGUgYW1vdW50IG9mIHNpZ25hbGluZyB3aGVu IG5vdGhpbmcgY2hhbmdlcywgc2luY2Ugd2UgdXNlIFRDUCBzdGF0ZSBhcyBhbiBpbmRpY2F0aW9u IHRoYXQgeFRScyBhbmQgdGhlIE1TIGFyZSBpbiBzeW5jIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRv IGRlYWwgd2l0aCB0aGUgb3B0aW1pemF0aW9uIG9mIHRoZSByZWZyZXNoIGxvZ2ljIChwZXJpb2Rp YyBvciBwYWNlZCkuDQo+Pj4+IA0KPj4+PiAgIExJU1AgKHRoZSBhcHBsaWNhdGlvbiksIGRvZXMg bm90IGtub3cgdGhhdCBpdHNlbGYsIHRoZSB4VFIsIGlzIGluIHN5bmMgd2l0aCB0aGUgbWFwLXNl cnZlci4gVGhlIHBhY2tldHMgY2FuIGJlIGluIGZsaWdodCBvciBiZWluZyByZXRyYW5zbWl0dGVk IGR1ZSB0byBsb3NzLiBCdXQgaWYgYSBNYXAtUmVnaXN0ZXIgaXMgc2VudCB3aXRoIGEgbm9uY2Ug YW5kIG5vIE1hcC1Ob3RpZnkgaXMgcmV0dXJuZWQgdGhlIHhUUiBrbm93cyBmb3Igc3VyZSB0aGUg dHdvIGFyZSBpbiBzeW5jLg0KPj4+PiANCj4+Pj4gICBJ4oCZZCBhcmd1ZSB5b3UgbWF5IGl0IHdv cnNlLiBUQ1AgZG9lcyBwcm92aWRlIHJlbGlhYmlsaXR5IGJ1dCBzbyBkb2VzIExJU1AgaXRzZWxm LiBBbmQgdGhlIG9ubHkgcmVhc29uIHRoZSBtZXNzYWdlcyBhcmUgcGVyaW9kaWMgaXMgYmVjYXVz ZSB0aGUgc3BlYyBzYWlkIHRvIHNlbmQgZXZlcnkgMSBtaW51dGUgYW5kIHRpbWVvdXQgZXZlcnkg MyBtaW51dGVzLiBZb3UgY2FuIG1ha2UgaXQgMTAwMCBtaW51dGVzIGFuZCB0aW1lb3V0IGV2ZXJ5 IDMwMDAgbWludXRlcy4NCj4+Pj4gDQo+Pj4+ICAgU28gbGV04oCZcyBrZWVwIHBlcmlpb2RpYyBv dmVyaGVhZCwgcmVsaWFiaWxpdHksIGFuZCBzdGF5aW5nIGluIHN5bmMgYXMgc2VwYXJhdGUgaXNz dWVzLg0KPj4+PiANCj4+Pj4+IE9uIHRoZSBvdGhlciBzaWRlLCB3aXRoIHJlbGlhYmxlIHRyYW5z cG9ydCB3ZSBvZmZsb2FkIHRoZSByZWxpYWJsZSBkZWxpdmVyeSBvZiBpbmZvcm1hdGlvbiAoYW5k IGNvbmdlc3Rpb24gY29udHJvbCkNCj4+Pj4gDQo+Pj4+ICAgSSB1bmRlcnN0YW5kIHRoYXQuIEJ1 dCB5b3UgY2Fu4oCZdCBzYXkgVENQIGlzIGtlZXBpbmcgeW91IGluIHN5bmMsIGJlY2F1c2UgeW91 IGhhdmUgcmVtb3ZlZCBkZXRhaWwgZnJvbSB0aGUgYXBwbGljYXRpb25pcy4NCj4+Pj4gDQo+Pj4+ PiBmcm9tIExJU1AgdG8gYW5vdGhlciBwcm9jZXNzIChUQ1ApIHRoYXQgaXMgZW50aXJlbHkgZGV2 b3RlZCBhbmQgZGVzaWduZWQgZm9yIHRoaXMuIEZvciBleGFtcGxlLCBzdXBwb3J0aW5nIGV2ZW50 cyBsaWtlIG1hc3MgVk0gbW92ZXMgcmVseWluZyBwdXJlbHkgb24gTElTUCBiYXNlZCBBQ2tzIGJl Y2FtZSB2ZXJ5IGNoYWxsZW5naW5nLCBhcyB3ZSBlbmRlZCB1cCBoYXZpbmcgdG8gZGVhbCB3aXRo IGNvbmdlc3Rpb24gZXZlbnRzIHJlbGF0ZWQgdG8gdGhlIHNpZ25hbGluZyBsb2FkIGdlbmVyYXRl ZC4gVGhlIHVzZSBvZiB0aGUgcmVsaWFibGUgdHJhbnNwb3J0IGxhcmdlbHkgc2ltcGxpZmllZCB0 aGUgcHJvYmxlbS4NCj4+Pj4gDQo+Pj4+IERpbm8NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE1hcmMN Cj4+Pj4+IA0KPj4+Pj4gT24gMTIvNS8xNywgMTI6MDYgUE0sICJsaXNwIG9uIGJlaGFsZiBvZiBK b2huc29uIExlb25nIChqb2xlb25nKSIgPGxpc3AtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2Ygam9sZW9uZ0BjaXNjby5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiAgSGkgRGlubywNCj4+ Pj4+IA0KPj4+Pj4gIEEgbGFyZ2UgcG9ydGlvbiBvZiB0aGlzIGRyYWZ0IGRpc2N1c3NlcyB0aGUg c3RhdGUgbWFjaGluZSByZXF1aXJlZCBmb3IgVENQIGFuZCBob3cgdG8gZW5zdXJlIHRoZSBNUyBh bmQgeFRSIGFyZSBpbiBzeW5jLiAgV2UgbGl0ZXJhbGx5IHJldXNlIHRoZSBlbnRpcmUgVURQIG1h cC1yZWdpc3RlciBjb2RlLCB3ZSBqdXN0IHdyYXAgdGhhdCBtZXNzYWdlIGFyb3VuZCB0aGUgTElT UCBUQ1AgaGVhZGVyIHNvIHRoZXJlJ3MgYSBsb3Qgb2YgY29kZSByZXVzZS4gIEZpbmFsbHksIHRo aXMgZHJhZnQgaXMgbm90IG1lYW50IHRvIHJlcGxhY2UgVURQIHJlZ2lzdGVyIGJ1dCBpbiBzb21l IG9mIG91ciB1c2UgY2FzZXMgVENQIHdvdWxkIHNjYWxlIGJldHRlciB0byBhdm9pZCB0aGUgcGVy aW9kaWMgcmVnaXN0cmF0aW9uLg0KPj4+Pj4gDQo+Pj4+PiAgLUpvaG5zb24NCj4+Pj4+IA0KPj4+ Pj4+IE9uIERlYyA1LCAyMDE3LCBhdCAxMDo1MiBBTSwgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNj aUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+PiByZWdpc3RyYXRpb24gcHJvdG9j b2wsIHRoYXQgbWlnaHQgYmUgb3J0aG9nb25hbCB0byBvdGhlciB0cmFuc3BvcnQtcmVsYXRlZCBt ZWNoYW5pc21zLiBJbiBteSBleHBlcmllbmNlIHRoaXMgaGFzIHByb3ZlZCB0byBiZSB2ZXJ5IGVm ZmVjdGl2ZSBpbiBzY2FsYWJpbGl0eSBvZiBsYXJnZSBMSVNQIGRlcGxveW1lbnRzLCBlc3BlY2lh bGx5IHdpdGggdGhlIGluY3JlYXNlZCB2b2x1bWUgb2YgcmVnaXN0cmF0aW9uIGRhdGEuDQo+Pj4+ Pj4gDQo+Pj4+Pj4gSSBhZ3JlZSBpdOKAmXMgYSBwb2ludCBzb2x1dGlvbiBmb3IgcmVnaXN0cmF0 aW9uLiBUaGVuIHdoeSBkaWQgeW91IG5lZWQgdG8gaGF2ZSBhIGdlbmVyYWwgZm9ybWF0Lg0KPj4+ Pj4+IA0KPj4+Pj4+IEkgY291bGQgc3VwcG9ydCB0aGlzIGRyYWZ0IGlmIGl0IHdhcyBzaW1wbGlm aWVkIHRvIHNwZWMgaG93IHRvIHVzZSBNYXAtUmVnaXN0ZXJzIGluIFRDUCBhbmQgbm90aGluZyBt b3JlLg0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSBvbmx5IHRoaW5nIEkgd291bGQgYWRkIGlzIGhvdyB0 byB1c2UgVExTIHNvIGVuY3J5cHRpb24gaXMgc3VwcG9ydGVkLiBNb3JlIGFuZCBtb3JlIHJlcXVp cmVtZW50cyBhcmUgY29taW5nIHVwIGZvciBwcm90ZWN0aW5nIHRoZSBwcml2YWN5IG9mIGxvY2F0 aW9uIGluZm9ybWF0aW9uLiBBbmQgc2luY2UgTWFwLVJlZ2lzdGVycyBjYXJyeSBSTE9DcyAoYW5k IHBvdGVudGlhbCBHZW8tQ29vcmRuYXRlcykgdGhhdCBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBw cm90ZWN0ZWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gRGlubw0KPj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gbGlzcCBtYWlsaW5nIGxpc3QN Cj4+Pj4+PiBsaXNwQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9saXNwDQo+Pj4+PiANCj4+Pj4+ICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gIGxpc3AgbWFpbGluZyBsaXN0DQo+Pj4+PiAg bGlzcEBpZXRmLm9yZw0KPj4+Pj4gIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbGlzcA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+PiANCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBsaXNwIG1h aWxpbmcgbGlzdA0KPj4gbGlzcEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9saXNwDQoNCg== From nobody Wed Dec 6 12:53:14 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9835126CF9 for ; Wed, 6 Dec 2017 12:53:12 -0800 (PST) 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_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 kmZWyZqeBseq for ; Wed, 6 Dec 2017 12:53:10 -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 96CFD1200FC for ; Wed, 6 Dec 2017 12:53:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 52F731C0742; Wed, 6 Dec 2017 12:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1512593590; bh=NiH9iM+YLyq9hnW9MgVpi1N2ZoLItQ4znuZi8OcbFjc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FjquH/susnIoefIVr/BErLRdMPzgI82+1DNmnadQFVzoC7aNcxdBT2kxR465feWAS Eh83HXNuXFYl/XM8WJ5Hn4iKyUyMbEt60c/b6QD8dsTJLkPL/xFgbBp2oUhd1GDpRl 2VTKt79ie8EEUOTrcFOLTTT2avTWOBhbHSUy3qQM= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 55D9B1CA7F6; Wed, 6 Dec 2017 12:53:09 -0800 (PST) To: "Johnson Leong (joleong)" Cc: Dino Farinacci , "lisp@ietf.org" References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> <52034017-790a-d040-c608-4004a6747dcd@joelhalpern.com> <97356212-F979-4263-894D-1BE7297675CC@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 6 Dec 2017 15:53:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <97356212-F979-4263-894D-1BE7297675CC@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 20:53:13 -0000 Sure, if the TCP queue backs up far enough that an effort to write by the application fails, the xTR can stop then. But until that point, it has no way of knowing whether the registration got through or not. TCP reliability != application delivery knowledge. There may well be good reasons for wanting to use TCP for this exchange. There often are. But the example you gave in this case is arguably a counter-example. Yours, Joel On 12/6/17 3:25 PM, Johnson Leong (joleong) wrote: > Joel, > > If there's flow control between the xTR and MS then the xTR wouldn't attempt to send the register if the MS cannot keep up. Depending on your implementation the xTR can stop building registration message until flow control is off with the MS. > > -Johnson > >> On Dec 6, 2017, at 12:17 PM, Joel M. Halpern wrote: >> >> >> Johnson, I think your example may cause more problems. >> I am not sure what you mean by "over-subscribed". >> But if the xTR sends a registration over TCP, and gets no answer, it is going to asume that it is properly registerd. If the registration has not been received due to the receiver not reading his TCP queue (because he is over-subscribed) that is a bad result. >> >> Yours, >> Joel >> >> On 12/6/17 2:44 PM, Johnson Leong (joleong) wrote: >>> Dino, >>> What we're trying to convey is that by using TCP it allows us to achieve reliability which significantly simplifies the code and error handling. One can achieve the same with UDP with ack and retry but it would be reimplementing what TCP already offers and this added complexity typically makes the code error prone. >>> Another benefit with TCP is congestion control, with UDP if we send a map-register and we don't get an ack then we retry. What if the MS is fully subscribed then this can lead to constant retry. You can impose backoff mechanism but ultimately this would affect convergence. >>> -Johnson >>>> On Dec 6, 2017, at 11:17 AM, Dino Farinacci wrote: >>>> >>>>> Dino, >>>>> >>>>>> LISP (the application), does not know that itself, the xTR, is in sync with the map-server. The packets can be in flight or being retransmitted due to loss. But if a Map-Register is sent with a nonce and no Map-Notify is returned the xTR knows for sure the two are in sync. >>>>> >>>>> An application (and LISP in this case) should always be able to know the state of a (TCP) socket that it has opened with a server. I’m not entirely sure why we would not want to use this information. >>>> >>>> All an app knows is the socket it has opened and any port it has bind()’ed to. It doesn’t know the connection state in terms of what packets have been sent and what has been ack’ed. There IS NOT enough information to do anything useful. >>>> >>>>> Besides, the reliable transport session does not invalidate the use of nonces and Map-Notifies as an indication that the MS has completely received the information, the just rely on the TCP state to know that nothing has changed. >>>> >>>> Right, so you have duplicate functionality. That isn’t efficient. >>>> >>>>>> I’d argue you may it worse. TCP does provide reliability but so does LISP itself. And the only reason the messages are periodic is because the spec said to send every 1 minute and timeout every 3 minutes. You can make it 1000 minutes and timeout every 3000 minutes. >>>>> >>>>> And this sounds as we would make the protocol very complicated to use (or code), as this would lead us to have to code/configure a specific registration pattern/logic for every use case that we want to support. Not saying we cannot, but it sounds like re-implementing TCP ;) >>>> >>>> You already have that code or you aren’t implementing Map-Register acks corrrectly. And changing a timer is really a constant change in the code. And what is spec’ed today in LISP proper is much simpler than TCP, it is not reimplementing it. >>>> >>>> But let's not drift from the point. The spec is written in a general way to solve only sending Map-Registers reliably. I suggest the text not mislead the reader to think this is a general new packet format for anything. >>>> >>>> When people judge which protocols they want to deploy, the people that do the due diligence will look at the protocol specs and see how much mechanism is designed in. And they make judgement decisions about using the protocol. >>>> >>>> I know of at least 2 vendors that said “I implemented pages 47-50 of the EVPN spec”. ;-) >>>> >>>> In LISP. we want to make sure what we spec is what is used and not ignored or considered optional. So please document the specific use-case you want to implement. And I’d suggest making the draft name draft-*-lisp-reliable-registers. >>>> >>>>>> LISP can pack all those EID-records in a Map-Register just like TCP does. And if you want per nonce acks, you pack them in IP packets <= 65535 bytes. TCP will have to o that as well. >>>>> >>>>> This is exactly the point, while LISP signaling allows it we don’t need to re-implement every TCP feature in LISP, as TCP can already provide it. >>>> >>>> You don’t need to. >>>> >>>>>> And guess what. What if there is an RLOC-change and you already gave the last one to TCP and can’t pull it back. If you were waiting for an ack and a new RLOC-change came in (during a lossy case), you wouldn’t have to retransmit the old information wastily. So keep the “retransmission queue” in LISP has its advantages. >>>>> >>>>> I’m not sure this is so easy. UDP, just like TCP uses the RLOC (IP) as part of the “session identifier” and the nonce is per-packet, not per-session. The moment the RLOC changes on the xTR, the MS does not know that the xTR is the same so we’d need a retransmission process. >>>> >>>> I’m not talking about when the xTR changes, I’m talking about an address on an interface on the same xTR changes since it was DHCP’ed to the xTR or behind a NAT. But for the LISP-MN case, the xTR is moving and its RLOCs are changing. You couple this with pubsub and the extra Map-Registers with old RLOCs has a ripple effect where then the Map-Server sends Map-Notify messages to all the subscribers, then followed by another set of Map-Notifies with the new RLOC-set. That is a lot of (unnecessary) messaging and processing. >>>> >>>> We have to think about the implications of any one draft on the ENTIRE LISP architecture. It must work efficiently as one holistic distributed system. >>>> >>>> Dino >>>> >>>>> >>>>> Marc >>>>> >>>>> On 12/5/17, 5:57 PM, "Dino Farinacci" wrote: >>>>> >>>>>> Dino, >>>>>> >>>>>> In addition to the previous arguments there are particular use-cases where the use of reliable transport simplified the deployment of LISP. >>>>> >>>>> I understand its advantages. I am examining its costs. >>>>> >>>>>> As an example, the moment we started scaling datacenters to support 10s of thousands of hosts, the use of a reliable transport helped a lot the management of scale: >>>>>> On one side it reduces the amount of signaling when nothing changes, since we use TCP state as an indication that xTRs and the MS are in sync and there is no need to deal with the optimization of the refresh logic (periodic or paced). >>>>> >>>>> LISP (the application), does not know that itself, the xTR, is in sync with the map-server. The packets can be in flight or being retransmitted due to loss. But if a Map-Register is sent with a nonce and no Map-Notify is returned the xTR knows for sure the two are in sync. >>>>> >>>>> I’d argue you may it worse. TCP does provide reliability but so does LISP itself. And the only reason the messages are periodic is because the spec said to send every 1 minute and timeout every 3 minutes. You can make it 1000 minutes and timeout every 3000 minutes. >>>>> >>>>> So let’s keep periiodic overhead, reliability, and staying in sync as separate issues. >>>>> >>>>>> On the other side, with reliable transport we offload the reliable delivery of information (and congestion control) >>>>> >>>>> I understand that. But you can’t say TCP is keeping you in sync, because you have removed detail from the applicationis. >>>>> >>>>>> from LISP to another process (TCP) that is entirely devoted and designed for this. For example, supporting events like mass VM moves relying purely on LISP based ACks became very challenging, as we ended up having to deal with congestion events related to the signaling load generated. The use of the reliable transport largely simplified the problem. >>>>> >>>>> Dino >>>>> >>>>>> >>>>>> Marc >>>>>> >>>>>> On 12/5/17, 12:06 PM, "lisp on behalf of Johnson Leong (joleong)" wrote: >>>>>> >>>>>> Hi Dino, >>>>>> >>>>>> A large portion of this draft discusses the state machine required for TCP and how to ensure the MS and xTR are in sync. We literally reuse the entire UDP map-register code, we just wrap that message around the LISP TCP header so there's a lot of code reuse. Finally, this draft is not meant to replace UDP register but in some of our use cases TCP would scale better to avoid the periodic registration. >>>>>> >>>>>> -Johnson >>>>>> >>>>>>> On Dec 5, 2017, at 10:52 AM, Dino Farinacci wrote: >>>>>>> >>>>>>>> registration protocol, that might be orthogonal to other transport-related mechanisms. In my experience this has proved to be very effective in scalability of large LISP deployments, especially with the increased volume of registration data. >>>>>>> >>>>>>> I agree it’s a point solution for registration. Then why did you need to have a general format. >>>>>>> >>>>>>> I could support this draft if it was simplified to spec how to use Map-Registers in TCP and nothing more. >>>>>>> >>>>>>> The only thing I would add is how to use TLS so encryption is supported. More and more requirements are coming up for protecting the privacy of location information. And since Map-Registers carry RLOCs (and potential Geo-Coordnates) that information needs to be protected. >>>>>>> >>>>>>> Dino >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > From nobody Wed Dec 6 13:56:24 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CAA127871 for ; Wed, 6 Dec 2017 13:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb8GEj_TMgUa for ; Wed, 6 Dec 2017 13:56:19 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363B0126B72 for ; Wed, 6 Dec 2017 13:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16090; q=dns/txt; s=iport; t=1512597379; x=1513806979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uxcvtMMAQ4cpRkBCVDpa1rYvS0C40JMOfaNeygLm5IU=; b=ZWtlO0+7ECN9YeymymEg1Ur4Vv6qZ0hLnKcUZLosaFJBacxGyc+Xpq6r XprRYUv8xqsidgDGt7D5fmeWOInNAOIoaA5yU6VtEd9gSluibz+8cGWyp YscxVrG5YFXeTTDeYh+vAAATeQujlQDM9jn3Ir8U3JpkR5Dc/RVLc+HZ5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQA1Ziha/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOL2ZxJweDe4ogjn2BVyaIdI4RFIIBChgLhRgCGoU6PxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUiAQEBAwEBASEROgsFCwIBCBIGAgImAgICHwYLFQIOAgQOBRuJc?= =?us-ascii?q?AMNCBCpE4InhzsNgxIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhE2BVoFoASk?= =?us-ascii?q?LgneCa4IeAhaDFTGCMgWSCJA4PQKQHIR7ghaGEYs0jT6IaAIRGQGBOQEfOYFOb?= =?us-ascii?q?xU6KgGBfoJPAxwZgU54hyUHgSyBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,369,1508803200"; d="scan'208";a="40718445" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2017 21:56:18 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vB6LuHKV026176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 21:56:18 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 15:56:17 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1320.000; Wed, 6 Dec 2017 15:56:17 -0600 From: "Johnson Leong (joleong)" To: "Joel M. Halpern" CC: Dino Farinacci , "lisp@ietf.org" Thread-Topic: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption Thread-Index: AQHTbeo9EtGVHwDVv0CpzXF7TtVp96M1cgIAgAAI1ACAAAI0gIAAFL8AgABIZYCAABmDAIAA9doAgAAs4gCAAAeGAIAACWMAgAACRgCAAAeUgIAAEaiA Date: Wed, 6 Dec 2017 21:56:17 +0000 Message-ID: <794A7337-7434-4520-807C-11C13C617A62@cisco.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> <52034017-790a-d040-c608-4004a6747dcd@joelhalpern.com> <97356212-F979-4263-894D-1BE7297675CC@cisco.com> In-Reply-To: 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.24.83.37] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 21:56:22 -0000 Sm9lbCwNCg0KSSBhZ3JlZSBUQ1AgcmVsaWFiaWxpdHkgIT0gYXBwbGljYXRpb24gZGVsaXZlcnkg a25vd2xlZGdlIGJ1dCBUQ1AgcmVsaWFiaWxpdHkgZG9lcyBlbnN1cmUgdGhlIG1lc3NhZ2Ugd2ls bCAqZXZlbnR1YWxseSogZ2V0IGRlbGl2ZXJlZCB0byB0aGUgYXBwbGljYXRpb24gKHVubGVzcyB0 aGVyZSdzIGFuIGFwcGxpY2F0aW9uIGJ1Zykgd2l0aG91dCBhZGRpdGlvbmFsIGFwcGxpY2F0aW9u IHJlbGlhYmlsaXR5IGxvZ2ljLiAgSSBhbSBzdXJlIHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhh dCByZXF1aXJlL2V4cGVjdCB0aGUgQUNLIHRvIGJlIHNlbnQgZnJvbSB0aGUgYXBwbGljYXRpb24g bGF5ZXIgdG8gYXZvaWQgdGhlIHRpbWUgZGVsdGEgYmV0d2VlbiB0cmFuc3BvcnQgcmVjZXB0aW9u IGFuZCBhcHBsaWNhdGlvbiByZWNlcHRpb24gc2VlbiBpbiBUQ1AgYnV0IEkgZG9uJ3QgdGhpbmsg TElTUCBuZWVkcyB0aGF0IGxldmVsIG9mIGRpZmZlcmVudGlhdGlvbi4NCg0KTXkgcHJldmlvdXMg ZXhhbXBsZSBzaW1wbHkgc3RhdGVzIHRoYXQgd2l0aCBjb25nZXN0aW9uIGNvbnRyb2wgdGhlIEVU UiB3b3VsZCBub3QgZW5kIHVwIGtlZXAgcmUtdHggaWYgdGhlIE1TIGlzIGNvbmdlc3RlZC4gIElu IGEgc2NhbGUgc2NlbmFyaW8gcmUtdHggY2FuIHBvdGVudGlhbGx5IGNhdXNlIHRoZSBzeXN0ZW0g dG8gc3R1Y2sgaW4gdGhpcyBzdGF0ZSBpbmRlZmluaXRlbHkuDQoNCi1Kb2huc29uDQoNCj4gT24g RGVjIDYsIDIwMTcsIGF0IDEyOjUzIFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVy bi5jb20+IHdyb3RlOg0KPiANCj4gU3VyZSwgaWYgdGhlIFRDUCBxdWV1ZSBiYWNrcyB1cCBmYXIg ZW5vdWdoIHRoYXQgYW4gZWZmb3J0IHRvIHdyaXRlIGJ5IHRoZSBhcHBsaWNhdGlvbiBmYWlscywg dGhlIHhUUiBjYW4gc3RvcCB0aGVuLiAgQnV0IHVudGlsIHRoYXQgcG9pbnQsIGl0IGhhcyBubyB3 YXkgb2Yga25vd2luZyB3aGV0aGVyIHRoZSByZWdpc3RyYXRpb24gZ290IHRocm91Z2ggb3Igbm90 LiAgVENQIHJlbGlhYmlsaXR5ICE9IGFwcGxpY2F0aW9uIGRlbGl2ZXJ5IGtub3dsZWRnZS4NCj4g DQo+IFRoZXJlIG1heSB3ZWxsIGJlIGdvb2QgcmVhc29ucyBmb3Igd2FudGluZyB0byB1c2UgVENQ IGZvciB0aGlzIGV4Y2hhbmdlLiAgVGhlcmUgb2Z0ZW4gYXJlLiAgQnV0IHRoZSBleGFtcGxlIHlv dSBnYXZlIGluIHRoaXMgY2FzZSBpcyBhcmd1YWJseSBhIGNvdW50ZXItZXhhbXBsZS4NCj4gDQo+ IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBPbiAxMi82LzE3IDM6MjUgUE0sIEpvaG5zb24gTGVvbmcg KGpvbGVvbmcpIHdyb3RlOg0KPj4gSm9lbCwNCj4+IElmIHRoZXJlJ3MgZmxvdyBjb250cm9sIGJl dHdlZW4gdGhlIHhUUiBhbmQgTVMgdGhlbiB0aGUgeFRSIHdvdWxkbid0IGF0dGVtcHQgdG8gc2Vu ZCB0aGUgcmVnaXN0ZXIgaWYgdGhlIE1TIGNhbm5vdCBrZWVwIHVwLiAgRGVwZW5kaW5nIG9uIHlv dXIgaW1wbGVtZW50YXRpb24gdGhlIHhUUiBjYW4gc3RvcCBidWlsZGluZyByZWdpc3RyYXRpb24g bWVzc2FnZSB1bnRpbCBmbG93IGNvbnRyb2wgaXMgb2ZmIHdpdGggdGhlIE1TLg0KPj4gLUpvaG5z b24NCj4+PiBPbiBEZWMgNiwgMjAxNywgYXQgMTI6MTcgUE0sIEpvZWwgTS4gSGFscGVybiA8am1o QGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gPHNwZWFraW5nIHdpdGhvdXQgaGF0 cy4+DQo+Pj4gSm9obnNvbiwgSSB0aGluayB5b3VyIGV4YW1wbGUgbWF5IGNhdXNlIG1vcmUgcHJv YmxlbXMuDQo+Pj4gSSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJvdmVyLXN1YnNjcmli ZWQiLg0KPj4+IEJ1dCBpZiB0aGUgeFRSIHNlbmRzIGEgcmVnaXN0cmF0aW9uIG92ZXIgVENQLCBh bmQgZ2V0cyBubyBhbnN3ZXIsIGl0IGlzIGdvaW5nIHRvIGFzdW1lIHRoYXQgaXQgaXMgcHJvcGVy bHkgcmVnaXN0ZXJkLiAgSWYgdGhlIHJlZ2lzdHJhdGlvbiBoYXMgbm90IGJlZW4gcmVjZWl2ZWQg ZHVlIHRvIHRoZSByZWNlaXZlciBub3QgcmVhZGluZyBoaXMgVENQIHF1ZXVlIChiZWNhdXNlIGhl IGlzIG92ZXItc3Vic2NyaWJlZCkgdGhhdCBpcyBhIGJhZCByZXN1bHQuDQo+Pj4gDQo+Pj4gWW91 cnMsDQo+Pj4gSm9lbA0KPj4+IA0KPj4+IE9uIDEyLzYvMTcgMjo0NCBQTSwgSm9obnNvbiBMZW9u ZyAoam9sZW9uZykgd3JvdGU6DQo+Pj4+IERpbm8sDQo+Pj4+IFdoYXQgd2UncmUgdHJ5aW5nIHRv IGNvbnZleSBpcyB0aGF0IGJ5IHVzaW5nIFRDUCBpdCBhbGxvd3MgdXMgdG8gYWNoaWV2ZSByZWxp YWJpbGl0eSB3aGljaCBzaWduaWZpY2FudGx5IHNpbXBsaWZpZXMgdGhlIGNvZGUgYW5kIGVycm9y IGhhbmRsaW5nLiAgT25lIGNhbiBhY2hpZXZlIHRoZSBzYW1lIHdpdGggVURQIHdpdGggYWNrIGFu ZCByZXRyeSBidXQgaXQgd291bGQgYmUgcmVpbXBsZW1lbnRpbmcgd2hhdCBUQ1AgYWxyZWFkeSBv ZmZlcnMgYW5kIHRoaXMgYWRkZWQgY29tcGxleGl0eSB0eXBpY2FsbHkgbWFrZXMgdGhlIGNvZGUg ZXJyb3IgcHJvbmUuDQo+Pj4+IEFub3RoZXIgYmVuZWZpdCB3aXRoIFRDUCBpcyBjb25nZXN0aW9u IGNvbnRyb2wsIHdpdGggVURQIGlmIHdlIHNlbmQgYSBtYXAtcmVnaXN0ZXIgYW5kIHdlIGRvbid0 IGdldCBhbiBhY2sgdGhlbiB3ZSByZXRyeS4gIFdoYXQgaWYgdGhlIE1TIGlzIGZ1bGx5IHN1YnNj cmliZWQgdGhlbiB0aGlzIGNhbiBsZWFkIHRvIGNvbnN0YW50IHJldHJ5LiAgWW91IGNhbiBpbXBv c2UgYmFja29mZiBtZWNoYW5pc20gYnV0IHVsdGltYXRlbHkgdGhpcyB3b3VsZCBhZmZlY3QgY29u dmVyZ2VuY2UuDQo+Pj4+IC1Kb2huc29uDQo+Pj4+PiBPbiBEZWMgNiwgMjAxNywgYXQgMTE6MTcg QU0sIERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiB3cm90ZToNCj4+Pj4+IA0K Pj4+Pj4+IERpbm8sDQo+Pj4+Pj4gDQo+Pj4+Pj4+ICBMSVNQICh0aGUgYXBwbGljYXRpb24pLCBk b2VzIG5vdCBrbm93IHRoYXQgaXRzZWxmLCB0aGUgeFRSLCBpcyBpbiBzeW5jIHdpdGggdGhlIG1h cC1zZXJ2ZXIuIFRoZSBwYWNrZXRzIGNhbiBiZSBpbiBmbGlnaHQgb3IgYmVpbmcgcmV0cmFuc21p dHRlZCBkdWUgdG8gbG9zcy4gQnV0IGlmIGEgTWFwLVJlZ2lzdGVyIGlzIHNlbnQgd2l0aCBhIG5v bmNlIGFuZCBubyBNYXAtTm90aWZ5IGlzIHJldHVybmVkIHRoZSB4VFIga25vd3MgZm9yIHN1cmUg dGhlIHR3byBhcmUgaW4gc3luYy4NCj4+Pj4+PiANCj4+Pj4+PiBBbiBhcHBsaWNhdGlvbiAoYW5k IExJU1AgaW4gdGhpcyBjYXNlKSBzaG91bGQgYWx3YXlzIGJlIGFibGUgdG8ga25vdyB0aGUgc3Rh dGUgb2YgYSAoVENQKSBzb2NrZXQgdGhhdCBpdCBoYXMgb3BlbmVkIHdpdGggYSBzZXJ2ZXIuIEni gJltIG5vdCBlbnRpcmVseSBzdXJlIHdoeSB3ZSB3b3VsZCBub3Qgd2FudCB0byB1c2UgdGhpcyBp bmZvcm1hdGlvbi4NCj4+Pj4+IA0KPj4+Pj4gQWxsIGFuIGFwcCBrbm93cyBpcyB0aGUgc29ja2V0 IGl0IGhhcyBvcGVuZWQgYW5kIGFueSBwb3J0IGl0IGhhcyBiaW5kKCnigJllZCB0by4gSXQgZG9l c27igJl0IGtub3cgdGhlIGNvbm5lY3Rpb24gc3RhdGUgaW4gdGVybXMgb2Ygd2hhdCBwYWNrZXRz IGhhdmUgYmVlbiBzZW50IGFuZCB3aGF0IGhhcyBiZWVuIGFja+KAmWVkLiBUaGVyZSBJUyBOT1Qg ZW5vdWdoIGluZm9ybWF0aW9uIHRvIGRvIGFueXRoaW5nIHVzZWZ1bC4NCj4+Pj4+IA0KPj4+Pj4+ IEJlc2lkZXMsIHRoZSByZWxpYWJsZSB0cmFuc3BvcnQgc2Vzc2lvbiBkb2VzIG5vdCBpbnZhbGlk YXRlIHRoZSB1c2Ugb2Ygbm9uY2VzIGFuZCBNYXAtTm90aWZpZXMgYXMgYW4gaW5kaWNhdGlvbiB0 aGF0IHRoZSBNUyBoYXMgY29tcGxldGVseSByZWNlaXZlZCB0aGUgaW5mb3JtYXRpb24sIHRoZSBq dXN0IHJlbHkgb24gdGhlIFRDUCBzdGF0ZSB0byBrbm93IHRoYXQgbm90aGluZyBoYXMgY2hhbmdl ZC4NCj4+Pj4+IA0KPj4+Pj4gUmlnaHQsIHNvIHlvdSBoYXZlIGR1cGxpY2F0ZSBmdW5jdGlvbmFs aXR5LiBUaGF0IGlzbuKAmXQgZWZmaWNpZW50Lg0KPj4+Pj4gDQo+Pj4+Pj4+IEnigJlkIGFyZ3Vl IHlvdSBtYXkgaXQgd29yc2UuIFRDUCBkb2VzIHByb3ZpZGUgcmVsaWFiaWxpdHkgYnV0IHNvIGRv ZXMgTElTUCBpdHNlbGYuIEFuZCB0aGUgb25seSByZWFzb24gdGhlIG1lc3NhZ2VzIGFyZSBwZXJp b2RpYyBpcyBiZWNhdXNlIHRoZSBzcGVjIHNhaWQgdG8gc2VuZCBldmVyeSAxIG1pbnV0ZSBhbmQg dGltZW91dCBldmVyeSAzIG1pbnV0ZXMuIFlvdSBjYW4gbWFrZSBpdCAxMDAwIG1pbnV0ZXMgYW5k IHRpbWVvdXQgZXZlcnkgMzAwMCBtaW51dGVzLg0KPj4+Pj4+IA0KPj4+Pj4+IEFuZCB0aGlzIHNv dW5kcyBhcyB3ZSB3b3VsZCBtYWtlIHRoZSBwcm90b2NvbCB2ZXJ5IGNvbXBsaWNhdGVkIHRvIHVz ZSAob3IgY29kZSksIGFzIHRoaXMgd291bGQgbGVhZCB1cyB0byBoYXZlIHRvIGNvZGUvY29uZmln dXJlIGEgc3BlY2lmaWMgcmVnaXN0cmF0aW9uIHBhdHRlcm4vbG9naWMgZm9yIGV2ZXJ5IHVzZSBj YXNlIHRoYXQgd2Ugd2FudCB0byBzdXBwb3J0LiBOb3Qgc2F5aW5nIHdlIGNhbm5vdCwgYnV0IGl0 IHNvdW5kcyBsaWtlIHJlLWltcGxlbWVudGluZyBUQ1AgOykNCj4+Pj4+IA0KPj4+Pj4gWW91IGFs cmVhZHkgaGF2ZSB0aGF0IGNvZGUgb3IgeW91IGFyZW7igJl0IGltcGxlbWVudGluZyBNYXAtUmVn aXN0ZXIgYWNrcyBjb3JycmVjdGx5LiBBbmQgY2hhbmdpbmcgYSB0aW1lciBpcyByZWFsbHkgYSBj b25zdGFudCBjaGFuZ2UgaW4gdGhlIGNvZGUuIEFuZCB3aGF0IGlzIHNwZWPigJllZCB0b2RheSBp biBMSVNQIHByb3BlciBpcyBtdWNoIHNpbXBsZXIgdGhhbiBUQ1AsIGl0IGlzIG5vdCByZWltcGxl bWVudGluZyBpdC4NCj4+Pj4+IA0KPj4+Pj4gQnV0IGxldCdzIG5vdCBkcmlmdCBmcm9tIHRoZSBw b2ludC4gVGhlIHNwZWMgaXMgd3JpdHRlbiBpbiBhIGdlbmVyYWwgd2F5IHRvIHNvbHZlIG9ubHkg c2VuZGluZyBNYXAtUmVnaXN0ZXJzIHJlbGlhYmx5LiBJIHN1Z2dlc3QgdGhlIHRleHQgbm90IG1p c2xlYWQgdGhlIHJlYWRlciB0byB0aGluayB0aGlzIGlzIGEgZ2VuZXJhbCBuZXcgcGFja2V0IGZv cm1hdCBmb3IgYW55dGhpbmcuDQo+Pj4+PiANCj4+Pj4+IFdoZW4gcGVvcGxlIGp1ZGdlIHdoaWNo IHByb3RvY29scyB0aGV5IHdhbnQgdG8gZGVwbG95LCB0aGUgcGVvcGxlIHRoYXQgZG8gdGhlIGR1 ZSBkaWxpZ2VuY2Ugd2lsbCBsb29rIGF0IHRoZSBwcm90b2NvbCBzcGVjcyBhbmQgc2VlIGhvdyBt dWNoIG1lY2hhbmlzbSBpcyBkZXNpZ25lZCBpbi4gQW5kIHRoZXkgbWFrZSBqdWRnZW1lbnQgZGVj aXNpb25zIGFib3V0IHVzaW5nIHRoZSBwcm90b2NvbC4NCj4+Pj4+IA0KPj4+Pj4gSSBrbm93IG9m IGF0IGxlYXN0IDIgdmVuZG9ycyB0aGF0IHNhaWQg4oCcSSBpbXBsZW1lbnRlZCBwYWdlcyA0Ny01 MCBvZiB0aGUgRVZQTiBzcGVj4oCdLiAgOy0pDQo+Pj4+PiANCj4+Pj4+IEluIExJU1AuIHdlIHdh bnQgdG8gbWFrZSBzdXJlIHdoYXQgd2Ugc3BlYyBpcyB3aGF0IGlzIHVzZWQgYW5kIG5vdCBpZ25v cmVkIG9yIGNvbnNpZGVyZWQgb3B0aW9uYWwuIFNvIHBsZWFzZSBkb2N1bWVudCB0aGUgc3BlY2lm aWMgdXNlLWNhc2UgeW91IHdhbnQgdG8gaW1wbGVtZW50LiBBbmQgSeKAmWQgc3VnZ2VzdCBtYWtp bmcgdGhlIGRyYWZ0IG5hbWUgZHJhZnQtKi1saXNwLXJlbGlhYmxlLXJlZ2lzdGVycy4NCj4+Pj4+ IA0KPj4+Pj4+PiBMSVNQIGNhbiBwYWNrIGFsbCB0aG9zZSBFSUQtcmVjb3JkcyBpbiBhIE1hcC1S ZWdpc3RlciBqdXN0IGxpa2UgVENQIGRvZXMuIEFuZCBpZiB5b3Ugd2FudCBwZXIgbm9uY2UgYWNr cywgeW91IHBhY2sgdGhlbSBpbiBJUCBwYWNrZXRzIDw9IDY1NTM1IGJ5dGVzLiBUQ1Agd2lsbCBo YXZlIHRvIG8gdGhhdCBhcyB3ZWxsLg0KPj4+Pj4+IA0KPj4+Pj4+IFRoaXMgaXMgZXhhY3RseSB0 aGUgcG9pbnQsIHdoaWxlIExJU1Agc2lnbmFsaW5nIGFsbG93cyBpdCB3ZSBkb27igJl0IG5lZWQg dG8gcmUtaW1wbGVtZW50IGV2ZXJ5IFRDUCBmZWF0dXJlIGluIExJU1AsIGFzIFRDUCBjYW4gYWxy ZWFkeSBwcm92aWRlIGl0Lg0KPj4+Pj4gDQo+Pj4+PiBZb3UgZG9u4oCZdCBuZWVkIHRvLg0KPj4+ Pj4gDQo+Pj4+Pj4+IEFuZCBndWVzcyB3aGF0LiBXaGF0IGlmIHRoZXJlIGlzIGFuIFJMT0MtY2hh bmdlIGFuZCB5b3UgYWxyZWFkeSBnYXZlIHRoZSBsYXN0IG9uZSB0byBUQ1AgYW5kIGNhbuKAmXQg cHVsbCBpdCBiYWNrLiBJZiB5b3Ugd2VyZSB3YWl0aW5nIGZvciBhbiBhY2sgYW5kIGEgbmV3IFJM T0MtY2hhbmdlIGNhbWUgaW4gKGR1cmluZyBhIGxvc3N5IGNhc2UpLCB5b3Ugd291bGRu4oCZdCBo YXZlIHRvIHJldHJhbnNtaXQgdGhlIG9sZCBpbmZvcm1hdGlvbiB3YXN0aWx5LiBTbyBrZWVwIHRo ZSDigJxyZXRyYW5zbWlzc2lvbiBxdWV1ZeKAnSBpbiBMSVNQIGhhcyBpdHMgYWR2YW50YWdlcy4N Cj4+Pj4+PiANCj4+Pj4+PiBJ4oCZbSBub3Qgc3VyZSB0aGlzIGlzIHNvIGVhc3kuIFVEUCwganVz dCBsaWtlIFRDUCB1c2VzIHRoZSBSTE9DIChJUCkgYXMgcGFydCBvZiB0aGUg4oCcc2Vzc2lvbiBp ZGVudGlmaWVy4oCdIGFuZCB0aGUgbm9uY2UgaXMgcGVyLXBhY2tldCwgbm90IHBlci1zZXNzaW9u LiBUaGUgbW9tZW50IHRoZSBSTE9DIGNoYW5nZXMgb24gdGhlIHhUUiwgdGhlIE1TIGRvZXMgbm90 IGtub3cgdGhhdCB0aGUgeFRSIGlzIHRoZSBzYW1lIHNvIHdl4oCZZCBuZWVkIGEgcmV0cmFuc21p c3Npb24gcHJvY2Vzcy4NCj4+Pj4+IA0KPj4+Pj4gSeKAmW0gbm90IHRhbGtpbmcgYWJvdXQgd2hl biB0aGUgeFRSIGNoYW5nZXMsIEnigJltIHRhbGtpbmcgYWJvdXQgYW4gYWRkcmVzcyBvbiBhbiBp bnRlcmZhY2Ugb24gdGhlIHNhbWUgeFRSIGNoYW5nZXMgc2luY2UgaXQgd2FzIERIQ1DigJllZCB0 byB0aGUgeFRSIG9yIGJlaGluZCBhIE5BVC4gQnV0IGZvciB0aGUgTElTUC1NTiBjYXNlLCB0aGUg eFRSIGlzIG1vdmluZyBhbmQgaXRzIFJMT0NzIGFyZSBjaGFuZ2luZy4gWW91IGNvdXBsZSB0aGlz IHdpdGggcHVic3ViIGFuZCB0aGUgZXh0cmEgTWFwLVJlZ2lzdGVycyB3aXRoIG9sZCBSTE9DcyBo YXMgYSByaXBwbGUgZWZmZWN0IHdoZXJlIHRoZW4gdGhlIE1hcC1TZXJ2ZXIgc2VuZHMgTWFwLU5v dGlmeSBtZXNzYWdlcyB0byBhbGwgdGhlIHN1YnNjcmliZXJzLCB0aGVuIGZvbGxvd2VkIGJ5IGFu b3RoZXIgc2V0IG9mIE1hcC1Ob3RpZmllcyB3aXRoIHRoZSBuZXcgUkxPQy1zZXQuIFRoYXQgaXMg YSBsb3Qgb2YgKHVubmVjZXNzYXJ5KSBtZXNzYWdpbmcgYW5kIHByb2Nlc3NpbmcuDQo+Pj4+PiAN Cj4+Pj4+IFdlIGhhdmUgdG8gdGhpbmsgYWJvdXQgdGhlIGltcGxpY2F0aW9ucyBvZiBhbnkgb25l IGRyYWZ0IG9uIHRoZSBFTlRJUkUgTElTUCBhcmNoaXRlY3R1cmUuIEl0IG11c3Qgd29yayBlZmZp Y2llbnRseSBhcyBvbmUgaG9saXN0aWMgZGlzdHJpYnV0ZWQgc3lzdGVtLg0KPj4+Pj4gDQo+Pj4+ PiBEaW5vDQo+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBNYXJjDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24g MTIvNS8xNywgNTo1NyBQTSwgIkRpbm8gRmFyaW5hY2NpIiA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4g d3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4+IERpbm8sDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJbiBhZGRp dGlvbiB0byB0aGUgcHJldmlvdXMgYXJndW1lbnRzIHRoZXJlIGFyZSBwYXJ0aWN1bGFyIHVzZS1j YXNlcyB3aGVyZSB0aGUgdXNlIG9mIHJlbGlhYmxlIHRyYW5zcG9ydCBzaW1wbGlmaWVkIHRoZSBk ZXBsb3ltZW50IG9mIExJU1AuDQo+Pj4+Pj4gDQo+Pj4+Pj4gICBJIHVuZGVyc3RhbmQgaXRzIGFk dmFudGFnZXMuIEkgYW0gZXhhbWluaW5nIGl0cyBjb3N0cy4NCj4+Pj4+PiANCj4+Pj4+Pj4gQXMg YW4gZXhhbXBsZSwgdGhlIG1vbWVudCB3ZSBzdGFydGVkIHNjYWxpbmcgZGF0YWNlbnRlcnMgdG8g c3VwcG9ydCAxMHMgb2YgdGhvdXNhbmRzIG9mIGhvc3RzLCB0aGUgdXNlIG9mIGEgcmVsaWFibGUg dHJhbnNwb3J0IGhlbHBlZCBhIGxvdCB0aGUgbWFuYWdlbWVudCBvZiBzY2FsZToNCj4+Pj4+Pj4g T24gb25lIHNpZGUgaXQgcmVkdWNlcyB0aGUgYW1vdW50IG9mIHNpZ25hbGluZyB3aGVuIG5vdGhp bmcgY2hhbmdlcywgc2luY2Ugd2UgdXNlIFRDUCBzdGF0ZSBhcyBhbiBpbmRpY2F0aW9uIHRoYXQg eFRScyBhbmQgdGhlIE1TIGFyZSBpbiBzeW5jIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIGRlYWwg d2l0aCB0aGUgb3B0aW1pemF0aW9uIG9mIHRoZSByZWZyZXNoIGxvZ2ljIChwZXJpb2RpYyBvciBw YWNlZCkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gICBMSVNQICh0aGUgYXBwbGljYXRpb24pLCBkb2VzIG5v dCBrbm93IHRoYXQgaXRzZWxmLCB0aGUgeFRSLCBpcyBpbiBzeW5jIHdpdGggdGhlIG1hcC1zZXJ2 ZXIuIFRoZSBwYWNrZXRzIGNhbiBiZSBpbiBmbGlnaHQgb3IgYmVpbmcgcmV0cmFuc21pdHRlZCBk dWUgdG8gbG9zcy4gQnV0IGlmIGEgTWFwLVJlZ2lzdGVyIGlzIHNlbnQgd2l0aCBhIG5vbmNlIGFu ZCBubyBNYXAtTm90aWZ5IGlzIHJldHVybmVkIHRoZSB4VFIga25vd3MgZm9yIHN1cmUgdGhlIHR3 byBhcmUgaW4gc3luYy4NCj4+Pj4+PiANCj4+Pj4+PiAgIEnigJlkIGFyZ3VlIHlvdSBtYXkgaXQg d29yc2UuIFRDUCBkb2VzIHByb3ZpZGUgcmVsaWFiaWxpdHkgYnV0IHNvIGRvZXMgTElTUCBpdHNl bGYuIEFuZCB0aGUgb25seSByZWFzb24gdGhlIG1lc3NhZ2VzIGFyZSBwZXJpb2RpYyBpcyBiZWNh dXNlIHRoZSBzcGVjIHNhaWQgdG8gc2VuZCBldmVyeSAxIG1pbnV0ZSBhbmQgdGltZW91dCBldmVy eSAzIG1pbnV0ZXMuIFlvdSBjYW4gbWFrZSBpdCAxMDAwIG1pbnV0ZXMgYW5kIHRpbWVvdXQgZXZl cnkgMzAwMCBtaW51dGVzLg0KPj4+Pj4+IA0KPj4+Pj4+ICAgU28gbGV04oCZcyBrZWVwIHBlcmlp b2RpYyBvdmVyaGVhZCwgcmVsaWFiaWxpdHksIGFuZCBzdGF5aW5nIGluIHN5bmMgYXMgc2VwYXJh dGUgaXNzdWVzLg0KPj4+Pj4+IA0KPj4+Pj4+PiBPbiB0aGUgb3RoZXIgc2lkZSwgd2l0aCByZWxp YWJsZSB0cmFuc3BvcnQgd2Ugb2ZmbG9hZCB0aGUgcmVsaWFibGUgZGVsaXZlcnkgb2YgaW5mb3Jt YXRpb24gKGFuZCBjb25nZXN0aW9uIGNvbnRyb2wpDQo+Pj4+Pj4gDQo+Pj4+Pj4gICBJIHVuZGVy c3RhbmQgdGhhdC4gQnV0IHlvdSBjYW7igJl0IHNheSBUQ1AgaXMga2VlcGluZyB5b3UgaW4gc3lu YywgYmVjYXVzZSB5b3UgaGF2ZSByZW1vdmVkIGRldGFpbCBmcm9tIHRoZSBhcHBsaWNhdGlvbmlz Lg0KPj4+Pj4+IA0KPj4+Pj4+PiBmcm9tIExJU1AgdG8gYW5vdGhlciBwcm9jZXNzIChUQ1ApIHRo YXQgaXMgZW50aXJlbHkgZGV2b3RlZCBhbmQgZGVzaWduZWQgZm9yIHRoaXMuIEZvciBleGFtcGxl LCBzdXBwb3J0aW5nIGV2ZW50cyBsaWtlIG1hc3MgVk0gbW92ZXMgcmVseWluZyBwdXJlbHkgb24g TElTUCBiYXNlZCBBQ2tzIGJlY2FtZSB2ZXJ5IGNoYWxsZW5naW5nLCBhcyB3ZSBlbmRlZCB1cCBo YXZpbmcgdG8gZGVhbCB3aXRoIGNvbmdlc3Rpb24gZXZlbnRzIHJlbGF0ZWQgdG8gdGhlIHNpZ25h bGluZyBsb2FkIGdlbmVyYXRlZC4gVGhlIHVzZSBvZiB0aGUgcmVsaWFibGUgdHJhbnNwb3J0IGxh cmdlbHkgc2ltcGxpZmllZCB0aGUgcHJvYmxlbS4NCj4+Pj4+PiANCj4+Pj4+PiBEaW5vDQo+Pj4+ Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBNYXJjDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBPbiAxMi81LzE3 LCAxMjowNiBQTSwgImxpc3Agb24gYmVoYWxmIG9mIEpvaG5zb24gTGVvbmcgKGpvbGVvbmcpIiA8 bGlzcC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqb2xlb25nQGNpc2NvLmNvbT4gd3Jv dGU6DQo+Pj4+Pj4+IA0KPj4+Pj4+PiAgSGkgRGlubywNCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICBBIGxh cmdlIHBvcnRpb24gb2YgdGhpcyBkcmFmdCBkaXNjdXNzZXMgdGhlIHN0YXRlIG1hY2hpbmUgcmVx dWlyZWQgZm9yIFRDUCBhbmQgaG93IHRvIGVuc3VyZSB0aGUgTVMgYW5kIHhUUiBhcmUgaW4gc3lu Yy4gIFdlIGxpdGVyYWxseSByZXVzZSB0aGUgZW50aXJlIFVEUCBtYXAtcmVnaXN0ZXIgY29kZSwg d2UganVzdCB3cmFwIHRoYXQgbWVzc2FnZSBhcm91bmQgdGhlIExJU1AgVENQIGhlYWRlciBzbyB0 aGVyZSdzIGEgbG90IG9mIGNvZGUgcmV1c2UuICBGaW5hbGx5LCB0aGlzIGRyYWZ0IGlzIG5vdCBt ZWFudCB0byByZXBsYWNlIFVEUCByZWdpc3RlciBidXQgaW4gc29tZSBvZiBvdXIgdXNlIGNhc2Vz IFRDUCB3b3VsZCBzY2FsZSBiZXR0ZXIgdG8gYXZvaWQgdGhlIHBlcmlvZGljIHJlZ2lzdHJhdGlv bi4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICAtSm9obnNvbg0KPj4+Pj4+PiANCj4+Pj4+Pj4+IE9uIERl YyA1LCAyMDE3LCBhdCAxMDo1MiBBTSwgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5j b20+IHdyb3RlOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gcmVnaXN0cmF0aW9uIHByb3RvY29sLCB0 aGF0IG1pZ2h0IGJlIG9ydGhvZ29uYWwgdG8gb3RoZXIgdHJhbnNwb3J0LXJlbGF0ZWQgbWVjaGFu aXNtcy4gSW4gbXkgZXhwZXJpZW5jZSB0aGlzIGhhcyBwcm92ZWQgdG8gYmUgdmVyeSBlZmZlY3Rp dmUgaW4gc2NhbGFiaWxpdHkgb2YgbGFyZ2UgTElTUCBkZXBsb3ltZW50cywgZXNwZWNpYWxseSB3 aXRoIHRoZSBpbmNyZWFzZWQgdm9sdW1lIG9mIHJlZ2lzdHJhdGlvbiBkYXRhLg0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiBJIGFncmVlIGl04oCZcyBhIHBvaW50IHNvbHV0aW9uIGZvciByZWdpc3RyYXRp b24uIFRoZW4gd2h5IGRpZCB5b3UgbmVlZCB0byBoYXZlIGEgZ2VuZXJhbCBmb3JtYXQuDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IEkgY291bGQgc3VwcG9ydCB0aGlzIGRyYWZ0IGlmIGl0IHdhcyBzaW1w bGlmaWVkIHRvIHNwZWMgaG93IHRvIHVzZSBNYXAtUmVnaXN0ZXJzIGluIFRDUCBhbmQgbm90aGlu ZyBtb3JlLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGUgb25seSB0aGluZyBJIHdvdWxkIGFkZCBp cyBob3cgdG8gdXNlIFRMUyBzbyBlbmNyeXB0aW9uIGlzIHN1cHBvcnRlZC4gTW9yZSBhbmQgbW9y ZSByZXF1aXJlbWVudHMgYXJlIGNvbWluZyB1cCBmb3IgcHJvdGVjdGluZyB0aGUgcHJpdmFjeSBv ZiBsb2NhdGlvbiBpbmZvcm1hdGlvbi4gQW5kIHNpbmNlIE1hcC1SZWdpc3RlcnMgY2FycnkgUkxP Q3MgKGFuZCBwb3RlbnRpYWwgR2VvLUNvb3JkbmF0ZXMpIHRoYXQgaW5mb3JtYXRpb24gbmVlZHMg dG8gYmUgcHJvdGVjdGVkLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBEaW5vDQo+Pj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gbGlz cCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+IGxpc3BAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KPj4+Pj4+PiANCj4+Pj4+Pj4gIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+ICBs aXNwIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiAgbGlzcEBpZXRmLm9yZw0KPj4+Pj4+PiAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBsaXNwIG1haWxpbmcgbGlzdA0K Pj4+PiBsaXNwQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbGlzcA0KDQo= From nobody Wed Dec 6 17:59:42 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A80C1279EB for ; Wed, 6 Dec 2017 17:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIWEQEIFB6eZ for ; Wed, 6 Dec 2017 17:59:38 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4D51250B8 for ; Wed, 6 Dec 2017 17:59:38 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id k134so3355891pga.3 for ; Wed, 06 Dec 2017 17:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UmkP5kgbcV5dZf4KaoMusJ98ux3N5DeAvYu9rDMG594=; b=BqjtCxt9Ty6qeTcogUuPcaCTnMvZMHnDPnKUAQ7ihuZtF6ynt9cjZ5KU6KC+vBaqCh ZY2h8L6MDR5Lr/LzI3HWgpAbp/FS8S5KFPZRJAlCzACbtDzYBEgipllUXRMUOlk7iy// +PFq9+Dxxbul6QdNHLBgNulry6bfpLNsJNwQrtX4Kr3bD7pnHsPiEYNqryaf2WARJls6 XV2lwZVLS7P3yMvfOHqhUOSmH2liRyZVP+T7eVhAUwBhS3Z0NS/UwQ4Mu6icBYkvsuj8 YKAGs4uYH9DC/LH7xSx4BDR64fiiUYzo4U4kJhxQm60J0U4U763QNdoUKhCIEO+4adcZ e3nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UmkP5kgbcV5dZf4KaoMusJ98ux3N5DeAvYu9rDMG594=; b=iaBUYxAYBAfMFwjEWDUGXQAc86ML/3C9PMHVtUTPprKCA9pg9HSi+DAp/Wf81a6nsr Fvrxd0sv8nlRewnY28VvlljAmfl0G3npfcTgaJhbPAVSSNsNUTL6sIhuYNIZ8wH+qpip uEwfVL3f/RW7If8UJ7h4rqXVThfswm9279iJR94boEZHhVyIZ353bAUgQI3PibavnUNl lBThdqURQIF2Axc89DksGNM+OT72XEwx0/TbTTUKAHhCX+pHH81g14zmjcD6fw2bfTaf yiR9zo24ESWNNxkP+3H8y5HmbIfzStXn5f3dFfETMuDErnoqHJTrV3vRoTi5W7gSRvEo 720g== X-Gm-Message-State: AJaThX75ytxyOj7s+/2F/yS6umJYp7+8JtawM25xdZzTxVtEQQlfxCah GlxQMVPh4DKfAkUS+zlY2w2wYoz7ung= X-Google-Smtp-Source: AGs4zMaXbTf2L7vKzIJrIdtunGPNuegTVzFRZa8W8XxHFAK3qA1Ateenh7KWaRWbS88GzZvTsuTGrQ== X-Received: by 10.101.93.79 with SMTP id e15mr22870328pgt.157.1512611977890; Wed, 06 Dec 2017 17:59:37 -0800 (PST) Received: from [10.1.235.28] ([199.36.244.14]) by smtp.gmail.com with ESMTPSA id 69sm6454043pfj.28.2017.12.06.17.59.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 17:59:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> Date: Wed, 6 Dec 2017 17:59:35 -0800 Cc: "Marc Portoles Comeras (mportole)" , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <835A59E6-9E85-4459-8ED6-44FA2739C73A@gmail.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> To: Johnson Leong X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 01:59:41 -0000 > Dino, >=20 > What we're trying to convey is that by using TCP it allows us to = achieve reliability which significantly simplifies the code and error = handling. One can achieve the same with UDP with ack and retry but it = would be reimplementing what TCP already offers and this added = complexity typically makes the code error prone. I know what you are trying to do and your assertion is simply not true. > Another benefit with TCP is congestion control, with UDP if we send a = map-register and we don't get an ack then we retry. What if the MS is = fully subscribed then this can lead to constant retry. You can impose = backoff mechanism but ultimately this would affect convergence. And you think in this condition that TCP won=E2=80=99t be retrying. THe = arguments are weak. In fact, if TCP is retrying there is a greater = window of time where old RLOC-set data is in the pipeline. Dino >=20 > -Johnson >=20 >> On Dec 6, 2017, at 11:17 AM, Dino Farinacci = wrote: >>=20 >>> Dino, >>>=20 >>>> LISP (the application), does not know that itself, the xTR, is in = sync with the map-server. The packets can be in flight or being = retransmitted due to loss. But if a Map-Register is sent with a nonce = and no Map-Notify is returned the xTR knows for sure the two are in = sync. >>>=20 >>> An application (and LISP in this case) should always be able to know = the state of a (TCP) socket that it has opened with a server. I=E2=80=99m = not entirely sure why we would not want to use this information.=20 >>=20 >> All an app knows is the socket it has opened and any port it has = bind()=E2=80=99ed to. It doesn=E2=80=99t know the connection state in = terms of what packets have been sent and what has been ack=E2=80=99ed. = There IS NOT enough information to do anything useful. >>=20 >>> Besides, the reliable transport session does not invalidate the use = of nonces and Map-Notifies as an indication that the MS has completely = received the information, the just rely on the TCP state to know that = nothing has changed. >>=20 >> Right, so you have duplicate functionality. That isn=E2=80=99t = efficient. >>=20 >>>> I=E2=80=99d argue you may it worse. TCP does provide reliability = but so does LISP itself. And the only reason the messages are periodic = is because the spec said to send every 1 minute and timeout every 3 = minutes. You can make it 1000 minutes and timeout every 3000 minutes. >>>=20 >>> And this sounds as we would make the protocol very complicated to = use (or code), as this would lead us to have to code/configure a = specific registration pattern/logic for every use case that we want to = support. Not saying we cannot, but it sounds like re-implementing TCP ;) >>=20 >> You already have that code or you aren=E2=80=99t implementing = Map-Register acks corrrectly. And changing a timer is really a constant = change in the code. And what is spec=E2=80=99ed today in LISP proper is = much simpler than TCP, it is not reimplementing it. >>=20 >> But let's not drift from the point. The spec is written in a general = way to solve only sending Map-Registers reliably. I suggest the text not = mislead the reader to think this is a general new packet format for = anything. >>=20 >> When people judge which protocols they want to deploy, the people = that do the due diligence will look at the protocol specs and see how = much mechanism is designed in. And they make judgement decisions about = using the protocol. >>=20 >> I know of at least 2 vendors that said =E2=80=9CI implemented pages = 47-50 of the EVPN spec=E2=80=9D. ;-) >>=20 >> In LISP. we want to make sure what we spec is what is used and not = ignored or considered optional. So please document the specific use-case = you want to implement. And I=E2=80=99d suggest making the draft name = draft-*-lisp-reliable-registers. >>=20 >>>> LISP can pack all those EID-records in a Map-Register just like TCP = does. And if you want per nonce acks, you pack them in IP packets <=3D = 65535 bytes. TCP will have to o that as well. >>>=20 >>> This is exactly the point, while LISP signaling allows it we don=E2=80= =99t need to re-implement every TCP feature in LISP, as TCP can already = provide it. >>=20 >> You don=E2=80=99t need to.=20 >>=20 >>>> And guess what. What if there is an RLOC-change and you already = gave the last one to TCP and can=E2=80=99t pull it back. If you were = waiting for an ack and a new RLOC-change came in (during a lossy case), = you wouldn=E2=80=99t have to retransmit the old information wastily. So = keep the =E2=80=9Cretransmission queue=E2=80=9D in LISP has its = advantages. >>>=20 >>> I=E2=80=99m not sure this is so easy. UDP, just like TCP uses the = RLOC (IP) as part of the =E2=80=9Csession identifier=E2=80=9D and the = nonce is per-packet, not per-session. The moment the RLOC changes on the = xTR, the MS does not know that the xTR is the same so we=E2=80=99d need = a retransmission process. >>=20 >> I=E2=80=99m not talking about when the xTR changes, I=E2=80=99m = talking about an address on an interface on the same xTR changes since = it was DHCP=E2=80=99ed to the xTR or behind a NAT. But for the LISP-MN = case, the xTR is moving and its RLOCs are changing. You couple this with = pubsub and the extra Map-Registers with old RLOCs has a ripple effect = where then the Map-Server sends Map-Notify messages to all the = subscribers, then followed by another set of Map-Notifies with the new = RLOC-set. That is a lot of (unnecessary) messaging and processing. >>=20 >> We have to think about the implications of any one draft on the = ENTIRE LISP architecture. It must work efficiently as one holistic = distributed system. >>=20 >> Dino >>=20 >>>=20 >>> Marc >>>=20 >>> On 12/5/17, 5:57 PM, "Dino Farinacci" wrote: >>>=20 >>>> Dino, >>>>=20 >>>> In addition to the previous arguments there are particular = use-cases where the use of reliable transport simplified the deployment = of LISP. >>>=20 >>> I understand its advantages. I am examining its costs. >>>=20 >>>> As an example, the moment we started scaling datacenters to support = 10s of thousands of hosts, the use of a reliable transport helped a lot = the management of scale:=20 >>>> On one side it reduces the amount of signaling when nothing = changes, since we use TCP state as an indication that xTRs and the MS = are in sync and there is no need to deal with the optimization of the = refresh logic (periodic or paced).=20 >>>=20 >>> LISP (the application), does not know that itself, the xTR, is in = sync with the map-server. The packets can be in flight or being = retransmitted due to loss. But if a Map-Register is sent with a nonce = and no Map-Notify is returned the xTR knows for sure the two are in = sync. >>>=20 >>> I=E2=80=99d argue you may it worse. TCP does provide reliability = but so does LISP itself. And the only reason the messages are periodic = is because the spec said to send every 1 minute and timeout every 3 = minutes. You can make it 1000 minutes and timeout every 3000 minutes.=20 >>>=20 >>> So let=E2=80=99s keep periiodic overhead, reliability, and staying = in sync as separate issues. >>>=20 >>>> On the other side, with reliable transport we offload the reliable = delivery of information (and congestion control)=20 >>>=20 >>> I understand that. But you can=E2=80=99t say TCP is keeping you in = sync, because you have removed detail from the applicationis. >>>=20 >>>> from LISP to another process (TCP) that is entirely devoted and = designed for this. For example, supporting events like mass VM moves = relying purely on LISP based ACks became very challenging, as we ended = up having to deal with congestion events related to the signaling load = generated. The use of the reliable transport largely simplified the = problem. >>>=20 >>> Dino >>>=20 >>>>=20 >>>> Marc >>>>=20 >>>> On 12/5/17, 12:06 PM, "lisp on behalf of Johnson Leong (joleong)" = wrote: >>>>=20 >>>> Hi Dino, >>>>=20 >>>> A large portion of this draft discusses the state machine required = for TCP and how to ensure the MS and xTR are in sync. We literally = reuse the entire UDP map-register code, we just wrap that message around = the LISP TCP header so there's a lot of code reuse. Finally, this draft = is not meant to replace UDP register but in some of our use cases TCP = would scale better to avoid the periodic registration. >>>>=20 >>>> -Johnson >>>>=20 >>>>> On Dec 5, 2017, at 10:52 AM, Dino Farinacci = wrote: >>>>>=20 >>>>>> registration protocol, that might be orthogonal to other = transport-related mechanisms. In my experience this has proved to be = very effective in scalability of large LISP deployments, especially with = the increased volume of registration data. >>>>>=20 >>>>> I agree it=E2=80=99s a point solution for registration. Then why = did you need to have a general format.=20 >>>>>=20 >>>>> I could support this draft if it was simplified to spec how to use = Map-Registers in TCP and nothing more.=20 >>>>>=20 >>>>> The only thing I would add is how to use TLS so encryption is = supported. More and more requirements are coming up for protecting the = privacy of location information. And since Map-Registers carry RLOCs = (and potential Geo-Coordnates) that information needs to be protected.=20= >>>>>=20 >>>>> Dino >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 From nobody Wed Dec 6 21:10:12 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675581279EB for ; Wed, 6 Dec 2017 21:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIMvqd5yq-Wn for ; Wed, 6 Dec 2017 21:10:07 -0800 (PST) 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 B35051200F3 for ; Wed, 6 Dec 2017 21:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15444; q=dns/txt; s=iport; t=1512623407; x=1513833007; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5bCDfL7EF5mM0jlwryG4v9h+sdNKBFQOav7w0U/iL+8=; b=Wtf3GsQ1LBZhKzKGaDYi5HsVWbNK/TvMO8fAFYsNCFyfTSQE75Lq+vgw /2PAWAd521yJEuYeUlTv+SZ/AsHSE7IWuiwyKp1engX/3O/cxlAPANv5d q+/Ubxs4U2f+SzfsZ7pLKVbN5jye88fygToJoZqWOqKbiZas/WBk5EmY5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDfzCha/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2ZyJweDe4ogjn+BfYh1jhQUggEKGAuFGAIahTo/GAEBAQE?= =?us-ascii?q?BAQEBAWsohSIBAQEBAgEBASEROgsQAgEIEgYCAiYCAgIfBgsVAg4CBAENBRsEi?= =?us-ascii?q?XADDQgQqFGCJ4c7DYMTAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4JFggpUgmo?= =?us-ascii?q?BKYMCgmuCHgIWgxUxgjIFkgiQOj0CkB6EfIIWhhGLNI0/iGkCERkBgToBHzmBT?= =?us-ascii?q?28VOioBgX6CTwMcGYFOeIh5gRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,371,1508803200"; d="scan'208";a="41491015" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2017 05:09:46 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vB759j02024673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 05:09:46 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 7 Dec 2017 00:09:44 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Thu, 7 Dec 2017 00:09:44 -0500 From: "Marc Portoles Comeras (mportole)" To: Dino Farinacci , "Johnson Leong (joleong)" CC: "lisp@ietf.org" Thread-Topic: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption Thread-Index: AQHTbeo9leq2xF5iHkW7tPGXEoJPSqM1YT4AgAAI1ACAAAI0gIAAFLuAgABIaYCAABmEAIAA9doAgAAs4QCAAAeDgIAAaOCAgAA1JIA= Date: Thu, 7 Dec 2017 05:09:43 +0000 Message-ID: <76C65DF3-8F6E-49BE-A85A-358F062143E6@cisco.com> References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> <835A59E6-9E85-4459-8ED6-44FA2739C73A@gmail.com> In-Reply-To: <835A59E6-9E85-4459-8ED6-44FA2739C73A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.4.250] Content-Type: text/plain; charset="utf-8" Content-ID: <5CA935BBBD964449A9CC00D281DD30DC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 05:10:10 -0000 ID4+IEFub3RoZXIgYmVuZWZpdCB3aXRoIFRDUCBpcyBjb25nZXN0aW9uIGNvbnRyb2wsIHdpdGgg VURQIGlmIHdlIHNlbmQgYSBtYXAtcmVnaXN0ZXIgYW5kIHdlIGRvbid0IGdldCBhbiBhY2sgdGhl biB3ZSByZXRyeS4gIFdoYXQgaWYgdGhlIE1TIGlzIGZ1bGx5IHN1YnNjcmliZWQgdGhlbiB0aGlz IGNhbiBsZWFkIHRvIGNvbnN0YW50IHJldHJ5LiAgWW91IGNhbiBpbXBvc2UgYmFja29mZiBtZWNo YW5pc20gYnV0IHVsdGltYXRlbHkgdGhpcyB3b3VsZCBhZmZlY3QgY29udmVyZ2VuY2UuDQogPiBB bmQgeW91IHRoaW5rIGluIHRoaXMgY29uZGl0aW9uIHRoYXQgVENQIHdvbuKAmXQgYmUgcmV0cnlp bmcuIFRoZSBhcmd1bWVudHMgYXJlIHdlYWsuIEluIGZhY3QsIGlmIFRDUCBpcyByZXRyeWluZyB0 aGVyZSBpcyBhIGdyZWF0ZXIgd2luZG93IG9mIHRpbWUgd2hlcmUgb2xkIFJMT0Mtc2V0IGRhdGEg aXMgaW4gdGhlIHBpcGVsaW5lLg0KDQpGcm9tIGEgZ2VuZXJhbCBwZXJzcGVjdGl2ZSBpZiBUQ1Ag aXMgYWRhcHRpbmcgdG8gbmV0d29yayBpbXBhaXJtZW50cyBvciBjb25nZXN0aW9uIGluIGEgZ2l2 ZW4gc2V0dGluZywgYW55IG90aGVyIHNvbHV0aW9uIHdpbGwgaGF2ZSB0byBhZGFwdCB0b28sIHNv IHRoZSBleHBlcmllbmNlZCBkZWxheS9sb3NzIHByb2JsZW1zIHNob3VsZCBiZSB0aGVyZSB0b28u IEJ1dCB0aGUgYWR2YW50YWdlIGluIHRoaXMgY2FzZSB3b3VsZCBiZSBub3QgaGF2aW5nIHRvIHJl LWltcGxlbWVudCBhbiBhZGFwdGl2ZSBzb2x1dGlvbiB3aXRoaW4gdGhlIExJU1AgYXBwbGljYXRp b24gaXRzZWxmLCBidXQgdGFraW5nIGFkdmFudGFnZSBvZiBhIHNvbHV0aW9uIHRoYXQgYWxyZWFk eSBwcm92aWRlcyB0aGlzLg0KDQpIb3dldmVyLCBub3RlIHRoYXQgYXMgRmFiaW8gYW5kIEpvaG5z b24gbWVudGlvbmVkIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHRocmVhZCwgYm90aCBMSVNQIGVu Y29kaW5nIG9mIG1lc3NhZ2VzIGFuZCBVRFAgYmFzZWQgc2lnbmFsaW5nIGFyZSBwcmVzZXJ2ZWQg d2l0aCB0aGUgcmVsaWFibGUgdHJhbnNwb3J0IGltcGxlbWVudGF0aW9uLiB4VFJzIHRoYXQgY2Fu IHRha2UgYWR2YW50YWdlIG9mIGVzdGFibGlzaGluZyB0aGUgc2Vzc2lvbiBhbmQgb2ZmbG9hZGlu ZyBjZXJ0YWluIHRhc2tzIHRvIHRoZSBUQ1Agc29ja2V0LCBjYW4gZG8gc28uIFRoZSByZXN0IG9m IG5vZGVzICh4VFJzIGhvc3RpbmcgYSBsb3cgbnVtYmVyIG9mIEVJRHMgb3IgTElTUC1NTiBub2Rl cykgY2FuIChhbmQgd2lsbCkgY29udGludWUgdXNpbmcgVURQIGJhc2VkIHJlZ2lzdHJhdGlvbnMg bm9ybWFsbHkuIA0KDQpPbiAxMi82LzE3LCA1OjU5IFBNLCAiRGlubyBGYXJpbmFjY2kiIDxmYXJp bmFjY2lAZ21haWwuY29tPiB3cm90ZToNCg0KICAgID4gRGlubywNCiAgICA+IA0KICAgID4gV2hh dCB3ZSdyZSB0cnlpbmcgdG8gY29udmV5IGlzIHRoYXQgYnkgdXNpbmcgVENQIGl0IGFsbG93cyB1 cyB0byBhY2hpZXZlIHJlbGlhYmlsaXR5IHdoaWNoIHNpZ25pZmljYW50bHkgc2ltcGxpZmllcyB0 aGUgY29kZSBhbmQgZXJyb3IgaGFuZGxpbmcuICBPbmUgY2FuIGFjaGlldmUgdGhlIHNhbWUgd2l0 aCBVRFAgd2l0aCBhY2sgYW5kIHJldHJ5IGJ1dCBpdCB3b3VsZCBiZSByZWltcGxlbWVudGluZyB3 aGF0IFRDUCBhbHJlYWR5IG9mZmVycyBhbmQgdGhpcyBhZGRlZCBjb21wbGV4aXR5IHR5cGljYWxs eSBtYWtlcyB0aGUgY29kZSBlcnJvciBwcm9uZS4NCiAgICANCiAgICBJIGtub3cgd2hhdCB5b3Ug YXJlIHRyeWluZyB0byBkbyBhbmQgeW91ciBhc3NlcnRpb24gaXMgc2ltcGx5IG5vdCB0cnVlLg0K ICAgIA0KICAgID4gQW5vdGhlciBiZW5lZml0IHdpdGggVENQIGlzIGNvbmdlc3Rpb24gY29udHJv bCwgd2l0aCBVRFAgaWYgd2Ugc2VuZCBhIG1hcC1yZWdpc3RlciBhbmQgd2UgZG9uJ3QgZ2V0IGFu IGFjayB0aGVuIHdlIHJldHJ5LiAgV2hhdCBpZiB0aGUgTVMgaXMgZnVsbHkgc3Vic2NyaWJlZCB0 aGVuIHRoaXMgY2FuIGxlYWQgdG8gY29uc3RhbnQgcmV0cnkuICBZb3UgY2FuIGltcG9zZSBiYWNr b2ZmIG1lY2hhbmlzbSBidXQgdWx0aW1hdGVseSB0aGlzIHdvdWxkIGFmZmVjdCBjb252ZXJnZW5j ZS4NCiAgICANCiAgICBBbmQgeW91IHRoaW5rIGluIHRoaXMgY29uZGl0aW9uIHRoYXQgVENQIHdv buKAmXQgYmUgcmV0cnlpbmcuIFRIZSBhcmd1bWVudHMgYXJlIHdlYWsuIEluIGZhY3QsIGlmIFRD UCBpcyByZXRyeWluZyB0aGVyZSBpcyBhIGdyZWF0ZXIgd2luZG93IG9mIHRpbWUgd2hlcmUgb2xk IFJMT0Mtc2V0IGRhdGEgaXMgaW4gdGhlIHBpcGVsaW5lLg0KICAgIA0KICAgIERpbm8NCiAgICAN CiAgICA+IA0KICAgID4gLUpvaG5zb24NCiAgICA+IA0KICAgID4+IE9uIERlYyA2LCAyMDE3LCBh dCAxMToxNyBBTSwgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5jb20+IHdyb3RlOg0K ICAgID4+IA0KICAgID4+PiBEaW5vLA0KICAgID4+PiANCiAgICA+Pj4+IExJU1AgKHRoZSBhcHBs aWNhdGlvbiksIGRvZXMgbm90IGtub3cgdGhhdCBpdHNlbGYsIHRoZSB4VFIsIGlzIGluIHN5bmMg d2l0aCB0aGUgbWFwLXNlcnZlci4gVGhlIHBhY2tldHMgY2FuIGJlIGluIGZsaWdodCBvciBiZWlu ZyByZXRyYW5zbWl0dGVkIGR1ZSB0byBsb3NzLiBCdXQgaWYgYSBNYXAtUmVnaXN0ZXIgaXMgc2Vu dCB3aXRoIGEgbm9uY2UgYW5kIG5vIE1hcC1Ob3RpZnkgaXMgcmV0dXJuZWQgdGhlIHhUUiBrbm93 cyBmb3Igc3VyZSB0aGUgdHdvIGFyZSBpbiBzeW5jLg0KICAgID4+PiANCiAgICA+Pj4gQW4gYXBw bGljYXRpb24gKGFuZCBMSVNQIGluIHRoaXMgY2FzZSkgc2hvdWxkIGFsd2F5cyBiZSBhYmxlIHRv IGtub3cgdGhlIHN0YXRlIG9mIGEgKFRDUCkgc29ja2V0IHRoYXQgaXQgaGFzIG9wZW5lZCB3aXRo IGEgc2VydmVyLiBJ4oCZbSBub3QgZW50aXJlbHkgc3VyZSB3aHkgd2Ugd291bGQgbm90IHdhbnQg dG8gdXNlIHRoaXMgaW5mb3JtYXRpb24uIA0KICAgID4+IA0KICAgID4+IEFsbCBhbiBhcHAga25v d3MgaXMgdGhlIHNvY2tldCBpdCBoYXMgb3BlbmVkIGFuZCBhbnkgcG9ydCBpdCBoYXMgYmluZCgp 4oCZZWQgdG8uIEl0IGRvZXNu4oCZdCBrbm93IHRoZSBjb25uZWN0aW9uIHN0YXRlIGluIHRlcm1z IG9mIHdoYXQgcGFja2V0cyBoYXZlIGJlZW4gc2VudCBhbmQgd2hhdCBoYXMgYmVlbiBhY2vigJll ZC4gVGhlcmUgSVMgTk9UIGVub3VnaCBpbmZvcm1hdGlvbiB0byBkbyBhbnl0aGluZyB1c2VmdWwu DQogICAgPj4gDQogICAgPj4+IEJlc2lkZXMsIHRoZSByZWxpYWJsZSB0cmFuc3BvcnQgc2Vzc2lv biBkb2VzIG5vdCBpbnZhbGlkYXRlIHRoZSB1c2Ugb2Ygbm9uY2VzIGFuZCBNYXAtTm90aWZpZXMg YXMgYW4gaW5kaWNhdGlvbiB0aGF0IHRoZSBNUyBoYXMgY29tcGxldGVseSByZWNlaXZlZCB0aGUg aW5mb3JtYXRpb24sIHRoZSBqdXN0IHJlbHkgb24gdGhlIFRDUCBzdGF0ZSB0byBrbm93IHRoYXQg bm90aGluZyBoYXMgY2hhbmdlZC4NCiAgICA+PiANCiAgICA+PiBSaWdodCwgc28geW91IGhhdmUg ZHVwbGljYXRlIGZ1bmN0aW9uYWxpdHkuIFRoYXQgaXNu4oCZdCBlZmZpY2llbnQuDQogICAgPj4g DQogICAgPj4+PiBJ4oCZZCBhcmd1ZSB5b3UgbWF5IGl0IHdvcnNlLiBUQ1AgZG9lcyBwcm92aWRl IHJlbGlhYmlsaXR5IGJ1dCBzbyBkb2VzIExJU1AgaXRzZWxmLiBBbmQgdGhlIG9ubHkgcmVhc29u IHRoZSBtZXNzYWdlcyBhcmUgcGVyaW9kaWMgaXMgYmVjYXVzZSB0aGUgc3BlYyBzYWlkIHRvIHNl bmQgZXZlcnkgMSBtaW51dGUgYW5kIHRpbWVvdXQgZXZlcnkgMyBtaW51dGVzLiBZb3UgY2FuIG1h a2UgaXQgMTAwMCBtaW51dGVzIGFuZCB0aW1lb3V0IGV2ZXJ5IDMwMDAgbWludXRlcy4NCiAgICA+ Pj4gDQogICAgPj4+IEFuZCB0aGlzIHNvdW5kcyBhcyB3ZSB3b3VsZCBtYWtlIHRoZSBwcm90b2Nv bCB2ZXJ5IGNvbXBsaWNhdGVkIHRvIHVzZSAob3IgY29kZSksIGFzIHRoaXMgd291bGQgbGVhZCB1 cyB0byBoYXZlIHRvIGNvZGUvY29uZmlndXJlIGEgc3BlY2lmaWMgcmVnaXN0cmF0aW9uIHBhdHRl cm4vbG9naWMgZm9yIGV2ZXJ5IHVzZSBjYXNlIHRoYXQgd2Ugd2FudCB0byBzdXBwb3J0LiBOb3Qg c2F5aW5nIHdlIGNhbm5vdCwgYnV0IGl0IHNvdW5kcyBsaWtlIHJlLWltcGxlbWVudGluZyBUQ1Ag OykNCiAgICA+PiANCiAgICA+PiBZb3UgYWxyZWFkeSBoYXZlIHRoYXQgY29kZSBvciB5b3UgYXJl buKAmXQgaW1wbGVtZW50aW5nIE1hcC1SZWdpc3RlciBhY2tzIGNvcnJyZWN0bHkuIEFuZCBjaGFu Z2luZyBhIHRpbWVyIGlzIHJlYWxseSBhIGNvbnN0YW50IGNoYW5nZSBpbiB0aGUgY29kZS4gQW5k IHdoYXQgaXMgc3BlY+KAmWVkIHRvZGF5IGluIExJU1AgcHJvcGVyIGlzIG11Y2ggc2ltcGxlciB0 aGFuIFRDUCwgaXQgaXMgbm90IHJlaW1wbGVtZW50aW5nIGl0Lg0KICAgID4+IA0KICAgID4+IEJ1 dCBsZXQncyBub3QgZHJpZnQgZnJvbSB0aGUgcG9pbnQuIFRoZSBzcGVjIGlzIHdyaXR0ZW4gaW4g YSBnZW5lcmFsIHdheSB0byBzb2x2ZSBvbmx5IHNlbmRpbmcgTWFwLVJlZ2lzdGVycyByZWxpYWJs eS4gSSBzdWdnZXN0IHRoZSB0ZXh0IG5vdCBtaXNsZWFkIHRoZSByZWFkZXIgdG8gdGhpbmsgdGhp cyBpcyBhIGdlbmVyYWwgbmV3IHBhY2tldCBmb3JtYXQgZm9yIGFueXRoaW5nLg0KICAgID4+IA0K ICAgID4+IFdoZW4gcGVvcGxlIGp1ZGdlIHdoaWNoIHByb3RvY29scyB0aGV5IHdhbnQgdG8gZGVw bG95LCB0aGUgcGVvcGxlIHRoYXQgZG8gdGhlIGR1ZSBkaWxpZ2VuY2Ugd2lsbCBsb29rIGF0IHRo ZSBwcm90b2NvbCBzcGVjcyBhbmQgc2VlIGhvdyBtdWNoIG1lY2hhbmlzbSBpcyBkZXNpZ25lZCBp bi4gQW5kIHRoZXkgbWFrZSBqdWRnZW1lbnQgZGVjaXNpb25zIGFib3V0IHVzaW5nIHRoZSBwcm90 b2NvbC4NCiAgICA+PiANCiAgICA+PiBJIGtub3cgb2YgYXQgbGVhc3QgMiB2ZW5kb3JzIHRoYXQg c2FpZCDigJxJIGltcGxlbWVudGVkIHBhZ2VzIDQ3LTUwIG9mIHRoZSBFVlBOIHNwZWPigJ0uICA7 LSkNCiAgICA+PiANCiAgICA+PiBJbiBMSVNQLiB3ZSB3YW50IHRvIG1ha2Ugc3VyZSB3aGF0IHdl IHNwZWMgaXMgd2hhdCBpcyB1c2VkIGFuZCBub3QgaWdub3JlZCBvciBjb25zaWRlcmVkIG9wdGlv bmFsLiBTbyBwbGVhc2UgZG9jdW1lbnQgdGhlIHNwZWNpZmljIHVzZS1jYXNlIHlvdSB3YW50IHRv IGltcGxlbWVudC4gQW5kIEnigJlkIHN1Z2dlc3QgbWFraW5nIHRoZSBkcmFmdCBuYW1lIGRyYWZ0 LSotbGlzcC1yZWxpYWJsZS1yZWdpc3RlcnMuDQogICAgPj4gDQogICAgPj4+PiBMSVNQIGNhbiBw YWNrIGFsbCB0aG9zZSBFSUQtcmVjb3JkcyBpbiBhIE1hcC1SZWdpc3RlciBqdXN0IGxpa2UgVENQ IGRvZXMuIEFuZCBpZiB5b3Ugd2FudCBwZXIgbm9uY2UgYWNrcywgeW91IHBhY2sgdGhlbSBpbiBJ UCBwYWNrZXRzIDw9IDY1NTM1IGJ5dGVzLiBUQ1Agd2lsbCBoYXZlIHRvIG8gdGhhdCBhcyB3ZWxs Lg0KICAgID4+PiANCiAgICA+Pj4gVGhpcyBpcyBleGFjdGx5IHRoZSBwb2ludCwgd2hpbGUgTElT UCBzaWduYWxpbmcgYWxsb3dzIGl0IHdlIGRvbuKAmXQgbmVlZCB0byByZS1pbXBsZW1lbnQgZXZl cnkgVENQIGZlYXR1cmUgaW4gTElTUCwgYXMgVENQIGNhbiBhbHJlYWR5IHByb3ZpZGUgaXQuDQog ICAgPj4gDQogICAgPj4gWW91IGRvbuKAmXQgbmVlZCB0by4gDQogICAgPj4gDQogICAgPj4+PiBB bmQgZ3Vlc3Mgd2hhdC4gV2hhdCBpZiB0aGVyZSBpcyBhbiBSTE9DLWNoYW5nZSBhbmQgeW91IGFs cmVhZHkgZ2F2ZSB0aGUgbGFzdCBvbmUgdG8gVENQIGFuZCBjYW7igJl0IHB1bGwgaXQgYmFjay4g SWYgeW91IHdlcmUgd2FpdGluZyBmb3IgYW4gYWNrIGFuZCBhIG5ldyBSTE9DLWNoYW5nZSBjYW1l IGluIChkdXJpbmcgYSBsb3NzeSBjYXNlKSwgeW91IHdvdWxkbuKAmXQgaGF2ZSB0byByZXRyYW5z bWl0IHRoZSBvbGQgaW5mb3JtYXRpb24gd2FzdGlseS4gU28ga2VlcCB0aGUg4oCccmV0cmFuc21p c3Npb24gcXVldWXigJ0gaW4gTElTUCBoYXMgaXRzIGFkdmFudGFnZXMuDQogICAgPj4+IA0KICAg ID4+PiBJ4oCZbSBub3Qgc3VyZSB0aGlzIGlzIHNvIGVhc3kuIFVEUCwganVzdCBsaWtlIFRDUCB1 c2VzIHRoZSBSTE9DIChJUCkgYXMgcGFydCBvZiB0aGUg4oCcc2Vzc2lvbiBpZGVudGlmaWVy4oCd IGFuZCB0aGUgbm9uY2UgaXMgcGVyLXBhY2tldCwgbm90IHBlci1zZXNzaW9uLiBUaGUgbW9tZW50 IHRoZSBSTE9DIGNoYW5nZXMgb24gdGhlIHhUUiwgdGhlIE1TIGRvZXMgbm90IGtub3cgdGhhdCB0 aGUgeFRSIGlzIHRoZSBzYW1lIHNvIHdl4oCZZCBuZWVkIGEgcmV0cmFuc21pc3Npb24gcHJvY2Vz cy4NCiAgICA+PiANCiAgICA+PiBJ4oCZbSBub3QgdGFsa2luZyBhYm91dCB3aGVuIHRoZSB4VFIg Y2hhbmdlcywgSeKAmW0gdGFsa2luZyBhYm91dCBhbiBhZGRyZXNzIG9uIGFuIGludGVyZmFjZSBv biB0aGUgc2FtZSB4VFIgY2hhbmdlcyBzaW5jZSBpdCB3YXMgREhDUOKAmWVkIHRvIHRoZSB4VFIg b3IgYmVoaW5kIGEgTkFULiBCdXQgZm9yIHRoZSBMSVNQLU1OIGNhc2UsIHRoZSB4VFIgaXMgbW92 aW5nIGFuZCBpdHMgUkxPQ3MgYXJlIGNoYW5naW5nLiBZb3UgY291cGxlIHRoaXMgd2l0aCBwdWJz dWIgYW5kIHRoZSBleHRyYSBNYXAtUmVnaXN0ZXJzIHdpdGggb2xkIFJMT0NzIGhhcyBhIHJpcHBs ZSBlZmZlY3Qgd2hlcmUgdGhlbiB0aGUgTWFwLVNlcnZlciBzZW5kcyBNYXAtTm90aWZ5IG1lc3Nh Z2VzIHRvIGFsbCB0aGUgc3Vic2NyaWJlcnMsIHRoZW4gZm9sbG93ZWQgYnkgYW5vdGhlciBzZXQg b2YgTWFwLU5vdGlmaWVzIHdpdGggdGhlIG5ldyBSTE9DLXNldC4gVGhhdCBpcyBhIGxvdCBvZiAo dW5uZWNlc3NhcnkpIG1lc3NhZ2luZyBhbmQgcHJvY2Vzc2luZy4NCiAgICA+PiANCiAgICA+PiBX ZSBoYXZlIHRvIHRoaW5rIGFib3V0IHRoZSBpbXBsaWNhdGlvbnMgb2YgYW55IG9uZSBkcmFmdCBv biB0aGUgRU5USVJFIExJU1AgYXJjaGl0ZWN0dXJlLiBJdCBtdXN0IHdvcmsgZWZmaWNpZW50bHkg YXMgb25lIGhvbGlzdGljIGRpc3RyaWJ1dGVkIHN5c3RlbS4NCiAgICA+PiANCiAgICA+PiBEaW5v DQogICAgPj4gDQogICAgPj4+IA0KICAgID4+PiBNYXJjDQogICAgPj4+IA0KICAgID4+PiBPbiAx Mi81LzE3LCA1OjU3IFBNLCAiRGlubyBGYXJpbmFjY2kiIDxmYXJpbmFjY2lAZ21haWwuY29tPiB3 cm90ZToNCiAgICA+Pj4gDQogICAgPj4+PiBEaW5vLA0KICAgID4+Pj4gDQogICAgPj4+PiBJbiBh ZGRpdGlvbiB0byB0aGUgcHJldmlvdXMgYXJndW1lbnRzIHRoZXJlIGFyZSBwYXJ0aWN1bGFyIHVz ZS1jYXNlcyB3aGVyZSB0aGUgdXNlIG9mIHJlbGlhYmxlIHRyYW5zcG9ydCBzaW1wbGlmaWVkIHRo ZSBkZXBsb3ltZW50IG9mIExJU1AuDQogICAgPj4+IA0KICAgID4+PiAgSSB1bmRlcnN0YW5kIGl0 cyBhZHZhbnRhZ2VzLiBJIGFtIGV4YW1pbmluZyBpdHMgY29zdHMuDQogICAgPj4+IA0KICAgID4+ Pj4gQXMgYW4gZXhhbXBsZSwgdGhlIG1vbWVudCB3ZSBzdGFydGVkIHNjYWxpbmcgZGF0YWNlbnRl cnMgdG8gc3VwcG9ydCAxMHMgb2YgdGhvdXNhbmRzIG9mIGhvc3RzLCB0aGUgdXNlIG9mIGEgcmVs aWFibGUgdHJhbnNwb3J0IGhlbHBlZCBhIGxvdCB0aGUgbWFuYWdlbWVudCBvZiBzY2FsZTogDQog ICAgPj4+PiBPbiBvbmUgc2lkZSBpdCByZWR1Y2VzIHRoZSBhbW91bnQgb2Ygc2lnbmFsaW5nIHdo ZW4gbm90aGluZyBjaGFuZ2VzLCBzaW5jZSB3ZSB1c2UgVENQIHN0YXRlIGFzIGFuIGluZGljYXRp b24gdGhhdCB4VFJzIGFuZCB0aGUgTVMgYXJlIGluIHN5bmMgYW5kIHRoZXJlIGlzIG5vIG5lZWQg dG8gZGVhbCB3aXRoIHRoZSBvcHRpbWl6YXRpb24gb2YgdGhlIHJlZnJlc2ggbG9naWMgKHBlcmlv ZGljIG9yIHBhY2VkKS4gDQogICAgPj4+IA0KICAgID4+PiAgTElTUCAodGhlIGFwcGxpY2F0aW9u KSwgZG9lcyBub3Qga25vdyB0aGF0IGl0c2VsZiwgdGhlIHhUUiwgaXMgaW4gc3luYyB3aXRoIHRo ZSBtYXAtc2VydmVyLiBUaGUgcGFja2V0cyBjYW4gYmUgaW4gZmxpZ2h0IG9yIGJlaW5nIHJldHJh bnNtaXR0ZWQgZHVlIHRvIGxvc3MuIEJ1dCBpZiBhIE1hcC1SZWdpc3RlciBpcyBzZW50IHdpdGgg YSBub25jZSBhbmQgbm8gTWFwLU5vdGlmeSBpcyByZXR1cm5lZCB0aGUgeFRSIGtub3dzIGZvciBz dXJlIHRoZSB0d28gYXJlIGluIHN5bmMuDQogICAgPj4+IA0KICAgID4+PiAgSeKAmWQgYXJndWUg eW91IG1heSBpdCB3b3JzZS4gVENQIGRvZXMgcHJvdmlkZSByZWxpYWJpbGl0eSBidXQgc28gZG9l cyBMSVNQIGl0c2VsZi4gQW5kIHRoZSBvbmx5IHJlYXNvbiB0aGUgbWVzc2FnZXMgYXJlIHBlcmlv ZGljIGlzIGJlY2F1c2UgdGhlIHNwZWMgc2FpZCB0byBzZW5kIGV2ZXJ5IDEgbWludXRlIGFuZCB0 aW1lb3V0IGV2ZXJ5IDMgbWludXRlcy4gWW91IGNhbiBtYWtlIGl0IDEwMDAgbWludXRlcyBhbmQg dGltZW91dCBldmVyeSAzMDAwIG1pbnV0ZXMuIA0KICAgID4+PiANCiAgICA+Pj4gIFNvIGxldOKA mXMga2VlcCBwZXJpaW9kaWMgb3ZlcmhlYWQsIHJlbGlhYmlsaXR5LCBhbmQgc3RheWluZyBpbiBz eW5jIGFzIHNlcGFyYXRlIGlzc3Vlcy4NCiAgICA+Pj4gDQogICAgPj4+PiBPbiB0aGUgb3RoZXIg c2lkZSwgd2l0aCByZWxpYWJsZSB0cmFuc3BvcnQgd2Ugb2ZmbG9hZCB0aGUgcmVsaWFibGUgZGVs aXZlcnkgb2YgaW5mb3JtYXRpb24gKGFuZCBjb25nZXN0aW9uIGNvbnRyb2wpIA0KICAgID4+PiAN CiAgICA+Pj4gIEkgdW5kZXJzdGFuZCB0aGF0LiBCdXQgeW91IGNhbuKAmXQgc2F5IFRDUCBpcyBr ZWVwaW5nIHlvdSBpbiBzeW5jLCBiZWNhdXNlIHlvdSBoYXZlIHJlbW92ZWQgZGV0YWlsIGZyb20g dGhlIGFwcGxpY2F0aW9uaXMuDQogICAgPj4+IA0KICAgID4+Pj4gZnJvbSBMSVNQIHRvIGFub3Ro ZXIgcHJvY2VzcyAoVENQKSB0aGF0IGlzIGVudGlyZWx5IGRldm90ZWQgYW5kIGRlc2lnbmVkIGZv ciB0aGlzLiBGb3IgZXhhbXBsZSwgc3VwcG9ydGluZyBldmVudHMgbGlrZSBtYXNzIFZNIG1vdmVz IHJlbHlpbmcgcHVyZWx5IG9uIExJU1AgYmFzZWQgQUNrcyBiZWNhbWUgdmVyeSBjaGFsbGVuZ2lu ZywgYXMgd2UgZW5kZWQgdXAgaGF2aW5nIHRvIGRlYWwgd2l0aCBjb25nZXN0aW9uIGV2ZW50cyBy ZWxhdGVkIHRvIHRoZSBzaWduYWxpbmcgbG9hZCBnZW5lcmF0ZWQuIFRoZSB1c2Ugb2YgdGhlIHJl bGlhYmxlIHRyYW5zcG9ydCBsYXJnZWx5IHNpbXBsaWZpZWQgdGhlIHByb2JsZW0uDQogICAgPj4+ IA0KICAgID4+PiBEaW5vDQogICAgPj4+IA0KICAgID4+Pj4gDQogICAgPj4+PiBNYXJjDQogICAg Pj4+PiANCiAgICA+Pj4+IE9uIDEyLzUvMTcsIDEyOjA2IFBNLCAibGlzcCBvbiBiZWhhbGYgb2Yg Sm9obnNvbiBMZW9uZyAoam9sZW9uZykiIDxsaXNwLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIGpvbGVvbmdAY2lzY28uY29tPiB3cm90ZToNCiAgICA+Pj4+IA0KICAgID4+Pj4gSGkgRGlu bywNCiAgICA+Pj4+IA0KICAgID4+Pj4gQSBsYXJnZSBwb3J0aW9uIG9mIHRoaXMgZHJhZnQgZGlz Y3Vzc2VzIHRoZSBzdGF0ZSBtYWNoaW5lIHJlcXVpcmVkIGZvciBUQ1AgYW5kIGhvdyB0byBlbnN1 cmUgdGhlIE1TIGFuZCB4VFIgYXJlIGluIHN5bmMuICBXZSBsaXRlcmFsbHkgcmV1c2UgdGhlIGVu dGlyZSBVRFAgbWFwLXJlZ2lzdGVyIGNvZGUsIHdlIGp1c3Qgd3JhcCB0aGF0IG1lc3NhZ2UgYXJv dW5kIHRoZSBMSVNQIFRDUCBoZWFkZXIgc28gdGhlcmUncyBhIGxvdCBvZiBjb2RlIHJldXNlLiAg RmluYWxseSwgdGhpcyBkcmFmdCBpcyBub3QgbWVhbnQgdG8gcmVwbGFjZSBVRFAgcmVnaXN0ZXIg YnV0IGluIHNvbWUgb2Ygb3VyIHVzZSBjYXNlcyBUQ1Agd291bGQgc2NhbGUgYmV0dGVyIHRvIGF2 b2lkIHRoZSBwZXJpb2RpYyByZWdpc3RyYXRpb24uDQogICAgPj4+PiANCiAgICA+Pj4+IC1Kb2hu c29uDQogICAgPj4+PiANCiAgICA+Pj4+PiBPbiBEZWMgNSwgMjAxNywgYXQgMTA6NTIgQU0sIERp bm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPiB3cm90ZToNCiAgICA+Pj4+PiANCiAg ICA+Pj4+Pj4gcmVnaXN0cmF0aW9uIHByb3RvY29sLCB0aGF0IG1pZ2h0IGJlIG9ydGhvZ29uYWwg dG8gb3RoZXIgdHJhbnNwb3J0LXJlbGF0ZWQgbWVjaGFuaXNtcy4gSW4gbXkgZXhwZXJpZW5jZSB0 aGlzIGhhcyBwcm92ZWQgdG8gYmUgdmVyeSBlZmZlY3RpdmUgaW4gc2NhbGFiaWxpdHkgb2YgbGFy Z2UgTElTUCBkZXBsb3ltZW50cywgZXNwZWNpYWxseSB3aXRoIHRoZSBpbmNyZWFzZWQgdm9sdW1l IG9mIHJlZ2lzdHJhdGlvbiBkYXRhLg0KICAgID4+Pj4+IA0KICAgID4+Pj4+IEkgYWdyZWUgaXTi gJlzIGEgcG9pbnQgc29sdXRpb24gZm9yIHJlZ2lzdHJhdGlvbi4gVGhlbiB3aHkgZGlkIHlvdSBu ZWVkIHRvIGhhdmUgYSBnZW5lcmFsIGZvcm1hdC4gDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gSSBj b3VsZCBzdXBwb3J0IHRoaXMgZHJhZnQgaWYgaXQgd2FzIHNpbXBsaWZpZWQgdG8gc3BlYyBob3cg dG8gdXNlIE1hcC1SZWdpc3RlcnMgaW4gVENQIGFuZCBub3RoaW5nIG1vcmUuIA0KICAgID4+Pj4+ IA0KICAgID4+Pj4+IFRoZSBvbmx5IHRoaW5nIEkgd291bGQgYWRkIGlzIGhvdyB0byB1c2UgVExT IHNvIGVuY3J5cHRpb24gaXMgc3VwcG9ydGVkLiBNb3JlIGFuZCBtb3JlIHJlcXVpcmVtZW50cyBh cmUgY29taW5nIHVwIGZvciBwcm90ZWN0aW5nIHRoZSBwcml2YWN5IG9mIGxvY2F0aW9uIGluZm9y bWF0aW9uLiBBbmQgc2luY2UgTWFwLVJlZ2lzdGVycyBjYXJyeSBSTE9DcyAoYW5kIHBvdGVudGlh bCBHZW8tQ29vcmRuYXRlcykgdGhhdCBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBwcm90ZWN0ZWQu IA0KICAgID4+Pj4+IA0KICAgID4+Pj4+IERpbm8NCiAgICA+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4+IGxpc3AgbWFpbGluZyBs aXN0DQogICAgPj4+Pj4gbGlzcEBpZXRmLm9yZw0KICAgID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KICAgID4+Pj4gDQogICAgPj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+Pj4gbGlzcCBtYWls aW5nIGxpc3QNCiAgICA+Pj4+IGxpc3BAaWV0Zi5vcmcNCiAgICA+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KICAgID4+Pj4gDQogICAgPj4+PiANCiAgICA+ Pj4gDQogICAgPj4+IA0KICAgID4+PiANCiAgICA+PiANCiAgICA+IA0KICAgIA0KICAgIA0KDQo= From nobody Thu Dec 7 13:23:44 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C574127B57 for ; Thu, 7 Dec 2017 13:23:42 -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, FREEMAIL_FROM=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 Kf29rJn9zplG for ; Thu, 7 Dec 2017 13:23:40 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE26128990 for ; Thu, 7 Dec 2017 13:23:40 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id y6so5348546pgp.4 for ; Thu, 07 Dec 2017 13:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xz9eqCxsvVOuH9enaGh3ycif/J7nxDZxtHJxXHO6mDM=; b=DtdSuk8Deenc9Q3W6ZXPO0oWTgb+vIlmMZ/VLVHJoyCGklCaQv0JDiuYoeGMT4pFfQ 8josbu0aI+6yDk0Xq7UGeC49gnQBKSh0xbpZapvG3zu7/VJYtwp1R9a5s6Y1neNnD6qS /7TLJF2XjwcW8lx9ejpF3QzHlRhxFdP8qLkqiO6FuSsq07RLVBdJ1pfUqubKJmbl2Ylc XjiK2upNwafcTeZnZo4f7I7JQRRbvdvRyGCzdTaB84n0ZfvC21iqx6WoZhfCPtJLuqOk GuDrQvWoDYEa0fLoHA1RfxYGf80xGF1C2U9cPbDpvanSuJqC5p0ieWoXh/qzGShYLdFb PX8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xz9eqCxsvVOuH9enaGh3ycif/J7nxDZxtHJxXHO6mDM=; b=XjkNjxxGmhUimk61GpNm8GC7XMs0OeiUL2aQTT8nRCz1nYz2gMzsEkr0kGsnfuasoi 8yKIDzXJW8i8Q699laurkBOVnVKnh37qyhR9ZUc8YfXSddsfzySCqDtdp+gEezyxuUrD PgazY8v8WxAC8yJcvzlAaz03+RTU3jmcF6OHRINoPPx6lfXrL+3w7Kj7zZrEpw++Vt35 d9+1/jtTRUdGx+46bOdTHeMGxkNovfrRrCSF4jG/aLbMuo5Qg2wVzm7spfskmWqp98kc ny5csIXhR4xDtoYZTD1wXIwOaN/PCZoWtrIZfm2rfHXoylGJ3azozYOHC+NC17wFeetB p/pg== X-Gm-Message-State: AJaThX7vZJJvddP4Re1F8DIf4XQVGGrkcJmABAd0qA/rY9JOi49ooH2a RjkuMm0qKpTd0v/7ArxBRIQ= X-Google-Smtp-Source: AGs4zMagcceMj9ddlkJioecregpYRVw3Yr+QpJCFoUP4XJiSO4Xo3/EtorUbrxZvubS7EVglfhq72A== X-Received: by 10.84.170.132 with SMTP id j4mr27887770plb.316.1512681819904; Thu, 07 Dec 2017 13:23:39 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:3c6e:7f66:d46b:2017? ([2603:3024:151c:55f0:3c6e:7f66:d46b:2017]) by smtp.gmail.com with ESMTPSA id z2sm9398592pgu.17.2017.12.07.13.23.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 13:23:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: <76C65DF3-8F6E-49BE-A85A-358F062143E6@cisco.com> Date: Thu, 7 Dec 2017 13:23:38 -0800 Cc: Johnson Leong , "lisp@ietf.org" , Stig Venaas Content-Transfer-Encoding: quoted-printable Message-Id: References: <42781EBC-3E60-425C-BFEC-B13686C654C6@kouvelas.net> <103862EC-37E4-4D43-B5E4-DD187C42FFC2@gmail.com> <6000ffde-430c-7f8c-d0be-9de6077fa6df@cisco.com> <1B364743-5EA6-4261-973B-EECD0DE395D9@gmail.com> <56870BB6-1CAB-4389-9680-7F0F7749DD84@cisco.com> <43F14534-07CE-46A1-B682-1A6C170C5507@gmail.com> <00086A69-B932-41A2-AC15-2EFB0D6A44E4@cisco.com> <835A59E6-9E85-4459-8ED6-44FA2739C73A@gmail.com> <76C65DF3-8F6E-49BE-A85A-358F062143E6@cisco.com> To: "Marc Portoles Comeras (mportole)" X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 21:23:42 -0000 >>> Another benefit with TCP is congestion control, with UDP if we send = a map-register and we don't get an ack then we retry. What if the MS is = fully subscribed then this can lead to constant retry. You can impose = backoff mechanism but ultimately this would affect convergence. >> And you think in this condition that TCP won=E2=80=99t be retrying. = The arguments are weak. In fact, if TCP is retrying there is a greater = window of time where old RLOC-set data is in the pipeline. >=20 > =46rom a general perspective if TCP is adapting to network impairments = or congestion in a given setting, any other solution will have to adapt = too, so the experienced delay/loss problems should be there too. But the = advantage in this case would be not having to re-implement an adaptive = solution within the LISP application itself, but taking advantage of a = solution that already provides this. Let me make it perfectly clear. I am NOT against using TCP. We did it = for PIM and thought it was a good idea. I have cc=E2=80=99ed Stig who = has intimate knowledge and experience with PIM-over-TCP. Maybe he can = comment. And we also have a lot of history with BGP-over-TCP. I am rebuttaling some of your reasons why. That=E2=80=99s all. > However, note that as Fabio and Johnson mentioned at the beginning of = the thread, both LISP encoding of messages and UDP based signaling are = preserved with the reliable transport implementation. xTRs that can take = advantage of=20 Right, that should be made more clear in the next revision to the draft. = And looks like Fabio is already thinking of that (my reply is pending). Dino From nobody Thu Dec 7 23:06:53 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1924E124BE8 for ; Thu, 7 Dec 2017 23:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukB6UEcKwQlQ for ; Thu, 7 Dec 2017 23:06:49 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86197124B17 for ; Thu, 7 Dec 2017 23:06:49 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id b5so2920076itc.3 for ; Thu, 07 Dec 2017 23:06:49 -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:content-transfer-encoding; bh=GfkcGpJvsHjDQXIzeiyJfEqwIG3zY+lYTM0LbCPC0Ww=; b=kd78Ehd/IUGmDmlyUOPQKiaNdyLshpDJq3EUJkOD7eNf6d4ONq2xpFDVG/xhM0gx5w muG06Y7+zdB/coTMZhfdAzSfUcRCJ5WXIhZDmIuzqBGPI/7Avv5RLlbF8IVOG68Ifvso khfn6anihz9ALDHOHpHo/t9jdNnZyWPAVoLYLYEtcssRZssL6+UJw+knkDWNUqqgohXV mL2o73idI5D1VOGoDPUGfN8Hj8R9XeifZXt/xynK8j1Qr903+dkIvckQQ2XffDajhk/R jtvOPjUTr50uwATqlRl0CAIfrmvpjlSfuIuUs+gDCREcBkWnFowvp9FaH9Z+MdojUqBu asfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GfkcGpJvsHjDQXIzeiyJfEqwIG3zY+lYTM0LbCPC0Ww=; b=s3N301v7J8X6e+pjMtB2t70AiD07di0cVe/fIbE4Bm1YhxitumOihpM+msC/lAguli RZE6BEEit9GgLZXHpeO9Zg4byY5aKYE6icaaBd0XlR4x4vpmDc8ge3EvRRrl9BQfYDD1 1Ej7gX+5PYZupcx1dhBuolThAHOsXeKLN7XLCPzWZFIugwX+b3oSmZgkHWzIXdmI0v8i VjY/lE8JHyizo7jh8/Yl1Oa2XC4CAsTRxd7aRGiCGXiw7ujnZjSQqGsKo6QC2qZyURE7 avd4ZJBTIfd4JMYP74BR4sgJQaKCDXK7Mw44NqKjRA6jZa7RQ06FesXFq0Vc2afXQPAB QL0Q== X-Gm-Message-State: AKGB3mLBVpy+SfltDPs8Xdf9m9Pfti38/jr49iWz/lIeb/ce+5o/3Ken LKNlggXswh5r0pGULIfxMWi2QuwVN84MqWDGyG0= X-Google-Smtp-Source: AGs4zMZ9LCgR+JX9zC9c4s0IZ/kNpp82/ZmZ+7FNNHoPrqT10Pk3C28mKT/zx8IwWZb3mJL4k8VnD5eP5GEp4dvrORw= X-Received: by 10.107.181.147 with SMTP id e141mr5642624iof.117.1512716808590; Thu, 07 Dec 2017 23:06:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.181.70 with HTTP; Thu, 7 Dec 2017 23:06:28 -0800 (PST) In-Reply-To: <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com> References: <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com> From: Alberto Rodriguez-Natal Date: Thu, 7 Dec 2017 23:06:28 -0800 Message-ID: To: Dino Farinacci Cc: "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] Review of RFC6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 07:06:51 -0000 Hey Dino, Sorry for the delay on this. Mostly agree with your responses, thanks for the edits! There a few points that I would like to clarify. See below. >> For definitions of other terms -- notably Map-Request, Map-Reply, >> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please >> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >> >> =E2=80=A2 [AR] I think that the definitions for Map-Request and Map-R= eply >> should be moved here, and probably we should include the definition >> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >> control-plane messages, not the other way around. > > They did. But the text you identified above was not changed. Changed now. I meant that Map-Request and Map-Reply are not defined here (or anywhere else that I can find) and they should. The closest things are Encapsulated Map-Request and Negative Map Reply. >> The RLOCs in the Map-Reply are globally routable IP addresses of all >> ETRs for the LISP site. >> >> =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a >> "Generally" at the beginning since we might have LCAFs with AFI =3D 0 >> (LISP-VPN encoding of Home-IID for instance). > > Removed =E2=80=9Cglobally=E2=80=9D. I don=E2=80=99t understand your other= =E2=80=9CGenerally=E2=80=9D comment. My point was that in the LISP-VPN draft the Home-IID is encoded as an RLOC that it is not a routable address for the ETR. >> For example, a requester with two cached EID-Prefixes that are covered >> by a Map-Reply containing one less-specific prefix replaces the entry >> with the less-specific EID-Prefix. >> >> =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a >> less-specific received in a Map-Reply will erase from the map-cache >> previously cached more-specifics that are covered by the >> less-specific? > > Yes, because if the Map-Reply returned a more-specific with the less-spec= ific, then it would be replaced so the less-specific replaces the more-spec= ifics that ARE NOT in the Map-Reply. I think that I would rephrase this behavior to make it optional then. There are implementations which just return the entry that the requested EID hits and don't return by default any more-specifics below. >> When more than one EID-Prefix is returned, all SHOULD use the same >> Time to Live value so they can all time out at the same time. When a >> more-specific EID-Prefix is received later, its Time to Live value in >> the Map-Reply record can be stored even when other less-specific >> entries exist. >> >> =E2=80=A2 [AR] We should explain in which cases a more-specific can b= e >> received later. > > I don=E2=80=99t follow. Each EID-record will contain a TTL for the length= prefix that is encoded. So the new Map-Reply TTL will be used for any leng= th entry (and in this case the more-specific). My concern was that we should provide some context on when an ITR may receive a more-specific prefix that overlaps with an existing less-specific prefix already in its map-cache. One example is the EID mobility draft, we can reference it here. Thanks! Alberto From nobody Wed Dec 13 14:57:53 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66476128854 for ; Wed, 13 Dec 2017 14:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRcRxQKrSyre for ; Wed, 13 Dec 2017 14:57:50 -0800 (PST) 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 71DD61201F8 for ; Wed, 13 Dec 2017 14:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10885; q=dns/txt; s=iport; t=1513205870; x=1514415470; h=to:cc:from:subject:message-id:date:mime-version; bh=CKbvcIdmgFVR9Jo6ViS2TY5+UhEmlsCLtJCAonodPqQ=; b=bjVjcIpSV5HapUhoPBkje+VhXktk2LRzshZbMdesejyXhl601JXK/CQ/ p1+RbPvg9X3h8Paz5OA6c01mIGfOL6+3xOHJOgHX2/9Cp1Mwj43x9BgSm YwIdTCpBHy/gyd95JSzZXDKVxbhrj4ik1fUmrh7y2lomXHN37x3RQPqP7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAgDsrzFa/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnhAKZKIJ7kEaFTYIVCieBNQGDXgKFE0EWAQEBAQEBAQE?= =?us-ascii?q?Bax0LhSMBKVYZEwMBAisCUQ4NBgIBAYokEIsknWyCJyaKOwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGQWDYIILgVaBaSmCTIF/gWUBGIEvR4J1gmMFilOIVY93h3uNLII?= =?us-ascii?q?WiX2HVYpFgkuJVoE7JgQugU4yGggbFYJjglMMEBmBbyA3BYdfgkgBAQE?= X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208,217";a="335089754" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 22:57:25 +0000 Received: from [10.155.69.203] (dhcp-10-155-69-203.cisco.com [10.155.69.203]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vBDMvOI9015549; Wed, 13 Dec 2017 22:57:24 GMT To: "lisp@ietf.org" From: Fabio Maino Message-ID: Date: Wed, 13 Dec 2017 14:57:24 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------0309BA00DBB7C04D404BF83D" Content-Language: en-US Archived-At: Subject: [lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:57:52 -0000 This is a multi-part message in MIME format. --------------0309BA00DBB7C04D404BF83D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have refreshed the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit compatible with the data plane encoding in RFC6830bis, as discussed in the thread started on Nov. 29 (https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?qid=a7da0673ad7ed2a161aa5f4334f96f19). As a summary of the long thread: - bit 5 is allocated as P-bit to indicate the presence of an 8-bit Next Protocol field - the Next Protocol field shares 8 bits with the Nonce/Map-Version field - when the P-bit is set, the Nonce/Map-Version features are still available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields Thanks, Fabio -------- Forwarded Message -------- Subject: [lisp] RFC6830bis and multiprotocol support Date: Wed, 29 Nov 2017 14:32:40 -0800 From: Fabio Maino To: lisp@ietf.org I would like to suggest a way to address mutiprotocol support in RFC6830bis, that may address what was discussed in Singapore. This is based on using the last reserved bit in the LISP header as P bit to indicate support for multiprotocol encapsulation, as specified in the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe). The header, as specified in section 5.1, would look like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L|N|L|E|V|I|P|K|K|Nonce/Map-Version/Next-Protocol| I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / |Instance ID/Locator-Status-Bits| P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and the text in section 5.3 that reserves the 6th bit would be replaced by: P: The P-bit is the Next Protocol bit. When this bit is set to 1, the V-bit MUST be set to 0 and the Nonce length, when used, is       limited to 16 bits. Refer to[draft-lewis-lisp-gpe] for more details.       The P-bit is set to 1to indicate the presence of the 8 bit Next       Protocol field encoded as: x x x 0 x 1 x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|P|K|K|         Nonce | Next-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Instance ID/Locator-Status-Bits| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I will have to refresh the LISP-GPE draft, and reflect the allocations of the KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE to indicate OAM packets, but that same functionality can be done using the Next-Protocol field. The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that. This would address the multiprotocol working item included in the current charter. I can very quickly update the LISP-GPE draft to reflect this, but I wanted to hear what the group thinks first. Thanks, Fabio --------------0309BA00DBB7C04D404BF83D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I have refreshed the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit compatible with the data plane encoding in RFC6830bis, as discussed in the thread started on Nov. 29 (https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?qid=a7da0673ad7ed2a161aa5f4334f96f19).

As a summary of the long thread:

- bit 5 is allocated as P-bit to indicate the presence of an 8-bit Next Protocol field

- the Next Protocol field shares 8 bits with the Nonce/Map-Version field

- when the P-bit is set, the Nonce/Map-Version features are still available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields


Thanks,

Fabio



-------- Forwarded Message --------

Subject: [lisp] RFC6830bis and multiprotocol support
Date: Wed, 29 Nov 2017 14:32:40 -0800
From: Fabio Maino <fmaino@cisco.com>
To: lisp@ietf.org <lisp@ietf.org>


I would like to suggest a way to address mutiprotocol support in RFC6830bis, that may address what was discussed in Singapore.

This is based on using the last reserved bit in the LISP header as P bit to indicate support for multiprotocol encapsulation, as specified in the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).

The header, as specified in section 5.1, would look like:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|P|K|K|            Nonce/Map-Version/Next-Protocol    |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 and the text in section 5.3 that reserves the 6th bit would be replaced by:

   P: The P-bit is the Next Protocol bit. When this bit is set to
      1, the V-bit MUST be set to 0 and the Nonce length, when used, is
      limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details.
      The P-bit is set to 1 to indicate the presence of the 8 bit Next
      Protocol field encoded as:

     x x x 0 x 1 x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|P|K|K|           Nonce               | Next-Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator-Status-Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the allocations of the KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE to indicate OAM packets, but that same functionality can be done using the Next-Protocol field.

The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that.

This would address the multiprotocol working item included in the current charter.

I can very quickly update the LISP-GPE draft to reflect this, but I wanted to hear what the group thinks first.

Thanks,
Fabio







--------------0309BA00DBB7C04D404BF83D-- From nobody Wed Dec 13 15:02:20 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DDE128AA1 for ; Wed, 13 Dec 2017 15:02:15 -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, FREEMAIL_FROM=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 OZU7GiWzO7rA for ; Wed, 13 Dec 2017 15:02:11 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CB91201F8 for ; Wed, 13 Dec 2017 15:02:11 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id k134so2099120pga.3 for ; Wed, 13 Dec 2017 15:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EbiJVRHOrYKuqfyT9bghhvgoRs5wCqI7Lf+fZ9FF9gs=; b=AgzwssVlyDUOgPq/qk/FVqYmqfK1/ankZhkRILeGuz4u/9XAbNBxUcgW1GSGccq9yJ iNStSLpH5HhbXvPPGKmXNncFVfj+NB9Ts0jdqms08lrb9A/v7An+5UMtAhNyBZRcDJnv gckg/Ls8B5NSJzog+ordapzNQWINlZslK3HPlSapRYUGIHvLkrSCxzwxcfnlAqA2qEm3 1gOUaqPpskZr+p9NEUggFFU0f1XrUgpNYN/Hk8dlE0pfFdOva750tX5bFju17zDwyD1o l8SYTYA/QERki3NI4wcoqesyoV1QTROrvNGvFSkScSdNjJtukcdTWipac+ZSpCU8FFUm 4HwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EbiJVRHOrYKuqfyT9bghhvgoRs5wCqI7Lf+fZ9FF9gs=; b=q4ufuR4p0zTFvQxy3hq/NITRtfJTBZkYfOOLl2UyVcLuWdHDZGSctsiV12kSGLgf3M YS13IIKwK8w4RdaSnFGoJ5yHUgehJ4oO0GRDx4MNMJrQoACM7/BcExzQ6GmQLBiAeEzk vVMVTRfaTvWrzmNnQP38h23TAF7xq3Kfi1m0kmYUc23PAXnZaM/GMjRIiIQPZFmdqxFJ AEalByqmyELgPsFTGAafur9dIp/qYWlXZy7VTJmD7P3mAXxpm3ocke4wp85v0LkfLwak SH3iZYXeLjIfH1J0HK5K0sXoTIUJ0M1iFytzEXt3f2ypS/bWqaLNdWFXxyNynnAexZRy DmAg== X-Gm-Message-State: AKGB3mI3Tp5WzkFSgk5XOVZnFkP211oIAZxTgiplD7EDszQTfK0stiBE tpNqydqqE8RkEtAG2LGOIJw= X-Google-Smtp-Source: ACJfBotiRnVA9YzR/g7Xk8k4+ZghDY4Tz6Ve0UAuD39M9r7fzsG+aRO9Dv8cBFDj3xgNcry/aSgwMQ== X-Received: by 10.98.102.219 with SMTP id s88mr7627711pfj.191.1513206130741; Wed, 13 Dec 2017 15:02:10 -0800 (PST) Received: from dino-macbook.attlocal.net (adsl-108-94-3-68.dsl.pltn13.sbcglobal.net. [108.94.3.68]) by smtp.gmail.com with ESMTPSA id s14sm5531119pfe.36.2017.12.13.15.02.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 15:02:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: Date: Wed, 13 Dec 2017 15:02:07 -0800 Cc: "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <37D8903D-05CC-4954-B377-DF66D8500725@gmail.com> References: To: Fabio Maino X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 23:02:16 -0000 After I go through Alberto=E2=80=99s response for RFC6833bis and one = comment from Albert regarding RFC6830bis, I=E2=80=99ll document the = P-bit and reference this spec in RFC6830bis. I plan to send email this = week with both updates at one time. This should be the final updates to both specs. I=E2=80=99d like to = request last call and possibly complete it before year-end. Is that = possible chairs? Dino > On Dec 13, 2017, at 2:57 PM, Fabio Maino wrote: >=20 > I have refreshed the LISP-GPE draft = (https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit = compatible with the data plane encoding in RFC6830bis, as discussed in = the thread started on Nov. 29 = (https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?q= id=3Da7da0673ad7ed2a161aa5f4334f96f19).=20 > As a summary of the long thread:=20 > - bit 5 is allocated as P-bit to indicate the presence of an 8-bit = Next Protocol field >=20 > - the Next Protocol field shares 8 bits with the Nonce/Map-Version = field >=20 > - when the P-bit is set, the Nonce/Map-Version features are still = available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields >=20 > Thanks, >=20 > Fabio >=20 >=20 > -------- Forwarded Message -------- >=20 > Subject: [lisp] RFC6830bis and multiprotocol support > Date: Wed, 29 Nov 2017 14:32:40 -0800 > From: Fabio Maino > To: lisp@ietf.org >=20 > I would like to suggest a way to address mutiprotocol support in = RFC6830bis, that may address what was discussed in Singapore.=20 > This is based on using the last reserved bit in the LISP header as P = bit to indicate support for multiprotocol encapsulation, as specified in = the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).=20= > The header, as specified in section 5.1, would look like:=20 >=20 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol = | > I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > S / | Instance ID/Locator-Status-Bits = | > P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > and the text in section 5.3 that reserves the 6th bit would be = replaced by:=20 >=20 > P: The P-bit is the Next Protocol bit. When this bit is set to > 1, the V-bit MUST be set to 0 and the Nonce length, when used, = is=20 > limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more = details.=20 > The P-bit is set to 1 to indicate the presence of the 8 bit Next=20= > Protocol field encoded as: >=20 > x x x 0 x 1 x x > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > I will have to refresh the LISP-GPE draft, and reflect the allocations = of the KK bits according to RFC8061 and Nonce. One of the K bits was = used by LISP-GPE to indicate OAM packets, but that same functionality = can be done using the Next-Protocol field.=20 >=20 > The use of the P-bit is not compatible with the Map-Versioning = feature, but an equivalent function can be specified (if needed) with a = Next-Protocol shim header. I can add text to the LISP-GPE draft to = reflect that.=20 >=20 > This would address the multiprotocol working item included in the = current charter.=20 >=20 > I can very quickly update the LISP-GPE draft to reflect this, but I = wanted to hear what the group thinks first.=20 >=20 > Thanks, > Fabio >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Wed Dec 13 16:29:49 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72ACC1243FE for ; Wed, 13 Dec 2017 16:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVOLJ5XIR9vk for ; Wed, 13 Dec 2017 16:29:46 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A244F1200F1 for ; Wed, 13 Dec 2017 16:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3881; q=dns/txt; s=iport; t=1513211386; x=1514420986; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KFAKZ0WCB9yDCQqE3oRGbxEGwTqq2fNxOMjRnEZ6dbQ=; b=jLjRAaZ1028B/c5ZJSzBEXp3UARrKI6jmF5HE+sOZOq6f3PxxmTu2cYP LwzSEiDeF6vS3zXNpxD2znWH0IRNK+z4bpqHsPcpKtq7Y9s+b4/Is1mJm CcKGlYcXejN0vD4z9giLMMIGaLI1hSGxbTaMsPcRBOl53Dp2XapRqKR08 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAgBFxTFa/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnhAKZKIF9fpYTFIIBCieBNQGDXgKFE0EWAQEBAQEBAQE?= =?us-ascii?q?BayhCDgGEUgEBAQQjDwEFQRALEQMBAgECAiYCAk8IBg0GAgEBiiQQqSmCJ4pfA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4JRgguBVoFpKYJMNoFJgWUBGIEjAQs?= =?us-ascii?q?HAYM0gmMFilOIVYYqiU2He40sghaJfYdVikWCS4lWgTsmDSVgbjIaCBsVgmOCU?= =?us-ascii?q?wwQGYFvIDcFghSFSw8YgiEBAQE?= X-IronPort-AV: E=Sophos;i="5.45,399,1508803200"; d="scan'208";a="44332194" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 00:29:45 +0000 Received: from [10.155.69.203] (dhcp-10-155-69-203.cisco.com [10.155.69.203]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBE0TjqJ008736; Thu, 14 Dec 2017 00:29:45 GMT To: Dino Farinacci Cc: "lisp@ietf.org" References: <37D8903D-05CC-4954-B377-DF66D8500725@gmail.com> From: Fabio Maino Message-ID: <8b4a5ccb-e631-b887-7d43-33880adf34f8@cisco.com> Date: Wed, 13 Dec 2017 16:29:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <37D8903D-05CC-4954-B377-DF66D8500725@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 00:29:49 -0000 Thanks Dino. Fabio On 12/13/17 3:02 PM, Dino Farinacci wrote: > After I go through Alberto’s response for RFC6833bis and one comment from Albert regarding RFC6830bis, I’ll document the P-bit and reference this spec in RFC6830bis. I plan to send email this week with both updates at one time. > > This should be the final updates to both specs. I’d like to request last call and possibly complete it before year-end. Is that possible chairs? > > Dino > >> On Dec 13, 2017, at 2:57 PM, Fabio Maino wrote: >> >> I have refreshed the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit compatible with the data plane encoding in RFC6830bis, as discussed in the thread started on Nov. 29 (https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?qid=a7da0673ad7ed2a161aa5f4334f96f19). >> As a summary of the long thread: >> - bit 5 is allocated as P-bit to indicate the presence of an 8-bit Next Protocol field >> >> - the Next Protocol field shares 8 bits with the Nonce/Map-Version field >> >> - when the P-bit is set, the Nonce/Map-Version features are still available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields >> >> Thanks, >> >> Fabio >> >> >> -------- Forwarded Message -------- >> >> Subject: [lisp] RFC6830bis and multiprotocol support >> Date: Wed, 29 Nov 2017 14:32:40 -0800 >> From: Fabio Maino >> To: lisp@ietf.org >> >> I would like to suggest a way to address mutiprotocol support in RFC6830bis, that may address what was discussed in Singapore. >> This is based on using the last reserved bit in the LISP header as P bit to indicate support for multiprotocol encapsulation, as specified in the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >> The header, as specified in section 5.1, would look like: >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol | >> I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> S / | Instance ID/Locator-Status-Bits | >> P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> and the text in section 5.3 that reserves the 6th bit would be replaced by: >> >> P: The P-bit is the Next Protocol bit. When this bit is set to >> 1, the V-bit MUST be set to 0 and the Nonce length, when used, is >> limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details. >> The P-bit is set to 1 to indicate the presence of the 8 bit Next >> Protocol field encoded as: >> >> x x x 0 x 1 x x >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Instance ID/Locator-Status-Bits | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> I will have to refresh the LISP-GPE draft, and reflect the allocations of the KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE to indicate OAM packets, but that same functionality can be done using the Next-Protocol field. >> >> The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that. >> >> This would address the multiprotocol working item included in the current charter. >> >> I can very quickly update the LISP-GPE draft to reflect this, but I wanted to hear what the group thinks first. >> >> Thanks, >> Fabio >> >> >> >> >> >> >> From nobody Thu Dec 14 02:59:00 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BDE128656 for ; Thu, 14 Dec 2017 02:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u07rxiGMU3zA for ; Thu, 14 Dec 2017 02:58:56 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 7CCAD1241F3 for ; Thu, 14 Dec 2017 02:58:56 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id f9so10665250wmh.0 for ; Thu, 14 Dec 2017 02:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wgw47OMCIYU0zkWwMF6Y8HjfbH905+D5PXaG3TZwe6s=; b=ywPGTHXNvqovl2VZegaEJyPsQ+DP+ovGRk8aa8u6xxnLbIpj6UnIk44N1ZB6jmgrqS p1MKhCuJ4rbAJvWCJMHz+IrYRXsmfbq4Y8Jzt0eThESMIFlYKfmd0/mrMX7W6D5seeec GOKPJhww0o+xOpfH15eJAwa8vjJEaBCbNKVtVwpTphUFAbejXDb21jSlipE24UJyensb cUxFgIORhfmG/Hh6t6905TZ4kYodvrdEieBRyE9ALMuHToz0H8j98dGxCY5iIk/A6Loy klPtdjB2UFGF33ncFPSB3pobttf9RGLjFollR8hGU5A0Uec34yKPSR9IGn+gR7RCMaic 5MBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wgw47OMCIYU0zkWwMF6Y8HjfbH905+D5PXaG3TZwe6s=; b=JriQx7Rvtro4KkvFNLY8+ZK+UGZdmIKiZsVd9o85R9II7vYwjXxSQFk5c5Qiu2lWBA SNgQRmapc8YunZWJ0qTT5W/QAvmXzlJ+TYsoFolO/YqwAr/+EMX0afXsCVVxopwjthfw LqX/UWeg/xrBnAkHp26CDTM1feKYGGfwRqhm1JsefdYoloh3gNZOo/cDgr3Qjp1hM+QT FdaU3ez5ovYDLrnAsHOztCru5bkV+/mO0DloRpVrhLEK2YwxDrVavQKoRLNSzvFdqJXR fcp0QY9SDe44DpfH8SI4QcXqgJ/RCoX8PxG/ONNrJmee5qTwbfseLDN10vlVHKOw4JZm SMBw== X-Gm-Message-State: AKGB3mKp1PILWK98MaBlQA/LepfS3aMuckdVTcxC1pKVFIv/1ONCqr6q zk8MEBrq2oOPcskKKRlO9SLdRw== X-Google-Smtp-Source: ACJfBos9/pt6joP7jyTlEg4aGcv1u7chcqTrtkXZnFG32DGp0p4TM33PjzezXciOYP5Rt1enbYyqIw== X-Received: by 10.80.190.135 with SMTP id b7mr12029316edk.282.1513249134878; Thu, 14 Dec 2017 02:58:54 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:d191:665:b2ac:7afa? ([2001:660:330f:a4:d191:665:b2ac:7afa]) by smtp.gmail.com with ESMTPSA id f11sm3258075edf.28.2017.12.14.02.58.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 02:58:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Luigi Iannone In-Reply-To: <37D8903D-05CC-4954-B377-DF66D8500725@gmail.com> Date: Thu, 14 Dec 2017 11:58:34 +0100 Cc: Fabio Maino , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8F96DB47-1F3C-489C-B2EF-F20D500AE8E3@gigix.net> References: <37D8903D-05CC-4954-B377-DF66D8500725@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 10:58:59 -0000 > On 14 Dec 2017, at 00:02, Dino Farinacci wrote: >=20 > After I go through Alberto=E2=80=99s response for RFC6833bis and one = comment from Albert regarding RFC6830bis, I=E2=80=99ll document the = P-bit and reference this spec in RFC6830bis. I plan to send email this = week with both updates at one time. >=20 > This should be the final updates to both specs. I=E2=80=99d like to = request last call and possibly complete it before year-end. Is that = possible chairs? >=20 I will send out my review of 6830bis this weekend at latest.=20 If we converge we can certainly last call the 6830bis while I=E2=80=99ll = review the 6833bis and move it forward right after.=20 L. > Dino >=20 >> On Dec 13, 2017, at 2:57 PM, Fabio Maino wrote: >>=20 >> I have refreshed the LISP-GPE draft = (https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit = compatible with the data plane encoding in RFC6830bis, as discussed in = the thread started on Nov. 29 = (https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?q= id=3Da7da0673ad7ed2a161aa5f4334f96f19).=20 >> As a summary of the long thread:=20 >> - bit 5 is allocated as P-bit to indicate the presence of an 8-bit = Next Protocol field >>=20 >> - the Next Protocol field shares 8 bits with the Nonce/Map-Version = field >>=20 >> - when the P-bit is set, the Nonce/Map-Version features are still = available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields >>=20 >> Thanks, >>=20 >> Fabio >>=20 >>=20 >> -------- Forwarded Message -------- >>=20 >> Subject: [lisp] RFC6830bis and multiprotocol support >> Date: Wed, 29 Nov 2017 14:32:40 -0800 >> From: Fabio Maino >> To: lisp@ietf.org >>=20 >> I would like to suggest a way to address mutiprotocol support in = RFC6830bis, that may address what was discussed in Singapore.=20 >> This is based on using the last reserved bit in the LISP header as P = bit to indicate support for multiprotocol encapsulation, as specified in = the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).=20= >> The header, as specified in section 5.1, would look like:=20 >>=20 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol = | >> I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> S / | Instance ID/Locator-Status-Bits = | >> P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> and the text in section 5.3 that reserves the 6th bit would be = replaced by:=20 >>=20 >> P: The P-bit is the Next Protocol bit. When this bit is set to >> 1, the V-bit MUST be set to 0 and the Nonce length, when used, = is=20 >> limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more = details.=20 >> The P-bit is set to 1 to indicate the presence of the 8 bit Next=20= >> Protocol field encoded as: >>=20 >> x x x 0 x 1 x x >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Instance ID/Locator-Status-Bits | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> I will have to refresh the LISP-GPE draft, and reflect the = allocations of the KK bits according to RFC8061 and Nonce. One of the K = bits was used by LISP-GPE to indicate OAM packets, but that same = functionality can be done using the Next-Protocol field.=20 >>=20 >> The use of the P-bit is not compatible with the Map-Versioning = feature, but an equivalent function can be specified (if needed) with a = Next-Protocol shim header. I can add text to the LISP-GPE draft to = reflect that.=20 >>=20 >> This would address the multiprotocol working item included in the = current charter.=20 >>=20 >> I can very quickly update the LISP-GPE draft to reflect this, but I = wanted to hear what the group thinks first.=20 >>=20 >> Thanks, >> Fabio >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Dec 14 02:59:15 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7D128B88 for ; Thu, 14 Dec 2017 02:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4EfHaU2HqZk for ; Thu, 14 Dec 2017 02:59:01 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 B5A9F128656 for ; Thu, 14 Dec 2017 02:59:00 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id t8so10455482wmc.3 for ; Thu, 14 Dec 2017 02:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XtMzhMgF5RkiVzSNkRWeG+j4xeJPbobLehoLcg13aaM=; b=XrGUllt60Oon2WxReiqF+OsYaJ48ie432L5TueMTYSvx6Uw7aEvIDsGWjHRExEeRzu F/cCaYUgS9AIz3uzi9LihcsrztOtLzFNkOqsIbQ1CSwRbdc2SGKHx0cdBUYahXyx29d3 X7M5yPIsS01OudR1rUJg1MmvwdD/fHIa0FKGCgDB5qj6JpXLmUMma6xW7hF5tQcfVOJ8 zVytKPx4J0KASLqk9JDRQfmVKC+1gIv7O+mrkbZTyjnas7Pxn7bUlkJJrkUgeATu8/q1 CoePVA3wSswF/VqhnfiAyiJV2+s/zHgandIWqW18hGSo/OPv4Jt5nBE7e4cSfw9PIWJg BBlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XtMzhMgF5RkiVzSNkRWeG+j4xeJPbobLehoLcg13aaM=; b=qCYwtB4l6dLPq8LkMTrUUmyyd5AhmgNCcbpOGjjp5lEh18+O+NHhtfr6I0tCJiBq2z VS3eE+FuBQqVZg+4gqGh8AVnUZnR/D2oWAHKGqxnD366/8qSe/Uw+ntGBBmhjL7p1/An VELKGvN60ekT5qAzj6mmVlw2+9ANccikYEM9dfINC4808xc1oCFXObOYqo0iICws0SqI j9+g7EQMij/EbCfuQb3sHBjxFqZOvuXjnySTzNW8XuCTGjjWysJncmnGdHRRCd6hNhqT zsfFO/IbcXGl6QeA722tJG61xVzeMZj/l1zW2zLZceOMyzFvEBIdiul6YsBvuKJYje5D 2YXQ== X-Gm-Message-State: AKGB3mKYqWMePNxqcNU6PKJYm8Xo2jWwLCRzLNdVGHXdeoWAsozmtY8j gbRBAk9yHhgIpCKjN/sAiJYE7w== X-Google-Smtp-Source: ACJfBotHEQ/xglGEZaCRelipOsufN0L00hEj98KWGpF7a1z+G/exqAIPjbQi8uefQRwKbrBYiIwk4A== X-Received: by 10.80.130.39 with SMTP id 36mr11736832edf.297.1513249139190; Thu, 14 Dec 2017 02:58:59 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:d191:665:b2ac:7afa? ([2001:660:330f:a4:d191:665:b2ac:7afa]) by smtp.gmail.com with ESMTPSA id f11sm3258075edf.28.2017.12.14.02.58.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 02:58:58 -0800 (PST) From: Luigi Iannone Message-Id: <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B6403A48-582B-448B-B2D3-950D09539FBA" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 14 Dec 2017 11:58:39 +0100 In-Reply-To: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> Cc: "lisp@ietf.org" To: Fabio Maino References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 10:59:14 -0000 --Apple-Mail=_B6403A48-582B-448B-B2D3-950D09539FBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 His All, happy to see so much consensus :-) As a chair I have to point out that if you add text in 6830bis to = allocate the last bit and refer to draft-lewis-lisp-gpe you are creating = an authoritative dependency on a to a document that as for now is not = even WG item. This will block the publication of 6830bis as RFC (remember the intro = document=E2=80=A6=E2=80=A6.). There are two possible solutions: A. 6830bis remains unchanged, leaving the P-bit marked as reserved for = future use. draft-lewis-lisp-gpe will than allocate this last bit and = detail the operations.=20 B. We merge the two documents. I do not have a preference, up to the WG to decide, but better to avoid = document dependencies that will block publication. Ciao L. > On 29 Nov 2017, at 23:32, Fabio Maino wrote: >=20 > I would like to suggest a way to address mutiprotocol support in = RFC6830bis, that may address what was discussed in Singapore.=20 > This is based on using the last reserved bit in the LISP header as P = bit to indicate support for multiprotocol encapsulation, as specified in = the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe = ).=20 > The header, as specified in section 5.1, would look like:=20 >=20 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol = | > I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > S / | Instance ID/Locator-Status-Bits = | > P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > and the text in section 5.3 that reserves the 6th bit would be = replaced by:=20 >=20 > P: The P-bit is the Next Protocol bit. When this bit is set to > 1, the V-bit MUST be set to 0 and the Nonce length, when used, = is=20 > limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more = details.=20 > The P-bit is set to 1 to indicate the presence of the 8 bit Next=20= > Protocol field encoded as: >=20 > x x x 0 x 1 x x > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > I will have to refresh the LISP-GPE draft, and reflect the allocations = of the KK bits according to RFC8061 and Nonce. One of the K bits was = used by LISP-GPE to indicate OAM packets, but that same functionality = can be done using the Next-Protocol field.=20 >=20 > The use of the P-bit is not compatible with the Map-Versioning = feature, but an equivalent function can be specified (if needed) with a = Next-Protocol shim header. I can add text to the LISP-GPE draft to = reflect that.=20 >=20 > This would address the multiprotocol working item included in the = current charter.=20 >=20 > I can very quickly update the LISP-GPE draft to reflect this, but I = wanted to hear what the group thinks first.=20 >=20 > Thanks, > Fabio >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_B6403A48-582B-448B-B2D3-950D09539FBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 His = All,

happy to see so = much consensus :-)

<chair hat on>

As a chair I have to point out that if = you add text in 6830bis to allocate the last bit and refer to = draft-lewis-lisp-gpe you are creating an authoritative dependency on a = to a document that as for now is not even WG item.
This will block the publication of 6830bis as RFC (remember = the intro document=E2=80=A6=E2=80=A6.).

There are two possible = solutions:

A. = 6830bis remains unchanged, leaving the P-bit marked as reserved for = future use. draft-lewis-lisp-gpe will than allocate this last bit and = detail the operations. 

B. We merge the two = documents.

I = do not have a preference, up to the WG to decide, but better to avoid = document dependencies that will block publication.

<chair hat = off>

Ciao

L.



On 29 Nov 2017, at 23:32, Fabio Maino <fmaino@cisco.com> = wrote:

=20 =20

I = would like to suggest a way to address mutiprotocol support in RFC6830bis, that may address what was discussed in Singapore.

This is based on using the last reserved bit in = the LISP header as P bit to indicate support for multiprotocol encapsulation, as specified in the LISP-GPE draft (https://tools.ie= tf.org/html/draft-lewis-lisp-gpe).

The header, as specified in section 5.1, would = look like:


       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    = L   = |N|L|E|V|I|P|K|K|          &nb= sp; Nonce/Map-Version/Next-Protocol    |
   = I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   = S / |          &nb= sp;      Instance ID/Locator-Status-Bits          &nb= sp;    |
   = P   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the text in section 5.3 that reserves the = 6th bit would be replaced by:

   P: The P-bit is the Next Protocol bit. When this bit is set to
      1, the V-bit MUST be set to 0 and the Nonce length, when used, is
      limited to 16 bits. Refer = to [draft-lewis-lisp-gpe] = for more details.
      The P-bit is set to = 1 = to indicate the presence of the 8 bit Next
      Protocol field encoded as: =

     x x x 0 x 1 x x
    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     = |N|L|E|V|I|P|K|K| =          Nonce =               | = Next-Protocol |
    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     = |          &nb= sp;      Instance ID/Locator-Status-Bits          &nb= sp;    |
    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I will have to refresh the LISP-GPE draft, and reflect the allocations of the KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE to indicate OAM packets, but that same functionality can be done using the Next-Protocol field.

The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that.

This would address the multiprotocol working item included in the current charter.

I can very quickly update the LISP-GPE draft to reflect this, but I wanted to hear what the group thinks first.

Thanks,
Fabio








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

= --Apple-Mail=_B6403A48-582B-448B-B2D3-950D09539FBA-- From nobody Thu Dec 14 08:59:18 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7F5128BA2 for ; Thu, 14 Dec 2017 08:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5doJBcsc3LVq for ; Thu, 14 Dec 2017 08:59:15 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB0F1288B8 for ; Thu, 14 Dec 2017 08:59:15 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id c204so4008107pfc.13 for ; Thu, 14 Dec 2017 08:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X9NkbJsgEkfmrbWEtknvC/Mnm8C14FHBasUAH1ypEcE=; b=QcuYbaM9DtZfEmYyQUP+2wciZcSPOsnznrx21DEQ87wE6Ftu5dheUQaN4bAG0u/dYu jzsnn1al4g3T7EOJEwwtg3v2igCMsQWPiKULRIDZewBbG+XrYmc9ZCcaOCR5yJhXEyts lpu7545JN3WJqlW2ytpRaw8v5vD93CcwdTnE4cDex/vfmRT2Kqs9p6PeTjGyLzUlebFB fDoBngNjyuCAfyeoPOiWtcijEuOX/qFql+g6rrsTM7gCRW+GM+vSEqOUsnslW7L2I36I 9V16zl9N3gxYTIz13Bz2k3z0AmfSo04rfFdhCIln/5nzaRpF5HtE86kBSaLmL+QrqRLV S/Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X9NkbJsgEkfmrbWEtknvC/Mnm8C14FHBasUAH1ypEcE=; b=eqLK/eZnWAdiVJunY296wAnEN1AYXoqKdXNsWFwbphKDni4jPgjvt/neyL1Gs6x5no fR3ji8tNrC0pIiFFsxK2bPA0o1EP5lbnukZVvzdY0KL1K1zMUlUKbWn1p+ijuDQWZMVG vrjaI2ok7PqmvgnN0s7YGlUcR7o8tFLUOiT9G2fpPQVLVWdTh9m16Q55NotrdmNYouAJ HA2H0Fo5PFBbyYVGiP3oBt5RPH8+mcA3kFdvTuigSdhgMnG/kIqgy3vdk77jOPx7AmP4 +ybjD0QirBsAlTjt/xgTNiQOoT9LDmLkjWaU7mtshG7ax364rH/YrCcrgriNdnUJXS0q RaEg== X-Gm-Message-State: AKGB3mKjxuQIB9dh0AgidE21U8dYPjy9GQsAza9haDuDV/k1MCjWvqi6 HgcTsho4CJ3GY9XUu9b73YdH4CZj X-Google-Smtp-Source: ACJfBovLPIbP0toLkXSxyDha1i1PqOF8G/L9EmCFp1deoSqvbby5AhIDPWlnm9dshr1AsfisFa74ow== X-Received: by 10.159.218.152 with SMTP id w24mr10314048plp.43.1513270754735; Thu, 14 Dec 2017 08:59:14 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id s14sm9728584pfe.36.2017.12.14.08.59.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 08:59:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: <8F96DB47-1F3C-489C-B2EF-F20D500AE8E3@gigix.net> Date: Thu, 14 Dec 2017 08:59:09 -0800 Cc: Fabio Maino , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3C33B42E-169A-4108-B8FE-72055D6A48CE@gmail.com> References: <37D8903D-05CC-4954-B377-DF66D8500725@gmail.com> <8F96DB47-1F3C-489C-B2EF-F20D500AE8E3@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 16:59:18 -0000 I=E2=80=99ll try to get an update to you before then so it can be = easier. Thanks Luigi. Dino > On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >=20 >=20 >=20 >> On 14 Dec 2017, at 00:02, Dino Farinacci wrote: >>=20 >> After I go through Alberto=E2=80=99s response for RFC6833bis and one = comment from Albert regarding RFC6830bis, I=E2=80=99ll document the = P-bit and reference this spec in RFC6830bis. I plan to send email this = week with both updates at one time. >>=20 >> This should be the final updates to both specs. I=E2=80=99d like to = request last call and possibly complete it before year-end. Is that = possible chairs? >>=20 >=20 > I will send out my review of 6830bis this weekend at latest.=20 > If we converge we can certainly last call the 6830bis while I=E2=80=99ll= review the 6833bis and move it forward right after.=20 >=20 > L. >=20 >=20 >> Dino >>=20 >>> On Dec 13, 2017, at 2:57 PM, Fabio Maino wrote: >>>=20 >>> I have refreshed the LISP-GPE draft = (https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit = compatible with the data plane encoding in RFC6830bis, as discussed in = the thread started on Nov. 29 = (https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?q= id=3Da7da0673ad7ed2a161aa5f4334f96f19).=20 >>> As a summary of the long thread:=20 >>> - bit 5 is allocated as P-bit to indicate the presence of an 8-bit = Next Protocol field >>>=20 >>> - the Next Protocol field shares 8 bits with the Nonce/Map-Version = field >>>=20 >>> - when the P-bit is set, the Nonce/Map-Version features are still = available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields >>>=20 >>> Thanks, >>>=20 >>> Fabio >>>=20 >>>=20 >>> -------- Forwarded Message -------- >>>=20 >>> Subject: [lisp] RFC6830bis and multiprotocol support >>> Date: Wed, 29 Nov 2017 14:32:40 -0800 >>> From: Fabio Maino >>> To: lisp@ietf.org >>>=20 >>> I would like to suggest a way to address mutiprotocol support in = RFC6830bis, that may address what was discussed in Singapore.=20 >>> This is based on using the last reserved bit in the LISP header as P = bit to indicate support for multiprotocol encapsulation, as specified in = the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).=20= >>> The header, as specified in section 5.1, would look like:=20 >>>=20 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol = | >>> I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> S / | Instance ID/Locator-Status-Bits = | >>> P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>>=20 >>> and the text in section 5.3 that reserves the 6th bit would be = replaced by:=20 >>>=20 >>> P: The P-bit is the Next Protocol bit. When this bit is set to >>> 1, the V-bit MUST be set to 0 and the Nonce length, when used, = is=20 >>> limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more = details.=20 >>> The P-bit is set to 1 to indicate the presence of the 8 bit Next=20= >>> Protocol field encoded as: >>>=20 >>> x x x 0 x 1 x x >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Instance ID/Locator-Status-Bits | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>>=20 >>> I will have to refresh the LISP-GPE draft, and reflect the = allocations of the KK bits according to RFC8061 and Nonce. One of the K = bits was used by LISP-GPE to indicate OAM packets, but that same = functionality can be done using the Next-Protocol field.=20 >>>=20 >>> The use of the P-bit is not compatible with the Map-Versioning = feature, but an equivalent function can be specified (if needed) with a = Next-Protocol shim header. I can add text to the LISP-GPE draft to = reflect that.=20 >>>=20 >>> This would address the multiprotocol working item included in the = current charter.=20 >>>=20 >>> I can very quickly update the LISP-GPE draft to reflect this, but I = wanted to hear what the group thinks first.=20 >>>=20 >>> Thanks, >>> Fabio >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Thu Dec 14 09:01:31 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C02129431 for ; Thu, 14 Dec 2017 09:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08rhghph_CSf for ; Thu, 14 Dec 2017 09:01:28 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF43126C0F for ; Thu, 14 Dec 2017 09:01:28 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id k134so3794035pga.3 for ; Thu, 14 Dec 2017 09:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N4AXmTbxfHnVhzPmGqzmGJy2QbN1g5F/e0XRL7wFU1Y=; b=C4RWicKBSE679rUcrD9FlAY0Gb2WoLr9L/lYTMnZOp3JA0RTeyDZvHOPxIEsfJlPJP uGYdRpvfKJPIOmzr4Uyl4gBf4xJmpVKjmFx2drqntrqcxc0SYsNpKJK6dpvL1noGFld7 pMoeDhaQYNQ/BF3PSAsiiZ+6MQwMETWL5UrDGdFVYgUJ428WVNvcdjKVH58CQVT//QOd CSZACSo8XapEpd2DIq/gUtuVxldUzwmHp49LbozO5IkeZdUXKT87y5VRmv3kTvS27JOx dNNESt1NQjuYX77l7wxWN0qpFBMU2v6ltEOUZI8Gs8djwCjGzcW9ZQdnS1d8irwa9cmk gRgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N4AXmTbxfHnVhzPmGqzmGJy2QbN1g5F/e0XRL7wFU1Y=; b=LzLZze5Ji2IolG+aB3hALLomydi0veaE3wdfDOORs5Y20CslX3MVlwVaB/G/v8MQeJ 1jWi9SwA51iF5b8ZR9vW603RkK2hIYgQy9ukT3KCe7XUUxc03PCzKylbBaaph6DnolOu O05Kx7zRNg/uSi48UXHXhA0StFN4C41u7yggKAfAAqMwl+nYrY6Pu46uaQg5Ea9LmO8P +vyLExcvA6V86H5n1qVWFLZ0XuFOCgyvELDvlGvNvHE5PBpQN74ue0dPdnB8nTTvyWVk bUz95qSJvmiovuxCkzlnxG+cYUhM79Kfx0cRjslE+A/DKP+nKOJIcGgo4bOoWcyVipbs oAPw== X-Gm-Message-State: AKGB3mLL3rODMvwSFZtATMc6ebRhSgQ4/65B3u4ikqoKksISPsQkkZbF +YRXv21pZc+AxZQxEAZfDbs= X-Google-Smtp-Source: ACJfBos8IVPpQWBdfXNXJeF6C5YtdDzL+HWpLm/vBuXalph29qNWK9h5DKrhUH4zOL0ih5sWbVmI0w== X-Received: by 10.159.218.143 with SMTP id w15mr10534638plp.38.1513270887630; Thu, 14 Dec 2017 09:01:27 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id y3sm9036334pff.122.2017.12.14.09.01.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 09:01:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> Date: Thu, 14 Dec 2017 09:01:24 -0800 Cc: Fabio Maino , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:01:30 -0000 I would prefer to not merge the two documents. Should we say in = RFC6830bis that the R-bit is already allocated but don=E2=80=99t way why = and make no reference. If no, I go for option A. Dino > On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >=20 > His All, >=20 > happy to see so much consensus :-) >=20 > >=20 > As a chair I have to point out that if you add text in 6830bis to = allocate the last bit and refer to draft-lewis-lisp-gpe you are creating = an authoritative dependency on a to a document that as for now is not = even WG item. > This will block the publication of 6830bis as RFC (remember the intro = document=E2=80=A6=E2=80=A6.). >=20 > There are two possible solutions: >=20 > A. 6830bis remains unchanged, leaving the P-bit marked as reserved for = future use. draft-lewis-lisp-gpe will than allocate this last bit and = detail the operations.=20 >=20 > B. We merge the two documents. >=20 > I do not have a preference, up to the WG to decide, but better to = avoid document dependencies that will block publication. >=20 > >=20 > Ciao >=20 > L. >=20 >=20 >=20 >> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>=20 >> I would like to suggest a way to address mutiprotocol support in = RFC6830bis, that may address what was discussed in Singapore.=20 >> This is based on using the last reserved bit in the LISP header as P = bit to indicate support for multiprotocol encapsulation, as specified in = the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).=20= >> The header, as specified in section 5.1, would look like:=20 >>=20 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol = | >> I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> S / | Instance ID/Locator-Status-Bits = | >> P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> and the text in section 5.3 that reserves the 6th bit would be = replaced by:=20 >>=20 >> P: The P-bit is the Next Protocol bit. When this bit is set to >> 1, the V-bit MUST be set to 0 and the Nonce length, when used, = is=20 >> limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more = details.=20 >> The P-bit is set to 1 to indicate the presence of the 8 bit = Next=20 >> Protocol field encoded as: >>=20 >> x x x 0 x 1 x x >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Instance ID/Locator-Status-Bits | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> I will have to refresh the LISP-GPE draft, and reflect the = allocations of the KK bits according to RFC8061 and Nonce. One of the K = bits was used by LISP-GPE to indicate OAM packets, but that same = functionality can be done using the Next-Protocol field.=20 >>=20 >> The use of the P-bit is not compatible with the Map-Versioning = feature, but an equivalent function can be specified (if needed) with a = Next-Protocol shim header. I can add text to the LISP-GPE draft to = reflect that.=20 >>=20 >> This would address the multiprotocol working item included in the = current charter.=20 >>=20 >> I can very quickly update the LISP-GPE draft to reflect this, but I = wanted to hear what the group thinks first.=20 >>=20 >> Thanks, >> Fabio >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Dec 14 09:30:13 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BDD127871 for ; Thu, 14 Dec 2017 09:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 SYAeBz3jhsIV for ; Thu, 14 Dec 2017 09:30:03 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::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 824641293DA for ; Thu, 14 Dec 2017 09:30:03 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id b11so3832784pgu.13 for ; Thu, 14 Dec 2017 09:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=+95yBDOmqQu1hWfaGtJzABqxV2AiRwBHQ1pFpFEfbJU=; b=kD5smx1LKd1a2aNiKN2YYhJc2Zk1x6YQ5kmwC3/rL+kwM4J/c3oSlu3HoopoamH6E0 SYy6qXk9LVqvahyG8BPk2z/RdhoezQU6uHIUHgjofOq01319TqMrjhpL8CnP1+6/lU80 9YE68ZYfwrUlhGqxDSpZHbrEAUxgFmgYUM8BSAgi+fb0LCPGCEcFcUUQOpsiUMtExU2n CbzUp/MEZyKOOFjvigkxtyA0disurMtqZYVN/rIrmqsePiN8n6rHGVI0HbjNtAF09LYj UwzAJpmpuDoKoKd6iX2P9xltFauEWwXPb7D1Skg5R2PR/hJxkk7RKBcEAWyZaL/8YJUh CXqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=+95yBDOmqQu1hWfaGtJzABqxV2AiRwBHQ1pFpFEfbJU=; b=cY9qRehHuGRqonO/52kf0JO2IyAiWN1jVjBFpXf5/FU1b1z4LebVFAQTlSWZcBhF6P mw8dJZSvK3SfvNEp79pwrrkPonHbP434ixBq4cMa3jvgoJxLHM6w4t5FcuHyqSGL6gEo LCT4EIcLM2X0hdNHV1IAsk3QjQPBI2MzPen1vMmhbmKbGu72TP3r58uKtuHQiMsjHDme ci7jP/I4vum8Zn79suq1GJz2G2/zYiJVyWmAn5voL+cITNxTwXLthSo5vwuxuTq9cYbc irY+5KTPIC/4Ked1j8cOrpG/NS6c8m9uMSBmN56L/Y/clFR3ehG3LqoldIGmtReKaYEe SCqw== X-Gm-Message-State: AKGB3mIgkcWF9/VNvszM3lfhBJFE7bxqVtHeIV7uFAyEVLW8Bn/yjpKr Z7mdVdvsVobX18FRqnMC2Ms1eM7W X-Google-Smtp-Source: ACJfBousv6YuOqld48uLrwfUWdDCl6QUOadthmAN9BI1gXnW96PriUU492DFrgHi6BbqU1ta6YvAyw== X-Received: by 10.84.246.194 with SMTP id j2mr10142058plt.7.1513272602936; Thu, 14 Dec 2017 09:30:02 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id u18sm8618289pgn.72.2017.12.14.09.30.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 09:30:02 -0800 (PST) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_28678882-3DCE-4B72-AB7E-0465F4EC8221" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <63DB086D-DCB2-4461-A286-27B99DFF11DE@gmail.com> References: To: "lisp@ietf.org list" Date: Thu, 14 Dec 2017 09:30:02 -0800 X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [lisp] Fwd: [5gangip] 5G & IP Task Force - was: FW: Re: MINUTES of side meeting in Singapore X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:30:11 -0000 --Apple-Mail=_28678882-3DCE-4B72-AB7E-0465F4EC8221 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI. Dino > Begin forwarded message: >=20 > From: > Subject: Re: [5gangip] 5G & IP Task Force - was: FW: Re: MINUTES of = side meeting in Singapore > Date: December 14, 2017 at 9:12:04 AM PST > To: <5gangip@ietf.org> > Cc: Roland.Schott@telekom.de, sarikaya@ieee.org, farinacci@gmail.com, = alexandre.petrescu@gmail.com, RKunze@telekom.de >=20 > Dear all > Following the extensive discussions on this list in the last weeks we = propose to set up a task force group to work on: >=20 > 1. White paper on id-loc protocol concept evaluation for 5G as = planned by 3GPP similar to the one mentioned by Arash in the mail some = days ago = (https://mailarchive.ietf.org/arch/msg/5gangip/TVjXrlW5tbNsJ4ZLJfUPVemIYcA= ) but on different other id-loc separation protocol proposals as e.g. = ILNP and ILA (in case of approval to be submitted to 3GPP e.g. as = Temp.Doc. on solution proposal or somewhere else).=20 > More details to follow soon ... >=20 > 2. Work on an IETF draft describing how id-loc systems can be = applied to the upcoming 5G architectures. This document could be based = on (1) above (or identical) or it could be different. >=20 > Here are the list of people who agreed to serve and contribute in = general: Dino Farinacci, Peter Ashwood (with Arash), Saleem, Tom, and = Alex. > This is gratefully acknowledged! > Further volunteers' effort is more than welcome! >=20 > The work will consist possibly of bi-weekly conference calls starting = in the week of January 7, 2018. Webex calls will be announced on the = list so that other list members will also be able to attend the calls if = they wish to do so. >=20 > Thanks! > Best Regards > Dirk=20 >=20 > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip --Apple-Mail=_28678882-3DCE-4B72-AB7E-0465F4EC8221 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI.

Dino

Begin forwarded = message:

From: = <Dirk.von-Hugo@telekom.de>
Subject: = Re: [5gangip] 5G = & IP Task Force - was: FW: Re: MINUTES of side meeting in = Singapore
Date: = December 14, 2017 at 9:12:04 AM = PST
To: = <5gangip@ietf.org>
Cc: = Roland.Schott@telekom.de, sarikaya@ieee.org, farinacci@gmail.com, = alexandre.petrescu@gmail.com, RKunze@telekom.de

Dear all
Following the extensive discussions on = this list in the last weeks we propose to set up a task force group to = work on:

1. White paper on id-loc protocol = concept evaluation for 5G as planned by 3GPP similar to the one = mentioned by Arash in the mail some days ago (https://mailarchive.ietf.org/arch/msg/5gangip/TVjXrlW5tbNsJ4ZLJ= fUPVemIYcA) but on different other id-loc separation protocol = proposals as e.g. ILNP and ILA (in case of approval to be submitted to = 3GPP e.g. as Temp.Doc. on solution proposal or somewhere else).
More details to follow soon ...

2. = Work on an IETF draft describing how id-loc systems can be = applied to the upcoming 5G architectures. This document could be based = on (1) above (or identical) or it could be different.

Here are the list of people who agreed to serve and = contribute in general: Dino Farinacci, Peter Ashwood (with Arash), =  Saleem, Tom, and Alex.
This is gratefully = acknowledged!
Further volunteers' effort is more than = welcome!

The work will consist possibly of = bi-weekly conference calls starting in the week of January 7, 2018. = Webex calls will be announced on the list so that other list members = will also be able to attend the calls if they wish to do so.

Thanks!
Best Regards
Dirk

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

= --Apple-Mail=_28678882-3DCE-4B72-AB7E-0465F4EC8221-- From nobody Thu Dec 14 09:51:53 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE8612704A; Thu, 14 Dec 2017 09:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.403 X-Spam-Level: **** X-Spam-Status: No, score=4.403 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, GB_SUMOF=5, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 VZG3CoxVR3CX; Thu, 14 Dec 2017 09:51:39 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F74129431; Thu, 14 Dec 2017 09:51:39 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id u19so4120561pfa.12; Thu, 14 Dec 2017 09:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=iHGIYFOW0GvjVIhi5eswArezIegBggg5OQQDwhgK0VA=; b=MBbVLvyV+90PwGhvG+xx88DyhYOq/ZCnM0J1bCKphEfrYa4x6MsZ5OGtQDokGVBUPk FPlwj8oHnAGrmO/UPCfW5NrDDcy43Iza9q+fyCzqZfMfATj7jseRWGT/yc3Tj3WPEgwh 7ZG09Ref8rf1Le+svezCeRyq5plDtbnmWV9E5XhJG06lZ7TLiPjNA3UnysMg7iFH9Vhr uXzm9Y92r5J8CF9lNarTFeAfThrKANmcABuSI1XBdQ2A3JuLlwQmgy6Ylp9oQbmF2gud gDn6tnrRHIPhT/qSaHZKBtIssGKIY8gkPjy/VpjTpnLC59gPxrrlw4pJYgpf/ylu9uWc fuSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=iHGIYFOW0GvjVIhi5eswArezIegBggg5OQQDwhgK0VA=; b=cX82v6IWDb0KscPd0miJVUIv199lGTANuSIo/U9i6KGMYS4O181Mht2DMD/x1Kz1a6 UXBCn3UA/Wg4JpTxC6ppKAhmGrK7igFhnsAgx1xNxu5sG1TCyfKrY/3KRzmTeLMe5TEs arGGmDHdr/m2O30JbnWknNEQRkjmoDGKsbiFUpxxXngBCQTFo/csDv4WsHSQxUdA/pz5 BAtmT7XdbuzM4fnMk6iR9DGvaOPZq4dKFlxqmZp7rEU3bk1xDJ0WudLphbnayj8qsoOf uVZjRnZb3qxljKFRUaQ0v/yihf1mChcBYlk8PAGN6X54osaOeDUpWrl+niZCwiP1TajV cU2g== X-Gm-Message-State: AKGB3mLc1x1+dz9ZG2vkZsg+jE6gIw+MSHKaqa6GDqdS6owzqFcSBMZD nFdaegKkfw2HJ0X4E9YIZcEGH3tV X-Google-Smtp-Source: ACJfBouqK2sZSSm0jRfbPE5A+HrplpC4wDRUDGs5yQXzH9GXDeyFuypXswWeSEfKj1YywlynsS7bIw== X-Received: by 10.159.255.5 with SMTP id bi5mr10502224plb.30.1513273898290; Thu, 14 Dec 2017 09:51:38 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id s72sm7630215pgc.18.2017.12.14.09.51.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 09:51:37 -0800 (PST) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_9F936107-2DF3-41BC-9AED-122CAEAD32FD" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <7D866DE9-4AA8-47CD-A08E-34F22C66F138@gmail.com> Date: Thu, 14 Dec 2017 09:51:35 -0800 Cc: "lisp@ietf.org list" To: lisp-chairs@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [lisp] Edits to RFC6830bis pre-Luigi review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:51:51 -0000 --Apple-Mail=_9F936107-2DF3-41BC-9AED-122CAEAD32FD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Here you go Luigi. The -08 edits are simple and straight-forward. Dino --Apple-Mail=_9F936107-2DF3-41BC-9AED-122CAEAD32FD Content-Disposition: attachment; filename=rfcdiff-rfc6830bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-rfc6830bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-07.txt - = draft-ietf-lisp-rfc6830bis-08.txt=20 =20 =20 =20 =20 =20 =20 = = = = = = =
< draft-ietf-lisp-rfc6830bis-07.txt  =  draft-ietf-lisp-rfc6830bis-08.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Intended status: = Standards Track D. Meyer = Intended status: Standards Track = D. Meyer
Expires: May 15, 2018 = D. Lewis Expires: June 17, 2018 = D. Lewis
= Cisco Systems = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= November = 11, 2017 = December = 14, 2017
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-07 = = draft-ietf-lisp-rfc6830bis-08
=
Abstract = Abstract
=
This document = describes the data-plane protocol for the Locator/ID This document describes the data-plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local map-cache. The according to EID-to-RLOC mappings stored in a local = map-cache. The
=
skipping to = change at = page 1, line 46 =C2=B6 = skipping to change at page 1, line 46 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on May 15, = 2018. This Internet-Draft will = expire on June 17, 2018.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 41 =C2=B6 = skipping to change at page 2, line 41 =C2=B6
6. LISP = EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 = 6. LISP EID-to-RLOC Map-Cache . . . . . . = . . . . . . . . . . . 20
7. Dealing = with Large Encapsulated Packets . . . . . . . . . . . 20 = 7. Dealing with Large Encapsulated Packets = . . . . . . . . . . . 20
7.1. A = Stateless Solution to MTU Handling . . . . . . . . . . 21 = 7.1. A Stateless Solution to MTU Handling = . . . . . . . . . . 21
7.2. A = Stateful Solution to MTU Handling . . . . . . . . . . . 22 = 7.2. A Stateful Solution to MTU Handling = . . . . . . . . . . . 22
8. Using = Virtualization and Segmentation with LISP . . . . . . . 22 = 8. Using Virtualization and Segmentation = with LISP . . . . . . . 22
9. Routing = Locator Selection . . . . . . . . . . . . . . . . . . 23 = 9. Routing Locator Selection . . . . . . . = . . . . . . . . . . . 23
10. Routing = Locator Reachability . . . . . . . . . . . . . . . . 24 = 10. Routing Locator Reachability . . . . . = . . . . . . . . . . . 24
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 27
10.2. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 = 10.2. RLOC-Probing Algorithm . . . . . . = . . . . . . . . . . . 28
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 29 = 11. EID Reachability within a LISP Site . . = . . . . . . . . . . . 29
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 30 12. = Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 31 13. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30
13.1. = Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32 13.1. = Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31
13.2. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 = 13.2. Solicit-Map-Request (SMR) . . . . = . . . . . . . . . . . 32
13.3. = Database Map-Versioning . . . . . . . . . . . . . . . . 34 = 13.3. Database Map-Versioning . . . . . = . . . . . . . . . . . 34
14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 35 14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 34
15. Router = Performance Considerations . . . . . . . . . . . . . . 35 = 15. Router Performance Considerations . . . = . . . . . . . . . . . 35
16. Mobility = Considerations . . . . . . . . . . . . . . . . . . . 36 = 16. Mobility Considerations . . . . . . . . = . . . . . . . . . . . 36
16.1. Slow = Mobility . . . . . . . . . . . . . . . . . . . . . 36 = 16.1. Slow Mobility . . . . . . . . . . = . . . . . . . . . . . 36
16.2. Fast = Mobility . . . . . . . . . . . . . . . . . . . . . 36 = 16.2. Fast Mobility . . . . . . . . . . = . . . . . . . . . . . 36
16.3. LISP = Mobile Node Mobility . . . . . . . . . . . . . . . 37 = 16.3. LISP Mobile Node Mobility . . . . = . . . . . . . . . . . 37
17. LISP xTR = Placement and Encapsulation Methods . . . . . . . . 38 17. LISP = xTR Placement and Encapsulation Methods . . . . . . . . 37
17.1. = First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 = 17.1. First-Hop/Last-Hop xTRs . . . . . = . . . . . . . . . . . 39
17.2. = Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 = 17.2. Border/Edge xTRs . . . . . . . . . = . . . . . . . . . . . 39
17.3. ISP = Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 = 17.3. ISP Provider Edge (PE) xTRs . . . = . . . . . . . . . . . 40
17.4. LISP = Functionality with Conventional NATs . . . . . . . 40 = 17.4. LISP Functionality with = Conventional NATs . . . . . . . 40
17.5. = Packets Egressing a LISP Site . . . . . . . . . . . . . 41 = 17.5. Packets Egressing a LISP Site . . = . . . . . . . . . . . 41
18. Traceroute = Considerations . . . . . . . . . . . . . . . . . . 41 18. Traceroute Considerations . . . . . . . . . . . . = . . . . . . 41
18.1. IPv6 = Traceroute . . . . . . . . . . . . . . . . . . . . 42 = 18.1. IPv6 Traceroute . . . . . . . . . = . . . . . . . . . . . 42
18.2. IPv4 = Traceroute . . . . . . . . . . . . . . . . . . . . 42 = 18.2. IPv4 Traceroute . . . . . . . . . = . . . . . . . . . . . 42
18.3. = Traceroute Using Mixed Locators . . . . . . . . . . . . 43 = 18.3. Traceroute Using Mixed Locators . = . . . . . . . . . . . 43
19. Security = Considerations . . . . . . . . . . . . . . . . . . . 43 = 19. Security Considerations . . . . . . . . = . . . . . . . . . . . 43
20. Network = Management Considerations . . . . . . . . . . . . . . 44 = 20. Network Management Considerations . . . = . . . . . . . . . . . 44
21. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 44 = 21. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 44
21.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 44 = 21.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 44
22. References = . . . . . . . . . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . = . . . . . . 44
22.1. = Normative References . . . . . . . . . . . . . . . . . . 44 = 22.1. Normative References . . . . . . . = . . . . . . . . . . . 44
22.2. = Informative References . . . . . . . . . . . . . . . . . 47 = 22.2. Informative References . . . . . . = . . . . . . . . . . . 47
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 51 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 51
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 51 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 51
B.1. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52 B.1. = Changes to draft-ietf-lisp-rfc6830bis-08 = . . . . . . . . 52
B.2. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52 B.2. = Changes to draft-ietf-lisp-rfc6830bis-07 = . . . . . . . . 52
B.3. = Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 52 B.3. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52
B.4. = Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 52 B.4. = Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 52
B.5. = Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 53 B.5. = Changes to draft-ietf-lisp-rfc6830bis-04 = . . . . . . . . 53
B.6. = Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 53 B.6. = Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 53
B.7. = Changes to draft-ietf-lisp-rfc6830bis-01 = . . . . . . . . 53 B.7. = Changes to draft-ietf-lisp-rfc6830bis-02 = . . . . . . . . 53
B.8. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 = B.8. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53
= B.9. = Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 53
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
=
skipping to = change at = page 5, line 25 =C2=B6 = skipping to change at page 5, line 25 =C2=B6
lookup or = Session Initiation Protocol (SIP) [RFC3261] exchange. lookup or Session Initiation Protocol (SIP) = [RFC3261] exchange.
The source = EID is obtained via existing mechanisms used to set a The source EID is obtained via existing mechanisms = used to set a
host's = "local" IP address. An EID used on the public Internet = host's "local" IP address. An EID used = on the public Internet
must have = the same properties as any other IP address used in that = must have the same properties as any = other IP address used in that
manner; = this means, among other things, that it must be globally = manner; this means, among other things, = that it must be globally
unique. An = EID is allocated to a host from an EID-Prefix block unique. An EID is allocated to a host from an = EID-Prefix block
associated = with the site where the host is located. An EID can be = associated with the site where the host = is located. An EID can be
used by a = host to refer to other hosts. Note that EID blocks MAY = used by a host to refer to other hosts. = Note that EID blocks MAY
be assigned = in a hierarchical manner, independent of the network be assigned in a hierarchical manner, independent = of the network
topology, = to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping = database. In
addition, = an EID block assigned to a site may have = site-local addition, an EID = block assigned to a site MAY have = site-local
structure = (subnetting) for routing within the site; this structure = structure (subnetting) for routing within = the site; this structure
is not = visible to the global routing system. In theory, the bit = is not visible to the global routing = system. In theory, the bit
string that = represents an EID for one device can represent an RLOC string that represents an EID for one device can = represent an RLOC
for a = different device. As the architecture is realized, if a = for a different device. As the = architecture is realized, if a
given bit = string is both an RLOC and an EID, it must refer to the = given bit string is both an RLOC and an = EID, it must refer to the
same entity = in both cases. When used in discussions with other same entity in both cases. When used in = discussions with other
Locator/ID = separation proposals, a LISP EID will be called an Locator/ID separation proposals, a LISP EID will = be called an
"LEID". = Throughout this document, any references to "EID" refer = "LEID". Throughout this document, any = references to "EID" refer
to an = LEID. to an LEID.
=
=
skipping to = change at = page 9, line 20 =C2=B6 = skipping to change at page 9, line 20 =C2=B6
in the edge = network are the demarcation points to separate the in the edge network are the demarcation points to = separate the
edge = network from the core network. = edge network from the core network.
=
Client-side: = Client-side is a term used in this document to indicate = Client-side: Client-side is a term used in = this document to indicate
a = connection initiation attempt by an EID. The ITR(s) at the = LISP a connection initiation = attempt by an EID. The ITR(s) at the LISP
site are = the first to get involved in obtaining database Map-Cache = site are the first to get involved in = obtaining database Map-Cache
entries by = sending Map-Request messages. = entries by sending Map-Request messages.
=
Server-side: = Server-side is a term used in this document to indicate = Server-side: Server-side is a term used in = this document to indicate
that a = connection initiation attempt is being accepted for a that a connection initiation attempt is being = accepted for a
= destination EID. The ETR(s) at the destination LISP site may be = destination EID. The ETR(s) at the destination LISP site MAY be
the first = to send Map-Replies to the source site initiating the the first to send Map-Replies to the source site = initiating the
connection. = The ETR(s) at this destination site can obtain connection. The ETR(s) at this destination site = can obtain
mappings by = gleaning information from Map-Requests, Data-Probes, mappings by gleaning information from = Map-Requests, Data-Probes,
or = encapsulated packets. or = encapsulated packets.
=
= Locator-Status-Bits (LSBs): Locator-Status-Bits are present in = the Locator-Status-Bits (LSBs): = Locator-Status-Bits are present in the
LISP = header. They are used by ITRs to inform ETRs about the up/ = LISP header. They are used by ITRs to = inform ETRs about the up/
down status = of all ETRs at the local site. These bits are used as down status of all ETRs at the local site. These = bits are used as
a hint to = convey up/down router status and not path reachability a hint to convey up/down router status and not = path reachability
status. = The LSBs can be verified by use of one of the Locator status. The LSBs can be verified by use of one of = the Locator
=
skipping to = change at = page 10, line 38 =C2=B6 = skipping to change at page 10, line = 38 =C2=B6
o Other types = of EID are supported by LISP, see [RFC8060] for o Other types of EID are supported by LISP, see = [RFC8060] for
further = information. further = information.
=
o LISP = routers mostly deal with Routing Locator addresses. See = o LISP routers mostly deal with Routing = Locator addresses. See
details in = Section 4.1 to clarify what is meant by "mostly". details in Section 4.1 to clarify what is meant by = "mostly".
=
o RLOCs are = always IP addresses assigned to routers, preferably o RLOCs are always IP addresses assigned to routers, = preferably
= topologically oriented addresses from provider CIDR (Classless = topologically oriented addresses from = provider CIDR (Classless
= Inter-Domain Routing) blocks. = Inter-Domain Routing) blocks.
=
o When a = router originates packets, it may use as a = source address o When a router = originates packets, it MAY use as a source = address
either an = EID or RLOC. When acting as a host (e.g., when either an EID or RLOC. When acting as a host = (e.g., when
terminating = a transport session such as Secure SHell (SSH), terminating a transport session such as Secure = SHell (SSH),
TELNET, = or the Simple Network Management Protocol (SNMP)), it may = TELNET, or the Simple Network Management Protocol (SNMP)), it MAY
use an EID = that is explicitly assigned for that purpose. An EID use an EID that is explicitly assigned for that = purpose. An EID
that = identifies the router as a host MUST NOT be used as an RLOC; = that identifies the router as a host MUST = NOT be used as an RLOC;
an EID is = only routable within the scope of a site. A typical BGP = an EID is only routable within the scope = of a site. A typical BGP
= configuration might demonstrate this "hybrid" EID/RLOC usage = where configuration might = demonstrate this "hybrid" EID/RLOC usage where
a router = could use its "host-like" EID to terminate iBGP sessions = a router could use its "host-like" EID to = terminate iBGP sessions
to other = routers in a site while at the same time using RLOCs to = to other routers in a site while at the = same time using RLOCs to
terminate = eBGP sessions to routers outside the site. terminate eBGP sessions to routers outside the = site.
=
o Packets = with EIDs in them are not expected to be delivered end-to- = o Packets with EIDs in them are not = expected to be delivered end-to-
end in the = absence of an EID-to-RLOC mapping operation. They are end in the absence of an EID-to-RLOC mapping = operation. They are
expected to = be used locally for intra-site communication or to be expected to be used locally for intra-site = communication or to be
= encapsulated for inter-site communication. encapsulated for inter-site communication.
=
o = EID-Prefixes are likely to be hierarchically assigned in a = manner o EID-Prefixes are likely = to be hierarchically assigned in a manner
that is = optimized for administrative convenience and to facilitate = that is optimized for administrative = convenience and to facilitate
scaling of = the EID-to-RLOC mapping database. The hierarchy is scaling of the EID-to-RLOC mapping database. The = hierarchy is
based on an = address allocation hierarchy that is independent of based on an address allocation hierarchy that is = independent of
the network = topology. the network = topology.
=
o EIDs = may also be structured (subnetted) in a = manner suitable for o EIDs MAY also be structured (subnetted) in a manner = suitable for
local = routing within an Autonomous System (AS). local routing within an Autonomous System = (AS).
=
An additional = LISP header MAY be prepended to packets by a TE-ITR An additional LISP header MAY be prepended to packets = by a TE-ITR
when = re-routing of the path for a packet is desired. A potential = when re-routing of the path for a packet is = desired. A potential
use-case for = this would be an ISP router that needs to perform use-case for this would be an ISP router that needs = to perform
Traffic = Engineering for packets flowing through its network. In such = Traffic Engineering for packets flowing = through its network. In such
a situation, = termed "Recursive Tunneling", an ISP transit acts as an = a situation, termed "Recursive Tunneling", = an ISP transit acts as an
additional = ITR, and the RLOC it uses for the new prepended header additional ITR, and the RLOC it uses for the new = prepended header
would be = either a TE-ETR within the ISP (along an intra-ISP traffic = would be either a TE-ETR within the ISP = (along an intra-ISP traffic
engineered = path) or a TE-ETR within another ISP (an inter-ISP traffic = engineered path) or a TE-ETR within another = ISP (an inter-ISP traffic
=
skipping to = change at = page 13, line 35 =C2=B6 = skipping to change at page 13, line = 35 =C2=B6
of the = addresses, strips the LISP header, and forwards packets to = of the addresses, strips the LISP = header, and forwards packets to
the = attached destination host. the = attached destination host.
=
9. In order = to defer the need for a mapping lookup in the reverse 9. In order to defer the need for a mapping lookup = in the reverse
direction, = an ETR can OPTIONALLY create a cache entry that maps direction, an ETR can OPTIONALLY create a cache = entry that maps
the source = EID (inner-header source IP address) to the source the source EID (inner-header source IP address) = to the source
RLOC = (outer-header source IP address) in a received LISP packet. = RLOC (outer-header source IP address) in = a received LISP packet.
Such a = cache entry is termed a "gleaned" mapping and only Such a cache entry is termed a "gleaned" mapping = and only
contains a = single RLOC for the EID in question. More complete contains a single RLOC for the EID in question. = More complete
= information about additional RLOCs SHOULD be verified by = sending information about = additional RLOCs SHOULD be verified by sending
a LISP = Map-Request for that EID. Both the ITR and the ETR may a = LISP Map-Request for that EID. Both the ITR and the ETR MAY
also = influence the decision the other makes in selecting an RLOC. = also influence the decision the other = makes in selecting an RLOC.
=
5. LISP = Encapsulation Details 5. LISP = Encapsulation Details
=
Since = additional tunnel headers are prepended, the packet becomes = Since additional tunnel headers are = prepended, the packet becomes
larger and can = exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed = from the ITR to
the ETR. It = is RECOMMENDED in IPv4 that packets do not get the ETR. It is RECOMMENDED in IPv4 that packets do = not get
fragmented as = they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. = Instead, the packet
is dropped and = an ICMP Unreachable/Fragmentation-Needed message is is dropped and an ICMP = Unreachable/Fragmentation-Needed message is
returned to = the source. returned to the = source.
=
skipping to = change at = page 20, line 40 =C2=B6 = skipping to change at page 20, line = 40 =C2=B6
information = about EIDs and RLOCs, and uses LISP reachability information about EIDs and RLOCs, and uses LISP = reachability
information = mechanisms to determine the reachability of RLOCs, see information mechanisms to determine the reachability = of RLOCs, see
Section 10 for = the specific mechanisms. Section 10 = for the specific mechanisms.
=
7. Dealing with = Large Encapsulated Packets 7. Dealing = with Large Encapsulated Packets
=
This section = proposes two mechanisms to deal with packets that exceed = This section proposes two mechanisms to deal = with packets that exceed
the path MTU = between the ITR and ETR. the path = MTU between the ITR and ETR.
=
It is left to = the implementor to decide if the stateless or stateful It is left to the implementor to decide if the = stateless or stateful
mechanism = should be implemented. Both or neither = can be used, since mechanism SHOULD be implemented. Both or neither can be = used, since
it is a local = decision in the ITR regarding how to deal with MTU it is a local decision in the ITR regarding how to = deal with MTU
issues, and = sites can interoperate with differing mechanisms. issues, and sites can interoperate with differing = mechanisms.
=
Both stateless = and stateful mechanisms also apply to Re-encapsulating Both stateless and stateful mechanisms also apply to = Re-encapsulating
and Recursive = Tunneling, so any actions below referring to an ITR and Recursive Tunneling, so any actions below = referring to an ITR
also apply to = a TE-ITR. also apply to a = TE-ITR.
=
7.1. A Stateless = Solution to MTU Handling 7.1. A = Stateless Solution to MTU Handling
=
An ITR = stateless solution to handle MTU issues is described as = An ITR stateless solution to handle MTU = issues is described as
=
skipping to = change at = page 21, line 19 =C2=B6 = skipping to change at page 21, line = 19 =C2=B6
=
1. Define H = to be the size, in octets, of the outer header an ITR 1. Define H to be the size, in octets, of the outer = header an ITR
prepends = to a packet. This includes the UDP and LISP header prepends to a packet. This includes the UDP and = LISP header
= lengths. lengths.
=
2. Define L = to be the size, in octets, of the maximum-sized packet 2. Define L to be the size, in octets, of the = maximum-sized packet
an ITR can = send to an ETR without the need for the ITR or any an ITR can send to an ETR without the need for = the ITR or any
= intermediate routers to fragment the packet. intermediate routers to fragment the = packet.
=
3. Define an = architectural constant S for the maximum size of a 3. Define an architectural constant S for the = maximum size of a
packet, = in octets, an ITR must receive from the = source so the packet, in = octets, an ITR MUST receive from the = source so the
effective = MTU can be met. That is, L =3D S + H. = effective MTU can be met. That is, L =3D S + H.
=
When an ITR = receives a packet from a site-facing interface and adds H = When an ITR receives a packet from a = site-facing interface and adds H
octets worth = of encapsulation to yield a packet size greater than L octets worth of encapsulation to yield a packet size = greater than L
octets = (meaning the received packet size was greater than S octets = octets (meaning the received packet size was = greater than S octets
from the = source), it resolves the MTU issue by first splitting the = from the source), it resolves the MTU issue = by first splitting the
original = packet into 2 equal-sized fragments. A LISP header is then = original packet into 2 equal-sized = fragments. A LISP header is then
prepended to = each fragment. The size of the encapsulated fragments prepended to each fragment. The size of the = encapsulated fragments
is then (S/2 + = H), which is less than the ITR's estimate of the path is then (S/2 + H), which is less than the ITR's = estimate of the path
MTU between = the ITR and its correspondent ETR. = MTU between the ITR and its correspondent ETR.
=
skipping = to change at page 23, line = 21 =C2=B6 = skipping to change at page 23, line = 21 =C2=B6
= details. details.
=
The Instance = ID that is stored in the mapping database when LISP-DDT = The Instance ID that is stored in the = mapping database when LISP-DDT
= [I-D.ietf-lisp-ddt] is used is 32 bits in length. That means = the [I-D.ietf-lisp-ddt] is used is = 32 bits in length. That means the
control-plane = can store more instances than a given data-plane can control-plane can store more instances than a given = data-plane can
use. Multiple = data-planes can use the same 32-bit space as long as use. Multiple data-planes can use the same 32-bit = space as long as
the low-order = 24 bits don't overlap among xTRs. = the low-order 24 bits don't overlap among xTRs.
=
9. Routing = Locator Selection 9. Routing Locator = Selection
=
Both the = client-side and server-side may need = control over the Both the = client-side and server-side MAY need = control over the
selection of = RLOCs for conversations between them. This control is selection of RLOCs for conversations between them. = This control is
achieved by = manipulating the 'Priority' and 'Weight' fields in EID- = achieved by manipulating the 'Priority' and = 'Weight' fields in EID-
to-RLOC = Map-Reply messages. Alternatively, RLOC information MAY be = to-RLOC Map-Reply messages. Alternatively, = RLOC information MAY be
gleaned from = received tunneled packets or EID-to-RLOC Map-Request gleaned from received tunneled packets or EID-to-RLOC = Map-Request
= messages. messages.
=
The following = are different scenarios for choosing RLOCs and the The following are different scenarios for choosing = RLOCs and the
controls that = are available: controls that are = available:
=
o The = server-side returns one RLOC. The client-side can only use = o The server-side returns one RLOC. The = client-side can only use
=
skipping = to change at page 24, line = 48 =C2=B6 = skipping to change at page 24, line = 48 =C2=B6
stored in the = mapping database system provides reachability stored in the mapping database system provides = reachability
information = for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not = part of the
mapping system = and is determined using one or more of the Routing mapping system and is determined using one or more of = the Routing
Locator = reachability algorithms described in the next section. Locator reachability algorithms described in the next = section.
=
10. Routing = Locator Reachability 10. Routing = Locator Reachability
=
Several = mechanisms for determining RLOC reachability are currently = Several mechanisms for determining RLOC = reachability are currently
= defined: defined:
=
1. An ETR = may examine the Locator-Status-Bits in the = LISP header of 1. An ETR MAY examine the Locator-Status-Bits in the LISP = header of
an = encapsulated data packet received from an ITR. If the ETR is = an encapsulated data packet received = from an ITR. If the ETR is
also = acting as an ITR and has traffic to return to the original = also acting as an ITR and has traffic to = return to the original
ITR site, = it can use this status information to help select an ITR site, it can use this status information to = help select an
= RLOC. RLOC.
=
2. An ITR = may receive an ICMP Network Unreachable or = Host 2. An ITR MAY receive an ICMP Network Unreachable or = Host
= Unreachable message for an RLOC it is using. This indicates = that Unreachable message for an = RLOC it is using. This indicates that
the RLOC = is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP = messages may
not be = desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them = completely.
= Implementations are encouraged to follow current best practices = Implementations are encouraged to follow = current best practices
in = treating these conditions. in = treating these conditions.
=
3. An ITR = that participates in the global routing system can 3. An ITR that participates in the global routing = system can
determine = that an RLOC is down if no BGP Routing Information Base = determine that an RLOC is down if no BGP = Routing Information Base
(RIB) = route exists that matches the RLOC IP address. (RIB) route exists that matches the RLOC IP = address.
=
4. An ITR = may receive an ICMP Port Unreachable = message from a 4. An ITR MAY receive an ICMP Port Unreachable message = from a
= destination host. This occurs if an ITR attempts to use = destination host. This occurs if an ITR = attempts to use
= interworking [RFC6832] and LISP-encapsulated data is sent to a = interworking [RFC6832] and = LISP-encapsulated data is sent to a
= non-LISP-capable site. = non-LISP-capable site.
=
5. An ITR = may receive a Map-Reply from an ETR in = response to a 5. An ITR MAY receive a Map-Reply from an ETR in response = to a
previously = sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of = the Map-Reply is
likely up, = since the ETR was able to send the Map-Reply to the likely up, since the ETR was able to send the = Map-Reply to the
= ITR. ITR.
=
6. When an = ETR receives an encapsulated packet from an ITR, the 6. When an ETR receives an encapsulated packet from = an ITR, the
source = RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet = is likely up.
=
7. An ITR/ETR = pair can use the Locator reachability algorithms 7. An ITR/ETR pair can use the Locator reachability = algorithms
described = in this section, namely Echo-Noncing or RLOC-Probing. described in this section, namely Echo-Noncing or = RLOC-Probing.
=
=
skipping = to change at page 27, line = 45 =C2=B6 = skipping to change at page 27, line = 45 =C2=B6
E-bit cleared. = The ITR sees this "echoed nonce" and knows that the E-bit cleared. The ITR sees this "echoed nonce" and = knows that the
path to and = from the ETR is up. path to and = from the ETR is up.
=
The ITR will = set the E-bit and N-bit for every packet it sends while = The ITR will set the E-bit and N-bit for = every packet it sends while
in the = echo-nonce-request state. The time the ITR waits to process = in the echo-nonce-request state. The time = the ITR waits to process
the echoed = nonce before it determines the path is unreachable is the echoed nonce before it determines the path is = unreachable is
variable and = is a choice left for the implementation. variable and is a choice left for the = implementation.
=
If the ITR is = receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does = not see the
nonce echoed = while being in the echo-nonce-request state, then the nonce echoed while being in the echo-nonce-request = state, then the
path to the = ETR is unreachable. This decision may be = overridden by path to the ETR is = unreachable. This decision MAY be = overridden by
other Locator = reachability algorithms. Once the ITR determines that other Locator reachability algorithms. Once the ITR = determines that
the path to = the ETR is down, it can switch to another Locator for the path to the ETR is down, it can switch to another = Locator for
that = EID-Prefix. that = EID-Prefix.
=
Note that = "ITR" and "ETR" are relative terms here. Both devices MUST = Note that "ITR" and "ETR" are relative terms = here. Both devices MUST
be = implementing both ITR and ETR functionality for the echo nonce = be implementing both ITR and ETR = functionality for the echo nonce
mechanism to = operate. mechanism to = operate.
=
The ITR and = ETR may both go into the = echo-nonce-request state at the = The ITR and ETR MAY both go into the = echo-nonce-request state at the
same time. = The number of packets sent or the time during which echo = same time. The number of packets sent or = the time during which echo
nonce requests = are sent is an implementation-specific setting. nonce requests are sent is an implementation-specific = setting.
However, when = an ITR is in the echo-nonce-request state, it can echo However, when an ITR is in the echo-nonce-request = state, it can echo
the ETR's = nonce in the next set of packets that it encapsulates and = the ETR's nonce in the next set of packets = that it encapsulates and
subsequently = continue sending echo-nonce-request packets. subsequently continue sending echo-nonce-request = packets.
=
This mechanism = does not completely solve the forward path This mechanism does not completely solve the forward = path
reachability = problem, as traffic may be unidirectional. That is, the = reachability problem, as traffic may be = unidirectional. That is, the
ETR = receiving traffic at a site may not be the = same device as an ITR ETR = receiving traffic at a site MAY not be the = same device as an ITR
that transmits = traffic from that site, or the site-to-site traffic is that transmits traffic from that site, or the = site-to-site traffic is
unidirectional = so there is no ITR returning traffic. = unidirectional so there is no ITR returning traffic.
=
The echo-nonce = algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if = one side sets the
E-bit and the = other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for = echo-noncing, then the
echoing of the = nonce does not occur and the requesting side may echoing of the nonce does not occur and the = requesting side may
erroneously = consider the Locator unreachable. An ITR SHOULD only set = erroneously consider the Locator = unreachable. An ITR SHOULD only set
the E-bit in = an encapsulated data packet when it knows the ETR is the E-bit in an encapsulated data packet when it = knows the ETR is
enabled for = echo-noncing. This is conveyed by the E-bit in the RLOC- = enabled for echo-noncing. This is conveyed = by the E-bit in the RLOC-
probe = Map-Reply message. probe Map-Reply = message.
=
Note that other Locator reachability mechanisms are= being researched Note = other Locator Reachability mechanisms can = be used to compliment
and can be used to compliment or even = override the echo nonce or even = override the echo nonce algorithm. See the next section for
algorithm. = See the next section for an example of control-plane an example of control-plane probing.
= probing.
=
10.2. = RLOC-Probing Algorithm 10.2. = RLOC-Probing Algorithm
=
RLOC-Probing = is a method that an ITR or PITR can use to determine the = RLOC-Probing is a method that an ITR or PITR = can use to determine the
reachability = status of one or more Locators that it has cached in a reachability status of one or more Locators that it = has cached in a
Map-Cache = entry. The probe-bit of the Map-Request and Map-Reply Map-Cache entry. The probe-bit of the Map-Request = and Map-Reply
messages is = used for RLOC-Probing. messages is = used for RLOC-Probing.
=
RLOC-Probing = is done in the control plane on a timer basis, where an = RLOC-Probing is done in the control plane on = a timer basis, where an
ITR or PITR = will originate a Map-Request destined to a locator ITR or PITR will originate a Map-Request destined to = a locator
address from = one of its own locator addresses. A Map-Request used as = address from one of its own locator = addresses. A Map-Request used as
an RLOC-probe = is NOT encapsulated and NOT sent to a Map-Server or to an RLOC-probe is NOT encapsulated and NOT sent to a = Map-Server or to
the mapping = database system as one would when soliciting mapping the mapping database system as one would when = soliciting mapping
data. The EID = record encoded in the Map-Request is the EID-Prefix of data. The EID record encoded in the Map-Request is = the EID-Prefix of
the = Map-Cache entry cached by the ITR or PITR. The ITR may include a = the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a
mapping data = record for its own database mapping information that mapping data record for its own database mapping = information that
contains the = local EID-Prefixes and RLOCs for its site. RLOC-probes = contains the local EID-Prefixes and RLOCs = for its site. RLOC-probes
are sent = periodically using a jittered timer interval. are sent periodically using a jittered timer = interval.
=
When an ETR = receives a Map-Request message with the probe-bit set, it = When an ETR receives a Map-Request message = with the probe-bit set, it
returns a = Map-Reply with the probe-bit set. The source address of = returns a Map-Reply with the probe-bit set. = The source address of
the Map-Reply = is set according to the procedure described in the Map-Reply is set according to the procedure = described in
= [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain = mapping [I-D.ietf-lisp-rfc6833bis]. = The Map-Reply SHOULD contain mapping
data for the = EID-Prefix contained in the Map-Request. This provides = data for the EID-Prefix contained in the = Map-Request. This provides
the = opportunity for the ITR or PITR that sent the RLOC-probe to get = the opportunity for the ITR or PITR that = sent the RLOC-probe to get
=
skipping = to change at page 29, line = 27 =C2=B6 = skipping to change at page 29, line = 27 =C2=B6
reachable or = has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a = robust
mechanism for = switching to using another Locator from the cached mechanism for switching to using another Locator from = the cached
Locator. = RLOC-Probing can also provide rough Round-Trip Time (RTT) = Locator. RLOC-Probing can also provide = rough Round-Trip Time (RTT)
estimates = between a pair of Locators, which can be useful for network = estimates between a pair of Locators, which = can be useful for network
management = purposes as well as for selecting low delay paths. The = management purposes as well as for selecting = low delay paths. The
major = disadvantage of RLOC-Probing is in the number of control = major disadvantage of RLOC-Probing is in the = number of control
messages = required and the amount of bandwidth used to obtain those = messages required and the amount of = bandwidth used to obtain those
benefits, = especially if the requirement for failure detection times = benefits, especially if the requirement for = failure detection times
is very = small. is very small.
=
Continued research and testing will attempt to = characterize the
tradeoffs of failure detection times versus message = overhead.
= =
11. EID = Reachability within a LISP Site 11. = EID Reachability within a LISP Site
=
A site may be multihomed using two or more ETRs. The = hosts and A site MAY be multihomed using two or more ETRs. The = hosts and
infrastructure = within a site will be addressed using one or more EID- infrastructure within a site will be addressed using = one or more EID-
Prefixes that = are mapped to the RLOCs of the relevant ETRs in the Prefixes that are mapped to the RLOCs of the relevant = ETRs in the
mapping = system. One possible failure mode is for an ETR to lose = mapping system. One possible failure mode = is for an ETR to lose
reachability = to one or more of the EID-Prefixes within its own site. = reachability to one or more of the = EID-Prefixes within its own site.
When this = occurs when the ETR sends Map-Replies, it can clear the = When this occurs when the ETR sends = Map-Replies, it can clear the
R-bit = associated with its own Locator. And when the ETR is also an = R-bit associated with its own Locator. And = when the ETR is also an
ITR, it can = clear its Locator-Status-Bit in the encapsulation data ITR, it can clear its Locator-Status-Bit in the = encapsulation data
= header. header.
=
It is = recognized that there are no simple solutions to the site = It is recognized that there are no simple = solutions to the site
=
skipping = to change at page 30, line = 8 =C2=B6 = skipping to change at page 29, line = 51 =C2=B6
EID-Prefix = range is partitioned and which Locators can reach any sub- = EID-Prefix range is partitioned and which = Locators can reach any sub-
ranges of the = EID-Prefixes. This problem is under investigation with = ranges of the EID-Prefixes. This problem is = under investigation with
the = expectation that experiments will tell us more. Note that this = the expectation that experiments will tell = us more. Note that this
is not a new = problem introduced by the LISP architecture. The is not a new problem introduced by the LISP = architecture. The
problem exists = today when a multihomed site uses BGP to advertise its problem exists today when a multihomed site uses BGP = to advertise its
reachability = upstream. reachability = upstream.
=
12. Routing = Locator Hashing 12. Routing Locator = Hashing
=
When an ETR = provides an EID-to-RLOC mapping in a Map-Reply message to = When an ETR provides an EID-to-RLOC mapping = in a Map-Reply message to
a requesting = ITR, the Locator-Set for the EID-Prefix may = contain a requesting ITR, the = Locator-Set for the EID-Prefix MAY = contain
different = Priority values for each locator address. When more than = different Priority values for each locator = address. When more than
one best = Priority Locator exists, the ITR can decide how to load- = one best Priority Locator exists, the ITR = can decide how to load-
share traffic = against the corresponding Locators. = share traffic against the corresponding Locators.
=
The = following hash algorithm may be used by an = ITR to select a The following hash = algorithm MAY be used by an ITR to select = a
Locator for a = packet destined to an EID for the EID-to-RLOC mapping: Locator for a packet destined to an EID for the = EID-to-RLOC mapping:
=
1. Either a = source and destination address hash or the traditional 1. Either a source and destination address hash or = the traditional
5-tuple = hash can be used. The traditional 5-tuple hash includes = 5-tuple hash can be used. The = traditional 5-tuple hash includes
the source = and destination addresses; source and destination TCP, the source and destination addresses; source and = destination TCP,
UDP, or = Stream Control Transmission Protocol (SCTP) port numbers; = UDP, or Stream Control Transmission = Protocol (SCTP) port numbers;
and the IP = protocol number field or IPv6 next-protocol fields of and the IP protocol number field or IPv6 = next-protocol fields of
a packet = that a host originates from within a LISP site. When a = a packet that a host originates from = within a LISP site. When a
packet is = not a TCP, UDP, or SCTP packet, the source and packet is not a TCP, UDP, or SCTP packet, the = source and
= destination addresses only from the header are used to compute = destination addresses only from the = header are used to compute
=
skipping = to change at page 34, line = 6 =C2=B6 = skipping to change at page 33, line = 44 =C2=B6
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
sender of an = SMR-based Map-Request MUST be verified. If an ITR sender of an SMR-based Map-Request MUST be verified. = If an ITR
receives an = SMR-based Map-Request and the source is not in the receives an SMR-based Map-Request and the source is = not in the
Locator-Set = for the stored Map-Cache entry, then the responding Map- = Locator-Set for the stored Map-Cache entry, = then the responding Map-
Request MUST = be sent with an EID destination to the mapping database = Request MUST be sent with an EID destination = to the mapping database
system. Since = the mapping database system is a more secure way to system. Since the mapping database system is a more = secure way to
reach an = authoritative ETR, it will deliver the Map-Request to the = reach an authoritative ETR, it will deliver = the Map-Request to the
authoritative = source of the mapping data. = authoritative source of the mapping data.
=
When an ITR = receives an SMR-based Map-Request for which it does not = When an ITR receives an SMR-based = Map-Request for which it does not
have a = cached mapping for the EID in the SMR message, it MAY not send = have a cached mapping for the EID in the SMR message, it may not send
an SMR-invoked = Map-Request. This scenario can occur when an ETR an SMR-invoked Map-Request. This scenario can occur = when an ETR
sends SMR = messages to all Locators in the Locator-Set it has stored = sends SMR messages to all Locators in the = Locator-Set it has stored
in its = map-cache but the remote ITRs that receive the SMR may not be = in its map-cache but the remote ITRs that = receive the SMR may not be
sending = packets to the site. There is no point in updating the ITRs = sending packets to the site. There is no = point in updating the ITRs
until they = need to send, in which case they will send Map-Requests to = until they need to send, in which case they = will send Map-Requests to
obtain a = Map-Cache entry. obtain a Map-Cache = entry.
=
13.3. Database = Map-Versioning 13.3. Database = Map-Versioning
=
When there is = unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an = ITR and ETR, and
=
skipping = to change at page 35, line = 52 =C2=B6 = skipping to change at page 35, line = 39 =C2=B6
few = implementation techniques can be used to incrementally = implement few implementation = techniques can be used to incrementally implement
LISP: = LISP:
=
o When a = tunnel-encapsulated packet is received by an ETR, the outer = o When a tunnel-encapsulated packet is = received by an ETR, the outer
destination = address may not be the address of the router. This destination address may not be the address of the = router. This
makes it = challenging for the control plane to get packets from the = makes it challenging for the control = plane to get packets from the
hardware. = This may be mitigated by creating special Forwarding hardware. This may be mitigated by creating = special Forwarding
Information = Base (FIB) entries for the EID-Prefixes of EIDs served Information Base (FIB) entries for the = EID-Prefixes of EIDs served
by the ETR = (those for which the router provides an RLOC by the ETR (those for which the router provides an = RLOC
= translation). These FIB entries are marked with a flag = indicating translation). These = FIB entries are marked with a flag indicating
that = control-plane processing should be = performed. The forwarding that = control-plane processing SHOULD be = performed. The forwarding
logic of = testing for particular IP protocol number values is not = logic of testing for particular IP = protocol number values is not
necessary. = There are a few proven cases where no changes to necessary. There are a few proven cases where no = changes to
existing = deployed hardware were needed to support the LISP data- = existing deployed hardware were needed to = support the LISP data-
= plane. plane.
=
o On an ITR, = prepending a new IP header consists of adding more o On an ITR, prepending a new IP header consists of = adding more
octets to a = MAC rewrite string and prepending the string as part octets to a MAC rewrite string and prepending the = string as part
of the = outgoing encapsulation procedure. Routers that support = of the outgoing encapsulation procedure. = Routers that support
Generic = Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 = Generic Routing Encapsulation (GRE) = tunneling [RFC2784] or 6to4
tunneling = [RFC3056] may already support this action. tunneling [RFC3056] may already support this = action.
=
skipping = to change at page 38, line = 15 =C2=B6 = skipping to change at page 38, line = 5 =C2=B6
17. LISP xTR = Placement and Encapsulation Methods 17. = LISP xTR Placement and Encapsulation Methods
=
This section = will explore how and where ITRs and ETRs can be placed This section will explore how and where ITRs and ETRs = can be placed
in the network = and will discuss the pros and cons of each scenario. in the network and will discuss the pros and cons of = each scenario.
For a more = detailed networkd design deployment recommendation, refer = For a more detailed networkd design = deployment recommendation, refer
to = [RFC7215]. to [RFC7215].
=
There are two = basic deployment tradeoffs to consider: centralized There are two basic deployment tradeoffs to consider: = centralized
versus = distributed caches; and flat, Recursive, or Re-encapsulating = versus distributed caches; and flat, = Recursive, or Re-encapsulating
Tunneling. = When deciding on centralized versus distributed caching, = Tunneling. When deciding on centralized = versus distributed caching,
the = following issues should be = considered: the following issues = SHOULD be considered:
=
o Are the = xTRs spread out so that the caches are spread across all = o Are the xTRs spread out so that the = caches are spread across all
the = memories of each router? A centralized cache is when an ITR = the memories of each router? A = centralized cache is when an ITR
keeps a = cache for all the EIDs it is encapsulating to. The packet = keeps a cache for all the EIDs it is = encapsulating to. The packet
takes a = direct path to the destination Locator. A distributed takes a direct path to the destination Locator. A = distributed
cache is = when an ITR needs help from other Re-Encapsulating Tunnel = cache is when an ITR needs help from = other Re-Encapsulating Tunnel
Routers = (RTRs) because it does not store all the cache entries for = Routers (RTRs) because it does not store = all the cache entries for
the EIDs it = is encapsulating to. So, the packet takes a path the EIDs it is encapsulating to. So, the packet = takes a path
through = RTRs that have a different set of cache entries. through RTRs that have a different set of cache = entries.
=
o Should = management "touch points" be minimized by only choosing a = o Should management "touch points" be = minimized by only choosing a
few xTRs, = just enough for redundancy? few = xTRs, just enough for redundancy?
=
o In general, = using more ITRs doesn't increase management load, o In general, using more ITRs doesn't increase = management load,
since = caches are built and stored dynamically. On the other hand, = since caches are built and stored = dynamically. On the other hand,
using more = ETRs does require more management, since EID-Prefix-to- = using more ETRs does require more = management, since EID-Prefix-to-
RLOC = mappings need to be explicitly configured. RLOC mappings need to be explicitly = configured.
=
When deciding = on flat, Recursive, or Re-Encapsulating Tunneling, the When deciding on flat, Recursive, or Re-Encapsulating = Tunneling, the
following = issues should be considered: = following issues SHOULD be considered:
=
o Flat = tunneling implements a single encapsulation path between the = o Flat tunneling implements a single = encapsulation path between the
source site = and destination site. This generally offers better source site and destination site. This generally = offers better
paths = between sources and destinations with a single encapsulation = paths between sources and destinations = with a single encapsulation
= path. path.
=
o Recursive = Tunneling is when encapsulated traffic is again further = o Recursive Tunneling is when encapsulated = traffic is again further
= encapsulated in another tunnel, either to implement VPNs or to = encapsulated in another tunnel, either to = implement VPNs or to
perform = Traffic Engineering. When doing VPN-based tunneling, the = perform Traffic Engineering. When doing = VPN-based tunneling, the
site has = some control, since the site is prepending a new site has some control, since the site is = prepending a new
= encapsulation header. In the case of TE-based tunneling, the = site encapsulation header. In = the case of TE-based tunneling, the site
may have control if it is prepending a new = tunnel header, but if MAY have control if it is prepending a new = tunnel header, but if
the site's = ISP is doing the TE, then the site has no control. the site's ISP is doing the TE, then the site has = no control.
Recursive = Tunneling generally will result in suboptimal paths but = Recursive Tunneling generally will result = in suboptimal paths but
with the = benefit of steering traffic to parts of the network that = with the benefit of steering traffic to = parts of the network that
have more = resources available. have more = resources available.
=
o The = technique of Re-Encapsulation ensures that packets only = o The technique of Re-Encapsulation ensures = that packets only
require one = encapsulation header. So, if a packet needs to be re- require one encapsulation header. So, if a packet = needs to be re-
routed, it = is first decapsulated by the RTR and then Re- routed, it is first decapsulated by the RTR and = then Re-
= Encapsulated with a new encapsulation header using a new RLOC. = Encapsulated with a new encapsulation = header using a new RLOC.
=
=
skipping = to change at page 41, line = 12 =C2=B6 = skipping to change at page 41, line = 9 =C2=B6
addresses MUST = be used only in the outer IP header so the NAT device addresses MUST be used only in the outer IP header so = the NAT device
can translate = properly. Otherwise, EID addresses MUST be translated can translate properly. Otherwise, EID addresses = MUST be translated
before = encapsulation is performed when LISP VPNs are not in use. = before encapsulation is performed when LISP = VPNs are not in use.
Both NAT = translation and LISP encapsulation functions could be co- = Both NAT translation and LISP encapsulation = functions could be co-
located in the = same device. located in the same = device.
=
17.5. Packets = Egressing a LISP Site 17.5. Packets = Egressing a LISP Site
=
When a LISP = site is using two ITRs for redundancy, the failure of one = When a LISP site is using two ITRs for = redundancy, the failure of one
ITR will = likely shift outbound traffic to the second. This second = ITR will likely shift outbound traffic to = the second. This second
ITR's cache = may not be populated with the same = EID-to-RLOC mapping ITR's cache = MAY not be populated with the same = EID-to-RLOC mapping
entries as the = first. If this second ITR does not have these entries as the first. If this second ITR does not = have these
mappings, = traffic will be dropped while the mappings are retrieved = mappings, traffic will be dropped while the = mappings are retrieved
from the = mapping system. The retrieval of these messages may from the mapping system. The retrieval of these = messages may
increase the = load of requests being sent into the mapping system. increase the load of requests being sent into the = mapping system.
=
18. Traceroute = Considerations 18. Traceroute = Considerations
=
When a source = host in a LISP site initiates a traceroute to a When a source host in a LISP site initiates a = traceroute to a
destination = host in another LISP site, it is highly desirable for it = destination host in another LISP site, it is = highly desirable for it
to see the = entire path. Since packets are encapsulated from the ITR = to see the entire path. Since packets are = encapsulated from the ITR
=
skipping = to change at page 44, line = 16 =C2=B6 = skipping to change at page 44, line = 14 =C2=B6
=
Map-Versioning = is a data-plane mechanism used to signal a peering xTR Map-Versioning is a data-plane mechanism used to = signal a peering xTR
that a local = EID-to-RLOC mapping has been updated, so that the that a local EID-to-RLOC mapping has been updated, so = that the
peering xTR = uses LISP Control-Plane signaling message to retrieve a = peering xTR uses LISP Control-Plane = signaling message to retrieve a
fresh mapping. = This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to = forge the map-
versioning = field of a LISP encapsulated header and force an excessive = versioning field of a LISP encapsulated = header and force an excessive
amount of = signaling between xTRs that may overload them. amount of signaling between xTRs that may overload = them.
=
Most of the = attack vectors can be mitigated with careful deployment = Most of the attack vectors can be mitigated = with careful deployment
and = configuration, information learned opportunistically (such as = LSB and configuration, information = learned opportunistically (such as LSB
or gleaning) = should be verified with other reachability = mechanisms. or gleaning) SHOULD be verified with other reachability = mechanisms.
In addition, = systematic rate-limitation and filtering is an effective = In addition, systematic rate-limitation and = filtering is an effective
technique to = mitigate attacks that aim to overload the control-plane. = technique to mitigate attacks that aim to = overload the control-plane.
=
20. Network = Management Considerations 20. Network = Management Considerations
=
Considerations = for network management tools exist so the LISP Considerations for network management tools exist so = the LISP
protocol suite = can be operationally managed. These mechanisms can be protocol suite can be operationally managed. These = mechanisms can be
found in = [RFC7052] and [RFC6835]. found in = [RFC7052] and [RFC6835].
=
21. IANA = Considerations 21. IANA = Considerations
=
skipping = to change at page 48, line = 8 =C2=B6 = skipping to change at page 47, line = 50 =C2=B6
[AFN] = IANA, "Address Family Numbers", August 2016, [AFN] IANA, "Address Family Numbers", August = 2016,
= <http://www.iana.org/assignments/address-family-numbers>. = = <http://www.iana.org/assignments/address-family-numbers>.
=
[CHIAPPA] = Chiappa, J., "Endpoints and Endpoint names: A Proposed", = [CHIAPPA] Chiappa, J., "Endpoints and = Endpoint names: A Proposed",
= 1999, 1999,
= <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. = = <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
=
= [I-D.ietf-lisp-eid-mobility] = [I-D.ietf-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-ietf-lisp-eid-mobility-00 = Unified Control Plane", draft-ietf-lisp-eid-mobility-01
= (work in progress), May 2017. = (work in progress), November 2017.
=
= [I-D.ietf-lisp-mn] = [I-D.ietf-lisp-mn]
= Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP = Farinacci, D., Lewis, D., Meyer, = D., and C. White, "LISP
= Mobile Node", draft-ietf-lisp-mn-01 (work in progress), = Mobile Node", = draft-ietf-lisp-mn-01 (work in progress),
= October 2017. October = 2017.
=
= [I-D.ietf-lisp-predictive-rlocs] = [I-D.ietf-lisp-predictive-rlocs]
= Farinacci, D. and P. Pillay-Esnault, "LISP Predictive Farinacci, D. and P. Pillay-Esnault, "LISP = Predictive
= RLOCs", draft-ietf-lisp-predictive-rlocs-00 = (work in RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work = in
= progress), June 2017. progress), November 2017.
=
= [I-D.ietf-lisp-signal-free-multicast] = [I-D.ietf-lisp-signal-free-multicast]
= Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", = Moreno, V. and D. Farinacci, = "Signal-Free LISP Multicast",
= draft-ietf-lisp-signal-free-multicast-06 = (work in draft-ietf-lisp-signal-free-multicast-07 (work = in
= progress), August 2017. progress), November 2017.
=
= [I-D.ietf-lisp-vpn] = [I-D.ietf-lisp-vpn]
= Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual = Private
= Networks (VPNs)", draft-ietf-lisp-vpn-00 = (work in Networks = (VPNs)", draft-ietf-lisp-vpn-01 (work = in
= progress), May 2017. progress), November 2017.
=
= [I-D.meyer-loc-id-implications] = [I-D.meyer-loc-id-implications]
= Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural = Implications of
= Locator/ID Separation", draft-meyer-loc-id-implications-01 = Locator/ID Separation", = draft-meyer-loc-id-implications-01
= (work in progress), January 2009. = (work in progress), January 2009.
=
[LISA96] = Lear, E., Tharp, D., Katinsky, J., and J. Coffin, [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. = Coffin,
= "Renumbering: Threat or Menace?", Usenix Tenth System "Renumbering: Threat or Menace?", Usenix = Tenth System
= Administration Conference (LISA 96), October 1996. Administration Conference (LISA 96), = October 1996.
=
=
skipping = to change at page 52, line = 5 =C2=B6 = skipping to change at page 52, line = 5 =C2=B6
The LISP = working group would like to give a special thanks to Jari = The LISP working group would like to give a = special thanks to Jari
Arkko, the = Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set = of LISP
documents were = being prepared for IESG last call, and for his documents were being prepared for IESG last call, and = for his
meticulous = reviews and detailed commentaries on the 7 working group = meticulous reviews and detailed commentaries = on the 7 working group
last call = documents progressing toward standards-track RFCs. last call documents progressing toward = standards-track RFCs.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-06 = B.1. Changes to draft-ietf-lisp-rfc6830bis-08
=
= o Posted December = 2017.
=
= o Remove references = to research work for any protocol mechanisms.
=
= o Document scanned = to make sure it is RFC 2119 compliant.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-06 B.3. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping = to change at page 52, line = 35 =C2=B6 = skipping to change at page 52, line = 43 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addreses can be used. = o Clarify when private addreses can be used.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-05 B.4. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Reencapsulating Tunnel Router is an RTR. o Make it clear that a Reencapsulating Tunnel Router = is an RTR.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-04 B.5. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-03 B.6. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-02 B.7. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-01 B.8. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-00 B.9. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = farinacci@gmail.com EMail: = farinacci@gmail.com
= =
Vince = Fuller Vince Fuller
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = vince.fuller@gmail.com EMail: = vince.fuller@gmail.com
=
Dave = Meyer Dave Meyer
Cisco = Systems Cisco Systems
 End of changes. 51 change blocks. 
68 lines changed or = deleted 73 lines changed or = added

This = html diff was produced by rfcdiff 1.46. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_9F936107-2DF3-41BC-9AED-122CAEAD32FD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_9F936107-2DF3-41BC-9AED-122CAEAD32FD Content-Disposition: attachment; filename=draft-ietf-lisp-rfc6830bis-08.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-rfc6830bis-08.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer Expires: June 17, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech December 14, 2017 The Locator/ID Separation Protocol (LISP) draft-ietf-lisp-rfc6830bis-08 Abstract This document describes the data-plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. The map-cache is populated by the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 17, 2018. Farinacci, et al. Expires June 17, 2018 [Page 1] =0C Internet-Draft LISP December 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 11 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 13 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 14 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 15 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 16 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 34 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 15. Router Performance Considerations . . . . . . . . . . . . . . 35 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 Farinacci, et al. Expires June 17, 2018 [Page 2] =0C Internet-Draft LISP December 2017 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 41 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 44 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.2. Informative References . . . . . . . . . . . . . . . . . 47 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 52 B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 52 B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 52 B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 52 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 53 B.6. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 53 B.7. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 B.8. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 B.9. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction This document describes the Locator/Identifier Separation Protocol (LISP). LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [CHIAPPA]. As a result LISP creates two namespaces: Endpoint Identifiers (EIDs), that are used to identify end-hosts (e.g., nodes or Virtual Machines) and routable Routing Locators (RLOCs), used to identify network attachment points. LISP then defines functions for mapping between the two namespaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. LISP is an overlay protocol that separates control from data-plane, this document specifies the data-plane, how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the appropriate location. Tunnel routers are equipped with a cache, called map-cache, that contains EID-to-RLOC mappings. The map-cache Farinacci, et al. Expires June 17, 2018 [Page 3] =0C Internet-Draft LISP December 2017 is populated using the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. LISP does not require changes to either host protocol stack or to underlay routers. By separating the EID from the RLOC space, LISP offers native Traffic Engineering, multihoming and mobility, among other features. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]) This document specifies the LISP data-plane encapsulation and other LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] specifies the LISP control plane. LISP deployment guidelines can be found in [RFC7215] and [RFC6835] describes considerations for network operational management. Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms Provider-Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g., from a particular service provider) and are therefore not topologically aggregatable in the routing system. Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider to which a site connects. Typically, each block is a sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. LISP uses only topologically assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically Farinacci, et al. Expires June 17, 2018 [Page 4] =0C Internet-Draft LISP December 2017 aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example, through a Domain Name System (DNS) [RFC1034] lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. An EID is allocated to a host from an EID-Prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site MAY have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called an "LEID". Throughout this document, any references to "EID" refer to an LEID. EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID- Prefixes are associated with a set of RLOC addresses that make up a "database mapping". EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. A globally routed address block (whether PI or PA) is not inherently an EID-Prefix. A globally routed address block MAY be used by its assignee as an EID block. The converse is not supported. That is, a site that receives an explicitly allocated EID-Prefix may not use that EID-Prefix as a globally routed prefix. This would require coordination and cooperation with the entities managing the mapping infrastructure. Once this has been done, that block could be removed from the globally routed IP system, if other suitable transition and access mechanisms are in place. Discussion of such transition and access mechanisms can be found in [RFC6832] and [RFC7215]. Farinacci, et al. Expires June 17, 2018 [Page 5] =0C Internet-Draft LISP December 2017 End-system: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e., outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Ingress Tunnel Router (ITR): An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its routable RLOCs (in the RLOC space) in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC MAY be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating host's supplied EID). TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the Farinacci, et al. Expires June 17, 2018 [Page 6] =0C Internet-Draft LISP December 2017 router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router. Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling occurs when an RTR (Re-encapsulating Tunnel Router) acts like an ETR to remove a LISP header, then acts as an ITR to prepend a new LISP header. Doing this allows a packet to be re-routed by the RTR without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured. When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration. LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), or Proxy-ETR (PETR). EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID- to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope. EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own globally visible IP addresses. Note that there MAY be transient conditions when the EID-Prefix for the site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used. Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured. Farinacci, et al. Expires June 17, 2018 [Page 7] =0C Internet-Draft LISP December 2017 LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP- specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips. Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet. An address family that pertains to the data-plane. See [AFN] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well-defined actions that are encoded in a Negative Map-Reply. Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host if the destination EID is in the EID-Prefix range configured on the ETR. Otherwise, the packet is discarded. A Data-Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. When using Data-Probes, by sending Map-Requests on the underlying routing system, EID-Prefixes must be advertised. However, this is discouraged if the core is to scale by having less EID-Prefixes stored in the core router's routing tables. Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites. Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites. Route-returnability: Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with Farinacci, et al. Expires June 17, 2018 [Page 8] =0C Internet-Draft LISP December 2017 a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message. LISP site: LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network. Client-side: Client-side is a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database Map-Cache entries by sending Map-Request messages. Server-side: Server-side is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site MAY be the first to send Map-Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets. Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 10. Anycast Address: Anycast Address is a term used in this document to refer to the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in each of their own address spaces. 4. Basic Overview One key concept of LISP is that end-systems operate the same way they do today. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the Farinacci, et al. Expires June 17, 2018 [Page 9] =0C Internet-Draft LISP December 2017 destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. Another key LISP concept is the "Tunnel Router". A Tunnel Router prepends LISP headers on host-originated packets and strips them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips the new header. The ITR performs EID-to- RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems only send to addresses that are EIDs. They don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change. o EIDs are typically IP addresses assigned to hosts. o Other types of EID are supported by LISP, see [RFC8060] for further information. o LISP routers mostly deal with Routing Locator addresses. See details in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks. o When a router originates packets, it MAY use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure SHell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it MAY use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o Packets with EIDs in them are not expected to be delivered end-to- end in the absence of an EID-to-RLOC mapping operation. They are Farinacci, et al. Expires June 17, 2018 [Page 10] =0C Internet-Draft LISP December 2017 expected to be used locally for intra-site communication or to be encapsulated for inter-site communication. o EID-Prefixes are likely to be hierarchically assigned in a manner that is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on an address allocation hierarchy that is independent of the network topology. o EIDs MAY also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS). An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document recommends that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and the second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. Another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility. 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow, including also control-plane information as specified in [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following conditions: Farinacci, et al. Expires June 17, 2018 [Page 11] =0C Internet-Draft LISP December 2017 o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site. o Map-Requests are sent to the mapping database system by using the LISP control-plane protocol documented in [I-D.ietf-lisp-rfc6833bis]. A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. o Map-Replies are sent on the underlying routing system topology using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol. Client host1.abc.example.com wants to communicate with server host2.xyz.example.com: 1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [I-D.ietf-lisp-rfc6833bis] for further information. 3. The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. 4. The mapping system helps forwarding the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-Prefixes the ETR Farinacci, et al. Expires June 17, 2018 [Page 12] =0C Internet-Draft LISP December 2017 is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. 6. The ITR receives the Map-Reply message, parses the message (to check for format validity), and stores the mapping information from the packet. This information is stored in the ITR's EID-to- RLOC map-cache. Note that the map-cache is an on-demand cache. An ITR will manage its map-cache in such a way that optimizes for its resource constraints. 7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host. 9. In order to defer the need for a mapping lookup in the reverse direction, an ETR can OPTIONALLY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC. 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Unreachable/Fragmentation-Needed message is returned to the source. This specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 7. Farinacci, et al. Expires June 17, 2018 [Page 13] =0C Internet-Draft LISP December 2017 Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported. Additional types of EIDs are defined in [RFC8060]. 5.1. LISP IPv4-in-IPv4 Header Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IHL =3D IP-Header-Length Farinacci, et al. Expires June 17, 2018 [Page 14] =0C Internet-Draft LISP December 2017 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | Farinacci, et al. Expires June 17, 2018 [Page 15] =0C Internet-Draft LISP December 2017 ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header (IH): The inner header is the header on the datagram received from the originating host. The source and destination IP addresses are EIDs [RFC0791] [RFC8200]. Outer Header: (OH) The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 7.1 and 7.2. UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 12 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341. UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP zero checksums over IPv6 for all tunneling protocols, including LISP, is subject to the applicability statement in [RFC6936]. UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers. Farinacci, et al. Expires June 17, 2018 [Page 16] =0C Internet-Draft LISP December 2017 N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a Nonce. See Section 10.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a Nonce value present. L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use. x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP- encapsulated packets when the ITR is also an ETR. See Section 10.1 for details. V: The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to Section 13.3 for more details. This bit indicates that the LISP header is encoded in this case as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: The I-bit is the Instance ID bit. See Section 8 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this: Farinacci, et al. Expires June 17, 2018 [Page 17] =0C Internet-Draft LISP December 2017 x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R: The R-bit is a Reserved bit for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt. KK: The KK-bits are a 2-bit field used when encapsualted packets are encrypted. The field is set to 00 when the packet is not encrypted. See [RFC8061] for further information. LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different destinations. However, the same nonce can be used for a period of time to the same destination. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 10.1 for more details. LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 10 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'. When doing ITR/PITR encapsulation: Farinacci, et al. Expires June 17, 2018 [Page 18] =0C Internet-Draft LISP December 2017 o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field. o The outer-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header 'Type of Service' field (with one exception; see below). When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. o The inner-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header 'Type of Service' field (with one exception; see below). Note that if an ETR/PETR is also an ITR/PITR and chooses to re- encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 18.3 for TTL exception handling for traceroute packets. The Explicit Congestion Notification ('ECN') field occupies bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC3168]. The 'ECN' field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes Farinacci, et al. Expires June 17, 2018 [Page 19] =0C Internet-Draft LISP December 2017 marked with a CE indication due to congestion between the tunnel endpoints. 6. LISP EID-to-RLOC Map-Cache ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- RLOC Map-Cache, that contains mappings from EID-prefixes to locator sets. The cache is used to encapsulate packets from the EID space to the corresponding RLOC network attachment point. When an ITR/PITR receives a packet from inside of the LISP site to destinations outside of the site a longest-prefix match lookup of the EID is done to the map-cache. When the lookup succeeds, the locator-set retrieved from the map- cache is used to send the packet to the EID's topological location. If the lookup fails, the ITR/PITR needs to retrieve the mapping using the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The mapping is then stored in the local map-cache to forward subsequent packets addressed to the same EID-prefix. The map-cache is a local cache of mappings, entries are expired based on the associated Time to live. In addition, entries can be updated with more current information, see Section 13 for further information on this. Finally, the map-cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. 7. Dealing with Large Encapsulated Packets This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism SHOULD be implemented. Both or neither can be used, since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Both stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below referring to an ITR also apply to a TE-ITR. Farinacci, et al. Expires June 17, 2018 [Page 20] =0C Internet-Draft LISP December 2017 7.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: 1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths. 2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet. 3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR MUST receive from the source so the effective MTU can be met. That is, L =3D S + H. When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets (meaning the received packet size was greater than S octets from the source), it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMP Unreachable/ Fragmentation-Needed message to the source with a value of S, where S is (L - H). When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. Farinacci, et al. Expires June 17, 2018 [Page 21] =0C Internet-Draft LISP December 2017 This specification RECOMMENDS that L be defined as 1500. 7.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR. 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Unreachable/Fragmentation-Needed message to the ITR. The ITR will parse the ICMP message to determine which Locator is affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Unreachable/ Fragmentation-Needed message back to the source. The packet size advertised by the ITR in the ICMP Unreachable/Fragmentation- Needed message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 8. Using Virtualization and Segmentation with LISP There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies or multi-tenant virtualization. For these and other scenarios where segregation is needed, Instance IDs are used. An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1. Farinacci, et al. Expires June 17, 2018 [Page 22] =0C Internet-Draft LISP December 2017 When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case details. The Instance ID that is stored in the mapping database when LISP-DDT [I-D.ietf-lisp-ddt] is used is 32 bits in length. That means the control-plane can store more instances than a given data-plane can use. Multiple data-planes can use the same 32-bit space as long as the low-order 24 bits don't overlap among xTRs. 9. Routing Locator Selection Both the client-side and server-side MAY need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the 'Priority' and 'Weight' fields in EID- to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following are different scenarios for choosing RLOCs and the controls that are available: o The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection. o The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o The server-side sets a Weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server- side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable. Farinacci, et al. Expires June 17, 2018 [Page 23] =0C Internet-Draft LISP December 2017 o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer- header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large. o A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map- Cache entry for the "gleaned" EID and is stored and used for the time indicated from the 'TTL' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry. This "gleaning" mechanism is OPTIONAL. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the Locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section. 10. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. Farinacci, et al. Expires June 17, 2018 [Page 24] =0C Internet-Draft LISP December 2017 2. An ITR MAY receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions. 3. An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address. 4. An ITR MAY receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR MAY receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator reachability algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal Farinacci, et al. Expires June 17, 2018 [Page 25] =0C Internet-Draft LISP December 2017 value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map- Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages. If an ITR does receive an ICMP Network Unreachable or Host Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a Locator-Set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default- Free Zone (DFZ), it can decide to not use the Locator even though the Locator-Status-Bits indicate that the Locator is up. In this case, the path from the ITR to the ETR that is assigned the Locator is not available. More details are in [I-D.meyer-loc-id-implications]. Optionally, an ITR can send a Map-Request to a Locator, and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Farinacci, et al. Expires June 17, 2018 [Page 26] =0C Internet-Draft LISP December 2017 Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with Priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets, since that increases the risk of packet loss for end-to-end sessions. When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true, due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability. 10.1. Echo Nonce Algorithm When data flows bidirectionally between Locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the echo-nonce-request state, then the path to the ETR is unreachable. This decision MAY be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix. Farinacci, et al. Expires June 17, 2018 [Page 27] =0C Internet-Draft LISP December 2017 Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR MAY both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation-specific setting. However, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and subsequently continue sending echo-nonce-request packets. This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site MAY not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- probe Map-Reply message. Note other Locator Reachability mechanisms can be used to compliment or even override the echo nonce algorithm. See the next section for an example of control-plane probing. 10.2. RLOC-Probing Algorithm RLOC-Probing is a method that an ITR or PITR can use to determine the reachability status of one or more Locators that it has cached in a Map-Cache entry. The probe-bit of the Map-Request and Map-Reply messages is used for RLOC-Probing. RLOC-Probing is done in the control plane on a timer basis, where an ITR or PITR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-probes are sent periodically using a jittered timer interval. Farinacci, et al. Expires June 17, 2018 [Page 28] =0C Internet-Draft LISP December 2017 When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping data for the EID-Prefix contained in the Map-Request. This provides the opportunity for the ITR or PITR that sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC-Probing. The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) estimates between a pair of Locators, which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC-Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times is very small. 11. EID Reachability within a LISP Site A site MAY be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID- Prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header. It is recognized that there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-Prefix range is partitioned and which Locators can reach any sub- ranges of the EID-Prefixes. This problem is under investigation with the expectation that experiments will tell us more. Note that this is not a new problem introduced by the LISP architecture. The problem exists today when a multihomed site uses BGP to advertise its reachability upstream. 12. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to a requesting ITR, the Locator-Set for the EID-Prefix MAY contain different Priority values for each locator address. When more than Farinacci, et al. Expires June 17, 2018 [Page 29] =0C Internet-Draft LISP December 2017 one best Priority Locator exists, the ITR can decide how to load- share traffic against the corresponding Locators. The following hash algorithm MAY be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping. 3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers that are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets that are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. 13. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, it is desirable to maintain this approach but need to provide a way for Farinacci, et al. Expires June 17, 2018 [Page 30] =0C Internet-Draft LISP December 2017 ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When adding a new Locator record in lexicographic order to the end of a Locator-Set, it is easy to update mappings. We assume that new mappings will maintain the same Locator ordering as the old mapping but will just have new Locators appended to the end of the list. So, some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing Locator-Set. When a Locator record is inserted in the middle of a Locator-Set, to maintain lexicographic order, the SMR procedure in Section 13.2 is used to inform ITRs and PITRs of the new Locator-Status-Bit mappings. When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed. We propose here three approaches for Locator-Set compaction: one operational mechanism and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. 13.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, there is a 24-hour window to time out old mappings. The following clock sweep procedure is used: Farinacci, et al. Expires June 17, 2018 [Page 31] =0C Internet-Draft LISP December 2017 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1-hour window, the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. 4. At the end of the 1-hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So, any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a TTL equal to the TTL in the Map-Reply. 13.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data. This can only occur when both ITR and ETR functionality reside in the same router. An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches. Farinacci, et al. Expires June 17, 2018 [Page 32] =0C Internet-Draft LISP December 2017 2. A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected, and the EID-Prefix used is the one copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request. 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map-Versioning as described in Section 13.3 is used, an SMR sender can detect if an ITR is using the most up-to-date database mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- limited. This is important to avoid Map-Reply implosion. 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map- Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it may not send an SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all Locators in the Locator-Set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case they will send Map-Requests to obtain a Map-Cache entry. Farinacci, et al. Expires June 17, 2018 [Page 33] =0C Internet-Draft LISP December 2017 13.3. Database Map-Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 13.2 occurs. An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version Number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects that the Source Map- Version Number is greater than the last Map-Version Number sent in a Map-Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-Prefix, so values that are greater are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map- Version Number. See [RFC6834] for a more detailed analysis and description of Database Map-Versioning. 14. Multicast Considerations A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determine where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP Farinacci, et al. Expires June 17, 2018 [Page 34] =0C Internet-Draft LISP December 2017 header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, can use the same group address as the destination Routing Locator, use a multicast or unicast Routing Locator obtained from a Mapping System lookup, or use other means to determine the group address mapping. With respect to the source Routing Locator address, the ITR prepends its own IP address as the source address of the outer IP header. Just like it would if the destination EID was a unicast address. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable. There are two approaches for LISP-Multicast, one that uses native multicast routing in the underlay with no support from the Mapping System and the other that uses only unicast routing in the underlay with support from the Mapping System. See [RFC6831] and [I-D.ietf-lisp-signal-free-multicast], respectively, for details. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832]. 15. Router Performance Considerations LISP is designed to be very "hardware-based forwarding friendly". A few implementation techniques can be used to incrementally implement LISP: o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control-plane processing SHOULD be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data- plane. o On an ITR, prepending a new IP header consists of adding more octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. Farinacci, et al. Expires June 17, 2018 [Page 35] =0C Internet-Draft LISP December 2017 o A packet's source address or interface the packet was received on can be used to select VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. For performance issues related to map-cache management, see Section 19. 16. Mobility Considerations There are several kinds of mobility, of which only some might be of concern to LISP. Essentially, they are as follows. 16.1. Slow Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-to-RLOC mappings for sites are expected to be handled by configuration, outside of LISP. An individual endpoint wishes to move but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs [RFC4984]. 16.2. Fast Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP-layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and primarily where interactions with LISP need to be explored, such as the mechanisms in [I-D.ietf-lisp-eid-mobility] when the EID moves but the RLOC is in the network infrastructure. In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-to-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have an internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP Farinacci, et al. Expires June 17, 2018 [Page 36] =0C Internet-Draft LISP December 2017 mobility should be considered in order to optimize the behavior of the overall system. Anything that decreases the number of new EID- to-RLOC mappings needed when a node moves, or maintains the validity of an EID-to-RLOC mapping for a longer time, is useful. In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same, and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. See [I-D.ietf-lisp-predictive-rlocs] for more recent mechanisms which can provide near-zero packet loss during handoffs. 16.3. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Refer to [I-D.ietf-lisp-mn] for more details for when the EID and RLOC are co-located in the roaming node. 17. LISP xTR Placement and Encapsulation Methods This section will explore how and where ITRs and ETRs can be placed in the network and will discuss the pros and cons of each scenario. For a more detailed networkd design deployment recommendation, refer to [RFC7215]. There are two basic deployment tradeoffs to consider: centralized versus distributed caches; and flat, Recursive, or Re-encapsulating Farinacci, et al. Expires June 17, 2018 [Page 37] =0C Internet-Draft LISP December 2017 Tunneling. When deciding on centralized versus distributed caching, the following issues SHOULD be considered: o Are the xTRs spread out so that the caches are spread across all the memories of each router? A centralized cache is when an ITR keeps a cache for all the EIDs it is encapsulating to. The packet takes a direct path to the destination Locator. A distributed cache is when an ITR needs help from other Re-Encapsulating Tunnel Routers (RTRs) because it does not store all the cache entries for the EIDs it is encapsulating to. So, the packet takes a path through RTRs that have a different set of cache entries. o Should management "touch points" be minimized by only choosing a few xTRs, just enough for redundancy? o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, using more ETRs does require more management, since EID-Prefix-to- RLOC mappings need to be explicitly configured. When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the following issues SHOULD be considered: o Flat tunneling implements a single encapsulation path between the source site and destination site. This generally offers better paths between sources and destinations with a single encapsulation path. o Recursive Tunneling is when encapsulated traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control, since the site is prepending a new encapsulation header. In the case of TE-based tunneling, the site MAY have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive Tunneling generally will result in suboptimal paths but with the benefit of steering traffic to parts of the network that have more resources available. o The technique of Re-Encapsulation ensures that packets only require one encapsulation header. So, if a packet needs to be re- routed, it is first decapsulated by the RTR and then Re- Encapsulated with a new encapsulation header using a new RLOC. The next sub-sections will examine where xTRs and RTRs can reside in the network. Farinacci, et al. Expires June 17, 2018 [Page 38] =0C Internet-Draft LISP December 2017 17.1. First-Hop/Last-Hop xTRs By locating xTRs close to hosts, the EID-Prefix set is at the granularity of an IP subnet. So, at the expense of more EID-Prefix- to-RLOC sets for the site, the caches in each xTR can remain relatively small. But caches always depend on the number of non- aggregated EID destination flows active through these xTRs. With more xTRs doing encapsulation, the increase in control traffic grows as well: since the EID granularity is greater, more Map- Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios than their core router counterparts. Memory is typically less expensive in these devices, and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing states. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices. 17.2. Border/Edge xTRs Using Customer Edge (CE) routers for xTR placement allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE-based xTRs for that site. This offers the opposite benefit of the first-hop/last-hop xTR scenario: the number of mapping entries and network management touch points is reduced, allowing better scaling. One disadvantage is that fewer network resources are used to reach host endpoints, thereby centralizing the point-of-failure domain and creating network choke points at the CE xTR. Note that more than one CE xTR at a site can be configured with the same IP address. In this case, an RLOC is an anycast address. This allows resilience between the CE xTRs. That is, if a CE xTR fails, traffic is automatically routed to the other xTRs using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast Locators is the limited advertisement scope of /32 (or /128 for IPv6) routes. Farinacci, et al. Expires June 17, 2018 [Page 39] =0C Internet-Draft LISP December 2017 17.3. ISP Provider Edge (PE) xTRs The use of ISP PE routers as xTRs is not the typical deployment scenario envisioned in this specification. This section attempts to capture some of the reasoning behind this preference for implementing LISP on CE routers. The use of ISP PE routers for xTR placement gives an ISP, rather than a site, control over the location of the ETRs. That is, the ISP can decide whether the xTRs are in the destination site (in either CE xTRs or last-hop xTRs within a site) or at other PE edges. The advantage of this case is that two encapsulation headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for a new encapsuluation path to the destination end site. An obvious disadvantage is that the end site has no control over where its packets flow or over the RLOCs used. Other disadvantages include difficulty in synchronizing path liveness updates between CE and PE routers. As mentioned in earlier sections, a combination of these scenarios is possible at the expense of extra packet header overhead; if both site and provider want control, then Recursive or Re-Encapsulating Tunnels are used. 17.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control message MUST be a routable address and therefore [RFC1918] addresses SHOULD only be presence when running in a local environment. When a LISP xTR is configured with private RLOC addresses and resides behind a NAT device and desires to communicate on the Internet, the private addresses MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed when LISP VPNs are not in use. Both NAT translation and LISP encapsulation functions could be co- located in the same device. Farinacci, et al. Expires June 17, 2018 [Page 40] =0C Internet-Draft LISP December 2017 17.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache MAY not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. 18. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from the ITR to the ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Segment 1 (in source LISP site based on EIDs): source host ---> first hop ... next hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next hop ... next hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next hop ... last hop ---> destination host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal manner as they are today. The ITR performs a TTL decrement and tests for 0 before encapsulating. Therefore, the ITR's hop is seen by the traceroute source as having an EID address (the address of the site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destinations of the ICMP messages are the ITR RLOC address and the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client and also retain the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The Farinacci, et al. Expires June 17, 2018 [Page 41] =0C Internet-Draft LISP December 2017 ETR returns its RLOC address and responds to the TTL decrement to 0, as the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 18.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above, since the entire traceroute data packet is included in the ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention to forwarding ICMP messages back to the traceroute source. 18.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure, since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 octets that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended, followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source, is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload, thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). Farinacci, et al. Expires June 17, 2018 [Page 42] =0C Internet-Draft LISP December 2017 The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value. 18.3. Traceroute Using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, one cannot get all 3 segments of the traceroute. Segment 2 of the traceroute cannot be conveyed to the traceroute source, since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. 19. Security Considerations Security considerations for LISP are discussed in [RFC7833], in addition [I-D.ietf-lisp-sec] provides authentication and integrity to LISP mappings. A complete LISP threat analysis can be found in [RFC7835], in what follows we provide a summary. The optional mechanisms of gleaning is offered to directly obtain a mapping from the LISP encapsulated packets. Specifically, an xTR can learn the EID-to-RLOC mapping by inspecting the source RLOC and source EID of an encapsulated packet, and insert this new mapping into its map-cache. An off-path attacker can spoof the source EID address to divert the traffic sent to the victim's spoofed EID. If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim;s RLOC, potentially overloading it. The LISP Data-Plane defines several mechanisms to monitor RLOC data- plane reachability, in this context Locator-Status Bits, Nonce- Present and Echo-Nonce bits of the LISP encapsulation header can be manipulated by an attacker to mount a DoS attack. An off-path attacker able to spoof the RLOC of a victim's xTR can manipulate such mechanisms to declare a set of RLOCs unreachable. This can be used also, for instance, to declare only one RLOC reachable with the aim of overload it. Farinacci, et al. Expires June 17, 2018 [Page 43] =0C Internet-Draft LISP December 2017 Map-Versioning is a data-plane mechanism used to signal a peering xTR that a local EID-to-RLOC mapping has been updated, so that the peering xTR uses LISP Control-Plane signaling message to retrieve a fresh mapping. This can be used by an attacker to forge the map- versioning field of a LISP encapsulated header and force an excessive amount of signaling between xTRs that may overload them. Most of the attack vectors can be mitigated with careful deployment and configuration, information learned opportunistically (such as LSB or gleaning) SHOULD be verified with other reachability mechanisms. In addition, systematic rate-limitation and filtering is an effective technique to mitigate attacks that aim to overload the control-plane. 20. Network Management Considerations Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [RFC7052] and [RFC6835]. 21. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this data-plane LISP specification, in accordance with BCP 26 [RFC5226]. 21.1. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for lisp-data and lisp-control operation, respectively. IANA has updated the description for UDP ports 4341 and 4342 as follows: lisp-data 4341 udp LISP Data Packets lisp-control 4342 udp LISP Control Packets 22. References 22.1. Normative References [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- ddt-09 (work in progress), January 2017. [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. Farinacci, et al. Expires June 17, 2018 [Page 44] =0C Internet-Draft LISP December 2017 [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-06 (work in progress), October 2017. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 (work in progress), October 2017. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . Farinacci, et al. Expires June 17, 2018 [Page 45] =0C Internet-Draft LISP December 2017 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, DOI 10.17487/RFC6115, February 2011, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, DOI 10.17487/RFC7052, October 2013, . Farinacci, et al. Expires June 17, 2018 [Page 46] =0C Internet-Draft LISP December 2017 [RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry", RFC 7214, DOI 10.17487/RFC7214, May 2014, . [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, . [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 22.2. Informative References [AFN] IANA, "Address Family Numbers", August 2016, . [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, . [I-D.ietf-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-ietf-lisp-eid-mobility-01 (work in progress), November 2017. Farinacci, et al. Expires June 17, 2018 [Page 47] =0C Internet-Draft LISP December 2017 [I-D.ietf-lisp-mn] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", draft-ietf-lisp-mn-01 (work in progress), October 2017. [I-D.ietf-lisp-predictive-rlocs] Farinacci, D. and P. Pillay-Esnault, "LISP Predictive RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in progress), November 2017. [I-D.ietf-lisp-signal-free-multicast] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", draft-ietf-lisp-signal-free-multicast-07 (work in progress), November 2017. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in progress), November 2017. [I-D.meyer-loc-id-implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01 (work in progress), January 2009. [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996. [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . Farinacci, et al. Expires June 17, 2018 [Page 48] =0C Internet-Draft LISP December 2017 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, . [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, DOI 10.17487/RFC4192, September 2005, . [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, DOI 10.17487/RFC4866, May 2007, . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, DOI 10.17487/RFC6518, February 2012, . [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, . [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, . Farinacci, et al. Expires June 17, 2018 [Page 49] =0C Internet-Draft LISP December 2017 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, . [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/RFC6837, January 2013, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . Farinacci, et al. Expires June 17, 2018 [Page 50] =0C Internet-Draft LISP December 2017 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, Alia Atlas, Florin Coras and Alberto Rodriguez. This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC. The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward standards-track RFCs. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] Farinacci, et al. Expires June 17, 2018 [Page 51] =0C Internet-Draft LISP December 2017 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 o Posted December 2017. o Remove references to research work for any protocol mechanisms. o Document scanned to make sure it is RFC 2119 compliant. B.2. Changes to draft-ietf-lisp-rfc6830bis-07 o Posted November 2017. o Rephrase how Instance-IDs are used and don't refer to [RFC1918] addresses. B.3. Changes to draft-ietf-lisp-rfc6830bis-06 o Posted October 2017. o Put RTR definition before it is used. o Rename references that are now working group drafts. o Remove "EIDs MUST NOT be used as used by a host to refer to other hosts. Note that EID blocks MAY LISP RLOCs". o Indicate what address-family can appear in data packets. o ETRs may, rather than will, be the ones to send Map-Replies. o Recommend, rather than mandate, max encapsulation headers to 2. o Reference VPN draft when introducing Instance-ID. o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Clarify when private addreses can be used. B.4. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Reencapsulating Tunnel Router is an RTR. Farinacci, et al. Expires June 17, 2018 [Page 52] =0C Internet-Draft LISP December 2017 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 o Posted July 2017. o Changed reference of IPv6 RFC2460 to RFC8200. o Indicate that the applicability statement for UDP zero checksums over IPv6 adheres to RFC6936. B.6. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. B.7. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. B.8. Changes to draft-ietf-lisp-rfc6830bis-01 o Posted March 2017. o Include references to new RFCs published. o Change references from RFC6833 to RFC6833bis. o Clarified LCAF text in the IANA section. o Remove references to "experimental". B.9. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses Farinacci, et al. Expires June 17, 2018 [Page 53] =0C Internet-Draft LISP December 2017 Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: farinacci@gmail.com Vince Fuller Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: vince.fuller@gmail.com Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: dmm@1-4-5.net Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: darlewis@cisco.com Albert Cabellos UPC/BarcelonaTech Campus Nord, C. Jordi Girona 1-3 Barcelona, Catalunya Spain EMail: acabello@ac.upc.edu Farinacci, et al. Expires June 17, 2018 [Page 54] --Apple-Mail=_9F936107-2DF3-41BC-9AED-122CAEAD32FD-- From nobody Thu Dec 14 09:59:23 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B9F126DFF for ; Thu, 14 Dec 2017 09:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWZE0A5Dn2In for ; Thu, 14 Dec 2017 09:59:19 -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 4F93C129413 for ; Thu, 14 Dec 2017 09:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4303; q=dns/txt; s=iport; t=1513274359; x=1514483959; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xVQSvBXo5eMrFpAJZnAxpGK1XkhAe0nPNJKvQF0y2VM=; b=KOt7wLkt/M1gipxywnfxJBK8N1+Y06A1TSmQ1YPXTQUOaDNHTaG26r8X l3t03sTrIgYjG7aC4axvzoExj8pegBh+BgTwP7+WE2Hupd21nmqfIERno RbNAhZszC0pBl1bTrdVqIxPDJMvaumXmZpA/3SmQmdvrTYJKFvDsFsfv4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPBAC9uzJa/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0J4QCmSeBTi+XFoIVChgLgTkBg14ChHdAFwEBAQEBAQE?= =?us-ascii?q?BAWsohSQBAQEDAQEbBg8BBTYLEAkCGAICJgICJzAGAQwGAgEBF4oPEIs0nWyCJ?= =?us-ascii?q?4peAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4JWgg6BVoFpKYMCgUmBZQGBR4M?= =?us-ascii?q?8gmMFkymPfId9jS2CFol+h1iKR4JOiViBOyABN4FOMhoIGxU6gimCX4IYIDeID?= =?us-ascii?q?oJIAQEB?= X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="44702728" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 17:59:18 +0000 Received: from [10.24.69.90] ([10.24.69.90]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vBEHxH6W027888; Thu, 14 Dec 2017 17:59:18 GMT To: Dino Farinacci , Luigi Iannone Cc: "lisp@ietf.org" References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> From: Fabio Maino Message-ID: <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> Date: Thu, 14 Dec 2017 09:59:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:59:22 -0000 Since there seem to be consensus, can we ask for WG adoption of LISP-GPE and include it as an informative reference as the other drafts that are in 6830bis? Can the chairs open a call for adoption in the mailing list, or do we need to wait the next IETF? This might be similar to what Dino proposes below. Thanks, Fabio On 12/14/17 9:01 AM, Dino Farinacci wrote: > I would prefer to not merge the two documents. Should we say in RFC6830bis that the R-bit is already allocated but don’t way why and make no reference. If no, I go for option A. > > Dino > >> On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >> >> His All, >> >> happy to see so much consensus :-) >> >> >> >> As a chair I have to point out that if you add text in 6830bis to allocate the last bit and refer to draft-lewis-lisp-gpe you are creating an authoritative dependency on a to a document that as for now is not even WG item. >> This will block the publication of 6830bis as RFC (remember the intro document…….). >> >> There are two possible solutions: >> >> A. 6830bis remains unchanged, leaving the P-bit marked as reserved for future use. draft-lewis-lisp-gpe will than allocate this last bit and detail the operations. >> >> B. We merge the two documents. >> >> I do not have a preference, up to the WG to decide, but better to avoid document dependencies that will block publication. >> >> >> >> Ciao >> >> L. >> >> >> >>> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>> >>> I would like to suggest a way to address mutiprotocol support in RFC6830bis, that may address what was discussed in Singapore. >>> This is based on using the last reserved bit in the LISP header as P bit to indicate support for multiprotocol encapsulation, as specified in the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >>> The header, as specified in section 5.1, would look like: >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol | >>> I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> S / | Instance ID/Locator-Status-Bits | >>> P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> and the text in section 5.3 that reserves the 6th bit would be replaced by: >>> >>> P: The P-bit is the Next Protocol bit. When this bit is set to >>> 1, the V-bit MUST be set to 0 and the Nonce length, when used, is >>> limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details. >>> The P-bit is set to 1 to indicate the presence of the 8 bit Next >>> Protocol field encoded as: >>> >>> x x x 0 x 1 x x >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Instance ID/Locator-Status-Bits | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> I will have to refresh the LISP-GPE draft, and reflect the allocations of the KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE to indicate OAM packets, but that same functionality can be done using the Next-Protocol field. >>> >>> The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that. >>> >>> This would address the multiprotocol working item included in the current charter. >>> >>> I can very quickly update the LISP-GPE draft to reflect this, but I wanted to hear what the group thinks first. >>> >>> Thanks, >>> Fabio >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Dec 14 10:00:41 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59944126DFF for ; Thu, 14 Dec 2017 10:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EX0mxbHnHXc8 for ; Thu, 14 Dec 2017 10:00:36 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3448124BAC for ; Thu, 14 Dec 2017 10:00:36 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id e14so3897912pgr.9 for ; Thu, 14 Dec 2017 10:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LuHfFqTDKzUyphdLbWX7znnyUI8BuIypuS3HoX0+gZU=; b=fMlsPuZHwRvq82UCyV8aBXe5taJObrUDbqBHz/KsNJSihCi5BLYnuagUg7sM+rp3hz CkDFGUVte8CMe6664FuIN0Frw71P5tzklk/1/nt0oZsF35eOI6zR3Ai9f3wRmkHn36/T Hbd7UWW1oHbODpO0K+dxJyH1sXFfQQ8Th5sa+gjUrkPpDE/qbUbeeQoPSIgymo0Q82/b 28800sQQjjUaNiDus+fWp5l5pQo7Mc/H/MVMDGsG7797k9cp8kFTYYD3ZUFTcb3Nv4fB 3CUr7fSu3T1vRH/gPIQ9qeQY3opj/uRedUFDWzBa8XB3IddhNlHnwEdbw8PKfYKdxiDl p7zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LuHfFqTDKzUyphdLbWX7znnyUI8BuIypuS3HoX0+gZU=; b=X5CJ30fQgYEKVRckt3RLAGgVPdwKsJBC4kw6lh2otqugHh1HesCMnHrfpJ1i4cZhUk 58jPTIsgn0UbOnhrR/eL3+JxwXivTpZpJMm77VPVG8OwGECgdApBOIi2t3vkCXHEMOPc VzEENT8Xo9Oy3GeYAibprdEGvoFzI9c749ojgolxs9+h1eReOJtgar87FYF/qUS8EreR 8dkvKshNUwhnTp0IdOpVWky2sxaNjCvi4JHY7d/7OJoy8m3fdCd2zv+S+FxTk8G9BQVc 6hQ6Ibu3roeugik2MiD0/1cPAJGfCrSkeBZnofAOz8cErttXcZxbupoCf7fBLZwE+6tX W31g== X-Gm-Message-State: AKGB3mI9+zfXovvo/PjdVif6Bq9aHW1fVHQAFY9IEagESaxlziToqtH5 MkCxMGg9B5vkXkB9beCQb1JSko/Y X-Google-Smtp-Source: ACJfBotY1wMS0b6SFDFCopXme4uUoBr28h1NG4szdspPJbSXUtnu6M3im5xVYK21hSwP/2fxnVC8qA== X-Received: by 10.99.95.22 with SMTP id t22mr9085225pgb.195.1513274436116; Thu, 14 Dec 2017 10:00:36 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id q22sm9455182pfj.94.2017.12.14.10.00.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 10:00:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> Date: Thu, 14 Dec 2017 10:00:34 -0800 Cc: Luigi Iannone , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 18:00:39 -0000 It is different but I=E2=80=99m okay with your suggestion. Dino > On Dec 14, 2017, at 9:59 AM, Fabio Maino wrote: >=20 > Since there seem to be consensus, can we ask for WG adoption of = LISP-GPE and include it as an informative reference as the other drafts = that are in 6830bis? >=20 > Can the chairs open a call for adoption in the mailing list, or do we = need to wait the next IETF? >=20 > This might be similar to what Dino proposes below. >=20 > Thanks, > Fabio >=20 > On 12/14/17 9:01 AM, Dino Farinacci wrote: >> I would prefer to not merge the two documents. Should we say in = RFC6830bis that the R-bit is already allocated but don=E2=80=99t way why = and make no reference. If no, I go for option A. >>=20 >> Dino >>=20 >>> On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >>>=20 >>> His All, >>>=20 >>> happy to see so much consensus :-) >>>=20 >>> >>>=20 >>> As a chair I have to point out that if you add text in 6830bis to = allocate the last bit and refer to draft-lewis-lisp-gpe you are creating = an authoritative dependency on a to a document that as for now is not = even WG item. >>> This will block the publication of 6830bis as RFC (remember the = intro document=E2=80=A6=E2=80=A6.). >>>=20 >>> There are two possible solutions: >>>=20 >>> A. 6830bis remains unchanged, leaving the P-bit marked as reserved = for future use. draft-lewis-lisp-gpe will than allocate this last bit = and detail the operations. >>>=20 >>> B. We merge the two documents. >>>=20 >>> I do not have a preference, up to the WG to decide, but better to = avoid document dependencies that will block publication. >>>=20 >>> >>>=20 >>> Ciao >>>=20 >>> L. >>>=20 >>>=20 >>>=20 >>>> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>>>=20 >>>> I would like to suggest a way to address mutiprotocol support in = RFC6830bis, that may address what was discussed in Singapore. >>>> This is based on using the last reserved bit in the LISP header as = P bit to indicate support for multiprotocol encapsulation, as specified = in the LISP-GPE draft = (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >>>> The header, as specified in section 5.1, would look like: >>>>=20 >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol = | >>>> I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> S / | Instance ID/Locator-Status-Bits = | >>>> P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>>>=20 >>>> and the text in section 5.3 that reserves the 6th bit would be = replaced by: >>>>=20 >>>> P: The P-bit is the Next Protocol bit. When this bit is set to >>>> 1, the V-bit MUST be set to 0 and the Nonce length, when = used, is >>>> limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more = details. >>>> The P-bit is set to 1 to indicate the presence of the 8 bit = Next >>>> Protocol field encoded as: >>>>=20 >>>> x x x 0 x 1 x x >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |N|L|E|V|I|P|K|K| Nonce | Next-Protocol = | >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Instance ID/Locator-Status-Bits = | >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>>>=20 >>>> I will have to refresh the LISP-GPE draft, and reflect the = allocations of the KK bits according to RFC8061 and Nonce. One of the K = bits was used by LISP-GPE to indicate OAM packets, but that same = functionality can be done using the Next-Protocol field. >>>>=20 >>>> The use of the P-bit is not compatible with the Map-Versioning = feature, but an equivalent function can be specified (if needed) with a = Next-Protocol shim header. I can add text to the LISP-GPE draft to = reflect that. >>>>=20 >>>> This would address the multiprotocol working item included in the = current charter. >>>>=20 >>>> I can very quickly update the LISP-GPE draft to reflect this, but I = wanted to hear what the group thinks first. >>>>=20 >>>> Thanks, >>>> Fabio >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 From nobody Thu Dec 14 10:11:36 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6671270B4 for ; Thu, 14 Dec 2017 10:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0cKNHF3Lnzfu for ; Thu, 14 Dec 2017 10:11:33 -0800 (PST) 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 4E79F12704A for ; Thu, 14 Dec 2017 10:11:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 35ACC3607DE; Thu, 14 Dec 2017 10:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1513275093; bh=AOnd9uy/C/DfsNnobr5PrTE7hP1823vh6kfTc6Lh0do=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jDCtEw/nsuHWAhqEx/LmOrpuF8LFiL8NbpW9UF+nBnwz76zC33YvpmoSkXU3ZCeYh W4fl+iUd34nrt3zPNpWYrp8q7FCUDGPJSNdl3BNo2X+uHCmaABSPX0mTPHHY/gfkeY 2Syzznnl0wwR2fI+3P4RH4EpC2IR6nbvqq38dyFQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 3D7BE3607DD; Thu, 14 Dec 2017 10:11:32 -0800 (PST) To: Fabio Maino , Dino Farinacci , Luigi Iannone Cc: "lisp@ietf.org" References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 14 Dec 2017 13:11:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 18:11:35 -0000 Let's separate things: 1) We can have a call for adoption of LISP GPE. Meetings are not special in terms of working group formal actions. 2) My personal read is that if we assign the bit a meaning in 6830bis, then the reference has to be normative, as a reader seeking to understand the RFC would need to read the other document to know what the bit meant. (My thanks to Luigi for catching this.) 2') I see no reason why the bit should be assigned in 6830bis. As long as we leave it reserved in 6830bis, LISP-GPE can assign it. That is what RFCs and registries are for. So my personal preference would be to leave the protocol identification bit out of 6830bis. Yours, Joel On 12/14/17 12:59 PM, Fabio Maino wrote: > Since there seem to be consensus, can we ask for WG adoption of LISP-GPE > and include it as an informative reference as the other drafts that are > in 6830bis? > > Can the chairs open a call for adoption in the mailing list, or do we > need to wait the next IETF? > > This might be similar to what Dino proposes below. > > Thanks, > Fabio > > On 12/14/17 9:01 AM, Dino Farinacci wrote: >> I would prefer to not merge the two documents. Should we say in >> RFC6830bis that the R-bit is already allocated but don’t way why and >> make no reference. If no, I go for option A. >> >> Dino >> >>> On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >>> >>> His All, >>> >>> happy to see so much consensus :-) >>> >>> >>> >>> As a chair I have to point out that if you add text in 6830bis to >>> allocate the last bit and refer to draft-lewis-lisp-gpe you are >>> creating an authoritative dependency on a to a document that as for >>> now is not even WG item. >>> This will block the publication of 6830bis as RFC (remember the intro >>> document…….). >>> >>> There are two possible solutions: >>> >>> A. 6830bis remains unchanged, leaving the P-bit marked as reserved >>> for future use. draft-lewis-lisp-gpe will than allocate this last bit >>> and detail the operations. >>> >>> B. We merge the two documents. >>> >>> I do not have a preference, up to the WG to decide, but better to >>> avoid document dependencies that will block publication. >>> >>> >>> >>> Ciao >>> >>> L. >>> >>> >>> >>>> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>>> >>>> I would like to suggest a way to address mutiprotocol support in >>>> RFC6830bis, that may address what was discussed in Singapore. >>>> This is based on using the last reserved bit in the LISP header as P >>>> bit to indicate support for multiprotocol encapsulation, as >>>> specified in the LISP-GPE draft >>>> (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >>>> The header, as specified in section 5.1, would look like: >>>> >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>     L   |N|L|E|V|I|P|K|K| >>>> Nonce/Map-Version/Next-Protocol    | >>>>     I \ >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>     S / |                 Instance >>>> ID/Locator-Status-Bits               | >>>>     P >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> and the text in section 5.3 that reserves the 6th bit would be >>>> replaced by: >>>> >>>>     P: The P-bit is the Next Protocol bit. When this bit is set to >>>>        1, the V-bit MUST be set to 0 and the Nonce length, when >>>> used, is >>>>        limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more >>>> details. >>>>        The P-bit is set to 1 to indicate the presence of the 8 bit Next >>>>        Protocol field encoded as: >>>> >>>>       x x x 0 x 1 x x >>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>      |N|L|E|V|I|P|K|K|           Nonce               | Next-Protocol | >>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>      |                 Instance ID/Locator-Status-Bits               | >>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> I will have to refresh the LISP-GPE draft, and reflect the >>>> allocations of the KK bits according to RFC8061 and Nonce. One of >>>> the K bits was used by LISP-GPE to indicate OAM packets, but that >>>> same functionality can be done using the Next-Protocol field. >>>> >>>> The use of the P-bit is not compatible with the Map-Versioning >>>> feature, but an equivalent function can be specified (if needed) >>>> with a Next-Protocol shim header. I can add text to the LISP-GPE >>>> draft to reflect that. >>>> >>>> This would address the multiprotocol working item included in the >>>> current charter. >>>> >>>> I can very quickly update the LISP-GPE draft to reflect this, but I >>>> wanted to hear what the group thinks first. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Dec 14 10:28:24 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B90612704A for ; Thu, 14 Dec 2017 10:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZnZQE9O7rSp for ; Thu, 14 Dec 2017 10:28:18 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3E51200FC for ; Thu, 14 Dec 2017 10:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6526; q=dns/txt; s=iport; t=1513276097; x=1514485697; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+Q0ug0cdzh7BHXHxXPHyecceTJfAEkK3a7a+76Yz6SI=; b=NsHn2snli5ZBC7QDXhACrdqAqFfEkwp33WoeJvphod0Ngtd8D1JJXr/m uZaEhHNo1CPMwCHOc2qT1u7ghlU8VQB9uzE7ywdSNQB507o/NGpYkwkJW 9k55SzPsel99hK7h+9n0gY2CLQPYcB7sP742XN/J5FWz3Onf5BuAI2SvE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0BABJwjJa/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnhAKZJ4FOCSaXFoIVChgLgTkBg14ChHdBFgEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQEBAgEBARsGDwEFNgsFCwkCGAICJgICJzAGAQwGAgEBF4oHCBCLO?= =?us-ascii?q?J1sgieKXgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CVoIOgVaBaSkLgneBSYF?= =?us-ascii?q?lAYFHgzyCYwWTKY98h32NLYIWiX4khzSKR4JOiViBOyYGLIFOMhoIGxU6gimCX?= =?us-ascii?q?4IYIDeIDoJIAQEB?= X-IronPort-AV: E=Sophos;i="5.45,401,1508803200"; d="scan'208";a="332253164" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 18:28:16 +0000 Received: from [10.24.69.90] ([10.24.69.90]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vBEISGJV022318; Thu, 14 Dec 2017 18:28:16 GMT To: "Joel M. Halpern" , Dino Farinacci , Luigi Iannone Cc: "lisp@ietf.org" References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> From: Fabio Maino Message-ID: <3702c899-5180-c1f8-758f-037207da0113@cisco.com> Date: Thu, 14 Dec 2017 10:28:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 18:28:20 -0000 On 12/14/17 10:11 AM, Joel M. Halpern wrote: > Let's separate things: > > 1) We can have a call for adoption of LISP GPE.  Meetings are not > special in terms of working group formal actions. agree. Doing it seems to be helpful whatever the WG decides to do with 6830bis. > > 2) My personal read is that if we assign the bit a meaning in 6830bis, > then the reference has to be normative, as a reader seeking to > understand the RFC would need to read the other document to know what > the bit meant.  (My thanks to Luigi for catching this.) Sounds reasonable, the reference should be normative then. Now, there are other drafts in the normative section: once GPE is adopted we would be in the same situation, and we could deal with it in the same way we do for the others. > 2') I see no reason why the bit should be assigned in 6830bis.  As > long as we leave it reserved in 6830bis, LISP-GPE can assign it. That > is what RFCs and registries are for. It would be helpful to document all the LISP  dataplane features in 6830bis. I think this  was one of the goals of having a dataplane document. Since we are so close, and there's consensus, if 1 and 2 above makes sense the WG could start the call for adoption of GPE asap. If that works the WG could then proceed with the last call for 6830bis. Fabio > > So my personal preference would be to leave the protocol > identification bit out of 6830bis. > > Yours, > Joel > > On 12/14/17 12:59 PM, Fabio Maino wrote: >> Since there seem to be consensus, can we ask for WG adoption of >> LISP-GPE and include it as an informative reference as the other >> drafts that are in 6830bis? >> >> Can the chairs open a call for adoption in the mailing list, or do we >> need to wait the next IETF? >> >> This might be similar to what Dino proposes below. >> >> Thanks, >> Fabio >> >> On 12/14/17 9:01 AM, Dino Farinacci wrote: >>> I would prefer to not merge the two documents. Should we say in >>> RFC6830bis that the R-bit is already allocated but don’t way why and >>> make no reference. If no, I go for option A. >>> >>> Dino >>> >>>> On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >>>> >>>> His All, >>>> >>>> happy to see so much consensus :-) >>>> >>>> >>>> >>>> As a chair I have to point out that if you add text in 6830bis to >>>> allocate the last bit and refer to draft-lewis-lisp-gpe you are >>>> creating an authoritative dependency on a to a document that as for >>>> now is not even WG item. >>>> This will block the publication of 6830bis as RFC (remember the >>>> intro document…….). >>>> >>>> There are two possible solutions: >>>> >>>> A. 6830bis remains unchanged, leaving the P-bit marked as reserved >>>> for future use. draft-lewis-lisp-gpe will than allocate this last >>>> bit and detail the operations. >>>> >>>> B. We merge the two documents. >>>> >>>> I do not have a preference, up to the WG to decide, but better to >>>> avoid document dependencies that will block publication. >>>> >>>> >>>> >>>> Ciao >>>> >>>> L. >>>> >>>> >>>> >>>>> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>>>> >>>>> I would like to suggest a way to address mutiprotocol support in >>>>> RFC6830bis, that may address what was discussed in Singapore. >>>>> This is based on using the last reserved bit in the LISP header as >>>>> P bit to indicate support for multiprotocol encapsulation, as >>>>> specified in the LISP-GPE draft >>>>> (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >>>>> The header, as specified in section 5.1, would look like: >>>>> >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>     L   |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol    | >>>>>     I \ >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>     S / |                 Instance >>>>> ID/Locator-Status-Bits               | >>>>>     P >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> >>>>> and the text in section 5.3 that reserves the 6th bit would be >>>>> replaced by: >>>>> >>>>>     P: The P-bit is the Next Protocol bit. When this bit is set to >>>>>        1, the V-bit MUST be set to 0 and the Nonce length, when >>>>> used, is >>>>>        limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for >>>>> more details. >>>>>        The P-bit is set to 1 to indicate the presence of the 8 bit >>>>> Next >>>>>        Protocol field encoded as: >>>>> >>>>>       x x x 0 x 1 x x >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>      |N|L|E|V|I|P|K|K|           Nonce               | >>>>> Next-Protocol | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>      |                 Instance >>>>> ID/Locator-Status-Bits               | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> >>>>> I will have to refresh the LISP-GPE draft, and reflect the >>>>> allocations of the KK bits according to RFC8061 and Nonce. One of >>>>> the K bits was used by LISP-GPE to indicate OAM packets, but that >>>>> same functionality can be done using the Next-Protocol field. >>>>> >>>>> The use of the P-bit is not compatible with the Map-Versioning >>>>> feature, but an equivalent function can be specified (if needed) >>>>> with a Next-Protocol shim header. I can add text to the LISP-GPE >>>>> draft to reflect that. >>>>> >>>>> This would address the multiprotocol working item included in the >>>>> current charter. >>>>> >>>>> I can very quickly update the LISP-GPE draft to reflect this, but >>>>> I wanted to hear what the group thinks first. >>>>> >>>>> Thanks, >>>>> Fabio >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Dec 15 01:08:58 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40036127599 for ; Fri, 15 Dec 2017 01:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXzQX_2ZmcSx for ; Fri, 15 Dec 2017 01:08:49 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 C312412708C for ; Fri, 15 Dec 2017 01:08:48 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id 9so16007430wme.4 for ; Fri, 15 Dec 2017 01:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VGnrAkQtvWNbu/hd2/rzu58xdACn9xR4qgP0pe7NjC0=; b=Y+4BQ0ovH6j8p7rp/kuM7mztqc2WCI6LWz9srt4VPNFOUwE9wlTWTGT2Pm+HwSjzlF ke1DIwnK49kpy7rVicEE7vWjSh6gpV1pzQVB/GONVDrp467z0xJ++T4kdKPM3Med45Sy NLtqLbC+QUc4+8Pei05cO6w6Lz6AYQx59tsyEGo2N+Sd3r/Tz9LBURxmsQ27PWUgL72X PEsy8QXvkjPQR9sA+49ao3gv+hu0pbGCK2h7Rk5zx5KYoa1VZdCWdbQihTKEJLD7iaZB t0uRkUNE5UIWU+QXHfV3z2IYMPvogMv1r+VvF5yjtrishzRKGBihD4ZAq9id9UxFaWVB PwEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VGnrAkQtvWNbu/hd2/rzu58xdACn9xR4qgP0pe7NjC0=; b=Q98FjOEXVb9AtIIU/2fKJnP0M2cDQ/htOVfc/cSnHUJFyORCgR3RPNCVUfA6nAWBN1 wvApsQYxe0DDHyARj1Q2MR5gh8EEmVzGxhh8ymWyJn2+7A3QE3CvAqq6qdkv3tqPKmuK 0g1q7Eg6BrizK1ICEAwFSF9wGAck9Ea1/DlQGPHuqUM4VSOihUtEzYszc6XU5boWhhGV 3jTpSCO1alrkrrYLtdg+a/1FRd8HP75aglJsNWSDNKB7Vulw/4ELFu2bXO/DSZoGg9yh 1RFygAD/V02bxBNFlI3qfCjGDnBddA0ziFfeB1XY5/4Ud5GqDyvVzJsmHqfVOFHPPWlR ImEA== X-Gm-Message-State: AKGB3mL3dzrPrg+OxQenomF4k3jf4TLOuc6vRyheWinFQnvIt4msNvhA pLkLg71IbVB6YHztcs5ElL/xmA== X-Google-Smtp-Source: ACJfBovgGfvh1m9M/bIKz8Zw2P1gInNrY/nagrMxpB3mpSlv/0gQUz9ia762yMxbu48U8EMQjnyeeQ== X-Received: by 10.80.201.12 with SMTP id o12mr16116792edh.90.1513328926962; Fri, 15 Dec 2017 01:08:46 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:2514:f1b4:f089:fa28? ([2001:660:330f:a4:2514:f1b4:f089:fa28]) by smtp.gmail.com with ESMTPSA id s14sm4836700eds.78.2017.12.15.01.08.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 01:08:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Luigi Iannone In-Reply-To: <3702c899-5180-c1f8-758f-037207da0113@cisco.com> Date: Fri, 15 Dec 2017 10:08:46 +0100 Cc: "Joel M. Halpern" , Dino Farinacci , "lisp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <679651E1-E520-43CB-8608-79926BA7660C@gigix.net> References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> <3702c899-5180-c1f8-758f-037207da0113@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 09:08:56 -0000 > On 14 Dec 2017, at 19:28, Fabio Maino wrote: >=20 > On 12/14/17 10:11 AM, Joel M. Halpern wrote: >> Let's separate things: >>=20 >> 1) We can have a call for adoption of LISP GPE. Meetings are not = special in terms of working group formal actions. > agree. Doing it seems to be helpful whatever the WG decides to do with = 6830bis. That works for me. >=20 >>=20 >> 2) My personal read is that if we assign the bit a meaning in = 6830bis, then the reference has to be normative, as a reader seeking to = understand the RFC would need to read the other document to know what = the bit meant. (My thanks to Luigi for catching this.) >=20 > Sounds reasonable, the reference should be normative then. >=20 > Now, there are other drafts in the normative section: once GPE is = adopted we would be in the same situation, and we could deal with it in = the same way we do for the others. >=20 That is not correct. As part of my review (Send it out later today) I = have seen that a lot of references that are declared Normative are = actually not at all so. The only Normative reference which is in draft status is 6833bis, which = is a different matter. So the way to proceed is: Mark the bit reserved in 6830bis and say nothing. Nobody can allocate = the bit without WG consensus, hence there is risk in proceeding this = way. Adopt LISP-GPE which will be a self contained document allocating the = bit. Ciao Luigi >> 2') I see no reason why the bit should be assigned in 6830bis. As = long as we leave it reserved in 6830bis, LISP-GPE can assign it. That is = what RFCs and registries are for. >=20 > It would be helpful to document all the LISP dataplane features in = 6830bis. I think this was one of the goals of having a dataplane = document. >=20 > Since we are so close, and there's consensus, if 1 and 2 above makes = sense the WG could start the call for adoption of GPE asap. If that = works the WG could then proceed with the last call for 6830bis. >=20 > Fabio >=20 >=20 >>=20 >> So my personal preference would be to leave the protocol = identification bit out of 6830bis. >>=20 >> Yours, >> Joel >>=20 >> On 12/14/17 12:59 PM, Fabio Maino wrote: >>> Since there seem to be consensus, can we ask for WG adoption of = LISP-GPE and include it as an informative reference as the other drafts = that are in 6830bis? >>>=20 >>> Can the chairs open a call for adoption in the mailing list, or do = we need to wait the next IETF? >>>=20 >>> This might be similar to what Dino proposes below. >>>=20 >>> Thanks, >>> Fabio >>>=20 >>> On 12/14/17 9:01 AM, Dino Farinacci wrote: >>>> I would prefer to not merge the two documents. Should we say in = RFC6830bis that the R-bit is already allocated but don=E2=80=99t way why = and make no reference. If no, I go for option A. >>>>=20 >>>> Dino >>>>=20 >>>>> On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >>>>>=20 >>>>> His All, >>>>>=20 >>>>> happy to see so much consensus :-) >>>>>=20 >>>>> >>>>>=20 >>>>> As a chair I have to point out that if you add text in 6830bis to = allocate the last bit and refer to draft-lewis-lisp-gpe you are creating = an authoritative dependency on a to a document that as for now is not = even WG item. >>>>> This will block the publication of 6830bis as RFC (remember the = intro document=E2=80=A6=E2=80=A6.). >>>>>=20 >>>>> There are two possible solutions: >>>>>=20 >>>>> A. 6830bis remains unchanged, leaving the P-bit marked as reserved = for future use. draft-lewis-lisp-gpe will than allocate this last bit = and detail the operations. >>>>>=20 >>>>> B. We merge the two documents. >>>>>=20 >>>>> I do not have a preference, up to the WG to decide, but better to = avoid document dependencies that will block publication. >>>>>=20 >>>>> >>>>>=20 >>>>> Ciao >>>>>=20 >>>>> L. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>>>>>=20 >>>>>> I would like to suggest a way to address mutiprotocol support in = RFC6830bis, that may address what was discussed in Singapore. >>>>>> This is based on using the last reserved bit in the LISP header = as P bit to indicate support for multiprotocol encapsulation, as = specified in the LISP-GPE draft = (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >>>>>> The header, as specified in section 5.1, would look like: >>>>>>=20 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol | >>>>>> I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> S / | Instance ID/Locator-Status-Bits = | >>>>>> P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>=20 >>>>>>=20 >>>>>> and the text in section 5.3 that reserves the 6th bit would be = replaced by: >>>>>>=20 >>>>>> P: The P-bit is the Next Protocol bit. When this bit is set = to >>>>>> 1, the V-bit MUST be set to 0 and the Nonce length, when = used, is >>>>>> limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for = more details. >>>>>> The P-bit is set to 1 to indicate the presence of the 8 = bit Next >>>>>> Protocol field encoded as: >>>>>>=20 >>>>>> x x x 0 x 1 x x >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> |N|L|E|V|I|P|K|K| Nonce | = Next-Protocol | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Instance ID/Locator-Status-Bits = | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>=20 >>>>>>=20 >>>>>> I will have to refresh the LISP-GPE draft, and reflect the = allocations of the KK bits according to RFC8061 and Nonce. One of the K = bits was used by LISP-GPE to indicate OAM packets, but that same = functionality can be done using the Next-Protocol field. >>>>>>=20 >>>>>> The use of the P-bit is not compatible with the Map-Versioning = feature, but an equivalent function can be specified (if needed) with a = Next-Protocol shim header. I can add text to the LISP-GPE draft to = reflect that. >>>>>>=20 >>>>>> This would address the multiprotocol working item included in the = current charter. >>>>>>=20 >>>>>> I can very quickly update the LISP-GPE draft to reflect this, but = I wanted to hear what the group thinks first. >>>>>>=20 >>>>>> Thanks, >>>>>> Fabio >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 From nobody Fri Dec 15 01:27:51 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57CF127B60 for ; Fri, 15 Dec 2017 01:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WC8nhPmoJbbg for ; Fri, 15 Dec 2017 01:27:46 -0800 (PST) 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 811F1127B52 for ; Fri, 15 Dec 2017 01:27:46 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id t8so16115147wmc.3 for ; Fri, 15 Dec 2017 01:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Di3fVhZWL5u4nVgx7HvFnaLGvLgydH3ChBJOoLT3klI=; b=HUDKS8IzK4vkWHNv8Udjl1GhApxcamrF7eC+3hMsukW11iEOq9Mp3fDNXlmzuqPJNM wHWeOnmY/Yk6KdigTDpcUE6VBuBZrQi10sm9K5v20kzs6z0iOpAreJLUGT6ty4PN7MbM qgr1xsL9nZ6xWtzqyMJw4ccdK23jBJIVDb6W+Hd96uGdIX1aRAfjQXjFCLpYALKRAWuR HLQCQyz3ak4R+hPLbtKzjbcdTqPaeWhDe83TMFd/O0koPBeUF2yaJ3wYZLXzQ/hkk9Kn TtiK5GcWtMbu8YW2ziX41ZL4prPWQLfjY77ip4cGB42BYUg/ZX8kUj8NYT3+tB5IlDKb DBWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Di3fVhZWL5u4nVgx7HvFnaLGvLgydH3ChBJOoLT3klI=; b=pKB9suVe/DdjR+oDUwr7+R2gu1dVQlpT8d29j0WU79mp16I2Xan5KBF/N6IvX7x3nd szqQNsUtoo7o07CVW+5sjTHDCqgOcP8DNRyOAqRQiJ21YTp9xLPT8gyV3Rp4K9+HOaQs vQgR61BZJsCMl8/xMH7WDYBrXpvzvvL+OIW+JPykQltdJ4IVLaFAyAx8nxNO/nRRR5lu s6t1gmTNmMDbRsT+p/uzrC1rHbfgII2HKSLO/G76tUHt3vQ8COtLi1K/CDTuNNhnBOE4 yqAFJukqiD/UXlCw6cbNoQho2UhHfDkBFl2MB6ih3YB7Dw94AET9I8/pzDGrWz12Q0a1 bBuQ== X-Gm-Message-State: AKGB3mKPNvcrSzdoXOyO7GKcv/GwreLOYvH/VOsKRzFtldlOEkS5KMPm qb5NthWAS4mZ8XNDq9FZec2V4PX98zw= X-Google-Smtp-Source: ACJfBoucRUGxodsVhS5rJiEVJowppXoJ7deTlnceciEFgHo5TmyKMflK6YxcMQ29yIDqc9v00n9cFw== X-Received: by 10.80.141.86 with SMTP id t22mr16142275edt.70.1513330064539; Fri, 15 Dec 2017 01:27:44 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:2514:f1b4:f089:fa28? ([2001:660:330f:a4:2514:f1b4:f089:fa28]) by smtp.gmail.com with ESMTPSA id y1sm5053771edl.39.2017.12.15.01.27.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 01:27:42 -0800 (PST) From: Luigi Iannone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 15 Dec 2017 10:27:42 +0100 References: <151197437351.7944.17794546083400854990@ietfa.amsl.com> <4289A7FC-B6F4-429C-8F29-3B1B941C1B1B@gigix.net> To: "lisp@ietf.org list" In-Reply-To: <4289A7FC-B6F4-429C-8F29-3B1B941C1B1B@gigix.net> Message-Id: <19862B76-35BB-4899-9083-39EA3670C39B@gigix.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] I-D Action: draft-ietf-lisp-signal-free-multicast-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 09:27:49 -0000 time is up. The chairs did not receive any objection to the changes of the = signal-free-document. As such the consensus is confirmed and this document will be shortly = handed over to our AD Deborah. Thanks Luigi > On 30 Nov 2017, at 10:33, Luigi Iannone wrote: >=20 > Folks, >=20 > As shepherd of the Signal Free document I asked the authors to fix = some editorial issues as well as the use of RFC2119 notation. >=20 > Changing the use of RFC 2119 notation is to be considered a technical = change, however, the aim of the document did not change at all, it just = made specifications clearer. >=20 > With this mail the chairs open a 2 week period to check if anybody has = any objection to the changes. > Without any further comment we will consider that rough consensus for = the 06 document still holds for 07. >=20 > Thanks >=20 > Luigi >=20 >=20 >=20 >> On 29 Nov 2017, at 17:52, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Locator/ID Separation Protocol WG of = the IETF. >>=20 >> Title : Signal-Free LISP Multicast >> Authors : Victor Moreno >> Dino Farinacci >> Filename : draft-ietf-lisp-signal-free-multicast-07.txt >> Pages : 23 >> Date : 2017-11-29 >>=20 >> Abstract: >> When multicast sources and receivers are active at LISP sites, the >> core network is required to use native multicast so packets can be >> delivered from sources to group members. When multicast is not >> available to connect the multicast sites together, a signal-free >> mechanism can be used to allow traffic to flow between sites. The >> mechanism within here uses unicast replication and encapsulation = over >> the core network for the data-plane and uses the LISP mapping >> database system so encapsulators at the source LISP multicast site >> can find decapsulators at the receiver LISP multicast sites. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-lisp-signal-free-multicast/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-lisp-signal-free-multicast-07 >> = https://datatracker.ietf.org/doc/html/draft-ietf-lisp-signal-free-multicas= t-07 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-signal-free-multicast-= 07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Fri Dec 15 01:48:58 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23013128799 for ; Fri, 15 Dec 2017 01:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.557 X-Spam-Level: *** X-Spam-Status: No, score=3.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlNS__phOqgl for ; Fri, 15 Dec 2017 01:48:39 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255921292F5 for ; Fri, 15 Dec 2017 01:48:38 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g130so29936579wme.0 for ; Fri, 15 Dec 2017 01:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:cc:to:message-id; bh=v4HXfOygJ80iVqG+DXnwnI/onTi3V91SHCO6AYst46Q=; b=p0siNzpWNSiMKy0i5ndTW/vra69Gc8RvfChqbQXck83YQvu7ujnF5hUKB2UomdcJ3x zIIVF5f7tOAELzTKCIqPX00RV3Phkr5fsY5IL3iCJ0d8oGS0PRoU2s/5k6imzyI937OS tvMEb/bVayJMKlKjUpkuLUYom7pYHLTru/FYaDv4yUeZYKiisZMbrOD+kWAnyAE7KG3R NhOJWwJWsv/R1wki2UQ7guPMaM+U4GTqcHynbipvvMAUV0mBA570smjitB7CYcOihWQV SQNBSYtg/IHA0dxpKAr/EZfrwt1AxOde+wUNtm5Zo6ifJ0IS8wUNO7TPNYX4DFFOW/dU gxoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=v4HXfOygJ80iVqG+DXnwnI/onTi3V91SHCO6AYst46Q=; b=QiCvomxUdkZjKGccW70sOBJH6FPklyMdExlGPjI9UfL7jCXc4iU/OfXG/cKnofF5gB juyudBREL/PXjtnQtpqcOvUhY+B0+Y0gP6h42ubcUF2trJJtnpj/caaWtCg5WUSiIa5P aKKxjmLyLJyeEZKUfHyJ5jgGMjtmTZXUOp3+bt1CoD0Ftafcw40m3ewTgFPWxal+KFVd GFGNNXVxTukcHv/K4ij6WGgXuc9QTGvmxJNZVsWziSX3DyyiOAOMv2CaTFkDon31WdO5 wuSMgRzIlKOy0FpbdxJXiJ4Y6a86oB7r/RNHkcK+wy97HiqduE5+UfnrPMSS5xG9jwHH FADA== X-Gm-Message-State: AKGB3mIFhPyVtrkX0waDK1FhgKO09rSsWnPFF96H9J2MmbdCK0GQpetS jc09jqyU1rHOH8WdMXoBH4lXAo3PCrY= X-Google-Smtp-Source: ACJfBosDNArllx2WsEy78rz8Qv2zAvuw75XHNjQKShuaV4UuGNfFLTlH+V9P2Xx1ECzdo5PMfbc6og== X-Received: by 10.80.159.3 with SMTP id b3mr15701474edf.163.1513331315538; Fri, 15 Dec 2017 01:48:35 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:2514:f1b4:f089:fa28? ([2001:660:330f:a4:2514:f1b4:f089:fa28]) by smtp.gmail.com with ESMTPSA id r1sm4842383edb.71.2017.12.15.01.48.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 01:48:33 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_81CC5B0C-BEEE-411D-AE1C-B0B73CADA679" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 15 Dec 2017 10:48:33 +0100 References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> Cc: lisp-chairs@tools.ietf.org To: "lisp@ietf.org list" Message-Id: <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 09:48:57 -0000 --Apple-Mail=_81CC5B0C-BEEE-411D-AE1C-B0B73CADA679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Folks, hereafter my review of the document.=20 There is one point that strikes me, more than one year ago the WG = decided to move all control-plane and OAM text out of this document, but = as of today it is still there. To have a slim easy to follow document there are a few sections that = must be dropped because are either control-plane or OAM stuff. Detailed comments inline. Ciao Luigi p.s. @Dino: sorry this is 07 version because I started with that = version. >=20 >=20 >=20 > Network Working Group D. = Farinacci > Internet-Draft V. = Fuller > Intended status: Standards Track D. = Meyer > Expires: May 15, 2018 D. = Lewis > Cisco = Systems > A. Cabellos = (Ed.) > = UPC/BarcelonaTech > November 11, = 2017 >=20 >=20 > The Locator/ID Separation Protocol (LISP) > draft-ietf-lisp-rfc6830bis-07 >=20 > Abstract >=20 > This document describes the data-plane protocol=20 >=20 the wording =E2=80=9Cdata-plane protocol=E2=80=9D sounds awkward to me. = I think would be better to put "data-plane operations=E2=80=9D or even = better =E2=80=9Cdata-plane specifications=E2=80=9D Best solution: just drop it. This document describes the data plane of = LISP. =20 > for the Locator/ID > Separation Protocol (LISP). LISP defines two namespaces, End-point > Identifiers (EIDs) that identify end-hosts and Routing Locators > (RLOCs) that identify network attachment points. With this, LISP > effectively separates control from data, and allows routers to = create > overlay networks. LISP-capable routers exchange encapsulated = packets > according to EID-to-RLOC mappings stored in a local map-cache. The > map-cache is populated by the LISP Control-Plane protocol >=20 Same as above for the "control-plane protocol" > [I-D.ietf-lisp-rfc6833bis]. > LISP requires no change to either host protocol stacks or to = underlay > routers and offers Traffic Engineering, multihoming and mobility, > among other features. >=20 > Status of This Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at=20 > https://datatracker.ietf.org/drafts/current/ > . >=20 > Internet-Drafts are draft documents valid for a maximum of six = months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on May 15, 2018. >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 1] > Internet-Draft LISP November = 2017 >=20 >=20 > Copyright Notice >=20 > Copyright (c) 2017 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > ( > https://trustee.ietf.org/license-info > ) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with = respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 > 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . = 4 > 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . = 4 > 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . = 9 > 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . = 11 > 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . = 13 > 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . = 14 > 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . = 15 > 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . = 16 > 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . = 20 > 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . = 20 > 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . = 21 > 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . = 22 > 8. Using Virtualization and Segmentation with LISP . . . . . . . = 22 > 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . = 23 > 10. Routing Locator Reachability . . . . . . . . . . . . . . . . = 24 > 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . = 27 > 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . = 28 > 11. EID Reachability within a LISP Site . . . . . . . . . . . . . = 29 > 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . = 30 > 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . = 31 > 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . = 32 > 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . = 32 > 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . = 34 > 14. Multicast Considerations . . . . . . . . . . . . . . . . . . = 35 > 15. Router Performance Considerations . . . . . . . . . . . . . . = 35 > 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . = 36 > 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . = 36 > 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . = 36 > 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . = 37 > 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . = 38 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 2] > Internet-Draft LISP November = 2017 >=20 >=20 > 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . = 39 > 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . = 39 > 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . = 40 > 17.4. LISP Functionality with Conventional NATs . . . . . . . = 40 > 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . = 41 > 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . = 41 > 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . = 42 > 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . = 42 > 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . = 43 > 19. Security Considerations . . . . . . . . . . . . . . . . . . . = 43 > 20. Network Management Considerations . . . . . . . . . . . . . . = 44 > 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 44 > 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . = 44 > 22. References . . . . . . . . . . . . . . . . . . . . . . . . . = 44 > 22.1. Normative References . . . . . . . . . . . . . . . . . . = 44 > 22.2. Informative References . . . . . . . . . . . . . . . . . = 47 > Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . = 51 > Appendix B. Document Change Log . . . . . . . . . . . . . . . . = 51 > B.1. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . = 52 > B.2. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . = 52 > B.3. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . = 52 > B.4. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . = 52 > B.5. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . = 53 > B.6. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . = 53 > B.7. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . = 53 > B.8. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . = 53 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = 53 >=20 > 1. Introduction >=20 > This document describes the Locator/Identifier Separation Protocol > (LISP). LISP is an encapsulation protocol built around the > fundamental idea of separating the topological location of a network > attachment point from the node's identity [CHIAPPA]. As a result > LISP creates two namespaces: Endpoint Identifiers (EIDs), that are > used to identify end-hosts (e.g., nodes or Virtual Machines) and > routable Routing Locators (RLOCs), used to identify network > attachment points. LISP then defines functions for mapping between > the two namespaces and for encapsulating traffic originated by > devices using non-routable EIDs for transport across a network > infrastructure that routes and forwards using RLOCs. >=20 > LISP is an overlay protocol that separates control from data-plane, > this document specifies the data-plane, how LISP-capable routers > (Tunnel Routers) exchange packets by encapsulating them to the > appropriate location. Tunnel routers are equipped with a cache, > called map-cache, that contains EID-to-RLOC mappings. The map-cache >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 3] > Internet-Draft LISP November = 2017 >=20 >=20 > is populated using the LISP Control-Plane protocol > [I-D.ietf-lisp-rfc6833bis]. >=20 > LISP does not require changes to either host protocol stack or to > underlay routers. By separating the EID from the RLOC space, LISP > offers native Traffic Engineering, multihoming and mobility, among > other features. >=20 > Creation of LISP was initially motivated by discussions during the > IAB-sponsored Routing and Addressing Workshop held in Amsterdam in > October 2006 (see [RFC4984]) >=20 > This document specifies the LISP data-plane encapsulation and other > LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] > specifies the LISP control plane. LISP deployment guidelines can be > found in [RFC7215] and [RFC6835] describes considerations for = network > operational management. Finally, [I-D.ietf-lisp-introduction] > describes the LISP architecture. >=20 > 2. Requirements Notation >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. >=20 > 3. Definition of Terms >=20 What is the order of the Terms? It is not alphabetical and not logical (at least I cannot se it). May be better to re-order in alphabetical order. > Provider-Independent (PI) Addresses: PI addresses are an address > block assigned from a pool where blocks are not associated with > any particular location in the network (e.g., from a particular > service provider) and are therefore not topologically = aggregatable > in the routing system. >=20 > Provider-Assigned (PA) Addresses: PA addresses are an address = block > assigned to a site by each service provider to which a site > connects. Typically, each block is a sub-block of a service > provider Classless Inter-Domain Routing (CIDR) [RFC4632] block = and > is aggregated into the larger block before being advertised into > the global Internet. Traditionally, IP multihoming has been > implemented by each multihomed site acquiring its own globally > visible prefix. LISP uses only topologically assigned and > aggregatable address blocks for RLOCs, eliminating this > demonstrably non-scalable practice. >=20 Last sentence to be deleted is a relic of scalability discussion. > Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 > [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is > the output of an EID-to-RLOC mapping lookup. An EID maps to one > or more RLOCs. Typically, RLOCs are numbered from topologically >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 4] > Internet-Draft LISP November = 2017 >=20 >=20 > aggregatable >=20 Delete "topologically aggregatable" > blocks that are assigned to a site at each point to > which it attaches to the global Internet; where the topology is > defined by the connectivity of provider networks, RLOCs can be > thought of as PA addresses. =20 >=20 Delete "RLOCs can be thought of as PA addresses." > Multiple RLOCs can be assigned to the > same ETR device or to multiple ETR devices at a site. >=20 > Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for > IPv6) value used in the source and destination address fields of > the first (most inner) LISP header of a packet. The host obtains > a destination EID the same way it obtains a destination address > today, for example, through a Domain Name System (DNS) [RFC1034] > lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. > The source EID is obtained via existing mechanisms used to set a > host's "local" IP address. An EID used on the public Internet > must have the same properties as any other IP address used in = that > manner; this means, among other things, that it must be globally > unique. An EID is allocated to a host from an EID-Prefix block > associated with the site where the host is located. An EID can = be > used by a host to refer to other hosts. Note that EID blocks MAY > be assigned in a hierarchical manner, independent of the network > topology, to facilitate scaling of the mapping database. In > addition, an EID block assigned to a site may have site-local > structure (subnetting) for routing within the site; this = structure > is not visible to the global routing system. In theory, the bit > string that represents an EID for one device can represent an = RLOC > for a different device. As the architecture is realized, if a > given bit string is both an RLOC and an EID, it must refer to the > same entity in both cases.=20 >=20 Is the above sentence really necessary? > When used in discussions with other > Locator/ID separation proposals, a LISP EID will be called an > "LEID". Throughout this document, any references to "EID" refer > to an LEID. >=20 > EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are > allocated to a site by an address allocation authority. EID- > Prefixes are associated with a set of RLOC addresses that make up > a "database mapping=E2=80=9D. >=20 Delete =E2=80=9Cthat make up a database mapping=E2=80=9D. > EID-Prefix allocations can be broken up > into smaller blocks when an RLOC set is to be associated with the > larger EID-Prefix block.=20 >=20 Delete the rest of the paragraph, is relic of scalability discussion. > A globally routed address block (whether > PI or PA) is not inherently an EID-Prefix. A globally routed > address block MAY be used by its assignee as an EID block. The > converse is not supported. That is, a site that receives an > explicitly allocated EID-Prefix may not use that EID-Prefix as a > globally routed prefix. This would require coordination and > cooperation with the entities managing the mapping = infrastructure. > Once this has been done, that block could be removed from the > globally routed IP system, if other suitable transition and = access > mechanisms are in place. Discussion of such transition and = access > mechanisms can be found in [RFC6832] and [RFC7215]. >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 5] > Internet-Draft LISP November = 2017 >=20 >=20 > End-system: An end-system is an IPv4 or IPv6 device that = originates > packets with a single IPv4 or IPv6 header. The end-system > supplies an EID value for the destination address field of the IP > header when communicating globally (i.e., outside of its routing > domain). An end-system can be a host computer, a switch or = router > device, or any network appliance. >=20 > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > LISP site. Packets sent by sources inside of the LISP site to > destinations outside of the site are candidates for encapsulation > by the ITR. The ITR treats the IP destination address as an EID > and performs an EID-to-RLOC mapping lookup. The router then > prepends an "outer" IP header with one of its routable RLOCs (in > the RLOC space) in the source address field and the result of the > mapping lookup in the destination address field. Note that this > destination RLOC MAY be an intermediate, proxy device that has > better knowledge of the EID-to-RLOC mapping closer to the > destination EID. In general, an ITR receives IP packets from = site > end-systems on one side and sends LISP-encapsulated IP packets > toward the Internet on the other side. >=20 > Specifically, when a service provider prepends a LISP header for > Traffic Engineering purposes, the router that does this is also > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > on the outer destination address (the originating ITR's supplied > RLOC) or the inner destination address (the originating host's > supplied EID). >=20 > TE-ITR: A TE-ITR is an ITR that is deployed in a service provider > network that prepends an additional LISP header for Traffic > Engineering purposes. >=20 > Egress Tunnel Router (ETR): An ETR is a router that accepts an IP > packet where the destination address in the "outer" IP header is > one of its own RLOCs. The router strips the "outer" header and > forwards the packet based on the next IP header found. In > general, an ETR receives LISP-encapsulated IP packets from the > Internet on one side and sends decapsulated IP packets to site > end-systems on the other side. ETR functionality does not have = to > be limited to a router device. A server host can be the endpoint > of a LISP tunnel as well. >=20 > TE-ETR: A TE-ETR is an ETR that is deployed in a service provider > network that strips an outer LISP header for Traffic Engineering > purposes. >=20 > xTR: An xTR is a reference to an ITR or ETR when direction of data > flow is not part of the context description. "xTR" refers to the >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 6] > Internet-Draft LISP November = 2017 >=20 >=20 > router that is the tunnel endpoint and is used synonymously with > the term "Tunnel Router". For example, "An xTR can be located at > the Customer Edge (CE) router" indicates both ITR and ETR > functionality at the CE router. >=20 > Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling >=20 RTR have never been defined. > occurs when an RTR (Re-encapsulating Tunnel Router) acts like an > ETR to remove a LISP header, then acts as an ITR to prepend a new > LISP header. Doing this allows a packet to be re-routed by the > RTR without adding the overhead of additional tunnel headers. = Any > references to tunnels in this specification refer to dynamic > encapsulating tunnels; they are never statically configured. = When > using multiple mapping database systems, care must be taken to = not > create re-encapsulation loops through misconfiguration. >=20 > LISP Router: A LISP router is a router that performs the functions > of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), > or Proxy-ETR (PETR). >=20 > EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally > short-lived, on-demand table in an ITR that stores, tracks, and = is > responsible for timing out and otherwise validating EID-to-RLOC > mappings. This cache is distinct from the full "database" of = EID- > to-RLOC mappings; it is dynamic, local to the ITR(s), and > relatively small, while the database is distributed, relatively > static, and much more global in scope. >=20 > EID-to-RLOC Database: The EID-to-RLOC Database is a global > distributed database that contains all known EID-Prefix-to-RLOC > mappings. Each potential ETR typically contains a small piece of > the database: the EID-to-RLOC mappings for the EID-Prefixes > "behind" the router. These map to one of the router's own > globally visible IP addresses. Note that there MAY be transient > conditions when the EID-Prefix for the site and Locator-Set for > each EID-Prefix may not be the same on all ETRs. This has no > negative implications, since a partial set of Locators can be > used. >=20 > Recursive Tunneling: Recursive Tunneling occurs when a packet has > more than one LISP IP header. Additional layers of tunneling MAY > be employed to implement Traffic Engineering or other re-routing > as needed. When this is done, an additional "outer" LISP header > is added, and the original RLOCs are preserved in the "inner" > header. =20 >=20 Do not think the following sentence is really necessary. > Any references to tunnels in this specification refer to > dynamic encapsulating tunnels; they are never statically > configured. >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 7] > Internet-Draft LISP November = 2017 >=20 >=20 > LISP Header: LISP header is a term used in this document to refer > to the outer IPv4 or IPv6 header, a UDP header, and a LISP- > specific 8-octet header that follow the UDP header and that an = ITR > prepends or an ETR strips. >=20 > Address Family Identifier (AFI): AFI is a term used to describe an > address encoding in a packet. An address family that pertains to > the data-plane. See [AFN] and [RFC3232] for details. An AFI > value of 0 used in this specification indicates an unspecified > encoded address where the length of the address is 0 octets > following the 16-bit AFI value of 0. >=20 > Negative Mapping Entry: A negative mapping entry, also known as a > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > is advertised or stored with no RLOCs. That is, the Locator-Set > for the EID-to-RLOC entry is empty or has an encoded Locator = count > of 0. This type of entry could be used to describe a prefix from > a non-LISP site, which is explicitly not in the mapping database. > There are a set of well-defined actions that are encoded in a > Negative Map-Reply. >=20 > Data-Probe: A Data-Probe is a LISP-encapsulated data packet where > the inner-header destination address equals the outer-header > destination address used to trigger a Map-Reply by a = decapsulating > ETR. In addition, the original packet is decapsulated and > delivered to the destination host if the destination EID is in = the > EID-Prefix range configured on the ETR. Otherwise, the packet is > discarded. A Data-Probe is used in some of the mapping database > designs to "probe" or request a Map-Reply from an ETR; in other > cases, Map-Requests are used. See each mapping database design > for details. When using Data-Probes, by sending Map-Requests on > the underlying routing system, EID-Prefixes must be advertised. >=20 Delete following sentence. > However, this is discouraged if the core is to scale by having > less EID-Prefixes stored in the core router's routing tables. >=20 > Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A > PITR acts like an ITR but does so on behalf of non-LISP sites = that > send packets to destinations at LISP sites. >=20 > Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A > PETR acts like an ETR but does so on behalf of LISP sites that > send packets to destinations at non-LISP sites. >=20 > Route-returnability: Route-returnability is an assumption that the > underlying routing system will deliver packets to the = destination. > When combined with a nonce that is provided by a sender and > returned by a receiver, this limits off-path data insertion. A > route-returnability check is verified when a message is sent with >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 8] > Internet-Draft LISP November = 2017 >=20 >=20 > a nonce, another message is returned with the same nonce, and the > destination of the original message appears as the source of the > returned message. >=20 > LISP site: LISP site is a set of routers in an edge network that = are > under a single technical administration. LISP routers that = reside > in the edge network are the demarcation points to separate the > edge network from the core network. >=20 > Client-side: Client-side is a term used in this document to = indicate > a connection initiation attempt by an EID.=20 >=20 Following sentence not needed here. (it is specified in the operation = part of the document) > The ITR(s) at the LISP > site are the first to get involved in obtaining database = Map-Cache > entries by sending Map-Request messages. >=20 > Server-side: Server-side is a term used in this document to = indicate > that a connection initiation attempt is being accepted for a > destination EID. =20 >=20 Rest of the paragraph not needed here. (it is specified in the operation = part of the document) > The ETR(s) at the destination LISP site may be > the first to send Map-Replies to the source site initiating the > connection. The ETR(s) at this destination site can obtain > mappings by gleaning information from Map-Requests, Data-Probes, > or encapsulated packets. >=20 > Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the > LISP header. They are used by ITRs to inform ETRs about the up/ > down status of all ETRs at the local site. These bits are used = as > a hint to convey up/down router status and not path reachability > status. The LSBs can be verified by use of one of the Locator > reachability algorithms described in Section 10. >=20 > Anycast Address: Anycast Address is a term used in this document to > refer to the same IPv4 or IPv6 address configured and used on > multiple systems at the same time. An EID or RLOC can be an > anycast address in each of their own address spaces. >=20 > 4. Basic Overview >=20 > One key concept of LISP is that end-systems operate the same way = they > do today. The IP addresses that hosts use for tracking sockets and > connections, and for sending and receiving packets, do not change. > In LISP terminology, these IP addresses are called Endpoint > Identifiers (EIDs). >=20 > Routers continue to forward packets based on IP destination > addresses. When a packet is LISP encapsulated, these addresses are > referred to as Routing Locators (RLOCs). Most routers along a path > between two hosts will not change; they continue to perform routing/ > forwarding lookups on the destination addresses. For routers = between > the source host and the ITR as well as routers from the ETR to the >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 9] > Internet-Draft LISP November = 2017 >=20 >=20 > destination host, the destination address is an EID. For the = routers > between the ITR and the ETR, the destination address is an RLOC. >=20 > Another key LISP concept is the "Tunnel Router". A Tunnel Router > prepends LISP headers on host-originated packets and strips them > prior to final delivery to their destination. The IP addresses in > this "outer header" are RLOCs. During end-to-end packet exchange > between two Internet hosts, an ITR prepends a new LISP header to = each > packet, and an ETR strips the new header. The ITR performs EID-to- > RLOC lookups to determine the routing path to the ETR, which has the > RLOC as one of its IP addresses. >=20 > Some basic rules governing LISP are: >=20 > o End-systems only send to addresses that are EIDs. They don't = know > that addresses are EIDs versus RLOCs but assume that packets get > to their intended destinations. In a system where LISP is > deployed, LISP routers intercept EID-addressed packets and assist > in delivering them across the network core where EIDs cannot be > routed. The procedure a host uses to send IP packets does not > change. >=20 > o EIDs are typically IP addresses assigned to hosts. >=20 > o Other types of EID are supported by LISP, see [RFC8060] for > further information. >=20 I would put the last two bullets in the definition of EID. It simplifies = the story here. > o LISP routers mostly deal with Routing Locator addresses. See > details in Section 4.1 to clarify what is meant by "mostly". >=20 > o RLOCs are always IP addresses assigned to routers, preferably > topologically oriented addresses from provider CIDR (Classless > Inter-Domain Routing) blocks. >=20 > o When a router originates packets, it may use as a source address > either an EID or RLOC. When acting as a host (e.g., when > terminating a transport session such as Secure SHell (SSH), > TELNET, or the Simple Network Management Protocol (SNMP)), it may > use an EID that is explicitly assigned for that purpose. An EID > that identifies the router as a host MUST NOT be used as an RLOC; > an EID is only routable within the scope of a site. A typical = BGP > configuration might demonstrate this "hybrid" EID/RLOC usage = where > a router could use its "host-like" EID to terminate iBGP sessions > to other routers in a site while at the same time using RLOCs to > terminate eBGP sessions to routers outside the site. >=20 > o Packets with EIDs in them are not expected to be delivered = end-to- > end in the absence of an EID-to-RLOC mapping operation. They are >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 10] > Internet-Draft LISP November = 2017 >=20 >=20 > expected to be used locally for intra-site communication or to be > encapsulated for inter-site communication. >=20 > o EID-Prefixes are likely to be hierarchically assigned in a manner > that is optimized for administrative convenience and to = facilitate > scaling of the EID-to-RLOC mapping database. The hierarchy is > based on an address allocation hierarchy that is independent of > the network topology. >=20 Drop the last bullet it is about scalability. > o EIDs may also be structured (subnetted) in a manner suitable for > local routing within an Autonomous System (AS). >=20 > An additional LISP header MAY be prepended to packets by a TE-ITR > when re-routing of the path for a packet is desired. A potential > use-case for this would be an ISP router that needs to perform > Traffic Engineering for packets flowing through its network. In = such > a situation, termed "Recursive Tunneling", an ISP transit acts as an > additional ITR, and the RLOC it uses for the new prepended header > would be either a TE-ETR within the ISP (along an intra-ISP traffic > engineered path) or a TE-ETR within another ISP (an inter-ISP = traffic > engineered path, where an agreement to build such a path exists). >=20 > In order to avoid excessive packet overhead as well as possible > encapsulation loops, this document recommends that a maximum of two > LISP headers can be prepended to a packet. For initial LISP > deployments, it is assumed that two headers is sufficient, where the > first prepended header is used at a site for Location/Identity > separation and the second prepended header is used inside a service > provider for Traffic Engineering purposes. >=20 > Tunnel Routers can be placed fairly flexibly in a multi-AS topology. > For example, the ITR for a particular end-to-end packet exchange > might be the first-hop or default router within a site for the = source > host. Similarly, the ETR might be the last-hop router directly > connected to the destination host. Another example, perhaps for a > VPN service outsourced to an ISP by a site, the ITR could be the > site's border router at the service provider attachment point. > Mixing and matching of site-operated, ISP-operated, and other Tunnel > Routers is allowed for maximum flexibility. >=20 > 4.1. Packet Flow Sequence >=20 > This section provides an example of the unicast packet flow, > including also control-plane information as specified in > [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following > conditions: >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 11] > Internet-Draft LISP November = 2017 >=20 >=20 > o Source host " > host1.abc.example.com > " is sending a packet to > " > host2.xyz.example.com > ", exactly what host1 would do if the site > was not using LISP. >=20 > o Each site is multihomed, so each Tunnel Router has an address > (RLOC) assigned from the service provider address block for each > provider to which that particular Tunnel Router is attached. >=20 > o The ITR(s) and ETR(s) are directly connected to the source and > destination, respectively, but the source and destination can be > located anywhere in the LISP site. >=20 > o Map-Requests are sent to the mapping database system by using the > LISP control-plane protocol documented in > [I-D.ietf-lisp-rfc6833bis]. A Map-Request is sent for an = external > destination when the destination is not found in the forwarding > table or matches a default route. >=20 Switch the two sentences of the above bullet. So to become: A Map-Request is sent for an external destination when the = destination is not found in=20 the forwarding table or matches a default route. Map-Requests = are sent to the mapping database=20 system by using the LISP control-plane documented in = [I-D.ietf-lisp-rfc6833bis]. > o Map-Replies are sent on the underlying routing system topology > using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol. >=20 > Client=20 > host1.abc.example.com > wants to communicate with server >=20 > host2.xyz.example.com > : >=20 > 1. =20 > host1.abc.example.com > wants to open a TCP connection to >=20 > host2.xyz.example.com > . It does a DNS lookup on >=20 > host2.xyz.example.com > . An A/AAAA record is returned. This > address is the destination EID. The locally assigned address of >=20 > host1.abc.example.com > is used as the source EID. An IPv4 or IPv6 > packet is built and forwarded through the LISP site as a normal > IP packet until it reaches a LISP ITR. >=20 > 2. The LISP ITR must be able to map the destination EID to an RLOC > of one of the ETRs at the destination site. The specific method > used to do this is not described in this example. See > [I-D.ietf-lisp-rfc6833bis] for further information. >=20 > 3. The ITR sends a LISP Map-Request as specified in > [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be = rate-limited. >=20 > 4. The mapping system helps forwarding the Map-Request to the > corresponding ETR. When the Map-Request arrives at one of the > ETRs at the destination site, it will process the packet as a > control message. >=20 > 5. The ETR looks at the destination EID of the Map-Request and > matches it against the prefixes in the ETR's configured EID-to- > RLOC mapping database. This is the list of EID-Prefixes the ETR >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 12] > Internet-Draft LISP November = 2017 >=20 >=20 > is supporting for the site it resides in. If there is no match, > the Map-Request is dropped. Otherwise, a LISP Map-Reply is > returned to the ITR. >=20 > 6. The ITR receives the Map-Reply message, parses the message (to > check for format validity), and stores the mapping information > from the packet. This information is stored in the ITR's = EID-to- > RLOC map-cache. Note that the map-cache is an on-demand cache. > An ITR will manage its map-cache in such a way that optimizes = for > its resource constraints. >=20 > 7. Subsequent packets from=20 > host1.abc.example.com > to >=20 > host2.xyz.example.com > will have a LISP header prepended by the > ITR using the appropriate RLOC as the LISP header destination > address learned from the ETR. Note that the packet MAY be sent > to a different ETR than the one that returned the Map-Reply due > to the source site's hashing policy or the destination site's > Locator-Set policy. >=20 > 8. The ETR receives these packets directly (since the destination > address is one of its assigned IP addresses), checks the = validity > of the addresses, strips the LISP header, and forwards packets = to > the attached destination host. >=20 > 9. In order to defer the need for a mapping lookup in the reverse > direction, an ETR can OPTIONALLY create a cache entry that maps > the source EID (inner-header source IP address) to the source > RLOC (outer-header source IP address) in a received LISP packet. > Such a cache entry is termed a "gleaned" mapping and only > contains a single RLOC for the EID in question. More complete > information about additional RLOCs SHOULD be verified by sending > a LISP Map-Request for that EID. Both the ITR and the ETR may > also influence the decision the other makes in selecting an = RLOC. >=20 > 5. LISP Encapsulation Details >=20 > Since additional tunnel headers are prepended, the packet becomes > larger and can exceed the MTU of any link traversed from the ITR to > the ETR. It is RECOMMENDED in IPv4 that packets do not get > fragmented as they are encapsulated by the ITR. Instead, the packet > is dropped and an ICMP Unreachable/Fragmentation-Needed message is > returned to the source. >=20 In the paragraph above it is recommended not to fragment. In the paragraph below it is recommended to use the suggested algorithms = to fragment. Shouldn=E2=80=99t we put a sentence like =E2=80=9CIn the case that = fragmentation is a desirable feature, this specification = RECOMMENDS=E2=80=A6..=E2=80=9D? =20 > This specification RECOMMENDS that implementations provide support > for one of the proposed fragmentation and reassembly schemes. Two > existing schemes are detailed in Section 7. >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 13] > Internet-Draft LISP November = 2017 >=20 >=20 > Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP > architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner > header is in IPv4 packet format and the outer header is in IPv6 > packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header > is in IPv6 packet format and the outer header is in IPv4 packet > format). The next sub-sections illustrate packet formats for the > homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 > combinations MUST be supported. Additional types of EIDs are = defined > in [RFC8060]. >=20 > 5.1. LISP IPv4-in-IPv4 Header Format >=20 > 0 1 2 3 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / |Version| IHL |Type of Service| Total Length = | > / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The correct IPv4 Header is with DSCP and ECN. Please update below as = well. > | | Identification |Flags| Fragment Offset = | > | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > OH | Time to Live | Protocol =3D 17 | Header Checksum = | > | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Source Routing Locator = | > \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | Destination Routing Locator = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Source Port =3D xxxx | Dest Port =3D 4341 = | > UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | UDP Length | UDP Checksum = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > L |N|L|E|V|I|R|K|K| Nonce/Map-Version = | > I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > S / | Instance ID/Locator-Status-Bits = | > P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / |Version| IHL |Type of Service| Total Length = | > / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Identification |Flags| Fragment Offset = | > | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > IH | Time to Live | Protocol | Header Checksum = | > | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Source EID = | > \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | Destination EID = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > IHL =3D IP-Header-Length >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 14] > Internet-Draft LISP November = 2017 >=20 >=20 > 5.2. LISP IPv6-in-IPv6 Header Format >=20 > 0 1 2 3 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / |Version| Traffic Class | Flow Label = | > / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The correct IPv6 Header is with DSCP and ECN. Please update below as = well. > | | Payload Length | Next Header=3D17| Hop Limit = | > v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | = | > O + = + > u | = | > t + Source Routing Locator = + > e | = | > r + = + > | = | > H = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > d | = | > r + = + > | = | > ^ + Destination Routing Locator = + > | | = | > \ + = + > \ | = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Source Port =3D xxxx | Dest Port =3D 4341 = | > UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | UDP Length | UDP Checksum = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > L |N|L|E|V|I|R|K|K| Nonce/Map-Version = | > I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > S / | Instance ID/Locator-Status-Bits = | > P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / |Version| Traffic Class | Flow Label = | > / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Payload Length | Next Header | Hop Limit = | > v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | = | > I + = + > n | = | > n + Source EID = + > e | = | > r + = + > | = | > H = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > d | = | > r + = + > | = | >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 15] > Internet-Draft LISP November = 2017 >=20 >=20 > ^ + Destination EID = + > \ | = | > \ + = + > \ | = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > 5.3. Tunnel Header Field Descriptions >=20 > Inner Header (IH): The inner header is the header on the datagram > received from the originating host. The source and destination = IP > addresses are EIDs [RFC0791] [RFC8200]. >=20 > Outer Header: (OH) The outer header is a new header prepended by an > ITR. The address fields contain RLOCs obtained from the ingress > router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" > from [RFC0768]. The setting of the Don't Fragment (DF) bit > 'Flags' field is according to rules listed in Sections 7.1 and > 7.2. >=20 > UDP Header: The UDP header contains an ITR selected source port = when > encapsulating a packet. See Section 12 for details on the hash > algorithm used to select a source port based on the 5-tuple of = the > inner header. The destination port MUST be set to the well-known > IANA-assigned port value 4341. >=20 > UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as = zero > by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation > [RFC6935] [RFC6936]. =20 >=20 shouldn=E2=80=99t be =E2=80=9Cfor both for IPv4 [RFC0768] and IPv6 = encapsulation [RFC6935] [RFC6936].??? > When a packet with a zero UDP checksum is > received by an ETR, the ETR MUST accept the packet for > decapsulation. When an ITR transmits a non-zero value for the = UDP > checksum, it MUST send a correctly computed value in this field. > When an ETR receives a packet with a non-zero UDP checksum, it = MAY > choose to verify the checksum value. If it chooses to perform > such verification, and the verification fails, the packet MUST be > silently dropped. If the ETR chooses not to perform the > verification, or performs the verification successfully, the > packet MUST be accepted for decapsulation. The handling of UDP > zero checksums over IPv6 for all tunneling protocols, including > LISP, is subject to the applicability statement in [RFC6936]. >=20 > UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated > packet to be the sum of the inner-header IPv4 Total Length plus > the UDP and LISP header lengths. For an IPv6-encapsulated = packet, > the 'UDP Length' field is the sum of the inner-header IPv6 = Payload > Length, the size of the IPv6 header (40 octets), and the size of > the UDP and LISP headers. >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 16] > Internet-Draft LISP November = 2017 >=20 >=20 > N: The N-bit is the nonce-present bit. When this bit is set to 1, > the low-order 24 bits of the first 32 bits of the LISP header > contain a Nonce. See Section 10.1 for details. Both N- and > V-bits MUST NOT be set in the same packet. If they are, a > decapsulating ETR MUST treat the 'Nonce/Map-Version' field as > having a Nonce value present. >=20 > L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When > this bit is set to 1, the Locator-Status-Bits in the second > 32 bits of the LISP header are in use. >=20 > x 1 x x 0 x x x > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|R|K|K| Nonce/Map-Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > E: The E-bit is the echo-nonce-request bit. This bit MUST be = ignored > and has no meaning when the N-bit is set to 0. When the N-bit is > set to 1 and this bit is set to 1, an ITR is requesting that the > nonce value in the 'Nonce' field be echoed back in LISP- > encapsulated packets when the ITR is also an ETR. See > Section 10.1 for details. >=20 > V: The V-bit is the Map-Version present bit. When this bit is set = to > 1, the N-bit MUST be 0. Refer to Section 13.3 for more details. > This bit indicates that the LISP header is encoded in this > case as: >=20 > 0 x 0 1 x x x x > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID/Locator-Status-Bits | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > I: The I-bit is the Instance ID bit. See Section 8 for more = details. > When this bit is set to 1, the 'Locator-Status-Bits' field is > reduced to 8 bits and the high-order 24 bits are used as an > Instance ID. If the L-bit is set to 0, then the low-order 8 bits > are transmitted as zero and ignored on receipt. The format of = the > LISP header would look like this: >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 17] > Internet-Draft LISP November = 2017 >=20 >=20 > x x x x 1 x x x > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|L|E|V|I|R|K|K| Nonce/Map-Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Instance ID | LSBs | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > R: The R-bit is a Reserved bit for future use. It MUST be set to 0 > on transmit and MUST be ignored on receipt. >=20 > KK: The KK-bits are a 2-bit field used when encapsualted packets = are > encrypted. The field is set to 00 when the packet is not > encrypted. See [RFC8061] for further information. >=20 > LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is > randomly generated by an ITR when the N-bit is set to 1. Nonce > generation algorithms are an implementation matter but are > required to generate different nonces when sending to different > destinations. >=20 What is a destination? Should be different RLOCs, for clarity. > However, the same nonce can be used for a period of > time to the same destination. The nonce is also used when the > E-bit is set to request the nonce value to be echoed by the other > side when packets are returned. When the E-bit is clear but the > N-bit is set, a remote ITR is either echoing a previously > requested echo-nonce or providing a random nonce. See > Section 10.1 for more details. >=20 > LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the > 'Locator-Status-Bits' field in the LISP header is set by an ITR = to > indicate to an ETR the up/down status of the Locators in the > source site. Each RLOC in a Map-Reply is assigned an ordinal > value from 0 to n-1 (when there are n RLOCs in a mapping entry). > The Locator-Status-Bits are numbered from 0 to n-1 from the least > significant bit of the field. The field is 32 bits when the = I-bit > is set to 0 and is 8 bits when the I-bit is set to 1. When a > Locator-Status-Bit is set to 1, the ITR is indicating to the ETR > that the RLOC associated with the bit ordinal has up status. See > Section 10 for details on how an ITR can determine the status of > the ETRs at the same site. When a site has multiple EID-Prefixes > that result in multiple mappings (where each could have a > different Locator-Set), the Locator-Status-Bits setting in an > encapsulated packet MUST reflect the mapping for the EID-Prefix > that the inner-header source EID address matches. If the LSB for > an anycast Locator is set to 1, then there is at least one RLOC > with that address, and the ETR is considered 'up'. >=20 > When doing ITR/PITR encapsulation: >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 18] > Internet-Draft LISP November = 2017 >=20 >=20 > o The outer-header 'Time to Live' field (or 'Hop Limit' field, in > the case of IPv6) SHOULD be copied from the inner-header 'Time to > Live' field. >=20 > o The outer-header 'Type of Service' field (or the 'Traffic Class' > field, in the case of IPv6) SHOULD be copied from the = inner-header > 'Type of Service' field (with one exception; see below). >=20 > When doing ETR/PETR decapsulation: >=20 > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > the case of IPv6) SHOULD be copied from the outer-header 'Time to > Live' field, when the Time to Live value of the outer header is > less than the Time to Live value of the inner header. Failing to > perform this check can cause the Time to Live of the inner header > to increment across encapsulation/decapsulation cycles. This > check is also performed when doing initial encapsulation, when a > packet comes to an ITR or PITR destined for a LISP site. >=20 > o The inner-header 'Type of Service' field (or the 'Traffic Class' > field, in the case of IPv6) SHOULD be copied from the = outer-header > 'Type of Service' field (with one exception; see below). >=20 > Note that if an ETR/PETR is also an ITR/PITR and chooses to re- > encapsulate after decapsulating, the net effect of this is that the > new outer header will carry the same Time to Live as the old outer > header minus 1. >=20 > Copying the Time to Live (TTL) serves two purposes: first, it > preserves the distance the host intended the packet to travel; > second, and more importantly, it provides for suppression of looping > packets in the event there is a loop of concatenated tunnels due to > misconfiguration. See Section 18.3 for TTL exception handling for > traceroute packets. >=20 >=20 The description of the encap/decap operation lacks of clarity concerning = how to deal with=20 ECN bits and DSCP . 1. I think that the text should make explicitly the difference between = DSCP and ECN fields. 2. How to deal with ECN should be part of the description of the = encap/decap not a paragraph apart. This basically means that half of the last paragraph should be a = bullet of the ITR/PITR encapsulation=20 and the other half in the ETR/PETR operation. > The Explicit Congestion Notification ('ECN') field occupies bits 6 > and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic > Class' field [RFC3168]. The 'ECN' field requires special treatment > in order to avoid discarding indications of congestion [RFC3168]. > ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner > header to the outer header. Re-encapsulation MUST copy the 2-bit > 'ECN' field from the stripped outer header to the new outer header. > If the 'ECN' field contains a congestion indication codepoint (the > value is '11', the Congestion Experienced (CE) codepoint), then ETR > decapsulation MUST copy the 2-bit 'ECN' field from the stripped = outer > header to the surviving inner header that is used to forward the > packet beyond the ETR. These requirements preserve CE indications > when a packet that uses ECN traverses a LISP tunnel and becomes >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 19] > Internet-Draft LISP November = 2017 >=20 >=20 > marked with a CE indication due to congestion between the tunnel > endpoints. >=20 > 6. LISP EID-to-RLOC Map-Cache >=20 > ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- > RLOC Map-Cache, that contains mappings from EID-prefixes to locator > sets. The cache is used to encapsulate packets from the EID space = to > the corresponding RLOC network attachment point. >=20 > When an ITR/PITR receives a packet from inside of the LISP site to > destinations outside of the site a longest-prefix match lookup of = the > EID is done to the map-cache. >=20 > When the lookup succeeds, the locator-set retrieved from the map- > cache is used to send the packet to the EID's topological location. >=20 > If the lookup fails, the ITR/PITR needs to retrieve the mapping = using > the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The > mapping is then stored in the local map-cache to forward subsequent > packets addressed to the same EID-prefix. >=20 > The map-cache is a local cache of mappings, entries are expired = based > on the associated Time to live. In addition, entries can be updated > with more current information, see Section 13 for further = information > on this. Finally, the map-cache also contains reachability > information about EIDs and RLOCs, and uses LISP reachability > information mechanisms to determine the reachability of RLOCs, see > Section 10 for the specific mechanisms. >=20 > 7. Dealing with Large Encapsulated Packets >=20 > This section proposes two mechanisms to deal with packets that = exceed > the path MTU between the ITR and ETR. >=20 > It is left to the implementor to decide if the stateless or stateful > mechanism should be implemented. Both or neither can be used, since > it is a local decision in the ITR regarding how to deal with MTU > issues, and sites can interoperate with differing mechanisms. >=20 > Both stateless and stateful mechanisms also apply to = Re-encapsulating > and Recursive Tunneling, so any actions below referring to an ITR > also apply to a TE-ITR. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 20] > Internet-Draft LISP November = 2017 >=20 >=20 > 7.1. A Stateless Solution to MTU Handling >=20 > An ITR stateless solution to handle MTU issues is described as > follows: >=20 > 1. Define H to be the size, in octets, of the outer header an ITR > prepends to a packet. This includes the UDP and LISP header > lengths. >=20 > 2. Define L to be the size, in octets, of the maximum-sized packet > an ITR can send to an ETR without the need for the ITR or any > intermediate routers to fragment the packet. >=20 > 3. Define an architectural constant S for the maximum size of a > packet, in octets, an ITR must receive from the source so the > effective MTU can be met. That is, L =3D S + H. >=20 > When an ITR receives a packet from a site-facing interface and adds = H > octets worth of encapsulation to yield a packet size greater than L > octets (meaning the received packet size was greater than S octets > from the source), it resolves the MTU issue by first splitting the > original packet into 2 equal-sized fragments. A LISP header is then > prepended to each fragment. The size of the encapsulated fragments > is then (S/2 + H), which is less than the ITR's estimate of the path > MTU between the ITR and its correspondent ETR. >=20 > When an ETR receives encapsulated fragments, it treats them as two > individually encapsulated packets. It strips the LISP headers and > then forwards each fragment to the destination host of the > destination site. The two fragments are reassembled at the > destination host into the single IP datagram that was originated by > the source host. Note that reassembly can happen at the ETR if the > encapsulated packet was fragmented at or after the ITR. >=20 > This behavior is performed by the ITR when the source host = originates > a packet with the 'DF' field of the IP header set to 0. When the > 'DF' field of the IP header is set to 1, or the packet is an IPv6 > packet originated by the source host, the ITR will drop the packet > when the size is greater than L and send an ICMP Unreachable/ > Fragmentation-Needed message to the source with a value of S, where = S > is (L - H). >=20 > When the outer-header encapsulation uses an IPv4 header, an > implementation SHOULD set the DF bit to 1 so ETR fragment reassembly > can be avoided. An implementation MAY set the DF bit in such = headers > to 0 if it has good reason to believe there are unresolvable path = MTU > issues between the sending ITR and the receiving ETR. >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 21] > Internet-Draft LISP November = 2017 >=20 >=20 > This specification RECOMMENDS that L be defined as 1500. >=20 > 7.2. A Stateful Solution to MTU Handling >=20 > An ITR stateful solution to handle MTU issues is described as = follows > and was first introduced in [OPENLISP]: >=20 > 1. The ITR will keep state of the effective MTU for each Locator = per > Map-Cache entry. The effective MTU is what the core network can > deliver along the path between the ITR and ETR. >=20 > 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet > with the DF bit set to 1, exceeds what the core network can > deliver, one of the intermediate routers on the path will send = an > ICMP Unreachable/Fragmentation-Needed message to the ITR. The > ITR will parse the ICMP message to determine which Locator is > affected by the effective MTU change and then record the new > effective MTU value in the Map-Cache entry. >=20 > 3. When a packet is received by the ITR from a source inside of the > site and the size of the packet is greater than the effective = MTU > stored with the Map-Cache entry associated with the destination > EID the packet is for, the ITR will send an ICMP Unreachable/ > Fragmentation-Needed message back to the source. The packet = size > advertised by the ITR in the ICMP Unreachable/Fragmentation- > Needed message is the effective MTU minus the LISP encapsulation > length. >=20 > Even though this mechanism is stateful, it has advantages over the > stateless IP fragmentation mechanism, by not involving the > destination host with reassembly of ITR fragmented packets. >=20 > 8. Using Virtualization and Segmentation with LISP >=20 > There are several cases where segregation is needed at the EID = level. > For instance, this is the case for deployments containing = overlapping > addresses, traffic isolation policies or multi-tenant = virtualization. > For these and other scenarios where segregation is needed, Instance > IDs are used. >=20 > An Instance ID can be carried in a LISP-encapsulated packet. An ITR > that prepends a LISP header will copy a 24-bit value used by the = LISP > router to uniquely identify the address space. The value is copied > to the 'Instance ID' field of the LISP header, and the I-bit is set > to 1. >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 22] > Internet-Draft LISP November = 2017 >=20 >=20 > When an ETR decapsulates a packet, the Instance ID from the LISP > header is used as a table identifier to locate the forwarding table > to use for the inner destination EID lookup. >=20 > For example, an 802.1Q VLAN tag or VPN identifier could be used as a > 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case > details. >=20 > The Instance ID that is stored in the mapping database when LISP-DDT > [I-D.ietf-lisp-ddt] is used is 32 bits in length. That means the > control-plane can store more instances than a given data-plane can > use. Multiple data-planes can use the same 32-bit space as long as > the low-order 24 bits don't overlap among xTRs. >=20 > 9. Routing Locator Selection >=20 Large part of this section is about control plane issues and as such = should be put in 6833bis. What this section should state is that priority and weight are used to = select the RLOC to use. Only exception is gleaning where we have one single RLOC and we do not = know neither priority nor weight. All the other operational discussion goes elsewhere, but not in this = document. > Both the client-side and server-side may need control over the > selection of RLOCs for conversations between them. This control is > achieved by manipulating the 'Priority' and 'Weight' fields in EID- > to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be > gleaned from received tunneled packets or EID-to-RLOC Map-Request > messages. >=20 > The following are different scenarios for choosing RLOCs and the > controls that are available: >=20 > o The server-side returns one RLOC. The client-side can only use > one RLOC. The server-side has complete control of the selection. >=20 > o The server-side returns a list of RLOCs where a subset of the = list > has the same best Priority. The client can only use the subset > list according to the weighting assigned by the server-side. In > this case, the server-side controls both the subset list and = load- > splitting across its members. The client-side can use RLOCs > outside of the subset list if it determines that the subset list > is unreachable (unless RLOCs are set to a Priority of 255). Some > sharing of control exists: the server-side determines the > destination RLOC list and load distribution while the client-side > has the option of using alternatives to this list if RLOCs in the > list are unreachable. >=20 > o The server-side sets a Weight of 0 for the RLOC subset list. In > this case, the client-side can choose how the traffic load is > spread across the subset list. Control is shared by the server- > side determining the list and the client determining load > distribution. Again, the client can use alternative RLOCs if the > server-provided list of RLOCs is unreachable. >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 23] > Internet-Draft LISP November = 2017 >=20 >=20 > o Either side (more likely the server-side ETR) decides not to send > a Map-Request. For example, if the server-side ETR does not send > Map-Requests, it gleans RLOCs from the client-side ITR, giving = the > client-side ITR responsibility for bidirectional RLOC = reachability > and preferability. Server-side ETR gleaning of the client-side > ITR RLOC is done by caching the inner-header source EID and the > outer-header source RLOC of received packets. The client-side = ITR > controls how traffic is returned and can alternate using an = outer- > header source RLOC, which then can be added to the list the > server-side ETR uses to return traffic. Since no Priority or > Weights are provided using this method, the server-side ETR MUST > assume that each client-side ITR RLOC uses the same best Priority > with a Weight of zero. In addition, since EID-Prefix encoding > cannot be conveyed in data packets, the EID-to-RLOC Cache on > Tunnel Routers can grow to be very large. >=20 > o A "gleaned" Map-Cache entry, one learned from the source RLOC of = a > received encapsulated packet, is only stored and used for a few > seconds, pending verification. Verification is performed by > sending a Map-Request to the source EID (the inner-header IP > source address) of the received encapsulated packet. A reply to > this "verifying Map-Request" is used to fully populate the Map- > Cache entry for the "gleaned" EID and is stored and used for the > time indicated from the 'TTL' field of a received Map-Reply. = When > a verified Map-Cache entry is stored, data gleaning no longer > occurs for subsequent packets that have a source EID that matches > the EID-Prefix of the verified entry. This "gleaning" mechanism > is OPTIONAL. >=20 > RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to = be > reachable when the R-bit for the Locator record is set to 1. When > the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the > RLOC. Neither the information contained in a Map-Reply nor that > stored in the mapping database system provides reachability > information for RLOCs. Note that reachability is not part of the > mapping system and is determined using one or more of the Routing > Locator reachability algorithms described in the next section. >=20 > 10. Routing Locator Reachability >=20 > Several mechanisms for determining RLOC reachability are currently > defined: >=20 There exists data-plane based reachability mechanisms and control plane = reachability mechanisms. We have to keep here only the data plane based mechanism and move the = other in 6833bis. We need to keep: 1, 6, Echo-Nonce,=20 We need to move: 2, 3, 4, 5, RLOC-Probing > 1. An ETR may examine the Locator-Status-Bits in the LISP header of > an encapsulated data packet received from an ITR. If the ETR is > also acting as an ITR and has traffic to return to the original > ITR site, it can use this status information to help select an > RLOC. >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 24] > Internet-Draft LISP November = 2017 >=20 >=20 > 2. An ITR may receive an ICMP Network Unreachable or Host > Unreachable message for an RLOC it is using. This indicates = that > the RLOC is likely down. Note that trusting ICMP messages may > not be desirable, but neither is ignoring them completely. > Implementations are encouraged to follow current best practices > in treating these conditions. >=20 > 3. An ITR that participates in the global routing system can > determine that an RLOC is down if no BGP Routing Information = Base > (RIB) route exists that matches the RLOC IP address. >=20 > 4. An ITR may receive an ICMP Port Unreachable message from a > destination host. This occurs if an ITR attempts to use > interworking [RFC6832] and LISP-encapsulated data is sent to a > non-LISP-capable site. >=20 > 5. An ITR may receive a Map-Reply from an ETR in response to a > previously sent Map-Request. The RLOC source of the Map-Reply = is > likely up, since the ETR was able to send the Map-Reply to the > ITR. >=20 > 6. When an ETR receives an encapsulated packet from an ITR, the > source RLOC from the outer header of the packet is likely up. >=20 > 7. An ITR/ETR pair can use the Locator reachability algorithms > described in this section, namely Echo-Noncing or RLOC-Probing. >=20 > When determining Locator up/down reachability by examining the > Locator-Status-Bits from the LISP-encapsulated data packet, an ETR > will receive up-to-date status from an encapsulating ITR about > reachability for all ETRs at the site. CE-based ITRs at the source > site can determine reachability relative to each other using the = site > IGP as follows: >=20 > o Under normal circumstances, each ITR will advertise a default > route into the site IGP. >=20 > o If an ITR fails or if the upstream link to its PE fails, its > default route will either time out or be withdrawn. >=20 > Each ITR can thus observe the presence or lack of a default route > originated by the others to determine the Locator-Status-Bits it = sets > for them. >=20 > RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. = The > Locator-Status-Bits in a LISP-encapsulated packet are numbered from = 0 > to n-1 starting with the least significant bit. For example, if an > RLOC listed in the 3rd position of the Map-Reply goes down (ordinal >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 25] > Internet-Draft LISP November = 2017 >=20 >=20 > value 2), then all ITRs at the site will clear the 3rd least > significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for > the packets they encapsulate. >=20 > When an ETR decapsulates a packet, it will check for any change in > the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the > ETR, if acting also as an ITR, will refrain from encapsulating > packets to an RLOC that is indicated as down. It will only resume > using that RLOC if the corresponding Locator-Status-Bit returns to a > value of 1. Locator-Status-Bits are associated with a Locator-Set > per EID-Prefix. Therefore, when a Locator becomes unreachable, the > Locator-Status-Bit that corresponds to that Locator's position in = the > list returned by the last Map-Reply will be set to zero for that > particular EID-Prefix. >=20 We need to cite the threats document because of the security issues of = LSB. > When ITRs at the site are not deployed in CE routers, the IGP can > still be used to determine the reachability of Locators, provided > they are injected into the IGP. This is typically done when a /32 > address is configured on a loopback interface. >=20 The above paragraph has to move to 6833bis. > When ITRs receive ICMP Network Unreachable or Host Unreachable > messages as a method to determine unreachability, they will refrain > from using Locators that are described in Locator lists of Map- > Replies. However, using this approach is unreliable because many > network operators turn off generation of ICMP Destination = Unreachable > messages. >=20 >=20 The above paragraph has to move to 6833bis. > If an ITR does receive an ICMP Network Unreachable or Host > Unreachable message, it MAY originate its own ICMP Destination > Unreachable message destined for the host that originated the data > packet the ITR encapsulated. >=20 >=20 The above paragraph has to move to 6833bis. > Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a > locator address from a Locator-Set in a mapping entry matches a > prefix. If it does not find one and BGP is running in the Default- > Free Zone (DFZ), it can decide to not use the Locator even though = the > Locator-Status-Bits indicate that the Locator is up. In this case, > the path from the ITR to the ETR that is assigned the Locator is not > available. More details are in [I-D.meyer-loc-id-implications]. >=20 >=20 The above paragraph has to move to 6833bis. > Optionally, an ITR can send a Map-Request to a Locator, and if a = Map- > Reply is returned, reachability of the Locator has been determined. > Obviously, sending such probes increases the number of control > messages originated by Tunnel Routers for active flows, so Locators > are assumed to be reachable when they are advertised. >=20 >=20 The above paragraph has to move to 6833bis. > This assumption does create a dependency: Locator unreachability is > detected by the receipt of ICMP Host Unreachable messages. When a >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 26] > Internet-Draft LISP November = 2017 >=20 >=20 > Locator has been determined to be unreachable, it is not used for > active traffic; this is the same as if it were listed in a Map-Reply > with Priority 255. >=20 >=20 The above paragraph has to move to 6833bis. > The ITR can test the reachability of the unreachable Locator by > sending periodic Requests. Both Requests and Replies MUST be rate- > limited. Locator reachability testing is never done with data > packets, since that increases the risk of packet loss for end-to-end > sessions. >=20 >=20 The above paragraph has to move to 6833bis. > When an ETR decapsulates a packet, it knows that it is reachable = from > the encapsulating ITR because that is how the packet arrived. In > most cases, the ETR can also reach the ITR but cannot assume this to > be true, due to the possibility of path asymmetry. In the presence > of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD > NOT use the lack of return traffic as an indication that the ETR is > unreachable. Instead, it MUST use an alternate mechanism to > determine reachability. >=20 > 10.1. Echo Nonce Algorithm >=20 > When data flows bidirectionally between Locators from different > sites, a data-plane mechanism called "nonce echoing" can be used to > determine reachability between an ITR and ETR. When an ITR wants to > solicit a nonce echo, it sets the N- and E-bits and places a 24-bit > nonce [RFC4086] in the LISP header of the next encapsulated data > packet. >=20 > When this packet is received by the ETR, the encapsulated packet is > forwarded as normal. When the ETR next sends a data packet to the > ITR, it includes the nonce received earlier with the N-bit set and > E-bit cleared. The ITR sees this "echoed nonce" and knows that the > path to and from the ETR is up. >=20 > The ITR will set the E-bit and N-bit for every packet it sends while > in the echo-nonce-request state. The time the ITR waits to process > the echoed nonce before it determines the path is unreachable is > variable and is a choice left for the implementation. >=20 > If the ITR is receiving packets from the ETR but does not see the > nonce echoed while being in the echo-nonce-request state, then the > path to the ETR is unreachable. This decision may be overridden by > other Locator reachability algorithms. Once the ITR determines that > the path to the ETR is down, it can switch to another Locator for > that EID-Prefix. >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 27] > Internet-Draft LISP November = 2017 >=20 >=20 > Note that "ITR" and "ETR" are relative terms here. Both devices = MUST > be implementing both ITR and ETR functionality for the echo nonce > mechanism to operate. >=20 > The ITR and ETR may both go into the echo-nonce-request state at the > same time. The number of packets sent or the time during which echo > nonce requests are sent is an implementation-specific setting. > However, when an ITR is in the echo-nonce-request state, it can echo > the ETR's nonce in the next set of packets that it encapsulates and > subsequently continue sending echo-nonce-request packets. >=20 > This mechanism does not completely solve the forward path > reachability problem, as traffic may be unidirectional. That is, = the > ETR receiving traffic at a site may not be the same device as an ITR > that transmits traffic from that site, or the site-to-site traffic = is > unidirectional so there is no ITR returning traffic. >=20 > The echo-nonce algorithm is bilateral. That is, if one side sets = the > E-bit and the other side is not enabled for echo-noncing, then the > echoing of the nonce does not occur and the requesting side may > erroneously consider the Locator unreachable. An ITR SHOULD only = set > the E-bit in an encapsulated data packet when it knows the ETR is > enabled for echo-noncing. This is conveyed by the E-bit in the = RLOC- > probe Map-Reply message. >=20 > Note that other Locator reachability mechanisms are being researched > and can be used to compliment or even override the echo nonce > algorithm. See the next section for an example of control-plane > probing. >=20 >=20 Drop the last paragraph about research. > 10.2. RLOC-Probing Algorithm >=20 >=20 This whole section has to go to 6833bis. > RLOC-Probing is a method that an ITR or PITR can use to determine = the > reachability status of one or more Locators that it has cached in a > Map-Cache entry. The probe-bit of the Map-Request and Map-Reply > messages is used for RLOC-Probing. >=20 > RLOC-Probing is done in the control plane on a timer basis, where an > ITR or PITR will originate a Map-Request destined to a locator > address from one of its own locator addresses. A Map-Request used = as > an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to > the mapping database system as one would when soliciting mapping > data. The EID record encoded in the Map-Request is the EID-Prefix = of > the Map-Cache entry cached by the ITR or PITR. The ITR may include = a > mapping data record for its own database mapping information that > contains the local EID-Prefixes and RLOCs for its site. RLOC-probes > are sent periodically using a jittered timer interval. >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 28] > Internet-Draft LISP November = 2017 >=20 >=20 > When an ETR receives a Map-Request message with the probe-bit set, = it > returns a Map-Reply with the probe-bit set. The source address of > the Map-Reply is set according to the procedure described in > [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping > data for the EID-Prefix contained in the Map-Request. This provides > the opportunity for the ITR or PITR that sent the RLOC-probe to get > mapping updates if there were changes to the ETR's database mapping > entries. >=20 > There are advantages and disadvantages of RLOC-Probing. The = greatest > benefit of RLOC-Probing is that it can handle many failure scenarios > allowing the ITR to determine when the path to a specific Locator is > reachable or has become unreachable, thus providing a robust > mechanism for switching to using another Locator from the cached > Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) > estimates between a pair of Locators, which can be useful for = network > management purposes as well as for selecting low delay paths. The > major disadvantage of RLOC-Probing is in the number of control > messages required and the amount of bandwidth used to obtain those > benefits, especially if the requirement for failure detection times > is very small. >=20 > Continued research and testing will attempt to characterize the > tradeoffs of failure detection times versus message overhead. >=20 >=20 Drop the last paragraph about research. > 11. EID Reachability within a LISP Site >=20 > A site may be multihomed using two or more ETRs. The hosts and > infrastructure within a site will be addressed using one or more = EID- > Prefixes that are mapped to the RLOCs of the relevant ETRs in the > mapping system. One possible failure mode is for an ETR to lose > reachability to one or more of the EID-Prefixes within its own site. > When this occurs when the ETR sends Map-Replies, it can clear the > R-bit associated with its own Locator. And when the ETR is also an > ITR, it can clear its Locator-Status-Bit in the encapsulation data > header. >=20 > It is recognized that there are no simple solutions to the site > partitioning problem because it is hard to know which part of the > EID-Prefix range is partitioned and which Locators can reach any = sub- > ranges of the EID-Prefixes. This problem is under investigation = with > the expectation that experiments will tell us more. >=20 Drop the last sentence about research. > Note that this > is not a new problem introduced by the LISP architecture. The > problem exists today when a multihomed site uses BGP to advertise = its > reachability upstream. >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 29] > Internet-Draft LISP November = 2017 >=20 >=20 > 12. Routing Locator Hashing >=20 > When an ETR provides an EID-to-RLOC mapping in a Map-Reply message = to > a requesting ITR, the Locator-Set for the EID-Prefix may contain > different Priority values for each locator address. When more than > one best Priority Locator exists, the ITR can decide how to load- > share traffic against the corresponding Locators. >=20 The above paragraph should not state where the mapping comes from, from = the data plane perspective it comes from the cache. Also where is weight??????? > The following hash algorithm may be used by an ITR to select a > Locator for a packet destined to an EID for the EID-to-RLOC mapping: >=20 > 1. Either a source and destination address hash or the traditional > 5-tuple hash can be used. The traditional 5-tuple hash includes > the source and destination addresses; source and destination = TCP, > UDP, or Stream Control Transmission Protocol (SCTP) port = numbers; > and the IP protocol number field or IPv6 next-protocol fields of > a packet that a host originates from within a LISP site. When a > packet is not a TCP, UDP, or SCTP packet, the source and > destination addresses only from the header are used to compute > the hash. >=20 > 2. Take the hash value and divide it by the number of Locators > stored in the Locator-Set for the EID-to-RLOC mapping. >=20 > 3. The remainder will yield a value of 0 to "number of Locators > minus 1". Use the remainder to select the Locator in the > Locator-Set. >=20 > Note that when a packet is LISP encapsulated, the source port number > in the outer UDP header needs to be set. Selecting a hashed value > allows core routers that are attached to Link Aggregation Groups > (LAGs) to load-split the encapsulated packets across member links of > such LAGs. Otherwise, core routers would see a single flow, since > packets have a source address of the ITR, for packets that are > originated by different EIDs at the source site. A suggested = setting > for the source port number computed by an ITR is a 5-tuple hash > function on the inner header, as described above. >=20 > Many core router implementations use a 5-tuple hash to decide how to > balance packet load across members of a LAG. The 5-tuple hash > includes the source and destination addresses of the packet and the > source and destination ports when the protocol number in the packet > is TCP or UDP. For this reason, UDP encoding is used for LISP > encapsulation. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 30] > Internet-Draft LISP November = 2017 >=20 >=20 > 13. Changing the Contents of EID-to-RLOC Mappings >=20 >=20 This is a control plane issue, as such it has to go in 6833bis, with two = exception: The very first paragraph stetting the problem, and the versioning = subsection, because it is a data-plane mechanism. All of the rest 6833bis Actually I remember a suggestion about putting operations issues like = this in an OAM document which would be a good idea.=20 > Since the LISP architecture uses a caching scheme to retrieve and > store EID-to-RLOC mappings, the only way an ITR can get a more = up-to- > date mapping is to re-request the mapping. However, the ITRs do not > know when the mappings change, and the ETRs do not keep track of > which ITRs requested its mappings. For scalability reasons, it is > desirable to maintain this approach but need to provide a way for > ETRs to change their mappings and inform the sites that are = currently > communicating with the ETR site using such mappings. >=20 > When adding a new Locator record in lexicographic order to the end = of > a Locator-Set, it is easy to update mappings. We assume that new > mappings will maintain the same Locator ordering as the old mapping > but will just have new Locators appended to the end of the list. = So, > some ITRs can have a new mapping while other ITRs have only an old > mapping that is used until they time out. When an ITR has only an > old mapping but detects bits set in the Locator-Status-Bits that > correspond to Locators beyond the list it has cached, it simply > ignores them. However, this can only happen for locator addresses > that are lexicographically greater than the locator addresses in the > existing Locator-Set. >=20 > When a Locator record is inserted in the middle of a Locator-Set, to > maintain lexicographic order, the SMR procedure in Section 13.2 is > used to inform ITRs and PITRs of the new Locator-Status-Bit = mappings. >=20 > When a Locator record is removed from a Locator-Set, ITRs that have > the mapping cached will not use the removed Locator because the xTRs > will set the Locator-Status-Bit to 0. So, even if the Locator is in > the list, it will not be used. For new mapping requests, the xTRs > can set the Locator AFI to 0 (indicating an unspecified address), as > well as setting the corresponding Locator-Status-Bit to 0. This > forces ITRs with old or new mappings to avoid using the removed > Locator. >=20 > If many changes occur to a mapping over a long period of time, one > will find empty record slots in the middle of the Locator-Set and = new > records appended to the Locator-Set. At some point, it would be > useful to compact the Locator-Set so the Locator-Status-Bit settings > can be efficiently packed. >=20 > We propose here three approaches for Locator-Set compaction: one > operational mechanism and two protocol mechanisms. The operational > approach uses a clock sweep method. The protocol approaches use the > concept of Solicit-Map-Requests and Map-Versioning. >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 31] > Internet-Draft LISP November = 2017 >=20 >=20 > 13.1. Clock Sweep >=20 > The clock sweep approach uses planning in advance and the use of > count-down TTLs to time out mappings that have already been cached. > The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, > there is a 24-hour window to time out old mappings. The following > clock sweep procedure is used: >=20 > 1. 24 hours before a mapping change is to take effect, a network > administrator configures the ETRs at a site to start the clock > sweep window. >=20 > 2. During the clock sweep window, ETRs continue to send Map-Reply > messages with the current (unchanged) mapping records. The TTL > for these mappings is set to 1 hour. >=20 > 3. 24 hours later, all previous cache entries will have timed out, > and any active cache entries will time out within 1 hour. = During > this 1-hour window, the ETRs continue to send Map-Reply messages > with the current (unchanged) mapping records with the TTL set to > 1 minute. >=20 > 4. At the end of the 1-hour window, the ETRs will send Map-Reply > messages with the new (changed) mapping records. So, any active > caches can get the new mapping contents right away if not = cached, > or in 1 minute if they had the mapping cached. The new mappings > are cached with a TTL equal to the TTL in the Map-Reply. >=20 > 13.2. Solicit-Map-Request (SMR) >=20 > Soliciting a Map-Request is a selective way for ETRs, at the site > where mappings change, to control the rate they receive requests for > Map-Reply messages. SMRs are also used to tell remote ITRs to = update > the mappings they have cached. >=20 > Since the ETRs don't keep track of remote ITRs that have cached = their > mappings, they do not know which ITRs need to have their mappings > updated. As a result, an ETR will solicit Map-Requests (called an > SMR message) from those sites to which it has been sending > encapsulated data for the last minute. In particular, an ETR will > send an SMR to an ITR to which it has recently sent encapsulated > data. This can only occur when both ITR and ETR functionality = reside > in the same router. >=20 > An SMR message is simply a bit set in a Map-Request message. An ITR > or PITR will send a Map-Request when they receive an SMR message. > Both the SMR sender and the Map-Request responder MUST rate-limit >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 32] > Internet-Draft LISP November = 2017 >=20 >=20 > these messages. Rate-limiting can be implemented as a global rate- > limiter or one rate-limiter per SMR destination. >=20 > The following procedure shows how an SMR exchange occurs when a site > is doing Locator-Set compaction for an EID-to-RLOC mapping: >=20 > 1. When the database mappings in an ETR change, the ETRs at the = site > begin to send Map-Requests with the SMR bit set for each Locator > in each Map-Cache entry the ETR caches. >=20 > 2. A remote ITR that receives the SMR message will schedule sending > a Map-Request message to the source locator address of the SMR > message or to the mapping database system. A newly allocated > random nonce is selected, and the EID-Prefix used is the one > copied from the SMR message. If the source Locator is the only > Locator in the cached Locator-Set, the remote ITR SHOULD send a > Map-Request to the database mapping system just in case the > single Locator has changed and may no longer be reachable to > accept the Map-Request. >=20 > 3. The remote ITR MUST rate-limit the Map-Request until it gets a > Map-Reply while continuing to use the cached mapping. When > Map-Versioning as described in Section 13.3 is used, an SMR > sender can detect if an ITR is using the most up-to-date = database > mapping. >=20 > 4. The ETRs at the site with the changed mapping will reply to the > Map-Request with a Map-Reply message that has a nonce from the > SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- > limited. This is important to avoid Map-Reply implosion. >=20 > 5. The ETRs at the site with the changed mapping record the fact > that the site that sent the Map-Request has received the new > mapping data in the Map-Cache entry for the remote site so the > Locator-Status-Bits are reflective of the new mapping for = packets > going to the remote site. The ETR then stops sending SMR > messages. >=20 > For security reasons, an ITR MUST NOT process unsolicited Map- > Replies. To avoid Map-Cache entry corruption by a third party, a > sender of an SMR-based Map-Request MUST be verified. If an ITR > receives an SMR-based Map-Request and the source is not in the > Locator-Set for the stored Map-Cache entry, then the responding Map- > Request MUST be sent with an EID destination to the mapping database > system. Since the mapping database system is a more secure way to > reach an authoritative ETR, it will deliver the Map-Request to the > authoritative source of the mapping data. >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 33] > Internet-Draft LISP November = 2017 >=20 >=20 > When an ITR receives an SMR-based Map-Request for which it does not > have a cached mapping for the EID in the SMR message, it MAY not = send > an SMR-invoked Map-Request. This scenario can occur when an ETR > sends SMR messages to all Locators in the Locator-Set it has stored > in its map-cache but the remote ITRs that receive the SMR may not be > sending packets to the site. There is no point in updating the ITRs > until they need to send, in which case they will send Map-Requests = to > obtain a Map-Cache entry. >=20 > 13.3. Database Map-Versioning >=20 > When there is unidirectional packet flow between an ITR and ETR, and > the EID-to-RLOC mappings change on the ETR, it needs to inform the > ITR so encapsulation to a removed Locator can stop and can instead = be > started to a new Locator in the Locator-Set. >=20 > An ETR, when it sends Map-Reply messages, conveys its own = Map-Version > Number. This is known as the Destination Map-Version Number. ITRs > include the Destination Map-Version Number in packets they > encapsulate to the site. When an ETR decapsulates a packet and > detects that the Destination Map-Version Number is less than the > current version for its mapping, the SMR procedure described in > Section 13.2 occurs. >=20 > An ITR, when it encapsulates packets to ETRs, can convey its own = Map- > Version Number. This is known as the Source Map-Version Number. > When an ETR decapsulates a packet and detects that the Source Map- > Version Number is greater than the last Map-Version Number sent in a > Map-Reply from the ITR's site, the ETR will send a Map-Request to = one > of the ETRs for the source site. >=20 > A Map-Version Number is used as a sequence number per EID-Prefix, so > values that are greater are considered to be more recent. A value = of > 0 for the Source Map-Version Number or the Destination Map-Version > Number conveys no versioning information, and an ITR does no > comparison with previously received Map-Version Numbers. >=20 > A Map-Version Number can be included in Map-Register messages as > well. This is a good way for the Map-Server to assure that all ETRs > for a site registering to it will be synchronized according to Map- > Version Number. >=20 > See [RFC6834] for a more detailed analysis and description of > Database Map-Versioning. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 34] > Internet-Draft LISP November = 2017 >=20 >=20 > 14. Multicast Considerations >=20 > A multicast group address, as defined in the original Internet > architecture, is an identifier of a grouping of topologically > independent receiver host locations. The address encoding itself > does not determine the location of the receiver(s). The multicast > routing protocol, and the network-based state the protocol creates, > determine where the receivers are located. >=20 > In the context of LISP, a multicast group address is both an EID and > a Routing Locator. Therefore, no specific semantic or action needs > to be taken for a destination address, as it would appear in an IP > header. Therefore, a group address that appears in an inner IP > header built by a source host will be used as the destination EID. > The outer IP header (the destination Routing Locator address), > prepended by a LISP router, can use the same group address as the > destination Routing Locator, use a multicast or unicast Routing > Locator obtained from a Mapping System lookup, or use other means to > determine the group address mapping. >=20 > With respect to the source Routing Locator address, the ITR prepends > its own IP address as the source address of the outer IP header. > Just like it would if the destination EID was a unicast address. > This source Routing Locator address, like any other Routing Locator > address, MUST be globally routable. >=20 > There are two approaches for LISP-Multicast, one that uses native > multicast routing in the underlay with no support from the Mapping > System and the other that uses only unicast routing in the underlay > with support from the Mapping System. See [RFC6831] and > [I-D.ietf-lisp-signal-free-multicast], respectively, for details. > Details for LISP-Multicast and interworking with non-LISP sites are > described in [RFC6831] and [RFC6832]. >=20 > 15. Router Performance Considerations >=20 > LISP is designed to be very "hardware-based forwarding friendly". A > few implementation techniques can be used to incrementally implement > LISP: >=20 > o When a tunnel-encapsulated packet is received by an ETR, the = outer > destination address may not be the address of the router. This > makes it challenging for the control plane to get packets from = the > hardware. This may be mitigated by creating special Forwarding > Information Base (FIB) entries for the EID-Prefixes of EIDs = served > by the ETR (those for which the router provides an RLOC > translation). These FIB entries are marked with a flag = indicating > that control-plane processing should be performed. The = forwarding >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 35] > Internet-Draft LISP November = 2017 >=20 >=20 > logic of testing for particular IP protocol number values is not > necessary. There are a few proven cases where no changes to > existing deployed hardware were needed to support the LISP data- > plane. >=20 > o On an ITR, prepending a new IP header consists of adding more > octets to a MAC rewrite string and prepending the string as part > of the outgoing encapsulation procedure. Routers that support > Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 > tunneling [RFC3056] may already support this action. >=20 > o A packet's source address or interface the packet was received on > can be used to select VRF (Virtual Routing/Forwarding). The = VRF's > routing table can be used to find EID-to-RLOC mappings. >=20 > For performance issues related to map-cache management, see > Section 19. >=20 > 16. Mobility Considerations >=20 Move it out. Mobility is equivalent to mapping change, it is a CP issue. move it in an OAM document. > There are several kinds of mobility, of which only some might be of > concern to LISP. Essentially, they are as follows. >=20 > 16.1. Slow Mobility >=20 > A site wishes to change its attachment points to the Internet, and > its LISP Tunnel Routers will have new RLOCs when it changes upstream > providers. Changes in EID-to-RLOC mappings for sites are expected = to > be handled by configuration, outside of LISP. >=20 > An individual endpoint wishes to move but is not concerned about > maintaining session continuity. Renumbering is involved. LISP can > help with the issues surrounding renumbering [RFC4192] [LISA96] by > decoupling the address space used by a site from the address spaces > used by its ISPs [RFC4984]. >=20 > 16.2. Fast Mobility >=20 > Fast endpoint mobility occurs when an endpoint moves relatively > rapidly, changing its IP-layer network attachment point. = Maintenance > of session continuity is a goal. This is where the Mobile IPv4 > [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used = and > primarily where interactions with LISP need to be explored, such as > the mechanisms in [I-D.ietf-lisp-eid-mobility] when the EID moves = but > the RLOC is in the network infrastructure. >=20 > In LISP, one possibility is to "glean" information. When a packet > arrives, the ETR could examine the EID-to-RLOC mapping and use that >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 36] > Internet-Draft LISP November = 2017 >=20 >=20 > mapping for all outgoing traffic to that EID. It can do this after > performing a route-returnability check, to ensure that the new > network location does have an internal route to that endpoint. > However, this does not cover the case where an ITR (the node = assigned > the RLOC) at the mobile-node location has been compromised. >=20 > Mobile IP packet exchange is designed for an environment in which = all > routing information is disseminated before packets can be forwarded. > In order to allow the Internet to grow to support expected future > use, we are moving to an environment where some information may have > to be obtained after packets are in flight. Modifications to IP > mobility should be considered in order to optimize the behavior of > the overall system. Anything that decreases the number of new EID- > to-RLOC mappings needed when a node moves, or maintains the validity > of an EID-to-RLOC mapping for a longer time, is useful. >=20 > In addition to endpoints, a network can be mobile, possibly changing > xTRs. A "network" can be as small as a single router and as large = as > a whole site. This is different from site mobility in that it is > fast and possibly short-lived, but different from endpoint mobility > in that a whole prefix is changing RLOCs. However, the mechanisms > are the same, and there is no new overhead in LISP. A map request > for any endpoint will return a binding for the entire mobile prefix. >=20 > If mobile networks become a more common occurrence, it may be useful > to revisit the design of the mapping service and allow for dynamic > updates of the database. >=20 > The issue of interactions between mobility and LISP needs to be > explored further. Specific improvements to the entire system will > depend on the details of mapping mechanisms. Mapping mechanisms > should be evaluated on how well they support session continuity for > mobile nodes. See [I-D.ietf-lisp-predictive-rlocs] for more recent > mechanisms which can provide near-zero packet loss during handoffs. >=20 > 16.3. LISP Mobile Node Mobility >=20 > A mobile device can use the LISP infrastructure to achieve mobility > by implementing the LISP encapsulation and decapsulation functions > and acting as a simple ITR/ETR. By doing this, such a "LISP mobile > node" can use topologically independent EID IP addresses that are = not > advertised into and do not impose a cost on the global routing > system. These EIDs are maintained at the edges of the mapping = system > in LISP Map-Servers and Map-Resolvers) and are provided on demand to > only the correspondents of the LISP mobile node. >=20 > Refer to [I-D.ietf-lisp-mn] for more details for when the EID and > RLOC are co-located in the roaming node. >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 37] > Internet-Draft LISP November = 2017 >=20 >=20 > 17. LISP xTR Placement and Encapsulation Methods >=20 This ia an OAM issue and has to be moved out of the document. > This section will explore how and where ITRs and ETRs can be placed > in the network and will discuss the pros and cons of each scenario. > For a more detailed networkd design deployment recommendation, refer > to [RFC7215]. >=20 > There are two basic deployment tradeoffs to consider: centralized > versus distributed caches; and flat, Recursive, or Re-encapsulating > Tunneling. When deciding on centralized versus distributed caching, > the following issues should be considered: >=20 > o Are the xTRs spread out so that the caches are spread across all > the memories of each router? A centralized cache is when an ITR > keeps a cache for all the EIDs it is encapsulating to. The = packet > takes a direct path to the destination Locator. A distributed > cache is when an ITR needs help from other Re-Encapsulating = Tunnel > Routers (RTRs) because it does not store all the cache entries = for > the EIDs it is encapsulating to. So, the packet takes a path > through RTRs that have a different set of cache entries. >=20 > o Should management "touch points" be minimized by only choosing a > few xTRs, just enough for redundancy? >=20 > o In general, using more ITRs doesn't increase management load, > since caches are built and stored dynamically. On the other = hand, > using more ETRs does require more management, since = EID-Prefix-to- > RLOC mappings need to be explicitly configured. >=20 > When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the > following issues should be considered: >=20 > o Flat tunneling implements a single encapsulation path between the > source site and destination site. This generally offers better > paths between sources and destinations with a single = encapsulation > path. >=20 > o Recursive Tunneling is when encapsulated traffic is again further > encapsulated in another tunnel, either to implement VPNs or to > perform Traffic Engineering. When doing VPN-based tunneling, the > site has some control, since the site is prepending a new > encapsulation header. In the case of TE-based tunneling, the = site > may have control if it is prepending a new tunnel header, but if > the site's ISP is doing the TE, then the site has no control. > Recursive Tunneling generally will result in suboptimal paths but > with the benefit of steering traffic to parts of the network that > have more resources available. >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 38] > Internet-Draft LISP November = 2017 >=20 >=20 > o The technique of Re-Encapsulation ensures that packets only > require one encapsulation header. So, if a packet needs to be = re- > routed, it is first decapsulated by the RTR and then Re- > Encapsulated with a new encapsulation header using a new RLOC. >=20 > The next sub-sections will examine where xTRs and RTRs can reside in > the network. >=20 > 17.1. First-Hop/Last-Hop xTRs >=20 > By locating xTRs close to hosts, the EID-Prefix set is at the > granularity of an IP subnet. So, at the expense of more EID-Prefix- > to-RLOC sets for the site, the caches in each xTR can remain > relatively small. But caches always depend on the number of non- > aggregated EID destination flows active through these xTRs. >=20 > With more xTRs doing encapsulation, the increase in control traffic > grows as well: since the EID granularity is greater, more Map- > Requests and Map-Replies are traveling between more routers. >=20 > The advantage of placing the caches and databases at these stub > routers is that the products deployed in this part of the network > have better price-memory ratios than their core router counterparts. > Memory is typically less expensive in these devices, and fewer = routes > are stored (only IGP routes). These devices tend to have excess > capacity, both for forwarding and routing states. >=20 > LISP functionality can also be deployed in edge switches. These > devices generally have layer-2 ports facing hosts and layer-3 ports > facing the Internet. Spare capacity is also often available in = these > devices. >=20 > 17.2. Border/Edge xTRs >=20 > Using Customer Edge (CE) routers for xTR placement allows the EID > space associated with a site to be reachable via a small set of = RLOCs > assigned to the CE-based xTRs for that site. >=20 > This offers the opposite benefit of the first-hop/last-hop xTR > scenario: the number of mapping entries and network management touch > points is reduced, allowing better scaling. >=20 > One disadvantage is that fewer network resources are used to reach > host endpoints, thereby centralizing the point-of-failure domain and > creating network choke points at the CE xTR. >=20 > Note that more than one CE xTR at a site can be configured with the > same IP address. In this case, an RLOC is an anycast address. This >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 39] > Internet-Draft LISP November = 2017 >=20 >=20 > allows resilience between the CE xTRs. That is, if a CE xTR fails, > traffic is automatically routed to the other xTRs using the same > anycast address. However, this comes with the disadvantage where = the > site cannot control the entrance point when the anycast route is > advertised out from all border routers. Another disadvantage of > using anycast Locators is the limited advertisement scope of /32 (or > /128 for IPv6) routes. >=20 > 17.3. ISP Provider Edge (PE) xTRs >=20 > The use of ISP PE routers as xTRs is not the typical deployment > scenario envisioned in this specification. This section attempts to > capture some of the reasoning behind this preference for = implementing > LISP on CE routers. >=20 > The use of ISP PE routers for xTR placement gives an ISP, rather = than > a site, control over the location of the ETRs. That is, the ISP can > decide whether the xTRs are in the destination site (in either CE > xTRs or last-hop xTRs within a site) or at other PE edges. The > advantage of this case is that two encapsulation headers can be > avoided. By having the PE be the first router on the path to > encapsulate, it can choose a TE path first, and the ETR can > decapsulate and Re-Encapsulate for a new encapsuluation path to the > destination end site. >=20 > An obvious disadvantage is that the end site has no control over > where its packets flow or over the RLOCs used. Other disadvantages > include difficulty in synchronizing path liveness updates between CE > and PE routers. >=20 > As mentioned in earlier sections, a combination of these scenarios = is > possible at the expense of extra packet header overhead; if both = site > and provider want control, then Recursive or Re-Encapsulating = Tunnels > are used. >=20 > 17.4. LISP Functionality with Conventional NATs >=20 > LISP routers can be deployed behind Network Address Translator (NAT) > devices to provide the same set of packet services hosts have today > when they are addressed out of private address space. >=20 > It is important to note that a locator address in any LISP control > message MUST be a routable address and therefore [RFC1918] addresses > SHOULD only be presence when running in a local environment. When a > LISP xTR is configured with private RLOC addresses and resides = behind > a NAT device and desires to communicate on the Internet, the private > addresses MUST be used only in the outer IP header so the NAT device > can translate properly. Otherwise, EID addresses MUST be translated >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 40] > Internet-Draft LISP November = 2017 >=20 >=20 > before encapsulation is performed when LISP VPNs are not in use. > Both NAT translation and LISP encapsulation functions could be co- > located in the same device. >=20 > 17.5. Packets Egressing a LISP Site >=20 > When a LISP site is using two ITRs for redundancy, the failure of = one > ITR will likely shift outbound traffic to the second. This second > ITR's cache may not be populated with the same EID-to-RLOC mapping > entries as the first. If this second ITR does not have these > mappings, traffic will be dropped while the mappings are retrieved > from the mapping system. The retrieval of these messages may > increase the load of requests being sent into the mapping system. >=20 > 18. Traceroute Considerations >=20 I consider traceroute again an OAM issue. > When a source host in a LISP site initiates a traceroute to a > destination host in another LISP site, it is highly desirable for it > to see the entire path. Since packets are encapsulated from the ITR > to the ETR, the hop across the tunnel could be viewed as a single > hop. However, LISP traceroute will provide the entire path so the > user can see 3 distinct segments of the path from a source LISP host > to a destination LISP host: >=20 > Segment 1 (in source LISP site based on EIDs): >=20 > source host ---> first hop ... next hop ---> ITR >=20 > Segment 2 (in the core network based on RLOCs): >=20 > ITR ---> next hop ... next hop ---> ETR >=20 > Segment 3 (in the destination LISP site based on EIDs): >=20 > ETR ---> next hop ... last hop ---> destination host >=20 > For segment 1 of the path, ICMP Time Exceeded messages are returned > in the normal manner as they are today. The ITR performs a TTL > decrement and tests for 0 before encapsulating. Therefore, the = ITR's > hop is seen by the traceroute source as having an EID address (the > address of the site-facing interface). >=20 > For segment 2 of the path, ICMP Time Exceeded messages are returned > to the ITR because the TTL decrement to 0 is done on the outer > header, so the destinations of the ICMP messages are the ITR RLOC > address and the source RLOC address of the encapsulated traceroute > packet. The ITR looks inside of the ICMP payload to inspect the > traceroute source so it can return the ICMP message to the address = of >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 41] > Internet-Draft LISP November = 2017 >=20 >=20 > the traceroute client and also retain the core router IP address in > the ICMP message. This is so the traceroute client can display the > core router address (the RLOC address) in the traceroute output. = The > ETR returns its RLOC address and responds to the TTL decrement to 0, > as the previous core routers did. >=20 > For segment 3, the next-hop router downstream from the ETR will be > decrementing the TTL for the packet that was encapsulated, sent into > the core, decapsulated by the ETR, and forwarded because it isn't = the > final destination. If the TTL is decremented to 0, any router on = the > path to the destination of the traceroute, including the next-hop > router or destination, will send an ICMP Time Exceeded message to = the > source EID of the traceroute client. The ICMP message will be > encapsulated by the local ITR and sent back to the ETR in the > originated traceroute source site, where the packet will be = delivered > to the host. >=20 > 18.1. IPv6 Traceroute >=20 > IPv6 traceroute follows the procedure described above, since the > entire traceroute data packet is included in the ICMP Time Exceeded > message payload. Therefore, only the ITR needs to pay special > attention to forwarding ICMP messages back to the traceroute source. >=20 > 18.2. IPv4 Traceroute >=20 > For IPv4 traceroute, we cannot follow the above procedure, since = IPv4 > ICMP Time Exceeded messages only include the invoking IP header and > 8 octets that follow the IP header. Therefore, when a core router > sends an IPv4 Time Exceeded message to an ITR, all the ITR has in = the > ICMP payload is the encapsulated header it prepended, followed by a > UDP header. The original invoking IP header, and therefore the > identity of the traceroute source, is lost. >=20 > The solution we propose to solve this problem is to cache traceroute > IPv4 headers in the ITR and to match them up with corresponding IPv4 > Time Exceeded messages received from core routers and the ETR. The > ITR will use a circular buffer for caching the IPv4 and UDP headers > of traceroute packets. It will select a 16-bit number as a key to > find them later when the IPv4 Time Exceeded messages are received. > When an ITR encapsulates an IPv4 traceroute packet, it will use the > 16-bit number as the UDP source port in the encapsulating header. > When the ICMP Time Exceeded message is returned to the ITR, the UDP > header of the encapsulating header is present in the ICMP payload, > thereby allowing the ITR to find the cached headers for the > traceroute source. The ITR puts the cached headers in the payload > and sends the ICMP Time Exceeded message to the traceroute source > retaining the source address of the original ICMP Time Exceeded >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 42] > Internet-Draft LISP November = 2017 >=20 >=20 > message (a core router or the ETR of the site of the traceroute > destination). >=20 > The signature of a traceroute packet comes in two forms. The first > form is encoded as a UDP message where the destination port is > inspected for a range of values. The second form is encoded as an > ICMP message where the IP identification field is inspected for a > well-known value. >=20 > 18.3. Traceroute Using Mixed Locators >=20 > When either an IPv4 traceroute or IPv6 traceroute is originated and > the ITR encapsulates it in the other address family header, one > cannot get all 3 segments of the traceroute. Segment 2 of the > traceroute cannot be conveyed to the traceroute source, since it is > expecting addresses from intermediate hops in the same address = format > for the type of traceroute it originated. Therefore, in this case, > segment 2 will make the tunnel look like one hop. All the ITR has = to > do to make this work is to not copy the inner TTL to the outer, > encapsulating header's TTL when a traceroute packet is encapsulated > using an RLOC from a different address family. This will cause no > TTL decrement to 0 to occur in core routers between the ITR and ETR. >=20 > 19. Security Considerations >=20 > Security considerations for LISP are discussed in [RFC7833], in > addition [I-D.ietf-lisp-sec] provides authentication and integrity = to > LISP mappings. >=20 lisp-sec is control-plane has to be referenced in 6833bis. > A complete LISP threat analysis can be found in [RFC7835], in what > follows we provide a summary. >=20 > The optional mechanisms of gleaning is offered to directly obtain a > mapping from the LISP encapsulated packets. Specifically, an xTR = can > learn the EID-to-RLOC mapping by inspecting the source RLOC and > source EID of an encapsulated packet, and insert this new mapping > into its map-cache. An off-path attacker can spoof the source EID > address to divert the traffic sent to the victim's spoofed EID. If > the attacker spoofs the source RLOC, it can mount a DoS attack by > redirecting traffic to the spoofed victim;s RLOC, potentially > overloading it. >=20 > The LISP Data-Plane defines several mechanisms to monitor RLOC data- > plane reachability, in this context Locator-Status Bits, Nonce- > Present and Echo-Nonce bits of the LISP encapsulation header can be > manipulated by an attacker to mount a DoS attack. An off-path > attacker able to spoof the RLOC of a victim's xTR can manipulate = such > mechanisms to declare a set of RLOCs unreachable. This can be used >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 43] > Internet-Draft LISP November = 2017 >=20 >=20 > also, for instance, to declare only one RLOC reachable with the aim > of overload it. >=20 > Map-Versioning is a data-plane mechanism used to signal a peering = xTR > that a local EID-to-RLOC mapping has been updated, so that the > peering xTR uses LISP Control-Plane signaling message to retrieve a > fresh mapping. This can be used by an attacker to forge the map- > versioning field of a LISP encapsulated header and force an = excessive > amount of signaling between xTRs that may overload them. >=20 > Most of the attack vectors can be mitigated with careful deployment > and configuration, information learned opportunistically (such as = LSB > or gleaning) should be verified with other reachability mechanisms. > In addition, systematic rate-limitation and filtering is an = effective > technique to mitigate attacks that aim to overload the = control-plane. >=20 > 20. Network Management Considerations >=20 > Considerations for network management tools exist so the LISP > protocol suite can be operationally managed. These mechanisms can = be > found in [RFC7052] and [RFC6835]. >=20 > 21. IANA Considerations >=20 > This section provides guidance to the Internet Assigned Numbers > Authority (IANA) regarding registration of values related to this > data-plane LISP specification, in accordance with BCP 26 [RFC5226]. >=20 > 21.1. LISP UDP Port Numbers >=20 > The IANA registry has allocated UDP port numbers 4341 and 4342 for > lisp-data and lisp-control operation, respectively. IANA has = updated > the description for UDP ports 4341 and 4342 as follows: >=20 > lisp-data 4341 udp LISP Data Packets > lisp-control 4342 udp LISP Control Packets >=20 4342 is control-plane and MUST be requested to IANA in the 6833bis = document. > 22. References >=20 > 22.1. Normative References >=20 > [I-D.ietf-lisp-ddt] > Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. > Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- > ddt-09 (work in progress), January 2017. >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 44] > Internet-Draft LISP November = 2017 >=20 >=20 > [I-D.ietf-lisp-introduction] > Cabellos-Aparicio, A. and D. Saucez, "An Architectural > Introduction to the Locator/ID Separation Protocol > (LISP)", draft-ietf-lisp-introduction-13 (work in > progress), April 2015. >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [I-D.ietf-lisp-rfc6833bis] > Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, > "Locator/ID Separation Protocol (LISP) Control-Plane", > draft-ietf-lisp-rfc6833bis-06 (work in progress), October > 2017. >=20 > [I-D.ietf-lisp-sec] > Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. > Saucez, "LISP-Security (LISP-SEC)", = draft-ietf-lisp-sec-14 > (work in progress), October 2017. >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, > DOI 10.17487/RFC0768, August 1980, > < > https://www.rfc-editor.org/info/rfc768 >> . >=20 > [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, > DOI 10.17487/RFC0791, September 1981, > < > https://www.rfc-editor.org/info/rfc791 >> . >=20 > [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., > and E. Lear, "Address Allocation for Private Internets", > BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, > < > https://www.rfc-editor.org/info/rfc1918 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > < > https://www.rfc-editor.org/info/rfc2119 >> . >=20 > [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within > ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November > 1998, < > https://www.rfc-editor.org/info/rfc2404 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition > of Explicit Congestion Notification (ECN) to IP", > RFC 3168, DOI 10.17487/RFC3168, September 2001, > < > https://www.rfc-editor.org/info/rfc3168 >> . >=20 > [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is = Replaced > by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, > January 2002, < > https://www.rfc-editor.org/info/rfc3232 >> . >=20 >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 45] > Internet-Draft LISP November = 2017 >=20 >=20 > [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, > "Randomness Requirements for Security", BCP 106, RFC = 4086, > DOI 10.17487/RFC4086, June 2005, > < > https://www.rfc-editor.org/info/rfc4086 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing > (CIDR): The Internet Address Assignment and Aggregation > Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August > 2006, < > https://www.rfc-editor.org/info/rfc4632 >> . >=20 > [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- > 384, and HMAC-SHA-512 with IPsec", RFC 4868, > DOI 10.17487/RFC4868, May 2007, > < > https://www.rfc-editor.org/info/rfc4868 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", RFC 5226, > DOI 10.17487/RFC5226, May 2008, > < > https://www.rfc-editor.org/info/rfc5226 >> . >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path > Forwarding (RPF) Vector TLV", RFC 5496, > DOI 10.17487/RFC5496, March 2009, > < > https://www.rfc-editor.org/info/rfc5496 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, = Revised", > RFC 5944, DOI 10.17487/RFC5944, November 2010, > < > https://www.rfc-editor.org/info/rfc5944 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", > RFC 6115, DOI 10.17487/RFC6115, February 2011, > < > https://www.rfc-editor.org/info/rfc6115 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility > Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July > 2011, < > https://www.rfc-editor.org/info/rfc6275 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID > Separation Protocol (LISP) Map-Versioning", RFC 6834, > DOI 10.17487/RFC6834, January 2013, > < > https://www.rfc-editor.org/info/rfc6834 >> . >=20 > [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, > "Locator/ID Separation Protocol Alternative Logical > Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, > January 2013, < > https://www.rfc-editor.org/info/rfc6836 >> . >=20 >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 46] > Internet-Draft LISP November = 2017 >=20 >=20 > [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID > Separation Protocol (LISP) MIB", RFC 7052, > DOI 10.17487/RFC7052, October 2013, > < > https://www.rfc-editor.org/info/rfc7052 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC7214] Andersson, L. and C. Pignataro, "Moving Generic = Associated > Channel (G-ACh) IANA Registries to a New Registry", > RFC 7214, DOI 10.17487/RFC7214, May 2014, > < > https://www.rfc-editor.org/info/rfc7214 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- > Pascual, J., and D. Lewis, "Locator/Identifier Separation > Protocol (LISP) Network Element Deployment > Considerations", RFC 7215, DOI 10.17487/RFC7215, April > 2014, < > https://www.rfc-editor.org/info/rfc7215 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A > RADIUS Attribute, Binding, Profiles, Name Identifier > Format, and Confirmation Methods for the Security > Assertion Markup Language (SAML)", RFC 7833, > DOI 10.17487/RFC7833, May 2016, > < > https://www.rfc-editor.org/info/rfc7833 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID > Separation Protocol (LISP) Threat Analysis", RFC 7835, > DOI 10.17487/RFC7835, April 2016, > < > https://www.rfc-editor.org/info/rfc7835 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation = Protocol > (LISP) Data-Plane Confidentiality", RFC 8061, > DOI 10.17487/RFC8061, February 2017, > < > https://www.rfc-editor.org/info/rfc8061 >> . >=20 >=20 Not normative. I don=E2=80=99t need to know this document to implement = the LISP data plane. > [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 > (IPv6) Specification", STD 86, RFC 8200, > DOI 10.17487/RFC8200, July 2017, > < > https://www.rfc-editor.org/info/rfc8200 >> . >=20 >=20 Please check as well the nits: Checking nits according to https://www.ietf.org/id-info/checklist : = --------------------------------------------------------------------------= -- ** The abstract seems to contain references = ([I-D.ietf-lisp-RFC6833bis]), which it shouldn't. Please replace those with straight textual = mentions of the documents in question. Miscellaneous warnings: = --------------------------------------------------------------------------= -- -- The document date (November 11, 2017) is 33 days in the past. Is = this intentional? Checking references for intended status: Proposed Standard = --------------------------------------------------------------------------= -- (See RFCs 3967 and 4897 for information about using normative = references to lower-maturity documents in RFCs) =3D=3D Unused Reference: 'RFC2404' is defined on line 2118, but no = explicit reference was found in the text '[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 = within...' =3D=3D Unused Reference: 'RFC4868' is defined on line 2141, but no = explicit reference was found in the text '[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, = HMAC-SHA-3...' =3D=3D Unused Reference: 'RFC5496' is defined on line 2151, but no = explicit reference was found in the text '[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse = Path...' =3D=3D Unused Reference: 'RFC6115' is defined on line 2160, but no = explicit reference was found in the text '[RFC6115] Li, T., Ed., "Recommendation for a Routing = Architecture",...' =3D=3D Unused Reference: 'RFC6836' is defined on line 2173, but no = explicit reference was found in the text '[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, = "Loca...' =3D=3D Unused Reference: 'RFC7214' is defined on line 2183, but no = explicit reference was found in the text '[RFC7214] Andersson, L. and C. Pignataro, "Moving Generic = Associate...' =3D=3D Unused Reference: 'RFC4107' is defined on line 2283, but no = explicit reference was found in the text '[RFC4107] Bellovin, S. and R. Housley, "Guidelines for = Cryptographi...' =3D=3D Unused Reference: 'RFC6480' is defined on line 2302, but no = explicit reference was found in the text '[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support = S...' =3D=3D Unused Reference: 'RFC6518' is defined on line 2306, but no = explicit reference was found in the text '[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication = fo...' =3D=3D Unused Reference: 'RFC6837' is defined on line 2327, but no = explicit reference was found in the text '[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to = Rout...' =3D=3D Outdated reference: draft-ietf-lisp-ddt has been published as = RFC 8111 ** Downref: Normative reference to an Experimental draft: draft-ietf-lisp-ddt (ref. 'I-D.ietf-lisp-ddt') ** Downref: Normative reference to an Informational draft: draft-ietf-lisp-introduction (ref. 'I-D.ietf-lisp-introduction') ** Downref: Normative reference to an Experimental draft: draft-ietf-lisp-sec (ref. 'I-D.ietf-lisp-sec') ** Downref: Normative reference to an Informational RFC: RFC 3232 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6115 ** Downref: Normative reference to an Experimental RFC: RFC 6834 ** Downref: Normative reference to an Experimental RFC: RFC 6836 ** Downref: Normative reference to an Experimental RFC: RFC 7052 ** Downref: Normative reference to an Experimental RFC: RFC 7215 ** Downref: Normative reference to an Informational RFC: RFC 7835 ** Downref: Normative reference to an Experimental RFC: RFC 8061 =3D=3D Outdated reference: A later version (-01) exists of draft-ietf-lisp-eid-mobility-00 =3D=3D Outdated reference: A later version (-01) exists of draft-ietf-lisp-predictive-rlocs-00 =3D=3D Outdated reference: A later version (-07) exists of draft-ietf-lisp-signal-free-multicast-06 =3D=3D Outdated reference: A later version (-01) exists of draft-ietf-lisp-vpn-00 Summary: 13 errors (**), 0 flaws (~~), 15 warnings (=3D=3D), 1 = comment (--). = --------------------------------------------------------------------------= --- > 22.2. Informative References >=20 > [AFN] IANA, "Address Family Numbers", August 2016, > < > http://www.iana.org/assignments/address-family-numbers >> . >=20 > [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", > 1999, > < > http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt >> . >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 47] > Internet-Draft LISP November = 2017 >=20 >=20 > [I-D.ietf-lisp-eid-mobility] > Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, > F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a > Unified Control Plane", draft-ietf-lisp-eid-mobility-00 > (work in progress), May 2017. >=20 > [I-D.ietf-lisp-mn] > Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP > Mobile Node", draft-ietf-lisp-mn-01 (work in progress), > October 2017. >=20 > [I-D.ietf-lisp-predictive-rlocs] > Farinacci, D. and P. Pillay-Esnault, "LISP Predictive > RLOCs", draft-ietf-lisp-predictive-rlocs-00 (work in > progress), June 2017. >=20 > [I-D.ietf-lisp-signal-free-multicast] > Moreno, V. and D. Farinacci, "Signal-Free LISP = Multicast", > draft-ietf-lisp-signal-free-multicast-06 (work in > progress), August 2017. >=20 > [I-D.ietf-lisp-vpn] > Moreno, V. and D. Farinacci, "LISP Virtual Private > Networks (VPNs)", draft-ietf-lisp-vpn-00 (work in > progress), May 2017. >=20 > [I-D.meyer-loc-id-implications] > Meyer, D. and D. Lewis, "Architectural Implications of > Locator/ID Separation", = draft-meyer-loc-id-implications-01 > (work in progress), January 2009. >=20 > [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, > "Renumbering: Threat or Menace?", Usenix Tenth System > Administration Conference (LISA 96), October 1996. >=20 > [OPENLISP] > Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP > Implementation Report", Work in Progress, July 2008. >=20 > [RFC1034] Mockapetris, P., "Domain names - concepts and = facilities", > STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, > < > https://www.rfc-editor.org/info/rfc1034 >> . >=20 > [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. > Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, > DOI 10.17487/RFC2784, March 2000, > < > https://www.rfc-editor.org/info/rfc2784 >> . >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 48] > Internet-Draft LISP November = 2017 >=20 >=20 > [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains > via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, = February > 2001, < > https://www.rfc-editor.org/info/rfc3056 >> . >=20 > [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, > A., Peterson, J., Sparks, R., Handley, M., and E. > Schooler, "SIP: Session Initiation Protocol", RFC 3261, > DOI 10.17487/RFC3261, June 2002, > < > https://www.rfc-editor.org/info/rfc3261 >> . >=20 > [RFC4107] Bellovin, S. and R. Housley, "Guidelines for = Cryptographic > Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, > June 2005, < > https://www.rfc-editor.org/info/rfc4107 >> . >=20 > [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for > Renumbering an IPv6 Network without a Flag Day", RFC = 4192, > DOI 10.17487/RFC4192, September 2005, > < > https://www.rfc-editor.org/info/rfc4192 >> . >=20 > [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route > Optimization for Mobile IPv6", RFC 4866, > DOI 10.17487/RFC4866, May 2007, > < > https://www.rfc-editor.org/info/rfc4866 >> . >=20 > [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report > from the IAB Workshop on Routing and Addressing", > RFC 4984, DOI 10.17487/RFC4984, September 2007, > < > https://www.rfc-editor.org/info/rfc4984 >> . >=20 > [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support > Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, > February 2012, < > https://www.rfc-editor.org/info/rfc6480 >> . >=20 > [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication = for > Routing Protocols (KARP) Design Guidelines", RFC 6518, > DOI 10.17487/RFC6518, February 2012, > < > https://www.rfc-editor.org/info/rfc6518 >> . >=20 > [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, = "The > Locator/ID Separation Protocol (LISP) for Multicast > Environments", RFC 6831, DOI 10.17487/RFC6831, January > 2013, < > https://www.rfc-editor.org/info/rfc6831 >> . >=20 > [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, > "Interworking between Locator/ID Separation Protocol > (LISP) and Non-LISP Sites", RFC 6832, > DOI 10.17487/RFC6832, January 2013, > < > https://www.rfc-editor.org/info/rfc6832 >> . >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 49] > Internet-Draft LISP November = 2017 >=20 >=20 > [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation > Protocol Internet Groper (LIG)", RFC 6835, > DOI 10.17487/RFC6835, January 2013, > < > https://www.rfc-editor.org/info/rfc6835 >> . >=20 > [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to > Routing Locator (RLOC) Database", RFC 6837, > DOI 10.17487/RFC6837, January 2013, > < > https://www.rfc-editor.org/info/rfc6837 >> . >=20 > [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and > UDP Checksums for Tunneled Packets", RFC 6935, > DOI 10.17487/RFC6935, April 2013, > < > https://www.rfc-editor.org/info/rfc6935 >> . >=20 > [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement > for the Use of IPv6 UDP Datagrams with Zero Checksums", > RFC 6936, DOI 10.17487/RFC6936, April 2013, > < > https://www.rfc-editor.org/info/rfc6936 >> . >=20 > [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP = Canonical > Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, > February 2017, < > https://www.rfc-editor.org/info/rfc8060 >> . >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 50] > Internet-Draft LISP November = 2017 >=20 >=20 > Appendix A. Acknowledgments >=20 > An initial thank you goes to Dave Oran for planting the seeds for = the > initial ideas for LISP. His consultation continues to provide value > to the LISP authors. >=20 > A special and appreciative thank you goes to Noel Chiappa for > providing architectural impetus over the past decades on separation > of location and identity, as well as detailed reviews of the LISP > architecture and documents, coupled with enthusiasm for making LISP = a > practical and incremental transition for the Internet. >=20 > The authors would like to gratefully acknowledge many people who = have > contributed discussions and ideas to the making of this proposal. > They include Scott Brim, Andrew Partan, John Zwiebel, Jason = Schiller, > Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff = Huston, > David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, > Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, > Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi > Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry > Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van > Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien > Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David > Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred = Templin, > Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, = Jari > Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, > Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri > Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina > Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, > Alia Atlas, Florin Coras and Alberto Rodriguez. >=20 > This work originated in the Routing Research Group (RRG) of the = IRTF. > An individual submission was converted into the IETF LISP working > group document that became this RFC. >=20 > The LISP working group would like to give a special thanks to Jari > Arkko, the Internet Area AD at the time that the set of LISP > documents were being prepared for IESG last call, and for his > meticulous reviews and detailed commentaries on the 7 working group > last call documents progressing toward standards-track RFCs. >=20 > Appendix B. Document Change Log >=20 > [RFC Editor: Please delete this section on publication as RFC.] >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 51] > Internet-Draft LISP November = 2017 >=20 >=20 > B.1. Changes to draft-ietf-lisp-rfc6830bis-06 >=20 > o Posted November 2017. >=20 > o Rephrase how Instance-IDs are used and don't refer to [RFC1918] > addresses. >=20 > B.2. Changes to draft-ietf-lisp-rfc6830bis-06 >=20 > o Posted October 2017. >=20 > o Put RTR definition before it is used. >=20 > o Rename references that are now working group drafts. >=20 > o Remove "EIDs MUST NOT be used as used by a host to refer to other > hosts. Note that EID blocks MAY LISP RLOCs". >=20 > o Indicate what address-family can appear in data packets. >=20 > o ETRs may, rather than will, be the ones to send Map-Replies. >=20 > o Recommend, rather than mandate, max encapsulation headers to 2. >=20 > o Reference VPN draft when introducing Instance-ID. >=20 > o Indicate that SMRs can be sent when ITR/ETR are in the same node. >=20 > o Clarify when private addreses can be used. >=20 > B.3. Changes to draft-ietf-lisp-rfc6830bis-05 >=20 > o Posted August 2017. >=20 > o Make it clear that a Reencapsulating Tunnel Router is an RTR. >=20 > B.4. Changes to draft-ietf-lisp-rfc6830bis-04 >=20 > o Posted July 2017. >=20 > o Changed reference of IPv6 RFC2460 to RFC8200. >=20 > o Indicate that the applicability statement for UDP zero checksums > over IPv6 adheres to RFC6936. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 52] > Internet-Draft LISP November = 2017 >=20 >=20 > B.5. Changes to draft-ietf-lisp-rfc6830bis-03 >=20 > o Posted May 2017. >=20 > o Move the control-plane related codepoints in the IANA > Considerations section to RFC6833bis. >=20 > B.6. Changes to draft-ietf-lisp-rfc6830bis-02 >=20 > o Posted April 2017. >=20 > o Reflect some editorial comments from Damien Sausez. >=20 > B.7. Changes to draft-ietf-lisp-rfc6830bis-01 >=20 > o Posted March 2017. >=20 > o Include references to new RFCs published. >=20 > o Change references from RFC6833 to RFC6833bis. >=20 > o Clarified LCAF text in the IANA section. >=20 > o Remove references to "experimental". >=20 > B.8. Changes to draft-ietf-lisp-rfc6830bis-00 >=20 > o Posted December 2016. >=20 > o Created working group document from draft-farinacci-lisp > -rfc6830-00 individual submission. No other changes made. >=20 > Authors' Addresses >=20 > Dino Farinacci > Cisco Systems > Tasman Drive > San Jose, CA 95134 > USA >=20 >=20 > EMail: farinacci@gmail.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 53] > Internet-Draft LISP November = 2017 >=20 >=20 > Vince Fuller > Cisco Systems > Tasman Drive > San Jose, CA 95134 > USA >=20 >=20 > EMail: vince.fuller@gmail.com >=20 >=20 >=20 > Dave Meyer > Cisco Systems > 170 Tasman Drive > San Jose, CA > USA >=20 >=20 > EMail: dmm@1-4-5.net >=20 >=20 >=20 > Darrel Lewis > Cisco Systems > 170 Tasman Drive > San Jose, CA > USA >=20 >=20 > EMail: darlewis@cisco.com >=20 >=20 >=20 > Albert Cabellos > UPC/BarcelonaTech > Campus Nord, C. Jordi Girona 1-3 > Barcelona, Catalunya > Spain >=20 >=20 > EMail: acabello@ac.upc.edu >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Farinacci, et al. Expires May 15, 2018 [Page = 54] --Apple-Mail=_81CC5B0C-BEEE-411D-AE1C-B0B73CADA679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Folks,

hereafter my review of the document. 
There is one = point that strikes me, more than one year ago the WG decided to move all = control-plane and OAM text out of this document, but as of today it is = still there.
To have a slim easy to follow document there = are a few sections that must be dropped because are either control-plane = or OAM stuff.

Detailed comments inline.

Ciao

Luigi

p.s. @Dino: sorry this is 07 version because I = started with that version.





Network Working Group =             &n= bsp;           &nbs= p;            =  D. Farinacci
Internet-Draft =             &n= bsp;           &nbs= p;            =            V. = Fuller
Intended status: Standards Track =             &n= bsp;           &nbs= p;      D. Meyer
Expires: = May 15, 2018 =             &n= bsp;           &nbs= p;            =      D. Lewis
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          Cisco = Systems
          &nb= sp;            = ;            &= nbsp;           &nb= sp;      A. Cabellos (Ed.)
          &nb= sp;            = ;            &= nbsp;           &nb= sp;      UPC/BarcelonaTech
          &nb= sp;            = ;            &= nbsp;           &nb= sp;      November 11, 2017

          &nb= sp;   The Locator/ID Separation Protocol (LISP)
          &nb= sp;         draft-ietf-lisp-r= fc6830bis-07

Abstract

  This document describes the data-plane = protocol 

the wording =E2=80=9Cdata-plane = protocol=E2=80=9D sounds awkward to me. I think would be better to put = "data-plane operations=E2=80=9D or even better =E2=80=9Cdata-plane = specifications=E2=80=9D
Best solution: just drop = it. This document describes the data plane of LISP.  


for the Locator/ID
  Separation = Protocol (LISP).  LISP defines two namespaces, End-point
  Identifiers (EIDs) that identify end-hosts and = Routing Locators
  (RLOCs) that identify network = attachment points.  With this, LISP
  effectively separates control from data, and = allows routers to create
  overlay networks. =  LISP-capable routers exchange encapsulated packets
  according to EID-to-RLOC mappings stored in a = local map-cache.  The
  map-cache is = populated by the LISP Control-Plane protocol

Same as above for the "control-plane = protocol"



  [I-D.ietf-lisp-rfc6833bis].
  LISP requires no change to either host protocol = stacks or to underlay
  routers and offers = Traffic Engineering, multihoming and mobility,
  among other features.

Status of This Memo

  This Internet-Draft is submitted in full = conformance with the
  provisions of BCP 78 and = BCP 79.

  Internet-Drafts are = working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups = may also distribute
  working documents as = Internet-Drafts.  The list of current Internet-
  Drafts is at 
https://datatracker.ietf.org/drafts/current/
.

  Internet-Drafts = are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by = other documents at any
  time.  It is = inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in = progress."

  This Internet-Draft = will expire on May 15, 2018.






Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 1]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


Copyright Notice

  Copyright (c) 2017 IETF Trust and = the persons identified as the
  document = authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF = Trust's Legal
  Provisions Relating to IETF = Documents
  (
https://trustee.ietf.org/license-info
) in = effect on the date of
  publication of this = document.  Please review these documents
  carefully, as they describe your rights and = restrictions with respect
  to this document. =  Code Components extracted from this document must
  include Simplified BSD License text as described = in Section 4.e of
  the Trust Legal Provisions = and are provided without warranty as
  described = in the Simplified BSD License.

Table of = Contents

  1.  Introduction =  . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.  Requirements Notation . . . . . . . . . = . . . . . . . . . . .   4
  3. =  Definition of Terms . . . . . . . . . . . . . . . . . . . . . =   4
  4.  Basic Overview  . = . . . . . . . . . . . . . . . . . . . . . .   9
    4.1.  Packet Flow Sequence =  . . . . . . . . . . . . . . . . . .  11
  5.  LISP Encapsulation Details  . . . . = . . . . . . . . . . . . .  13
    5.1.  LISP IPv4-in-IPv4 Header = Format . . . . . . . . . . . . .  14
    5.2.  LISP IPv6-in-IPv6 Header = Format . . . . . . . . . . . . .  15
    5.3.  Tunnel Header Field = Descriptions  . . . . . . . . . . . .  16
  6.  LISP EID-to-RLOC Map-Cache  . . . . = . . . . . . . . . . . . .  20
  7. =  Dealing with Large Encapsulated Packets . . . . . . . . . . . =  20
    7.1.  A Stateless = Solution to MTU Handling  . . . . . . . . . .  21
    7.2.  A Stateful Solution to MTU = Handling . . . . . . . . . . .  22
  8. =  Using Virtualization and Segmentation with LISP . . . . . . . =  22
  9.  Routing Locator Selection . = . . . . . . . . . . . . . . . . .  23
  10. = Routing Locator Reachability  . . . . . . . . . . . . . . . . =  24
    10.1.  Echo Nonce = Algorithm . . . . . . . . . . . . . . . . . .  27
    10.2.  RLOC-Probing Algorithm . = . . . . . . . . . . . . . . . .  28
  11. = EID Reachability within a LISP Site . . . . . . . . . . . . . =  29
  12. Routing Locator Hashing . . . . . = . . . . . . . . . . . . . .  30
  13. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . =  31
    13.1.  Clock Sweep =  . . . . . . . . . . . . . . . . . . . . . .  32
    13.2.  Solicit-Map-Request (SMR) =  . . . . . . . . . . . . . . .  32
    13.3.  Database Map-Versioning =  . . . . . . . . . . . . . . . .  34
  14. Multicast Considerations  . . . . . . . = . . . . . . . . . . .  35
  15. Router = Performance Considerations . . . . . . . . . . . . . .  35
  16. Mobility Considerations . . . . . . . . . . . = . . . . . . . .  36
    16.1. =  Slow Mobility  . . . . . . . . . . . . . . . . . . . . . =  36
    16.2.  Fast Mobility =  . . . . . . . . . . . . . . . . . . . . .  36
    16.3.  LISP Mobile Node Mobility =  . . . . . . . . . . . . . . .  37
  17.= LISP xTR Placement and Encapsulation Methods  . . . . . . . . =  38



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 2]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


    17.1. =  First-Hop/Last-Hop xTRs  . . . . . . . . . . . . . . . . =  39
    17.2.  Border/Edge = xTRs . . . . . . . . . . . . . . . . . . . .  39
    17.3.  ISP Provider Edge (PE) = xTRs  . . . . . . . . . . . . . .  40
    17.4.  LISP Functionality with = Conventional NATs  . . . . . . .  40
    17.5.  Packets Egressing a LISP = Site  . . . . . . . . . . . . .  41
  18. Traceroute Considerations . . . . . . . . . . = . . . . . . . .  41
    18.1. =  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . =  42
    18.2.  IPv4 = Traceroute  . . . . . . . . . . . . . . . . . . . .  42
    18.3.  Traceroute Using Mixed = Locators  . . . . . . . . . . . .  43
  19. Security Considerations . . . . . . . . . . . = . . . . . . . .  43
  20. Network = Management Considerations . . . . . . . . . . . . . .  44
  21. IANA Considerations . . . . . . . . . . . . . = . . . . . . . .  44
    21.1. =  LISP UDP Port Numbers  . . . . . . . . . . . . . . . . . =  44
  22. References  . . . . . . . . = . . . . . . . . . . . . . . . . .  44
    22.1.  Normative References . . = . . . . . . . . . . . . . . . .  44
    22.2.  Informative References . = . . . . . . . . . . . . . . . .  47
  Appendix A.  Acknowledgments  . . . . . = . . . . . . . . . . . . .  51
  Appendix B. =  Document Change Log  . . . . . . . . . . . . . . . . =  51
    B.1.  Changes to = draft-ietf-lisp-rfc6830bis-06  . . . . . . . .  52
    B.2.  Changes to = draft-ietf-lisp-rfc6830bis-06  . . . . . . . .  52
    B.3.  Changes to = draft-ietf-lisp-rfc6830bis-05  . . . . . . . .  52
    B.4.  Changes to = draft-ietf-lisp-rfc6830bis-04  . . . . . . . .  52
    B.5.  Changes to = draft-ietf-lisp-rfc6830bis-03  . . . . . . . .  53
    B.6.  Changes to = draft-ietf-lisp-rfc6830bis-02  . . . . . . . .  53
    B.7.  Changes to = draft-ietf-lisp-rfc6830bis-01  . . . . . . . .  53
    B.8.  Changes to = draft-ietf-lisp-rfc6830bis-00  . . . . . . . .  53
  Authors' Addresses  . . . . . . . . . . . . = . . . . . . . . . . .  53

1. =  Introduction

  This = document describes the Locator/Identifier Separation Protocol
  (LISP).  LISP is an encapsulation protocol = built around the
  fundamental idea of = separating the topological location of a network
  attachment point from the node's identity = [CHIAPPA].  As a result
  LISP creates two = namespaces: Endpoint Identifiers (EIDs), that are
  used to identify end-hosts (e.g., nodes or = Virtual Machines) and
  routable Routing = Locators (RLOCs), used to identify network
  attachment points.  LISP then defines = functions for mapping between
  the two = namespaces and for encapsulating traffic originated by
  devices using non-routable EIDs for transport = across a network
  infrastructure that routes = and forwards using RLOCs.

  LISP = is an overlay protocol that separates control from data-plane,
  this document specifies the data-plane, how = LISP-capable routers
  (Tunnel Routers) exchange = packets by encapsulating them to the
  appropriate= location.  Tunnel routers are equipped with a cache,
  called map-cache, that contains EID-to-RLOC = mappings.  The map-cache




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 3]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  is populated using = the LISP Control-Plane protocol
  [I-D.ietf-lisp-rfc6833bis].

  LISP does not require changes to either host = protocol stack or to
  underlay routers. =  By separating the EID from the RLOC space, LISP
  offers native Traffic Engineering, multihoming = and mobility, among
  other features.

  Creation of LISP was initially = motivated by discussions during the
  IAB-sponsored Routing and Addressing Workshop = held in Amsterdam in
  October 2006 (see = [RFC4984])

  This document = specifies the LISP data-plane encapsulation and other
  LISP forwarding node functionality while = [I-D.ietf-lisp-rfc6833bis]
  specifies the LISP = control plane.  LISP deployment guidelines can be
  found in [RFC7215] and [RFC6835] describes = considerations for network
  operational = management.  Finally, [I-D.ietf-lisp-introduction]
  describes the LISP architecture.

2.  Requirements Notation

  The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in = [RFC2119].

3.  Definition of Terms


What is the order = of the Terms?

It is not alphabetical and = not logical (at least I cannot se it).

May = be better to re-order in alphabetical order.

  Provider-Independent (PI) Addresses: =   PI addresses are an address
     block assigned from a pool = where blocks are not associated with
     any particular location in the = network (e.g., from a particular
     service provider) and are = therefore not topologically aggregatable
     in the routing system.

  Provider-Assigned (PA) Addresses: =   PA addresses are an address block
     assigned to a site by each = service provider to which a site
     connects.  Typically, each = block is a sub-block of a service
     provider Classless Inter-Domain = Routing (CIDR) [RFC4632] block and
     is aggregated into the larger = block before being advertised into
     the global Internet. =  Traditionally, IP multihoming has been
     implemented by each multihomed = site acquiring its own globally
     visible prefix.  LISP uses = only topologically assigned and
     aggregatable address blocks for = RLOCs, eliminating this
     demonstrably non-scalable = practice.

Last sentence to be = deleted is a relic of scalability discussion.


  Routing Locator (RLOC):   An RLOC is an = IPv4 [RFC0791] or IPv6
     [RFC8200] address of an Egress = Tunnel Router (ETR).  An RLOC is
     the output of an EID-to-RLOC = mapping lookup.  An EID maps to one
     or more RLOCs.  Typically, = RLOCs are numbered from topologically



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 4]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


     aggregatable

Delete "topologically aggregatable"


blocks that are assigned to a site at each point to
     which it attaches to the global = Internet; where the topology is
     defined by the connectivity of = provider networks, RLOCs can be
     thought of as PA addresses. =  

Delete "RLOCs can be = thought of as PA addresses."


Multiple RLOCs can be = assigned to the
     same ETR = device or to multiple ETR devices at a site.

  Endpoint ID (EID):   An EID is a 32-bit = (for IPv4) or 128-bit (for
     IPv6) value used in the source = and destination address fields of
     the first (most inner) LISP = header of a packet.  The host obtains
     a destination EID the same way = it obtains a destination address
     today, for example, through a = Domain Name System (DNS) [RFC1034]
     lookup or Session Initiation = Protocol (SIP) [RFC3261] exchange.
     The source EID is obtained via = existing mechanisms used to set a
     host's "local" IP address. =  An EID used on the public Internet
     must have the same properties = as any other IP address used in that
     manner; this means, among other = things, that it must be globally
     unique.  An EID is = allocated to a host from an EID-Prefix block
     associated with the site where = the host is located.  An EID can be
     used by a host to refer to = other hosts.  Note that EID blocks MAY
     be assigned in a hierarchical = manner, independent of the network
     topology, to facilitate scaling = of the mapping database.  In
     addition, an EID block assigned = to a site may have site-local
     structure (subnetting) for = routing within the site; this structure
     is not visible to the global = routing system.  In theory, the bit
     string that represents an EID = for one device can represent an RLOC
     for a different device. =  As the architecture is realized, if a
     given bit string is both an = RLOC and an EID, it must refer to the
     same entity in both cases. 


Is the above sentence really = necessary?

When used in discussions = with other
     Locator/ID = separation proposals, a LISP EID will be called an
     "LEID".  Throughout this = document, any references to "EID" refer
     to an LEID.

  EID-Prefix:   An EID-Prefix is a = power-of-two block of EIDs that are
     allocated to a site by an = address allocation authority.  EID-
     Prefixes are associated with a = set of RLOC addresses that make up
     a "database mapping=E2=80=9D.

Delete =E2=80=9Cthat make up a = database mapping=E2=80=9D.

 EID-Prefix allocations can be broken = up
     into smaller blocks when = an RLOC set is to be associated with the
     larger EID-Prefix block. 

Delete the rest of the paragraph, is relic of = scalability discussion.
A globally routed address block (whether
     PI or PA) is not inherently an = EID-Prefix.  A globally routed
     address block MAY be used by = its assignee as an EID block.  The
     converse is not supported. =  That is, a site that receives an
     explicitly allocated EID-Prefix = may not use that EID-Prefix as a
     globally routed prefix. =  This would require coordination and
     cooperation with the entities = managing the mapping infrastructure.
     Once this has been done, that = block could be removed from the
     globally routed IP system, if = other suitable transition and access
     mechanisms are in place. =  Discussion of such transition and access
     mechanisms can be found in = [RFC6832] and [RFC7215].



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 5]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  End-system: =   An end-system is an IPv4 or IPv6 device that originates
     packets with a single IPv4 or = IPv6 header.  The end-system
     supplies an EID value for the = destination address field of the IP
     header when communicating = globally (i.e., outside of its routing
     domain).  An end-system = can be a host computer, a switch or router
     device, or any network = appliance.

  Ingress Tunnel = Router (ITR):   An ITR is a router that resides in a
     LISP site.  Packets sent = by sources inside of the LISP site to
     destinations outside of the = site are candidates for encapsulation
     by the ITR.  The ITR = treats the IP destination address as an EID
     and performs an EID-to-RLOC = mapping lookup.  The router then
     prepends an "outer" IP header = with one of its routable RLOCs (in
     the RLOC space) in the source = address field and the result of the
     mapping lookup in the = destination address field.  Note that this
     destination RLOC MAY be an = intermediate, proxy device that has
     better knowledge of the = EID-to-RLOC mapping closer to the
     destination EID.  In = general, an ITR receives IP packets from site
     end-systems on one side and = sends LISP-encapsulated IP packets
     toward the Internet on the = other side.

     Specifically, when a service = provider prepends a LISP header for
     Traffic Engineering purposes, = the router that does this is also
     regarded as an ITR.  The = outer RLOC the ISP ITR uses can be based
     on the outer destination = address (the originating ITR's supplied
     RLOC) or the inner destination = address (the originating host's
     supplied EID).

  TE-ITR:   A TE-ITR is an ITR that is = deployed in a service provider
     network that prepends an = additional LISP header for Traffic
     Engineering purposes.

  Egress Tunnel Router (ETR): =   An ETR is a router that accepts an IP
     packet where the destination = address in the "outer" IP header is
     one of its own RLOCs.  The = router strips the "outer" header and
     forwards the packet based on = the next IP header found.  In
     general, an ETR receives = LISP-encapsulated IP packets from the
     Internet on one side and sends = decapsulated IP packets to site
     end-systems on the other side. =  ETR functionality does not have to
     be limited to a router device. =  A server host can be the endpoint
     of a LISP tunnel as well.

  TE-ETR:   A TE-ETR is an = ETR that is deployed in a service provider
     network that strips an outer = LISP header for Traffic Engineering
     purposes.

  xTR:   An xTR is a reference to an ITR = or ETR when direction of data
     flow is not part of the context = description.  "xTR" refers to the



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 6]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


     router that is the tunnel = endpoint and is used synonymously with
     the term "Tunnel Router". =  For example, "An xTR can be located at
     the Customer Edge (CE) router" = indicates both ITR and ETR
     functionality at the CE = router.

  Re-encapsulating = Tunneling in RTRs:   Re-encapsulating Tunneling

RTR have never been defined.


     occurs when an RTR = (Re-encapsulating Tunnel Router) acts like an
     ETR to remove a LISP header, = then acts as an ITR to prepend a new
     LISP header.  Doing this = allows a packet to be re-routed by the
     RTR without adding the overhead = of additional tunnel headers.  Any
     references to tunnels in this = specification refer to dynamic
     encapsulating tunnels; they are = never statically configured.  When
     using multiple mapping database = systems, care must be taken to not
     create re-encapsulation loops = through misconfiguration.

  LISP = Router:   A LISP router is a router that performs the = functions
     of any or all of = the following: ITR, ETR, RTR, Proxy-ITR (PITR),
     or Proxy-ETR (PETR).

  EID-to-RLOC Map-Cache: =   The EID-to-RLOC map-cache is generally
     short-lived, on-demand table in = an ITR that stores, tracks, and is
     responsible for timing out and = otherwise validating EID-to-RLOC
     mappings.  This cache is = distinct from the full "database" of EID-
     to-RLOC mappings; it is = dynamic, local to the ITR(s), and
     relatively small, while the = database is distributed, relatively
     static, and much more global in = scope.

  EID-to-RLOC Database: =   The EID-to-RLOC Database is a global
     distributed database that = contains all known EID-Prefix-to-RLOC
     mappings.  Each potential = ETR typically contains a small piece of
     the database: the EID-to-RLOC = mappings for the EID-Prefixes
     "behind" the router. =  These map to one of the router's own
     globally visible IP addresses. =  Note that there MAY be transient
     conditions when the EID-Prefix = for the site and Locator-Set for
     each EID-Prefix may not be the = same on all ETRs.  This has no
     negative implications, since a = partial set of Locators can be
     used.

  Recursive Tunneling:   Recursive = Tunneling occurs when a packet has
     more than one LISP IP header. =  Additional layers of tunneling MAY
     be employed to implement = Traffic Engineering or other re-routing
     as needed.  When this is = done, an additional "outer" LISP header
     is added, and the original = RLOCs are preserved in the "inner"
     header.  

Do not think the following sentence is really = necessary.



Any references to tunnels in this specification refer to
     dynamic encapsulating tunnels; = they are never statically
     configured.





Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 7]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  LISP Header: =   LISP header is a term used in this document to refer
     to the outer IPv4 or IPv6 = header, a UDP header, and a LISP-
     specific 8-octet header that = follow the UDP header and that an ITR
     prepends or an ETR strips.

  Address Family Identifier (AFI): =   AFI is a term used to describe an
     address encoding in a packet. =  An address family that pertains to
     the data-plane.  See [AFN] = and [RFC3232] for details.  An AFI
     value of 0 used in this = specification indicates an unspecified
     encoded address where the = length of the address is 0 octets
     following the 16-bit AFI value = of 0.

  Negative Mapping Entry: =   A negative mapping entry, also known as a
     negative cache entry, is an = EID-to-RLOC entry where an EID-Prefix
     is advertised or stored with no = RLOCs.  That is, the Locator-Set
     for the EID-to-RLOC entry is = empty or has an encoded Locator count
     of 0.  This type of entry = could be used to describe a prefix from
     a non-LISP site, which is = explicitly not in the mapping database.
     There are a set of well-defined = actions that are encoded in a
     Negative Map-Reply.

  Data-Probe:   A = Data-Probe is a LISP-encapsulated data packet where
     the inner-header destination = address equals the outer-header
     destination address used to = trigger a Map-Reply by a decapsulating
     ETR.  In addition, the = original packet is decapsulated and
     delivered to the destination = host if the destination EID is in the
     EID-Prefix range configured on = the ETR.  Otherwise, the packet is
     discarded.  A Data-Probe = is used in some of the mapping database
     designs to "probe" or request a = Map-Reply from an ETR; in other
     cases, Map-Requests are used. =  See each mapping database design
     for details.  When using = Data-Probes, by sending Map-Requests on
     the underlying routing system, = EID-Prefixes must be advertised.



Delete following sentence.
     However, this is discouraged if = the core is to scale by having
     less EID-Prefixes stored in the = core router's routing tables.

  Proxy-ITR (PITR):   A PITR is defined = and described in [RFC6832].  A
     PITR acts like an ITR but does = so on behalf of non-LISP sites that
     send packets to destinations at = LISP sites.

  Proxy-ETR (PETR): =   A PETR is defined and described in [RFC6832].  A
     PETR acts like an ETR but does = so on behalf of LISP sites that
     send packets to destinations at = non-LISP sites.

  Route-returnability:  Route-returnability is = an assumption that the
     underlying routing system will = deliver packets to the destination.
     When combined with a nonce that = is provided by a sender and
     returned by a receiver, this = limits off-path data insertion.  A
     route-returnability check is = verified when a message is sent with



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 8]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


     a = nonce, another message is returned with the same nonce, and the
     destination of the original = message appears as the source of the
     returned message.

  LISP site:  LISP site is a = set of routers in an edge network that are
     under a single technical = administration.  LISP routers that reside
     in the edge network are the = demarcation points to separate the
     edge network from the core = network.

  Client-side: =  Client-side is a term used in this document to indicate
     a connection initiation attempt = by an EID. 



Following sentence not = needed here. (it is specified in the operation part of the document)
The ITR(s) at the = LISP
     site are the first to = get involved in obtaining database Map-Cache
     entries by sending Map-Request = messages.

  Server-side: =  Server-side is a term used in this document to indicate
     that a connection initiation = attempt is being accepted for a
     destination EID.  




Rest of the paragraph not needed here. (it is specified in = the operation part of the document)

The ETR(s) at the = destination LISP site may be
     the first to send Map-Replies = to the source site initiating the
     connection.  The ETR(s) at = this destination site can obtain
     mappings by gleaning = information from Map-Requests, Data-Probes,
     or encapsulated packets.

  Locator-Status-Bits (LSBs): =  Locator-Status-Bits are present in the
     LISP header.  They are = used by ITRs to inform ETRs about the up/
     down status of all ETRs at the = local site.  These bits are used as
     a hint to convey up/down router = status and not path reachability
     status.  The LSBs can be = verified by use of one of the Locator
     reachability algorithms = described in Section 10.

  Anycast = Address:  Anycast Address is a term used in this document to
     refer to the same IPv4 or IPv6 = address configured and used on
     multiple systems at the same = time.  An EID or RLOC can be an
     anycast address in each of = their own address spaces.

4.  Basic = Overview

  One key concept of = LISP is that end-systems operate the same way they
  do today.  The IP addresses that hosts use = for tracking sockets and
  connections, and for = sending and receiving packets, do not change.
  In= LISP terminology, these IP addresses are called Endpoint
  Identifiers (EIDs).

  Routers continue to forward packets based on IP = destination
  addresses.  When a packet is = LISP encapsulated, these addresses are
  referred = to as Routing Locators (RLOCs).  Most routers along a path
  between two hosts will not change; they continue = to perform routing/
  forwarding lookups on the = destination addresses.  For routers between
  the source host and the ITR as well as routers = from the ETR to the



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;    [Page 9]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  destination host, = the destination address is an EID.  For the routers
  between the ITR and the ETR, the destination = address is an RLOC.

  Another key = LISP concept is the "Tunnel Router".  A Tunnel Router
  prepends LISP headers on host-originated packets = and strips them
  prior to final delivery to = their destination.  The IP addresses in
  this "outer header" are RLOCs.  During = end-to-end packet exchange
  between two = Internet hosts, an ITR prepends a new LISP header to each
  packet, and an ETR strips the new header. =  The ITR performs EID-to-
  RLOC lookups to = determine the routing path to the ETR, which has the
  RLOC as one of its IP addresses.

  Some basic rules governing LISP are:

  o  End-systems only send to = addresses that are EIDs.  They don't know
     that addresses are EIDs versus = RLOCs but assume that packets get
     to their intended destinations. =  In a system where LISP is
     deployed, LISP routers = intercept EID-addressed packets and assist
     in delivering them across the = network core where EIDs cannot be
     routed.  The procedure a = host uses to send IP packets does not
     change.

  o  EIDs are typically IP addresses assigned = to hosts.

  o  Other types = of EID are supported by LISP, see [RFC8060] for
     further information.

I would put the last two bullets = in the definition of EID. It simplifies the story here.






  o  LISP routers mostly deal with Routing = Locator addresses.  See
     details in Section 4.1 to = clarify what is meant by "mostly".

  o  RLOCs are always IP addresses assigned to = routers, preferably
     topologically oriented = addresses from provider CIDR (Classless
     Inter-Domain Routing) = blocks.

  o  When a router = originates packets, it may use as a source address
     either an EID or RLOC. =  When acting as a host (e.g., when
     terminating a transport session = such as Secure SHell (SSH),
     TELNET, or the Simple Network = Management Protocol (SNMP)), it may
     use an EID that is explicitly = assigned for that purpose.  An EID
     that identifies the router as a = host MUST NOT be used as an RLOC;
     an EID is only routable within = the scope of a site.  A typical BGP
     configuration might demonstrate = this "hybrid" EID/RLOC usage where
     a router could use its = "host-like" EID to terminate iBGP sessions
     to other routers in a site = while at the same time using RLOCs to
     terminate eBGP sessions to = routers outside the site.

  o =  Packets with EIDs in them are not expected to be delivered = end-to-
     end in the absence = of an EID-to-RLOC mapping operation.  They are



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 10]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


     expected to be used locally for = intra-site communication or to be
     encapsulated for inter-site = communication.

  o =  EID-Prefixes are likely to be hierarchically assigned in a = manner
     that is optimized for = administrative convenience and to facilitate
     scaling of the EID-to-RLOC = mapping database.  The hierarchy is
     based on an address allocation = hierarchy that is independent of
     the network topology.

Drop the last bullet it is about = scalability.





  o  EIDs may also be structured (subnetted) = in a manner suitable for
     local= routing within an Autonomous System (AS).

  An additional LISP header MAY be prepended to = packets by a TE-ITR
  when re-routing of the = path for a packet is desired.  A potential
  use-case for this would be an ISP router that = needs to perform
  Traffic Engineering for = packets flowing through its network.  In such
  a situation, termed "Recursive Tunneling", an ISP = transit acts as an
  additional ITR, and the = RLOC it uses for the new prepended header
  would = be either a TE-ETR within the ISP (along an intra-ISP traffic
  engineered path) or a TE-ETR within another ISP = (an inter-ISP traffic
  engineered path, where = an agreement to build such a path exists).

  In order to avoid excessive packet overhead as = well as possible
  encapsulation loops, this = document recommends that a maximum of two
  LISP = headers can be prepended to a packet.  For initial LISP
  deployments, it is assumed that two headers is = sufficient, where the
  first prepended header = is used at a site for Location/Identity
  separation and the second prepended header is = used inside a service
  provider for Traffic = Engineering purposes.

  Tunnel = Routers can be placed fairly flexibly in a multi-AS topology.
  For example, the ITR for a particular end-to-end = packet exchange
  might be the first-hop or = default router within a site for the source
  host.  Similarly, the ETR might be the = last-hop router directly
  connected to the = destination host.  Another example, perhaps for a
  VPN service outsourced to an ISP by a site, the = ITR could be the
  site's border router at the = service provider attachment point.
  Mixing and = matching of site-operated, ISP-operated, and other Tunnel
  Routers is allowed for maximum flexibility.

4.1.  Packet Flow Sequence

  This section provides an example = of the unicast packet flow,
  including also = control-plane information as specified in
  [I-D.ietf-lisp-rfc6833bis].  The example = also assumes the following
  conditions:




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 11]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  o  Source host = "
host1.abc.example.com
" is sending a packet = to
     "
host2.xyz.example.com
", exactly what host1 = would do if the site
     was not = using LISP.

  o  Each site = is multihomed, so each Tunnel Router has an address
     (RLOC) assigned from the = service provider address block for each
     provider to which that = particular Tunnel Router is attached.

  o  The ITR(s) and ETR(s) are directly = connected to the source and
     destination, respectively, but = the source and destination can be
     located anywhere in the LISP = site.

  o  Map-Requests are = sent to the mapping database system by using the
     LISP control-plane protocol = documented in
     [I-D.ietf-lisp-rfc6833bis]. =  A Map-Request is sent for an external
     destination when the = destination is not found in the forwarding
     table or matches a default = route.

Switch the two = sentences of the above bullet. So to become:

= A Map-Request is sent for an external destination when the = destination is not found in 
the = forwarding table or matches a default route. Map-Requests are sent to = the mapping database  = system by using the LISP control-plane documented in = [I-D.ietf-lisp-rfc6833bis].





  o =  Map-Replies are sent on the underlying routing system topology
     using the = [I-D.ietf-lisp-rfc6833bis] control-plane protocol.

  Client 
host1.abc.example.com
wants to communicate = with server

host2.xyz.example.com
:

  1.  
host1.abc.example.com
wants to open a TCP = connection to

host2.xyz.example.com
.  It does a DNS lookup on

host2.xyz.example.com
.  An A/AAAA record = is returned.  This
      address is the = destination EID.  The locally assigned address of

host1.abc.example.com
is used as the source = EID.  An IPv4 or IPv6
      packet is built and = forwarded through the LISP site as a normal
      IP packet until it = reaches a LISP ITR.

  2. =  The LISP ITR must be able to map the destination EID to an RLOC
      of one of the ETRs at the = destination site.  The specific method
      used to do this is not = described in this example.  See
      [I-D.ietf-lisp-rfc6833bis] = for further information.

  3. =  The ITR sends a LISP Map-Request as specified in
      [I-D.ietf-lisp-rfc6833bis].=  Map-Requests SHOULD be rate-limited.

  4.  The mapping system helps forwarding the = Map-Request to the
      corresponding ETR. =  When the Map-Request arrives at one of the
      ETRs at the destination = site, it will process the packet as a
      control message.

  5.  The ETR looks at the = destination EID of the Map-Request and
      matches it against the = prefixes in the ETR's configured EID-to-
      RLOC mapping database. =  This is the list of EID-Prefixes the ETR



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 12]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


      is supporting for the = site it resides in.  If there is no match,
      the Map-Request is = dropped.  Otherwise, a LISP Map-Reply is
      returned to the ITR.

  6.  The ITR receives the = Map-Reply message, parses the message (to
      check for format = validity), and stores the mapping information
      from the packet. =  This information is stored in the ITR's EID-to-
      RLOC map-cache. =  Note that the map-cache is an on-demand cache.
      An ITR will manage its = map-cache in such a way that optimizes for
      its resource = constraints.

  7. =  Subsequent packets from 
host1.abc.example.com
to

host2.xyz.example.com
will have a LISP header = prepended by the
      ITR = using the appropriate RLOC as the LISP header destination
      address learned from the = ETR.  Note that the packet MAY be sent
      to a different ETR than = the one that returned the Map-Reply due
      to the source site's = hashing policy or the destination site's
      Locator-Set policy.

  8.  The ETR receives these = packets directly (since the destination
      address is one of its = assigned IP addresses), checks the validity
      of the addresses, strips = the LISP header, and forwards packets to
      the attached destination = host.

  9.  In order to = defer the need for a mapping lookup in the reverse
      direction, an ETR can = OPTIONALLY create a cache entry that maps
      the source EID = (inner-header source IP address) to the source
      RLOC (outer-header source = IP address) in a received LISP packet.
      Such a cache entry is = termed a "gleaned" mapping and only
      contains a single RLOC = for the EID in question.  More complete
      information about = additional RLOCs SHOULD be verified by sending
      a LISP Map-Request for = that EID.  Both the ITR and the ETR may
      also influence the = decision the other makes in selecting an RLOC.

5.  LISP Encapsulation Details

  Since additional tunnel headers are prepended, = the packet becomes
  larger and can exceed the = MTU of any link traversed from the ITR to
  the = ETR.  It is RECOMMENDED in IPv4 that packets do not get
  fragmented as they are encapsulated by the ITR. =  Instead, the packet
  is dropped and an = ICMP Unreachable/Fragmentation-Needed message is
  returned to the source.

In the paragraph above  it is recommended = not to fragment.
In the paragraph below it is recommended = to use the suggested algorithms to fragment.

Shouldn=E2=80=99t we put a sentence like =E2=80=9CIn the case = that fragmentation is a desirable feature, this specification = RECOMMENDS=E2=80=A6..=E2=80=9D?   

  This = specification RECOMMENDS that implementations provide support
  for one of the proposed fragmentation and = reassembly schemes.  Two
  existing schemes = are detailed in Section 7.




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 13]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  Since IPv4 or IPv6 = addresses can be either EIDs or RLOCs, the LISP
  architecture supports IPv4 EIDs with IPv6 RLOCs = (where the inner
  header is in IPv4 packet = format and the outer header is in IPv6
  packet = format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
  is in IPv6 packet format and the outer header is = in IPv4 packet
  format).  The next = sub-sections illustrate packet formats for the
  homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), = but all 4
  combinations MUST be supported. =  Additional types of EIDs are defined
  in = [RFC8060].

5.1.  LISP IPv4-in-IPv4 = Header Format

       0 =             &n= bsp;     1 =             &n= bsp;     2 =             &n= bsp;     3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / |Version|  IHL  |Type of = Service|          Total = Length         |
   / =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /  |Version|  IHL =   |DSCP      |ECN| =          Total Length =         |
   / =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

The correct IPv4 Header is with DSCP = and ECN. Please update below as well.

  | =   | =         Identification =        |Flags| =      Fragment Offset    |
  | =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  OH  |  Time to Live | Protocol =3D= 17 |         Header Checksum =       |
  | =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  |   | =             &n= bsp;      Source Routing Locator =             &n= bsp;       |
   \ =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    \ | =             &n= bsp;   Destination Routing Locator =             &n= bsp;     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / | =       Source Port =3D xxxx =      |       Dest = Port =3D 4341        |
  UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ | =           UDP Length =          | =        UDP Checksum =           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  L =   |N|L|E|V|I|R|K|K| =            Nonce/Ma= p-Version =             &n= bsp;    |
  I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  S / | =             &n= bsp;   Instance ID/Locator-Status-Bits =             &n= bsp; |
  P =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
    / |Version|  IHL =  |Type of Service| =          Total Length =         |
   / =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |   | =         Identification =        |Flags| =      Fragment Offset    |
  | =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  IH  |  Time to Live | =    Protocol   | =         Header Checksum =       |
  | =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  |   | =             &n= bsp;           &nbs= p; Source EID =             &n= bsp;           &nbs= p;|
   \ =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    \ | =             &n= bsp;           Dest= ination EID =             &n= bsp;         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IHL =3D = IP-Header-Length






Farinacci, et = al.         Expires May 15, 2018 =             &n= bsp;   [Page 14]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


5.2.  LISP IPv6-in-IPv6 = Header Format

       0 =             &n= bsp;     1 =             &n= bsp;     2 =             &n= bsp;     3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / |Version| Traffic Class | =           Flow Label =             &n= bsp;    |
   / =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / |Version| DSCP =      |ECN| =           Flow Label =             &n= bsp;    |
   / =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The correct IPv6 Header is with DSCP and ECN. = Please update below as well.

  |   | =         Payload Length =        | Next Header=3D17| =   Hop Limit   |
  v =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
      | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  O   + =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;+
  u   | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  t   + =             &n= bsp;       Source Routing Locator =             &n= bsp;      +
  e =   | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  r   + =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;+
      | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  H =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  d   | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  r   + =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;+
      | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  ^   + =             &n= bsp;    Destination Routing Locator =             &n= bsp;    +
  |   | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
   \  + =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;+
    \ | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    / | =       Source Port =3D xxxx =      |       Dest = Port =3D 4341        |
  UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \ | =           UDP Length =          | =        UDP Checksum =           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  L =   |N|L|E|V|I|R|K|K| =            Nonce/Ma= p-Version =             &n= bsp;    |
  I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  S / | =             &n= bsp;   Instance ID/Locator-Status-Bits =             &n= bsp; |
  P =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
    / |Version| Traffic Class | =           Flow Label =             &n= bsp;    |
   / =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  /   | =         Payload Length =        |  Next Header  | =   Hop Limit   |
  v =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
      | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  I   + =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;+
  n   | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  n   + =             &n= bsp;           &nbs= p;Source EID =             &n= bsp;           &nbs= p; +
  e   | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  r   + =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;+
      | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  H =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  d   | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
  r   + =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;+
      | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|



Farinacci, = et al.         Expires May 15, = 2018 =             &n= bsp;   [Page 15]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  ^   + =             &n= bsp;          Destinatio= n EID =             &n= bsp;          +
  \   | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
   \  + =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;+
    \ | =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3. =  Tunnel Header Field Descriptions

  Inner Header (IH):  The inner header is the = header on the datagram
     received from the originating = host.  The source and destination IP
     addresses are EIDs [RFC0791] = [RFC8200].

  Outer Header: (OH) =  The outer header is a new header prepended by an
     ITR.  The address fields = contain RLOCs obtained from the ingress
     router's EID-to-RLOC Cache. =  The IP protocol number is "UDP (17)"
     from [RFC0768].  The = setting of the Don't Fragment (DF) bit
     'Flags' field is according to = rules listed in Sections 7.1 and
     7.2.

  UDP Header:  The UDP header contains an ITR = selected source port when
     encapsulating a packet. =  See Section 12 for details on the hash
     algorithm used to select a = source port based on the 5-tuple of the
     inner header.  The = destination port MUST be set to the well-known
     IANA-assigned port value = 4341.

  UDP Checksum:  The = 'UDP Checksum' field SHOULD be transmitted as zero
     by an ITR for either IPv4 = [RFC0768] or IPv6 encapsulation
     [RFC6935] [RFC6936].  

shouldn=E2=80=99t be =E2=80=9Cfor = both for IPv4 [RFC0768] and IPv6 encapsulation [RFC6935] = [RFC6936].???


When a packet with a zero UDP checksum is
     received by an ETR, the ETR = MUST accept the packet for
     decapsulation.  When an = ITR transmits a non-zero value for the UDP
     checksum, it MUST send a = correctly computed value in this field.
     When an ETR receives a packet = with a non-zero UDP checksum, it MAY
     choose to verify the checksum = value.  If it chooses to perform
     such verification, and the = verification fails, the packet MUST be
     silently dropped.  If the = ETR chooses not to perform the
     verification, or performs the = verification successfully, the
     packet MUST be accepted for = decapsulation.  The handling of UDP
     zero checksums over IPv6 for = all tunneling protocols, including
     LISP, is subject to the = applicability statement in [RFC6936].

  UDP Length:  The 'UDP Length' field is set = for an IPv4-encapsulated
     packet to be the sum of the = inner-header IPv4 Total Length plus
     the UDP and LISP header = lengths.  For an IPv6-encapsulated packet,
     the 'UDP Length' field is the = sum of the inner-header IPv6 Payload
     Length, the size of the IPv6 = header (40 octets), and the size of
     the UDP and LISP headers.




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 16]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  N: The N-bit is the = nonce-present bit.  When this bit is set to 1,
     the low-order 24 bits of the = first 32 bits of the LISP header
     contain a Nonce.  See = Section 10.1 for details.  Both N- and
     V-bits MUST NOT be set in the = same packet.  If they are, a
     decapsulating ETR MUST treat = the 'Nonce/Map-Version' field as
     having a Nonce value = present.

  L: The L-bit is the = 'Locator-Status-Bits' field enabled bit.  When
     this bit is set to 1, the = Locator-Status-Bits in the second
     32 bits of the LISP header are = in use.

    x 1 x x 0 x = x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K| =            Nonce/Ma= p-Version =             &n= bsp;    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   | =             &n= bsp;        Locator-Status-Bits =             &n= bsp;        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

  E: The = E-bit is the echo-nonce-request bit.  This bit MUST be ignored
     and has no meaning when the = N-bit is set to 0.  When the N-bit is
     set to 1 and this bit is set to = 1, an ITR is requesting that the
     nonce value in the 'Nonce' = field be echoed back in LISP-
     encapsulated packets when the = ITR is also an ETR.  See
     Section 10.1 for details.

  V: The V-bit is the Map-Version = present bit.  When this bit is set to
     1, the N-bit MUST be 0. =  Refer to Section 13.3 for more details.
     This bit indicates that the = LISP header is encoded in this
     case as:

    0 x 0 1 x x x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K| =  Source Map-Version   |   Dest Map-Version =    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   | =             &n= bsp;   Instance ID/Locator-Status-Bits =             &n= bsp; |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

  I: The = I-bit is the Instance ID bit.  See Section 8 for more details.
     When this bit is set to 1, the = 'Locator-Status-Bits' field is
     reduced to 8 bits and the = high-order 24 bits are used as an
     Instance ID.  If the L-bit = is set to 0, then the low-order 8 bits
     are transmitted as zero and = ignored on receipt.  The format of the
     LISP header would look like = this:








Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 17]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


    x x x x = 1 x x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K| =            Nonce/Ma= p-Version =             &n= bsp;    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   | =             &n= bsp;   Instance ID =             &n= bsp;     |     LSBs =      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

  R: The = R-bit is a Reserved bit for future use.  It MUST be set to 0
     on transmit and MUST be ignored = on receipt.

  KK:  The = KK-bits are a 2-bit field used when encapsualted packets are
     encrypted.  The field is = set to 00 when the packet is not
     encrypted.  See [RFC8061] = for further information.

  LISP = Nonce:  The LISP 'Nonce' field is a 24-bit value that is
     randomly generated by an ITR = when the N-bit is set to 1.  Nonce
     generation algorithms are an = implementation matter but are
     required to generate different = nonces when sending to different
     destinations.

What is a destination? Should be different = RLOCs, for clarity.



 However, the same nonce can be used for = a period of
     time to the same = destination.  The nonce is also used when the
     E-bit is set to request the = nonce value to be echoed by the other
     side when packets are returned. =  When the E-bit is clear but the
     N-bit is set, a remote ITR is = either echoing a previously
     requested echo-nonce or = providing a random nonce.  See
     Section 10.1 for more = details.

  LISP = Locator-Status-Bits (LSBs):  When the L-bit is also set, the
     'Locator-Status-Bits' field in = the LISP header is set by an ITR to
     indicate to an ETR the up/down = status of the Locators in the
     source site.  Each RLOC in = a Map-Reply is assigned an ordinal
     value from 0 to n-1 (when there = are n RLOCs in a mapping entry).
     The Locator-Status-Bits are = numbered from 0 to n-1 from the least
     significant bit of the field. =  The field is 32 bits when the I-bit
     is set to 0 and is 8 bits when = the I-bit is set to 1.  When a
     Locator-Status-Bit is set to 1, = the ITR is indicating to the ETR
     that the RLOC associated with = the bit ordinal has up status.  See
     Section 10 for details on how = an ITR can determine the status of
     the ETRs at the same site. =  When a site has multiple EID-Prefixes
     that result in multiple = mappings (where each could have a
     different Locator-Set), the = Locator-Status-Bits setting in an
     encapsulated packet MUST = reflect the mapping for the EID-Prefix
     that the inner-header source = EID address matches.  If the LSB for
     an anycast Locator is set to 1, = then there is at least one RLOC
     with that address, and the ETR = is considered 'up'.

  When doing = ITR/PITR encapsulation:





Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 18]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  o  The = outer-header 'Time to Live' field (or 'Hop Limit' field, in
     the case of IPv6) SHOULD be = copied from the inner-header 'Time to
     Live' field.

  o  The outer-header 'Type of Service' field = (or the 'Traffic Class'
     field,= in the case of IPv6) SHOULD be copied from the inner-header
     'Type of Service' field (with = one exception; see below).

  When = doing ETR/PETR decapsulation:

  o =  The inner-header 'Time to Live' field (or 'Hop Limit' field, in
     the case of IPv6) SHOULD be = copied from the outer-header 'Time to
     Live' field, when the Time to = Live value of the outer header is
     less than the Time to Live = value of the inner header.  Failing to
     perform this check can cause = the Time to Live of the inner header
     to increment across = encapsulation/decapsulation cycles.  This
     check is also performed when = doing initial encapsulation, when a
     packet comes to an ITR or PITR = destined for a LISP site.

  o =  The inner-header 'Type of Service' field (or the 'Traffic = Class'
     field, in the case of = IPv6) SHOULD be copied from the outer-header
     'Type of Service' field (with = one exception; see below).

  Note = that if an ETR/PETR is also an ITR/PITR and chooses to re-
  encapsulate after decapsulating, the net effect = of this is that the
  new outer header will = carry the same Time to Live as the old outer
  header minus 1.

  Copying the Time to Live (TTL) serves two = purposes: first, it
  preserves the distance the = host intended the packet to travel;
  second, = and more importantly, it provides for suppression of looping
  packets in the event there is a loop of = concatenated tunnels due to
  misconfiguration. =  See Section 18.3 for TTL exception handling for
  traceroute packets.



The description of = the encap/decap operation lacks of clarity concerning how to deal = with 
ECN bits and DSCP .

1. I think that the text should make explicitly the = difference between DSCP and ECN fields.

2. = How to deal with ECN should be part of the description of the =  encap/decap not a paragraph apart.
   This basically means that half of the last = paragraph should be a bullet of the ITR/PITR encapsulation 
   and the other half  in the ETR/PETR = operation.




  The Explicit = Congestion Notification ('ECN') field occupies bits 6
  and 7 of both the IPv4 'Type of Service' field = and the IPv6 'Traffic
  Class' field [RFC3168]. =  The 'ECN' field requires special treatment
  in order to avoid discarding indications of = congestion [RFC3168].
  ITR encapsulation MUST = copy the 2-bit 'ECN' field from the inner
  header= to the outer header.  Re-encapsulation MUST copy the 2-bit
  'ECN' field from the stripped outer header to the = new outer header.
  If the 'ECN' field contains = a congestion indication codepoint (the
  value = is '11', the Congestion Experienced (CE) codepoint), then ETR
  decapsulation MUST copy the 2-bit 'ECN' field = from the stripped outer
  header to the = surviving inner header that is used to forward the
  packet beyond the ETR.  These requirements = preserve CE indications
  when a packet that = uses ECN traverses a LISP tunnel and becomes



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 19]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  marked with a CE = indication due to congestion between the tunnel
  endpoints.

6. =  LISP EID-to-RLOC Map-Cache

  ITRs and PITRs maintain an on-demand cache, = referred as LISP EID-to-
  RLOC Map-Cache, that = contains mappings from EID-prefixes to locator
  sets.  The cache is used to encapsulate = packets from the EID space to
  the = corresponding RLOC network attachment point.

  When an ITR/PITR receives a packet from inside of = the LISP site to
  destinations outside of the = site a longest-prefix match lookup of the
  EID = is done to the map-cache.

  When = the lookup succeeds, the locator-set retrieved from the map-
  cache is used to send the packet to the EID's = topological location.

  If the = lookup fails, the ITR/PITR needs to retrieve the mapping using
  the LISP control-plane protocol = [I-D.ietf-lisp-rfc6833bis].  The
  mapping = is then stored in the local map-cache to forward subsequent
  packets addressed to the same EID-prefix.

  The map-cache is a local cache of = mappings, entries are expired based
  on the = associated Time to live.  In addition, entries can be updated
  with more current information, see Section 13 for = further information
  on this.  Finally, = the map-cache also contains reachability
  information about EIDs and RLOCs, and uses LISP = reachability
  information mechanisms to = determine the reachability of RLOCs, see
  Section= 10 for the specific mechanisms.

7. =  Dealing with Large Encapsulated Packets

  This section proposes two mechanisms to deal with = packets that exceed
  the path MTU between the = ITR and ETR.

  It is left to the = implementor to decide if the stateless or stateful
  mechanism should be implemented.  Both or = neither can be used, since
  it is a local = decision in the ITR regarding how to deal with MTU
  issues, and sites can interoperate with differing = mechanisms.

  Both stateless and = stateful mechanisms also apply to Re-encapsulating
  and Recursive Tunneling, so any actions below = referring to an ITR
  also apply to a TE-ITR.







Farinacci, et = al.         Expires May 15, 2018 =             &n= bsp;   [Page 20]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


7.1.  A Stateless Solution = to MTU Handling

  An ITR = stateless solution to handle MTU issues is described as
  follows:

  1.  Define H to be the size, in octets, of = the outer header an ITR
      prepends to a packet. =  This includes the UDP and LISP header
      lengths.

  2.  Define L to be the size, in octets, of = the maximum-sized packet
      an ITR can send to an ETR = without the need for the ITR or any
      intermediate routers to = fragment the packet.

  3. =  Define an architectural constant S for the maximum size of a
      packet, in octets, an ITR = must receive from the source so the
      effective MTU can be met. =  That is, L =3D S + H.

  When = an ITR receives a packet from a site-facing interface and adds H
  octets worth of encapsulation to yield a packet = size greater than L
  octets (meaning the = received packet size was greater than S octets
  from the source), it resolves the MTU issue by = first splitting the
  original packet into 2 = equal-sized fragments.  A LISP header is then
  prepended to each fragment.  The size of the = encapsulated fragments
  is then (S/2 + H), = which is less than the ITR's estimate of the path
  MTU between the ITR and its correspondent ETR.

  When an ETR receives encapsulated = fragments, it treats them as two
  individually = encapsulated packets.  It strips the LISP headers and
  then forwards each fragment to the destination = host of the
  destination site.  The two = fragments are reassembled at the
  destination = host into the single IP datagram that was originated by
  the source host.  Note that reassembly can = happen at the ETR if the
  encapsulated packet = was fragmented at or after the ITR.

  This behavior is performed by the ITR when the = source host originates
  a packet with the 'DF' = field of the IP header set to 0.  When the
  'DF' field of the IP header is set to 1, or the = packet is an IPv6
  packet originated by the = source host, the ITR will drop the packet
  when = the size is greater than L and send an ICMP Unreachable/
  Fragmentation-Needed message to the source with a = value of S, where S
  is (L - H).

  When the outer-header = encapsulation uses an IPv4 header, an
  implementation SHOULD set the DF bit to 1 so ETR = fragment reassembly
  can be avoided.  An = implementation MAY set the DF bit in such headers
  to 0 if it has good reason to believe there are = unresolvable path MTU
  issues between the = sending ITR and the receiving ETR.




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 21]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  This specification = RECOMMENDS that L be defined as 1500.

7.2. =  A Stateful Solution to MTU Handling

  An ITR stateful solution to handle MTU issues is = described as follows
  and was first introduced = in [OPENLISP]:

  1.  The ITR = will keep state of the effective MTU for each Locator per
      Map-Cache entry. =  The effective MTU is what the core network can
      deliver along the path = between the ITR and ETR.

  2. =  When an IPv6-encapsulated packet, or an IPv4-encapsulated = packet
      with the DF bit = set to 1, exceeds what the core network can
      deliver, one of the = intermediate routers on the path will send an
      ICMP = Unreachable/Fragmentation-Needed message to the ITR.  The
      ITR will parse the ICMP = message to determine which Locator is
      affected by the effective = MTU change and then record the new
      effective MTU value in = the Map-Cache entry.

  3. =  When a packet is received by the ITR from a source inside of = the
      site and the size = of the packet is greater than the effective MTU
      stored with the Map-Cache = entry associated with the destination
      EID the packet is for, = the ITR will send an ICMP Unreachable/
      Fragmentation-Needed = message back to the source.  The packet size
      advertised by the ITR in = the ICMP Unreachable/Fragmentation-
      Needed message is the = effective MTU minus the LISP encapsulation
      length.

  Even though this mechanism is stateful, it has = advantages over the
  stateless IP fragmentation = mechanism, by not involving the
  destination = host with reassembly of ITR fragmented packets.

8.  Using Virtualization and Segmentation with LISP

  There are several cases where = segregation is needed at the EID level.
  For = instance, this is the case for deployments containing overlapping
  addresses, traffic isolation policies or = multi-tenant virtualization.
  For these and = other scenarios where segregation is needed, Instance
  IDs are used.

  An Instance ID can be carried in a = LISP-encapsulated packet.  An ITR
  that = prepends a LISP header will copy a 24-bit value used by the LISP
  router to uniquely identify the address space. =  The value is copied
  to the 'Instance ID' = field of the LISP header, and the I-bit is set
  to 1.






Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 22]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  When an ETR = decapsulates a packet, the Instance ID from the LISP
  header is used as a table identifier to locate = the forwarding table
  to use for the inner = destination EID lookup.

  For = example, an 802.1Q VLAN tag or VPN identifier could be used as a
  24-bit Instance ID.  See [I-D.ietf-lisp-vpn] = for LISP VPN use-case
  details.
  The Instance ID that is stored in the mapping = database when LISP-DDT
  [I-D.ietf-lisp-ddt] is = used is 32 bits in length.  That means the
  control-plane can store more instances than a = given data-plane can
  use.  Multiple = data-planes can use the same 32-bit space as long as
  the low-order 24 bits don't overlap among = xTRs.

9.  Routing Locator Selection

Large part of this section is = about control plane issues and as such should be put in 6833bis.

What this section should state is that = priority and weight are used to select the RLOC to use.
Only= exception is gleaning where we have one single RLOC and we do not know = neither priority nor weight.

All the = other operational discussion goes elsewhere, but not in this = document.



  Both the client-side and server-side may need = control over the
  selection of RLOCs for = conversations between them.  This control is
  achieved by manipulating the 'Priority' and = 'Weight' fields in EID-
  to-RLOC Map-Reply = messages.  Alternatively, RLOC information MAY be
  gleaned from received tunneled packets or = EID-to-RLOC Map-Request
  messages.

  The following are different = scenarios for choosing RLOCs and the
  controls = that are available:

  o  The = server-side returns one RLOC.  The client-side can only use
     one RLOC.  The server-side = has complete control of the selection.

  o  The server-side returns a list of RLOCs = where a subset of the list
     has= the same best Priority.  The client can only use the subset
     list according to the weighting = assigned by the server-side.  In
     this case, the server-side = controls both the subset list and load-
     splitting across its members. =  The client-side can use RLOCs
     outside of the subset list if = it determines that the subset list
     is unreachable (unless RLOCs = are set to a Priority of 255).  Some
     sharing of control exists: the = server-side determines the
     destination RLOC list and load = distribution while the client-side
     has the option of using = alternatives to this list if RLOCs in the
     list are unreachable.

  o  The server-side sets a = Weight of 0 for the RLOC subset list.  In
     this case, the client-side can = choose how the traffic load is
     spread across the subset list. =  Control is shared by the server-
     side determining the list and = the client determining load
     distribution.  Again, the = client can use alternative RLOCs if the
     server-provided list of RLOCs = is unreachable.




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 23]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  o  Either side = (more likely the server-side ETR) decides not to send
     a Map-Request.  For = example, if the server-side ETR does not send
     Map-Requests, it gleans RLOCs = from the client-side ITR, giving the
     client-side ITR responsibility = for bidirectional RLOC reachability
     and preferability. =  Server-side ETR gleaning of the client-side
     ITR RLOC is done by caching the = inner-header source EID and the
     outer-header source RLOC of = received packets.  The client-side ITR
     controls how traffic is = returned and can alternate using an outer-
     header source RLOC, which then = can be added to the list the
     server-side ETR uses to return = traffic.  Since no Priority or
     Weights are provided using this = method, the server-side ETR MUST
     assume that each client-side = ITR RLOC uses the same best Priority
     with a Weight of zero.  In = addition, since EID-Prefix encoding
     cannot be conveyed in data = packets, the EID-to-RLOC Cache on
     Tunnel Routers can grow to be = very large.

  o  A "gleaned" = Map-Cache entry, one learned from the source RLOC of a
     received encapsulated packet, = is only stored and used for a few
     seconds, pending verification. =  Verification is performed by
     sending a Map-Request to the = source EID (the inner-header IP
     source address) of the received = encapsulated packet.  A reply to
     this "verifying Map-Request" is = used to fully populate the Map-
     Cache entry for the "gleaned" = EID and is stored and used for the
     time indicated from the 'TTL' = field of a received Map-Reply.  When
     a verified Map-Cache entry is = stored, data gleaning no longer
     occurs for subsequent packets = that have a source EID that matches
     the EID-Prefix of the verified = entry.  This "gleaning" mechanism
     is OPTIONAL.

  RLOCs that appear in EID-to-RLOC Map-Reply = messages are assumed to be
  reachable when the = R-bit for the Locator record is set to 1.  When
  the R-bit is set to 0, an ITR or PITR MUST NOT = encapsulate to the
  RLOC.  Neither the = information contained in a Map-Reply nor that
  stored in the mapping database system provides = reachability
  information for RLOCs.  Note = that reachability is not part of the
  mapping = system and is determined using one or more of the Routing
  Locator reachability algorithms described in the = next section.

10.  Routing Locator = Reachability

  Several mechanisms = for determining RLOC reachability are currently
  defined:

There exists data-plane based reachability = mechanisms and control plane reachability mechanisms.
We = have to keep here only the data plane based mechanism and move the other = in 6833bis.

We need to keep: 1, 6, = Echo-Nonce, 

We need to move: 2, 3, 4, 5, =  RLOC-Probing






  1.  An ETR may examine the = Locator-Status-Bits in the LISP header of
      an encapsulated data = packet received from an ITR.  If the ETR is
      also acting as an ITR and = has traffic to return to the original
      ITR site, it can use this = status information to help select an
      RLOC.



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 24]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  2.  An ITR may = receive an ICMP Network Unreachable or Host
      Unreachable message for = an RLOC it is using.  This indicates that
      the RLOC is likely down. =  Note that trusting ICMP messages may
      not be desirable, but = neither is ignoring them completely.
      Implementations are = encouraged to follow current best practices
      in treating these = conditions.

  3.  An ITR = that participates in the global routing system can
      determine that an RLOC is = down if no BGP Routing Information Base
      (RIB) route exists that = matches the RLOC IP address.

  4. =  An ITR may receive an ICMP Port Unreachable message from a
      destination host. =  This occurs if an ITR attempts to use
      interworking [RFC6832] = and LISP-encapsulated data is sent to a
      non-LISP-capable site.

  5.  An ITR may receive a = Map-Reply from an ETR in response to a
      previously sent = Map-Request.  The RLOC source of the Map-Reply is
      likely up, since the ETR = was able to send the Map-Reply to the
      ITR.

  6.  When an ETR receives an encapsulated = packet from an ITR, the
      source RLOC from the = outer header of the packet is likely up.

  7.  An ITR/ETR pair can use the Locator = reachability algorithms
      described in this = section, namely Echo-Noncing or RLOC-Probing.

  When determining Locator up/down reachability by = examining the
  Locator-Status-Bits from the = LISP-encapsulated data packet, an ETR
  will = receive up-to-date status from an encapsulating ITR about
  reachability for all ETRs at the site. =  CE-based ITRs at the source
  site can = determine reachability relative to each other using the site
  IGP as follows:

  o  Under normal circumstances, each ITR will = advertise a default
     route = into the site IGP.

  o  If = an ITR fails or if the upstream link to its PE fails, its
     default route will either time = out or be withdrawn.

  Each ITR = can thus observe the presence or lack of a default route
  originated by the others to determine the = Locator-Status-Bits it sets
  for them.

  RLOCs listed in a Map-Reply are = numbered with ordinals 0 to n-1.  The
  Locator-Status-Bits in a LISP-encapsulated packet = are numbered from 0
  to n-1 starting with the = least significant bit.  For example, if an
  RLOC listed in the 3rd position of the Map-Reply = goes down (ordinal



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 25]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  value 2), then all = ITRs at the site will clear the 3rd least
  significant bit (xxxx x0xx) of the = 'Locator-Status-Bits' field for
  the packets = they encapsulate.

  When an ETR = decapsulates a packet, it will check for any change in
  the 'Locator-Status-Bits' field.  When a bit = goes from 1 to 0, the
  ETR, if acting also as = an ITR, will refrain from encapsulating
  packets = to an RLOC that is indicated as down.  It will only resume
  using that RLOC if the corresponding = Locator-Status-Bit returns to a
  value of 1. =  Locator-Status-Bits are associated with a Locator-Set
  per EID-Prefix.  Therefore, when a Locator = becomes unreachable, the
  Locator-Status-Bit = that corresponds to that Locator's position in the
  list returned by the last Map-Reply will be set = to zero for that
  particular EID-Prefix.

We need to cite the threats = document because of the security issues of LSB.






  When ITRs at the site are not deployed in CE = routers, the IGP can
  still be used to = determine the reachability of Locators, provided
  they are injected into the IGP.  This is = typically done when a /32
  address is = configured on a loopback interface.

The above paragraph has to move to 6833bis.



  When ITRs receive ICMP Network Unreachable or = Host Unreachable
  messages as a method to = determine unreachability, they will refrain
  from= using Locators that are described in Locator lists of Map-
  Replies.  However, using this approach is = unreliable because many
  network operators turn = off generation of ICMP Destination Unreachable
  messages.


The above paragraph has to move to 6833bis.






  If an ITR does receive an ICMP Network = Unreachable or Host
  Unreachable message, it = MAY originate its own ICMP Destination
  Unreachable message destined for the host that = originated the data
  packet the ITR = encapsulated.


The= above paragraph has to move to 6833bis.





  Also, BGP-enabled ITRs can = unilaterally examine the RIB to see if a
  locator= address from a Locator-Set in a mapping entry matches a
  prefix.  If it does not find one and BGP is = running in the Default-
  Free Zone (DFZ), it = can decide to not use the Locator even though the
  Locator-Status-Bits indicate that the Locator is = up.  In this case,
  the path from the ITR = to the ETR that is assigned the Locator is not
  available.  More details are in = [I-D.meyer-loc-id-implications].


The above paragraph has to move to 6833bis.




  Optionally, an ITR can send a = Map-Request to a Locator, and if a Map-
  Reply = is returned, reachability of the Locator has been determined.
  Obviously, sending such probes increases the = number of control
  messages originated by = Tunnel Routers for active flows, so Locators
  are= assumed to be reachable when they are advertised.


The above paragraph has to move = to 6833bis.




  This = assumption does create a dependency: Locator unreachability is
  detected by the receipt of ICMP Host Unreachable = messages.  When a



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 26]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  Locator has been = determined to be unreachable, it is not used for
  active traffic; this is the same as if it were = listed in a Map-Reply
  with Priority 255.


The above = paragraph has to move to 6833bis.



  The ITR can = test the reachability of the unreachable Locator by
  sending periodic Requests.  Both Requests = and Replies MUST be rate-
  limited. =  Locator reachability testing is never done with data
  packets, since that increases the risk of packet = loss for end-to-end
  sessions.


The above paragraph has to move = to 6833bis.





  When an ETR decapsulates a packet, it knows that = it is reachable from
  the encapsulating ITR = because that is how the packet arrived.  In
  most cases, the ETR can also reach the ITR but = cannot assume this to
  be true, due to the = possibility of path asymmetry.  In the presence
  of unidirectional traffic flow from an ITR to an = ETR, the ITR SHOULD
  NOT use the lack of return = traffic as an indication that the ETR is
  unreachable.  Instead, it MUST use an = alternate mechanism to
  determine = reachability.

10.1.  Echo Nonce = Algorithm

  When data flows = bidirectionally between Locators from different
  sites, a data-plane mechanism called "nonce = echoing" can be used to
  determine reachability = between an ITR and ETR.  When an ITR wants to
  solicit a nonce echo, it sets the N- and E-bits = and places a 24-bit
  nonce [RFC4086] in the = LISP header of the next encapsulated data
  packet.

  When this packet is received by the ETR, the = encapsulated packet is
  forwarded as normal. =  When the ETR next sends a data packet to the
  ITR, it includes the nonce received earlier with = the N-bit set and
  E-bit cleared.  The ITR = sees this "echoed nonce" and knows that the
  path= to and from the ETR is up.

  The = ITR will set the E-bit and N-bit for every packet it sends while
  in the echo-nonce-request state.  The time = the ITR waits to process
  the echoed nonce = before it determines the path is unreachable is
  variable and is a choice left for the = implementation.

  If the ITR is = receiving packets from the ETR but does not see the
  nonce echoed while being in the = echo-nonce-request state, then the
  path to the = ETR is unreachable.  This decision may be overridden by
  other Locator reachability algorithms.  Once = the ITR determines that
  the path to the ETR is = down, it can switch to another Locator for
  that = EID-Prefix.





Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 27]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  Note that "ITR" and = "ETR" are relative terms here.  Both devices MUST
  be implementing both ITR and ETR functionality = for the echo nonce
  mechanism to operate.

  The ITR and ETR may both go into = the echo-nonce-request state at the
  same time. =  The number of packets sent or the time during which echo
  nonce requests are sent is an = implementation-specific setting.
  However, when = an ITR is in the echo-nonce-request state, it can echo
  the ETR's nonce in the next set of packets that = it encapsulates and
  subsequently continue = sending echo-nonce-request packets.

  This mechanism does not completely solve the = forward path
  reachability problem, as traffic = may be unidirectional.  That is, the
  ETR = receiving traffic at a site may not be the same device as an ITR
  that transmits traffic from that site, or the = site-to-site traffic is
  unidirectional so = there is no ITR returning traffic.

  The echo-nonce algorithm is bilateral.  That = is, if one side sets the
  E-bit and the other = side is not enabled for echo-noncing, then the
  echoing of the nonce does not occur and the = requesting side may
  erroneously consider the = Locator unreachable.  An ITR SHOULD only set
  the E-bit in an encapsulated data packet when it = knows the ETR is
  enabled for echo-noncing. =  This is conveyed by the E-bit in the RLOC-
  probe Map-Reply message.

  Note that other Locator reachability mechanisms = are being researched
  and can be used to = compliment or even override the echo nonce
  algorithm.  See the next section for an = example of control-plane
  probing.


Drop the last = paragraph about research.






10.2.  RLOC-Probing = Algorithm


This = whole section has to go to 6833bis.






  RLOC-Probing is a method that an ITR or PITR can = use to determine the
  reachability status of = one or more Locators that it has cached in a
  Map-Cache entry.  The probe-bit of the = Map-Request and Map-Reply
  messages is used for = RLOC-Probing.

  RLOC-Probing is = done in the control plane on a timer basis, where an
  ITR or PITR will originate a Map-Request destined = to a locator
  address from one of its own = locator addresses.  A Map-Request used as
  an RLOC-probe is NOT encapsulated and NOT sent to = a Map-Server or to
  the mapping database system = as one would when soliciting mapping
  data. =  The EID record encoded in the Map-Request is the EID-Prefix of
  the Map-Cache entry cached by the ITR or PITR. =  The ITR may include a
  mapping data = record for its own database mapping information that
  contains the local EID-Prefixes and RLOCs for its = site.  RLOC-probes
  are sent periodically = using a jittered timer interval.




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 28]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  When an ETR = receives a Map-Request message with the probe-bit set, it
  returns a Map-Reply with the probe-bit set. =  The source address of
  the Map-Reply is = set according to the procedure described in
  [I-D.ietf-lisp-rfc6833bis].  The Map-Reply = SHOULD contain mapping
  data for the EID-Prefix = contained in the Map-Request.  This provides
  the opportunity for the ITR or PITR that sent the = RLOC-probe to get
  mapping updates if there = were changes to the ETR's database mapping
  entries.

  There are advantages and disadvantages of = RLOC-Probing.  The greatest
  benefit of = RLOC-Probing is that it can handle many failure scenarios
  allowing the ITR to determine when the path to a = specific Locator is
  reachable or has become = unreachable, thus providing a robust
  mechanism = for switching to using another Locator from the cached
  Locator.  RLOC-Probing can also provide = rough Round-Trip Time (RTT)
  estimates between = a pair of Locators, which can be useful for network
  management purposes as well as for selecting low = delay paths.  The
  major disadvantage of = RLOC-Probing is in the number of control
  messages required and the amount of bandwidth = used to obtain those
  benefits, especially if = the requirement for failure detection times
  is = very small.

  Continued research = and testing will attempt to characterize the
  tradeoffs of failure detection times versus = message overhead.


Drop the last paragraph about research.



11.  EID Reachability within a LISP Site
  A site may be multihomed using two or more ETRs. =  The hosts and
  infrastructure within a = site will be addressed using one or more EID-
  Prefixes that are mapped to the RLOCs of the = relevant ETRs in the
  mapping system.  One = possible failure mode is for an ETR to lose
  reachability to one or more of the EID-Prefixes = within its own site.
  When this occurs when the = ETR sends Map-Replies, it can clear the
  R-bit = associated with its own Locator.  And when the ETR is also an
  ITR, it can clear its Locator-Status-Bit in the = encapsulation data
  header.

  It is recognized that there are no simple = solutions to the site
  partitioning problem = because it is hard to know which part of the
  EID-Prefix range is partitioned and which = Locators can reach any sub-
  ranges of the = EID-Prefixes.  This problem is under investigation with
  the expectation that experiments will tell us = more.

Drop the last sentence = about research.



 Note that this
  is not a new problem introduced by the LISP = architecture.  The
  problem exists today = when a multihomed site uses BGP to advertise its
  reachability upstream.





Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 29]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


12.  Routing Locator = Hashing

  When an ETR provides an = EID-to-RLOC mapping in a Map-Reply message to
  a = requesting ITR, the Locator-Set for the EID-Prefix may contain
  different Priority values for each locator = address.  When more than
  one best = Priority Locator exists, the ITR can decide how to load-
  share traffic against the corresponding = Locators.

The above paragraph = should not state where the mapping comes from, from the data plane = perspective it comes from the cache.

Also = where is weight???????




  The following hash algorithm may be used by an = ITR to select a
  Locator for a packet destined = to an EID for the EID-to-RLOC mapping:

  1.  Either a source and destination address = hash or the traditional
      5-tuple hash can be used. =  The traditional 5-tuple hash includes
      the source and = destination addresses; source and destination TCP,
      UDP, or Stream Control = Transmission Protocol (SCTP) port numbers;
      and the IP protocol = number field or IPv6 next-protocol fields of
      a packet that a host = originates from within a LISP site.  When a
      packet is not a TCP, UDP, = or SCTP packet, the source and
      destination addresses = only from the header are used to compute
      the hash.
  2.  Take the hash value and divide it by = the number of Locators
      stored in the Locator-Set = for the EID-to-RLOC mapping.

  3. =  The remainder will yield a value of 0 to "number of Locators
      minus 1".  Use the = remainder to select the Locator in the
      Locator-Set.

  Note that when a packet is LISP = encapsulated, the source port number
  in the = outer UDP header needs to be set.  Selecting a hashed value
  allows core routers that are attached to Link = Aggregation Groups
  (LAGs) to load-split the = encapsulated packets across member links of
  such= LAGs.  Otherwise, core routers would see a single flow, since
  packets have a source address of the ITR, for = packets that are
  originated by different EIDs = at the source site.  A suggested setting
  for the source port number computed by an ITR is = a 5-tuple hash
  function on the inner header, = as described above.

  Many core = router implementations use a 5-tuple hash to decide how to
  balance packet load across members of a LAG. =  The 5-tuple hash
  includes the source and = destination addresses of the packet and the
  source and destination ports when the protocol = number in the packet
  is TCP or UDP.  For = this reason, UDP encoding is used for LISP
  encapsulation.






Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 30]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


13.  Changing the Contents = of EID-to-RLOC Mappings


This is a control plane issue, as such it has to = go in 6833bis, with two exception:
The very first = paragraph stetting the problem, and the versioning subsection, because = it is a data-plane mechanism.

All of the = rest 6833bis

Actually I remember a = suggestion about putting operations issues like this in an OAM document = which would be a good idea. 





  Since the LISP architecture uses a caching scheme = to retrieve and
  store EID-to-RLOC mappings, = the only way an ITR can get a more up-to-
  date = mapping is to re-request the mapping.  However, the ITRs do not
  know when the mappings change, and the ETRs do = not keep track of
  which ITRs requested its = mappings.  For scalability reasons, it is
  desirable to maintain this approach but need to = provide a way for
  ETRs to change their = mappings and inform the sites that are currently
  communicating with the ETR site using such = mappings.

  When adding a new = Locator record in lexicographic order to the end of
  a Locator-Set, it is easy to update mappings. =  We assume that new
  mappings will = maintain the same Locator ordering as the old mapping
  but will just have new Locators appended to the = end of the list.  So,
  some ITRs can have = a new mapping while other ITRs have only an old
  mapping that is used until they time out. =  When an ITR has only an
  old mapping but = detects bits set in the Locator-Status-Bits that
  correspond to Locators beyond the list it has = cached, it simply
  ignores them.  However, = this can only happen for locator addresses
  that = are lexicographically greater than the locator addresses in the
  existing Locator-Set.

  When a Locator record is inserted in the middle = of a Locator-Set, to
  maintain lexicographic = order, the SMR procedure in Section 13.2 is
  used= to inform ITRs and PITRs of the new Locator-Status-Bit mappings.

  When a Locator record is removed = from a Locator-Set, ITRs that have
  the mapping = cached will not use the removed Locator because the xTRs
  will set the Locator-Status-Bit to 0.  So, = even if the Locator is in
  the list, it will = not be used.  For new mapping requests, the xTRs
  can set the Locator AFI to 0 (indicating an = unspecified address), as
  well as setting the = corresponding Locator-Status-Bit to 0.  This
  forces ITRs with old or new mappings to avoid = using the removed
  Locator.

  If many changes occur to a mapping over a long = period of time, one
  will find empty record = slots in the middle of the Locator-Set and new
  records appended to the Locator-Set. At some = point, it would be
  useful to compact the = Locator-Set so the Locator-Status-Bit settings
  can be efficiently packed.

  We propose here three approaches for Locator-Set = compaction: one
  operational mechanism and two = protocol mechanisms.  The operational
  approach uses a clock sweep method.  The = protocol approaches use the
  concept of = Solicit-Map-Requests and Map-Versioning.





Farinacci, et = al.         Expires May 15, 2018 =             &n= bsp;   [Page 31]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


13.1.  Clock = Sweep
  The clock sweep approach uses planning in = advance and the use of
  count-down TTLs to time = out mappings that have already been cached.
  The = default setting for an EID-to-RLOC mapping TTL is 24 hours.  So,
  there is a 24-hour window to time out old = mappings.  The following
  clock sweep = procedure is used:

  1.  24 = hours before a mapping change is to take effect, a network
      administrator configures = the ETRs at a site to start the clock
      sweep window.

  2.  During the clock sweep = window, ETRs continue to send Map-Reply
      messages with the current = (unchanged) mapping records.  The TTL
      for these mappings is set = to 1 hour.

  3.  24 hours = later, all previous cache entries will have timed out,
      and any active cache = entries will time out within 1 hour.  During
      this 1-hour window, the = ETRs continue to send Map-Reply messages
      with the current = (unchanged) mapping records with the TTL set to
      1 minute.
  4.  At the end of the 1-hour window, the = ETRs will send Map-Reply
      messages with the new = (changed) mapping records.  So, any active
      caches can get the new = mapping contents right away if not cached,
      or in 1 minute if they = had the mapping cached.  The new mappings
      are cached with a TTL = equal to the TTL in the Map-Reply.

13.2. =  Solicit-Map-Request (SMR)

  Soliciting a Map-Request is a selective way for = ETRs, at the site
  where mappings change, to = control the rate they receive requests for
  Map-Reply messages.  SMRs are also used to = tell remote ITRs to update
  the mappings they = have cached.

  Since the ETRs = don't keep track of remote ITRs that have cached their
  mappings, they do not know which ITRs need to = have their mappings
  updated.  As a = result, an ETR will solicit Map-Requests (called an
  SMR message) from those sites to which it has = been sending
  encapsulated data for the last = minute.  In particular, an ETR will
  send = an SMR to an ITR to which it has recently sent encapsulated
  data.  This can only occur when both ITR and = ETR functionality reside
  in the same = router.

  An SMR message is = simply a bit set in a Map-Request message.  An ITR
  or PITR will send a Map-Request when they receive = an SMR message.
  Both the SMR sender and the = Map-Request responder MUST rate-limit




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 32]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  these messages. =  Rate-limiting can be implemented as a global rate-
  limiter or one rate-limiter per SMR = destination.

  The following = procedure shows how an SMR exchange occurs when a site
  is doing Locator-Set compaction for an = EID-to-RLOC mapping:

  1. =  When the database mappings in an ETR change, the ETRs at the = site
      begin to send = Map-Requests with the SMR bit set for each Locator
      in each Map-Cache entry = the ETR caches.

  2.  A = remote ITR that receives the SMR message will schedule sending
      a Map-Request message to = the source locator address of the SMR
      message or to the mapping = database system.  A newly allocated
      random nonce is selected, = and the EID-Prefix used is the one
      copied from the SMR = message.  If the source Locator is the only
      Locator in the cached = Locator-Set, the remote ITR SHOULD send a
      Map-Request to the = database mapping system just in case the
      single Locator has = changed and may no longer be reachable to
      accept the = Map-Request.

  3.  The = remote ITR MUST rate-limit the Map-Request until it gets a
      Map-Reply while = continuing to use the cached mapping.  When
      Map-Versioning as = described in Section 13.3 is used, an SMR
      sender can detect if an = ITR is using the most up-to-date database
      mapping.

  4.  The ETRs at the site with the changed = mapping will reply to the
      Map-Request with a = Map-Reply message that has a nonce from the
      SMR-invoked Map-Request. =  The Map-Reply messages SHOULD be rate-
      limited.  This is = important to avoid Map-Reply implosion.

  5.  The ETRs at the site with the changed = mapping record the fact
      that the site that sent = the Map-Request has received the new
      mapping data in the = Map-Cache entry for the remote site so the
      Locator-Status-Bits are = reflective of the new mapping for packets
      going to the remote site. =  The ETR then stops sending SMR
      messages.
  For security reasons, an ITR MUST NOT process = unsolicited Map-
  Replies.  To avoid = Map-Cache entry corruption by a third party, a
  sender of an SMR-based Map-Request MUST be = verified.  If an ITR
  receives an = SMR-based Map-Request and the source is not in the
  Locator-Set for the stored Map-Cache entry, then = the responding Map-
  Request MUST be sent with = an EID destination to the mapping database
  system.  Since the mapping database system = is a more secure way to
  reach an authoritative = ETR, it will deliver the Map-Request to the
  authoritative source of the mapping data.




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 33]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  When an ITR = receives an SMR-based Map-Request for which it does not
  have a cached mapping for the EID in the SMR = message, it MAY not send
  an SMR-invoked = Map-Request.  This scenario can occur when an ETR
  sends SMR messages to all Locators in the = Locator-Set it has stored
  in its map-cache but = the remote ITRs that receive the SMR may not be
  sending packets to the site.  There is no = point in updating the ITRs
  until they need to = send, in which case they will send Map-Requests to
  obtain a Map-Cache entry.

13.3.  Database Map-Versioning

  When there is unidirectional packet flow between = an ITR and ETR, and
  the EID-to-RLOC mappings = change on the ETR, it needs to inform the
  ITR = so encapsulation to a removed Locator can stop and can instead be
  started to a new Locator in the Locator-Set.

  An ETR, when it sends Map-Reply = messages, conveys its own Map-Version
  Number. =  This is known as the Destination Map-Version Number.  ITRs
  include the Destination Map-Version Number in = packets they
  encapsulate to the site. =  When an ETR decapsulates a packet and
  detects that the Destination Map-Version Number = is less than the
  current version for its = mapping, the SMR procedure described in
  Section = 13.2 occurs.

  An ITR, when it = encapsulates packets to ETRs, can convey its own Map-
  Version Number.  This is known as the Source = Map-Version Number.
  When an ETR decapsulates a = packet and detects that the Source Map-
  Version = Number is greater than the last Map-Version Number sent in a
  Map-Reply from the ITR's site, the ETR will send = a Map-Request to one
  of the ETRs for the = source site.

  A Map-Version = Number is used as a sequence number per EID-Prefix, so
  values that are greater are considered to be more = recent.  A value of
  0 for the Source = Map-Version Number or the Destination Map-Version
  Number conveys no versioning information, and an = ITR does no
  comparison with previously = received Map-Version Numbers.

  A = Map-Version Number can be included in Map-Register messages as
  well.  This is a good way for the Map-Server = to assure that all ETRs
  for a site registering = to it will be synchronized according to Map-
  Version Number.

  See [RFC6834] for a more detailed analysis and = description of
  Database Map-Versioning.






Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 34]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


14.  Multicast = Considerations

  A multicast = group address, as defined in the original Internet
  architecture, is an identifier of a grouping of = topologically
  independent receiver host = locations.  The address encoding itself
  does not determine the location of the = receiver(s).  The multicast
  routing = protocol, and the network-based state the protocol creates,
  determine where the receivers are located.

  In the context of LISP, a = multicast group address is both an EID and
  a = Routing Locator.  Therefore, no specific semantic or action = needs
  to be taken for a destination address, = as it would appear in an IP
  header. =  Therefore, a group address that appears in an inner IP
  header built by a source host will be used as the = destination EID.
  The outer IP header (the = destination Routing Locator address),
  prepended = by a LISP router, can use the same group address as the
  destination Routing Locator, use a multicast or = unicast Routing
  Locator obtained from a = Mapping System lookup, or use other means to
  determine the group address mapping.

  With respect to the source Routing = Locator address, the ITR prepends
  its own IP = address as the source address of the outer IP header.
  Just like it would if the destination EID was a = unicast address.
  This source Routing Locator = address, like any other Routing Locator
  address,= MUST be globally routable.

  There= are two approaches for LISP-Multicast, one that uses native
  multicast routing in the underlay with no support = from the Mapping
  System and the other that = uses only unicast routing in the underlay
  with = support from the Mapping System.  See [RFC6831] and
  [I-D.ietf-lisp-signal-free-multicast], = respectively, for details.
  Details for = LISP-Multicast and interworking with non-LISP sites are
  described in [RFC6831] and [RFC6832].

15.  Router Performance Considerations

  LISP is designed to be very = "hardware-based forwarding friendly".  A
  few implementation techniques can be used to = incrementally implement
  LISP:

  o  When a tunnel-encapsulated packet is = received by an ETR, the outer
     destination address may not be = the address of the router.  This
     makes it challenging for the = control plane to get packets from the
     hardware.  This may be = mitigated by creating special Forwarding
     Information Base (FIB) entries = for the EID-Prefixes of EIDs served
     by the ETR (those for which the = router provides an RLOC
     translation).  These FIB = entries are marked with a flag indicating
     that control-plane processing = should be performed.  The forwarding


Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 35]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


     logic of testing for particular = IP protocol number values is not
     necessary.  There are a = few proven cases where no changes to
     existing deployed hardware were = needed to support the LISP data-
     plane.

  o  On an ITR, prepending a new IP header = consists of adding more
     octets= to a MAC rewrite string and prepending the string as part
     of the outgoing encapsulation = procedure.  Routers that support
     Generic Routing Encapsulation = (GRE) tunneling [RFC2784] or 6to4
     tunneling [RFC3056] may already = support this action.

  o  A = packet's source address or interface the packet was received on
     can be used to select VRF = (Virtual Routing/Forwarding).  The VRF's
     routing table can be used to = find EID-to-RLOC mappings.

  For = performance issues related to map-cache management, see
  Section 19.

16. =  Mobility Considerations

Move it out. Mobility is equivalent to mapping = change, it is a CP issue.

move it in an OAM = document.


  There are several kinds of = mobility, of which only some might be of
  concern= to LISP.  Essentially, they are as follows.

16.1.  Slow Mobility

  A site wishes to change its attachment points to = the Internet, and
  its LISP Tunnel Routers will = have new RLOCs when it changes upstream
  providers.  Changes in EID-to-RLOC mappings = for sites are expected to
  be handled by = configuration, outside of LISP.

  An individual endpoint wishes to move but is not = concerned about
  maintaining session = continuity.  Renumbering is involved.  LISP can
  help with the issues surrounding renumbering = [RFC4192] [LISA96] by
  decoupling the address = space used by a site from the address spaces
  used by its ISPs [RFC4984].

16.2.  Fast Mobility

  Fast endpoint mobility occurs when an endpoint = moves relatively
  rapidly, changing its = IP-layer network attachment point.  Maintenance
  of session continuity is a goal.  This is = where the Mobile IPv4
  [RFC5944] and Mobile = IPv6 [RFC6275] [RFC4866] mechanisms are used and
  primarily where interactions with LISP need to be = explored, such as
  the mechanisms in = [I-D.ietf-lisp-eid-mobility] when the EID moves but
  the RLOC is in the network infrastructure.

  In LISP, one possibility is to = "glean" information.  When a packet
  arrives, the ETR could examine the EID-to-RLOC = mapping and use that



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 36]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  mapping for all = outgoing traffic to that EID.  It can do this after
  performing a route-returnability check, to ensure = that the new
  network location does have an = internal route to that endpoint.
  However, this = does not cover the case where an ITR (the node assigned
  the RLOC) at the mobile-node location has been = compromised.

  Mobile IP packet = exchange is designed for an environment in which all
  routing information is disseminated before = packets can be forwarded.
  In order to allow = the Internet to grow to support expected future
  use, we are moving to an environment where some = information may have
  to be obtained after = packets are in flight.  Modifications to IP
  mobility should be considered in order to = optimize the behavior of
  the overall system. =  Anything that decreases the number of new EID-
  to-RLOC mappings needed when a node moves, or = maintains the validity
  of an EID-to-RLOC = mapping for a longer time, is useful.

  In addition to endpoints, a network can be = mobile, possibly changing
  xTRs.  A = "network" can be as small as a single router and as large as
  a whole site.  This is different from site = mobility in that it is
  fast and possibly = short-lived, but different from endpoint mobility
  in that a whole prefix is changing RLOCs. =  However, the mechanisms
  are the same, = and there is no new overhead in LISP.  A map request
  for any endpoint will return a binding for the = entire mobile prefix.

  If mobile = networks become a more common occurrence, it may be useful
  to revisit the design of the mapping service and = allow for dynamic
  updates of the database.

  The issue of interactions between = mobility and LISP needs to be
  explored = further.  Specific improvements to the entire system will
  depend on the details of mapping mechanisms. =  Mapping mechanisms
  should be evaluated = on how well they support session continuity for
  mobile nodes.  See = [I-D.ietf-lisp-predictive-rlocs] for more recent
  mechanisms which can provide near-zero packet = loss during handoffs.

16.3.  LISP = Mobile Node Mobility

  A mobile = device can use the LISP infrastructure to achieve mobility
  by implementing the LISP encapsulation and = decapsulation functions
  and acting as a simple = ITR/ETR.  By doing this, such a "LISP mobile
  node" can use topologically independent EID IP = addresses that are not
  advertised into and do = not impose a cost on the global routing
  system. =  These EIDs are maintained at the edges of the mapping system
  in LISP Map-Servers and Map-Resolvers) and are = provided on demand to
  only the correspondents = of the LISP mobile node.

  Refer = to [I-D.ietf-lisp-mn] for more details for when the EID and
  RLOC are co-located in the roaming node.



Farinacci, et = al.         Expires May 15, 2018 =             &n= bsp;   [Page 37]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


17.  LISP xTR Placement = and Encapsulation Methods

This = ia an OAM issue and has to be moved out of the document.





  This section will explore how and where ITRs and = ETRs can be placed
  in the network and will = discuss the pros and cons of each scenario.
  For = a more detailed networkd design deployment recommendation, refer
  to [RFC7215].

  There are two basic deployment tradeoffs to = consider: centralized
  versus distributed = caches; and flat, Recursive, or Re-encapsulating
  Tunneling.  When deciding on centralized = versus distributed caching,
  the following = issues should be considered:

  o =  Are the xTRs spread out so that the caches are spread across = all
     the memories of each = router?  A centralized cache is when an ITR
     keeps a cache for all the EIDs = it is encapsulating to.  The packet
     takes a direct path to the = destination Locator.  A distributed
     cache is when an ITR needs help = from other Re-Encapsulating Tunnel
     Routers (RTRs) because it does = not store all the cache entries for
     the EIDs it is encapsulating = to.  So, the packet takes a path
     through RTRs that have a = different set of cache entries.

  o=  Should management "touch points" be minimized by only choosing = a
     few xTRs, just enough for = redundancy?

  o  In general, = using more ITRs doesn't increase management load,
     since caches are built and = stored dynamically.  On the other hand,
     using more ETRs does require = more management, since EID-Prefix-to-
     RLOC mappings need to be = explicitly configured.

  When = deciding on flat, Recursive, or Re-Encapsulating Tunneling, the
  following issues should be considered:

  o  Flat tunneling implements = a single encapsulation path between the
     source site and destination = site.  This generally offers better
     paths between sources and = destinations with a single encapsulation
     path.

  o  Recursive Tunneling is when encapsulated = traffic is again further
     encapsulated in another tunnel, = either to implement VPNs or to
     perform Traffic Engineering. =  When doing VPN-based tunneling, the
     site has some control, since = the site is prepending a new
     encapsulation header.  In = the case of TE-based tunneling, the site
     may have control if it is = prepending a new tunnel header, but if
     the site's ISP is doing the TE, = then the site has no control.
     Recursive Tunneling generally = will result in suboptimal paths but
     with the benefit of steering = traffic to parts of the network that
     have more resources = available.




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 38]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  o  The = technique of Re-Encapsulation ensures that packets only
     require one encapsulation = header.  So, if a packet needs to be re-
     routed, it is first = decapsulated by the RTR and then Re-
     Encapsulated with a new = encapsulation header using a new RLOC.

  The next sub-sections will examine where xTRs and = RTRs can reside in
  the network.

17.1.  First-Hop/Last-Hop xTRs

  By locating xTRs close to hosts, = the EID-Prefix set is at the
  granularity of an = IP subnet.  So, at the expense of more EID-Prefix-
  to-RLOC sets for the site, the caches in each xTR = can remain
  relatively small.  But caches = always depend on the number of non-
  aggregated = EID destination flows active through these xTRs.

  With more xTRs doing encapsulation, the increase = in control traffic
  grows as well: since the = EID granularity is greater, more Map-
  Requests = and Map-Replies are traveling between more routers.

  The advantage of placing the caches and databases = at these stub
  routers is that the products = deployed in this part of the network
  have = better price-memory ratios than their core router counterparts.
  Memory is typically less expensive in these = devices, and fewer routes
  are stored (only IGP = routes).  These devices tend to have excess
  capacity, both for forwarding and routing = states.

  LISP functionality can = also be deployed in edge switches.  These
  devices generally have layer-2 ports facing hosts = and layer-3 ports
  facing the Internet. =  Spare capacity is also often available in these
  devices.

17.2. =  Border/Edge xTRs

  Using = Customer Edge (CE) routers for xTR placement allows the EID
  space associated with a site to be reachable via = a small set of RLOCs
  assigned to the CE-based = xTRs for that site.

  This offers = the opposite benefit of the first-hop/last-hop xTR
  scenario: the number of mapping entries and = network management touch
  points is reduced, = allowing better scaling.

  One = disadvantage is that fewer network resources are used to reach
  host endpoints, thereby centralizing the = point-of-failure domain and
  creating network = choke points at the CE xTR.

  Note = that more than one CE xTR at a site can be configured with the
  same IP address.  In this case, an RLOC is = an anycast address.  This



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 39]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  allows resilience = between the CE xTRs.  That is, if a CE xTR fails,
  traffic is automatically routed to the other xTRs = using the same
  anycast address.  However, = this comes with the disadvantage where the
  site = cannot control the entrance point when the anycast route is
  advertised out from all border routers. =  Another disadvantage of
  using anycast = Locators is the limited advertisement scope of /32 (or
  /128 for IPv6) routes.

17.3.  ISP Provider Edge (PE) xTRs

  The use of ISP PE routers as xTRs is not the = typical deployment
  scenario envisioned in this = specification.  This section attempts to
  capture some of the reasoning behind this = preference for implementing
  LISP on CE = routers.

  The use of ISP PE = routers for xTR placement gives an ISP, rather than
  a site, control over the location of the ETRs. =  That is, the ISP can
  decide whether the = xTRs are in the destination site (in either CE
  xTRs or last-hop xTRs within a site) or at other = PE edges.  The
  advantage of this case is = that two encapsulation headers can be
  avoided. =  By having the PE be the first router on the path to
  encapsulate, it can choose a TE path first, and = the ETR can
  decapsulate and Re-Encapsulate for = a new encapsuluation path to the
  destination = end site.

  An obvious = disadvantage is that the end site has no control over
  where its packets flow or over the RLOCs used. =  Other disadvantages
  include difficulty = in synchronizing path liveness updates between CE
  and PE routers.

  As mentioned in earlier sections, a combination = of these scenarios is
  possible at the expense = of extra packet header overhead; if both site
  and provider want control, then Recursive or = Re-Encapsulating Tunnels
  are used.

17.4.  LISP Functionality with = Conventional NATs

  LISP routers = can be deployed behind Network Address Translator (NAT)
  devices to provide the same set of packet = services hosts have today
  when they are = addressed out of private address space.

  It is important to note that a locator address in = any LISP control
  message MUST be a routable = address and therefore [RFC1918] addresses
  SHOULD= only be presence when running in a local environment.  When a
  LISP xTR is configured with private RLOC = addresses and resides behind
  a NAT device and = desires to communicate on the Internet, the private
  addresses MUST be used only in the outer IP = header so the NAT device
  can translate = properly.  Otherwise, EID addresses MUST be translated



Farinacci, et = al.         Expires May 15, 2018 =             &n= bsp;   [Page 40]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  before = encapsulation is performed when LISP VPNs are not in use.
  Both NAT translation and LISP encapsulation = functions could be co-
  located in the same = device.

17.5.  Packets Egressing a = LISP Site

  When a LISP site is = using two ITRs for redundancy, the failure of one
  ITR will likely shift outbound traffic to the = second.  This second
  ITR's cache may not = be populated with the same EID-to-RLOC mapping
  entries as the first.  If this second ITR = does not have these
  mappings, traffic will be = dropped while the mappings are retrieved
  from = the mapping system.  The retrieval of these messages may
  increase the load of requests being sent into the = mapping system.

18.  Traceroute = Considerations

I consider = traceroute again an OAM issue.


  When a = source host in a LISP site initiates a traceroute to a
  destination host in another LISP site, it is = highly desirable for it
  to see the entire = path.  Since packets are encapsulated from the ITR
  to the ETR, the hop across the tunnel could be = viewed as a single
  hop.  However, LISP = traceroute will provide the entire path so the
  user can see 3 distinct segments of the path from = a source LISP host
  to a destination LISP = host:

     Segment = 1 (in source LISP site based on EIDs):

         source = host ---> first hop ... next hop ---> ITR

     Segment 2 (in the core network = based on RLOCs):

         ITR = ---> next hop ... next hop ---> ETR

     Segment 3 (in the destination = LISP site based on EIDs):

         ETR = ---> next hop ... last hop ---> destination host

  For segment 1 of the path, ICMP Time Exceeded = messages are returned
  in the normal manner as = they are today.  The ITR performs a TTL
  decrement and tests for 0 before encapsulating. =  Therefore, the ITR's
  hop is seen by the = traceroute source as having an EID address (the
  address of the site-facing interface).

  For segment 2 of the path, ICMP = Time Exceeded messages are returned
  to the ITR = because the TTL decrement to 0 is done on the outer
  header, so the destinations of the ICMP messages = are the ITR RLOC
  address and the source RLOC = address of the encapsulated traceroute
  packet. =  The ITR looks inside of the ICMP payload to inspect the
  traceroute source so it can return the ICMP = message to the address of



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 41]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  the traceroute = client and also retain the core router IP address in
  the ICMP message.  This is so the traceroute = client can display the
  core router address = (the RLOC address) in the traceroute output.  The
  ETR returns its RLOC address and responds to the = TTL decrement to 0,
  as the previous core = routers did.

  For segment 3, the = next-hop router downstream from the ETR will be
  decrementing the TTL for the packet that was = encapsulated, sent into
  the core, decapsulated = by the ETR, and forwarded because it isn't the
  final destination.  If the TTL is = decremented to 0, any router on the
  path to = the destination of the traceroute, including the next-hop
  router or destination, will send an ICMP Time = Exceeded message to the
  source EID of the = traceroute client.  The ICMP message will be
  encapsulated by the local ITR and sent back to = the ETR in the
  originated traceroute source = site, where the packet will be delivered
  to = the host.

18.1.  IPv6 Traceroute

  IPv6 traceroute follows the = procedure described above, since the
  entire = traceroute data packet is included in the ICMP Time Exceeded
  message payload.  Therefore, only the ITR = needs to pay special
  attention to forwarding = ICMP messages back to the traceroute source.

18.2.  IPv4 Traceroute

  For IPv4 traceroute, we cannot follow the above = procedure, since IPv4
  ICMP Time Exceeded = messages only include the invoking IP header and
  8 octets that follow the IP header. =  Therefore, when a core router
  sends an = IPv4 Time Exceeded message to an ITR, all the ITR has in the
  ICMP payload is the encapsulated header it = prepended, followed by a
  UDP header.  The = original invoking IP header, and therefore the
  identity of the traceroute source, is lost.

  The solution we propose to solve = this problem is to cache traceroute
  IPv4 = headers in the ITR and to match them up with corresponding IPv4
  Time Exceeded messages received from core routers = and the ETR.  The
  ITR will use a circular = buffer for caching the IPv4 and UDP headers
  of = traceroute packets.  It will select a 16-bit number as a key to
  find them later when the IPv4 Time Exceeded = messages are received.
  When an ITR = encapsulates an IPv4 traceroute packet, it will use the
  16-bit number as the UDP source port in the = encapsulating header.
  When the ICMP Time = Exceeded message is returned to the ITR, the UDP
  header of the encapsulating header is present in = the ICMP payload,
  thereby allowing the ITR to = find the cached headers for the
  traceroute = source.  The ITR puts the cached headers in the payload
  and sends the ICMP Time Exceeded message to the = traceroute source
  retaining the source address = of the original ICMP Time Exceeded



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 42]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  message (a core = router or the ETR of the site of the traceroute
  destination).

  The signature of a traceroute packet comes in two = forms.  The first
  form is encoded as a = UDP message where the destination port is
  inspected for a range of values.  The second = form is encoded as an
  ICMP message where the = IP identification field is inspected for a
  well-known value.

18.3.  Traceroute Using Mixed Locators

  When either an IPv4 traceroute or IPv6 traceroute = is originated and
  the ITR encapsulates it in = the other address family header, one
  cannot = get all 3 segments of the traceroute.  Segment 2 of the
  traceroute cannot be conveyed to the traceroute = source, since it is
  expecting addresses from = intermediate hops in the same address format
  for= the type of traceroute it originated.  Therefore, in this case,
  segment 2 will make the tunnel look like one hop. =  All the ITR has to
  do to make this work = is to not copy the inner TTL to the outer,
  encapsulating header's TTL when a traceroute = packet is encapsulated
  using an RLOC from a = different address family.  This will cause no
  TTL decrement to 0 to occur in core routers = between the ITR and ETR.

19.  Security = Considerations

  Security = considerations for LISP are discussed in [RFC7833], in
  addition [I-D.ietf-lisp-sec] provides = authentication and integrity to
  LISP = mappings.

lisp-sec is = control-plane has to be referenced in 6833bis.


  A complete LISP threat analysis can be found in = [RFC7835], in what
  follows we provide a = summary.

  The optional = mechanisms of gleaning is offered to directly obtain a
  mapping from the LISP encapsulated packets. =  Specifically, an xTR can
  learn the = EID-to-RLOC mapping by inspecting the source RLOC and
  source EID of an encapsulated packet, and insert = this new mapping
  into its map-cache.  An = off-path attacker can spoof the source EID
  address to divert the traffic sent to the = victim's spoofed EID.  If
  the attacker = spoofs the source RLOC, it can mount a DoS attack by
  redirecting traffic to the spoofed victim;s RLOC, = potentially
  overloading it.

  The LISP Data-Plane defines several mechanisms to = monitor RLOC data-
  plane reachability, in this = context Locator-Status Bits, Nonce-
  Present = and Echo-Nonce bits of the LISP encapsulation header can be
  manipulated by an attacker to mount a DoS attack. =  An off-path
  attacker able to spoof the = RLOC of a victim's xTR can manipulate such
  mechanisms to declare a set of RLOCs unreachable. =  This can be used



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 43]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  also, for instance, = to declare only one RLOC reachable with the aim
  of overload it.

  Map-Versioning is a data-plane mechanism used to = signal a peering xTR
  that a local EID-to-RLOC = mapping has been updated, so that the
  peering = xTR uses LISP Control-Plane signaling message to retrieve a
  fresh mapping.  This can be used by an = attacker to forge the map-
  versioning field of = a LISP encapsulated header and force an excessive
  amount of signaling between xTRs that may = overload them.

  Most of the = attack vectors can be mitigated with careful deployment
  and configuration, information learned = opportunistically (such as LSB
  or gleaning) = should be verified with other reachability mechanisms.
  In addition, systematic rate-limitation and = filtering is an effective
  technique to = mitigate attacks that aim to overload the control-plane.
20.  Network Management Considerations

  Considerations for network management tools exist = so the LISP
  protocol suite can be = operationally managed.  These mechanisms can be
  found in [RFC7052] and [RFC6835].
21.  IANA Considerations

  This section provides guidance to the Internet = Assigned Numbers
  Authority (IANA) regarding = registration of values related to this
  data-plane LISP specification, in accordance with = BCP 26 [RFC5226].

21.1.  LISP UDP Port = Numbers

  The IANA registry has = allocated UDP port numbers 4341 and 4342 for
  lisp-data and lisp-control operation, = respectively.  IANA has updated
  the = description for UDP ports 4341 and 4342 as follows:

      lisp-data =      4341 udp    LISP Data = Packets
      lisp-control =   4342 udp    LISP Control Packets

4342 is control-plane and MUST be = requested to IANA in the 6833bis document.



22.  References

22.1.  Normative References

  [I-D.ietf-lisp-ddt]
          &nb= sp;  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
          &nb= sp;  Smirnov, "LISP Delegated Database Tree", = draft-ietf-lisp-
          &nb= sp;  ddt-09 (work in progress), January 2017.


Not normative. I don=E2=80=99t = need to know this document to implement the LISP data plane.






Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 44]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  [I-D.ietf-lisp-introduction]
          &nb= sp;  Cabellos-Aparicio, A. and D. Saucez, "An Architectural
          &nb= sp;  Introduction to the Locator/ID Separation Protocol
          &nb= sp;  (LISP)", draft-ietf-lisp-introduction-13 (work in
          &nb= sp;  progress), April 2015.


Not normative. I don=E2=80=99t need to know this = document to implement the LISP data plane.



  [I-D.ietf-lisp-rfc6833bis]
          &nb= sp;  Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
          &nb= sp;  "Locator/ID Separation Protocol (LISP) Control-Plane",
          &nb= sp;  draft-ietf-lisp-rfc6833bis-06 (work in progress), = October
          &nb= sp;  2017.

  [I-D.ietf-lisp-sec]
          &nb= sp;  Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
          &nb= sp;  Saucez, "LISP-Security (LISP-SEC)", = draft-ietf-lisp-sec-14
          &nb= sp;  (work in progress), October 2017.


Not normative. I don=E2=80=99t = need to know this document to implement the LISP data plane.




  [RFC0768]  Postel, J., "User = Datagram Protocol", STD 6, RFC 768,
          &nb= sp;  DOI 10.17487/RFC0768, August 1980,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc768
.

  [RFC0791] =  Postel, J., "Internet Protocol", STD 5, RFC 791,
          &nb= sp;  DOI 10.17487/RFC0791, September 1981,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc791
.

  [RFC1918] =  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
          &nb= sp;  and E. Lear, "Address Allocation for Private = Internets",
          &nb= sp;  BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc1918
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.





  [RFC2119] =  Bradner, S., "Key words for use in RFCs to Indicate
          &nb= sp;  Requirement Levels", BCP 14, RFC 2119,
          &nb= sp;  DOI 10.17487/RFC2119, March 1997,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc2119
.

  [RFC2404] =  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
          &nb= sp;  ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
          &nb= sp;  1998, <
https://www.rfc-editor.org/info/rfc2404
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.





  [RFC3168] =  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
          &nb= sp;  of Explicit Congestion Notification (ECN) to IP",
          &nb= sp;  RFC 3168, DOI 10.17487/RFC3168, September 2001,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc3168
.

  [RFC3232] =  Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
          &nb= sp;  by an On-line Database", RFC 3232, DOI = 10.17487/RFC3232,
          &nb= sp;  January 2002, <
https://www.rfc-editor.org/info/rfc3232
.



Not normative. I don=E2=80=99t need to know this = document to implement the LISP data plane.






Farinacci, = et al.         Expires May 15, = 2018 =             &n= bsp;   [Page 45]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  [RFC4086] =  Eastlake 3rd, D., Schiller, J., and S. Crocker,
          &nb= sp;  "Randomness Requirements for Security", BCP 106, RFC = 4086,
          &nb= sp;  DOI 10.17487/RFC4086, June 2005,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc4086
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.





  [RFC4632]  Fuller, V. and T. = Li, "Classless Inter-domain Routing
          &nb= sp;  (CIDR): The Internet Address Assignment and = Aggregation
          &nb= sp;  Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
          &nb= sp;  2006, <
https://www.rfc-editor.org/info/rfc4632
.

  [RFC4868] =  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
          &nb= sp;  384, and HMAC-SHA-512 with IPsec", RFC 4868,
          &nb= sp;  DOI 10.17487/RFC4868, May 2007,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc4868
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.





  [RFC5226]  Narten, T. and H. = Alvestrand, "Guidelines for Writing an
          &nb= sp;  IANA Considerations Section in RFCs", RFC 5226,
          &nb= sp;  DOI 10.17487/RFC5226, May 2008,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc5226
.

Not normative. I = don=E2=80=99t need to know this document to implement the LISP data = plane.





  [RFC5496]  Wijnands, IJ., Boers, A., and E. = Rosen, "The Reverse Path
          &nb= sp;  Forwarding (RPF) Vector TLV", RFC 5496,
          &nb= sp;  DOI 10.17487/RFC5496, March 2009,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc5496
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.




  [RFC5944]  Perkins, C., Ed., "IP Mobility = Support for IPv4, Revised",
          &nb= sp;  RFC 5944, DOI 10.17487/RFC5944, November 2010,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc5944
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.




  [RFC6115]  Li, T., Ed., "Recommendation for = a Routing Architecture",
          &nb= sp;  RFC 6115, DOI 10.17487/RFC6115, February 2011,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc6115
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.




  [RFC6275]  Perkins, C., Ed., Johnson, D., = and J. Arkko, "Mobility
          &nb= sp;  Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
          &nb= sp;  2011, <
https://www.rfc-editor.org/info/rfc6275
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.




  [RFC6834]  Iannone, L., Saucez, D., and O. = Bonaventure, "Locator/ID
          &nb= sp;  Separation Protocol (LISP) Map-Versioning", RFC 6834,
          &nb= sp;  DOI 10.17487/RFC6834, January 2013,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc6834
.

  [RFC6836] =  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
          &nb= sp;  "Locator/ID Separation Protocol Alternative Logical
          &nb= sp;  Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
          &nb= sp;  January 2013, <
https://www.rfc-editor.org/info/rfc6836
.



Not normative. I don=E2=80=99t need to know this = document to implement the LISP data plane.







Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 46]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  [RFC7052] =  Schudel, G., Jain, A., and V. Moreno, "Locator/ID
          &nb= sp;  Separation Protocol (LISP) MIB", RFC 7052,
          &nb= sp;  DOI 10.17487/RFC7052, October 2013,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc7052
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.




  [RFC7214]  Andersson, L. and C. Pignataro, = "Moving Generic Associated
          &nb= sp;  Channel (G-ACh) IANA Registries to a New Registry",
          &nb= sp;  RFC 7214, DOI 10.17487/RFC7214, May 2014,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc7214
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.




  [RFC7215]  Jakab, L., Cabellos-Aparicio, A., = Coras, F., Domingo-
          &nb= sp;  Pascual, J., and D. Lewis, "Locator/Identifier = Separation
          &nb= sp;  Protocol (LISP) Network Element Deployment
          &nb= sp;  Considerations", RFC 7215, DOI 10.17487/RFC7215, April
          &nb= sp;  2014, <
https://www.rfc-editor.org/info/rfc7215
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.
  [RFC7833]  Howlett, J., Hartman, S., and A. = Perez-Mendez, Ed., "A
          &nb= sp;  RADIUS Attribute, Binding, Profiles, Name Identifier
          &nb= sp;  Format, and Confirmation Methods for the Security
          &nb= sp;  Assertion Markup Language (SAML)", RFC 7833,
          &nb= sp;  DOI 10.17487/RFC7833, May 2016,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc7833
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.

  [RFC7835]  Saucez, D., Iannone, L., and O. = Bonaventure, "Locator/ID
          &nb= sp;  Separation Protocol (LISP) Threat Analysis", RFC 7835,
          &nb= sp;  DOI 10.17487/RFC7835, April 2016,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc7835
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.




  [RFC8061]  Farinacci, D. and B. Weis, = "Locator/ID Separation Protocol
          &nb= sp;  (LISP) Data-Plane Confidentiality", RFC 8061,
          &nb= sp;  DOI 10.17487/RFC8061, February 2017,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc8061
.


Not = normative. I don=E2=80=99t need to know this document to implement the = LISP data plane.




  [RFC8200]  Deering, S. and R. Hinden, = "Internet Protocol, Version 6
          &nb= sp;  (IPv6) Specification", STD 86, RFC 8200,
          &nb= sp;  DOI 10.17487/RFC8200, July 2017,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc8200
.



Please check as well the nits:

Checking nits according to https://www.ietf.org/id-info/checklist :
 ---------------------------------------------------------= -------------------

 ** The abstract = seems to contain references ([I-D.ietf-lisp-RFC6833bis]),
    which it shouldn't.  Please = replace those with straight textual mentions
    of the documents in question.


 Miscellaneous = warnings:
 ---------------------------------------------------------= -------------------

 -- The document = date (November 11, 2017) is 33 days in the past.  Is this
    intentional?


 Checking references for intended status: = Proposed Standard
 ---------------------------------------------------------= -------------------

    (See RFCs 3967 and 4897 for = information about using normative references
    to lower-maturity documents in = RFCs)

 =3D=3D Unused Reference: = 'RFC2404' is defined on line 2118, but no explicit
    reference was found in the text
    '[RFC2404]  Madson, C. and R. = Glenn, "The Use of HMAC-SHA-1-96 within...'

 =3D=3D Unused Reference: 'RFC4868' is defined on line = 2141, but no explicit
    reference = was found in the text
    '[RFC4868] =  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-3...'

 =3D=3D Unused Reference: 'RFC5496' is = defined on line 2151, but no explicit
    reference was found in the text
    '[RFC5496]  Wijnands, IJ., = Boers, A., and E. Rosen, "The Reverse Path...'

 =3D=3D Unused Reference: 'RFC6115' is defined on line = 2160, but no explicit
    reference = was found in the text
    '[RFC6115] =  Li, T., Ed., "Recommendation for a Routing Architecture",...'

 =3D=3D Unused Reference: 'RFC6836' is = defined on line 2173, but no explicit
    reference was found in the text
    '[RFC6836]  Fuller, V., = Farinacci, D., Meyer, D., and D. Lewis, "Loca...'

 =3D=3D Unused Reference: 'RFC7214' is defined on line = 2183, but no explicit
    reference = was found in the text
    '[RFC7214] =  Andersson, L. and C. Pignataro, "Moving Generic Associate...'

 =3D=3D Unused Reference: 'RFC4107' is = defined on line 2283, but no explicit
    reference was found in the text
    '[RFC4107]  Bellovin, S. and R. = Housley, "Guidelines for Cryptographi...'

 =3D=3D Unused Reference: 'RFC6480' is defined on line = 2302, but no explicit
    reference = was found in the text
    '[RFC6480] =  Lepinski, M. and S. Kent, "An Infrastructure to Support S...'

 =3D=3D Unused Reference: 'RFC6518' is = defined on line 2306, but no explicit
    reference was found in the text
    '[RFC6518]  Lebovitz, G. and M. = Bhatia, "Keying and Authentication fo...'

 =3D=3D Unused Reference: 'RFC6837' is defined on line = 2327, but no explicit
    reference = was found in the text
    '[RFC6837] =  Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Rout...'

 =3D=3D Outdated reference: = draft-ietf-lisp-ddt has been published as RFC 8111

 ** Downref: Normative reference to an Experimental = draft:
    draft-ietf-lisp-ddt (ref. = 'I-D.ietf-lisp-ddt')

 ** Downref: = Normative reference to an Informational draft:
    draft-ietf-lisp-introduction (ref. = 'I-D.ietf-lisp-introduction')

 ** = Downref: Normative reference to an Experimental draft:
    draft-ietf-lisp-sec (ref. = 'I-D.ietf-lisp-sec')

 ** Downref: = Normative reference to an Informational RFC: RFC 3232

 ** Obsolete normative reference: RFC 5226 (Obsoleted by = RFC 8126)

 ** Downref: Normative = reference to an Informational RFC: RFC 6115

 ** Downref: Normative reference to an Experimental RFC: = RFC 6834

 ** Downref: Normative = reference to an Experimental RFC: RFC 6836

 ** Downref: Normative reference to an Experimental RFC: = RFC 7052

 ** Downref: Normative = reference to an Experimental RFC: RFC 7215

 ** Downref: Normative reference to an Informational = RFC: RFC 7835

 ** Downref: Normative = reference to an Experimental RFC: RFC 8061

 =3D=3D Outdated reference: A later version (-01) exists = of
    draft-ietf-lisp-eid-mobility-00

 =3D=3D Outdated reference: A later = version (-01) exists of
    draft-ietf-lisp-predictive-rlocs-00

 =3D=3D Outdated reference: A later = version (-07) exists of
    draft-ietf-lisp-signal-free-multicast-0= 6

 =3D=3D Outdated reference: A later = version (-01) exists of
    draft-ietf-lisp-vpn-00


    Summary: = 13 errors (**), 0 flaws (~~), 15 warnings (=3D=3D), 1 comment (--).

---------------------------------------------------------------= --------------


22.2.  Informative References

  [AFN] =      IANA, "Address Family Numbers", August = 2016,
          &nb= sp;  <
http://www.iana.org/assignments/address-family-numbers
.

  [CHIAPPA] =  Chiappa, J., "Endpoints and Endpoint names: A Proposed",
          &nb= sp;  1999,
          &nb= sp;  <
http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt
.





Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 47]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  [I-D.ietf-lisp-eid-mobility]
          &nb= sp;  Portoles-Comeras, M., Ashtaputre, V., Moreno, V., = Maino,
          &nb= sp;  F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
          &nb= sp;  Unified Control Plane", = draft-ietf-lisp-eid-mobility-00
          &nb= sp;  (work in progress), May 2017.

  [I-D.ietf-lisp-mn]
          &nb= sp;  Farinacci, D., Lewis, D., Meyer, D., and C. White, = "LISP
          &nb= sp;  Mobile Node", draft-ietf-lisp-mn-01 (work in = progress),
          &nb= sp;  October 2017.

  [I-D.ietf-lisp-predictive-rlocs]
          &nb= sp;  Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
          &nb= sp;  RLOCs", draft-ietf-lisp-predictive-rlocs-00 (work in
          &nb= sp;  progress), June 2017.

  [I-D.ietf-lisp-signal-free-multicast]
          &nb= sp;  Moreno, V. and D. Farinacci, "Signal-Free LISP = Multicast",
          &nb= sp;  draft-ietf-lisp-signal-free-multicast-06 (work in
          &nb= sp;  progress), August 2017.

  [I-D.ietf-lisp-vpn]
          &nb= sp;  Moreno, V. and D. Farinacci, "LISP Virtual Private
          &nb= sp;  Networks (VPNs)", draft-ietf-lisp-vpn-00 (work in
          &nb= sp;  progress), May 2017.

  [I-D.meyer-loc-id-implications]
          &nb= sp;  Meyer, D. and D. Lewis, "Architectural Implications of
          &nb= sp;  Locator/ID Separation", = draft-meyer-loc-id-implications-01
          &nb= sp;  (work in progress), January 2009.

  [LISA96]   Lear, E., Tharp, D., = Katinsky, J., and J. Coffin,
          &nb= sp;  "Renumbering: Threat or Menace?", Usenix Tenth System
          &nb= sp;  Administration Conference (LISA 96), October 1996.

  [OPENLISP]
          &nb= sp;  Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
          &nb= sp;  Implementation Report", Work in Progress, July 2008.

  [RFC1034]  Mockapetris, P., = "Domain names - concepts and facilities",
          &nb= sp;  STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc1034
.

  [RFC2784] =  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
          &nb= sp;  Traina, "Generic Routing Encapsulation (GRE)", RFC = 2784,
          &nb= sp;  DOI 10.17487/RFC2784, March 2000,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc2784
.




Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 48]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  [RFC3056] =  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
          &nb= sp;  via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, = February
          &nb= sp;  2001, <
https://www.rfc-editor.org/info/rfc3056
.

  [RFC3261] =  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
          &nb= sp;  A., Peterson, J., Sparks, R., Handley, M., and E.
          &nb= sp;  Schooler, "SIP: Session Initiation Protocol", RFC = 3261,
          &nb= sp;  DOI 10.17487/RFC3261, June 2002,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc3261
.

  [RFC4107] =  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
          &nb= sp;  Key Management", BCP 107, RFC 4107, DOI = 10.17487/RFC4107,
          &nb= sp;  June 2005, <
https://www.rfc-editor.org/info/rfc4107
.

  [RFC4192] =  Baker, F., Lear, E., and R. Droms, "Procedures for
          &nb= sp;  Renumbering an IPv6 Network without a Flag Day", RFC = 4192,
          &nb= sp;  DOI 10.17487/RFC4192, September 2005,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc4192
.

  [RFC4866] =  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
          &nb= sp;  Optimization for Mobile IPv6", RFC 4866,
          &nb= sp;  DOI 10.17487/RFC4866, May 2007,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc4866
.

  [RFC4984] =  Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
          &nb= sp;  from the IAB Workshop on Routing and Addressing",
          &nb= sp;  RFC 4984, DOI 10.17487/RFC4984, September 2007,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc4984
.

  [RFC6480] =  Lepinski, M. and S. Kent, "An Infrastructure to Support
          &nb= sp;  Secure Internet Routing", RFC 6480, DOI = 10.17487/RFC6480,
          &nb= sp;  February 2012, <
https://www.rfc-editor.org/info/rfc6480
.

  [RFC6518] =  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
          &nb= sp;  Routing Protocols (KARP) Design Guidelines", RFC 6518,
          &nb= sp;  DOI 10.17487/RFC6518, February 2012,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc6518
.

  [RFC6831] =  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
          &nb= sp;  Locator/ID Separation Protocol (LISP) for Multicast
          &nb= sp;  Environments", RFC 6831, DOI 10.17487/RFC6831, January
          &nb= sp;  2013, <
https://www.rfc-editor.org/info/rfc6831
.

  [RFC6832] =  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
          &nb= sp;  "Interworking between Locator/ID Separation Protocol
          &nb= sp;  (LISP) and Non-LISP Sites", RFC 6832,
          &nb= sp;  DOI 10.17487/RFC6832, January 2013,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc6832
.



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 49]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  [RFC6835] =  Farinacci, D. and D. Meyer, "The Locator/ID Separation
          &nb= sp;  Protocol Internet Groper (LIG)", RFC 6835,
          &nb= sp;  DOI 10.17487/RFC6835, January 2013,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc6835
.

  [RFC6837]  Lear, = E., "NERD: A Not-so-novel Endpoint ID (EID) to
          &nb= sp;  Routing Locator (RLOC) Database", RFC 6837,
          &nb= sp;  DOI 10.17487/RFC6837, January 2013,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc6837
.

  [RFC6935] =  Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
          &nb= sp;  UDP Checksums for Tunneled Packets", RFC 6935,
          &nb= sp;  DOI 10.17487/RFC6935, April 2013,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc6935
.

  [RFC6936] =  Fairhurst, G. and M. Westerlund, "Applicability Statement
          &nb= sp;  for the Use of IPv6 UDP Datagrams with Zero = Checksums",
          &nb= sp;  RFC 6936, DOI 10.17487/RFC6936, April 2013,
          &nb= sp;  <
https://www.rfc-editor.org/info/rfc6936
.

  [RFC8060] =  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
          &nb= sp;  Address Format (LCAF)", RFC 8060, DOI = 10.17487/RFC8060,
          &nb= sp;  February 2017, <
https://www.rfc-editor.org/info/rfc8060
.

























Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 50]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


Appendix A. =  Acknowledgments

  An = initial thank you goes to Dave Oran for planting the seeds for the
  initial ideas for LISP.  His consultation = continues to provide value
  to the LISP = authors.

  A special and = appreciative thank you goes to Noel Chiappa for
  providing architectural impetus over the past = decades on separation
  of location and = identity, as well as detailed reviews of the LISP
  architecture and documents, coupled with = enthusiasm for making LISP a
  practical and = incremental transition for the Internet.

  The authors would like to gratefully acknowledge = many people who have
  contributed discussions = and ideas to the making of this proposal.
  They = include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
  Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay = Gill, Geoff Huston,
  David Conrad, Mark = Handley, Ron Bonica, Ted Seely, Mark Townsley,
  Chris Morrow, Brian Weis, Dave McGrew, Peter = Lothberg, Dave Thaler,
  Eliot Lear, Shane = Amante, Ved Kafle, Olivier Bonaventure, Luigi
  Iannone, Robin Whittle, Brian Carpenter, Joel = Halpern, Terry
  Manderson, Roger Jorgensen, Ran = Atkinson, Stig Venaas, Iljitsch van
  Beijnum, = Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien
  Saucez, Damian Lezama, Attilla De Groot, Parantap = Lahiri, David
  Black, Roque Gagliano, Isidor = Kouvelas, Jesper Skriver, Fred Templin,
  Margaret= Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari
  Arkko, Gregg Schudel, Srinivas Subramanian, Amit = Jain, Xu Xiaohu,
  Dhirendra Trivedi, Yakov = Rekhter, John Scudder, John Drake, Dimitri
  Papadimitriou, Ross Callon, Selina Heimlich, Job = Snijders, Vina
  Ermagan, Fabio Maino, Victor = Moreno, Chris White, Clarence Filsfils,
  Alia = Atlas, Florin Coras and Alberto Rodriguez.

  This work originated in the Routing Research = Group (RRG) of the IRTF.
  An individual = submission was converted into the IETF LISP working
  group document that became this RFC.

  The LISP working group would like = to give a special thanks to Jari
  Arkko, the = Internet Area AD at the time that the set of LISP
  documents were being prepared for IESG last call, = and for his
  meticulous reviews and detailed = commentaries on the 7 working group
  last call = documents progressing toward standards-track RFCs.

Appendix B.  Document Change Log

  [RFC Editor: Please delete this section on = publication as RFC.]







Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 51]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


B.1.  Changes to = draft-ietf-lisp-rfc6830bis-06

  o =  Posted November 2017.

  o =  Rephrase how Instance-IDs are used and don't refer to [RFC1918]
     addresses.

B.2.  Changes to draft-ietf-lisp-rfc6830bis-06

  o  Posted October 2017.

  o  Put RTR definition before = it is used.

  o  Rename = references that are now working group drafts.

  o  Remove "EIDs MUST NOT be used as used by = a host to refer to other
     hosts.  Note that EID = blocks MAY LISP RLOCs".

  o =  Indicate what address-family can appear in data packets.

  o  ETRs may, rather than = will, be the ones to send Map-Replies.

  o  Recommend, rather than mandate, max = encapsulation headers to 2.

  o =  Reference VPN draft when introducing Instance-ID.

  o  Indicate that SMRs can be sent when = ITR/ETR are in the same node.

  o =  Clarify when private addreses can be used.

B.3.  Changes to draft-ietf-lisp-rfc6830bis-05

  o  Posted August 2017.

  o  Make it clear that a = Reencapsulating Tunnel Router is an RTR.

B.4.=  Changes to draft-ietf-lisp-rfc6830bis-04

  o  Posted July 2017.

  o  Changed reference of IPv6 RFC2460 to = RFC8200.

  o  Indicate that = the applicability statement for UDP zero checksums
     over IPv6 adheres to = RFC6936.







Farinacci, et = al.         Expires May 15, 2018 =             &n= bsp;   [Page 52]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


B.5.  Changes to = draft-ietf-lisp-rfc6830bis-03

  o =  Posted May 2017.

  o =  Move the control-plane related codepoints in the IANA
     Considerations section to = RFC6833bis.

B.6.  Changes to = draft-ietf-lisp-rfc6830bis-02

  o =  Posted April 2017.

  o =  Reflect some editorial comments from Damien Sausez.

B.7.  Changes to = draft-ietf-lisp-rfc6830bis-01

  o =  Posted March 2017.

  o =  Include references to new RFCs published.

  o  Change references from RFC6833 to = RFC6833bis.

  o  Clarified = LCAF text in the IANA section.

  o =  Remove references to "experimental".

B.8.  Changes to draft-ietf-lisp-rfc6830bis-00

  o  Posted December 2016.

  o  Created working group = document from draft-farinacci-lisp
     -rfc6830-00 individual = submission.  No other changes made.

Authors' Addresses

  Dino Farinacci
  Cisco = Systems
  Tasman Drive
  San Jose, CA  95134
  USA


EMail: farinacci@gmail.com










Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 53]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


  Vince Fuller
  Cisco Systems
  Tasman = Drive
  San Jose, CA  95134
  USA


EMail: vince.fuller@gmail.com



  Dave Meyer
  Cisco Systems
  170 = Tasman Drive
  San Jose, CA
  USA


EMail: dmm@1-4-5.net



  Darrel Lewis
  Cisco Systems
  170 = Tasman Drive
  San Jose, CA
  USA


EMail: darlewis@cisco.com



  Albert Cabellos
  UPC/BarcelonaTech
  Campus = Nord, C. Jordi Girona 1-3
  Barcelona, = Catalunya
  Spain

EMail: acabello@ac.upc.edu
















Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 54]

= --Apple-Mail=_81CC5B0C-BEEE-411D-AE1C-B0B73CADA679-- From nobody Fri Dec 15 03:07:33 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ADE128768; Fri, 15 Dec 2017 03:07:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Luigi Iannone To: X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Cc: ggx@gigix.net, lisp-chairs@ietf.org, iesg-secretary@ietf.org, lisp@ietf.org, luigi.iannone@telecom-paristech.fr Message-ID: <151333605162.30443.15564407051004598251.idtracker@ietfa.amsl.com> Date: Fri, 15 Dec 2017 03:07:31 -0800 Archived-At: Subject: [lisp] Publication has been requested for draft-ietf-lisp-signal-free-multicast-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 11:07:31 -0000 Luigi Iannone has requested publication of draft-ietf-lisp-signal-free-multicast-07 as Experimental on behalf of the LISP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lisp-signal-free-multicast/ From nobody Fri Dec 15 08:17:34 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D231126C2F for ; Fri, 15 Dec 2017 08:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UFWE_sgvnbd for ; Fri, 15 Dec 2017 08:17:30 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB96124319 for ; Fri, 15 Dec 2017 08:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7258; q=dns/txt; s=iport; t=1513354650; x=1514564250; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=uPjkmC5jn5ducXrnE1PGdHcB6Mq/dYdDMy1hqNdX1S4=; b=icW/QoP9KCv4rK8gnJQ3aAa6NEDve2n387yfY0l0cF59xr0ApH+yrXM+ gJwOCuNYdhon54fpBKCB0sELfcr6Bcbo4o129jKlc+lXWvp9rLv9aSRe6 5Is3gaiQ20zmNcZPbfUbRRwhIfTz7m1dKS8krvsg5nXhB49wiyzFnRPky E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAQCB9DNa/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0J4QCd4kqjwiBWiaXIIIVChgLgTkBg14ChQA/GAEBAQE?= =?us-ascii?q?BAQEBAWsohSQBAQQBARsGDwEFNgsQCQIOCgICJgICJzAGDQYCAQEXig8QizWdb?= =?us-ascii?q?IInimEBAQEBAQEBAQEBAQEBAQEBAQEBARkFgQ+CWoIOgVaBaSkMgneBSYFlAYF?= =?us-ascii?q?HgzyCYwWTLoYuiVqHfo0tghaJfySHOIpKgk6JXYE7HzmBTzIaCBsVPIIpgl+CG?= =?us-ascii?q?CA3h32CSQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,405,1508803200"; d="scan'208";a="331012617" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2017 16:17:29 +0000 Received: from [10.24.20.170] ([10.24.20.170]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vBFGHSBN008412; Fri, 15 Dec 2017 16:17:28 GMT To: Luigi Iannone Cc: "Joel M. Halpern" , Dino Farinacci , "lisp@ietf.org" References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> <3702c899-5180-c1f8-758f-037207da0113@cisco.com> <679651E1-E520-43CB-8608-79926BA7660C@gigix.net> From: Fabio Maino Message-ID: <681e32cb-6961-f628-be2b-fd268999c400@cisco.com> Date: Fri, 15 Dec 2017 08:17:27 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <679651E1-E520-43CB-8608-79926BA7660C@gigix.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:17:33 -0000 Sounds good Luigi. I have just updated https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 that has now an intended status of standard track. We are ready for WG adoption. Thanks, Fabio On 12/15/17 1:08 AM, Luigi Iannone wrote: > >> On 14 Dec 2017, at 19:28, Fabio Maino wrote: >> >> On 12/14/17 10:11 AM, Joel M. Halpern wrote: >>> Let's separate things: >>> >>> 1) We can have a call for adoption of LISP GPE. Meetings are not special in terms of working group formal actions. >> agree. Doing it seems to be helpful whatever the WG decides to do with 6830bis. > That works for me. > >>> 2) My personal read is that if we assign the bit a meaning in 6830bis, then the reference has to be normative, as a reader seeking to understand the RFC would need to read the other document to know what the bit meant. (My thanks to Luigi for catching this.) >> Sounds reasonable, the reference should be normative then. >> >> Now, there are other drafts in the normative section: once GPE is adopted we would be in the same situation, and we could deal with it in the same way we do for the others. >> > That is not correct. As part of my review (Send it out later today) I have seen that a lot of references that are declared Normative are actually not at all so. > > The only Normative reference which is in draft status is 6833bis, which is a different matter. > > So the way to proceed is: > > Mark the bit reserved in 6830bis and say nothing. Nobody can allocate the bit without WG consensus, hence there is risk in proceeding this way. > > Adopt LISP-GPE which will be a self contained document allocating the bit. > > Ciao > > Luigi > > > >>> 2') I see no reason why the bit should be assigned in 6830bis. As long as we leave it reserved in 6830bis, LISP-GPE can assign it. That is what RFCs and registries are for. >> It would be helpful to document all the LISP dataplane features in 6830bis. I think this was one of the goals of having a dataplane document. >> >> Since we are so close, and there's consensus, if 1 and 2 above makes sense the WG could start the call for adoption of GPE asap. If that works the WG could then proceed with the last call for 6830bis. >> >> Fabio >> >> >>> So my personal preference would be to leave the protocol identification bit out of 6830bis. >>> >>> Yours, >>> Joel >>> >>> On 12/14/17 12:59 PM, Fabio Maino wrote: >>>> Since there seem to be consensus, can we ask for WG adoption of LISP-GPE and include it as an informative reference as the other drafts that are in 6830bis? >>>> >>>> Can the chairs open a call for adoption in the mailing list, or do we need to wait the next IETF? >>>> >>>> This might be similar to what Dino proposes below. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> On 12/14/17 9:01 AM, Dino Farinacci wrote: >>>>> I would prefer to not merge the two documents. Should we say in RFC6830bis that the R-bit is already allocated but don’t way why and make no reference. If no, I go for option A. >>>>> >>>>> Dino >>>>> >>>>>> On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >>>>>> >>>>>> His All, >>>>>> >>>>>> happy to see so much consensus :-) >>>>>> >>>>>> >>>>>> >>>>>> As a chair I have to point out that if you add text in 6830bis to allocate the last bit and refer to draft-lewis-lisp-gpe you are creating an authoritative dependency on a to a document that as for now is not even WG item. >>>>>> This will block the publication of 6830bis as RFC (remember the intro document…….). >>>>>> >>>>>> There are two possible solutions: >>>>>> >>>>>> A. 6830bis remains unchanged, leaving the P-bit marked as reserved for future use. draft-lewis-lisp-gpe will than allocate this last bit and detail the operations. >>>>>> >>>>>> B. We merge the two documents. >>>>>> >>>>>> I do not have a preference, up to the WG to decide, but better to avoid document dependencies that will block publication. >>>>>> >>>>>> >>>>>> >>>>>> Ciao >>>>>> >>>>>> L. >>>>>> >>>>>> >>>>>> >>>>>>> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>>>>>> >>>>>>> I would like to suggest a way to address mutiprotocol support in RFC6830bis, that may address what was discussed in Singapore. >>>>>>> This is based on using the last reserved bit in the LISP header as P bit to indicate support for multiprotocol encapsulation, as specified in the LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >>>>>>> The header, as specified in section 5.1, would look like: >>>>>>> >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> L |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol | >>>>>>> I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> S / | Instance ID/Locator-Status-Bits | >>>>>>> P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> >>>>>>> and the text in section 5.3 that reserves the 6th bit would be replaced by: >>>>>>> >>>>>>> P: The P-bit is the Next Protocol bit. When this bit is set to >>>>>>> 1, the V-bit MUST be set to 0 and the Nonce length, when used, is >>>>>>> limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details. >>>>>>> The P-bit is set to 1 to indicate the presence of the 8 bit Next >>>>>>> Protocol field encoded as: >>>>>>> >>>>>>> x x x 0 x 1 x x >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> |N|L|E|V|I|P|K|K| Nonce | Next-Protocol | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Instance ID/Locator-Status-Bits | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> >>>>>>> I will have to refresh the LISP-GPE draft, and reflect the allocations of the KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE to indicate OAM packets, but that same functionality can be done using the Next-Protocol field. >>>>>>> >>>>>>> The use of the P-bit is not compatible with the Map-Versioning feature, but an equivalent function can be specified (if needed) with a Next-Protocol shim header. I can add text to the LISP-GPE draft to reflect that. >>>>>>> >>>>>>> This would address the multiprotocol working item included in the current charter. >>>>>>> >>>>>>> I can very quickly update the LISP-GPE draft to reflect this, but I wanted to hear what the group thinks first. >>>>>>> >>>>>>> Thanks, >>>>>>> Fabio >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >> From nobody Fri Dec 15 08:23:24 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6671124205 for ; Fri, 15 Dec 2017 08:23:23 -0800 (PST) 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_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 QAdEpj88YX_d for ; Fri, 15 Dec 2017 08:23:22 -0800 (PST) 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 7BAC0120227 for ; Fri, 15 Dec 2017 08:23:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6215026AA40 for ; Fri, 15 Dec 2017 08:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1513355002; bh=1TwbJqqaq6s5uqxwGQ2OGLOCl34q3mbr+nCrMcKryhc=; h=Subject:References:To:From:Date:In-Reply-To:From; b=pCiB9gT1Or1vAqYKBL7Or3WFaA2jQ5XBAGG0U+W1+pcKx6WLlUq4V7Tq/0Ow7Z6pf lCG6ZRjRpbxYrmCSEDBgDgTk1Ay1zMOlajKMK3y9lzkUs22Wn8IW4tZgVRvUaUm8H/ GFFu/YZUsEZBy4iX263jpJqLEG11zloXmhtdJ9T0= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 0629026AA3C for ; Fri, 15 Dec 2017 08:23:21 -0800 (PST) References: <151335440470.30447.859080782552191016@ietfa.amsl.com> To: "lisp@ietf.org" From: Joel Halpern X-Forwarded-Message-Id: <151335440470.30447.859080782552191016@ietfa.amsl.com> Message-ID: <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> Date: Fri, 15 Dec 2017 11:23:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151335440470.30447.859080782552191016@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:23:24 -0000 The authors of the lisp-gpe draft (below) have requested working group adoption for this document. This email starts a two week last call for working group adoption of this document. Please respond, positively or negatively. Silence does NOT mean consent. Please include explanation / motivation / reasoning for your view. Also remember that this is not a last call. Once the document is adopted (assuming it is), we as a working group can make changes as needed. The primary quesitonin this call is whether this is a good basis for work we want to do. Thank you, Joel (& Luigi) -------- Forwarded Message -------- Subject: I-D Action: draft-lewis-lisp-gpe-04.txt Date: Fri, 15 Dec 2017 08:13:24 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LISP Generic Protocol Extension Authors : Darrel Lewis John Lemon Puneet Agarwal Larry Kreeger Paul Quinn Michael Smith Navindra Yadav Fabio Maino Filename : draft-lewis-lisp-gpe-04.txt Pages : 8 Date : 2017-12-15 Abstract: This draft describes extending the Locator/ID Separation Protocol (LISP), via changes to the LISP header, to support multi-protocol encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Dec 15 08:26:46 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF5A127241 for ; Fri, 15 Dec 2017 08:26:44 -0800 (PST) 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_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 L6OO_UxRCklI for ; Fri, 15 Dec 2017 08:26:42 -0800 (PST) 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 82B76120227 for ; Fri, 15 Dec 2017 08:26:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6B78826AA4D; Fri, 15 Dec 2017 08:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1513355202; bh=tNSUAPTYhjqxGqf7MWvJNqbho54Y6jZ5Btr4BmYv1gg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cRxGDpwx0BaBaL2l9k4qsoVvxDgaOiTw8DQDmkvY4x0t9MVYvZfHwGQ1f9vLkadjk PmZBX/ezPs5y3JQzfWwqI/O/Hgio6UbkC8ui6EhNEMMql+pGKQafGG0e6I8eNVUqjg wVakVQZjC8pp5hJfPB3m2TUjX+6kqIAW+7X9f3dQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 A524826AA5E; Fri, 15 Dec 2017 08:26:41 -0800 (PST) To: Fabio Maino Cc: Luigi Iannone , Dino Farinacci , "lisp@ietf.org" References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> <3702c899-5180-c1f8-758f-037207da0113@cisco.com> <679651E1-E520-43CB-8608-79926BA7660C@gigix.net> <681e32cb-6961-f628-be2b-fd268999c400@cisco.com> From: "Joel M. Halpern" Message-ID: <80565c27-aeeb-7995-8bfd-b8245847d648@joelhalpern.com> Date: Fri, 15 Dec 2017 11:26:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <681e32cb-6961-f628-be2b-fd268999c400@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:26:45 -0000 I have issued the adoption call. There is one obvious question that does not block adoption, but does block completion. Is there some way we can use a common registry for the next protocol field for this, vxlan gpe, and NSH? Yours, Joel On 12/15/17 11:17 AM, Fabio Maino wrote: > Sounds good Luigi. > > I have just updated https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 > that has now an intended status of standard track. > > We are ready for WG adoption. > > Thanks, > Fabio > > On 12/15/17 1:08 AM, Luigi Iannone wrote: >> >>> On 14 Dec 2017, at 19:28, Fabio Maino wrote: >>> >>> On 12/14/17 10:11 AM, Joel M. Halpern wrote: >>>> Let's separate things: >>>> >>>> 1) We can have a call for adoption of LISP GPE.  Meetings are not >>>> special in terms of working group formal actions. >>> agree. Doing it seems to be helpful whatever the WG decides to do >>> with 6830bis. >> That works for me. >> >>>> 2) My personal read is that if we assign the bit a meaning in >>>> 6830bis, then the reference has to be normative, as a reader seeking >>>> to understand the RFC would need to read the other document to know >>>> what the bit meant.  (My thanks to Luigi for catching this.) >>> Sounds reasonable, the reference should be normative then. >>> >>> Now, there are other drafts in the normative section: once GPE is >>> adopted we would be in the same situation, and we could deal with it >>> in the same way we do for the others. >>> >> That is not correct. As part of my review (Send it out later today) I >> have seen that a lot of references that are declared Normative are >> actually not at all so. >> >> The only Normative reference which is in draft status is 6833bis, >> which is a different matter. >> >> So the way to proceed is: >> >> Mark the bit reserved in 6830bis and say nothing. Nobody can allocate >> the bit without WG consensus, hence there is risk in proceeding this way. >> >> Adopt LISP-GPE which will be  a self contained document allocating the >> bit. >> >> Ciao >> >> Luigi >> >> >> >>>> 2') I see no reason why the bit should be assigned in 6830bis.  As >>>> long as we leave it reserved in 6830bis, LISP-GPE can assign it. >>>> That is what RFCs and registries are for. >>> It would be helpful to document all the LISP  dataplane features in >>> 6830bis. I think this  was one of the goals of having a dataplane >>> document. >>> >>> Since we are so close, and there's consensus, if 1 and 2 above makes >>> sense the WG could start the call for adoption of GPE asap. If that >>> works the WG could then proceed with the last call for 6830bis. >>> >>> Fabio >>> >>> >>>> So my personal preference would be to leave the protocol >>>> identification bit out of 6830bis. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/14/17 12:59 PM, Fabio Maino wrote: >>>>> Since there seem to be consensus, can we ask for WG adoption of >>>>> LISP-GPE and include it as an informative reference as the other >>>>> drafts that are in 6830bis? >>>>> >>>>> Can the chairs open a call for adoption in the mailing list, or do >>>>> we need to wait the next IETF? >>>>> >>>>> This might be similar to what Dino proposes below. >>>>> >>>>> Thanks, >>>>> Fabio >>>>> >>>>> On 12/14/17 9:01 AM, Dino Farinacci wrote: >>>>>> I would prefer to not merge the two documents. Should we say in >>>>>> RFC6830bis that the R-bit is already allocated but don’t way why >>>>>> and make no reference. If no, I go for option A. >>>>>> >>>>>> Dino >>>>>> >>>>>>> On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >>>>>>> >>>>>>> His All, >>>>>>> >>>>>>> happy to see so much consensus :-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> As a chair I have to point out that if you add text in 6830bis to >>>>>>> allocate the last bit and refer to draft-lewis-lisp-gpe you are >>>>>>> creating an authoritative dependency on a to a document that as >>>>>>> for now is not even WG item. >>>>>>> This will block the publication of 6830bis as RFC (remember the >>>>>>> intro document…….). >>>>>>> >>>>>>> There are two possible solutions: >>>>>>> >>>>>>> A. 6830bis remains unchanged, leaving the P-bit marked as >>>>>>> reserved for future use. draft-lewis-lisp-gpe will than allocate >>>>>>> this last bit and detail the operations. >>>>>>> >>>>>>> B. We merge the two documents. >>>>>>> >>>>>>> I do not have a preference, up to the WG to decide, but better to >>>>>>> avoid document dependencies that will block publication. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ciao >>>>>>> >>>>>>> L. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>>>>>>> >>>>>>>> I would like to suggest a way to address mutiprotocol support in >>>>>>>> RFC6830bis, that may address what was discussed in Singapore. >>>>>>>> This is based on using the last reserved bit in the LISP header >>>>>>>> as P bit to indicate support for multiprotocol encapsulation, as >>>>>>>> specified in the LISP-GPE draft >>>>>>>> (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >>>>>>>> The header, as specified in section 5.1, would look like: >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>      L   |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol    | >>>>>>>>      I \ >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>      S / |                 Instance >>>>>>>> ID/Locator-Status-Bits               | >>>>>>>>      P >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> >>>>>>>> >>>>>>>> and the text in section 5.3 that reserves the 6th bit would be >>>>>>>> replaced by: >>>>>>>> >>>>>>>>      P: The P-bit is the Next Protocol bit. When this bit is set to >>>>>>>>         1, the V-bit MUST be set to 0 and the Nonce length, when >>>>>>>> used, is >>>>>>>>         limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for >>>>>>>> more details. >>>>>>>>         The P-bit is set to 1 to indicate the presence of the 8 >>>>>>>> bit Next >>>>>>>>         Protocol field encoded as: >>>>>>>> >>>>>>>>        x x x 0 x 1 x x >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>       |N|L|E|V|I|P|K|K|           Nonce               | >>>>>>>> Next-Protocol | >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>       |                 Instance >>>>>>>> ID/Locator-Status-Bits               | >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> >>>>>>>> >>>>>>>> I will have to refresh the LISP-GPE draft, and reflect the >>>>>>>> allocations of the KK bits according to RFC8061 and Nonce. One >>>>>>>> of the K bits was used by LISP-GPE to indicate OAM packets, but >>>>>>>> that same functionality can be done using the Next-Protocol field. >>>>>>>> >>>>>>>> The use of the P-bit is not compatible with the Map-Versioning >>>>>>>> feature, but an equivalent function can be specified (if needed) >>>>>>>> with a Next-Protocol shim header. I can add text to the LISP-GPE >>>>>>>> draft to reflect that. >>>>>>>> >>>>>>>> This would address the multiprotocol working item included in >>>>>>>> the current charter. >>>>>>>> >>>>>>>> I can very quickly update the LISP-GPE draft to reflect this, >>>>>>>> but I wanted to hear what the group thinks first. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Fabio >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>> > From nobody Fri Dec 15 08:39:27 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EFC120227 for ; Fri, 15 Dec 2017 08:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrTmSf5jXEgm for ; Fri, 15 Dec 2017 08:39:23 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F00126C83 for ; Fri, 15 Dec 2017 08:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8844; q=dns/txt; s=iport; t=1513355962; x=1514565562; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=w2rENnj0JKN49eE+GFLKjOuoOZWdqorlHXcPpaFTw3A=; b=EV0EbwhO3qwp5DnczB/xcVF7WaWnV74HiJrSqZ7RVOTyL9VRXlsSqIZo kse/zhjf5rI0/dpuuMiCDXsnTf1bzg1pV1WWWUk7jlyY8vwLM8SnE1GLN NFKlVABtm8jwJeLGpIJOjD8Yf+HtOiTm7OypsIjOr5vud5heWfkbG6crm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyBAAl+jNa/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnhAJ3mDKBWiaXIIIVChgLgTkBg14ChQBAFwEBAQEBAQE?= =?us-ascii?q?BAWsohSQBAQQBARsGDwEFNgsQCQIYAgImAgInMAYNBgIBAReKDxCLOp1sgieKY?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBGQWBD4Jagg6BVoFpKQyCd4FJgWUBgUeDPIJ?= =?us-ascii?q?jBZMuhi6JWod+jS2CFol/JIc4ikqCToldgTshAzSBTzIaCBsVPIIpgl+CGCA3h?= =?us-ascii?q?32CSQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,405,1508803200"; d="scan'208";a="336470796" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 16:39:21 +0000 Received: from [10.24.20.170] ([10.24.20.170]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBFGdKkw003712; Fri, 15 Dec 2017 16:39:21 GMT To: "Joel M. Halpern" Cc: Luigi Iannone , Dino Farinacci , "lisp@ietf.org" References: <211ad1ba-b5fb-b0d5-7001-0f91e89691b7@cisco.com> <0E7372A3-8FB8-47A3-B8EC-72F998824EF2@gigix.net> <8cbe53a1-90ce-e373-dbca-649e5590e9b3@cisco.com> <3702c899-5180-c1f8-758f-037207da0113@cisco.com> <679651E1-E520-43CB-8608-79926BA7660C@gigix.net> <681e32cb-6961-f628-be2b-fd268999c400@cisco.com> <80565c27-aeeb-7995-8bfd-b8245847d648@joelhalpern.com> From: Fabio Maino Message-ID: <6ca1d6d7-7861-ea38-b12f-4cc6b22063e2@cisco.com> Date: Fri, 15 Dec 2017 08:39:20 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <80565c27-aeeb-7995-8bfd-b8245847d648@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] RFC6830bis and multiprotocol support X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:39:26 -0000 right. Up to now the authors of the related documents have made an effort to keep the Next Protocol registries aligned, but it would be nice to have a single registry for the three applications. Fabio On 12/15/17 8:26 AM, Joel M. Halpern wrote: > I have issued the adoption call. > > There is one obvious question that does not block adoption, but does > block completion.  Is there some way we can use a common registry for > the next protocol field for this, vxlan gpe, and NSH? > > Yours, > Joel > > On 12/15/17 11:17 AM, Fabio Maino wrote: >> Sounds good Luigi. >> >> I have just updated >> https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 that has now an >> intended status of standard track. >> >> We are ready for WG adoption. >> >> Thanks, >> Fabio >> >> On 12/15/17 1:08 AM, Luigi Iannone wrote: >>> >>>> On 14 Dec 2017, at 19:28, Fabio Maino wrote: >>>> >>>> On 12/14/17 10:11 AM, Joel M. Halpern wrote: >>>>> Let's separate things: >>>>> >>>>> 1) We can have a call for adoption of LISP GPE.  Meetings are not >>>>> special in terms of working group formal actions. >>>> agree. Doing it seems to be helpful whatever the WG decides to do >>>> with 6830bis. >>> That works for me. >>> >>>>> 2) My personal read is that if we assign the bit a meaning in >>>>> 6830bis, then the reference has to be normative, as a reader >>>>> seeking to understand the RFC would need to read the other >>>>> document to know what the bit meant.  (My thanks to Luigi for >>>>> catching this.) >>>> Sounds reasonable, the reference should be normative then. >>>> >>>> Now, there are other drafts in the normative section: once GPE is >>>> adopted we would be in the same situation, and we could deal with >>>> it in the same way we do for the others. >>>> >>> That is not correct. As part of my review (Send it out later today) >>> I have seen that a lot of references that are declared Normative are >>> actually not at all so. >>> >>> The only Normative reference which is in draft status is 6833bis, >>> which is a different matter. >>> >>> So the way to proceed is: >>> >>> Mark the bit reserved in 6830bis and say nothing. Nobody can >>> allocate the bit without WG consensus, hence there is risk in >>> proceeding this way. >>> >>> Adopt LISP-GPE which will be  a self contained document allocating >>> the bit. >>> >>> Ciao >>> >>> Luigi >>> >>> >>> >>>>> 2') I see no reason why the bit should be assigned in 6830bis.  As >>>>> long as we leave it reserved in 6830bis, LISP-GPE can assign it. >>>>> That is what RFCs and registries are for. >>>> It would be helpful to document all the LISP  dataplane features in >>>> 6830bis. I think this  was one of the goals of having a dataplane >>>> document. >>>> >>>> Since we are so close, and there's consensus, if 1 and 2 above >>>> makes sense the WG could start the call for adoption of GPE asap. >>>> If that works the WG could then proceed with the last call for >>>> 6830bis. >>>> >>>> Fabio >>>> >>>> >>>>> So my personal preference would be to leave the protocol >>>>> identification bit out of 6830bis. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 12/14/17 12:59 PM, Fabio Maino wrote: >>>>>> Since there seem to be consensus, can we ask for WG adoption of >>>>>> LISP-GPE and include it as an informative reference as the other >>>>>> drafts that are in 6830bis? >>>>>> >>>>>> Can the chairs open a call for adoption in the mailing list, or >>>>>> do we need to wait the next IETF? >>>>>> >>>>>> This might be similar to what Dino proposes below. >>>>>> >>>>>> Thanks, >>>>>> Fabio >>>>>> >>>>>> On 12/14/17 9:01 AM, Dino Farinacci wrote: >>>>>>> I would prefer to not merge the two documents. Should we say in >>>>>>> RFC6830bis that the R-bit is already allocated but don’t way why >>>>>>> and make no reference. If no, I go for option A. >>>>>>> >>>>>>> Dino >>>>>>> >>>>>>>> On Dec 14, 2017, at 2:58 AM, Luigi Iannone wrote: >>>>>>>> >>>>>>>> His All, >>>>>>>> >>>>>>>> happy to see so much consensus :-) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> As a chair I have to point out that if you add text in 6830bis >>>>>>>> to allocate the last bit and refer to draft-lewis-lisp-gpe you >>>>>>>> are creating an authoritative dependency on a to a document >>>>>>>> that as for now is not even WG item. >>>>>>>> This will block the publication of 6830bis as RFC (remember the >>>>>>>> intro document…….). >>>>>>>> >>>>>>>> There are two possible solutions: >>>>>>>> >>>>>>>> A. 6830bis remains unchanged, leaving the P-bit marked as >>>>>>>> reserved for future use. draft-lewis-lisp-gpe will than >>>>>>>> allocate this last bit and detail the operations. >>>>>>>> >>>>>>>> B. We merge the two documents. >>>>>>>> >>>>>>>> I do not have a preference, up to the WG to decide, but better >>>>>>>> to avoid document dependencies that will block publication. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ciao >>>>>>>> >>>>>>>> L. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 29 Nov 2017, at 23:32, Fabio Maino wrote: >>>>>>>>> >>>>>>>>> I would like to suggest a way to address mutiprotocol support >>>>>>>>> in RFC6830bis, that may address what was discussed in Singapore. >>>>>>>>> This is based on using the last reserved bit in the LISP >>>>>>>>> header as P bit to indicate support for multiprotocol >>>>>>>>> encapsulation, as specified in the LISP-GPE draft >>>>>>>>> (https://tools.ietf.org/html/draft-lewis-lisp-gpe). >>>>>>>>> The header, as specified in section 5.1, would look like: >>>>>>>>> >>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>      L   |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol    | >>>>>>>>>      I \ >>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>      S / |                 Instance >>>>>>>>> ID/Locator-Status-Bits               | >>>>>>>>>      P >>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>> >>>>>>>>> >>>>>>>>> and the text in section 5.3 that reserves the 6th bit would be >>>>>>>>> replaced by: >>>>>>>>> >>>>>>>>>      P: The P-bit is the Next Protocol bit. When this bit is >>>>>>>>> set to >>>>>>>>>         1, the V-bit MUST be set to 0 and the Nonce length, >>>>>>>>> when used, is >>>>>>>>>         limited to 16 bits. Refer to [draft-lewis-lisp-gpe] >>>>>>>>> for more details. >>>>>>>>>         The P-bit is set to 1 to indicate the presence of the >>>>>>>>> 8 bit Next >>>>>>>>>         Protocol field encoded as: >>>>>>>>> >>>>>>>>>        x x x 0 x 1 x x >>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>       |N|L|E|V|I|P|K|K| Nonce               | Next-Protocol | >>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>       |                 Instance >>>>>>>>> ID/Locator-Status-Bits               | >>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>> >>>>>>>>> >>>>>>>>> I will have to refresh the LISP-GPE draft, and reflect the >>>>>>>>> allocations of the KK bits according to RFC8061 and Nonce. One >>>>>>>>> of the K bits was used by LISP-GPE to indicate OAM packets, >>>>>>>>> but that same functionality can be done using the >>>>>>>>> Next-Protocol field. >>>>>>>>> >>>>>>>>> The use of the P-bit is not compatible with the Map-Versioning >>>>>>>>> feature, but an equivalent function can be specified (if >>>>>>>>> needed) with a Next-Protocol shim header. I can add text to >>>>>>>>> the LISP-GPE draft to reflect that. >>>>>>>>> >>>>>>>>> This would address the multiprotocol working item included in >>>>>>>>> the current charter. >>>>>>>>> >>>>>>>>> I can very quickly update the LISP-GPE draft to reflect this, >>>>>>>>> but I wanted to hear what the group thinks first. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Fabio >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> lisp mailing list >>>>>>>>> lisp@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >> From nobody Fri Dec 15 08:41:05 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8883126CC7 for ; Fri, 15 Dec 2017 08:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZKqyzT4Ceur for ; Fri, 15 Dec 2017 08:41:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CBF126C83 for ; Fri, 15 Dec 2017 08:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3723; q=dns/txt; s=iport; t=1513356061; x=1514565661; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=YFL8E4hEnk5oQyFccJjA0DlSsxCJsQj5gyyofv7kmys=; b=DmRECKQCG+KrUwtkaN1zfpVT9NrKDs8uRzAdsMOdNXw8wB+pY3rjG04p kRHhPekt8MJI0U3v4DK0H126VyIhkVkgP6mCja/FuaiN6xO7FFocPPas9 emtAU3PGW72LlGhvE0WqcUsdjMDpbntqNCKjlW/CqJc6kW7GXOSrt8WsY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAwAl+jNa/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnhAKZKYFaJpcgFIIBChgLhRgChQBAFwEBAQEBAQEBAWs?= =?us-ascii?q?ohSMBAQEEAQEbBg8BBTYbCQIRAwECAQICJgICJx8JCBMGAgEBBYohEIs6nWyCJ?= =?us-ascii?q?4piAQEBAQEBBAEBAQEBASKBD4Jagg6BVoFpKQyCd4MjCwEBF4EjARIBgzSCYwW?= =?us-ascii?q?TLpAIh36NLYIWY4Uwg2yHXI0Yf4hegTshAjVgbzIaCBsVGCSCKQmEbiA3AYgLg?= =?us-ascii?q?joBAQE?= X-IronPort-AV: E=Sophos;i="5.45,405,1508803200"; d="scan'208";a="336471534" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 16:41:00 +0000 Received: from [10.24.20.170] ([10.24.20.170]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vBFGf0qf017604 for ; Fri, 15 Dec 2017 16:41:00 GMT To: lisp@ietf.org References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> From: Fabio Maino Message-ID: <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> Date: Fri, 15 Dec 2017 08:40:59 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:41:04 -0000 As an author I support the adoption of this document. This simple LISP dataplane extension enables multiprotocol support in LISP. It allows use of LISP in L2 overlays, and introduces the capability to support dataplane extensions such as Network Service Header or Group Based Policy. This is bit-by-bit compatible with RFC6830bis and allows the use of Map-Versioning and Echo-Noncing, albeit with a reduced size of the corresponding dataplane metadata. An earlier version of the draft has been implemented in the FD.io (http://FD.io) and OOR (https://www.openoverlayrouter.org/) open source data plane implementations. Thanks, Fabio On 12/15/17 8:23 AM, Joel Halpern wrote: > The authors of the lisp-gpe draft (below) have requested working group > adoption for this document. > > This email starts a two week last call for working group adoption of > this document. > > Please respond, positively or negatively.  Silence does NOT mean > consent.  Please include explanation / motivation / reasoning for your > view. > > Also remember that this is not a last call.  Once the document is > adopted (assuming it is), we as a working group can make changes as > needed.  The primary quesitonin this call is whether this is a good > basis for work we want to do. > > Thank you, > Joel (& Luigi) > > > -------- Forwarded Message -------- > Subject: I-D Action: draft-lewis-lisp-gpe-04.txt > Date: Fri, 15 Dec 2017 08:13:24 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > >         Title           : LISP Generic Protocol Extension >         Authors         : Darrel Lewis >                           John Lemon >                           Puneet Agarwal >                           Larry Kreeger >                           Paul Quinn >                           Michael Smith >                           Navindra Yadav >                           Fabio Maino >     Filename        : draft-lewis-lisp-gpe-04.txt >     Pages           : 8 >     Date            : 2017-12-15 > > Abstract: >    This draft describes extending the Locator/ID Separation Protocol >    (LISP), via changes to the LISP header, to support multi-protocol >    encapsulation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 > https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Dec 15 08:53:22 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD8120227 for ; Fri, 15 Dec 2017 08:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYlaLKTotsiX for ; Fri, 15 Dec 2017 08:53:18 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044D9127241 for ; Fri, 15 Dec 2017 08:53:18 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id d16so20439764itj.1 for ; Fri, 15 Dec 2017 08:53:17 -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; bh=z4QMgdC1qhe72YIn5g/eXobJRRN/9BMPSRt6LNFLZUE=; b=mAep2rTfnqbmvlHwUYouRKWpjL6I7FJT9vEEeM3/iiN1HZ/PE25uwGoN4WW6Tr6d1P nLjmby+UGyQM7UOGOtzcbr3GLrvO4/658d8Lx4HEX6oFBWoQCSPqOdyj8AT4x0R1SY5X efxw3fM/RJapwCT8by79CnWLR+GKKzSpOaVIUEB0mo6HcbXTzuHXuurvLVcZy+YmilpG RhxE95z47Rm52faM6jiyYZj6+DdfLjoBMIcTZTEsEeR/yX8VDCRW32WDvtgm5jGrM8mt N56ZpLjqj5BsF8CJwGIW7p0r0lVeefX1/vxNTG5VDpUZhpI6Qa86h6FYzycSe0ilFSbp herA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=z4QMgdC1qhe72YIn5g/eXobJRRN/9BMPSRt6LNFLZUE=; b=azm9UlhTkQHgtjkaMNHuwjA+4LntlsxIN+Xc9BnVzadrFuli8ye4Xj0UustCXCmvDo SgRK+0T+VBZEpXX4gNcz/q4mDSHmwxiJtaoupTDNLw9AFKBWwgofVrd6W9CsAeUR2tPm DAA0FG6LFt7EqpSOmuY+2ONY8ryP4oOXVMl4UTajUPymWq3tAqaqWNNt5O0G5LO04NkT JTmOB4NEGaHzsUN62dCYe2SsA9EEViefFRhnwY/9d5qEXdHsl5veP6GGoGXieHGONCHG oNyI72iXkJG0HJuxpi+zbFnIEqcgQ3YXI5TDbftRkJla10Z7DNxYFq0MvIP+9OlUB2N/ bqiA== X-Gm-Message-State: AKGB3mIRMVS5GMg8dsWDdCfe8CvO4Qx9TajLDY1kQjwca7gHVY7Ik4Wr 4bjYA9i7AvdN0jcAlAnTBUsSReRIhwLLwFQI56tAnQ== X-Google-Smtp-Source: ACJfBouhWKcdfcsCO3QYA6Cqw+6cIVc17o7gvB/cpD73tHRocQfzM/uf/f0S/CCDcDM1G4RVjAOTNbLxLiOvwufoMRk= X-Received: by 10.107.168.41 with SMTP id r41mr12287077ioe.42.1513356796578; Fri, 15 Dec 2017 08:53:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.181.70 with HTTP; Fri, 15 Dec 2017 08:52:55 -0800 (PST) In-Reply-To: <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> From: Alberto Rodriguez-Natal Date: Fri, 15 Dec 2017 08:52:55 -0800 Message-ID: To: "lisp@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:53:20 -0000 I'm in favor of adoption. Several LISP implementation already support multiprotocol via this specification. I think it makes sense for the WG to take this document and make it advance aligned with the rest of the WG documents. Alberto On Fri, Dec 15, 2017 at 8:23 AM, Joel Halpern wrote: > The authors of the lisp-gpe draft (below) have requested working group > adoption for this document. > > This email starts a two week last call for working group adoption of this > document. > > Please respond, positively or negatively. Silence does NOT mean consent. > Please include explanation / motivation / reasoning for your view. > > Also remember that this is not a last call. Once the document is adopted > (assuming it is), we as a working group can make changes as needed. The > primary quesitonin this call is whether this is a good basis for work we > want to do. > > Thank you, > Joel (& Luigi) > > > -------- Forwarded Message -------- > Subject: I-D Action: draft-lewis-lisp-gpe-04.txt > Date: Fri, 15 Dec 2017 08:13:24 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : LISP Generic Protocol Extension > Authors : Darrel Lewis > John Lemon > Puneet Agarwal > Larry Kreeger > Paul Quinn > Michael Smith > Navindra Yadav > Fabio Maino > Filename : draft-lewis-lisp-gpe-04.txt > Pages : 8 > Date : 2017-12-15 > > Abstract: > This draft describes extending the Locator/ID Separation Protocol > (LISP), via changes to the LISP header, to support multi-protocol > encapsulation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 > https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Dec 15 08:53:25 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1D5120227 for ; Fri, 15 Dec 2017 08:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwRVwBldEOck for ; Fri, 15 Dec 2017 08:53:19 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD6B126C83 for ; Fri, 15 Dec 2017 08:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5608; q=dns/txt; s=iport; t=1513356798; x=1514566398; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=S4HOTzk9JFN4OSnohwlPUyc59cokkkLgzhy5p2TADGg=; b=JfF5lwutEOonjw6K8Szx1n8TDpdovIgmpbUKuUUNbp81MSI4Gg7PcNZd jMkMwXpnEyLlU04n5Ztm0HytdErXbnvHirchiIxjCigGYiwaopyurKFq3 8ObSiYY8CrVUeBGHhddxMAN9qmQ8cBH+oq5NoEPSbWskAYcAaR7enK80n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAADD/DNa/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPCIIAlyAUggEKGAuFGAIahGY/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQEEAQEbBhE6FwQCAQYCEQMBAQEBAgIjAwICAiULFAEICAIEARIIA?= =?us-ascii?q?YohEIsunWyCJ4pVAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPglqCDoFWgWmDLIM?= =?us-ascii?q?jCwEBF4EjARIBNoJ+gmMFozYCh3yNJIIfY4Uwi0iNGH+IMQIRGQGBOgEfOWBvb?= =?us-ascii?q?xUYJIIpCYRNeAGIC4ElgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,405,1508803200"; d="scan'208";a="44636945" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2017 16:53:18 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vBFGrHxX031036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 15 Dec 2017 16:53:17 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Dec 2017 10:53:17 -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.1320.000; Fri, 15 Dec 2017 10:53:17 -0600 From: "Frank Brockners (fbrockne)" To: "Fabio Maino (fmaino)" , "lisp@ietf.org" Thread-Topic: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt Thread-Index: AQHTdcENZg4bouTygUmj95xMwSXK0KNFAAuA//+evfA= Date: Fri, 15 Dec 2017 16:53:16 +0000 Message-ID: <49404db84cb54e749cbf8353e0808fff@XCH-RCD-008.cisco.com> References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> In-Reply-To: <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.69.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:53:21 -0000 KzENCg0KUmVnYXJkcywgRnJhbmsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGxpc3AgW21haWx0bzpsaXNwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGYWJpbyBN YWlubyAoZm1haW5vKQ0KU2VudDogRnJlaXRhZywgMTUuIERlemVtYmVyIDIwMTcgMDg6NDENClRv OiBsaXNwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2xpc3BdIEFkb3B0aW9uIGNhbGw6IGRyYWZ0 LWxld2lzLWxpc3AtZ3BlLTA0LnR4dA0KDQpBcyBhbiBhdXRob3IgSSBzdXBwb3J0IHRoZSBhZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQpUaGlzIHNpbXBsZSBMSVNQIGRhdGFwbGFuZSBleHRl bnNpb24gZW5hYmxlcyBtdWx0aXByb3RvY29sIHN1cHBvcnQgaW4gTElTUC4gSXQgYWxsb3dzIHVz ZSBvZiBMSVNQIGluIEwyIG92ZXJsYXlzLCBhbmQgaW50cm9kdWNlcyB0aGUgY2FwYWJpbGl0eSB0 byBzdXBwb3J0IGRhdGFwbGFuZSBleHRlbnNpb25zIHN1Y2ggYXMgTmV0d29yayBTZXJ2aWNlIEhl YWRlciBvciBHcm91cCBCYXNlZCBQb2xpY3kuDQoNClRoaXMgaXMgYml0LWJ5LWJpdCBjb21wYXRp YmxlIHdpdGggUkZDNjgzMGJpcyBhbmQgYWxsb3dzIHRoZSB1c2Ugb2YgTWFwLVZlcnNpb25pbmcg YW5kIEVjaG8tTm9uY2luZywgYWxiZWl0IHdpdGggYSByZWR1Y2VkIHNpemUgb2YgdGhlIGNvcnJl c3BvbmRpbmcgZGF0YXBsYW5lIG1ldGFkYXRhLg0KDQpBbiBlYXJsaWVyIHZlcnNpb24gb2YgdGhl IGRyYWZ0IGhhcyBiZWVuIGltcGxlbWVudGVkIGluIHRoZSBGRC5pbw0KKGh0dHA6Ly9GRC5pbykg YW5kIE9PUiAoaHR0cHM6Ly93d3cub3Blbm92ZXJsYXlyb3V0ZXIub3JnLykgb3BlbiBzb3VyY2Ug ZGF0YSBwbGFuZSBpbXBsZW1lbnRhdGlvbnMuDQoNClRoYW5rcywNCkZhYmlvDQoNCg0KDQpPbiAx Mi8xNS8xNyA4OjIzIEFNLCBKb2VsIEhhbHBlcm4gd3JvdGU6DQo+IFRoZSBhdXRob3JzIG9mIHRo ZSBsaXNwLWdwZSBkcmFmdCAoYmVsb3cpIGhhdmUgcmVxdWVzdGVkIHdvcmtpbmcgZ3JvdXAgDQo+ IGFkb3B0aW9uIGZvciB0aGlzIGRvY3VtZW50Lg0KPg0KPiBUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3 byB3ZWVrIGxhc3QgY2FsbCBmb3Igd29ya2luZyBncm91cCBhZG9wdGlvbiBvZiANCj4gdGhpcyBk b2N1bWVudC4NCj4NCj4gUGxlYXNlIHJlc3BvbmQsIHBvc2l0aXZlbHkgb3IgbmVnYXRpdmVseS7C oCBTaWxlbmNlIGRvZXMgTk9UIG1lYW4gDQo+IGNvbnNlbnQuwqAgUGxlYXNlIGluY2x1ZGUgZXhw bGFuYXRpb24gLyBtb3RpdmF0aW9uIC8gcmVhc29uaW5nIGZvciB5b3VyIA0KPiB2aWV3Lg0KPg0K PiBBbHNvIHJlbWVtYmVyIHRoYXQgdGhpcyBpcyBub3QgYSBsYXN0IGNhbGwuwqAgT25jZSB0aGUg ZG9jdW1lbnQgaXMgDQo+IGFkb3B0ZWQgKGFzc3VtaW5nIGl0IGlzKSwgd2UgYXMgYSB3b3JraW5n IGdyb3VwIGNhbiBtYWtlIGNoYW5nZXMgYXMgDQo+IG5lZWRlZC7CoCBUaGUgcHJpbWFyeSBxdWVz aXRvbmluIHRoaXMgY2FsbCBpcyB3aGV0aGVyIHRoaXMgaXMgYSBnb29kIA0KPiBiYXNpcyBmb3Ig d29yayB3ZSB3YW50IHRvIGRvLg0KPg0KPiBUaGFuayB5b3UsDQo+IEpvZWwgKCYgTHVpZ2kpDQo+ DQo+DQo+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+IFN1YmplY3Q6IEkt RCBBY3Rpb246IGRyYWZ0LWxld2lzLWxpc3AtZ3BlLTA0LnR4dA0KPiBEYXRlOiBGcmksIDE1IERl YyAyMDE3IDA4OjEzOjI0IC0wODAwDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K PiBSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFRvOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcNCj4NCj4NCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KPiBkaXJlY3Rvcmllcy4NCj4NCj4NCj4gwqDC oMKgwqDCoMKgwqAgVGl0bGXCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IExJU1AgR2VuZXJpYyBQcm90 b2NvbCBFeHRlbnNpb24NCj4gwqDCoMKgwqDCoMKgwqAgQXV0aG9yc8KgwqDCoMKgwqDCoMKgwqAg OiBEYXJyZWwgTGV3aXMNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgSm9obiBMZW1vbg0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBQdW5lZXQgQWdhcndhbA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBMYXJyeSBLcmVlZ2VyDQo+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFBhdWwgUXVpbm4NCj4g wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgTWljaGFl bCBTbWl0aA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBOYXZpbmRyYSBZYWRhdg0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBGYWJpbyBNYWlubw0KPiDCoMKgwqDCoEZpbGVuYW1lwqDCoMKgwqDC oMKgwqAgOiBkcmFmdC1sZXdpcy1saXNwLWdwZS0wNC50eHQNCj4gwqDCoMKgwqBQYWdlc8KgwqDC oMKgwqDCoMKgwqDCoMKgIDogOA0KPiDCoMKgwqDCoERhdGXCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDogMjAxNy0xMi0xNQ0KPg0KPiBBYnN0cmFjdDoNCj4gwqDCoCBUaGlzIGRyYWZ0IGRlc2NyaWJl cyBleHRlbmRpbmcgdGhlIExvY2F0b3IvSUQgU2VwYXJhdGlvbiBQcm90b2NvbA0KPiDCoMKgIChM SVNQKSwgdmlhIGNoYW5nZXMgdG8gdGhlIExJU1AgaGVhZGVyLCB0byBzdXBwb3J0IG11bHRpLXBy b3RvY29sDQo+IMKgwqAgZW5jYXBzdWxhdGlvbi4NCj4NCj4NCj4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWxld2lzLWxpc3AtZ3BlLw0KPg0KPiBUaGVyZSBhcmUgYWxzbyBo dG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1sZXdpcy1saXNwLWdwZS0wNA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWxld2lzLWxpc3AtZ3BlLTA0DQo+DQo+IEEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxld2lzLWxpc3AtZ3BlLTA0DQo+DQo+DQo+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IA0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgDQo+IHRvb2xzLmlldGYub3JnLg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gSS1ELUFubm91 bmNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1k LWFubm91bmNlDQo+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sIG9yIA0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNp dGVzLnR4dA0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBsaXNwIG1haWxpbmcgbGlzdA0KPiBsaXNwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpsaXNwIG1haWxpbmcgbGlzdA0KbGlzcEBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQo= From nobody Fri Dec 15 09:15:15 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092B0127B60 for ; Fri, 15 Dec 2017 09:15:14 -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, FREEMAIL_FROM=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 gKWiWSoEi-EZ for ; Fri, 15 Dec 2017 09:15:11 -0800 (PST) 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 A30B61200CF for ; Fri, 15 Dec 2017 09:15:11 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id c204so6561516pfc.13 for ; Fri, 15 Dec 2017 09:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7+buoUXaLf/Da1SsKr/hBHjLnMWO5TCSuuxkHVhFTto=; b=HfUMHeHu7DsL0PuLkDzSSVAYCpKRb2ZKESpv40IJorJMZZ7L236CPv6gH7Fyli1Tvn krqeUV13RcCcjvRp2Ddkutyv7wLhgYzrU7Yxwwufcg57eF4MXG3d40xByEM3CfmAJm33 pULtXUOosQc+pImWB2iLRjj1PVlq4HQKjoTkxJVWpbb5PKTpRsbvXPmQecwPrbWVdyj+ YQntwhtZv5Ha2HOcZyF4JZR0mfOfO1NnbPbzMcIc3YdybGL/VSwQoi0+oJmC3O7ecqwO 2uloBJxLiCDf8c2MBV1zpAQOe8b97v0OyCxieOZSsT8iA4zjYhZBvxVqdIyqYdxVHWNF apxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7+buoUXaLf/Da1SsKr/hBHjLnMWO5TCSuuxkHVhFTto=; b=UtjvaxdCOe09mrE5SpD02AVx63JhlrBfIo0tYZ896dL1ss8b3RJ6+zAU6IwLqaVE73 S1L3bBsmUF3cZGgpCglE8QGwWvCvHwGWz6D7FDKvy4YVXsEcpML9rhC4pKregaBRQPo9 YzndX6pFbcy0lWSjbJpWPDIrx3YqJP4yvy0pZhK0LZeT1/eoGEDpDvip6xzX3I7qecCd hQxW3b8CS/5RPRxvYKuIdHW4QdrwCFayF8d2Tg1OjBqgtbwv/1nTWDT8xNqo3k2Rd8JW nTr7WGM28pP1cPvwnjPOUvzl3rSHV+TWIlYMkOWZSrao6jBLsOyOorQUOrZct0/revil aCnQ== X-Gm-Message-State: AKGB3mLrAm6oVSSZtp39hi0y/JROjtF35xSHCuPbAMDVBOeTVYoVggjN PRDT4cetJCB7ewisn3ffT8c= X-Google-Smtp-Source: ACJfBotoeUE6clHvKxdNkZ1lRLaqGM1QvqcMgbfPiW3sOvBB6DcN1tn7gHIYrXcwlA0kbdo/PYfCow== X-Received: by 10.84.160.227 with SMTP id v32mr9389730plg.184.1513358111006; Fri, 15 Dec 2017 09:15:11 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1004::111? ([2001:420:c0c8:1004::111]) by smtp.gmail.com with ESMTPSA id n12sm14281211pfb.5.2017.12.15.09.15.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 09:15:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Florin Coras In-Reply-To: <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> Date: Fri, 15 Dec 2017 09:15:08 -0800 Cc: lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 17:15:14 -0000 +1 Florin > On Dec 15, 2017, at 8:40 AM, Fabio Maino wrote: >=20 > As an author I support the adoption of this document. >=20 > This simple LISP dataplane extension enables multiprotocol support in = LISP. It allows use of LISP in L2 overlays, and introduces the = capability to support dataplane extensions such as Network Service = Header or Group Based Policy. >=20 > This is bit-by-bit compatible with RFC6830bis and allows the use of = Map-Versioning and Echo-Noncing, albeit with a reduced size of the = corresponding dataplane metadata. >=20 > An earlier version of the draft has been implemented in the FD.io = (http://FD.io) and OOR (https://www.openoverlayrouter.org/) open source = data plane implementations. >=20 > Thanks, > Fabio >=20 >=20 >=20 > On 12/15/17 8:23 AM, Joel Halpern wrote: >> The authors of the lisp-gpe draft (below) have requested working = group adoption for this document. >>=20 >> This email starts a two week last call for working group adoption of = this document. >>=20 >> Please respond, positively or negatively. Silence does NOT mean = consent. Please include explanation / motivation / reasoning for your = view. >>=20 >> Also remember that this is not a last call. Once the document is = adopted (assuming it is), we as a working group can make changes as = needed. The primary quesitonin this call is whether this is a good = basis for work we want to do. >>=20 >> Thank you, >> Joel (& Luigi) >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-lewis-lisp-gpe-04.txt >> Date: Fri, 15 Dec 2017 08:13:24 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : LISP Generic Protocol Extension >> Authors : Darrel Lewis >> John Lemon >> Puneet Agarwal >> Larry Kreeger >> Paul Quinn >> Michael Smith >> Navindra Yadav >> Fabio Maino >> Filename : draft-lewis-lisp-gpe-04.txt >> Pages : 8 >> Date : 2017-12-15 >>=20 >> Abstract: >> This draft describes extending the Locator/ID Separation Protocol >> (LISP), via changes to the LISP header, to support multi-protocol >> encapsulation. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 >> https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-lewis-lisp-gpe-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Dec 15 10:07:26 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197E61273B1 for ; Fri, 15 Dec 2017 10:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X6a7Z30PEqD for ; Fri, 15 Dec 2017 10:07:23 -0800 (PST) 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 D17AA12706D for ; Fri, 15 Dec 2017 10:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6094; q=dns/txt; s=iport; t=1513361242; x=1514570842; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iWCKhsLV6VK0PkKpB6PZ1NPtFcqnCP7NkHPd1Lvajnw=; b=N7llI9ByMyds/MXUklucPwwUS4oogsU06PI3xazYISmRHhKHby4bNq6u 3qYYZCWGm5lZpUiwHD/0rMXZvRTVQbayR4SUT3e4W75IFaKgj961CSZli XEo+AWoSy1WV+mFi0EX4eH0EgLPb+Vfx4GaH+0DLZUief6nYwY4gIwkVX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAAArDjRa/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPCIIAiQGOHxSCAQoYC4UYAhqEZj8YAQEBAQE?= =?us-ascii?q?BAQEBayiFIwEBAQMBAQEbBhE6CxACAQgOAwMBAgECAiYCAgIfBgEKFAEICAIEA?= =?us-ascii?q?Q0FCYoJAw0IEKkUgieHOQ2DJgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4Jagg6?= =?us-ascii?q?BVoFpKYMDgmo5CwEBF4EjARIBNoJ+MYIyBZlciR09Aod8hxuBFIR+ghZjhTCLS?= =?us-ascii?q?I0YPkGIMQIRGQGBOgEfOWBvbxUYJCoBgX4JhE14AYgTgSUBgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,406,1508803200"; d="scan'208";a="45320279" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 18:07:22 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vBFI7LnL012195 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Dec 2017 18:07:21 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Dec 2017 12:07:21 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Fri, 15 Dec 2017 12:07:21 -0600 From: "Reshad Rahman (rrahman)" To: Florin Coras , "Fabio Maino (fmaino)" CC: "lisp@ietf.org" Thread-Topic: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt Thread-Index: AQHTdcEWjDhesuyU4kKl3Yz6CyeU96NFAAuAgAAJiwCAAA6aAA== Date: Fri, 15 Dec 2017 18:07:21 +0000 Message-ID: References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.57] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 18:07:25 -0000 SW4gZmF2b3VyLg0KDQoNCk9uIDIwMTctMTItMTUsIDEyOjE1IFBNLCAibGlzcCBvbiBiZWhhbGYg b2YgRmxvcmluIENvcmFzIiA8bGlzcC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBmY29y YXMubGlzdHNAZ21haWwuY29tPiB3cm90ZToNCg0KICAgICsxDQogICAgDQogICAgRmxvcmluDQog ICAgDQogICAgPiBPbiBEZWMgMTUsIDIwMTcsIGF0IDg6NDAgQU0sIEZhYmlvIE1haW5vIDxmbWFp bm9AY2lzY28uY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gQXMgYW4gYXV0aG9yIEkgc3VwcG9y dCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudC4NCiAgICA+IA0KICAgID4gVGhpcyBzaW1w bGUgTElTUCBkYXRhcGxhbmUgZXh0ZW5zaW9uIGVuYWJsZXMgbXVsdGlwcm90b2NvbCBzdXBwb3J0 IGluIExJU1AuIEl0IGFsbG93cyB1c2Ugb2YgTElTUCBpbiBMMiBvdmVybGF5cywgYW5kIGludHJv ZHVjZXMgdGhlIGNhcGFiaWxpdHkgdG8gc3VwcG9ydCBkYXRhcGxhbmUgZXh0ZW5zaW9ucyBzdWNo IGFzIE5ldHdvcmsgU2VydmljZSBIZWFkZXIgb3IgR3JvdXAgQmFzZWQgUG9saWN5Lg0KICAgID4g DQogICAgPiBUaGlzIGlzIGJpdC1ieS1iaXQgY29tcGF0aWJsZSB3aXRoIFJGQzY4MzBiaXMgYW5k IGFsbG93cyB0aGUgdXNlIG9mIE1hcC1WZXJzaW9uaW5nIGFuZCBFY2hvLU5vbmNpbmcsIGFsYmVp dCB3aXRoIGEgcmVkdWNlZCBzaXplIG9mIHRoZSBjb3JyZXNwb25kaW5nIGRhdGFwbGFuZSBtZXRh ZGF0YS4NCiAgICA+IA0KICAgID4gQW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBoYXMg YmVlbiBpbXBsZW1lbnRlZCBpbiB0aGUgRkQuaW8gKGh0dHA6Ly9GRC5pbykgYW5kIE9PUiAoaHR0 cHM6Ly93d3cub3Blbm92ZXJsYXlyb3V0ZXIub3JnLykgb3BlbiBzb3VyY2UgZGF0YSBwbGFuZSBp bXBsZW1lbnRhdGlvbnMuDQogICAgPiANCiAgICA+IFRoYW5rcywNCiAgICA+IEZhYmlvDQogICAg PiANCiAgICA+IA0KICAgID4gDQogICAgPiBPbiAxMi8xNS8xNyA4OjIzIEFNLCBKb2VsIEhhbHBl cm4gd3JvdGU6DQogICAgPj4gVGhlIGF1dGhvcnMgb2YgdGhlIGxpc3AtZ3BlIGRyYWZ0IChiZWxv dykgaGF2ZSByZXF1ZXN0ZWQgd29ya2luZyBncm91cCBhZG9wdGlvbiBmb3IgdGhpcyBkb2N1bWVu dC4NCiAgICA+PiANCiAgICA+PiBUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3byB3ZWVrIGxhc3QgY2Fs bCBmb3Igd29ya2luZyBncm91cCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KICAgID4+IA0K ICAgID4+IFBsZWFzZSByZXNwb25kLCBwb3NpdGl2ZWx5IG9yIG5lZ2F0aXZlbHkuICBTaWxlbmNl IGRvZXMgTk9UIG1lYW4gY29uc2VudC4gIFBsZWFzZSBpbmNsdWRlIGV4cGxhbmF0aW9uIC8gbW90 aXZhdGlvbiAvIHJlYXNvbmluZyBmb3IgeW91ciB2aWV3Lg0KICAgID4+IA0KICAgID4+IEFsc28g cmVtZW1iZXIgdGhhdCB0aGlzIGlzIG5vdCBhIGxhc3QgY2FsbC4gIE9uY2UgdGhlIGRvY3VtZW50 IGlzIGFkb3B0ZWQgKGFzc3VtaW5nIGl0IGlzKSwgd2UgYXMgYSB3b3JraW5nIGdyb3VwIGNhbiBt YWtlIGNoYW5nZXMgYXMgbmVlZGVkLiAgVGhlIHByaW1hcnkgcXVlc2l0b25pbiB0aGlzIGNhbGwg aXMgd2hldGhlciB0aGlzIGlzIGEgZ29vZCBiYXNpcyBmb3Igd29yayB3ZSB3YW50IHRvIGRvLg0K ICAgID4+IA0KICAgID4+IFRoYW5rIHlvdSwNCiAgICA+PiBKb2VsICgmIEx1aWdpKQ0KICAgID4+ IA0KICAgID4+IA0KICAgID4+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQog ICAgPj4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtbGV3aXMtbGlzcC1ncGUtMDQudHh0DQog ICAgPj4gRGF0ZTogRnJpLCAxNSBEZWMgMjAxNyAwODoxMzoyNCAtMDgwMA0KICAgID4+IEZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KICAgID4+IFJlcGx5LVRvOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcNCiAgICA+PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQogICAgPj4gDQog ICAgPj4gDQogICAgPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgID4+IA0KICAgID4+IA0K ICAgID4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogTElTUCBHZW5lcmljIFByb3RvY29sIEV4 dGVuc2lvbg0KICAgID4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRGFycmVsIExld2lzDQog ICAgPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBKb2huIExlbW9uDQogICAgPj4gICAgICAg ICAgICAgICAgICAgICAgICAgICBQdW5lZXQgQWdhcndhbA0KICAgID4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgTGFycnkgS3JlZWdlcg0KICAgID4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgUGF1bCBRdWlubg0KICAgID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljaGFlbCBT bWl0aA0KICAgID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTmF2aW5kcmEgWWFkYXYNCiAg ICA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEZhYmlvIE1haW5vDQogICAgPj4gICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWxld2lzLWxpc3AtZ3BlLTA0LnR4dA0KICAgID4+ICAgICBQ YWdlcyAgICAgICAgICAgOiA4DQogICAgPj4gICAgIERhdGUgICAgICAgICAgICA6IDIwMTctMTIt MTUNCiAgICA+PiANCiAgICA+PiBBYnN0cmFjdDoNCiAgICA+PiAgICBUaGlzIGRyYWZ0IGRlc2Ny aWJlcyBleHRlbmRpbmcgdGhlIExvY2F0b3IvSUQgU2VwYXJhdGlvbiBQcm90b2NvbA0KICAgID4+ ICAgIChMSVNQKSwgdmlhIGNoYW5nZXMgdG8gdGhlIExJU1AgaGVhZGVyLCB0byBzdXBwb3J0IG11 bHRpLXByb3RvY29sDQogICAgPj4gICAgZW5jYXBzdWxhdGlvbi4NCiAgICA+PiANCiAgICA+PiAN CiAgICA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCiAgICA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZXdpcy1s aXNwLWdwZS8NCiAgICA+PiANCiAgICA+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6DQogICAgPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWxld2lzLWxpc3AtZ3BlLTA0DQogICAgPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1sZXdpcy1saXNwLWdwZS0wNA0KICAgID4+IA0KICAgID4+IEEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGV3aXMtbGlzcC1ncGUtMDQNCiAgICA+ PiANCiAgICA+PiANCiAgICA+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgPj4gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCiAgICA+PiANCiAgICA+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQogICAgPj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCiAgICA+PiANCiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgID4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCiAgICA+PiBJ LUQtQW5ub3VuY2VAaWV0Zi5vcmcNCiAgICA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KICAgID4+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVz OiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQogICAgPj4gb3IgZnRwOi8vZnRwLmll dGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCiAgICA+PiANCiAgICA+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+IGxpc3AgbWFpbGlu ZyBsaXN0DQogICAgPj4gbGlzcEBpZXRmLm9yZw0KICAgID4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbGlzcA0KICAgID4gDQogICAgPiANCiAgICA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBsaXNwIG1haWxpbmcg bGlzdA0KICAgID4gbGlzcEBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9saXNwDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICBsaXNwIG1haWxpbmcgbGlzdA0KICAgIGxpc3BAaWV0 Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCiAg ICANCg0K From nobody Fri Dec 15 10:08:37 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9690412940C for ; Fri, 15 Dec 2017 10:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 f_coJflnEbMI for ; Fri, 15 Dec 2017 10:08:32 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 98DFB1273B1 for ; Fri, 15 Dec 2017 10:08:31 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vBFI8U7a010732 for ; Fri, 15 Dec 2017 19:08:30 +0100 Received: from [192.168.1.5] (137.red-88-18-119.staticip.rima-tde.net [88.18.119.137]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 900E5132 for ; Fri, 15 Dec 2017 19:08:24 +0100 (CET) To: lisp@ietf.org References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9?= Message-ID: Date: Fri, 15 Dec 2017 19:08:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 18:08:35 -0000 +1 Jordi El 15/12/2017 a les 18:15, Florin Coras ha escrit: > +1 > > Florin > >> On Dec 15, 2017, at 8:40 AM, Fabio Maino wrote: >> >> As an author I support the adoption of this document. >> >> This simple LISP dataplane extension enables multiprotocol support in LISP. It allows use of LISP in L2 overlays, and introduces the capability to support dataplane extensions such as Network Service Header or Group Based Policy. >> >> This is bit-by-bit compatible with RFC6830bis and allows the use of Map-Versioning and Echo-Noncing, albeit with a reduced size of the corresponding dataplane metadata. >> >> An earlier version of the draft has been implemented in the FD.io (http://FD.io) and OOR (https://www.openoverlayrouter.org/) open source data plane implementations. >> >> Thanks, >> Fabio >> >> >> >> On 12/15/17 8:23 AM, Joel Halpern wrote: >>> The authors of the lisp-gpe draft (below) have requested working group adoption for this document. >>> >>> This email starts a two week last call for working group adoption of this document. >>> >>> Please respond, positively or negatively. Silence does NOT mean consent. Please include explanation / motivation / reasoning for your view. >>> >>> Also remember that this is not a last call. Once the document is adopted (assuming it is), we as a working group can make changes as needed. The primary quesitonin this call is whether this is a good basis for work we want to do. >>> >>> Thank you, >>> Joel (& Luigi) >>> >>> >>> -------- Forwarded Message -------- >>> Subject: I-D Action: draft-lewis-lisp-gpe-04.txt >>> Date: Fri, 15 Dec 2017 08:13:24 -0800 >>> From: internet-drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : LISP Generic Protocol Extension >>> Authors : Darrel Lewis >>> John Lemon >>> Puneet Agarwal >>> Larry Kreeger >>> Paul Quinn >>> Michael Smith >>> Navindra Yadav >>> Fabio Maino >>> Filename : draft-lewis-lisp-gpe-04.txt >>> Pages : 8 >>> Date : 2017-12-15 >>> >>> Abstract: >>> This draft describes extending the Locator/ID Separation Protocol >>> (LISP), via changes to the LISP header, to support multi-protocol >>> encapsulation. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 >>> https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-04 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Dec 15 10:22:54 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE00128B27 for ; Fri, 15 Dec 2017 10:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq2K7_Y_T76d for ; Fri, 15 Dec 2017 10:22:51 -0800 (PST) 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 4B0C5127077 for ; Fri, 15 Dec 2017 10:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2909; q=dns/txt; s=iport; t=1513362171; x=1514571771; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P1wfSVq1KzRC1rKAvzrHpO94VkO219vEjhNUy/L3B6g=; b=Sx/xYOxe9D+OmYUQdlQEenK7MMYMyWonQALFt/AembdVO5WLsWOaV995 8oDWhReJy19ZxWxn65t8Azhqpr+Tl8B2iC213/hV/NGHhRBNtLyG7bUsf 5szmBs0Fiy+sezhG7Fy162lWnkTy42UY03CI1/htrTbaMOrIiNP7zGoUA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAABhEjRa/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnjiOPCIIAlyAUggEKGAuFGAKFAD8YAQEBAQEBAQEBayi?= =?us-ascii?q?FIwEBAQMBAQEbHTQLBQsCAQgOAwMBAgEeECcLFAkIAgQOBQmKGQgQqz6KbAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2DaYIOgVaBaSmDA4MjCwEBF4EjARIBHzKDFII?= =?us-ascii?q?yBaM2Aod8jS2CFmOFMItIjRh/iDECERkBgToBHzlgb28VGCQqAYF+CYRNeAGIE?= =?us-ascii?q?4I6AQEB?= X-IronPort-AV: E=Sophos;i="5.45,406,1508803200"; d="scan'208";a="335886872" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 18:22:49 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBFIMnKJ003782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Dec 2017 18:22:49 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Dec 2017 12:22:49 -0600 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1320.000; Fri, 15 Dec 2017 12:22:49 -0600 From: "Vina Ermagan (vermagan)" To: Joel Halpern CC: "lisp@ietf.org" Thread-Topic: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt Thread-Index: AQHTdcEXwfMN1Py/90+iRDDvjmhzTqNEt+r7 Date: Fri, 15 Dec 2017 18:22:49 +0000 Message-ID: <64E8E1EE-BA2A-4BDC-8A37-52B7A641140A@cisco.com> References: <151335440470.30447.859080782552191016@ietfa.amsl.com>, <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> In-Reply-To: <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 18:22:53 -0000 +1 on adoption.=20 Best, Vina > On Dec 15, 2017, at 8:23 AM, Joel Halpern wrote: >=20 > The authors of the lisp-gpe draft (below) have requested working group ad= option for this document. >=20 > This email starts a two week last call for working group adoption of this= document. >=20 > Please respond, positively or negatively. Silence does NOT mean consent.= Please include explanation / motivation / reasoning for your view. >=20 > Also remember that this is not a last call. Once the document is adopted= (assuming it is), we as a working group can make changes as needed. The p= rimary quesitonin this call is whether this is a good basis for work we wan= t to do. >=20 > Thank you, > Joel (& Luigi) >=20 >=20 > -------- Forwarded Message -------- > Subject: I-D Action: draft-lewis-lisp-gpe-04.txt > Date: Fri, 15 Dec 2017 08:13:24 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : LISP Generic Protocol Extension > Authors : Darrel Lewis > John Lemon > Puneet Agarwal > Larry Kreeger > Paul Quinn > Michael Smith > Navindra Yadav > Fabio Maino > Filename : draft-lewis-lisp-gpe-04.txt > Pages : 8 > Date : 2017-12-15 >=20 > Abstract: > This draft describes extending the Locator/ID Separation Protocol > (LISP), via changes to the LISP header, to support multi-protocol > encapsulation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 > https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-lewis-lisp-gpe-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Dec 15 10:23:42 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04F12871F for ; Fri, 15 Dec 2017 10:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiBRBwfJROvl for ; Fri, 15 Dec 2017 10:23:39 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B78B127077 for ; Fri, 15 Dec 2017 10:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3233; q=dns/txt; s=iport; t=1513362219; x=1514571819; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aL4xw+mcddf1TWUnm0YRCTDugpbkPCeYvBSXOubYDtI=; b=VfEMOwFnbiA8xNf4yxBcRk9AvWyFcTzFoTBtHq9DBFXh8Kzy5tcqImoO KZsogQ/X9NYK9TzAzH2oF+NgVRcJxROPtKsVM+qM74SauMlJ1e+wXj1TS XY4V+JP9W8qXGeYCWbs5eB+Ari/0fCNjEdXkLrjUUdP2WQrv7sFeluOVz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAAAqEjRa/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQUEweOHI8IggCXIBSCAQoYC4UYAoUAPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUjAQEBAwEBARsdNAsFCwIBCBEDAQIBHhAnCxQJCAIEDgUJihkIEKs9imwBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdg2mCDoFWgWkpgwODIwsBAReBIwESAR8ygxS?= =?us-ascii?q?CMgWjNgKHfI0tghZjhTCLSI0Yf4gxAhEZAYE6AR85YG9vFRgkKgGBfgmETXgBi?= =?us-ascii?q?BOBJYEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,406,1508803200"; d="scan'208";a="45195675" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2017 18:23:38 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBFINcle025476 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Dec 2017 18:23:38 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Dec 2017 12:23:37 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1320.000; Fri, 15 Dec 2017 12:23:37 -0600 From: "Johnson Leong (joleong)" To: "Vina Ermagan (vermagan)" CC: Joel Halpern , "lisp@ietf.org" Thread-Topic: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt Thread-Index: AQHTdcENIbwOw0X+lUyKSfv7lsgdwqNFHH+AgAAAOwA= Date: Fri, 15 Dec 2017 18:23:37 +0000 Message-ID: <95F9BD84-146C-478E-9E02-F7FE1F7404E5@cisco.com> References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> <64E8E1EE-BA2A-4BDC-8A37-52B7A641140A@cisco.com> In-Reply-To: <64E8E1EE-BA2A-4BDC-8A37-52B7A641140A@cisco.com> 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.154.160.123] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 18:23:41 -0000 +1 -Johnson > On Dec 15, 2017, at 10:22 AM, Vina Ermagan (vermagan) wrote: >=20 > +1 on adoption.=20 >=20 > Best, > Vina >=20 >> On Dec 15, 2017, at 8:23 AM, Joel Halpern wrote: >>=20 >> The authors of the lisp-gpe draft (below) have requested working group a= doption for this document. >>=20 >> This email starts a two week last call for working group adoption of thi= s document. >>=20 >> Please respond, positively or negatively. Silence does NOT mean consent= . Please include explanation / motivation / reasoning for your view. >>=20 >> Also remember that this is not a last call. Once the document is adopte= d (assuming it is), we as a working group can make changes as needed. The = primary quesitonin this call is whether this is a good basis for work we wa= nt to do. >>=20 >> Thank you, >> Joel (& Luigi) >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-lewis-lisp-gpe-04.txt >> Date: Fri, 15 Dec 2017 08:13:24 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : LISP Generic Protocol Extension >> Authors : Darrel Lewis >> John Lemon >> Puneet Agarwal >> Larry Kreeger >> Paul Quinn >> Michael Smith >> Navindra Yadav >> Fabio Maino >> Filename : draft-lewis-lisp-gpe-04.txt >> Pages : 8 >> Date : 2017-12-15 >>=20 >> Abstract: >> This draft describes extending the Locator/ID Separation Protocol >> (LISP), via changes to the LISP header, to support multi-protocol >> encapsulation. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 >> https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-lewis-lisp-gpe-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Dec 15 10:41:51 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24CD12940C for ; Fri, 15 Dec 2017 10:41:49 -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, FREEMAIL_FROM=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 N-jCWQezafWU for ; Fri, 15 Dec 2017 10:41:48 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326AC128DE7 for ; Fri, 15 Dec 2017 10:41:46 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id u25so6732678pfg.5 for ; Fri, 15 Dec 2017 10:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bncio3YYODFmhZeMY2bFc/e8dGgNj1oLm26TB1lS0qw=; b=RNbSmfO5b0mElNqUgQ2bep9bvquOfu2sMuaE/sUiG/XWUcfxQ/xOVrtpRuf7mx9sFE Ybc61XdKnoLLJQJ6y41nm3ZBM7+ZE1XKN5HU7gB6W13x2apThPCM/D9SV++U7Sc9wI/y vTTDhWgEB/GvmNVuirsUyTN0GiB4LXDNYtFUoGxfrq2OE5AxQWhb6OD+UGgxQkYXZe8s DbihP5+1QEA3/06dIoeUTwWtyeSIGiYSCLMg8xq4UQnhgKcRAg3bTVQkvtNqVbtFNbKM nCX/Vpz3UT6y+/AdUeyfodSFzezQh97YURcGazkKlBNaGW3uS8B18BATa1WXWkevL2Q1 hCog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bncio3YYODFmhZeMY2bFc/e8dGgNj1oLm26TB1lS0qw=; b=ED9D7ETbamJCHkxKwUwkRXgWVBmJTxHzzjsmbHTjYmhZxCgXAUrg3syZIGaQ8La9fv 9y5yyOBsQq/ZL9G5F/v2vtZNM09JXqv8sWMEjIiXQyBhL0fLhl7dNvyjQgnN17xqaizg q0hJlEAYw95OyTVZhjw4sRl5DHcCV4gNous0FAC98vYQu3oDtnNwucybcg3WM1ii2Tjv Tb4Oiycgixly7dbToyT0EBU0jyekKTA3o2dwEFEdqax3liRZ12xzcp1Pn1xnVvWywLTP C8kGrVMXP29kNttCOunWn4DCoQz9j2PtWrqcKGSEccC0UgGCcmTB4zWUoiYqTrDkIfdj jsnQ== X-Gm-Message-State: AKGB3mKYD2iErcWKwdxYXsYK/QBcDnS8hjU8zGkiRl7VxgYKELjB0hwq pJ9AbE1fCx7595udIJgSUzc= X-Google-Smtp-Source: ACJfBosdaVGl7etUqMIdKX4y4SkyDKgJuitBjLygvQmvFm/AjcW9QqB8yVySYNxjkF+ucRy/zT4JgQ== X-Received: by 10.98.209.8 with SMTP id z8mr14338646pfg.113.1513363305660; Fri, 15 Dec 2017 10:41:45 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id b184sm11250584pga.90.2017.12.15.10.41.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 10:41:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Dino Farinacci In-Reply-To: <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> Date: Fri, 15 Dec 2017 10:41:42 -0800 Cc: lisp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E101D8F-9B4A-471E-8FA0-238132801C51@gmail.com> References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> To: Fabio Maino X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 18:41:50 -0000 I support the WG adoption of this document. Dino > On Dec 15, 2017, at 8:40 AM, Fabio Maino wrote: >=20 > As an author I support the adoption of this document. >=20 > This simple LISP dataplane extension enables multiprotocol support in = LISP. It allows use of LISP in L2 overlays, and introduces the = capability to support dataplane extensions such as Network Service = Header or Group Based Policy. >=20 > This is bit-by-bit compatible with RFC6830bis and allows the use of = Map-Versioning and Echo-Noncing, albeit with a reduced size of the = corresponding dataplane metadata. >=20 > An earlier version of the draft has been implemented in the FD.io = (http://FD.io) and OOR (https://www.openoverlayrouter.org/) open source = data plane implementations. >=20 > Thanks, > Fabio >=20 >=20 >=20 > On 12/15/17 8:23 AM, Joel Halpern wrote: >> The authors of the lisp-gpe draft (below) have requested working = group adoption for this document. >>=20 >> This email starts a two week last call for working group adoption of = this document. >>=20 >> Please respond, positively or negatively. Silence does NOT mean = consent. Please include explanation / motivation / reasoning for your = view. >>=20 >> Also remember that this is not a last call. Once the document is = adopted (assuming it is), we as a working group can make changes as = needed. The primary quesitonin this call is whether this is a good = basis for work we want to do. >>=20 >> Thank you, >> Joel (& Luigi) >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-lewis-lisp-gpe-04.txt >> Date: Fri, 15 Dec 2017 08:13:24 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : LISP Generic Protocol Extension >> Authors : Darrel Lewis >> John Lemon >> Puneet Agarwal >> Larry Kreeger >> Paul Quinn >> Michael Smith >> Navindra Yadav >> Fabio Maino >> Filename : draft-lewis-lisp-gpe-04.txt >> Pages : 8 >> Date : 2017-12-15 >>=20 >> Abstract: >> This draft describes extending the Locator/ID Separation Protocol >> (LISP), via changes to the LISP header, to support multi-protocol >> encapsulation. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 >> https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-lewis-lisp-gpe-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Dec 15 12:12:48 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7341B126DCA for ; Fri, 15 Dec 2017 12:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 VBXLxbRQR7gw for ; Fri, 15 Dec 2017 12:12:35 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B22124D6C for ; Fri, 15 Dec 2017 12:12:35 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id m26so6877150pfj.11 for ; Fri, 15 Dec 2017 12:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=a9tJCATwgkfQuShCIZdqBE8+9+kBk/aVxzQiFpv3lPQ=; b=RIo5whVPl+MCsXjwCmg+s9XV3Ev3RFETgvADCUSIMxiIIXaDfsNkqpeCV0MXya7mlz KoWaGTiB4T3ku1PpPUDblrE7dAvDf7E5wdBqzeUTWC/jq1dmkywcETq6oaI577RD1vUh 67NrSKTKJL5rAHgf3HviUk9JCXDH2AlwM7WcdSyXOIuQGE0FG9rLZbj6fdFBmzXpwGx9 4iKhNOFn6GE4WyVn3HLvp81REgHKcilvECQj6deZtnv0PXm45VnQXk2uXgQWIkoYC49j hh6kyuwkt37NjX3RHdSv7y/38NhA2Xwv77lp6CJgYaT2xHukF69FYXxiVk7K3jl61Mc6 xYeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=a9tJCATwgkfQuShCIZdqBE8+9+kBk/aVxzQiFpv3lPQ=; b=b+fspl23fZ6VC+7CMMgUhADFSSWDhsPGrnRGpgcHRLf1+4rMA3cGlAQFqYNXnG9mE9 +5uXQx1BmzdGNyaNv4qzkzQuw1Y5lnzmwjjGltrEMJ/xchJCrpev660B+IRP+BgISNbm D/rNtnnFZTEeb1OpY9lmin3mOyiR/yrbrj/WFKg9GobgeJoyR4fQGoiF483RmlSFyJpf 6XwheEeajcnDErfUhx455hDXtGsEES6DoX7bn6cYumkPEJRtLoqM3JJMFqmPDVL3qc5T ru7/0/J/GnSBlN9fijfUWitPtxbzmGaVoQ0JNmtbxc+oo1C8Lhqn3EfOBtUBxsHFe7wf RnyA== X-Gm-Message-State: AKGB3mLDRU+BKfnTiFU5lfswSqt3XPLmj8Is9ZZyS3WbF4NfIzhOC3wq 8EsSR9f3vPh0l6YFAG5+SmY= X-Google-Smtp-Source: ACJfBosP2pyOZ5W3xYl1+dyyHrPT+cIXo+xm9Ilj5YY/bWQ0QLNbeZlSiEzI7fLMdS5h0pX9sI2aUQ== X-Received: by 10.99.125.23 with SMTP id y23mr13124105pgc.345.1513368754731; Fri, 15 Dec 2017 12:12:34 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id u21sm13412234pfl.102.2017.12.15.12.12.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 12:12:32 -0800 (PST) From: Dino Farinacci Message-Id: <50B62140-68E0-4C0E-AB1C-2642C7FA11E7@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_3BEB5D08-F895-4DF2-B8D8-8F47EE2AA29A" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Fri, 15 Dec 2017 12:12:30 -0800 In-Reply-To: Cc: "lisp@ietf.org list" , Dino Farinacci To: Alberto Rodriguez-Natal References: <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] Review of RFC6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 20:12:46 -0000 --Apple-Mail=_3BEB5D08-F895-4DF2-B8D8-8F47EE2AA29A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Enclosed is the latest revision of RFC6833bis-07. Thanks for closing the = loop Alberto. If you can ack the new changes, I=E2=80=99ll submit -07 = this weekend. > On Dec 7, 2017, at 11:06 PM, Alberto Rodriguez-Natal = wrote: >=20 > Hey Dino, >=20 > Sorry for the delay on this. Mostly agree with your responses, thanks > for the edits! >=20 > There a few points that I would like to clarify. See below. No prob. See my responses. >=20 >>> For definitions of other terms -- notably Map-Request, Map-Reply, >>> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- = please >>> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >>>=20 >>> =E2=80=A2 [AR] I think that the definitions for Map-Request and = Map-Reply >>> should be moved here, and probably we should include the definition >>> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >>> control-plane messages, not the other way around. >>=20 >> They did. But the text you identified above was not changed. Changed = now. >=20 > I meant that Map-Request and Map-Reply are not defined here (or > anywhere else that I can find) and they should. The closest things are > Encapsulated Map-Request and Negative Map Reply. I added a brief definitions of each to be consistent with Map-Register = and Map-Notify definitions that are already there. >=20 >>> The RLOCs in the Map-Reply are globally routable IP addresses of all >>> ETRs for the LISP site. >>>=20 >>> =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a >>> "Generally" at the beginning since we might have LCAFs with AFI =3D = 0 >>> (LISP-VPN encoding of Home-IID for instance). >>=20 >> Removed =E2=80=9Cglobally=E2=80=9D. I don=E2=80=99t understand your = other =E2=80=9CGenerally=E2=80=9D comment. >=20 > My point was that in the LISP-VPN draft the Home-IID is encoded as an > RLOC that it is not a routable address for the ETR. I removed all occurrences of =E2=80=9Cglobally routable=E2=80=9D to = =E2=80=9Croutable=E2=80=9D. >=20 >>> For example, a requester with two cached EID-Prefixes that are = covered >>> by a Map-Reply containing one less-specific prefix replaces the = entry >>> with the less-specific EID-Prefix. >>>=20 >>> =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a >>> less-specific received in a Map-Reply will erase from the map-cache >>> previously cached more-specifics that are covered by the >>> less-specific? >>=20 >> Yes, because if the Map-Reply returned a more-specific with the = less-specific, then it would be replaced so the less-specific replaces = the more-specifics that ARE NOT in the Map-Reply. >=20 > I think that I would rephrase this behavior to make it optional then. > There are implementations which just return the entry that the > requested EID hits and don't return by default any more-specifics > below. It is not optional. And this section of the draft defines the details. = And the section includes a MUST. >=20 >=20 >>> When more than one EID-Prefix is returned, all SHOULD use the same >>> Time to Live value so they can all time out at the same time. When = a >>> more-specific EID-Prefix is received later, its Time to Live value = in >>> the Map-Reply record can be stored even when other less-specific >>> entries exist. >>>=20 >>> =E2=80=A2 [AR] We should explain in which cases a more-specific = can be >>> received later. >>=20 >> I don=E2=80=99t follow. Each EID-record will contain a TTL for the = length prefix that is encoded. So the new Map-Reply TTL will be used for = any length entry (and in this case the more-specific). >=20 > My concern was that we should provide some context on when an ITR may > receive a more-specific prefix that overlaps with an existing > less-specific prefix already in its map-cache. One example is the EID > mobility draft, we can reference it here. I added a few sentences. Thanks, Dino --Apple-Mail=_3BEB5D08-F895-4DF2-B8D8-8F47EE2AA29A Content-Disposition: attachment; filename=rfcdiff-rfc6833bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-rfc6833bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6833bis-06.txt - = draft-ietf-lisp-rfc6833bis-07.txt=20 =20 =20 =20 =20 =20 =20 = = = = =
< draft-ietf-lisp-rfc6833bis-06.txt  =  draft-ietf-lisp-rfc6833bis-07.txt >
=
Network Working = Group V. Fuller = Network Working Group = V. Fuller
Internet-Draft = D. Farinacci Internet-Draft = D. Farinacci
Intended status: = Standards Track Cisco Systems = Intended status: Standards Track = Cisco Systems
Expires: April 8, 2018 A. = Cabellos (Ed.) Expires: June 18, 2018 A. = Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= October = 5, 2017 = December = 15, 2017
=
= Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) = Control-Plane
= draft-ietf-lisp-rfc6833bis-06 = = draft-ietf-lisp-rfc6833bis-07
=
Abstract = Abstract
=
This document = describes the Control-Plane and Mapping Service for the = This document describes the Control-Plane = and Mapping Service for the
Locator/ID = Separation Protocol (LISP), implemented by two new types = Locator/ID Separation Protocol (LISP), = implemented by two new types
of = LISP-speaking devices -- the LISP Map-Resolver and LISP = Map-Server of LISP-speaking devices = -- the LISP Map-Resolver and LISP Map-Server
-- that = provides a simplified "front end" for one or more Endpoint ID = -- that provides a simplified "front end" = for one or more Endpoint ID
to Routing = Locator mapping databases. to = Routing Locator mapping databases.
=
By using this = control-plane service interface and communicating with By using this control-plane service interface and = communicating with
=
skipping to = change at = page 1, line 46 =C2=B6 = skipping to change at page 1, line 46 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on April 8, = 2018. This Internet-Draft will = expire on June 18, 2018.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. = Definition of Terms . . . . . . . . . . . . . . . . . . . . . = 4 2. Requirements Notation . . . . . . . . . . . . . . . . . = . . . 4
3. Basic Overview . . . . . . . . . . . . . . = . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . = . . . . . . . . . . 4
4. LISP IPv4 and IPv6 Control-Plane Packet = Formats . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . = . . . . . . . . . 5
4.1. LISP Control Packet Type Allocations . . = . . . . . . . . 9 5. LISP IPv4 and IPv6 Control-Plane Packet = Formats . . . . . . . 7
4.2. Map-Request Message Format . . . . . . . = . . . . . . . . 10 5.1. LISP Control Packet Type Allocations . . = . . . . . . . . 9
4.3. EID-to-RLOC UDP Map-Request Message . . . = . . . . . . . . 13 5.2. Map-Request Message Format . . . . . . . = . . . . . . . . 10
4.4. Map-Reply Message Format . . . . . . . . = . . . . . . . . 15 5.3. EID-to-RLOC UDP Map-Request Message . . . = . . . . . . . . 13
4.5. EID-to-RLOC UDP Map-Reply Message . . . . = . . . . . . . . 19 5.4. Map-Reply Message Format . . . . . . . . = . . . . . . . . 15
4.6. Map-Register Message Format . . . . . . . = . . . . . . . . 22 5.5. EID-to-RLOC UDP Map-Reply Message . . . . = . . . . . . . . 19
4.7. Map-Notify/Map-Notify-Ack Message Format = . . . . . . . . 25 5.6. Map-Register Message Format . . . . . . . = . . . . . . . . 22
4.8. Encapsulated Control Message Format . . . = . . . . . . . . 26 5.7. Map-Notify/Map-Notify-Ack Message Format = . . . . . . . . 25
5. Interactions with Other LISP Components . . = . . . . . . . . . 28 5.8. Encapsulated Control Message Format . . . = . . . . . . . . 26
5.1. ITR EID-to-RLOC Mapping Resolution . . . = . . . . . . . . 28 6. Interactions with Other LISP Components . . = . . . . . . . . . 28
5.2. EID-Prefix Configuration and ETR = Registration . . . . . . 29 = 6.1. ITR EID-to-RLOC Mapping Resolution = . . . . . . . . . . . 28
5.3. Map-Server Processing . . . . . . . . . . = . . . . . . . . 31 6.2. EID-Prefix Configuration and ETR = Registration . . . . . . 29
5.4. Map-Resolver Processing . . . . . . . . . = . . . . . . . . 31 6.3. Map-Server Processing . . . . . . . . . . = . . . . . . . . 31
5.4.1. Anycast Map-Resolver Operation . . . . = . . . . . . . 32 6.4. Map-Resolver Processing . . . . . . . . . = . . . . . . . . 31
6. Security Considerations . . . . . . . . . . = . . . . . . . . . 32 6.4.1. Anycast Map-Resolver Operation . . . . = . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . = . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . = . . . . . . . . . 32
7.1. LISP Packet Type Codes . . . . . . . . . = . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . = . . . . . . . . . 33
7.2. LISP ACT and Flag Fields . . . . . . . . = . . . . . . . . 33 8.1. LISP Packet Type Codes . . . . . . . . . = . . . . . . . . 33
7.3. LISP Address Type Codes . . . . . . . . . = . . . . . . . . 34 8.2. LISP ACT and Flag Fields . . . . . . . . = . . . . . . . . 33
7.4. LISP Algorithm ID Numbers . . . . . . . . = . . . . . . . . 34 8.3. LISP Address Type Codes . . . . . . . . . = . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . = . . . . . . . . . 34 8.4. LISP Algorithm ID Numbers . . . . . . . . = . . . . . . . . 34
8.1. Normative References . . . . . . . . . . = . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . = . . . . . . . . . 34
8.2. Informative References . . . . . . . . . = . . . . . . . . 36 9.1. Normative References . . . . . . . . . . = . . . . . . . . 34
= 9.2. = Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . = . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 39 = Appendix B. Document Change Log . . . . . = . . . . . . . . . . . 39
B.1. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 39 B.1. = Changes to draft-ietf-lisp-rfc6833bis-07 = . . . . . . . . 39
B.2. = Changes to draft-ietf-lisp-rfc6833bis-05 = . . . . . . . . 39 B.2. = Changes to draft-ietf-lisp-rfc6833bis-06 = . . . . . . . . 39
B.3. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 39 B.3. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . = 40
B.4. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 40 B.4. = Changes to draft-ietf-lisp-rfc6833bis-04 = . . . . . . . . 40
B.5. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 40 B.5. = Changes to draft-ietf-lisp-rfc6833bis-03 = . . . . . . . . 40
B.6. = Changes to draft-ietf-lisp-rfc6833bis-01 = . . . . . . . . 40 B.6. = Changes to draft-ietf-lisp-rfc6833bis-02 = . . . . . . . . 40
B.7. = Changes to draft-ietf-lisp-rfc6833bis-00 = . . . . . . . . 40 B.7. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . = 41
B.8. = Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 41 = B.8. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . = 41
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 B.9. Changes to = draft-farinacci-lisp-rfc6833bis-00 . . . . . . 41
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 42
=
1. = Introduction 1. Introduction
=
The Locator/ID = Separation Protocol [I-D.ietf-lisp-introduction] and The Locator/ID Separation Protocol = [I-D.ietf-lisp-introduction] and
= [I-D.ietf-lisp-rfc6830bis] specifies an architecture and = mechanism = [I-D.ietf-lisp-rfc6830bis] specifies an architecture and = mechanism
for replacing = the addresses currently used by IP with two separate for replacing the addresses currently used by IP with = two separate
name spaces: = Endpoint IDs (EIDs), used within sites; and Routing name spaces: Endpoint IDs (EIDs), used within sites; = and Routing
Locators = (RLOCs), used on the transit networks that make up the Locators (RLOCs), used on the transit networks that = make up the
Internet = infrastructure. To achieve this separation, LISP defines = Internet infrastructure. To achieve this = separation, LISP defines
protocol = mechanisms for mapping from EIDs to RLOCs. In addition, = protocol mechanisms for mapping from EIDs to = RLOCs. In addition,
=
skipping to = change at = page 4, line 11 =C2=B6 = skipping to change at page 4, line 12 =C2=B6
Note that = while this document assumes a LISP+ALT database mapping = Note that while this document assumes a = LISP+ALT database mapping
infrastructure = to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of = Map-Server and Map-
Resolver = operation, the Mapping Service interface can (and likely = Resolver operation, the Mapping Service = interface can (and likely
will) be used = by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other = mapping database
systems as the = LISP infrastructure evolves. = systems as the LISP infrastructure evolves.
=
The LISP = Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of = the LISP
toolset. = Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of = LISP for
Internet = traffic are discussed in [I-D.ietf-lisp-rfc6830bis]. Internet traffic are discussed in = [I-D.ietf-lisp-rfc6830bis].
=
2. Definition = of Terms 2. Requirements Notation
=
= The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
= "SHOULD", "SHOULD = NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
= document are to be = interpreted as described in [RFC2119].
=
= 3. Definition = of Terms
=
Map-Server: = A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that = learns of EID-
Prefix = mapping entries from an ETR, via the registration mechanism = Prefix mapping entries from an ETR, via = the registration mechanism
described = below, or some other authoritative source if one exists. = described below, or some other = authoritative source if one exists.
A = Map-Server publishes these EID-Prefixes in a mapping database. = A Map-Server publishes these EID-Prefixes = in a mapping database.
=
= Map-Request: A = LISP Map-Request is a control-plane message to query
= the mapping = system to resolve an EID. A LISP Map-Request can also
= be sent to an = RLOC to test for reachability and to exchange
= security keys = between an encapsulator and a decapsulator. This
= type of = Map-Request is also known as an RLOC-Probe Request.
=
= Map-Reply: A LISP = Map-Reply is a control-plane message returned in
= response to a = Map-Request sent to the mapping system when
= resolving an EID. = A LISP Map-Reply can also be returned by a
= decapsulator in = response to a Map-Request sent by an encapsulator
= to test for = reachability. This type of Map-Reply is known as a
= RLOC-Probe = Reply.
=
= Encapsulated = Map-Request: A LISP Map-Request carried within an
= Encapsulated = Control Message (ECM), which has an additional LISP
= header prepended. = Sent to UDP destination port 4342. The "outer"
= addresses are = routable IP addresses, also known as RLOCs. Used by
= an ITR when = sending to a Map-Resolver and by a Map-Server when
= forwarding a = Map-Request to an ETR.
= =
Map-Resolver: = A network infrastructure component that accepts LISP Map-Resolver: A network infrastructure component = that accepts LISP
= Encapsulated Map-Requests, typically from an ITR, and = determines Encapsulated (ECM) Map-Requests, typically from an ITR, = and
whether = or not the destination IP address is part of the EID determines whether or not the destination IP = address is part of
= namespace; if it is not, a Negative Map-Reply is returned. = the EID namespace; if it is not, a = Negative Map-Reply is returned.
Otherwise, = the Map-Resolver finds the appropriate EID-to-RLOC Otherwise, the Map-Resolver finds the appropriate = EID-to-RLOC
mapping by = consulting a mapping database system. = mapping by consulting a mapping database system.
=
Encapsulated Map-Request: A LISP Map-Request carried = within an
Encapsulated Control Message, which has an = additional LISP header
prepended. Sent to UDP destination port 4342. = The "outer"
addresses are globally routable IP addresses, = also known as RLOCs.
Used by an ITR when sending to a Map-Resolver and = by a Map-Server
when forwarding a Map-Request to an = ETR.
= =
Negative = Map-Reply: A LISP Map-Reply that contains an empty Negative Map-Reply: A LISP Map-Reply that contains = an empty
= Locator-Set. Returned in response to a Map-Request if the = Locator-Set. Returned in response to a = Map-Request if the
destination = EID does not exist in the mapping database. destination EID does not exist in the mapping = database.
Typically, = this means that the "EID" being requested is an IP Typically, this means that the "EID" being = requested is an IP
address = connected to a non-LISP site. = address connected to a non-LISP site.
=
Map-Register = message: A LISP message sent by an ETR to a Map-Server = Map-Register message: A LISP message sent = by an ETR to a Map-Server
to register = its associated EID-Prefixes. In addition to the set to register its associated EID-Prefixes. In = addition to the set
of = EID-Prefixes to register, the message includes one or more = of EID-Prefixes to register, the message = includes one or more
RLOCs to = be used by the Map-Server when forwarding = Map-Requests RLOCs to reach ETR(s). The Map-Server uses these RLOCs when
= (re-formatted as Encapsulated Map-Requests) = received through the = forwarding Map-Requests (re-formatted as Encapsulated Map-
database mapping system. An ETR may request that the Map-Server = Requests). = An ETR MAY request that the Map-Server = answer Map-
answer = Map-Requests on its behalf by setting the = "proxy Map-Reply" Requests on its behalf by setting the = "proxy Map-Reply" flag
flag = (P-bit) in the message. (P-bit) = in the message.
=
Map-Notify = message: A LISP message sent by a Map-Server to an ETR = Map-Notify message: A LISP message sent by = a Map-Server to an ETR
to confirm = that a Map-Register has been received and processed. to confirm that a Map-Register has been received = and processed.
An ETR = requests that a Map-Notify be returned by setting the An ETR requests that a Map-Notify be returned by = setting the
= "want-map-notify" flag (M-bit) in the Map-Register message. = "want-map-notify" flag (M-bit) in the = Map-Register message.
=
Unlike a = Map-Reply, a Map-Notify uses UDP port 4342 for both Unlike a Map-Reply, a Map-Notify uses UDP port = 4342 for both
source = and destination. source and = destination. Map-Notify messages are also sent = to ITRs
= by Map-Servers = when there are RLOC-set changes.
=
For = definitions of other terms -- notably = Map-Request, Map-Reply, For definitions of other terms, notably Ingress Tunnel Router = (ITR),
Ingress = Tunnel Router (ITR), and Egress Tunnel = Router (ETR) -- please Egress Tunnel Router (ETR), = and Re-encapsulating Tunnel Router (RTR),
consult the LISP specification = [I-D.ietf-lisp-rfc6830bis]. refer to the LISP Data-Plane specification
= [I-D.ietf-lisp-rfc6830bis].
=
3. Basic Overview 4. Basic = Overview
=
A Map-Server = is a device that publishes EID-Prefixes in a LISP A Map-Server is a device that publishes EID-Prefixes = in a LISP
mapping = database on behalf of a set of ETRs. When it receives a Map = mapping database on behalf of a set of ETRs. = When it receives a Map
Request = (typically from an ITR), it consults the mapping database to = Request (typically from an ITR), it consults = the mapping database to
find an ETR = that can answer with the set of RLOCs for an EID-Prefix. = find an ETR that can answer with the set of = RLOCs for an EID-Prefix.
To publish its = EID-Prefixes, an ETR periodically sends Map-Register To publish its EID-Prefixes, an ETR periodically = sends Map-Register
messages to = the Map-Server. A Map-Register message contains a list = messages to the Map-Server. A Map-Register = message contains a list
of = EID-Prefixes plus a set of RLOCs that can be used to reach the ETR of = EID-Prefixes plus a set of RLOCs that can be used to reach the
when a Map-Server needs to forward a Map-Request to = it. ETRs.
=
When LISP+ALT = is used as the mapping database, a Map-Server connects When LISP+ALT is used as the mapping database, a = Map-Server connects
to the ALT = network and acts as a "last-hop" ALT-Router. Intermediate = to the ALT network and acts as a "last-hop" = ALT-Router. Intermediate
ALT-Routers = forward Map-Requests to the Map-Server that advertises a = ALT-Routers forward Map-Requests to the = Map-Server that advertises a
particular = EID-Prefix, and the Map-Server forwards them to the owning = particular EID-Prefix, and the Map-Server = forwards them to the owning
ETR, which = responds with Map-Reply messages. = ETR, which responds with Map-Reply messages.
=
When LISP-DDT = [RFC8111] is used as the mapping database, a Map-Server = When LISP-DDT [RFC8111] is used as the = mapping database, a Map-Server
sends the = final Map-Referral messages from the Delegated Database = sends the final Map-Referral messages from = the Delegated Database
Tree. = Tree.
=
skipping to = change at = page 5, line 45 =C2=B6 = skipping to change at page 6, line 17 =C2=B6
to answer = those requests. On a LISP+ALT network, a Map-Resolver acts = to answer those requests. On a LISP+ALT = network, a Map-Resolver acts
as a = "first-hop" ALT-Router. It has Generic Routing Encapsulation = as a "first-hop" ALT-Router. It has Generic = Routing Encapsulation
(GRE) tunnels = configured to other ALT-Routers and uses BGP to learn (GRE) tunnels configured to other ALT-Routers and = uses BGP to learn
paths to ETRs = for different prefixes in the LISP+ALT database. The paths to ETRs for different prefixes in the LISP+ALT = database. The
Map-Resolver = uses this path information to forward Map-Requests over = Map-Resolver uses this path information to = forward Map-Requests over
the ALT to the = correct ETRs. On a LISP-DDT network [RFC8111], a Map- the ALT to the correct ETRs. On a LISP-DDT network = [RFC8111], a Map-
Resolver = maintains a referral-cache and acts as a "first-hop" DDT- = Resolver maintains a referral-cache and acts = as a "first-hop" DDT-
node. The = Map-Resolver uses the referral information to forward Map- = node. The Map-Resolver uses the referral = information to forward Map-
= Requests. Requests.
=
Note that = while it is conceivable that a non-LISP-DDT = Map-Resolver Note that while it is = conceivable that a Map-Resolver could cache
could cache = responses to improve performance, issues surrounding responses to improve performance, issues surrounding = cache management
cache = management will need to be resolved so that doing so will be = will need to be resolved so that doing so = will be reliable and
reliable and = practical. As initially deployed, Map-Resolvers will practical. As initially deployed, Map-Resolvers = will operate only in
operate only = in a non-caching mode, decapsulating and forwarding a non-caching mode, decapsulating and forwarding = Encapsulated Map
Encapsulated = Map Requests received from ITRs. Any specification of Requests received from ITRs. Any specification of = caching
caching = functionality is left for future work. = functionality is left for future work.
=
Note that a = single device can implement the functions of both a Map- = Note that a single device can implement the = functions of both a Map-
Server and a = Map-Resolver, and in many cases the functions will be Server and a Map-Resolver, and in many cases the = functions will be
co-located in = that way. Also, there can be ALT-only nodes and DDT- co-located in that way. Also, there can be ALT-only = nodes and DDT-
only nodes, = when LISP+ALT and LISP-DDT are used, respectively, to only nodes, when LISP+ALT and LISP-DDT are used, = respectively, to
connect = Map-Resolvers and Map-Servers together to make up the Mapping = connect Map-Resolvers and Map-Servers = together to make up the Mapping
= System. System.
=
Detailed = descriptions of the LISP packet types referenced by this = Detailed descriptions of the LISP packet = types referenced by this
document may = be found in [I-D.ietf-lisp-rfc6830bis]. = document may be found in [I-D.ietf-lisp-rfc6830bis].
=
4. LISP IPv4 and IPv6 Control-Plane Packet = Formats 5. LISP IPv4 and IPv6 Control-Plane Packet = Formats
=
The following = UDP packet formats are used by the LISP control plane. The following UDP packet formats are used by the LISP = control plane.
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| = IHL |Type of Service| Total Length | |Version| IHL |Type of Service| Total = Length |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Identification |Flags| Fragment Offset | = | Identification |Flags| = Fragment Offset |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping to = change at = page 8, line 15 =C2=B6 = skipping to change at page 8, line 15 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port | Dest Port | / | Source Port | Dest = Port |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
| = LISP Message | | LISP Message = |
| = | | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
The LISP UDP-based messages are the Map-Request and = Map-Reply When a UDP Map-Request, Map-Register, or Map-Notify (when used as = a
messages. When a UDP Map-Request is sent, the UDP source port = is = notification message) are sent, the UDP source port is chosen by = the
chosen by = the sender and the destination UDP port number is set to = sender and the destination UDP port number = is set to 4342. When a
4342. When = a UDP Map-Reply is sent, the source UDP = port number is UDP Map-Reply Map-Notify (when used as an acknowledgement to a = Map-
= Register), or = Map-Notify-Ack are sent, the source UDP port number is
set to 4342 = and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is = copied from the
source port of = either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking = data packet.
= Implementations MUST be prepared to accept packets when either = the Implementations MUST be = prepared to accept packets when either the
source port or = destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 = due to NATs
changing port = number values. changing port number = values.
=
The 'UDP = Length' field will reflect the length of the UDP header and = The 'UDP Length' field will reflect the = length of the UDP header and
the LISP = Message payload. the LISP Message = payload.
=
The UDP = checksum is computed and set to non-zero for Map-Request, = The UDP checksum is computed and set to non-zero for all messages
Map-Reply, Map-Register, and Encapsulated Control = Message (ECM) sent to or from port 4342. It MUST be = checked on receipt, and if the
control messages. It MUST be checked on = receipt, and if the checksum = checksum fails, the control message MUST = be dropped.
fails, the = packet MUST be dropped.
=
The format of = control messages includes the UDP header so the The format of control messages includes the UDP = header so the
checksum and = length fields can be used to protect and delimit message = checksum and length fields can be used to = protect and delimit message
= boundaries. boundaries.
=
4.1. LISP Control Packet Type = Allocations 5.1. LISP Control Packet Type = Allocations
=
This section = defines the LISP control message formats and summarizes = This section defines the LISP control = message formats and summarizes
for IANA the = LISP Type codes assigned by this document. For for IANA the LISP Type codes assigned by this = document. For
completeness, = this document references the LISP Shared Extension completeness, this document references the LISP = Shared Extension
Message = assigned by [RFC8113]. Message type definitions are: Message assigned by [RFC8113]. Message type = definitions are:
=
Reserved: = 0 b'0000' = Reserved: 0 b'0000'
LISP = Map-Request: 1 b'0001' LISP Map-Request: 1 = b'0001'
LISP = Map-Reply: 2 b'0010' LISP Map-Reply: 2 = b'0010'
LISP = Map-Register: 3 b'0011' LISP Map-Register: 3 = b'0011'
LISP = Map-Notify: 4 b'0100' LISP Map-Notify: 4 = b'0100'
LISP = Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 = b'0101'
LISP = Map-Referral: 6 b'0110' LISP Map-Referral: 6 = b'0110'
LISP = Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 = b'1000'
Not Assigned = 9-14 b'1001'- b'1110' Not Assigned 9-14 b'1001'- = b'1110'
LISP Shared = Extension Message: 15 b'1111' [RFC8113] = LISP Shared Extension Message: 15 = b'1111' [RFC8113]
=
Values in the = "Not Assigned" range can be assigned according to Values in the "Not Assigned" range can be assigned = according to
procedures = in [RFC5226]. Documents that request for = a new LISP procedures in [RFC8126]. Documents that request for a new = LISP
packet type = may indicate a preferred value in Section = 7.3. = packet type MAY indicate a preferred value = in Section 8.3.
=
Protocol = designers experimenting with new message formats should use = Protocol designers experimenting with new message formats SHOULD use
the LISP = Shared Extension Message Type and request a [RFC8113] sub- = the LISP Shared Extension Message Type and = request a [RFC8113] sub-
type = assignment. type = assignment.
=
All LISP = control-plane messages use Address Family Identifiers (AFI) = All LISP control-plane messages use Address = Family Identifiers (AFI)
[AFI] or LISP = Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) = [RFC8060] formats to
encode either = fixed or variable length addresses. This includes encode either fixed or variable length addresses. = This includes
explicit = fields in each control message or part of EID-records or = explicit fields in each control message or = part of EID-records or
RLOC-records = in commonly formatted messages. = RLOC-records in commonly formatted messages.
=
The LISP = control-plane describes how other data-planes can encode = The LISP control-plane describes how other = data-planes can encode
messages to = support the SMR and RLOC-probing procedures of the LISP = messages to support the SMR and RLOC-probing = procedures of the LISP
data-plane = defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane = data-plane defined in = [I-D.ietf-lisp-rfc6830bis]. This control-plane
specification = itself does not offer such functionality and other specification itself does not offer such = functionality and other
data-planes = can use their own mechanisms that do not rely on the LISP = data-planes can use their own mechanisms = that do not rely on the LISP
= control-plane. = control-plane.
=
4.2. Map-Request Message Format = 5.2. = Map-Request Message Format
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3D1 = |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | = |Type=3D1 |A|M|P|S|p|s|m|I| Rsvd = |L|D| IRC | Record Count |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Nonce . . . | | Nonce . . . = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = . . . Nonce | | . . . Nonce = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping to = change at = page 12, line 32 =C2=B6 = skipping to change at page 12, line = 32 =C2=B6
selecting = the destination address from any address family for the = selecting the destination address from = any address family for the
Map-Reply = message. This address MUST be a routable RLOC address Map-Reply message. This address MUST be a = routable RLOC address
of the = sender of the Map-Request message. = of the sender of the Map-Request message.
=
EID mask-len: = This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the = EID-Prefix.
=
= EID-Prefix-AFI: This is the address family of the EID-Prefix = EID-Prefix-AFI: This is the address family = of the EID-Prefix
according = to [AFI] and [RFC8060]. = according to [AFI] and [RFC8060].
=
EID-Prefix: = This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix is 4 octets for an IPv4 = address family and
16 octets = for an IPv6 address family. When a Map-Request is sent 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1
by an ITR = because a data packet is received for a destination or 2, respectively. For = other AFIs [AFI], the length varies and
where = there is no mapping entry, the EID-Prefix is set to the = for the LCAF AFI = the format is defined in [RFC8060]. When a Map-
= destination IP address of the data packet, and the 'EID = mask-len' = Request is sent by an ITR because a data packet is received for = a
is set to = 32 or 128 for IPv4 or IPv6, respectively. When an xTR destination where there is no mapping entry, the = EID-Prefix is set
wants to = query a site about the status of a mapping it already has = to the destination IP address of the = data packet, and the 'EID
cached, = the EID-Prefix used in the Map-Request has the same mask = mask-len' is set to 32 or 128 for IPv4 = or IPv6, respectively.
length as = the EID-Prefix returned from the site when it sent a When an xTR wants to query a site about the = status of a mapping it
Map-Reply = message. already has cached, = the EID-Prefix used in the Map-Request has the
= same mask length as the EID-Prefix = returned from the site when it
= sent a Map-Reply message.
=
Map-Reply = Record: When the M-bit is set, this field is the size of a = Map-Reply Record: When the M-bit is set, = this field is the size of a
single = "Record" in the Map-Reply format. This Map-Reply record = single "Record" in the Map-Reply format. = This Map-Reply record
contains = the EID-to-RLOC mapping entry associated with the Source = contains the EID-to-RLOC mapping entry = associated with the Source
EID. This = allows the ETR that will receive this Map-Request to EID. This allows the ETR that will receive this = Map-Request to
cache the = data if it chooses to do so. = cache the data if it chooses to do so.
=
4.3. EID-to-RLOC UDP Map-Request = Message 5.3. EID-to-RLOC UDP Map-Request = Message
=
A Map-Request = is sent from an ITR when it needs a mapping for an EID, = A Map-Request is sent from an ITR when it = needs a mapping for an EID,
wants to test = an RLOC for reachability, or wants to refresh a mapping = wants to test an RLOC for reachability, or = wants to refresh a mapping
before TTL = expiration. For the initial case, the destination IP before TTL expiration. For the initial case, the = destination IP
address used = for the Map-Request is the data packet's destination address used for the Map-Request is the data packet's = destination
address (i.e., = the destination EID) that had a mapping cache lookup address (i.e., the destination EID) that had a = mapping cache lookup
failure. For = the latter two cases, the destination IP address used failure. For the latter two cases, the destination = IP address used
for the = Map-Request is one of the RLOC addresses from the Locator-Set = for the Map-Request is one of the RLOC = addresses from the Locator-Set
of the = Map-Cache entry. The source address is either an IPv4 or IPv6 = of the Map-Cache entry. The source address = is either an IPv4 or IPv6
RLOC address, = depending on whether the Map-Request is using an IPv4 RLOC address, depending on whether the Map-Request is = using an IPv4
=
skipping to = change at = page 13, line 37 =C2=B6 = skipping to change at page 13, line = 37 =C2=B6
configured = Locators in this list or just provide one locator address = configured Locators in this list or just = provide one locator address
from each = address family it supports. If the ITR erroneously from each address family it supports. If the ITR = erroneously
provides no = ITR-RLOC addresses, the Map-Replier MUST drop the Map- provides no ITR-RLOC addresses, the Map-Replier MUST = drop the Map-
= Request. Request.
=
Map-Requests = can also be LISP encapsulated using UDP destination Map-Requests can also be LISP encapsulated using UDP = destination
port 4342 with = a LISP Type value set to "Encapsulated Control port 4342 with a LISP Type value set to "Encapsulated = Control
Message", when = sent from an ITR to a Map-Resolver. Likewise, Map- Message", when sent from an ITR to a Map-Resolver. = Likewise, Map-
Requests are = LISP encapsulated the same way from a Map-Server to an Requests are LISP encapsulated the same way from a = Map-Server to an
ETR. Details = on Encapsulated Map-Requests and Map-Resolvers can be ETR. Details on Encapsulated Map-Requests and = Map-Resolvers can be
found in = Section 4.8. found in Section 5.8.
=
Map-Requests = MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED = that a Map-
Request for = the same EID-Prefix be sent no more than once per second. = Request for the same EID-Prefix be sent no = more than once per second.
=
An ITR that is = configured with mapping database information (i.e., it An ITR that is configured with mapping database = information (i.e., it
is also an = ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings = in a Map-
Request. When = an ETR configured to accept and verify such Request. When an ETR configured to accept and verify = such
"piggybacked" = mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a = Map-Request and it does
not have this = mapping in the map-cache, it MAY originate a "verifying = not have this mapping in the map-cache, it = MAY originate a "verifying
Map-Request", = addressed to the map-requesting ITR and the ETR MAY add = Map-Request", addressed to the = map-requesting ITR and the ETR MAY add
a Map-Cache = entry. If the ETR has a Map-Cache entry that matches the = a Map-Cache entry. If the ETR has a = Map-Cache entry that matches the
"piggybacked" = EID and the RLOC is in the Locator-Set for the entry, "piggybacked" EID and the RLOC is in the Locator-Set = for the entry,
then it = may send the "verifying Map-Request" = directly to the then it MAY send the "verifying Map-Request" directly to = the
originating = Map-Request source. If the RLOC is not in the Locator- = originating Map-Request source. If the RLOC = is not in the Locator-
Set, then the = ETR MUST send the "verifying Map-Request" to the Set, then the ETR MUST send the "verifying = Map-Request" to the
"piggybacked" = EID. Doing this forces the "verifying Map-Request" to "piggybacked" EID. Doing this forces the "verifying = Map-Request" to
go through the = mapping database system to reach the authoritative go through the mapping database system to reach the = authoritative
source of = information about that EID, guarding against RLOC-spoofing = source of information about that EID, = guarding against RLOC-spoofing
in the = "piggybacked" mapping data. in the = "piggybacked" mapping data.
=
4.4. Map-Reply Message Format 5.4. Map-Reply Message = Format
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3D2 = |P|E|S| Reserved | Record Count | = |Type=3D2 |P|E|S| Reserved = | Record Count |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Nonce . . . | | Nonce . . . = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = . . . Nonce | | . . . Nonce = |
+-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= +-> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping to = change at = page 16, line 43 =C2=B6 = skipping to change at page 16, line = 43 =C2=B6
= Prefix. Prefix.
=
EID mask-len: = This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the = EID-Prefix.
=
ACT: This = 3-bit field describes Negative Map-Reply actions. In any = ACT: This 3-bit field describes Negative = Map-Reply actions. In any
other = message type, these bits are set to 0 and ignored on other message type, these bits are set to 0 and = ignored on
receipt. = These bits are used only when the 'Locator Count' field = receipt. These bits are used only when = the 'Locator Count' field
is set to = 0. The action bits are encoded only in Map-Reply is set to 0. The action bits are encoded only in = Map-Reply
messages. = The actions defined are used by an ITR or PITR when a messages. The actions defined are used by an ITR = or PITR when a
destination = EID matches a negative Map-Cache entry. Unassigned destination EID matches a negative Map-Cache = entry. Unassigned
values = should cause a Map-Cache entry to be = created, and when values SHOULD cause a Map-Cache entry to be created, = and when
packets = match this negative cache entry, they will be dropped. packets match this negative cache entry, they will = be dropped.
The current = assigned values are: The current = assigned values are:
=
(0) = No-Action: The map-cache is kept alive, and no packet (0) No-Action: The map-cache is kept alive, and = no packet
= encapsulation occurs. = encapsulation occurs.
=
(1) = Natively-Forward: The packet is not encapsulated or dropped = (1) Natively-Forward: The packet is not = encapsulated or dropped
but = natively forwarded. but = natively forwarded.
=
(2) = Send-Map-Request: The packet invokes sending a Map-Request. = (2) Send-Map-Request: The packet invokes = sending a Map-Request.
=
skipping to = change at = page 18, line 49 =C2=B6 = skipping to change at page 18, line = 49 =C2=B6
probed and = MAY be different from the source address of the Map- probed and MAY be different from the source = address of the Map-
Reply. An = ITR that RLOC-probes a particular Locator MUST use this = Reply. An ITR that RLOC-probes a = particular Locator MUST use this
Locator for = retrieving the data structure used to store the fact Locator for retrieving the data structure used to = store the fact
that the = Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set = for a single
Locator in = the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an = implementation sets more
than one = p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the = Map-Reply MUST
select the = first Locator. The p-bit MUST NOT be set for Locator- select the first Locator. The p-bit MUST NOT be = set for Locator-
Set records = sent in Map-Request and Map-Register messages. Set records sent in Map-Request and Map-Register = messages.
=
R: This is set = when the sender of a Map-Reply has a route to the R: This is set when the sender of a Map-Reply has a = route to the
Locator = in the Locator data record. This receiver may find this = Locator in the Locator data record. This receiver MAY find this
useful to = know if the Locator is up but not necessarily reachable = useful to know if the Locator is up but = not necessarily reachable
from the = receiver's point of view. See also EID-Reachability from the receiver's point of view. See also = EID-Reachability
= [I-D.ietf-lisp-rfc6830bis] for another way the R-bit may be used. = [I-D.ietf-lisp-rfc6830bis] for another way the R-bit MAY be used.
=
Locator: This = is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded = by the 'Loc-
AFI' field) = assigned to an ETR. Note that the destination RLOC AFI' field) assigned to an ETR. Note that the = destination RLOC
address MAY = be an anycast address. A source RLOC can be an address MAY be an anycast address. A source RLOC = can be an
anycast = address as well. The source or destination RLOC MUST NOT = anycast address as well. The source or = destination RLOC MUST NOT
be the = broadcast address (255.255.255.255 or any subnet broadcast = be the broadcast address (255.255.255.255 = or any subnet broadcast
address = known to the router) and MUST NOT be a link-local address known to the router) and MUST NOT be a = link-local
multicast = address. The source RLOC MUST NOT be a multicast multicast address. The source RLOC MUST NOT be a = multicast
address. = The destination RLOC SHOULD be a multicast address if it = address. The destination RLOC SHOULD be = a multicast address if it
is being = mapped from a multicast destination EID. is being mapped from a multicast destination = EID.
=
4.5. EID-to-RLOC UDP Map-Reply Message = 5.5. = EID-to-RLOC UDP Map-Reply Message
=
A Map-Reply = returns an EID-Prefix with a prefix length that is less = A Map-Reply returns an EID-Prefix with a = prefix length that is less
than or equal = to the EID being requested. The EID being requested is = than or equal to the EID being requested. = The EID being requested is
either from = the destination field of an IP header of a Data-Probe or = either from the destination field of an IP = header of a Data-Probe or
the EID record = of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the = Map-Reply are
globally routable IP addresses of all ETRs for = the LISP site. Each routable IP = addresses of all ETRs for the LISP site. Each RLOC
RLOC conveys = status reachability but does not convey path conveys status reachability but does not convey path = reachability
reachability = from a requester's perspective. Separate testing of from a requester's perspective. Separate testing of = path
path = reachability is required. See RLOC-reachability reachability is required. See = RLOC-reachability
= [I-D.ietf-lisp-rfc6830bis] for details. = [I-D.ietf-lisp-rfc6830bis] for details.
=
Note that a = Map-Reply may contain different EID-Prefix = granularity Note that a Map-Reply = MAY contain different EID-Prefix = granularity
(prefix + = length) than the Map-Request that triggers it. This might = (prefix + length) than the Map-Request that = triggers it. This might
occur if a = Map-Request were for a prefix that had been returned by an = occur if a Map-Request were for a prefix = that had been returned by an
earlier = Map-Reply. In such a case, the requester updates its cache = earlier Map-Reply. In such a case, the = requester updates its cache
with the new = prefix information and granularity. For example, a with the new prefix information and granularity. For = example, a
requester with = two cached EID-Prefixes that are covered by a Map- requester with two cached EID-Prefixes that are = covered by a Map-
Reply = containing one less-specific prefix replaces the entry with the = Reply containing one less-specific prefix = replaces the entry with the
less-specific = EID-Prefix. Note that the reverse, replacement of one less-specific EID-Prefix. Note that the reverse, = replacement of one
less-specific = prefix with multiple more-specific prefixes, can also less-specific prefix with multiple more-specific = prefixes, can also
occur, not by = removing the less-specific prefix but rather by adding occur, not by removing the less-specific prefix but = rather by adding
the = more-specific prefixes that, during a lookup, will override the = the more-specific prefixes that, during a = lookup, will override the
less-specific = prefix. less-specific = prefix.
=
When an = ETR is configured with overlapping EID-Prefixes, a Map- When = an EID moves out of a LISP site = [I-D.ietf-lisp-eid-mobility],
Request with an EID that best matches any = EID-Prefix MUST be returned the database mapping system may have overlapping = EID-prefixes. Or
in a single = Map-Reply message. For instance, if an ETR had database = when a LISP = site is configured with multiple sets of = ETRs that
mapping = entries for EID-Prefixes: support different EID-prefix lengths, the database = mapping system may
= have overlapping = EID-prefixes. When overlapping EID-prefixes= exist,
= a Map-Request = with an EID that best matches any EID-Prefix MUST be
= returned in a single Map-Reply message. = For instance, if an ETR had
= database mapping entries for = EID-Prefixes:
=
= 10.0.0.0/8 10.0.0.0/8
= 10.1.0.0/16 10.1.0.0/16
= 10.1.1.0/24 10.1.1.0/24
= 10.1.2.0/24 10.1.2.0/24
=
A Map-Request = for EID 10.1.1.1 would cause a Map-Reply with a record A Map-Request for EID 10.1.1.1 would cause a = Map-Reply with a record
count of 1 to = be returned with a mapping record EID-Prefix of count of 1 to be returned with a mapping record = EID-Prefix of
= 10.1.1.0/24. 10.1.1.0/24.
=
=
skipping = to change at page 22, line = 5 =C2=B6 = skipping to change at page 22, line = 5 =C2=B6
choose a = locator address from one of the address families it choose a locator address from one of the address = families it
supports. For = Data-Probes, the destination address of the Map-Reply supports. For Data-Probes, the destination address = of the Map-Reply
is copied from = the source address of the Data-Probe message that is is copied from the source address of the Data-Probe = message that is
invoking the = reply. The source address of the Map-Reply is one of invoking the reply. The source address of the = Map-Reply is one of
the local IP = addresses chosen to allow Unicast Reverse Path the local IP addresses chosen to allow Unicast = Reverse Path
Forwarding = (uRPF) checks to succeed in the upstream service provider. = Forwarding (uRPF) checks to succeed in the = upstream service provider.
The = destination port of a Map-Reply message is copied from the = source The destination port of a = Map-Reply message is copied from the source
port of the = Map-Request or Data-Probe, and the source port of the port of the Map-Request or Data-Probe, and the source = port of the
Map-Reply = message is set to the well-known UDP port 4342. Map-Reply message is set to the well-known UDP port = 4342.
=
4.6. Map-Register Message Format = 5.6. = Map-Register Message Format
=
This section = specifies the encoding format for the Map-Register This section specifies the encoding format for the = Map-Register
message. The = message is sent in UDP with a destination UDP port of message. The message is sent in UDP with a = destination UDP port of
4342 and a = randomly selected UDP source port number. 4342 and a randomly selected UDP source port = number.
=
The = Map-Register message format is: The = Map-Register message format is:
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping = to change at page 23, line = 44 =C2=B6 = skipping to change at page 23, line = 44 =C2=B6
sending a = Map-Register message. The Map-Notify message sent by a = sending a Map-Register message. The = Map-Notify message sent by a
Map-Server = is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a = Map-Register
= message. message.
=
Record Count: = This is the number of records in this Map-Register Record Count: This is the number of records in this = Map-Register
message. A = record is comprised of that portion of the packet message. A record is comprised of that portion of = the packet
labeled = 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of = times equal to
Record = Count. Record Count.
=
Nonce: This = 8-octet 'Nonce' field is set to 0 in Map-Register Nonce: This 8-octet 'Nonce' field is set to 0 in = Map-Register
messages. Since the Map-Register message is = authenticated, the messages if no Map-Notify message is expected to = acknowledge it.
'Nonce' = field is not currently used for any security function but = Since the Map-Register message is = authenticated, the 'Nonce' field
may be in the future as part of an anti-replay = solution. is not currently used = for any security function but MAY be in = the
= future as part of an anti-replay = solution.
=
Key ID: This = is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that = corresponds to a
= shared-secret password that is used to authenticate the sender. = shared-secret password that is used to = authenticate the sender.
Multiple = shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over = keys in a non-
disruptive = way. disruptive way.
=
Algorithm ID: = This is the configured Message Authentication Code Algorithm ID: This is the configured Message = Authentication Code
(MAC) = algorithm value used for the authentication function. See = (MAC) algorithm value used for the = authentication function. See
Algorithm = ID Numbers in the Section 7.3 for = codepoint assignments. = Algorithm ID Numbers in the Section 8.3 = for codepoint assignments.
=
Authentication = Data Length: This is the length in octets of the Authentication Data Length: This is the length in = octets of the
= 'Authentication Data' field that follows this field. The = length 'Authentication Data' = field that follows this field. The length
of the = 'Authentication Data' field is dependent on the MAC of the 'Authentication Data' field is dependent on = the MAC
algorithm = used. The length field allows a device that doesn't algorithm used. The length field allows a device = that doesn't
know the = MAC algorithm to correctly parse the packet. know the MAC algorithm to correctly parse the = packet.
=
Authentication = Data: This is the message digest used from the output Authentication Data: This is the message digest used = from the output
of the MAC = algorithm. The entire Map-Register payload is of the MAC algorithm. The entire Map-Register = payload is
= authenticated with this field preset to 0. After the MAC is = authenticated with this field preset to = 0. After the MAC is
computed, = it is placed in this field. Implementations of this computed, it is placed in this field. = Implementations of this
= specification MUST include support for HMAC-SHA-1-96 [RFC2404], = specification MUST include support for = HMAC-SHA-1-96 [RFC2404],
and support = for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. and support for HMAC-SHA-256-128 [RFC4868] is = RECOMMENDED.
=
The definition = of the rest of the Map-Register can be found in The definition of the rest of the Map-Register can be = found in
Section = 4.4. = Section 5.4.
=
4.7. Map-Notify/Map-Notify-Ack Message = Format 5.7. Map-Notify/Map-Notify-Ack Message = Format
=
This section = specifies the encoding format for the Map-Notify and This section specifies the encoding format for the = Map-Notify and
Map-Notify-Ack = messages. The messages are sent inside a UDP packet Map-Notify-Ack messages. The messages are sent = inside a UDP packet
with source = and destination UDP ports equal to 4342. with source and destination UDP ports equal to = 4342.
=
The Map-Notify = and Map-Notify-Ack message formats are: = The Map-Notify and Map-Notify-Ack message formats are:
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping = to change at page 26, line = 5 =C2=B6 = skipping to change at page 26, line = 5 =C2=B6
Type: 4/5 = (Map-Notify/Map-Notify-Ack) Type: = 4/5 (Map-Notify/Map-Notify-Ack)
=
The Map-Notify = message has the same contents as a Map-Register The Map-Notify message has the same contents as a = Map-Register
message. See = the Map-Register section for field descriptions. message. See the Map-Register section for field = descriptions.
=
The = Map-Notify-Ack message has the same contents as a Map-Notify = The Map-Notify-Ack message has the same = contents as a Map-Notify
message. It = is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a = Map-Notify and
for the sender = to stop retransmitting a Map-Notify with the same for the sender to stop retransmitting a Map-Notify = with the same
= nonce. nonce.
=
4.8. Encapsulated Control Message = Format 5.8. Encapsulated Control Message = Format
=
An = Encapsulated Control Message (ECM) is used to encapsulate = control An Encapsulated Control = Message (ECM) is used to encapsulate control
packets sent = between xTRs and the mapping database system. packets sent between xTRs and the mapping database = system.
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = IPv4 or IPv6 Header | / | IPv4 or IPv6 Header = |
OH | = (uses RLOC addresses) | OH | (uses RLOC addresses) = |
\ | = | \ | = |
=
skipping = to change at page 27, line = 39 =C2=B6 = skipping to change at page 27, line = 39 =C2=B6
control = packet being encapsulated. When the control packet is control packet being encapsulated. When the = control packet is
a = Map-Request or Map-Register, the source port is selected by = a Map-Request or Map-Register, the = source port is selected by
the = ITR/PITR and the destination port is 4342. When the the ITR/PITR and the destination port is 4342. = When the
control = packet is a Map-Reply, the source port is 4342 and the control packet is a Map-Reply, the source port = is 4342 and the
= destination port is assigned from the source port of the = destination port is assigned from the = source port of the
invoking = Map-Request. Port number 4341 MUST NOT be assigned to invoking Map-Request. Port number 4341 MUST = NOT be assigned to
either = port. The checksum field MUST be non-zero. either port. The checksum field MUST be = non-zero.
=
LCM: The = format is one of the control message formats described in = LCM: The format is one of the control = message formats described in
this = section. At this time, only Map-Request messages are this section. At this time, only Map-Request = messages are
= allowed to be encapsulated. In the future, PIM Join/Prune = allowed to be control-plane (ECM) encapsulated. In the = future,
= messages [RFC6831] might be allowed. Encapsulating other types = PIM Join/Prune messages [RFC6831] = might be allowed.
of = LISP control messages is for further study. When Map- = Encapsulating other types of LISP control messages is for
Requests are sent for RLOC-Probing = purposes (i.e., the probe- = further study. When Map-Requests are sent for RLOC-Probing
bit is set), they MUST NOT be sent = inside Encapsulated Control = purposes (i.e., the probe-bit is set), = they MUST NOT be sent
= Messages. inside = Encapsulated Control Messages.
=
5. Interactions with Other LISP = Components 6. Interactions with Other LISP = Components
=
5.1. ITR EID-to-RLOC Mapping = Resolution 6.1. ITR EID-to-RLOC Mapping Resolution
=
An ITR is = configured with one or more Map-Resolver addresses. These = An ITR is configured with one or more = Map-Resolver addresses. These
addresses = are "Locators" (or RLOCs) and must be = routable on the addresses are = "Locators" (or RLOCs) and MUST be routable = on the
underlying = core network; they must not need to be = resolved through underlying core = network; they MUST NOT need to be resolved = through
LISP = EID-to-RLOC mapping, as that would introduce a circular = LISP EID-to-RLOC mapping, as that would = introduce a circular
dependency. = When using a Map-Resolver, an ITR does not need to dependency. When using a Map-Resolver, an ITR does = not need to
connect to any = other database mapping system. In particular, the ITR connect to any other database mapping system. In = particular, the ITR
need not = connect to the LISP+ALT infrastructure or implement the BGP = need not connect to the LISP+ALT = infrastructure or implement the BGP
and GRE = protocols that it uses. and GRE = protocols that it uses.
=
An ITR sends = an Encapsulated Map-Request to a configured Map-Resolver = An ITR sends an Encapsulated Map-Request to = a configured Map-Resolver
when it needs = an EID-to-RLOC mapping that is not found in its local when it needs an EID-to-RLOC mapping that is not = found in its local
map-cache. = Using the Map-Resolver greatly reduces both the map-cache. Using the Map-Resolver greatly reduces = both the
complexity of = the ITR implementation and the costs associated with complexity of the ITR implementation and the costs = associated with
=
skipping = to change at page 28, line = 44 =C2=B6 = skipping to change at page 28, line = 44 =C2=B6
o A Negative = Map-Reply, with action code of "Natively-Forward", from = o A Negative Map-Reply, with action code of = "Natively-Forward", from
a = Map-Server that is authoritative for an EID-Prefix that matches = a Map-Server that is authoritative for an = EID-Prefix that matches
the = requested EID but that does not have an actively registered, = the requested EID but that does not have = an actively registered,
= more-specific ID-prefix. In this case, the requested EID is = said more-specific ID-prefix. = In this case, the requested EID is said
to match a = "hole" in the authoritative EID-Prefix. If the to match a "hole" in the authoritative EID-Prefix. = If the
requested = EID matches a more-specific EID-Prefix that has been requested EID matches a more-specific EID-Prefix = that has been
delegated = by the Map-Server but for which no ETRs are currently delegated by the Map-Server but for which no ETRs = are currently
registered, = a 1-minute TTL is returned. If the requested EID registered, a 1-minute TTL is returned. If the = requested EID
matches a = non-delegated part of the authoritative EID-Prefix, then = matches a non-delegated part of the = authoritative EID-Prefix, then
it is not a = LISP EID and a 15-minute TTL is returned. See it is not a LISP EID and a 15-minute TTL is = returned. See
Section = 5.2 for discussion of aggregate = EID-Prefixes and details = Section 6.2 for discussion of aggregate = EID-Prefixes and details
of = Map-Server EID-Prefix matching. = of Map-Server EID-Prefix matching.
=
o A LISP = Map-Reply from the ETR that owns the EID-to-RLOC mapping or = o A LISP Map-Reply from the ETR that owns = the EID-to-RLOC mapping or
possibly = from a Map-Server answering on behalf of the ETR. See possibly from a Map-Server answering on behalf of = the ETR. See
Section = 5.4 for more details on Map-Resolver = message processing. Section = 6.4 for more details on Map-Resolver = message processing.
=
Note that an = ITR may be configured to both use a = Map-Resolver and to Note that an = ITR MAY be configured to both use a = Map-Resolver and to
participate in = a LISP+ALT logical network. In such a situation, the participate in a LISP+ALT logical network. In such a = situation, the
ITR should send Map-Requests through the ALT network = for any EID- ITR SHOULD send Map-Requests through the ALT network = for any EID-
Prefix learned = via ALT BGP. Such a configuration is expected to be Prefix learned via ALT BGP. Such a configuration is = expected to be
very rare, = since there is little benefit to using a Map-Resolver if = very rare, since there is little benefit to = using a Map-Resolver if
an ITR is = already using LISP+ALT. There would be, for example, no = an ITR is already using LISP+ALT. There = would be, for example, no
need for such = an ITR to send a Map-Request to a possibly non-existent = need for such an ITR to send a Map-Request = to a possibly non-existent
EID (and rely = on Negative Map-Replies) if it can consult the ALT EID (and rely on Negative Map-Replies) if it can = consult the ALT
database to = verify that an EID-Prefix is present before sending that = database to verify that an EID-Prefix is = present before sending that
= Map-Request. Map-Request.
=
5.2. EID-Prefix Configuration and ETR = Registration 6.2. EID-Prefix Configuration and ETR = Registration
=
An ETR = publishes its EID-Prefixes on a Map-Server by sending LISP = An ETR publishes its EID-Prefixes on a = Map-Server by sending LISP
Map-Register = messages. A Map-Register message includes Map-Register messages. A Map-Register message = includes
authentication = data, so prior to sending a Map-Register message, the authentication data, so prior to sending a = Map-Register message, the
ETR and = Map-Server must be configured with a = shared secret or other ETR and = Map-Server SHOULD be configured with a = shared secret or other
relevant = authentication information. A Map-Server's configuration = relevant authentication information. A = Map-Server's configuration
must also include a list of the EID-Prefixes for = which each ETR is SHOULD also include a list of the EID-Prefixes = for which each ETR is
authoritative. = Upon receipt of a Map-Register from an ETR, a Map- authoritative. Upon receipt of a Map-Register from = an ETR, a Map-
Server accepts = only EID-Prefixes that are configured for that ETR. Server accepts only EID-Prefixes that are configured = for that ETR.
Failure to = implement such a check would leave the mapping system Failure to implement such a check would leave the = mapping system
vulnerable to = trivial EID-Prefix hijacking attacks. As developers vulnerable to trivial EID-Prefix hijacking attacks. = As developers
and operators = gain experience with the mapping system, additional, and operators gain experience with the mapping = system, additional,
stronger = security measures may be added to the = registration process. stronger = security measures MAY be added to the = registration process.
=
In addition = to the set of EID-Prefixes defined for each ETR that may In = addition to the set of EID-Prefixes defined for each ETR that MAY
register, a = Map-Server is typically also configured with one or more = register, a Map-Server is typically also = configured with one or more
aggregate = prefixes that define the part of the EID numbering space = aggregate prefixes that define the part of = the EID numbering space
assigned to = it. When LISP+ALT is the database in use, aggregate EID- = assigned to it. When LISP+ALT is the = database in use, aggregate EID-
Prefixes are = implemented as discard routes and advertised into ALT Prefixes are implemented as discard routes and = advertised into ALT
BGP. The = existence of aggregate EID-Prefixes in a Map-Server's BGP. The existence of aggregate EID-Prefixes in a = Map-Server's
database = means that it may receive Map Requests for = EID-Prefixes that database means = that it MAY receive Map Requests for = EID-Prefixes that
match an = aggregate but do not match a registered prefix; Section 5.3 match = an aggregate but do not match a registered prefix; Section 6.3
describes how = this is handled. describes how this = is handled.
=
Map-Register = messages are sent periodically from an ETR to a Map- Map-Register messages are sent periodically from an = ETR to a Map-
Server with a = suggested interval between messages of one minute. A Server with a suggested interval between messages of = one minute. A
Map-Server = should time out and remove an ETR's = registration if it has Map-Server = SHOULD time out and remove an ETR's = registration if it has
not received a = valid Map-Register message within the past not received a valid Map-Register message within the = past
three minutes. = When first contacting a Map-Server after restart or three minutes. When first contacting a Map-Server = after restart or
changes to = its EID-to-RLOC database mappings, an ETR may initially = changes to its EID-to-RLOC database mappings, an ETR MAY initially
send = Map-Register messages at an increased frequency, up to one = every send Map-Register messages at = an increased frequency, up to one every
20 seconds. = This "quick registration" period is limited to 20 seconds. This "quick registration" period is = limited to
five minutes = in duration. five minutes in = duration.
=
An ETR may request that a Map-Server explicitly = acknowledge receipt An ETR MAY request that a Map-Server explicitly = acknowledge receipt
and processing = of a Map-Register message by setting the "want-map- and processing of a Map-Register message by setting = the "want-map-
notify" = (M-bit) flag. A Map-Server that receives a Map-Register with = notify" (M-bit) flag. A Map-Server that = receives a Map-Register with
this flag set = will respond with a Map-Notify message. Typical use of = this flag set will respond with a Map-Notify = message. Typical use of
this flag by = an ETR would be to set it for Map-Register messages sent = this flag by an ETR would be to set it for = Map-Register messages sent
during the = initial "quick registration" with a Map-Server but then = during the initial "quick registration" with = a Map-Server but then
set it only = occasionally during steady-state maintenance of its set it only occasionally during steady-state = maintenance of its
association = with that Map-Server. Note that the Map-Notify message = association with that Map-Server. Note that = the Map-Notify message
is sent to UDP = destination port 4342, not to the source port is sent to UDP destination port 4342, not to the = source port
specified in = the original Map-Register message. = specified in the original Map-Register message.
=
Note that a = one-minute minimum registration interval during Note that a one-minute minimum registration interval = during
maintenance of = an ETR-Map-Server association places a lower bound on maintenance of an ETR-Map-Server association places a = lower bound on
how quickly = and how frequently a mapping database entry can be how quickly and how frequently a mapping database = entry can be
updated. = This may have implications for what sorts = of mobility can updated. This = MAY have implications for what sorts of = mobility can
be supported = directly by the mapping system; shorter registration be supported directly by the mapping system; shorter = registration
intervals or = other mechanisms might be needed to support faster intervals or other mechanisms might be needed to = support faster
mobility in = some cases. For a discussion on one way that faster mobility in some cases. For a discussion on one way = that faster
mobility = may be implemented for individual devices, = please see mobility MAY be implemented for individual devices, = please see
= [I-D.ietf-lisp-mn]. = [I-D.ietf-lisp-mn].
=
An ETR may also request, by setting the "proxy = Map-Reply" flag An ETR MAY also request, by setting the "proxy = Map-Reply" flag
(P-bit) in the = Map-Register message, that a Map-Server answer Map- (P-bit) in the Map-Register message, that a = Map-Server answer Map-
Requests = instead of forwarding them to the ETR. See Requests instead of forwarding them to the ETR. = See
= [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server = sets [I-D.ietf-lisp-rfc6830bis] for = details on how the Map-Server sets
certain flags = (such as those indicating whether the message is certain flags (such as those indicating whether the = message is
= authoritative and how returned Locators should be treated) when authoritative and how returned Locators SHOULD be treated) when
sending a = Map-Reply on behalf of an ETR. When an ETR requests proxy = sending a Map-Reply on behalf of an ETR. = When an ETR requests proxy
reply = service, it should include all RLOCs for = all ETRs for the EID- reply = service, it SHOULD include all RLOCs for = all ETRs for the EID-
Prefix being = registered, along with the routable flag ("R-bit") Prefix being registered, along with the routable flag = ("R-bit")
setting for = each RLOC. The Map-Server includes all of this setting for each RLOC. The Map-Server includes all = of this
information in = Map-Reply messages that it sends on behalf of the ETR. information in Map-Reply messages that it sends on = behalf of the ETR.
This differs = from a non-proxy registration, since the latter need This differs from a non-proxy registration, since the = latter need
only provide = one or more RLOCs for a Map-Server to use for forwarding = only provide one or more RLOCs for a = Map-Server to use for forwarding
Map-Requests; = the registration information is not used in Map- Map-Requests; the registration information is not = used in Map-
Replies, so it = being incomplete is not incorrect. = Replies, so it being incomplete is not incorrect.
=
An ETR that = uses a Map-Server to publish its EID-to-RLOC mappings An ETR that uses a Map-Server to publish its = EID-to-RLOC mappings
does not need = to participate further in the mapping database does not need to participate further in the mapping = database
=
skipping = to change at page 31, line = 5 =C2=B6 = skipping to change at page 31, line = 5 =C2=B6
this means = that the ETR does not need to implement GRE or BGP, which = this means that the ETR does not need to = implement GRE or BGP, which
greatly = simplifies its configuration and reduces its cost of greatly simplifies its configuration and reduces its = cost of
= operation. operation.
=
Note that use = of a Map-Server does not preclude an ETR from also Note that use of a Map-Server does not preclude an = ETR from also
connecting to = the mapping database (i.e., it could also connect to connecting to the mapping database (i.e., it could = also connect to
the LISP+ALT = network), but doing so doesn't seem particularly useful, = the LISP+ALT network), but doing so doesn't = seem particularly useful,
as the whole = purpose of using a Map-Server is to avoid the complexity = as the whole purpose of using a Map-Server = is to avoid the complexity
of the mapping = database protocols. of the mapping = database protocols.
=
5.3. Map-Server Processing 6.3. Map-Server = Processing
=
Once a = Map-Server has EID-Prefixes registered by its client ETRs, it = Once a Map-Server has EID-Prefixes = registered by its client ETRs, it
can accept and = process Map-Requests for them. can = accept and process Map-Requests for them.
=
In response to = a Map-Request (received over the ALT if LISP+ALT is in In response to a Map-Request (received over the ALT = if LISP+ALT is in
use), the = Map-Server first checks to see if the destination EID use), the Map-Server first checks to see if the = destination EID
matches a = configured EID-Prefix. If there is no match, the Map- matches a configured EID-Prefix. If there is no = match, the Map-
Server returns = a Negative Map-Reply with action code "Natively- Server returns a Negative Map-Reply with action code = "Natively-
Forward" and = a 15-minute TTL. This may occur if a Map = Request is Forward" and a = 15-minute TTL. This MAY occur if a Map = Request is
received for a = configured aggregate EID-Prefix for which no more- received for a configured aggregate EID-Prefix for = which no more-
specific = EID-Prefix exists; it indicates the presence of a non-LISP = specific EID-Prefix exists; it indicates the = presence of a non-LISP
"hole" in the = aggregate EID-Prefix. "hole" in the = aggregate EID-Prefix.
=
Next, the = Map-Server checks to see if any ETRs have registered the = Next, the Map-Server checks to see if any = ETRs have registered the
matching = EID-Prefix. If none are found, then the Map-Server returns = matching EID-Prefix. If none are found, = then the Map-Server returns
a Negative = Map-Reply with action code "Natively-Forward" and a a Negative Map-Reply with action code = "Natively-Forward" and a
1-minute = TTL. 1-minute TTL.
=
If any of the = registered ETRs for the EID-Prefix have requested proxy = If any of the registered ETRs for the = EID-Prefix have requested proxy
reply service, = then the Map-Server answers the request instead of reply service, then the Map-Server answers the = request instead of
forwarding it. = It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the = EID-Prefix, RLOCs,
and other = information learned through the registration process. and other information learned through the = registration process.
=
If none of the = ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply = service, then the Map-
Server = re-encapsulates and forwards the resulting Encapsulated Map- = Server re-encapsulates and forwards the = resulting Encapsulated Map-
Request to one = of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not = otherwise alter
the = Map-Request, so any Map-Reply sent by the ETR is returned to = the the Map-Request, so any = Map-Reply sent by the ETR is returned to the
RLOC in the = Map-Request, not to the Map-Server. Unless also acting = RLOC in the Map-Request, not to the = Map-Server. Unless also acting
as a = Map-Resolver, a Map-Server should never = receive Map-Replies; any as a = Map-Resolver, a Map-Server SHOULD never = receive Map-Replies; any
such = messages should be discarded without = response, perhaps such messages = SHOULD be discarded without response, = perhaps
accompanied by = the logging of a diagnostic message if the rate of accompanied by the logging of a diagnostic message if = the rate of
Map-Replies is = suggestive of malicious traffic. = Map-Replies is suggestive of malicious traffic.
=
5.4. Map-Resolver Processing 6.4. Map-Resolver = Processing
=
Upon receipt = of an Encapsulated Map-Request, a Map-Resolver Upon receipt of an Encapsulated Map-Request, a = Map-Resolver
decapsulates = the enclosed message and then searches for the requested = decapsulates the enclosed message and then = searches for the requested
EID in its = local database of mapping entries (statically configured = EID in its local database of mapping entries = (statically configured
or learned = from associated ETRs if the Map-Resolver is also a Map- = or learned from associated ETRs if the = Map-Resolver is also a Map-
Server = offering proxy reply service). If it finds a matching entry, = Server offering proxy reply service). If it = finds a matching entry,
it returns a = LISP Map-Reply with the known mapping. = it returns a LISP Map-Reply with the known mapping.
=
If the = Map-Resolver does not have the mapping entry and if it can = If the Map-Resolver does not have the = mapping entry and if it can
determine that = the EID is not in the mapping database (for example, determine that the EID is not in the mapping database = (for example,
if LISP+ALT is = used, the Map-Resolver will have an ALT forwarding if LISP+ALT is used, the Map-Resolver will have an = ALT forwarding
table that = covers the full EID space), it immediately returns a table that covers the full EID space), it immediately = returns a
negative LISP = Map-Reply, with action code "Natively-Forward" and a negative LISP Map-Reply, with action code = "Natively-Forward" and a
15-minute TTL. = To minimize the number of negative cache entries 15-minute TTL. To minimize the number of negative = cache entries
needed by an = ITR, the Map-Resolver should return the = least-specific needed by an ITR, = the Map-Resolver SHOULD return the = least-specific
prefix that = both matches the original query and does not match any prefix that both matches the original query and does = not match any
EID-Prefix = known to exist in the LISP-capable infrastructure. EID-Prefix known to exist in the LISP-capable = infrastructure.
=
If the = Map-Resolver does not have sufficient information to know = If the Map-Resolver does not have sufficient = information to know
whether the = EID exists, it needs to forward the Map-Request to whether the EID exists, it needs to forward the = Map-Request to
another device = that has more information about the EID being another device that has more information about the = EID being
requested. To = do this, it forwards the unencapsulated Map-Request, requested. To do this, it forwards the = unencapsulated Map-Request,
with the = original ITR RLOC as the source, to the mapping database = with the original ITR RLOC as the source, to = the mapping database
system. Using = LISP+ALT, the Map-Resolver is connected to the ALT system. Using LISP+ALT, the Map-Resolver is = connected to the ALT
network and = sends the Map-Request to the next ALT hop learned from network and sends the Map-Request to the next ALT hop = learned from
its ALT BGP = neighbors. The Map-Resolver does not send any response = its ALT BGP neighbors. The Map-Resolver = does not send any response
to the ITR; = since the source RLOC is that of the ITR, the ETR or Map- = to the ITR; since the source RLOC is that of = the ITR, the ETR or Map-
Server that = receives the Map-Request over the ALT and responds will = Server that receives the Map-Request over = the ALT and responds will
do so directly = to the ITR. do so directly to the = ITR.
=
5.4.1. Anycast Map-Resolver Operation = 6.4.1. Anycast = Map-Resolver Operation
=
A Map-Resolver = can be set up to use "anycast", where the same address A Map-Resolver can be set up to use "anycast", where = the same address
is assigned to = multiple Map-Resolvers and is propagated through IGP is assigned to multiple Map-Resolvers and is = propagated through IGP
routing, to = facilitate the use of a topologically close Map-Resolver = routing, to facilitate the use of a = topologically close Map-Resolver
by each = ITR. by each ITR.
=
Note that = Map-Server associations with ETRs should = not use anycast Note that = Map-Server associations with ETRs SHOULD = NOT use anycast
addresses, as = registrations need to be established between an ETR and = addresses, as registrations need to be = established between an ETR and
a specific set = of Map-Servers, each identified by a specific a specific set of Map-Servers, each identified by a = specific
registration = association. registration = association.
=
6. Security Considerations 7. Security = Considerations
=
The 2-way LISP = header nonce exchange documented in = The 2-way LISP header nonce exchange documented in
= [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing = attacks. [I-D.ietf-lisp-rfc6830bis] = can be used to avoid ITR spoofing attacks.
=
To publish an = authoritative EID-to-RLOC mapping with a Map-Server, an = To publish an authoritative EID-to-RLOC = mapping with a Map-Server, an
ETR includes = authentication data that is a hash of the message using = ETR includes authentication data that is a = hash of the message using
a pair-wise = shared key. An implementation must = support use of HMAC- a pair-wise = shared key. An implementation MUST = support use of HMAC-
SHA-1-96 = [RFC2104] and should support use of = HMAC-SHA-256-128 SHA-1-96 = [RFC2104] and SHOULD support use of = HMAC-SHA-256-128
[RFC6234] = (SHA-256 truncated to 128 bits). = [RFC6234] (SHA-256 truncated to 128 bits).
=
As noted in = Section 5.2, a Map-Server should verify = that all EID- As noted in Section = 6.2, a Map-Server SHOULD verify that all = EID-
Prefixes = registered by an ETR match the configuration stored on the = Prefixes registered by an ETR match the = configuration stored on the
= Map-Server. Map-Server.
=
The currently = defined authentication mechanism for Map-Register The currently defined authentication mechanism for = Map-Register
messages does = not provide protection against "replay" attacks by a messages does not provide protection against "replay" = attacks by a
= "man-in-the-middle". Additional work is needed in this area. = "man-in-the-middle". Additional work is = needed in this area.
=
= [I-D.ietf-lisp-sec] defines a proposed mechanism for providing = origin [I-D.ietf-lisp-sec] defines = a proposed mechanism for providing origin
= authentication, integrity, anti-replay protection, and prevention = of authentication, integrity, = anti-replay protection, and prevention of
= man-in-the-middle and "overclaiming" attacks on the = Map-Request/Map- man-in-the-middle = and "overclaiming" attacks on the Map-Request/Map-
Reply = exchange. Work is ongoing on this and other proposals for = Reply exchange. Work is ongoing on this and = other proposals for
resolving = these open security issues. = resolving these open security issues.
=
While beyond = the scope of securing an individual Map-Server or Map- While beyond the scope of securing an individual = Map-Server or Map-
Resolver, it = should be noted that a BGP-based LISP+ALT = network (if Resolver, it SHOULD be noted that a BGP-based LISP+ALT = network (if
ALT is used as = the mapping database infrastructure) can take ALT is used as the mapping database infrastructure) = can take
advantage of = standards work on adding security to BGP. advantage of standards work on adding security to = BGP.
=
A complete = LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in = [RFC7835].
Please refer = to it for more security related details. Please refer to it for more security related = details.
=
7. IANA Considerations 8. IANA = Considerations
=
This section = provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet = Assigned Numbers
Authority = (IANA) regarding registration of values related to this = Authority (IANA) regarding registration of = values related to this
LISP = control-plane specification, in accordance with BCP 26 LISP control-plane specification, in accordance with = BCP 26
[RFC5226]. = [RFC8126].
=
There are = three namespaces (listed in the sub-sections below) in LISP = There are three namespaces (listed in the = sub-sections below) in LISP
that have been = registered. that have been = registered.
=
o LISP IANA = registry allocations should not be made = for purposes o LISP IANA registry = allocations SHOULD NOT be made for = purposes
unrelated = to LISP routing or transport protocols. = unrelated to LISP routing or transport protocols.
=
o The = following policies are used here with the meanings defined in = o The following policies are used here with = the meanings defined in
BCP 26: = "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", = "Experimental
Use", and = "First Come First Served". Use", = and "First Come First Served".
=
7.1. LISP Packet Type Codes 8.1. LISP Packet Type = Codes
=
It is being = requested that the IANA be authoritative for LISP Packet = It is being requested that the IANA be = authoritative for LISP Packet
Type = definitions and that it refers to this document as well as = Type definitions and that it refers to this = document as well as
[RFC8113] as = references. [RFC8113] as = references.
=
Based on = deployment experience of [RFC6830], the Map-Notify-Ack Based on deployment experience of [RFC6830], the = Map-Notify-Ack
message, = message type 5, was added to this document. This document = message, message type 5, was added to this = document. This document
requests IANA = to add it to the LISP Packet Type Registry. requests IANA to add it to the LISP Packet Type = Registry.
=
7.2. LISP ACT and Flag Fields 8.2. LISP ACT and Flag = Fields
=
New ACT values = can be allocated through IETF review or IESG approval. New ACT values can be allocated through IETF review = or IESG approval.
Four values = have already been allocated by [RFC6830]. This Four values have already been allocated by [RFC6830]. = This
specification = changes the name of ACT type 3 value from "Drop" to specification changes the name of ACT type 3 value = from "Drop" to
= "Drop/No-Reason" as well as adding two new ACT values, the = "Drop/ "Drop/No-Reason" as well as = adding two new ACT values, the "Drop/
Policy-Denied" = (type 4) and "Drop/Authentication-Failure" (type 5). Policy-Denied" (type 4) and = "Drop/Authentication-Failure" (type 5).
=
In addition, = LISP has a number of flag fields and reserved fields, In addition, LISP has a number of flag fields and = reserved fields,
such as the = LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New = such as the LISP header flags field = [I-D.ietf-lisp-rfc6830bis]. New
bits for flags = in these fields can be implemented after IETF review bits for flags in these fields can be implemented = after IETF review
or IESG = approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by = IANA.
=
7.3. LISP Address Type Codes 8.3. LISP Address Type = Codes
=
LISP Canonical = Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an = 8-bit field that
defines = LISP-specific encodings for AFI value 16387. LCAF encodings = defines LISP-specific encodings for AFI = value 16387. LCAF encodings
are used for = specific use-cases where different address types for are used for specific use-cases where different = address types for
EID-records = and RLOC-records are required. = EID-records and RLOC-records are required.
=
The IANA = registry "LISP Canonical Address Format (LCAF) Types" is = The IANA registry "LISP Canonical Address = Format (LCAF) Types" is
used for LCAF = types, the registry for LCAF types use the used for LCAF types, the registry for LCAF types use = the
= Specification Required policy [RFC5226]. = Initial values for the = Specification Required policy [RFC8126]. = Initial values for the
registry as = well as further information can be found in [RFC8060]. registry as well as further information can be found = in [RFC8060].
=
Therefore, = there is no longer a need for the "LISP Address Type Therefore, there is no longer a need for the "LISP = Address Type
Codes" = registry requested by [RFC6830]. This document requests to = Codes" registry requested by [RFC6830]. = This document requests to
remove = it. remove it.
=
7.4. LISP Algorithm ID Numbers = 8.4. LISP = Algorithm ID Numbers
=
In [RFC6830], = a request for a "LISP Key ID Numbers" registry was In [RFC6830], a request for a "LISP Key ID Numbers" = registry was
submitted. = This document renames the registry to "LISP Algorithm ID = submitted. This document renames the = registry to "LISP Algorithm ID
Numbers" and = requests the IANA to make the name change. Numbers" and requests the IANA to make the name = change.
=
The following = Algorithm ID values are defined by this specification The following Algorithm ID values are defined by this = specification
as used in any = packet type that references a 'Algorithm ID' field: as used in any packet type that references a = 'Algorithm ID' field:
=
Name = Number Defined in = Name Number Defined in
= ----------------------------------------------- = -----------------------------------------------
None = 0 n/a = None 0 n/a
= HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-1-96 1 = [RFC2404]
= HMAC-SHA-256-128 2 [RFC4868] HMAC-SHA-256-128 2 = [RFC4868]
=
Number values = are in the range of 0 to 255. The allocation of values = Number values are in the range of 0 to 255. = The allocation of values
is on a first = come first served basis. is on a = first come first served basis.
=
8. References 9. References
=
8.1. Normative References 9.1. Normative = References
=
[RFC1035] = Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - = implementation and
= specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, = specification", STD 13, RFC 1035, = DOI 10.17487/RFC1035,
= November 1987, <https://www.rfc-editor.org/info/rfc1035>. = November 1987, = <https://www.rfc-editor.org/info/rfc1035>.
=
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, = "HMAC: Keyed- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Hashing for Message Authentication", RFC 2104, Requirement Levels", BCP 14, RFC = 2119,
= DOI 10.17487/RFC2104, February = 1997, DOI 10.17487/RFC2119, March 1997,
= <https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2119>.
=
[RFC2404] = Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within = [RFC2404] Madson, C. and R. Glenn, "The Use = of HMAC-SHA-1-96 within
ESP = and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November
= 1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, = <https://www.rfc-editor.org/info/rfc2404>.
=
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for = Cryptographic
Key Management", BCP 107, RFC 4107, DOI = 10.17487/RFC4107,
June 2005, = <https://www.rfc-editor.org/info/rfc4107>. =
= =
[RFC4868] = Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- = [RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
= 384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI = 10.17487/RFC4868, May 2007, = DOI 10.17487/RFC4868, May 2007,
= <https://www.rfc-editor.org/info/rfc4868>. = <https://www.rfc-editor.org/info/rfc4868>.
=
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines = for Writing an
IANA Considerations Section in RFCs", RFC = 5226,
DOI 10.17487/RFC5226, May = 2008,
= <https://www.rfc-editor.org/info/rfc5226>. =
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US = Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC = 6234,
DOI 10.17487/RFC6234, May = 2011,
= <https://www.rfc-editor.org/info/rfc6234>. =
= =
[RFC6830] = Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The = [RFC6830] Farinacci, D., Fuller, V., Meyer, = D., and D. Lewis, "The
= Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", = RFC 6830,
DOI = 10.17487/RFC6830, January 2013, = DOI 10.17487/RFC6830, January 2013,
= <https://www.rfc-editor.org/info/rfc6830>. = <https://www.rfc-editor.org/info/rfc6830>.
=
[RFC6831] = Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The = [RFC6831] Farinacci, D., Meyer, D., = Zwiebel, J., and S. Venaas, "The
= Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for = Multicast
= Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI = 10.17487/RFC6831, January
= 2013, <https://www.rfc-editor.org/info/rfc6831>. 2013, = <https://www.rfc-editor.org/info/rfc6831>.
=
[RFC6836] = Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and = D. Lewis,
= "Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol = Alternative Logical
= Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI = 10.17487/RFC6836,
= January 2013, <https://www.rfc-editor.org/info/rfc6836>. = January 2013, = <https://www.rfc-editor.org/info/rfc6836>.
=
[RFC6837] = Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint = ID (EID) to
= Routing Locator (RLOC) Database", RFC 6837, Routing Locator (RLOC) Database", RFC = 6837,
DOI = 10.17487/RFC6837, January 2013, = DOI 10.17487/RFC6837, January 2013,
= <https://www.rfc-editor.org/info/rfc6837>. = <https://www.rfc-editor.org/info/rfc6837>.
=
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, = P., Kreeger,
L., Sridhar, T., Bursell, M., and C. = Wright, "Virtual
eXtensible Local Area Network (VXLAN): A = Framework for
Overlaying Virtualized Layer 2 Networks = over Layer 3
Networks", RFC 7348, DOI = 10.17487/RFC7348, August 2014,
= <https://www.rfc-editor.org/info/rfc7348>. =
[RFC7835] Saucez, D., Iannone, L., and O. = Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat = Analysis", RFC 7835,
DOI 10.17487/RFC7835, April = 2016,
= <https://www.rfc-editor.org/info/rfc7835>. =
= =
[RFC8060] = Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical = [RFC8060] Farinacci, D., Meyer, D., and J. = Snijders, "LISP Canonical
= Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, = Address Format (LCAF)", RFC 8060, = DOI 10.17487/RFC8060,
= February 2017, <https://www.rfc-editor.org/info/rfc8060>. = February 2017, = <https://www.rfc-editor.org/info/rfc8060>.
=
[RFC8111] = Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
= Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol = Delegated
= Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, = Database Tree (LISP-DDT)", RFC = 8111, DOI 10.17487/RFC8111,
May = 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, = <https://www.rfc-editor.org/info/rfc8111>.
=
[RFC8113] = Boucadair, M. and C. Jacquenet, "Locator/ID Separation [RFC8113] Boucadair, M. and C. Jacquenet, = "Locator/ID Separation
= Protocol (LISP): Shared Extension Message & IANA Registry = Protocol (LISP): Shared Extension = Message & IANA Registry
for = Packet Type Allocations", RFC 8113, = for Packet Type Allocations", RFC 8113,
DOI = 10.17487/RFC8113, March 2017, = DOI 10.17487/RFC8113, March 2017,
= <https://www.rfc-editor.org/info/rfc8113>. = <https://www.rfc-editor.org/info/rfc8113>.
=
8.2. Informative References [RFC8126] Cotton, M., Leiba, = B., and T. Narten, "Guidelines for
= Writing = an IANA Considerations Section in RFCs", BCP 26,
= RFC 8126, = DOI 10.17487/RFC8126, June 2017,
= = <https://www.rfc-editor.org/info/rfc8126>.
=
= 9.2. = Informative References
=
[AFI] = IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY = [AFI] IANA, "Address Family Identifier = (AFIs)", ADDRESS FAMILY
= NUMBERS http://www.iana.org/assignments/address-family- = NUMBERS = http://www.iana.org/assignments/address-family-
= numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, = Febuary 2007.
=
= [I-D.ermagan-lisp-nat-traversal] = [I-D.ermagan-lisp-nat-traversal]
= Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, = Ermagan, V., Farinacci, D., = Lewis, D., Skriver, J., Maino,
F., = and C. White, "NAT traversal for LISP", draft-ermagan- F., and C. White, "NAT traversal for = LISP", draft-ermagan-
= lisp-nat-traversal-13 (work in progress), September 2017. = lisp-nat-traversal-13 (work in = progress), September 2017.
=
= [I-D.ietf-lisp-eid-mobility] = [I-D.ietf-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-ietf-lisp-eid-mobility-00 = Unified Control Plane", draft-ietf-lisp-eid-mobility-01
= (work in progress), May 2017. = (work in progress), November 2017.
=
= [I-D.ietf-lisp-introduction] = [I-D.ietf-lisp-introduction]
= Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An = Architectural
= Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation = Protocol
= (LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 = (work in
= progress), April 2015. = progress), April 2015.
=
= [I-D.ietf-lisp-mn] = [I-D.ietf-lisp-mn]
= Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP = Farinacci, D., Lewis, D., Meyer, = D., and C. White, "LISP
= Mobile Node", draft-ietf-lisp-mn-00 (work = in progress), Mobile = Node", draft-ietf-lisp-mn-01 (work in = progress),
= April 2017. October = 2017.
=
= [I-D.ietf-lisp-rfc6830bis] = [I-D.ietf-lisp-rfc6830bis]
= Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. = Farinacci, D., Fuller, V., Meyer, = D., Lewis, D., and A.
= Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID = Separation Protocol
= (LISP)", draft-ietf-lisp-rfc6830bis-05 = (work in progress), = (LISP)", draft-ietf-lisp-rfc6830bis-07 = (work in progress),
= August 2017. November = 2017.
=
= [I-D.ietf-lisp-sec] = [I-D.ietf-lisp-sec]
= Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, = A., and D.
= Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-13 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
= (work in progress), September = 2017. (work in = progress), October 2017.
=
= [I-D.ietf-lisp-signal-free-multicast] = [I-D.ietf-lisp-signal-free-multicast]
= Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", = Moreno, V. and D. Farinacci, = "Signal-Free LISP Multicast",
= draft-ietf-lisp-signal-free-multicast-06 = (work in draft-ietf-lisp-signal-free-multicast-07 (work = in
= progress), August 2017. progress), November 2017.
=
= [I-D.lewis-lisp-gpe] = [I-D.lewis-lisp-gpe]
= Lewis, D., Agarwal, P., Kreeger, L., Maino, = F., Quinn, P., = Lewis, D., Lemon, J., Agarwal, P., = Kreeger, L., Quinn, P.,
= Smith, M., and N. Yadav, "LISP Generic = Protocol Smith, M., = Yadav, N., and F. Maino, "LISP Generic = Protocol
= Extension", draft-lewis-lisp-gpe-02 (work = in progress), = Extension", draft-lewis-lisp-gpe-04 (work = in progress),
= July 2014. December = 2017.
=
= [I-D.quinn-vxlan-gpe] = [I-D.quinn-vxlan-gpe]
= Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., = Quinn, P., Manur, R., Kreeger, = L., Lewis, D., Maino, F.,
= Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, = Smith, M., Agarwal, P., Yong, L., = Xu, X., Elzur, U., Garg,
P., = and D. Melman, "Generic Protocol Extension for VXLAN", P., and D. Melman, "Generic Protocol = Extension for VXLAN",
= draft-quinn-vxlan-gpe-04 (work in progress), February draft-quinn-vxlan-gpe-04 (work in = progress), February
= 2015. 2015.
=
= [I-D.rodrigueznatal-lisp-pubsub] = [I-D.rodrigueznatal-lisp-pubsub]
= Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., = Rodriguez-Natal, A., Ermagan, V., = Leong, J., Maino, F.,
= Cabellos-Aparicio, A., Barkai, S., and D. = Farinacci, = Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
= "Publish-Subscribe mechanism for LISP", = draft- Boucadair, M., = Jacquenet, C., and s.
rodrigueznatal-lisp-pubsub-00 = (work in progress), August = = stefano.secci@lip6.fr, "Publish/Subscribe Functionality
= 2017. for LISP", draft-rodrigueznatal-lisp-pubsub-01 (work = in
= progress), October 2017.
=
= [LISP-CONS] [LISP-CONS]
= Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, = Brim, S., Chiappa, N., Farinacci, = D., Fuller, V., Lewis,
D., = and D. Meyer, "LISP-CONS: A Content distribution D., and D. Meyer, "LISP-CONS: A Content = distribution
= Overlay Network Service for LISP", Work in Progress, April = Overlay Network Service for = LISP", Work in Progress, April
= 2008. 2008.
=
= [RFC2104] Krawczyk, = H., Bellare, M., and R. Canetti, "HMAC: Keyed-
= Hashing = for Message Authentication", RFC 2104,
= DOI = 10.17487/RFC2104, February 1997,
= = <https://www.rfc-editor.org/info/rfc2104>.
=
= [RFC6234] Eastlake = 3rd, D. and T. Hansen, "US Secure Hash Algorithms
= (SHA and = SHA-based HMAC and HKDF)", RFC 6234,
= DOI = 10.17487/RFC6234, May 2011,
= = <https://www.rfc-editor.org/info/rfc6234>.
=
= [RFC7348] = Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
= L., = Sridhar, T., Bursell, M., and C. Wright, "Virtual
= = eXtensible Local Area Network (VXLAN): A Framework for
= = Overlaying Virtualized Layer 2 Networks over Layer 3
= = Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
= = <https://www.rfc-editor.org/info/rfc7348>.
=
= [RFC7835] Saucez, = D., Iannone, L., and O. Bonaventure, "Locator/ID
= = Separation Protocol (LISP) Threat Analysis", RFC 7835,
= DOI = 10.17487/RFC7835, April 2016,
= = <https://www.rfc-editor.org/info/rfc7835>.
= =
Appendix A. = Acknowledgments Appendix A. = Acknowledgments
=
The authors = would like to thank Greg Schudel, Darrel Lewis, John The authors would like to thank Greg Schudel, Darrel = Lewis, John
Zwiebel, = Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, = Zwiebel, Andrew Partan, Dave Meyer, Isidor = Kouvelas, Jesper Skriver,
Fabio Maino, = and members of the lisp@ietf.org mailing list for their = Fabio Maino, and members of the = lisp@ietf.org mailing list for their
feedback and = helpful suggestions. feedback and = helpful suggestions.
=
Special thanks = are due to Noel Chiappa for his extensive work on Special thanks are due to Noel Chiappa for his = extensive work on
caching with = LISP-CONS, some of which may be used by Map-Resolvers. caching with LISP-CONS, some of which may be used by = Map-Resolvers.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6833bis-06 B.1. = Changes to draft-ietf-lisp-rfc6833bis-07
=
= o Posted December = 2017.
=
= o Make it more = clear in a couple of places that RLOCs are used to
= locate ETRs more = so than for Map-Server Map-Request forwarding.
=
= o Make it clear = that "encapsualted" for a control message is an ECM
= based = message.
=
= o Make it more = clear what messages use source-port 4342 and which
= ones use = destinatino-port 4342.
=
= o Don't make DDT = references when the mapping transport system can be
= of any type and = the referneced text is general to it.
=
= o Generalize text = when referring to the format of an EID-prefix.
= Can use othe AFIs = then IPv4 and IPv6.
=
= o Many editorial = changes to clarify text.
=
= o Changed some = "must", "should", and "may" to capitalized.
=
= o Added definitions = for Map-Request and Map-Reply messages.
=
= o Ran document = through IDNITs.
=
= B.2. Changes to = draft-ietf-lisp-rfc6833bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Spec the = I-bit to include the xTR-ID in a Map-Request message to = o Spec the I-bit to include the xTR-ID in a = Map-Request message to
be = consistent with the Map-Register message and to anticipate the = be consistent with the Map-Register = message and to anticipate the
= introduction of pubsub functionality to allow Map-Requests to = introduction of pubsub functionality to = allow Map-Requests to
subscribe = to RLOC-set changes. subscribe = to RLOC-set changes.
=
o Updated = references for individual submissions that became working = o Updated references for individual = submissions that became working
group = documents. group = documents.
=
o Updated = references for working group documents that became RFCs. = o Updated references for working group = documents that became RFCs.
=
B.2. Changes to = draft-ietf-lisp-rfc6833bis-05 B.3. Changes to = draft-ietf-lisp-rfc6833bis-05
=
o Posted May = 2017. o Posted May 2017.
=
o Update IANA = Considerations section based on new requests from this o Update IANA Considerations section based on new = requests from this
document = and changes from what was requested in [RFC6830]. document and changes from what was requested in = [RFC6830].
=
B.3. Changes to = draft-ietf-lisp-rfc6833bis-04 B.4. Changes to = draft-ietf-lisp-rfc6833bis-04
=
o Posted May = 2017. o Posted May 2017.
=
o Clarify how = the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in = Map-Register and Map-
Notify = messages. Break the 16-bit field into a 8-bit Key-ID field = Notify messages. Break the 16-bit field = into a 8-bit Key-ID field
and a 8-bit = Algorithm-ID field. and a 8-bit = Algorithm-ID field.
=
o Move the = control-plane codepoints from the IANA Considerations o Move the control-plane codepoints from the IANA = Considerations
section of = RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations = section of this
= document. document.
=
o In the = "LISP Control Packet Type Allocations" section, indicate = o In the "LISP Control Packet Type = Allocations" section, indicate
how message = Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how = experimental RFC8113
sub-types = should be requested. sub-types = should be requested.
=
B.4. Changes to = draft-ietf-lisp-rfc6833bis-03 B.5. Changes to = draft-ietf-lisp-rfc6833bis-03
=
o Posted = April 2017. o Posted April = 2017.
=
o Add types = 9-14 and specify they are not assigned. = o Add types 9-14 and specify they are not assigned.
=
o Add the = "LISP Shared Extension Message" type and point to RFC8113. = o Add the "LISP Shared Extension Message" = type and point to RFC8113.
=
B.5. Changes to = draft-ietf-lisp-rfc6833bis-02 B.6. Changes to = draft-ietf-lisp-rfc6833bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Clarify = that the LISP control-plane document defines how the LISP = o Clarify that the LISP control-plane = document defines how the LISP
data-plane = uses Map-Requests with either the SMR-bit set or the data-plane uses Map-Requests with either the = SMR-bit set or the
P-bit set = supporting mapping updates and RLOC-probing. Indicating = P-bit set supporting mapping updates and = RLOC-probing. Indicating
that other = data-planes can use the same mechanisms or their own that other data-planes can use the same mechanisms = or their own
defined = mechanisms to achieve the same functionality. defined mechanisms to achieve the same = functionality.
=
B.6. Changes to = draft-ietf-lisp-rfc6833bis-01 B.7. Changes to = draft-ietf-lisp-rfc6833bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Remove = references to self. o Remove = references to self.
=
o Change = references from RFC6830 to RFC6830bis. = o Change references from RFC6830 to RFC6830bis.
=
o Add two new = action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has = posted to the LISP
WG mailing = list. WG mailing list.
=
o In intro = section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to = I-D.ietf-lisp-introduction.
=
o Removed = Open Issues section and references to "experimental". o Removed Open Issues section and references to = "experimental".
=
B.7. Changes to = draft-ietf-lisp-rfc6833bis-00 B.8. Changes to = draft-ietf-lisp-rfc6833bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6833-00 = individual submission. No other changes made. -rfc6833-00 individual submission. No other = changes made.
=
B.8. Changes to = draft-farinacci-lisp-rfc6833bis-00 B.9. Changes to = draft-farinacci-lisp-rfc6833bis-00
=
o Posted = November 2016. o Posted November = 2016.
=
o This is the = initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into = RFC 6833bis.
=
o The = document name has changed from the "Locator/ID Separation = o The document name has changed from the = "Locator/ID Separation
Protocol = (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the = "Locator/ID
Separation = Protocol (LISP) Control-Plane". = Separation Protocol (LISP) Control-Plane".
=
o The = fundamental change was to move the control-plane messages from = o The fundamental change was to move the = control-plane messages from
 End of changes. 106 change = blocks. 
227 lines changed or = deleted 285 lines changed or = added

This = html diff was produced by rfcdiff 1.46. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_3BEB5D08-F895-4DF2-B8D8-8F47EE2AA29A Content-Disposition: attachment; filename=draft-ietf-lisp-rfc6833bis-07.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-rfc6833bis-07.txt" Content-Transfer-Encoding: quoted-printable Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Standards Track Cisco Systems Expires: June 18, 2018 A. Cabellos (Ed.) UPC/BarcelonaTech December 15, 2017 Locator/ID Separation Protocol (LISP) Control-Plane draft-ietf-lisp-rfc6833bis-07 Abstract This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this control-plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 18, 2018. Fuller, et al. Expires June 18, 2018 [Page 1] =0C Internet-Draft LISP Control-Plane December 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 6. Interactions with Other LISP Components . . . . . . . . . . . 28 6.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 28 6.2. EID-Prefix Configuration and ETR Registration . . . . . . 29 6.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 31 6.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 31 6.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8.1. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 33 8.2. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 33 8.3. LISP Address Type Codes . . . . . . . . . . . . . . . . . 34 8.4. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 B.1. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 39 Fuller, et al. Expires June 18, 2018 [Page 2] =0C Internet-Draft LISP Control-Plane December 2017 B.2. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 39 B.3. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 40 B.6. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 40 B.7. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 41 B.9. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: Endpoint IDs (EIDs), used within sites; and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. Several such databases have been proposed; among them are the Content distribution Overlay Network Service for LISP (LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111]. The LISP Mapping Service defines two new types of LISP-speaking devices: the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping database; and the Map-Server, which learns authoritative EID- to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes them in a database. This LISP Control-Plane Mapping Service can be used by many different encapsulation-based or translation-based data-planes which include but are not limited to the ones defined in LISP RFC 6830bis [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN [RFC7348], and VXLAN-GPE [I-D.quinn-vxlan-gpe]. Conceptually, LISP Map-Servers share some of the same basic configuration and maintenance properties as Domain Name System (DNS) [RFC1035] servers; likewise, Map-Resolvers are conceptually similar to DNS caching resolvers. With this in mind, this specification borrows familiar terminology (resolver and server) from the DNS specifications. Note that while this document assumes a LISP+ALT database mapping infrastructure to illustrate certain aspects of Map-Server and Map- Fuller, et al. Expires June 18, 2018 [Page 3] =0C Internet-Draft LISP Control-Plane December 2017 Resolver operation, the Mapping Service interface can (and likely will) be used by ITRs and ETRs to access other mapping database systems as the LISP infrastructure evolves. The LISP Mapping Service is an important component of the LISP toolset. Issues and concerns about the deployment of LISP for Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis]. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms Map-Server: A network infrastructure component that learns of EID- Prefix mapping entries from an ETR, via the registration mechanism described below, or some other authoritative source if one exists. A Map-Server publishes these EID-Prefixes in a mapping database. Map-Request: A LISP Map-Request is a control-plane message to query the mapping system to resolve an EID. A LISP Map-Request can also be sent to an RLOC to test for reachability and to exchange security keys between an encapsulator and a decapsulator. This type of Map-Request is also known as an RLOC-Probe Request. Map-Reply: A LISP Map-Reply is a control-plane message returned in response to a Map-Request sent to the mapping system when resolving an EID. A LISP Map-Reply can also be returned by a decapsulator in response to a Map-Request sent by an encapsulator to test for reachability. This type of Map-Reply is known as a RLOC-Probe Reply. Encapsulated Map-Request: A LISP Map-Request carried within an Encapsulated Control Message (ECM), which has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR. Map-Resolver: A network infrastructure component that accepts LISP Encapsulated (ECM) Map-Requests, typically from an ITR, and determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting a mapping database system. Fuller, et al. Expires June 18, 2018 [Page 4] =0C Internet-Draft LISP Control-Plane December 2017 Negative Map-Reply: A LISP Map-Reply that contains an empty Locator-Set. Returned in response to a Map-Request if the destination EID does not exist in the mapping database. Typically, this means that the "EID" being requested is an IP address connected to a non-LISP site. Map-Register message: A LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to reach ETR(s). The Map-Server uses these RLOCs when forwarding Map-Requests (re-formatted as Encapsulated Map- Requests). An ETR MAY request that the Map-Server answer Map- Requests on its behalf by setting the "proxy Map-Reply" flag (P-bit) in the message. Map-Notify message: A LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed. An ETR requests that a Map-Notify be returned by setting the "want-map-notify" flag (M-bit) in the Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both source and destination. Map-Notify messages are also sent to ITRs by Map-Servers when there are RLOC-set changes. For definitions of other terms, notably Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), refer to the LISP Data-Plane specification [I-D.ietf-lisp-rfc6830bis]. 4. Basic Overview A Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map Request (typically from an ITR), it consults the mapping database to find an ETR that can answer with the set of RLOCs for an EID-Prefix. To publish its EID-Prefixes, an ETR periodically sends Map-Register messages to the Map-Server. A Map-Register message contains a list of EID-Prefixes plus a set of RLOCs that can be used to reach the ETRs. When LISP+ALT is used as the mapping database, a Map-Server connects to the ALT network and acts as a "last-hop" ALT-Router. Intermediate ALT-Routers forward Map-Requests to the Map-Server that advertises a particular EID-Prefix, and the Map-Server forwards them to the owning ETR, which responds with Map-Reply messages. When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server sends the final Map-Referral messages from the Delegated Database Tree. Fuller, et al. Expires June 18, 2018 [Page 5] =0C Internet-Draft LISP Control-Plane December 2017 A Map-Resolver receives Encapsulated Map-Requests from its client ITRs and uses a mapping database system to find the appropriate ETR to answer those requests. On a LISP+ALT network, a Map-Resolver acts as a "first-hop" ALT-Router. It has Generic Routing Encapsulation (GRE) tunnels configured to other ALT-Routers and uses BGP to learn paths to ETRs for different prefixes in the LISP+ALT database. The Map-Resolver uses this path information to forward Map-Requests over the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- Resolver maintains a referral-cache and acts as a "first-hop" DDT- node. The Map-Resolver uses the referral information to forward Map- Requests. Note that while it is conceivable that a Map-Resolver could cache responses to improve performance, issues surrounding cache management will need to be resolved so that doing so will be reliable and practical. As initially deployed, Map-Resolvers will operate only in a non-caching mode, decapsulating and forwarding Encapsulated Map Requests received from ITRs. Any specification of caching functionality is left for future work. Note that a single device can implement the functions of both a Map- Server and a Map-Resolver, and in many cases the functions will be co-located in that way. Also, there can be ALT-only nodes and DDT- only nodes, when LISP+ALT and LISP-DDT are used, respectively, to connect Map-Resolvers and Map-Servers together to make up the Mapping System. Detailed descriptions of the LISP packet types referenced by this document may be found in [I-D.ietf-lisp-rfc6830bis]. Fuller, et al. Expires June 18, 2018 [Page 6] =0C Internet-Draft LISP Control-Plane December 2017 5. LISP IPv4 and IPv6 Control-Plane Packet Formats The following UDP packet formats are used by the LISP control plane. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol =3D 17 | Header Checksum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Routing Locator + | | + + Fuller, et al. Expires June 18, 2018 [Page 7] =0C Internet-Draft LISP Control-Plane December 2017 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When a UDP Map-Request, Map-Register, or Map-Notify (when used as a notification message) are sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply Map-Notify (when used as an acknowledgement to a Map- Register), or Map-Notify-Ack are sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. The 'UDP Length' field will reflect the length of the UDP header and the LISP Message payload. The UDP checksum is computed and set to non-zero for all messages sent to or from port 4342. It MUST be checked on receipt, and if the checksum fails, the control message MUST be dropped. The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries. Fuller, et al. Expires June 18, 2018 [Page 8] =0C Internet-Draft LISP Control-Plane December 2017 5.1. LISP Control Packet Type Allocations This section defines the LISP control message formats and summarizes for IANA the LISP Type codes assigned by this document. For completeness, this document references the LISP Shared Extension Message assigned by [RFC8113]. Message type definitions are: Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Map-Notify: 4 b'0100' LISP Map-Notify-Ack: 5 b'0101' LISP Map-Referral: 6 b'0110' LISP Encapsulated Control Message: 8 b'1000' Not Assigned 9-14 b'1001'- b'1110' LISP Shared Extension Message: 15 b'1111' [RFC8113] Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]. Documents that request for a new LISP packet type MAY indicate a preferred value in Section 8.3. Protocol designers experimenting with new message formats SHOULD use the LISP Shared Extension Message Type and request a [RFC8113] sub- type assignment. All LISP control-plane messages use Address Family Identifiers (AFI) [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to encode either fixed or variable length addresses. This includes explicit fields in each control message or part of EID-records or RLOC-records in commonly formatted messages. The LISP control-plane describes how other data-planes can encode messages to support the SMR and RLOC-probing procedures of the LISP data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane specification itself does not offer such functionality and other data-planes can use their own mechanisms that do not rely on the LISP control-plane. Fuller, et al. Expires June 18, 2018 [Page 9] =0C Internet-Draft LISP Control-Plane December 2017 5.2. Map-Request Message Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-EID-AFI | Source EID Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI n | ITR-RLOC Address n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Reserved | EID mask-len | EID-Prefix-AFI | Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | EID-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Map-Reply Record ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 1 (Map-Request) A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system. M: This is the map-data-present bit. When set, it indicates that a Map-Reply Record segment is included in the Map-Request. P: This is the probe-bit, which indicates that a Map-Request SHOULD be treated as a Locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating that the Map-Reply is a Locator reachability probe reply, with the nonce copied from the Map-Request. See RLOC-Probing [I-D.ietf-lisp-rfc6830bis] for more details. S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- Request (SMRs) [I-D.ietf-lisp-rfc6830bis] for details. Fuller, et al. Expires June 18, 2018 [Page 10] =0C Internet-Draft LISP Control-Plane December 2017 p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request. s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map- Request. m: This is the LISP mobile-node m-bit. This bit is set by xTRs that operate as a mobile node as defined in [I-D.ietf-lisp-mn]. I: This is the xTR-ID bit. When this bit is set, what is appended to the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage procedures in [I-D.rodrigueznatal-lisp-pubsub] for details. Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on receipt. L: This is the local-xtr bit. It is used by an xTR in a LISP site to tell other xTRs in the same site that it is local to the site. That is, that it is part of the RLOC-set for the LISP site. D: This is the dont-map-reply bit. It is used in the SMR procedure described in [I-D.ietf-lisp-rfc6830bis]. When an xTR sends an SMR Map-Request message, it doesn't need a Map-Reply returned. When this bit is set, the receiver of the Map-Request does not return a Map-Reply. IRC: This 5-bit field is the ITR-RLOC Count, which encodes the additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier can select which destination address to use for a Map-Reply. The IRC value ranges from 0 to 31. For a value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, there are 2 ITR-RLOC addresses encoded, and so on up to 31, which encodes a total of 32 ITR-RLOC addresses. Record Count: This is the number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: This is an 8-octet random value created by the sender of the Map-Request. This nonce will be returned in the Map-Reply. The Fuller, et al. Expires June 18, 2018 [Page 11] =0C Internet-Draft LISP Control-Plane December 2017 security of the LISP mapping protocol critically depends on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. Source-EID-AFI: This is the address family of the 'Source EID Address' field. Source EID Address: This is the EID of the source host that originated the packet that caused the Map-Request. When Map- Requests are used for refreshing a Map-Cache entry or for RLOC- Probing, an AFI value 0 is used and this field is of zero length. ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' field that follows this field. ITR-RLOC Address: This is used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address of the sender of the Map-Request message. EID mask-len: This is the mask length for the EID-Prefix. EID-Prefix-AFI: This is the address family of the EID-Prefix according to [AFI] and [RFC8060]. EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the length varies and for the LCAF AFI the format is defined in [RFC8060]. When a Map- Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID-Prefix used in the Map-Request has the same mask length as the EID-Prefix returned from the site when it sent a Map-Reply message. Map-Reply Record: When the M-bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR that will receive this Map-Request to cache the data if it chooses to do so. Fuller, et al. Expires June 18, 2018 [Page 12] =0C Internet-Draft LISP Control-Plane December 2017 5.3. EID-to-RLOC UDP Map-Request Message A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure. For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry. The source address is either an IPv4 or IPv6 RLOC address, depending on whether the Map-Request is using an IPv4 or IPv6 header, respectively. In all cases, the UDP source port number for the Map-Request message is a 16-bit value selected by the ITR/PITR, and the UDP destination port number is set to the well- known destination port number 4342. A successful Map-Reply, which is one that has a nonce that matches an outstanding Map-Request nonce, will update the cached set of RLOCs associated with the EID-Prefix range. One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be placed in the 'IRC' field. The ITR MAY include all locally configured Locators in this list or just provide one locator address from each address family it supports. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP Type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map- Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be found in Section 5.8. Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Request for the same EID-Prefix be sent no more than once per second. An ITR that is configured with mapping database information (i.e., it is also an ETR) MAY optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the map-cache, it MAY originate a "verifying Map-Request", addressed to the map-requesting ITR and the ETR MAY add a Map-Cache entry. If the ETR has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for the entry, then it MAY send the "verifying Map-Request" directly to the originating Map-Request source. If the RLOC is not in the Locator- Set, then the ETR MUST send the "verifying Map-Request" to the Fuller, et al. Expires June 18, 2018 [Page 13] =0C Internet-Draft LISP Control-Plane December 2017 "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in the "piggybacked" mapping data. Fuller, et al. Expires June 18, 2018 [Page 14] =0C Internet-Draft LISP Control-Plane December 2017 5.4. Map-Reply Message Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D2 |P|E|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-Prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-Prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 2 (Map-Reply) P: This is the probe-bit, which indicates that the Map-Reply is in response to a Locator reachability probe Map-Request. The 'Nonce' field MUST contain a copy of the nonce value from the original Map-Request. See RLOC-probing [I-D.ietf-lisp-rfc6830bis] for more details. E: This bit indicates that the ETR that sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce Locator reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] for more details. S: This is the Security bit. When set to 1, the following authentication information will be appended to the end of the Map- Reply. The details of signing a Map-Reply message can be found in [I-D.ietf-lisp-sec]. Fuller, et al. Expires June 18, 2018 [Page 15] =0C Internet-Draft LISP Control-Plane December 2017 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt. Record Count: This is the number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count. Nonce: This is a 24-bit value set in a Data-Probe packet, or a 64-bit value from the Map-Request is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit value is supplied, it resides in the low-order 64 bits of the 'Nonce' field. Record TTL: This is the time in minutes the recipient of the Map- Reply will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping. Locator Count: This is the number of Locator entries. A Locator entry comprises what is labeled above as 'Loc'. The Locator count can be 0, indicating that there are no Locators for the EID- Prefix. EID mask-len: This is the mask length for the EID-Prefix. ACT: This 3-bit field describes Negative Map-Reply actions. In any other message type, these bits are set to 0 and ignored on receipt. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PITR when a destination EID matches a negative Map-Cache entry. Unassigned values SHOULD cause a Map-Cache entry to be created, and when packets match this negative cache entry, they will be dropped. The current assigned values are: (0) No-Action: The map-cache is kept alive, and no packet encapsulation occurs. Fuller, et al. Expires June 18, 2018 [Page 16] =0C Internet-Draft LISP Control-Plane December 2017 (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. (3) Drop/No-Reason: A packet that matches this map-cache entry is dropped. An ICMP Destination Unreachable message SHOULD be sent. (4) Drop/Policy-Denied: A packet that matches this map-cache entry is dropped. The reason for the Drop action is that a Map-Request for the target-EID is being policy denied by either an xTR or the mapping system. (5) Drop/Authentication-Failure: A packet that matches this map- cache entry is dropped. The reason for the Drop action is that a Map-Request for the target-EID fails an authentication verification-check by either an xTR or the mapping system. A: The Authoritative bit, when sent, is always set to 1 by an ETR. When a Map-Server is proxy Map-Replying for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-Prefix. Map-Version Number: When this 12-bit value is non-zero, the Map- Reply sender is informing the ITR what the version number is for the EID record contained in the Map-Reply. The ETR can allocate this number internally but MUST coordinate this value with other ETRs for the site. When this value is 0, there is no versioning information conveyed. The Map-Version Number can be included in Map-Request and Map-Register messages. See Map-Versioning [I-D.ietf-lisp-rfc6830bis] for more details. EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] and [RFC8060]. EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family. Priority: Each RLOC is assigned a unicast Priority. Lower values are more preferable. When multiple RLOCs have the same Priority, they MAY be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding. Weight: When priorities are the same for multiple RLOCs, the Weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match Fuller, et al. Expires June 18, 2018 [Page 17] =0C Internet-Draft LISP Control-Plane December 2017 the mapping entry. For example, if there are 4 Locators in a Locator-Set, where the Weights assigned are 30, 20, 20, and 10, the first Locator will get 37.5% of the traffic, the 2nd and 3rd Locators will get 25% of the traffic, and the 4th Locator will get 12.5% of the traffic. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to load-split the traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a suggested hash algorithm to distribute the load across Locators with the same Priority and equal Weight values. M Priority: Each RLOC is assigned a multicast Priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. For more details, see [RFC6831]. M Weight: When priorities are the same for multiple RLOCs, the Weight indicates how to balance building multicast distribution trees across multiple ITRs. The Weight is encoded as a relative weight (similar to the unicast Weights) of the total number of trees built to the source site identified by the EID-Prefix. If all Weights for a Locator-Set are equal, the receiver of the Map- Reply will decide how to distribute multicast state across ITRs. For more details, see [RFC6831]. Unused Flags: These are set to 0 when sending and ignored on receipt. L: When this bit is set, the Locator is flagged as a local Locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying for a LISP site, the L-bit is set to 0 for all Locators in this Locator-Set. p: When this bit is set, an ETR informs the RLOC-Probing ITR that the locator address for which this bit is set is the one being RLOC- probed and MAY be different from the source address of the Map- Reply. An ITR that RLOC-probes a particular Locator MUST use this Locator for retrieving the data structure used to store the fact that the Locator is reachable. The p-bit is set for a single Locator in the same Locator-Set. If an implementation sets more than one p-bit erroneously, the receiver of the Map-Reply MUST select the first Locator. The p-bit MUST NOT be set for Locator- Set records sent in Map-Request and Map-Register messages. R: This is set when the sender of a Map-Reply has a route to the Locator in the Locator data record. This receiver MAY find this useful to know if the Locator is up but not necessarily reachable Fuller, et al. Expires June 18, 2018 [Page 18] =0C Internet-Draft LISP Control-Plane December 2017 from the receiver's point of view. See also EID-Reachability [I-D.ietf-lisp-rfc6830bis] for another way the R-bit MAY be used. Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- AFI' field) assigned to an ETR. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router) and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. 5.5. EID-to-RLOC UDP Map-Reply Message A Map-Reply returns an EID-Prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requester's perspective. Separate testing of path reachability is required. See RLOC-reachability [I-D.ietf-lisp-rfc6830bis] for details. Note that a Map-Reply MAY contain different EID-Prefix granularity (prefix + length) than the Map-Request that triggers it. This might occur if a Map-Request were for a prefix that had been returned by an earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-Prefixes that are covered by a Map- Reply containing one less-specific prefix replaces the entry with the less-specific EID-Prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur, not by removing the less-specific prefix but rather by adding the more-specific prefixes that, during a lookup, will override the less-specific prefix. When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], the database mapping system may have overlapping EID-prefixes. Or when a LISP site is configured with multiple sets of ETRs that support different EID-prefix lengths, the database mapping system may have overlapping EID-prefixes. When overlapping EID-prefixes exist, a Map-Request with an EID that best matches any EID-Prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-Prefixes: Fuller, et al. Expires June 18, 2018 [Page 19] =0C Internet-Draft LISP Control-Plane December 2017 10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-Prefix of 10.1.1.0/24. A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Note that not all overlapping EID-Prefixes need to be returned but only the more-specific entries (note that in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the matching EID-Prefix of the requesting EID. When more than one EID- Prefix is returned, all SHOULD use the same Time to Live value so they can all time out at the same time. When a more-specific EID- Prefix is received later, its Time to Live value in the Map-Reply record can be stored even when other less-specific entries exist. When a less-specific EID-Prefix is received later, its map-cache expiration time SHOULD be set to the minimum expiration time of any more-specific EID-Prefix in the map-cache. This is done so the integrity of the EID-Prefix set is wholly maintained and so no more- specific entries are removed from the map-cache while keeping less- specific entries. Map-Replies SHOULD be sent for an EID-Prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-Prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range, thereby reducing the number of Map-Request messages. Map-Reply records can have an empty Locator-Set. A Negative Map- Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies convey special actions by the sender to the ITR or PITR that have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PITR when a destination is for a LISP site versus a non-LISP site, and the other is to source quench Map-Requests that are sent for non-allocated EIDs. For each Map-Reply record, the list of Locators in a Locator-Set MUST appear in the same order for each ETR that originates a Map-Reply message. The Locator-Set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. Fuller, et al. Expires June 18, 2018 [Page 20] =0C Internet-Draft LISP Control-Plane December 2017 When sending a Map-Reply message, the destination address is copied from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can choose a locator address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message that is invoking the reply. The source address of the Map-Reply is one of the local IP addresses chosen to allow Unicast Reverse Path Forwarding (uRPF) checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data-Probe, and the source port of the Map-Reply message is set to the well-known UDP port 4342. Fuller, et al. Expires June 18, 2018 [Page 21] =0C Internet-Draft LISP Control-Plane December 2017 5.6. Map-Register Message Format This section specifies the encoding format for the Map-Register message. The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. The Map-Register message format is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D3 |P|S|I| Reserved |E|T|a|m|M| Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Algorithm ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-Prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-Prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 3 (Map-Register) P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a Map-Register message requesting the Map-Server to proxy a Map- Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR. S: This is the security-capable bit. When set, the procedures from [I-D.ietf-lisp-sec] are supported. Fuller, et al. Expires June 18, 2018 [Page 22] =0C Internet-Draft LISP Control-Plane December 2017 I: This is the xTR-ID bit. When this bit is set, what is appended to the Map-Register is a 128-bit xTR router-ID and then a 64-bit site-ID. See LISP NAT-Traversal procedures in [I-D.ermagan-lisp-nat-traversal] for details. Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt. E: This is the Map-Register EID-notify bit. This is used by a First- Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify based Map-Register is sent by the FHR to the same site xTR that propogates the Map-Register to the mapping system. The site xTR keeps state to later Map-Notify the FHR after the EID has moves away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. T: This is the use-TTL for timeout bit. When set to 1, the xTR wants the Map-Server to time out registrations based on the value in the "Record TTL" field of this message. a: This is the merge-request bit. When set to 1, the xTR requests to merge RLOC-records from different xTRs registering the same EID- record. See signal-free multicast [I-D.ietf-lisp-signal-free-multicast] for one use case example. m: This is the mobile-node bit. When set to 1, the registering xTR supports the procedures in [I-D.ietf-lisp-mn]. M: This is the want-map-notify bit. When set to 1, an ETR is requesting a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to acknowledge receipt of a Map-Register message. Record Count: This is the number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count. Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages if no Map-Notify message is expected to acknowledge it. Since the Map-Register message is authenticated, the 'Nonce' field is not currently used for any security function but MAY be in the future as part of an anti-replay solution. Key ID: This is a configured key-id value that corresponds to a shared-secret password that is used to authenticate the sender. Multiple shared-secrets can be used to roll over keys in a non- disruptive way. Fuller, et al. Expires June 18, 2018 [Page 23] =0C Internet-Draft LISP Control-Plane December 2017 Algorithm ID: This is the configured Message Authentication Code (MAC) algorithm value used for the authentication function. See Algorithm ID Numbers in the Section 8.3 for codepoint assignments. Authentication Data Length: This is the length in octets of the 'Authentication Data' field that follows this field. The length of the 'Authentication Data' field is dependent on the MAC algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: This is the message digest used from the output of the MAC algorithm. The entire Map-Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404], and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. The definition of the rest of the Map-Register can be found in Section 5.4. Fuller, et al. Expires June 18, 2018 [Page 24] =0C Internet-Draft LISP Control-Plane December 2017 5.7. Map-Notify/Map-Notify-Ack Message Format This section specifies the encoding format for the Map-Notify and Map-Notify-Ack messages. The messages are sent inside a UDP packet with source and destination UDP ports equal to 4342. The Map-Notify and Map-Notify-Ack message formats are: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D4/5| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Algorithm ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-Prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-Prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 4/5 (Map-Notify/Map-Notify-Ack) The Map-Notify message has the same contents as a Map-Register message. See the Map-Register section for field descriptions. The Map-Notify-Ack message has the same contents as a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify and for the sender to stop retransmitting a Map-Notify with the same nonce. Fuller, et al. Expires June 18, 2018 [Page 25] =0C Internet-Draft LISP Control-Plane December 2017 5.8. Encapsulated Control Message Format An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 |S|D|E|M| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non- zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message", and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the 'Reserved' field. Type: 8 (Encapsulated Control Message (ECM)) S: This is the Security bit. When set to 1, the procedures from [I-D.ietf-lisp-sec] are followed. Fuller, et al. Expires June 18, 2018 [Page 26] =0C Internet-Draft LISP Control-Plane December 2017 D: This is the DDT-bit. When set to 1, the sender is requesting a Map-Referral message to be returned. The details of this procedure are described in [RFC8111]. E: This is the to-ETR bit. When set to 1, the Map-Server's intention is to forward the ECM to an authoritative ETR. M: This is the to-MS bit. When set to 1, a Map-Request is being sent to a co-located Map-Resolver and Map-Server where the message can be processed directly by the Map-Server versus the Map-Resolver using the LISP-DDT procedures in [RFC8111]. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format, the destination address in this header is an EID. UDP: The inner UDP header, where the port assignments depend on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is selected by the ITR/PITR and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages are allowed to be control-plane (ECM) encapsulated. In the future, PIM Join/Prune messages [RFC6831] might be allowed. Encapsulating other types of LISP control messages is for further study. When Map-Requests are sent for RLOC-Probing purposes (i.e., the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. Fuller, et al. Expires June 18, 2018 [Page 27] =0C Internet-Draft LISP Control-Plane December 2017 6. Interactions with Other LISP Components 6.1. ITR EID-to-RLOC Mapping Resolution An ITR is configured with one or more Map-Resolver addresses. These addresses are "Locators" (or RLOCs) and MUST be routable on the underlying core network; they MUST NOT need to be resolved through LISP EID-to-RLOC mapping, as that would introduce a circular dependency. When using a Map-Resolver, an ITR does not need to connect to any other database mapping system. In particular, the ITR need not connect to the LISP+ALT infrastructure or implement the BGP and GRE protocols that it uses. An ITR sends an Encapsulated Map-Request to a configured Map-Resolver when it needs an EID-to-RLOC mapping that is not found in its local map-cache. Using the Map-Resolver greatly reduces both the complexity of the ITR implementation and the costs associated with its operation. In response to an Encapsulated Map-Request, the ITR can expect one of the following: o An immediate Negative Map-Reply (with action code of "Natively- Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if the Map-Resolver can determine that the requested EID does not exist. The ITR saves the EID-Prefix returned in the Map-Reply in its cache, marks it as non-LISP-capable, and knows not to attempt LISP encapsulation for destinations matching it. o A Negative Map-Reply, with action code of "Natively-Forward", from a Map-Server that is authoritative for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific ID-prefix. In this case, the requested EID is said to match a "hole" in the authoritative EID-Prefix. If the requested EID matches a more-specific EID-Prefix that has been delegated by the Map-Server but for which no ETRs are currently registered, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it is not a LISP EID and a 15-minute TTL is returned. See Section 6.2 for discussion of aggregate EID-Prefixes and details of Map-Server EID-Prefix matching. o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or possibly from a Map-Server answering on behalf of the ETR. See Section 6.4 for more details on Map-Resolver message processing. Note that an ITR MAY be configured to both use a Map-Resolver and to participate in a LISP+ALT logical network. In such a situation, the Fuller, et al. Expires June 18, 2018 [Page 28] =0C Internet-Draft LISP Control-Plane December 2017 ITR SHOULD send Map-Requests through the ALT network for any EID- Prefix learned via ALT BGP. Such a configuration is expected to be very rare, since there is little benefit to using a Map-Resolver if an ITR is already using LISP+ALT. There would be, for example, no need for such an ITR to send a Map-Request to a possibly non-existent EID (and rely on Negative Map-Replies) if it can consult the ALT database to verify that an EID-Prefix is present before sending that Map-Request. 6.2. EID-Prefix Configuration and ETR Registration An ETR publishes its EID-Prefixes on a Map-Server by sending LISP Map-Register messages. A Map-Register message includes authentication data, so prior to sending a Map-Register message, the ETR and Map-Server SHOULD be configured with a shared secret or other relevant authentication information. A Map-Server's configuration SHOULD also include a list of the EID-Prefixes for which each ETR is authoritative. Upon receipt of a Map-Register from an ETR, a Map- Server accepts only EID-Prefixes that are configured for that ETR. Failure to implement such a check would leave the mapping system vulnerable to trivial EID-Prefix hijacking attacks. As developers and operators gain experience with the mapping system, additional, stronger security measures MAY be added to the registration process. In addition to the set of EID-Prefixes defined for each ETR that MAY register, a Map-Server is typically also configured with one or more aggregate prefixes that define the part of the EID numbering space assigned to it. When LISP+ALT is the database in use, aggregate EID- Prefixes are implemented as discard routes and advertised into ALT BGP. The existence of aggregate EID-Prefixes in a Map-Server's database means that it MAY receive Map Requests for EID-Prefixes that match an aggregate but do not match a registered prefix; Section 6.3 describes how this is handled. Map-Register messages are sent periodically from an ETR to a Map- Server with a suggested interval between messages of one minute. A Map-Server SHOULD time out and remove an ETR's registration if it has not received a valid Map-Register message within the past three minutes. When first contacting a Map-Server after restart or changes to its EID-to-RLOC database mappings, an ETR MAY initially send Map-Register messages at an increased frequency, up to one every 20 seconds. This "quick registration" period is limited to five minutes in duration. An ETR MAY request that a Map-Server explicitly acknowledge receipt and processing of a Map-Register message by setting the "want-map- notify" (M-bit) flag. A Map-Server that receives a Map-Register with this flag set will respond with a Map-Notify message. Typical use of Fuller, et al. Expires June 18, 2018 [Page 29] =0C Internet-Draft LISP Control-Plane December 2017 this flag by an ETR would be to set it for Map-Register messages sent during the initial "quick registration" with a Map-Server but then set it only occasionally during steady-state maintenance of its association with that Map-Server. Note that the Map-Notify message is sent to UDP destination port 4342, not to the source port specified in the original Map-Register message. Note that a one-minute minimum registration interval during maintenance of an ETR-Map-Server association places a lower bound on how quickly and how frequently a mapping database entry can be updated. This MAY have implications for what sorts of mobility can be supported directly by the mapping system; shorter registration intervals or other mechanisms might be needed to support faster mobility in some cases. For a discussion on one way that faster mobility MAY be implemented for individual devices, please see [I-D.ietf-lisp-mn]. An ETR MAY also request, by setting the "proxy Map-Reply" flag (P-bit) in the Map-Register message, that a Map-Server answer Map- Requests instead of forwarding them to the ETR. See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets certain flags (such as those indicating whether the message is authoritative and how returned Locators SHOULD be treated) when sending a Map-Reply on behalf of an ETR. When an ETR requests proxy reply service, it SHOULD include all RLOCs for all ETRs for the EID- Prefix being registered, along with the routable flag ("R-bit") setting for each RLOC. The Map-Server includes all of this information in Map-Reply messages that it sends on behalf of the ETR. This differs from a non-proxy registration, since the latter need only provide one or more RLOCs for a Map-Server to use for forwarding Map-Requests; the registration information is not used in Map- Replies, so it being incomplete is not incorrect. An ETR that uses a Map-Server to publish its EID-to-RLOC mappings does not need to participate further in the mapping database protocol(s). When using a LISP+ALT mapping database, for example, this means that the ETR does not need to implement GRE or BGP, which greatly simplifies its configuration and reduces its cost of operation. Note that use of a Map-Server does not preclude an ETR from also connecting to the mapping database (i.e., it could also connect to the LISP+ALT network), but doing so doesn't seem particularly useful, as the whole purpose of using a Map-Server is to avoid the complexity of the mapping database protocols. Fuller, et al. Expires June 18, 2018 [Page 30] =0C Internet-Draft LISP Control-Plane December 2017 6.3. Map-Server Processing Once a Map-Server has EID-Prefixes registered by its client ETRs, it can accept and process Map-Requests for them. In response to a Map-Request (received over the ALT if LISP+ALT is in use), the Map-Server first checks to see if the destination EID matches a configured EID-Prefix. If there is no match, the Map- Server returns a Negative Map-Reply with action code "Natively- Forward" and a 15-minute TTL. This MAY occur if a Map Request is received for a configured aggregate EID-Prefix for which no more- specific EID-Prefix exists; it indicates the presence of a non-LISP "hole" in the aggregate EID-Prefix. Next, the Map-Server checks to see if any ETRs have registered the matching EID-Prefix. If none are found, then the Map-Server returns a Negative Map-Reply with action code "Natively-Forward" and a 1-minute TTL. If any of the registered ETRs for the EID-Prefix have requested proxy reply service, then the Map-Server answers the request instead of forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, and other information learned through the registration process. If none of the ETRs have requested proxy reply service, then the Map- Server re-encapsulates and forwards the resulting Encapsulated Map- Request to one of the registered ETRs. It does not otherwise alter the Map-Request, so any Map-Reply sent by the ETR is returned to the RLOC in the Map-Request, not to the Map-Server. Unless also acting as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; any such messages SHOULD be discarded without response, perhaps accompanied by the logging of a diagnostic message if the rate of Map-Replies is suggestive of malicious traffic. 6.4. Map-Resolver Processing Upon receipt of an Encapsulated Map-Request, a Map-Resolver decapsulates the enclosed message and then searches for the requested EID in its local database of mapping entries (statically configured or learned from associated ETRs if the Map-Resolver is also a Map- Server offering proxy reply service). If it finds a matching entry, it returns a LISP Map-Reply with the known mapping. If the Map-Resolver does not have the mapping entry and if it can determine that the EID is not in the mapping database (for example, if LISP+ALT is used, the Map-Resolver will have an ALT forwarding table that covers the full EID space), it immediately returns a negative LISP Map-Reply, with action code "Natively-Forward" and a Fuller, et al. Expires June 18, 2018 [Page 31] =0C Internet-Draft LISP Control-Plane December 2017 15-minute TTL. To minimize the number of negative cache entries needed by an ITR, the Map-Resolver SHOULD return the least-specific prefix that both matches the original query and does not match any EID-Prefix known to exist in the LISP-capable infrastructure. If the Map-Resolver does not have sufficient information to know whether the EID exists, it needs to forward the Map-Request to another device that has more information about the EID being requested. To do this, it forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, to the mapping database system. Using LISP+ALT, the Map-Resolver is connected to the ALT network and sends the Map-Request to the next ALT hop learned from its ALT BGP neighbors. The Map-Resolver does not send any response to the ITR; since the source RLOC is that of the ITR, the ETR or Map- Server that receives the Map-Request over the ALT and responds will do so directly to the ITR. 6.4.1. Anycast Map-Resolver Operation A Map-Resolver can be set up to use "anycast", where the same address is assigned to multiple Map-Resolvers and is propagated through IGP routing, to facilitate the use of a topologically close Map-Resolver by each ITR. Note that Map-Server associations with ETRs SHOULD NOT use anycast addresses, as registrations need to be established between an ETR and a specific set of Map-Servers, each identified by a specific registration association. 7. Security Considerations The 2-way LISP header nonce exchange documented in [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks. To publish an authoritative EID-to-RLOC mapping with a Map-Server, an ETR includes authentication data that is a hash of the message using a pair-wise shared key. An implementation MUST support use of HMAC- SHA-1-96 [RFC2104] and SHOULD support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 bits). As noted in Section 6.2, a Map-Server SHOULD verify that all EID- Prefixes registered by an ETR match the configuration stored on the Map-Server. The currently defined authentication mechanism for Map-Register messages does not provide protection against "replay" attacks by a "man-in-the-middle". Additional work is needed in this area. Fuller, et al. Expires June 18, 2018 [Page 32] =0C Internet-Draft LISP Control-Plane December 2017 [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin authentication, integrity, anti-replay protection, and prevention of man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- Reply exchange. Work is ongoing on this and other proposals for resolving these open security issues. While beyond the scope of securing an individual Map-Server or Map- Resolver, it SHOULD be noted that a BGP-based LISP+ALT network (if ALT is used as the mapping database infrastructure) can take advantage of standards work on adding security to BGP. A complete LISP threat analysis has been published in [RFC7835]. Please refer to it for more security related details. 8. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this LISP control-plane specification, in accordance with BCP 26 [RFC8126]. There are three namespaces (listed in the sub-sections below) in LISP that have been registered. o LISP IANA registry allocations SHOULD NOT be made for purposes unrelated to LISP routing or transport protocols. o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served". 8.1. LISP Packet Type Codes It is being requested that the IANA be authoritative for LISP Packet Type definitions and that it refers to this document as well as [RFC8113] as references. Based on deployment experience of [RFC6830], the Map-Notify-Ack message, message type 5, was added to this document. This document requests IANA to add it to the LISP Packet Type Registry. 8.2. LISP ACT and Flag Fields New ACT values can be allocated through IETF review or IESG approval. Four values have already been allocated by [RFC6830]. This specification changes the name of ACT type 3 value from "Drop" to "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). Fuller, et al. Expires June 18, 2018 [Page 33] =0C Internet-Draft LISP Control-Plane December 2017 In addition, LISP has a number of flag fields and reserved fields, such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New bits for flags in these fields can be implemented after IETF review or IESG approval, but these need not be managed by IANA. 8.3. LISP Address Type Codes LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that defines LISP-specific encodings for AFI value 16387. LCAF encodings are used for specific use-cases where different address types for EID-records and RLOC-records are required. The IANA registry "LISP Canonical Address Format (LCAF) Types" is used for LCAF types, the registry for LCAF types use the Specification Required policy [RFC8126]. Initial values for the registry as well as further information can be found in [RFC8060]. Therefore, there is no longer a need for the "LISP Address Type Codes" registry requested by [RFC6830]. This document requests to remove it. 8.4. LISP Algorithm ID Numbers In [RFC6830], a request for a "LISP Key ID Numbers" registry was submitted. This document renames the registry to "LISP Algorithm ID Numbers" and requests the IANA to make the name change. The following Algorithm ID values are defined by this specification as used in any packet type that references a 'Algorithm ID' field: Name Number Defined in ----------------------------------------------- None 0 n/a HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-256-128 2 [RFC4868] Number values are in the range of 0 to 255. The allocation of values is on a first come first served basis. 9. References 9.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Fuller, et al. Expires June 18, 2018 [Page 34] =0C Internet-Draft LISP Control-Plane December 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/RFC6837, January 2013, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, . Fuller, et al. Expires June 18, 2018 [Page 35] =0C Internet-Draft LISP Control-Plane December 2017 [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations", RFC 8113, DOI 10.17487/RFC8113, March 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . 9.2. Informative References [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/assignments/address-family- numbers/address-family-numbers.xhtml?, Febuary 2007. [I-D.ermagan-lisp-nat-traversal] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan- lisp-nat-traversal-13 (work in progress), September 2017. [I-D.ietf-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-ietf-lisp-eid-mobility-01 (work in progress), November 2017. [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-lisp-mn] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", draft-ietf-lisp-mn-01 (work in progress), October 2017. [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-rfc6830bis-07 (work in progress), November 2017. Fuller, et al. Expires June 18, 2018 [Page 36] =0C Internet-Draft LISP Control-Plane December 2017 [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 (work in progress), October 2017. [I-D.ietf-lisp-signal-free-multicast] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", draft-ietf-lisp-signal-free-multicast-07 (work in progress), November 2017. [I-D.lewis-lisp-gpe] Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P., Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol Extension", draft-lewis-lisp-gpe-04 (work in progress), December 2017. [I-D.quinn-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P., and D. Melman, "Generic Protocol Extension for VXLAN", draft-quinn-vxlan-gpe-04 (work in progress), February 2015. [I-D.rodrigueznatal-lisp-pubsub] Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Boucadair, M., Jacquenet, C., and s. stefano.secci@lip6.fr, "Publish/Subscribe Functionality for LISP", draft-rodrigueznatal-lisp-pubsub-01 (work in progress), October 2017. [LISP-CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . Fuller, et al. Expires June 18, 2018 [Page 37] =0C Internet-Draft LISP Control-Plane December 2017 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . Fuller, et al. Expires June 18, 2018 [Page 38] =0C Internet-Draft LISP Control-Plane December 2017 Appendix A. Acknowledgments The authors would like to thank Greg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, Fabio Maino, and members of the lisp@ietf.org mailing list for their feedback and helpful suggestions. Special thanks are due to Noel Chiappa for his extensive work on caching with LISP-CONS, some of which may be used by Map-Resolvers. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-rfc6833bis-07 o Posted December 2017. o Make it more clear in a couple of places that RLOCs are used to locate ETRs more so than for Map-Server Map-Request forwarding. o Make it clear that "encapsualted" for a control message is an ECM based message. o Make it more clear what messages use source-port 4342 and which ones use destinatino-port 4342. o Don't make DDT references when the mapping transport system can be of any type and the referneced text is general to it. o Generalize text when referring to the format of an EID-prefix. Can use othe AFIs then IPv4 and IPv6. o Many editorial changes to clarify text. o Changed some "must", "should", and "may" to capitalized. o Added definitions for Map-Request and Map-Reply messages. o Ran document through IDNITs. B.2. Changes to draft-ietf-lisp-rfc6833bis-06 o Posted October 2017. o Spec the I-bit to include the xTR-ID in a Map-Request message to be consistent with the Map-Register message and to anticipate the Fuller, et al. Expires June 18, 2018 [Page 39] =0C Internet-Draft LISP Control-Plane December 2017 introduction of pubsub functionality to allow Map-Requests to subscribe to RLOC-set changes. o Updated references for individual submissions that became working group documents. o Updated references for working group documents that became RFCs. B.3. Changes to draft-ietf-lisp-rfc6833bis-05 o Posted May 2017. o Update IANA Considerations section based on new requests from this document and changes from what was requested in [RFC6830]. B.4. Changes to draft-ietf-lisp-rfc6833bis-04 o Posted May 2017. o Clarify how the Key-ID field is used in Map-Register and Map- Notify messages. Break the 16-bit field into a 8-bit Key-ID field and a 8-bit Algorithm-ID field. o Move the control-plane codepoints from the IANA Considerations section of RFC6830bis to the IANA Considerations section of this document. o In the "LISP Control Packet Type Allocations" section, indicate how message Types are IANA allocated and how experimental RFC8113 sub-types should be requested. B.5. Changes to draft-ietf-lisp-rfc6833bis-03 o Posted April 2017. o Add types 9-14 and specify they are not assigned. o Add the "LISP Shared Extension Message" type and point to RFC8113. B.6. Changes to draft-ietf-lisp-rfc6833bis-02 o Posted April 2017. o Clarify that the LISP control-plane document defines how the LISP data-plane uses Map-Requests with either the SMR-bit set or the P-bit set supporting mapping updates and RLOC-probing. Indicating that other data-planes can use the same mechanisms or their own defined mechanisms to achieve the same functionality. Fuller, et al. Expires June 18, 2018 [Page 40] =0C Internet-Draft LISP Control-Plane December 2017 B.7. Changes to draft-ietf-lisp-rfc6833bis-01 o Posted March 2017. o Include references to new RFCs published. o Remove references to self. o Change references from RFC6830 to RFC6830bis. o Add two new action/reasons to a Map-Reply has posted to the LISP WG mailing list. o In intro section, add refernece to I-D.ietf-lisp-introduction. o Removed Open Issues section and references to "experimental". B.8. Changes to draft-ietf-lisp-rfc6833bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6833-00 individual submission. No other changes made. B.9. Changes to draft-farinacci-lisp-rfc6833bis-00 o Posted November 2016. o This is the initial draft to turn RFC 6833 into RFC 6833bis. o The document name has changed from the "Locator/ID Separation Protocol (LISP) Map-Server Interface" to the "Locator/ID Separation Protocol (LISP) Control-Plane". o The fundamental change was to move the control-plane messages from RFC 6830 to this document in an effort so any IETF developed or industry created data-plane could use the LISP mapping system and control-plane. o Update control-plane messages to incorporate what has been implemented in products during the early phase of LISP development but wasn't able to make it into RFC6830 and RFC6833 to make the Experimental RFC deadline. o Indicate there may be nodes in the mapping system that are not MRs or MSs, that is a ALT-node or a DDT-node. Fuller, et al. Expires June 18, 2018 [Page 41] =0C Internet-Draft LISP Control-Plane December 2017 o Include LISP-DDT in Map-Resolver section and explain how they maintain a referral-cache. o Removed open issue about additional state in Map-Servers. With [RFC8111], Map-Servers have the same registration state and can give Map-Resolvers complete information in ms-ack Map-Referral messages. o Make reference to the LISP Threats Analysis RFC [RFC7835]. Authors' Addresses Vince Fuller Cisco Systems EMail: vaf@vaf.net Dino Farinacci Cisco Systems EMail: farinacci@gmail.com Albert Cabellos UPC/BarcelonaTech Campus Nord, C. Jordi Girona 1-3 Barcelona, Catalunya Spain EMail: acabello@ac.upc.edu Fuller, et al. Expires June 18, 2018 [Page 42] --Apple-Mail=_3BEB5D08-F895-4DF2-B8D8-8F47EE2AA29A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_3BEB5D08-F895-4DF2-B8D8-8F47EE2AA29A-- From nobody Fri Dec 15 16:26:01 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CD0124D85 for ; Fri, 15 Dec 2017 16:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 Pqrrwx79hhg8 for ; Fri, 15 Dec 2017 16:25:57 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CCB1205D3 for ; Fri, 15 Dec 2017 16:25:56 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id o2so9411088wro.5 for ; Fri, 15 Dec 2017 16:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qTmF8jf2Twcf8Gjtix4PhvlUjlT492T7emRDxIBSg5o=; b=dmxlKik3WMexci1yNAhhqE+hbUkYObM6yazb/SxRmViu9OUkkyT6d9aj3Yk+r3N1G9 GlfZCe27o619fEky/mqTxNgq6CEIDFjCnMTxu88dIeuQ/Ff68aUqqqlvmuIwAhcvw2wF ffe4Xoh0FmXJOWC2SwFbwKm5txzWy7lM9uNio= 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=qTmF8jf2Twcf8Gjtix4PhvlUjlT492T7emRDxIBSg5o=; b=SlRwRYp7sN/sB89qyW7wRWkKN0JBaInAnYB7eNvG8LcAA3IknkxLJ6eQMuhS1l1Q+T aPnb8ZISr/1BizXHOSGhR15XGLZMBYk/TyEVVOloBuW+jH1AZ6QDKVBcW72/Ir/ChZ/G pVuJD5Wxr2zZKaKoFTRyi4xhMtujSzF48GnPK1XhTalEz5NhFWXFKHetmthIV/ISsiIw qDljIG9HmpYYfDapYKnX8Fs4sghXkNqm16HhX5N/BNm+InDjAbTupeIvglzD6+OHePXp p8i2H7eO8q7rFrnZ5nElMZEeXAM4WNWu0BbVyh63+pFg+pTmyE0tm8iLbghr5tgZH/VR sgVQ== X-Gm-Message-State: AKGB3mK5FtWRZs1xAkcpypIf07s2Clkx9lzC5bP0v12V+JzwQAPOY4e0 KCeoO+sPmCP2m9Gh3gJMLIPdr3iKa22dsuP74DgDBg== X-Google-Smtp-Source: ACJfBouI9xieTJ2+1V4sEba4/Qmq0Aee1XsgTf2wBE1BZlcpc4BmCTO6JIEoGXJHtCVuMiEC/pgat+SdHljJojx9hxo= X-Received: by 10.223.164.22 with SMTP id d22mr11911581wra.232.1513383955303; Fri, 15 Dec 2017 16:25:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.172.4 with HTTP; Fri, 15 Dec 2017 16:25:54 -0800 (PST) In-Reply-To: <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> From: John Lemon Date: Fri, 15 Dec 2017 16:25:54 -0800 Message-ID: To: Fabio Maino Cc: lisp@ietf.org Content-Type: multipart/alternative; boundary="f403045f1fa010c0a205606a29d4" Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 00:25:59 -0000 --f403045f1fa010c0a205606a29d4 Content-Type: text/plain; charset="UTF-8" I support the WG adoption of this document. Multiprotocol support to LISP is highly desired, and this provides it in a simple extension. Regards, John On Fri, Dec 15, 2017 at 8:40 AM, Fabio Maino wrote: > As an author I support the adoption of this document. > > This simple LISP dataplane extension enables multiprotocol support in > LISP. It allows use of LISP in L2 overlays, and introduces the capability > to support dataplane extensions such as Network Service Header or Group > Based Policy. > > This is bit-by-bit compatible with RFC6830bis and allows the use of > Map-Versioning and Echo-Noncing, albeit with a reduced size of the > corresponding dataplane metadata. > > An earlier version of the draft has been implemented in the FD.io ( > http://FD.io) and OOR (https://www.openoverlayrouter.org/) open source > data plane implementations. > > Thanks, > Fabio > > > > > On 12/15/17 8:23 AM, Joel Halpern wrote: > >> The authors of the lisp-gpe draft (below) have requested working group >> adoption for this document. >> >> This email starts a two week last call for working group adoption of this >> document. >> >> Please respond, positively or negatively. Silence does NOT mean >> consent. Please include explanation / motivation / reasoning for your view. >> >> Also remember that this is not a last call. Once the document is adopted >> (assuming it is), we as a working group can make changes as needed. The >> primary quesitonin this call is whether this is a good basis for work we >> want to do. >> >> Thank you, >> Joel (& Luigi) >> >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-lewis-lisp-gpe-04.txt >> Date: Fri, 15 Dec 2017 08:13:24 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : LISP Generic Protocol Extension >> Authors : Darrel Lewis >> John Lemon >> Puneet Agarwal >> Larry Kreeger >> Paul Quinn >> Michael Smith >> Navindra Yadav >> Fabio Maino >> Filename : draft-lewis-lisp-gpe-04.txt >> Pages : 8 >> Date : 2017-12-15 >> >> Abstract: >> This draft describes extending the Locator/ID Separation Protocol >> (LISP), via changes to the LISP header, to support multi-protocol >> encapsulation. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 >> https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --f403045f1fa010c0a205606a29d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the WG adoption= of this document.

Multiprotocol support to LIS= P is highly desired, and this provides it in a simple extension.

Regards, John


On Fri, Dec 15, 2017 at 8:40 AM, Fabio Maino <fmaino@cisco= .com> wrote:
As an author I= support the adoption of this document.

This simple LISP dataplane extension enables multiprotocol support in LISP.= It allows use of LISP in L2 overlays, and introduces the capability to sup= port dataplane extensions such as Network Service Header or Group Based Pol= icy.

This is bit-by-bit compatible with RFC6830bis and allows the use of Map-Ver= sioning and Echo-Noncing, albeit with a reduced size of the corresponding d= ataplane metadata.

An earlier version of the draft has been implemented in the FD.io (http://FD.io) an= d OOR (https://www.openoverlayrouter.org/) open source da= ta plane implementations.

Thanks,
Fabio




On 12/15/17 8:23 AM, Joel Halpern wrote:
The authors of the lisp-gpe draft (below) have requested working group adop= tion for this document.

This email starts a two week last call for working group adoption of this d= ocument.

Please respond, positively or negatively.=C2=A0 Silence does NOT mean conse= nt.=C2=A0 Please include explanation / motivation / reasoning for your view= .

Also remember that this is not a last call.=C2=A0 Once the document is adop= ted (assuming it is), we as a working group can make changes as needed.=C2= =A0 The primary quesitonin this call is whether this is a good basis for wo= rk we want to do.

Thank you,
Joel (& Luigi)


-------- Forwarded Message --------
Subject: I-D Action: draft-lewis-lisp-gpe-04.txt
Date: Fri, 15 Dec 2017 08:13:24 -0800
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : LISP Generic Protocol Extension
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 : Darrel Lewis
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= John Lemon
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Puneet Agarwal
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Larry Kreeger
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Paul Quinn
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Michael Smith
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Navindra Yadav
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Fabio Maino
=C2=A0=C2=A0=C2=A0=C2=A0Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = : draft-lewis-lisp-gpe-04.txt
=C2=A0=C2=A0=C2=A0=C2=A0Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 : 8
=C2=A0=C2=A0=C2=A0=C2=A0Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : 2017-12-15

Abstract:
=C2=A0=C2=A0 This draft describes extending the Locator/ID Separation Proto= col
=C2=A0=C2=A0 (LISP), via changes to the LISP header, to support multi-proto= col
=C2=A0=C2=A0 encapsulation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-le= wis-lisp-gpe/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-lewis-lisp= -gpe-04
https://datatracker.ietf.org/doc/h= tml/draft-lewis-lisp-gpe-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-lewis-lisp-gpe-04


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
Internet-Draft directories: http://www.ietf.org/shadow.html<= br> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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


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

--f403045f1fa010c0a205606a29d4-- From nobody Sun Dec 17 13:11:32 2017 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE98124B0A; Sun, 17 Dec 2017 13:11:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151354509128.25335.11751928998976564140@ietfa.amsl.com> Date: Sun, 17 Dec 2017 13:11:31 -0800 Archived-At: Subject: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 21:11:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : Locator/ID Separation Protocol (LISP) Control-Plane Authors : Vince Fuller Dino Farinacci Albert Cabellos Filename : draft-ietf-lisp-rfc6833bis-07.txt Pages : 42 Date : 2017-12-17 Abstract: This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this control-plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6833bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 18 00:09:02 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DF51201F2 for ; Mon, 18 Dec 2017 00:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 2YtXc1-dGqqj for ; Mon, 18 Dec 2017 00:08:57 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB2E1200F3 for ; Mon, 18 Dec 2017 00:08:57 -0800 (PST) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vBI88qfj009644; Mon, 18 Dec 2017 09:08:52 +0100 Received: from [147.83.35.39] (sirius.ac.upc.es [147.83.35.39]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 2D5A25AB; Mon, 18 Dec 2017 09:08:47 +0100 (CET) To: Fabio Maino , lisp@ietf.org References: <151335440470.30447.859080782552191016@ietfa.amsl.com> <3fde0530-6c0d-6ad2-6739-fddc71bcb024@joelhalpern.com> <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> From: =?UTF-8?Q?Albert_L=c3=b3pez?= Message-ID: <8487397f-ad1e-60d9-2629-c3f287a3b594@ac.upc.edu> Date: Mon, 18 Dec 2017 09:08:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7f5d72a7-ca3e-5390-0b7f-f62c53f1cc12@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ca Archived-At: Subject: Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 08:09:01 -0000 +1 Albert L. El 15/12/17 a les 17:40, Fabio Maino ha escrit: > As an author I support the adoption of this document. > > This simple LISP dataplane extension enables multiprotocol support in > LISP. It allows use of LISP in L2 overlays, and introduces the > capability to support dataplane extensions such as Network Service > Header or Group Based Policy. > > This is bit-by-bit compatible with RFC6830bis and allows the use of > Map-Versioning and Echo-Noncing, albeit with a reduced size of the > corresponding dataplane metadata. > > An earlier version of the draft has been implemented in the FD.io > (http://FD.io) and OOR (https://www.openoverlayrouter.org/) open > source data plane implementations. > > Thanks, > Fabio > > > > On 12/15/17 8:23 AM, Joel Halpern wrote: >> The authors of the lisp-gpe draft (below) have requested working >> group adoption for this document. >> >> This email starts a two week last call for working group adoption of >> this document. >> >> Please respond, positively or negatively.  Silence does NOT mean >> consent.  Please include explanation / motivation / reasoning for >> your view. >> >> Also remember that this is not a last call.  Once the document is >> adopted (assuming it is), we as a working group can make changes as >> needed.  The primary quesitonin this call is whether this is a good >> basis for work we want to do. >> >> Thank you, >> Joel (& Luigi) >> >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-lewis-lisp-gpe-04.txt >> Date: Fri, 15 Dec 2017 08:13:24 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >>         Title           : LISP Generic Protocol Extension >>         Authors         : Darrel Lewis >>                           John Lemon >>                           Puneet Agarwal >>                           Larry Kreeger >>                           Paul Quinn >>                           Michael Smith >>                           Navindra Yadav >>                           Fabio Maino >>     Filename        : draft-lewis-lisp-gpe-04.txt >>     Pages           : 8 >>     Date            : 2017-12-15 >> >> Abstract: >>    This draft describes extending the Locator/ID Separation Protocol >>    (LISP), via changes to the LISP header, to support multi-protocol >>    encapsulation. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 >> https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp -- Albert López CCABA System Administrator Universitat Politècnica de Catalunya Telf: 93 4017182 From nobody Mon Dec 18 01:40:26 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4CE127909 for ; Mon, 18 Dec 2017 01:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIvL7EOgoPtr for ; Mon, 18 Dec 2017 01:40:19 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 29579127419 for ; Mon, 18 Dec 2017 01:40:19 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id i11so27973542wmf.4 for ; Mon, 18 Dec 2017 01:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=D3gylLNadej1fzBu3ZIo8zjvztzucFgIOxixAEusw2k=; b=Evn5gRY/44viUMw5HGa35ZEC/G4E7+Ls79lVDcef10tDoF69vm6AP4zcN9ZRZoOpSy LaM5bgMIZ8cvUvrTsR5W1nkt4UTssGxMT3KQOaCl4cLOR9mKYZ/MGZvvsBV4AVex+TSg YugIQqQGuTRoJpPVIFYy6cdIFpx8p2Zt4pf5hjbplYiYvKAR0YkInPsZoXYwSzRPm3v9 8E/r/Lci+97UFP4EzGkVVN/icAOTugpoT6UflgOPdtpF2ff/cksIQGgsslbDMmB0rvFR fHAfUXMXT7mshOFQZSs5vMUtzrlzf7AqgCu4c95FYWqJkvgyMvih7kjDhzLEdv1VRhZv nhwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=D3gylLNadej1fzBu3ZIo8zjvztzucFgIOxixAEusw2k=; b=cvoUr+Lp+Rj1Qp0zE8RLZgpFXRPEr1Lk7jktADyMTKAqRzM4dtg7o4Ya1A/G3pXgmj taP6DNqUlDmPzpoqx7GunyUak8MPmoQ6bOnpIv4AhaJBLcpZ/1bIvun8ZdL/Gc+vJ49G +NDAqoWf2WlhAXrtFwSYLEX83MLnXc4uihD9IHe5kU6cYYaecwH5HYCD+FsLlVMMs0o3 raZQFapsMGpUw4jKskCk1c8AZi/cYkkzbUXXtHD83/RA6PkhTQ66KbKACIVekCAJyn0U 3k5O2HabFbOgYzRCvrcxbpliNlf0CyUo9TSEgH1MyaCL05jEd/eYSM1P7fiv5xeTyzPJ nbWQ== X-Gm-Message-State: AKGB3mKP7Vt0QPAVcv8KrNp0bntH3uyTOpeQT4IXQWONA5h42auA6SE8 nvcIq+TpnbzOS2uyfVsi70QvUQ== X-Google-Smtp-Source: ACJfBovAzRK1LPBDsyAD1iebSa2cerY9EHOnSrD6XtYfgQIbjjslqlOSlip3TEceQIu5UOtUusORYA== X-Received: by 10.80.219.136 with SMTP id p8mr28605049edk.84.1513590017391; Mon, 18 Dec 2017 01:40:17 -0800 (PST) Received: from 2a01cb0404892000dc156693c9981dfb.ipv6.abo.wanadoo.fr (2a01cb0404892000dc156693c9981dfb.ipv6.abo.wanadoo.fr. [2a01:cb04:489:2000:dc15:6693:c998:1dfb]) by smtp.gmail.com with ESMTPSA id h56sm10428936eda.97.2017.12.18.01.40.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 01:40:15 -0800 (PST) From: Luigi Iannone Message-Id: <86F3ABEE-5623-45EB-AD8F-342027FA6101@gigix.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_BE4231F2-D20D-4102-B450-46C471962B8B" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 18 Dec 2017 10:40:13 +0100 In-Reply-To: <4D2A0EA8-9096-4E12-99F9-B60910D7122E@gmail.com> Cc: "lisp@ietf.org list" , lisp-chairs@tools.ietf.org To: Dino Farinacci References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <4D2A0EA8-9096-4E12-99F9-B60910D7122E@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review (PLEASE COMMENTS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 09:40:25 -0000 --Apple-Mail=_BE4231F2-D20D-4102-B450-46C471962B8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dino, thanks for the hard work.=20 my replies inline (trimmed the points we agree or have been clarified by = your answers). @ALL: this is not a private discussion between me and Dino and I = invite all of you to chime in and provide an opinion. There one clear point here: This document is not about data-plane, is = data-plane + fragmented information that does not belong here.=20 The document can be shorter and to the point. There are a lot of OAM = information that does not belong to the data-plane. > On 17 Dec 2017, at 22:37, Dino Farinacci wrote: >=20 >> Detailed comments inline. >=20 > Thanks for your comments. A diff and txt file are enclosed at the = bottom. >=20 >> p.s. @Dino: sorry this is 07 version because I started with that = version. >=20 > No worries. >=20 >> the wording =E2=80=9Cdata-plane protocol=E2=80=9D sounds awkward to = me. I think would be better to put "data-plane operations=E2=80=9D or = even better =E2=80=9Cdata-plane specifications=E2=80=9D >> Best solution: just drop it. This document describes the data plane = of LISP. =20 >>=20 >>=20 >>> for the Locator/ID >>> Separation Protocol (LISP). LISP defines two namespaces, End-point >>> Identifiers (EIDs) that identify end-hosts and Routing Locators >>> (RLOCs) that identify network attachment points. With this, LISP >>> effectively separates control from data, and allows routers to = create >>> overlay networks. LISP-capable routers exchange encapsulated = packets >>> according to EID-to-RLOC mappings stored in a local map-cache. The >>> map-cache is populated by the LISP Control-Plane protocol >>>=20 >> Same as above for the "control-plane protocol=E2=80=9D >=20 > These are well-known terms across the industry. I would prefer to not = change them. Plus they made it through the experimental RFC-set without = opposition. It is redundant because the =E2=80=9CP=E2=80=9D in LISP that does mean = =E2=80=9Cprotocol=E2=80=9D. But this is an english nit. I can live with = the current wording. >=20 >>>=20 >>> 3. Definition of Terms >>>=20 >>=20 >> What is the order of the Terms? >>=20 >> It is not alphabetical and not logical (at least I cannot se it). >=20 > Originally it was suppose to be logical. I will double check to make = sure the terms are introduced in an obvious sequence. If I can avoid = forward-references, I will do so. >=20 I guess this is still on your to do list.=20 [snip] >=20 >>> Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling >>>=20 >> RTR have never been defined. >=20 > It is being defined right here. I=E2=80=99ll read word it. >=20 If you define it the text should read like: RTR: Re-encapsulating Tunnel Router=E2=80=A6=E2=80=A6. >>> Recursive Tunneling: Recursive Tunneling occurs when a packet has >>> more than one LISP IP header. Additional layers of tunneling = MAY >>> be employed to implement Traffic Engineering or other re-routing >>> as needed. When this is done, an additional "outer" LISP header >>> is added, and the original RLOCs are preserved in the "inner" >>> header. =20 >>>=20 >> Do not think the following sentence is really necessary. >>=20 >>=20 >>=20 >>> Any references to tunnels in this specification refer to >>> dynamic encapsulating tunnels; they are never statically >>> configured. >=20 > Well many have said that LISP tunnels are not like traditional = tunnels. Traditional tunnels are configured and provisioned. Where LISP = tunnels are dynamic and used on demand. I would like the sectiond to = stay. You can move this sentence in the intro or where it make sense to you. = In the Definition of terms is just lost. [snip] >=20 >>> Server-side: Server-side is a term used in this document to = indicate >>> that a connection initiation attempt is being accepted for a >>> destination EID. =20 >>>=20 >>=20 >>=20 >>=20 >> Rest of the paragraph not needed here. (it is specified in the = operation part of the document) >>=20 >>> The ETR(s) at the destination LISP site may be >>> the first to send Map-Replies to the source site initiating the >>> connection. The ETR(s) at this destination site can obtain >>> mappings by gleaning information from Map-Requests, Data-Probes, >>> or encapsulated packets. >=20 > Okay, reworded though. Still not needed. And you added =E2=80=9CMAY=E2=80=9D which is = pointless. Please delete. The procedures are described elsewhere in the = document.=20 >=20 >>> o Other types of EID are supported by LISP, see [RFC8060] for >>> further information. >>>=20 >> I would put the last two bullets in the definition of EID. It = simplifies the story here. >=20 > I think it should be kept in. I feel it adds value. You break the operational flow by opening a different point describing = what is what. It makes the overall procedure unclear. >=20 >>> o EID-Prefixes are likely to be hierarchically assigned in a = manner >>> that is optimized for administrative convenience and to = facilitate >>> scaling of the EID-to-RLOC mapping database. The hierarchy is >>> based on an address allocation hierarchy that is independent of >>> the network topology. >>>=20 >> Drop the last bullet it is about scalability. >=20 > Right, but still important to mention. Many of the benefits of LISP = aren=E2=80=99t always obvious. So we have to point them out. Dino, this has to go away. This is NOT the control-plane advertisement = document. This is the LISP control-plane, that=E2=80=99s all. This was agreed upon at the time of rechartering. [snip] >=20 >>> 5.1. LISP IPv4-in-IPv4 Header Format >>>=20 >>> 0 1 2 3 >>> 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 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> / |Version| IHL |Type of Service| Total Length = | >>> / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> / |Version| IHL |DSCP |ECN| Total Length = | >> / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> The correct IPv4 Header is with DSCP and ECN. Please update below as = well. >=20 > I am not sure we should change this. We are referencing the RFC791 so = good to be consistent. Go on the data tracker: https://tools.ietf.org/html/rfc791 = You will read that 791 has been updated by RFC 1349, RFC 2474, and RFC = 6864. You have to refer to these documents. Please update. >=20 >>> 5.2. LISP IPv6-in-IPv6 Header Format >>>=20 >>> 0 1 2 3 >>> 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 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> / |Version| Traffic Class | Flow Label = | >>> / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> / |Version| DSCP |ECN| Flow Label = | >> / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> The correct IPv6 Header is with DSCP and ECN. Please update below as = well. >=20 > As comment as above. As for my answer above. [snip] >> The description of the encap/decap operation lacks of clarity = concerning how to deal with=20 >> ECN bits and DSCP . >>=20 >> 1. I think that the text should make explicitly the difference = between DSCP and ECN fields. >>=20 >> 2. How to deal with ECN should be part of the description of the = encap/decap not a paragraph apart. >> This basically means that half of the last paragraph should be a = bullet of the ITR/PITR encapsulation=20 >> and the other half in the ETR/PETR operation. >=20 > We went through this with a lot of people for RFC6830. It took many = months to resolve. I dare not touch this text. You have just to move it up and separate it in two bullets. No changes = needed. >=20 >>> 9. Routing Locator Selection >>>=20 >> Large part of this section is about control plane issues and as such = should be put in 6833bis. >>=20 >> What this section should state is that priority and weight are used = to select the RLOC to use. >> Only exception is gleaning where we have one single RLOC and we do = not know neither priority nor weight. >>=20 >> All the other operational discussion goes elsewhere, but not in this = document. >=20 > We have already decided (a year ago) not to move this because its the = data-plane that needs to know about locator reachability so it knows = which locators to use. Please check the minutes of past meetings (as I did), the only unclear = point was SMR, everything else was agreed to be moved out.=20 >=20 >>> 10. Routing Locator Reachability >>>=20 >>> Several mechanisms for determining RLOC reachability are currently >>> defined: >>>=20 >> There exists data-plane based reachability mechanisms and control = plane reachability mechanisms. >> We have to keep here only the data plane based mechanism and move the = other in 6833bis. >>=20 >> We need to keep: 1, 6, Echo-Nonce,=20 >>=20 >> We need to move: 2, 3, 4, 5, RLOC-Probing >=20 > Again, we already had this debate. The decision was made and agreed = upon. We shouldn=E2=80=99t open this up again. Exactly, it has been decided, hence control plane things go in the = control plane document. (or OAM) >=20 >>> When an ETR decapsulates a packet, it will check for any change in >>> the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the >>> ETR, if acting also as an ITR, will refrain from encapsulating >>> packets to an RLOC that is indicated as down. It will only resume >>> using that RLOC if the corresponding Locator-Status-Bit returns to = a >>> value of 1. Locator-Status-Bits are associated with a Locator-Set >>> per EID-Prefix. Therefore, when a Locator becomes unreachable, the >>> Locator-Status-Bit that corresponds to that Locator's position in = the >>> list returned by the last Map-Reply will be set to zero for that >>> particular EID-Prefix. >>>=20 >> We need to cite the threats document because of the security issues = of LSB. >=20 > We reference it in the Security Considerations section. Don=E2=80=99t = you think its good enough. Otherwise, we=E2=80=99ll have to reference it = in every situation that the threats document covers. One thing is the threats an other is a feature that you cannot use in = public deployments.=20 Somewhere in this document we must state that LSB cannot be used in = public deployments. Choose where.=20 >=20 >>> When ITRs at the site are not deployed in CE routers, the IGP can >>> still be used to determine the reachability of Locators, provided >>> they are injected into the IGP. This is typically done when a /32 >>> address is configured on a loopback interface. >>>=20 >> The above paragraph has to move to 6833bis. >=20 > Disagree. The WG decided differently. >=20 >>> When ITRs receive ICMP Network Unreachable or Host Unreachable >>> messages as a method to determine unreachability, they will refrain >>> from using Locators that are described in Locator lists of Map- >>> Replies. However, using this approach is unreliable because many >>> network operators turn off generation of ICMP Destination = Unreachable >>> messages. >>>=20 >>>=20 >> The above paragraph has to move to 6833bis. >=20 > Disagree. The WG decided differently. >=20 >>> If an ITR does receive an ICMP Network Unreachable or Host >>> Unreachable message, it MAY originate its own ICMP Destination >>> Unreachable message destined for the host that originated the data >>> packet the ITR encapsulated. >>>=20 >>>=20 >> The above paragraph has to move to 6833bis. >=20 > Disagree. The WG decided differently. >=20 >>> Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a >>> locator address from a Locator-Set in a mapping entry matches a >>> prefix. If it does not find one and BGP is running in the Default- >>> Free Zone (DFZ), it can decide to not use the Locator even though = the >>> Locator-Status-Bits indicate that the Locator is up. In this case, >>> the path from the ITR to the ETR that is assigned the Locator is = not >>> available. More details are in [I-D.meyer-loc-id-implications]. >>>=20 >>>=20 >> The above paragraph has to move to 6833bis. >=20 > Disagree. The WG decided differently. >=20 >>> Optionally, an ITR can send a Map-Request to a Locator, and if a = Map- >>> Reply is returned, reachability of the Locator has been determined. >>> Obviously, sending such probes increases the number of control >>> messages originated by Tunnel Routers for active flows, so Locators >>> are assumed to be reachable when they are advertised. >>>=20 >>>=20 >> The above paragraph has to move to 6833bis. >=20 > Disagree. The WG decided differently. >=20 >>> This assumption does create a dependency: Locator unreachability is >>> detected by the receipt of ICMP Host Unreachable messages. When a >>>=20 >>>=20 >>>=20 >>> Farinacci, et al. Expires May 15, 2018 [Page = 26] >>> Internet-Draft LISP November = 2017 >>>=20 >>>=20 >>> Locator has been determined to be unreachable, it is not used for >>> active traffic; this is the same as if it were listed in a = Map-Reply >>> with Priority 255. >>>=20 >>>=20 >> The above paragraph has to move to 6833bis. >=20 > Disagree. The WG decided differently. >=20 >>> The ITR can test the reachability of the unreachable Locator by >>> sending periodic Requests. Both Requests and Replies MUST be rate- >>> limited. Locator reachability testing is never done with data >>> packets, since that increases the risk of packet loss for = end-to-end >>> sessions. >>>=20 >>>=20 >> The above paragraph has to move to 6833bis. >=20 > Disagree. The WG decided differently. [snip] >>> 10.2. RLOC-Probing Algorithm >>>=20 >>>=20 >> This whole section has to go to 6833bis. >=20 > Disagree. >=20 The WG decided differently. [snip] >=20 >>=20 >>> 13. Changing the Contents of EID-to-RLOC Mappings >>>=20 >>>=20 >> This is a control plane issue, as such it has to go in 6833bis, with = two exception: >> The very first paragraph stetting the problem, and the versioning = subsection, because it is a data-plane mechanism. >>=20 >> All of the rest 6833bis >>=20 >> Actually I remember a suggestion about putting operations issues like = this in an OAM document which would be a good idea.=20 >=20 > I don=E2=80=99t agree. We had already mentioned there is a = control-plane protocol that is described in RFC6833bis and a data-plane = protocol that USEs the control-plane protocol. And the usage should be = here. Not following here. Why should the data-plane control the control plane? Changing a mapping can be triggered by data plane events but the control = plane will manage. It=E2=80=99s like routing, the data plane can detect a link outage but = is the control plane that will do the rest. Said differently, you can = detect a link failure with IP but is IGP that will find an alternative = route. >=20 > Think of it as an API. There is a document that defines an API and = there is a document on which API calls are used for the use-case of say = a data-plane. >=20 >>>=20 >>> 16. Mobility Considerations >>>=20 >> Move it out. Mobility is equivalent to mapping change, it is a CP = issue. >>=20 >> move it in an OAM document. >>=20 >>=20 >>>=20 >>>=20 >>> 17. LISP xTR Placement and Encapsulation Methods >>>=20 >> This ia an OAM issue and has to be moved out of the document. >=20 > Luigi, we already decided on this and you didn=E2=80=99t disagree when = we decided. Dino, please check the minutes. The discussion was on the excellent = summary that Albert prepared. Except for disagreement on SMR there was a decision to move everything = out. To the question: where to put it? I am not even sure that everything = should go in the control plane document, hence the suggestion of the OAM = which could be just a cut and paste of these sections. > Making changes like this to RFC6833 will be huge. You do not have to. see my comment above. > We have the documents separated in the current state right now that = seems to work and seems to be clear. I did not have time to go over 6833bis, but concerning 6830bis the = document is not clear and it is a patchwork of data-plane, = control-plane, and deployment issues. This is not what was agreed upon when we started this effort. >=20 >>=20 >>>=20 >>> 19. Security Considerations >>>=20 >>> Security considerations for LISP are discussed in [RFC7833], in >>> addition [I-D.ietf-lisp-sec] provides authentication and integrity = to >>> LISP mappings. >>>=20 >> lisp-sec is control-plane has to be referenced in 6833bis. >=20 > Yes, but if an ITR caches a coarse EID-prefix, then there is a = data-plane redirection attack. >=20 My point is that lisp-sec provides control plane features, so the = sentence does not bring anything to the discussion. Please delete. >>> 21.1. LISP UDP Port Numbers >>>=20 >>> The IANA registry has allocated UDP port numbers 4341 and 4342 for >>> lisp-data and lisp-control operation, respectively. IANA has = updated >>> the description for UDP ports 4341 and 4342 as follows: >>>=20 >>> lisp-data 4341 udp LISP Data Packets >>> lisp-control 4342 udp LISP Control Packets >>>=20 >> 4342 is control-plane and MUST be requested to IANA in the 6833bis = document. >=20 > We didn=E2=80=99t want to change the registry so we are keeping this = here. Its really no big deal. > Note the data-plane implementation will have to send to the 4342 = socket so its not out of place at all for this to be in this document. >=20 4342 is control plane not data plane, any further review beyond the WG = will point out this inconsistency. Thanks=20 Luigi --Apple-Mail=_BE4231F2-D20D-4102-B450-46C471962B8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dino,

thanks for the hard work. 
my replies inline (trimmed the points we agree or have been = clarified by your answers).


@ALL:   this is not a private discussion between me and = Dino and I invite all of you to chime in and provide an = opinion.

There = one clear point here:  This document is not about data-plane, is = data-plane + fragmented information that does not belong = here. 
The document can be shorter and to the = point. There are a lot of OAM information that does not belong to the = data-plane.


On 17 Dec 2017, at 22:37, Dino Farinacci = <farinacci@gmail.com> wrote:

Detailed comments = inline.

Thanks for your = comments. A diff and txt file are enclosed at the bottom.

p.s. = @Dino: sorry this is 07 version because I started with that version.

No worries.

the wording = =E2=80=9Cdata-plane protocol=E2=80=9D sounds awkward to me. I think = would be better to put "data-plane operations=E2=80=9D or even better = =E2=80=9Cdata-plane specifications=E2=80=9D
Best solution: = just drop it. This document describes the data plane of LISP.  


for the Locator/ID
 Separation Protocol = (LISP).  LISP defines two namespaces, End-point
=  Identifiers (EIDs) that identify end-hosts and Routing Locators
 (RLOCs) that identify network attachment points. =  With this, LISP
 effectively separates control = from data, and allows routers to create
 overlay = networks.  LISP-capable routers exchange encapsulated packets
 according to EID-to-RLOC mappings stored in a local = map-cache.  The
 map-cache is populated by the = LISP Control-Plane protocol

Same= as above for the "control-plane protocol=E2=80=9D

These are well-known terms across = the industry. I would prefer to not change them. Plus they made it = through the experimental RFC-set without opposition.

It is = redundant because the =E2=80=9CP=E2=80=9D in LISP that does mean = =E2=80=9Cprotocol=E2=80=9D. But this is an english nit. I can live with = the current wording.




3.  Definition of Terms


What is the order = of the Terms?

It is not alphabetical and = not logical (at least I cannot se it).

Originally it was suppose to be logical. I will double check = to make sure the terms are introduced in an obvious sequence. If I can = avoid forward-references, I will do so.


I = guess this is still on your to do list. 


[snip]

 Re-encapsulating Tunneling in RTRs: =   Re-encapsulating Tunneling

RTR have never been defined.

It is being defined right here. = I=E2=80=99ll read word it.


If = you define it the text should read like:

RTR: Re-encapsulating Tunnel = Router=E2=80=A6=E2=80=A6.


 Recursive Tunneling:   Recursive Tunneling = occurs when a packet has
    more = than one LISP IP header.  Additional layers of tunneling MAY
    be employed to implement Traffic = Engineering or other re-routing
=     as needed.  When this is done, an = additional "outer" LISP header
    is = added, and the original RLOCs are preserved in the "inner"
=     header.  

Do not think the following sentence is really = necessary.



Any references to = tunnels in this specification refer to
=     dynamic encapsulating tunnels; they are never = statically
    configured.

Well many have said = that LISP tunnels are not like traditional tunnels. Traditional tunnels = are configured and provisioned. Where LISP tunnels are dynamic and used = on demand. I would like the sectiond to stay.

You = can move this sentence in the intro or where it make sense to you. In = the Definition of terms is just lost.

[snip]

=  Server-side:  Server-side is a term used in this document to = indicate
    that a connection = initiation attempt is being accepted for a
=     destination EID.  




Rest = of the paragraph not needed here. (it is specified in the operation part = of the document)

The ETR(s) at the destination LISP site may be
=     the first to send Map-Replies to the source site = initiating the
    connection. =  The ETR(s) at this destination site can obtain
=     mappings by gleaning information from = Map-Requests, Data-Probes,
    or = encapsulated packets.

Okay, reworded though.

Still = not needed. And you added =E2=80=9CMAY=E2=80=9D which is pointless. = Please delete. The procedures are described elsewhere in the = document. 




 o  Other = types of EID are supported by LISP, see [RFC8060] for
=     further information.

I would put the last two bullets in the = definition of EID. It simplifies the story here.

I think it should be kept in. I = feel it adds value.

You break the operational flow by opening a = different point describing what is what. It makes the overall procedure = unclear.



 o  EID-Prefixes are likely to be hierarchically = assigned in a manner
    that is = optimized for administrative convenience and to facilitate
=     scaling of the EID-to-RLOC mapping database. =  The hierarchy is
    based on = an address allocation hierarchy that is independent of
=     the network topology.

Drop the last bullet it is about scalability.

Right, but still important to = mention. Many of the benefits of LISP aren=E2=80=99t always obvious. So = we have to point them out.
Dino, this has to go away. This is NOT the = control-plane advertisement document. This is the LISP control-plane, = that=E2=80=99s all.
This was agreed upon at the time of = rechartering.

[snip]

5.1.  LISP IPv4-in-IPv4 Header Format

      0 =             &n= bsp;     1 =             &n= bsp;     2 =             &n= bsp;     3
=       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
=      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   / |Version| =  IHL  |Type of Service| =          Total Length =         |
=   / =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
   / =  |Version|  IHL   |DSCP =      |ECN| =          Total Length =         |
=   / =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

The correct IPv4 Header is with DSCP = and ECN. Please update below as well.

I am not sure we should change this. We are referencing the = RFC791 so good to be consistent.

Go on = the data tracker: https://tools.ietf.org/html/rfc791

You will read that 791 has been updated by RFC = 1349, RFC 2474, and RFC 6864. You have to refer to these = documents.
Please update.



5.2.  LISP IPv6-in-IPv6 Header Format

      0 =             &n= bsp;     1 =             &n= bsp;     2 =             &n= bsp;     3
=       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
=      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   / |Version| = Traffic Class | =           Flow Label =             &n= bsp;    |
  / =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
   / |Version| DSCP =      |ECN| =           Flow Label =             &n= bsp;    |
  / =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The correct IPv6 Header is with DSCP and ECN. = Please update below as well.

As = comment as above.

As for my answer above.

[snip]


The = description of the encap/decap operation lacks of clarity concerning how = to deal with
ECN bits and DSCP .

1. I think that the text should make explicitly the = difference between DSCP and ECN fields.

2. = How to deal with ECN should be part of the description of the =  encap/decap not a paragraph apart.
  This = basically means that half of the last paragraph should be a bullet of = the ITR/PITR encapsulation
  and the other = half  in the ETR/PETR operation.

We went through this with a lot of people for RFC6830. It = took many months to resolve. I dare not touch this text.

You = have just to move it up and separate it in two bullets. No changes = needed.



9.  Routing Locator = Selection

Large part of this = section is about control plane issues and as such should be put in = 6833bis.

What this section should state is = that priority and weight are used to select the RLOC to use.
Only exception is gleaning where we have one single RLOC and = we do not know neither priority nor weight.

All the other operational discussion goes elsewhere, but not = in this document.

We have = already decided (a year ago) not to move this because its the data-plane = that needs to know about locator reachability so it knows which locators = to use.

Please check the minutes of past meetings (as I = did), the only unclear point was SMR, everything else was agreed to be = moved out. 




10.  Routing = Locator Reachability

 Several = mechanisms for determining RLOC reachability are currently
=  defined:

There exists = data-plane based reachability mechanisms and control plane reachability = mechanisms.
We have to keep here only the data plane based = mechanism and move the other in 6833bis.

We = need to keep: 1, 6, Echo-Nonce,

We need to = move: 2, 3, 4, 5,  RLOC-Probing

Again, we already had this debate. The decision was made and = agreed upon. We shouldn=E2=80=99t open this up again.

Exactly, it has been decided, hence control plane = things go in the control plane document. (or OAM)





 When an ETR decapsulates a packet, it = will check for any change in
 the = 'Locator-Status-Bits' field.  When a bit goes from 1 to 0, the
 ETR, if acting also as an ITR, will refrain from = encapsulating
 packets to an RLOC that is indicated = as down.  It will only resume
 using that RLOC = if the corresponding Locator-Status-Bit returns to a
=  value of 1.  Locator-Status-Bits are associated with a = Locator-Set
 per EID-Prefix.  Therefore, when a = Locator becomes unreachable, the
 Locator-Status-Bit = that corresponds to that Locator's position in the
=  list returned by the last Map-Reply will be set to zero for = that
 particular EID-Prefix.

We need to cite the threats document because of = the security issues of LSB.

We = reference it in the Security Considerations section. Don=E2=80=99t you = think its good enough. Otherwise, we=E2=80=99ll have to reference it in = every situation that the threats document = covers.
One thing is the = threats an other is a feature that you cannot use in public = deployments. 
Somewhere in this document we must state = that LSB cannot be used in public deployments. Choose = where. 




 When ITRs at the site are not deployed = in CE routers, the IGP can
 still be used to = determine the reachability of Locators, provided
=  they are injected into the IGP.  This is typically done when = a /32
 address is configured on a loopback = interface.

The above paragraph = has to move to 6833bis.

Disagree.

The WG decided differently.


 When ITRs receive ICMP Network = Unreachable or Host Unreachable
 messages as a = method to determine unreachability, they will refrain
=  from using Locators that are described in Locator lists of Map-
 Replies.  However, using this approach is = unreliable because many
 network operators turn off = generation of ICMP Destination Unreachable
=  messages.


The above paragraph has to move to 6833bis.

Disagree.

The = WG decided differently.



 If an ITR does = receive an ICMP Network Unreachable or Host
=  Unreachable message, it MAY originate its own ICMP Destination
 Unreachable message destined for the host that = originated the data
 packet the ITR encapsulated.


The above = paragraph has to move to 6833bis.

Disagree.

The WG decided differently.




 Also, BGP-enabled ITRs can unilaterally = examine the RIB to see if a
 locator address from a = Locator-Set in a mapping entry matches a
 prefix. =  If it does not find one and BGP is running in the Default-
 Free Zone (DFZ), it can decide to not use the Locator = even though the
 Locator-Status-Bits indicate that = the Locator is up.  In this case,
 the path = from the ITR to the ETR that is assigned the Locator is not
=  available.  More details are in = [I-D.meyer-loc-id-implications].


The above paragraph has to move to 6833bis.

Disagree.

The WG decided differently.


 Optionally, an ITR can send a = Map-Request to a Locator, and if a Map-
 Reply is = returned, reachability of the Locator has been determined.
=  Obviously, sending such probes increases the number of control
 messages originated by Tunnel Routers for active = flows, so Locators
 are assumed to be reachable when = they are advertised.


The above paragraph has to move to 6833bis.

Disagree.

The WG decided differently.



This = assumption does create a dependency: Locator unreachability is
 detected by the receipt of ICMP Host Unreachable = messages.  When a



Farinacci, et al. =         Expires May 15, 2018 =             &n= bsp;   [Page 26]
Internet-Draft =             &n= bsp;      LISP =             &n= bsp;       November 2017


 Locator has been = determined to be unreachable, it is not used for
=  active traffic; this is the same as if it were listed in a = Map-Reply
 with Priority 255.


The above paragraph has to move = to 6833bis.

Disagree.

The WG decided differently.


 The ITR can test the reachability of = the unreachable Locator by
 sending periodic = Requests.  Both Requests and Replies MUST be rate-
=  limited.  Locator reachability testing is never done with = data
 packets, since that increases the risk of = packet loss for end-to-end
 sessions.


The above = paragraph has to move to 6833bis.

Disagree.

The WG decided differently.


[snip]

10.2. =  RLOC-Probing Algorithm


This whole section has to go to 6833bis.

Disagree.


The WG decided differently.


[snip]


13.  Changing the Contents of EID-to-RLOC Mappings


This is a control = plane issue, as such it has to go in 6833bis, with two exception:
The very first paragraph stetting the problem, and the = versioning subsection, because it is a data-plane mechanism.

All of the rest 6833bis

Actually I remember a suggestion about putting operations = issues like this in an OAM document which would be a good idea.

I don=E2=80=99t agree. We had = already mentioned there is a control-plane protocol that is described in = RFC6833bis and a data-plane protocol that USEs the control-plane = protocol. And the usage should be here.

Not following here. Why should the = data-plane control the control plane?

Changing a mapping can be triggered by = data plane events but the control plane will manage.

It=E2=80=99s like = routing, the data plane can detect a link outage but is the control = plane that will do the rest. Said differently, you can detect a link = failure with IP but is IGP that will find an alternative = route.



Think of it as an API. There is a document = that defines an API and there is a document on which API calls are used = for the use-case of say a data-plane.


16.  Mobility Considerations

Move it out. Mobility is = equivalent to mapping change, it is a CP issue.

move it in an OAM document.




17.  LISP xTR Placement and Encapsulation Methods

This ia an OAM issue and has to = be moved out of the document.

Luigi, we already decided on this and you didn=E2=80=99t = disagree when we decided.

Dino, please check the minutes. The = discussion was on the excellent summary that Albert prepared.
Except for disagreement on SMR there was a decision to move = everything out.

To the question: where to put it? I am not even sure that = everything should go in the control plane document, hence the suggestion = of the OAM  which could be just a cut and paste of these = sections.



Making changes like this to RFC6833 will be = huge.

You do not have to. see my comment above.

We have the documents separated in the current state right = now that seems to work and seems to be clear.

I did not have time to go over 6833bis, = but concerning 6830bis the document is not clear and it is a patchwork = of data-plane, control-plane, and deployment issues.

This is not what was = agreed upon when we started this effort.





19.  Security Considerations

=  Security considerations for LISP are discussed in [RFC7833], = in
 addition [I-D.ietf-lisp-sec] provides = authentication and integrity to
 LISP mappings.

lisp-sec is control-plane has to = be referenced in 6833bis.

Yes, = but if an ITR caches a coarse EID-prefix, then there is a data-plane = redirection attack.


My point is that lisp-sec provides = control plane features, so the sentence does not bring anything to the = discussion.
Please delete.


21.1.  LISP UDP = Port Numbers

 The IANA registry has = allocated UDP port numbers 4341 and 4342 for
=  lisp-data and lisp-control operation, respectively.  IANA has = updated
 the description for UDP ports 4341 and 4342 = as follows:

=      lisp-data =      4341 udp    LISP Data = Packets
     lisp-control =   4342 udp    LISP Control Packets

4342 is control-plane and MUST be = requested to IANA in the 6833bis document.

We didn=E2=80=99t want to change the registry so we are = keeping this here. Its really no big deal.

Note the data-plane implementation will have = to send to the 4342 socket so its not out of place at all for this to be = in this document.


4342  is control plane not data = plane, any further review beyond the WG will point out this = inconsistency.

Thanks 

Luigi



= --Apple-Mail=_BE4231F2-D20D-4102-B450-46C471962B8B-- From nobody Mon Dec 18 10:07:30 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39E6129C6B for ; Mon, 18 Dec 2017 10:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.568 X-Spam-Level: X-Spam-Status: No, score=0.568 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_COMMENT_SAVED_URL=0.357, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 tocStjp8bzCu for ; Mon, 18 Dec 2017 10:07:17 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18373126D05 for ; Mon, 18 Dec 2017 10:07:17 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id u62so29352003ita.2 for ; Mon, 18 Dec 2017 10:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vhHZhxa0Y+ya4ANt3xlSrbrND6n/JI4pwcZvVJ2l55E=; b=sU6zxo5zVuir/BfBURCkmZ6sfon5hxmLjBchOdoQPxrLCbBxbIivNuiipSxLCNRKgC E3W1/WG3FmlIXltch7SHOkdQiDxbXPiUqfTetEQG3FNeLDavsl5ny0HQAD0kDmMjiN4V Jtmgj4GIDze+eCMobPP3ipWc5Y5skA5dBkeDnhLiTYz7EIxFztg7TDU7kz7HieDXRF7G IoYaaCquMUVRHYoawIzpGv18MVYuWY5yg6O30wwAmanxYmONl+DKp2lGxYyplU5iB90m L7d0PwB9Q7CJv9OtgbauM0Kpvw6le126U5osCuhMmwmLKkQtC52ze/qfOa/cbbmE3wa2 43VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vhHZhxa0Y+ya4ANt3xlSrbrND6n/JI4pwcZvVJ2l55E=; b=fcf0GamVgCfEI/XfpahHx8i/WZup+oSho+V6Od79FWFCF+r8e6i0BUvuV67o0qvA/z QT0Ejtc2KRZCBgLqw0taOGvL2pJBWyxHfpqQra1uVsnNYYWBhukj4viF1X2GG8QhK7VX ayoYDvjI9K7OMqRMOWZ5h5+6k/WwXNoOk83PPgjMfSRLU0NkZUH/d6AyRrLnLR6zCSvc ByhedQu3obqifuH2xQ4VYvuVr3wCemCZdZe7c6MzBZ9rWrmT6qSVzt51NoAwh5zktxgn puXz2WFn/xi6ksEoIlPupaNjZa2Mvp+x0UPh9Nmsy11kWhkXj6aUjgpb7CDQ06McmkMF OESA== X-Gm-Message-State: AKGB3mKUZpc/b0prjp0UZAGBkhrviwsFb4gzIZ2Kxdqhu6Xb9/amcO7G Qt9WZal3VlQBSLHCBGHZie3b99rr X-Google-Smtp-Source: ACJfBovmRviVI+q9E0v/5uiibXvwO75urkf86lf2SWS2ALuPW1ji9hIXNFkmMDQZ9q9K3GXQNAf96g== X-Received: by 10.36.211.22 with SMTP id n22mr708391itg.5.1513620436080; Mon, 18 Dec 2017 10:07:16 -0800 (PST) Received: from [172.19.131.117] ([12.130.117.85]) by smtp.gmail.com with ESMTPSA id 134sm6955592ion.0.2017.12.18.10.07.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 10:07:13 -0800 (PST) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_EBF70E63-3D33-4166-9407-E9E9514946DC" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 18 Dec 2017 10:06:59 -0800 In-Reply-To: <86F3ABEE-5623-45EB-AD8F-342027FA6101@gigix.net> Cc: "lisp@ietf.org list" , lisp-chairs@tools.ietf.org To: Luigi Iannone References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <4D2A0EA8-9096-4E12-99F9-B60910D7122E@gmail.com> <86F3ABEE-5623-45EB-AD8F-342027FA6101@gigix.net> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [lisp] 6830bis Review (PLEASE COMMENTS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 18:07:29 -0000 --Apple-Mail=_EBF70E63-3D33-4166-9407-E9E9514946DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Dino, >=20 > thanks for the hard work.=20 I am trying to make it less harder than it needs to be. New diff and = text file enclosed. > my replies inline (trimmed the points we agree or have been clarified = by your answers). Thanks for that. > @ALL: this is not a private discussion between me and Dino and I = invite all of you to chime in and provide an opinion. >=20 > There one clear point here: This document is not about data-plane, is = data-plane + fragmented information that does not belong here.=20 It is about not losing important information we decided 10 years ago to = keep in because otherwise, we=E2=80=99d have to sprinkle it across = documents. And WE DID decide to NOT create a third document. > The document can be shorter and to the point. There are a lot of OAM = information that does not belong to the data-plane. The OAM information is necessary for the data-plane. And if LISP-GPE, = VXLAN, or any other data plane wants to use their own OAM or use the = LISP control-plane differently, it needs to be documented in their = data-planes. Hence, why this information is there. Short is not necessarily good if the document is incomplete. And I think = the effort we have put in over the last couple of years finds the right = balance. >>>=20 >>> It is not alphabetical and not logical (at least I cannot se it). >>=20 >> Originally it was suppose to be logical. I will double check to make = sure the terms are introduced in an obvious sequence. If I can avoid = forward-references, I will do so. >>=20 >=20 > I guess this is still on your to do list.=20 I thought the order was fine so I didn=E2=80=99t change it. >>=20 >>>> Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling >>>>=20 >>> RTR have never been defined.e >>=20 >> It is being defined right here. I=E2=80=99ll read word it. >>=20 >=20 > If you define it the text should read like: >=20 > RTR: Re-encapsulating Tunnel Router=E2=80=A6=E2=80=A6. Changed. >>>=20 >>>> Any references to tunnels in this specification refer to >>>> dynamic encapsulating tunnels; they are never statically >>>> configured. >>=20 >> Well many have said that LISP tunnels are not like traditional = tunnels. Traditional tunnels are configured and provisioned. Where LISP = tunnels are dynamic and used on demand. I would like the sectiond to = stay. >=20 > You can move this sentence in the intro or where it make sense to you. = In the Definition of terms is just lost. I added it as the first definition in the Definition of Terms section. >=20 > [snip] >>=20 >>>> Server-side: Server-side is a term used in this document to = indicate >>>> that a connection initiation attempt is being accepted for a >>>> destination EID. =20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> Rest of the paragraph not needed here. (it is specified in the = operation part of the document) >>>=20 >>>> The ETR(s) at the destination LISP site may be >>>> the first to send Map-Replies to the source site initiating the >>>> connection. The ETR(s) at this destination site can obtain >>>> mappings by gleaning information from Map-Requests, = Data-Probes, >>>> or encapsulated packets. >>=20 >> Okay, reworded though. >=20 > Still not needed. And you added =E2=80=9CMAY=E2=80=9D which is = pointless. Please delete. The procedures are described elsewhere in the = document.=20 Sentence removed. >=20 >>>> o Other types of EID are supported by LISP, see [RFC8060] for >>>> further information. >>>>=20 >>> I would put the last two bullets in the definition of EID. It = simplifies the story here. >>=20 >> I think it should be kept in. I feel it adds value. >=20 > You break the operational flow by opening a different point describing = what is what. It makes the overall procedure unclear. It was put there because someone commented on it. You have to tell me = why you think it breaks flow. We discuss how end-systems send to EIDs. = We say what EIDs are and how they are assigned to hosts. And then we = move to RLOCs. It is pretty plan, simple, and straight-forward. >=20 >=20 >>=20 >>>> o EID-Prefixes are likely to be hierarchically assigned in a = manner >>>> that is optimized for administrative convenience and to = facilitate >>>> scaling of the EID-to-RLOC mapping database. The hierarchy is >>>> based on an address allocation hierarchy that is independent of >>>> the network topology. >>>>=20 >>> Drop the last bullet it is about scalability. >>=20 >> Right, but still important to mention. Many of the benefits of LISP = aren=E2=80=99t always obvious. So we have to point them out. >=20 > Dino, this has to go away. This is NOT the control-plane advertisement = document. This is the LISP control-plane, that=E2=80=99s all. > This was agreed upon at the time of rechartering. Sorry disagree. You have to mention some control-plane. And not the = definition of it but how its used by this data-plane. >=20 > [snip] >>=20 >>>> 5.1. LISP IPv4-in-IPv4 Header Format >>>>=20 >>>> 0 1 2 3 >>>> 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 >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> / |Version| IHL |Type of Service| Total Length = | >>>> / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> / |Version| IHL |DSCP |ECN| Total Length = | >>> / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> The correct IPv4 Header is with DSCP and ECN. Please update below as = well. >>=20 >> I am not sure we should change this. We are referencing the RFC791 so = good to be consistent. >=20 > Go on the data tracker: https://tools.ietf.org/html/rfc791 >=20 > You will read that 791 has been updated by RFC 1349, RFC 2474, and RFC = 6864. You have to refer to these documents. > Please update. Changed for both IPv4 and IPv6. And referenced only 2474. 1349 is = replaced by 2474 and 6864 discusses the ID field that is not what is = being commented on here. >=20 >>> The description of the encap/decap operation lacks of clarity = concerning how to deal with=20 >>> ECN bits and DSCP . >>>=20 >>> 1. I think that the text should make explicitly the difference = between DSCP and ECN fields. >>>=20 >>> 2. How to deal with ECN should be part of the description of the = encap/decap not a paragraph apart. >>> This basically means that half of the last paragraph should be a = bullet of the ITR/PITR encapsulation=20 >>> and the other half in the ETR/PETR operation. >>=20 >> We went through this with a lot of people for RFC6830. It took many = months to resolve. I dare not touch this text. >=20 > You have just to move it up and separate it in two bullets. No changes = needed. Can you be more specific please. >>=20 >>>> 9. Routing Locator Selection >>>>=20 >>> Large part of this section is about control plane issues and as such = should be put in 6833bis. >>>=20 >>> What this section should state is that priority and weight are used = to select the RLOC to use. >>> Only exception is gleaning where we have one single RLOC and we do = not know neither priority nor weight. >>>=20 >>> All the other operational discussion goes elsewhere, but not in this = document. >>=20 >> We have already decided (a year ago) not to move this because its the = data-plane that needs to know about locator reachability so it knows = which locators to use. >=20 > Please check the minutes of past meetings (as I did), the only unclear = point was SMR, everything else was agreed to be moved out.=20 Please point it out. We have taken every input from the WG. And Albert = and I were in sync and thought you had agreed (or maybe you stopped = disagreeing until now). >>=20 >>>> 10. Routing Locator Reachability >>>>=20 >>>> Several mechanisms for determining RLOC reachability are currently >>>> defined: >>>>=20 >>> There exists data-plane based reachability mechanisms and control = plane reachability mechanisms. >>> We have to keep here only the data plane based mechanism and move = the other in 6833bis. >>>=20 >>> We need to keep: 1, 6, Echo-Nonce,=20 >>>=20 >>> We need to move: 2, 3, 4, 5, RLOC-Probing >>=20 >> Again, we already had this debate. The decision was made and agreed = upon. We shouldn=E2=80=99t open this up again. >=20 > Exactly, it has been decided, hence control plane things go in the = control plane document. (or OAM) You are trying to draw a hard wall between the data-plane and = control-plane. In the real world that is not how protocols are deployed. >>=20 >>>> When an ETR decapsulates a packet, it will check for any change in >>>> the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the >>>> ETR, if acting also as an ITR, will refrain from encapsulating >>>> packets to an RLOC that is indicated as down. It will only resume >>>> using that RLOC if the corresponding Locator-Status-Bit returns to = a >>>> value of 1. Locator-Status-Bits are associated with a Locator-Set >>>> per EID-Prefix. Therefore, when a Locator becomes unreachable, = the >>>> Locator-Status-Bit that corresponds to that Locator's position in = the >>>> list returned by the last Map-Reply will be set to zero for that >>>> particular EID-Prefix. >>>>=20 >>> We need to cite the threats document because of the security issues = of LSB. >>=20 >> We reference it in the Security Considerations section. Don=E2=80=99t = you think its good enough. Otherwise, we=E2=80=99ll have to reference it = in every situation that the threats document covers. >=20 > One thing is the threats an other is a feature that you cannot use in = public deployments.=20 > Somewhere in this document we must state that LSB cannot be used in = public deployments. Choose where.=20 I put a reference to the Security Consideration section that talks about = LSB vulnerabiliies as well as has the refernece to the LISP threats RFC. >>>=20 >>> Actually I remember a suggestion about putting operations issues = like this in an OAM document which would be a good idea.=20 >>=20 >> I don=E2=80=99t agree. We had already mentioned there is a = control-plane protocol that is described in RFC6833bis and a data-plane = protocol that USEs the control-plane protocol. And the usage should be = here. >=20 > Not following here. Why should the data-plane control the control = plane? It is not controlling the control-plane, it is using it. Did my example = of an API not make that clear? This example: >> Think of it as an API. There is a document that defines an API and = there is a document on which API calls are used for the use-case of say = a data-plane. > Changing a mapping can be triggered by data plane events but the = control plane will manage. Sorry, no, the data-plane manages the map-cache, its own data structure. = The data-plane uses messages to manage that map-cache, and those = messages are defined in the control-plane spec. > It=E2=80=99s like routing, the data plane can detect a link outage but = is the control plane that will do=20 Well that is not true. The OS infrastructure detects a link failure. The = IP forwaring engine does not (and I know I implemented at least 6 = different data-planes over the years). > the rest. Said differently, you can detect a link failure with IP but = is IGP that will find an alternative route. Why would IP detect a link failre for AppleTalk (another network layer = protocol). And AppleTalk doesn=E2=80=99t do it for itself either. Not a = good example. >> Making changes like this to RFC6833 will be huge. >=20 > You do not have to. see my comment above. >=20 >> We have the documents separated in the current state right now that = seems to work and seems to be clear. >=20 > I did not have time to go over 6833bis, but concerning 6830bis the = document is not clear and it is a patchwork of data-plane, = control-plane, and deployment issues. >=20 > This is not what was agreed upon when we started this effort. The effort was continuing. And we created options with further study. = Both Albert and I did that further study and the drafts reflect the = decisions. There were no WG objections other than from you which we had = thought we convinced. >>>>=20 >>>> 19. Security Considerations >>>>=20 >>>> Security considerations for LISP are discussed in [RFC7833], in >>>> addition [I-D.ietf-lisp-sec] provides authentication and integrity = to >>>> LISP mappings. >>>>=20 >>> lisp-sec is control-plane has to be referenced in 6833bis. >>=20 >> Yes, but if an ITR caches a coarse EID-prefix, then there is a = data-plane redirection attack. >>=20 >=20 > My point is that lisp-sec provides control plane features, so the = sentence does not bring anything to the discussion. > Please delete. >=20 >=20 >>>> 21.1. LISP UDP Port Numbers >>>>=20 >>>> The IANA registry has allocated UDP port numbers 4341 and 4342 for >>>> lisp-data and lisp-control operation, respectively. IANA has = updated >>>> the description for UDP ports 4341 and 4342 as follows: >>>>=20 >>>> lisp-data 4341 udp LISP Data Packets >>>> lisp-control 4342 udp LISP Control Packets >>>>=20 >>> 4342 is control-plane and MUST be requested to IANA in the 6833bis = document. >>=20 >> We didn=E2=80=99t want to change the registry so we are keeping this = here. Its really no big deal. >=20 >> Note the data-plane implementation will have to send to the 4342 = socket so its not out of place at all for this to be in this document. >>=20 >=20 > 4342 is control plane not data plane, any further review beyond the = WG will point out this inconsistency. Sorry a data-plane component uses it. Why split it up when we can have = this in one place. Dino --Apple-Mail=_EBF70E63-3D33-4166-9407-E9E9514946DC Content-Disposition: attachment; filename=rfcdiff-rfc6830bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-rfc6830bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-07.txt - = draft-ietf-lisp-rfc6830bis-08.txt=20 =20 =20 =20 =20 =20 =20 = = = = = = = = = = = =
< draft-ietf-lisp-rfc6830bis-07.txt  =  draft-ietf-lisp-rfc6830bis-08.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Intended status: = Standards Track D. Meyer = Intended status: Standards Track = D. Meyer
Expires: May 15, 2018 = D. Lewis Expires: June 21, 2018 = D. Lewis
= Cisco Systems = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= November = 11, 2017 = December = 18, 2017
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-07 = = draft-ietf-lisp-rfc6830bis-08
=
Abstract = Abstract
=
This document = describes the data-plane protocol for the Locator/ID This document describes the data-plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local map-cache. The = according to EID-to-RLOC mappings stored in a local map-cache.
map-cache is populated by the LISP Control-Plane = protocol
[I-D.ietf-lisp-rfc6833bis].
=
LISP requires = no change to either host protocol stacks or to underlay = LISP requires no change to either host = protocol stacks or to underlay
routers and = offers Traffic Engineering, multihoming and mobility, routers and offers Traffic Engineering, multihoming = and mobility,
among other = features. among other = features.
=
Status of This = Memo Status of This Memo
=
This = Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
provisions of = BCP 78 and BCP 79. provisions of = BCP 78 and BCP 79.
=
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on May 15, = 2018. This Internet-Draft will = expire on June 21, 2018.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 28 =C2=B6 = skipping to change at page 2, line 28 =C2=B6
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . = 4 2. Requirements Notation . . . . = . . . . . . . . . . . . . . . . 4
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 9 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 9
4.1. Packet = Flow Sequence . . . . . . . . . . . . . . . . . . 11 4.1. Packet Flow Sequence . . . . . . . . . . . . = . . . . . . 11
5. LISP = Encapsulation Details . . . . . . . . . . . . . . . . . 13 = 5. LISP Encapsulation Details . . . . . . = . . . . . . . . . . . 13
5.1. LISP = IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 14 5.1. = LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13
5.2. LISP = IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 15 5.2. = LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14
5.3. = Tunnel Header Field Descriptions . . . . . . . . . . . . 16 5.3. = Tunnel Header Field Descriptions . . . . . . . . . . . . 15
6. LISP = EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 6. = LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19
7. Dealing = with Large Encapsulated Packets . . . . . . . . . . . 20 = 7. Dealing with Large Encapsulated Packets = . . . . . . . . . . . 20
7.1. A = Stateless Solution to MTU Handling . . . . . . . . . . 21 7.1. = A Stateless Solution to MTU Handling . . . . . . . . . . 20
7.2. A = Stateful Solution to MTU Handling . . . . . . . . . . . 22 7.2. = A Stateful Solution to MTU Handling . . . . . . . . . . . 21
8. Using = Virtualization and Segmentation with LISP . . . . . . . 22 = 8. Using Virtualization and Segmentation = with LISP . . . . . . . 22
9. Routing = Locator Selection . . . . . . . . . . . . . . . . . . 23 = 9. Routing Locator Selection . . . . . . . = . . . . . . . . . . . 23
10. Routing = Locator Reachability . . . . . . . . . . . . . . . . 24 = 10. Routing Locator Reachability . . . . . = . . . . . . . . . . . 24
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 27
10.2. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 = 10.2. RLOC-Probing Algorithm . . . . . . = . . . . . . . . . . . 28
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 29 = 11. EID Reachability within a LISP Site . . = . . . . . . . . . . . 29
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 30 12. = Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 31 13. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30
13.1. = Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32 13.1. = Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31
13.2. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 = 13.2. Solicit-Map-Request (SMR) . . . . = . . . . . . . . . . . 32
13.3. = Database Map-Versioning . . . . . . . . . . . . . . . . 34 13.3. = Database Map-Versioning . . . . . . . . . . . . . . . . 33
14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 35 14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 34
15. Router = Performance Considerations . . . . . . . . . . . . . . 35 = 15. Router Performance Considerations . . . = . . . . . . . . . . . 35
16. Mobility = Considerations . . . . . . . . . . . . . . . . . . . 36 16. = Mobility Considerations . . . . . . . . . . . . . . . . . . . 35
16.1. Slow = Mobility . . . . . . . . . . . . . . . . . . . . . 36 = 16.1. Slow Mobility . . . . . . . . . . = . . . . . . . . . . . 36
16.2. Fast = Mobility . . . . . . . . . . . . . . . . . . . . . 36 = 16.2. Fast Mobility . . . . . . . . . . = . . . . . . . . . . . 36
16.3. LISP = Mobile Node Mobility . . . . . . . . . . . . . . . 37 = 16.3. LISP Mobile Node Mobility . . . . = . . . . . . . . . . . 37
17. LISP xTR = Placement and Encapsulation Methods . . . . . . . . 38 17. = LISP xTR Placement and Encapsulation Methods . . . . . . . . 37
17.1. = First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 17.1. = First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38
17.2. = Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 = 17.2. Border/Edge xTRs . . . . . . . . . = . . . . . . . . . . . 39
17.3. ISP = Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 17.3. = ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39
17.4. LISP = Functionality with Conventional NATs . . . . . . . 40 = 17.4. LISP Functionality with = Conventional NATs . . . . . . . 40
17.5. = Packets Egressing a LISP Site . . . . . . . . . . . . . 41 17.5. = Packets Egressing a LISP Site . . . . . . . . . . . . . 40
18. = Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18. = Traceroute Considerations . . . . . . . . . . . . . . . . . . 40
18.1. = IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.1. = IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41
18.2. IPv4 = Traceroute . . . . . . . . . . . . . . . . . . . . 42 = 18.2. IPv4 Traceroute . . . . . . . . . = . . . . . . . . . . . 42
18.3. = Traceroute Using Mixed Locators . . . . . . . . . . . . 43 18.3. = Traceroute Using Mixed Locators . . . . . . . . . . . . 42
19. Security = Considerations . . . . . . . . . . . . . . . . . . . 43 = 19. Security Considerations . . . . . . . . = . . . . . . . . . . . 43
20. Network = Management Considerations . . . . . . . . . . . . . . 44 20. = Network Management Considerations . . . . . . . . . . . . . . 43
21. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 44 = 21. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 44
21.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 44 = 21.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 44
22. References = . . . . . . . . . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . = . . . . . . 44
22.1. = Normative References . . . . . . . . . . . . . . . . . . 44 = 22.1. Normative References . . . . . . . = . . . . . . . . . . . 44
22.2. = Informative References . . . . . . . . . . . . . . . . . 47 22.2. = Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 51 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 50
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 51 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 50
B.1. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . = 51
B.2. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52 B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . = 51
B.3. = Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 52 B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . = 51
B.4. = Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 = B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . = 51
B.5. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 53 B.5. Changes to = draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52
B.6. Changes to = draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 B.6. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 52
B.7. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 B.7. Changes to = draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52
B.8. Changes to = draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 B.8. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 B.9. Changes to = draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 52
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
routable = Routing Locators (RLOCs), used to identify network routable Routing Locators (RLOCs), used to identify = network
=
skipping to = change at = page 4, line 31 =C2=B6 = skipping to change at page 4, line 31 =C2=B6
describes the = LISP architecture. describes the = LISP architecture.
=
2. Requirements = Notation 2. Requirements = Notation
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
document are = to be interpreted as described in [RFC2119]. document are to be interpreted as described in = [RFC2119].
=
3. Definition of = Terms 3. Definition of Terms
=
= Tunneling: = Tunneling is a technique where another IP header is
= prepended to an = existing IP packet so a level of indirection in
= the data-plane = can be accomplished. Any references to tunnels in
= this = specification refer to dynamic encapsulating tunnels, = meaning
= they are never = statically configured.
= =
= Provider-Independent (PI) Addresses: PI addresses are an = address Provider-Independent (PI) = Addresses: PI addresses are an address
block = assigned from a pool where blocks are not associated with = block assigned from a pool where blocks = are not associated with
any = particular location in the network (e.g., from a particular = any particular location in the network = (e.g., from a particular
service = provider) and are therefore not topologically aggregatable = service provider) and are therefore not = topologically aggregatable
in the = routing system. in the routing = system.
=
= Provider-Assigned (PA) Addresses: PA addresses are an address = block Provider-Assigned (PA) = Addresses: PA addresses are an address block
assigned to = a site by each service provider to which a site assigned to a site by each service provider to = which a site
connects. = Typically, each block is a sub-block of a service connects. Typically, each block is a sub-block of = a service
provider = Classless Inter-Domain Routing (CIDR) [RFC4632] block and = provider Classless Inter-Domain Routing = (CIDR) [RFC4632] block and
is = aggregated into the larger block before being advertised into = is aggregated into the larger block = before being advertised into
the global = Internet. Traditionally, IP multihoming has been the global Internet. Traditionally, IP = multihoming has been
implemented = by each multihomed site acquiring its own globally implemented by each multihomed site acquiring its = own globally
visible = prefix. LISP uses only topologically assigned = and visible = prefix.
aggregatable address blocks for RLOCs, = eliminating this
demonstrably non-scalable = practice.
=
Routing = Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 Routing Locator (RLOC): An RLOC is an IPv4 = [RFC0791] or IPv6
[RFC8200] = address of an Egress Tunnel Router (ETR). An RLOC is [RFC8200] address of an Egress Tunnel Router = (ETR). An RLOC is
the output = of an EID-to-RLOC mapping lookup. An EID maps to one the output of an EID-to-RLOC mapping lookup. An = EID maps to one
or more = RLOCs. Typically, RLOCs are numbered from topologically = or more RLOCs. Typically, RLOCs are numbered from = aggregatable
= aggregatable blocks that are assigned to a site at each point = to blocks that are assigned to = a site at each point to which it
which it = attaches to the global Internet; where the topology is attaches to the global Internet; where the = topology is defined by
defined = by the connectivity of provider networks, RLOCs = can be the connectivity = of provider networks. Multiple RLOCs can = be
thought of as PA addresses. Multiple = RLOCs can be assigned to the = assigned to the same ETR device or to multiple ETR devices at a
same ETR = device or to multiple ETR devices at a site. site.
=
Endpoint ID = (EID): An EID is a 32-bit (for IPv4) or 128-bit (for Endpoint ID (EID): An EID is a 32-bit (for IPv4) or = 128-bit (for
IPv6) value = used in the source and destination address fields of IPv6) value used in the source and destination = address fields of
the first = (most inner) LISP header of a packet. The host obtains = the first (most inner) LISP header of a = packet. The host obtains
a = destination EID the same way it obtains a destination address = a destination EID the same way it obtains = a destination address
today, for = example, through a Domain Name System (DNS) [RFC1034] today, for example, through a Domain Name System = (DNS) [RFC1034]
lookup or = Session Initiation Protocol (SIP) [RFC3261] exchange. lookup or Session Initiation Protocol (SIP) = [RFC3261] exchange.
The source = EID is obtained via existing mechanisms used to set a The source EID is obtained via existing mechanisms = used to set a
host's = "local" IP address. An EID used on the public Internet = host's "local" IP address. An EID used = on the public Internet
must have = the same properties as any other IP address used in that = must have the same properties as any = other IP address used in that
manner; = this means, among other things, that it must be globally = manner; this means, among other things, = that it must be globally
unique. An = EID is allocated to a host from an EID-Prefix block unique. An EID is allocated to a host from an = EID-Prefix block
associated = with the site where the host is located. An EID can be = associated with the site where the host = is located. An EID can be
used by a = host to refer to other hosts. Note that EID blocks MAY = used by a host to refer to other hosts. = Note that EID blocks MAY
be assigned = in a hierarchical manner, independent of the network be assigned in a hierarchical manner, independent = of the network
topology, = to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping = database. In
addition, = an EID block assigned to a site may have = site-local addition, an EID = block assigned to a site MAY have = site-local
structure = (subnetting) for routing within the site; this structure = structure (subnetting) for routing within = the site; this structure
is not = visible to the global routing system. In theory, the bit = is not visible to the global routing = system. In theory, the bit
string that = represents an EID for one device can represent an RLOC string that represents an EID for one device can = represent an RLOC
for a = different device. As the architecture is = realized, if a for a = different device. When used in discussions with other
given bit string is both an RLOC and an EID, it = must refer to the
same entity in both cases. When used in = discussions with other
Locator/ID = separation proposals, a LISP EID will be called an Locator/ID separation proposals, a LISP EID will = be called an
"LEID". = Throughout this document, any references to "EID" refer = "LEID". Throughout this document, any = references to "EID" refer
to an = LEID. to an LEID.
=
EID-Prefix: = An EID-Prefix is a power-of-two block of EIDs that are EID-Prefix: An EID-Prefix is a power-of-two block = of EIDs that are
allocated = to a site by an address allocation authority. EID- allocated to a site by an address allocation = authority. EID-
Prefixes = are associated with a set of RLOC addresses that = make up Prefixes are = associated with a set of RLOC addresses. = EID-Prefix
a "database mapping". EID-Prefix = allocations can be broken up = allocations can be broken up into smaller blocks when an RLOC = set
into = smaller blocks when an RLOC set is to be associated with the = is to be associated with the larger = EID-Prefix block.
larger = EID-Prefix block. A globally routed address = block (whether
PI or PA) is not inherently an EID-Prefix. A = globally routed
address block MAY be used by its assignee as an = EID block. The
converse is not supported. That is, a site that = receives an
explicitly allocated EID-Prefix may not use that = EID-Prefix as a
globally routed prefix. This would require = coordination and
cooperation with the entities managing the = mapping infrastructure.
Once this has been done, that block could be = removed from the
globally routed IP system, if other suitable = transition and access
mechanisms are in place. Discussion of such = transition and access
mechanisms can be found in [RFC6832] and = [RFC7215].
=
End-system: = An end-system is an IPv4 or IPv6 device that originates = End-system: An end-system is an IPv4 or = IPv6 device that originates
packets = with a single IPv4 or IPv6 header. The end-system packets with a single IPv4 or IPv6 header. The = end-system
supplies an = EID value for the destination address field of the IP supplies an EID value for the destination address = field of the IP
header when = communicating globally (i.e., outside of its routing header when communicating globally (i.e., outside = of its routing
domain). = An end-system can be a host computer, a switch or router = domain). An end-system can be a host = computer, a switch or router
device, or = any network appliance. device, = or any network appliance.
=
Ingress Tunnel = Router (ITR): An ITR is a router that resides in a Ingress Tunnel Router (ITR): An ITR is a router = that resides in a
LISP site. = Packets sent by sources inside of the LISP site to LISP site. Packets sent by sources inside of the = LISP site to
=
skipping to = change at = page 7, line 9 =C2=B6 = skipping to change at page 6, line 51 =C2=B6
network = that strips an outer LISP header for Traffic Engineering = network that strips an outer LISP header = for Traffic Engineering
= purposes. purposes.
=
xTR: An xTR = is a reference to an ITR or ETR when direction of data xTR: An xTR is a reference to an ITR or ETR when = direction of data
flow is not = part of the context description. "xTR" refers to the flow is not part of the context description. = "xTR" refers to the
router that = is the tunnel endpoint and is used synonymously with router that is the tunnel endpoint and is used = synonymously with
the term = "Tunnel Router". For example, "An xTR can be located at = the term "Tunnel Router". For example, = "An xTR can be located at
the = Customer Edge (CE) router" indicates both ITR and ETR the Customer Edge (CE) router" indicates both ITR = and ETR
= functionality at the CE router. = functionality at the CE router.
=
= Re-encapsulating Tunneling in RTRs: = Re-encapsulating Tunneling = Re-encapsulating Tunneling Router (RTR): = An RTR acts like an ETR to
occurs when an RTR (Re-encapsulating Tunnel Router) acts like = an remove a LISP header, then = acts as an ITR to prepend a new LISP
ETR to = remove a LISP header, then acts as an ITR to prepend a new = header. This is = known as Re-encapsulating Tunneling. Doing this
LISP = header. Doing this allows a packet to be re-routed by the = allows a packet to be re-routed by the = RTR without adding the
RTR = without adding the overhead of additional tunnel headers. Any = overhead of additional tunnel headers. = Any references to tunnels
= references to tunnels in this specification refer to dynamic = in this specification refer to dynamic = encapsulating tunnels; they
= encapsulating tunnels; they are never statically configured. = When are never statically = configured. When using multiple mapping
using = multiple mapping database systems, care must be taken to not = database systems, care must be taken to = not create re-
create = re-encapsulation loops through = misconfiguration. encapsulation loops through = misconfiguration.
=
LISP Router: = A LISP router is a router that performs the functions LISP Router: A LISP router is a router that = performs the functions
of any or = all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), of any or all of the following: ITR, ETR, RTR, = Proxy-ITR (PITR),
or = Proxy-ETR (PETR). or Proxy-ETR = (PETR).
=
EID-to-RLOC = Map-Cache: The EID-to-RLOC map-cache is generally EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is = generally
= short-lived, on-demand table in an ITR that stores, tracks, and = is short-lived, on-demand table = in an ITR that stores, tracks, and is
responsible = for timing out and otherwise validating EID-to-RLOC responsible for timing out and otherwise = validating EID-to-RLOC
mappings. = This cache is distinct from the full "database" of EID- = mappings. This cache is distinct from = the full "database" of EID-
to-RLOC = mappings; it is dynamic, local to the ITR(s), and to-RLOC mappings; it is dynamic, local to the = ITR(s), and
=
skipping to = change at = page 7, line 47 =C2=B6 = skipping to change at page 7, line 40 =C2=B6
conditions = when the EID-Prefix for the site and Locator-Set for conditions when the EID-Prefix for the site and = Locator-Set for
each = EID-Prefix may not be the same on all ETRs. This has no = each EID-Prefix may not be the same on = all ETRs. This has no
negative = implications, since a partial set of Locators can be negative implications, since a partial set of = Locators can be
= used. used.
=
Recursive = Tunneling: Recursive Tunneling occurs when a packet has = Recursive Tunneling: Recursive Tunneling = occurs when a packet has
more than = one LISP IP header. Additional layers of tunneling MAY = more than one LISP IP header. Additional = layers of tunneling MAY
be employed = to implement Traffic Engineering or other re-routing be employed to implement Traffic Engineering or = other re-routing
as needed. = When this is done, an additional "outer" LISP header as needed. When this is done, an additional = "outer" LISP header
is added, = and the original RLOCs are preserved in the "inner" is added, and the original RLOCs are preserved in = the "inner"
header. = Any references to tunnels in this specification = refer to header.
dynamic encapsulating tunnels; they are never = statically
configured.
=
LISP Header: = LISP header is a term used in this document to refer LISP Header: LISP header is a term used in this = document to refer
to the = outer IPv4 or IPv6 header, a UDP header, and a LISP- to the outer IPv4 or IPv6 header, a UDP header, = and a LISP-
specific = 8-octet header that follow the UDP header and that an ITR = specific 8-octet header that follow the = UDP header and that an ITR
prepends or = an ETR strips. prepends or an = ETR strips.
=
Address Family = Identifier (AFI): AFI is a term used to describe an Address Family Identifier (AFI): AFI is a term used = to describe an
address = encoding in a packet. An address family that pertains to = address encoding in a packet. An address = family that pertains to
the = data-plane. See [AFN] and [RFC3232] for details. An AFI = the data-plane. See [AFN] and [RFC3232] = for details. An AFI
value of 0 = used in this specification indicates an unspecified value of 0 used in this specification indicates an = unspecified
=
skipping to = change at = page 8, line 37 =C2=B6 = skipping to change at page 8, line 27 =C2=B6
the = inner-header destination address equals the outer-header = the inner-header destination address = equals the outer-header
destination = address used to trigger a Map-Reply by a decapsulating destination address used to trigger a Map-Reply by = a decapsulating
ETR. In = addition, the original packet is decapsulated and ETR. In addition, the original packet is = decapsulated and
delivered = to the destination host if the destination EID is in the = delivered to the destination host if the = destination EID is in the
EID-Prefix = range configured on the ETR. Otherwise, the packet is EID-Prefix range configured on the ETR. = Otherwise, the packet is
discarded. = A Data-Probe is used in some of the mapping database discarded. A Data-Probe is used in some of the = mapping database
designs to = "probe" or request a Map-Reply from an ETR; in other designs to "probe" or request a Map-Reply from an = ETR; in other
cases, = Map-Requests are used. See each mapping database design = cases, Map-Requests are used. See each = mapping database design
for = details. When using Data-Probes, by sending Map-Requests on = for details. When using Data-Probes, by = sending Map-Requests on
the = underlying routing system, EID-Prefixes must be advertised. = the underlying routing system, = EID-Prefixes must be advertised.
However, this is discouraged if the core is to scale by = having
less EID-Prefixes stored in the core router's = routing tables.
=
Proxy-ITR = (PITR): A PITR is defined and described in [RFC6832]. A = Proxy-ITR (PITR): A PITR is defined and = described in [RFC6832]. A
PITR acts = like an ITR but does so on behalf of non-LISP sites that = PITR acts like an ITR but does so on = behalf of non-LISP sites that
send = packets to destinations at LISP sites. = send packets to destinations at LISP sites.
=
Proxy-ETR = (PETR): A PETR is defined and described in [RFC6832]. A = Proxy-ETR (PETR): A PETR is defined and = described in [RFC6832]. A
PETR acts = like an ETR but does so on behalf of LISP sites that PETR acts like an ETR but does so on behalf of = LISP sites that
send = packets to destinations at non-LISP sites. send packets to destinations at non-LISP = sites.
=
= Route-returnability: Route-returnability is an assumption that = the Route-returnability: = Route-returnability is an assumption that the
=
skipping to = change at = page 9, line 15 =C2=B6 = skipping to change at page 9, line 4 =C2=B6
destination = of the original message appears as the source of the destination of the original message appears as the = source of the
returned = message. returned = message.
=
LISP site: = LISP site is a set of routers in an edge network that are = LISP site: LISP site is a set of routers in = an edge network that are
under a = single technical administration. LISP routers that reside = under a single technical administration. = LISP routers that reside
in the edge = network are the demarcation points to separate the in the edge network are the demarcation points to = separate the
edge = network from the core network. = edge network from the core network.
=
Client-side: = Client-side is a term used in this document to indicate = Client-side: Client-side is a term used in = this document to indicate
a = connection initiation attempt by an EID. The ITR(s) at the = LISP a connection initiation = attempt by an EID. The ITR(s) at the LISP
site are = the first to get involved in obtaining database = Map-Cache site are the = first to get involved in forwarding a packet from = the
entries by sending Map-Request = messages. source EID.
=
Server-side: = Server-side is a term used in this document to indicate = Server-side: Server-side is a term used in = this document to indicate
that a = connection initiation attempt is being accepted for a that a connection initiation attempt is being = accepted for a
= destination EID. The ETR(s) at the destination = LISP site may be = destination EID.
the first to send Map-Replies to the source site = initiating the
connection. The ETR(s) at this destination site = can obtain
mappings by gleaning information from = Map-Requests, Data-Probes,
or encapsulated packets.
=
= Locator-Status-Bits (LSBs): Locator-Status-Bits are present in = the Locator-Status-Bits (LSBs): = Locator-Status-Bits are present in the
LISP = header. They are used by ITRs to inform ETRs about the up/ = LISP header. They are used by ITRs to = inform ETRs about the up/
down status = of all ETRs at the local site. These bits are used as down status of all ETRs at the local site. These = bits are used as
a hint to = convey up/down router status and not path reachability a hint to convey up/down router status and not = path reachability
status. = The LSBs can be verified by use of one of the Locator status. The LSBs can be verified by use of one of = the Locator
= reachability algorithms described in Section 10. reachability algorithms described in Section = 10.
=
Anycast = Address: Anycast Address is a term used in this document to = Anycast Address: Anycast Address is a term = used in this document to
refer to = the same IPv4 or IPv6 address configured and used on refer to the same IPv4 or IPv6 address configured = and used on
=
skipping to = change at = page 10, line 38 =C2=B6 = skipping to change at page 10, line = 25 =C2=B6
o Other types = of EID are supported by LISP, see [RFC8060] for o Other types of EID are supported by LISP, see = [RFC8060] for
further = information. further = information.
=
o LISP = routers mostly deal with Routing Locator addresses. See = o LISP routers mostly deal with Routing = Locator addresses. See
details in = Section 4.1 to clarify what is meant by "mostly". details in Section 4.1 to clarify what is meant by = "mostly".
=
o RLOCs are = always IP addresses assigned to routers, preferably o RLOCs are always IP addresses assigned to routers, = preferably
= topologically oriented addresses from provider CIDR (Classless = topologically oriented addresses from = provider CIDR (Classless
= Inter-Domain Routing) blocks. = Inter-Domain Routing) blocks.
=
o When a = router originates packets, it may use as a = source address o When a router = originates packets, it MAY use as a source = address
either an = EID or RLOC. When acting as a host (e.g., when either an EID or RLOC. When acting as a host = (e.g., when
terminating = a transport session such as Secure SHell (SSH), terminating a transport session such as Secure = SHell (SSH),
TELNET, = or the Simple Network Management Protocol (SNMP)), it may = TELNET, or the Simple Network Management Protocol (SNMP)), it MAY
use an EID = that is explicitly assigned for that purpose. An EID use an EID that is explicitly assigned for that = purpose. An EID
that = identifies the router as a host MUST NOT be used as an RLOC; = that identifies the router as a host MUST = NOT be used as an RLOC;
an EID is = only routable within the scope of a site. A typical BGP = an EID is only routable within the scope = of a site. A typical BGP
= configuration might demonstrate this "hybrid" EID/RLOC usage = where configuration might = demonstrate this "hybrid" EID/RLOC usage where
a router = could use its "host-like" EID to terminate iBGP sessions = a router could use its "host-like" EID to = terminate iBGP sessions
to other = routers in a site while at the same time using RLOCs to = to other routers in a site while at the = same time using RLOCs to
terminate = eBGP sessions to routers outside the site. terminate eBGP sessions to routers outside the = site.
=
o Packets = with EIDs in them are not expected to be delivered end-to- = o Packets with EIDs in them are not = expected to be delivered end-to-
end in the = absence of an EID-to-RLOC mapping operation. They are end in the absence of an EID-to-RLOC mapping = operation. They are
expected to = be used locally for intra-site communication or to be expected to be used locally for intra-site = communication or to be
= encapsulated for inter-site communication. encapsulated for inter-site communication.
=
o = EID-Prefixes are likely to be hierarchically assigned in a = manner o EID-Prefixes are likely = to be hierarchically assigned in a manner
that is = optimized for administrative convenience and to facilitate = that is optimized for administrative = convenience and to facilitate
scaling of = the EID-to-RLOC mapping database. The hierarchy is scaling of the EID-to-RLOC mapping database. The = hierarchy is
based on an = address allocation hierarchy that is independent of based on an address allocation hierarchy that is = independent of
the network = topology. the network = topology.
=
o EIDs = may also be structured (subnetted) in a = manner suitable for o EIDs MAY also be structured (subnetted) in a manner = suitable for
local = routing within an Autonomous System (AS). local routing within an Autonomous System = (AS).
=
An additional = LISP header MAY be prepended to packets by a TE-ITR An additional LISP header MAY be prepended to packets = by a TE-ITR
when = re-routing of the path for a packet is desired. A potential = when re-routing of the path for a packet is = desired. A potential
use-case for = this would be an ISP router that needs to perform use-case for this would be an ISP router that needs = to perform
Traffic = Engineering for packets flowing through its network. In such = Traffic Engineering for packets flowing = through its network. In such
a situation, = termed "Recursive Tunneling", an ISP transit acts as an = a situation, termed "Recursive Tunneling", = an ISP transit acts as an
additional = ITR, and the RLOC it uses for the new prepended header additional ITR, and the RLOC it uses for the new = prepended header
would be = either a TE-ETR within the ISP (along an intra-ISP traffic = would be either a TE-ETR within the ISP = (along an intra-ISP traffic
engineered = path) or a TE-ETR within another ISP (an inter-ISP traffic = engineered path) or a TE-ETR within another = ISP (an inter-ISP traffic
=
skipping to = change at = page 12, line 17 =C2=B6 = skipping to change at page 11, line = 49 =C2=B6
was not = using LISP. was not using = LISP.
=
o Each site = is multihomed, so each Tunnel Router has an address o Each site is multihomed, so each Tunnel Router has = an address
(RLOC) = assigned from the service provider address block for each = (RLOC) assigned from the service provider = address block for each
provider to = which that particular Tunnel Router is attached. provider to which that particular Tunnel Router is = attached.
=
o The ITR(s) = and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to = the source and
= destination, respectively, but the source and destination can = be destination, respectively, = but the source and destination can be
located = anywhere in the LISP site. = located anywhere in the LISP site.
=
o Map-Requests are sent to the mapping database system by = using the o A Map-Request = is sent for an external destination when the
LISP control-plane protocol documented = in destination is not = found in the forwarding table or matches a
[I-D.ietf-lisp-rfc6833bis]. A Map-Request = is sent for an external default = route. Map-Requests are sent to the mapping = database
= destination when the destination is not found in the forwarding = system by using = the LISP control-plane protocol documented in
table or = matches a default route. [I-D.ietf-lisp-rfc6833bis].
=
o Map-Replies = are sent on the underlying routing system topology o Map-Replies are sent on the underlying routing = system topology
using the = [I-D.ietf-lisp-rfc6833bis] control-plane protocol. using the [I-D.ietf-lisp-rfc6833bis] control-plane = protocol.
=
Client = host1.abc.example.com wants to communicate with server Client host1.abc.example.com wants to communicate = with server
= host2.xyz.example.com: = host2.xyz.example.com:
=
1. = host1.abc.example.com wants to open a TCP connection to = 1. host1.abc.example.com wants to open a = TCP connection to
= host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup = on
= host2.xyz.example.com. An A/AAAA record is returned. This = host2.xyz.example.com. An A/AAAA record = is returned. This
=
skipping = to change at page 13, line = 35 =C2=B6 = skipping to change at page 13, line = 20 =C2=B6
of the = addresses, strips the LISP header, and forwards packets to = of the addresses, strips the LISP = header, and forwards packets to
the = attached destination host. the = attached destination host.
=
9. In order = to defer the need for a mapping lookup in the reverse 9. In order to defer the need for a mapping lookup = in the reverse
direction, = an ETR can OPTIONALLY create a cache entry that maps direction, an ETR can OPTIONALLY create a cache = entry that maps
the source = EID (inner-header source IP address) to the source the source EID (inner-header source IP address) = to the source
RLOC = (outer-header source IP address) in a received LISP packet. = RLOC (outer-header source IP address) in = a received LISP packet.
Such a = cache entry is termed a "gleaned" mapping and only Such a cache entry is termed a "gleaned" mapping = and only
contains a = single RLOC for the EID in question. More complete contains a single RLOC for the EID in question. = More complete
= information about additional RLOCs SHOULD be verified by = sending information about = additional RLOCs SHOULD be verified by sending
a LISP = Map-Request for that EID. Both the ITR and the ETR may a = LISP Map-Request for that EID. Both the ITR and the ETR MAY
also = influence the decision the other makes in selecting an RLOC. = also influence the decision the other = makes in selecting an RLOC.
=
5. LISP = Encapsulation Details 5. LISP = Encapsulation Details
=
Since = additional tunnel headers are prepended, the packet becomes = Since additional tunnel headers are = prepended, the packet becomes
larger and can = exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed = from the ITR to
the ETR. It = is RECOMMENDED in IPv4 that packets do not get the ETR. It is RECOMMENDED in IPv4 that packets do = not get
fragmented as = they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. = Instead, the packet
is dropped and = an ICMP Unreachable/Fragmentation-Needed message is is dropped and an ICMP = Unreachable/Fragmentation-Needed message is
returned to = the source. returned to the = source.
=
This specification RECOMMENDS that = implementations provide support = In the case when fragmentation is needed, = this specification
for one of = the proposed fragmentation and reassembly schemes. Two = RECOMMENDS that implementations provide = support for one of the
existing = schemes are detailed in Section 7. = proposed fragmentation and reassembly schemes. Two existing = schemes
= are detailed in Section 7.
=
Since IPv4 or = IPv6 addresses can be either EIDs or RLOCs, the LISP Since IPv4 or IPv6 addresses can be either EIDs or = RLOCs, the LISP
architecture = supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs = (where the inner
header is in = IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header = is in IPv6
packet format) = or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where = the inner header
is in IPv6 = packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in = IPv4 packet
format). The = next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet = formats for the
homogeneous = case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but = all 4
combinations = MUST be supported. Additional types of EIDs are defined = combinations MUST be supported. Additional = types of EIDs are defined
in = [RFC8060]. in [RFC8060].
=
skipping = to change at page 14, line = 16 =C2=B6 = skipping to change at page 14, line = 4 =C2=B6
architecture = supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs = (where the inner
header is in = IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header = is in IPv6
packet format) = or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where = the inner header
is in IPv6 = packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in = IPv4 packet
format). The = next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet = formats for the
homogeneous = case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but = all 4
combinations = MUST be supported. Additional types of EIDs are defined = combinations MUST be supported. Additional = types of EIDs are defined
in = [RFC8060]. in [RFC8060].
=
5.1. LISP = IPv4-in-IPv4 Header Format 5.1. LISP = IPv4-in-IPv4 Header Format
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| IHL |Type of Service| = Total Length | / = |Version| IHL | DSCP |ECN| = Total Length |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Identification |Flags| Fragment Offset | = | | Identification |Flags| = Fragment Offset |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to = Live | Protocol =3D 17 | Header Checksum | = OH | Time to Live | Protocol =3D 17 | = Header Checksum |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Source Routing Locator | | | Source Routing Locator = |
\ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = Destination Routing Locator | \ | Destination Routing Locator = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port =3D xxxx | Dest Port =3D 4341 | = / | Source Port =3D xxxx | = Dest Port =3D 4341 |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L = |N|L|E|V|I|R|K|K| Nonce/Map-Version = | L |N|L|E|V|I|R|K|K| = Nonce/Map-Version |
I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | = Instance ID/Locator-Status-Bits | S / | Instance ID/Locator-Status-Bits = |
P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| IHL |Type of Service| = Total Length | / = |Version| IHL | DSCP |ECN| = Total Length |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Identification |Flags| Fragment Offset | = | | Identification |Flags| = Fragment Offset |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to = Live | Protocol | Header Checksum | IH | Time to Live | Protocol | Header = Checksum |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Source EID | | | Source EID = |
\ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = Destination EID | \ | Destination EID = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
IHL =3D = IP-Header-Length IHL =3D = IP-Header-Length
=
5.2. LISP = IPv6-in-IPv6 Header Format 5.2. LISP = IPv6-in-IPv6 Header Format
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| Traffic Class | Flow = Label | / = |Version| DSCP |ECN| Flow = Label |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Payload Length | Next Header=3D17| Hop Limit | = | | Payload Length | Next = Header=3D17| Hop Limit |
v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
O + = + O + = +
u | = | u | = |
t + = Source Routing Locator + t + Source Routing Locator = +
e | = | e | = |
r + = + r + = +
| = | | = |
=
skipping = to change at page 15, line = 38 =C2=B6 = skipping to change at page 15, line = 23 =C2=B6
\ | = | \ | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port =3D xxxx | Dest Port =3D 4341 | = / | Source Port =3D xxxx | = Dest Port =3D 4341 |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L = |N|L|E|V|I|R|K|K| Nonce/Map-Version = | L |N|L|E|V|I|R|K|K| = Nonce/Map-Version |
I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | = Instance ID/Locator-Status-Bits | S / | Instance ID/Locator-Status-Bits = |
P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| Traffic Class | Flow = Label | / = |Version| DSCP |ECN| Flow = Label |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Payload Length | Next Header | Hop Limit | = / | Payload Length | Next = Header | Hop Limit |
v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
I + = + I + = +
n | = | n | = |
n + = Source EID + n + Source EID = +
e | = | e | = |
r + = + r + = +
| = | | = |
=
skipping = to change at page 16, line = 4 =C2=B6 = skipping to change at page 15, line = 38 =C2=B6
I + = + I + = +
n | = | n | = |
n + = Source EID + n + Source EID = +
e | = | e | = |
r + = + r + = +
| = | | = |
H = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= H = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | = | d | = |
r + = + r + = +
| = | | = |
=
^ + = Destination EID + ^ + Destination EID = +
\ | = | \ | = |
\ + = + \ + = +
\ | = | \ | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
5.3. Tunnel = Header Field Descriptions 5.3. Tunnel = Header Field Descriptions
=
Inner Header = (IH): The inner header is the header on the datagram Inner Header (IH): The inner header is = the header on the
received = from the originating host. The source and = destination IP datagram = received from the originating host [RFC0791] = [RFC8200]
addresses = are EIDs [RFC0791] [RFC8200]. = [RFC2474]. = The source and destination IP addresses are EIDs.
=
Outer Header: = (OH) The outer header is a new header prepended by an Outer Header: (OH) The outer header is a new header = prepended by an
ITR. The = address fields contain RLOCs obtained from the ingress ITR. The address fields contain RLOCs obtained = from the ingress
router's = EID-to-RLOC Cache. The IP protocol number is "UDP (17)" = router's EID-to-RLOC Cache. The IP = protocol number is "UDP (17)"
from = [RFC0768]. The setting of the Don't Fragment (DF) bit from [RFC0768]. The setting of the Don't Fragment = (DF) bit
'Flags' = field is according to rules listed in Sections 7.1 and 'Flags' field is according to rules listed in = Sections 7.1 and
= 7.2. 7.2.
=
UDP Header: = The UDP header contains an ITR selected source port when = UDP Header: The UDP header contains an ITR = selected source port when
= encapsulating a packet. See Section 12 for details on the hash = encapsulating a packet. See Section 12 = for details on the hash
algorithm = used to select a source port based on the 5-tuple of the = algorithm used to select a source port = based on the 5-tuple of the
inner = header. The destination port MUST be set to the well-known = inner header. The destination port MUST = be set to the well-known
= IANA-assigned port value 4341. = IANA-assigned port value 4341.
=
UDP Checksum: = The 'UDP Checksum' field SHOULD be transmitted as zero UDP Checksum: The 'UDP Checksum' field SHOULD be = transmitted as zero
by an ITR = for either IPv4 [RFC0768] or IPv6 = encapsulation by an ITR for = either IPv4 [RFC0768] and IPv6 = encapsulation
[RFC6935] = [RFC6936]. When a packet with a zero UDP checksum is [RFC6935] [RFC6936]. When a packet with a zero = UDP checksum is
received by = an ETR, the ETR MUST accept the packet for received by an ETR, the ETR MUST accept the packet = for
= decapsulation. When an ITR transmits a non-zero value for the = UDP decapsulation. When an ITR = transmits a non-zero value for the UDP
checksum, = it MUST send a correctly computed value in this field. checksum, it MUST send a correctly computed value = in this field.
When an ETR = receives a packet with a non-zero UDP checksum, it MAY When an ETR receives a packet with a non-zero UDP = checksum, it MAY
choose to = verify the checksum value. If it chooses to perform choose to verify the checksum value. If it = chooses to perform
such = verification, and the verification fails, the packet MUST be = such verification, and the verification = fails, the packet MUST be
silently = dropped. If the ETR chooses not to perform the silently dropped. If the ETR chooses not to = perform the
= verification, or performs the verification successfully, the = verification, or performs the = verification successfully, the
packet MUST = be accepted for decapsulation. The handling of UDP packet MUST be accepted for decapsulation. The = handling of UDP
=
skipping = to change at page 20, line = 40 =C2=B6 = skipping to change at page 20, line = 27 =C2=B6
information = about EIDs and RLOCs, and uses LISP reachability information about EIDs and RLOCs, and uses LISP = reachability
information = mechanisms to determine the reachability of RLOCs, see information mechanisms to determine the reachability = of RLOCs, see
Section 10 for = the specific mechanisms. Section 10 = for the specific mechanisms.
=
7. Dealing with = Large Encapsulated Packets 7. Dealing = with Large Encapsulated Packets
=
This section = proposes two mechanisms to deal with packets that exceed = This section proposes two mechanisms to deal = with packets that exceed
the path MTU = between the ITR and ETR. the path = MTU between the ITR and ETR.
=
It is left to = the implementor to decide if the stateless or stateful It is left to the implementor to decide if the = stateless or stateful
mechanism = should be implemented. Both or neither = can be used, since mechanism SHOULD be implemented. Both or neither can be = used, since
it is a local = decision in the ITR regarding how to deal with MTU it is a local decision in the ITR regarding how to = deal with MTU
issues, and = sites can interoperate with differing mechanisms. issues, and sites can interoperate with differing = mechanisms.
=
Both stateless = and stateful mechanisms also apply to Re-encapsulating Both stateless and stateful mechanisms also apply to = Re-encapsulating
and Recursive = Tunneling, so any actions below referring to an ITR and Recursive Tunneling, so any actions below = referring to an ITR
also apply to = a TE-ITR. also apply to a = TE-ITR.
=
7.1. A Stateless = Solution to MTU Handling 7.1. A = Stateless Solution to MTU Handling
=
An ITR = stateless solution to handle MTU issues is described as = An ITR stateless solution to handle MTU = issues is described as
=
skipping = to change at page 21, line = 19 =C2=B6 = skipping to change at page 20, line = 49 =C2=B6
=
1. Define H = to be the size, in octets, of the outer header an ITR 1. Define H to be the size, in octets, of the outer = header an ITR
prepends = to a packet. This includes the UDP and LISP header prepends to a packet. This includes the UDP and = LISP header
= lengths. lengths.
=
2. Define L = to be the size, in octets, of the maximum-sized packet 2. Define L to be the size, in octets, of the = maximum-sized packet
an ITR can = send to an ETR without the need for the ITR or any an ITR can send to an ETR without the need for = the ITR or any
= intermediate routers to fragment the packet. intermediate routers to fragment the = packet.
=
3. Define an = architectural constant S for the maximum size of a 3. Define an architectural constant S for the = maximum size of a
packet, = in octets, an ITR must receive from the = source so the packet, in = octets, an ITR MUST receive from the = source so the
effective = MTU can be met. That is, L =3D S + H. = effective MTU can be met. That is, L =3D S + H.
=
When an ITR = receives a packet from a site-facing interface and adds H = When an ITR receives a packet from a = site-facing interface and adds H
octets worth = of encapsulation to yield a packet size greater than L octets worth of encapsulation to yield a packet size = greater than L
octets = (meaning the received packet size was greater than S octets = octets (meaning the received packet size was = greater than S octets
from the = source), it resolves the MTU issue by first splitting the = from the source), it resolves the MTU issue = by first splitting the
original = packet into 2 equal-sized fragments. A LISP header is then = original packet into 2 equal-sized = fragments. A LISP header is then
prepended to = each fragment. The size of the encapsulated fragments prepended to each fragment. The size of the = encapsulated fragments
is then (S/2 + = H), which is less than the ITR's estimate of the path is then (S/2 + H), which is less than the ITR's = estimate of the path
MTU between = the ITR and its correspondent ETR. = MTU between the ITR and its correspondent ETR.
=
skipping = to change at page 23, line = 14 =C2=B6 = skipping to change at page 22, line = 43 =C2=B6
=
When an ETR = decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID = from the LISP
header is used = as a table identifier to locate the forwarding table header is used as a table identifier to locate the = forwarding table
to use for the = inner destination EID lookup. to = use for the inner destination EID lookup.
=
For example, = an 802.1Q VLAN tag or VPN identifier could be used as a = For example, an 802.1Q VLAN tag or VPN = identifier could be used as a
24-bit = Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case = 24-bit Instance ID. See [I-D.ietf-lisp-vpn] = for LISP VPN use-case
= details. details.
=
The Instance = ID that is stored in the mapping database when LISP-DDT = The Instance ID that is stored in the = mapping database when LISP-DDT
[I-D.ietf-lisp-ddt] is used is 32 bits in = length. That means the [RFC8111] is used is 32 bits in length. That = means the control-plane
= control-plane can store more instances than a given data-plane = can can store more instances than = a given data-plane can use. Multiple
use. = Multiple data-planes can use the same 32-bit space as long as = data-planes can use the same 32-bit space = as long as the low-order 24
the = low-order 24 bits don't overlap among xTRs. bits don't overlap among xTRs.
=
9. Routing = Locator Selection 9. Routing Locator = Selection
=
Both the = client-side and server-side may need = control over the Both the = client-side and server-side MAY need = control over the
selection of = RLOCs for conversations between them. This control is selection of RLOCs for conversations between them. = This control is
achieved by = manipulating the 'Priority' and 'Weight' fields in EID- = achieved by manipulating the 'Priority' and = 'Weight' fields in EID-
to-RLOC = Map-Reply messages. Alternatively, RLOC information MAY be = to-RLOC Map-Reply messages. Alternatively, = RLOC information MAY be
gleaned from = received tunneled packets or EID-to-RLOC Map-Request gleaned from received tunneled packets or EID-to-RLOC = Map-Request
= messages. messages.
=
The following = are different scenarios for choosing RLOCs and the The following are different scenarios for choosing = RLOCs and the
controls that = are available: controls that are = available:
=
o The = server-side returns one RLOC. The client-side can only use = o The server-side returns one RLOC. The = client-side can only use
=
skipping = to change at page 24, line = 48 =C2=B6 = skipping to change at page 24, line = 34 =C2=B6
stored in the = mapping database system provides reachability stored in the mapping database system provides = reachability
information = for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not = part of the
mapping system = and is determined using one or more of the Routing mapping system and is determined using one or more of = the Routing
Locator = reachability algorithms described in the next section. Locator reachability algorithms described in the next = section.
=
10. Routing = Locator Reachability 10. Routing = Locator Reachability
=
Several = mechanisms for determining RLOC reachability are currently = Several mechanisms for determining RLOC = reachability are currently
= defined: defined:
=
1. An ETR = may examine the Locator-Status-Bits in the = LISP header of 1. An ETR MAY examine the Locator-Status-Bits in the LISP = header of
an = encapsulated data packet received from an ITR. If the ETR is = an encapsulated data packet received = from an ITR. If the ETR is
also = acting as an ITR and has traffic to return to the original = also acting as an ITR and has traffic to = return to the original
ITR site, = it can use this status information to help select an ITR site, it can use this status information to = help select an
= RLOC. RLOC.
=
2. An ITR = may receive an ICMP Network Unreachable or = Host 2. An ITR MAY receive an ICMP Network Unreachable or = Host
= Unreachable message for an RLOC it is using. This indicates = that Unreachable message for an = RLOC it is using. This indicates that
the RLOC = is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP = messages may
not be = desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them = completely.
= Implementations are encouraged to follow current best practices = Implementations are encouraged to follow = current best practices
in = treating these conditions. in = treating these conditions.
=
3. An ITR = that participates in the global routing system can 3. An ITR that participates in the global routing = system can
determine = that an RLOC is down if no BGP Routing Information Base = determine that an RLOC is down if no BGP = Routing Information Base
(RIB) = route exists that matches the RLOC IP address. (RIB) route exists that matches the RLOC IP = address.
=
4. An ITR = may receive an ICMP Port Unreachable = message from a 4. An ITR MAY receive an ICMP Port Unreachable message = from a
= destination host. This occurs if an ITR attempts to use = destination host. This occurs if an ITR = attempts to use
= interworking [RFC6832] and LISP-encapsulated data is sent to a = interworking [RFC6832] and = LISP-encapsulated data is sent to a
= non-LISP-capable site. = non-LISP-capable site.
=
5. An ITR = may receive a Map-Reply from an ETR in = response to a 5. An ITR MAY receive a Map-Reply from an ETR in response = to a
previously = sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of = the Map-Reply is
likely up, = since the ETR was able to send the Map-Reply to the likely up, since the ETR was able to send the = Map-Reply to the
= ITR. ITR.
=
6. When an = ETR receives an encapsulated packet from an ITR, the 6. When an ETR receives an encapsulated packet from = an ITR, the
source = RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet = is likely up.
=
7. An ITR/ETR = pair can use the Locator reachability algorithms 7. An ITR/ETR pair can use the Locator reachability = algorithms
described = in this section, namely Echo-Noncing or RLOC-Probing. described in this section, namely Echo-Noncing or = RLOC-Probing.
=
=
skipping = to change at page 26, line = 17 =C2=B6 = skipping to change at page 26, line = 6 =C2=B6
=
When an ETR = decapsulates a packet, it will check for any change in When an ETR decapsulates a packet, it will check for = any change in
the = 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the = the 'Locator-Status-Bits' field. When a bit = goes from 1 to 0, the
ETR, if acting = also as an ITR, will refrain from encapsulating ETR, if acting also as an ITR, will refrain from = encapsulating
packets to an = RLOC that is indicated as down. It will only resume packets to an RLOC that is indicated as down. It = will only resume
using that = RLOC if the corresponding Locator-Status-Bit returns to a = using that RLOC if the corresponding = Locator-Status-Bit returns to a
value of 1. = Locator-Status-Bits are associated with a Locator-Set value of 1. Locator-Status-Bits are associated with = a Locator-Set
per = EID-Prefix. Therefore, when a Locator becomes unreachable, the = per EID-Prefix. Therefore, when a Locator = becomes unreachable, the
= Locator-Status-Bit that corresponds to that Locator's position in = the Locator-Status-Bit that = corresponds to that Locator's position in the
list returned = by the last Map-Reply will be set to zero for that list returned by the last Map-Reply will be set to = zero for that
particular = EID-Prefix. particular EID-Prefix. = Refer to Section 19 for security = related
= issues regarding = Locator-Status-Bits.
=
When ITRs at = the site are not deployed in CE routers, the IGP can When ITRs at the site are not deployed in CE routers, = the IGP can
still be used = to determine the reachability of Locators, provided still be used to determine the reachability of = Locators, provided
they are = injected into the IGP. This is typically done when a /32 = they are injected into the IGP. This is = typically done when a /32
address is = configured on a loopback interface. = address is configured on a loopback interface.
=
When ITRs = receive ICMP Network Unreachable or Host Unreachable When ITRs receive ICMP Network Unreachable or Host = Unreachable
messages as a = method to determine unreachability, they will refrain messages as a method to determine unreachability, = they will refrain
from using = Locators that are described in Locator lists of Map- from using Locators that are described in Locator = lists of Map-
Replies. = However, using this approach is unreliable because many = Replies. However, using this approach is = unreliable because many
=
skipping = to change at page 27, line = 45 =C2=B6 = skipping to change at page 27, line = 36 =C2=B6
E-bit cleared. = The ITR sees this "echoed nonce" and knows that the E-bit cleared. The ITR sees this "echoed nonce" and = knows that the
path to and = from the ETR is up. path to and = from the ETR is up.
=
The ITR will = set the E-bit and N-bit for every packet it sends while = The ITR will set the E-bit and N-bit for = every packet it sends while
in the = echo-nonce-request state. The time the ITR waits to process = in the echo-nonce-request state. The time = the ITR waits to process
the echoed = nonce before it determines the path is unreachable is the echoed nonce before it determines the path is = unreachable is
variable and = is a choice left for the implementation. variable and is a choice left for the = implementation.
=
If the ITR is = receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does = not see the
nonce echoed = while being in the echo-nonce-request state, then the nonce echoed while being in the echo-nonce-request = state, then the
path to the = ETR is unreachable. This decision may be = overridden by path to the ETR is = unreachable. This decision MAY be = overridden by
other Locator = reachability algorithms. Once the ITR determines that other Locator reachability algorithms. Once the ITR = determines that
the path to = the ETR is down, it can switch to another Locator for the path to the ETR is down, it can switch to another = Locator for
that = EID-Prefix. that = EID-Prefix.
=
Note that = "ITR" and "ETR" are relative terms here. Both devices MUST = Note that "ITR" and "ETR" are relative terms = here. Both devices MUST
be = implementing both ITR and ETR functionality for the echo nonce = be implementing both ITR and ETR = functionality for the echo nonce
mechanism to = operate. mechanism to = operate.
=
The ITR and = ETR may both go into the = echo-nonce-request state at the = The ITR and ETR MAY both go into the = echo-nonce-request state at the
same time. = The number of packets sent or the time during which echo = same time. The number of packets sent or = the time during which echo
nonce requests = are sent is an implementation-specific setting. nonce requests are sent is an implementation-specific = setting.
However, when = an ITR is in the echo-nonce-request state, it can echo However, when an ITR is in the echo-nonce-request = state, it can echo
the ETR's = nonce in the next set of packets that it encapsulates and = the ETR's nonce in the next set of packets = that it encapsulates and
subsequently = continue sending echo-nonce-request packets. subsequently continue sending echo-nonce-request = packets.
=
This mechanism = does not completely solve the forward path This mechanism does not completely solve the forward = path
reachability = problem, as traffic may be unidirectional. That is, the = reachability problem, as traffic may be = unidirectional. That is, the
ETR = receiving traffic at a site may not be the = same device as an ITR ETR = receiving traffic at a site MAY not be the = same device as an ITR
that transmits = traffic from that site, or the site-to-site traffic is that transmits traffic from that site, or the = site-to-site traffic is
unidirectional = so there is no ITR returning traffic. = unidirectional so there is no ITR returning traffic.
=
The echo-nonce = algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if = one side sets the
E-bit and the = other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for = echo-noncing, then the
echoing of the = nonce does not occur and the requesting side may echoing of the nonce does not occur and the = requesting side may
erroneously = consider the Locator unreachable. An ITR SHOULD only set = erroneously consider the Locator = unreachable. An ITR SHOULD only set
the E-bit in = an encapsulated data packet when it knows the ETR is the E-bit in an encapsulated data packet when it = knows the ETR is
enabled for = echo-noncing. This is conveyed by the E-bit in the RLOC- = enabled for echo-noncing. This is conveyed = by the E-bit in the RLOC-
probe = Map-Reply message. probe Map-Reply = message.
=
Note that other Locator reachability mechanisms are= being researched Note = other Locator Reachability mechanisms can = be used to compliment
and can be used to compliment or even = override the echo nonce or even = override the echo nonce algorithm. See the next section for
algorithm. = See the next section for an example of control-plane an example of control-plane probing.
= probing.
=
10.2. = RLOC-Probing Algorithm 10.2. = RLOC-Probing Algorithm
=
RLOC-Probing = is a method that an ITR or PITR can use to determine the = RLOC-Probing is a method that an ITR or PITR = can use to determine the
reachability = status of one or more Locators that it has cached in a reachability status of one or more Locators that it = has cached in a
Map-Cache = entry. The probe-bit of the Map-Request and Map-Reply Map-Cache entry. The probe-bit of the Map-Request = and Map-Reply
messages is = used for RLOC-Probing. messages is = used for RLOC-Probing.
=
RLOC-Probing = is done in the control plane on a timer basis, where an = RLOC-Probing is done in the control plane on = a timer basis, where an
ITR or PITR = will originate a Map-Request destined to a locator ITR or PITR will originate a Map-Request destined to = a locator
address from = one of its own locator addresses. A Map-Request used as = address from one of its own locator = addresses. A Map-Request used as
an RLOC-probe = is NOT encapsulated and NOT sent to a Map-Server or to an RLOC-probe is NOT encapsulated and NOT sent to a = Map-Server or to
the mapping = database system as one would when soliciting mapping the mapping database system as one would when = soliciting mapping
data. The EID = record encoded in the Map-Request is the EID-Prefix of data. The EID record encoded in the Map-Request is = the EID-Prefix of
the = Map-Cache entry cached by the ITR or PITR. The ITR may include a = the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a
mapping data = record for its own database mapping information that mapping data record for its own database mapping = information that
contains the = local EID-Prefixes and RLOCs for its site. RLOC-probes = contains the local EID-Prefixes and RLOCs = for its site. RLOC-probes
are sent = periodically using a jittered timer interval. are sent periodically using a jittered timer = interval.
=
When an ETR = receives a Map-Request message with the probe-bit set, it = When an ETR receives a Map-Request message = with the probe-bit set, it
returns a = Map-Reply with the probe-bit set. The source address of = returns a Map-Reply with the probe-bit set. = The source address of
the Map-Reply = is set according to the procedure described in the Map-Reply is set according to the procedure = described in
= [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain = mapping [I-D.ietf-lisp-rfc6833bis]. = The Map-Reply SHOULD contain mapping
data for the = EID-Prefix contained in the Map-Request. This provides = data for the EID-Prefix contained in the = Map-Request. This provides
the = opportunity for the ITR or PITR that sent the RLOC-probe to get = the opportunity for the ITR or PITR that = sent the RLOC-probe to get
=
skipping = to change at page 29, line = 27 =C2=B6 = skipping to change at page 29, line = 14 =C2=B6
reachable or = has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a = robust
mechanism for = switching to using another Locator from the cached mechanism for switching to using another Locator from = the cached
Locator. = RLOC-Probing can also provide rough Round-Trip Time (RTT) = Locator. RLOC-Probing can also provide = rough Round-Trip Time (RTT)
estimates = between a pair of Locators, which can be useful for network = estimates between a pair of Locators, which = can be useful for network
management = purposes as well as for selecting low delay paths. The = management purposes as well as for selecting = low delay paths. The
major = disadvantage of RLOC-Probing is in the number of control = major disadvantage of RLOC-Probing is in the = number of control
messages = required and the amount of bandwidth used to obtain those = messages required and the amount of = bandwidth used to obtain those
benefits, = especially if the requirement for failure detection times = benefits, especially if the requirement for = failure detection times
is very = small. is very small.
=
Continued research and testing will attempt to = characterize the
tradeoffs of failure detection times versus message = overhead.
= =
11. EID = Reachability within a LISP Site 11. = EID Reachability within a LISP Site
=
A site may be multihomed using two or more ETRs. The = hosts and A site MAY be multihomed using two or more ETRs. The = hosts and
infrastructure = within a site will be addressed using one or more EID- infrastructure within a site will be addressed using = one or more EID-
Prefixes that = are mapped to the RLOCs of the relevant ETRs in the Prefixes that are mapped to the RLOCs of the relevant = ETRs in the
mapping = system. One possible failure mode is for an ETR to lose = mapping system. One possible failure mode = is for an ETR to lose
reachability = to one or more of the EID-Prefixes within its own site. = reachability to one or more of the = EID-Prefixes within its own site.
When this = occurs when the ETR sends Map-Replies, it can clear the = When this occurs when the ETR sends = Map-Replies, it can clear the
R-bit = associated with its own Locator. And when the ETR is also an = R-bit associated with its own Locator. And = when the ETR is also an
ITR, it can = clear its Locator-Status-Bit in the encapsulation data ITR, it can clear its Locator-Status-Bit in the = encapsulation data
= header. header.
=
It is = recognized that there are no simple solutions to the site = It is recognized that there are no simple = solutions to the site
partitioning = problem because it is hard to know which part of the partitioning problem because it is hard to know which = part of the
EID-Prefix = range is partitioned and which Locators can reach any sub- = EID-Prefix range is partitioned and which = Locators can reach any sub-
ranges of = the EID-Prefixes. This problem is under = investigation with ranges = of the EID-Prefixes. Note that this is not a new problem
the expectation that experiments will tell us = more. Note that this = introduced by the LISP architecture. The problem exists today when = a
is not a new = problem introduced by the LISP architecture. The multihomed site uses BGP to advertise its = reachability upstream.
problem = exists today when a multihomed site uses BGP to advertise its =
reachability = upstream.
=
12. Routing = Locator Hashing 12. Routing Locator = Hashing
=
When an ETR = provides an EID-to-RLOC mapping in a Map-Reply message to When an = ETR provides an EID-to-RLOC mapping in a Map-Reply message
a requesting = ITR, the Locator-Set for the EID-Prefix may = contain that = is stored in the map-cache of a requesting ITR, the = Locator-Set
different = Priority values for each locator address. When more than = for the EID-Prefix MAY contain different Priority and Weight values
one best = Priority Locator exists, the ITR can decide how to load- for = each locator address. When more than one best Priority Locator
share traffic against the corresponding = Locators. exists, the ITR can = decide how to load-share traffic against = the
= corresponding Locators.
=
The = following hash algorithm may be used by an = ITR to select a The following hash = algorithm MAY be used by an ITR to select = a
Locator for a = packet destined to an EID for the EID-to-RLOC mapping: Locator for a packet destined to an EID for the = EID-to-RLOC mapping:
=
1. Either a = source and destination address hash or the traditional 1. Either a source and destination address hash or = the traditional
5-tuple = hash can be used. The traditional 5-tuple hash includes = 5-tuple hash can be used. The = traditional 5-tuple hash includes
the source = and destination addresses; source and destination TCP, the source and destination addresses; source and = destination TCP,
UDP, or = Stream Control Transmission Protocol (SCTP) port numbers; = UDP, or Stream Control Transmission = Protocol (SCTP) port numbers;
and the IP = protocol number field or IPv6 next-protocol fields of and the IP protocol number field or IPv6 = next-protocol fields of
a packet = that a host originates from within a LISP site. When a = a packet that a host originates from = within a LISP site. When a
packet is = not a TCP, UDP, or SCTP packet, the source and packet is not a TCP, UDP, or SCTP packet, the = source and
= destination addresses only from the header are used to compute = destination addresses only from the = header are used to compute
=
skipping = to change at page 34, line = 6 =C2=B6 = skipping to change at page 33, line = 30 =C2=B6
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
sender of an = SMR-based Map-Request MUST be verified. If an ITR sender of an SMR-based Map-Request MUST be verified. = If an ITR
receives an = SMR-based Map-Request and the source is not in the receives an SMR-based Map-Request and the source is = not in the
Locator-Set = for the stored Map-Cache entry, then the responding Map- = Locator-Set for the stored Map-Cache entry, = then the responding Map-
Request MUST = be sent with an EID destination to the mapping database = Request MUST be sent with an EID destination = to the mapping database
system. Since = the mapping database system is a more secure way to system. Since the mapping database system is a more = secure way to
reach an = authoritative ETR, it will deliver the Map-Request to the = reach an authoritative ETR, it will deliver = the Map-Request to the
authoritative = source of the mapping data. = authoritative source of the mapping data.
=
When an ITR = receives an SMR-based Map-Request for which it does not = When an ITR receives an SMR-based = Map-Request for which it does not
have a = cached mapping for the EID in the SMR message, it MAY not send = have a cached mapping for the EID in the SMR message, it may not send
an SMR-invoked = Map-Request. This scenario can occur when an ETR an SMR-invoked Map-Request. This scenario can occur = when an ETR
sends SMR = messages to all Locators in the Locator-Set it has stored = sends SMR messages to all Locators in the = Locator-Set it has stored
in its = map-cache but the remote ITRs that receive the SMR may not be = in its map-cache but the remote ITRs that = receive the SMR may not be
sending = packets to the site. There is no point in updating the ITRs = sending packets to the site. There is no = point in updating the ITRs
until they = need to send, in which case they will send Map-Requests to = until they need to send, in which case they = will send Map-Requests to
obtain a = Map-Cache entry. obtain a Map-Cache = entry.
=
13.3. Database = Map-Versioning 13.3. Database = Map-Versioning
=
When there is = unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an = ITR and ETR, and
=
skipping = to change at page 35, line = 52 =C2=B6 = skipping to change at page 35, line = 26 =C2=B6
few = implementation techniques can be used to incrementally = implement few implementation = techniques can be used to incrementally implement
LISP: = LISP:
=
o When a = tunnel-encapsulated packet is received by an ETR, the outer = o When a tunnel-encapsulated packet is = received by an ETR, the outer
destination = address may not be the address of the router. This destination address may not be the address of the = router. This
makes it = challenging for the control plane to get packets from the = makes it challenging for the control = plane to get packets from the
hardware. = This may be mitigated by creating special Forwarding hardware. This may be mitigated by creating = special Forwarding
Information = Base (FIB) entries for the EID-Prefixes of EIDs served Information Base (FIB) entries for the = EID-Prefixes of EIDs served
by the ETR = (those for which the router provides an RLOC by the ETR (those for which the router provides an = RLOC
= translation). These FIB entries are marked with a flag = indicating translation). These = FIB entries are marked with a flag indicating
that = control-plane processing should be = performed. The forwarding that = control-plane processing SHOULD be = performed. The forwarding
logic of = testing for particular IP protocol number values is not = logic of testing for particular IP = protocol number values is not
necessary. = There are a few proven cases where no changes to necessary. There are a few proven cases where no = changes to
existing = deployed hardware were needed to support the LISP data- = existing deployed hardware were needed to = support the LISP data-
= plane. plane.
=
o On an ITR, = prepending a new IP header consists of adding more o On an ITR, prepending a new IP header consists of = adding more
octets to a = MAC rewrite string and prepending the string as part octets to a MAC rewrite string and prepending the = string as part
of the = outgoing encapsulation procedure. Routers that support = of the outgoing encapsulation procedure. = Routers that support
Generic = Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 = Generic Routing Encapsulation (GRE) = tunneling [RFC2784] or 6to4
tunneling = [RFC3056] may already support this action. tunneling [RFC3056] may already support this = action.
=
skipping = to change at page 38, line = 15 =C2=B6 = skipping to change at page 37, line = 40 =C2=B6
17. LISP xTR = Placement and Encapsulation Methods 17. = LISP xTR Placement and Encapsulation Methods
=
This section = will explore how and where ITRs and ETRs can be placed This section will explore how and where ITRs and ETRs = can be placed
in the network = and will discuss the pros and cons of each scenario. in the network and will discuss the pros and cons of = each scenario.
For a more = detailed networkd design deployment recommendation, refer = For a more detailed networkd design = deployment recommendation, refer
to = [RFC7215]. to [RFC7215].
=
There are two = basic deployment tradeoffs to consider: centralized There are two basic deployment tradeoffs to consider: = centralized
versus = distributed caches; and flat, Recursive, or Re-encapsulating = versus distributed caches; and flat, = Recursive, or Re-encapsulating
Tunneling. = When deciding on centralized versus distributed caching, = Tunneling. When deciding on centralized = versus distributed caching,
the = following issues should be = considered: the following issues = SHOULD be considered:
=
o Are the = xTRs spread out so that the caches are spread across all = o Are the xTRs spread out so that the = caches are spread across all
the = memories of each router? A centralized cache is when an ITR = the memories of each router? A = centralized cache is when an ITR
keeps a = cache for all the EIDs it is encapsulating to. The packet = keeps a cache for all the EIDs it is = encapsulating to. The packet
takes a = direct path to the destination Locator. A distributed takes a direct path to the destination Locator. A = distributed
cache is = when an ITR needs help from other Re-Encapsulating Tunnel = cache is when an ITR needs help from = other Re-Encapsulating Tunnel
Routers = (RTRs) because it does not store all the cache entries for = Routers (RTRs) because it does not store = all the cache entries for
the EIDs it = is encapsulating to. So, the packet takes a path the EIDs it is encapsulating to. So, the packet = takes a path
through = RTRs that have a different set of cache entries. through RTRs that have a different set of cache = entries.
=
o Should = management "touch points" be minimized by only choosing a = o Should management "touch points" be = minimized by only choosing a
few xTRs, = just enough for redundancy? few = xTRs, just enough for redundancy?
=
o In general, = using more ITRs doesn't increase management load, o In general, using more ITRs doesn't increase = management load,
since = caches are built and stored dynamically. On the other hand, = since caches are built and stored = dynamically. On the other hand,
using more = ETRs does require more management, since EID-Prefix-to- = using more ETRs does require more = management, since EID-Prefix-to-
RLOC = mappings need to be explicitly configured. RLOC mappings need to be explicitly = configured.
=
When deciding = on flat, Recursive, or Re-Encapsulating Tunneling, the When deciding on flat, Recursive, or Re-Encapsulating = Tunneling, the
following = issues should be considered: = following issues SHOULD be considered:
=
o Flat = tunneling implements a single encapsulation path between the = o Flat tunneling implements a single = encapsulation path between the
source site = and destination site. This generally offers better source site and destination site. This generally = offers better
paths = between sources and destinations with a single encapsulation = paths between sources and destinations = with a single encapsulation
= path. path.
=
o Recursive = Tunneling is when encapsulated traffic is again further = o Recursive Tunneling is when encapsulated = traffic is again further
= encapsulated in another tunnel, either to implement VPNs or to = encapsulated in another tunnel, either to = implement VPNs or to
perform = Traffic Engineering. When doing VPN-based tunneling, the = perform Traffic Engineering. When doing = VPN-based tunneling, the
site has = some control, since the site is prepending a new site has some control, since the site is = prepending a new
= encapsulation header. In the case of TE-based tunneling, the = site encapsulation header. In = the case of TE-based tunneling, the site
may have control if it is prepending a new = tunnel header, but if MAY have control if it is prepending a new = tunnel header, but if
the site's = ISP is doing the TE, then the site has no control. the site's ISP is doing the TE, then the site has = no control.
Recursive = Tunneling generally will result in suboptimal paths but = Recursive Tunneling generally will result = in suboptimal paths but
with the = benefit of steering traffic to parts of the network that = with the benefit of steering traffic to = parts of the network that
have more = resources available. have more = resources available.
=
o The = technique of Re-Encapsulation ensures that packets only = o The technique of Re-Encapsulation ensures = that packets only
require one = encapsulation header. So, if a packet needs to be re- require one encapsulation header. So, if a packet = needs to be re-
routed, it = is first decapsulated by the RTR and then Re- routed, it is first decapsulated by the RTR and = then Re-
= Encapsulated with a new encapsulation header using a new RLOC. = Encapsulated with a new encapsulation = header using a new RLOC.
=
=
skipping = to change at page 41, line = 12 =C2=B6 = skipping to change at page 40, line = 36 =C2=B6
addresses MUST = be used only in the outer IP header so the NAT device addresses MUST be used only in the outer IP header so = the NAT device
can translate = properly. Otherwise, EID addresses MUST be translated can translate properly. Otherwise, EID addresses = MUST be translated
before = encapsulation is performed when LISP VPNs are not in use. = before encapsulation is performed when LISP = VPNs are not in use.
Both NAT = translation and LISP encapsulation functions could be co- = Both NAT translation and LISP encapsulation = functions could be co-
located in the = same device. located in the same = device.
=
17.5. Packets = Egressing a LISP Site 17.5. Packets = Egressing a LISP Site
=
When a LISP = site is using two ITRs for redundancy, the failure of one = When a LISP site is using two ITRs for = redundancy, the failure of one
ITR will = likely shift outbound traffic to the second. This second = ITR will likely shift outbound traffic to = the second. This second
ITR's cache = may not be populated with the same = EID-to-RLOC mapping ITR's cache = MAY not be populated with the same = EID-to-RLOC mapping
entries as the = first. If this second ITR does not have these entries as the first. If this second ITR does not = have these
mappings, = traffic will be dropped while the mappings are retrieved = mappings, traffic will be dropped while the = mappings are retrieved
from the = mapping system. The retrieval of these messages may from the mapping system. The retrieval of these = messages may
increase the = load of requests being sent into the mapping system. increase the load of requests being sent into the = mapping system.
=
18. Traceroute = Considerations 18. Traceroute = Considerations
=
When a source = host in a LISP site initiates a traceroute to a When a source host in a LISP site initiates a = traceroute to a
destination = host in another LISP site, it is highly desirable for it = destination host in another LISP site, it is = highly desirable for it
to see the = entire path. Since packets are encapsulated from the ITR = to see the entire path. Since packets are = encapsulated from the ITR
=
skipping = to change at page 44, line = 16 =C2=B6 = skipping to change at page 43, line = 42 =C2=B6
=
Map-Versioning = is a data-plane mechanism used to signal a peering xTR Map-Versioning is a data-plane mechanism used to = signal a peering xTR
that a local = EID-to-RLOC mapping has been updated, so that the that a local EID-to-RLOC mapping has been updated, so = that the
peering xTR = uses LISP Control-Plane signaling message to retrieve a = peering xTR uses LISP Control-Plane = signaling message to retrieve a
fresh mapping. = This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to = forge the map-
versioning = field of a LISP encapsulated header and force an excessive = versioning field of a LISP encapsulated = header and force an excessive
amount of = signaling between xTRs that may overload them. amount of signaling between xTRs that may overload = them.
=
Most of the = attack vectors can be mitigated with careful deployment = Most of the attack vectors can be mitigated = with careful deployment
and = configuration, information learned opportunistically (such as = LSB and configuration, information = learned opportunistically (such as LSB
or gleaning) = should be verified with other reachability = mechanisms. or gleaning) SHOULD be verified with other reachability = mechanisms.
In addition, = systematic rate-limitation and filtering is an effective = In addition, systematic rate-limitation and = filtering is an effective
technique to = mitigate attacks that aim to overload the control-plane. = technique to mitigate attacks that aim to = overload the control-plane.
=
20. Network = Management Considerations 20. Network = Management Considerations
=
Considerations = for network management tools exist so the LISP Considerations for network management tools exist so = the LISP
protocol suite = can be operationally managed. These mechanisms can be protocol suite can be operationally managed. These = mechanisms can be
found in = [RFC7052] and [RFC6835]. found in = [RFC7052] and [RFC6835].
=
21. IANA = Considerations 21. IANA = Considerations
=
This section = provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet = Assigned Numbers
Authority = (IANA) regarding registration of values related to this = Authority (IANA) regarding registration of = values related to this
data-plane = LISP specification, in accordance with BCP 26 [RFC5226]. = data-plane LISP specification, in accordance with BCP 26 [RFC8126].
=
21.1. LISP UDP = Port Numbers 21.1. LISP UDP Port = Numbers
=
The IANA = registry has allocated UDP port numbers 4341 and 4342 for = The IANA registry has allocated UDP port = numbers 4341 and 4342 for
lisp-data and = lisp-control operation, respectively. IANA has updated = lisp-data and lisp-control operation, = respectively. IANA has updated
the = description for UDP ports 4341 and 4342 as follows: the description for UDP ports 4341 and 4342 as = follows:
=
lisp-data = 4341 udp LISP Data Packets = lisp-data 4341 udp LISP Data Packets
= lisp-control 4342 udp LISP Control Packets lisp-control 4342 udp LISP Control = Packets
=
22. = References 22. References
=
22.1. Normative = References 22.1. Normative = References
=
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
Smirnov, "LISP Delegated Database Tree", = draft-ietf-lisp-
ddt-09 (work in progress), January = 2017.
[I-D.ietf-lisp-introduction] =
Cabellos-Aparicio, A. and D. Saucez, "An = Architectural
Introduction to the Locator/ID Separation = Protocol
(LISP)", draft-ietf-lisp-introduction-13 = (work in
progress), April 2015. =
= =
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-06 (work in progress), = October = draft-ietf-lisp-rfc6833bis-07 (work in progress), = December
= 2017. 2017.
=
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., = Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", = draft-ietf-lisp-sec-14
(work in progress), October = 2017.
= =
[RFC0768] = Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD = 6, RFC 768,
DOI = 10.17487/RFC0768, August 1980, = DOI 10.17487/RFC0768, August 1980,
= <https://www.rfc-editor.org/info/rfc768>. = <https://www.rfc-editor.org/info/rfc768>.
=
[RFC0791] = Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, = RFC 791,
DOI = 10.17487/RFC0791, September 1981, = DOI 10.17487/RFC0791, September 1981,
= <https://www.rfc-editor.org/info/rfc791>. = <https://www.rfc-editor.org/info/rfc791>.
=
[RFC1918] = Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., = [RFC1918] Rekhter, Y., Moskowitz, B., = Karrenberg, D., de Groot, G.,
and = E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for = Private Internets",
BCP = 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, = February 1996,
= <https://www.rfc-editor.org/info/rfc1918>. = <https://www.rfc-editor.org/info/rfc1918>.
=
[RFC2119] = Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
= Requirement Levels", BCP 14, RFC 2119, = Requirement Levels", BCP 14, RFC 2119,
DOI = 10.17487/RFC2119, March 1997, = DOI 10.17487/RFC2119, March 1997,
= <https://www.rfc-editor.org/info/rfc2119>. = <https://www.rfc-editor.org/info/rfc2119>.
=
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2474] Nichols, K., = Blake, S., Baker, F., and D. = Black,
ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November = = "Definition of the Differentiated Services = Field (DS
= 1998, <https://www.rfc-editor.org/info/rfc2404>. = Field) in the IPv4 and IPv6 = Headers", RFC 2474,
= DOI 10.17487/RFC2474, December 1998,
= <https://www.rfc-editor.org/info/rfc2474>.
=
[RFC3168] = Ramakrishnan, K., Floyd, S., and D. Black, "The Addition = [RFC3168] Ramakrishnan, K., Floyd, S., and = D. Black, "The Addition
of = Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) = to IP",
RFC = 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September = 2001,
= <https://www.rfc-editor.org/info/rfc3168>. = <https://www.rfc-editor.org/info/rfc3168>.
=
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC = 1700 is Replaced
by an On-line Database", RFC 3232, DOI = 10.17487/RFC3232,
January 2002, = <https://www.rfc-editor.org/info/rfc3232>. =
= =
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4632] = Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless = Inter-domain Routing
= (CIDR): The Internet Address Assignment and Aggregation = (CIDR): The Internet Address = Assignment and Aggregation
= Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI = 10.17487/RFC4632, August
= 2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, = <https://www.rfc-editor.org/info/rfc4632>.
=
[RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI 10.17487/RFC4868, May = 2007,
= <https://www.rfc-editor.org/info/rfc4868>. =
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines = for Writing an
IANA Considerations Section in RFCs", RFC = 5226,
DOI 10.17487/RFC5226, May = 2008,
= <https://www.rfc-editor.org/info/rfc5226>. =
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, = "The Reverse Path
Forwarding (RPF) Vector TLV", RFC = 5496,
DOI 10.17487/RFC5496, March = 2009,
= <https://www.rfc-editor.org/info/rfc5496>. =
= =
[RFC5944] = Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", = [RFC5944] Perkins, C., Ed., "IP Mobility = Support for IPv4, Revised",
RFC = 5944, DOI 10.17487/RFC5944, November 2010, RFC 5944, DOI 10.17487/RFC5944, November = 2010,
= <https://www.rfc-editor.org/info/rfc5944>. = <https://www.rfc-editor.org/info/rfc5944>.
=
[RFC6115] Li, T., Ed., "Recommendation for a Routing = Architecture",
RFC 6115, DOI 10.17487/RFC6115, February = 2011,
= <https://www.rfc-editor.org/info/rfc6115>. =
= =
[RFC6275] = Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. = Arkko, "Mobility
= Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI = 10.17487/RFC6275, July
= 2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, = <https://www.rfc-editor.org/info/rfc6275>.
=
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, = "Locator/ID
Separation Protocol (LISP) = Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January = 2013,
= <https://www.rfc-editor.org/info/rfc6834>. =
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and = D. Lewis,
"Locator/ID Separation Protocol = Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI = 10.17487/RFC6836,
January 2013, = <https://www.rfc-editor.org/info/rfc6836>. =
[RFC7052] Schudel, G., Jain, A., and V. Moreno, = "Locator/ID
Separation Protocol (LISP) MIB", RFC = 7052,
DOI 10.17487/RFC7052, October = 2013,
= <https://www.rfc-editor.org/info/rfc7052>. =
[RFC7214] Andersson, L. and C. Pignataro, "Moving = Generic Associated
Channel (G-ACh) IANA Registries to a New = Registry",
RFC 7214, DOI 10.17487/RFC7214, May = 2014,
= <https://www.rfc-editor.org/info/rfc7214>. =
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, = F., Domingo-
Pascual, J., and D. Lewis, = "Locator/Identifier Separation
Protocol (LISP) Network Element = Deployment
Considerations", RFC 7215, DOI = 10.17487/RFC7215, April
2014, = <https://www.rfc-editor.org/info/rfc7215>. =
= =
[RFC7833] = Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A [RFC7833] Howlett, J., Hartman, S., and A. = Perez-Mendez, Ed., "A
= RADIUS Attribute, Binding, Profiles, Name Identifier RADIUS Attribute, Binding, Profiles, Name = Identifier
= Format, and Confirmation Methods for the Security Format, and Confirmation Methods for the = Security
= Assertion Markup Language (SAML)", RFC 7833, Assertion Markup Language (SAML)", RFC = 7833,
DOI = 10.17487/RFC7833, May 2016, = DOI 10.17487/RFC7833, May 2016,
= <https://www.rfc-editor.org/info/rfc7833>. = <https://www.rfc-editor.org/info/rfc7833>.
=
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC8126] Cotton, M., Leiba, = B., and T. Narten, "Guidelines = for
Separation Protocol (LISP) Threat = Analysis", RFC 7835, = Writing = an IANA Considerations Section in RFCs", BCP 26,
= DOI 10.17487/RFC7835, April 2016, = RFC 8126, DOI 10.17487/RFC8126,= June 2017,
= <https://www.rfc-editor.org/info/rfc7835>. = <https://www.rfc-editor.org/info/rfc8126>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID = Separation Protocol
(LISP) Data-Plane Confidentiality", RFC = 8061,
DOI 10.17487/RFC8061, February = 2017,
= <https://www.rfc-editor.org/info/rfc8061>.
=
[RFC8200] = Deering, S. and R. Hinden, "Internet Protocol, Version 6 = [RFC8200] Deering, S. and R. Hinden, = "Internet Protocol, Version 6
= (IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC = 8200,
DOI = 10.17487/RFC8200, July 2017, = DOI 10.17487/RFC8200, July 2017,
= <https://www.rfc-editor.org/info/rfc8200>. = <https://www.rfc-editor.org/info/rfc8200>.
=
22.2. = Informative References 22.2. = Informative References
=
[AFN] = IANA, "Address Family Numbers", August 2016, [AFN] IANA, "Address Family Numbers", August = 2016,
= <http://www.iana.org/assignments/address-family-numbers>. = = <http://www.iana.org/assignments/address-family-numbers>.
=
[CHIAPPA] = Chiappa, J., "Endpoints and Endpoint names: A Proposed", = [CHIAPPA] Chiappa, J., "Endpoints and = Endpoint names: A Proposed",
= 1999, 1999,
= <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. = = <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
=
= [I-D.ietf-lisp-eid-mobility] = [I-D.ietf-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-ietf-lisp-eid-mobility-00 = Unified Control Plane", draft-ietf-lisp-eid-mobility-01
= (work in progress), May 2017. = (work in progress), November 2017.
= =
= [I-D.ietf-lisp-introduction]
= = Cabellos-Aparicio, A. and D. Saucez, "An Architectural
= = Introduction to the Locator/ID Separation Protocol
= (LISP)", = draft-ietf-lisp-introduction-13 (work in
= = progress), April 2015.
=
= [I-D.ietf-lisp-mn] = [I-D.ietf-lisp-mn]
= Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP = Farinacci, D., Lewis, D., Meyer, = D., and C. White, "LISP
= Mobile Node", draft-ietf-lisp-mn-01 (work in progress), = Mobile Node", = draft-ietf-lisp-mn-01 (work in progress),
= October 2017. October = 2017.
=
= [I-D.ietf-lisp-predictive-rlocs] = [I-D.ietf-lisp-predictive-rlocs]
= Farinacci, D. and P. Pillay-Esnault, "LISP Predictive Farinacci, D. and P. Pillay-Esnault, "LISP = Predictive
= RLOCs", draft-ietf-lisp-predictive-rlocs-00 = (work in RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work = in
= progress), June 2017. progress), November = 2017.
=
= = [I-D.ietf-lisp-sec]
= Maino, = F., Ermagan, V., Cabellos-Aparicio, A., and D.
= Saucez, = "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
= (work in = progress), October 2017.
=
= [I-D.ietf-lisp-signal-free-multicast] = [I-D.ietf-lisp-signal-free-multicast]
= Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", = Moreno, V. and D. Farinacci, = "Signal-Free LISP Multicast",
= draft-ietf-lisp-signal-free-multicast-06 = (work in draft-ietf-lisp-signal-free-multicast-07 (work = in
= progress), August 2017. progress), November 2017.
=
= [I-D.ietf-lisp-vpn] = [I-D.ietf-lisp-vpn]
= Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual = Private
= Networks (VPNs)", draft-ietf-lisp-vpn-00 = (work in Networks = (VPNs)", draft-ietf-lisp-vpn-01 (work = in
= progress), May 2017. progress), November 2017.
=
= [I-D.meyer-loc-id-implications] = [I-D.meyer-loc-id-implications]
= Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural = Implications of
= Locator/ID Separation", draft-meyer-loc-id-implications-01 = Locator/ID Separation", = draft-meyer-loc-id-implications-01
= (work in progress), January 2009. = (work in progress), January 2009.
=
[LISA96] = Lear, E., Tharp, D., Katinsky, J., and J. Coffin, [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. = Coffin,
= "Renumbering: Threat or Menace?", Usenix Tenth System "Renumbering: Threat or Menace?", Usenix = Tenth System
= Administration Conference (LISA 96), October 1996. Administration Conference (LISA 96), = October 1996.
=
=
skipping = to change at page 49, line = 9 =C2=B6 = skipping to change at page 47, line = 22 =C2=B6
=
[RFC2784] = Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, = D., and P.
= Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, = Traina, "Generic Routing = Encapsulation (GRE)", RFC 2784,
DOI = 10.17487/RFC2784, March 2000, = DOI 10.17487/RFC2784, March 2000,
= <https://www.rfc-editor.org/info/rfc2784>. = <https://www.rfc-editor.org/info/rfc2784>.
=
[RFC3056] = Carpenter, B. and K. Moore, "Connection of IPv6 Domains = [RFC3056] Carpenter, B. and K. Moore, = "Connection of IPv6 Domains
via = IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February via IPv4 Clouds", RFC 3056, DOI = 10.17487/RFC3056, February
= 2001, <https://www.rfc-editor.org/info/rfc3056>. 2001, = <https://www.rfc-editor.org/info/rfc3056>.
=
= [RFC3232] Reynolds, = J., Ed., "Assigned Numbers: RFC 1700 is Replaced
= by an = On-line Database", RFC 3232, DOI 10.17487/RFC3232,
= January = 2002, <https://www.rfc-editor.org/info/rfc3232>.
= =
[RFC3261] = Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, = [RFC3261] Rosenberg, J., Schulzrinne, H., = Camarillo, G., Johnston,
A., = Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., = and E.
= Schooler, "SIP: Session Initiation Protocol", RFC 3261, = Schooler, "SIP: Session = Initiation Protocol", RFC 3261,
DOI = 10.17487/RFC3261, June 2002, = DOI 10.17487/RFC3261, June 2002,
= <https://www.rfc-editor.org/info/rfc3261>. = <https://www.rfc-editor.org/info/rfc3261>.
=
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for = Cryptographic
Key Management", BCP 107, RFC 4107, DOI = 10.17487/RFC4107,
June 2005, = <https://www.rfc-editor.org/info/rfc4107>. =
= =
[RFC4192] = Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, = "Procedures for
= Renumbering an IPv6 Network without a Flag Day", RFC 4192, = Renumbering an IPv6 Network = without a Flag Day", RFC 4192,
DOI = 10.17487/RFC4192, September 2005, = DOI 10.17487/RFC4192, September 2005,
= <https://www.rfc-editor.org/info/rfc4192>. = <https://www.rfc-editor.org/info/rfc4192>.
=
[RFC4866] = Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, = "Enhanced Route
= Optimization for Mobile IPv6", RFC 4866, Optimization for Mobile IPv6", RFC = 4866,
DOI = 10.17487/RFC4866, May 2007, = DOI 10.17487/RFC4866, May 2007,
= <https://www.rfc-editor.org/info/rfc4866>. = <https://www.rfc-editor.org/info/rfc4866>.
=
[RFC4984] = Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report = [RFC4984] Meyer, D., Ed., Zhang, L., Ed., = and K. Fall, Ed., "Report
= from the IAB Workshop on Routing and Addressing", from the IAB Workshop on Routing and = Addressing",
RFC = 4984, DOI 10.17487/RFC4984, September 2007, RFC 4984, DOI 10.17487/RFC4984, September = 2007,
= <https://www.rfc-editor.org/info/rfc4984>. = <https://www.rfc-editor.org/info/rfc4984>.
=
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure = to Support
Secure Internet Routing", RFC 6480, DOI = 10.17487/RFC6480,
February 2012, = <https://www.rfc-editor.org/info/rfc6480>. =
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and = Authentication for
Routing Protocols (KARP) Design = Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February = 2012,
= <https://www.rfc-editor.org/info/rfc6518>. =
= =
[RFC6831] = Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The = [RFC6831] Farinacci, D., Meyer, D., = Zwiebel, J., and S. Venaas, "The
= Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for = Multicast
= Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI = 10.17487/RFC6831, January
= 2013, <https://www.rfc-editor.org/info/rfc6831>. 2013, = <https://www.rfc-editor.org/info/rfc6831>.
=
[RFC6832] = Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and = V. Fuller,
= "Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID = Separation Protocol
= (LISP) and Non-LISP Sites", RFC 6832, = (LISP) and Non-LISP Sites", RFC 6832,
DOI = 10.17487/RFC6832, January 2013, = DOI 10.17487/RFC6832, January 2013,
= <https://www.rfc-editor.org/info/rfc6832>. = <https://www.rfc-editor.org/info/rfc6832>.
=
= [RFC6834] Iannone, = L., Saucez, D., and O. Bonaventure, "Locator/ID
= = Separation Protocol (LISP) Map-Versioning", RFC 6834,
= DOI = 10.17487/RFC6834, January 2013,
= = <https://www.rfc-editor.org/info/rfc6834>.
= =
[RFC6835] = Farinacci, D. and D. Meyer, "The Locator/ID Separation [RFC6835] Farinacci, D. and D. Meyer, "The = Locator/ID Separation
= Protocol Internet Groper (LIG)", RFC 6835, Protocol Internet Groper (LIG)", RFC = 6835,
DOI = 10.17487/RFC6835, January 2013, = DOI 10.17487/RFC6835, January 2013,
= <https://www.rfc-editor.org/info/rfc6835>. = <https://www.rfc-editor.org/info/rfc6835>.
=
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID = (EID) to
Routing Locator (RLOC) Database", RFC = 6837,
DOI 10.17487/RFC6837, January = 2013,
= <https://www.rfc-editor.org/info/rfc6837>. =
= =
[RFC6935] = Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and = [RFC6935] Eubanks, M., Chimento, P., and M. = Westerlund, "IPv6 and
UDP = Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC = 6935,
DOI = 10.17487/RFC6935, April 2013, = DOI 10.17487/RFC6935, April 2013,
= <https://www.rfc-editor.org/info/rfc6935>. = <https://www.rfc-editor.org/info/rfc6935>.
=
[RFC6936] = Fairhurst, G. and M. Westerlund, "Applicability Statement = [RFC6936] Fairhurst, G. and M. Westerlund, = "Applicability Statement
for = the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with = Zero Checksums",
RFC = 6936, DOI 10.17487/RFC6936, April 2013, = RFC 6936, DOI 10.17487/RFC6936, April 2013,
= <https://www.rfc-editor.org/info/rfc6936>. = <https://www.rfc-editor.org/info/rfc6936>.
=
= [RFC7052] Schudel, = G., Jain, A., and V. Moreno, "Locator/ID
= = Separation Protocol (LISP) MIB", RFC 7052,
= DOI = 10.17487/RFC7052, October 2013,
= = <https://www.rfc-editor.org/info/rfc7052>.
=
= [RFC7215] Jakab, = L., Cabellos-Aparicio, A., Coras, F., Domingo-
= Pascual, = J., and D. Lewis, "Locator/Identifier Separation
= Protocol = (LISP) Network Element Deployment
= = Considerations", RFC 7215, DOI 10.17487/RFC7215, April
= 2014, = <https://www.rfc-editor.org/info/rfc7215>.
=
= [RFC7835] Saucez, = D., Iannone, L., and O. Bonaventure, "Locator/ID
= = Separation Protocol (LISP) Threat Analysis", RFC 7835,
= DOI = 10.17487/RFC7835, April 2016,
= = <https://www.rfc-editor.org/info/rfc7835>.
= =
[RFC8060] = Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical = [RFC8060] Farinacci, D., Meyer, D., and J. = Snijders, "LISP Canonical
= Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, = Address Format (LCAF)", RFC 8060, = DOI 10.17487/RFC8060,
= February 2017, <https://www.rfc-editor.org/info/rfc8060>. = February 2017, = <https://www.rfc-editor.org/info/rfc8060>.
=
= [RFC8061] = Farinacci, D. and B. Weis, "Locator/ID Separation = Protocol
= (LISP) = Data-Plane Confidentiality", RFC 8061,
= DOI = 10.17487/RFC8061, February 2017,
= = <https://www.rfc-editor.org/info/rfc8061>.
=
= [RFC8111] Fuller, = V., Lewis, D., Ermagan, V., Jain, A., and A.
= Smirnov, = "Locator/ID Separation Protocol Delegated
= Database = Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
= May 2017, = <https://www.rfc-editor.org/info/rfc8111>.
= =
Appendix A. = Acknowledgments Appendix A. = Acknowledgments
=
An initial = thank you goes to Dave Oran for planting the seeds for the = An initial thank you goes to Dave Oran for = planting the seeds for the
initial ideas = for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues = to provide value
to the LISP = authors. to the LISP = authors.
=
A special and = appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel = Chiappa for
providing = architectural impetus over the past decades on separation = providing architectural impetus over the = past decades on separation
of location = and identity, as well as detailed reviews of the LISP of location and identity, as well as detailed reviews = of the LISP
architecture = and documents, coupled with enthusiasm for making LISP a = architecture and documents, coupled with = enthusiasm for making LISP a
=
skipping = to change at page 52, line = 5 =C2=B6 = skipping to change at page 51, line = 5 =C2=B6
The LISP = working group would like to give a special thanks to Jari = The LISP working group would like to give a = special thanks to Jari
Arkko, the = Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set = of LISP
documents were = being prepared for IESG last call, and for his documents were being prepared for IESG last call, and = for his
meticulous = reviews and detailed commentaries on the 7 working group = meticulous reviews and detailed commentaries = on the 7 working group
last call = documents progressing toward standards-track RFCs. last call documents progressing toward = standards-track RFCs.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-06 = B.1. Changes to draft-ietf-lisp-rfc6830bis-08
=
= o Posted December = 2017.
=
= o Remove references = to research work for any protocol mechanisms.
=
= o Document scanned = to make sure it is RFC 2119 compliant.
=
= o Made changes to = reflect comments from document WG shepherd Luigi
= = Iannone.
=
= o Ran IDNITs on the = document.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-06 B.3. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping = to change at page 52, line = 35 =C2=B6 = skipping to change at page 51, line = 48 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addreses can be used. = o Clarify when private addreses can be used.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-05 B.4. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Reencapsulating Tunnel Router is an RTR. o Make it clear that a Reencapsulating Tunnel Router = is an RTR.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-04 B.5. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-03 B.6. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-02 B.7. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-01 B.8. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-00 B.9. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = farinacci@gmail.com EMail: = farinacci@gmail.com
= =
Vince = Fuller Vince Fuller
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = vince.fuller@gmail.com EMail: = vince.fuller@gmail.com
=
Dave = Meyer Dave Meyer
Cisco = Systems Cisco Systems
 End of changes. 98 change blocks. 
265 lines changed or = deleted 215 lines changed or = added

This = html diff was produced by rfcdiff 1.46. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_EBF70E63-3D33-4166-9407-E9E9514946DC Content-Disposition: attachment; filename=draft-ietf-lisp-rfc6830bis-08.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-rfc6830bis-08.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer Expires: June 21, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech December 18, 2017 The Locator/ID Separation Protocol (LISP) draft-ietf-lisp-rfc6830bis-08 Abstract This document describes the data-plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 21, 2018. Farinacci, et al. Expires June 21, 2018 [Page 1] =0C Internet-Draft LISP December 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 11 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 13 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 15. Router Performance Considerations . . . . . . . . . . . . . . 35 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 35 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 Farinacci, et al. Expires June 21, 2018 [Page 2] =0C Internet-Draft LISP December 2017 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39 17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 40 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 43 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 50 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 50 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 51 B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 51 B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 51 B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 51 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 B.6. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 B.7. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52 B.8. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52 B.9. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction This document describes the Locator/Identifier Separation Protocol (LISP). LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [CHIAPPA]. As a result LISP creates two namespaces: Endpoint Identifiers (EIDs), that are used to identify end-hosts (e.g., nodes or Virtual Machines) and routable Routing Locators (RLOCs), used to identify network attachment points. LISP then defines functions for mapping between the two namespaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. LISP is an overlay protocol that separates control from data-plane, this document specifies the data-plane, how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the appropriate location. Tunnel routers are equipped with a cache, called map-cache, that contains EID-to-RLOC mappings. The map-cache Farinacci, et al. Expires June 21, 2018 [Page 3] =0C Internet-Draft LISP December 2017 is populated using the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. LISP does not require changes to either host protocol stack or to underlay routers. By separating the EID from the RLOC space, LISP offers native Traffic Engineering, multihoming and mobility, among other features. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]) This document specifies the LISP data-plane encapsulation and other LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] specifies the LISP control plane. LISP deployment guidelines can be found in [RFC7215] and [RFC6835] describes considerations for network operational management. Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms Tunneling: Tunneling is a technique where another IP header is prepended to an existing IP packet so a level of indirection in the data-plane can be accomplished. Any references to tunnels in this specification refer to dynamic encapsulating tunnels, meaning they are never statically configured. Provider-Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g., from a particular service provider) and are therefore not topologically aggregatable in the routing system. Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider to which a site connects. Typically, each block is a sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. Farinacci, et al. Expires June 21, 2018 [Page 4] =0C Internet-Draft LISP December 2017 Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example, through a Domain Name System (DNS) [RFC1034] lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. An EID is allocated to a host from an EID-Prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site MAY have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called an "LEID". Throughout this document, any references to "EID" refer to an LEID. EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID- Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. End-system: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e., outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Farinacci, et al. Expires June 21, 2018 [Page 5] =0C Internet-Draft LISP December 2017 Ingress Tunnel Router (ITR): An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its routable RLOCs (in the RLOC space) in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC MAY be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating host's supplied EID). TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router. Re-encapsulating Tunneling Router (RTR): An RTR acts like an ETR to remove a LISP header, then acts as an ITR to prepend a new LISP Farinacci, et al. Expires June 21, 2018 [Page 6] =0C Internet-Draft LISP December 2017 header. This is known as Re-encapsulating Tunneling. Doing this allows a packet to be re-routed by the RTR without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured. When using multiple mapping database systems, care must be taken to not create re- encapsulation loops through misconfiguration. LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), or Proxy-ETR (PETR). EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID- to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope. EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own globally visible IP addresses. Note that there MAY be transient conditions when the EID-Prefix for the site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used. Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header. LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP- specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips. Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet. An address family that pertains to the data-plane. See [AFN] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified Farinacci, et al. Expires June 21, 2018 [Page 7] =0C Internet-Draft LISP December 2017 encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well-defined actions that are encoded in a Negative Map-Reply. Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host if the destination EID is in the EID-Prefix range configured on the ETR. Otherwise, the packet is discarded. A Data-Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. When using Data-Probes, by sending Map-Requests on the underlying routing system, EID-Prefixes must be advertised. Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites. Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites. Route-returnability: Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message. LISP site: LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network. Client-side: Client-side is a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP Farinacci, et al. Expires June 21, 2018 [Page 8] =0C Internet-Draft LISP December 2017 site are the first to get involved in forwarding a packet from the source EID. Server-side: Server-side is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID. Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 10. Anycast Address: Anycast Address is a term used in this document to refer to the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in each of their own address spaces. 4. Basic Overview One key concept of LISP is that end-systems operate the same way they do today. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. Another key LISP concept is the "Tunnel Router". A Tunnel Router prepends LISP headers on host-originated packets and strips them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips the new header. The ITR performs EID-to- RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: Farinacci, et al. Expires June 21, 2018 [Page 9] =0C Internet-Draft LISP December 2017 o End-systems only send to addresses that are EIDs. They don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change. o EIDs are typically IP addresses assigned to hosts. o Other types of EID are supported by LISP, see [RFC8060] for further information. o LISP routers mostly deal with Routing Locator addresses. See details in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks. o When a router originates packets, it MAY use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure SHell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it MAY use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o Packets with EIDs in them are not expected to be delivered end-to- end in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication or to be encapsulated for inter-site communication. o EID-Prefixes are likely to be hierarchically assigned in a manner that is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on an address allocation hierarchy that is independent of the network topology. o EIDs MAY also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS). An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential Farinacci, et al. Expires June 21, 2018 [Page 10] =0C Internet-Draft LISP December 2017 use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document recommends that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and the second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. Another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility. 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow, including also control-plane information as specified in [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following conditions: o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site. o A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. Map-Requests are sent to the mapping database Farinacci, et al. Expires June 21, 2018 [Page 11] =0C Internet-Draft LISP December 2017 system by using the LISP control-plane protocol documented in [I-D.ietf-lisp-rfc6833bis]. o Map-Replies are sent on the underlying routing system topology using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol. Client host1.abc.example.com wants to communicate with server host2.xyz.example.com: 1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [I-D.ietf-lisp-rfc6833bis] for further information. 3. The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. 4. The mapping system helps forwarding the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. 6. The ITR receives the Map-Reply message, parses the message (to check for format validity), and stores the mapping information from the packet. This information is stored in the ITR's EID-to- RLOC map-cache. Note that the map-cache is an on-demand cache. An ITR will manage its map-cache in such a way that optimizes for its resource constraints. 7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent Farinacci, et al. Expires June 21, 2018 [Page 12] =0C Internet-Draft LISP December 2017 to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host. 9. In order to defer the need for a mapping lookup in the reverse direction, an ETR can OPTIONALLY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC. 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Unreachable/Fragmentation-Needed message is returned to the source. In the case when fragmentation is needed, this specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 7. Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported. Additional types of EIDs are defined in [RFC8060]. 5.1. LISP IPv4-in-IPv4 Header Format Farinacci, et al. Expires June 21, 2018 [Page 13] =0C Internet-Draft LISP December 2017 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL | DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL | DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IHL =3D IP-Header-Length 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | Farinacci, et al. Expires June 21, 2018 [Page 14] =0C Internet-Draft LISP December 2017 r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header (IH): The inner header is the header on the datagram received from the originating host [RFC0791] [RFC8200] [RFC2474]. The source and destination IP addresses are EIDs. Outer Header: (OH) The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress Farinacci, et al. Expires June 21, 2018 [Page 15] =0C Internet-Draft LISP December 2017 router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 7.1 and 7.2. UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 12 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341. UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP zero checksums over IPv6 for all tunneling protocols, including LISP, is subject to the applicability statement in [RFC6936]. UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers. N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a Nonce. See Section 10.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a Nonce value present. L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use. Farinacci, et al. Expires June 21, 2018 [Page 16] =0C Internet-Draft LISP December 2017 x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP- encapsulated packets when the ITR is also an ETR. See Section 10.1 for details. V: The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to Section 13.3 for more details. This bit indicates that the LISP header is encoded in this case as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: The I-bit is the Instance ID bit. See Section 8 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this: x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R: The R-bit is a Reserved bit for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt. KK: The KK-bits are a 2-bit field used when encapsualted packets are encrypted. The field is set to 00 when the packet is not encrypted. See [RFC8061] for further information. Farinacci, et al. Expires June 21, 2018 [Page 17] =0C Internet-Draft LISP December 2017 LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different destinations. However, the same nonce can be used for a period of time to the same destination. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 10.1 for more details. LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 10 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'. When doing ITR/PITR encapsulation: o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field. o The outer-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header 'Type of Service' field (with one exception; see below). When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header Farinacci, et al. Expires June 21, 2018 [Page 18] =0C Internet-Draft LISP December 2017 to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. o The inner-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header 'Type of Service' field (with one exception; see below). Note that if an ETR/PETR is also an ITR/PITR and chooses to re- encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 18.3 for TTL exception handling for traceroute packets. The Explicit Congestion Notification ('ECN') field occupies bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC3168]. The 'ECN' field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. 6. LISP EID-to-RLOC Map-Cache ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- RLOC Map-Cache, that contains mappings from EID-prefixes to locator sets. The cache is used to encapsulate packets from the EID space to the corresponding RLOC network attachment point. When an ITR/PITR receives a packet from inside of the LISP site to destinations outside of the site a longest-prefix match lookup of the EID is done to the map-cache. Farinacci, et al. Expires June 21, 2018 [Page 19] =0C Internet-Draft LISP December 2017 When the lookup succeeds, the locator-set retrieved from the map- cache is used to send the packet to the EID's topological location. If the lookup fails, the ITR/PITR needs to retrieve the mapping using the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The mapping is then stored in the local map-cache to forward subsequent packets addressed to the same EID-prefix. The map-cache is a local cache of mappings, entries are expired based on the associated Time to live. In addition, entries can be updated with more current information, see Section 13 for further information on this. Finally, the map-cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. 7. Dealing with Large Encapsulated Packets This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism SHOULD be implemented. Both or neither can be used, since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Both stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below referring to an ITR also apply to a TE-ITR. 7.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: 1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths. 2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet. 3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR MUST receive from the source so the effective MTU can be met. That is, L =3D S + H. Farinacci, et al. Expires June 21, 2018 [Page 20] =0C Internet-Draft LISP December 2017 When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets (meaning the received packet size was greater than S octets from the source), it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMP Unreachable/ Fragmentation-Needed message to the source with a value of S, where S is (L - H). When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification RECOMMENDS that L be defined as 1500. 7.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR. 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Unreachable/Fragmentation-Needed message to the ITR. The ITR will parse the ICMP message to determine which Locator is Farinacci, et al. Expires June 21, 2018 [Page 21] =0C Internet-Draft LISP December 2017 affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Unreachable/ Fragmentation-Needed message back to the source. The packet size advertised by the ITR in the ICMP Unreachable/Fragmentation- Needed message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 8. Using Virtualization and Segmentation with LISP There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies or multi-tenant virtualization. For these and other scenarios where segregation is needed, Instance IDs are used. An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case details. The Instance ID that is stored in the mapping database when LISP-DDT [RFC8111] is used is 32 bits in length. That means the control-plane can store more instances than a given data-plane can use. Multiple data-planes can use the same 32-bit space as long as the low-order 24 bits don't overlap among xTRs. Farinacci, et al. Expires June 21, 2018 [Page 22] =0C Internet-Draft LISP December 2017 9. Routing Locator Selection Both the client-side and server-side MAY need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the 'Priority' and 'Weight' fields in EID- to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following are different scenarios for choosing RLOCs and the controls that are available: o The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection. o The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o The server-side sets a Weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server- side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable. o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer- header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding Farinacci, et al. Expires June 21, 2018 [Page 23] =0C Internet-Draft LISP December 2017 cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large. o A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map- Cache entry for the "gleaned" EID and is stored and used for the time indicated from the 'TTL' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry. This "gleaning" mechanism is OPTIONAL. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the Locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section. 10. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR MAY receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions. 3. An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address. Farinacci, et al. Expires June 21, 2018 [Page 24] =0C Internet-Draft LISP December 2017 4. An ITR MAY receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR MAY receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator reachability algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Farinacci, et al. Expires June 21, 2018 [Page 25] =0C Internet-Draft LISP December 2017 Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix. Refer to Section 19 for security related issues regarding Locator-Status-Bits. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map- Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages. If an ITR does receive an ICMP Network Unreachable or Host Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a Locator-Set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default- Free Zone (DFZ), it can decide to not use the Locator even though the Locator-Status-Bits indicate that the Locator is up. In this case, the path from the ITR to the ETR that is assigned the Locator is not available. More details are in [I-D.meyer-loc-id-implications]. Optionally, an ITR can send a Map-Request to a Locator, and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with Priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets, since that increases the risk of packet loss for end-to-end sessions. Farinacci, et al. Expires June 21, 2018 [Page 26] =0C Internet-Draft LISP December 2017 When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true, due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability. 10.1. Echo Nonce Algorithm When data flows bidirectionally between Locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the echo-nonce-request state, then the path to the ETR is unreachable. This decision MAY be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR MAY both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation-specific setting. However, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and subsequently continue sending echo-nonce-request packets. Farinacci, et al. Expires June 21, 2018 [Page 27] =0C Internet-Draft LISP December 2017 This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site MAY not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- probe Map-Reply message. Note other Locator Reachability mechanisms can be used to compliment or even override the echo nonce algorithm. See the next section for an example of control-plane probing. 10.2. RLOC-Probing Algorithm RLOC-Probing is a method that an ITR or PITR can use to determine the reachability status of one or more Locators that it has cached in a Map-Cache entry. The probe-bit of the Map-Request and Map-Reply messages is used for RLOC-Probing. RLOC-Probing is done in the control plane on a timer basis, where an ITR or PITR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-probes are sent periodically using a jittered timer interval. When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping data for the EID-Prefix contained in the Map-Request. This provides the opportunity for the ITR or PITR that sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC-Probing. The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is Farinacci, et al. Expires June 21, 2018 [Page 28] =0C Internet-Draft LISP December 2017 reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) estimates between a pair of Locators, which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC-Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times is very small. 11. EID Reachability within a LISP Site A site MAY be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID- Prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header. It is recognized that there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-Prefix range is partitioned and which Locators can reach any sub- ranges of the EID-Prefixes. Note that this is not a new problem introduced by the LISP architecture. The problem exists today when a multihomed site uses BGP to advertise its reachability upstream. 12. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache of a requesting ITR, the Locator-Set for the EID-Prefix MAY contain different Priority and Weight values for each locator address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators. The following hash algorithm MAY be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and Farinacci, et al. Expires June 21, 2018 [Page 29] =0C Internet-Draft LISP December 2017 destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping. 3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers that are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets that are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. 13. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, it is desirable to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When adding a new Locator record in lexicographic order to the end of a Locator-Set, it is easy to update mappings. We assume that new mappings will maintain the same Locator ordering as the old mapping but will just have new Locators appended to the end of the list. So, some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses Farinacci, et al. Expires June 21, 2018 [Page 30] =0C Internet-Draft LISP December 2017 that are lexicographically greater than the locator addresses in the existing Locator-Set. When a Locator record is inserted in the middle of a Locator-Set, to maintain lexicographic order, the SMR procedure in Section 13.2 is used to inform ITRs and PITRs of the new Locator-Status-Bit mappings. When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed. We propose here three approaches for Locator-Set compaction: one operational mechanism and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. 13.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, there is a 24-hour window to time out old mappings. The following clock sweep procedure is used: 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1-hour window, the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. Farinacci, et al. Expires June 21, 2018 [Page 31] =0C Internet-Draft LISP December 2017 4. At the end of the 1-hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So, any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a TTL equal to the TTL in the Map-Reply. 13.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data. This can only occur when both ITR and ETR functionality reside in the same router. An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches. 2. A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected, and the EID-Prefix used is the one copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request. 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map-Versioning as described in Section 13.3 is used, an SMR Farinacci, et al. Expires June 21, 2018 [Page 32] =0C Internet-Draft LISP December 2017 sender can detect if an ITR is using the most up-to-date database mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- limited. This is important to avoid Map-Reply implosion. 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map- Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it may not send an SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all Locators in the Locator-Set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case they will send Map-Requests to obtain a Map-Cache entry. 13.3. Database Map-Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 13.2 occurs. Farinacci, et al. Expires June 21, 2018 [Page 33] =0C Internet-Draft LISP December 2017 An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version Number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects that the Source Map- Version Number is greater than the last Map-Version Number sent in a Map-Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-Prefix, so values that are greater are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map- Version Number. See [RFC6834] for a more detailed analysis and description of Database Map-Versioning. 14. Multicast Considerations A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determine where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, can use the same group address as the destination Routing Locator, use a multicast or unicast Routing Locator obtained from a Mapping System lookup, or use other means to determine the group address mapping. With respect to the source Routing Locator address, the ITR prepends its own IP address as the source address of the outer IP header. Just like it would if the destination EID was a unicast address. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable. Farinacci, et al. Expires June 21, 2018 [Page 34] =0C Internet-Draft LISP December 2017 There are two approaches for LISP-Multicast, one that uses native multicast routing in the underlay with no support from the Mapping System and the other that uses only unicast routing in the underlay with support from the Mapping System. See [RFC6831] and [I-D.ietf-lisp-signal-free-multicast], respectively, for details. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832]. 15. Router Performance Considerations LISP is designed to be very "hardware-based forwarding friendly". A few implementation techniques can be used to incrementally implement LISP: o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control-plane processing SHOULD be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data- plane. o On an ITR, prepending a new IP header consists of adding more octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. For performance issues related to map-cache management, see Section 19. 16. Mobility Considerations There are several kinds of mobility, of which only some might be of concern to LISP. Essentially, they are as follows. Farinacci, et al. Expires June 21, 2018 [Page 35] =0C Internet-Draft LISP December 2017 16.1. Slow Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-to-RLOC mappings for sites are expected to be handled by configuration, outside of LISP. An individual endpoint wishes to move but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs [RFC4984]. 16.2. Fast Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP-layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and primarily where interactions with LISP need to be explored, such as the mechanisms in [I-D.ietf-lisp-eid-mobility] when the EID moves but the RLOC is in the network infrastructure. In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-to-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have an internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything that decreases the number of new EID- to-RLOC mappings needed when a node moves, or maintains the validity of an EID-to-RLOC mapping for a longer time, is useful. In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same, and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. Farinacci, et al. Expires June 21, 2018 [Page 36] =0C Internet-Draft LISP December 2017 If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. See [I-D.ietf-lisp-predictive-rlocs] for more recent mechanisms which can provide near-zero packet loss during handoffs. 16.3. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Refer to [I-D.ietf-lisp-mn] for more details for when the EID and RLOC are co-located in the roaming node. 17. LISP xTR Placement and Encapsulation Methods This section will explore how and where ITRs and ETRs can be placed in the network and will discuss the pros and cons of each scenario. For a more detailed networkd design deployment recommendation, refer to [RFC7215]. There are two basic deployment tradeoffs to consider: centralized versus distributed caches; and flat, Recursive, or Re-encapsulating Tunneling. When deciding on centralized versus distributed caching, the following issues SHOULD be considered: o Are the xTRs spread out so that the caches are spread across all the memories of each router? A centralized cache is when an ITR keeps a cache for all the EIDs it is encapsulating to. The packet takes a direct path to the destination Locator. A distributed cache is when an ITR needs help from other Re-Encapsulating Tunnel Routers (RTRs) because it does not store all the cache entries for the EIDs it is encapsulating to. So, the packet takes a path through RTRs that have a different set of cache entries. o Should management "touch points" be minimized by only choosing a few xTRs, just enough for redundancy? Farinacci, et al. Expires June 21, 2018 [Page 37] =0C Internet-Draft LISP December 2017 o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, using more ETRs does require more management, since EID-Prefix-to- RLOC mappings need to be explicitly configured. When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the following issues SHOULD be considered: o Flat tunneling implements a single encapsulation path between the source site and destination site. This generally offers better paths between sources and destinations with a single encapsulation path. o Recursive Tunneling is when encapsulated traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control, since the site is prepending a new encapsulation header. In the case of TE-based tunneling, the site MAY have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive Tunneling generally will result in suboptimal paths but with the benefit of steering traffic to parts of the network that have more resources available. o The technique of Re-Encapsulation ensures that packets only require one encapsulation header. So, if a packet needs to be re- routed, it is first decapsulated by the RTR and then Re- Encapsulated with a new encapsulation header using a new RLOC. The next sub-sections will examine where xTRs and RTRs can reside in the network. 17.1. First-Hop/Last-Hop xTRs By locating xTRs close to hosts, the EID-Prefix set is at the granularity of an IP subnet. So, at the expense of more EID-Prefix- to-RLOC sets for the site, the caches in each xTR can remain relatively small. But caches always depend on the number of non- aggregated EID destination flows active through these xTRs. With more xTRs doing encapsulation, the increase in control traffic grows as well: since the EID granularity is greater, more Map- Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios than their core router counterparts. Memory is typically less expensive in these devices, and fewer routes Farinacci, et al. Expires June 21, 2018 [Page 38] =0C Internet-Draft LISP December 2017 are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing states. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices. 17.2. Border/Edge xTRs Using Customer Edge (CE) routers for xTR placement allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE-based xTRs for that site. This offers the opposite benefit of the first-hop/last-hop xTR scenario: the number of mapping entries and network management touch points is reduced, allowing better scaling. One disadvantage is that fewer network resources are used to reach host endpoints, thereby centralizing the point-of-failure domain and creating network choke points at the CE xTR. Note that more than one CE xTR at a site can be configured with the same IP address. In this case, an RLOC is an anycast address. This allows resilience between the CE xTRs. That is, if a CE xTR fails, traffic is automatically routed to the other xTRs using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast Locators is the limited advertisement scope of /32 (or /128 for IPv6) routes. 17.3. ISP Provider Edge (PE) xTRs The use of ISP PE routers as xTRs is not the typical deployment scenario envisioned in this specification. This section attempts to capture some of the reasoning behind this preference for implementing LISP on CE routers. The use of ISP PE routers for xTR placement gives an ISP, rather than a site, control over the location of the ETRs. That is, the ISP can decide whether the xTRs are in the destination site (in either CE xTRs or last-hop xTRs within a site) or at other PE edges. The advantage of this case is that two encapsulation headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for a new encapsuluation path to the destination end site. Farinacci, et al. Expires June 21, 2018 [Page 39] =0C Internet-Draft LISP December 2017 An obvious disadvantage is that the end site has no control over where its packets flow or over the RLOCs used. Other disadvantages include difficulty in synchronizing path liveness updates between CE and PE routers. As mentioned in earlier sections, a combination of these scenarios is possible at the expense of extra packet header overhead; if both site and provider want control, then Recursive or Re-Encapsulating Tunnels are used. 17.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control message MUST be a routable address and therefore [RFC1918] addresses SHOULD only be presence when running in a local environment. When a LISP xTR is configured with private RLOC addresses and resides behind a NAT device and desires to communicate on the Internet, the private addresses MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed when LISP VPNs are not in use. Both NAT translation and LISP encapsulation functions could be co- located in the same device. 17.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache MAY not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. 18. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from the ITR to the ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Farinacci, et al. Expires June 21, 2018 [Page 40] =0C Internet-Draft LISP December 2017 Segment 1 (in source LISP site based on EIDs): source host ---> first hop ... next hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next hop ... next hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next hop ... last hop ---> destination host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal manner as they are today. The ITR performs a TTL decrement and tests for 0 before encapsulating. Therefore, the ITR's hop is seen by the traceroute source as having an EID address (the address of the site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destinations of the ICMP messages are the ITR RLOC address and the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client and also retain the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0, as the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 18.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above, since the entire traceroute data packet is included in the ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention to forwarding ICMP messages back to the traceroute source. Farinacci, et al. Expires June 21, 2018 [Page 41] =0C Internet-Draft LISP December 2017 18.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure, since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 octets that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended, followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source, is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload, thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value. 18.3. Traceroute Using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, one cannot get all 3 segments of the traceroute. Segment 2 of the traceroute cannot be conveyed to the traceroute source, since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. Farinacci, et al. Expires June 21, 2018 [Page 42] =0C Internet-Draft LISP December 2017 19. Security Considerations Security considerations for LISP are discussed in [RFC7833], in addition [I-D.ietf-lisp-sec] provides authentication and integrity to LISP mappings. A complete LISP threat analysis can be found in [RFC7835], in what follows we provide a summary. The optional mechanisms of gleaning is offered to directly obtain a mapping from the LISP encapsulated packets. Specifically, an xTR can learn the EID-to-RLOC mapping by inspecting the source RLOC and source EID of an encapsulated packet, and insert this new mapping into its map-cache. An off-path attacker can spoof the source EID address to divert the traffic sent to the victim's spoofed EID. If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim;s RLOC, potentially overloading it. The LISP Data-Plane defines several mechanisms to monitor RLOC data- plane reachability, in this context Locator-Status Bits, Nonce- Present and Echo-Nonce bits of the LISP encapsulation header can be manipulated by an attacker to mount a DoS attack. An off-path attacker able to spoof the RLOC of a victim's xTR can manipulate such mechanisms to declare a set of RLOCs unreachable. This can be used also, for instance, to declare only one RLOC reachable with the aim of overload it. Map-Versioning is a data-plane mechanism used to signal a peering xTR that a local EID-to-RLOC mapping has been updated, so that the peering xTR uses LISP Control-Plane signaling message to retrieve a fresh mapping. This can be used by an attacker to forge the map- versioning field of a LISP encapsulated header and force an excessive amount of signaling between xTRs that may overload them. Most of the attack vectors can be mitigated with careful deployment and configuration, information learned opportunistically (such as LSB or gleaning) SHOULD be verified with other reachability mechanisms. In addition, systematic rate-limitation and filtering is an effective technique to mitigate attacks that aim to overload the control-plane. 20. Network Management Considerations Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [RFC7052] and [RFC6835]. Farinacci, et al. Expires June 21, 2018 [Page 43] =0C Internet-Draft LISP December 2017 21. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this data-plane LISP specification, in accordance with BCP 26 [RFC8126]. 21.1. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for lisp-data and lisp-control operation, respectively. IANA has updated the description for UDP ports 4341 and 4342 as follows: lisp-data 4341 udp LISP Data Packets lisp-control 4342 udp LISP Control Packets 22. References 22.1. Normative References [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-07 (work in progress), December 2017. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . Farinacci, et al. Expires June 21, 2018 [Page 44] =0C Internet-Draft LISP December 2017 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 22.2. Informative References [AFN] IANA, "Address Family Numbers", August 2016, . [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, . Farinacci, et al. Expires June 21, 2018 [Page 45] =0C Internet-Draft LISP December 2017 [I-D.ietf-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-ietf-lisp-eid-mobility-01 (work in progress), November 2017. [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-lisp-mn] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", draft-ietf-lisp-mn-01 (work in progress), October 2017. [I-D.ietf-lisp-predictive-rlocs] Farinacci, D. and P. Pillay-Esnault, "LISP Predictive RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in progress), November 2017. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 (work in progress), October 2017. [I-D.ietf-lisp-signal-free-multicast] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", draft-ietf-lisp-signal-free-multicast-07 (work in progress), November 2017. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in progress), November 2017. [I-D.meyer-loc-id-implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01 (work in progress), January 2009. [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996. Farinacci, et al. Expires June 21, 2018 [Page 46] =0C Internet-Draft LISP December 2017 [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, DOI 10.17487/RFC4192, September 2005, . [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, DOI 10.17487/RFC4866, May 2007, . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, . Farinacci, et al. Expires June 21, 2018 [Page 47] =0C Internet-Draft LISP December 2017 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, . [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, . [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, DOI 10.17487/RFC7052, October 2013, . [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . Farinacci, et al. Expires June 21, 2018 [Page 48] =0C Internet-Draft LISP December 2017 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, . Farinacci, et al. Expires June 21, 2018 [Page 49] =0C Internet-Draft LISP December 2017 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, Alia Atlas, Florin Coras and Alberto Rodriguez. This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC. The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward standards-track RFCs. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] Farinacci, et al. Expires June 21, 2018 [Page 50] =0C Internet-Draft LISP December 2017 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 o Posted December 2017. o Remove references to research work for any protocol mechanisms. o Document scanned to make sure it is RFC 2119 compliant. o Made changes to reflect comments from document WG shepherd Luigi Iannone. o Ran IDNITs on the document. B.2. Changes to draft-ietf-lisp-rfc6830bis-07 o Posted November 2017. o Rephrase how Instance-IDs are used and don't refer to [RFC1918] addresses. B.3. Changes to draft-ietf-lisp-rfc6830bis-06 o Posted October 2017. o Put RTR definition before it is used. o Rename references that are now working group drafts. o Remove "EIDs MUST NOT be used as used by a host to refer to other hosts. Note that EID blocks MAY LISP RLOCs". o Indicate what address-family can appear in data packets. o ETRs may, rather than will, be the ones to send Map-Replies. o Recommend, rather than mandate, max encapsulation headers to 2. o Reference VPN draft when introducing Instance-ID. o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Clarify when private addreses can be used. B.4. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Reencapsulating Tunnel Router is an RTR. Farinacci, et al. Expires June 21, 2018 [Page 51] =0C Internet-Draft LISP December 2017 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 o Posted July 2017. o Changed reference of IPv6 RFC2460 to RFC8200. o Indicate that the applicability statement for UDP zero checksums over IPv6 adheres to RFC6936. B.6. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. B.7. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. B.8. Changes to draft-ietf-lisp-rfc6830bis-01 o Posted March 2017. o Include references to new RFCs published. o Change references from RFC6833 to RFC6833bis. o Clarified LCAF text in the IANA section. o Remove references to "experimental". B.9. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses Farinacci, et al. Expires June 21, 2018 [Page 52] =0C Internet-Draft LISP December 2017 Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: farinacci@gmail.com Vince Fuller Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: vince.fuller@gmail.com Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: dmm@1-4-5.net Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: darlewis@cisco.com Albert Cabellos UPC/BarcelonaTech Campus Nord, C. Jordi Girona 1-3 Barcelona, Catalunya Spain EMail: acabello@ac.upc.edu Farinacci, et al. Expires June 21, 2018 [Page 53] --Apple-Mail=_EBF70E63-3D33-4166-9407-E9E9514946DC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_EBF70E63-3D33-4166-9407-E9E9514946DC-- From nobody Mon Dec 18 22:22:50 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2DF1241FC for ; Mon, 18 Dec 2017 22:22:48 -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, FREEMAIL_FROM=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 Y3oVn-vav5ST for ; Mon, 18 Dec 2017 22:22:46 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBB41205F0 for ; Mon, 18 Dec 2017 22:22:46 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id m11so7396353iti.1 for ; Mon, 18 Dec 2017 22:22:46 -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:content-transfer-encoding; bh=rkt6heyix/N0YwhA7GU6xyEzGZDKl53+JZpD8akR61c=; b=jrPCnZEoebaN/lDEfBJWnPEAyGannLypkldv6FgF/HcTyqAAGxgB8asBDQVI31AtEe LP1JNx42r8L33PLXK0t01D3IyTkngwO9jfPt4nLTK7OeUfxKS5ICMO7YayPto/ZrDlmJ SCIsJQzYskiRbPamwyWyyMDGf5y+lt4OmqIimtpOD01l7xt4tUaknarmMfa2cPDVBj5+ F7GSE+dbs1Rwk7YJoxIDXsHWUAwhoD6w5lHRPzyYSuSgdZcP4MSnIEhnbuNH40GJqcPY Wf/0ygfKA43NZbVODVbrncXFkePoCRG578Uuyhc+qT6gegjbw1Q+/s9nrL0fJo2+Z1or mBTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rkt6heyix/N0YwhA7GU6xyEzGZDKl53+JZpD8akR61c=; b=QBZ4u82LnhCW9VQVvjAE5myRmEARY5shtpKnbFwM+l3Q0uF5CWf9H3+pVWIlfGGCQS LZqKEnn1dcCqvIyfYF0VoBb0RprniApv4vc7OOfdHpiUl8zNM0NROZ6yw1orZmgMFuv1 TD1cRSmqwjn/O+knWF2QrEra1XO5hG4xINS/Zbgbufj4iaA+crFbRgq78L2m961HwMDV b5OIXtxJGfH83xtImeXk885gLVa7ac83k+0fecU1CK+7LRPQkGq+hGwUjEIttmQ+9ig6 49WI2HRdElKBLUoU068BB8Vjp3v0+T9Uu9I6yo4A+q+uudKF1S44LJ9YVUExAo4xgscv 5d9w== X-Gm-Message-State: AKGB3mLRSTqR2asx/QsHz/EOMEZbf+erIU/0jah9P4n32aLGie6h2FFW qhX/4/BPxxn0FjAl0o3KK7B2VwF8tV53QY4106+gnw== X-Google-Smtp-Source: ACJfBosfQEGuSkiJt5t0XVNPXFTZ+UwTuSX1TalIDhKhFV2Dyf+tnlH1ThkM799oW25Yxj+GVne80TLrssF6BbvUqRk= X-Received: by 10.36.93.5 with SMTP id w5mr1987681ita.124.1513664565917; Mon, 18 Dec 2017 22:22:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.166.68 with HTTP; Mon, 18 Dec 2017 22:22:25 -0800 (PST) In-Reply-To: <50B62140-68E0-4C0E-AB1C-2642C7FA11E7@gmail.com> References: <2CE690EE-D955-4E50-B17D-6BF31A8622AF@gmail.com> <50B62140-68E0-4C0E-AB1C-2642C7FA11E7@gmail.com> From: Alberto Rodriguez-Natal Date: Mon, 18 Dec 2017 22:22:25 -0800 Message-ID: To: Dino Farinacci Cc: "lisp@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lisp] Review of RFC6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 06:22:48 -0000 Ack on the new version. Thanks Dino. Alberto On Fri, Dec 15, 2017 at 12:12 PM, Dino Farinacci wrot= e: > Enclosed is the latest revision of RFC6833bis-07. Thanks for closing the = loop Alberto. If you can ack the new changes, I=E2=80=99ll submit -07 this = weekend. > >> On Dec 7, 2017, at 11:06 PM, Alberto Rodriguez-Natal wrote: >> >> Hey Dino, >> >> Sorry for the delay on this. Mostly agree with your responses, thanks >> for the edits! >> >> There a few points that I would like to clarify. See below. > > No prob. See my responses. > >> >>>> For definitions of other terms -- notably Map-Request, Map-Reply, >>>> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please >>>> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >>>> >>>> =E2=80=A2 [AR] I think that the definitions for Map-Request and Map-= Reply >>>> should be moved here, and probably we should include the definition >>>> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >>>> control-plane messages, not the other way around. >>> >>> They did. But the text you identified above was not changed. Changed no= w. >> >> I meant that Map-Request and Map-Reply are not defined here (or >> anywhere else that I can find) and they should. The closest things are >> Encapsulated Map-Request and Negative Map Reply. > > I added a brief definitions of each to be consistent with Map-Register an= d Map-Notify definitions that are already there. > >> >>>> The RLOCs in the Map-Reply are globally routable IP addresses of all >>>> ETRs for the LISP site. >>>> >>>> =E2=80=A2 [AR] We should remove "globally" here. Maybe also add a >>>> "Generally" at the beginning since we might have LCAFs with AFI =3D 0 >>>> (LISP-VPN encoding of Home-IID for instance). >>> >>> Removed =E2=80=9Cglobally=E2=80=9D. I don=E2=80=99t understand your oth= er =E2=80=9CGenerally=E2=80=9D comment. >> >> My point was that in the LISP-VPN draft the Home-IID is encoded as an >> RLOC that it is not a routable address for the ETR. > > I removed all occurrences of =E2=80=9Cglobally routable=E2=80=9D to =E2= =80=9Croutable=E2=80=9D. > >> >>>> For example, a requester with two cached EID-Prefixes that are covered >>>> by a Map-Reply containing one less-specific prefix replaces the entry >>>> with the less-specific EID-Prefix. >>>> >>>> =E2=80=A2 [AR] Not sure if I follow here. Does this mean that a >>>> less-specific received in a Map-Reply will erase from the map-cache >>>> previously cached more-specifics that are covered by the >>>> less-specific? >>> >>> Yes, because if the Map-Reply returned a more-specific with the less-sp= ecific, then it would be replaced so the less-specific replaces the more-sp= ecifics that ARE NOT in the Map-Reply. >> >> I think that I would rephrase this behavior to make it optional then. >> There are implementations which just return the entry that the >> requested EID hits and don't return by default any more-specifics >> below. > > It is not optional. And this section of the draft defines the details. An= d the section includes a MUST. > >> >> >>>> When more than one EID-Prefix is returned, all SHOULD use the same >>>> Time to Live value so they can all time out at the same time. When a >>>> more-specific EID-Prefix is received later, its Time to Live value in >>>> the Map-Reply record can be stored even when other less-specific >>>> entries exist. >>>> >>>> =E2=80=A2 [AR] We should explain in which cases a more-specific can = be >>>> received later. >>> >>> I don=E2=80=99t follow. Each EID-record will contain a TTL for the leng= th prefix that is encoded. So the new Map-Reply TTL will be used for any le= ngth entry (and in this case the more-specific). >> >> My concern was that we should provide some context on when an ITR may >> receive a more-specific prefix that overlaps with an existing >> less-specific prefix already in its map-cache. One example is the EID >> mobility draft, we can reference it here. > > I added a few sentences. > > Thanks, > Dino > > > > > > > From nobody Wed Dec 20 03:21:51 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF72127599 for ; Wed, 20 Dec 2017 03:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBmTw9afHY9R for ; Wed, 20 Dec 2017 03:21:48 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC8612421A for ; Wed, 20 Dec 2017 03:21:47 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id i11so9025730wmf.4 for ; Wed, 20 Dec 2017 03:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=GXCv6Vohkv2y//kyZ9FfNwxgjPeMSgZ1NKQrYyDeAKo=; b=bzRb5qmGqkcrX72RYv39ugk9mjIzmLKwgwtO7+2aptjZkB7LMtmyv+YKVVKqrJEDCn LnSsqRwuF3jfvGIoWHOCTMapvMxBQ/ho0JMBqc8MryAFgofFxIe8/nnY/EX/xSu+TPMh t5ncztUnvko/8if2k5lHhpG9uAC/a2q6lXfjZa7kLfIYYdks61QnNe4feFRptp4tV8LH oggHtPdr/X78kzkmhehAG3sGZdy4HbWTSRMlyonRHLxtqK8e21qATw8r4wvA2ydT6LhY IEf9dYlYspVy9ZRV51vnHdPeBu0G5dkpeJ6fXrgJxC0izxVHDEF79RWtAAfTt3KoHaNF ym5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=GXCv6Vohkv2y//kyZ9FfNwxgjPeMSgZ1NKQrYyDeAKo=; b=p8CqnmJhZqFQTScBwnohnVcNiqJAUjEkeZZLlFtJs44SLqeI4CaLIsdul7zb2obDx5 QVmAGc7dG2OSz4Dj8uAsYOPsX7ECwCmYzBQmr/TxLi4azm2tKt9J4UYwAC3j0D0KJT2B /wO/mNXJlfkvBy4VrOnYp38xkftptS+Vpa5t/vkARl1Vj6y3qFXRen8E2RNLgpl6ek1G UFPnQtbkWjSaQoCb0WGHTLJtZKM8JertoDuWrLx5FNsjLul9nQ86JykA8YLcggKreLus 1mbdN0QOGI8Y8CnuRlUFSTd20Bd4UUHF8fX6rJtl122PtwSZZHvvYd2lV98WDZXjg+b5 P1xQ== X-Gm-Message-State: AKGB3mKJGZCoSmBJ4Urcu49wQ0PbvMtF80mhIwxgAdeJDvqMjZEH1zUC 5E4SjMtILoZZ8JqgqTJ29t8ZEQ== X-Google-Smtp-Source: ACJfBouEyAiamIssIh52TyZV8IkC9cjtYuj/bveu49fI7CU7NitWdx5iydFQ4ip+Qm9xERZnTgAu8A== X-Received: by 10.80.164.241 with SMTP id x46mr4934544edb.247.1513768905699; Wed, 20 Dec 2017 03:21:45 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:e844:40fd:34af:8886? ([2001:660:330f:a4:e844:40fd:34af:8886]) by smtp.gmail.com with ESMTPSA id p47sm16269875edc.30.2017.12.20.03.21.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 03:21:44 -0800 (PST) From: Luigi Iannone Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 20 Dec 2017 12:21:41 +0100 References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <4D2A0EA8-9096-4E12-99F9-B60910D7122E@gmail.com> <86F3ABEE-5623-45EB-AD8F-342027FA6101@gigix.net> <30D14161-2DE0-4153-879D-01F2EF951C1C@gigix.net> To: Dino Farinacci , lisp-chairs@tools.ietf.org, "lisp@ietf.org list" In-Reply-To: <30D14161-2DE0-4153-879D-01F2EF951C1C@gigix.net> Message-Id: <24D2C029-B9F6-4030-9769-3E6FD5A9FC8E@gigix.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review (PLEASE COMMENTS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 11:21:50 -0000 Dino, my answers inline. > On 18 Dec 2017, at 19:06, Dino Farinacci wrote: >=20 >> Dino, >>=20 >> thanks for the hard work.=20 >=20 > I am trying to make it less harder than it needs to be. New diff and = text file enclosed. >=20 >> my replies inline (trimmed the points we agree or have been clarified = by your answers). >=20 > Thanks for that. >=20 >> @ALL: this is not a private discussion between me and Dino and I = invite all of you to chime in and provide an opinion. >>=20 >> There one clear point here: This document is not about data-plane, = is data-plane + fragmented information that does not belong here.=20 >=20 > It is about not losing important information we decided 10 years ago = to keep > in because otherwise, we=E2=80=99d have to sprinkle it across = documents. And WE DID decide to NOT create a third document. AFAIR there was only consensus in having two documents. I can live with two documents, but the content has to be clear. At this = stage I do not consider its content clear enough. >=20 >> The document can be shorter and to the point. There are a lot of OAM = information that does not belong to the data-plane. >=20 > The OAM information is necessary for the data-plane. And if LISP-GPE, = VXLAN, or any other data plane wants to use their own OAM or use the = LISP control-plane differently, it needs to be documented in their = data-planes. Hence, why this information is there. Doesn=E2=80=99t make sense to me. That is not a reason.=20 That information can be available in another document and still be used = by LISP-GPE, VxLAN, or any other data plane. >=20 > Short is not necessarily good if the document is incomplete. Agreed, but long does not mean complete either. >>>>=20 >>>> It is not alphabetical and not logical (at least I cannot se it). >>>=20 >>> Originally it was suppose to be logical. I will double check to make = sure the terms are introduced in an obvious sequence. If I can avoid = forward-references, I will do so. >>>=20 >>=20 >> I guess this is still on your to do list.=20 >=20 > I thought the order was fine so I didn=E2=80=99t change it. >=20 OK, but a reader will just think the order is random. Can you add text = elaborating the rationale of the order? [snip] >=20 >>>>=20 >>>>> Any references to tunnels in this specification refer to >>>>> dynamic encapsulating tunnels; they are never statically >>>>> configured. >>>=20 >>> Well many have said that LISP tunnels are not like traditional = tunnels. Traditional tunnels are configured and provisioned. Where LISP = tunnels are dynamic and used on demand. I would like the sectiond to = stay. >>=20 >> You can move this sentence in the intro or where it make sense to = you. In the Definition of terms is just lost. >=20 > I added it as the first definition in the Definition of Terms section. Why not in the introduction or somewhere else?=20 Why put a sentence that states what LISP is in the definition of term = section?=20 Such a sentence fits better in the introduction. [snip] >>=20 >>>>> o Other types of EID are supported by LISP, see [RFC8060] for >>>>> further information. >>>>>=20 >>>> I would put the last two bullets in the definition of EID. It = simplifies the story here. >>>=20 >>> I think it should be kept in. I feel it adds value. >>=20 >> You break the operational flow by opening a different point = describing what is what. It makes the overall procedure unclear. >=20 > It was put there because someone commented on it. You have to tell me = why you think it breaks flow. We discuss how end-systems send to EIDs. = We say what EIDs are and how they are assigned to hosts. And then we = move to RLOCs. It is pretty plan, simple, and straight-forward. >=20 Those two point would have more emphasis somewhere else.=20 Where they are now they break the flow and do not provide details. You can actually put them at the end of section 1 as normal sentences. = We then add a reference to LCAF and state that this document describes = procedures only for EID that are IPv4 or IPv6 addresses. Incidentally, the end of the 1 section is also a good place to put the = sentences about dynamic tunnelling.=20 >>=20 >>=20 >>>=20 >>>>> o EID-Prefixes are likely to be hierarchically assigned in a = manner >>>>> that is optimized for administrative convenience and to = facilitate >>>>> scaling of the EID-to-RLOC mapping database. The hierarchy is >>>>> based on an address allocation hierarchy that is independent of >>>>> the network topology. >>>>>=20 >>>> Drop the last bullet it is about scalability. >>>=20 >>> Right, but still important to mention. Many of the benefits of LISP = aren=E2=80=99t always obvious. So we have to point them out. >>=20 >> Dino, this has to go away. This is NOT the control-plane = advertisement document. This is the LISP control-plane, that=E2=80=99s = all. >> This was agreed upon at the time of rechartering. >=20 > Sorry disagree. You have to mention some control-plane. And not the = definition of it but how its used by this data-plane. >=20 The bullet is just not accurate. Look at the LISP-Beta and you realise = that that statement does not hold. [snip] >>=20 >>>> The description of the encap/decap operation lacks of clarity = concerning how to deal with=20 >>>> ECN bits and DSCP . >>>>=20 >>>> 1. I think that the text should make explicitly the difference = between DSCP and ECN fields. >>>>=20 >>>> 2. How to deal with ECN should be part of the description of the = encap/decap not a paragraph apart. >>>> This basically means that half of the last paragraph should be a = bullet of the ITR/PITR encapsulation=20 >>>> and the other half in the ETR/PETR operation. >>>=20 >>> We went through this with a lot of people for RFC6830. It took many = months to resolve. I dare not touch this text. >>=20 >> You have just to move it up and separate it in two bullets. No = changes needed. >=20 > Can you be more specific please. In the ITR part we put as last bullet the first part of the original = paragraph: - =16=16The Explicit Congestion Notification ('ECN=E2=80=99), = namely bits 6 and 7 of both the IPv4 and IPv6 headers, requires = special treatment in order to avoid discarding indications of congestion = [RFC3168]. An ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field = from the inner header to the outer header. Re-encapsulation MUST copy the = 2-bit 'ECN' field from the stripped outer header to the new outer = header. In the ETR part we put as last bullet the second part of the original = paragraph: - =16=16The Explicit Congestion Notification ('ECN=E2=80=99), = namely bits 6 and 7 of both the IPv4 and IPv6 headers, requires = special treatment in order to avoid discarding indications of congestion = [RFC3168]. If the 'ECN' field contains a congestion indication = codepoint (the value is '11', the Congestion Experienced (CE) codepoint), = then ETR/PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is = used to forward the packet beyond the ETR. =20 that=E2=80=99s it=20 >=20 >>>=20 >>>>> 9. Routing Locator Selection >>>>>=20 >>>> Large part of this section is about control plane issues and as = such should be put in 6833bis. >>>>=20 >>>> What this section should state is that priority and weight are used = to select the RLOC to use. >>>> Only exception is gleaning where we have one single RLOC and we do = not know neither priority nor weight. >>>>=20 >>>> All the other operational discussion goes elsewhere, but not in = this document. >>>=20 >>> We have already decided (a year ago) not to move this because its = the data-plane that needs to know about locator reachability so it knows = which locators to use. >>=20 >> Please check the minutes of past meetings (as I did), the only = unclear point was SMR, everything else was agreed to be moved out.=20 >=20 > Please point it out. We have taken every input from the WG. https://www.ietf.org/proceedings/96/minutes/minutes-96-lisp > And Albert and I were in sync and thought you had agreed (or maybe you = stopped disagreeing until now). Great, now you need to sync with the group, hence, this discussion. >=20 >>>=20 >>>>> 10. Routing Locator Reachability >>>>>=20 >>>>> Several mechanisms for determining RLOC reachability are currently >>>>> defined: >>>>>=20 >>>> There exists data-plane based reachability mechanisms and control = plane reachability mechanisms. >>>> We have to keep here only the data plane based mechanism and move = the other in 6833bis. >>>>=20 >>>> We need to keep: 1, 6, Echo-Nonce,=20 >>>>=20 >>>> We need to move: 2, 3, 4, 5, RLOC-Probing >>>=20 >>> Again, we already had this debate. The decision was made and agreed = upon. We shouldn=E2=80=99t open this up again. >>=20 >> Exactly, it has been decided, hence control plane things go in the = control plane document. (or OAM) >=20 > You are trying to draw a hard wall between the data-plane and = control-plane. In the real world that is not how protocols are deployed. I am trying to make this a high quality document. I really don=E2=80=99t = want that the document comes back from the IESG because this would delay = publication a lot. Besides, this is a specification document, independent from the = implementationS. If anybody wants to tighten somehow control and data = planes, they are free to go that way. What we need here is to put some text in 6833bis, and replace it here = with the sentence =E2=80=9COther control plane based reachability = mechanism can be found in [6833bis]=E2=80=9D In 6833bis we do the opposite, we add the text cut from 6830bis and add = =E2=80=9COther data plane based reachability mechanism can be found in = [6830bis]=E2=80=9D [snip] >=20 >>>>=20 >>>> Actually I remember a suggestion about putting operations issues = like this in an OAM document which would be a good idea.=20 >>>=20 >>> I don=E2=80=99t agree. We had already mentioned there is a = control-plane protocol that is described in RFC6833bis and a data-plane = protocol that USEs the control-plane protocol. And the usage should be = here. >>=20 >> Not following here. Why should the data-plane control the control = plane? >=20 > It is not controlling the control-plane, it is using it. Did my = example of an API not make that clear? >=20 To me was not clear, let me try to reword. The link between control and data planes is the LISP cache and some = events that may trigger specific operations. If those operations are data-plane they stay here.=20 It those operations are control-plane they go in 6833bis. =20 [snip] >>> Making changes like this to RFC6833 will be huge. >>=20 >> You do not have to. see my comment above. >>=20 >>> We have the documents separated in the current state right now that = seems to work and seems to be clear. >>=20 >> I did not have time to go over 6833bis, but concerning 6830bis the = document is not clear and it is a patchwork of data-plane, = control-plane, and deployment issues. >>=20 >> This is not what was agreed upon when we started this effort. >=20 > The effort was continuing. And we created options with further study. Not sure I am following here. The initial intent was two have two = documents. > Both Albert and I did that further study and the drafts reflect the = decisions. There were no WG objections other than from you which we had = thought we convinced. Again, IETF 96th. Yes, I proposed at the mic to move the text in = 6833bis, only objection to this was you on the SMR mechanism. Other then the SMR point we draw a clear line. >=20 >>>>>=20 >>>>> 19. Security Considerations >>>>>=20 >>>>> Security considerations for LISP are discussed in [RFC7833], in >>>>> addition [I-D.ietf-lisp-sec] provides authentication and integrity = to >>>>> LISP mappings. >>>>>=20 >>>> lisp-sec is control-plane has to be referenced in 6833bis. >>>=20 >>> Yes, but if an ITR caches a coarse EID-prefix, then there is a = data-plane redirection attack. >>>=20 >>=20 >> My point is that lisp-sec provides control plane features, so the = sentence does not bring anything to the discussion. >> Please delete. Any comment here? >>=20 >>=20 >>>>> 21.1. LISP UDP Port Numbers >>>>>=20 >>>>> The IANA registry has allocated UDP port numbers 4341 and 4342 for >>>>> lisp-data and lisp-control operation, respectively. IANA has = updated >>>>> the description for UDP ports 4341 and 4342 as follows: >>>>>=20 >>>>> lisp-data 4341 udp LISP Data Packets >>>>> lisp-control 4342 udp LISP Control Packets >>>>>=20 >>>> 4342 is control-plane and MUST be requested to IANA in the 6833bis = document. >>>=20 >>> We didn=E2=80=99t want to change the registry so we are keeping this = here. Its really no big deal. >>=20 >>> Note the data-plane implementation will have to send to the 4342 = socket so its not out of place at all for this to be in this document. >>>=20 >>=20 >> 4342 is control plane not data plane, any further review beyond the = WG will point out this inconsistency. >=20 > Sorry a data-plane component uses it > . Why split it up when we can have this in one place. Can you elaborate better your rationale?=20 The data-plane can trigger control plane messages but you do not = allocate the types here.=20 That is done (rightfully) elsewhere. So, following the same policy, 4342 = has to go 6833bis. Thanks again Ciao L. >=20 > Dino >=20 > >=20 >=20 >=20 From nobody Tue Dec 26 17:48:37 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1677124207 for ; Tue, 26 Dec 2017 17:48:35 -0800 (PST) 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 UJuk7wS8uP-H for ; Tue, 26 Dec 2017 17:48:32 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9AA127076 for ; Tue, 26 Dec 2017 17:48:32 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id z132so4476078ywd.9 for ; Tue, 26 Dec 2017 17:48:32 -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=0CCs8qCRKe9ddSdVI/cQnMYjmMCyfA+reLWJqCQG4xY=; b=tKGEROaKcB9nrUSwrcs4WidXE9unCGJH/MIsyB11iiZ/WBGRWpwYuYWxwyrUAl7+E8 FKa0Ikb3uN4k+Xl9+jt0QjTT65oQKzwvDwgEauvUTQoazwuM0xlKqhvJ6zEHwhzOmzO4 LcOXD4xGj6UUcGBOqXJQreKdZzSxZV9RLr3zoXU9g9lvZNQ1fVkybwLnhJj5DVQbWHEg /icHxrGF4ZSpzUjKnKBCFI+4pVmlompyTWLoX/BOYYUmPP1FUNcuis3QY4Q4608pLTm7 lOTXck9j2QBm9fYzsC94wClLXr5tspZNkQvL8nZtyC4p4lYcKTVlTyUpGD9GJCHRT+dZ TIMg== 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=0CCs8qCRKe9ddSdVI/cQnMYjmMCyfA+reLWJqCQG4xY=; b=UM4zcbZnHYwL5msHB0WaH9C0MIfLvfeU4WVZ61qgLeubwlJaVCr4TyhFKQFVvJTRBq EFTlHISiFCbK9jd+bQnIwR1i6Kn02rNeNTLlJ3npblGeoo1qeblYQxY+t9eYdRuvogvf xf5sJNpVmsnFTPCb7r40dULGHMWYbPYk1CKtEuXC72HPUB9IcZBmWOUT+tHKSSObFAbT yT2d45ycUw5ZEYnoIc1U5tyo6SNaqUC7GKegU1kZDYYL14MMI2SYCIyPtwsJlI3xeWTX Nzdp+KOJ2SZrcjHHve6v2jUA/lx4jMvlfcZr/Y09EdgSjU9S85TGa280uDFSUR++fLQD OAXg== X-Gm-Message-State: AKGB3mLhGPH/tmpGYw24aN3If1z5QfbfreMVcKA9XguxBMKcFP6WFyzf 2vf+SVPURWkt0/bRqvOEN9CKmRIWyvz2HiC1zdooU35R X-Google-Smtp-Source: ACJfBosAmIs3SufNFrSUUekJzFAbEIGmhmIFToBz202oPOIVf/SK+Rm6bHRmnEjOdfwSg1Q5DE2UqG4jrIkhsAHJYGk= X-Received: by 10.129.104.194 with SMTP id d185mr18599276ywc.322.1514339311122; Tue, 26 Dec 2017 17:48:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.183.142 with HTTP; Tue, 26 Dec 2017 17:48:30 -0800 (PST) In-Reply-To: <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> From: Albert Cabellos Date: Wed, 27 Dec 2017 02:48:30 +0100 Message-ID: To: Luigi Iannone Cc: "lisp@ietf.org list" , lisp-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary="001a11490486b57fac0561489850" Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 01:48:36 -0000 --001a11490486b57fac0561489850 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thanks for the review, please find my comments inline. I have removed all the comments for which I **agree**: > > Provider-Assigned (PA) Addresses: PA addresses are an address block > assigned to a site by each service provider to which a site > connects. Typically, each block is a sub-block of a service > provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and > is aggregated into the larger block before being advertised into > the global Internet. Traditionally, IP multihoming has been > implemented by each multihomed site acquiring its own globally > visible prefix. LISP uses only topologically assigned and > aggregatable address blocks for RLOCs, eliminating this > demonstrably non-scalable practice. > > Last sentence to be deleted is a relic of scalability discussion. > > Agreed. I suggest deleting entirely the definitions for both PA and PI, they are not used throughout the document. [snip] > > > Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for > IPv6) value used in the source and destination address fields of > the first (most inner) LISP header of a packet. The host obtains > a destination EID the same way it obtains a destination address > today, for example, through a Domain Name System (DNS) [RFC1034] > lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. > The source EID is obtained via existing mechanisms used to set a > host's "local" IP address. An EID used on the public Internet > must have the same properties as any other IP address used in that > manner; this means, among other things, that it must be globally > unique. An EID is allocated to a host from an EID-Prefix block > associated with the site where the host is located. An EID can be > used by a host to refer to other hosts. Note that EID blocks MAY > be assigned in a hierarchical manner, independent of the network > topology, to facilitate scaling of the mapping database. In > addition, an EID block assigned to a site may have site-local > structure (subnetting) for routing within the site; this structure > is not visible to the global routing system. In theory, the bit > string that represents an EID for one device can represent an RLOC > for a different device. As the architecture is realized, if a > given bit string is both an RLOC and an EID, it must refer to the > same entity in both cases. > > > Is the above sentence really necessary? > Agreed, why not simplify the definitions. They are written from the =E2=80=98Internet scalability mindset=E2=80=99, why not say that an EID is = an address of the overlay and an RLOC an address of the overlay. This change may require further changes on the document so I am not 100% sure if this is a good idea. [snip] > > Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling > > RTR have never been defined. Agree, they are defined in LISP-TE, not sure about the rules here. They are used in section 17. [snip] > > Recursive Tunneling: Recursive Tunneling occurs when a packet has > more than one LISP IP header. Additional layers of tunneling MAY > be employed to implement Traffic Engineering or other re-routing > as needed. When this is done, an additional "outer" LISP header > is added, and the original RLOCs are preserved in the "inner" > header. > > Do not think the following sentence is really necessary. > It is an easy way to explain that tunnels can be nested, may be obvious for us but not for some readers. In any case the term =E2=80=98recursive tunnel= ing=E2=80=99 is used several times throughout the document. I don=C2=B4t have a strong opin= ion but I=C2=B4d say leave it as it is. > > o EIDs are typically IP addresses assigned to hosts. > > o Other types of EID are supported by LISP, see [RFC8060] for > further information. > > I would put the last two bullets in the definition of EID. It simplifies the story here. > > I suggest to leave them here, I don=C2=B4t think that readers start from th= e =E2=80=98Definition of terms=E2=80=99, these are relevant concepts to under= stand LISP. > > The description of the encap/decap operation lacks of clarity concerning how to deal with > ECN bits and DSCP . > > 1. I think that the text should make explicitly the difference between DSCP and ECN fields. > > 2. How to deal with ECN should be part of the description of the encap/decap not a paragraph apart. > This basically means that half of the last paragraph should be a bullet of the ITR/PITR encapsulation > and the other half in the ETR/PETR operation. Agreed, what about this (please comment): When doing ITR/PITR encapsulation: o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field. o The outer-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below. o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. o The inner-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below. o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 18.3 for TTL exception handling for traceroute packets. > > Large part of this section is about control plane issues and as such should be put in 6833bis. > > What this section should state is that priority and weight are used to select the RLOC to use. > Only exception is gleaning where we have one single RLOC and we do not know neither priority nor weight. > > All the other operational discussion goes elsewhere, but not in this document. > Agree, I suggest moving it to 6833bis. What to leave in 6830bis is less obvious, maybe something like (not final, just a couple of ideas): The data-plane must follow the state stored in the map-cache to encapsulate and decapsulate packets. The map-cache is populated using a control-plane, such as [6833bis]. ETRs encapsulate packets following the Priorities and Weights stored in the map-cache. Actually we should merge this section with 'Routing Locator Hashing' > We need to cite the threats document because of the security issues of LSB. What about this: Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix. *****There are security risks associated to the use of Locator-Status-Bits, we recommend to follow the guidelines described in [THREATS]****** > > 12. Routing Locator Hashing > > When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to > a requesting ITR, the Locator-Set for the EID-Prefix may contain > different Priority values for each locator address. When more than > one best Priority Locator exists, the ITR can decide how to load- > share traffic against the corresponding Locators. > > The above paragraph should not state where the mapping comes from, from the data plane perspective it comes from the cache. > > Also where is weight??????? What about: When an ITR encapsulates packets it may found that corresponding map-cache entry contains a Locator-Set with different priorities and weights, the following hash algorithm may be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: > > 13. Changing the Contents of EID-to-RLOC Mappings > > > This is a control plane issue, as such it has to go in 6833bis, with two exception: > The very first paragraph stetting the problem, and the versioning subsection, because it is a data-plane mechanism. > > All of the rest 6833bis > > Actually I remember a suggestion about putting operations issues like this in an OAM document which would be a good idea. > > So you are suggesting that the LISP control-plane does not define any mechanism to update EID-to-RLOC mappings? --001a11490486b57fac0561489850 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

Thanks for the review, please find my comments i= nline.

I have removed all the comments for which I **agr= ee**:

>
> =C2=A0 Provider-Assigned (PA) Addresses: =C2=A0 P= A addresses are an address block
> =C2=A0 =C2=A0 =C2=A0assigned to a = site by each service provider to which a site
> =C2=A0 =C2=A0 =C2=A0c= onnects.=C2=A0 Typically, each block is a sub-block of a service
> = =C2=A0 =C2=A0 =C2=A0provider Classless Inter-Domain Routing (CIDR) [RFC4632= ] block and
> =C2=A0 =C2=A0 =C2=A0is aggregated into the larger block= before being advertised into
> =C2=A0 =C2=A0 =C2=A0the global Intern= et.=C2=A0 Traditionally, IP multihoming has been
> =C2=A0 =C2=A0 =C2= =A0implemented by each multihomed site acquiring its own globally
> = =C2=A0 =C2=A0 =C2=A0visible prefix.=C2=A0 LISP uses only topologically assi= gned and
> =C2=A0 =C2=A0 =C2=A0aggregatable address blocks for RLOCs,= eliminating this
> =C2=A0 =C2=A0 =C2=A0demonstrably non-scalable pra= ctice.
>
> Last sentence to be deleted is a relic of scalabilit= y discussion.
>
>

Agreed. I suggest deleting entirely th= e definitions for both PA and PI, they are not used throughout the document= .

[snip]
>
>
> =C2=A0 Endpoint ID (EID): =C2=A0 An= EID is a 32-bit (for IPv4) or 128-bit (for
> =C2=A0 =C2=A0 =C2=A0IPv= 6) value used in the source and destination address fields of
> =C2= =A0 =C2=A0 =C2=A0the first (most inner) LISP header of a packet.=C2=A0 The = host obtains
> =C2=A0 =C2=A0 =C2=A0a destination EID the same way it = obtains a destination address
> =C2=A0 =C2=A0 =C2=A0today, for exampl= e, through a Domain Name System (DNS) [RFC1034]
> =C2=A0 =C2=A0 =C2= =A0lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
> = =C2=A0 =C2=A0 =C2=A0The source EID is obtained via existing mechanisms used= to set a
> =C2=A0 =C2=A0 =C2=A0host's "local" IP addre= ss.=C2=A0 An EID used on the public Internet
> =C2=A0 =C2=A0 =C2=A0mu= st have the same properties as any other IP address used in that
> = =C2=A0 =C2=A0 =C2=A0manner; this means, among other things, that it must be= globally
> =C2=A0 =C2=A0 =C2=A0unique.=C2=A0 An EID is allocated to = a host from an EID-Prefix block
> =C2=A0 =C2=A0 =C2=A0associated with= the site where the host is located.=C2=A0 An EID can be
> =C2=A0 =C2= =A0 =C2=A0used by a host to refer to other hosts.=C2=A0 Note that EID block= s MAY
> =C2=A0 =C2=A0 =C2=A0be assigned in a hierarchical manner, ind= ependent of the network
> =C2=A0 =C2=A0 =C2=A0topology, to facilitate= scaling of the mapping database.=C2=A0 In
> =C2=A0 =C2=A0 =C2=A0addi= tion, an EID block assigned to a site may have site-local
> =C2=A0 = =C2=A0 =C2=A0structure (subnetting) for routing within the site; this struc= ture
> =C2=A0 =C2=A0 =C2=A0is not visible to the global routing syste= m.=C2=A0 In theory, the bit
> =C2=A0 =C2=A0 =C2=A0string that represe= nts an EID for one device can represent an RLOC
> =C2=A0 =C2=A0 =C2= =A0for a different device.=C2=A0 As the architecture is realized, if a
&= gt; =C2=A0 =C2=A0 =C2=A0given bit string is both an RLOC and an EID, it mus= t refer to the
> =C2=A0 =C2=A0 =C2=A0same entity in both cases.
&g= t;
>
> Is the above sentence really necessary?
>

A= greed, why not simplify the definitions. They are written from the =E2=80= =98Internet scalability mindset=E2=80=99, why not say that an EID is an add= ress of the overlay and an RLOC an address of the overlay. This change may = require further changes on the document so I am not 100% sure if this is a = good idea.

[snip]
>
> =C2=A0 Re-encapsulating Tunneling = in RTRs: =C2=A0 Re-encapsulating Tunneling
>
> RTR have never b= een defined.


Agree, they are defined in LISP-TE, not sure about = the rules here. They are used in section 17.

[snip]
>
> = =C2=A0 Recursive Tunneling: =C2=A0 Recursive Tunneling occurs when a packet= has
> =C2=A0 =C2=A0 =C2=A0more than one LISP IP header.=C2=A0 Additi= onal layers of tunneling MAY
> =C2=A0 =C2=A0 =C2=A0be employed to imp= lement Traffic Engineering or other re-routing
> =C2=A0 =C2=A0 =C2=A0= as needed.=C2=A0 When this is done, an additional "outer" LISP he= ader
> =C2=A0 =C2=A0 =C2=A0is added, and the original RLOCs are prese= rved in the "inner"
> =C2=A0 =C2=A0 =C2=A0header. =C2=A0>
> Do not think the following sentence is really necessary.
&= gt;

It is an easy way to explain that tunnels can be nested, may be = obvious for us but not for some readers. In any case the term =E2=80=98recu= rsive tunneling=E2=80=99 is used several times throughout the document. I d= on=C2=B4t have a strong opinion but I=C2=B4d say leave it as it is.
>
> =C2=A0 o =C2=A0EIDs are typically IP addresses assigned to ho= sts.
>
> =C2=A0 o =C2=A0Other types of EID are supported by LIS= P, see [RFC8060] for
> =C2=A0 =C2=A0 =C2=A0further information.
&g= t;
> I would put the last two bullets in the definition of EID. It si= mplifies the story here.
>
>

I suggest to leave them her= e, I don=C2=B4t think that readers start from the =E2=80=98Definition of te= rms=E2=80=99, these are relevant concepts to understand LISP.
>
> The description of the encap/decap operation lacks of clarity= concerning how to deal with
> ECN bits and DSCP .
>
> 1.= I think that the text should make explicitly the difference between DSCP a= nd ECN fields.
>
> 2. How to deal with ECN should be part of th= e description of the =C2=A0encap/decap not a paragraph apart.
> =C2= =A0 =C2=A0This basically means that half of the last paragraph should be a = bullet of the ITR/PITR encapsulation
> =C2=A0 =C2=A0and the other hal= f =C2=A0in the ETR/PETR operation.


Agreed, what about this (plea= se comment):

=C2=A0 =C2=A0When doing ITR/PITR encapsulation:

=C2=A0 =C2=A0 o =C2=A0The outer-header 'Time to Live&= #39; field (or 'Hop Limit' field, in the case of IPv6) SHOULD be co= pied from the inner-header 'Time to Live' field.
=C2=A0 = =C2=A0 o =C2=A0The outer-header 'Differentiated Services Code Point'= ; (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) = SHOULD be copied from the inner-header DSCP field ('Traffic Class' = field, in the case of IPv6) considering the exception listed below.
=C2=A0 =C2=A0o =C2=A0The 'Explicit Congestion Notification' (ECN= ) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires s= pecial treatment in order to avoid discarding indications of congestion [RF= C3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the = inner header to the outer header. Re-encapsulation MUST copy the 2-bit '= ;ECN' field from the stripped outer header to the new outer header.

When doing ETR/PETR decapsulation:

=C2=A0 =C2=A0o =C2=A0The inner-header 'Time to Live' field (= or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from th= e outer-header 'Time to Live' field, when the Time to Live value of= the outer header is less than the Time to Live value of the inner header.= =C2=A0 Failing to perform this check can cause the Time to Live of the inne= r header to increment across encapsulation/decapsulation cycles.=C2=A0 This= check is also performed when doing initial encapsulation, when a packet co= mes to an ITR or PITR destined for a LISP site.
=C2=A0 =C2=A0o = =C2=A0The inner-header 'Differentiated Services Code Point' (DSCP) = field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be= copied from the outer-header DSCP field ('Traffic Class' field, in= the case of IPv6) considering the exception listed below.
=C2=A0= =C2=A0o =C2=A0The 'Explicit Congestion Notification' (ECN) field (= bits 6 and 7 of the IPv6 'Traffic Class' field) requires special tr= eatment in order to avoid discarding indications of congestion [RFC3168]. I= f the 'ECN' field contains a congestion indication codepoint (the v= alue is '11', the Congestion Experienced (CE) codepoint), then ETR = decapsulation MUST copy the 2-bit 'ECN' field from the stripped out= er header to the surviving inner header that is used to forward the packet = beyond the ETR.=C2=A0 These requirements preserve CE indications when a pac= ket that uses ECN traverses a LISP tunnel and becomes marked with a CE indi= cation due to congestion between the tunnel endpoints.

=
Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsu= late after decapsulating, the net effect of this is that the new outer head= er will carry the same Time to Live as the old outer header minus 1.
<= div>
Copying the Time to Live (TTL) serves two purposes: firs= t, it preserves the distance the host intended the packet to travel; second= , and more importantly, it provides for suppression of looping packets in t= he event there is a loop of concatenated tunnels due to misconfiguration.= =C2=A0 See Section 18.3 for TTL exception handling for traceroute packets.<= /div>


>
> Large part of this section is a= bout control plane issues and as such should be put in 6833bis.
>
= > What this section should state is that priority and weight are used to= select the RLOC to use.
> Only exception is gleaning where we have o= ne single RLOC and we do not know neither priority nor weight.
>
&= gt; All the other operational discussion goes elsewhere, but not in this do= cument.
>

Agree, I suggest moving it to 6833bis. What to leave= in 6830bis is less obvious, maybe something like (not final, just a couple= of ideas):

The data-plane must follow the state stored in the map-c= ache to encapsulate and decapsulate packets. The map-cache is populated usi= ng a control-plane, such as [6833bis]. ETRs encapsulate packets following t= he Priorities and Weights stored in the map-cache.

Ac= tually we should merge this section with 'Routing Locator Hashing'<= /blockquote>


> We need to cite the threats document because = of the security issues of LSB.

What about this:

Therefore, wh= en a Locator becomes unreachable, the Locator-Status-Bit that corresponds t= o that Locator's position in the list returned by the last Map-Reply wi= ll be set to zero for that particular EID-Prefix. *****There are security r= isks associated to the use of Locator-Status-Bits, we recommend to follow t= he guidelines described in [THREATS]******

><= br>> 12.=C2=A0 Routing Locator Hashing
>
> =C2=A0 When an ET= R provides an EID-to-RLOC mapping in a Map-Reply message to
> =C2=A0 = a requesting ITR, the Locator-Set for the EID-Prefix may contain
> = =C2=A0 different Priority values for each locator address.=C2=A0 When more = than
> =C2=A0 one best Priority Locator exists, the ITR can decide ho= w to load-
> =C2=A0 share traffic against the corresponding Locators.=
>
> The above paragraph should not state where the mapping com= es from, from the data plane perspective it comes from the cache.
>> Also where is weight???????


What about:

When an IT= R encapsulates packets it may found that corresponding map-cache entry cont= ains a Locator-Set with different priorities and weights, the following has= h algorithm may be used by an ITR to select a Locator for a packet destined= to an EID for the EID-to-RLOC mapping:

>
> 13.=C2=A0 Changing the Contents of EID-to-RLOC Mappings
= >
>
> This is a control plane issue, as such it has to go in= 6833bis, with two exception:
> The very first paragraph stetting the= problem, and the versioning subsection, because it is a data-plane mechani= sm.
>
> All of the rest 6833bis
>
> Actually I reme= mber a suggestion about putting operations issues like this in an OAM docum= ent which would be a good idea.
>
>

So you are suggestin= g that the LISP control-plane does not define any mechanism to update EID-t= o-RLOC mappings?

--001a11490486b57fac0561489850-- From nobody Tue Dec 26 20:13:41 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C52612783A for ; Tue, 26 Dec 2017 20:13:40 -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, FREEMAIL_FROM=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 qb8E4yzJMGsa for ; Tue, 26 Dec 2017 20:13:37 -0800 (PST) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E951277BB for ; Tue, 26 Dec 2017 20:13:37 -0800 (PST) Received: by mail-pl0-x22f.google.com with SMTP id 62so17421368pld.7 for ; Tue, 26 Dec 2017 20:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5WmJv8DDZWOfnbkJdkC2jGABmb/tQNNOsWnP8yyOO+E=; b=c22QCj/msmcCQMYuq937PVSUo/bt+hM79bzn3Ras8zuhSBbXtRIn6XWcLJo+kKojAB lYej2EK1vaXUekaZYIwKn904QlJOSjMNqJ/TcQA9oRuHz89i6bQwBj8dqdpKvRUw9C4a fO1uUsLbEDg+gWfy/wiHrZRIjQNUfoj7h303uU00o4/O8zq1H3sL1JFGQalECWw42g+B uXffPTXdArcAzt0ACNuRCCxAPjNmzdq/bcTfWHq+vdgPlwBLR0EBubphczZT6ZLDIHTa CcLRbN7jx/ILBVmVBNe29pgcfNAX7fLAr/vILdrBzjQrNX8BR2ejiYsEUlIot56NcusQ Jwzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5WmJv8DDZWOfnbkJdkC2jGABmb/tQNNOsWnP8yyOO+E=; b=BxCgcarxC3PhYbMpHIZ41vGELPIkLkGubkgFnSLdi4pqleWrIi7xeprShlYKjVCKYn U7uxdJP1m+nKBwPV/+1BOBofVOQeQfHUv4kT0FSixde5VbGcnwdfhFH1jt9kOFGWzHph bmsRR7LXrKRXgleU5UzwLFgMh4MF6r85tG2En8UOZKhK03+O+AwZAxrVOK1gK1d7P8HS YMhYHGEG7OihtRkIV8YtV0hTSp0Ct9W0mWawkMrfb8iE7Dh8fow8n/grRdMo/CiExByk ePZ/OY4XUEUnUCKRxz4LuYPT5DMTwcHoKb0CUs9GpD99zsijZOkcSriE0ce0sFkA2Bqd 5OSQ== X-Gm-Message-State: AKGB3mItdcQ3Zc/3Opa9+tkb5LcKgNiYjRQONwtVlrDgLkDic/+pey6X Usi8ow59C79LnLzW/SC0F/k= X-Google-Smtp-Source: ACJfBouYDgVsG0o7AGwENOgTO/MpvsR1xINlc1xoxbA3Dr+L+wQNlU65A0FxbojYxEW8HW1TLeFtEg== X-Received: by 10.84.128.229 with SMTP id a92mr27740233pla.108.1514348017222; Tue, 26 Dec 2017 20:13:37 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:1ca2:28e8:b31:5b77? ([2603:3024:151c:55f0:1ca2:28e8:b31:5b77]) by smtp.gmail.com with ESMTPSA id t4sm71182412pfj.56.2017.12.26.20.13.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Dec 2017 20:13:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: Date: Tue, 26 Dec 2017 20:13:35 -0800 Cc: Luigi Iannone , "lisp@ietf.org list" , lisp-chairs@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> To: Albert Cabellos X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 04:13:40 -0000 I will comment here before providing a new update and response to = Luigi=E2=80=99s latest email. > On Dec 26, 2017, at 5:48 PM, Albert Cabellos = wrote: >=20 > Hi >=20 > Thanks for the review, please find my comments inline. >=20 > I have removed all the comments for which I **agree**: >=20 > > > > Provider-Assigned (PA) Addresses: PA addresses are an address = block > > assigned to a site by each service provider to which a site > > connects. Typically, each block is a sub-block of a service > > provider Classless Inter-Domain Routing (CIDR) [RFC4632] block = and > > is aggregated into the larger block before being advertised = into > > the global Internet. Traditionally, IP multihoming has been > > implemented by each multihomed site acquiring its own globally > > visible prefix. LISP uses only topologically assigned and > > aggregatable address blocks for RLOCs, eliminating this > > demonstrably non-scalable practice. > > > > Last sentence to be deleted is a relic of scalability discussion. > > > > >=20 > Agreed. I suggest deleting entirely the definitions for both PA and = PI, they are not used throughout the document. Note, we still care about scalability of any underlay, especially the = Internet core, so we should leave this in. Note, we ARE still solving = the scalability problem. I don=E2=80=99t know why any of you would think differently. >=20 > [snip] > > > > > > Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for > > IPv6) value used in the source and destination address fields = of > > the first (most inner) LISP header of a packet. The host = obtains > > a destination EID the same way it obtains a destination address > > today, for example, through a Domain Name System (DNS) = [RFC1034] > > lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. > > The source EID is obtained via existing mechanisms used to set = a > > host's "local" IP address. An EID used on the public Internet > > must have the same properties as any other IP address used in = that > > manner; this means, among other things, that it must be = globally > > unique. An EID is allocated to a host from an EID-Prefix block > > associated with the site where the host is located. An EID can = be > > used by a host to refer to other hosts. Note that EID blocks = MAY > > be assigned in a hierarchical manner, independent of the = network > > topology, to facilitate scaling of the mapping database. In > > addition, an EID block assigned to a site may have site-local > > structure (subnetting) for routing within the site; this = structure > > is not visible to the global routing system. In theory, the = bit > > string that represents an EID for one device can represent an = RLOC > > for a different device. As the architecture is realized, if a > > given bit string is both an RLOC and an EID, it must refer to = the > > same entity in both cases. > > > > > > Is the above sentence really necessary? > > >=20 > Agreed, why not simplify the definitions. They are written from the = =E2=80=98Internet scalability mindset=E2=80=99, why not say that an EID = is an address of the overlay and an RLOC an address of the overlay. This = change may require further changes on the document so I am not 100% sure = if this is a good idea. I have planned to remove the sentence. >=20 > [snip] > > > > Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling > > > > RTR have never been defined. >=20 >=20 > Agree, they are defined in LISP-TE, not sure about the rules here. = They are used in section 17. No, it is used in this document. Others have made a comment that we = referneced it but didn=E2=80=99t define it. RTRs were created BEFORE the = LISP-TE draft was written. >=20 >=20 > > > > The description of the encap/decap operation lacks of clarity = concerning how to deal with > > ECN bits and DSCP . > > > > 1. I think that the text should make explicitly the difference = between DSCP and ECN fields. > > > > 2. How to deal with ECN should be part of the description of the = encap/decap not a paragraph apart. > > This basically means that half of the last paragraph should be a = bullet of the ITR/PITR encapsulation > > and the other half in the ETR/PETR operation. >=20 >=20 > Agreed, what about this (please comment): >=20 > When doing ITR/PITR encapsulation: >=20 > o The outer-header 'Time to Live' field (or 'Hop Limit' field, in = the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' = field. > o The outer-header 'Differentiated Services Code Point' (DSCP) = field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be = copied from the inner-header DSCP field ('Traffic Class' field, in the = case of IPv6) considering the exception listed below. > o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 = of the IPv6 'Traffic Class' field) requires special treatment in order = to avoid discarding indications of congestion [RFC3168]. ITR = encapsulation MUST copy the 2-bit 'ECN' field from the inner header to = the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from = the stripped outer header to the new outer header. >=20 > When doing ETR/PETR decapsulation: >=20 > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in = the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' = field, when the Time to Live value of the outer header is less than the = Time to Live value of the inner header. Failing to perform this check = can cause the Time to Live of the inner header to increment across = encapsulation/decapsulation cycles. This check is also performed when = doing initial encapsulation, when a packet comes to an ITR or PITR = destined for a LISP site. > o The inner-header 'Differentiated Services Code Point' (DSCP) = field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be = copied from the outer-header DSCP field ('Traffic Class' field, in the = case of IPv6) considering the exception listed below. > o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 = of the IPv6 'Traffic Class' field) requires special treatment in order = to avoid discarding indications of congestion [RFC3168]. If the 'ECN' = field contains a congestion indication codepoint (the value is '11', the = Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy = the 2-bit 'ECN' field from the stripped outer header to the surviving = inner header that is used to forward the packet beyond the ETR. These = requirements preserve CE indications when a packet that uses ECN = traverses a LISP tunnel and becomes marked with a CE indication due to = congestion between the tunnel endpoints. >=20 > Note that if an ETR/PETR is also an ITR/PITR and chooses to = re-encapsulate after decapsulating, the net effect of this is that the = new outer header will carry the same Time to Live as the old outer = header minus 1. >=20 > Copying the Time to Live (TTL) serves two purposes: first, it = preserves the distance the host intended the packet to travel; second, = and more importantly, it provides for suppression of looping packets in = the event there is a loop of concatenated tunnels due to = misconfiguration. See Section 18.3 for TTL exception handling for = traceroute packets. I had planned to take Luigi=E2=80=99s suggestion. I did not want to = rewrite this section. It was carefully written by David Black with = consolation from the ECN experts. I do not want to lose this technical = text. > > > > Large part of this section is about control plane issues and as such = should be put in 6833bis. > > > > What this section should state is that priority and weight are used = to select the RLOC to use. > > Only exception is gleaning where we have one single RLOC and we do = not know neither priority nor weight. > > > > All the other operational discussion goes elsewhere, but not in this = document. > > >=20 > Agree, I suggest moving it to 6833bis. What to leave in 6830bis is = less obvious, maybe something like (not final, just a couple of ideas): >=20 > The data-plane must follow the state stored in the map-cache to = encapsulate and decapsulate packets. The map-cache is populated using a = control-plane, such as [6833bis]. ETRs encapsulate packets following the = Priorities and Weights stored in the map-cache. >=20 > Actually we should merge this section with 'Routing Locator Hashing=E2=80= =99 I disagree with you guys. Who do you think punts packets when there is a = map-cache miss? The data-plane. Note there are many users of the = control-plane, an SDN controller, many data-planes, and lig/rig. How = they each use the control-plane is documented in their own documents. And please do not suggest that lig/rig usage of the control plane move = to 6833bis. >=20 >=20 > > We need to cite the threats document because of the security issues = of LSB. >=20 > What about this: >=20 > Therefore, when a Locator becomes unreachable, the Locator-Status-Bit = that corresponds to that Locator's position in the list returned by the = last Map-Reply will be set to zero for that particular EID-Prefix. = *****There are security risks associated to the use of = Locator-Status-Bits, we recommend to follow the guidelines described in = [THREATS]****** This has been fixed in the last revision. >=20 > > > > 12. Routing Locator Hashing > > > > When an ETR provides an EID-to-RLOC mapping in a Map-Reply message = to > > a requesting ITR, the Locator-Set for the EID-Prefix may contain > > different Priority values for each locator address. When more = than > > one best Priority Locator exists, the ITR can decide how to load- > > share traffic against the corresponding Locators. > > > > The above paragraph should not state where the mapping comes from, = from the data plane perspective it comes from the cache. > > > > Also where is weight??????? >=20 >=20 > What about: >=20 > When an ITR encapsulates packets it may found that corresponding = map-cache entry contains a Locator-Set with different priorities and = weights, the following hash algorithm may be used by an ITR to select a = Locator for a packet destined to an EID for the EID-to-RLOC mapping: Was the last revision not sufficient Albert? Dino From nobody Tue Dec 26 21:05:06 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9D3126579 for ; Tue, 26 Dec 2017 21:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.559 X-Spam-Level: X-Spam-Status: No, score=0.559 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 NovjDaOuHezb for ; Tue, 26 Dec 2017 21:04:54 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F31A12426E for ; Tue, 26 Dec 2017 20:54:59 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id k134so18445148pga.3 for ; Tue, 26 Dec 2017 20:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DjRkrMBcuMV+CKEJXR7utCrg/lYkH1aw+4O3Q4SNelk=; b=r8w7xPY58MzU41PnMmCf0Ilw+dV1arQEtUZrNVwccksHTQKY9gOC95Mnfr3vrjwqgp W7LIrkP5415j0t0/bZgL26wqpujC5TZPBaerG9qC21l6K/uJZZYdCBKu2slJcliAutgj S0HznSRafnA3a6V+9XhYlprw1efaly2Bvk/vF97qDQiyzKfqKTeQ6EqYeM6QT2RW8MxT 3Emdi1cTUAkr4ONQHq9UttVXSDlMCNtBDpWhZdJDYGmppLs+RSVhTrZNCBIKBSJNNTZ0 DOy/SIYdn+USlTKchc/FXKz5h1n4sshKlkipl5ps8OL10S0n3vbUj7cIYvxUQxttOxbu UMiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DjRkrMBcuMV+CKEJXR7utCrg/lYkH1aw+4O3Q4SNelk=; b=XqWxx0wRvoNwIaQXonF2hsgBzWtsFOySogzRbtP5sVFIvM8Qf6qXCge2AYIbjUfC9z 2HJeIde4ADFc/Mznc2HIG+llOg6YQIITrmhewT5rQMWkhyVelpQOf/PvoEEMWIQCtfnE 6DED5TqqzUzIcuPK1vqJI8krLjtdl50ewEv8C/Ouq/sSIQTt//Hkt5IF3+1MWog1cjQY nM+/GlHPOtZwAzRtqwIVTZ+qgkimWehZWjdOc5XlulKtc5aSWXAZZkBcf+/S+H3/bAOg js2Iup0t0C9TkcjNCV6v6i+4VB2uxFvgX/y3VtKAEbjI6NdjXgx/ZTcoY7j4M3F0CF8h NaDA== X-Gm-Message-State: AKGB3mKU5UFflPYo5ZVW0pZ/IXnc7AQHHGCwjyuvfo4oQVOcnq8paBB2 YdLw5SXhigsN2SC2g9OcLr8= X-Google-Smtp-Source: ACJfBouxpVUPVPIdiTn6cIrmX4uOPE7xIhqY5hX6Her96FmYrSSF/UE/vEkBVYHitYCUQJaBLazrlg== X-Received: by 10.101.82.196 with SMTP id z4mr20268883pgp.397.1514350498483; Tue, 26 Dec 2017 20:54:58 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:1ca2:28e8:b31:5b77? ([2603:3024:151c:55f0:1ca2:28e8:b31:5b77]) by smtp.gmail.com with ESMTPSA id c123sm17442589pga.8.2017.12.26.20.54.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Dec 2017 20:54:56 -0800 (PST) From: Dino Farinacci Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_FAEFD238-FB88-4833-9DAE-41AB577F17A5" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 26 Dec 2017 20:54:55 -0800 In-Reply-To: <24D2C029-B9F6-4030-9769-3E6FD5A9FC8E@gigix.net> Cc: lisp-chairs@tools.ietf.org, "lisp@ietf.org list" To: Luigi Iannone References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <4D2A0EA8-9096-4E12-99F9-B60910D7122E@gmail.com> <86F3ABEE-5623-45EB-AD8F-342027FA6101@gigix.net> <30D14161-2DE0-4153-879D-01F2EF951C1C@gigix.net> <24D2C029-B9F6-4030-9769-3E6FD5A9FC8E@gigix.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review (PLEASE COMMENTS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 05:05:05 -0000 --Apple-Mail=_FAEFD238-FB88-4833-9DAE-41AB577F17A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 New update included. I have made a lot of your requested changes but = still disagree with many of your points. More justification below. >> It is about not losing important information we decided 10 years ago = to keep >> in because otherwise, we=E2=80=99d have to sprinkle it across = documents. And WE DID decide to NOT create a third document. >=20 > AFAIR there was only consensus in having two documents. > I can live with two documents, but the content has to be clear. At = this stage I do not consider its content clear enough. Well you have to be specific where you think it is not clear. >=20 >>> The document can be shorter and to the point. There are a lot of OAM = information that does not belong to the data-plane. >>=20 >> The OAM information is necessary for the data-plane. And if LISP-GPE, = VXLAN, or any other data plane wants to use their own OAM or use the = LISP control-plane differently, it needs to be documented in their = data-planes. Hence, why this information is there. >=20 > Doesn=E2=80=99t make sense to me. That is not a reason.=20 It is a reason, maybe one you don=E2=80=99t like, but it is a reason. > That information can be available in another document and still be = used by LISP-GPE, VxLAN, or any other data plane. But we decided on only 2 documents. And if we put data-plane usage in a = control-plane document, then we are making 6833bis like 6830. > OK, but a reader will just think the order is random. Can you add text = elaborating the rationale of the order? It doesn=E2=80=99t matter to me. I=E2=80=99ll alphabetize it. > [snip] >>=20 >>>>>=20 >>>>>> Any references to tunnels in this specification refer to >>>>>> dynamic encapsulating tunnels; they are never statically >>>>>> configured. >>>>=20 >>>> Well many have said that LISP tunnels are not like traditional = tunnels. Traditional tunnels are configured and provisioned. Where LISP = tunnels are dynamic and used on demand. I would like the sectiond to = stay. >>>=20 >>> You can move this sentence in the intro or where it make sense to = you. In the Definition of terms is just lost. >>=20 >> I added it as the first definition in the Definition of Terms = section. >=20 > Why not in the introduction or somewhere else?=20 > Why put a sentence that states what LISP is in the definition of term = section?=20 LISP is just not a tunnel. > Such a sentence fits better in the introduction. There is plenty of introductory information and examples of LISP tunnels = in the introduction. >>> You break the operational flow by opening a different point = describing what is what. It makes the overall procedure unclear. >>=20 >> It was put there because someone commented on it. You have to tell me = why you think it breaks flow. We discuss how end-systems send to EIDs. = We say what EIDs are and how they are assigned to hosts. And then we = move to RLOCs. It is pretty plan, simple, and straight-forward. >>=20 >=20 > Those two point would have more emphasis somewhere else.=20 > Where they are now they break the flow and do not provide details. Unless you provide clear text where they should go, I=E2=80=99m not = going to change it. > You can actually put them at the end of section 1 as normal sentences. = We then add a reference to LCAF and state that this document describes = procedures only for EID that are IPv4 or IPv6 addresses. The intro section is taking about broad concepts. Describing EIDs and = RLOC encodings is too early for it. > Incidentally, the end of the 1 section is also a good place to put the = sentences about dynamic tunnelling.=20 I removed Tunneling from the Definition of Terms and added a sentence to = the Intro per your request. >>>>=20 >>>>>> o EID-Prefixes are likely to be hierarchically assigned in a = manner >>>>>> that is optimized for administrative convenience and to = facilitate >>>>>> scaling of the EID-to-RLOC mapping database. The hierarchy is >>>>>> based on an address allocation hierarchy that is independent of >>>>>> the network topology. >>>>>>=20 >>>>> Drop the last bullet it is about scalability. >>>>=20 >>>> Right, but still important to mention. Many of the benefits of LISP = aren=E2=80=99t always obvious. So we have to point them out. >>>=20 >>> Dino, this has to go away. This is NOT the control-plane = advertisement document. This is the LISP control-plane, that=E2=80=99s = all. >>> This was agreed upon at the time of rechartering. >>=20 >> Sorry disagree. You have to mention some control-plane. And not the = definition of it but how its used by this data-plane. >>=20 >=20 > The bullet is just not accurate. Look at the LISP-Beta and you = realise that that statement does not hold. Will remove it. >>>>=20 >>>> We went through this with a lot of people for RFC6830. It took many = months to resolve. I dare not touch this text. >>>=20 >>> You have just to move it up and separate it in two bullets. No = changes needed. >>=20 >> Can you be more specific please. >=20 > In the ITR part we put as last bullet the first part of the original = paragraph: >=20 > - =16=16The Explicit Congestion Notification ('ECN=E2=80=99), = namely bits 6 and 7 of both the IPv4 and IPv6 headers, requires = special treatment > in order to avoid discarding indications of congestion = [RFC3168]. An ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field = from the inner > header to the outer header. Re-encapsulation MUST copy the = 2-bit 'ECN' field from the stripped outer header to the new outer = header. >=20 >=20 > In the ETR part we put as last bullet the second part of the original = paragraph: >=20 > - =16=16The Explicit Congestion Notification ('ECN=E2=80=99), = namely bits 6 and 7 of both the IPv4 and IPv6 headers, requires = special treatment > in order to avoid discarding indications of congestion = [RFC3168]. If the 'ECN' field contains a congestion indication = codepoint (the > value is '11', the Congestion Experienced (CE) codepoint), = then ETR/PETR decapsulation MUST copy the 2-bit 'ECN' field from > the stripped outer header to the surviving inner header that is = used to forward the packet beyond the ETR. =20 >=20 > that=E2=80=99s it=20 I made some minor comments but do not want to undo what David Black = spent effort on and got approval for. And I certainly don=E2=80=99t want = to repeat text as you suggested above. >=20 >>=20 >>>>=20 >>>>>> 9. Routing Locator Selection >>>>>>=20 >>>>> Large part of this section is about control plane issues and as = such should be put in 6833bis. >>>>>=20 >>>>> What this section should state is that priority and weight are = used to select the RLOC to use. >>>>> Only exception is gleaning where we have one single RLOC and we do = not know neither priority nor weight. >>>>>=20 >>>>> All the other operational discussion goes elsewhere, but not in = this document. >>>>=20 >>>> We have already decided (a year ago) not to move this because its = the data-plane that needs to know about locator reachability so it knows = which locators to use. >>>=20 >>> Please check the minutes of past meetings (as I did), the only = unclear point was SMR, everything else was agreed to be moved out.=20 >>=20 >> Please point it out. We have taken every input from the WG. >=20 > https://www.ietf.org/proceedings/96/minutes/minutes-96-lisp All I see in the notes about RLOC-probing is this: - Luigi Iannone says for him RLOC probing/Clock Sweep should be = in Control Plane. - Dino Farinacci says that if people want to use LISP control = plane, seeing RLOC probing in control plane document may look awkward = for people not willing to use the lisp data encapsulation. And we already know this. ;-) That doesn=E2=80=99t tell me there was a decision or concensus. >>> Exactly, it has been decided, hence control plane things go in the = control plane document. (or OAM) >>=20 >> You are trying to draw a hard wall between the data-plane and = control-plane. In the real world that is not how protocols are deployed. >=20 > I am trying to make this a high quality document. I really don=E2=80=99= t want that the document comes back from the IESG because this would = delay publication a lot. > Besides, this is a specification document, independent from the = implementationS. If anybody wants to tighten somehow control and data = planes, they are free to go that way. >=20 > What we need here is to put some text in 6833bis, and replace it here = with the sentence =E2=80=9COther control plane based reachability = mechanism can be found in [6833bis]=E2=80=9D >=20 > In 6833bis we do the opposite, we add the text cut from 6830bis and = add =E2=80=9COther data plane based reachability mechanism can be found = in [6830bis]=E2=80=9D Is this a new comment. Sounds like you are suggesting something new. >>=20 >>>>>=20 >>>>> Actually I remember a suggestion about putting operations issues = like this in an OAM document which would be a good idea.=20 >>>>=20 >>>> I don=E2=80=99t agree. We had already mentioned there is a = control-plane protocol that is described in RFC6833bis and a data-plane = protocol that USEs the control-plane protocol. And the usage should be = here. >>>=20 >>> Not following here. Why should the data-plane control the control = plane? >>=20 >> It is not controlling the control-plane, it is using it. Did my = example of an API not make that clear? >>=20 >=20 > To me was not clear, let me try to reword. > The link between control and data planes is the LISP cache and some = events that may trigger specific operations. > If those operations are data-plane they stay here.=20 > It those operations are control-plane they go in 6833bis. The data-plane does echo-noncing. So that should remain in the = data-plane based on your premise above. I think you=E2=80=99d agree with = that. But RLOC-probes may be suppressed due to echo-noncing showing = reachability. Do you want to put echo-noncing logic in 6833bis if you = move RLOC-probing there. That would not be a good thing. Also, if a map-cache entry doesn=E2=80=99t exist, no RLOC-probes are = sent. So how to do you say that in a control-plane document when there = are a lot of reasons to send RLOC-probes. RLOC-probes are sent to do = lisp-crypto key-exchange, that is a data-plane feature. Please, let=E2=80=99s just keep it where it is and let=E2=80=99s move = on. >=20 >=20 > [snip] >=20 >=20 >>>> Making changes like this to RFC6833 will be huge. >>>=20 >>> You do not have to. see my comment above. >>>=20 >>>> We have the documents separated in the current state right now that = seems to work and seems to be clear. >>>=20 >>> I did not have time to go over 6833bis, but concerning 6830bis the = document is not clear and it is a patchwork of data-plane, = control-plane, and deployment issues. >>>=20 >>> This is not what was agreed upon when we started this effort. >>=20 >> The effort was continuing. And we created options with further study. >=20 > Not sure I am following here. The initial intent was two have two = documents. >=20 >> Both Albert and I did that further study and the drafts reflect the = decisions. There were no WG objections other than from you which we had = thought we convinced. >=20 > Again, IETF 96th. Yes, I proposed at the mic to move the text in = 6833bis, only objection to this was you on the SMR mechanism. > Other then the SMR point we draw a clear line. >=20 >>=20 >>>>>>=20 >>>>>> 19. Security Considerations >>>>>>=20 >>>>>> Security considerations for LISP are discussed in [RFC7833], in >>>>>> addition [I-D.ietf-lisp-sec] provides authentication and = integrity to >>>>>> LISP mappings. >>>>>>=20 >>>>> lisp-sec is control-plane has to be referenced in 6833bis. >>>>=20 >>>> Yes, but if an ITR caches a coarse EID-prefix, then there is a = data-plane redirection attack. >>>>=20 >>>=20 >>> My point is that lisp-sec provides control plane features, so the = sentence does not bring anything to the discussion. >>> Please delete. >=20 > Any comment here? No comment. I think we should reference it. >=20 >>>>>> 21.1. LISP UDP Port Numbers >>>>>>=20 >>>>>> The IANA registry has allocated UDP port numbers 4341 and 4342 = for >>>>>> lisp-data and lisp-control operation, respectively. IANA has = updated >>>>>> the description for UDP ports 4341 and 4342 as follows: >>>>>>=20 >>>>>> lisp-data 4341 udp LISP Data Packets >>>>>> lisp-control 4342 udp LISP Control Packets >>>>>>=20 >>>>> 4342 is control-plane and MUST be requested to IANA in the 6833bis = document. >>>>=20 >>>> We didn=E2=80=99t want to change the registry so we are keeping = this here. Its really no big deal. >>>=20 >>>> Note the data-plane implementation will have to send to the 4342 = socket so its not out of place at all for this to be in this document. >>>>=20 >>>=20 >>> 4342 is control plane not data plane, any further review beyond the = WG will point out this inconsistency. >>=20 >> Sorry a data-plane component uses it >=20 >> . Why split it up when we can have this in one place. >=20 > Can you elaborate better your rationale?=20 The registry already refers to RFC6830. What=E2=80=99s the point of = changing this when it really is a very minor point. Dino --Apple-Mail=_FAEFD238-FB88-4833-9DAE-41AB577F17A5 Content-Disposition: attachment; filename=rfcdiff-rfc6830bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-rfc6830bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-07.txt - = draft-ietf-lisp-rfc6830bis-08.txt=20 =20 =20 =20 =20 =20 =20 = = = = = = = = = = = = =
< draft-ietf-lisp-rfc6830bis-07.txt  =  draft-ietf-lisp-rfc6830bis-08.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Intended status: = Standards Track D. Meyer = Intended status: Standards Track = D. Meyer
Expires: May 15, 2018 = D. Lewis Expires: June 29, 2018 = D. Lewis
= Cisco Systems = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= November = 11, 2017 = December = 26, 2017
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-07 = = draft-ietf-lisp-rfc6830bis-08
=
Abstract = Abstract
=
This document = describes the data-plane protocol for the Locator/ID This document describes the data-plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local map-cache. The = according to EID-to-RLOC mappings stored in a local map-cache.
map-cache is populated by the LISP Control-Plane = protocol
[I-D.ietf-lisp-rfc6833bis].
=
LISP requires = no change to either host protocol stacks or to underlay = LISP requires no change to either host = protocol stacks or to underlay
routers and = offers Traffic Engineering, multihoming and mobility, routers and offers Traffic Engineering, multihoming = and mobility,
among other = features. among other = features.
=
Status of This = Memo Status of This Memo
=
This = Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
provisions of = BCP 78 and BCP 79. provisions of = BCP 78 and BCP 79.
=
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on May 15, = 2018. This Internet-Draft will = expire on June 29, 2018.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 28 =C2=B6 = skipping to change at page 2, line 28 =C2=B6
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . = 4 2. Requirements Notation . . . . = . . . . . . . . . . . . . . . . 4
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 9 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 9
4.1. Packet = Flow Sequence . . . . . . . . . . . . . . . . . . 11 4.1. Packet Flow Sequence . . . . . . . . . . . . = . . . . . . 11
5. LISP = Encapsulation Details . . . . . . . . . . . . . . . . . 13 = 5. LISP Encapsulation Details . . . . . . = . . . . . . . . . . . 13
5.1. LISP = IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 14 5.1. = LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13
5.2. LISP = IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 15 5.2. = LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14
5.3. = Tunnel Header Field Descriptions . . . . . . . . . . . . 16 5.3. = Tunnel Header Field Descriptions . . . . . . . . . . . . 15
6. LISP = EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 6. = LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19
7. Dealing = with Large Encapsulated Packets . . . . . . . . . . . 20 = 7. Dealing with Large Encapsulated Packets = . . . . . . . . . . . 20
7.1. A = Stateless Solution to MTU Handling . . . . . . . . . . 21 7.1. = A Stateless Solution to MTU Handling . . . . . . . . . . 20
7.2. A = Stateful Solution to MTU Handling . . . . . . . . . . . 22 7.2. = A Stateful Solution to MTU Handling . . . . . . . . . . . 21
8. Using = Virtualization and Segmentation with LISP . . . . . . . 22 = 8. Using Virtualization and Segmentation = with LISP . . . . . . . 22
9. Routing = Locator Selection . . . . . . . . . . . . . . . . . . 23 = 9. Routing Locator Selection . . . . . . . = . . . . . . . . . . . 23
10. Routing = Locator Reachability . . . . . . . . . . . . . . . . 24 = 10. Routing Locator Reachability . . . . . = . . . . . . . . . . . 24
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 27
10.2. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 = 10.2. RLOC-Probing Algorithm . . . . . . = . . . . . . . . . . . 28
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 29 = 11. EID Reachability within a LISP Site . . = . . . . . . . . . . . 29
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 30 12. = Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 31 13. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30
13.1. = Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32 13.1. = Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31
13.2. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 = 13.2. Solicit-Map-Request (SMR) . . . . = . . . . . . . . . . . 32
13.3. = Database Map-Versioning . . . . . . . . . . . . . . . . 34 13.3. = Database Map-Versioning . . . . . . . . . . . . . . . . 33
14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 35 14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 34
15. Router = Performance Considerations . . . . . . . . . . . . . . 35 = 15. Router Performance Considerations . . . = . . . . . . . . . . . 35
16. Mobility = Considerations . . . . . . . . . . . . . . . . . . . 36 16. = Mobility Considerations . . . . . . . . . . . . . . . . . . . 35
16.1. Slow = Mobility . . . . . . . . . . . . . . . . . . . . . 36 = 16.1. Slow Mobility . . . . . . . . . . = . . . . . . . . . . . 36
16.2. Fast = Mobility . . . . . . . . . . . . . . . . . . . . . 36 = 16.2. Fast Mobility . . . . . . . . . . = . . . . . . . . . . . 36
16.3. LISP = Mobile Node Mobility . . . . . . . . . . . . . . . 37 = 16.3. LISP Mobile Node Mobility . . . . = . . . . . . . . . . . 37
17. LISP xTR = Placement and Encapsulation Methods . . . . . . . . 38 17. = LISP xTR Placement and Encapsulation Methods . . . . . . . . 37
17.1. = First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 17.1. = First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38
17.2. = Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 = 17.2. Border/Edge xTRs . . . . . . . . . = . . . . . . . . . . . 39
17.3. ISP = Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 17.3. = ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39
17.4. LISP = Functionality with Conventional NATs . . . . . . . 40 = 17.4. LISP Functionality with = Conventional NATs . . . . . . . 40
17.5. = Packets Egressing a LISP Site . . . . . . . . . . . . . 41 17.5. = Packets Egressing a LISP Site . . . . . . . . . . . . . 40
18. = Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18. = Traceroute Considerations . . . . . . . . . . . . . . . . . . 40
18.1. = IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.1. = IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41
18.2. IPv4 = Traceroute . . . . . . . . . . . . . . . . . . . . 42 = 18.2. IPv4 Traceroute . . . . . . . . . = . . . . . . . . . . . 42
18.3. = Traceroute Using Mixed Locators . . . . . . . . . . . . 43 18.3. = Traceroute Using Mixed Locators . . . . . . . . . . . . 42
19. Security = Considerations . . . . . . . . . . . . . . . . . . . 43 = 19. Security Considerations . . . . . . . . = . . . . . . . . . . . 43
20. Network = Management Considerations . . . . . . . . . . . . . . 44 20. = Network Management Considerations . . . . . . . . . . . . . . 43
21. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 44 = 21. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 44
21.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 44 = 21.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 44
22. References = . . . . . . . . . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . = . . . . . . 44
22.1. = Normative References . . . . . . . . . . . . . . . . . . 44 = 22.1. Normative References . . . . . . . = . . . . . . . . . . . 44
22.2. = Informative References . . . . . . . . . . . . . . . . . 47 22.2. = Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 51 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 50
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 51 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 50
B.1. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . = 51
B.2. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52 B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . = 51
B.3. = Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 52 B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . = 51
B.4. = Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 = B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . = 51
B.5. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 53 B.5. Changes to = draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52
B.6. Changes to = draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 B.6. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 52
B.7. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 B.7. Changes to = draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52
B.8. Changes to = draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 B.8. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 B.9. Changes to = draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 52
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
routable = Routing Locators (RLOCs), used to identify network routable Routing Locators (RLOCs), used to identify = network
attachment = points. LISP then defines functions for mapping between = attachment points. LISP then defines = functions for mapping between
the two = namespaces and for encapsulating traffic originated by the two namespaces and for encapsulating traffic = originated by
devices using = non-routable EIDs for transport across a network devices using non-routable EIDs for transport across = a network
= infrastructure that routes and forwards using RLOCs. infrastructure that routes and forwards using RLOCs. = LISP
= encapsulation uses a = dynamic form of tunneling where no static
= provisioning is = required or necessary.
=
LISP is an = overlay protocol that separates control from data-plane, = LISP is an overlay protocol that separates = control from data-plane,
this document = specifies the data-plane, how LISP-capable routers this document specifies the data-plane, how = LISP-capable routers
(Tunnel = Routers) exchange packets by encapsulating them to the (Tunnel Routers) exchange packets by encapsulating = them to the
appropriate = location. Tunnel routers are equipped with a cache, appropriate location. Tunnel routers are equipped = with a cache,
called = map-cache, that contains EID-to-RLOC mappings. The map-cache = called map-cache, that contains EID-to-RLOC = mappings. The map-cache
is populated = using the LISP Control-Plane protocol = is populated using the LISP Control-Plane protocol
= [I-D.ietf-lisp-rfc6833bis]. = [I-D.ietf-lisp-rfc6833bis].
=
LISP does not = require changes to either host protocol stack or to LISP does not require changes to either host protocol = stack or to
=
skipping to = change at = page 4, line 31 =C2=B6 = skipping to change at page 4, line 33 =C2=B6
describes the = LISP architecture. describes the = LISP architecture.
=
2. Requirements = Notation 2. Requirements = Notation
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
document are = to be interpreted as described in [RFC2119]. document are to be interpreted as described in = [RFC2119].
=
3. Definition of = Terms 3. Definition of Terms
=
Provider-Independent (PI) Addresses: PI addresses = are an address Address Family Identifier (AFI): AFI is a term used = to describe an
block assigned from a pool where blocks are not = associated with address = encoding in a packet.= An address family that pertains to
any particular location in the network (e.g., from a particular the data-plane. See = [AFN] and [RFC3232] for details. An = AFI
service provider) and are therefore not topologically = aggregatable value of 0 used in this specification indicates an = unspecified
in the = routing system. encoded address where the = length of the address is 0 octets
= following = the 16-bit AFI value of 0.
=
Provider-Assigned (PA) Addresses: PA addresses are an = address block Anycast Address: Anycast Address is a term used in this document to
assigned to a site by each service provider to = which a site refer to the same = IPv4 or IPv6 address configured and used on
connects. Typically, each block is a = sub-block of a service multiple systems at = the same time. An EID or RLOC can be = an
provider Classless Inter-Domain Routing (CIDR) = [RFC4632] block and anycast address in each of their own address spaces.
is aggregated into the larger block before being advertised = into
the global Internet. Traditionally, IP multihoming has = been
implemented by each multihomed site acquiring its own globally
visible prefix. LISP uses only topologically = assigned and
aggregatable address blocks for RLOCs, eliminating this =
demonstrably non-scalable = practice.
=
Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 Client-side: = Client-side is a term used in this = document to indicate
[RFC8200] address of an Egress Tunnel = Router (ETR). An RLOC is a connection initiation attempt by an = EID. The ITR(s) at the LISP
the output of an EID-to-RLOC mapping lookup. An EID maps to = one site = are the first to get involved in forwarding a packet from = the
or more RLOCs. Typically, = RLOCs are numbered from topologically source EID.
aggregatable blocks that are assigned to = a site at each = point to
which it attaches to the global Internet; where the topology is Data-Probe: A Data-Probe is = a LISP-encapsulated data packet where
defined by the connectivity of provider = networks, RLOCs can be the inner-header destination address equals the = outer-header
thought of as PA = addresses. Multiple RLOCs can be assigned to the destination address = used to trigger a Map-Reply by a = decapsulating
same ETR device or to = multiple ETR devices at a site. ETR. In addition, the original packet is = decapsulated and
= delivered to the = destination host if the destination EID is in the
= EID-Prefix range = configured on the ETR. Otherwise, the packet is
= discarded. A = Data-Probe is used in some of the mapping = database
= designs to = "probe" or request a Map-Reply from an ETR; = in other
= cases, = Map-Requests are used. See each mapping database design
= for details. = When using Data-Probes, by sending Map-Requests on
= the underlying = routing system, EID-Prefixes must be advertised.
= =
= Egress Tunnel Router (ETR): An ETR is = a router that accepts an IP
= packet where the = destination address in the "outer" IP header is
= one of its = own RLOCs. The router strips the "outer" = header and
= forwards the = packet based on the next IP header found. In
= general, an ETR = receives LISP-encapsulated IP packets from the
= Internet on one = side and sends decapsulated IP packets to site
= end-systems on = the other side. ETR functionality does not have to
= be limited = to a router device. A server host can be = the endpoint
= of a LISP tunnel = as well.
=
= EID-to-RLOC = Database: The EID-to-RLOC Database is a global
= distributed = database that contains all known EID-Prefix-to-RLOC
= mappings. Each = potential ETR typically contains a small piece of
= the database: the = EID-to-RLOC mappings for the EID-Prefixes
= "behind" the = router. These map to one of the router's own
= globally visible = IP addresses. Note that there MAY be transient
= conditions when = the EID-Prefix for the site and Locator-Set for
= each EID-Prefix = may not be the same on all ETRs. This has = no
= negative = implications, since a partial set of Locators can be
= used.
=
= EID-to-RLOC = Map-Cache: The EID-to-RLOC map-cache is generally
= short-lived, = on-demand table in an ITR that stores, tracks, and is
= responsible for = timing out and otherwise validating EID-to-RLOC
= mappings. This = cache is distinct from the full "database" of EID-
= to-RLOC mappings; = it is dynamic, local to the ITR(s), and
= relatively small, = while the database is distributed, relatively
= static, and much = more global in scope.
=
= EID-Prefix: An = EID-Prefix is a power-of-two block of EIDs that are
= allocated to a = site by an address allocation authority. EID-
= Prefixes are = associated with a set of RLOC addresses. EID-Prefix
= = allocations can be broken up into smaller = blocks when an RLOC set
= is to = be associated with the larger EID-Prefix block.
=
= End-System: An = end-system is an IPv4 or IPv6 device that = originates
= packets with a = single IPv4 or IPv6 header. The = end-system
= supplies an EID = value for the destination address field of the IP
= header when = communicating globally (i.e., outside of its routing
= domain). An = end-system can be a host computer, a = switch or router
= device, or any = network appliance.
=
Endpoint ID = (EID): An EID is a 32-bit (for IPv4) or 128-bit (for Endpoint ID (EID): An EID is a 32-bit (for IPv4) or = 128-bit (for
IPv6) value = used in the source and destination address fields of IPv6) value used in the source and destination = address fields of
the first = (most inner) LISP header of a packet. The host obtains = the first (most inner) LISP header of a = packet. The host obtains
a = destination EID the same way it obtains a destination address = a destination EID the same way it obtains = a destination address
today, for = example, through a Domain Name System (DNS) [RFC1034] today, for example, through a Domain Name System = (DNS) [RFC1034]
lookup or = Session Initiation Protocol (SIP) [RFC3261] exchange. lookup or Session Initiation Protocol (SIP) = [RFC3261] exchange.
The source = EID is obtained via existing mechanisms used to set a The source EID is obtained via existing mechanisms = used to set a
host's = "local" IP address. An EID used on the public Internet = host's "local" IP address. An EID used = on the public Internet
must have = the same properties as any other IP address used in that = must have the same properties as any = other IP address used in that
manner; = this means, among other things, that it must be globally = manner; this means, among other things, = that it must be globally
unique. An = EID is allocated to a host from an EID-Prefix block unique. An EID is allocated to a host from an = EID-Prefix block
associated = with the site where the host is located. An EID can be = associated with the site where the host = is located. An EID can be
used by a = host to refer to other hosts. Note that EID blocks MAY = used by a host to refer to other hosts. = Note that EID blocks MAY
be assigned = in a hierarchical manner, independent of the network be assigned in a hierarchical manner, independent = of the network
topology, = to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping = database. In
addition, = an EID block assigned to a site may have = site-local addition, an EID = block assigned to a site MAY have = site-local
structure = (subnetting) for routing within the site; this structure = structure (subnetting) for routing within = the site; this structure
is not = visible to the global routing system. In theory, the bit = is not visible to the global routing = system. In theory, the bit
string that = represents an EID for one device can represent an RLOC string that represents an EID for one device can = represent an RLOC
for a = different device. As the architecture is = realized, if a for a = different device. When used in discussions with other
given bit string is both an RLOC and an EID, it = must refer to the
same entity in both cases. When used in = discussions with other
Locator/ID = separation proposals, a LISP EID will be called an Locator/ID separation proposals, a LISP EID will = be called an
"LEID". = Throughout this document, any references to "EID" refer = "LEID". Throughout this document, any = references to "EID" refer
to an = LEID. to an LEID.
=
EID-Prefix: An EID-Prefix is a power-of-two block of = EIDs that are
allocated to a site by an address allocation = authority. EID-
Prefixes are associated with a set of RLOC = addresses that make up
a "database mapping". EID-Prefix allocations can = be broken up
into smaller blocks when an RLOC set is to be = associated with the
larger EID-Prefix block. A globally routed = address block (whether
PI or PA) is not inherently an EID-Prefix. A = globally routed
address block MAY be used by its assignee as an = EID block. The
converse is not supported. That is, a site that = receives an
explicitly allocated EID-Prefix may not use that = EID-Prefix as a
globally routed prefix. This would require = coordination and
cooperation with the entities managing the = mapping infrastructure.
Once this has been done, that block could be = removed from the
globally routed IP system, if other suitable = transition and access
mechanisms are in place. Discussion of such = transition and access
mechanisms can be found in [RFC6832] and = [RFC7215].
End-system: An end-system is an IPv4 or IPv6 = device that originates
packets with a single IPv4 or IPv6 header. The = end-system
supplies an EID value for the destination address = field of the IP
header when communicating globally (i.e., outside = of its routing
domain). An end-system can be a host computer, a = switch or router
device, or any network appliance. =
= =
Ingress Tunnel = Router (ITR): An ITR is a router that resides in a Ingress Tunnel Router (ITR): An ITR is a router = that resides in a
LISP site. = Packets sent by sources inside of the LISP site to LISP site. Packets sent by sources inside of the = LISP site to
= destinations outside of the site are candidates for = encapsulation destinations = outside of the site are candidates for encapsulation
by the ITR. = The ITR treats the IP destination address as an EID by the ITR. The ITR treats the IP destination = address as an EID
and = performs an EID-to-RLOC mapping lookup. The router then = and performs an EID-to-RLOC mapping = lookup. The router then
prepends an = "outer" IP header with one of its routable RLOCs (in prepends an "outer" IP header with one of its = routable RLOCs (in
the RLOC = space) in the source address field and the result of the = the RLOC space) in the source address = field and the result of the
mapping = lookup in the destination address field. Note that this = mapping lookup in the destination address = field. Note that this
destination = RLOC MAY be an intermediate, proxy device that has destination RLOC MAY be an intermediate, proxy = device that has
better = knowledge of the EID-to-RLOC mapping closer to the better knowledge of the EID-to-RLOC mapping closer = to the
=
skipping to = change at = page 6, line 33 =C2=B6 = skipping to change at page 7, line 5 =C2=B6
end-systems = on one side and sends LISP-encapsulated IP packets end-systems on one side and sends = LISP-encapsulated IP packets
toward the = Internet on the other side. = toward the Internet on the other side.
=
= Specifically, when a service provider prepends a LISP header = for Specifically, when a service = provider prepends a LISP header for
Traffic = Engineering purposes, the router that does this is also = Traffic Engineering purposes, the router = that does this is also
regarded as = an ITR. The outer RLOC the ISP ITR uses can be based regarded as an ITR. The outer RLOC the ISP ITR = uses can be based
on the = outer destination address (the originating ITR's supplied = on the outer destination address (the = originating ITR's supplied
RLOC) or = the inner destination address (the originating host's RLOC) or the inner destination address (the = originating host's
supplied = EID). supplied EID).
=
TE-ITR: A TE-ITR is an ITR that is deployed in a = service provider LISP Header: LISP header is a term used in this = document to refer
network that prepends an additional LISP = header for Traffic to the outer IPv4 or IPv6 = header, a UDP header, and a LISP-
Engineering purposes. specific 8-octet = header that follow the UDP header and that = an ITR
prepends or an ETR strips.
Egress Tunnel Router (ETR): An ETR is a = router that accepts an IP =
packet where the destination address in = the "outer" IP header is
one of its own RLOCs. The router strips the = "outer" header and
forwards the packet based on the next IP header = found. In
general, an ETR receives LISP-encapsulated IP = packets from the
Internet on one side and sends decapsulated IP = packets to site
end-systems on the other side. ETR functionality = does not have to
be limited to a router = device. A server host can be the endpoint
of a LISP tunnel as = well.
TE-ETR: A TE-ETR is an ETR that is deployed = in a service provider =
network that strips an outer LISP header = for Traffic Engineering
purposes.
xTR: An xTR is a reference to an ITR or ETR when = direction of data
flow is not part of the context description. = "xTR" refers to the
router that is the = tunnel endpoint and is used synonymously with
the term "Tunnel Router". For example, "An xTR = can be located at
the Customer Edge (CE) router" indicates both ITR = and ETR
functionality at the CE router. =
Re-encapsulating Tunneling in RTRs: = Re-encapsulating Tunneling
occurs when an RTR = (Re-encapsulating Tunnel Router) acts like an
ETR to remove a LISP header, then acts as an ITR to prepend = a new
LISP header. Doing this allows a packet to be = re-routed by the
RTR without adding the overhead of additional = tunnel headers. Any
references to tunnels in this specification refer = to dynamic
encapsulating tunnels; they are never statically = configured. When
using multiple mapping database systems, care = must be taken to not
create re-encapsulation loops through = misconfiguration.
=
LISP Router: = A LISP router is a router that performs the functions LISP Router: A LISP router is a router that = performs the functions
of any or = all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), of any or all of the following: ITR, ETR, RTR, = Proxy-ITR (PITR),
or = Proxy-ETR (PETR). or Proxy-ETR = (PETR).
=
EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is = generally LISP Site: LISP site is a set of routers = in an edge network that are
short-lived, on-demand table in an ITR that = stores, tracks, and is = under a single technical administration. LISP = routers that reside
responsible for timing out and otherwise = validating EID-to-RLOC = in the edge network are the demarcation points to separate the
mappings. This cache is distinct from the full = "database" of EID- edge network from the core = network.
to-RLOC mappings; it is dynamic, local to the = ITR(s), and
relatively small, while the database is = distributed, relatively
static, and much more global in = scope.
EID-to-RLOC Database: The EID-to-RLOC Database is = a global
distributed database that contains all known = EID-Prefix-to-RLOC
mappings. Each potential ETR typically contains = a small piece of
the database: the EID-to-RLOC mappings for the = EID-Prefixes
"behind" the router. These map to one of the = router's own
globally visible IP addresses. Note that there = MAY be transient
conditions when the EID-Prefix for the = site and Locator-Set for
each EID-Prefix may not be the same on all ETRs. = This has no
negative implications, since a partial set of Locators = can be
used.
Recursive Tunneling: Recursive Tunneling occurs = when a packet has
more than one LISP IP header. Additional layers = of tunneling MAY
be employed to implement Traffic Engineering or = other re-routing
as needed. When this is done, an additional "outer" LISP header
is added, and the original RLOCs are preserved in the "inner"
header. Any references to tunnels in this = specification refer to
dynamic encapsulating tunnels; they are = never statically
configured.
LISP Header: LISP header is a term used in this = document to refer
to the = outer IPv4 or IPv6 header, a UDP header, and a = LISP-
specific 8-octet header that follow the = UDP header and that an ITR =
prepends or an ETR strips. =
=
Address Family Identifier (AFI): AFI is a term = used to describe an Locator-Status-Bits (LSBs): = Locator-Status-Bits are present in the
address encoding in a packet. An address family that pertains = to LISP = header. They are used by ITRs to = inform ETRs about the up/
the data-plane. See [AFN] and [RFC3232] for details. An AFI down status of all ETRs at = the local site. These bits are used as
value of 0 used in = this specification indicates an unspecified a hint to convey up/down router status and not path reachability
encoded address where the length of the = address is 0 octets status. The LSBs can be = verified by use of one of the Locator
following the 16-bit AFI value of = 0. = reachability algorithms described in Section 10.
=
Negative = Mapping Entry: A negative mapping entry, also known as a = Negative Mapping Entry: A negative mapping = entry, also known as a
negative = cache entry, is an EID-to-RLOC entry where an EID-Prefix = negative cache entry, is an EID-to-RLOC = entry where an EID-Prefix
is = advertised or stored with no RLOCs. That is, the Locator-Set = is advertised or stored with no RLOCs. = That is, the Locator-Set
for the = EID-to-RLOC entry is empty or has an encoded Locator count = for the EID-to-RLOC entry is empty or has = an encoded Locator count
of 0. This = type of entry could be used to describe a prefix from of 0. This type of entry could be used to = describe a prefix from
a non-LISP = site, which is explicitly not in the mapping database. a non-LISP site, which is explicitly not in the = mapping database.
There are a = set of well-defined actions that are encoded in a There are a set of well-defined actions that are = encoded in a
Negative = Map-Reply. Negative = Map-Reply.
=
Data-Probe: A Data-Probe is a LISP-encapsulated data = packet where Provider-Assigned (PA) Addresses: PA addresses are = an address block
the inner-header destination address equals the = outer-header assigned to a site by each service = provider to which a site
destination address used to trigger a = Map-Reply by a = decapsulating connects. Typically, each block is a sub-block of a service
ETR. In addition, the original packet is = decapsulated and provider Classless Inter-Domain Routing (CIDR) = [RFC4632] block and
delivered to the = destination host if the destination EID is in the = is aggregated = into the larger block before being = advertised into
EID-Prefix range configured on the ETR. = Otherwise, the packet is the global Internet. Traditionally, IP = multihoming has been
discarded. A Data-Probe is used in some of the = mapping database implemented by each = multihomed site acquiring its own globally
designs to "probe" or request a Map-Reply from an ETR; in other = visible = prefix.
cases, Map-Requests are used. See each mapping = database design
for details. When using Data-Probes, by sending = Map-Requests on
the underlying routing system, EID-Prefixes must = be advertised.
However, this is discouraged if the core = is to scale by having =
less EID-Prefixes stored in the core router's = routing tables.
=
Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. = A Provider-Independent (PI) Addresses: PI addresses are = an address
PITR acts like an ITR but does so on behalf of = non-LISP sites that block assigned from a pool where blocks are not = associated with
send packets to destinations at LISP = sites. = any particular location in the network (e.g., from a = particular
= service = provider) and are therefore not = topologically aggregatable
= in the routing = system.
=
Proxy-ETR = (PETR): A PETR is defined and described in [RFC6832]. A = Proxy-ETR (PETR): A PETR is defined and = described in [RFC6832]. A
PETR acts = like an ETR but does so on behalf of LISP sites that PETR acts like an ETR but does so on behalf of = LISP sites that
send = packets to destinations at non-LISP sites. send packets to destinations at non-LISP = sites.
=
Route-returnability: Route-returnability is an = assumption that the Proxy-ITR (PITR): A PITR is defined and described in = [RFC6832]. A
= PITR acts like an = ITR but does so on behalf of non-LISP sites that
= send packets to = destinations at LISP sites.
=
= Recursive Tunneling: = Recursive Tunneling occurs when a packet has
= more than one = LISP IP header. Additional layers of tunneling MAY
= be employed to = implement Traffic Engineering or other re-routing
= as needed. When = this is done, an additional "outer" LISP header
= is added, and the = original RLOCs are preserved in the "inner"
= = header.
=
= Re-Encapsulating = Tunneling Router (RTR): An RTR acts like an ETR to
= remove a LISP = header, then acts as an ITR to prepend a new LISP
= header. This is = known as Re-encapsulating Tunneling. Doing this
= allows a packet = to be re-routed by the RTR without adding the
= overhead of = additional tunnel headers. Any references to tunnels
= in this = specification refer to dynamic encapsulating tunnels; = they
= are never = statically configured. When using multiple mapping
= database systems, = care must be taken to not create re-
= encapsulation = loops through misconfiguration.
=
= = Route-Returnability: Route-returnability is an assumption that = the
underlying = routing system will deliver packets to the destination. = underlying routing system will deliver = packets to the destination.
When = combined with a nonce that is provided by a sender and When combined with a nonce that is provided by a = sender and
returned by = a receiver, this limits off-path data insertion. A returned by a receiver, this limits off-path data = insertion. A
= route-returnability check is verified when a message is sent = with route-returnability check = is verified when a message is sent with
a nonce, = another message is returned with the same nonce, and the = a nonce, another message is returned with = the same nonce, and the
destination = of the original message appears as the source of the destination of the original message appears as the = source of the
returned = message. returned = message.
=
LISP site: LISP site is a = set of routers in an edge network that are Routing Locator (RLOC): An = RLOC is an IPv4 [RFC0791] or = IPv6
under a single technical administration. LISP = routers that reside = [RFC8200] = address of an Egress Tunnel Router (ETR). = An RLOC is
in the edge network are the demarcation points to separate the the output of an = EID-to-RLOC mapping lookup. An EID maps to one
edge network from the core = network. = or more RLOCs. Typically, RLOCs are numbered from aggregatable
blocks that are assigned to a site at each point to which = it
Client-side: Client-side is a term used in this document to = indicate = attaches to the global Internet; = where the topology is defined by
a connection initiation attempt by an EID. The ITR(s) at the LISP = the connectivity of provider networks. Multiple = RLOCs can be
site are the first to get involved in = obtaining database Map-Cache assigned to the = same ETR device or to multiple ETR devices at a
entries by sending Map-Request = messages. site.
=
Server-side: = Server-side is a term used in this document to indicate = Server-side: Server-side is a term used in = this document to indicate
that a = connection initiation attempt is being accepted for a that a connection initiation attempt is being = accepted for a
= destination EID. The ETR(s) at the destination = LISP site may be = destination EID.
the first to send Map-Replies to the source site = initiating the
connection. The ETR(s) at this destination site = can obtain
mappings by gleaning information from = Map-Requests, Data-Probes,
or encapsulated packets.
=
Locator-Status-Bits (LSBs): Locator-Status-Bits are = present in the TE-ETR: A TE-ETR is an ETR = that is deployed in a service = provider
LISP header. They are used by ITRs to inform = ETRs about the up/ network that strips an outer LISP header for = Traffic Engineering
down status of all ETRs at the local site. These = bits are used as purposes.
a hint to convey up/down router status and not path = reachability
status. The LSBs can be verified by use of one = of the Locator
reachability algorithms described in Section = 10.
=
Anycast Address: Anycast Address is a term used in this = document to TE-ITR: A TE-ITR is an = ITR that is deployed in a service = provider
refer to the same IPv4 or = IPv6 address configured and used on network that prepends an additional LISP header = for Traffic
multiple systems at the same time. An EID or RLOC can be an Engineering purposes.
anycast address in each of their own address = spaces.
= xTR: An xTR is a = reference to an ITR or ETR when direction = of data
= flow is not part = of the context description. "xTR" refers to the
= router that is = the tunnel endpoint and is used = synonymously with
= the term "Tunnel = Router". For example, "An xTR can be located at
= the Customer Edge = (CE) router" indicates both ITR and ETR
= functionality at = the CE router.
=
4. Basic = Overview 4. Basic Overview
=
One key = concept of LISP is that end-systems operate the same way they = One key concept of LISP is that end-systems = operate the same way they
do today. The = IP addresses that hosts use for tracking sockets and do today. The IP addresses that hosts use for = tracking sockets and
connections, = and for sending and receiving packets, do not change. connections, and for sending and receiving packets, = do not change.
In LISP = terminology, these IP addresses are called Endpoint In LISP terminology, these IP addresses are called = Endpoint
Identifiers = (EIDs). Identifiers (EIDs).
=
Routers = continue to forward packets based on IP destination Routers continue to forward packets based on IP = destination
=
skipping to = change at = page 10, line 38 =C2=B6 = skipping to change at page 10, line = 15 =C2=B6
o Other types = of EID are supported by LISP, see [RFC8060] for o Other types of EID are supported by LISP, see = [RFC8060] for
further = information. further = information.
=
o LISP = routers mostly deal with Routing Locator addresses. See = o LISP routers mostly deal with Routing = Locator addresses. See
details in = Section 4.1 to clarify what is meant by "mostly". details in Section 4.1 to clarify what is meant by = "mostly".
=
o RLOCs are = always IP addresses assigned to routers, preferably o RLOCs are always IP addresses assigned to routers, = preferably
= topologically oriented addresses from provider CIDR (Classless = topologically oriented addresses from = provider CIDR (Classless
= Inter-Domain Routing) blocks. = Inter-Domain Routing) blocks.
=
o When a = router originates packets, it may use as a = source address o When a router = originates packets, it MAY use as a source = address
either an = EID or RLOC. When acting as a host (e.g., when either an EID or RLOC. When acting as a host = (e.g., when
terminating = a transport session such as Secure SHell (SSH), terminating a transport session such as Secure = SHell (SSH),
TELNET, = or the Simple Network Management Protocol (SNMP)), it may = TELNET, or the Simple Network Management Protocol (SNMP)), it MAY
use an EID = that is explicitly assigned for that purpose. An EID use an EID that is explicitly assigned for that = purpose. An EID
that = identifies the router as a host MUST NOT be used as an RLOC; = that identifies the router as a host MUST = NOT be used as an RLOC;
an EID is = only routable within the scope of a site. A typical BGP = an EID is only routable within the scope = of a site. A typical BGP
= configuration might demonstrate this "hybrid" EID/RLOC usage = where configuration might = demonstrate this "hybrid" EID/RLOC usage where
a router = could use its "host-like" EID to terminate iBGP sessions = a router could use its "host-like" EID to = terminate iBGP sessions
to other = routers in a site while at the same time using RLOCs to = to other routers in a site while at the = same time using RLOCs to
terminate = eBGP sessions to routers outside the site. terminate eBGP sessions to routers outside the = site.
=
o Packets = with EIDs in them are not expected to be delivered end-to- = o Packets with EIDs in them are not = expected to be delivered end-to-
end in the = absence of an EID-to-RLOC mapping operation. They are end in the absence of an EID-to-RLOC mapping = operation. They are
expected to = be used locally for intra-site communication or to be expected to be used locally for intra-site = communication or to be
= encapsulated for inter-site communication. encapsulated for inter-site communication.
=
o = EID-Prefixes are likely to be hierarchically assigned in a = manner o EID-Prefixes are likely = to be hierarchically assigned in a manner
that is = optimized for administrative convenience and to facilitate = that is optimized for administrative = convenience and to facilitate
scaling = of the EID-to-RLOC mapping database. The = hierarchy is scaling of = the EID-to-RLOC mapping database.
based on an address allocation hierarchy that is = independent of
the network topology.
=
o EIDs = may also be structured (subnetted) in a = manner suitable for o EIDs MAY also be structured (subnetted) in a manner = suitable for
local = routing within an Autonomous System (AS). local routing within an Autonomous System = (AS).
=
An additional = LISP header MAY be prepended to packets by a TE-ITR An additional LISP header MAY be prepended to packets = by a TE-ITR
when = re-routing of the path for a packet is desired. A potential = when re-routing of the path for a packet is = desired. A potential
use-case for = this would be an ISP router that needs to perform use-case for this would be an ISP router that needs = to perform
Traffic = Engineering for packets flowing through its network. In such = Traffic Engineering for packets flowing = through its network. In such
a situation, = termed "Recursive Tunneling", an ISP transit acts as an = a situation, termed "Recursive Tunneling", = an ISP transit acts as an
additional = ITR, and the RLOC it uses for the new prepended header additional ITR, and the RLOC it uses for the new = prepended header
would be = either a TE-ETR within the ISP (along an intra-ISP traffic = would be either a TE-ETR within the ISP = (along an intra-ISP traffic
engineered = path) or a TE-ETR within another ISP (an inter-ISP traffic = engineered path) or a TE-ETR within another = ISP (an inter-ISP traffic
=
skipping to = change at = page 12, line 17 =C2=B6 = skipping to change at page 11, line = 37 =C2=B6
was not = using LISP. was not using = LISP.
=
o Each site = is multihomed, so each Tunnel Router has an address o Each site is multihomed, so each Tunnel Router has = an address
(RLOC) = assigned from the service provider address block for each = (RLOC) assigned from the service provider = address block for each
provider to = which that particular Tunnel Router is attached. provider to which that particular Tunnel Router is = attached.
=
o The ITR(s) = and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to = the source and
= destination, respectively, but the source and destination can = be destination, respectively, = but the source and destination can be
located = anywhere in the LISP site. = located anywhere in the LISP site.
=
o Map-Requests are sent to the mapping database system by = using the o A Map-Request = is sent for an external destination when the
LISP control-plane protocol documented = in destination is not = found in the forwarding table or matches a
[I-D.ietf-lisp-rfc6833bis]. A Map-Request = is sent for an external default = route. Map-Requests are sent to the mapping = database
= destination when the destination is not found in the forwarding = system by using = the LISP control-plane protocol documented in
table or = matches a default route. [I-D.ietf-lisp-rfc6833bis].
=
o Map-Replies = are sent on the underlying routing system topology o Map-Replies are sent on the underlying routing = system topology
using the = [I-D.ietf-lisp-rfc6833bis] control-plane protocol. using the [I-D.ietf-lisp-rfc6833bis] control-plane = protocol.
=
Client = host1.abc.example.com wants to communicate with server Client host1.abc.example.com wants to communicate = with server
= host2.xyz.example.com: = host2.xyz.example.com:
=
1. = host1.abc.example.com wants to open a TCP connection to = 1. host1.abc.example.com wants to open a = TCP connection to
= host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup = on
= host2.xyz.example.com. An A/AAAA record is returned. This = host2.xyz.example.com. An A/AAAA record = is returned. This
=
skipping to = change at = page 13, line 35 =C2=B6 = skipping to change at page 13, line 8 =C2=B6
of the = addresses, strips the LISP header, and forwards packets to = of the addresses, strips the LISP = header, and forwards packets to
the = attached destination host. the = attached destination host.
=
9. In order = to defer the need for a mapping lookup in the reverse 9. In order to defer the need for a mapping lookup = in the reverse
direction, = an ETR can OPTIONALLY create a cache entry that maps direction, an ETR can OPTIONALLY create a cache = entry that maps
the source = EID (inner-header source IP address) to the source the source EID (inner-header source IP address) = to the source
RLOC = (outer-header source IP address) in a received LISP packet. = RLOC (outer-header source IP address) in = a received LISP packet.
Such a = cache entry is termed a "gleaned" mapping and only Such a cache entry is termed a "gleaned" mapping = and only
contains a = single RLOC for the EID in question. More complete contains a single RLOC for the EID in question. = More complete
= information about additional RLOCs SHOULD be verified by = sending information about = additional RLOCs SHOULD be verified by sending
a LISP = Map-Request for that EID. Both the ITR and the ETR may a = LISP Map-Request for that EID. Both the ITR and the ETR MAY
also = influence the decision the other makes in selecting an RLOC. = also influence the decision the other = makes in selecting an RLOC.
=
5. LISP = Encapsulation Details 5. LISP = Encapsulation Details
=
Since = additional tunnel headers are prepended, the packet becomes = Since additional tunnel headers are = prepended, the packet becomes
larger and can = exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed = from the ITR to
the ETR. It = is RECOMMENDED in IPv4 that packets do not get the ETR. It is RECOMMENDED in IPv4 that packets do = not get
fragmented as = they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. = Instead, the packet
is dropped and = an ICMP Unreachable/Fragmentation-Needed message is is dropped and an ICMP = Unreachable/Fragmentation-Needed message is
returned to = the source. returned to the = source.
=
This specification RECOMMENDS that = implementations provide support = In the case when fragmentation is needed, = this specification
for one of = the proposed fragmentation and reassembly schemes. Two = RECOMMENDS that implementations provide = support for one of the
existing = schemes are detailed in Section 7. = proposed fragmentation and reassembly schemes. Two existing = schemes
= are detailed in Section 7.
=
Since IPv4 or = IPv6 addresses can be either EIDs or RLOCs, the LISP Since IPv4 or IPv6 addresses can be either EIDs or = RLOCs, the LISP
architecture = supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs = (where the inner
header is in = IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header = is in IPv6
packet format) = or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where = the inner header
is in IPv6 = packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in = IPv4 packet
format). The = next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet = formats for the
homogeneous = case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but = all 4
combinations = MUST be supported. Additional types of EIDs are defined = combinations MUST be supported. Additional = types of EIDs are defined
in = [RFC8060]. in [RFC8060].
=
skipping to = change at = page 14, line 16 =C2=B6 = skipping to change at page 14, line 4 =C2=B6
architecture = supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs = (where the inner
header is in = IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header = is in IPv6
packet format) = or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where = the inner header
is in IPv6 = packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in = IPv4 packet
format). The = next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet = formats for the
homogeneous = case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but = all 4
combinations = MUST be supported. Additional types of EIDs are defined = combinations MUST be supported. Additional = types of EIDs are defined
in = [RFC8060]. in [RFC8060].
=
5.1. LISP = IPv4-in-IPv4 Header Format 5.1. LISP = IPv4-in-IPv4 Header Format
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| IHL |Type of Service| = Total Length | / = |Version| IHL | DSCP |ECN| = Total Length |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Identification |Flags| Fragment Offset | = | | Identification |Flags| = Fragment Offset |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to = Live | Protocol =3D 17 | Header Checksum | = OH | Time to Live | Protocol =3D 17 | = Header Checksum |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Source Routing Locator | | | Source Routing Locator = |
\ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = Destination Routing Locator | \ | Destination Routing Locator = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port =3D xxxx | Dest Port =3D 4341 | = / | Source Port =3D xxxx | = Dest Port =3D 4341 |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L = |N|L|E|V|I|R|K|K| Nonce/Map-Version = | L |N|L|E|V|I|R|K|K| = Nonce/Map-Version |
I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | = Instance ID/Locator-Status-Bits | S / | Instance ID/Locator-Status-Bits = |
P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| IHL |Type of Service| = Total Length | / = |Version| IHL | DSCP |ECN| = Total Length |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Identification |Flags| Fragment Offset | = | | Identification |Flags| = Fragment Offset |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to = Live | Protocol | Header Checksum | IH | Time to Live | Protocol | Header = Checksum |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Source EID | | | Source EID = |
\ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = Destination EID | \ | Destination EID = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
IHL =3D = IP-Header-Length IHL =3D = IP-Header-Length
=
5.2. LISP = IPv6-in-IPv6 Header Format 5.2. LISP = IPv6-in-IPv6 Header Format
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| Traffic Class | Flow = Label | / = |Version| DSCP |ECN| Flow = Label |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Payload Length | Next Header=3D17| Hop Limit | = | | Payload Length | Next = Header=3D17| Hop Limit |
v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
O + = + O + = +
u | = | u | = |
t + = Source Routing Locator + t + Source Routing Locator = +
e | = | e | = |
r + = + r + = +
| = | | = |
=
skipping to = change at = page 15, line 38 =C2=B6 = skipping to change at page 15, line = 23 =C2=B6
\ | = | \ | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port =3D xxxx | Dest Port =3D 4341 | = / | Source Port =3D xxxx | = Dest Port =3D 4341 |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L = |N|L|E|V|I|R|K|K| Nonce/Map-Version = | L |N|L|E|V|I|R|K|K| = Nonce/Map-Version |
I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | = Instance ID/Locator-Status-Bits | S / | Instance ID/Locator-Status-Bits = |
P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| Traffic Class | Flow = Label | / = |Version| DSCP |ECN| Flow = Label |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Payload Length | Next Header | Hop Limit | = / | Payload Length | Next = Header | Hop Limit |
v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
I + = + I + = +
n | = | n | = |
n + = Source EID + n + Source EID = +
e | = | e | = |
r + = + r + = +
| = | | = |
=
skipping = to change at page 16, line = 4 =C2=B6 = skipping to change at page 15, line = 38 =C2=B6
I + = + I + = +
n | = | n | = |
n + = Source EID + n + Source EID = +
e | = | e | = |
r + = + r + = +
| = | | = |
H = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= H = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | = | d | = |
r + = + r + = +
| = | | = |
=
^ + = Destination EID + ^ + Destination EID = +
\ | = | \ | = |
\ + = + \ + = +
\ | = | \ | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
5.3. Tunnel = Header Field Descriptions 5.3. Tunnel = Header Field Descriptions
=
Inner Header = (IH): The inner header is the header on the datagram Inner Header (IH): The inner header is = the header on the
received = from the originating host. The source and = destination IP datagram = received from the originating host [RFC0791] = [RFC8200]
addresses = are EIDs [RFC0791] [RFC8200]. = [RFC2474]. = The source and destination IP addresses are EIDs.
=
Outer Header: = (OH) The outer header is a new header prepended by an Outer Header: (OH) The outer header is a new header = prepended by an
ITR. The = address fields contain RLOCs obtained from the ingress ITR. The address fields contain RLOCs obtained = from the ingress
router's = EID-to-RLOC Cache. The IP protocol number is "UDP (17)" = router's EID-to-RLOC Cache. The IP = protocol number is "UDP (17)"
from = [RFC0768]. The setting of the Don't Fragment (DF) bit from [RFC0768]. The setting of the Don't Fragment = (DF) bit
'Flags' = field is according to rules listed in Sections 7.1 and 'Flags' field is according to rules listed in = Sections 7.1 and
= 7.2. 7.2.
=
UDP Header: = The UDP header contains an ITR selected source port when = UDP Header: The UDP header contains an ITR = selected source port when
= encapsulating a packet. See Section 12 for details on the hash = encapsulating a packet. See Section 12 = for details on the hash
algorithm = used to select a source port based on the 5-tuple of the = algorithm used to select a source port = based on the 5-tuple of the
inner = header. The destination port MUST be set to the well-known = inner header. The destination port MUST = be set to the well-known
= IANA-assigned port value 4341. = IANA-assigned port value 4341.
=
UDP Checksum: = The 'UDP Checksum' field SHOULD be transmitted as zero UDP Checksum: The 'UDP Checksum' field SHOULD be = transmitted as zero
by an ITR = for either IPv4 [RFC0768] or IPv6 = encapsulation by an ITR for = either IPv4 [RFC0768] and IPv6 = encapsulation
[RFC6935] = [RFC6936]. When a packet with a zero UDP checksum is [RFC6935] [RFC6936]. When a packet with a zero = UDP checksum is
received by = an ETR, the ETR MUST accept the packet for received by an ETR, the ETR MUST accept the packet = for
= decapsulation. When an ITR transmits a non-zero value for the = UDP decapsulation. When an ITR = transmits a non-zero value for the UDP
checksum, = it MUST send a correctly computed value in this field. checksum, it MUST send a correctly computed value = in this field.
When an ETR = receives a packet with a non-zero UDP checksum, it MAY When an ETR receives a packet with a non-zero UDP = checksum, it MAY
choose to = verify the checksum value. If it chooses to perform choose to verify the checksum value. If it = chooses to perform
such = verification, and the verification fails, the packet MUST be = such verification, and the verification = fails, the packet MUST be
silently = dropped. If the ETR chooses not to perform the silently dropped. If the ETR chooses not to = perform the
= verification, or performs the verification successfully, the = verification, or performs the = verification successfully, the
packet MUST = be accepted for decapsulation. The handling of UDP packet MUST be accepted for decapsulation. The = handling of UDP
=
skipping = to change at page 19, line = 43 =C2=B6 = skipping to change at page 19, line = 27 =C2=B6
Copying the = Time to Live (TTL) serves two purposes: first, it Copying the Time to Live (TTL) serves two purposes: = first, it
preserves the = distance the host intended the packet to travel; preserves the distance the host intended the packet = to travel;
second, and = more importantly, it provides for suppression of looping = second, and more importantly, it provides = for suppression of looping
packets in the = event there is a loop of concatenated tunnels due to packets in the event there is a loop of concatenated = tunnels due to
= misconfiguration. See Section 18.3 for TTL exception handling = for misconfiguration. See Section = 18.3 for TTL exception handling for
traceroute = packets. traceroute = packets.
=
The Explicit = Congestion Notification ('ECN') field occupies bits 6 The Explicit Congestion Notification ('ECN') field = occupies bits 6
and 7 of both = the IPv4 'Type of Service' field and the IPv6 'Traffic and 7 of both the IPv4 'Type of Service' field and = the IPv6 'Traffic
Class' field = [RFC3168]. The 'ECN' field requires special treatment Class' field [RFC3168]. The 'ECN' field requires = special treatment
in order to = avoid discarding indications of congestion [RFC3168]. in order to avoid discarding indications of = congestion [RFC3168]. An
ITR encapsulation MUST copy the 2-bit 'ECN' = field from the inner ITR/PITR encapsulation MUST copy the 2-bit = 'ECN' field from the inner
header to the = outer header. Re-encapsulation MUST copy the 2-bit header to the outer header. Re-encapsulation MUST = copy the 2-bit
'ECN' field = from the stripped outer header to the new outer header. = 'ECN' field from the stripped outer header = to the new outer header.
If the 'ECN' = field contains a congestion indication codepoint (the If the 'ECN' field contains a congestion indication = codepoint (the
value is = '11', the Congestion Experienced (CE) codepoint), then ETR value = is '11', the Congestion Experienced (CE) codepoint), then ETR/
= decapsulation MUST copy the 2-bit 'ECN' field from the stripped = outer = PETR decapsulation MUST copy the 2-bit 'ECN' field from the = stripped
header to = the surviving inner header that is used to forward the outer header to the surviving inner header that is = used to forward
packet = beyond the ETR. These requirements preserve CE indications = the packet beyond the ETR. These = requirements preserve CE
when a = packet that uses ECN traverses a LISP tunnel and becomes = indications when a packet that uses ECN = traverses a LISP tunnel and
marked with = a CE indication due to congestion between the tunnel becomes marked with a CE indication due to = congestion between the
= endpoints. tunnel = endpoints.
=
6. LISP = EID-to-RLOC Map-Cache 6. LISP = EID-to-RLOC Map-Cache
=
ITRs and PITRs = maintain an on-demand cache, referred as LISP EID-to- ITRs and PITRs maintain an on-demand cache, referred = as LISP EID-to-
RLOC = Map-Cache, that contains mappings from EID-prefixes to locator = RLOC Map-Cache, that contains mappings from = EID-prefixes to locator
sets. The = cache is used to encapsulate packets from the EID space to = sets. The cache is used to encapsulate = packets from the EID space to
the = corresponding RLOC network attachment point. the corresponding RLOC network attachment = point.
=
When an = ITR/PITR receives a packet from inside of the LISP site to = When an ITR/PITR receives a packet from = inside of the LISP site to
destinations = outside of the site a longest-prefix match lookup of the = destinations outside of the site a = longest-prefix match lookup of the
=
skipping = to change at page 20, line = 40 =C2=B6 = skipping to change at page 20, line = 27 =C2=B6
information = about EIDs and RLOCs, and uses LISP reachability information about EIDs and RLOCs, and uses LISP = reachability
information = mechanisms to determine the reachability of RLOCs, see information mechanisms to determine the reachability = of RLOCs, see
Section 10 for = the specific mechanisms. Section 10 = for the specific mechanisms.
=
7. Dealing with = Large Encapsulated Packets 7. Dealing = with Large Encapsulated Packets
=
This section = proposes two mechanisms to deal with packets that exceed = This section proposes two mechanisms to deal = with packets that exceed
the path MTU = between the ITR and ETR. the path = MTU between the ITR and ETR.
=
It is left to = the implementor to decide if the stateless or stateful It is left to the implementor to decide if the = stateless or stateful
mechanism = should be implemented. Both or neither = can be used, since mechanism SHOULD be implemented. Both or neither can be = used, since
it is a local = decision in the ITR regarding how to deal with MTU it is a local decision in the ITR regarding how to = deal with MTU
issues, and = sites can interoperate with differing mechanisms. issues, and sites can interoperate with differing = mechanisms.
=
Both stateless = and stateful mechanisms also apply to Re-encapsulating Both stateless and stateful mechanisms also apply to = Re-encapsulating
and Recursive = Tunneling, so any actions below referring to an ITR and Recursive Tunneling, so any actions below = referring to an ITR
also apply to = a TE-ITR. also apply to a = TE-ITR.
=
7.1. A Stateless = Solution to MTU Handling 7.1. A = Stateless Solution to MTU Handling
=
An ITR = stateless solution to handle MTU issues is described as = An ITR stateless solution to handle MTU = issues is described as
=
skipping = to change at page 21, line = 19 =C2=B6 = skipping to change at page 20, line = 49 =C2=B6
=
1. Define H = to be the size, in octets, of the outer header an ITR 1. Define H to be the size, in octets, of the outer = header an ITR
prepends = to a packet. This includes the UDP and LISP header prepends to a packet. This includes the UDP and = LISP header
= lengths. lengths.
=
2. Define L = to be the size, in octets, of the maximum-sized packet 2. Define L to be the size, in octets, of the = maximum-sized packet
an ITR can = send to an ETR without the need for the ITR or any an ITR can send to an ETR without the need for = the ITR or any
= intermediate routers to fragment the packet. intermediate routers to fragment the = packet.
=
3. Define an = architectural constant S for the maximum size of a 3. Define an architectural constant S for the = maximum size of a
packet, = in octets, an ITR must receive from the = source so the packet, in = octets, an ITR MUST receive from the = source so the
effective = MTU can be met. That is, L =3D S + H. = effective MTU can be met. That is, L =3D S + H.
=
When an ITR = receives a packet from a site-facing interface and adds H = When an ITR receives a packet from a = site-facing interface and adds H
octets worth = of encapsulation to yield a packet size greater than L octets worth of encapsulation to yield a packet size = greater than L
octets = (meaning the received packet size was greater than S octets = octets (meaning the received packet size was = greater than S octets
from the = source), it resolves the MTU issue by first splitting the = from the source), it resolves the MTU issue = by first splitting the
original = packet into 2 equal-sized fragments. A LISP header is then = original packet into 2 equal-sized = fragments. A LISP header is then
prepended to = each fragment. The size of the encapsulated fragments prepended to each fragment. The size of the = encapsulated fragments
is then (S/2 + = H), which is less than the ITR's estimate of the path is then (S/2 + H), which is less than the ITR's = estimate of the path
MTU between = the ITR and its correspondent ETR. = MTU between the ITR and its correspondent ETR.
=
skipping = to change at page 23, line = 14 =C2=B6 = skipping to change at page 22, line = 43 =C2=B6
=
When an ETR = decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID = from the LISP
header is used = as a table identifier to locate the forwarding table header is used as a table identifier to locate the = forwarding table
to use for the = inner destination EID lookup. to = use for the inner destination EID lookup.
=
For example, = an 802.1Q VLAN tag or VPN identifier could be used as a = For example, an 802.1Q VLAN tag or VPN = identifier could be used as a
24-bit = Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case = 24-bit Instance ID. See [I-D.ietf-lisp-vpn] = for LISP VPN use-case
= details. details.
=
The Instance = ID that is stored in the mapping database when LISP-DDT = The Instance ID that is stored in the = mapping database when LISP-DDT
[I-D.ietf-lisp-ddt] is used is 32 bits in = length. That means the [RFC8111] is used is 32 bits in length. That = means the control-plane
= control-plane can store more instances than a given data-plane = can can store more instances than = a given data-plane can use. Multiple
use. = Multiple data-planes can use the same 32-bit space as long as = data-planes can use the same 32-bit space = as long as the low-order 24
the = low-order 24 bits don't overlap among xTRs. bits don't overlap among xTRs.
=
9. Routing = Locator Selection 9. Routing Locator = Selection
=
Both the = client-side and server-side may need = control over the Both the = client-side and server-side MAY need = control over the
selection of = RLOCs for conversations between them. This control is selection of RLOCs for conversations between them. = This control is
achieved by = manipulating the 'Priority' and 'Weight' fields in EID- = achieved by manipulating the 'Priority' and = 'Weight' fields in EID-
to-RLOC = Map-Reply messages. Alternatively, RLOC information MAY be = to-RLOC Map-Reply messages. Alternatively, = RLOC information MAY be
gleaned from = received tunneled packets or EID-to-RLOC Map-Request gleaned from received tunneled packets or EID-to-RLOC = Map-Request
= messages. messages.
=
The following = are different scenarios for choosing RLOCs and the The following are different scenarios for choosing = RLOCs and the
controls that = are available: controls that are = available:
=
o The = server-side returns one RLOC. The client-side can only use = o The server-side returns one RLOC. The = client-side can only use
=
skipping = to change at page 24, line = 48 =C2=B6 = skipping to change at page 24, line = 34 =C2=B6
stored in the = mapping database system provides reachability stored in the mapping database system provides = reachability
information = for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not = part of the
mapping system = and is determined using one or more of the Routing mapping system and is determined using one or more of = the Routing
Locator = reachability algorithms described in the next section. Locator reachability algorithms described in the next = section.
=
10. Routing = Locator Reachability 10. Routing = Locator Reachability
=
Several = mechanisms for determining RLOC reachability are currently = Several mechanisms for determining RLOC = reachability are currently
= defined: defined:
=
1. An ETR = may examine the Locator-Status-Bits in the = LISP header of 1. An ETR MAY examine the Locator-Status-Bits in the LISP = header of
an = encapsulated data packet received from an ITR. If the ETR is = an encapsulated data packet received = from an ITR. If the ETR is
also = acting as an ITR and has traffic to return to the original = also acting as an ITR and has traffic to = return to the original
ITR site, = it can use this status information to help select an ITR site, it can use this status information to = help select an
= RLOC. RLOC.
=
2. An ITR = may receive an ICMP Network Unreachable or = Host 2. An ITR MAY receive an ICMP Network Unreachable or = Host
= Unreachable message for an RLOC it is using. This indicates = that Unreachable message for an = RLOC it is using. This indicates that
the RLOC = is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP = messages may
not be = desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them = completely.
= Implementations are encouraged to follow current best practices = Implementations are encouraged to follow = current best practices
in = treating these conditions. in = treating these conditions.
=
3. An ITR = that participates in the global routing system can 3. An ITR that participates in the global routing = system can
determine = that an RLOC is down if no BGP Routing Information Base = determine that an RLOC is down if no BGP = Routing Information Base
(RIB) = route exists that matches the RLOC IP address. (RIB) route exists that matches the RLOC IP = address.
=
4. An ITR = may receive an ICMP Port Unreachable = message from a 4. An ITR MAY receive an ICMP Port Unreachable message = from a
= destination host. This occurs if an ITR attempts to use = destination host. This occurs if an ITR = attempts to use
= interworking [RFC6832] and LISP-encapsulated data is sent to a = interworking [RFC6832] and = LISP-encapsulated data is sent to a
= non-LISP-capable site. = non-LISP-capable site.
=
5. An ITR = may receive a Map-Reply from an ETR in = response to a 5. An ITR MAY receive a Map-Reply from an ETR in response = to a
previously = sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of = the Map-Reply is
likely up, = since the ETR was able to send the Map-Reply to the likely up, since the ETR was able to send the = Map-Reply to the
= ITR. ITR.
=
6. When an = ETR receives an encapsulated packet from an ITR, the 6. When an ETR receives an encapsulated packet from = an ITR, the
source = RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet = is likely up.
=
7. An ITR/ETR = pair can use the Locator reachability algorithms 7. An ITR/ETR pair can use the Locator reachability = algorithms
described = in this section, namely Echo-Noncing or RLOC-Probing. described in this section, namely Echo-Noncing or = RLOC-Probing.
=
=
skipping = to change at page 26, line = 17 =C2=B6 = skipping to change at page 26, line = 6 =C2=B6
=
When an ETR = decapsulates a packet, it will check for any change in When an ETR decapsulates a packet, it will check for = any change in
the = 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the = the 'Locator-Status-Bits' field. When a bit = goes from 1 to 0, the
ETR, if acting = also as an ITR, will refrain from encapsulating ETR, if acting also as an ITR, will refrain from = encapsulating
packets to an = RLOC that is indicated as down. It will only resume packets to an RLOC that is indicated as down. It = will only resume
using that = RLOC if the corresponding Locator-Status-Bit returns to a = using that RLOC if the corresponding = Locator-Status-Bit returns to a
value of 1. = Locator-Status-Bits are associated with a Locator-Set value of 1. Locator-Status-Bits are associated with = a Locator-Set
per = EID-Prefix. Therefore, when a Locator becomes unreachable, the = per EID-Prefix. Therefore, when a Locator = becomes unreachable, the
= Locator-Status-Bit that corresponds to that Locator's position in = the Locator-Status-Bit that = corresponds to that Locator's position in the
list returned = by the last Map-Reply will be set to zero for that list returned by the last Map-Reply will be set to = zero for that
particular = EID-Prefix. particular EID-Prefix. = Refer to Section 19 for security = related
= issues regarding = Locator-Status-Bits.
=
When ITRs at = the site are not deployed in CE routers, the IGP can When ITRs at the site are not deployed in CE routers, = the IGP can
still be used = to determine the reachability of Locators, provided still be used to determine the reachability of = Locators, provided
they are = injected into the IGP. This is typically done when a /32 = they are injected into the IGP. This is = typically done when a /32
address is = configured on a loopback interface. = address is configured on a loopback interface.
=
When ITRs = receive ICMP Network Unreachable or Host Unreachable When ITRs receive ICMP Network Unreachable or Host = Unreachable
messages as a = method to determine unreachability, they will refrain messages as a method to determine unreachability, = they will refrain
from using = Locators that are described in Locator lists of Map- from using Locators that are described in Locator = lists of Map-
Replies. = However, using this approach is unreliable because many = Replies. However, using this approach is = unreliable because many
=
skipping = to change at page 27, line = 45 =C2=B6 = skipping to change at page 27, line = 36 =C2=B6
E-bit cleared. = The ITR sees this "echoed nonce" and knows that the E-bit cleared. The ITR sees this "echoed nonce" and = knows that the
path to and = from the ETR is up. path to and = from the ETR is up.
=
The ITR will = set the E-bit and N-bit for every packet it sends while = The ITR will set the E-bit and N-bit for = every packet it sends while
in the = echo-nonce-request state. The time the ITR waits to process = in the echo-nonce-request state. The time = the ITR waits to process
the echoed = nonce before it determines the path is unreachable is the echoed nonce before it determines the path is = unreachable is
variable and = is a choice left for the implementation. variable and is a choice left for the = implementation.
=
If the ITR is = receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does = not see the
nonce echoed = while being in the echo-nonce-request state, then the nonce echoed while being in the echo-nonce-request = state, then the
path to the = ETR is unreachable. This decision may be = overridden by path to the ETR is = unreachable. This decision MAY be = overridden by
other Locator = reachability algorithms. Once the ITR determines that other Locator reachability algorithms. Once the ITR = determines that
the path to = the ETR is down, it can switch to another Locator for the path to the ETR is down, it can switch to another = Locator for
that = EID-Prefix. that = EID-Prefix.
=
Note that = "ITR" and "ETR" are relative terms here. Both devices MUST = Note that "ITR" and "ETR" are relative terms = here. Both devices MUST
be = implementing both ITR and ETR functionality for the echo nonce = be implementing both ITR and ETR = functionality for the echo nonce
mechanism to = operate. mechanism to = operate.
=
The ITR and = ETR may both go into the = echo-nonce-request state at the = The ITR and ETR MAY both go into the = echo-nonce-request state at the
same time. = The number of packets sent or the time during which echo = same time. The number of packets sent or = the time during which echo
nonce requests = are sent is an implementation-specific setting. nonce requests are sent is an implementation-specific = setting.
However, when = an ITR is in the echo-nonce-request state, it can echo However, when an ITR is in the echo-nonce-request = state, it can echo
the ETR's = nonce in the next set of packets that it encapsulates and = the ETR's nonce in the next set of packets = that it encapsulates and
subsequently = continue sending echo-nonce-request packets. subsequently continue sending echo-nonce-request = packets.
=
This mechanism = does not completely solve the forward path This mechanism does not completely solve the forward = path
reachability = problem, as traffic may be unidirectional. That is, the = reachability problem, as traffic may be = unidirectional. That is, the
ETR = receiving traffic at a site may not be the = same device as an ITR ETR = receiving traffic at a site MAY not be the = same device as an ITR
that transmits = traffic from that site, or the site-to-site traffic is that transmits traffic from that site, or the = site-to-site traffic is
unidirectional = so there is no ITR returning traffic. = unidirectional so there is no ITR returning traffic.
=
The echo-nonce = algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if = one side sets the
E-bit and the = other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for = echo-noncing, then the
echoing of the = nonce does not occur and the requesting side may echoing of the nonce does not occur and the = requesting side may
erroneously = consider the Locator unreachable. An ITR SHOULD only set = erroneously consider the Locator = unreachable. An ITR SHOULD only set
the E-bit in = an encapsulated data packet when it knows the ETR is the E-bit in an encapsulated data packet when it = knows the ETR is
enabled for = echo-noncing. This is conveyed by the E-bit in the RLOC- = enabled for echo-noncing. This is conveyed = by the E-bit in the RLOC-
probe = Map-Reply message. probe Map-Reply = message.
=
Note that other Locator reachability mechanisms are= being researched Note = other Locator Reachability mechanisms can = be used to compliment
and can be used to compliment or even = override the echo nonce or even = override the echo nonce algorithm. See the next section for
algorithm. = See the next section for an example of control-plane an example of control-plane probing.
= probing.
=
10.2. = RLOC-Probing Algorithm 10.2. = RLOC-Probing Algorithm
=
RLOC-Probing = is a method that an ITR or PITR can use to determine the = RLOC-Probing is a method that an ITR or PITR = can use to determine the
reachability = status of one or more Locators that it has cached in a reachability status of one or more Locators that it = has cached in a
Map-Cache = entry. The probe-bit of the Map-Request and Map-Reply Map-Cache entry. The probe-bit of the Map-Request = and Map-Reply
messages is = used for RLOC-Probing. messages is = used for RLOC-Probing.
=
RLOC-Probing = is done in the control plane on a timer basis, where an = RLOC-Probing is done in the control plane on = a timer basis, where an
ITR or PITR = will originate a Map-Request destined to a locator ITR or PITR will originate a Map-Request destined to = a locator
address from = one of its own locator addresses. A Map-Request used as = address from one of its own locator = addresses. A Map-Request used as
an RLOC-probe = is NOT encapsulated and NOT sent to a Map-Server or to an RLOC-probe is NOT encapsulated and NOT sent to a = Map-Server or to
the mapping = database system as one would when soliciting mapping the mapping database system as one would when = soliciting mapping
data. The EID = record encoded in the Map-Request is the EID-Prefix of data. The EID record encoded in the Map-Request is = the EID-Prefix of
the = Map-Cache entry cached by the ITR or PITR. The ITR may include a = the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a
mapping data = record for its own database mapping information that mapping data record for its own database mapping = information that
contains the = local EID-Prefixes and RLOCs for its site. RLOC-probes = contains the local EID-Prefixes and RLOCs = for its site. RLOC-probes
are sent = periodically using a jittered timer interval. are sent periodically using a jittered timer = interval.
=
When an ETR = receives a Map-Request message with the probe-bit set, it = When an ETR receives a Map-Request message = with the probe-bit set, it
returns a = Map-Reply with the probe-bit set. The source address of = returns a Map-Reply with the probe-bit set. = The source address of
the Map-Reply = is set according to the procedure described in the Map-Reply is set according to the procedure = described in
= [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain = mapping [I-D.ietf-lisp-rfc6833bis]. = The Map-Reply SHOULD contain mapping
data for the = EID-Prefix contained in the Map-Request. This provides = data for the EID-Prefix contained in the = Map-Request. This provides
the = opportunity for the ITR or PITR that sent the RLOC-probe to get = the opportunity for the ITR or PITR that = sent the RLOC-probe to get
=
skipping = to change at page 29, line = 27 =C2=B6 = skipping to change at page 29, line = 14 =C2=B6
reachable or = has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a = robust
mechanism for = switching to using another Locator from the cached mechanism for switching to using another Locator from = the cached
Locator. = RLOC-Probing can also provide rough Round-Trip Time (RTT) = Locator. RLOC-Probing can also provide = rough Round-Trip Time (RTT)
estimates = between a pair of Locators, which can be useful for network = estimates between a pair of Locators, which = can be useful for network
management = purposes as well as for selecting low delay paths. The = management purposes as well as for selecting = low delay paths. The
major = disadvantage of RLOC-Probing is in the number of control = major disadvantage of RLOC-Probing is in the = number of control
messages = required and the amount of bandwidth used to obtain those = messages required and the amount of = bandwidth used to obtain those
benefits, = especially if the requirement for failure detection times = benefits, especially if the requirement for = failure detection times
is very = small. is very small.
=
Continued research and testing will attempt to = characterize the
tradeoffs of failure detection times versus message = overhead.
= =
11. EID = Reachability within a LISP Site 11. = EID Reachability within a LISP Site
=
A site may be multihomed using two or more ETRs. The = hosts and A site MAY be multihomed using two or more ETRs. The = hosts and
infrastructure = within a site will be addressed using one or more EID- infrastructure within a site will be addressed using = one or more EID-
Prefixes that = are mapped to the RLOCs of the relevant ETRs in the Prefixes that are mapped to the RLOCs of the relevant = ETRs in the
mapping = system. One possible failure mode is for an ETR to lose = mapping system. One possible failure mode = is for an ETR to lose
reachability = to one or more of the EID-Prefixes within its own site. = reachability to one or more of the = EID-Prefixes within its own site.
When this = occurs when the ETR sends Map-Replies, it can clear the = When this occurs when the ETR sends = Map-Replies, it can clear the
R-bit = associated with its own Locator. And when the ETR is also an = R-bit associated with its own Locator. And = when the ETR is also an
ITR, it can = clear its Locator-Status-Bit in the encapsulation data ITR, it can clear its Locator-Status-Bit in the = encapsulation data
= header. header.
=
It is = recognized that there are no simple solutions to the site = It is recognized that there are no simple = solutions to the site
partitioning = problem because it is hard to know which part of the partitioning problem because it is hard to know which = part of the
EID-Prefix = range is partitioned and which Locators can reach any sub- = EID-Prefix range is partitioned and which = Locators can reach any sub-
ranges of = the EID-Prefixes. This problem is under = investigation with ranges = of the EID-Prefixes. Note that this is not a new problem
the expectation that experiments will tell us = more. Note that this = introduced by the LISP architecture. The problem exists today when = a
is not a new = problem introduced by the LISP architecture. The multihomed site uses BGP to advertise its = reachability upstream.
problem = exists today when a multihomed site uses BGP to advertise its =
reachability = upstream.
=
12. Routing = Locator Hashing 12. Routing Locator = Hashing
=
When an ETR = provides an EID-to-RLOC mapping in a Map-Reply message to When an = ETR provides an EID-to-RLOC mapping in a Map-Reply message
a requesting = ITR, the Locator-Set for the EID-Prefix may = contain that = is stored in the map-cache of a requesting ITR, the = Locator-Set
different = Priority values for each locator address. When more than = for the EID-Prefix MAY contain different Priority and Weight values
one best = Priority Locator exists, the ITR can decide how to load- for = each locator address. When more than one best Priority Locator
share traffic against the corresponding = Locators. exists, the ITR can = decide how to load-share traffic against = the
= corresponding Locators.
=
The = following hash algorithm may be used by an = ITR to select a The following hash = algorithm MAY be used by an ITR to select = a
Locator for a = packet destined to an EID for the EID-to-RLOC mapping: Locator for a packet destined to an EID for the = EID-to-RLOC mapping:
=
1. Either a = source and destination address hash or the traditional 1. Either a source and destination address hash or = the traditional
5-tuple = hash can be used. The traditional 5-tuple hash includes = 5-tuple hash can be used. The = traditional 5-tuple hash includes
the source = and destination addresses; source and destination TCP, the source and destination addresses; source and = destination TCP,
UDP, or = Stream Control Transmission Protocol (SCTP) port numbers; = UDP, or Stream Control Transmission = Protocol (SCTP) port numbers;
and the IP = protocol number field or IPv6 next-protocol fields of and the IP protocol number field or IPv6 = next-protocol fields of
a packet = that a host originates from within a LISP site. When a = a packet that a host originates from = within a LISP site. When a
packet is = not a TCP, UDP, or SCTP packet, the source and packet is not a TCP, UDP, or SCTP packet, the = source and
= destination addresses only from the header are used to compute = destination addresses only from the = header are used to compute
=
skipping = to change at page 34, line = 6 =C2=B6 = skipping to change at page 33, line = 30 =C2=B6
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
sender of an = SMR-based Map-Request MUST be verified. If an ITR sender of an SMR-based Map-Request MUST be verified. = If an ITR
receives an = SMR-based Map-Request and the source is not in the receives an SMR-based Map-Request and the source is = not in the
Locator-Set = for the stored Map-Cache entry, then the responding Map- = Locator-Set for the stored Map-Cache entry, = then the responding Map-
Request MUST = be sent with an EID destination to the mapping database = Request MUST be sent with an EID destination = to the mapping database
system. Since = the mapping database system is a more secure way to system. Since the mapping database system is a more = secure way to
reach an = authoritative ETR, it will deliver the Map-Request to the = reach an authoritative ETR, it will deliver = the Map-Request to the
authoritative = source of the mapping data. = authoritative source of the mapping data.
=
When an ITR = receives an SMR-based Map-Request for which it does not = When an ITR receives an SMR-based = Map-Request for which it does not
have a = cached mapping for the EID in the SMR message, it MAY not send = have a cached mapping for the EID in the SMR message, it may not send
an SMR-invoked = Map-Request. This scenario can occur when an ETR an SMR-invoked Map-Request. This scenario can occur = when an ETR
sends SMR = messages to all Locators in the Locator-Set it has stored = sends SMR messages to all Locators in the = Locator-Set it has stored
in its = map-cache but the remote ITRs that receive the SMR may not be = in its map-cache but the remote ITRs that = receive the SMR may not be
sending = packets to the site. There is no point in updating the ITRs = sending packets to the site. There is no = point in updating the ITRs
until they = need to send, in which case they will send Map-Requests to = until they need to send, in which case they = will send Map-Requests to
obtain a = Map-Cache entry. obtain a Map-Cache = entry.
=
13.3. Database = Map-Versioning 13.3. Database = Map-Versioning
=
When there is = unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an = ITR and ETR, and
=
skipping = to change at page 35, line = 52 =C2=B6 = skipping to change at page 35, line = 26 =C2=B6
few = implementation techniques can be used to incrementally = implement few implementation = techniques can be used to incrementally implement
LISP: = LISP:
=
o When a = tunnel-encapsulated packet is received by an ETR, the outer = o When a tunnel-encapsulated packet is = received by an ETR, the outer
destination = address may not be the address of the router. This destination address may not be the address of the = router. This
makes it = challenging for the control plane to get packets from the = makes it challenging for the control = plane to get packets from the
hardware. = This may be mitigated by creating special Forwarding hardware. This may be mitigated by creating = special Forwarding
Information = Base (FIB) entries for the EID-Prefixes of EIDs served Information Base (FIB) entries for the = EID-Prefixes of EIDs served
by the ETR = (those for which the router provides an RLOC by the ETR (those for which the router provides an = RLOC
= translation). These FIB entries are marked with a flag = indicating translation). These = FIB entries are marked with a flag indicating
that = control-plane processing should be = performed. The forwarding that = control-plane processing SHOULD be = performed. The forwarding
logic of = testing for particular IP protocol number values is not = logic of testing for particular IP = protocol number values is not
necessary. = There are a few proven cases where no changes to necessary. There are a few proven cases where no = changes to
existing = deployed hardware were needed to support the LISP data- = existing deployed hardware were needed to = support the LISP data-
= plane. plane.
=
o On an ITR, = prepending a new IP header consists of adding more o On an ITR, prepending a new IP header consists of = adding more
octets to a = MAC rewrite string and prepending the string as part octets to a MAC rewrite string and prepending the = string as part
of the = outgoing encapsulation procedure. Routers that support = of the outgoing encapsulation procedure. = Routers that support
Generic = Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 = Generic Routing Encapsulation (GRE) = tunneling [RFC2784] or 6to4
tunneling = [RFC3056] may already support this action. tunneling [RFC3056] may already support this = action.
=
skipping = to change at page 38, line = 15 =C2=B6 = skipping to change at page 37, line = 40 =C2=B6
17. LISP xTR = Placement and Encapsulation Methods 17. = LISP xTR Placement and Encapsulation Methods
=
This section = will explore how and where ITRs and ETRs can be placed This section will explore how and where ITRs and ETRs = can be placed
in the network = and will discuss the pros and cons of each scenario. in the network and will discuss the pros and cons of = each scenario.
For a more = detailed networkd design deployment recommendation, refer = For a more detailed networkd design = deployment recommendation, refer
to = [RFC7215]. to [RFC7215].
=
There are two = basic deployment tradeoffs to consider: centralized There are two basic deployment tradeoffs to consider: = centralized
versus = distributed caches; and flat, Recursive, or Re-encapsulating = versus distributed caches; and flat, = Recursive, or Re-encapsulating
Tunneling. = When deciding on centralized versus distributed caching, = Tunneling. When deciding on centralized = versus distributed caching,
the = following issues should be = considered: the following issues = SHOULD be considered:
=
o Are the = xTRs spread out so that the caches are spread across all = o Are the xTRs spread out so that the = caches are spread across all
the = memories of each router? A centralized cache is when an ITR = the memories of each router? A = centralized cache is when an ITR
keeps a = cache for all the EIDs it is encapsulating to. The packet = keeps a cache for all the EIDs it is = encapsulating to. The packet
takes a = direct path to the destination Locator. A distributed takes a direct path to the destination Locator. A = distributed
cache is = when an ITR needs help from other Re-Encapsulating Tunnel = cache is when an ITR needs help from = other Re-Encapsulating Tunnel
Routers = (RTRs) because it does not store all the cache entries for = Routers (RTRs) because it does not store = all the cache entries for
the EIDs it = is encapsulating to. So, the packet takes a path the EIDs it is encapsulating to. So, the packet = takes a path
through = RTRs that have a different set of cache entries. through RTRs that have a different set of cache = entries.
=
o Should = management "touch points" be minimized by only choosing a = o Should management "touch points" be = minimized by only choosing a
few xTRs, = just enough for redundancy? few = xTRs, just enough for redundancy?
=
o In general, = using more ITRs doesn't increase management load, o In general, using more ITRs doesn't increase = management load,
since = caches are built and stored dynamically. On the other hand, = since caches are built and stored = dynamically. On the other hand,
using more = ETRs does require more management, since EID-Prefix-to- = using more ETRs does require more = management, since EID-Prefix-to-
RLOC = mappings need to be explicitly configured. RLOC mappings need to be explicitly = configured.
=
When deciding = on flat, Recursive, or Re-Encapsulating Tunneling, the When deciding on flat, Recursive, or Re-Encapsulating = Tunneling, the
following = issues should be considered: = following issues SHOULD be considered:
=
o Flat = tunneling implements a single encapsulation path between the = o Flat tunneling implements a single = encapsulation path between the
source site = and destination site. This generally offers better source site and destination site. This generally = offers better
paths = between sources and destinations with a single encapsulation = paths between sources and destinations = with a single encapsulation
= path. path.
=
o Recursive = Tunneling is when encapsulated traffic is again further = o Recursive Tunneling is when encapsulated = traffic is again further
= encapsulated in another tunnel, either to implement VPNs or to = encapsulated in another tunnel, either to = implement VPNs or to
perform = Traffic Engineering. When doing VPN-based tunneling, the = perform Traffic Engineering. When doing = VPN-based tunneling, the
site has = some control, since the site is prepending a new site has some control, since the site is = prepending a new
= encapsulation header. In the case of TE-based tunneling, the = site encapsulation header. In = the case of TE-based tunneling, the site
may have control if it is prepending a new = tunnel header, but if MAY have control if it is prepending a new = tunnel header, but if
the site's = ISP is doing the TE, then the site has no control. the site's ISP is doing the TE, then the site has = no control.
Recursive = Tunneling generally will result in suboptimal paths but = Recursive Tunneling generally will result = in suboptimal paths but
with the = benefit of steering traffic to parts of the network that = with the benefit of steering traffic to = parts of the network that
have more = resources available. have more = resources available.
=
o The = technique of Re-Encapsulation ensures that packets only = o The technique of Re-Encapsulation ensures = that packets only
require one = encapsulation header. So, if a packet needs to be re- require one encapsulation header. So, if a packet = needs to be re-
routed, it = is first decapsulated by the RTR and then Re- routed, it is first decapsulated by the RTR and = then Re-
= Encapsulated with a new encapsulation header using a new RLOC. = Encapsulated with a new encapsulation = header using a new RLOC.
=
=
skipping = to change at page 41, line = 12 =C2=B6 = skipping to change at page 40, line = 36 =C2=B6
addresses MUST = be used only in the outer IP header so the NAT device addresses MUST be used only in the outer IP header so = the NAT device
can translate = properly. Otherwise, EID addresses MUST be translated can translate properly. Otherwise, EID addresses = MUST be translated
before = encapsulation is performed when LISP VPNs are not in use. = before encapsulation is performed when LISP = VPNs are not in use.
Both NAT = translation and LISP encapsulation functions could be co- = Both NAT translation and LISP encapsulation = functions could be co-
located in the = same device. located in the same = device.
=
17.5. Packets = Egressing a LISP Site 17.5. Packets = Egressing a LISP Site
=
When a LISP = site is using two ITRs for redundancy, the failure of one = When a LISP site is using two ITRs for = redundancy, the failure of one
ITR will = likely shift outbound traffic to the second. This second = ITR will likely shift outbound traffic to = the second. This second
ITR's cache = may not be populated with the same = EID-to-RLOC mapping ITR's cache = MAY not be populated with the same = EID-to-RLOC mapping
entries as the = first. If this second ITR does not have these entries as the first. If this second ITR does not = have these
mappings, = traffic will be dropped while the mappings are retrieved = mappings, traffic will be dropped while the = mappings are retrieved
from the = mapping system. The retrieval of these messages may from the mapping system. The retrieval of these = messages may
increase the = load of requests being sent into the mapping system. increase the load of requests being sent into the = mapping system.
=
18. Traceroute = Considerations 18. Traceroute = Considerations
=
When a source = host in a LISP site initiates a traceroute to a When a source host in a LISP site initiates a = traceroute to a
destination = host in another LISP site, it is highly desirable for it = destination host in another LISP site, it is = highly desirable for it
to see the = entire path. Since packets are encapsulated from the ITR = to see the entire path. Since packets are = encapsulated from the ITR
=
skipping = to change at page 44, line = 16 =C2=B6 = skipping to change at page 43, line = 42 =C2=B6
=
Map-Versioning = is a data-plane mechanism used to signal a peering xTR Map-Versioning is a data-plane mechanism used to = signal a peering xTR
that a local = EID-to-RLOC mapping has been updated, so that the that a local EID-to-RLOC mapping has been updated, so = that the
peering xTR = uses LISP Control-Plane signaling message to retrieve a = peering xTR uses LISP Control-Plane = signaling message to retrieve a
fresh mapping. = This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to = forge the map-
versioning = field of a LISP encapsulated header and force an excessive = versioning field of a LISP encapsulated = header and force an excessive
amount of = signaling between xTRs that may overload them. amount of signaling between xTRs that may overload = them.
=
Most of the = attack vectors can be mitigated with careful deployment = Most of the attack vectors can be mitigated = with careful deployment
and = configuration, information learned opportunistically (such as = LSB and configuration, information = learned opportunistically (such as LSB
or gleaning) = should be verified with other reachability = mechanisms. or gleaning) SHOULD be verified with other reachability = mechanisms.
In addition, = systematic rate-limitation and filtering is an effective = In addition, systematic rate-limitation and = filtering is an effective
technique to = mitigate attacks that aim to overload the control-plane. = technique to mitigate attacks that aim to = overload the control-plane.
=
20. Network = Management Considerations 20. Network = Management Considerations
=
Considerations = for network management tools exist so the LISP Considerations for network management tools exist so = the LISP
protocol suite = can be operationally managed. These mechanisms can be protocol suite can be operationally managed. These = mechanisms can be
found in = [RFC7052] and [RFC6835]. found in = [RFC7052] and [RFC6835].
=
21. IANA = Considerations 21. IANA = Considerations
=
This section = provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet = Assigned Numbers
Authority = (IANA) regarding registration of values related to this = Authority (IANA) regarding registration of = values related to this
data-plane = LISP specification, in accordance with BCP 26 [RFC5226]. = data-plane LISP specification, in accordance with BCP 26 [RFC8126].
=
21.1. LISP UDP = Port Numbers 21.1. LISP UDP Port = Numbers
=
The IANA = registry has allocated UDP port numbers 4341 and 4342 for = The IANA registry has allocated UDP port = numbers 4341 and 4342 for
lisp-data and = lisp-control operation, respectively. IANA has updated = lisp-data and lisp-control operation, = respectively. IANA has updated
the = description for UDP ports 4341 and 4342 as follows: the description for UDP ports 4341 and 4342 as = follows:
=
lisp-data = 4341 udp LISP Data Packets = lisp-data 4341 udp LISP Data Packets
= lisp-control 4342 udp LISP Control Packets lisp-control 4342 udp LISP Control = Packets
=
22. = References 22. References
=
22.1. Normative = References 22.1. Normative = References
=
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
Smirnov, "LISP Delegated Database Tree", = draft-ietf-lisp-
ddt-09 (work in progress), January = 2017.
[I-D.ietf-lisp-introduction] =
Cabellos-Aparicio, A. and D. Saucez, "An = Architectural
Introduction to the Locator/ID Separation = Protocol
(LISP)", draft-ietf-lisp-introduction-13 = (work in
progress), April 2015. =
= =
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-06 (work in progress), = October = draft-ietf-lisp-rfc6833bis-07 (work in progress), = December
= 2017. 2017.
=
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., = Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", = draft-ietf-lisp-sec-14
(work in progress), October = 2017.
= =
[RFC0768] = Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD = 6, RFC 768,
DOI = 10.17487/RFC0768, August 1980, = DOI 10.17487/RFC0768, August 1980,
= <https://www.rfc-editor.org/info/rfc768>. = <https://www.rfc-editor.org/info/rfc768>.
=
[RFC0791] = Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, = RFC 791,
DOI = 10.17487/RFC0791, September 1981, = DOI 10.17487/RFC0791, September 1981,
= <https://www.rfc-editor.org/info/rfc791>. = <https://www.rfc-editor.org/info/rfc791>.
=
[RFC1918] = Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., = [RFC1918] Rekhter, Y., Moskowitz, B., = Karrenberg, D., de Groot, G.,
and = E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for = Private Internets",
BCP = 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, = February 1996,
= <https://www.rfc-editor.org/info/rfc1918>. = <https://www.rfc-editor.org/info/rfc1918>.
=
[RFC2119] = Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
= Requirement Levels", BCP 14, RFC 2119, = Requirement Levels", BCP 14, RFC 2119,
DOI = 10.17487/RFC2119, March 1997, = DOI 10.17487/RFC2119, March 1997,
= <https://www.rfc-editor.org/info/rfc2119>. = <https://www.rfc-editor.org/info/rfc2119>.
=
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2474] Nichols, K., = Blake, S., Baker, F., and D. = Black,
ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November = = "Definition of the Differentiated Services = Field (DS
= 1998, <https://www.rfc-editor.org/info/rfc2404>. = Field) in the IPv4 and IPv6 = Headers", RFC 2474,
= DOI 10.17487/RFC2474, December 1998,
= <https://www.rfc-editor.org/info/rfc2474>.
=
[RFC3168] = Ramakrishnan, K., Floyd, S., and D. Black, "The Addition = [RFC3168] Ramakrishnan, K., Floyd, S., and = D. Black, "The Addition
of = Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) = to IP",
RFC = 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September = 2001,
= <https://www.rfc-editor.org/info/rfc3168>. = <https://www.rfc-editor.org/info/rfc3168>.
=
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC = 1700 is Replaced
by an On-line Database", RFC 3232, DOI = 10.17487/RFC3232,
January 2002, = <https://www.rfc-editor.org/info/rfc3232>. =
= =
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4632] = Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless = Inter-domain Routing
= (CIDR): The Internet Address Assignment and Aggregation = (CIDR): The Internet Address = Assignment and Aggregation
= Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI = 10.17487/RFC4632, August
= 2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, = <https://www.rfc-editor.org/info/rfc4632>.
=
[RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI 10.17487/RFC4868, May = 2007,
= <https://www.rfc-editor.org/info/rfc4868>. =
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines = for Writing an
IANA Considerations Section in RFCs", RFC = 5226,
DOI 10.17487/RFC5226, May = 2008,
= <https://www.rfc-editor.org/info/rfc5226>. =
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, = "The Reverse Path
Forwarding (RPF) Vector TLV", RFC = 5496,
DOI 10.17487/RFC5496, March = 2009,
= <https://www.rfc-editor.org/info/rfc5496>. =
= =
[RFC5944] = Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", = [RFC5944] Perkins, C., Ed., "IP Mobility = Support for IPv4, Revised",
RFC = 5944, DOI 10.17487/RFC5944, November 2010, RFC 5944, DOI 10.17487/RFC5944, November = 2010,
= <https://www.rfc-editor.org/info/rfc5944>. = <https://www.rfc-editor.org/info/rfc5944>.
=
[RFC6115] Li, T., Ed., "Recommendation for a Routing = Architecture",
RFC 6115, DOI 10.17487/RFC6115, February = 2011,
= <https://www.rfc-editor.org/info/rfc6115>. =
= =
[RFC6275] = Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. = Arkko, "Mobility
= Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI = 10.17487/RFC6275, July
= 2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, = <https://www.rfc-editor.org/info/rfc6275>.
=
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, = "Locator/ID
Separation Protocol (LISP) = Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January = 2013,
= <https://www.rfc-editor.org/info/rfc6834>. =
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and = D. Lewis,
"Locator/ID Separation Protocol = Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI = 10.17487/RFC6836,
January 2013, = <https://www.rfc-editor.org/info/rfc6836>. =
[RFC7052] Schudel, G., Jain, A., and V. Moreno, = "Locator/ID
Separation Protocol (LISP) MIB", RFC = 7052,
DOI 10.17487/RFC7052, October = 2013,
= <https://www.rfc-editor.org/info/rfc7052>. =
[RFC7214] Andersson, L. and C. Pignataro, "Moving = Generic Associated
Channel (G-ACh) IANA Registries to a New = Registry",
RFC 7214, DOI 10.17487/RFC7214, May = 2014,
= <https://www.rfc-editor.org/info/rfc7214>. =
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, = F., Domingo-
Pascual, J., and D. Lewis, = "Locator/Identifier Separation
Protocol (LISP) Network Element = Deployment
Considerations", RFC 7215, DOI = 10.17487/RFC7215, April
2014, = <https://www.rfc-editor.org/info/rfc7215>. =
= =
[RFC7833] = Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A [RFC7833] Howlett, J., Hartman, S., and A. = Perez-Mendez, Ed., "A
= RADIUS Attribute, Binding, Profiles, Name Identifier RADIUS Attribute, Binding, Profiles, Name = Identifier
= Format, and Confirmation Methods for the Security Format, and Confirmation Methods for the = Security
= Assertion Markup Language (SAML)", RFC 7833, Assertion Markup Language (SAML)", RFC = 7833,
DOI = 10.17487/RFC7833, May 2016, = DOI 10.17487/RFC7833, May 2016,
= <https://www.rfc-editor.org/info/rfc7833>. = <https://www.rfc-editor.org/info/rfc7833>.
=
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC8126] Cotton, M., Leiba, = B., and T. Narten, "Guidelines = for
Separation Protocol (LISP) Threat = Analysis", RFC 7835, = Writing = an IANA Considerations Section in RFCs", BCP 26,
= DOI 10.17487/RFC7835, April 2016, = RFC 8126, DOI 10.17487/RFC8126,= June 2017,
= <https://www.rfc-editor.org/info/rfc7835>. = <https://www.rfc-editor.org/info/rfc8126>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID = Separation Protocol
(LISP) Data-Plane Confidentiality", RFC = 8061,
DOI 10.17487/RFC8061, February = 2017,
= <https://www.rfc-editor.org/info/rfc8061>.
=
[RFC8200] = Deering, S. and R. Hinden, "Internet Protocol, Version 6 = [RFC8200] Deering, S. and R. Hinden, = "Internet Protocol, Version 6
= (IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC = 8200,
DOI = 10.17487/RFC8200, July 2017, = DOI 10.17487/RFC8200, July 2017,
= <https://www.rfc-editor.org/info/rfc8200>. = <https://www.rfc-editor.org/info/rfc8200>.
=
22.2. = Informative References 22.2. = Informative References
=
[AFN] = IANA, "Address Family Numbers", August 2016, [AFN] IANA, "Address Family Numbers", August = 2016,
= <http://www.iana.org/assignments/address-family-numbers>. = = <http://www.iana.org/assignments/address-family-numbers>.
=
[CHIAPPA] = Chiappa, J., "Endpoints and Endpoint names: A Proposed", = [CHIAPPA] Chiappa, J., "Endpoints and = Endpoint names: A Proposed",
= 1999, 1999,
= <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. = = <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
=
= [I-D.ietf-lisp-eid-mobility] = [I-D.ietf-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-ietf-lisp-eid-mobility-00 = Unified Control Plane", draft-ietf-lisp-eid-mobility-01
= (work in progress), May 2017. = (work in progress), November 2017.
= =
= [I-D.ietf-lisp-introduction]
= = Cabellos-Aparicio, A. and D. Saucez, "An Architectural
= = Introduction to the Locator/ID Separation Protocol
= (LISP)", = draft-ietf-lisp-introduction-13 (work in
= = progress), April 2015.
=
= [I-D.ietf-lisp-mn] = [I-D.ietf-lisp-mn]
= Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP = Farinacci, D., Lewis, D., Meyer, = D., and C. White, "LISP
= Mobile Node", draft-ietf-lisp-mn-01 (work in progress), = Mobile Node", = draft-ietf-lisp-mn-01 (work in progress),
= October 2017. October = 2017.
=
= [I-D.ietf-lisp-predictive-rlocs] = [I-D.ietf-lisp-predictive-rlocs]
= Farinacci, D. and P. Pillay-Esnault, "LISP Predictive Farinacci, D. and P. Pillay-Esnault, "LISP = Predictive
= RLOCs", draft-ietf-lisp-predictive-rlocs-00 = (work in RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work = in
= progress), June 2017. progress), November = 2017.
=
= = [I-D.ietf-lisp-sec]
= Maino, = F., Ermagan, V., Cabellos-Aparicio, A., and D.
= Saucez, = "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
= (work in = progress), October 2017.
=
= [I-D.ietf-lisp-signal-free-multicast] = [I-D.ietf-lisp-signal-free-multicast]
= Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", = Moreno, V. and D. Farinacci, = "Signal-Free LISP Multicast",
= draft-ietf-lisp-signal-free-multicast-06 = (work in draft-ietf-lisp-signal-free-multicast-07 (work = in
= progress), August 2017. progress), November 2017.
=
= [I-D.ietf-lisp-vpn] = [I-D.ietf-lisp-vpn]
= Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual = Private
= Networks (VPNs)", draft-ietf-lisp-vpn-00 = (work in Networks = (VPNs)", draft-ietf-lisp-vpn-01 (work = in
= progress), May 2017. progress), November 2017.
=
= [I-D.meyer-loc-id-implications] = [I-D.meyer-loc-id-implications]
= Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural = Implications of
= Locator/ID Separation", draft-meyer-loc-id-implications-01 = Locator/ID Separation", = draft-meyer-loc-id-implications-01
= (work in progress), January 2009. = (work in progress), January 2009.
=
[LISA96] = Lear, E., Tharp, D., Katinsky, J., and J. Coffin, [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. = Coffin,
= "Renumbering: Threat or Menace?", Usenix Tenth System "Renumbering: Threat or Menace?", Usenix = Tenth System
= Administration Conference (LISA 96), October 1996. Administration Conference (LISA 96), = October 1996.
=
=
skipping = to change at page 49, line = 9 =C2=B6 = skipping to change at page 47, line = 22 =C2=B6
=
[RFC2784] = Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, = D., and P.
= Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, = Traina, "Generic Routing = Encapsulation (GRE)", RFC 2784,
DOI = 10.17487/RFC2784, March 2000, = DOI 10.17487/RFC2784, March 2000,
= <https://www.rfc-editor.org/info/rfc2784>. = <https://www.rfc-editor.org/info/rfc2784>.
=
[RFC3056] = Carpenter, B. and K. Moore, "Connection of IPv6 Domains = [RFC3056] Carpenter, B. and K. Moore, = "Connection of IPv6 Domains
via = IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February via IPv4 Clouds", RFC 3056, DOI = 10.17487/RFC3056, February
= 2001, <https://www.rfc-editor.org/info/rfc3056>. 2001, = <https://www.rfc-editor.org/info/rfc3056>.
=
= [RFC3232] Reynolds, = J., Ed., "Assigned Numbers: RFC 1700 is Replaced
= by an = On-line Database", RFC 3232, DOI 10.17487/RFC3232,
= January = 2002, <https://www.rfc-editor.org/info/rfc3232>.
= =
[RFC3261] = Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, = [RFC3261] Rosenberg, J., Schulzrinne, H., = Camarillo, G., Johnston,
A., = Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., = and E.
= Schooler, "SIP: Session Initiation Protocol", RFC 3261, = Schooler, "SIP: Session = Initiation Protocol", RFC 3261,
DOI = 10.17487/RFC3261, June 2002, = DOI 10.17487/RFC3261, June 2002,
= <https://www.rfc-editor.org/info/rfc3261>. = <https://www.rfc-editor.org/info/rfc3261>.
=
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for = Cryptographic
Key Management", BCP 107, RFC 4107, DOI = 10.17487/RFC4107,
June 2005, = <https://www.rfc-editor.org/info/rfc4107>. =
= =
[RFC4192] = Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, = "Procedures for
= Renumbering an IPv6 Network without a Flag Day", RFC 4192, = Renumbering an IPv6 Network = without a Flag Day", RFC 4192,
DOI = 10.17487/RFC4192, September 2005, = DOI 10.17487/RFC4192, September 2005,
= <https://www.rfc-editor.org/info/rfc4192>. = <https://www.rfc-editor.org/info/rfc4192>.
=
[RFC4866] = Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, = "Enhanced Route
= Optimization for Mobile IPv6", RFC 4866, Optimization for Mobile IPv6", RFC = 4866,
DOI = 10.17487/RFC4866, May 2007, = DOI 10.17487/RFC4866, May 2007,
= <https://www.rfc-editor.org/info/rfc4866>. = <https://www.rfc-editor.org/info/rfc4866>.
=
[RFC4984] = Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report = [RFC4984] Meyer, D., Ed., Zhang, L., Ed., = and K. Fall, Ed., "Report
= from the IAB Workshop on Routing and Addressing", from the IAB Workshop on Routing and = Addressing",
RFC = 4984, DOI 10.17487/RFC4984, September 2007, RFC 4984, DOI 10.17487/RFC4984, September = 2007,
= <https://www.rfc-editor.org/info/rfc4984>. = <https://www.rfc-editor.org/info/rfc4984>.
=
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure = to Support
Secure Internet Routing", RFC 6480, DOI = 10.17487/RFC6480,
February 2012, = <https://www.rfc-editor.org/info/rfc6480>. =
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and = Authentication for
Routing Protocols (KARP) Design = Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February = 2012,
= <https://www.rfc-editor.org/info/rfc6518>. =
= =
[RFC6831] = Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The = [RFC6831] Farinacci, D., Meyer, D., = Zwiebel, J., and S. Venaas, "The
= Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for = Multicast
= Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI = 10.17487/RFC6831, January
= 2013, <https://www.rfc-editor.org/info/rfc6831>. 2013, = <https://www.rfc-editor.org/info/rfc6831>.
=
[RFC6832] = Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and = V. Fuller,
= "Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID = Separation Protocol
= (LISP) and Non-LISP Sites", RFC 6832, = (LISP) and Non-LISP Sites", RFC 6832,
DOI = 10.17487/RFC6832, January 2013, = DOI 10.17487/RFC6832, January 2013,
= <https://www.rfc-editor.org/info/rfc6832>. = <https://www.rfc-editor.org/info/rfc6832>.
=
= [RFC6834] Iannone, = L., Saucez, D., and O. Bonaventure, "Locator/ID
= = Separation Protocol (LISP) Map-Versioning", RFC 6834,
= DOI = 10.17487/RFC6834, January 2013,
= = <https://www.rfc-editor.org/info/rfc6834>.
= =
[RFC6835] = Farinacci, D. and D. Meyer, "The Locator/ID Separation [RFC6835] Farinacci, D. and D. Meyer, "The = Locator/ID Separation
= Protocol Internet Groper (LIG)", RFC 6835, Protocol Internet Groper (LIG)", RFC = 6835,
DOI = 10.17487/RFC6835, January 2013, = DOI 10.17487/RFC6835, January 2013,
= <https://www.rfc-editor.org/info/rfc6835>. = <https://www.rfc-editor.org/info/rfc6835>.
=
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID = (EID) to
Routing Locator (RLOC) Database", RFC = 6837,
DOI 10.17487/RFC6837, January = 2013,
= <https://www.rfc-editor.org/info/rfc6837>. =
= =
[RFC6935] = Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and = [RFC6935] Eubanks, M., Chimento, P., and M. = Westerlund, "IPv6 and
UDP = Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC = 6935,
DOI = 10.17487/RFC6935, April 2013, = DOI 10.17487/RFC6935, April 2013,
= <https://www.rfc-editor.org/info/rfc6935>. = <https://www.rfc-editor.org/info/rfc6935>.
=
[RFC6936] = Fairhurst, G. and M. Westerlund, "Applicability Statement = [RFC6936] Fairhurst, G. and M. Westerlund, = "Applicability Statement
for = the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with = Zero Checksums",
RFC = 6936, DOI 10.17487/RFC6936, April 2013, = RFC 6936, DOI 10.17487/RFC6936, April 2013,
= <https://www.rfc-editor.org/info/rfc6936>. = <https://www.rfc-editor.org/info/rfc6936>.
=
= [RFC7052] Schudel, = G., Jain, A., and V. Moreno, "Locator/ID
= = Separation Protocol (LISP) MIB", RFC 7052,
= DOI = 10.17487/RFC7052, October 2013,
= = <https://www.rfc-editor.org/info/rfc7052>.
=
= [RFC7215] Jakab, = L., Cabellos-Aparicio, A., Coras, F., Domingo-
= Pascual, = J., and D. Lewis, "Locator/Identifier Separation
= Protocol = (LISP) Network Element Deployment
= = Considerations", RFC 7215, DOI 10.17487/RFC7215, April
= 2014, = <https://www.rfc-editor.org/info/rfc7215>.
=
= [RFC7835] Saucez, = D., Iannone, L., and O. Bonaventure, "Locator/ID
= = Separation Protocol (LISP) Threat Analysis", RFC 7835,
= DOI = 10.17487/RFC7835, April 2016,
= = <https://www.rfc-editor.org/info/rfc7835>.
= =
[RFC8060] = Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical = [RFC8060] Farinacci, D., Meyer, D., and J. = Snijders, "LISP Canonical
= Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, = Address Format (LCAF)", RFC 8060, = DOI 10.17487/RFC8060,
= February 2017, <https://www.rfc-editor.org/info/rfc8060>. = February 2017, = <https://www.rfc-editor.org/info/rfc8060>.
=
= [RFC8061] = Farinacci, D. and B. Weis, "Locator/ID Separation = Protocol
= (LISP) = Data-Plane Confidentiality", RFC 8061,
= DOI = 10.17487/RFC8061, February 2017,
= = <https://www.rfc-editor.org/info/rfc8061>.
=
= [RFC8111] Fuller, = V., Lewis, D., Ermagan, V., Jain, A., and A.
= Smirnov, = "Locator/ID Separation Protocol Delegated
= Database = Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
= May 2017, = <https://www.rfc-editor.org/info/rfc8111>.
= =
Appendix A. = Acknowledgments Appendix A. = Acknowledgments
=
An initial = thank you goes to Dave Oran for planting the seeds for the = An initial thank you goes to Dave Oran for = planting the seeds for the
initial ideas = for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues = to provide value
to the LISP = authors. to the LISP = authors.
=
A special and = appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel = Chiappa for
providing = architectural impetus over the past decades on separation = providing architectural impetus over the = past decades on separation
of location = and identity, as well as detailed reviews of the LISP of location and identity, as well as detailed reviews = of the LISP
architecture = and documents, coupled with enthusiasm for making LISP a = architecture and documents, coupled with = enthusiasm for making LISP a
=
skipping = to change at page 52, line = 5 =C2=B6 = skipping to change at page 51, line = 5 =C2=B6
The LISP = working group would like to give a special thanks to Jari = The LISP working group would like to give a = special thanks to Jari
Arkko, the = Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set = of LISP
documents were = being prepared for IESG last call, and for his documents were being prepared for IESG last call, and = for his
meticulous = reviews and detailed commentaries on the 7 working group = meticulous reviews and detailed commentaries = on the 7 working group
last call = documents progressing toward standards-track RFCs. last call documents progressing toward = standards-track RFCs.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-06 = B.1. Changes to draft-ietf-lisp-rfc6830bis-08
=
= o Posted December = 2017.
=
= o Remove references = to research work for any protocol mechanisms.
=
= o Document scanned = to make sure it is RFC 2119 compliant.
=
= o Made changes to = reflect comments from document WG shepherd Luigi
= = Iannone.
=
= o Ran IDNITs on the = document.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-06 B.3. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping = to change at page 52, line = 35 =C2=B6 = skipping to change at page 51, line = 48 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addreses can be used. = o Clarify when private addreses can be used.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-05 B.4. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Reencapsulating Tunnel Router is an RTR. o Make it clear that a Reencapsulating Tunnel Router = is an RTR.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-04 B.5. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-03 B.6. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-02 B.7. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-01 B.8. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-00 B.9. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = farinacci@gmail.com EMail: = farinacci@gmail.com
= =
Vince = Fuller Vince Fuller
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = vince.fuller@gmail.com EMail: = vince.fuller@gmail.com
=
Dave = Meyer Dave Meyer
Cisco = Systems Cisco Systems
 End of changes. 107 change = blocks. 
395 lines changed or = deleted 339 lines changed or = added

This = html diff was produced by rfcdiff 1.46. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_FAEFD238-FB88-4833-9DAE-41AB577F17A5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_FAEFD238-FB88-4833-9DAE-41AB577F17A5 Content-Disposition: attachment; filename=draft-ietf-lisp-rfc6830bis-08.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-rfc6830bis-08.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer Expires: June 29, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech December 26, 2017 The Locator/ID Separation Protocol (LISP) draft-ietf-lisp-rfc6830bis-08 Abstract This document describes the data-plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 29, 2018. Farinacci, et al. Expires June 29, 2018 [Page 1] =0C Internet-Draft LISP December 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 11 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 13 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 15. Router Performance Considerations . . . . . . . . . . . . . . 35 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 35 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 Farinacci, et al. Expires June 29, 2018 [Page 2] =0C Internet-Draft LISP December 2017 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39 17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 40 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 43 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 50 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 50 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 51 B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 51 B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 51 B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 51 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 B.6. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 B.7. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52 B.8. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52 B.9. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction This document describes the Locator/Identifier Separation Protocol (LISP). LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [CHIAPPA]. As a result LISP creates two namespaces: Endpoint Identifiers (EIDs), that are used to identify end-hosts (e.g., nodes or Virtual Machines) and routable Routing Locators (RLOCs), used to identify network attachment points. LISP then defines functions for mapping between the two namespaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. LISP encapsulation uses a dynamic form of tunneling where no static provisioning is required or necessary. LISP is an overlay protocol that separates control from data-plane, this document specifies the data-plane, how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the Farinacci, et al. Expires June 29, 2018 [Page 3] =0C Internet-Draft LISP December 2017 appropriate location. Tunnel routers are equipped with a cache, called map-cache, that contains EID-to-RLOC mappings. The map-cache is populated using the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. LISP does not require changes to either host protocol stack or to underlay routers. By separating the EID from the RLOC space, LISP offers native Traffic Engineering, multihoming and mobility, among other features. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]) This document specifies the LISP data-plane encapsulation and other LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] specifies the LISP control plane. LISP deployment guidelines can be found in [RFC7215] and [RFC6835] describes considerations for network operational management. Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet. An address family that pertains to the data-plane. See [AFN] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0. Anycast Address: Anycast Address is a term used in this document to refer to the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in each of their own address spaces. Client-side: Client-side is a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in forwarding a packet from the source EID. Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header Farinacci, et al. Expires June 29, 2018 [Page 4] =0C Internet-Draft LISP December 2017 destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host if the destination EID is in the EID-Prefix range configured on the ETR. Otherwise, the packet is discarded. A Data-Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. When using Data-Probes, by sending Map-Requests on the underlying routing system, EID-Prefixes must be advertised. Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own globally visible IP addresses. Note that there MAY be transient conditions when the EID-Prefix for the site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used. EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID- to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope. EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID- Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. End-System: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP Farinacci, et al. Expires June 29, 2018 [Page 5] =0C Internet-Draft LISP December 2017 header when communicating globally (i.e., outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example, through a Domain Name System (DNS) [RFC1034] lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. An EID is allocated to a host from an EID-Prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site MAY have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called an "LEID". Throughout this document, any references to "EID" refer to an LEID. Ingress Tunnel Router (ITR): An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its routable RLOCs (in the RLOC space) in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC MAY be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating host's supplied EID). Farinacci, et al. Expires June 29, 2018 [Page 6] =0C Internet-Draft LISP December 2017 LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP- specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips. LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), or Proxy-ETR (PETR). LISP Site: LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network. Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 10. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well-defined actions that are encoded in a Negative Map-Reply. Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider to which a site connects. Typically, each block is a sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. Provider-Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g., from a particular service provider) and are therefore not topologically aggregatable in the routing system. Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites. Farinacci, et al. Expires June 29, 2018 [Page 7] =0C Internet-Draft LISP December 2017 Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites. Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header. Re-Encapsulating Tunneling Router (RTR): An RTR acts like an ETR to remove a LISP header, then acts as an ITR to prepend a new LISP header. This is known as Re-encapsulating Tunneling. Doing this allows a packet to be re-routed by the RTR without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured. When using multiple mapping database systems, care must be taken to not create re- encapsulation loops through misconfiguration. Route-Returnability: Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message. Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Server-side: Server-side is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID. TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. Farinacci, et al. Expires June 29, 2018 [Page 8] =0C Internet-Draft LISP December 2017 TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router. 4. Basic Overview One key concept of LISP is that end-systems operate the same way they do today. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. Another key LISP concept is the "Tunnel Router". A Tunnel Router prepends LISP headers on host-originated packets and strips them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips the new header. The ITR performs EID-to- RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems only send to addresses that are EIDs. They don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change. o EIDs are typically IP addresses assigned to hosts. Farinacci, et al. Expires June 29, 2018 [Page 9] =0C Internet-Draft LISP December 2017 o Other types of EID are supported by LISP, see [RFC8060] for further information. o LISP routers mostly deal with Routing Locator addresses. See details in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks. o When a router originates packets, it MAY use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure SHell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it MAY use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o Packets with EIDs in them are not expected to be delivered end-to- end in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication or to be encapsulated for inter-site communication. o EID-Prefixes are likely to be hierarchically assigned in a manner that is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. o EIDs MAY also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS). An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document recommends that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the Farinacci, et al. Expires June 29, 2018 [Page 10] =0C Internet-Draft LISP December 2017 first prepended header is used at a site for Location/Identity separation and the second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. Another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility. 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow, including also control-plane information as specified in [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following conditions: o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site. o A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. Map-Requests are sent to the mapping database system by using the LISP control-plane protocol documented in [I-D.ietf-lisp-rfc6833bis]. o Map-Replies are sent on the underlying routing system topology using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol. Client host1.abc.example.com wants to communicate with server host2.xyz.example.com: 1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This Farinacci, et al. Expires June 29, 2018 [Page 11] =0C Internet-Draft LISP December 2017 address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [I-D.ietf-lisp-rfc6833bis] for further information. 3. The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. 4. The mapping system helps forwarding the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. 6. The ITR receives the Map-Reply message, parses the message (to check for format validity), and stores the mapping information from the packet. This information is stored in the ITR's EID-to- RLOC map-cache. Note that the map-cache is an on-demand cache. An ITR will manage its map-cache in such a way that optimizes for its resource constraints. 7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host. 9. In order to defer the need for a mapping lookup in the reverse direction, an ETR can OPTIONALLY create a cache entry that maps the source EID (inner-header source IP address) to the source Farinacci, et al. Expires June 29, 2018 [Page 12] =0C Internet-Draft LISP December 2017 RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC. 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Unreachable/Fragmentation-Needed message is returned to the source. In the case when fragmentation is needed, this specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 7. Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported. Additional types of EIDs are defined in [RFC8060]. 5.1. LISP IPv4-in-IPv4 Header Format Farinacci, et al. Expires June 29, 2018 [Page 13] =0C Internet-Draft LISP December 2017 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL | DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL | DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IHL =3D IP-Header-Length 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | Farinacci, et al. Expires June 29, 2018 [Page 14] =0C Internet-Draft LISP December 2017 r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header (IH): The inner header is the header on the datagram received from the originating host [RFC0791] [RFC8200] [RFC2474]. The source and destination IP addresses are EIDs. Outer Header: (OH) The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress Farinacci, et al. Expires June 29, 2018 [Page 15] =0C Internet-Draft LISP December 2017 router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 7.1 and 7.2. UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 12 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341. UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP zero checksums over IPv6 for all tunneling protocols, including LISP, is subject to the applicability statement in [RFC6936]. UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers. N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a Nonce. See Section 10.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a Nonce value present. L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use. Farinacci, et al. Expires June 29, 2018 [Page 16] =0C Internet-Draft LISP December 2017 x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP- encapsulated packets when the ITR is also an ETR. See Section 10.1 for details. V: The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to Section 13.3 for more details. This bit indicates that the LISP header is encoded in this case as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: The I-bit is the Instance ID bit. See Section 8 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this: x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R: The R-bit is a Reserved bit for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt. KK: The KK-bits are a 2-bit field used when encapsualted packets are encrypted. The field is set to 00 when the packet is not encrypted. See [RFC8061] for further information. Farinacci, et al. Expires June 29, 2018 [Page 17] =0C Internet-Draft LISP December 2017 LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different destinations. However, the same nonce can be used for a period of time to the same destination. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 10.1 for more details. LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 10 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'. When doing ITR/PITR encapsulation: o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field. o The outer-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header 'Type of Service' field (with one exception; see below). When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header Farinacci, et al. Expires June 29, 2018 [Page 18] =0C Internet-Draft LISP December 2017 to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. o The inner-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header 'Type of Service' field (with one exception; see below). Note that if an ETR/PETR is also an ITR/PITR and chooses to re- encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 18.3 for TTL exception handling for traceroute packets. The Explicit Congestion Notification ('ECN') field occupies bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC3168]. The 'ECN' field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. An ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR/ PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. 6. LISP EID-to-RLOC Map-Cache ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- RLOC Map-Cache, that contains mappings from EID-prefixes to locator sets. The cache is used to encapsulate packets from the EID space to the corresponding RLOC network attachment point. When an ITR/PITR receives a packet from inside of the LISP site to destinations outside of the site a longest-prefix match lookup of the EID is done to the map-cache. Farinacci, et al. Expires June 29, 2018 [Page 19] =0C Internet-Draft LISP December 2017 When the lookup succeeds, the locator-set retrieved from the map- cache is used to send the packet to the EID's topological location. If the lookup fails, the ITR/PITR needs to retrieve the mapping using the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The mapping is then stored in the local map-cache to forward subsequent packets addressed to the same EID-prefix. The map-cache is a local cache of mappings, entries are expired based on the associated Time to live. In addition, entries can be updated with more current information, see Section 13 for further information on this. Finally, the map-cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. 7. Dealing with Large Encapsulated Packets This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism SHOULD be implemented. Both or neither can be used, since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Both stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below referring to an ITR also apply to a TE-ITR. 7.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: 1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths. 2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet. 3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR MUST receive from the source so the effective MTU can be met. That is, L =3D S + H. Farinacci, et al. Expires June 29, 2018 [Page 20] =0C Internet-Draft LISP December 2017 When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets (meaning the received packet size was greater than S octets from the source), it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMP Unreachable/ Fragmentation-Needed message to the source with a value of S, where S is (L - H). When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification RECOMMENDS that L be defined as 1500. 7.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR. 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Unreachable/Fragmentation-Needed message to the ITR. The ITR will parse the ICMP message to determine which Locator is Farinacci, et al. Expires June 29, 2018 [Page 21] =0C Internet-Draft LISP December 2017 affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Unreachable/ Fragmentation-Needed message back to the source. The packet size advertised by the ITR in the ICMP Unreachable/Fragmentation- Needed message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 8. Using Virtualization and Segmentation with LISP There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies or multi-tenant virtualization. For these and other scenarios where segregation is needed, Instance IDs are used. An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case details. The Instance ID that is stored in the mapping database when LISP-DDT [RFC8111] is used is 32 bits in length. That means the control-plane can store more instances than a given data-plane can use. Multiple data-planes can use the same 32-bit space as long as the low-order 24 bits don't overlap among xTRs. Farinacci, et al. Expires June 29, 2018 [Page 22] =0C Internet-Draft LISP December 2017 9. Routing Locator Selection Both the client-side and server-side MAY need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the 'Priority' and 'Weight' fields in EID- to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following are different scenarios for choosing RLOCs and the controls that are available: o The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection. o The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o The server-side sets a Weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server- side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable. o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer- header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding Farinacci, et al. Expires June 29, 2018 [Page 23] =0C Internet-Draft LISP December 2017 cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large. o A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map- Cache entry for the "gleaned" EID and is stored and used for the time indicated from the 'TTL' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry. This "gleaning" mechanism is OPTIONAL. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the Locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section. 10. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR MAY receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions. 3. An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address. Farinacci, et al. Expires June 29, 2018 [Page 24] =0C Internet-Draft LISP December 2017 4. An ITR MAY receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR MAY receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator reachability algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Farinacci, et al. Expires June 29, 2018 [Page 25] =0C Internet-Draft LISP December 2017 Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix. Refer to Section 19 for security related issues regarding Locator-Status-Bits. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map- Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages. If an ITR does receive an ICMP Network Unreachable or Host Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a Locator-Set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default- Free Zone (DFZ), it can decide to not use the Locator even though the Locator-Status-Bits indicate that the Locator is up. In this case, the path from the ITR to the ETR that is assigned the Locator is not available. More details are in [I-D.meyer-loc-id-implications]. Optionally, an ITR can send a Map-Request to a Locator, and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with Priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets, since that increases the risk of packet loss for end-to-end sessions. Farinacci, et al. Expires June 29, 2018 [Page 26] =0C Internet-Draft LISP December 2017 When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true, due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability. 10.1. Echo Nonce Algorithm When data flows bidirectionally between Locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the echo-nonce-request state, then the path to the ETR is unreachable. This decision MAY be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR MAY both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation-specific setting. However, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and subsequently continue sending echo-nonce-request packets. Farinacci, et al. Expires June 29, 2018 [Page 27] =0C Internet-Draft LISP December 2017 This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site MAY not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- probe Map-Reply message. Note other Locator Reachability mechanisms can be used to compliment or even override the echo nonce algorithm. See the next section for an example of control-plane probing. 10.2. RLOC-Probing Algorithm RLOC-Probing is a method that an ITR or PITR can use to determine the reachability status of one or more Locators that it has cached in a Map-Cache entry. The probe-bit of the Map-Request and Map-Reply messages is used for RLOC-Probing. RLOC-Probing is done in the control plane on a timer basis, where an ITR or PITR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-probes are sent periodically using a jittered timer interval. When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping data for the EID-Prefix contained in the Map-Request. This provides the opportunity for the ITR or PITR that sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC-Probing. The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is Farinacci, et al. Expires June 29, 2018 [Page 28] =0C Internet-Draft LISP December 2017 reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) estimates between a pair of Locators, which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC-Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times is very small. 11. EID Reachability within a LISP Site A site MAY be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID- Prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header. It is recognized that there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-Prefix range is partitioned and which Locators can reach any sub- ranges of the EID-Prefixes. Note that this is not a new problem introduced by the LISP architecture. The problem exists today when a multihomed site uses BGP to advertise its reachability upstream. 12. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache of a requesting ITR, the Locator-Set for the EID-Prefix MAY contain different Priority and Weight values for each locator address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators. The following hash algorithm MAY be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and Farinacci, et al. Expires June 29, 2018 [Page 29] =0C Internet-Draft LISP December 2017 destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping. 3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers that are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets that are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. 13. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, it is desirable to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When adding a new Locator record in lexicographic order to the end of a Locator-Set, it is easy to update mappings. We assume that new mappings will maintain the same Locator ordering as the old mapping but will just have new Locators appended to the end of the list. So, some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses Farinacci, et al. Expires June 29, 2018 [Page 30] =0C Internet-Draft LISP December 2017 that are lexicographically greater than the locator addresses in the existing Locator-Set. When a Locator record is inserted in the middle of a Locator-Set, to maintain lexicographic order, the SMR procedure in Section 13.2 is used to inform ITRs and PITRs of the new Locator-Status-Bit mappings. When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed. We propose here three approaches for Locator-Set compaction: one operational mechanism and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. 13.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, there is a 24-hour window to time out old mappings. The following clock sweep procedure is used: 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1-hour window, the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. Farinacci, et al. Expires June 29, 2018 [Page 31] =0C Internet-Draft LISP December 2017 4. At the end of the 1-hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So, any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a TTL equal to the TTL in the Map-Reply. 13.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data. This can only occur when both ITR and ETR functionality reside in the same router. An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches. 2. A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected, and the EID-Prefix used is the one copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request. 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map-Versioning as described in Section 13.3 is used, an SMR Farinacci, et al. Expires June 29, 2018 [Page 32] =0C Internet-Draft LISP December 2017 sender can detect if an ITR is using the most up-to-date database mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- limited. This is important to avoid Map-Reply implosion. 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map- Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it may not send an SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all Locators in the Locator-Set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case they will send Map-Requests to obtain a Map-Cache entry. 13.3. Database Map-Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 13.2 occurs. Farinacci, et al. Expires June 29, 2018 [Page 33] =0C Internet-Draft LISP December 2017 An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version Number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects that the Source Map- Version Number is greater than the last Map-Version Number sent in a Map-Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-Prefix, so values that are greater are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map- Version Number. See [RFC6834] for a more detailed analysis and description of Database Map-Versioning. 14. Multicast Considerations A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determine where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, can use the same group address as the destination Routing Locator, use a multicast or unicast Routing Locator obtained from a Mapping System lookup, or use other means to determine the group address mapping. With respect to the source Routing Locator address, the ITR prepends its own IP address as the source address of the outer IP header. Just like it would if the destination EID was a unicast address. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable. Farinacci, et al. Expires June 29, 2018 [Page 34] =0C Internet-Draft LISP December 2017 There are two approaches for LISP-Multicast, one that uses native multicast routing in the underlay with no support from the Mapping System and the other that uses only unicast routing in the underlay with support from the Mapping System. See [RFC6831] and [I-D.ietf-lisp-signal-free-multicast], respectively, for details. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832]. 15. Router Performance Considerations LISP is designed to be very "hardware-based forwarding friendly". A few implementation techniques can be used to incrementally implement LISP: o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control-plane processing SHOULD be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data- plane. o On an ITR, prepending a new IP header consists of adding more octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. For performance issues related to map-cache management, see Section 19. 16. Mobility Considerations There are several kinds of mobility, of which only some might be of concern to LISP. Essentially, they are as follows. Farinacci, et al. Expires June 29, 2018 [Page 35] =0C Internet-Draft LISP December 2017 16.1. Slow Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-to-RLOC mappings for sites are expected to be handled by configuration, outside of LISP. An individual endpoint wishes to move but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs [RFC4984]. 16.2. Fast Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP-layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and primarily where interactions with LISP need to be explored, such as the mechanisms in [I-D.ietf-lisp-eid-mobility] when the EID moves but the RLOC is in the network infrastructure. In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-to-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have an internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything that decreases the number of new EID- to-RLOC mappings needed when a node moves, or maintains the validity of an EID-to-RLOC mapping for a longer time, is useful. In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same, and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. Farinacci, et al. Expires June 29, 2018 [Page 36] =0C Internet-Draft LISP December 2017 If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. See [I-D.ietf-lisp-predictive-rlocs] for more recent mechanisms which can provide near-zero packet loss during handoffs. 16.3. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Refer to [I-D.ietf-lisp-mn] for more details for when the EID and RLOC are co-located in the roaming node. 17. LISP xTR Placement and Encapsulation Methods This section will explore how and where ITRs and ETRs can be placed in the network and will discuss the pros and cons of each scenario. For a more detailed networkd design deployment recommendation, refer to [RFC7215]. There are two basic deployment tradeoffs to consider: centralized versus distributed caches; and flat, Recursive, or Re-encapsulating Tunneling. When deciding on centralized versus distributed caching, the following issues SHOULD be considered: o Are the xTRs spread out so that the caches are spread across all the memories of each router? A centralized cache is when an ITR keeps a cache for all the EIDs it is encapsulating to. The packet takes a direct path to the destination Locator. A distributed cache is when an ITR needs help from other Re-Encapsulating Tunnel Routers (RTRs) because it does not store all the cache entries for the EIDs it is encapsulating to. So, the packet takes a path through RTRs that have a different set of cache entries. o Should management "touch points" be minimized by only choosing a few xTRs, just enough for redundancy? Farinacci, et al. Expires June 29, 2018 [Page 37] =0C Internet-Draft LISP December 2017 o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, using more ETRs does require more management, since EID-Prefix-to- RLOC mappings need to be explicitly configured. When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the following issues SHOULD be considered: o Flat tunneling implements a single encapsulation path between the source site and destination site. This generally offers better paths between sources and destinations with a single encapsulation path. o Recursive Tunneling is when encapsulated traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control, since the site is prepending a new encapsulation header. In the case of TE-based tunneling, the site MAY have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive Tunneling generally will result in suboptimal paths but with the benefit of steering traffic to parts of the network that have more resources available. o The technique of Re-Encapsulation ensures that packets only require one encapsulation header. So, if a packet needs to be re- routed, it is first decapsulated by the RTR and then Re- Encapsulated with a new encapsulation header using a new RLOC. The next sub-sections will examine where xTRs and RTRs can reside in the network. 17.1. First-Hop/Last-Hop xTRs By locating xTRs close to hosts, the EID-Prefix set is at the granularity of an IP subnet. So, at the expense of more EID-Prefix- to-RLOC sets for the site, the caches in each xTR can remain relatively small. But caches always depend on the number of non- aggregated EID destination flows active through these xTRs. With more xTRs doing encapsulation, the increase in control traffic grows as well: since the EID granularity is greater, more Map- Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios than their core router counterparts. Memory is typically less expensive in these devices, and fewer routes Farinacci, et al. Expires June 29, 2018 [Page 38] =0C Internet-Draft LISP December 2017 are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing states. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices. 17.2. Border/Edge xTRs Using Customer Edge (CE) routers for xTR placement allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE-based xTRs for that site. This offers the opposite benefit of the first-hop/last-hop xTR scenario: the number of mapping entries and network management touch points is reduced, allowing better scaling. One disadvantage is that fewer network resources are used to reach host endpoints, thereby centralizing the point-of-failure domain and creating network choke points at the CE xTR. Note that more than one CE xTR at a site can be configured with the same IP address. In this case, an RLOC is an anycast address. This allows resilience between the CE xTRs. That is, if a CE xTR fails, traffic is automatically routed to the other xTRs using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast Locators is the limited advertisement scope of /32 (or /128 for IPv6) routes. 17.3. ISP Provider Edge (PE) xTRs The use of ISP PE routers as xTRs is not the typical deployment scenario envisioned in this specification. This section attempts to capture some of the reasoning behind this preference for implementing LISP on CE routers. The use of ISP PE routers for xTR placement gives an ISP, rather than a site, control over the location of the ETRs. That is, the ISP can decide whether the xTRs are in the destination site (in either CE xTRs or last-hop xTRs within a site) or at other PE edges. The advantage of this case is that two encapsulation headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for a new encapsuluation path to the destination end site. Farinacci, et al. Expires June 29, 2018 [Page 39] =0C Internet-Draft LISP December 2017 An obvious disadvantage is that the end site has no control over where its packets flow or over the RLOCs used. Other disadvantages include difficulty in synchronizing path liveness updates between CE and PE routers. As mentioned in earlier sections, a combination of these scenarios is possible at the expense of extra packet header overhead; if both site and provider want control, then Recursive or Re-Encapsulating Tunnels are used. 17.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control message MUST be a routable address and therefore [RFC1918] addresses SHOULD only be presence when running in a local environment. When a LISP xTR is configured with private RLOC addresses and resides behind a NAT device and desires to communicate on the Internet, the private addresses MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed when LISP VPNs are not in use. Both NAT translation and LISP encapsulation functions could be co- located in the same device. 17.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache MAY not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. 18. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from the ITR to the ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Farinacci, et al. Expires June 29, 2018 [Page 40] =0C Internet-Draft LISP December 2017 Segment 1 (in source LISP site based on EIDs): source host ---> first hop ... next hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next hop ... next hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next hop ... last hop ---> destination host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal manner as they are today. The ITR performs a TTL decrement and tests for 0 before encapsulating. Therefore, the ITR's hop is seen by the traceroute source as having an EID address (the address of the site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destinations of the ICMP messages are the ITR RLOC address and the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client and also retain the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0, as the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 18.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above, since the entire traceroute data packet is included in the ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention to forwarding ICMP messages back to the traceroute source. Farinacci, et al. Expires June 29, 2018 [Page 41] =0C Internet-Draft LISP December 2017 18.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure, since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 octets that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended, followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source, is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload, thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value. 18.3. Traceroute Using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, one cannot get all 3 segments of the traceroute. Segment 2 of the traceroute cannot be conveyed to the traceroute source, since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. Farinacci, et al. Expires June 29, 2018 [Page 42] =0C Internet-Draft LISP December 2017 19. Security Considerations Security considerations for LISP are discussed in [RFC7833], in addition [I-D.ietf-lisp-sec] provides authentication and integrity to LISP mappings. A complete LISP threat analysis can be found in [RFC7835], in what follows we provide a summary. The optional mechanisms of gleaning is offered to directly obtain a mapping from the LISP encapsulated packets. Specifically, an xTR can learn the EID-to-RLOC mapping by inspecting the source RLOC and source EID of an encapsulated packet, and insert this new mapping into its map-cache. An off-path attacker can spoof the source EID address to divert the traffic sent to the victim's spoofed EID. If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim;s RLOC, potentially overloading it. The LISP Data-Plane defines several mechanisms to monitor RLOC data- plane reachability, in this context Locator-Status Bits, Nonce- Present and Echo-Nonce bits of the LISP encapsulation header can be manipulated by an attacker to mount a DoS attack. An off-path attacker able to spoof the RLOC of a victim's xTR can manipulate such mechanisms to declare a set of RLOCs unreachable. This can be used also, for instance, to declare only one RLOC reachable with the aim of overload it. Map-Versioning is a data-plane mechanism used to signal a peering xTR that a local EID-to-RLOC mapping has been updated, so that the peering xTR uses LISP Control-Plane signaling message to retrieve a fresh mapping. This can be used by an attacker to forge the map- versioning field of a LISP encapsulated header and force an excessive amount of signaling between xTRs that may overload them. Most of the attack vectors can be mitigated with careful deployment and configuration, information learned opportunistically (such as LSB or gleaning) SHOULD be verified with other reachability mechanisms. In addition, systematic rate-limitation and filtering is an effective technique to mitigate attacks that aim to overload the control-plane. 20. Network Management Considerations Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [RFC7052] and [RFC6835]. Farinacci, et al. Expires June 29, 2018 [Page 43] =0C Internet-Draft LISP December 2017 21. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this data-plane LISP specification, in accordance with BCP 26 [RFC8126]. 21.1. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for lisp-data and lisp-control operation, respectively. IANA has updated the description for UDP ports 4341 and 4342 as follows: lisp-data 4341 udp LISP Data Packets lisp-control 4342 udp LISP Control Packets 22. References 22.1. Normative References [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-07 (work in progress), December 2017. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . Farinacci, et al. Expires June 29, 2018 [Page 44] =0C Internet-Draft LISP December 2017 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 22.2. Informative References [AFN] IANA, "Address Family Numbers", August 2016, . [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, . Farinacci, et al. Expires June 29, 2018 [Page 45] =0C Internet-Draft LISP December 2017 [I-D.ietf-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-ietf-lisp-eid-mobility-01 (work in progress), November 2017. [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-lisp-mn] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", draft-ietf-lisp-mn-01 (work in progress), October 2017. [I-D.ietf-lisp-predictive-rlocs] Farinacci, D. and P. Pillay-Esnault, "LISP Predictive RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in progress), November 2017. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 (work in progress), October 2017. [I-D.ietf-lisp-signal-free-multicast] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", draft-ietf-lisp-signal-free-multicast-07 (work in progress), November 2017. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in progress), November 2017. [I-D.meyer-loc-id-implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01 (work in progress), January 2009. [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996. Farinacci, et al. Expires June 29, 2018 [Page 46] =0C Internet-Draft LISP December 2017 [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, DOI 10.17487/RFC4192, September 2005, . [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, DOI 10.17487/RFC4866, May 2007, . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, . Farinacci, et al. Expires June 29, 2018 [Page 47] =0C Internet-Draft LISP December 2017 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, . [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, . [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, DOI 10.17487/RFC7052, October 2013, . [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . Farinacci, et al. Expires June 29, 2018 [Page 48] =0C Internet-Draft LISP December 2017 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, . Farinacci, et al. Expires June 29, 2018 [Page 49] =0C Internet-Draft LISP December 2017 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, Alia Atlas, Florin Coras and Alberto Rodriguez. This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC. The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward standards-track RFCs. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] Farinacci, et al. Expires June 29, 2018 [Page 50] =0C Internet-Draft LISP December 2017 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 o Posted December 2017. o Remove references to research work for any protocol mechanisms. o Document scanned to make sure it is RFC 2119 compliant. o Made changes to reflect comments from document WG shepherd Luigi Iannone. o Ran IDNITs on the document. B.2. Changes to draft-ietf-lisp-rfc6830bis-07 o Posted November 2017. o Rephrase how Instance-IDs are used and don't refer to [RFC1918] addresses. B.3. Changes to draft-ietf-lisp-rfc6830bis-06 o Posted October 2017. o Put RTR definition before it is used. o Rename references that are now working group drafts. o Remove "EIDs MUST NOT be used as used by a host to refer to other hosts. Note that EID blocks MAY LISP RLOCs". o Indicate what address-family can appear in data packets. o ETRs may, rather than will, be the ones to send Map-Replies. o Recommend, rather than mandate, max encapsulation headers to 2. o Reference VPN draft when introducing Instance-ID. o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Clarify when private addreses can be used. B.4. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Reencapsulating Tunnel Router is an RTR. Farinacci, et al. Expires June 29, 2018 [Page 51] =0C Internet-Draft LISP December 2017 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 o Posted July 2017. o Changed reference of IPv6 RFC2460 to RFC8200. o Indicate that the applicability statement for UDP zero checksums over IPv6 adheres to RFC6936. B.6. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. B.7. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. B.8. Changes to draft-ietf-lisp-rfc6830bis-01 o Posted March 2017. o Include references to new RFCs published. o Change references from RFC6833 to RFC6833bis. o Clarified LCAF text in the IANA section. o Remove references to "experimental". B.9. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses Farinacci, et al. Expires June 29, 2018 [Page 52] =0C Internet-Draft LISP December 2017 Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: farinacci@gmail.com Vince Fuller Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: vince.fuller@gmail.com Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: dmm@1-4-5.net Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: darlewis@cisco.com Albert Cabellos UPC/BarcelonaTech Campus Nord, C. Jordi Girona 1-3 Barcelona, Catalunya Spain EMail: acabello@ac.upc.edu Farinacci, et al. Expires June 29, 2018 [Page 53] --Apple-Mail=_FAEFD238-FB88-4833-9DAE-41AB577F17A5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_FAEFD238-FB88-4833-9DAE-41AB577F17A5-- From nobody Tue Dec 26 21:20:47 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFBD1241F5 for ; Tue, 26 Dec 2017 21:20:45 -0800 (PST) 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_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 W4Rw2Ywy1TKx for ; Tue, 26 Dec 2017 21:20:44 -0800 (PST) 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 070D61201FA for ; Tue, 26 Dec 2017 21:20:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E1979D4012F; Tue, 26 Dec 2017 21:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1514352043; bh=RlDhpO5SUES2kv++9Y+5qzlYSb8gC/uWGSRVQ9gPu8Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CB+giH/WZ6LH2jmwes58ZNGrXdj0AmJ9EU6K/SZ606qbH67zFgVpVNtD0CwbHdYc6 rPMNpfThM9aVy0O4jhwyKqNBVLsZlObzZyeyRrDiBW7Lit3J8AUTKdjtZM8YlZcHr0 QNn0pIAdbG/cKS8Rx9awtaKZVJcWNHHMFclWR2Gs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 451602403E7; Tue, 26 Dec 2017 21:20:43 -0800 (PST) To: Dino Farinacci , Albert Cabellos Cc: "lisp@ietf.org list" , lisp-chairs@tools.ietf.org References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 27 Dec 2017 00:20:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] 6830bis Review - scalability X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 05:20:46 -0000 Clearly, scalability of LISP matters. However, we are explicitly not attempting to move LISP to standards track for purposes of solving global Internet address scaling problems. The agreement under which we are doing this is to focus on the value of the other uses of LISP. To put it simply Dino, if we try to make the argument that LISP is suitable for Internet-scale deployment, and for solving the core growth difficulties, we will have a large set of additional arguments to undertake. If we focus on what we have agreed, we get Proposed Standards without having that fight. And we get to use a PS for all sorts of interesting and desirable tasks. Yours, Joel On 12/26/17 11:13 PM, Dino Farinacci wrote: > I will comment here before providing a new update and response to Luigi’s latest email. > >> On Dec 26, 2017, at 5:48 PM, Albert Cabellos wrote: >> >> Hi >> >> Thanks for the review, please find my comments inline. >> >> I have removed all the comments for which I **agree**: >> >>> >>> Provider-Assigned (PA) Addresses: PA addresses are an address block >>> assigned to a site by each service provider to which a site >>> connects. Typically, each block is a sub-block of a service >>> provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and >>> is aggregated into the larger block before being advertised into >>> the global Internet. Traditionally, IP multihoming has been >>> implemented by each multihomed site acquiring its own globally >>> visible prefix. LISP uses only topologically assigned and >>> aggregatable address blocks for RLOCs, eliminating this >>> demonstrably non-scalable practice. >>> >>> Last sentence to be deleted is a relic of scalability discussion. >>> >>> >> >> Agreed. I suggest deleting entirely the definitions for both PA and PI, they are not used throughout the document. > > Note, we still care about scalability of any underlay, especially the Internet core, so we should leave this in. Note, we ARE still solving the scalability problem. > > I don’t know why any of you would think differently. > From nobody Tue Dec 26 21:28:35 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8521241F5 for ; Tue, 26 Dec 2017 21:28:34 -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, FREEMAIL_FROM=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 8Tg7b79qv_V1 for ; Tue, 26 Dec 2017 21:28:32 -0800 (PST) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC151201FA for ; Tue, 26 Dec 2017 21:28:32 -0800 (PST) Received: by mail-pl0-x22e.google.com with SMTP id b12so18955458plm.3 for ; Tue, 26 Dec 2017 21:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J6aXxrlISIY5u+82CirceJrGRglue6wqk06+EidKrx0=; b=idbg/DmpHffEw2Ell4zGrUrjtdfmyjMajJTSezDU8aFFcQqOfLqUFqR9qt3hQRg7e+ bNwOVfLDOH2IdRqXTDo9nwk/VDWBFjXRGEGIOc2zOP4/4W7tV+oWqf89sm8BZkRTDFV0 lq5ztamZTJG3mr5IzmQG3/fhL9otXwSwlgu8azH6AYveuDsOWSwicL3n9oUILmN6BtWB 38KghUHn81Oj7pMYYq141fSI9XUKEpUILdxMJYx9olK2LfIyk9+kpxQRPue0p763AF3o QzV/ZBv8bPrkO64ukALKeJxHgkf11Io/G4P4fhMp5HJc+JTxJ8pDgtNhXHfYIUvt+PI6 4BSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J6aXxrlISIY5u+82CirceJrGRglue6wqk06+EidKrx0=; b=iN0bsxs9kkqF2GGL1Yz92kUzRAV3JuFF3nYpyMNHXXk/TmRFDf6nhlIeXbcnyVCXu6 phv2tcGU11utwmYwLlOkgTf8mucvylpd/sg5kLwnGhkGxZIbQFSfJDYcCPC7dy+za7wT 0tTEMw9x7bXW8M412U6xhKrdaJmXPA6FKDgVTaqOZ03WRN6YUxjm6Yk5KP5e01EUE31N BW9Q3QO0W0eHbeY8r5RwwS55jTZ01ex8jxLP5FodjuWDLSxLLksrffNFZemfZmxtbyjY eHMQr8sywRprtBWxOebEOWkbKmygjUZC3ceiR25am6MNTgYcKqiB1RP9US591jayAxUi 3Qug== X-Gm-Message-State: AKGB3mKauRX2f7vRm/16srkS0/kSkpi2Cjnenflg91SHkFY/8eSxDFr7 8PY+k4deRJPBgVfx10Z7eMY= X-Google-Smtp-Source: ACJfBovj67+5wVfIRWrdfMv1qRaTmCPXaJa9xjSUmHBbPeidYerUbku0qpUkff9DB2IrgDT7FubDQQ== X-Received: by 10.84.133.67 with SMTP id 61mr27729451plf.20.1514352512151; Tue, 26 Dec 2017 21:28:32 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:1ca2:28e8:b31:5b77? ([2603:3024:151c:55f0:1ca2:28e8:b31:5b77]) by smtp.gmail.com with ESMTPSA id u81sm67402363pfa.70.2017.12.26.21.28.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Dec 2017 21:28:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: Date: Tue, 26 Dec 2017 21:28:29 -0800 Cc: Albert Cabellos , "lisp@ietf.org list" , lisp-chairs@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <27C29B7E-D491-4D98-88DF-69E6C7BA8FC7@gmail.com> References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review - scalability X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 05:28:34 -0000 > Clearly, scalability of LISP matters. > However, we are explicitly not attempting to move LISP to standards = track for purposes of solving global Internet address scaling problems. = The agreement under which we are doing this is to focus on the value of = the other uses of LISP. Right, that is not the sole problem to solve. But removing the features = of what overlays bring to the document would not be a good idea. > To put it simply Dino, if we try to make the argument that LISP is = suitable for Internet-scale=20 That is not what the text is saying. The text that people are commenting = on is that the aggregatabeility of RLOC addresses should be present in = the document. > deployment, and for solving the core growth difficulties, we will have = a large set of additional arguments to undertake. If we focus on what = we have agreed, we get Proposed Standards without having that fight. = And we get to use a PS for all sorts of interesting and desirable tasks. I agree that the document should not say we are trying to scale the = Internet. And I believe it does not say that. Dino >=20 > Yours, > Joel >=20 > On 12/26/17 11:13 PM, Dino Farinacci wrote: >> I will comment here before providing a new update and response to = Luigi=E2=80=99s latest email. >>> On Dec 26, 2017, at 5:48 PM, Albert Cabellos = wrote: >>>=20 >>> Hi >>>=20 >>> Thanks for the review, please find my comments inline. >>>=20 >>> I have removed all the comments for which I **agree**: >>>=20 >>>>=20 >>>> Provider-Assigned (PA) Addresses: PA addresses are an address = block >>>> assigned to a site by each service provider to which a site >>>> connects. Typically, each block is a sub-block of a service >>>> provider Classless Inter-Domain Routing (CIDR) [RFC4632] block = and >>>> is aggregated into the larger block before being advertised = into >>>> the global Internet. Traditionally, IP multihoming has been >>>> implemented by each multihomed site acquiring its own globally >>>> visible prefix. LISP uses only topologically assigned and >>>> aggregatable address blocks for RLOCs, eliminating this >>>> demonstrably non-scalable practice. >>>>=20 >>>> Last sentence to be deleted is a relic of scalability discussion. >>>>=20 >>>>=20 >>>=20 >>> Agreed. I suggest deleting entirely the definitions for both PA and = PI, they are not used throughout the document. >> Note, we still care about scalability of any underlay, especially the = Internet core, so we should leave this in. Note, we ARE still solving = the scalability problem. >> I don=E2=80=99t know why any of you would think differently. From nobody Wed Dec 27 16:25:53 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4224126C2F for ; Wed, 27 Dec 2017 16:25:51 -0800 (PST) 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 LOn6fAF7FnLN for ; Wed, 27 Dec 2017 16:25:49 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4561200B9 for ; Wed, 27 Dec 2017 16:25:48 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id r205so8044163ywb.3 for ; Wed, 27 Dec 2017 16:25:48 -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=HOymE9bD59l9deWtWkSiz03gKy81xzohW7MJDe5cZIg=; b=tIPl3QgMhN8Nv7fCKzcwtPGR2KuCBp+aqvuzKtpN3Qunk/lWNLNzGaguywxQri9H4c A4d8Ws85r8cgRFd9doU+kg4WAWDBQpd72UIBWYSgWeoKIA5OG5/b9P3JPKgxZt3ybY75 qhyhb28v+BQiNHoXUtD+XoLoIGPoiFMBQewFnyhYcsZnn/FUbEjfuEy5V2p94RI/JwUL NVfYe355xp78M9ZFeYnkfO7Oh+XFK8aSJ3Gh8/0MpngOQfFqJMyk1fLKDh0PkdYLNAv0 JjA72SzwhK8kqZsBy6WcbxNmjXNW5BHzn5Dy+lgSRBltN6IxwcVFAsZjBar6/1T++pST dJMQ== 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=HOymE9bD59l9deWtWkSiz03gKy81xzohW7MJDe5cZIg=; b=l4YzvMuY2qQh2X4JpyTwMBzGeshyJvyb84xzvSGI0FXIwz2vClqS7cdg2hnH0B4lZP YpSjDz9ZSc5nM+76I7XV7jB7p1BcH4C6ABJTxcnLQKclA3X/QCzfaUKZzRM8iOLsN8GY xz+VP2UyrqAezvflviu3tU7/klUdp10pHzTI6M94UCBIwBfF3N6GpAHuvpc6mP91OshO iNSDatHZ1VTOrtu0n8DIXFp8EGKYY1yTG7D9X76bSfT27Sj1pt0dpRI/rgufrVZscr69 ewsHfwII9/W2uom4cmhB6Cvlj4EObrn9MbTHa5PFoNLQih0Hpc7zyFHCTfWrAAYdJZof qbaQ== X-Gm-Message-State: AKGB3mKjil2sMgjVgm7mgkxJh5Eh1oM6RFBIPm5TY1296GDs4dadXs43 2OS6WNfbH3WU5jGTvLXY69ap/2Xpn72SfjkxAfH4YLID X-Google-Smtp-Source: ACJfBotwoHHPjWLDriQdsU+TE8YP7hw2H64gptdxKZVZvFIuUf5kCNgzsFJOJwnz5TZr1BTqwsnbab3t3qrPhAjRHzo= X-Received: by 10.129.193.5 with SMTP id f5mr20203858ywi.475.1514420747985; Wed, 27 Dec 2017 16:25:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.183.142 with HTTP; Wed, 27 Dec 2017 16:25:47 -0800 (PST) In-Reply-To: <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> From: Albert Cabellos Date: Thu, 28 Dec 2017 01:25:47 +0100 Message-ID: To: Dino Farinacci Cc: Luigi Iannone , "lisp@ietf.org list" , lisp-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary="f403043ee044b967ee05615b8e63" Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 00:25:52 -0000 --f403043ee044b967ee05615b8e63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all Please find my comments inline: On Wed, Dec 27, 2017 at 5:13 AM, Dino Farinacci wrote= : > I will comment here before providing a new update and response to Luigi= =E2=80=99s > latest email. > > > On Dec 26, 2017, at 5:48 PM, Albert Cabellos > wrote: > > > > Hi > > > > Thanks for the review, please find my comments inline. > > > > I have removed all the comments for which I **agree**: > > > > > > > > Provider-Assigned (PA) Addresses: PA addresses are an address blo= ck > > > assigned to a site by each service provider to which a site > > > connects. Typically, each block is a sub-block of a service > > > provider Classless Inter-Domain Routing (CIDR) [RFC4632] block a= nd > > > is aggregated into the larger block before being advertised into > > > the global Internet. Traditionally, IP multihoming has been > > > implemented by each multihomed site acquiring its own globally > > > visible prefix. LISP uses only topologically assigned and > > > aggregatable address blocks for RLOCs, eliminating this > > > demonstrably non-scalable practice. > > > > > > Last sentence to be deleted is a relic of scalability discussion. > > > > > > > > > > Agreed. I suggest deleting entirely the definitions for both PA and PI, > they are not used throughout the document. > > Note, we still care about scalability of any underlay, especially the > Internet core, so we should leave this in. Note, we ARE still solving the > scalability problem. > > I don=E2=80=99t know why any of you would think differently. > We are solving this issue and many others. But the point of the document is specifying a data-plane, not the benefits of this data-plane. > > > > > [snip] > > > > > > > > > Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for > > > IPv6) value used in the source and destination address fields of > > > the first (most inner) LISP header of a packet. The host obtain= s > > > a destination EID the same way it obtains a destination address > > > today, for example, through a Domain Name System (DNS) [RFC1034] > > > lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. > > > The source EID is obtained via existing mechanisms used to set a > > > host's "local" IP address. An EID used on the public Internet > > > must have the same properties as any other IP address used in th= at > > > manner; this means, among other things, that it must be globally > > > unique. An EID is allocated to a host from an EID-Prefix block > > > associated with the site where the host is located. An EID can = be > > > used by a host to refer to other hosts. Note that EID blocks MA= Y > > > be assigned in a hierarchical manner, independent of the network > > > topology, to facilitate scaling of the mapping database. In > > > addition, an EID block assigned to a site may have site-local > > > structure (subnetting) for routing within the site; this structu= re > > > is not visible to the global routing system. In theory, the bit > > > string that represents an EID for one device can represent an RL= OC > > > for a different device. As the architecture is realized, if a > > > given bit string is both an RLOC and an EID, it must refer to th= e > > > same entity in both cases. > > > > > > > > > Is the above sentence really necessary? > > > > > > > Agreed, why not simplify the definitions. They are written from the > =E2=80=98Internet scalability mindset=E2=80=99, why not say that an EID i= s an address of > the overlay and an RLOC an address of the overlay. This change may requir= e > further changes on the document so I am not 100% sure if this is a good > idea. > > I have planned to remove the sentence. > What do you think about defining an EID as an identifier of the overlay and an RLOC as an identifier of the underlay? (Probably this needs to be reworded, but you get my point). In my view this definition is broader and accounts for many of the LCAF uses. > > > > > > > > > > > The description of the encap/decap operation lacks of clarity > concerning how to deal with > > > ECN bits and DSCP . > > > > > > 1. I think that the text should make explicitly the difference betwee= n > DSCP and ECN fields. > > > > > > 2. How to deal with ECN should be part of the description of the > encap/decap not a paragraph apart. > > > This basically means that half of the last paragraph should be a > bullet of the ITR/PITR encapsulation > > > and the other half in the ETR/PETR operation. > > > > > > Agreed, what about this (please comment): > > > > When doing ITR/PITR encapsulation: > > > > o The outer-header 'Time to Live' field (or 'Hop Limit' field, in > the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' > field. > > o The outer-header 'Differentiated Services Code Point' (DSCP) > field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copie= d > from the inner-header DSCP field ('Traffic Class' field, in the case of > IPv6) considering the exception listed below. > > o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in order to > avoid discarding indications of congestion [RFC3168]. ITR encapsulation > MUST copy the 2-bit 'ECN' field from the inner header to the outer header= . > Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer > header to the new outer header. > > > > When doing ETR/PETR decapsulation: > > > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' > field, when the Time to Live value of the outer header is less than the > Time to Live value of the inner header. Failing to perform this check ca= n > cause the Time to Live of the inner header to increment across > encapsulation/decapsulation cycles. This check is also performed when > doing initial encapsulation, when a packet comes to an ITR or PITR destin= ed > for a LISP site. > > o The inner-header 'Differentiated Services Code Point' (DSCP) fiel= d > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from > the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) > considering the exception listed below. > > o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 > of the IPv6 'Traffic Class' field) requires special treatment in order to > avoid discarding indications of congestion [RFC3168]. If the 'ECN' field > contains a congestion indication codepoint (the value is '11', the > Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy > the 2-bit 'ECN' field from the stripped outer header to the surviving inn= er > header that is used to forward the packet beyond the ETR. These > requirements preserve CE indications when a packet that uses ECN traverse= s > a LISP tunnel and becomes marked with a CE indication due to congestion > between the tunnel endpoints. > > > > Note that if an ETR/PETR is also an ITR/PITR and chooses to > re-encapsulate after decapsulating, the net effect of this is that the ne= w > outer header will carry the same Time to Live as the old outer header min= us > 1. > > > > Copying the Time to Live (TTL) serves two purposes: first, it preserves > the distance the host intended the packet to travel; second, and more > importantly, it provides for suppression of looping packets in the event > there is a loop of concatenated tunnels due to misconfiguration. See > Section 18.3 for TTL exception handling for traceroute packets. > > I had planned to take Luigi=E2=80=99s suggestion. I did not want to rewri= te this > section. It was carefully written by David Black with consolation from th= e > ECN experts. I do not want to lose this technical text. > I still think that Luigi's suggestion clarifies the text and that my edit (hopefully) makes it easier for readers to understand. I just moved some sentences . > > > > > > > Large part of this section is about control plane issues and as such > should be put in 6833bis. > > > > > > What this section should state is that priority and weight are used t= o > select the RLOC to use. > > > Only exception is gleaning where we have one single RLOC and we do no= t > know neither priority nor weight. > > > > > > All the other operational discussion goes elsewhere, but not in this > document. > > > > > > > Agree, I suggest moving it to 6833bis. What to leave in 6830bis is less > obvious, maybe something like (not final, just a couple of ideas): > > > > The data-plane must follow the state stored in the map-cache to > encapsulate and decapsulate packets. The map-cache is populated using a > control-plane, such as [6833bis]. ETRs encapsulate packets following the > Priorities and Weights stored in the map-cache. > > > > Actually we should merge this section with 'Routing Locator Hashing=E2= =80=99 > > I disagree with you guys. Who do you think punts packets when there is a > map-cache miss? The data-plane. Note there are many users of the > control-plane, an SDN controller, many data-planes, and lig/rig. How they > each use the control-plane is documented in their own documents. > > And please do not suggest that lig/rig usage of the control plane move to > 6833bis. > As an example, if we keep the 'Routing Locator Hashing' text as it is then it only works with Map-Reply messages: "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache of a requesting ITR" The point is to allow LISP data-plane to work with any control-plane. > > > > > > > > We need to cite the threats document because of the security issues o= f > LSB. > > > > What about this: > > > > Therefore, when a Locator becomes unreachable, the Locator-Status-Bit > that corresponds to that Locator's position in the list returned by the > last Map-Reply will be set to zero for that particular EID-Prefix. > *****There are security risks associated to the use of Locator-Status-Bit= s, > we recommend to follow the guidelines described in [THREATS]****** > > This has been fixed in the last revision. > thanks! > > > --f403043ee044b967ee05615b8e63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all

Please find my comments inline:<= /div>


On Wed, Dec 27, 2017 at 5:13 AM, Dino Farinacci <farinacci@gmail.com<= /a>> wrote:
= I will comment here before providing a new update and response to Luigi=E2= =80=99s latest email.

> On Dec 26, 2017, at 5:48 PM, Albert Cabellos <albert.cabellos@gmail.com> wrote:
>
> Hi
>
> Thanks for the review, please find my comments inline.
>
> I have removed all the comments for which I **agree**:
>
> >
> >=C2=A0 =C2=A0Provider-Assigned (PA) Addresses:=C2=A0 =C2=A0PA addr= esses are an address block
> >=C2=A0 =C2=A0 =C2=A0 assigned to a site by each service provider t= o which a site
> >=C2=A0 =C2=A0 =C2=A0 connects.=C2=A0 Typically, each block is a su= b-block of a service
> >=C2=A0 =C2=A0 =C2=A0 provider Classless Inter-Domain Routing (CIDR= ) [RFC4632] block and
> >=C2=A0 =C2=A0 =C2=A0 is aggregated into the larger block before be= ing advertised into
> >=C2=A0 =C2=A0 =C2=A0 the global Internet.=C2=A0 Traditionally, IP = multihoming has been
> >=C2=A0 =C2=A0 =C2=A0 implemented by each multihomed site acquiring= its own globally
> >=C2=A0 =C2=A0 =C2=A0 visible prefix.=C2=A0 LISP uses only topologi= cally assigned and
> >=C2=A0 =C2=A0 =C2=A0 aggregatable address blocks for RLOCs, elimin= ating this
> >=C2=A0 =C2=A0 =C2=A0 demonstrably non-scalable practice.
> >
> > Last sentence to be deleted is a relic of scalability discussion.=
> >
> >
>
> Agreed. I suggest deleting entirely the definitions for both PA and PI= , they are not used throughout the document.

Note, we still care about scalability of any underlay, especially th= e Internet core, so we should leave this in. Note, we ARE still solving the= scalability problem.

I don=E2=80=99t know why any of you would think differently.

We are solving this issue and many others. But the po= int of the document is specifying a data-plane, not the benefits of this da= ta-plane.
=C2=A0

>
> [snip]
> >
> >
> >=C2=A0 =C2=A0Endpoint ID (EID):=C2=A0 =C2=A0An EID is a 32-bit (fo= r IPv4) or 128-bit (for
> >=C2=A0 =C2=A0 =C2=A0 IPv6) value used in the source and destinatio= n address fields of
> >=C2=A0 =C2=A0 =C2=A0 the first (most inner) LISP header of a packe= t.=C2=A0 The host obtains
> >=C2=A0 =C2=A0 =C2=A0 a destination EID the same way it obtains a d= estination address
> >=C2=A0 =C2=A0 =C2=A0 today, for example, through a Domain Name Sys= tem (DNS) [RFC1034]
> >=C2=A0 =C2=A0 =C2=A0 lookup or Session Initiation Protocol (SIP) [= RFC3261] exchange.
> >=C2=A0 =C2=A0 =C2=A0 The source EID is obtained via existing mecha= nisms used to set a
> >=C2=A0 =C2=A0 =C2=A0 host's "local" IP address.=C2= =A0 An EID used on the public Internet
> >=C2=A0 =C2=A0 =C2=A0 must have the same properties as any other IP= address used in that
> >=C2=A0 =C2=A0 =C2=A0 manner; this means, among other things, that = it must be globally
> >=C2=A0 =C2=A0 =C2=A0 unique.=C2=A0 An EID is allocated to a host f= rom an EID-Prefix block
> >=C2=A0 =C2=A0 =C2=A0 associated with the site where the host is lo= cated.=C2=A0 An EID can be
> >=C2=A0 =C2=A0 =C2=A0 used by a host to refer to other hosts.=C2=A0= Note that EID blocks MAY
> >=C2=A0 =C2=A0 =C2=A0 be assigned in a hierarchical manner, indepen= dent of the network
> >=C2=A0 =C2=A0 =C2=A0 topology, to facilitate scaling of the mappin= g database.=C2=A0 In
> >=C2=A0 =C2=A0 =C2=A0 addition, an EID block assigned to a site may= have site-local
> >=C2=A0 =C2=A0 =C2=A0 structure (subnetting) for routing within the= site; this structure
> >=C2=A0 =C2=A0 =C2=A0 is not visible to the global routing system.= =C2=A0 In theory, the bit
> >=C2=A0 =C2=A0 =C2=A0 string that represents an EID for one device = can represent an RLOC
> >=C2=A0 =C2=A0 =C2=A0 for a different device.=C2=A0 As the architec= ture is realized, if a
> >=C2=A0 =C2=A0 =C2=A0 given bit string is both an RLOC and an EID, = it must refer to the
> >=C2=A0 =C2=A0 =C2=A0 same entity in both cases.
> >
> >
> > Is the above sentence really necessary?
> >
>
> Agreed, why not simplify the definitions. They are written from the = =E2=80=98Internet scalability mindset=E2=80=99, why not say that an EID is = an address of the overlay and an RLOC an address of the overlay. This chang= e may require further changes on the document so I am not 100% sure if this= is a good idea.

I have planned to remove the sentence.
What do you think about defining an EID as an identifier of the= overlay and an RLOC as an identifier of the underlay? (Probably this needs= to be reworded, but you get my point).

In my view= this definition is broader and accounts for many of the LCAF uses.
=C2=A0



>
> >
> > The description of the encap/decap operation lacks of clarity con= cerning how to deal with
> > ECN bits and DSCP .
> >
> > 1. I think that the text should make explicitly the difference be= tween DSCP and ECN fields.
> >
> > 2. How to deal with ECN should be part of the description of the= =C2=A0 encap/decap not a paragraph apart.
> >=C2=A0 =C2=A0 This basically means that half of the last paragraph= should be a bullet of the ITR/PITR encapsulation
> >=C2=A0 =C2=A0 and the other half=C2=A0 in the ETR/PETR operation.<= br> >
>
> Agreed, what about this (please comment):
>
>=C2=A0 =C2=A0 When doing ITR/PITR encapsulation:
>
>=C2=A0 =C2=A0 =C2=A0o=C2=A0 The outer-header 'Time to Live' fie= ld (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied fro= m the inner-header 'Time to Live' field.
>=C2=A0 =C2=A0 =C2=A0o=C2=A0 The outer-header 'Differentiated Servic= es Code Point' (DSCP) field (or the 'Traffic Class' field, in t= he case of IPv6) SHOULD be copied from the inner-header DSCP field ('Tr= affic Class' field, in the case of IPv6) considering the exception list= ed below.
>=C2=A0 =C2=A0 o=C2=A0 The 'Explicit Congestion Notification' (E= CN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires= special treatment in order to avoid discarding indications of congestion [= RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from th= e inner header to the outer header. Re-encapsulation MUST copy the 2-bit &#= 39;ECN' field from the stripped outer header to the new outer header. >
> When doing ETR/PETR decapsulation:
>
>=C2=A0 =C2=A0 o=C2=A0 The inner-header 'Time to Live' field (or= 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the = outer-header 'Time to Live' field, when the Time to Live value of t= he outer header is less than the Time to Live value of the inner header.=C2= =A0 Failing to perform this check can cause the Time to Live of the inner h= eader to increment across encapsulation/decapsulation cycles.=C2=A0 This ch= eck is also performed when doing initial encapsulation, when a packet comes= to an ITR or PITR destined for a LISP site.
>=C2=A0 =C2=A0 o=C2=A0 The inner-header 'Differentiated Services Cod= e Point' (DSCP) field (or the 'Traffic Class' field, in the cas= e of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic = Class' field, in the case of IPv6) considering the exception listed bel= ow.
>=C2=A0 =C2=A0 o=C2=A0 The 'Explicit Congestion Notification' (E= CN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires= special treatment in order to avoid discarding indications of congestion [= RFC3168]. If the 'ECN' field contains a congestion indication codep= oint (the value is '11', the Congestion Experienced (CE) codepoint)= , then ETR decapsulation MUST copy the 2-bit 'ECN' field from the s= tripped outer header to the surviving inner header that is used to forward = the packet beyond the ETR.=C2=A0 These requirements preserve CE indications= when a packet that uses ECN traverses a LISP tunnel and becomes marked wit= h a CE indication due to congestion between the tunnel endpoints.
>
> Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsu= late after decapsulating, the net effect of this is that the new outer head= er will carry the same Time to Live as the old outer header minus 1.
>
> Copying the Time to Live (TTL) serves two purposes: first, it preserve= s the distance the host intended the packet to travel; second, and more imp= ortantly, it provides for suppression of looping packets in the event there= is a loop of concatenated tunnels due to misconfiguration.=C2=A0 See Secti= on 18.3 for TTL exception handling for traceroute packets.

I had planned to take Luigi=E2=80=99s suggestion. I did not want to = rewrite this section. It was carefully written by David Black with consolat= ion from the ECN experts. I do not want to lose this technical text.

I still think that Luigi's suggestion cla= rifies the text and that my edit (hopefully) makes it easier for readers to= understand. I just moved some sentences .=C2=A0

> >
> > Large part of this section is about control plane issues and as s= uch should be put in 6833bis.
> >
> > What this section should state is that priority and weight are us= ed to select the RLOC to use.
> > Only exception is gleaning where we have one single RLOC and we d= o not know neither priority nor weight.
> >
> > All the other operational discussion goes elsewhere, but not in t= his document.
> >
>
> Agree, I suggest moving it to 6833bis. What to leave in 6830bis is les= s obvious, maybe something like (not final, just a couple of ideas):
>
> The data-plane must follow the state stored in the map-cache to encaps= ulate and decapsulate packets. The map-cache is populated using a control-p= lane, such as [6833bis]. ETRs encapsulate packets following the Priorities = and Weights stored in the map-cache.
>
> Actually we should merge this section with 'Routing Locator= Hashing=E2=80=99

I disagree with you guys. Who do you think punts packets when there is a ma= p-cache miss? The data-plane. Note there are many users of the control-plan= e, an SDN controller, many data-planes, and lig/rig. How they each use the = control-plane is documented in their own documents.

And please do not suggest that lig/rig usage of the control plane move to 6= 833bis.

As an example, if we keep the &= #39;Routing Locator Hashing' text as it is then it only works with Map-= Reply messages:

"When an ETR provides an= EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache= of a requesting ITR"

=C2=A0The point i= s to allow LISP data-plane to work with any control-plane.

>
>
> > We need to cite the threats document because of the security issu= es of LSB.
>
> What about this:
>
> Therefore, when a Locator becomes unreachable, the Locator-Status-Bit = that corresponds to that Locator's position in the list returned by the= last Map-Reply will be set to zero for that particular EID-Prefix. *****Th= ere are security risks associated to the use of Locator-Status-Bits, we rec= ommend to follow the guidelines described in [THREATS]******

This has been fixed in the last revision.

<= /div>
thanks!
=C2=A0



--f403043ee044b967ee05615b8e63-- From nobody Wed Dec 27 20:18:43 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16356124239 for ; Wed, 27 Dec 2017 20:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32ez4aSfYtpJ for ; Wed, 27 Dec 2017 20:18:40 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316101241FC for ; Wed, 27 Dec 2017 20:18:40 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id 68so27452298ite.4 for ; Wed, 27 Dec 2017 20:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mw8GnPxORNKtqn8/pTnP4IB7bJd0Irf0dyhJnT62NJc=; b=qN5gyN8rtdMyzaWnEFLHPcP66L6sd1Y7hR00r1nVPDx1RvtR6vZ8UIa18MQcg1RWBu Fh2geGeAsVenQSx9UVK5qz/LswRsLM89RtaFh/yKOEWr6ftQljNhhduSdiPx9w7zSPJ3 Gws+htai+qGHCgc5Ua1fwgQrmTMvgJ8erub77eww0K+T/jEiUFov2WZBRymOOgypYa/G l8aDnZUOgdC9ci1CLGWjAXH5wPfzE5cQkeyyiVahR719GCZCXUf+MSSW39LMOJindlnC QLkPR9aUt+unfilfVWQCEsW4G55Ix4HU3+zdd2/5P59KkJ58TXrqygs6Wnb7DaUbLZ7u OBzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mw8GnPxORNKtqn8/pTnP4IB7bJd0Irf0dyhJnT62NJc=; b=DYatmO7zsM5pr2+VMWDK/6NLmimDyOpjB49C5+G3JG8+8unLKvhVO2McRRz5EOiuJm F+HoCfZosHXki9zT4LYqlbVam9pYXlueqUZcBPURj5/xlfiXNidrRZebx6duobOjPZVy RJCVCOlIm9kRxWtrlYeN8mweiimJPPNj8xwmnbmECeBcwyvtVWQIQG65cIWuWQJ/i9Qi psz6MKjx7xlMNDsk+E9cRMIODhAJ0/WEDUZXZnzZ/3nNMb90UB4GViCvxM3caY3kGsrc OluDzvlXIYXTwI5KH3gH066aJjD4oSoTqlPmHibavUjfqsQApTt2ilkXqI4TS5xZcKaj o3ng== X-Gm-Message-State: AKGB3mL7M+ylKtIZBlGz/+3PMXF8rEG2FPU3CMDssIiii0nGavo35Yes dLMzBeR/Dh0BOeFEubuk0Uc= X-Google-Smtp-Source: ACJfBotc2jCQ9ot2iI6c2WcfYpL5g9jTSPlGIOBuJlx5HhLwIqxKNXrmgNfqetZj+98rUB8eBoyvmQ== X-Received: by 10.36.48.74 with SMTP id q71mr41621854itq.95.1514434719446; Wed, 27 Dec 2017 20:18:39 -0800 (PST) Received: from [192.168.4.79] ([12.219.234.2]) by smtp.gmail.com with ESMTPSA id a13sm11299920itj.33.2017.12.27.20.18.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 20:18:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: Date: Wed, 27 Dec 2017 20:18:35 -0800 Cc: Luigi Iannone , "lisp@ietf.org list" , lisp-chairs@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> To: Albert Cabellos X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 04:18:42 -0000 >> Note, we still care about scalability of any underlay, especially the = Internet core, so we should leave this in. Note, we ARE still solving = the scalability problem. >>=20 >> I don=E2=80=99t know why any of you would think differently. >=20 > We are solving this issue and many others. But the point of the = document is specifying a data-plane, not the benefits of this = data-plane. When you spec a protocol you must say why you are doing it and ususally = a requirements for the solution state that. So benefits is a natural = output of satisfying the requirements. And at the same time we also = indicate what the costs are. >> I have planned to remove the sentence. >>=20 >> What do you think about defining an EID as an identifier of the = overlay and an RLOC as an identifier of the underlay? (Probably this = needs to be reworded, but you get my point). >>=20 >> In my view this definition is broader and accounts for many of the = LCAF uses. We spent two years on the definition of an EID and RLOC. There were so = many people that contributed and discussed it. Why undo that effort. = There is nothing inherently wrong with the definitions. > > > I had planned to take Luigi=E2=80=99s suggestion. I did not want to = rewrite this section. It was carefully written by David Black with = consolation from the ECN experts. I do not want to lose this technical = text. >=20 > I still think that Luigi's suggestion clarifies the text and that my = edit (hopefully) makes it easier for readers to understand. I just moved = some sentences .=20 I made some changes but it is never a good idea to repeat the same exact = text. Check the new wording. >> > Actually we should merge this section with 'Routing Locator = Hashing=E2=80=99 >>=20 >> I disagree with you guys. Who do you think punts packets when there = is a map-cache miss? The data-plane. Note there are many users of the = control-plane, an SDN controller, many data-planes, and lig/rig. How = they each use the control-plane is documented in their own documents. >>=20 >> And please do not suggest that lig/rig usage of the control plane = move to 6833bis. >>=20 > As an example, if we keep the 'Routing Locator Hashing' text as it is = then it only works with Map-Reply messages: >=20 > "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message = that is stored in the map-cache of a requesting ITR=E2=80=9D >=20 > The point is to allow LISP data-plane to work with any control-plane. No that has never been a requirement. We have stated (in the charter) = that we can use any data-plane =E2=80=9Cwith the LISP control-plane=E2=80=9D= . We have never discussed and it was never a requirement to do the = converse. Dino From nobody Wed Dec 27 20:42:26 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EA6124217 for ; Wed, 27 Dec 2017 20:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 dwnuRoREPliR for ; Wed, 27 Dec 2017 20:42:22 -0800 (PST) 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 C68CE1241FC for ; Wed, 27 Dec 2017 20:42:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AE0222463F2; Wed, 27 Dec 2017 20:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1514436142; bh=LvGSWXF6yMGL70VzdwA4KpedL/EOfSL6eltmfVdFUUQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aRLGgqMjqEBFhvN9Sj0BL3gA9OnG3F2eEhgaQwd6syPNGypS7gUiovRMmaQ7Ae4Pq f3QcVlM10nlcJLqS7kY/uB0soqj4UF9ylOoafhmm9/qK4uJpSpieICcJcChLW1ShLf Q52nFcyKHUNitdnbicWcRFH4NlxZEu03Y1DcjVkg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 126C6240F85; Wed, 27 Dec 2017 20:42:21 -0800 (PST) To: Dino Farinacci , Albert Cabellos Cc: "lisp@ietf.org list" , lisp-chairs@tools.ietf.org References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> From: "Joel M. Halpern" Message-ID: <252ece17-7705-3f19-c9b1-21030e753151@joelhalpern.com> Date: Wed, 27 Dec 2017 23:42:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 04:42:25 -0000 Actually, I do not see why the LISP spec should talk at all about the scalability of the underlay. The underlay is what it is. We are not claiming to change that. Working Group: Does anyone else have an opinion either way? This document belongs to the WG, not to the chairs or the editors. Yours, Joel On 12/27/17 11:18 PM, Dino Farinacci wrote: >>> Note, we still care about scalability of any underlay, especially the Internet core, so we should leave this in. Note, we ARE still solving the scalability problem. >>> >>> I don’t know why any of you would think differently. >> >> We are solving this issue and many others. But the point of the document is specifying a data-plane, not the benefits of this data-plane. > > When you spec a protocol you must say why you are doing it and ususally a requirements for the solution state that. So benefits is a natural output of satisfying the requirements. And at the same time we also indicate what the costs are. > > >>> I have planned to remove the sentence. >>> >>> What do you think about defining an EID as an identifier of the overlay and an RLOC as an identifier of the underlay? (Probably this needs to be reworded, but you get my point). >>> >>> In my view this definition is broader and accounts for many of the LCAF uses. > > We spent two years on the definition of an EID and RLOC. There were so many people that contributed and discussed it. Why undo that effort. There is nothing inherently wrong with the definitions. > >>> >> I had planned to take Luigi’s suggestion. I did not want to rewrite this section. It was carefully written by David Black with consolation from the ECN experts. I do not want to lose this technical text. >> >> I still think that Luigi's suggestion clarifies the text and that my edit (hopefully) makes it easier for readers to understand. I just moved some sentences . > > I made some changes but it is never a good idea to repeat the same exact text. Check the new wording. > >>>> Actually we should merge this section with 'Routing Locator Hashing’ >>> >>> I disagree with you guys. Who do you think punts packets when there is a map-cache miss? The data-plane. Note there are many users of the control-plane, an SDN controller, many data-planes, and lig/rig. How they each use the control-plane is documented in their own documents. >>> >>> And please do not suggest that lig/rig usage of the control plane move to 6833bis. >>> >> As an example, if we keep the 'Routing Locator Hashing' text as it is then it only works with Map-Reply messages: >> >> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache of a requesting ITR” >> >> The point is to allow LISP data-plane to work with any control-plane. > > No that has never been a requirement. We have stated (in the charter) that we can use any data-plane “with the LISP control-plane”. We have never discussed and it was never a requirement to do the converse. > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Wed Dec 27 20:44:54 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE8124239 for ; Wed, 27 Dec 2017 20:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 PaW3_ZfoS76K for ; Wed, 27 Dec 2017 20:44:51 -0800 (PST) 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 EDBD71241FC for ; Wed, 27 Dec 2017 20:44:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D9A1BDA0210; Wed, 27 Dec 2017 20:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1514436290; bh=BktGsbc7aQO6R+B+6lv0wizGb1XIOOz1JzkvQ70lsQw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JpKpPRMPaoQ3menu/+yBj3uGja2SMne+jjmCmuAv2IZw0OSWm+QMpcMSHpa7S5pZ/ +gP4ZvNdJn2PX9khIvV7q9bOxZsgM2GuudyjB7/Vcdipe22aPhOaeVT0vWgxHPx6pb DKOM72dUuco4WytVkkeQu8++TOPJSyKXVAovdI80= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 3EE3D245B65; Wed, 27 Dec 2017 20:44:50 -0800 (PST) To: Dino Farinacci , Albert Cabellos Cc: "lisp@ietf.org list" , lisp-chairs@tools.ietf.org References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> From: "Joel M. Halpern" Message-ID: <18a49bad-e493-5d15-db07-276a9a654808@joelhalpern.com> Date: Wed, 27 Dec 2017 23:44:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] 6830bis Review - control relationship X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 04:44:52 -0000 Trimmed... I agree with Dino here. There has never been a requirement that the LISP data plane work with anything other than the LISP control plane. Strictly speaking, it is not even a requirement that the LISP control plane be capable of supporting anything other than the LISP data plane. However, we have found that to be useful, and so are going a short way down that path (there are still assumptions abou tthe data plane behavior that are needed for control plane robustness, which is fine.) Yours, Joel On 12/27/17 11:18 PM, Dino Farinacci wrote: ... >>>> Actually we should merge this section with 'Routing Locator Hashing’ >>> >>> I disagree with you guys. Who do you think punts packets when there is a map-cache miss? The data-plane. Note there are many users of the control-plane, an SDN controller, many data-planes, and lig/rig. How they each use the control-plane is documented in their own documents. >>> >>> And please do not suggest that lig/rig usage of the control plane move to 6833bis. >>> >> As an example, if we keep the 'Routing Locator Hashing' text as it is then it only works with Map-Reply messages: >> >> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache of a requesting ITR” >> >> The point is to allow LISP data-plane to work with any control-plane. > > No that has never been a requirement. We have stated (in the charter) that we can use any data-plane “with the LISP control-plane”. We have never discussed and it was never a requirement to do the converse. > > Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Wed Dec 27 20:44:59 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD73127286 for ; Wed, 27 Dec 2017 20:44:57 -0800 (PST) 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, 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 LkAZB3v1FVNw for ; Wed, 27 Dec 2017 20:44:55 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 7E78812025C for ; Wed, 27 Dec 2017 20:44:55 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id g70so24631798ioj.6 for ; Wed, 27 Dec 2017 20:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3mW2iOlxmNH+3xDARRXW4BgxiXMpNBPN8tlSDwe9XB0=; b=qeAk0+x/TE38rmrEgwDAjW9JFxs7fL0Q76iJu9XBq7k4p5/aVPa0UBKLRqyNU1+Lod zMoYFskJG02mqFyKaTb+GCDz/IYQvEq8FaHI/Zg9rWlfOYirDYIRp0dNrqn1MPNvKJFJ InGY4JTXVcf8ipCYfpcvqqe3MlTl48uyiB9bsiIpKOoBX8E8EDShmjYvLubsCiY/L6Hu AEGaPcXRR/uN1gxG5p3AfeaX5wiDaqmg/so9jqFQxFKdcPkS7HSylE7QJflBa/VlEWRh r/Nab1cdGmgiq64uwQrXQqDyrbPYpsOR4X4TQAoKUvB9y8F3y9GxAj2V6KkmDQB3Kefm dSrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3mW2iOlxmNH+3xDARRXW4BgxiXMpNBPN8tlSDwe9XB0=; b=ZEnKQn+GafYUDel1HumnlQ9dVyxVfWvaj57ZRdbRtlN7p7ddhwG+x4CZEfejx9R/Sq su9jz1QG9EQELWmS7jRC5pVONqLtzD5FJ4ZBGYusOT714u9N5Q3jziFZkQp9zUaA8wq2 Bo8nxkw2BnBoIGbXxaG1KRELbJ+smCVvjHHo8ABetK82n1j/WAIkPiVQ8sKC2GI6HebP xFKzyuwZib4txoKBwotlvp3OGfgHu488NudW97yNThMh0pxVmiJn8CkpUZpznyk+aCkl KNfRDp96bVs9tES7mT8An0mMzRYlMM4Oz2TotbVgfgU6YGJaj/1nSoyXiXnGSRcE6Kkt 0AFg== X-Gm-Message-State: AKGB3mK2cOoqCw0nz1xeHMfjPYimds244tYWS2GGv+xVKH0x3cPRz3hd 5HnksuF7XpFKrseGcPdC2XQ= X-Google-Smtp-Source: ACJfBotAUe8A0XpYepzslXsOMrzgSSncmWLGrBnB9T8noq+rXWoUYgVKzQdxCXDK5OU6CjvALuiVhg== X-Received: by 10.107.101.26 with SMTP id z26mr20723889iob.41.1514436294764; Wed, 27 Dec 2017 20:44:54 -0800 (PST) Received: from [192.168.4.79] ([12.219.234.2]) by smtp.gmail.com with ESMTPSA id 202sm11309042iti.6.2017.12.27.20.44.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 20:44:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Dino Farinacci In-Reply-To: <252ece17-7705-3f19-c9b1-21030e753151@joelhalpern.com> Date: Wed, 27 Dec 2017 20:44:52 -0800 Cc: Albert Cabellos , "lisp@ietf.org list" , lisp-chairs@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> <252ece17-7705-3f19-c9b1-21030e753151@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 04:44:58 -0000 > Actually, I do not see why the LISP spec should talk at all about the = scalability of the underlay. The underlay is what it is. We are not = claiming to change that. But if you assign non PA addresses to RLOCs, the underlay scalability = will be worse. It=E2=80=99s definitely worth mentioning how EIDs are = independent and can be opaque where RLOCs need to be topologically = aggregatable, or otherise you worsen the underlay. Dino > Working Group: Does anyone else have an opinion either way? This = document belongs to the WG, not to the chairs or the editors. >=20 > Yours, > Joel >=20 > On 12/27/17 11:18 PM, Dino Farinacci wrote: >>>> Note, we still care about scalability of any underlay, especially = the Internet core, so we should leave this in. Note, we ARE still = solving the scalability problem. >>>>=20 >>>> I don=E2=80=99t know why any of you would think differently. >>>=20 >>> We are solving this issue and many others. But the point of the = document is specifying a data-plane, not the benefits of this = data-plane. >> When you spec a protocol you must say why you are doing it and = ususally a requirements for the solution state that. So benefits is a = natural output of satisfying the requirements. And at the same time we = also indicate what the costs are. >>>> I have planned to remove the sentence. >>>>=20 >>>> What do you think about defining an EID as an identifier of the = overlay and an RLOC as an identifier of the underlay? (Probably this = needs to be reworded, but you get my point). >>>>=20 >>>> In my view this definition is broader and accounts for many of the = LCAF uses. >> We spent two years on the definition of an EID and RLOC. There were = so many people that contributed and discussed it. Why undo that effort. = There is nothing inherently wrong with the definitions. >>>>=20 >>> I had planned to take Luigi=E2=80=99s suggestion. I did not want to = rewrite this section. It was carefully written by David Black with = consolation from the ECN experts. I do not want to lose this technical = text. >>>=20 >>> I still think that Luigi's suggestion clarifies the text and that my = edit (hopefully) makes it easier for readers to understand. I just moved = some sentences . >> I made some changes but it is never a good idea to repeat the same = exact text. Check the new wording. >>>>> Actually we should merge this section with 'Routing Locator = Hashing=E2=80=99 >>>>=20 >>>> I disagree with you guys. Who do you think punts packets when there = is a map-cache miss? The data-plane. Note there are many users of the = control-plane, an SDN controller, many data-planes, and lig/rig. How = they each use the control-plane is documented in their own documents. >>>>=20 >>>> And please do not suggest that lig/rig usage of the control plane = move to 6833bis. >>>>=20 >>> As an example, if we keep the 'Routing Locator Hashing' text as it = is then it only works with Map-Reply messages: >>>=20 >>> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message = that is stored in the map-cache of a requesting ITR=E2=80=9D >>>=20 >>> The point is to allow LISP data-plane to work with any = control-plane. >> No that has never been a requirement. We have stated (in the charter) = that we can use any data-plane =E2=80=9Cwith the LISP control-plane=E2=80=9D= . We have never discussed and it was never a requirement to do the = converse. >> Dino >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Dec 27 20:53:03 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6D61241FC for ; Wed, 27 Dec 2017 20:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 N7GjyRdYw0H3 for ; Wed, 27 Dec 2017 20:52:59 -0800 (PST) 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 8DD07126B6E for ; Wed, 27 Dec 2017 20:52:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 77A49245B65; Wed, 27 Dec 2017 20:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1514436779; bh=2NnFCWfRNWJSBjKNEtAptuCLx0DVkiC2n0t/vzc6N/A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=rHYluEDRxyO16GPPVvsuxaJfsoZN5EKv/hRUaCz7pzZKnDdOsFduwbSZOVG9rrmFf uRi6p16ErNxca2SDTsrrNAkjButJUvrDSDDmjsNphDNmzpZRPyFPOTubzYFxqwiU6j G+eJA8kRfPBxTbEo51aiu8rC1PCnuR/1eH1EI2fM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 9DBAD240426; Wed, 27 Dec 2017 20:52:58 -0800 (PST) To: Dino Farinacci Cc: Albert Cabellos , "lisp@ietf.org list" , lisp-chairs@tools.ietf.org References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> <252ece17-7705-3f19-c9b1-21030e753151@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <105de8e0-d1b8-a11c-242b-06b2f156b2ee@joelhalpern.com> Date: Wed, 27 Dec 2017 23:52:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 04:53:01 -0000 I would talk about that purely in terms of RLOCs being dervice from, and assigned according to, the underlay. It is up to the underlay to set it policies so that it scales well (or chooses not to care, as some underlays do.) Yours, Joel On 12/27/17 11:44 PM, Dino Farinacci wrote: >> Actually, I do not see why the LISP spec should talk at all about the scalability of the underlay. The underlay is what it is. We are not claiming to change that. > > But if you assign non PA addresses to RLOCs, the underlay scalability will be worse. It’s definitely worth mentioning how EIDs are independent and can be opaque where RLOCs need to be topologically aggregatable, or otherise you worsen the underlay. > > Dino > >> Working Group: Does anyone else have an opinion either way? This document belongs to the WG, not to the chairs or the editors. >> >> Yours, >> Joel >> >> On 12/27/17 11:18 PM, Dino Farinacci wrote: >>>>> Note, we still care about scalability of any underlay, especially the Internet core, so we should leave this in. Note, we ARE still solving the scalability problem. >>>>> >>>>> I don’t know why any of you would think differently. >>>> >>>> We are solving this issue and many others. But the point of the document is specifying a data-plane, not the benefits of this data-plane. >>> When you spec a protocol you must say why you are doing it and ususally a requirements for the solution state that. So benefits is a natural output of satisfying the requirements. And at the same time we also indicate what the costs are. >>>>> I have planned to remove the sentence. >>>>> >>>>> What do you think about defining an EID as an identifier of the overlay and an RLOC as an identifier of the underlay? (Probably this needs to be reworded, but you get my point). >>>>> >>>>> In my view this definition is broader and accounts for many of the LCAF uses. >>> We spent two years on the definition of an EID and RLOC. There were so many people that contributed and discussed it. Why undo that effort. There is nothing inherently wrong with the definitions. >>>>> >>>> I had planned to take Luigi’s suggestion. I did not want to rewrite this section. It was carefully written by David Black with consolation from the ECN experts. I do not want to lose this technical text. >>>> >>>> I still think that Luigi's suggestion clarifies the text and that my edit (hopefully) makes it easier for readers to understand. I just moved some sentences . >>> I made some changes but it is never a good idea to repeat the same exact text. Check the new wording. >>>>>> Actually we should merge this section with 'Routing Locator Hashing’ >>>>> >>>>> I disagree with you guys. Who do you think punts packets when there is a map-cache miss? The data-plane. Note there are many users of the control-plane, an SDN controller, many data-planes, and lig/rig. How they each use the control-plane is documented in their own documents. >>>>> >>>>> And please do not suggest that lig/rig usage of the control plane move to 6833bis. >>>>> >>>> As an example, if we keep the 'Routing Locator Hashing' text as it is then it only works with Map-Reply messages: >>>> >>>> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache of a requesting ITR” >>>> >>>> The point is to allow LISP data-plane to work with any control-plane. >>> No that has never been a requirement. We have stated (in the charter) that we can use any data-plane “with the LISP control-plane”. We have never discussed and it was never a requirement to do the converse. >>> Dino >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > > From nobody Wed Dec 27 21:10:49 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9D126C22 for ; Wed, 27 Dec 2017 21:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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 b6RtlZ2l2TEv for ; Wed, 27 Dec 2017 21:10:44 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877C21241FC for ; Wed, 27 Dec 2017 21:10:44 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id w127so37244360iow.11 for ; Wed, 27 Dec 2017 21:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Gz412hGfZbJU7Ty4NPTr9dlMNIl3DPFEDydFGMOM3wI=; b=oBXcJZfITxkdY7TkXbvkWA5cg1HDWiK2oNsyxiNYr+SjOaCMQkZ4RkYu20cSu8GmOq aq0RqCRMZ9/nyr+0Qnt+GaKIei0e6qMh6iDRNwkMjWtCGAF+9lEJ+tK05IC9JZmq3YNx 6z1+B1R5zP+bF0olYrJSb/+qIvCSz9KwzK2xunBgzmD7zYeL1kf8B3TTJ+lhsmNBYkpo iqXGU9DFo16g9h5KIzuij837i7/p0b7I3U1QUN+xEzgszbSpD1KdzhUR0rHTGB2BKXDw OLCNXG3zA2XXKupoprh+TIU7RJf5Xune/xvyQlQyw/M2BjUoiC2tbxxdVtNDFdSdRUKT kdZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Gz412hGfZbJU7Ty4NPTr9dlMNIl3DPFEDydFGMOM3wI=; b=edv4I75XUpb3dFFF/oMgCiIG7dR3lEnbwYQHdZUfztdAuJev8Dp19QEMqjw0Xnj+Zu j84jZbIRxJ8d4ejZpsDS6WOm86ht+BEFQRARNF+h76KIMJttkYRY5MtUcmQWsSDFtmuc kW1qDFu64F7o21jBKLsf+dnEg2hCb6+W5RaA9ldtESqH4FT6NyU0kuiN1yhukCTtLOR8 Sofe6sgwhoXHKMWQ6jIWlU9EeOsgzvY65DB5FAScJzbIW227xtynicqlmRn+aRYGffXH XlJ81TmB8jvzQtuf5LWRxsZ+GBaTHpcuN54UI2ZFRwSa2l+wdszjD6hH5N4MwQ87QHye AfBw== X-Gm-Message-State: AKGB3mJ21RA5cPooeYjk6ym+fgQxviShfwHbhxrzj1fukWoIJ1ctPmUU IL6CvFomXZFRGL+7OE/OuwI= X-Google-Smtp-Source: ACJfBovAGtnRMz4SPBHPSVF4iYtCFxlMkF38OcUz/RzD9NTMtU1HNilZAxTWwOkTHNcjUFYAJbfryw== X-Received: by 10.107.6.194 with SMTP id f63mr23424986ioi.14.1514437843880; Wed, 27 Dec 2017 21:10:43 -0800 (PST) Received: from [192.168.4.79] ([12.219.234.2]) by smtp.gmail.com with ESMTPSA id v19sm11517206ite.4.2017.12.27.21.10.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 21:10:43 -0800 (PST) From: Dino Farinacci Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_673EEAE6-4043-4B6C-8C36-DDF97C33DC63" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 27 Dec 2017 21:10:41 -0800 In-Reply-To: <105de8e0-d1b8-a11c-242b-06b2f156b2ee@joelhalpern.com> Cc: Albert Cabellos , "lisp@ietf.org list" , lisp-chairs@tools.ietf.org To: "Joel M. Halpern" References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> <252ece17-7705-3f19-c9b1-21030e753151@joelhalpern.com> <105de8e0-d1b8-a11c-242b-06b2f156b2ee@joelhalpern.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 05:10:47 -0000 --Apple-Mail=_673EEAE6-4043-4B6C-8C36-DDF97C33DC63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I would talk about that purely in terms of RLOCs being dervice from, = and assigned according to, the underlay. It is up to the underlay to = set it policies so that it scales well (or chooses not to care, as some = underlays do.) I can change =E2=80=9Cglobal Internet=E2=80=9D to =E2=80=9Ccore=E2=80=9D = and =E2=80=9Cprovider underlay networks=E2=80=9D. What do you think? Dino >=20 > Yours, > Joel >=20 > On 12/27/17 11:44 PM, Dino Farinacci wrote: >>> Actually, I do not see why the LISP spec should talk at all about = the scalability of the underlay. The underlay is what it is. We are = not claiming to change that. >> But if you assign non PA addresses to RLOCs, the underlay scalability = will be worse. It=E2=80=99s definitely worth mentioning how EIDs are = independent and can be opaque where RLOCs need to be topologically = aggregatable, or otherise you worsen the underlay. >> Dino >>> Working Group: Does anyone else have an opinion either way? This = document belongs to the WG, not to the chairs or the editors. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 12/27/17 11:18 PM, Dino Farinacci wrote: >>>>>> Note, we still care about scalability of any underlay, especially = the Internet core, so we should leave this in. Note, we ARE still = solving the scalability problem. >>>>>>=20 >>>>>> I don=E2=80=99t know why any of you would think differently. >>>>>=20 >>>>> We are solving this issue and many others. But the point of the = document is specifying a data-plane, not the benefits of this = data-plane. >>>> When you spec a protocol you must say why you are doing it and = ususally a requirements for the solution state that. So benefits is a = natural output of satisfying the requirements. And at the same time we = also indicate what the costs are. >>>>>> I have planned to remove the sentence. >>>>>>=20 >>>>>> What do you think about defining an EID as an identifier of the = overlay and an RLOC as an identifier of the underlay? (Probably this = needs to be reworded, but you get my point). >>>>>>=20 >>>>>> In my view this definition is broader and accounts for many of = the LCAF uses. >>>> We spent two years on the definition of an EID and RLOC. There were = so many people that contributed and discussed it. Why undo that effort. = There is nothing inherently wrong with the definitions. >>>>>>=20 >>>>> I had planned to take Luigi=E2=80=99s suggestion. I did not want = to rewrite this section. It was carefully written by David Black with = consolation from the ECN experts. I do not want to lose this technical = text. >>>>>=20 >>>>> I still think that Luigi's suggestion clarifies the text and that = my edit (hopefully) makes it easier for readers to understand. I just = moved some sentences . >>>> I made some changes but it is never a good idea to repeat the same = exact text. Check the new wording. >>>>>>> Actually we should merge this section with 'Routing Locator = Hashing=E2=80=99 >>>>>>=20 >>>>>> I disagree with you guys. Who do you think punts packets when = there is a map-cache miss? The data-plane. Note there are many users of = the control-plane, an SDN controller, many data-planes, and lig/rig. How = they each use the control-plane is documented in their own documents. >>>>>>=20 >>>>>> And please do not suggest that lig/rig usage of the control plane = move to 6833bis. >>>>>>=20 >>>>> As an example, if we keep the 'Routing Locator Hashing' text as it = is then it only works with Map-Reply messages: >>>>>=20 >>>>> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply = message that is stored in the map-cache of a requesting ITR=E2=80=9D >>>>>=20 >>>>> The point is to allow LISP data-plane to work with any = control-plane. >>>> No that has never been a requirement. We have stated (in the = charter) that we can use any data-plane =E2=80=9Cwith the LISP = control-plane=E2=80=9D. We have never discussed and it was never a = requirement to do the converse. >>>> Dino >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_673EEAE6-4043-4B6C-8C36-DDF97C33DC63 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_8B258AF5-825B-442E-943D-D005AB4468D1" --Apple-Mail=_8B258AF5-825B-442E-943D-D005AB4468D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I = would talk about that purely in terms of RLOCs being dervice from, and = assigned according to, the underlay.  It is up to the underlay = to set it policies so that it scales well (or chooses not to care, = as some underlays do.)

I can change =E2=80=9Cglobal Internet=E2=80=9D= to =E2=80=9Ccore=E2=80=9D and =E2=80=9Cprovider underlay networks=E2=80=9D= . What do you think?

Dino


Yours,
Joel

On 12/27/17 11:44 PM, Dino Farinacci wrote:
Actually, I do not see why the LISP spec should talk at all = about the scalability of the underlay.  The underlay is what = it is.  We are not claiming to change that.
But if you assign non PA addresses to RLOCs, the = underlay scalability will be worse. It=E2=80=99s definitely worth = mentioning how EIDs are independent and can be opaque where RLOCs need = to be topologically aggregatable, or otherise you worsen the = underlay.
Dino
Working Group:  Does anyone else have an opinion either = way?  This document belongs to the WG, not to the chairs or = the editors.

Yours,
Joel

On 12/27/17 11:18 PM, Dino Farinacci wrote:
Note, we still care = about scalability of any underlay, especially the Internet core, so = we should leave this in. Note, we ARE still solving the scalability = problem.

I don=E2=80=99t know why any of = you would think differently.

We = are solving this issue and many others. But the point of the document is = specifying a data-plane, not the benefits of this data-plane.
When you spec a protocol you must say why you = are doing it and ususally a requirements for the solution state = that. So benefits is a natural output of satisfying the requirements. = And at the same time we also indicate what the costs are.
I have planned to remove the sentence.

What do you think about defining an EID as an identifier of = the overlay and an RLOC as an identifier of the underlay? (Probably = this needs to be reworded, but you get my point).

In my view this definition is broader and accounts for many = of the LCAF uses.
We spent two = years on the definition of an EID and RLOC. There were so many people = that contributed and discussed it. Why undo that effort. There is = nothing inherently wrong with the definitions.

I had planned to take Luigi=E2=80=99= s suggestion. I did not want to rewrite this section. It = was carefully written by David Black with consolation from the ECN = experts. I do not want to lose this technical text.
I still think that Luigi's suggestion clarifies the text and = that my edit (hopefully) makes it easier for readers to understand. = I just moved some sentences .
I made some = changes but it is never a good idea to repeat the same exact text. Check = the new wording.
Actually we should merge this section with 'Routing Locator = Hashing=E2=80=99

I disagree = with you guys. Who do you think punts packets when there is a map-cache = miss? The data-plane. Note there are many users of the = control-plane, an SDN controller, many data-planes, and lig/rig. How = they each use the control-plane is documented in their = own documents.

And please do not = suggest that lig/rig usage of the control plane move to 6833bis.

As an example, if we keep the = 'Routing Locator Hashing' text as it is then it only works = with Map-Reply messages:

"When an ETR = provides an EID-to-RLOC mapping in a Map-Reply message that is stored in = the map-cache of a requesting ITR=E2=80=9D

 The point is to allow LISP data-plane to work with any = control-plane.
No that has never been a = requirement. We have stated (in the charter) that we can use any = data-plane =E2=80=9Cwith the LISP control-plane=E2=80=9D. We have never = discussed and it was never a requirement to do the converse.
Dino
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

= --Apple-Mail=_8B258AF5-825B-442E-943D-D005AB4468D1 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-3.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-3.png" Content-Id: <2A330CA1-3D00-4DD6-8D14-F783BA69B483@hil-clecbdt.pit.wayport.net> iVBORw0KGgoAAAANSUhEUgAABBIAAAEQCAYAAAANqFdqAAAMI2lDQ1BJQ0MgUHJvZmlsZQAASImV VwdUk8kWnr8kISGhBUKREnoTpEiXXiMISAcbIQkklBACQcWOLCqwFlQsWNFVEdtaAFlsWLAtgr0v iKAo62LBBsqbJICu+8p595z55zt37r3z3Wn/DADKkWyRKBNVASBLmCeOCvZjJiQmMUkdgAL0gArQ BqZsTq7INzIyDEAZqf8u728DRFrfsJHG+mf7fxVVLi+XAwASCXEKN5eTBfFRAHBnjkicBwChF+qN Z+aJICZClkBdDAlCbCLFaXLsKsUpchwms4mJ8oc4GQAFKpstTgNAScqLmc9Jg3GUyiC2E3IFQogb Ifbi8NlciAchHpuVlQ2xsgXEFinfxUn7W8yU0ZhsdtooluciE4UAQa4okz37/xyO/y1ZmZKRPoxh ofLFIVHSnKXjlpEdKsVUiC8KU8IjIFaD+KaAK7OX4m6+JCR22P4jJ9cfjhlgAIBSueyAUIh1ITaS ZMT6DmMvtljmC+3RpAJ+TLw8PioUZ0cNx0cLhJnhYcNxyvg81giu4uUGRo/YpAqCWBDDOUTrBXms mOGYF/MFceEQK0H8MDcjOnTY90UB3z98tC9JlJQznHMMZOWO5IKZpIqDouT2mDNfwAof1ofl8WNC 5L7YdA5bxkEL4nRebkLYCB8uLyBQzgcr5Aljh3li5aI8v6hh+52izMhhe6yRlxks1RtB3JKbHz3i 25cHF5s8FxyksydGyvvF1UV5kTFybjgThAF/EACYQAJLCsgG6UDQ0lvXC0ZaggAbiEEa4AGbYc2I R7ysRQi/0aAA/AkRD+SO+vnJWnkgH+q/jGrlXxuQKmvNl3lkgG6Is3Ad3Av3wMPg1wcWB9wVdxvx YyqP9EoMJAYQQ4hBRMsZgkLxD3GZgAMzyIRFDEJhzYNZSTkIR7h/i0PoJrQRnhBuEdoJ90AceArt BP/I8Fs0wahuEmiHUYOGs0v5PjvcDLJ2wv1wT8gfcscZuA6wwcfDTHxxb5ibE9R+G7V/x10ywpps R0bJmmQfssWPdkpWSk6jPtLcvucp55Uymon/aMuPvfl/lxsX1qE/WmJLsSNYM3YGu4Q1YnWAiZ3C 6rGr2AkpHl0bT2VrY6S3KBmfDBhHMGJjV2PXYzf4Q9/s4f7FsvkHebxZedKN458tmi0WpPHzmL7w tOYxWUKO7Vimg529CwDSs19+tLxlyM50hHH5my7nNABuJVCZ9k3HhmfQ8W4A6O+/6YzfwC2wEoAT rRyJOF+uw6UfAvyrKMOdog304dllATNyAM7AA/iAQDARRIAYkAimw3HmgyzIeiaYCxaBYlAKVoK1 YCPYCnaAPWA/OAzqQCM4Ay6AK6AV3AIP4FrpAi9BH3gPBhAEISE0hI5oIwaIKWKNOCCuiBcSiIQh UUgikoykIUJEgsxFFiOlSDmyEdmOVCO/IseRM8glpA25h3QgPcgb5DOKoVRUHdVDzdBxqCvqi4ai Meg0NA3NQQvQInQ5uh6tQvehtegZ9Ap6C21HX6L9GMAUMQZmiNlgrpg/FoElYamYGJuPlWAVWBV2 AGuAM30Da8d6sU84EafjTNwGrtcQPBbn4Dn4fLwM34jvwWvxc/gNvAPvw78SaARdgjXBncAiJBDS CDMJxYQKwi7CMcJ5uKe6CO+JRCKDaE50gXs1kZhOnEMsI24mHiSeJrYRO4n9JBJJm2RN8iRFkNik PFIxaQNpH+kU6Tqpi/RRQVHBQMFBIUghSUGoUKhQobBX4aTCdYVnCgNkFbIp2Z0cQeaSZ5NXkHeS G8jXyF3kAYoqxZziSYmhpFMWUdZTDlDOUx5S3ioqKhopuilOVhQoLlRcr3hI8aJih+InqhrViupP nUqVUJdTd1NPU+9R39JoNDOaDy2JlkdbTqumnaU9pn1UoivZKrGUuEoLlCqVapWuK71SJiubKvsq T1cuUK5QPqJ8TblXhaxipuKvwlaZr1Kpclzljkq/Kl3VXjVCNUu1THWv6iXV52okNTO1QDWuWpHa DrWzap10jG5M96dz6IvpO+nn6V3qRHVzdZZ6unqp+n71FvU+DTWN8RpxGrM0KjVOaLQzMIYZg8XI ZKxgHGbcZnzW1NP01eRpLtM8oHld84PWGC0fLZ5WidZBrVtan7WZ2oHaGdqrtOu0H+ngOlY6k3Vm 6mzROa/TO0Z9jMcYzpiSMYfH3NdFda10o3Tn6O7Qvarbr6evF6wn0tugd1avV5+h76Ofrr9G/6R+ jwHdwMtAYLDG4JTBC6YG05eZyVzPPMfsM9Q1DDGUGG43bDEcMDI3ijUqNDpo9MiYYuxqnGq8xrjJ uM/EwGSSyVyTGpP7pmRTV1O+6TrTZtMPZuZm8WZLzOrMnptrmbPMC8xrzB9a0Cy8LXIsqixuWhIt XS0zLDdbtlqhVk5WfKtKq2vWqLWztcB6s3XbWMJYt7HCsVVj79hQbXxt8m1qbDpsGbZhtoW2dbav xpmMSxq3alzzuK92TnaZdjvtHtir2U+0L7RvsH/jYOXAcah0uOlIcwxyXOBY7/h6vPV43vgt4+86 0Z0mOS1xanL64uziLHY+4NzjYuKS7LLJ5Y6rumuka5nrRTeCm5/bArdGt0/uzu557ofd//Kw8cjw 2OvxfIL5BN6EnRM6PY082Z7bPdu9mF7JXtu82r0NvdneVd5PfIx9uD67fJ75Wvqm++7zfeVn5yf2 O+b3wd/df57/6QAsIDigJKAlUC0wNnBj4OMgo6C0oJqgvmCn4DnBp0MIIaEhq0LusPRYHFY1q2+i y8R5E8+FUkOjQzeGPgmzChOHNUxCJ02ctHrSw3DTcGF4XQSIYEWsjngUaR6ZE/nbZOLkyMmVk7uj 7KPmRjVH06NnRO+Nfh/jF7Mi5kGsRawktilOOW5qXHXch/iA+PL49oRxCfMSriTqJAoS65NISXFJ u5L6pwROWTula6rT1OKpt6eZT5s17dJ0nemZ00/MUJ7BnnEkmZAcn7w3eZAdwa5i96ewUjal9HH8 Oes4L7k+3DXcHp4nr5z3LNUztTz1eZpn2uq0Hr43v4LfK/AXbBS8Tg9J35r+ISMiY3fGUGZ85sEs hazkrONCNWGG8Fy2fvas7DaRtahY1J7jnrM2p08cKt6Vi+ROy63PU4eX7KsSC8lPko58r/zK/I8z 42YemaU6Szjr6myr2ctmPysIKvhlDj6HM6dpruHcRXM75vnO2z4fmZ8yv2mB8YKiBV0LgxfuWURZ lLHo90K7wvLCd4vjFzcU6RUtLOr8KfinmmKlYnHxnSUeS7YuxZcKlrYsc1y2YdnXEm7J5VK70orS wTJO2eWf7X9e//PQ8tTlLSucV2xZSVwpXHl7lfeqPeWq5QXlnasnra5dw1xTsubd2hlrL1WMr9i6 jrJOsq59fdj6+g0mG1ZuGNzI33ir0q/y4CbdTcs2fdjM3Xx9i8+WA1v1tpZu/bxNsO3u9uDttVVm VRU7iDvyd3TvjNvZ/IvrL9W7dHaV7vqyW7i7fU/UnnPVLtXVe3X3rqhBayQ1Pfum7mvdH7C//oDN ge0HGQdLD4FDkkMvfk3+9fbh0MNNR1yPHDhqenTTMfqxklqkdnZtXx2/rr0+sb7t+MTjTQ0eDcd+ s/1td6NhY+UJjRMrTlJOFp0cOlVwqv+06HTvmbQznU0zmh6cTTh789zkcy3nQ89fvBB04Wyzb/Op i54XGy+5Xzp+2fVy3RXnK7VXna4e+93p92Mtzi2111yu1be6tTa0TWg7ed37+pkbATcu3GTdvHIr /Fbb7djbd+9MvdN+l3v3+b3Me6/v598feLDwIeFhySOVRxWPdR9X/WH5x8F25/YTHQEdV59EP3nQ yel8+TT36WBXUTetu+KZwbPq5w7PG3uCelpfTHnR9VL0cqC3+E/VPze9snh19C+fv672JfR1vRa/ HnpT9lb77e5349819Uf2P36f9X7gQ8lH7Y97Prl+av4c//nZwMxB0uD6L5ZfGr6Gfn04lDU0JGKL 2bKrAAYLmpoKwJvdANAS4d2hFQDKFPnbTCaI/D0pQ+A/Yfn7TSbOAOz2ASB2IQBh8I6yBRZTiKmw ll7HY3wA6ug4WoYlN9XRQR6LCl84hI9DQ2/1ACA1APBFPDQ0sHlo6MtOSPYeAKdz5G9CqUjfoNvG SVFr1yvwo/wL/Wdw9t/+zNMAAAAJcEhZcwAAFiUAABYlAUlSJPAAAAGeaVRYdFhNTDpjb20uYWRv YmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJY TVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcv MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFi b3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8x LjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjEwNDI8L2V4aWY6UGl4ZWxYRGlt ZW5zaW9uPgogICAgICAgICA8ZXhpZjpQaXhlbFlEaW1lbnNpb24+MjcyPC9leGlmOlBpeGVsWURp bWVuc2lvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1l dGE+CqZzJpEAAAAcaURPVAAAAAIAAAAAAAAAiAAAACgAAACIAAAAiAAAjVDezN2VAABAAElEQVR4 Aey9Daxjx3UmeAx0R24Beh6pLcvp9qAldJyVjW0q6IbR8l8CtgNDHm9EwVbiRKYCK55QgjaQaGQs DzOxd/MSRKCCgUQhq2ErcCjLTcUONYCoYEHNzrK1ppKYwgx7I2rHFCw2zN7J69iv3eyIbyM+hQ+o PZfkrTp1/3hv8afJ9w4br3nv5a2qU985derUqVNV7xL4Af4wAowAI8AIMAKMACPACDACjAAjwAgw AowAIxACgXexIyEESvwKI8AIMAKMACPACDACjAAjwAgwAowAI8AIDBFgRwILAiPACDACjAAjwAgw AowAI8AIMAKMACPACIRGgB0JoaHiFxkBRoARYAQYAUaAEWAEGAFGgBFgBBgBRoAdCSwDjAAjwAgw AowAI8AIMAKMACPACDACjAAjEBoBdiSEhopfZAQYAUaAEWAEGAFGgBFgBBgBRoARYAQYAXYksAww AowAI8AIMAKMACPACDACjAAjwAgwAoxAaATYkRAaKn6REWAEGAFGgBFgBBgBRoARYAQYAUaAEWAE 2JHAMsAIMAKMACPACDACjAAjwAgwAowAI8AIMAKhEWBHQmio+EVGgBFgBBgBRoARYAQYAUaAEWAE GAFGgBFgRwLLACPACDACjAAjwAgwAowAI8AIMAKMACPACIRGgB0JoaHiFxkBRoARYAQYAUaAEWAE GAFGgBFgBBgBRoAdCSwDjAAjwAgwAowAI8AIMAKMACPACDACjAAjEBoBdiSEhopfZAQYAUaAEWAE GAFGgBFgBBgBRoARYAQYAXYksAwwAowAI8AIMAKMACPACDACjAAjwAgwAoxAaATYkRAaKn6REWAE GAFGgBFgBBgBRoARYAQYAUaAEWAE2JHAMsAIMAKMACPACDACjAAjwAgwAowAI8AIMAKhEWBHQmio +EVGgBFgBBgBRoARYAQYAUaAEWAEGAFGgBFgRwLLACPACDACjAAjwAgwAowAI8AIMAKMACPACIRG gB0JoaHiFxkBRoARYAQYAUaAEWAEGAFGgBFgBBgBRoAdCSwDjAAjwAgwAowAI8AIMAKMACPACDAC jAAjEBoBdiSEhopfZAQYAUaAEWAEGAFGgBFgBBgBRoARYAQYAXYksAwwAowAI8AIMAKMACPACDAC jAAjwAgwAoxAaATYkRAaKn6REWAELAQuvnEOfvz2fnj/h4/BoXfvXUx2ti5A883LsP/a98OxWw/t XSC45owAI8AIGCOwBW+cexPeJun3v+dfwrGjN5InfLlcCGzD+dd/AG8NCFX7D0Ls2BHYRx7xJSPA COx+BNiRsGQ83r5yEX7SG8C1azfBjdfv4VHakvGFyRkhsP36M3Agdt/wptjuwz1H966Mbr1+GtZi DwyxKCEWd+9hLLh97E4EuD/anXxdqlptvQqn1m6HlzWistAVj8D12jO+WRoEkGe3Ic+aGkFxqPfO wsnrtId8wwgwArscgaV2JFx85Tk48/2fwrsdY5Vr1t4LHz7xcfjorvN+bsHpU2vwAPaosWwdXnvk 5IqL3za8+ty34Hs/fQvec/Nn4P47j614ffY6+VdQPm8YyWe6Aq89focnIObtdkp52bkILz71J/DE N8/C5TFlt5z6Mnzjqyk4Pil0YucSvHQmD/lnn4cfYeKDBw/C2uEPwsc+9Vn4fOLTcNTTqbcNz917 AL54BgtLFqH/7XvAoao88dkbDy/Bi0/+BXSsym5fA5+478tw/MblmKvaO/I5raTttv5oWjwipked 8uI3sQ28E5DOq22gHnv+qefhokeytffeDLGTH4Xjc5+t34ZXnnka/u8eEuFFowdtxo+2z8G9B06A pUYhloTMqWuhf8sX4NGHTmn61LzdArz+4jNQ6fS0/Jz0bsN74QsP3gNHvNSUYf/w6vNPwqNPvQTX ffCDsPXmm3DLHQ9C+qG74YhHRxGGRmQGXHPol+HLdx93zfxvnX8F/sOfPg0vnW2O+7+DcPsXH4Tf 8ynPWf+Lr5+F/6vx/8I/4w83xD4Ndx4PiLLbuQCnv/rH8MaBa+Hso0+MHQoJaPRegON71ZGwgu19 68KrUHjiT+GbKDNo9MAta4fhlhMfgV+56244dSyA/07h4fu9jYBY4k8jlxDIHf+/WEpU272lqkGz kBzRmyiI6JT1RD4+qm8i11iqepkRo+oDsZzommWyEqmm4/tKVFH0mnnZFjEawZdo83Y7hbz0miLt qytiotj0l75+pyKSvmmxPaLs+rXlsJj4grVLfxi0i1JWLB2eLLaWpqZ7ST6nA121x93RH02HRuTU vbqIB+mV8W/ZukM39RoT08WSOdHyU0qRCXUn2KxltfbrotGdxPxJvyH1b745534lkB9xUffA1Kx/ 6IpCys92TYmGg+UCraNczO99x/NY1mVLtUoZjV+63ZwUtc2BD38GotMoi3RCLyOerfu8737csm1e SIiGB37uFLv0yYq191Z53V9mdrm9vksl8KpVC65aySEKbubHg3KIiVQ6LdLWX8p+Ziu+pGgukfKS NMfzLmU/ucp9Uc2mRDweF5klMrwn0+33Rk8U7A4qkfcdjPmlXqXn0/F9FWo6EGXbMJog2xKLyO3W VF660gFnGVCxZFbUmg1RzqVIR5kQTnvdQn2wUdWMdittpVYX1UpJZNNjR2Zgp7oh1scGYCxTXQVG LoRG6VizDXcjx+p8SN1b8jkNhrutP5oGC4O0g7bIob2SSqWGfwk5UIyJ5PhZMpkSlY5j8EwG1gBx kc5Ytk9GpJJxos/Q/sE+1TUeNSDTlWTQEim73Y6/c+6RryuZ8QNS36ByZtJusU+ysbf5Yn8nUfe3 HKww7R9qWcKreEaUq1WRz5CJMXQGbGqADUQtl/amDe1e6uhO5PRB/qBT1uQiU6iIJvZ/hXVSHqyL Da08vEH5XB9PXOmOBxBRHIeKL3vckbBC7X2jqjsRkusFUalURDGfFUlLTwXaPE5B4vu9jsBqOBLQ CNX0e78jcknbkYBKL99cGj5K76yT5qWhcJGEkIEhDj6XyN8zcxB2Pd831YA7XWoH4icNC2cbmNhu zeSlT2e/kwXNuG4WlDMhWWg56O6Lku0cQYM5ldcNNOvlXqcqcvmarn8cucj64oyMl7PC8foeuMXZ NZeBGhe1uYx6osMp+bVH5DM6QpxiHgiE7iPIwNpp2/TaevRUfg6zKNV1MgheRkfCNO3WmTaQ0Yb9 A0aUJKQjJiPaMhigL3LyOYggp4mTrHbR7sdiotyRGQ5fq5PI3Vxdd0805GQciLwzXECjMy5ypaJI j51d7EhwciD6/fK2947ISDn0itbsi83N3WytR+clpwhGYDUcCV4zoGRg46v0cOBSQi9vPBYTiWRy +J1M50S949NIBhuiXMiLXK4gmq5QsL5olAr4W15UmlRZD0SzjM/zeZHHtGlpQMdFNl8Qees5/lnp Gq48LeZg+koR0xZEwf7D98t1l/9YcRLpLOVzIzq7PdGqFEQqEcdIhpiIxTCaoVALHLT32jWxnkrg u7Fh9EMyg7R1OqKG9csjzfUNzW2jyo18ZTYwlMVE5Z9MiBeDTVEtoncVcbEwsaI8Esm0yJdqYtOj er3NlqgU8yKDM0gJfNd6Px5PiPR6XtRalN92IdPyHfMxrN9gsyHyOeR/vjwcNHfqJZFJJlC+keZE EmewUMY3fGTcJj/id0sOyCcPluVALXK7NZMXGqpeVFbbuIZtteQh7lheQ3QIJB3Oyij4kHwylU6o lJsYTmrphJFuKAmHbRgqj6V9CfGIjQ2V9WJBzqZlKj46bUp9FhWHPSefkQAy6I/s/HsdUc6viyTq zqHOTSRwhjUtcoWyaHkpXTudwXd0fY2FLFjOnNUKlDv6MnUkeCxx3CSziTnbc2nZLkObICcqLR+P Xa8lCla/gXqnvqEPRu3i+63CeHY7IQqlnGzHUQa9dl6hv0l9g8oJxI/oYLc9qPcrPui4ySV5Rukf unW1LGS9SmwHzE85GEDEszV3mZ5PyMDPFdmJy4/sqE9XlANmRrCNrzsi5votdBzERBZtou5QHPoy gtSNoSdhw4eSL/Ne2rBC9pIFjMTFyw6icBIeeeE+6/bea6glqplyOHuFksvXjIATgZVxJLiGRYOm NFC9Gp+1ro0qbWfoVrbiMauKHlp7TaN7TaBaL6qvH+uKrPTuqSgJZ3nW/brd6Wtc8E6vl6ElwGlS RadXOcNn6bLnLOpmXSkRv7TuujvKD32rd+AuHgbkY8S/cX69djmQ97Gsc/+J3sT1ieli00GtN9+8 MPXi+1T1a+TGxp4V9krDF5X84WadDnqnu61nx+U4B+Me2dIO1MXzwHZrIi/EkIKUcC+x7YuijF5C JwghqCVnebBtVn0GuR71cz3CkEZ7fwYvXeR6Hx80cnTWz3ttrle6VXjWKaflYKTR21TLTlJldJt6 fKbQZx65TXy05+RzIiL0BW+9FtgfYfLBRkUOOr10oFvn0jKjXpvoayxjwXLmrFWg3NGXJwws1GDf GoyO9TzqILkcIVXybGedkt0uQXjvcaOWaVmREP227VSINntOqxLqmtQ3rCOBqPFREWH7lQgRCab9 QzNv98k0CqtH+qFxPz1pgDkGTxv4uRzVpM90ORmsDMjvE/tu9W7YfswqQcr1HB0Jq2Yvabggn13y ar1gf4j8e+E+6/auJl6SYhSj2Rfd7iZGIWyKbt+zh7Yp5W9GwBOB1XAkeChIqlzjLq/9BgndwaUP uP6n3mziDDVdFxQTFadXnjRod4fmp2QHol2viFK5jGuMyiJLBi0FXHNUxufDv1JFtEduXwcjBqJV LYlCsSRKOANgOzK8FIpMSOgcGm246WSp1hD1Sl6mx+2PXSFwliFFnStpXEvXauHsdpoOamZpNCjM YJIylZWzLgz5ZyXt6htcxTECpdZoimajJooYnWLh5R5k24ZpTKSzGHGCa+SbLZQXwg8rnR5SOA3f p6gfVpFu8Gcb7QmMQiij/BVz60MZcNfRAsf0QwbrE40RYlhEbrcm8kLSeJRn1djP0FEGn+5giI6S oiGGDrwwXbGiyTIqd9PaUuK4QX5YwT9NGXrr5ejBF0z1WXRGDVNI7D3kJbhfUXwOr89IGo/yLIIk PQ45mJ18RgHKoD9Cia9mYmPnES4RyhaH/W2zURelQnbY58xaH402pouirxGDBcuZE3XJ50l9IaHT yw7olNXGetQBqgYIXvpssg5X+5qkhTXN0ieb67rtIWftprgn9Q0qR+Ln0Y5Ct1tIiiK1y6R9VnZF qpq2P7k/AkYI2O5pOqts99kQd+6T4IUh7k2UtttW0mMzQ8JXdJK4B6xkmZkHbnqJSld5yZ3+rrqT fHHoL/XGtFerZi+N6itxWbL2LvUEbthaLauoI1suk+tF4RwaTctBTr+7EVgNRwIq3E6/L3q9nuih 56ypDZhBFBzbF9MdhxOO8LHNuj2b6xFaFtihhVOyoddFecrVQBTHYWqBipzQCbGMtkFQv6lmEZyR Be2Svc4OhB6Cba0FtDurq+9IMOYfYipnznHgny6N/K0U6sFGXVRcy0Zw52J0NHmuPMGZNuncCdiL Iwrfp6mfVRfdkRAThQYJn7Re6G+K9kyXNijZd4VHWuU5PqoDjdZu9dmTCV58WaaizW9wpwxkfcAu 6ZzaACKbPaLRECZ0VhmpI0cCjZSQVVvFC9y52nZWJsftpUd0kudAwVCfmcIj+R6xX1ld+TRFKmR/ hBJvnzbkveFoT2x2PdaTmZKFjgsjfb1gOXNWT8ndBN1G6HTukbDZLMn+yDL8C2R3wEG7JJ05rmVE mypiJFX0iMYkESV2OD7tZzzbrbOCpvekvkHlKPym6FcQM3vA5Px2OrtkeZH6B9UWrM0whwP7flNG iyQxsrEl7TAvh48DxG5N8juWqTh+tG5J/wdp0XJ6sQlfrf4xuG9SeQXanw4qzHByZBJwu3r20qgy EpcojgSHjTn79k4cTwFtAYDu7RHAHP6JEUAEVsORECDw6x6DRWWkJzw2+CIeWqdiDezQwinZ0MrD U/zClUFnVlwb32GInx3imMjTEH6Vt6UkbE+5TQYNnwrqzO33w32TMicpU5KhMf8EWUvo5C3JP/hy MHRWbXa7GO7VFX1c95sNcSRnFL6b129EOTXwdB4H18z4V2IIhSlPYhGx3WpGUVh5QdrkjtY+aapp 23ik+oB2qLqDwQQnueGVDw3OPNt4XFfM2rcD15HHcFdv95IMZ4rVuKdGnxzk4FpcWyfF1j3WBRO9 G16fmeOxF+XTDC2lv4MHFqQtJXLo9DcrzSxVBH29YDlz1kfK3SQdQei0IguTuG9PEvd4Ssj9l8b6 LFl0zEBviqx9MgT+RtmgwvTjgi7bH9GIg197nT2Z1ab9zOxsAicqeE/qG1SOxG+afgXTWnp3tAeS +o4hbhltE2Ei05EcCarNWAN3iwc1e/PK2OjkhJbcAHFyv6M2WcTNEn021qQTRIlcVUXE4b4ZeRkh G8ZhrWgPbu86DxVfJtdHTxnubuXspXG1JC5L1d4Vj21HWqZYF90eTtRuNrVN7JOFZjgG8Vt7HoHV diSkvTy0qLjto3d8GrBq4I7QssAOTTXAICWr8p4w6+ApeuHKoB2vu3NReeiKQD33DL8mA7KgztyT bN+Hqky/2WKvpMb8I0s3gnjkVabotUUpmw5c52vPsHqlj8J34/qNC6YGXqlNzUUvymbxbFPuwj8T R4JPuzVyJOAhWvKEAJ/23pBrVvUZILU7+bQGEAnn96FhFlxY/jwGoiJD3DPo1lOfigzP1Z8P3yB6 N7w+U3lHvZJt1W9AsuvkMypC9vtKfwfrU+S7dNaNBrnJTFYUyxXRaLYdg1077ym/TfT1guXMWUMp d5N0BKHTNvad3/F0wdNhQx0G6pQUMnnicDBYNKqlErgcksQ006UNrh3/nZWb5p7UN8j2kPgtpN0K YdY/EAcEYr1BokQKY0eAqofeH7khVHtWwNgJ4X4HnxDbbSgn8ZTIpPEYcSdOZKmFZz4kuiG4veup aX2cB0Pob5rdrZ69NKqnxGWp2juRT5QPlz1H9nuKYrObcZZT7RYEVsORgCGorc3ucDOQdrMqMsQz r4foW2whoWU+DVg2cPQ0ayHFgR1aOKNK5u1TdrDghCuDOhLcHa9fHuS5I3xqSBOGPtrGijvPYKr9 f1VlhldKM+Kf58aWPpQSB4SNAeBuxtapFtZMhf0sqHMNz/cp6jcmXzkScM3kIvwIaGB4zVj5oKnW fEdqt1ZuJvJC0tihpA7CJG8cM0vq+bQ4TqbBQdLuvNXOn4/LtciVakU7r7xIwrGHQMxA70YBVPJ9 z8hnFHTou0qug3TfMAWeCOB3Jr21B0jZsfyQlhL52lRfL1jOnPVScjdhkoHQCbG0KJZKolgsiiKe 6lQq10Q76Gg2soQhPd6RfdApyz7MteQBo4VkRBdu0tjt94aReNYMZYecDpHBzal7PYzQc4bOOytp ck/qG2R7KPyi2IMWQUqOLTskOLxfVUCWh/sqhO9niVMZT1FKjO2HGDkxQeWb0palqpJHV3SZqj4p 5HwTfQl4TLHkI3UgxPAUp+R4Dyyf/lHlpnCa2N5VItXfO/pX8soUl6toL42qK/k8aSxA5H/u7R3b gtp8mm4Gqlgk91BAuW8uxL5UZfPVaiKwGo4EpwIkodbg2qmdnP3rTDfmkVozjWvKaEMhDdrdoSmv fpCSDa08POUlpCIPpNMvD/Xcc5078Wq76+5JbIiHqszwjoTp+CfXZxdaIegbvSL3N8AOOJWriA00 otRH1WE2fJ+ifmOilCNh2pl0VcvgK7KHhk+boullG3C+G9hurRwU1uHlhTg5fGZt6MwSdRyqDhN3 MdcUAa1NmGsVFREkI2FyWuV3lFwq55vthKPfrlkQI31mjtTek09TrFR7DCfXOPjETW1LhRwOXuyd 621ZSAnXyayGZBnr6wXLmbN6Uu4iDCyceyQ483TfK57B+IQCWa7XQM/LKUMHoo7rbCPsMNxNme+T QL6oVLIeC+lXrJN1lAxH6R8knRI76jBA/tjLDZz1UFXFKxrdhRuDO7ZB0l6VNz3RrJZFAY8Pt44S L1Ua2KNaG6GOHQkTN0pWshOuvY8KVvWdhz2yivaSA5dlau9I2iR+0d+pvSTFjC8YAQcCq+FI8GiI GxW1c3GyqA8aVUPw2jCE7ILrVORkMO0KscXOzh6kBilZWbYzbwfw3rchFXlgx+uXBx1wOZZ0IDGD jtqo6eo6EqiiM+ef98ZEXqgTXDzCPmnY4Kz4LmXEc0ObAPkck68GbPPouL0wsnhiG1UeGzo5ksj6 RWy3Zo6EvijLjUK9POzKAQi4GRUdzGg7fdvHqDnqEuqW6gavaB+PTLptHHCVRie6WLOMnht9eqRb 5kd0o9N4YrSu21rbPfrDvSBswxoNWs0uNtJn5kjsOfk0hsqvLwmX4QD3lymS42lnEx4/hb5esJw5 UQqSO+1dQmdQn6OlITfq+FXUh5sbaumX14kyWJYrBN5upx7fS+FIWEi/gr1RQx2VLY/ZJDj7XbbJ MZuWAzVbI9qORm1hBAidstDyI5vWgpddor0ccIP8te1WzwkkLalZe5dy7eWo0vI3u1H5R7QHx8Vd DXvJKlrS7SGvGhKLbO9YcKtgb7ruiMgeE6WWgmIkjvsYEI10vmEELARW1pGAK/vIEY/U44sNhZwP 7zy5QAQpaOKdd+5s3Guo0x6COnc54MLZUdJ9hJS2kIqcKB73oN8/D6nYsHOz1+vZhNWy9kBxTqc2 GJ7fHIl/2C2XbG8/xPF4T7t2+ndfi88koXNJ9/nbyijD9WSuY0ZVvlH4biyf4+KuRsfYJaedOGVH oTC6knLm2YH6t1vNkRBBXjZr6ljXpCMSpd8qyrBe90Z/lJY4Hu/pZdb1xcZG8CycvsFguJ63kaNH rsb1JVZOQFfinqzn9eQ7neFzHL1rqM9MYdlr8mmKE22PQbovKP9BU/WbuSjLzXwznUJfL1jOnFWQ kRSTdBuh0wh3YuPEMTLEduC5+tIhgdZmlaONha3NheXfUi9t8FoaQnW5bg9SOQ4f6WaBQ/MM3z/Q pSQQy2FUgPrQYyDTpY76wXFF7Q56xKfjtQm3GNVgb/Ro2XwTo+76omCfGhbSIW4RIPXpnBwJq2gv WbgsZ3vHScO2somc4xzr6PV1ezkv9uPBlo9VS/4wAivtSLA2CUrLQUKKRiWQI3NG6zNHzWHQbckd +F2eYksacKORjPTCW+s6R+m6rbL06lrpgjp3qvSGYfLYOY86aivIzOMzGB9riR33oI8nBIwbcRyP rezL33r62kRiaERxJAiyfhJwoF2sd0S/3xX1gsLRqp87Tw+6Qz1STg3A9VblekPU63X3X62O6z7J IM6Uf0gTdfhYvC81Nsa4o8G02RKFFO7a7Jh9pmegZ6v20Vh90SpnpXzNlO9T1M+C/Wo4EmgH433E mxIIaVj4DCh92y1d2hBFXkgk0VB+xzzsOdaNuqKMkGRKi9UmCrX2cJZogGuFO7gfy/rQMZUL6FBJ 6OXE0FEPjIb6ZnGRJYqC2V7RiCa/cGwlt7iEiO6QbqrPDKuwt+QzIkiyz4nQH1ntNhnDZWEl0exs yn7O6m9z+Nxqk1bbqs4o7MZYXy9YzqwBbGvc3zUadVFIj52HuO9BZdwX1moNsUG6viG3CJ1BtoY/ Z4lOGmJv4Y+Da08DJCCXppqRn000iU9ZpL5BtsdM2q1Pn+RDmWH/QKPgAE+DaA7bRK9dJtEfXtFz NhVqqZx76a79jv7dKmZEKlsSrY1NtOnGto4tb5YM+PVN/Q3RqNWGNlmjURVpe0+HVF7UG2N7rTHq E/US1Z3ky5wcCWJl7KVVae/oLJB6ISZyaC8NVQPKQsleBoO/m+keJRd8tXcQWOGIBGQSDRNz7JWg 9kGw12g6vpMFz8GBnFmWDc2RblID69ZJZ6Gn9eok6Tq8kcGlp7GfxelsOHa8driaO08V+umlCJok WsPO2/ntztO0QShanGU4752De1P+oVCIKomucJZj3TvDFOnRl8P3rU0WPfjvhadEJiLfzeunOxIW uYZNHUUVvPmUNCz8jDbfdmsuLxtkYzBPnuNmV9529EDUyFpYr7TWrJKvZ54YOfbmZlImAi4kRkM5 W31Hgpx9wfoU/DbWo3tk4KysnKmbQp8FQOz7k8R+L8inLwrePxj1R8jJPNkA2WpD1ka1WlsKCuP2 JsX3qbG+XrCcWdGPYZYNuCIFCJ2BfY4vQkLQKKkhP8hmfwHJtJ+o4292NoFWxOgG62tvFOjl7LVT zKTd+rV5uxDXt1n/0MfTGrxsCLtNuI65JeUGR9GRF8llcLtNirqPE0+fePG2PS0nYJCdoXT//Pqx lbCXVqi995oFXT/jMbO2bI6+U8LntFEidXzJCIwQWG5HQiE5Eu6A/QZoBIAzdLJVyXkq82S24j8w wF+oV27UqNBrV6nhbPaosSUnnK/a69TEegpDCu0QofGg1CskfKKCHKfVjh4kM7DuPK3ZoVGH4Edn u5rXDZx4WpRwkx77rPfZGQ2KFl1JuTssLaJk3DrN+DdK3K4WpLNFKzuWEIW6e9FJp+bAZIj7iO/F 8dF1Gg88NEgUvlvJTeunDOngAb0HidM9IgafNqPsyFXKdOR2O528bCAPvYy3dL7m40RQhLvaxLjd WUbUeqnhm17WNeKMX1OuU7TawqqvRcQZUHm8Y9AeGrifhdd7U+ozxcVwV5Jne0A+wyGi3pLYSPl3 62pLn+q6sC+quZRn27PeTefKM98DxEhfL1jOrP117D5V64Mc2Lr6cEKnXx+uOOZz5SjbVYZPMvpY 9TPupZD0vamvab+CZ9p3Om3R9lhOJmUzcru1IjTGAyXqwIxAuEn/YEUg2A4Syv9suRVYslrDHhPF kMc7t8tqeR8tK46RBW3psXUXS3lM0+nXOKh0Rs1gj7jRbovORlsUbWznFZEwJnvp7SVHm9MxVHrU 1RavUnvvYaS1l3zGUjnhNxfgliB+wggI8S4LBBT43fvZ2YIL7Q2AtTXo93qwdvjn4NB1+ybW98qF 89CFA7BvZwBrR47A9ZOTTMxzuV7Yge1tgH1Yr33Wf1uvwKm1X4SXkUh0JMBDx69fDnIN+Tcifgcu XbgAl3f2wdq+HRhcewMcvvF68GWlVdaFTYAD+2Cnvx/ed+QQhBCV6XCaqn7TFW2S+vXT90LsgTOY NA2t/uNw67tNcpljmp0rcL719wAH12BwGdv7Bz4Eh0I33m24eL4DPWz3Q3nZj/JyKEBets7BvWsn wEID1xrC6XuOzrFinPWuQGCR8rlwwHZg68oV2OoNsOQ+9FDvHsa+c2469Gro64VjugcKRD16F+rR slbVLHTFI7AkVsiYsoj9wzAV2hRvbMAO2p9Wf3Tw5lvhxuu0is7uZmcbLm12wWp9vcuX4cD7b4Yj 8yps61W4be12aGrUJ6DeewFOzqt+VlkrZi9p8CzlzTbK55vQP3AQDvR7aDcdnp/MLGX9mahZILD7 HQmzQGkX5bF95QL8ZOcmVBb6CPDVJ++C2x+2uvIYVDYacMch3+H2LkKDqxIZgZ0L8Nh9D8NL6Jt7 8Klvw923ztNqiEzdQhNsnXsGEv/mWVj74BfgqdP3w6GFls6FMQKMACOwCxDYfgP+8Nf/LTSuuw6G vcnWFsCJ34I/+/qdoFspu6Cuu6UKO+fRDvhd+Fvk2MgC2IItOAW5wkNwhE3H3cJlrgcjEAoBdiSE gmn3vHTuyVNw4uGXIZFah7s++xE4ii7/7595DL72tBWLgJ90GQaP3+k/az96i/9nBBgBRoARYAQY AUaAEWAEGAFGgBHYowiwI2GPMd52JHhWO5GD9ncegqM8DeAJDz9kBBgBRoARYAQYAUaAEWAEGAFG gBEAYEfCHpOCna1L0PpBAxp/90PY3Pwx/GO3j+ujfhbiic/Dvzp5lCMR9pg8cHUZAUaAEWAEGAFG gBFgBBgBRoARiIoAOxKiIsbvMwKMACPACDACjAAjwAgwAowAI8AIMAJ7GAF2JOxh5nPVGQFGgBFg BBgBRoARYAQYAUaAEWAEGIGoCLAjISpiod7fgjfOvQlvk3f3v+dfwrGjN5InfLlcCGzD+dd/AG9Z ZyfZn/0HIXbsCC/3sPHgb0aAEWAEGAFGYA8jcPGNc/Djt/fD+z98DA7tgv2kdrYuQPPNy7D/2vfD sVv57KE9LNpcdUbACAF2JBjBNiERnrF7Cs/YHZ+DMH55Gc9FnlCPvfSz57nIcTwX+ex8z0WeGcY7 cOnCBbjcx6OAbz4KjtM9A0oxTReQJf8UCYHtSxdhw2Lc/lGyAzcchkPX7wILNRIK/DIjsLwIbF08 D2/++C3Yv3/cSAE9zvvfDx/CgRefdre8fJs1ZduvPwMHYvcNsy22+3DPLtiZeuv107AWe2BYpxLW 6e5dUKdZ853zWw4Etq9chJ/0BnDt2k1wI9tIy8EUpIIdCfNgxfY5uPfACThj5R1LQubUtdC/5Qvw 6EOntHORL77yHJz5/k/h3Y4xwzVr74UPn/g4fDRgNvz1F5+BSqen5eesyja8F77w4D3e5/ruXIKX zuQh/+zz8KPLOPg8eBDWDn8QPvapz8LnE5/GYyEdRGHm2xdfh++c+XN44aWz8CM4CIDpYqfugC/+ VhLuOObtyb5y4XWovlyBv6n+Lby20cM0mOiWGNzxa/dB8nOnJnj0t+HV55+ER596Ca774Adh6803 4ZY7HoT0Q3fDETd5pPoG6XYuwOmv/jG8ceBaOPvoE9Ac5paARu8FOD46KJnkv4SXKHOnUOYs51W2 3oVHTuK5nmE+punC5M3vTEDgEjz3e78NX3y0rL0Xy9bhtUdOas929c3ORXj+qefhYmAlt+GaQ78E X777JA/cAnEy+/GNl56BF38Y3J9oOV/z83Dv/XdASC2jJV3Fm3OP3QYnvjbqFST9sRx0X3to5hhM YxdI2vhiDghcgdOnboAHsJONpSvw2uN3eJdhoM+maX/Ty8s2PHfvAfiiZbAmi9D/9j2BdqV3pZf9 6SV48cm/gI5F5vY18In7vgzHb1wOF6A5/9DOfe5b8L2fvgXvufkzcP+dx6IxAeX0xaf+BJ745lnL lB9+bjn1ZfjGV1NwfFKojcH4IRpxXm9vYftbG7W/vWYjecGxTM8Ef2aPQL8hkgAC+Szyzb5v/o1c YviO9Z7nXywlqu2eR/qeyMd90mh5xUXdI3m/U5H0eZebE85kG9WsN43j8uLrVTFwUNoqJAPTAMRF ueUsyc6kKwopvzqmRKNrv+f8Nk2n8lF0J0TDjzz1+nJcEZnL+YPjptU0nTsnfhIRgaajfcTicRHD 9pQqNCPmtOKv9xoiruktn3YfywnfZr/iEFxd8rsiF/PB3JcvMVFbFd04A3DblZxIJlMinU4N2+iw 30zkXf3kDIoS5nbBLEo3y0PqskRhLpiYUTXbVL1mXtozGI3gn3lkfTZd+5uFvISum3+tl/qXQbso eWe13WSxtTT0mvOPjAOi9o29pkgH6PZi07+nNRk/zAZsVd9ErjGbLDmXmSDAEQmoVWb+wVleOyIB B3Xw0HHveZvXT98LsQcsN3AMUulTcK1FyNs/hSeeHsYyjMlKQrP3bTimzYpvwTN3rcF9w4nMGCRT t4/SjlPYX2+/fRT+3Z89AreS2fudi2fh04c/JZddxJJZyKZ+CX7mn/47/Nf/dAa+9gRm6pxpufIq 3HXD7TAsDjNPZUvo/fwf4J/+n5fhf/nVh2Ve2domPPJJtQ/EuSfvghMPj1LFUxn4wi8dh5/9mf8P /ven7oOnX7apTEOr/7hGo/XLK4+dgl/82vileAbKv//L8A//55PwgD17G8vC5muPgCptlJ9pOpsa 61vxZbUiEsLIHK3n8DqkrLrS8YMpEVDedUjmYaNwPxxajgmSKetlkJzI4EgX3o560JkPPvjAFyH3 9Tt24WyZs66Lvt+BV578Kjz9397W+pGf1J+G8nAS3t3HvA3H4Y/+t/u9o90WTf6Cy3vjmXvhQ/dh Hx3PQ+/s/aB1zTOgRfU/Ue2CGRRumIWkGTHpIibXG+azvMl24MX790PiaaRwUh0j67Pp2p/EPrId SdG+CH9422H4Brb3WKYKr/3xKfrjyl+/jm02ZrVZ+5MoQO+FL8287drZR/k25x8ZByRQF70QVhep yBqLTmsM8KeP/DJcefk0JB62BNz6JKDefQGcga1G44dRhjP4fxvOPvYw/NFLb8Lt//op+ON7bp1B npzFTBCYiTuCM9ERCDnL28yPZ+zRi6/5t/sdkUuqGaJE3jlD2ROFxPh3Z1qdEsddX5TILH8qX3f8 LkSvUxW5fE2jp9fISW9u0jFb2m8pT288p+fXKa+L5HpRtLvOWIWeKKZiMs+cc9ofPfoJ6S3NiLZM 3hc5+RyEa+bdNJ0DBckXWK2IBBszFy6O+mm3KKtG6bRM+CY6AgPZhpOF5ZkdiV6PGaQg+tKt62aQ P2dhhICMzIrUxxgVtVKJZP8Qn09EgszfiftEu+DqwbjrZWWzKqOm0qV2MNAz0mdhMZ2VvMh80O6p +09IB9d9KX/FiA9XBG9c1JakjhL3yO2djAMi6KI+jc5IFrQov2YhJe1yt11iNn5YSpFgomaKAMw0 N85shADpSIIGdVKBoBJw6TTScbnDeHQF4krrxweSJyQdzgu/NPichr2VOnJUP07RFpnx4N5Np3+m fRIm6HROdOtqGcV6dVNlgvTbg170ool4tqZ+wyvTdFomeCP5MkdHQm+zJSrFvMikkiKBIe3x4V9C pNfzotYidXYSh/e9dk2spxIiFosN0yUzedFo1URqzAc/mTNNN9hsiHwuhw6m8lBOO/WSyCQTIh5D uhNJkc7kRH3DK865LxrlvEglMGTfeteiN5kWpXrHo1bkUa8jynl0Qlmh/sMyEiKZSotcoSxam5rL jSSygDFMp+cS/g4N+1IuPaxXIpkcfifTiEXHCwvMdrAhSvmcyOfzopDPKlnGJUz5QmH43MK5VN8I T8OEN43kbExnLlcQzW5PtCqFIQ/j8diQH5lCbbbhy0RfRtEhdtU95brTEbWShWkBZdNbZliubQS9 v6Ue9OqfaBKUl3IhL4bysunsH1AHIB9yubyoNB16zVTOTNNJmg310jg9xcWnpcuSTC5o/q6+nfTh vm3FQC9F599ANMvIV9RleeR9Wg7U4iKLbc7ScdafxfeGSyZsVMz4YN5u7XKjf7fkACvEIHtKfWZT FygH9kv4HfheGHmx8yLvZioT+mg7zSp8Y72sJYOWzbheLMhlvZmKTz87tX6JBoo5//RxQFhdRJdS FNUs3ZjotlryEHcsJSTyEWX8EA0N59uoZyrFoX1UQBtp+Id6pRzGRlq0PegkfQ/dsyNhHswmHYnf oM4qlioQlxIYNKXCcxsMRIE4vZgB9WkVlbdxveqjRD3S04gEV/QA1tUe3McjrFvqtwrS85ku6x7+ Zt7eO4J6jTGKgURpWJ0ChhhqDhjTdM4qS77MzZHQm7gmOV1sOska3m/UVHTIEINxB0mvvWTONJ1V qOJ/HJ0GNm9UxIxVNm4QqNPba4l1aVzq71rvJ7JVLerFTjzYqMhOn9bJvo5lvdfGmaazy436ba0T tOXepo1+Zyu6TA/z79UD6ybTrzuwjEqcfN9QzsKs8U2XPfkni45yQfRl1IiEzbpatyzxc7QJ3HzU kxqWa09Y5EOpByfNdhF5cWOt1rXGXToixN4YXnJGyvPjOXils2pmqJckKHgRGheaKMJ1YP6BdoEQ ZnpJ8SE8/7oi62hnfrxY92p/U/DBqN1GwN/r1Xp23O85B1deL0+hz2h2gXJAXgx8b4K8kGzQ0a0G kW6bU3tzpW465fTY1rQiTDfV/mKpsmtfr2HFptEvBsiY84+MAybpaEkX6mM7mhlSwr2FW5/Y2eg0 IwMT0/GDLNrowlvPuPoSR96Ltgcdxe+5W3YkzIPlpCPxGtTZRUoF4rFpU6+hDGT3AJ0oEEiKYqUi yuWy/lcqu2ZG1UBbVxA2Pb7fqFjtzSMhnsEZhvEMX39TlDJx6RDIR9jkj4ZQ5ZtEWyERtew4z1hW 2O6Ozeq6LEcaLPGsoHNcpumc9ZZ8mbsjISbSWZypq9VFs9UU1VJOhk9adSw7oz9wIEoHr5liVbRa dZEjy0SsdC6ZM003BoZGpNjYJzAKoVwpi2JufUiz7kjY1EIJY6msqDaaolkrk5krEO4ZgYGoZtSS l1S2KOpNTNeoi1JhNIOvl2NzzjSdnT7q94aMwrHwSKzjrDfSWS1SGY2JyoZzdrYrauN2WkEve8re 4C6+jljabbg0MSIlPLW2IyGinBH9NeQ3RkyUag1Rr+SJfMbc8hmeMP1NWh5iUalWRQXx0P4QN1ek B+ol2h7ShQq2B4yeSSud5NkexqWzXOtscN5JPTjJSCX8c+kejF0pjA1X1+CEpIskZ6bpsLegIc7h 9ZKOTGhc9GSh72T+ke0CQ71E8AzPv4Fo1yuihO2ygv1AVjr5E6IgdRnaJKWKx9LG6fgQvd2Ght7n RTL4iuhIgCj6zFG6lIMJ7U++F1leHAWSthpDR5yz93K+vRr3ZGCM+FiWa1Nucu41kMYXSHuIpJcM ATHnn9Kt1qSabkX7EUPSeMiLlUrS47B/jccPfqSEej4QrWpJFIolUSL2sasv0fJatD2oFb4nb9iR MA+2E0Xk7phVgbLB4oC40++LXq8net1NDOWhBjuIgutkA6IMAmYFnIMuWZ5DQSiK/K+6zZJmtFs7 zA+V7Lj8TMl7Bt0zRzrrTJwFo3e7ymNsK7p+U4btJ3GmvlWyIyuoQ8Q0nZvCaXBy5+b1ZCA6OPD0 jPhEbOwd7J2zs21ZbwzR0yJKUB6kIed2JJimsynXDbeYKDSo+wbfQodSmyxtoEtMUgVnBAHOCEiP eEboAZSKh7jhk108+e6Jza5XmLppOpJ1hMvNmlp6k3Asr9msq4gR59IbvYi+GmC59kDR3zS/M5Mz zZCKZUSLQN5vqkgi9+ylIaVEX1Kd4rx26jMq13oorrWWUzmk/HQwy3Uwv6QenGSkEv65sVZ9lcv4 I+lwh7fwcmaYzlwv6TiFxkVPFvpO5R/NLjDWSwTPSPwjNQq7nt9KMi0forZbQqbhpZJh63SqiR+C p1OH0XunPnPmq+QgeJCo3osmL87ykDPK9sI27x3H5U611E/IJEpy3M/2SB/mlnesDeVfFL1kCIQ5 /5RcGjkSfPS6PIHFMU6QdDqeG1bbINlAFP2c0lpuSo6j2ZFaJnwTAQF2JEQAK/SrRBF5KqpxRqph ukO/7Q5nvdTyKJYoEBzIW4P60Rp79R3D2c6MtikQ8aqbKAIrFDHAaVH2PKbSg/RBR6zbM7GYX6CT BBWdNYaprdsRCuvDCIWWvUmlVg+CSaR0bhoVXxax2eJg6Dza7HZFF//6uK4rO14SoBvepH4wwoFS Tvec0GXONJ3KnRpuibzTMaDeG13RDXlioorr0/u9Ud2s+nXRYdYqqVBDfcMjIqOJHDrXnHn73Zum 88sv+Dn1zOv0W+nIxk6Bxpjii87n4LLNfw0rZ1gC0V+ujcUwVNbei2OyLISklpRn6b0Y7qXh+sPn ae3ILoUfQEZGLtkl0qVTenuw38Aod7JPy+S67H65VsiMrqQe9DE45fuEf26sFZ9cck7SRZIzo3TT 8E/WdHgRGhc9Weg7mX9Af+tlFxjrJYJnJP6RGkmaJ8kK9uhqw+eo/cOowGjtlhBpekkmMibrCSyE 4Blen7mJC4upfC+ivLhLFKJuz9ZP5KNX6uV7Rp1rBdsj3m/JPiy2ru+zNawB4V8kvWRYfXP+Kd0a 2pGAsqyii70dVNW0PR5JkA0piY2l2d2GlTZKpurr6ku0/AitkexILRO+iYAAOxIigBX6VaKI3B2z ymWiAklX1MvalWpQoRUIpq/aA/KoioAubcDOKpUrilq9jqH4WTl7bnWYk5c2dLWZ87SPk0TOWCeL YqNdkpEPhfESCIUbjUggyiNSOg3Y4Q3N33mghPttwye9tihl04Fr5m0P+qgExXPPsENfmTNNp+pF DbdS0PnZwySEDwGGje0oK9qd+zDtQFRkJzbqzJKZrCiWK6LRbAeE7pmmU3WMciWX0PgYW1J+HEtv 9DIUX4I7RT1V5LvIcoYlEFlyLjvC4beMpEg6TnCJTJudgJQXHgtFh3d7UAaTnw5mubYZ4P2t5Njb 4JSpCP/cWCs+uXhL0kWSM6N00+glWdPhRWhc9GSh72T+fvrTxy4w1ksEz0j8IzWSNPvoRPXq9HyI 1m5VyeZXailGVEeCS+YjEBEWU/leRHlxk0KWAUzkozv18j1Bu0AuldSjHytpO2JNfz6sA2kPkfSS IQDm/FO6Nfw4QMmyX5qG3KOM2tdTjB8McXEnU/UNbleLtQfddO69J+xImAfPiSJyd8yqQKlAcMDR 2uyKzU0MEW9WRYZsUqeH7NppVYOylEHYEDRZHu6r0Ag920vXTIHI1uxdC8a04E6ucp1yYOfTEyWp vHFdec7DEzzMknRmuGN/Yhy9ECMhhaoeKRIOa5rOxlR9q/znFJHgWNs9HFTLWVjbG2xhRGf/Fc89 N5rxlTnTdAoPZbiFkRtVnl4v5yyzVc+YKDqX7QRuwpUQZef7Npmm6ez0ob9V2JxfR0zlh25WpBeh cNL5rL811Z2RnGGJvrJkUTMHukl54bEgdHgtDdmsSAeknw5muQ6WLinHgXp9CnkhfHfziPBX04Om 5an8jPQSgSo0LiRNlEuVfxS7YAq9ZMoHUilF8wSnE9EfpnyI1m4JkcaXxPmBm1tPXItO8Ayvz9zE hcVUvRdFXtzlUd0O9rJSr9dW5dlARR4AxOVeYpVqRdsIWp/MwMoR/kXSS4a4mPOP6LRJOlrSRtL4 8FjS45hwVM/D2IGywBleKNontquF2YMzrN4KZ8WOhHkwL1ARqQJlw3Q2aBJKB547q6oG5TeYUaWo K+3YF20mWL3jviKdqM9GQ3JHY1Q83gMn3PxERkNg6HKmMlyy4C5r9ETiIj3s1GGAdbf3A3DgZprO SYfKZz6OBLmeFOuXylXERo96dRRvdWWpnns7EvxmYE3TKVSU4RYGD1Ue+MiLytnvqi86jRpusJgT aTxmcmhwEllwnVgkszFNJzMIcUFCcx3yZydWawzTxNFl/2p/K5x0Ptu/T/9tJmdYbqD+mgPdpLzw WCg6PNctkxBOtzE4wpblOljGpB6cZKQS/rmxVkt9XLwNTKf4O5t0Kj9zvTTCS+Li0/6DUZ38q2/+ gXbBFHopkA8B/CNVkTRPkhXqSDDsH6K1W0Kk8aWF7XgGOwzPCZ4u2Y1AQ1hM5XtO2gLlxYsQNVs9 Dd1eOV+NZ0pO1OSMbkuMnruiTAj/3PpM6ZFZYWTOP0VL+HEAsedj7iWyFp+Ura7b82bjh1lyXtU3 HPaLsAdnWb/VzYsdCfPgXaAiUgVKBeLR+W5UMnIAldTWBlvpVYMKr0AwFT0JwnkUlyLLcUUUj483 Xg1YdMVjZ1TPJWVdIFWc6NFvyzX0I0WfrZHN/aiXOVXSHBKm6Ww67W/JF4dH1v59um+CJy7BoC6E Yb5kAKQrSzrj5Djf10pINrDUOz/TdKqWqkMO50iQS1MMDUVV8uhqgPtGFMmxk/mQ601M0znLd94r +cgIt1NjIMp25I3TsNMyUm1Y57P20hQ3pnKGRQbqrznQTcoLjwWpH27YSjTEELNBRy2J0tuDgpTl WmHhdSXl3KN/0t4nOssVCoy8tSPWXLwlfHfzKEDOjNIReZlSL0lcMLLPfXyahozRjczfA/cgu0Cm wz1DIuklU/6R2smyA3WelWB6PkRrt4TIKS7V/hPoHJ50nAGRT5fMR6BBYuohBzSboPeC5IXmMbym bdUrysuZAPcayGDEqL2fjTXpFbJrduY0l3s1wQUinkiKZJL+JdSyUtQHWv9B+BdJLxnWwpx/SkeG Hwf0Rdl2imGURuAeT5DW9IjZ+MEQFM9kqr4m7Wpe9qAnqXvsITsS5sHwQEWkCgxSIAL3s8+QWVg9 gEA1qPAKxCqX5hnH49tcw1h8py82NuhiiZ52rmyw4nEfp0OPeYyFcCJYVA46ZeV4iOU0xwM9BjJd 6livy49pOpnB+ELyZS6OBDKwT5ZcRyypM4+dSxvIsZjYAVS0nk8I5cxxn9og185GTGfjEtVwo7TY +1rYedHvwSSDjLw8aKrTEHJe55KTd+mlaTqah/OanqfsOrmA7BINXo4imZlqwyadoszG98Jczq6q IyGMATuus2qnuGmr6whZFcniNgZHGbBc+wrP8AeJ74SBDHqopbMgVWxrmfYaqt265DywnwxoH4bp ZqWXlEGNhvjEOHcNjlA3wbjTPpxG6mEfULRPM8IliE4dGaSXTPlHaiMH2jjL6eiayFujy2n5ELXd uggweNAlp/E4dY0rOyKfzpOXXO8GPAiWA5Uw+D1/eVE5jK70jQlDCDaRm9FMv/dEkrOcxdxvqE29 ffSXmmF3HNVM+OfuOwL0kmHFzPmnaAGc5POy5r1I2qypY6qThZb2Sr9VlLa3eyNKKkthxw9a9lPe qPq6+pKQOc/DHgxZ9K5+jR0J82BvoCJSBQYrEBz2l+3d7TEEXotKUA0qmiNBz9NaN1aotYcKaNDv 4ZGEVbE+XDagz3jTY9YgnhH18VF/g96GKK0rg905cNqoKIVldTQFPIu+gZs01ulfrSaa5OjAEToq nNJKZx0taY05e+0y2dxxkjc1SjrFE+tK8mUujgQMHZMbAKHBV7UNbzzNoKyOFbTq7VSW/bZS8tb5 1M3uaCTeqeWl8rfSOTs/03Q2KpENt25d41O+2pKd3KDfFa16WWTwGJ+4c+2zFWmTjOFyj5Jodjal k2XQbYkcPrfqZsls1XVupmk6u4YRv7s1Uj9r34aR482i0z5xw6JVi6RxFaHasJPPrlcNH5jK2dV0 JEAyJ+qNhq4jxvqiVm9pTkWB+yDEhjIxkotivSP6KF/1gtKbXu3BhpPl2kbC+1vqQR9DXKYatInT W7WHbqssHQwWH1xyHthPBrQP03TGeknWdHhBo10gkRWNzgY63zuigzorrDGv56jfTcLd1y4w1Uum /CNkUyfGcLkentDTG55E1JN6XL4+JR8it1tZ8DQXamDqfaQcyZvIZyR9RrKwLifJgf36pPd85cXO YPhNlsaEjdih9Rzq4TARi1qhc7uhbdTPmaPkCO1resIZqZfTlqLRwC59Zlgbc/4pHQkYHVWue/eb 9VpdtDeJZiIRSMP+cWyD9jpVdaID8tMVXYb1o7IUdvxgCMso2aAver0e/vXFoN8R2fGeadbR2n35 Ww+vaSkLtgdp0Xv0mh0J82A8UURejdEucpICETSMX9srgYYHTtrcyC7N/h6Imn3EjzTCR0sILKUy /MMoABqTIDRDw37HHtjZaWOuCAfl8bXf8f72Ok+5j6c1qEGCO53rWJ5x9UzT2ehY32rGZD4dIz2a boQ3bkRoY0++3R0VhqURJ4TkF0ljPXN3fqbpRqioDjf8jEOnqjtFvGh17/WAck02GrXSWGGTWlrH cpYxhYbpRqlN/lf7ILhlc0hvsqC3IVchqg27+ex62eiBsZyh/rLD0d2yNAe6SXkarx1ybW3O6dyD pUlmYf3SuuswgpPlOlisJvZPJLmckXbxTLUPl5wTvrt5FCBnpumQXjO9RCo6vCSDLq2+cZd8OlOG uZ+Iu69dgIPPAllGqNE25kPSWy8Z8Y9WRnMOKJ5bbdLN2+n4YNJuKamm122payZsNkfk008njZ67 9RmlbaIcjF+e+F6AvMjyiBMqXdYjPeU7zguPiIRlWdqgbDivI8bHFcEBtX2UsTWjL2MwCP/cshug l5z4hLw355+iJVjO0I5yLGXeqOqTfM70DeEdcQAAQABJREFU1r5D2thc1sVg/CDTRr8IO4bQJ6UQ FyM7Mjp9nGKEADsS5iEJqIjss1pTxTrOVLRFW1suMCpUdvoB6wqpp1+FdNPNf4gCjFCXdjVPZlVp xx8X66WGW4mgN7C47m2kxJLrGKVAPJ5jOloFFWrpVFT0Xj/mUFXCikCwcaTvZ8t6OJZKMboySzfA oybborPRFkW5hmw+jgSLSiuKIO4y9GIiV6mJ4niNvTcuPVHJuvmQzq7LwZ/3HgKm6XCxS6swHsxP MKAcjOi18QQSjDygvLOv44mUKDWcQbB9Uc2lPJ0qVrp0rixcwQjDMk3TOQiOeNuq5DxpTWYrE5wI VkGW13yETcoRXhiRjMDXjeSMzFi4w3gV3cmZHf+oNgq15cP72710yqq8S5fF06JULUsj0W0MjiBj uQ4UHTUoDeifVA5dUcrEHW19pM8KY33qkhdTOTNNNyY2ul5StVRXXVHJOY/vRf0oRyPqzahX5nbB qCQzvWTAP0fFep2aWE/h2vPxrKHdht06ZJTQlA+m7dZBbvRbatfRGWxnTkQ+bQy8v731mZ1dGDmw 3g3znrcdaZdE8sAJq4l7QNjJsJ5yID60ZWYj/3b25t9oH9v7FOE6f//64ASL13uEf27ZnX3/Z84/ RYu3fCnbS49oHiG7gTao1wRWOl9z2/8OZrj6XGnL+owfHOnD3kpsZP6qTrTOuq18dezBsHXaje+9 y6oUMoQ/s0Rg6xzctXYCylqeWeiKR+B67dnVvtmGi+c70IMDsLZvBwb7b4DDh66HfQFk7WxfgQud n8C+tTXY6WHKm26GQ9e/OyDFtD9twYU3NmAHyxtc7sHBm2+FG68Lk2fEdFuvwm1rt0NTyzoB9d4L cDJUeVrCcDc7SOOFTYAD+2Cnvx/ed+QQXBcEPsl1+9IF6PQA+Qaw/4bDiEm4hKbpSNGRL7eQ1o3L O7CGxPYHWM+b3gfXvTuI3h3YunIFtnoDLKsPvZ19cPjIkRDYmKaLXCWVwOJhewMZsQZ9bA9rh38O DoXkhcpkzldTyNmcKZth9juwvQ2wD8Vqn/Xf1itwau0X4WUsAR0J8NDx2WveXS3Xhpy5cuE8dLE/ 2bczgDVss9cHNXPDMmaVLDr/ZlXyAvIx1EtXg3+rxIfXT98LsQfOIAPT0Oo/DrfO0/RZgJgMi0B7 9V60V61a4R4ncPqeo4sqmcu52gjsXIHzrb8HODiyr9c+8CG058Mq7ejjh8VW9yrYg4ut4NKUxo6E ebBi+w34w1//t9C47joYjkG3tgBO/Bb82dfvhN3Q78wDsque5855eOy+34W/RY6N/AZbsAWnIFd4 CI6E1atXvRJMACOwtxDYvnIBfrJzExy5Udesrz55F9z+sOXKjUFlowF3HOJGvLckg2vLCMwBgZ0L aCc8DC+h7/jBp74Nd986r1mGOdDuk+XWuWcg8W+ehbUPfgGeOn0/HPJ5jx8zAowAI+CFADsSvFDh Z4wAI8AIMAJLj8C5J0/BiYdfhkRqHe767EfgKAYefP/MY/C1p61YBPykyzB4/M7AKKvRi/w/I8AI MAKMACPACDACjEAUBNiREAUtfpcRYAQYAUZgaRCwHQmeBCVy0P7OQ3BUD1bwfJUfMgKMACPACDAC jAAjwAhEQ4AdCdHw4rcZAUaAEWAElgSBna1L0PpBAxp/90PY3Pwx/GO3D/0DPwvxxOfhX508ypEI S8InJoMRYAQYAUaAEWAEdh8C7EjYfTzlGjECjAAjwAgwAowAI8AIMAKMACPACDACc0OAHQlzg5Yz ZgQYAUaAEWAEGAFGgBFgBBgBRoARYAR2HwLsSNh9POUaMQKMACPACDACjAAjwAgwAowAI8AIMAJz Q4AdCXODNkzG1jmsG9DDlbyH8cztZTt+PkwN+J3VRWD70kXYuNwH2D+qw4EbDuMZwrwz3epylCln BFYbge0rF+EnvQFcu3YT3LgLdNHWxfPw5o/fgv37x0oWBqhv3w8fuvXQUu3fsX3pAnSwL9i/dhiO Hlr9Iw1XuxUw9YwAI8AIrA4C7Ei4mrzaehVOrd0O1kFl2UYXHjmOZ5fxhxGYOwKX4Lnf+2344qNl raRYtg6vPXJSe7arb3YuwvNPPQ8XAyu5Ddcc+iX48t0nleG/cwle/OZfQOedgITb18An7vsyHL9x 3/ilHXj9xTNQ6fTAdtVsb2/Du9/zAfgfP3ISPnb8qHwekOuu/OniK8/Bme//FN5tAzOu5TVr74UP n/g4fPTYEYW9hsA2vPrct+B7P30L3nPzZ+D+O49pv068Qf6/+NSfwBPfPAuXxy/fcurL8I2vpuD4 IQcxzsxQBl46k4f8s8/DjzDxwYMHYe3wB+Fjn/osfD7xaTyGckJ6Z358jwhswelTa/AAdoi7RRed e+w2OPG1ps7dWA66rz0Ey9Tby9NPlpA2HbxVu8O+4knsKyyyXX3CVa4L939XmQFcPCOwSxAQ/Jkp As1CUqBoCEgURG9Szv2GSFrv4l+u0Z309p78PRKeVxGhVaHTgkjSOpa9WDwuYnidKjSvIoJXoehe Q8THGAzbrN91LCe01tmrh0qXrdNUPZGPj9q6d1lJUWpszg0EyfMwemluVHhn3MglRjrTF/+UqLa9 tCnB1Mkj76LU015TpP3Kg5goNinvVDLrqt+pSL3tyUukxYtaPRe+cyOg+JnINdw/r+CTdiUnksmU SKdTQx07lJdEfunko5m37Zblo20F2S5JHrSLmm5LFlvyt6t+sYf6v6uO9ZISsMx2wZJCxmR5IMAR Cdizz/Lz+ul7IfbAGYB4Hrpn7w+eddg+B/ceOAH4NqAjAR7iiAQXKyLh6Uq9uAerQied9YNkHjYK 98Mhe9J8cXAtR0mk/eEcKKTStwO87SQNH3zgi5D7+h0qYmDnPDz5P/+v8N/g2uHLP6k/DeXhpGMM kqnbh0/fxmRf/KMc3HHEnpnegmfuWoP7hkEgWFbmbjgIfw/1R58eRiTZpaZLLXj87lvt25l9L7N8 StqGPDg1QvXtn8ITT1ua0f4kodn7NhzToq4Jpok89F64H7Sf7aSu7ys4833DcObb+imWzMKfPvLL cOXl05B4+Onx2wmod1+Ak45p452LZ+HThz8leWalzaZ+CX7mn/47/Nf/dAa+9gQymGd1XYiHe7AN Zx97GP7opTfh9n/9FPzxPbNvB+HomM9bbzxzL3zovpFt0EPbIJyszocWZ66yDaLdsmy0OWldpfvX kecxi+f2J1FAPfWl5eD9Hur/bPj5W0eAtvuJ4xU9Kd8xAgoBD+cCP5oCgRaJSOhPykeLSOA5LC+4 IuHplcGCnq0KnUIMRCExmhlPFpZodmRBfNKKIe0vkTePxgjH+57E3YpWUrqhJxqldTJrFRfVOQQm hKNRQ2dhN2o2lOKCxfc7IpdUURxuHhFM4+FnUvt0ljBZ0KJNmoWU5IW7ffRFKaXoSeXrLox6narI 5WuEv65X+MEeRUDKeQRZXRRUy0zbojCYfTldkXNFocVFzT/YafYkBOW4h/q/IBj28m/LbBfsZb6s Wt05IkH5VAyvRmufX/6Hd+CaawDeePYBeOJlK6s4ZPO/Ce+B0ULqd/DrE79B10zjK8QjXGhuwCcv /R/w2JPPwpu9y3D58kH47Ff+ADJf+mSA93obzr34LTj959+F+o9wna610jd2Ch78nTTcffKIYX0C km1fgOeffgKewjXFa7EY9JpNOIxrin8nfR+cPOIxv2KtQT7zV9DpXQPx30jCMble3CoDaX/+O/DX F9+Bn49/Du44duO44CnwtNb8fRPXvL/zXojf/XHY+KvTkP9uHXqXEZdbboff/N1H4EufPOqu4KLp dFMQ7YkBHyxcLsM1+O8teOGBr8FoYjwF+a98FMASTvw7ePJulJtD0WjxeXvr0hvwN//5e1D73l/D D960NhS1PmtwW/wz8Llf/Rx88lab3yQDyb81iN/7edj/6n+Ex/NR2gPJK8wlaX8YSg0vPHQ8TCrX O+G8+mT23CNa6eJLvweHP/PoMO9paFHETdGO7EyiypmdLuJ3IH6XzsKp940iANy46JiGnUk99+Rd cOLhYQuAYnsA9xylITnn4Svv+jl4wqpDHNeynyVr2QktkCxA/9tfUlEqEes8+XVcW33aWlv9Xrj5 4BaUnvouNFGNnXrwD+Abn/sX8Ge//3UoDpX+KXi88CickpEvo5yna3/R9aeR3h2SinL60l/C3/74 n1E3jT+oi274hV+BO/100ZR6Yuv8K/DEY/8enkf8rL0tDt/+BfjK/XfAP/2Xl+EHiPEv/Mqvw8lJ e2TYtEb4pnIeSlZN259BOn/alB6Bt96Bk8kHEZtxezHqNxEwyb+IchYB66V4FfXFbai7rGC19WIB fvjF+4bRp5nKBvzxHR79rMSF+z/TvljxfYX0p0301gV48blnofTdl4e6/uAta3D4plvgIx+Nw6c/ +2m49UY7utFOYPKt2nPk8YpdnIF+sZMafUctb+p2tOBxlREoS5Zo1Twfy0dvV2R919qq2Stku1jX 1kxjTYhH2Prd8y9d9p7d6rXEusvbrfJIZKve6QwBtNYFJ/xoxOfZStudM1mDp68Xt15V62HjWTqz NwWepDxPLJHORK6Gc/KOD0m3EDodxUe5NeNDXVh7IPhhIp+vUz5Eocr5bk/kYsHlpYseEQCED5Im J91+7cFJQph70v7cs91hMhi9E242b8Ls+aAlUnZdZzJjOUU7wmoZyVl4yLQ3A/EbNOV+BO518xMw 1Uqxb1DvjCNyAFKiqUJDxi/0RVFGQSREnQSKtYoqWmG9umFnOJ/vkPtwjNpJRnQ0KubX/ibpT792 65luSLO3nOp9glY57DpC7G3ioyc26/mJetDdBzjKN7wNlHNHnqbtzzSdH211e+8ESzclcqJDO0/C Bzdmfv07VpSkiy4vDqCW+LZTTo9lLSEavU21R06q7LZBrHqEwAV85NoIht3c/62S/kTmDTYqgTZa LDurPWO89a1XO3SNV5BOU/1iJJ+m5U3TjhY8rjLFZdnSwbIRtHr0DES7XhGlcllUKmWRJUZooVIR ZXw+/CtVRLtLe2GsKVHkw4YcS4lSrSHqlTzZzC0mylrvbSG0qYXMxVJZUW00RbNWFmniXEDP94zg 3BAZe5CD34n1gqg3m6JapCHZMVHZ8K+fezNJNQjQBwizxbNcbyEuRc0J4qKF8MH1Gzo87KUAM6PT mCuGfMDg7dpYDiuVokjZg/z4uihLGS2JWmtWMfX2QCYm0tm8qNTqotlCeSnliFyDW64JH6K1B0NA aXmIRaVaxTZc0f8Qt3qHjCY9ivIzwvVXlRzh/ikem61NGuDquU2+m6IdCVM5m0yV1xsSP49N6HoN NfCLuzbgm4SpV2kkjUd5VgpJD1gDAJVHM29vCqk7GNQbM7wishlL5kS9XpYOFattpPJVUStmxgOV mCh1qEdkdu0vqv60222odEO4BqJVLYlCsSRKRD/outaBK8HGLi9Uv4kGJnWGpwsV0Wo1RD4d15wL 7j7AUb7hrZQrz/ZPMzVtf6bpiMwjbaPI+4GoZm15RydCSl8CNKSW8MGNmWpnLl6SdDb/wssLxWmZ r4lDEvWM1TqbclNZLwcmvuCBSyi5NoWBlrfb+j9St6XXn+hWqmZiUgelssWhfd1s1EWpkB3qLDzF xpTLjnSrYxcIUzuE8N7WL+Ha0aLHVQ7WrPAtOxJmzLxIa46owMcyokVswX6zIBWL09vfrWflb6mC 01OJnm854+acqTKr7GZNlZfI1rRMNus5SUvc8RvtGCMZGqQEYzxxtpEOAsRGVQ1inTMChA8LoZPU L8qlMR+0QvrKMTLFvgBalq6bgeigo2nT4Vcavoaed/ukBFcUAOEDRGgPruLDPqDlEUfZsPMh95M6 8XADBGVYezsS0JhYtwc0sx+oRmlHs5GzsEygg5is6PT7otfriV53UzQ1hyqIQouM6ofZT8LUi4bJ aeRO1i5Hwnhne8dzr1KmfkZkMz8Om5ByFsuiK9n6bIj1sVNQ11szaH+G+tOK8gitd10gDURx3He5 Bp/0XYJNFD3RLqmIkkyFxnBYe18oQ17HkhY83bXk3wRHgmn7M01n1UrShvu3WGpb6SIQsXTJw/GJ LxE+uDFT7czFS5JuOnmxKF/SD86I206r5Lif7RGbzo0X1oPiwv3fdIwlWC69/kTXnX2iUyxT9ah3 T2x2yeDA4w3TR8tsFxjrM8L7KP3DosdVpjxbxnTsSJgxV2SHPMFYGBZLBD5dciwNwJBeO9Q5kafO ArrhV0xUN/qi3+uKbnf8h4Z4q6RC6maxsQ+diXPnRzYUkrMZY1BJ/dwdZ4ChQXhiiqeO2ShD5fV1 zAgsmk5SvyiXxnzQCgmHu5ZkqpvBcFC4OZbPfq8jsuOomSADM3x7mII4wnfLeRCLxdx/+Dw94ciu cDKqcPd2JBBjXhuo9kW72RANdMw0J/01GqLlEz0RjsYRlmZyZk6npI04b5zOnPVSy4PRkzF1Jeqr pRJ+fKim7WU5CbIxGo0Y0SMVXGXM4gGRTVt3SpxkJIWqv/2Ou2iz9meqPyOlcxGr6uPSDfRdgk14 PaHyBsigC0b/9FvKce+PpZ4m6p3k3wTbwKz9WfrDjiCgcmtTGdBP4yuKtozIr9v5gIivV/yXSBI+ uDFTeLt4SdJNJy923Zbvmw6CCvYMUV8tX4ut6xMywxoQXMLL9RR1J+Utb/9nWD9SN1s2pYwvm/60 lvnak3/W8qH5+Aw8gZSYTNBJVuJp9Itn4RMeGpdHeB++HS1+XDWh+iv1MzsSZsyuKA2TeqDzTf/Z tmShSagkSifA8LYN8aLdiZEcol7WsuOZUh9lo+psz5SNSyAN2lbmquwAQ0O9RAwcr3Bw8qJ1qZXn xFOItlzj7Jjx1dI5t1SeA50OssPeGvNBKyBcfbQkJje9tihl04Hr/uyZGpk94UP49iBTR78g5bmM 3Qi5KfkPklGFu98AtkEGAnJWN9JaT3SG+IRAhqNxVGkjOZuCTkmbnz5LV3y4MRlTd0ISvuijzygf 6B4JapZ2sY6EYntkWUqcJN2q/i79OmX7y0kBVAiG058R9K7Kenyl6hPYHkm7Da8nVN4xXGfuCpYi DiYXli46zR64+eedj1H7w6xM01lUSNocbbDi7A4pyYQPbswU3i5eaummkRdKzDJdD0RFhqrrUaGV tB35oj8fUk9wCS/XU9SblOfiUYRspexIveSVWMlDpP7PK6swz0jdll5/ojaqSOf1yImdzGRFsVzB CYS2dzRQGAxCvBOOd6OMptEvIUhxvWJcHuF9+Ha0+HGVq8Ir/IAdCTNmXpSGqQ98nT22Ury6klfP h84Cr1nU4TNLIcVE0RUOHLXCKuzKrwOQdcaZVGp4m9VPp0/mHdhJjdMQBeI2bKy9jOxlGI6BQGA6 hbfOhyno1JOGvJuCD1oJ4eqjJYl641iLrMupPdtrbXxJI22wkBnwIRKppDwXLREyCiejCnfvdkR+ p+2I0Gg7B4O+/eoRjkar0oZyNgWdirasaG12xebmJkZhVEVG2++FhqLbzCGYhdEPw2QkjZyZsvMb fUt6tMgQOthKisa8Z40knqqsXnO8X4Ssq6qLpu/m0v5M9WdAOh12vFP18ZPjYRKJDQit3sMf/fIg z72WdG1W5BI9d54uQo0eSLmS/PPKxrD9mbbbMQmSNrQdNP2CSx3cQ/1xIiM+YNrAdFHkxQu/JXhG N86FuCiO9yGqVCvaBtmuSZ5AXIj8OvtN0yqT8gLb24T8pewEyrWiP1L/N6Fs359l3VZAf1qVCNzk LyHKU9vx3kiF452V1lQveZc7+ekU5Unem/UPur3qjFKd1bhqMgKr9AY7EmbMrfANEwueVuDjOWze 8/6QkB8/w7tgrx1Oa/s8BNdPhVoGdWKmeLo9kbhFZdXeHDKKI2EOdBqxbAo+aOWpDj0Idy1JxBu5 7g5nt1K5itjo0VFXQPlG7SEicfR1Ut40WISTUVVvb0NqQ2TlJpi58Rp4Sux01+FotMqYlZyFp1fS 5tQvOEtsL+/yPmFhEqZeNJCZh9i6K8TdSkEjD6hjtCE3SwN00FKZ9ipnymdSNpWuCutImEX7M9Wf kdK5IFL8DGyPEhszQzG+7rEOeZERCU4513AwbX+m6UaFyzaIOjtTqokK2WhRj4gkxAbyIaDfJOmm kxdCyxJdynbqiO7QHDT4m2tZB8HF7cwK2Tai4EDKC2xvE/KUsjOVI2HG/Z+s2wroT4lvX3QaNdxg MSfSSbW8aCQ3KdF2hVHJhMYX4XhnZT+dfolO4BTlSd6b9Q947PMCxlXREVnmFOxImDF3ZMMMNBbG hRoKvFxPtSCBl3XCtaVuZTYQZTtcz1lnYpy5DAasu70ZUVAnJst25u3FN4KnvpnW6GU1EHBGTqh1 0wuh04v2EM8kFlH5oOU9B4PEkb+Uz2TRvb6WyISL74R/e82QGrRLaiYwVXLjpmEc/UbKToh2JN+d Ss7C0yjL8zBENyr2yQQgkq69KpQseztnvGjoi7LcWC9O9kCw31UDIIC0pu+0EyR8lpDYuUz9LdtC VEOYOEqmaH/R9GdDnigRKZ0LJMVPl26g70psohmKUi/JzSpVpoOOan9u3aPem+ZKyjkkPY4dVTmr 96L1t6bprJJlWtkGO3IjT2sg497oFBMRXR6p3yT8M5IX3Gsgg05Xe08b14aNCsqrclUnTph4IimS SfqXUMv90H7TzkkiuLhlMGTbiFJjUl5ge5uQp1t2vBIo+r109cz7P1m3FdCfXnDhswHuJ1XMKIdC 3mO5mU/S0I8l75bZLohqh0jeG/YPCxpXhWbSCrzIjoQZM0luEIKzXVon4VWOkcALQWecCq69FVRB gxl5MOn56c4TJATZnRichisJsU0V9c0k1TIDjxB3VQW1wUtEPAFDMvU5Q7XDueVx1HizaDpJ/aJc GvNBK0R16NMYD1qW2g0JSUuWXGuR1dnaHnw3bA9a8VFuSHmuEyQi5CPbo0vmaCYKd5dsdptayKvL KKfZGF5H0UuzkbPwhEpjRg5iaNoOOXo2pUc8kVB4F6Y0C8f1Zs2OTELnRKGl/dpvFaVDx70hGqUl jseX6hpmlFFfbGzMIE5MymZUQ3g27c+NZ4D+lLRi2KerDQSk05C3blQbCdRNpLwoAy4pZ9bA2NFv 1sjgz52ni1CjB8oRhQ4s3/UC2L/LvXxAROlvTdNZlZHYkAHFoFOWbcFyqrmCcEz7TcI/I3kh5Y5m ax0TA0bcmVUiKu/ee+aoCQ3HkdkEF7cMhmwbUapBytt1/Z+s2wrozwCeDZr2clwcFNdn0K84ylpm u8BYn0neR3EkLH5c5WDFSt+yI2HG7KPCPwzrxt3qe8Md63uuQVVw6H9Ax9GtyyP0ANfg5astOWge 9LuihWeOZ3AXWPe564aV7dZIedZ6rZFCG3Rbcgd+q0PP1rThObpU22QQoNJ1W2UZjWClCzIaTfG0 8k3mauP1nV1RlkfrecxsLppOQzYIUz5o5QXIlfae+Y06HQNlomo7kPA0kbI6RtST74YdgDGlpDxI 5kQdTz2o1+uuv1q95Vgn3MM2NnqvgWc9F+xz6GNpUamP8qjVGgIPVCEfhbtllFdbbdFq4jnROTXj bmFiGdYBYwySX7TLSO1oJnIWnj45iPF0JAhBnU8pLSqBYpoU5TH2Lh7W6qK9SZhBZlItzHNjGe11 qnJm3Xru5dChtFi6t1BrD3XvoN/DI0+rYj1praGcQWiklM2ohjAuzciode6m7c+qf2j9KWm16h4h nSUig/Fxn7j8adDHE13Gy3uso4T78rceXhN5IuVFGnDhPggxpM+i0eJdsd4Rfewv6wX7lKPRb+48 SdlTXNKoB0hkRaOzgU6njuh0NmX/PczetP2ZpsNC/dog1RvgjJQy7TcJ/yLLiwWQIz049jIZYniV /qM89huc06UPKXpaF6mXWwaVrguylyJVm5S36/o/WbcV0J+WAzUZw2WgJdFEXWCrOsu+zuFzW19V Pc/TjsRx18u0fU8cr0yhX1wFh3lgWp7kfTRHglj0uCoMBivyDjsSZs0oTRhto8XHQEGBt8P7vToO OxTTq+PoVPVB2UjZ6OXFZxh+q85W18uQ5SYLnuuKpMdTGnDu9F71k2yJiGcyoJwRrV7hopYhpULI ZJ0cec2MTlm56BemfFAlqdDnwPqoBJGv6FFqQyytzT8dWFrPXeVP0R4iE2klIOX58Xz0PKZvIhry hAJ9NlHh7ldWPFPUI2WMKuWTKEo7wiymlzMfOjwe+w1i5Kva5mX06NbJmNpYO0+z2JD7pbj1kZXG WkdvG3SSjuHFQNTIXgl2/tp3bAaOBDnr6m0Ij1y5qv60/5im/RnpT2K4aThobd5b76rZWW8+2Plp TnHSbmm9R3xSmLj0C77QJLP9dt7Ob3eeugSY35F1vxo2cV2/WHTKfYd8cEn69Lem6fLjfY7QmafP e1qDHEWD8zg1o35zCnkZYi/bhk2XaiPmvJlNShmdhvz1XA5iFYOOTLn3C3UcTyHXRtST8pxtQL9f wf5PyoiSDenAkTKudAVt8wvXn+hIyJONhS3srWU7Gg+cTjwjhnskWmK7wKLWSA8SuaZ8HdVe8dyr f1j0uMqDIyv5iB0Jc2Bbr1MT6ylcC2dvnjY2GpzhlHSNoeu3oZdy1FEmteMfFcG9Nu5sbp8/qxkm aAgnUqLUcEQIqKRGV61KznNAmMxWHMYHzb4rSpnx8ZGSxpjIVWqiMF6r7Fc/O5fweKq1uslMRjpp pELGWSD/zW8XSKddMcNvMz7YhSnDMOUI67bfmMV3p5YnUSy2wTfie3G8p4b7+Ee1V4VJe4hMt2Nm WsqJlFObbjp4xVKoIeh6107jDJ+2BhEO42CYNiaS6ayoNmfbVr2wCN2OxomnkzMvCryfSWOBhFU7 36QzJyrEU8myP+9G/NAjGUa5b6CMejm40vmajxNBUdWuesm3VVZcrJcaE9OrnHyupIzhruPjEBVp COMSstGjniiOB3nO9bNm7c9Qf5KBYVS9K3kf0I4s3mq6grRbEz3h4l08LUrVshzcuY1PHx4ZPe6K Ss55LK7iMc3StP2ZpJN8kLJFKMFBmXIwOZcXGfSbU8jLkCrZNmxd640fqcGCLlHH2/tFWUtBvD2R SAvu0+L13pRyHbmSpLxg/bmC/Z+UESUbS6s/UR6quZRnX2TxJZ0rizkEI0hxWVa7wCYwsj4jcm3S Pyx6XGXXc5W/32URj8LKnxVGYOvSBdi4vANra/ugP9gP77vpfXDdu/fNp0Y7W3ChvQFYGPR7PVg7 /HNw6LrJZV25cB66cAD27Qxg7cgRuH5ykuj0b5+Dew+cgDOYMt/qw/23DuDC+S7s37cDfViDo0du nJjnQuicSEWIFwz5ECLn2b1i0XhhE+DAPtjpo1weOQQhRGV25XNO0yOwCnI2TS13rsD51t8DHFyD wWXUZx/4EBwKrZy24eL5DvRQr62hjhnsvwEOH7oe5qHajKoYtf2Z6k/TdEaVmlWiHdjeBtiHzNpn /bf1Cpxa+0V4GbNHRwI8dPz6WRU0XT6m7c80nSG1kfrNlZQXQ2A42eoisCj9KRHaga0rV2CrN8An fejt7IPDaCsvpc20YP0Ciy4PObDQcZWUgdW8YEfCavKNqfZCgBgoS2UMetHKzxgBRoARWCYETPWn abqrUPftKxfgJzs3wZEb362V/uqTd8HtD5fxWQwqGw2449DSuIM0OnfFzQrJy67AmyuxGARYrheD M5eydAiwI2HpWMIEGSPAitwYOk7ICDACexwBU/1pmu4qwH3uyVNw4uGXIZFah7s++xE4ioEH3z/z GHztaSsWAT/pMgwev3N5okpGVO2u/1dIXnYX8FybuSLAcj1XeDnz5UWAHQnLyxumLCoCW+cwPPXE MDwVN7qDR04uSXhq1Hrw+4wAI8AILBoBU/1pmm7R9cPybEeCZ9GJHLS/8xAc1YMVPF/lh1MgsELy MkUtOeleQ4Dleq9xnOs7RoAdCSwKuweBnYvw4pm/gn945zr42K/9GhwLvdZ590DANWEEGAFGwAgB U/1pms6IyOkS7WxdgtYPGtD4ux/C5uaP4R+7fegf+FmIJz4P/+rkUY5EmA7ecKlXSF7CVYjfYgQQ AZZrFoM9igA7EvYo47najAAjwAgwAowAI8AIMAKMACPACDACjIAJAuxIMEGN0zACjAAjwAgwAowA I8AIMAKMACPACDACexQBdiTsUcZztRkBRoARYAQYAUaAEWAEGAFGgBFgBBgBEwTYkWCCGqdhBBgB RmAGCGxfuQg/wXOjr127CW68fnl2edu6eB7e/PFbsH///nEt8Wzr/e+HD916KHAduWm6GUDJWTAC jIARAttw8fwG9LBlL+259Ub1CpNoBy5duACX+wAHbz4KjlNBw2QQ+p3tSxdhwyporFIP3HAYDi2R zg9dEX6REYiEgLl+YXsiEtBX7WV2JFw16LngZUHg4ivPwZnv/xTe7RjHXbP2XvjwiY/DR48d8Rk8 bcOrz30LvvfTt+A9N38G7r/zWLQqWZvzPPUn8MQ3z8LlccpbTn0ZvvHVFBw/5CDGmfPOJXjpTB7y zz4PP8LEBw8ehLXDH4SPfeqz8PnEp/FYswnpnfmt6P0bLz0DL/6wB6Fre83Pw7333wHLcZ7HFpw+ tQYP4MlzsWwdXnvk5NJw4dxjt8GJrzV1emI56L72UCB2pun0gpbzjvXEcvKFqZoSga1X8bSj20en HTXwtKPjy6Edp6xVuOR4ZN+pA/M+6ekSPPd7vw1ffLSs0bRsOl8jjm8YgVkhMIV+2c32xKzgXYp8 BH8YgT2OQCOXENgY/f9iKVFt9zxQ6ol8fJwulhNdjzd8H/WaIu1bZkwUm/659TsVkfRNi/QgLV7U +tKysj90RS4WwDdPjGKitjTgKPlJ5BpLxYV2JSeSyZRIp1MiZuOYyE+UK9N0S1V5H2JYT/gAw49X G4F+Q/YnuYZ/v7PalfShfgF1bxaSmm0Ri8eHOjVVaPoQxY8ZgcUgIGUzUZjYtxtTNEUb2832hDGe S5gQlpAmJokRWCgCzbzd0cdEKp3GwRP+pexn9kA1KZquAWhPFBLj30MMslSlusoBgYO0WDIras2G KOdSxOBIiLqHTTfYqIq4PbAbp63U6qJaKYlseuwQierUUISt2NVA1HJpkUylRIr8JaRzIeb6LZnK i85gWarZF9VsSsTRsMwUW8tClIuOlm0Ixyc7Emhi03Q0j2W6Zj2xTNxgWmaGwBSG/sxouFoZzb3u ylkMybzYWJq+52oBzuUuEwKyT8O+3cPcnA2pM2pju82emA24y5ELOxKWgw9MxVVEQCpT9Mr2KR39 jsglbUcCiETeOYNAHAkRBln9dlE5DJIFTYE3C8qZkCw4B5d9UUopelL5OqV2eN3rVEUuX9Pr4Xpr dz+QHY6Tn7u72nOrnWwfEWTcIsY03dwqMmXGsj5OuWI9MSWynPyqIqAZ+i5v+VUlbe6FY90TY8f8 fKIxBnKywd2fz712XAAjEIjAQmylGekX2f9GtEMCAeAfZ4IA75EwywUm2xfg+aefgKdwzftaLAa9 ZhMO45r330nfByePXOdb0s6lc/DNv/hreOeam3H99p3Qe/V5OP2nZ6De7AHcchhu+/BH4Nd/B/M4 5J+Hb+byh0vw4um/gA68F24+uAWlp74LTVxbf+rBP4BvfO5fwJ/9/tehWP8RLrY/BY8XHoVTRzxW nS+8fttw7sVvwek//y4MSbN2Eoidggd/Jw13nzwiazbtxeun74XYA2cA4nnonr1fXwN+6Sycet+n hutHMfwcXnjoOCluC565aw3us5Y+Ytoepg3DoXNP3gUnHh6tlyy2B3DP0X0kz/PwlXf9HDxhPYnj mvSzZE06oQWSBeh/+0vh9waw8tu6AC8+9yyUvvvykPcHb1mDwzfdAh/5aBw+/dlPw63z3GnKKn9B n0B+ShpwjwlsDz98B+DQybtRng7JX+QF7mHx/Defh4v4zs2f+A248/iNo5/k8/dC/O6Pw8ZfnYb8 d+vQu4zyecvt8Ju/+wh86ZNHZTb6xQ68/tJfwt/++J/hGvuHd96BG37hV+BOLxrsd+xv3Bvj7F8W oPCXL0HTaq4HAffGuA0+k/gcfO5/+qRrs7CtS2/A3/zn70Hte38NP3jT2lDN+qzBbfHPwOd+9XPw yVvHdbLz9/imeIaVcSubcOmm4IMHrfN8ROvDemI2SE8jn+b95mL6FZB6Yg3i934e9r/6H+Hx/LPw Zu8yXL58ED77lT+AzJc+6e4zrL1zzvwVdHrXQPw3knDsRto/IO3Pfwf+GpXSz8c/B3ccs9vvFP07 7hNwL+4TgD0g5GtN+OD5F+DJZ18e6bODMfjC7/87uP/UrQEMN8Nz0fzbOv8KPPHYv4fn0Ziw9hQ6 fPsX4Cu/+WE4/aFfhKexduhIgIdmsT/EmO+XUcNfA2/BCw98DYa9fSwF+a98FAD1vfV30KffMcYl kn02hbwESMKkn6Zp7578w/2O/um/vAw/wK73F37l19FGdtutpumM+QBm7cGEzuh4ov3x4hl4+R/e gWvQAHnj2QfgiZctrsUhm/9NeA+gbOLHEtFP/MaX4bime9CENLEnptYvQ5JC2hOjd0f/m/GB5sDX IRGYiTuCMxHWunXbs43QC+dfttL2RanXyI3fj4t0xnu9Pm7M45s+1A+9uhYS76RPv8+IjiPThdev 1xLr9v4DHngmstWZzboHejoHTbl+1L2O3SQiAUMd7eUQkBJNLQTCAr0vijIKApc3kAmiVlFFK6xX NxwcCr4dbFTUWncPPGPZ5VqjH1yb4F8D+SmTboh1GwefpSCqXYJIV0iL6DUmtqVEria8o1i7ImuX S77jIdp3r10O1DFuHvYm7iGRLjqjbCRA8iIcnvJ1eREu3RR8kCUt5iKwPqwnDJgwnXyq9hmh31xg vyJC6AlIl939GEmXda1vU6Hyms6Ypn8nM4a6HaDsmPh61VufTYHnIvm3UbNtLFUnZ11nFpGAvJD7 yhAd7ywP1r1tOhNcIttn08iLQUsfJTFv75v1vMumduLpbitCmKaz6DXhgzBsD2Z0muDpbX84sbTu 1z10z6Q9qTztiWn0C5G1wP6XvDe8NOSDMxu+D4cAL20Ih9OEtzZEhnQYifWCqDebolpcJ8ovJio+ C+R6TbeSTGRyolwpi2JufThomdqRQBpzLJkT9XpZDpAtpZHKV0WtmBnTGxOlDh3hLrp+myJHnAix VFZUG03RrJVFmjzPVKINpv2YKBWUxz4HvYbiTdy1IZ6ZI2HSvgqSHkiIBnEkNPO2k0l3MPjVSz0f iGomJmUxlS0O5bPZqItSITscnE4tX6qwq34l8ZsQAtcupSUmpTaVd6sKA1FO25ilRIt6BUhbGnbA uBlnud5C+SxqA31vw3QgWtWSKBRLolTKSYeE20nlgLGrOwLj6ZyoWW2iUUMdMaqHm4e2oRET6Wxe WHtpNFuol0i5Fv3lCZtGhMXTQXHopQ3GfHAWOOd7iQPriRkhPZ18Ru83F9uvCA89Uao1RL2Sl+0e Q+zc7Y+kc+sQ1edoOoOkidy/k7RDfQZJUfLQZ+u1TQffp8NzYfzDQTOd5MkUq6LVqotcytbvI+fC /8/e9cDIVZz3z8YXxwQfwtQQ+RIMmFQGlSVAU9O0jrRESkhpsg35A0mOyAhpiSKSLGqV6pQ0Uq7/ tFGjsGkUnalgU+BIYanaJUo3bbNxWdJo8+cctFQsatbNXsIaWMdL2CNamz17Om/3vZlv3pv3Z+bt re/Wc5K9772Zb75vft833/yf8WLtym7k1w6pFIukSP+VSosk7ZzZk5ynbbrS4HuxWCCVuhvPIQN1 XDTaZ0jnyvYSGQd3RM3yTgfWsP4y+RLV3xJZyCRZ/W3ZrUd/unS22Op60CwP2nLq4NknjWqJFAa2 WSRZNGmVZ7ZJbbdQIo0ObvRYoOjwo2TI1tT8i60I+4fVvyHtOjp8NNb+gyjl2flmBhJGoPd2Jcsc WipbEVJsV/lIeNIV5kQUHVaC5JdcFUyvTRot1KN0CFV+UWFesKfBWcFMZGnRs/7o7KBd6WGnPO78 daocz3TePVPeRjP63pUTKpA4cRkOySxp9nqk2+2SbqdNakKDD0i+7tYBb9TRrQ0RT70Np2En6XoG EpwDIMUBBicf/r/8cMfEXFkSrUvaHXdHWhJtg3zi+gzRCWpgCrN7Vj6FMLFMixVjWhjsIfgwzHRR PovHcOyTRXt1itApYOH8oZp1BpHo6ohCnQfYT/1WlZSq7oG1PmnSAc22uz1g0dAVKs6hnd6zP8Tk I+MpkkUeSBCxds3SBenBxW+tXzkOxk+MBut49qlab467XhH8RGKO1JGL7dXyrM3gmUlFdTWuh4eY 8/pD8BmIRrV+F+Skgwh48Jq0K7wTNyue7B4Xz3Hpr1HwW8lHsWQdKUlHdCRG3mNnJIT5WYedKi5a 7bM49uIIqvyrV96x/ubwykC6lqeABoPcZUWXzsmWqh50y4O+nHp4OvmzftXOSNDkh2wNFPwLltN6 5vVvcLtOVw9ufuY9OgJmICE6Vr4x8UxxxXP0Kb2izplFp51NTzBNFTus1IK74+zLVi0AFWbH4bKC yWbYeCPFiWMxGW/+8IGCCVJu9Uiv2yGdjv2PdvTrbCY5Rbx4q8EyzJ/TQfdf9jgv6bxZI7R5Z5tC 1IGEHt8q4Tf4UM44cuD84S0RqgMJiDaVo4Ml6hhtJApm16E66ZMSW3WQIQ3U4W4WndU5QDyrFVBZ kpVXvvpDtnUFI8ntR+gU4CiD5yZf8eTjQzwkng/9weBY2y5HvW6TZG2/FMw7egXuZrnmenAzXON3 lh+0+mw4w+KUV7oc1PgJTS2o26davTn+egV30DMF19ZGuhUmbduRx4cg/4Lr4SGwPj5DQsPsNaR+ x3LKfEFl3pn5xSvh4uM5Hv1xvADm6VSJ+NdDq0G9WItx9d44fxm2sjTVcNFsn8WxF5nQyt+ilneO H8CcV391PiAn6k+XjmdETQ+65SG+nEOJo+LJ82c9MR8R2lYS6awVm9ZkW6T2BLI1WRmQ+xc3v6iy 6urBy898iY6AGUiIjpVvzErWrmh9CiMvrM7Mv5gUdlieTosYVf8NFeZFexk3l8sZ4eNODTvl8eYP dXoDGuxOA34RT/NoosNw8OOXKfmkzPHyGxTwEqJlVz72suSzhaGMGnTCrJGXieuL1WHmnR0Lu9m5 LFkslshSrRFxJYUryXX8yvTpgy8WHZe9LFu6S1dwsAGinHfwD5WlnEQRDXaWBW54Y67OM7cfWQXr xLL2WjtLOwPjMQL00G2QQjYTuGd31nMbCaKnjyp4YkoVOi09YGZjeGb5MX5idGjHsE9sM+H15vjr FdxBX/DcHczL/mzedU6J4F/cUw+cTvAFiEa1fsdy4nrfUTKf8cYD2PHxHI/+OF4Jeh4FGiseZg/h Jsu7g4H+L+cv6CsgQTVcCNFqn6F8K9tLgOyhQcrlneMn1x+fmBH1p0vHc6CmB93yEFNOZTx5/qwn VqdFaCsNKHX4IVsTdTSURe5fhmH4/2iy6uoBczLPqgiYgQRVxDzx+bJxv84kKwB0qTo+PM9Jijss uqxwrWaLWWHmPBhf5kS4U+MFftz54zIMBgsSCZKQ/rM6xgmy6Nlu4KAa/Zfph25tqLc7pN2mW0lq ZTLnrCShHQdxSZ2TNpKVYeiE+f0iGjZTJMZl8vhubeA6FCkD3gIPn0mR4ghwDOA+1iCGXySd8O08 MFsYHnzWKrKOd6bY9MrOypJ8OSw/pAk3vL3J4BUtgY1MzM9zAJIsXfsbGoBwBt6AlSU+sBTImyal hieXR41OQw+c1VieeH6MnxgJ4DHtk9Vf1nLZ0HoT+V1rIIiVA3f9Mrp6JbiDzuXxlD9c3pdUBxI4 Fgwf5gc5T16/U00G8iOELxXG/oynpVtPM/nWVH9cTs/2NcuIQ/Ie3845f4+efRJXw0WzfcbyrWEv PnKHftYq7wg/2YB3u8S2CAk2jVaLSreU+NLxXKjpgcupVh44nbKcWnjy/FlPvE5zJhPFcOFNlx+z NXl7Se5fBM6Dl2iycjzV9ODlZ75ER8AMJETHyicmWkrj1zHMO0vnM8I+SSdB7rBwRe2EjuiXFWbO g/ENbGiMO3/IESQls8EjggMnwxyUW390G4Kz/BSkNyxgWSM44gFTNGKa8C61tKLglQd44Gkpx/fJ 663E6JEmPZyvkM+RzCxPa9jJTAtL+zE+G+2Z6ZPZdXAO+G0YSVKlHZI6WhEiWXAgND69M430qJ+y c8gqL2tyCbj9BDYyadl1ViSo3EXO9j/SjlM6VyKtLu5tReRNBWd4usuHPFPsqyqdsh4Yp/E8+ObH +AktBcS1T1Z/uQZc5cJwe6fX6npXGcmJ4n1lda6sAc3l8ZT9QDq+VVKgYzTc5zB8mB/kPIVOF6MF IvNnLB0BZ56WLp7ydP0g1+XH6eQDCX4z2n5yqH7n/AV9BSSjhotm+4zpXMNeAmQPCtIr7xw/6+YQ zx/aKirYNBpIUKPjHNT0wOVUKw+cTlVOPTx5/qwnVqcxHyGG4zdtfszWVPwL5jx8ZrIGtkM4nmp6 8PIzX6IjYAYSomPlG5MZON3DhfdZDwnQ6e8+BUDNYfmKERzACrN6xTHe/KGO9pgafCx/EmfaKvG9 8rOLdRfG2GlFHUjokSI7ICgpOeOBNxQBxH37wg0SEa4LdAnree3TffKL6LrRBWmvmZL16mSOHsLp rAyxBlX8onqYnIEPQfqUitOpsIMHM/kCu3Y0MVeSRsezWLKVKnzAR74CiSfK7SewkYkaS74y8UTt J1SOZhe9V8yhNAN509QYnnTm0HtdqYcx+6BMp6oHxomaaKtGT0gv2f/KpNH1LGJGsfUeWX6Mn9AD UKCKb59q9SbiN6Z6BfsJsZNjARFQ9lHZ9HTsaT3uDCoK5TZG/Y7llK3AYnYvrKiMj+d49Idn7CUD SOhaZK+OBIPVfAnQs0+Karhg/6zQ/oxjLz5yB39G9qJUHyE6dig459RvFnxXJLDtiUp0PG01PSA5 lfwLolOSE9Ep4cnzZz2xsu3TN+GxY/BjtkYPipas8GQyCP6Fc3aeeLygdgiSU0kPDhfzq4OAGUjQ Qc1Fw2fSgHhOYEanjoOswNO01ByWi3nUV1aY1QcSxp0/PPKZ9+wt5Rnuj6ivwByUpINACDrojnag xSMZeCMBUnlvZ42LKjy1K86MNT2rIC8OTvTqi6xiTMy7bgsQZEnSa8PwDLPDokdaLfdyWCfM+9uv 8VtFcn7L5j1L2sI6yF4+4/wSrE+ZJGhWB+1/9zTiHVJWlugyaI/e0RJ9WpG57l9xUrB/uf0InQJX LNpNJgV2uniSXiPriTD40OvhAoEa0HTLBg6xIjeL/OrLYN7UP7ErUOnAl/viErkog6/qdIp6QLyX cs6BcMMtGx4/jOLqPgbblfETarjGt0/VenPc9QruoHs7qQFlH/nb9KJ4SCPfNgVEKLfMJ6nX71hO 8HQo2uxQVuuwQrzRKy6e49IfO0MAqO90OWScB6+O1CxaHjtAz3IC5fagVvssjr34yB38Wb+8M79L 62Z3e7CCbjNy60+XzsnHuOxTT059PJ38Wb/sIHW6OtZVNHA0+hyDH7M1q73knnDz9y8uASK3Q3CZ dtsLTnNU/Qec5tn6bAYSRqF5NJMGdFStWB925PqdOqqE6SADO8xNZKrqsETqiG+sMGs0NMadv06V zRADrfwXynXWSe/3OqReLZI5ehheMjeaGy6YI5cOJIidrrSwKoE3EqxrbYpVekd4ter9V6mSRht1 +tGMk7WtIFceNha7zTKZDenI4g6ghU2+0hhg0+916VV/ZTI/6HC6Z16onLMJury9QGrNNutUWvaZ o9+HWxuSpCy9J5DaF7OdYSfNsvGJWpFAs9hZ4gMqw7118m0ng9LmwmM2V7EPrOyQIjsQkw4SCbZi l9O+fb0o3WbQ79GbE+zrVq2rYXssrEuf7fj2D+5AWPgXllq2Hunpye06yafpihHXKhV+ewT1PbaN WYMS9SK/XtXKq9AhEdkO3vCsD6SyZKnZooNVTdKktoSs2kOpQ6ekB8SRlWG7/LgblSiq9iPjYfyE NoaYMK59KtebY65XsN/02iOvOzzlr9/gt7Sg9kSnXmSrETzllvkk7psZPsxeOU9BHkY79O+pXJn5 s9I83wI36z4UMiaeTL6o9Ykmv16DD85Dcp7UOkPn2qwssEF7C08BE2yosZ455h49+6SrjgtfURe5 /cl0rmEvPnKHfdYu7/Q8gwRrFyXJYrVJerQdWM3zwXCp/nTp7Iyo60Gz3aoppzaeSFF4EGqw/ZHe 6tQd3OzUZe1EJ7o2P2Zriv7FYWz/Rm5PaPoJFzvzqoCAGUhQACsoao2dg+B0tly/s3nffZnYYeE9 8UH8lMPYLIe84hgOffBlQe5Kddz5a5bFzo5VUbj/Sfc8KgODlnexBpcrkX7d56wEjpdbNve7u5PX YvvovfmyaK39cq6+pC1Un1TQWQluPoP3hHcgYQEdHGnFsbYpCLRp+6BBV9YHr8x2HFm5Dcmin+lv YR0+uXx0Rtnu1Fu4eBrNmMhVMQo4MjuVLTMlhG97cLCU/3oHyfqkjGZfZDzd5aGHrsYaxLcOmGPy cb7hDVz5SgFrICvYX+nQKegB6cTtn3xX1yAa1cdQuzrb/YQioHHtU6feHGe9Yg0kONsQ3PWptbXB WXotK39splBSXp2yL9AxH819M8OH1muB9TuS00nb+ys/3ykOnkw+OpAQ7Ee4Yenxo9sJ51z1nQRX r444X/2nYD3L0tXBxe3/PPqbdbU/49iLTOgI3+KU9xq7CYnXW+48yvSnS2dlR0cPevZJ26Aa+YuD J1OX0OkWsXXjqc0vhn9hcg4eorcndPUg8jNvUREwAwlRkYoQr17KSRvqs9mS7yCClSwvoPwE3Qjs 1KLQWfDhwYGUh708mTlKuuVi+KlLFu0l1LL98uPOX7dBb05wruFzVfzJVJrOygYvxooKEKuEPcuu eAp45JZ3UqyZftH5uis3511cyTBMt0VnRGQdu8xCxWcQgcvTKC+gVRtYhiS9y37JRd8j5VxaysuS L5MrEr/FCAOOzHYcPtyGuETr5ymKPmXSFpmtJTxLYIX4aCBhdm6OdRYcXVuz9n6XYDDZXPbMaO3v flcyNsp5Lz+LJpEi+aq3PFizbkkPrwTJlSpkMTNsXPvxEvJMPVgp575GMoodqNNF1gMT0Gpg4I5C FLkYceQHpjvjJyJjFhYxjn3q1pvjqlcIWnnmXWLL6w75oGWHFObE7TrWLUVWuc3bti7QMR/NbT9y /Y7kzGSzwqq4gV9K0Vn8gC1NuniOV39dUso6h1479Rit+7LzzJ/K2jxh9hsezvWcdm1j9KPVxUWp fRbHXvwEj/A9Tnn3tHmSGVIoF9kkj7vj64ijS6erB93yoCNnHDwdfLrNCplPp+jkEi8XVrn3+iy6 OlenPRHTvzhyDn+jtyd09SDyM29RENhkRaJGY/5GhcDqCiw3WgDT09DrdmF65grYtX3LqFI/8+mc gfytHFuG1vFVCukW6PWn4KKLL4Ltr58QTFdfhiP15wEunIb+cWovb7oSdl0QNW8n4OiRJnRhG0xv WYX+1A6Y2XUB+FOvwsrLL8NKt0/tqAfd1S0ws3s3TJJ56heQZfjLay6FL9RoCrN56D50ALb7JXbi MNy+7Xp4mIYv1Htw194+LB/pwBTVQQ+mYc/unX6UI/q+CseWl+E41d9A7+dSve8M0LtVZpfbANu2 wGqPlp/du9axzhX04KC5+hzcNXUl3Ge/0w4WPHTgaid0Mn4n2U+cIfvcCPXKy8tHoEP9+5bVPkxT Xx25aqXgt8EAAA0ESURBVIhj9QN9qPuzceOpw+8EbUs0u7R5RivJqR0zsHPSKr8z0D6LYmrkRA/g /xoAz/8C4FQPXjjnDdB/y+Wwenr7oD46bxWFWwm+6RKAy6+ATa/fNkie0/8cXnsNYPMlb4Ytv70X NvV/AjdOvwOqmzfB/YWn4Lbzfj0Ux0O/AifrDdjy4i/hnHPOAbjgOLznhgPw76cJ0AEI+NRVr+fy BfKn8kcMX9n+Ojj6G1pHW+3WV0/Bxb95Bd5w7GgIvUb+LJ3/7y9g6lgLNi2/BOfv3AHbdvvhF11+ Of5x9efQTwNcOgO9rRcN2ktcvyOQz6WfgZ84+irs+HULTj1P8Tn/fNh2+WWCfQ2VYv7XRcAMJOgi Z+gMAgaBiUHgyOP3wBUfuneQn/lKG/5if8BgABpIsBohn77ugonB4UxnREkPtrAnjjwC2674mP2W hlrvIFxN24XmzyBgEDAIGATOPAKk9lMg//O0IMim33krbEpcO/gWFn7i+/8Grz77POw4b4qlYdH/ 6L++CDd8pgi/t+0qeODL98CV59NBAvvPCj/55h3w0urFcMkLdYF/88l/gI88tAQ/6u2FUmsJ3v2r Z4RwKwkV+cLkDwvXzV9U/ML4n+3hjs2YXz0EzECCHm6GyiBgENjgCKweOwxfX/guvNL5AXzh3qKd mzlokr+B3UF5MwMJQegoh2nrweb0zDf+BBJ3DPVHtxDBwY/uVZbBEBgEDAIGAYPA2iBwOr8AcPyY mPiFO2HzHZ8YfAsL/+Wd18KjpSbsufrtcMXlF8P5WwEajZ/CO789HJz4s/d/Cv727TQ9zIGm//TK Y3D9Zw7BAzd/AH73zdMDuhfqP4GnnvklHWA4DX/3sYeg/5X3weaY8oXJHxaum7+o+IXxP9vDsdmY Z3UEzECCOmaGwiBgEJgABFYOfwmmr/9zISf5WgcOXB2ywmDlMF1OeT0copT0mkH47L6Q+AIH8+JG QFsPdkIrR56CR779Uzi5dRek7vwg7Pbf2+Nmbd4NAgYBg4BBYI0ROP3Xnwfyor2s3+a16Y27YPPn /mrwFhb+0q1XQ/VHLwlSPt8/BXe3OvSiihx0rm3D9K+86T+9/QeDgYSvzeyAN03x1QpWQs/P3AA3 ffcJ2ENXr4XxX+tw3fxFxW+t5d/o6QuGZV6UETADCcqQGQKDgEFgIhB4+Tl45LEn4bWtW+F1510C +975DtgTZRPy6lF44uFvwQsnt8PbP/xhuDoKzUQAtkaZ0NXDGoljkjUIGAQMAgaB0SFw+pFvAPmn bwgJbrrtAGz+6IHBt7Dw/gN/D/1vPggnTr4Gp06dgtOnTsNTl10Hr8t8Ef5o3x7Y7JP+6ffeDPVn l+DVBx+FK57+8YDu9OYtcO4bzoNz70jDVET+YfLFDdfNX1T84so36fSCYZoXZQTMQIIyZIbAIGAQ MAgYBAwCBgGDgEHAIGAQCEOAHGsD+ZdHgZS/M4i66Z03wab33wqbdl40eDfhBp8zaR9h9mvCgxEw AwnB+JhQg4BBwCBgEDAIGAQMAgYBg4BBwCBgEDAIGAQQAmYgAYFhHg0CBgGDgEHAIGAQMAgYBAwC BgGDgEHAIGAQCEbADCQE4xMx9AQcPdKCLmyBGXrXs8rVxCtHj8DPXnwFpqaca2369ILjN8KVe3fR 1NbP3+D+5eM9mJqegT27tq8fwUYiib7+RsLeJHLWInDi5aPwUrcP505fDDsvmOQ7C1fh2PIyUBcC F166B3ZOclYnyJrPHvucIKWNLStnX71pysPYjGsEjEZnn2ur99HJqQva2uZPVypDt2EQIOYvPgLd KkkCEKp0kl3qKKW3lE0M6Cxa9i+RI2qpKLHUiryUSw7lW4eyaWUIE8XQH07GPBsE1BDokoXksNwn slU10o0Wu7fEfWR1vXm3jQbmuOQ9i+xzXJBOEp+zrt405WFDme/I7HON9T4yOXW1s8b50xXL0G0Y BGDDSLqeBaWN5Fl7ICCnOJDQKOXI7GyaZDJpknAGE1ILpLvO8ltbmB0OJKxD2WRQ1fKOvPlwLGPo T8Zb5ZuSnCoJm7gbAAFegadySxtA3hgirnEZM+Uohm58SdXtc9L1MOn58zUFWcAal2kZyzP7Tb08 6Mo7bjsbNz9dXJToRmafa6z3kcmphA6KrJ6/ibQXhIh5VEPADCSo4SWPPSJHUHc6v8l1PJCwDmWT KYUNfFB5Q+c/R6Q/mRxh35TkDEvMhG8wBHqknE2TZDJJ5hbrG0x2RXHXuIyZcqSoj0jR1e1z0vUw 6fmLZBZOpDUu0w6b9fOrXh50ZR+3nY2bny4uSnQjs8811vvI5FRCB0VWz99E2gtCxDyqIWAGEtTw kscWHIH+WgJcOPVTkYsY9+t6lk2WNzYok8qTniwC/jYi/eEkoz4ryRk1URPPILDeEKBlLKW5aitK Vkw5ioLS2seZdD1Mev6ULOQM1ptKcm7AyOO2s3HzG4tKNop9bhQ5kdIm0l5Q/syjGgLmsMVRnGZx 4jDcvu16eJimtVCpwVuO/Ct89cFD0D1+nJ4sloBbP/85uOvGvaGcnjl4OyQ+QVNJLkD3e3dB6JGG J5bh8fvuha/f/z2YTiSgW6vBzI13wt2ZO2Df7hDq1WPwvcfykH/sO1D7ORXzQoDpmWvgPalb4JY/ 3u85DM1ftlV45omH4dALJwFeOQn7Zj8J+3a5jolcWYYnHnkQCo8egpoFyWXTMHPxZfC230/Cu25+ F+wdyclrXI6tWwGee/ATcO8hC/IkZBc+DucDlY/+naQ/f/iRO+G6nUhGpL98rQX7j/0HfOmrD8LP usfh+PEL4eZ7vghzB/ZL9bFy7Dn47/98EipPfh+e/Zl14Kb1Nw3XJN8Dt3zoFti/d+fgC/8vhpw8 EeUndTk5i9Vjh+H+b34fTm69FG6/633Q/eHjcPBrD0O1RnN72Qxcc9Xb4La7qc15DuE8AYef+Ec4 +MCjULVsDKjyEzfCJ+/OwAf37eYMRvAUJ3+ga59adFT/33kMfvDia0DNdPhHjXLHW98L79u3y/ki /V058hTc+6Uvw+MUzAtpgZ254Va4566b4Dc/PgTPUmjf+t7bqA7QKYarR+Hx+x+HoyenIXn7B2Dq h/8MX1mIZtdDAfT0J5Xz41fBwSvfAffRhOn2L/j0dRdI8xj94wjKURz/GV3QQcxY9qnIi0Ufi32O QA+gZ2csnwoP6noYRf4UBBSiquOinj+BIYBKuyBGveniGu2V+bPfguQH/wBa3zoIC49Wh+2sy26A j//pZ+HA/j3+aWmVdw1/zeRU8bvjtrMR8NPC0189nhCa/iP3FeFXtKbcR9ts+3CbzR2ZYv4Ereua tH13bSoN+3fTejCWfWroHcu0nsvRQE7V/I3AXjA+5nmyEFAbdzCxpQigEUVqHUT2LzlfJn0pMf+o Muvfa5bYDJ+MX7bU4Am7nrqNYiBtIuvdr+0nW9U5O8HKdypHmq5M9lslws5+kGAj4+USN+Jrh2Ql 6cuwmXcf9hZBf5ApSlY2dEkuIde3wzezWHPJH0NOV0rRX3Xk5Kl3l3K2TSdJZi4ltW/PYYHdOpm3 DxJ0sMC/qWxZgifnqfaknz9d+9SlI3SjjcxOkyGHLbarC1LcMaZZt113+QGHOJ7wLLVrir6m/loV x1b8y4XqOTJyW5DjKOTN9gee8k4TjOM/5fIEfdW3z6BUg8LGZ5/x9KBrZ0F59w/T0UPM/PkLExyi Vf508sfFUG4XaNebnKfSUwR/lspVpO0s/fIu13+gv44gp7c9IecT1Z8p4TiIHI+fPp4KkqJDCOfK rWDCdpm1M1k9GMs+5fgE6t2WcN2XowD9++dPjsfa2Wewuk3o+kLAbG0YhT48DmuWFKp1UqssCh32 +Uo7kJtfZ91L1CJzqNOcms+Taq1GyovzqLORIKWWq1dvJdThN0xYTiCZyZHKUo3UlipkMZcZ0Hs6 hZQMyzY8c6BP93ejTmU6LzmLgMaZ47dSpLOLAzlrS1VSyGcH2Mh4efMb5UufNKolUigWSalUJNlZ pyOTIvlSiRTp98G/Qok0Oi5c3PpLpEmhskSqpQV20jydSidF9ygJPcZxOJCQIJnsAilVqqRWp3oo 5BAduOhiyBkFBmkcHTl5Qt2atxObmsuRIsV5MTc/yKuoxzbJoUGERDpLypaNVYokg77PlUIaB1yE kCfd/Onapy6dlY0+qZcLJL9YIAVkJ4GHLdKGqbMtwCqzmXyJ1OtLZCFj36Ri+wJPB13brjX1Rxt+ WM65xTKVs0pyae4DLPk9coZoVx4cpxzF8J9yYUK+6tpnSLK+weO0zzh60LQz33yHBejoIU7+wuTx C9fFRSd/tgw67QJt/+KX75DvEn5FSTvL61/ilHcNfy2RM7w9MW47i8MvDp4hOhaCO6wdkcxWhBD3 S6eatdu+KcLG07X04KSsoXeLdCOUo0EWVfMXx14cTM3vpCLw/wAAAP//5VEpKgAAQABJREFU7L0N jGPXdSZ4AnS73UZUWanTVtI9mJYgJ2h5ISojwWg5sTxge2HY44koyLITJ5RXXs9QgmFI1AYjgZmx B6kZ2KAWsxaFWaFaA4eO0iXbogKI8u5SyIQSTDsJhYA9MY01tXEJZgNbbbs6zY5ZmLDbLODueeR7 9+f98d77Hsn6OQSq+N7j/TnnO+eee+559wcYfZIjMOqwPACDyV+edYZSkVstlvN+y1eZ/JOUanLZ XctPy8iuxabbapXduoDlyi2lmK12hf+W9f3mJGyXc/z3Yq2n5HVuxptt1mhvBp5z2nJVNsZfm6tZ Xk6mWIugd8DWslNcMqVmoEyGubYGo5DnyR/1qi6WSO/MGmT5ZUqsJ2UYdaucz3J74CNszPrdLtty APF/Nhss68o9t9b1/8rvjejkuUwvktE57K5xDAAyrNrZUgkYbbGNTaHZg7bQz0K1o6ZlW2wt57WV Euv7frW7teXPVj9t8/m5G7N1F4tcxY+TSLtRK3D8Sw0ZsRGrFTL8t0rHp5+Wem0rP5nO1aZsQ4as mvdkDixAp2DV+sqkHSWxn3YE2uqnXW2MLVY/ZSpN5GCrZ3J9ZtfJ5WDCnxltIrU9Lvb8WfkFlvZF cGp4JdcHBdXP2mzy/hYK9YmP4pWeXnvXs9dMptPIn/AoZmwReiZqM6svPTxlCsKvuV5mK2jV3M94 xIbDIRuNhOPVqbh+bbaMHob7SUEO05I05Y6JOb3o+2n716nR6TFu+q3Pn1fyovXTq5e+dycCsDvJ 2mNUSYYgbEDQ4oPuHGuL8VaAST5YnxFI6K55wYAca3Hr6hU3YBV38A5Yjvpzn5W8oEbgNy9/+Leg rcTWVr36gWVXGzED9aEYNOYqrC8N0MNrSe+poDc+KDOpUZJfsbahEjHusgIPCEQP9jAEw4aDLQyM DNgA/0bDPiu7cgjTCa8SIzq9TIm+zemUAwm5tTgMHMKcwa03aMyw5uYIsZhi4uAyGI1Yr1Z0B79h +puIOcxswp+tftrm8/OGA+yZgQSRBqDE5OG5U9qoJwJdgQG6lV7byk+mczVIpxSMCtDph8Xi3qQd 2dtPC8ICWUz0M5BZ88Ei9VMlSV8Otnqm1md/ZycHff5sKUsLFxP+LP0CK/tiiwvmk+oL64eaJS+o WmBdyddIr70LGxfXp8t02voT89czVQ4m9aWHp0pD2J0IWogXdO2y+xIr4wUXhFyyq9KLNUlfbOUw pUmUHyt3fC1i5V+nRmcYgjrPdPkTZZnoi8hFV/sVAQokpCFZyRCEOcnCGObUKLqvbt3G2fIMaUTA QZQjRWeduoYdPjsi3iD6CMNbXqYXiHC/G2qkwpdxzBpFb1A5/c6Xymy93mCd7kbELAZfEZa3nN4I jJRiJfmtdf2RHmFk89WQmQXDDVYrF1nGh8t0dorLc8yMBCM6FaINbxLQKQcSahuShxZKgjSIicHE w2ddnv4RWp7mQyv+bPXTNp+fF6Fb0e1RpMkU1Tdtk9JGXT4bKmB7rPTaVn6z6BSztgJ0+mGxuDdp R9b204IunsVKP3luw4tF6qdKmr4cbPVMrc/4LqEc9PkzpszNkBAXG/5s/QIr+2KLC+aT6qso0z6n ZW6sezO31Bc26bV3YeOi7bVKp7E/4cIzfz1zK7KoLz08VRpC77bETJPqxFfYYuUM+lXOH2SnL9LG Pf6yR5kJJ+mLrRymNGnKfa+0owDQmvxJ+Ratn1LVdLkLEaBAQhpCkQxWmJMspiqmEUgQ01adGQf+ Ya/DDm/koHaoSkccmKYfDwQvM+NF/aeDZMClA2E08NKGPbbqzZAIDCxzrN6Lzc2LMb3g9EZgpJQX K78YIyt1HN7AGBCfzOTPxQd5jnM6jOhUiDa4SUinCCTgW4FZcQTUBu8t+wQTjoeHi/ft4JNh62nI Pwl/tvppm08Rm8AqWkekNGEBqa2G1tKGoF2SylWWVYjnZvIT+bLltsLl5Ca2jQWTmz7Rb0cJ7Kcp UV76JPrplWH6vTD9VAnTl4PQFzM9U+szuktBDvr8GVEmJU6Aiy1/cttsx74ZkOjESzmff1mV1A9E 2za1uJl3sfU570m8ZZ2yn5VmexeyieUplk69MuavZyra+vWliadKQ/jdJludBA2AFWq4rG8oAguO 3Vh1puRu1tw+MMMam2K5Q3r6qSczpb7d3I4CQGvyJ+XT1xcpE13uWwQokJCGaKWOIxj5RNvHp/XK HVywYt44c+EBgmkOaepjRLqutz8AFJX1/o6h8/ZryFd7QQJinnDa0HiXai3WkPZaCH1Tr5Q1Yv1O i9WqFVbMi2UREwcS1zpuSLZfyZbghtM7x0ACXyeGmBQqDbY5lEfZesbZiE5LPJLSqau/U/IE3yCv a7SkXSdbUv7QI7bUT9t8HlcCq2jHVKTJrobsM6I5I8EqkGAkP4nO0EBCzMwJD44E3/rtKIH9tKQv uX5aVmyt1159QqbR+umlnX7ry0GUvXfshBSk1+lXVGg07+xxsdYzW79A8nv07YsmDGHJpPrC/Kyt 5qo7oJT9rDTbu5BNbHuQ6LTFRb8dhQFl/ky/vjTx1KFzzLwlKxns/zZaUxlnstPlDRlcyrDB5e7b cykFOUwp1Je7lX+dGp06eIal0eRPyqqvL1Imuty3CFAgIQ3RSoagWMeoqe/DG51/hkBkuryyxs+X TJpxUAoZhI9ZvejOGvAHGqRBR6bU8Bcbe8954A5Un0eKnYBA1eDN8hj3D1gviYDCWsg0xVhiNH7k 9PoxCMsryU+/45emoObXg/tESFjHOR1GdIbRPvNZcjpNAwl8M0WjgehMRiISJOfPX7Ctfprn0+nA Jf4yvqVKSPi4772NCdnEMKleG8lPflPlrV2VkMXNR73lP8E2JqWzvDRpRzwt7jkRDGLG2E8r2iT5 JbATVlX7Ms1HP9VKOLYz7a6Ei5GeqfXp30n1JZCDPn/6lKkpJTqNcJHymfIn9VVGfoGVfVG5NbqT 6lM3nZ2Wwjfc8/lZXGaJ27uOvUZaJDqDtk6vDE7zzHZkhGBkYpP6eNrEeEaSo/yw2ShNA0S5EisX nQBCBmeydqf+Z7bIyq4vGVj6l4IcpoToyYztlXakoOvcaPIn5eM6sCD9lKqmy12IAAUS0hCKZLAg 0LBwTRef2r8au0v9sOPtjo9rv2Jm/Pf4WkBggZMEhm0+6wACDgVGk/nu6VmcBhbOvLwbrpcizHCM +3X3DYAzTd03+8HLGPE97nrTEHEAZDINLKI8/2O+IVBmVezi60/k3Uvy0+/4pYFTvqbsEu0U2697 GwrOWtrgBlR06PToNfpOTqdZIEHaAdoJMAX2nBDEj1OZiZKcP0GRuLLVT7N8eh04b3sheLakmUEB 3bXSa3v58bWzuHa1wbfOnmIqvy0N0Clgt74yae/29tOGvPnopw0lTp556KdMi5Ec+My5vWMnTPiT cTG5ltuKvv1MomeWfoGlfTHBQkkr1ecsqZTn/+H8dvFiAwMwsvlJr73r2et0Agnz9gsUZPHllH59 6eGp0hB1p/qZ6GviSRiOfJslcXKY8zIrsKGipC/BPkdTlhOidNPukXYUAFqXP5HRRF9ELrrarwhQ ICENyUoGyzFouUrT3TdgwBrSCQezlgDIbxchV2ad/ibb3Oyzfn9L7TQHLXHUEUbf673pusbxoCcF LTDI0JK70ymjYh2hM/jPsVpn0x0E4y7PWz1WxR33MyFTk/lghs9ImJYndypQqKl0OpHOfAan/ddY F3nwxo0OnRV8Pl3akGXN0PMTkwlGpmuy7ABPDBhOTlQYcjp4DZL8TDocb8qdw0e56Z32gKcS1MXx h1N9iD7pwIhOTrDZRVI6TQMJbNCW9DPL1po9rhfj0YD12nVWwtMKssrafDOe5NT2/Nnqp20+pNo9 umqIy2DGIzzZw13/6RzVOuK/4dFWXmNxGMV9ELy3+c4GU+vtPh59NWDtqghWOXoW0F1LvbaV32hj XQQWs6usO5gy0W95AVLH5oTQKQvT8tqoHSWwnzbk2eunTW1OngXrp0SmmRz2ip0QDBrxJ7KZXVna zyR6ZuUX2NoXMzREaqk+x47kKy3uZ9X5yVj4fN23bDNJe+c22cBeS3QGbLLTNmee1IPBXOll0Uz/ RSBkfWVUXxI8bSgcb7AiytuRufPnLfETm5hPn6/7N4JOIgcbuSNve6IdOTKw5M8Tn5G+eJnoe98i QIGENESLBstbG+UZu+C3zht7af2ZZDidwYP/2EixD4IwsEqd+arv6EePUVxzJr3FVPJ4hnpGIEHd jslxWgUNalQYp1vy2RjTNM5GhEqdgeCDR2fCb8UZE/Q5dQc6d0l+gd+w4/em6vuXKMhH7014Qt7E gE/U6c+ncGZCp5JR/yYpnXIgwa+HUVT0m2owRZF5jJ5FlRf33J4/W/20zceYmH4r9CMUG1+QpSs5 lmHpnWcB3bXUawdrO/mNWJ0fwRbNX4DOOOHq/mbYjuztpy5BIp29fooyzK4Wr5+cPkM52OkZr83o IhU5GPJnRKCU2AaXZPxZ+AUJ7IvEqv4l1pd3+44oG+gckRtcroR7W0izX0Lz5sP9JSt7nQYuC9Iz Dr5hfbZ48vqMLlS/mM/CRZqF311gPTn47pSfQA5Wcp/wtAfaEdJpz9+ESaa+bFD7+rn072619LU7 EaBAQhpykdZGFcvlYGeXw7dzMUsVVBJwFkPFf5ygOENXTttrVEIHrvlyIyKIIHJvNKuSEZYMQSbH qu3gTAbeceByiQAruFu06ODRoPM5hyPWrBRCaXQ682KlzuYwGYEzOey32Gohh6coSPxhvYHpopL8 Ar85bxDcQEnYjBLnbWs24NxkWKXRYuvuXhX5sN32OZUYxdalU8pjepmETuGg6pzaICgbbjQnMw/C HLdsroCzYYJ6JnKbXdnxZ6uftvk0HFpXl8J0ZqPp0zVcH1pr1vnRV4EOPIFeO+jbyW+IG7Hm1WCh 09bLq9zezGNPlAm9hu0oif00004MzKRgJ/TrXI5+evSZ2jM7PfNqM/tOQw6m/JlRKFLb4JKUPyO/ IKF9EZxqXkmBhHypxO0J719wFmfcVk027Z37PYE+XvUpFHudEi6L0jMPfdP6bPD06jL9Fkd7yr6w mN0RXMaLNSSQg5XcJaZ2dTtCOpPy57Bqqi8SPHS5zxD4BYcfNMT0SROBnW24eHEAhw/twAhW4LZT x9MsXS3LqWtjE2BlBUbDIaycfA+cuOGQmibybgcuX7wIV3YOwQrSOn7XTXDy+I2gmzuy2MAPO7B9 9SpsD8f4ywiGWN/JU6dAm8xAebvswUTeWwBHD8HO6DC8+9SJ3cnbkujcvnwRNq/soIoegtEY8bn5 3XDDO9PXMrDmz1Y/bfMl0d8duHYN4BDCd8j5t/0dOLvyQXgDi8RAAjx2141JCg/NayO/ayjz/hDN EpJ4+KaTcHy3NvZE9jMUruiH1voZXWT8L8vQz3iK4n610bO48iJ/W7gcIinR+sEYl8T8Lcov0GJf JLp2AR46ejecxydrvRE8cnoMF9829LMW2d4F5fv3ivCMke0ubUcxFNNPhIANAhRIsEGN8hAChAAh sEAErl29CD/duRlOHX+nUuubz94P9zxex2cZaGx24CMncOROH0KAECAE9hsCUiBhXkHT/QYZ8UMI EAKEwLwRoEDCvBGm8gkBQoAQSIjAhWfPwt2PvwG5wirc/7H3wW048eCvzz8NTz3vzEXAT7EO46/c N4fZRNPi6T8hQAgQAktFgAIJS4WfKicECAFCIAwBCiSEoULPCAFCgBDYRQh4gYRQknIV2PjGY3Cb OlkhNCk9JAQIAUJgTyKwfQGXcd09WcaFG+7Bk2fSX8a1J3EhogkBQoAQWCICFEhYIvhUNSFACBAC OgjsbF+G3g860Pnbv4OtrZ/APwxGMDr6q5DNfRz+xZnbaCaCDoiUhhAgBPYuAjuX4NXz34IfX78B fvOTn4Q7bqRlXHtXmEQ5IUAI7BcEKJCwXyRJfBAChAAhQAgQAoQAIUAIEAKEACFACBACC0CAAgkL AJmqIAQIAUKAECAECAFCgBAgBAgBQoAQIAT2CwIUSNgvkiQ+CAFCgBAgBAgBQoAQIAQIAUKAECAE CIEFIECBhAWAfHCruAaX3t6EIa7gPnnqFOzWo+QPrnxmcb7/5bd96W344U9+BocPH3bBGAMc/hW4 /fSJOew7sHg8F8vfLH2i3wmBNBBYfDtKg+rdWwbhuVtkQ/ZaTxLXrl6Cnw7H8K6Vm+H4jXthl+Ed uHzxIlwZARy75TbwneKsx7RmqmuXL8GmU5Hr0hy96SScmIER4emAS3ZQU8UCySiQEICEHqSGwPab uMvyPdNdlju4y/JdtMtyatguoqADIL8LT98Jdz/VVdHMVGDwvccgdW1dAp4L5W/nMrz61a9D/7oK p3J37Qh84DOfhbuO00ZpCi50o4/AEtqRPnF7MCXhuWuEtlB7vWu4NiVkG86dXYFH8eTjTLkN33vy jGkBi0+PR5eePTrvE0cuw4t/+K/h979cV/ibjRHhOQGM7KCiN0Y3jD67AoFuNc9QcAxyVTY0oMg2 n0EV9klHHZZ3eMK/SmdgX84eyLmr5SDhZ0TnAZDfRqPC8vkCKxYLLOPqKuTWjNqgBG/85RLwXCh/ wzbLehjGfOPRbfE4WfxqpNcW5e/VLPsSlyW0o70mfyO570E8jfjbQ8JbqL3eQ7iopA7ZWnbqV+Yq HfWn3Xq3gDbG24Tb92ay2YlPU6h2Z6BCeE4AWoCMZghiz/4Me5byfUZ4d80NJGTXmImbbZtvIfAd oIa5q+UgCduIzgMkPweinhfMwzZoEsyT4I2/XDKec+dvvMEqhTwrFAqTv1xm6uzheyOWd585QZtG fxSPk8WvRnptUf5ezbIvcVlyO9oLumAk9z2IpxF/e0FgITTO3V6H1Lk3Ho1Ys1xgWRwol9Z7e4Tk eb9UE8EAyK+xzbEJLITnBK09aAdNpDzPtBRImCe6BmXzTgNnJJi42bb5DEizT6o0zLkMzexpSznn rpaDxKsRnQdIfg5EsnM6F21dMp5z50/SM+fSSNd8eU1vF1mXKW3LTL8vcVlyO1qmPHXrNpL7HsTT iD9d0HZZukXb613G/v4iB9tYzp0pMJ/ZuWNWzU0D9/nqHgmuJJHwPPDcg3YwCYRp5qU9EowWgkQn 3r78Fvzlf/02tL79XfjBD50NBp3PCtyZ/Sg88IkH4N7Tx32Zd+D7r56HN358HY4cAXjrhUfhGVzz BZCF8tqn4ZdgutD4On594FPymmLbfNPqzen0k30ZXn+pCtWXXoPuj3DjmGPI5ck74aO5B+CBf3mv uokMrgt7CNeFncciqt1NuPfyn8PTz74APxxegStXjsHHnvgjKD18L9zgq0LcXoMLr/4JnPvjb0Lb qQuu4MvNs/C5zxfhwTOnRDL/1fZFePXFF6D2zTegi1mO3boCJ2++Fd73/ix8+GMfhtOp7HSTTA4T kq9dhJeffwae++rrsJLJwLDbhZNnPwufL34GzpyKRsXPbvx9AjqXJb94hiJ/3X77O/DM0/8JXkZl OYaKefKe34EnHvkI/Pe/eQN+gHrwG7/9u3DmRPTGTN8/9xBkHkVtza7B8PVHYvTSJcFUfhKea60u /Nrbr8CzL7wBwyuOkmbgd/7dv4VHzp4O5S9xu8VSjfkLpUT/oVzfAPGM3HNi5xK8/NWX4dL1Fcg+ 9HE4/OafwVfWZtmJBHrNWbCzLzuXL8BXv/5duH7kFnjokftg+ObLcO4/n4d2F63+rSfhzve+D373 89iGT7ht2Io/TiRemNCZBi4Aly+8Cl//7o8nfdP168cg97kH4VRa21pgu3nx+Tr8PRyBM9i3nYnb LwOxexV1w9l345/lCnDvKWy/UjtaZL9iLHcuQhP58UyGFwnkviQ8zRhMwJ9Xkam95u32lyH74G/B 5rfOwdo321N7fes98Ok/eBIevvc2r/Tgt2l9vhJk+zmX/sitz6zfvAyvnfs6/B22xxNnHkQ/7ISP arzluAHc8oFPwX13+X3fYJbZT1D+r70Ef/WTn6PVcD/oHN/0G78N94XR4KVxvhfiD4oKQ/H89Hvh 3O0fhOcxGQYS4LHQ/cIM7YSL8xVE5Aj8DF559CmY7I6QKcDaE+8HcAYP+HcsVE4WeHK5mvTTAhez fkzks8dTlKF1JdlBff9sWe1Bi6PFJUozKnFwyxqyCp/G603nVb+L6/51SgNWjllHjBrAvL9VZU2x bT5HOjZ0CqkON+o8qurRJn9nyr71alKET06nXBfr4TMwhj226q6DU9K7uOTKzdB8480G42vdJQy9 MgI0CvYMr5LIgbFRvxGLZbmxYUhPVPIEdC5BflFczHq+1V7j7cWTtf971tp8kzdAVvLTwDO72mTB WYnJ2q2HnQl/Xp4k39r1DTuz91YI2IkEeu0wZWlfJlk7FVfXsqxYyoXqHW5wJaCz4s/NbkxnQlzc ajuVrMRXlrXTnKIj7aVRam4KnMKutprcnvP2q9GOIKAvtngKooamcneyGstP1Gd2lUDuS8JzYfxh RVb2WqPd5iqtEHttWZ8PEG37acsf5jPvNzfZqudXZSqhy3BFOwFWbPR9XNnehut3VrazIUUvzh+c Vr7Z8voG4b/7/ZDQGQk2dgLtaJyvy+tdlfoijpEFnhrtIW27a40n59PgQsMOBv2zZbUHA74WkJSW NqQCsufoZ1ixvMYarTbr9rqsWasoDnK9Lw8Rxmyj3WC1ep01GnVWznuGJ8eqjQar4/PJX63BNgZp 5HMYtaHTBWigbqSWLVZYq9Nl3U6LrVeKE6dTcZ6dbP6GmSmwWqvD2o01CZcMU3FxMm6xihREyBTK rOnU1aqzovS81PA7oWPWLGW4A1wor7N216GxzWrV8mTgHqDRqc7qYys/p7JNVvI6Y/zOrVYndDbX VzntzrryhtlCtwguEtC5cPlFsDDrMXZw3rRBp/MsVhus1+uwtaI8GJq94ae+42YpPz+ekGe1dg/1 el2hf7W15eM4QbuVStLnT8qU4FK7Pj8uWnYigV5b25cpGMNuMGiVK1VYHe34emV1YtsUO2PFn1OX jR1MgosQNpfdxE7lWCfNQAIOPzz7ni23RKUhV4N22bWJOcbj6QvFUxBlLHcr+Yn6zK4SyH1JeC6M P9v+NgSXeoi9Dg4MLfsHHyC8Dc7cs8eyPst+c6M29fecvra24V+IO2b1oueDFVhPdl19/Jndjlmv WWPV9RqrSX51/GaLi/QHkRsc2Mt+SGm9iX5IG/cN8vCY+vhBfbGx8w56A9ZyxwmNxjoreC8zs6vY F3ljiBpr9fz+hJPXAs+Q9jBXf94aT4c/i4+fP03/bDntwYK/OWahQEIq4I5ZHwesW2FGE9+QezuZ 59b8sxJE5bZr/szy2dPZLos3b8VacA3WeLPNGm3fwF5umJkS60l9zqhb5YNm/qbJhUM4j8AKVd8s B3TO1ty1YAAlpsa7B3w330ypKcDlV0O2NZCI4M+TX5jIYavlOccYRPA50lttEdGe5WTbUG1CpxII Woj8bDhibKNW4LpUUt6AjFhN6sSDHbhan67jZi0/uT1gJ6UMzrZawgnJV32bPdq3W5lDXf7kPEmu teuTcTHQM5k2E722ty/TGtUBZYZVOz5HbbTFNjalkbclf0npdKg1wUXGs7sm7D0ADuIlduR0tte8 P8lKbzXHIzYcDtloJDrSTsWlI1tGy+9+loSnqdzTkJ/Hsum3kdyXhKcpT3J6E/7SsdcF1V5vNrlf B4W6MivBuj6ZQbzWtZ+29Vn3m9IALzAjQPktPkjoY9fgdszWXR8wPpCwWH9QxnNVmWk1ZFX+ojD4 QiMdOzHieyTEjTPCQdbEc8F2whbPcB41nsr8mfhnis77Zn8ov82rPWjwNuckFEhIHeAxGw62cMA6 YAP8Gw37rKxxVI1up+En1zafE5HUp7Mv3qCbnCohNcxizTdVf9xlhcnbLhxMr8nBAmfw583OyLDm 5ggxnGLp4DkYjViPR8RzrKUccYE713pBhlyFzWFzeD/8/N5EDsJJ99PvFCfe1uFafbxL92NCpxxI WIz8bHjFTtqTOQaWfKEsNuqJgFVagQRr+UntIcwBaq16MyjiBm4m7VbF00j2alarO+36JFz09Uwl SbsuXBBlb1+mdcoDStV2qTTxOyv+ktPp1K+PC6d2crFRKzHn+LBcLoffJdZNOf4qBj8ioNYuu/rP p0yLtp1dlZywJeFpJvd05KdKRf/OSO5LwlOfm2BKE/5SsdeKjzKlR8x+LCjtw7o+H5u6PNrVJ9qW 80LGrN8cswafdVBkGyLux/r1Eg/qB2cr+Bi0vhW0h/WjothF+oOCJoDVIJ7SLDbVD0nLToj64zER 6IgrzbwLtROCJjM8BVfGVxJ/YRhG+2fLbg/GnKaegQIJaUE63GC1cjF2zVI+ZkaCbqfhJ9c4nw2d 0hS4sAbmp4nfSw1zret/pSUMRV4551Yy/m6gga/1Crlfl6c5YHCkUfSCENPvfKnM1usN1ulu+N7y cipTuTCRQ8tzmCOmLIqypLdwqVBpOLBYuPxsmBR6lMF10ZJPMy1s1GV5V2/UDjxYl8A9/vhHa/lJ eIbRIgZXIVPJbdqtj0Vd/nzZrG+165Nw0bcTKlnadaEV4MHGEHvitzWqfZnWKQ8otZxlK/6S0+lQ q4+Liufc73DvA2+mXnViw7dY2ZmaO5mem50GiMc9HmxW3vAtCU8zuacjP1s5GMl9SXja8ubkM+Ev HXvt919wJty6NxNODfxa1+cDRJdHu/qS9ZtyWyjzpXg4A8AL6sszjXx8Jb8VtMf7o4v0BwVN4X5I 1PGPadkJUX88JmHoa+ZdqJ0QNJnhGcaf5jOJP1P/bLntQZO/OSajQEIa4EoDbe6IZjIsM/kTA9u4 Bq7bafjJNcpnS6fcwPhCVT8lIfdyvo7/3bowFCou4vkES46jh6f37eCaYes9Xwcfu2lNjtX96UPI tnmkLwcx3c6ZceCjflI1L2sOU4p52RF1K7wvQ34KATo3Ql9Cp/RtNfgbkrDOQa5BD5sE8ovFE+ei SOvBlWUPtu1WZg6v9fjzZUpwq11fLC6SfCvyzCWVMO26sMWJGSzOwNWzJ/7vCPuC1QqnAd+m67yp t+IvOZ0OQvq4qHjO/w43qXLX9BZquEBtKAILjt1fdaaabdbctuvbL2ZJeJrJPR352crBSO5LwtOW NyefPn/zs9diU0E58JugPh8gejza1if0067fFO0X8rXpxtebdf4irVjHNj23j0R7TJ8wqX5h/qCg KbDcwyEkso2JfFb+LsdYlKP60zxBzIVm3kgenKKjyhDPzfgT+czwjGFz1k+x/MX4Z5Nyl9keZjE2 /98pkJACxny9HjpAhUqDbQ5l71I0iLgGrtdpBIk1yWdNJzYwbxMZozNqYxtmFC7iOVhHtUesj5tA 1qoVVszLa32dwUFBmYoXRNTuib4cpKlsuYhAQjXvOtBFZV8JO8rUXPp0Yr6lyU+lOf5O6Iuzo27g YzMjIUIu07ITyE/CM/jmXR6gyo6ptM49gX1xaOeyj+UvgKD1A17frKCVhEsw2CPkm479FOXZ2hcx oFTlFAmUFX/J6XTo0ZZBJPHz+kFshJbBdrvRmm406yyncBzODC5l2Gh6m8/69sJZEp5mck9Hfrbo G8l9SXja8ubk0+dvfvZ6i+unbAcS1OcDhPMYa69t6xP6adtv9viMDDzVBV3eHt9XRcbDx1Qqt4L2 uD5BVLUIf1DQFD7wjZoZKfLZ9kdTPkU5epgIdKKDAHIavF6onRD8mOHpo9nkVuLPxD/zqlhee/Ao WN43BRISYy9NTcqvB48klAYycQ1cr9MIEqufLwGdEg+ZUiNIRNQTqWHqDxAkOq0DCSpBY9ynYl06 pm1Ned2rprW905eD5ATh2kR5feG0bmnX41gHwo5SEzptO47FTG/0+Jf0JRNcCjLue281g5sceSV4 3xwb3Ggnbk24SGcoP6k9hL2xEeXKU2Ul/hLYF4dHUX48fx4eSb95fYsMJMxsMxKelvbFbECJKEpy X7Qd5DKYiYsq7dFmF08Tarh/ONAfBhYNqRks7jYb7nrqXImVJyes4Ak+ve50pkK2yMquzQ5MbV0S nmZyT65nFpDyLEZyXxKenFiLCxP+eFrT/lbCRd3Ed0ow3wjUN3PQuj4fDqKceHst0pn0R5J+2vab gxZfnlSs1vhx3UY+oo9nvVsxyIzzqaPKmo8/KM8MkTaQ9YiQjiVX+wBJDpb90bSKJJho5pXag8qD Q0FUGbb82eLpAW7xLfGn759J9SytPUg0LOmSAgmJgZcUHqd4+d2tfl0clRNn9PiGOZlVsTu1Bm36 +ZLQiVFvvutsFo8lDCdM3m17kkJqmPqGR30DWw3srSDqHvvBFj8FrsZdcRpCxWR5RqCk8Af6ckD+ eCQfmP/ECuUIobCBY3j12k9N6LQbAM1HfnEMCkcKmF9fWtJpI0EdVEsddrxj/XCNdtiaEze5tfyk 9gCBgR2uEedHm65Kp5Ekabd2/Km57O/4DKhcNRhglYuVcAnKKMpBkQtwgiTuzCMN+8npwjfffn2R S42yL2YDSizRkr+kdDq8mOAi896peBt/OrO4QuyUnNjyetyvuzOvpnUAntjhnMzQLKl1BzbgXBKe pnJPQ36W0JrJfUl42vLm5DPR63Tstd+GSVOZcQDITxRB2qzr8wEy7/4oeb8pzYZAGzGZuo7fYW9z fawlvNXrE+IqmYc/yPeqAPSRZYVAQmRb4O/j5N9s+qMpn0kw0cy7YDthi2ec3GN/k/jT98/kEpfV HmQalnNNgYQUcBe796LD1fROJ8DTBerimD/HyMYFEuTOZ7I8Ak8oGE5OfhgGghMyySb5ktAp1gM6 HUaO1TqbLl24i/xWj1XxpAXl7HSHSKlh+o1ndAQT8w3aPNINaJTXmj0+EBmPBqzXrrMSbuqTDayP Q4OYz+Dykhrr9rc4buNBj1Xw+bSjy7Jm6DmdMqrm1yZyYFLk0sGy3pvuH+HQKQaTqEt8EyNzeqJy GNG5cPlFUT3jOe6DkOGOTJatt/t4hNyAtasiiOfIPqiDarny7AXIlVmnv8k2N/usj7okL1aylp+E 59QeNN09MgassSqW4OSVzUedgZWnu/b2xeFUmz8VFoO7IbbNNmvjX6fTZtXJW2a0F5kiHg3bmTxv tToMD2JRPxIuQRnpOTlGem1tX6Zkmw4oF28HBbxGuIhsOFDzlldNBwhBuUiJbS/HG6zI2y3ac3dp kth0dFr3uv+selt9WbTcE9ZnC6uTz0juS8JzYfzZ9rcSLo69zlda3F7X+Qk7+Hy9p7JiW59air69 tq0vhX5z0BEvaCb+FQZyI94z+bgzvHWPhh3isuHxqD/dmBVl4hyRPeK/4dGxysulxfqDo411HkyB 7CrrDqbE9FveC4oIW5qKndDrJznqHDMDPKX2EOwPYuq35M8aT86k4YXEn4l/JteysPYgV7oLrimQ kIIQ5CPmpsYUN+6SHKTJM7yPCySog+epwfHyBRutRLTSSOPzJaMT17RKb3c92uTvwFombJje3gpB HsSUpzBc+k01CCPX410H6sNufo2/1Z1i4Wx46aWffBfcjYEkCFO5NJCDU1+X74OgyozTmq+mfvTj hE8TOhcuvwmFVv+60iwPjqGvDQZ10F9VeETZCWa1fTMUrOQn4RlFI0BwX4xk7VbmUZ8/OZf2NZ6Z 7O3EH80fBkP8M4IkXIIyircTnDYTvcZMdvZlWpscSPDrBadHvkjAXxI6JyQY4uKR7dfvecziwkiz dBSnpBdIs9dvOHva9JTBAVK4JDyN5Y6kJpafJxDTbxO5LwlPU5aU9Cb8YUa/PgfsUz6kv0VcvBN/ Aul53xK2nMCyPoVB50ZtH4KGlPojrCF5v4lHg7ubpjr05X1B8ABLlg/EMpIIf8mVh/pyadH+4IjV paC/kJdKc7CPS8NOaPaTLv5WeC7cTtjjaaVmEn9Rsgvzz9S6FtMe1DqXf0eBhJRk4EQdg050hlUa Lbbunrkbd/yjQ8aw32KrBTy3WzLMjkLHTXcyzZeUzo1mVXLyJAOZybFq2zefS9pbIciDEy2e5o/q fIYbzcnMg7BGnc0VcFaErz7seJuVQmgQxymjWKmzOUxG4BpkKr9eoxJKa77cmE8QwaVUm86Fy49D aXWx0fS1QVxnXWvW+RFyYR14sCKcHVDxH+MqzrqX0xvLT8KzWC4HndQcvsXwBSy8+pK2W68cnO6j zZ/Io3mF/BVchy6szXrPArZAwiXwm7P2coad8KjT1ms3g7l9mWYUgR3dUxvERls2/NnSaYtLcAAT rv9e+Um+xRF6ch3i7RaELe9KqC+2eBrL3QXGtr4kuDp5tdvDkvBcGH9uReb2WgQS8qVS0O/BWWtx h0AZ1xcKiL69tq0vab9Z9458xFO0/FP6Q1myeDgzEOT2O6qPvQx/cMgaZXU218T3LK9y/YnaoyuZ nRD9ZKHqmyETgrcVnkuxE/Z4hrAd/0jiz9Q/kwteRHuQ69sN17/gEIGKTp80ENjZhosXtwCOHoKd 0WF496kTcMOhNApOuYzEdO7A5YsX4crOIVg5tAPjd90EJ4/fCPNidfvyRdi8sgMrK4dgNEZcb343 3PDOuNp2YPvqVdgejhG4EQyRzpOnTu1eWWxsAjIHo+EQVk6+B07sSqWx10Fz+dnXBbAD164BHEL1 OOT82/4OnF35ILyBRWIgAR6768YkhQfzOm3JVn6TdjiAw9iGRrACt506HixffpK43cqF0bWHwGL1 06vV/HthdO68BY8cvh2ed0nMV3vwpw+fNid4l+dYGJ4uDouub9Hw7wn+TOz1tQvw0NG74TwCudYb wSOnx3DxbQN77QjApL40BGZdn22/eRH+w523wBe7SHy+CsM/fRhuSIOPVMtYvD94DX3W/hDdOnRB Dt90Eo4b+HR7oh0lkI8Nf0nwtCZ14m8ZtnfYC+3BGpHIjBRIiISGfiAECIG9gsC1qxfhpzs3w6nj 71RIfvPZ++Gex+v4LAONzQ585AT27PQhBAiBSASuvfU1OHr7Z9zfC9Abn4PT1Gwi8aIf9ikCUiBh LkHoXQBb0n7z7ZefgPd84pkJJ6utLfjCvTOC4buAZyKBEJgXAge1PVAgYV4aReUSAoTAwhC48OxZ uPvxNyBXWIX7P/Y+uA0nHvz1+afhqeeduQj4KdZh/JX75jZrZloJ/ScE9j4CF199Am7JTQcHhfUe nPu9/TcbYe9LiTiYOwIHIJBg02/uXL4Az639Bfxs8FfwxWecIL3zKUGffQlOTW/oPyFwYBCg9gBA gYQDo+7EKCGwfxHwHKJQDnMV2PjGY3CbOlkhNCk9JAQIAWea884EhkPvfCcF30ghDiYC2xdwWdzd k2VxuEEsPHkm5WVxuwBVm35z+8LTsHL3Uwr11e4AHr5j/+GjMEk3hEAIAtQeKJAQohb0iBAgBPYa Ajvbl6H3gw50/vbvYGvrJ/APgxGMjv4qZHMfh39x5jYaDO01gRK9hAAhQAgsE4GdS/Dq+W/Bj6/f AL/5yU/CHTfuv/U9Vv3m1bfgxZe+DT8/cgTe8Yv/FM586IM4A3D/YbNM1aO69xAC1B5oRsIeUlci lRAgBAgBQoAQIAQIAUKAECAECAFCgBBYOgK0tGHpIiACCAFCgBAgBAgBQoAQIAQIAUKAECAECIG9 gwAFEvaOrIhSQoAQIAQIAUKAECAECAFCgBAgBAgBQmDpCFAgYakiuAaX3t6EIa7gPnnqFBgcNbtU qqny3YPAtauX4KfDMbxr5WY4fuP8dxNcdH27B+nZlFy7fAk2r4zw4Ohp2qN4fvSJBchkNmV7L0Vy PduByxcvgiOOY7fcBr5TQfceIERxKghMziNHpTi8chJuO7H7TrxPhck9UMj2pbfhhz/5GRw+7BpL GKPd/BW4/fSJhexnk9y+xIO8bP7iqaNfCQEbBGi8YoPaQchDgYRlSnn7TdwV+J7prsAd3BX4Ltr1 dpni2Ht1b8O5syvwKJ5wmCm34XtPnpkzC4uub87spFb8ZXjxD/81/P6XvaOwpgUvRiapMbGLCkpB z/DotrNH9/eO67tIYHuGFL5LfaYCg+89Bge7x92B77/2EnR+AvAO+Dn84u0fhvvOnFBkuf32d+DP vvM2vOMdgCn+KeR+72wqmF14+k64+6muUhcsTCYp2BeV8sDdcvkLkBP64NJ3XoTzf/33gAezKJ8j K78M7737t+D9d5yKCOpcgzdf/BP49t//DH7plo/CI/fdoeSfeeNsYvnc/wbPfPV1uOImvvXsZ+GL /6YAd53wEeMvbOcyvHZ+DdZeeBl+hJmPHTsGKyd/DX7zQx+Dj+c+jJs+zsjvL4/u9RGg8Yo+Vgct JaNPqgh0q3mGOsQgV2XDWSWPOizvpMW/SmcwKzX9vg8RMNKXAP9Dtpad6k+u0gn8mv4D8/qS8Zc+ B/MokfPotuVMNssyeF2odudR3QEo01zPAqCQbQ1AYvKA67ROP2ZS8JLTdte8/nltdv+8ZFrnX/2Q Vdz+Y+KzZMpsS6l0zOqFaf8y+R2yrD3TqVEKiLzZaFRYPl9gxWJhYiunPpO+TJLpZwr2JZKz6Q9J +ZtRfCo/dyq5qa/q9ltTGUvyzhRYcyNM4AI/DP4wI8912GXFqPogw9a70aWN+g3uLwdodcpEWsKo TQUsKoQx6lNJCyIQgIjn9NgSAe6oZNdmG1hqmJYo759sRvoSYHvEmuUCy+LAtbTeC/ya/gPz+pLx lz4H6ZcoOVX5NbY5Tr+Gg1eiuZ4FMCLbGoDE5MF+bbcyXzToGLJqTho44kCu3pcM2FC86JgO3HKs MwfQet7LF/SZdIuX5Rg99IzS+BTsS1TRIc9t+AspJvVHHEOUe6FYxKAO/hXcQBsf7OdZNyAUSW9y +jJj6BF7Lz4cfcrky6zV7bB6pSAFNHKsHSLQ8WaTZTlN07yNVps1GzVWLroBEdOgRuqI7vMCqU/d 5wK2Z48CCfbYhebknQa+yRmFppAeKg0zYK2lhHS5XxEw0pc9CMJ+54+xMXfG89VFBHP2oBIsg2S0 rTnX8aTZXuYC2K/tlg+eDAat5ujtlRzSgNBtK/m1Lid+q7kqDfCcgMN8Agk2MtlL+mnDHxfCHC84 XX5fddRnlbwIMOUknZiSI+mNQTsabawLfcpXlRdt3aoIJgT70RGrSTNjCmvtACrDfpNV1lqzfe5A TnqgjQCNV7ShOmgJaY8EDI0m++A6w1fPwxs/vg5HjgC89cKj8MwbTolZKK99Gn4Jrk+Kv45fH/jU Z+Gu44dEdbiO9yFcx3sen1S7m3Dv5T+Hp599AX44vAJXrhyDjz3xR1B6+F6I3hLqGlx49U/g3B9/ E9o/wvVizoqzzFn43OeL8OCZU6KeNK9wjdrrL1Wh+tJr0HXqPAa4Ru1O+GjuAXjgX94bvqnZtYvw 8vPPwHO4Jm4lk4FhtwsncU3c54ufgTOnQrjDNXQvf/VluHR9BbIPfRwOv/ln8JU1DVxs83F8EuCp jUsCfZnQOV3X+lc/+Tmguk0/qFw3/cZvB9a3TpPjekTEso/69+sffgg+cjpkVfD2W/C16p/jpp9H 4MyDn4UzJyQdBcP6nPRW7QHXPp77Ovwd0nnizIOov+paXY+XqV4A3PKBT8F9dx13AUj4ZamfVxCv I/AzeOXRp2CyO0KmAGtPvB/Aaez4dyyKD1NyuV7/MmQf/C3Y/NY5WPtmG4ZXsL3feg98+g+ehIfv vS2y1J3LF+CrX/8uXD9yCzz0yH0wfPNlOPefz0O7O8T8J+HO974Pfvfz2Bb9m8+Z4OKse12ongl2 nXXczzz9n+BlNILOmtmT9/wOPPHp98K52z8Iz2MyDCTAY6H7z9i1d2s8Bcl6V1zuhnaQl27Cn0W7 Rf148fk6/L1jN7BvOyP3bZwG90LSj3+WK8C9p6S1zCZ6JpVrI4fvn3sIMo9ij5tdg+Hrj0h9q+Af fnYdzuQ/57ODWPH2RXj1xReg9s03oItN79itK3Dy5lvhfe/Pwoc/9mE4ved29NyGr92/Ap9B45XB frmL/TJutgNb33sSjsM1ePmRo/AJpwHxTw46w1fgLq/LdmR6/lvQHx6B7KfycIcif9S9l78B3710 HX49+wB85I5oWx0tE14xXgj5GPtZk2IwP+4Hod1vOnl4+7Ozu5Nq8Z8ef15q59uk3cr5zK5lugbY FhTP4PLrcPbdH5rs34XLJuGVx+6SChd6E2xHUjLf5YVn74e7H5/0lLC+MYbfu032M96GJ37hPfCM kyeL+5e8Lu1fItEC+SqM/vRhkKyHr5aQ22W0W21/cErv9uW34C//67eh9e3vwg9+6GzA7nxW4M7s R+GBTzwA954OaT9cP237h2nd2v+l8cpaqwu/9vYr8OwLb0z9kGMZ+J1/92/hkbOnY4pbjF7HEEA/ zQuBgxY5SZ/fAStLU65QTizqb9U/Z0uK8EXlgWI9PMo67LFVeX2jr95cuRmeLwEAw406f8sXRm+m HFyn76xr894MhuUpNzaCFOGUSnkaW1i+UFxs8zkUJMDTDJcE+jJBKjx/thyM0k+SjzdYwdONQg3f nwc//VqR6+z6hn8ejWF9+J7Brj1sslWPzogpisNOhdNZbPSDjFg8sdPPtljX69Ec9r0aIRNTOjX0 OldphcrWqUrglmXFUvi6WNwYUqHKGJeF69mU3M2W0IlQO4FyCZ2RkKS9cz3Ux1MBV/dGQ+6hdtAp 35g/i3Y7bHM7XWpuxnO11eRtpiz1g8Z6JtVio9f8LazvTWrb2zvBace5CpNn+DtVjjcbnP4wPQvr +yRSd+mleLOcr6yzVXeZQ80xraO222/nWbnkTXf3zUiQ9FOW6ZRZseQrsm9yUYmSiQqahX4qBYTn j6VN4i9M5s6zOLvrVa/Hn5vauN16tZh/x9I17vL9CIL7Lwm9wUCC5nIU1Ae+jKbAun43A73VdT4L Apc3SBN0e+titsLqLDvjg2EZ7dbMH3QIxr1KMtHjBkfPiutiphBnUUM/I/sHXojBhcZ4JbvaDPdD FqjXBhxR0pQQoKUNiYEcs412g9XqddZo1FlZMobVRoPV8fnkr9ZgGwPfMM7fMHFzm1qrw9qNNe6g 4SsCdd3ihN4tZZOkTKHMmp0u67bqrCgFF0qNGc6dCe8D4TQ6hi1brLCWU2enxdYr04GofzDC2CYr OY6Z+5dbrbJ2t8ua6/KUyQxr+BeW2+Jimw+3mJI3nTLC0xiXBPoykdeY9Zo1Vl2vsVqtwvUk2NkL 4YpNldQOeppC6uCzYRsnmdZnz9+GFNCoBQIauPFXMePqUoH1fE1JcGtyZamfGCxpue260VhnBc8J yK6yOm/zNdbqqVuXmVCmpA3R63q7h+19XQnShQ6YsaBhd423Qd4WSxWktY5td3WiQ2rbtcNlsXrm MOYNdqY2prTeZL1em1UKnp5MnwdxSdDerfBUpKl/EyL3+fUPNu12wO1mttyK5WvQLrs6KK+BttMz ryJzvWZMHjxNl2KPcZ8ZKbhWUKdcT+vCNCWhU4Xy+qQf63barFYtT9qg2n48Cnf7txgQ5qsd5m1g 6Ewt32pN++hMqc7afCDnCyRI+hlsY6LsuL7JQUiWiTR+9IFno59yEab9GOaV+JvYTfTPTOyuV7se f07qZHbJq0/3m9MVss/BsCP6jGxgI2chW5NAQtULJITU59DM6fEtoemuee0zzH+J43YJ7dbYH3To 9wIJGVYsrzFn74duD/1kyb9z9E/Zv8TJFqKfev2Dk9ni468P8qwW4oestvx+z2L12oIzypIQAQok JATQn91o7Z7cMDMl1pOitKNulTv//mi/cMqcneH9swC2pMhviaXz3paxtuRsFWvBteDjzTZrtNXA xVbLcx4xcu9zNLfa4k1iwAm1xEUxrAvC0wYXWWeM9EXOOLkes3W3c45z1sYbNa5LgeDSlnjTVlgP mR2i1KlXn5zFiD9pYBh4U6T8Fj9okeuPu7bWT6XQEd8jIbiWVElofyO3ByioG57Jm1AV6qFvA9QB V4ZVO76OfrTFNjaFC2+Ly6L1bKMW9aYKHV0e0A3OSEhqP03xtBa8LPcF2TOPVt12y+2fHIQcj9hw OGSjkYj28SBTVpwMYKtnHo02cuCDFVwX7lDXXM1y25gp1iLeropN4jKlple99D1kWwOp85Z+2d2X YkCYW+vhrAu3n8jmWSE3DZyU22gb1iNmJEj6Of9Agoqkrn6qubw7zX5M4g8s7K5XG9e5GW/vk9ol rz7db0FXmfVH0zY7HGyxrvIiC1i1J/qGadlCb6wCCRE4eIEs/14cnE5fgGE2n4tvt9we4sBf1092 9lnq4wu2LWEuBWs4E8qbnRvwL2T9NOgfROGGV3J9GERQNl7daomXGvmqYkcXrdeGXFHyFBCgQEIK IMpFcKMXYSzltPLAt1jzDeJwapk3JT23JgcL5I1nMqy5OWKj4YANBu4fdgg9/mY3x1ohO+AqNGjd 9MXMAuRLt0g5khykQ7zNcjojpUzJYOnjgoxY5UuCpx0uMuRG+iJnnFyLDj0ukOC86Sh7b83z68qS FzFtMMuavvFloDrsHry3CvH1iZxm/I1Zg886KLINqWPt10vc4Q/OVhD1mVxZ66dSiTkmSnadG0mv VVswzSzeloZNGVVnJITl95Ngj8si9UzgDrCKc5/Uz0iahaEOcpK092kd8gBWB0+VMoM7Se76djA5 fw6Fuu1WBAOEY9kuu4NzvkRJyCq7KoKA9no2xdBGDoKvEltb9d504gy71YZiF1UpSbO2nGUPezFm oDLk3gm55CrO1Okttur1E5NZhLhjP9rgHl/2scwZCSoDQo66U+vl/DLfsm8lp8Frqf2FtfNZdtcr TY/WdNqtV6fON6fLnTHqzVaTv1dDXho5b9A9P0A7kDASSyWi8jSL3uxV2W+V2p5xIEHKu5B2m9wf dIIKTjBny/XnR8M+K0cd8S3pp37/oKMZEWmk+sL8vxYPysozRxav1xHU0+M5IkCBhJTB5cbZMJCw FjhjRxjrvHIevWQcYzoArzNYl6c52PKKa7G8fQ7CDEhUsS3PoYzAQmAl3lJNypIMlj4umNMqXwI8 LXGR8RIYzNEhwgrlgIEI6kjBHF+AQaZRXAud1NUDU/7kwUGZT5HDNwvetEj5zacgzOrKWj+V2swx UbLr3Eh6XVFeA0wzb0hTj+W1pV7RMqY6QZgkuCxOzwTuGdxHRoo5TdlWMJPDlAnauwuoKZ6eHIy/ JR707WBy/hw6tdst7n3gvTGrTvoaN5g0GZBmp4HscY8HxeU1zkn0zKHRRg6cL1/f2ZBVxClc+TgB Tm+QM/3Ol8psvd5gne6G8vZNybbrb0Qb8uy5gg/OcHI+4tnBDSTY2F1P/By/CD9omi6dduvVqfPN 6fK1Bc93hGIjohihN1FBgWBGaXp7BA6diCUMYtaQT/+ClfieLLjdJvEHhxusVi7G7sMin6gyYdSq f/BBZHIr1acG56eFiKCyLKfF67UJS5Q2HQQokJAOjrwUbpwjjCVP6FzENkxhrL1OfppXPJ8Y/EyG 4Y7LIX+Ow5Nh64FpaQoFejcyndJGWfGZxbSyqM6GY4WRZmUAJNfX8Xt4gn8VF6TGKp8ozxhPuT5t XFTUOAY6+qJmxTtBewALf1ppCUOxPl3wMu7X+Vv+wJIHf/7JvUF9bn5z/nDTRe+tWL42fUu4Wecd rEd7KHlGDxPop1KPOSZKdp0bWc8C7QG1gG/+J3fgomAx4MK3xjPfpibEZWF6JnAPLINxWI/ETOQz bu8upGZ4CjkYX0Xy4JQk+FDbvnhuy59Tun67Fe214OzSNxSBBaf+VSdq6U2Zx/5I7IeTUM8cBPis Ex29driS+MI+c4KPN4jCpQ7+CdzTHFCW8FQAADK2SURBVO7/2M3CcqyeRj+rVLiIG6Erng6N+2IZ nLfWmeuC/42wlX4G+eLlG/SBNnlEzUG+xW/SVSx/qH8z7K5Xkh6tgqYk7darU+db0FVmva0B29rC ZSzdJisp+2xNfQW1PIlWbZlJeYz3SPCW1ui3c07vItutrC8m/qAUgOA2Ce3T1K8XAUyvjXLe5PoC foHAO5CPF2B4EVsfY2IJg+yHCDoWpdeGXFHyFBCgQEIKIMpFCOOs8YY5tmGKBqgaAvEcj8lRlwTI hKR5jXR6MxKCZ/xGVSRNaYrqOKpeB1FU9oeIHgQ4dQn+VVzwp0XjaYWLipeRvqhZ47GISQvuudG8 br+DGMjrPYjB3kvi++Z1aDsc6uyJNg58e9KbipAX8r4adW8T6KdShTkmSnadG0mvg2+mcUIyP+9d 7sBFwWLAFf67SOlcJcVF4DFfPRP1hAcSxFRa9e2JyGdrP83wVNE1upPkrvLglCL4UO2geG7Ln1O6 frsVG5plcMfuDW+Tvux0eUMGlzJscP2U9+xJqmeIAA8k6Oi1w5XEFwYQSrUWa0h7/+SVmX/T9Or/ Eevj5sK1aoUV82JZxNT5LyhLsdR8u/VO6IrQIeRxo8d6G302dKf5cF3w9xOx+ilmu4myw3Hg5Uf4 CWG5eB6DfkWUE8a3+JVfSfzZ2F2vHE5rLH+CpiTt1qtT5zuSLlyG4C2rdfaGCJ6wINOq4edOiJHe TGeCS9GcJPLMA/nFEt9fBdus3QzbBbVb1BdzPxn9G+4H455nlQbbHMrRfoF1oB1J+qnfP+hoRkQa qb6w9hBujwX9i9LrCOrp8RwRoEBCyuBGGueweqSGqW8IJIO8sECCcMozpajpbkEGORZQCnGypF34 /R2sFS5Yv1W+BHhK6/5McJGR4hj5MZATRV4LIx3oZELy9OveMY845Xhrk++47hwRFJgaHpI/evAS mnjy0Iq/QYtPly5Wa/yYU1uMo6jjtJnqp1KgmQyUrLo3kl6XQo69FI6Wb2aPW354Bx9deVJcFqNn 8hvtkICqdFyfalsTtHdLPKORnvGLJHeVBydflN4l588pneuAhl3abLj7l+RKrFx0Agh40hDuOj6Z WZQt4vGB00G3fwkKr8Oy/ZnqtcIXH4D2xQwoHKgEN5ZzcoV/xrh+eV06TnUtKso56rESzrLyZg4G Nu4LL34BT6N0SK1ayMkXsJH6v8DAAnXXG1TN6ptE+bgngzyGUslQ7ngeDf1UMk5u9PiW/Qkbu+vV y2nFDeqi+Uun3Xp16nxzunhbELl4m8Y2kV/viR8mVwK/qNmmvgx4O2J1fpqOu+RJSSQCTwDq/kjK CRK+Y4qVIjRvtNutZnk8mdQe9H0VSe5hy0ulMgPtyKp/4NSaX0j1hc0M5fqkzDCW+FvUeMWcM8qR EAEKJCQE0J+dbyCFUdeZe9dJDVPfUVQjmNXA3gqCorHe6FBkiLzCt0d8F/QsTk8NTyjv0u2kEOul gflPnlCObvMbUEtc5I5/MXja4SKjZ6QvcsbJtejQA51MIC0+kE8+wDdqGXQSnLdpAdmE5bWpD/PY 8Se9rXRpdOgMOKuRdOr9YK2fSvGGMlDyat5I7cF7yy9yiqnlTsQ/zOaYDrgS47IgPeNr7AFtko9x +S2P3xbIv9nYT1M8hawMryS5+3mIDiSk0z+YtFt5idR0+mppoofNkjgRwXnu3xAsqZ7ZyIE7u9IA VKXfNztuhsjGXXH6UCVqOnNg6nJ4wG9GVXP4Wc92ccz8MxIkvvwn/ohp/3hiU+D4QJUVMVDEAWbs +hKRz0Q/RS7vSo9v2Z+wsbu8Nn6UYjx/Se2SV5/uN5drSCCB4Xlf4uhuPG5ZCfAI/IK4RNfuHSnq 2II8HjEqf0a9db7UyJnFpH5kWrJ4DKJCjJt0xDY3/ctg1VLkO612K2fQurbxB6WAOC7l9LvsIigf 0o4s+wctVsISSfWBZD+nSXFvHL4kZlU5LW7Reh1GOj2bLwIUSEgZX9k5mkxTwt1Xh5MdWIcBIyF3 VCaOIi5G4m9sAZ3otWaP7zg9Hg1Yr11nJdycLnj+rz2zsmPgHM9T62y6/OAus1s9Vi3gGxd/tFh6 s+zkqfemhn486ElGBweyfFM9lz7JYBnhYpsvAZ5WuEhiMNIXJ597tNoQp7+NR7ijr7ufgHOE5oj/ hkev+XukSZ1hA3R0EkLTukTyMm3qU4NJM9uDW6XzNeDrT901ghHTIaUs5pe2+qnUJJyqWQ6zks3k RtLriRNWabnruQeszndKDntzNK3EeMCVGJfF6NloQzifkF1l3cFUkfstcQa6g1fAhiRo7w6ixnia yFpOK8k9wEPkjAQsICF/DglGdmm8wYqIs4O185fFJQ7OR2y+NX2+vuEbACTUMxs5RA2eZH6h4O7N MuHC+YdtPJ/Bacc11u1v8X7c6ccq+HzKt3PqTYQhleQ4Tet7s8/rWfSFnu3imPkDCSh3MdgU/fug V+ezERx+Z9lFeV8GyJVZp7+Jg8I+6yPWPo3hAMny0upXbPoxn9zyhnbXI1abvxTarVenzjeXa2gg AUMJfAYjTrlXZiUIvQGcZVFvd1i73Q7+tdpsY0uSoPR23dGLSnN6Utmw32R513Y4z8NeGMi0OD5v tbUx0Y3xaIhHJzbZ6uRFl39mWsJ2qwOiL42NPyhO/0Bf2MXEmcHRq4vj00PbkaSfRv2Dj2btW6m+ KT1N7oc0pBNwAkvEFqzX2vxQwtQQoEBCalC6BSmNRjhXE8Pp3xAFG6Y3/S/MEHg71Yd1xP2mamSc 8v1/oWuHrfnFtbDSelJ/Xc59WH3ibOAgfZMy8tXgPg+2uNjmQ0zs8bTDhYvBRF8wk5jGHoGnqwdR QSS/c++sa477JK1PHdSoNAd1XqYE30J4my4iT4HOSU6a4NpKP5X6xNS9sHaqJLW98XXgYW0PQqeH TyuUB1zy2tM4cpLishg9w+myJW8gp+qWjFGYntm3dzWQoItnHNaRvy3FnrnUGNklNXDEZzhhGV7/ 5kznDwtYJtEzK732jjLEwZP6/tIZdAgdUmdPYBvnb9umaZxlCrKOBYMPklSlN/fTPLsnkBDnY3gc 8Lf/GEjw67v4TWCn4IK2e7ZdVPVH5M8G6vNoMu1XrPqxhHaX04qDwhq+aBF8eddB/pLYJVGf3tWs QAKTTltR90oQfV6QJ4+36bf/5dIm3y9FTeeV4wQhw8NxY9aq+Pcl8ZXBj5v1+E/Ybr1ijL7N/cFR r6rqhrPRouvHebg434F2lKB/MGLJSyzVJ9OlXofP6FqkXnvk0vfiEKBAwhywHvZbbLWAU8elgZDT 2ALTaKUIbeC3yVuQqaGMGkQNN3CHXe9YPJ/hyeYKOGvAN983BV43mlXJOZQMeSbHqu3w+nqNSqhh zJcbPmfOJdAWF9t8brVJ8LTBxROHtr5ghpmOt6sHgaOCvMoQI7GRUohOeunc78T1YTkm/MnV17lu 427v4aolJ7e+NtZPpSYxACn4pmsqyZLcSA5tvlQKtj98ixe3abxwVMx2vU6Ey8L0bIgb5nmbtgp7 VCyvcpyi1q7btndbPI1VYIn2zKHVpN2KI0hRx/j0dOnNpX/5mgSGrZ7ZyIHbM6SHk+nRggN+8WZU ns49Ys1KIbQPc/r1YqXOoiYjTIr2tQXnLa7AyKt8Gd9Dtu4GTyL7CyRrY93bWyds470Bq/mWsDh7 ZFQaLZylOA22RPkvKscD1qj4j7+Lx8lEP7ncfX6SOgjCgPVaV5CV0O6Kgpwrff5s7ZJa3+w7jklg mrrIK8/8EEt3RJ/nx89/r85kmJa7iTPGwgbKxbVWRBBB0LPRXJNm4wp778xSWK11fPkTtltRrfGV qT/ozKLzjtEVGE7b0XrRbUeybjoUJewfjJmS6iuWy5KtdOWQw1mBAaMqalmUXosa6WpRCPyCUxEq Ln32MALbly/C5pUdWFk5BKPxYXj3ze+GG955aI4c7cDlixfhys4hWDm0A+N33QQnj98IsTXubMPF jU1AImE0HMLKyffAiRtic8yR/vii7fG0wCWelAP860X4D3feAl/sIgT5Kgz/9GG4YZ5o7Gb9vHYB Hjp6N5xH/td6I3jk9Bguvj2Aw9j2RrACt506Pj9kdjMuEtfX0Ab2h2he0KQcvukkHDewLfbtXSJg F1/uCf72hJ7twPbVq7A9HKO0RzDE/u/kqVNgoGq7WEuSkXb14tswgKNwaGcMK4jJjbuzazdjcpl2 FyndE+3WDFGReucqvN37/wCOrcD4CvqD/+R2OKGtNNfg0tt9GKK+TfzPw+h/nojzP5fVbg39QccG XtwCOHoIdkbox586sbtty4Recz9kX+u10PADdUWBhAMlbmKWENgbCLz98hPwnk88MyEWzzOHL9w7 x8HybodEcmhxmj48dteNu51ioo8QIAQIgb2NANndvS0/op4QIAQWggAFEhYCM1VCCBACsxDYuXwB nlv7C/jZ4K/gi8/U3eQl6LMvwalZmffz7+TQ7mfpEm+EACGwGxEgu7sbpUI0EQKEwC5DgAIJu0wg RA4hcFAR2L7wNKzc/ZTCfrU7gIfvOOBv4LcvwNmVu+ENRAY3soMnzxxwPBQNoRtCgBAgBOaAANnd OYBKRRIChMB+Q4ACCftNosQPIbBXEbj6Frz40rfh50eOwDt+8Z/CmQ99EG7TXje5V5nWoHvnErx6 /lvw4+s3wG9+8pNwB2GiARolIQQIAUIgAQJkdxOAR1kJAULgoCBAgYSDImnikxAgBAgBQoAQIAQI AUKAECAECAFCgBBIAQEKJKQAIhVBCBAChAAhQAgQAoQAIUAIEAKEACFACBwUBCiQcFAkTXwSAoQA IUAIEAKEACFACBAChAAhQAgQAikgQIGEFEDcy0Vcu3oJfornYr9r5WY4fuM79zIrM2h3z/Qd4dHF t9wGx/czqzOQ0P/ZOa95E89rpvPS9TGjlLsDgd3d3g+O3d0d2kBUxCOwfelt+OFPfgaHDx92E44B Dv8K3H76BFr/+X/m3R6Wzd/8EdzrNZC93usSJPoPLgIUSDi4skfOt+Hc2RV4FLeDz5Tb8L0nz+xf NPAop7NHaed7IwFvv4mnBdwzPS2gg6cF3EWnBRjht+zEuFnYy8+9DJdi6bgGR078c/jsg2cmA4a3 XvsavPp3Q9COsx35dXjokY+AoxmXvvMinP/rv4d3+jIfWflleO/dvwXvv+PUQgYlE3Z3dXs/QHY3 Vvfox92CwIWn74S7n+qq5GQqMPjeY5O2rf6Q9t3828Ny+dPEi+z1Lj2ZaP76qakhlIwQ2J0IMPoc YASGbC0LDDWT5Sqd/Y3DqMPyyKfDa6UzSJ3XbjU/KRtyVTZMvfT0CjSic86YpccVlRSKwLDDsq7O O3of+ZepsGmLGLBKJiZdaBkZ1nIVvlPJRdfh5M0UWHNjQa1jV+vuAbK7oYq5/IdGdnD55M6dgo1G heXzBVYsFljGa+e5Ne2+LBme828PSfmbuwCcCshez80/Sya/+etnMvr2Tu5kdmLv8HnQKKUZCehd H9zPNXj96cfhP772Q7jnXz0HX/q90/sXCnxD+RDOSDiPHGIgAR5L+e369889BJlHsfTsGgxef2QB b3HsRGVE55wxs+OAcmkjIMkP5xxBoXgPwD/6c+ODf/L7UPnCR3AWwg5859l/A8//P/8I75KS/bT9 PNQnLyszkC/co/z2j3AX/Mf/4xE4hfOfuW5N6jo7TfePfw/PPO+0Ou+Th+7wT+GOG7z7OX1LvM+j vSej+gDZ3WRAzS0319Vdbq/nBkBMwW997SG4/TPTvmyIfZlOU02G52Lbgw1/MXCl95Nks8he76bZ j4vVz/QUaveVlMxO7D5+iCIXgYMWOSF+DygC+IYy575pmceMhJ40I2G0iyE2olN5q7ugN8m7GLs9 R5okv9xa15p8XZ3prolZOUobGPVZJS9mOiShRZuJObd3bToo4a5EQFendyXxcyaKt+Os/oyEvYSn DX9zhnxaPNnrXTojYSHSPxCV7CU7cSAEkhKTNCMhpZDS9uW34C//67eh9e3vwg9+6GxQ53xW4M7s R+GBTzwA954+Hl3T9kV49cUXoPbNN6B7BTcDvHUFTt58K7zv/Vn48Mc+DKejdga0yrcD33/tJfir n/wcjngUXb8ON/3Gb8N9Z054T0K/t9/+Djzz9H+Cl9s/gmPHjsHJe34HnsD10f/9b96AHyDdv/Hb vwtnTkgLpJ01f1/FNdrXVyD70Mfh8Jt/Bl9ZewF+OLwCV64cg4898UdQevjemDce1+DCq38C5/74 m4BVwjHASjJn4XOfL8KDZ06F0ug8DKXz0++Fc7d/EJ7H39N5Q4k4vnoe3vjxdTiCQL71wqPwzBtO 7Vkor30afgmuOzeA0MIHPvVZuOs4vrL1f65dhJeffwae++rrsJLJwLDbhZNnPwufL34GzpzSeQ/k LzDsPgGd0huSancT7r385/D0s/OXXxgXWs8s2oN5u70Mr577OvThl+GWY9tQe+6bkzZ79nN/BF98 4H+A//LvvgDrE2U9C1+pfhnOnpLaA2fCTq95dt0LSX64dAleeewu3ZxKOt23CLHpLr8OZ9/9ocka 2CS0KIS5N/bt3UAOaMteRVvWx/b86x9+CD5yOuSN2fZb8LXqn6PtPwJnHvws2kK5zdvb3QmbO5fh 9ZeqUH3pNeg6tvAY9i4n74SP5h6AB/7lvRGbxxrwFwas6TNLe7Zz+QJ89evfhetHbsH9Nu6D4Zsv w7n/fB7aXexFbz0Jd773ffC7n0ebeCKJTUxgBz0cLPnzsut9J7Avjo6e/xb0h0cg+6k83KH0OagL L38DvnvpOvx69gH4yB3R/ojcjqNnJCTF06I9cH/ilyH74G/B5rfOwdo32zC8gn7BrffAp//gSXj4 3ttmwqzHn1zMgtoR2esZ/pmBHA6Svbbwe2TtNrk295eS2gkT6kRaczpFXrqyQCClgMQBL2Y4c21x cT38jeB4s8H4mkRvbaL0nSmH711gm4/hauiyVD6qDHP+suV2rAy32muTdF76sO9y27f3gM6av2Kd KW8vPSqGPbbq7t8QVleu3AzNt9mqzKQznRkJ4TiG0brqxwV5HPUbfIZEWJ5yY8NDIuF3AjqlNyRh NE6epSw/W2bt2oNFux229fYdmLSrEuv7GbLUa38xWveS/JLMAtB9gxebbtzle5SkuR+LdXs3lcN4 gxU8u1mosXGIAPq1Irc96xt+qxbeDmfZXaea4UY91laE9hGm/IXwY/IoiT0bdjybnWXFUvg+G7gZ sAk5IWnD8Q+za0u110nsi9TfBvpi3O3A2w9pls7FtmOObDI8rfwQib8wuTnPcpVWaNvkZOOFHn9u jkW2I7LXE/sZ6p+ZyuGA2Gs7v0duDSbXFv5SxHgjrP2G2V0T6kRaGzpFbroyRwDMs1COIAKe4mZY sbzGGq026/a6rFmrKIOOet/vfo5Zs5ThzmehvM7a3S7rdtqsVi1PnMdwB8o2n0P5mPWaNVZdr7Ga RF+sc48duLcswDEAxWqD9XodtlbMctqd54EOQOoYJ4YDN1urtTqs3ViTcMmwIC5brCIFETKFMmt2 EJdWnRWl56XGpioKdMJkOkvrTaSzzSoFgXEonWopmndjttFusFq9zhqNOivzqds5Vm00WB2fT/5q DbYx8Mt9k5W8QYnj/KxWJ3Jvrq9KeGZYY9OfT5M0JVkCOhctP4Vukxvb9mDRbiVMMvkKa7frfIDs 6FZhrcla6yVXjhlW68sDSku9NoFCTivRCtlV1mg2UVcb6h/qabsfv2xF1/Hm6UI2aRt2RCAym9bG rtbt3U4OYjPJHGsHIMOBWs5dvpH1Nq+UhWFhd53sAzVwlS1WWMuxhZ0WW69MAxfBPsKOP5las+tk 9mzYFbox6Sccm1iqsDra1fXK6qSvCPJoRqHT7+0Jey21WWP7IuUN9MUYSKi6+hnb1yOsvB3HLm1I gqcjO4v2IPHn+RP1dg/9gnWl3w/yruqKHn9OngW3I5k/steS0OzksP/tta3fI0FrdGnhLyWyu0bE SYlt6JSy06UxAhRIMIYsLMOY9TEAsBU27sMZB97O6cG3ggP+liBTaoYUPGRbA3kg4iWxzefl977H bF3DudioFfgAt9SQ37GOWE0apAc6cLljzJRYT2Jl1K3yMv1vTwbtMv+tUPXPyNgSDjuob3xlOleb cpABnSg+0A8JeHhwJPg2Wfu11RL85cotpdattvd2zpklov6mJLS8MaGTLVh+lixhNtv2YNFuJUzW ulOF5o5ppoyup/PZZKvu6Qdym7DV60mRNv8kWr0BWtj3rEEa5y92YCEPQMqsPxqx4XDIhoMt1lUC h8CqvcAo3IY7ZtvebeUw3qhxuxQIYm6JmWWF9VmzifTsrgNKuyze0BdrvQBO4802a7RlW+fEHoR9 MbGfgcI1HyS1Z2ogIcOqnWkr4tWPttjGZjo645VpYgeT8ufVqfUttVlT+yLba9nuTOtNO5CgcmOC p5rTudNsDxI2AAXWkVVis8n9LCjUscToj649W3Q7kuUXZqe9Z2SvZdlG+4P7317b+j0yfibXFv6S r/hkdsJXWORtcjoji6YfQhGgQEIoLEkejifO89ZgwAb4Nxr2WTnyiEXpLVaugs63br22+fzl6zgX Ig3gwF11WXGKfk8EBALOi9TxF2s+5xqnOntThXNrcrDACU54G7NlWHNzhBhOsXTwHOAApcenEOdY i6+mkOlcDdIpvfUK0OmHxeJe1zlxiu6ueYMDmX6vUjyCz5t1gQM3zp73c8JvEzplx2b+8kvCWBrt QbPdSjrt6RHHlL+JF7ropcGWYqnXCXCRaHWc0EwmE/zD58X14ABVrpXzpxtIwDI9p9f/vRoyGJbr 0r8WGAOYtPckcthiZe94zPy6srSqt+4FW7Os6RsHB3kStMe/He6LmUvatiAJf0FKdZ4ktWdyIEHt C3Rqt0ujq9NO6Un5M6JQarOe7eC0xtoXrCUkr6hbV+fkgKD+Zoucxhk2QtAjX2nSJvEXpididmeB uTFeuRJ+rUfr4tuRLD+y1564kshhv9vrNPweD2fTb01/yVesXtvzZUp0a0dnoioPYGYKJKQl9OEG q5WLsfsd5AM7p49Zo6g63flSma3XG6zT3Yg5w9k2n59ZnQ5cpMngevhApH8k1j57jg+vRer417ry 6wMnhSg3X+3yLM5zPkU4ZkDiDVDW+TQHUV44nR0+BT1Ap1S77aWJgWyV3SUhEU6XKMt7w21LVTCf KFvDSVyo/IK06j9J0B5M262EibcOPoip0EWha7Z6rY9CIKVEa/yANZBTeRDkT/mZ3/B0Ue222OBp k18IjM3aezI5yAEDEcSUgn++AEM4n4L2WLlIS8pi0ymVJONPKUrzJqk9kwMJtcDeEppEGCbjuhph g+XikvInlzXzWmqzZvYFS5byCrvj1aipc5jcBBuvdJs8Xl7ZF4jVc4U/vz/B2AYP5oUtPRK16dG6 +HYkyy8WB8FK6JUef5KcyV6H4igearadhdvrBH6PYM7sytRf8pWuq5u+bOa3Cek0r/Bg56BAQhry lwyIN8AF/vZPBApCO4fYTWRyrB41Ddg2n8KvjoGU0gQCIVgYTun1eA44L0rH73+3LpWrrJkWzyfl chz9b1MdXDNsneMj8oVuJhVLiwKK1Y2+gRTT0SDCieVlQbxDZEMoLzuibqXMWMwE3qpei+dm8lNq Nr+xaQ827ZZjkmcddwYRHwhxTAUGok2IZwvDhdPqbEImz/oxg1dXZ0S6MuttDdjWFk5J7zZZyZth gw6rujTKjA41tcDTrL2LfFZykJYwFOvTZV7jfp3bwMCSB5Vo907QECsXSX6VkA1bQ4uWArRW/IUX GvM0uT3j7QdEm4qpMJWfhK7OCqgm58+IYC5zgQXHJ9a+YC08b9jyPU2dw2L0sRGc2eQRuTVpi+UP wxF8086cuuxBVDS50qNV0LSYdoSkSfzF2gUfP/5bPf5kOZO99mOo3gtdiJWLJL+F2Wsbv0dlTv/O xl/yla6rm75sZrcp0GlWIaWmQEIKOsDX/aCjXKg02OZQXqOgY4RGrI+bZ9WqFVbMe9PevQBEgW0E pgF4RNvm8/Lr0CbSZFdD9nHQnJEgBlSz6hb1QeimZV5+/7fIFz6wiJk54S/K4l7fQEpT9fhUVbXC bjXvDkyKyr4Saiq7O306sXy5Y+xYBIKM5GfHj5rLrD1YtVuOiXBW9Rx9oZ9meq1yaHTHaV1wIMGv 12gjvGVMztrmuGnH+vwJPM3au8hnJwcpf646Wd7A2xQG/pR125HMiDJmOabe5rH5avzyE1GVKNuO P1GS3lVye8bbjzZ+epTFpeIy44PzqNTJ+YsqOfQ5b7NClzg+nFYhY6Vf5XnDAgli1kysziFRHBt/ Ow4lePqQ5+E0xiQO/CT4iaVN4i84wxHfaTS9zYoFdoGq8AGnNZY/QdNi2hESJvEXi0MYU9Izzt8M WfB0fhzIXktoOpdCF2LlgvJbjr0283t8zGnfWvlLvtK5zs3QTV82o9s06DSqkBIzCiQkVgJpClzY tFZpoB1rhCQ6xrivwrp0DNaannfKzPPpGEiJP76ZnCB23BcbkClOjZNE6hgDv0UaZ6k+o4Go/OYo ZNd06ZjNIC2CH9srbiD9nXJIgTwt7jkRDBKNWb3onjKhUVZI8bGPeN06ZS9UfrFkW/0Y3x4kPTNp txwT4azqOfpSfUZ6bcX6NBOndcGBhBAnYbPhnWQBLD9jTwY9jm3be3I59OveMY9Z1traFHuahC39 CmVGx+5iRqnvyJR0l4Uk5y+U5JiH3KZY2jPefpYRSNCwg0n5i4Eu+BNvs6b2BYuS9CUw0MZyvUHO LD9E8JvXDvrxPBp4BpnWbQ9ieWLYzKb4XfpFrZxWnAETHdRcfDuS/aVZMhLcBK84fyF2WE4dl47s tYyUrn6Kl1XLtNfxfo/Ml8m11B5M/CVfFVznrOyEr7DQ23ToDC2aHkYiQIGESGh0f5Ac2nzwfHHh dJo58+Ou2L1ff5oU7n9slE/PQPLGjzMuqr69DlrSruKBATp3isLekETXLUcU/fXJUhn7ZmrwtayQ ZQ3fhmdymQE65UItr/mGXJlVd+f+6ILEOmtg/hMrmHykXZjBji5W6xcTOmXHJohZ+vLTYsAwUXR7 sGy3XKfNHX1ZB0302pBlkZzTirYnbFmSSBl7xdt/AseUMWnjQJyVwLc2ia05/kfb9p5YDlIbzeIM soy7xjjQliPJj247ahZ8G85Pm0Gb5t/p1k08GqmGMDF/KhEz75Las+UEEtyZf7vNXvM2a25fcG4/ Dxb4Tw4R0/5n+yHiqFYMlAW3IgjVB6N+JVCCZnvg2OBsTXc2kChKnJTjzCDwdf8iGV7p8rfodiT3 t2SvhcgSy+EA2utov0fganZl6S/5KklmJ3yFhd6mQ2do0fQwEgEKJERCo/+D2C0YB4ZN73QCPF2g Lo7hctbZBaPM2IHmM7gcosa6/S2+keF40GMVfD5Zm4eD4mbgXEnbfMjT2D2WDZdfjEd4ooS7C7lz 1OCI/zbEa4l/aV0wID3r7T4bjQasXfXezE2XYQQGm1LHH/gtckYC1qucnZ5la80e3yF9jPX22nVW wmMr/efRjzbW+VplwHOYu4MpE/2Wek55kBaJV8tL2ZmeLG/BEyaGk5M7hlyuvOhBSxxVhW/h6r3p sgFH7t4JH47sy604d4iXZnRhROeC5WfEiJLYrj1YtVuOiYWjb6nXCqsmN5xWbJ/5Cmt3Oqzdbgf+ WngWe9x4IZ1AAoYS+Jt8XAKWwqwE6/aeWA7SdHc3iOAs2ejJNtMvJ25bDewuliEPAAFtRa2z6doT 3I16q8eqeMJN4Di4xPz5iZ9xn9CeLSOQYGQHE/I3Az31Z95mLezLeEOc8iH1K4NenQcYwv0QlQR5 liHkyqzT32Sbm33WRx9FXrQp5zLC08lo0x44NlN/I19puXZrwOqr7gbG2B5nzXjS5m/R7Ujmj+y1 UK/Ectiv9trO7xHAml1Z+Uu+KozthC+/zm0adOrUQ2kEAhRIEFhYX8lHIE4G/84GgdzBnHZ64R04 TsORNiJz0jhHtE3K8PIXaiGdt20+xsT0P0GXUp9br3+Q3uU7IkfnCwzQsWP0plMGfkMXwDudIRhg wUFHUw3ChNJYbvtkNmL1kg8/D0fpO0iLrxibW6WzUzEKq0/sg6Cm5Xzmq6kf/Thhy4TOhcvPBngn j117sGq3/K1fuKM/DQkJ3fbL3k6vLXGR5Mf1SmoH4lmGtWMiCWkFEti4l/JeCfbtPakctlqqfcqE 7R8jic3W7uKIizWlWV9CZsJuhO0RkZQ/iXStyyT2TA4kxOmhFiG6iUzsIJaZhD9dkibpEtoX/sYv tJ1PdSasv1VpDBt4OXmz0XbCEE+r9iAPtCP5C1suqHKHa0Cko3hFOwrjb6HtiOz1xPf195mO9JLK YX/aazu/x98adO+t/CV/4YZ2wp9d5z4VOnUqojQcAQokcCiSXThvvbOBzi3DKo0WW3fXvAePfxyx ZqUQGnRwHMZipc4CkxEmZNrm03CIXB6CtOLxSk0fj9kiqzXrfHAQ6ACkNZvBqdxONHXaieeV4x+F HIYbuOM7zjwIdZ5zBXw7F/bGfsgaZW+zQpG3WF7lQQ3dPScEJXpXw36LrRZwqrN31ryLZZD3aXm9 RiVU9vlyYz5BBJcNbTqXIj89rNVU9u3BuN0iJtONA3FXdXfwzQdCuBRl+mjI1l3dDtM1O71WOda6 k+QX1obEs/gNEPkgasa6Rp108hsJkyVb0fzat/dEcuB6MLUxUW3co5tjE+gjhI1y5BFmd50yNppV br+E3DBvJseq7TA7iOE1K/vpUWz+bWvPhOMnTiowr908h7YddIu25c+IMq5XtvZlwGol8XZ+qitT P6RamAbZo/pblc4Ba1T8x1kLmtS00zsTPK3agxRIyJdKwfaAsyf4IU5hBCrP9PlbWDsiez3x9cL6 TEd0ieTA29V+stf2fo/SFAxujP2lkLJN7ERIdq1HadCpVRElmiDwC85/7GzokwYCO9tw8eIWwNFD sDM6DO8+dQJuOKRT8A5sX70K28MxJh7BcOcQnDx1SiOvbT4dmqLS7MC1awCHkK9Dzr/t78DZlQ/C G5gcAwnw2F03RmW0fr59+SJsXtmBlZVDMBojrje/G254Zzyw1zBPfwiAWeDwTSfhuJ4grGm0zujo zMYmEroCo+EQVk6+B07sVlotmbSRn11Vlu3But3aUenlWhwuXo379ztJe987ctiByxcvwhXsH1YO 7cD4XTfByeM3QrwlRBNtYT+tNWW/27M9wt/Vi2/DAI7CoZ0xrKAvceMsJbEW+AIzXrsADx29G85j lWu9ETxyegwX3x7AYWwLI1iB204dnysxC21Hc+Vk+YWTvY6WgbmeWfo90STE/7IkfymeqJBf9wqd IaTvtUcUSNhrElsSvdeuXoSf7twMp46/U6HgzWfvh3ser+OzDDQ2O/CRE/vBY1FYpBtCgBAgBAgB QoAQWCYCUiBhXi8tlske1U0IEAKEwF5EgAIJe1FqS6D5wrNn4e7H34BcYRXu/9j74DacePDX55+G p5535iLgp1iH8Vfum/l2bJqY/hMChAAhQAgQAoQAIaCJAAUSNIGiZIQAIUAILA4BCiQsDus9XZMX SAhlIleBjW88BrepkxVCk9JDQoAQIAQIAUKAECAEjBDYvoDLKO+eLKPEo1bhyTPpL6M0oocSEwKE ACFACAAFEkgJtBDY2b4MvR90oPO3fwdbWz+BfxiMYHT0VyGb+zj8izO30UwELRQpESFACBAChAAh QAgYI7BzCV49/y348fUb4Dc/+Um4Y19s/GCMAmUgBAgBQmBXIUCBhF0lDiKGECAECAFCgBAgBAgB QoAQIAQIAUKAENjdCFAgYXfLh6gjBAgBQoAQIAQIAUKAECAECAFCgBAgBHYVAhRI2FXiIGIIAUKA ECAECAFCgBAgBAgBQoAQIAQIgd2NAAUSdpl8rl29BD8djuFdKzfD8Rtp98JdJh4ihxAgBAgBQoAQ IAQIAUKAECAECIEDjwAFEnaVCmzDubMr8CieqJgpt+F7T57ZVdQRMYQAIUAIEAKEACFACBAChAAh QAgQAoQABRJ2lQ6IQEKu0oFXHrtrJnXf/9pDkPnMeYBcFYavPAw3zMxBCQgBQoAQIAQIAUKAECAE CAFCgBAgBAgBewQokGCP3RxyXoPXn34c/uNrP4R7/tVz8KXfOz2zju+fw0DCoxhIyK7B4PVHgE5W ngkZJSAECAFCgBAgBAgBQoAQIAQIAUKAEEiAAAUSEoC3G7K+hTMSbndnJIxwRgLtqrAbpEI0EAKE ACFACBAChAAhQAgQAoQAIbB/EaBAQpqy3b4Ir774AtS++QZ0rwAcu3UFTt58K7zv/Vn48Mc+DKeP hw3zd+D7r70Ef/WTn8MRj5br1+Gm3/htuO/MCe+J9I3pXz0Pb/z4OhzBDG+98Cg8g3sq4JQEKK99 Gn4Jrk/SYhHwgU99Fu46fkjK611egwuv/gmc++NvQvtHSCcgsZmz8LnPF+HBM6e8RPRNCBAChAAh QAgQAoQAIUAIEAKEACFACAQQoEBCABK7BzuXXoO7T34UuhHZM+UObp4YtufBVXj6F26Cp3z5srjZ 4uuhmy2Gp/dln9yutgfwhTO+xQ7bb8F/yN0OX5wEH4K5cuUmfOPJszSzIQgNPSEECAFCgBAgBAgB QoAQIAQIAUKAEEAEKJCQihrswOt/eDd86MvTMEKhvA7/y0fvgHeN/xH+3+634fxnnoIfRZ7CsANv vf4KtH8C8IvvuATPfeJxcMb40Zst7sDbb/4F/Lef/hzTA3TXc/AUbpGAOaDaeBRu+vnPpxz9/B3w P37of4LbbpRnJFyGZ8++Gx53gwiZQhm+8shH4fh//xH88b/PuTMbAEqNTfjSR8JmQ0yLpv+EACFA CBAChAAhQAgQAoQAIUAIEAIHFwEKJKQi+6t4bONN02MbS0343pfO+krdhstXD8PxG8OWNshJd+DF +w/D79fjAglyelzaYLBHwtU3n4ab7pnOfShUO3DuYXmGxGU4d/+74VGsG0MJ0GdfAlrkoGJNd4QA IUAIEAKEACFACBAChAAhQAgQAjQjISUdwGMb71+ZDsJzFeh/4zE4NStmEFrzNnwNy/mMQSBBPrVh iKc2RB//eA1efuQofOJ5p+IMNDffhN+8YQSjHZeQo0fhp/9nCW7/xDP4IAetwStwr29VhJuSvggB QoAQIAQIAUKAECAECAFCgBAgBA4wAjQjIRXh78BrTxyGjzpjcPeTL5Xho/dk4PStvwa/dsdtMQN8 L4fzPc9AghTskKuMuF7vjeD3TltFQyJKpMeEACFACBAChAAhQAgQAoQAIUAIEAL7AQEKJKQlxdhN DHNQ7/0p3Hc6er7AlIz5BhK82Q6TujIZnJcQ9ulCt5uB9d53MZAwi96w/PSMECAECAFCgBAgBAgB QoAQIAQIAUJgPyNAgYRUpXsNLl74G/ib7n+Dv2y+Ds+cn2w44NZQgI3xObhN3vswUPeCAgnZCgxe fwxo5UJAAPSAECAECAFCgBAgBAgBQoAQIAQIAUJgBgIUSJgBUJKfd7Yvwktffhx+/8vTgMJaZwiP 3BX3lj9BICG3BsNX4vZIkJY22AYSrr0Ff3jmdvi/3LkM3e490Bmeg1iWkgBIeQkBQoAQIAQIAUKA ECAECAFCgBAgBHYdAhRImLNIdr7/LBzOPD6ppdIewGNn4uYB2AQS7oeMc9RCZhW2vvcFOB7DDz/h AdNUu0N4+I7woMYObsB4KGzmxPYFuH/lbpiGRZyKctAevgJnwouJoYR+IgQIAUKAECAECAFCgBAg BAgBQoAQ2KsIUCAhFclhAOChD8Bfv+8L8PncP4fbTx0HZxy+c/UteO6x34HHz3fxLgvNrT+Hs8d9 I/Sda7A9GuPvh+Ho4Z/C/37mFngKk2fLLfi//9f3wXjyG/569AZ4py+rQ/pbLz4Ct//+5CgGKFQa 8O8fOjPZ2HEHKbjhxhsmdDjpJp+rb8LZm+6BNyY3WVhrPgf/89nT4GypuHPtKmx87zvwwpcxOHC2 A68/Jh8NOc0O1y7AQ0fvhvPurRNI+P/bu1/epsIoDsBHDIHY5BCI8QWoGAJd5gExOQRmS2YKIYEE gSIQSEjoFKBIJsHsC9RgZoboNGICRciSVXQJFdyuo//ozNLXnDwzu/eu9yznOer++r7tQRUkWJEw BHFAgAABAgQIECBAgACB9AKChLmMuNo2cKf6+sfBE/pZxVr1YYbtdj9AOP/Z/BLdj+tnD+3/LvV/ f9+5H7cao/f4x/82flxvXvBwPxEOjN8R0TyoVkCsTq6AOGq9jRtrzyZfOHVWf7Mfrae3p65WpzNW JAgS/mdyhQABAgQIECBAgAABApkFBAlzme5ptHYa8bjxKcaig2HlR829eL59N6YXI/RfcPj5QdQe jt7jH940dbDxoR27Wzenrg5OO0ff4v2rd/F1f68KL0YvuWj7QudHK14/WYvzj24Y3VAd1e9txvaL l7G+OmOTxOlhbF2txWD9Q/+2jWpFwq4VCROCTggQIECAAAECBAgQIJBbQJAw1/n2onN8HJ2T/laF bpz0FuL6ykosztiSMNd/e8linV9H8fN3L5aWFqL750osX1uOxVn7Jy5Z320ECBAgQIAAAQIECBAg kE9AkJBvpjoiQIAAAQIECBAgQIAAAQLFBAQJxWgVJkCAAAECBAgQIECAAAEC+QQECflmqiMCBAgQ IECAAAECBAgQIFBMQJBQjFZhAgQIECBAgAABAgQIECCQT0CQkG+mOiJAgAABAgQIECBAgAABAsUE BAnFaBUmQIAAAQIECBAgQIAAAQL5BAQJ+WaqIwIECBAgQIAAAQIECBAgUExAkFCMVmECBAgQIECA AAECBAgQIJBPQJCQb6Y6IkCAAAECBAgQIECAAAECxQQECcVoFSZAgAABAgQIECBAgAABAvkEBAn5 ZqojAgQIECBAgAABAgQIECBQTECQUIxWYQIECBAgQIAAAQIECBAgkE9AkJBvpjoiQIAAAQIECBAg QIAAAQLFBAQJxWgVJkCAAAECBAgQIECAAAEC+QQECflmqiMCBAgQIECAAAECBAgQIFBMQJBQjFZh AgQIECBAgAABAgQIECCQT0CQkG+mOiJAgAABAgQIECBAgAABAsUEBAnFaBUmQIAAAQIECBAgQIAA AQL5BAQJ+WaqIwIECBAgQIAAAQIECBAgUExAkFCMVmECBAgQIECAAAECBAgQIJBPQJCQb6Y6IkCA AAECBAgQIECAAAECxQT+AvwptXsGrfjoAAAAAElFTkSuQmCC --Apple-Mail=_8B258AF5-825B-442E-943D-D005AB4468D1-- --Apple-Mail=_673EEAE6-4043-4B6C-8C36-DDF97C33DC63-- From nobody Thu Dec 28 05:49:16 2017 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26F512D893 for ; Thu, 28 Dec 2017 05:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 8m49Hd-5xjHv for ; Thu, 28 Dec 2017 05:49:03 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6ED12D82F for ; Thu, 28 Dec 2017 05:49:03 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id v30so6621320iov.7 for ; Thu, 28 Dec 2017 05:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=T58OQQg9Iu/4NrREkzQKOEu+xVZGEKIXP4iPY8s6xrI=; b=oe37Wz5zBilzKr792KMUOOVR3U786SNwXPi7Ap49DuCXQIz4SGMa7aM4GUVwmlco5u OF6cWz635WPkppEop0e2L/kSdTN+EfVdps7sNoo6J34Rp1PHIdPOMIi9lISzZY7pKb23 LrE0tZDARww02N2OEoV2MVcdVQZF87KzszYVkw7DP8MCvgrk8uBqhygI3HvLgwCcsKMT x2NksNV5ylt3INHOVW3nVB3kVb8XCAZ5OgK6zXFiVYYvQSJGjhOD8TfiJNSnovyjSYKn 4oPhJN2w0Clyxb3oSl20fBgTNume+wufifiPixSn0WgQEvlJgt/xDqFmR3bT+i+8GwRw 55mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=T58OQQg9Iu/4NrREkzQKOEu+xVZGEKIXP4iPY8s6xrI=; b=Ge99YZD6F54K41nqKanhxAmcIiOJkeLZZyTL60Aos3r5bc4ursf1kMvEX3MCL2BJmM ovTN92wuS9BlWe5nAij0ghKeSIfD6oxh3t9wG3Q6egU7Uil22MvJafnPg8JaR3lmN/D1 ocWIvmSB1tj99Y34+PTtBhlswWbHe9WGyWwlv6lESh+NvcYV0aHxOltdth7Bk7jPy4NN N+dGy1+7PHMrcxwH2zaujWtY3+LO+EJy9+mU542dj+VZYJy+tc7wPYQxH9ABWWqIoMBr beS1B0H4/pPHNTAe3NjRVY5NfowDB7kqekO/Uqy3wQbaN2wnZ+C5rtNLhLPICvBL0spG bDJA== X-Gm-Message-State: AKGB3mKnik0qF3elDiJHKgItP0oleL/7XJ7lNZeXFP50QIaa5cGAtLAz yPeINouXnvLAOCckeb0iMEQ= X-Google-Smtp-Source: ACJfBos5in558ralXO2+DMQ033a8/yV06TLukTTgIiMIk+rt+fzwUbzH3NHx4peCI/QXF7AVgwgXtw== X-Received: by 10.107.52.14 with SMTP id b14mr41292618ioa.185.1514468942786; Thu, 28 Dec 2017 05:49:02 -0800 (PST) Received: from [192.168.4.79] ([12.219.234.2]) by smtp.gmail.com with ESMTPSA id j68sm13364794iod.53.2017.12.28.05.48.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Dec 2017 05:49:01 -0800 (PST) From: Dino Farinacci Message-Id: <648277C9-9361-485E-B9EE-1B59D2FC301E@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_8C1A4519-7E43-41B9-9800-E4BFA031930D" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 28 Dec 2017 05:48:53 -0800 In-Reply-To: Cc: Albert Cabellos , "lisp@ietf.org list" , lisp-chairs@tools.ietf.org To: "Joel M. Halpern" References: <907CD955-B043-4728-ABD6-5AD96192EC5F@inria.fr> <4EAD1E98-E8E7-4A0A-8300-2D185B9109CC@gigix.net> <6FEB1404-FA34-432A-8441-3F6B394A8217@gmail.com> <252ece17-7705-3f19-c9b1-21030e753151@joelhalpern.com> <105de8e0-d1b8-a11c-242b-06b2f156b2ee@joelhalpern.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [lisp] 6830bis Review X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 13:49:14 -0000 --Apple-Mail=_8C1A4519-7E43-41B9-9800-E4BFA031930D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Latest change reflects Joel=E2=80=99s comment. Changed =E2=80=9Cglobal = Internet=E2=80=9D to =E2=80=9Cunderlay network=E2=80=9D in the = definition of "Provider-Assigned (PA) Addresses=E2=80=9D and "Routing = Locator (RLOC)=E2=80=9D. Dino --Apple-Mail=_8C1A4519-7E43-41B9-9800-E4BFA031930D Content-Disposition: attachment; filename=rfcdiff-rfc6830bis.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-rfc6830bis.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-rfc6830bis-07.txt - = draft-ietf-lisp-rfc6830bis-08.txt=20 =20 =20 =20 =20 =20 =20 = = = = = = = = = = = = =
< draft-ietf-lisp-rfc6830bis-07.txt  =  draft-ietf-lisp-rfc6830bis-08.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = V. Fuller Internet-Draft = V. Fuller
Intended status: = Standards Track D. Meyer = Intended status: Standards Track = D. Meyer
Expires: May 15, 2018 = D. Lewis Expires: July 1, 2018 = D. Lewis
= Cisco Systems = Cisco Systems
= A. Cabellos (Ed.) = A. Cabellos (Ed.)
= UPC/BarcelonaTech = UPC/BarcelonaTech
= November = 11, 2017 = December = 28, 2017
=
= The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol = (LISP)
= draft-ietf-lisp-rfc6830bis-07 = = draft-ietf-lisp-rfc6830bis-08
=
Abstract = Abstract
=
This document = describes the data-plane protocol for the Locator/ID This document describes the data-plane protocol for = the Locator/ID
Separation = Protocol (LISP). LISP defines two namespaces, End-point = Separation Protocol (LISP). LISP defines = two namespaces, End-point
Identifiers = (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and = Routing Locators
(RLOCs) that = identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. = With this, LISP
effectively = separates control from data, and allows routers to create = effectively separates control from data, and = allows routers to create
overlay = networks. LISP-capable routers exchange encapsulated packets = overlay networks. LISP-capable routers = exchange encapsulated packets
according to = EID-to-RLOC mappings stored in a local map-cache. The = according to EID-to-RLOC mappings stored in a local map-cache.
map-cache is populated by the LISP Control-Plane = protocol
[I-D.ietf-lisp-rfc6833bis].
=
LISP requires = no change to either host protocol stacks or to underlay = LISP requires no change to either host = protocol stacks or to underlay
routers and = offers Traffic Engineering, multihoming and mobility, routers and offers Traffic Engineering, multihoming = and mobility,
among other = features. among other = features.
=
Status of This = Memo Status of This Memo
=
This = Internet-Draft is submitted in full conformance with the = This Internet-Draft is submitted in full = conformance with the
provisions of = BCP 78 and BCP 79. provisions of = BCP 78 and BCP 79.
=
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current/. Drafts is at = https://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on May 15, = 2018. This Internet-Draft will = expire on July 1, 2018.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 28 =C2=B6 = skipping to change at page 2, line 28 =C2=B6
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. = Requirements Notation . . . . . . . . . . . . . . . . . . . . = 4 2. Requirements Notation . . . . = . . . . . . . . . . . . . . . . 4
3. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
4. Basic = Overview . . . . . . . . . . . . . . . . . . . . . . . 9 = 4. Basic Overview . . . . . . . . . . . . = . . . . . . . . . . . 9
4.1. Packet = Flow Sequence . . . . . . . . . . . . . . . . . . 11 4.1. Packet Flow Sequence . . . . . . . . . . . . = . . . . . . 11
5. LISP = Encapsulation Details . . . . . . . . . . . . . . . . . 13 = 5. LISP Encapsulation Details . . . . . . = . . . . . . . . . . . 13
5.1. LISP = IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 14 5.1. = LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13
5.2. LISP = IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 15 5.2. = LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14
5.3. = Tunnel Header Field Descriptions . . . . . . . . . . . . 16 5.3. = Tunnel Header Field Descriptions . . . . . . . . . . . . 15
6. LISP = EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 6. = LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19
7. Dealing = with Large Encapsulated Packets . . . . . . . . . . . 20 = 7. Dealing with Large Encapsulated Packets = . . . . . . . . . . . 20
7.1. A = Stateless Solution to MTU Handling . . . . . . . . . . 21 7.1. = A Stateless Solution to MTU Handling . . . . . . . . . . 20
7.2. A = Stateful Solution to MTU Handling . . . . . . . . . . . 22 7.2. = A Stateful Solution to MTU Handling . . . . . . . . . . . 21
8. Using = Virtualization and Segmentation with LISP . . . . . . . 22 = 8. Using Virtualization and Segmentation = with LISP . . . . . . . 22
9. Routing = Locator Selection . . . . . . . . . . . . . . . . . . 23 = 9. Routing Locator Selection . . . . . . . = . . . . . . . . . . . 23
10. Routing = Locator Reachability . . . . . . . . . . . . . . . . 24 = 10. Routing Locator Reachability . . . . . = . . . . . . . . . . . 24
10.1. Echo = Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 = 10.1. Echo Nonce Algorithm . . . . . . . = . . . . . . . . . . . 27
10.2. = RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 = 10.2. RLOC-Probing Algorithm . . . . . . = . . . . . . . . . . . 28
11. EID = Reachability within a LISP Site . . . . . . . . . . . . . 29 = 11. EID Reachability within a LISP Site . . = . . . . . . . . . . . 29
12. Routing = Locator Hashing . . . . . . . . . . . . . . . . . . . 30 12. = Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29
13. Changing = the Contents of EID-to-RLOC Mappings . . . . . . . . 31 13. = Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30
13.1. = Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32 13.1. = Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31
13.2. = Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 = 13.2. Solicit-Map-Request (SMR) . . . . = . . . . . . . . . . . 32
13.3. = Database Map-Versioning . . . . . . . . . . . . . . . . 34 13.3. = Database Map-Versioning . . . . . . . . . . . . . . . . 33
14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 35 14. = Multicast Considerations . . . . . . . . . . . . . . . . . . 34
15. Router = Performance Considerations . . . . . . . . . . . . . . 35 = 15. Router Performance Considerations . . . = . . . . . . . . . . . 35
16. Mobility = Considerations . . . . . . . . . . . . . . . . . . . 36 16. = Mobility Considerations . . . . . . . . . . . . . . . . . . . 35
16.1. Slow = Mobility . . . . . . . . . . . . . . . . . . . . . 36 = 16.1. Slow Mobility . . . . . . . . . . = . . . . . . . . . . . 36
16.2. Fast = Mobility . . . . . . . . . . . . . . . . . . . . . 36 = 16.2. Fast Mobility . . . . . . . . . . = . . . . . . . . . . . 36
16.3. LISP = Mobile Node Mobility . . . . . . . . . . . . . . . 37 = 16.3. LISP Mobile Node Mobility . . . . = . . . . . . . . . . . 37
17. LISP xTR = Placement and Encapsulation Methods . . . . . . . . 38 17. = LISP xTR Placement and Encapsulation Methods . . . . . . . . 37
17.1. = First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 17.1. = First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38
17.2. = Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 = 17.2. Border/Edge xTRs . . . . . . . . . = . . . . . . . . . . . 39
17.3. ISP = Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 17.3. = ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39
17.4. LISP = Functionality with Conventional NATs . . . . . . . 40 = 17.4. LISP Functionality with = Conventional NATs . . . . . . . 40
17.5. = Packets Egressing a LISP Site . . . . . . . . . . . . . 41 17.5. = Packets Egressing a LISP Site . . . . . . . . . . . . . 40
18. = Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18. = Traceroute Considerations . . . . . . . . . . . . . . . . . . 40
18.1. = IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.1. = IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41
18.2. IPv4 = Traceroute . . . . . . . . . . . . . . . . . . . . 42 = 18.2. IPv4 Traceroute . . . . . . . . . = . . . . . . . . . . . 42
18.3. = Traceroute Using Mixed Locators . . . . . . . . . . . . 43 18.3. = Traceroute Using Mixed Locators . . . . . . . . . . . . 42
19. Security = Considerations . . . . . . . . . . . . . . . . . . . 43 = 19. Security Considerations . . . . . . . . = . . . . . . . . . . . 43
20. Network = Management Considerations . . . . . . . . . . . . . . 44 20. = Network Management Considerations . . . . . . . . . . . . . . 43
21. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 44 = 21. IANA Considerations . . . . . . . . . . = . . . . . . . . . . . 44
21.1. LISP = UDP Port Numbers . . . . . . . . . . . . . . . . . 44 = 21.1. LISP UDP Port Numbers . . . . . . = . . . . . . . . . . . 44
22. References = . . . . . . . . . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . = . . . . . . 44
22.1. = Normative References . . . . . . . . . . . . . . . . . . 44 = 22.1. Normative References . . . . . . . = . . . . . . . . . . . 44
22.2. = Informative References . . . . . . . . . . . . . . . . . 47 22.2. = Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 51 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 50
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 51 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 50
B.1. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . = 51
B.2. = Changes to draft-ietf-lisp-rfc6830bis-06 = . . . . . . . . 52 B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . = 51
B.3. = Changes to draft-ietf-lisp-rfc6830bis-05 = . . . . . . . . 52 B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . = 51
B.4. = Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 = B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . = 51
B.5. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 53 B.5. Changes to = draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52
B.6. Changes to = draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 B.6. Changes to draft-ietf-lisp-rfc6830bis-03 = . . . . . . . . 52
B.7. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 B.7. Changes to = draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52
B.8. Changes to = draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 B.8. Changes to = draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 B.9. Changes to = draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 52
=
1. = Introduction 1. Introduction
=
This document = describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier = Separation Protocol
(LISP). LISP = is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built = around the
fundamental = idea of separating the topological location of a network = fundamental idea of separating the = topological location of a network
attachment = point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. = As a result
LISP creates = two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers = (EIDs), that are
used to = identify end-hosts (e.g., nodes or Virtual Machines) and = used to identify end-hosts (e.g., nodes or = Virtual Machines) and
routable = Routing Locators (RLOCs), used to identify network routable Routing Locators (RLOCs), used to identify = network
attachment = points. LISP then defines functions for mapping between = attachment points. LISP then defines = functions for mapping between
the two = namespaces and for encapsulating traffic originated by the two namespaces and for encapsulating traffic = originated by
devices using = non-routable EIDs for transport across a network devices using non-routable EIDs for transport across = a network
= infrastructure that routes and forwards using RLOCs. infrastructure that routes and forwards using RLOCs. = LISP
= encapsulation uses a = dynamic form of tunneling where no static
= provisioning is = required or necessary.
=
LISP is an = overlay protocol that separates control from data-plane, = LISP is an overlay protocol that separates = control from data-plane,
this document = specifies the data-plane, how LISP-capable routers this document specifies the data-plane, how = LISP-capable routers
(Tunnel = Routers) exchange packets by encapsulating them to the (Tunnel Routers) exchange packets by encapsulating = them to the
appropriate = location. Tunnel routers are equipped with a cache, appropriate location. Tunnel routers are equipped = with a cache,
called = map-cache, that contains EID-to-RLOC mappings. The map-cache = called map-cache, that contains EID-to-RLOC = mappings. The map-cache
is populated = using the LISP Control-Plane protocol = is populated using the LISP Control-Plane protocol
= [I-D.ietf-lisp-rfc6833bis]. = [I-D.ietf-lisp-rfc6833bis].
=
LISP does not = require changes to either host protocol stack or to LISP does not require changes to either host protocol = stack or to
=
skipping to = change at = page 4, line 31 =C2=B6 = skipping to change at page 4, line 33 =C2=B6
describes the = LISP architecture. describes the = LISP architecture.
=
2. Requirements = Notation 2. Requirements = Notation
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
document are = to be interpreted as described in [RFC2119]. document are to be interpreted as described in = [RFC2119].
=
3. Definition of = Terms 3. Definition of Terms
=
Provider-Independent (PI) Addresses: PI addresses = are an address Address Family Identifier (AFI): AFI is a term used = to describe an
block assigned from a pool where blocks are not = associated with address = encoding in a packet.= An address family that pertains to
any particular location in the network (e.g., from a particular the data-plane. See = [AFN] and [RFC3232] for details. An = AFI
service provider) and are therefore not topologically = aggregatable value of 0 used in this specification indicates an = unspecified
in the = routing system. encoded address where the = length of the address is 0 octets
= following = the 16-bit AFI value of 0.
=
Provider-Assigned (PA) Addresses: PA addresses are an = address block Anycast Address: Anycast Address is a term used in this document to
assigned to a site by each service provider to = which a site refer to the same = IPv4 or IPv6 address configured and used on
connects. Typically, each block is a = sub-block of a service multiple systems at = the same time. An EID or RLOC can be = an
provider Classless Inter-Domain Routing (CIDR) = [RFC4632] block and anycast address in each of their own address spaces.
is aggregated into the larger block before being advertised = into
the global Internet. Traditionally, IP multihoming has = been
implemented by each multihomed site acquiring its own globally
visible prefix. LISP uses only topologically = assigned and
aggregatable address blocks for RLOCs, eliminating this =
demonstrably non-scalable = practice.
=
Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 Client-side: = Client-side is a term used in this = document to indicate
[RFC8200] address of an Egress Tunnel = Router (ETR). An RLOC is a connection initiation attempt by an = EID. The ITR(s) at the LISP
the output of an EID-to-RLOC mapping lookup. An EID maps to = one site = are the first to get involved in forwarding a packet from = the
or more RLOCs. Typically, = RLOCs are numbered from topologically source EID.
aggregatable blocks that are assigned to = a site at each = point to
which it attaches to the global Internet; where the topology is Data-Probe: A Data-Probe is = a LISP-encapsulated data packet where
defined by the connectivity of provider = networks, RLOCs can be the inner-header destination address equals the = outer-header
thought of as PA = addresses. Multiple RLOCs can be assigned to the destination address = used to trigger a Map-Reply by a = decapsulating
same ETR device or to = multiple ETR devices at a site. ETR. In addition, the original packet is = decapsulated and
= delivered to the = destination host if the destination EID is in the
= EID-Prefix range = configured on the ETR. Otherwise, the packet is
= discarded. A = Data-Probe is used in some of the mapping = database
= designs to = "probe" or request a Map-Reply from an ETR; = in other
= cases, = Map-Requests are used. See each mapping database design
= for details. = When using Data-Probes, by sending Map-Requests on
= the underlying = routing system, EID-Prefixes must be advertised.
= =
= Egress Tunnel Router (ETR): An ETR is = a router that accepts an IP
= packet where the = destination address in the "outer" IP header is
= one of its = own RLOCs. The router strips the "outer" = header and
= forwards the = packet based on the next IP header found. In
= general, an ETR = receives LISP-encapsulated IP packets from the
= Internet on one = side and sends decapsulated IP packets to site
= end-systems on = the other side. ETR functionality does not have to
= be limited = to a router device. A server host can be = the endpoint
= of a LISP tunnel = as well.
=
= EID-to-RLOC = Database: The EID-to-RLOC Database is a global
= distributed = database that contains all known EID-Prefix-to-RLOC
= mappings. Each = potential ETR typically contains a small piece of
= the database: the = EID-to-RLOC mappings for the EID-Prefixes
= "behind" the = router. These map to one of the router's own
= globally visible = IP addresses. Note that there MAY be transient
= conditions when = the EID-Prefix for the site and Locator-Set for
= each EID-Prefix = may not be the same on all ETRs. This has = no
= negative = implications, since a partial set of Locators can be
= used.
=
= EID-to-RLOC = Map-Cache: The EID-to-RLOC map-cache is generally
= short-lived, = on-demand table in an ITR that stores, tracks, and is
= responsible for = timing out and otherwise validating EID-to-RLOC
= mappings. This = cache is distinct from the full "database" of EID-
= to-RLOC mappings; = it is dynamic, local to the ITR(s), and
= relatively small, = while the database is distributed, relatively
= static, and much = more global in scope.
=
= EID-Prefix: An = EID-Prefix is a power-of-two block of EIDs that are
= allocated to a = site by an address allocation authority. EID-
= Prefixes are = associated with a set of RLOC addresses. EID-Prefix
= = allocations can be broken up into smaller = blocks when an RLOC set
= is to = be associated with the larger EID-Prefix block.
=
= End-System: An = end-system is an IPv4 or IPv6 device that = originates
= packets with a = single IPv4 or IPv6 header. The = end-system
= supplies an EID = value for the destination address field of the IP
= header when = communicating globally (i.e., outside of its routing
= domain). An = end-system can be a host computer, a = switch or router
= device, or any = network appliance.
=
Endpoint ID = (EID): An EID is a 32-bit (for IPv4) or 128-bit (for Endpoint ID (EID): An EID is a 32-bit (for IPv4) or = 128-bit (for
IPv6) value = used in the source and destination address fields of IPv6) value used in the source and destination = address fields of
the first = (most inner) LISP header of a packet. The host obtains = the first (most inner) LISP header of a = packet. The host obtains
a = destination EID the same way it obtains a destination address = a destination EID the same way it obtains = a destination address
today, for = example, through a Domain Name System (DNS) [RFC1034] today, for example, through a Domain Name System = (DNS) [RFC1034]
lookup or = Session Initiation Protocol (SIP) [RFC3261] exchange. lookup or Session Initiation Protocol (SIP) = [RFC3261] exchange.
The source = EID is obtained via existing mechanisms used to set a The source EID is obtained via existing mechanisms = used to set a
host's = "local" IP address. An EID used on the public Internet = host's "local" IP address. An EID used = on the public Internet
must have = the same properties as any other IP address used in that = must have the same properties as any = other IP address used in that
manner; = this means, among other things, that it must be globally = manner; this means, among other things, = that it must be globally
unique. An = EID is allocated to a host from an EID-Prefix block unique. An EID is allocated to a host from an = EID-Prefix block
associated = with the site where the host is located. An EID can be = associated with the site where the host = is located. An EID can be
used by a = host to refer to other hosts. Note that EID blocks MAY = used by a host to refer to other hosts. = Note that EID blocks MAY
be assigned = in a hierarchical manner, independent of the network be assigned in a hierarchical manner, independent = of the network
topology, = to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping = database. In
addition, = an EID block assigned to a site may have = site-local addition, an EID = block assigned to a site MAY have = site-local
structure = (subnetting) for routing within the site; this structure = structure (subnetting) for routing within = the site; this structure
is not = visible to the global routing system. In theory, the bit = is not visible to the global routing = system. In theory, the bit
string that = represents an EID for one device can represent an RLOC string that represents an EID for one device can = represent an RLOC
for a = different device. As the architecture is = realized, if a for a = different device. When used in discussions with other
given bit string is both an RLOC and an EID, it = must refer to the
same entity in both cases. When used in = discussions with other
Locator/ID = separation proposals, a LISP EID will be called an Locator/ID separation proposals, a LISP EID will = be called an
"LEID". = Throughout this document, any references to "EID" refer = "LEID". Throughout this document, any = references to "EID" refer
to an = LEID. to an LEID.
=
EID-Prefix: An EID-Prefix is a power-of-two block of = EIDs that are
allocated to a site by an address allocation = authority. EID-
Prefixes are associated with a set of RLOC = addresses that make up
a "database mapping". EID-Prefix allocations can = be broken up
into smaller blocks when an RLOC set is to be = associated with the
larger EID-Prefix block. A globally routed = address block (whether
PI or PA) is not inherently an EID-Prefix. A = globally routed
address block MAY be used by its assignee as an = EID block. The
converse is not supported. That is, a site that = receives an
explicitly allocated EID-Prefix may not use that = EID-Prefix as a
globally routed prefix. This would require = coordination and
cooperation with the entities managing the = mapping infrastructure.
Once this has been done, that block could be = removed from the
globally routed IP system, if other suitable = transition and access
mechanisms are in place. Discussion of such = transition and access
mechanisms can be found in [RFC6832] and = [RFC7215].
End-system: An end-system is an IPv4 or IPv6 = device that originates
packets with a single IPv4 or IPv6 header. The = end-system
supplies an EID value for the destination address = field of the IP
header when communicating globally (i.e., outside = of its routing
domain). An end-system can be a host computer, a = switch or router
device, or any network appliance. =
= =
Ingress Tunnel = Router (ITR): An ITR is a router that resides in a Ingress Tunnel Router (ITR): An ITR is a router = that resides in a
LISP site. = Packets sent by sources inside of the LISP site to LISP site. Packets sent by sources inside of the = LISP site to
= destinations outside of the site are candidates for = encapsulation destinations = outside of the site are candidates for encapsulation
by the ITR. = The ITR treats the IP destination address as an EID by the ITR. The ITR treats the IP destination = address as an EID
and = performs an EID-to-RLOC mapping lookup. The router then = and performs an EID-to-RLOC mapping = lookup. The router then
prepends an = "outer" IP header with one of its routable RLOCs (in prepends an "outer" IP header with one of its = routable RLOCs (in
the RLOC = space) in the source address field and the result of the = the RLOC space) in the source address = field and the result of the
mapping = lookup in the destination address field. Note that this = mapping lookup in the destination address = field. Note that this
destination = RLOC MAY be an intermediate, proxy device that has destination RLOC MAY be an intermediate, proxy = device that has
better = knowledge of the EID-to-RLOC mapping closer to the better knowledge of the EID-to-RLOC mapping closer = to the
=
skipping to = change at = page 6, line 33 =C2=B6 = skipping to change at page 7, line 5 =C2=B6
end-systems = on one side and sends LISP-encapsulated IP packets end-systems on one side and sends = LISP-encapsulated IP packets
toward the = Internet on the other side. = toward the Internet on the other side.
=
= Specifically, when a service provider prepends a LISP header = for Specifically, when a service = provider prepends a LISP header for
Traffic = Engineering purposes, the router that does this is also = Traffic Engineering purposes, the router = that does this is also
regarded as = an ITR. The outer RLOC the ISP ITR uses can be based regarded as an ITR. The outer RLOC the ISP ITR = uses can be based
on the = outer destination address (the originating ITR's supplied = on the outer destination address (the = originating ITR's supplied
RLOC) or = the inner destination address (the originating host's RLOC) or the inner destination address (the = originating host's
supplied = EID). supplied EID).
=
TE-ITR: A TE-ITR is an ITR that is deployed in a = service provider LISP Header: LISP header is a term used in this = document to refer
network that prepends an additional LISP = header for Traffic to the outer IPv4 or IPv6 = header, a UDP header, and a LISP-
Engineering purposes. specific 8-octet = header that follow the UDP header and that = an ITR
prepends or an ETR strips.
Egress Tunnel Router (ETR): An ETR is a = router that accepts an IP =
packet where the destination address in = the "outer" IP header is
one of its own RLOCs. The router strips the = "outer" header and
forwards the packet based on the next IP header = found. In
general, an ETR receives LISP-encapsulated IP = packets from the
Internet on one side and sends decapsulated IP = packets to site
end-systems on the other side. ETR functionality = does not have to
be limited to a router = device. A server host can be the endpoint
of a LISP tunnel as = well.
TE-ETR: A TE-ETR is an ETR that is deployed = in a service provider =
network that strips an outer LISP header = for Traffic Engineering
purposes.
xTR: An xTR is a reference to an ITR or ETR when = direction of data
flow is not part of the context description. = "xTR" refers to the
router that is the = tunnel endpoint and is used synonymously with
the term "Tunnel Router". For example, "An xTR = can be located at
the Customer Edge (CE) router" indicates both ITR = and ETR
functionality at the CE router. =
Re-encapsulating Tunneling in RTRs: = Re-encapsulating Tunneling
occurs when an RTR = (Re-encapsulating Tunnel Router) acts like an
ETR to remove a LISP header, then acts as an ITR to prepend = a new
LISP header. Doing this allows a packet to be = re-routed by the
RTR without adding the overhead of additional = tunnel headers. Any
references to tunnels in this specification refer = to dynamic
encapsulating tunnels; they are never statically = configured. When
using multiple mapping database systems, care = must be taken to not
create re-encapsulation loops through = misconfiguration.
=
LISP Router: = A LISP router is a router that performs the functions LISP Router: A LISP router is a router that = performs the functions
of any or = all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), of any or all of the following: ITR, ETR, RTR, = Proxy-ITR (PITR),
or = Proxy-ETR (PETR). or Proxy-ETR = (PETR).
=
EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is = generally LISP Site: LISP site is a set of routers = in an edge network that are
short-lived, on-demand table in an ITR that = stores, tracks, and is = under a single technical administration. LISP = routers that reside
responsible for timing out and otherwise = validating EID-to-RLOC = in the edge network are the demarcation points to separate the
mappings. This cache is distinct from the full = "database" of EID- edge network from the core = network.
to-RLOC mappings; it is dynamic, local to the = ITR(s), and
relatively small, while the database is = distributed, relatively
static, and much more global in = scope.
EID-to-RLOC Database: The EID-to-RLOC Database is = a global
distributed database that contains all known = EID-Prefix-to-RLOC
mappings. Each potential ETR typically contains = a small piece of
the database: the EID-to-RLOC mappings for the = EID-Prefixes
"behind" the router. These map to one of the = router's own
globally visible IP addresses. Note that there = MAY be transient
conditions when the EID-Prefix for the = site and Locator-Set for
each EID-Prefix may not be the same on all ETRs. = This has no
negative implications, since a partial set of Locators = can be
used.
Recursive Tunneling: Recursive Tunneling occurs = when a packet has
more than one LISP IP header. Additional layers = of tunneling MAY
be employed to implement Traffic Engineering or = other re-routing
as needed. When this is done, an additional "outer" LISP header
is added, and the original RLOCs are preserved in the "inner"
header. Any references to tunnels in this = specification refer to
dynamic encapsulating tunnels; they are = never statically
configured.
LISP Header: LISP header is a term used in this = document to refer
to the = outer IPv4 or IPv6 header, a UDP header, and a = LISP-
specific 8-octet header that follow the = UDP header and that an ITR =
prepends or an ETR strips. =
=
Address Family Identifier (AFI): AFI is a term = used to describe an Locator-Status-Bits (LSBs): = Locator-Status-Bits are present in the
address encoding in a packet. An address family that pertains = to LISP = header. They are used by ITRs to = inform ETRs about the up/
the data-plane. See [AFN] and [RFC3232] for details. An AFI down status of all ETRs at = the local site. These bits are used as
value of 0 used in = this specification indicates an unspecified a hint to convey up/down router status and not path reachability
encoded address where the length of the = address is 0 octets status. The LSBs can be = verified by use of one of the Locator
following the 16-bit AFI value of = 0. = reachability algorithms described in Section 10.
=
Negative = Mapping Entry: A negative mapping entry, also known as a = Negative Mapping Entry: A negative mapping = entry, also known as a
negative = cache entry, is an EID-to-RLOC entry where an EID-Prefix = negative cache entry, is an EID-to-RLOC = entry where an EID-Prefix
is = advertised or stored with no RLOCs. That is, the Locator-Set = is advertised or stored with no RLOCs. = That is, the Locator-Set
for the = EID-to-RLOC entry is empty or has an encoded Locator count = for the EID-to-RLOC entry is empty or has = an encoded Locator count
of 0. This = type of entry could be used to describe a prefix from of 0. This type of entry could be used to = describe a prefix from
a non-LISP = site, which is explicitly not in the mapping database. a non-LISP site, which is explicitly not in the = mapping database.
There are a = set of well-defined actions that are encoded in a There are a set of well-defined actions that are = encoded in a
Negative = Map-Reply. Negative = Map-Reply.
=
Data-Probe: A Data-Probe is a LISP-encapsulated data = packet where Provider-Assigned (PA) Addresses: PA addresses are = an address block
the inner-header destination address equals the = outer-header assigned to a site by each service = provider to which a site
destination address used to trigger a = Map-Reply by a = decapsulating connects. Typically, each block is a sub-block of a service
ETR. In addition, the original packet is = decapsulated and provider Classless Inter-Domain Routing (CIDR) = [RFC4632] block and
delivered to the = destination host if the destination EID is in the = is aggregated = into the larger block before being = advertised into
EID-Prefix range configured on the ETR. = Otherwise, the packet is the underlay network. Traditionally, IP = multihoming has been
discarded. A Data-Probe is used in some of the = mapping database implemented by each = multihomed site acquiring its own globally
designs to "probe" or request a Map-Reply from an ETR; in other = visible = prefix.
cases, Map-Requests are used. See each mapping = database design
for details. When using Data-Probes, by sending = Map-Requests on
the underlying routing system, EID-Prefixes must = be advertised.
However, this is discouraged if the core = is to scale by having =
less EID-Prefixes stored in the core router's = routing tables.
=
Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. = A Provider-Independent (PI) Addresses: PI addresses are = an address
PITR acts like an ITR but does so on behalf of = non-LISP sites that block assigned from a pool where blocks are not = associated with
send packets to destinations at LISP = sites. = any particular location in the network (e.g., from a = particular
= service = provider) and are therefore not = topologically aggregatable
= in the routing = system.
=
Proxy-ETR = (PETR): A PETR is defined and described in [RFC6832]. A = Proxy-ETR (PETR): A PETR is defined and = described in [RFC6832]. A
PETR acts = like an ETR but does so on behalf of LISP sites that PETR acts like an ETR but does so on behalf of = LISP sites that
send = packets to destinations at non-LISP sites. send packets to destinations at non-LISP = sites.
=
Route-returnability: Route-returnability is an = assumption that the Proxy-ITR (PITR): A PITR is defined and described in = [RFC6832]. A
= PITR acts like an = ITR but does so on behalf of non-LISP sites that
= send packets to = destinations at LISP sites.
=
= Recursive Tunneling: = Recursive Tunneling occurs when a packet has
= more than one = LISP IP header. Additional layers of tunneling MAY
= be employed to = implement Traffic Engineering or other re-routing
= as needed. When = this is done, an additional "outer" LISP header
= is added, and the = original RLOCs are preserved in the "inner"
= = header.
=
= Re-Encapsulating = Tunneling Router (RTR): An RTR acts like an ETR to
= remove a LISP = header, then acts as an ITR to prepend a new LISP
= header. This is = known as Re-encapsulating Tunneling. Doing this
= allows a packet = to be re-routed by the RTR without adding the
= overhead of = additional tunnel headers. Any references to tunnels
= in this = specification refer to dynamic encapsulating tunnels; = they
= are never = statically configured. When using multiple mapping
= database systems, = care must be taken to not create re-
= encapsulation = loops through misconfiguration.
=
= = Route-Returnability: Route-returnability is an assumption that = the
underlying = routing system will deliver packets to the destination. = underlying routing system will deliver = packets to the destination.
When = combined with a nonce that is provided by a sender and When combined with a nonce that is provided by a = sender and
returned by = a receiver, this limits off-path data insertion. A returned by a receiver, this limits off-path data = insertion. A
= route-returnability check is verified when a message is sent = with route-returnability check = is verified when a message is sent with
a nonce, = another message is returned with the same nonce, and the = a nonce, another message is returned with = the same nonce, and the
destination = of the original message appears as the source of the destination of the original message appears as the = source of the
returned = message. returned = message.
=
LISP site: LISP site is a = set of routers in an edge network that are Routing Locator (RLOC): An = RLOC is an IPv4 [RFC0791] or = IPv6
under a single technical administration. LISP = routers that reside = [RFC8200] = address of an Egress Tunnel Router (ETR). = An RLOC is
in the edge network are the demarcation points to separate the the output of an = EID-to-RLOC mapping lookup. An EID maps to one
edge network from the core = network. = or more RLOCs. Typically, RLOCs are numbered from aggregatable
blocks that are assigned to a site at each point to which = it
Client-side: Client-side is a term used in this document to = indicate = attaches to the underlay network; = where the topology is defined by
a connection initiation attempt by an EID. The ITR(s) at the LISP = the connectivity of provider networks. Multiple = RLOCs can be
site are the first to get involved in = obtaining database Map-Cache assigned to the = same ETR device or to multiple ETR devices at a
entries by sending Map-Request = messages. site.
=
Server-side: = Server-side is a term used in this document to indicate = Server-side: Server-side is a term used in = this document to indicate
that a = connection initiation attempt is being accepted for a that a connection initiation attempt is being = accepted for a
= destination EID. The ETR(s) at the destination = LISP site may be = destination EID.
the first to send Map-Replies to the source site = initiating the
connection. The ETR(s) at this destination site = can obtain
mappings by gleaning information from = Map-Requests, Data-Probes,
or encapsulated packets.
=
Locator-Status-Bits (LSBs): Locator-Status-Bits are = present in the TE-ETR: A TE-ETR is an ETR = that is deployed in a service = provider
LISP header. They are used by ITRs to inform = ETRs about the up/ network that strips an outer LISP header for = Traffic Engineering
down status of all ETRs at the local site. These = bits are used as purposes.
a hint to convey up/down router status and not path = reachability
status. The LSBs can be verified by use of one = of the Locator
reachability algorithms described in Section = 10.
=
Anycast Address: Anycast Address is a term used in this = document to TE-ITR: A TE-ITR is an = ITR that is deployed in a service = provider
refer to the same IPv4 or = IPv6 address configured and used on network that prepends an additional LISP header = for Traffic
multiple systems at the same time. An EID or RLOC can be an Engineering purposes.
anycast address in each of their own address = spaces.
= xTR: An xTR is a = reference to an ITR or ETR when direction = of data
= flow is not part = of the context description. "xTR" refers to the
= router that is = the tunnel endpoint and is used = synonymously with
= the term "Tunnel = Router". For example, "An xTR can be located at
= the Customer Edge = (CE) router" indicates both ITR and ETR
= functionality at = the CE router.
=
4. Basic = Overview 4. Basic Overview
=
One key = concept of LISP is that end-systems operate the same way they = One key concept of LISP is that end-systems = operate the same way they
do today. The = IP addresses that hosts use for tracking sockets and do today. The IP addresses that hosts use for = tracking sockets and
connections, = and for sending and receiving packets, do not change. connections, and for sending and receiving packets, = do not change.
In LISP = terminology, these IP addresses are called Endpoint In LISP terminology, these IP addresses are called = Endpoint
Identifiers = (EIDs). Identifiers (EIDs).
=
Routers = continue to forward packets based on IP destination Routers continue to forward packets based on IP = destination
=
skipping to = change at = page 10, line 38 =C2=B6 = skipping to change at page 10, line = 15 =C2=B6
o Other types = of EID are supported by LISP, see [RFC8060] for o Other types of EID are supported by LISP, see = [RFC8060] for
further = information. further = information.
=
o LISP = routers mostly deal with Routing Locator addresses. See = o LISP routers mostly deal with Routing = Locator addresses. See
details in = Section 4.1 to clarify what is meant by "mostly". details in Section 4.1 to clarify what is meant by = "mostly".
=
o RLOCs are = always IP addresses assigned to routers, preferably o RLOCs are always IP addresses assigned to routers, = preferably
= topologically oriented addresses from provider CIDR (Classless = topologically oriented addresses from = provider CIDR (Classless
= Inter-Domain Routing) blocks. = Inter-Domain Routing) blocks.
=
o When a = router originates packets, it may use as a = source address o When a router = originates packets, it MAY use as a source = address
either an = EID or RLOC. When acting as a host (e.g., when either an EID or RLOC. When acting as a host = (e.g., when
terminating = a transport session such as Secure SHell (SSH), terminating a transport session such as Secure = SHell (SSH),
TELNET, = or the Simple Network Management Protocol (SNMP)), it may = TELNET, or the Simple Network Management Protocol (SNMP)), it MAY
use an EID = that is explicitly assigned for that purpose. An EID use an EID that is explicitly assigned for that = purpose. An EID
that = identifies the router as a host MUST NOT be used as an RLOC; = that identifies the router as a host MUST = NOT be used as an RLOC;
an EID is = only routable within the scope of a site. A typical BGP = an EID is only routable within the scope = of a site. A typical BGP
= configuration might demonstrate this "hybrid" EID/RLOC usage = where configuration might = demonstrate this "hybrid" EID/RLOC usage where
a router = could use its "host-like" EID to terminate iBGP sessions = a router could use its "host-like" EID to = terminate iBGP sessions
to other = routers in a site while at the same time using RLOCs to = to other routers in a site while at the = same time using RLOCs to
terminate = eBGP sessions to routers outside the site. terminate eBGP sessions to routers outside the = site.
=
o Packets = with EIDs in them are not expected to be delivered end-to- = o Packets with EIDs in them are not = expected to be delivered end-to-
end in the = absence of an EID-to-RLOC mapping operation. They are end in the absence of an EID-to-RLOC mapping = operation. They are
expected to = be used locally for intra-site communication or to be expected to be used locally for intra-site = communication or to be
= encapsulated for inter-site communication. encapsulated for inter-site communication.
=
o = EID-Prefixes are likely to be hierarchically assigned in a = manner o EID-Prefixes are likely = to be hierarchically assigned in a manner
that is = optimized for administrative convenience and to facilitate = that is optimized for administrative = convenience and to facilitate
scaling = of the EID-to-RLOC mapping database. The = hierarchy is scaling of = the EID-to-RLOC mapping database.
based on an address allocation hierarchy that is = independent of
the network topology.
=
o EIDs = may also be structured (subnetted) in a = manner suitable for o EIDs MAY also be structured (subnetted) in a manner = suitable for
local = routing within an Autonomous System (AS). local routing within an Autonomous System = (AS).
=
An additional = LISP header MAY be prepended to packets by a TE-ITR An additional LISP header MAY be prepended to packets = by a TE-ITR
when = re-routing of the path for a packet is desired. A potential = when re-routing of the path for a packet is = desired. A potential
use-case for = this would be an ISP router that needs to perform use-case for this would be an ISP router that needs = to perform
Traffic = Engineering for packets flowing through its network. In such = Traffic Engineering for packets flowing = through its network. In such
a situation, = termed "Recursive Tunneling", an ISP transit acts as an = a situation, termed "Recursive Tunneling", = an ISP transit acts as an
additional = ITR, and the RLOC it uses for the new prepended header additional ITR, and the RLOC it uses for the new = prepended header
would be = either a TE-ETR within the ISP (along an intra-ISP traffic = would be either a TE-ETR within the ISP = (along an intra-ISP traffic
engineered = path) or a TE-ETR within another ISP (an inter-ISP traffic = engineered path) or a TE-ETR within another = ISP (an inter-ISP traffic
=
skipping to = change at = page 12, line 17 =C2=B6 = skipping to change at page 11, line = 37 =C2=B6
was not = using LISP. was not using = LISP.
=
o Each site = is multihomed, so each Tunnel Router has an address o Each site is multihomed, so each Tunnel Router has = an address
(RLOC) = assigned from the service provider address block for each = (RLOC) assigned from the service provider = address block for each
provider to = which that particular Tunnel Router is attached. provider to which that particular Tunnel Router is = attached.
=
o The ITR(s) = and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to = the source and
= destination, respectively, but the source and destination can = be destination, respectively, = but the source and destination can be
located = anywhere in the LISP site. = located anywhere in the LISP site.
=
o Map-Requests are sent to the mapping database system by = using the o A Map-Request = is sent for an external destination when the
LISP control-plane protocol documented = in destination is not = found in the forwarding table or matches a
[I-D.ietf-lisp-rfc6833bis]. A Map-Request = is sent for an external default = route. Map-Requests are sent to the mapping = database
= destination when the destination is not found in the forwarding = system by using = the LISP control-plane protocol documented in
table or = matches a default route. [I-D.ietf-lisp-rfc6833bis].
=
o Map-Replies = are sent on the underlying routing system topology o Map-Replies are sent on the underlying routing = system topology
using the = [I-D.ietf-lisp-rfc6833bis] control-plane protocol. using the [I-D.ietf-lisp-rfc6833bis] control-plane = protocol.
=
Client = host1.abc.example.com wants to communicate with server Client host1.abc.example.com wants to communicate = with server
= host2.xyz.example.com: = host2.xyz.example.com:
=
1. = host1.abc.example.com wants to open a TCP connection to = 1. host1.abc.example.com wants to open a = TCP connection to
= host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup = on
= host2.xyz.example.com. An A/AAAA record is returned. This = host2.xyz.example.com. An A/AAAA record = is returned. This
=
skipping to = change at = page 13, line 35 =C2=B6 = skipping to change at page 13, line 8 =C2=B6
of the = addresses, strips the LISP header, and forwards packets to = of the addresses, strips the LISP = header, and forwards packets to
the = attached destination host. the = attached destination host.
=
9. In order = to defer the need for a mapping lookup in the reverse 9. In order to defer the need for a mapping lookup = in the reverse
direction, = an ETR can OPTIONALLY create a cache entry that maps direction, an ETR can OPTIONALLY create a cache = entry that maps
the source = EID (inner-header source IP address) to the source the source EID (inner-header source IP address) = to the source
RLOC = (outer-header source IP address) in a received LISP packet. = RLOC (outer-header source IP address) in = a received LISP packet.
Such a = cache entry is termed a "gleaned" mapping and only Such a cache entry is termed a "gleaned" mapping = and only
contains a = single RLOC for the EID in question. More complete contains a single RLOC for the EID in question. = More complete
= information about additional RLOCs SHOULD be verified by = sending information about = additional RLOCs SHOULD be verified by sending
a LISP = Map-Request for that EID. Both the ITR and the ETR may a = LISP Map-Request for that EID. Both the ITR and the ETR MAY
also = influence the decision the other makes in selecting an RLOC. = also influence the decision the other = makes in selecting an RLOC.
=
5. LISP = Encapsulation Details 5. LISP = Encapsulation Details
=
Since = additional tunnel headers are prepended, the packet becomes = Since additional tunnel headers are = prepended, the packet becomes
larger and can = exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed = from the ITR to
the ETR. It = is RECOMMENDED in IPv4 that packets do not get the ETR. It is RECOMMENDED in IPv4 that packets do = not get
fragmented as = they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. = Instead, the packet
is dropped and = an ICMP Unreachable/Fragmentation-Needed message is is dropped and an ICMP = Unreachable/Fragmentation-Needed message is
returned to = the source. returned to the = source.
=
This specification RECOMMENDS that = implementations provide support = In the case when fragmentation is needed, = this specification
for one of = the proposed fragmentation and reassembly schemes. Two = RECOMMENDS that implementations provide = support for one of the
existing = schemes are detailed in Section 7. = proposed fragmentation and reassembly schemes. Two existing = schemes
= are detailed in Section 7.
=
Since IPv4 or = IPv6 addresses can be either EIDs or RLOCs, the LISP Since IPv4 or IPv6 addresses can be either EIDs or = RLOCs, the LISP
architecture = supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs = (where the inner
header is in = IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header = is in IPv6
packet format) = or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where = the inner header
is in IPv6 = packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in = IPv4 packet
format). The = next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet = formats for the
homogeneous = case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but = all 4
combinations = MUST be supported. Additional types of EIDs are defined = combinations MUST be supported. Additional = types of EIDs are defined
in = [RFC8060]. in [RFC8060].
=
skipping to = change at = page 14, line 16 =C2=B6 = skipping to change at page 14, line 4 =C2=B6
architecture = supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs = (where the inner
header is in = IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header = is in IPv6
packet format) = or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where = the inner header
is in IPv6 = packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in = IPv4 packet
format). The = next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet = formats for the
homogeneous = case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but = all 4
combinations = MUST be supported. Additional types of EIDs are defined = combinations MUST be supported. Additional = types of EIDs are defined
in = [RFC8060]. in [RFC8060].
=
5.1. LISP = IPv4-in-IPv4 Header Format 5.1. LISP = IPv4-in-IPv4 Header Format
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| IHL |Type of Service| = Total Length | / = |Version| IHL | DSCP |ECN| = Total Length |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Identification |Flags| Fragment Offset | = | | Identification |Flags| = Fragment Offset |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to = Live | Protocol =3D 17 | Header Checksum | = OH | Time to Live | Protocol =3D 17 | = Header Checksum |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Source Routing Locator | | | Source Routing Locator = |
\ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = Destination Routing Locator | \ | Destination Routing Locator = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port =3D xxxx | Dest Port =3D 4341 | = / | Source Port =3D xxxx | = Dest Port =3D 4341 |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L = |N|L|E|V|I|R|K|K| Nonce/Map-Version = | L |N|L|E|V|I|R|K|K| = Nonce/Map-Version |
I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | = Instance ID/Locator-Status-Bits | S / | Instance ID/Locator-Status-Bits = |
P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| IHL |Type of Service| = Total Length | / = |Version| IHL | DSCP |ECN| = Total Length |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Identification |Flags| Fragment Offset | = | | Identification |Flags| = Fragment Offset |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to = Live | Protocol | Header Checksum | IH | Time to Live | Protocol | Header = Checksum |
| = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Source EID | | | Source EID = |
\ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = Destination EID | \ | Destination EID = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
IHL =3D = IP-Header-Length IHL =3D = IP-Header-Length
=
5.2. LISP = IPv6-in-IPv6 Header Format 5.2. LISP = IPv6-in-IPv6 Header Format
=
0 = 1 2 3 0 1 2 = 3
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 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
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| Traffic Class | Flow = Label | / = |Version| DSCP |ECN| Flow = Label |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | = Payload Length | Next Header=3D17| Hop Limit | = | | Payload Length | Next = Header=3D17| Hop Limit |
v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
O + = + O + = +
u | = | u | = |
t + = Source Routing Locator + t + Source Routing Locator = +
e | = | e | = |
r + = + r + = +
| = | | = |
=
skipping to = change at = page 15, line 38 =C2=B6 = skipping to change at page 15, line = 23 =C2=B6
\ | = | \ | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Source Port =3D xxxx | Dest Port =3D 4341 | = / | Source Port =3D xxxx | = Dest Port =3D 4341 |
UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= UDP = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | = UDP Length | UDP Checksum | \ | UDP Length | UDP = Checksum |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L = |N|L|E|V|I|R|K|K| Nonce/Map-Version = | L |N|L|E|V|I|R|K|K| = Nonce/Map-Version |
I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= I \ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | = Instance ID/Locator-Status-Bits | S / | Instance ID/Locator-Status-Bits = |
P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= P = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ = |Version| Traffic Class | Flow = Label | / = |Version| DSCP |ECN| Flow = Label |
/ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= / = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | = Payload Length | Next Header | Hop Limit | = / | Payload Length | Next = Header | Hop Limit |
v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= v = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = | | = |
I + = + I + = +
n | = | n | = |
n + = Source EID + n + Source EID = +
e | = | e | = |
r + = + r + = +
| = | | = |
=
skipping = to change at page 16, line = 4 =C2=B6 = skipping to change at page 15, line = 38 =C2=B6
I + = + I + = +
n | = | n | = |
n + = Source EID + n + Source EID = +
e | = | e | = |
r + = + r + = +
| = | | = |
H = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= H = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | = | d | = |
r + = + r + = +
| = | | = |
=
^ + = Destination EID + ^ + Destination EID = +
\ | = | \ | = |
\ + = + \ + = +
\ | = | \ | = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
5.3. Tunnel = Header Field Descriptions 5.3. Tunnel = Header Field Descriptions
=
Inner Header = (IH): The inner header is the header on the datagram Inner Header (IH): The inner header is = the header on the
received = from the originating host. The source and = destination IP datagram = received from the originating host [RFC0791] = [RFC8200]
addresses = are EIDs [RFC0791] [RFC8200]. = [RFC2474]. = The source and destination IP addresses are EIDs.
=
Outer Header: = (OH) The outer header is a new header prepended by an Outer Header: (OH) The outer header is a new header = prepended by an
ITR. The = address fields contain RLOCs obtained from the ingress ITR. The address fields contain RLOCs obtained = from the ingress
router's = EID-to-RLOC Cache. The IP protocol number is "UDP (17)" = router's EID-to-RLOC Cache. The IP = protocol number is "UDP (17)"
from = [RFC0768]. The setting of the Don't Fragment (DF) bit from [RFC0768]. The setting of the Don't Fragment = (DF) bit
'Flags' = field is according to rules listed in Sections 7.1 and 'Flags' field is according to rules listed in = Sections 7.1 and
= 7.2. 7.2.
=
UDP Header: = The UDP header contains an ITR selected source port when = UDP Header: The UDP header contains an ITR = selected source port when
= encapsulating a packet. See Section 12 for details on the hash = encapsulating a packet. See Section 12 = for details on the hash
algorithm = used to select a source port based on the 5-tuple of the = algorithm used to select a source port = based on the 5-tuple of the
inner = header. The destination port MUST be set to the well-known = inner header. The destination port MUST = be set to the well-known
= IANA-assigned port value 4341. = IANA-assigned port value 4341.
=
UDP Checksum: = The 'UDP Checksum' field SHOULD be transmitted as zero UDP Checksum: The 'UDP Checksum' field SHOULD be = transmitted as zero
by an ITR = for either IPv4 [RFC0768] or IPv6 = encapsulation by an ITR for = either IPv4 [RFC0768] and IPv6 = encapsulation
[RFC6935] = [RFC6936]. When a packet with a zero UDP checksum is [RFC6935] [RFC6936]. When a packet with a zero = UDP checksum is
received by = an ETR, the ETR MUST accept the packet for received by an ETR, the ETR MUST accept the packet = for
= decapsulation. When an ITR transmits a non-zero value for the = UDP decapsulation. When an ITR = transmits a non-zero value for the UDP
checksum, = it MUST send a correctly computed value in this field. checksum, it MUST send a correctly computed value = in this field.
When an ETR = receives a packet with a non-zero UDP checksum, it MAY When an ETR receives a packet with a non-zero UDP = checksum, it MAY
choose to = verify the checksum value. If it chooses to perform choose to verify the checksum value. If it = chooses to perform
such = verification, and the verification fails, the packet MUST be = such verification, and the verification = fails, the packet MUST be
silently = dropped. If the ETR chooses not to perform the silently dropped. If the ETR chooses not to = perform the
= verification, or performs the verification successfully, the = verification, or performs the = verification successfully, the
packet MUST = be accepted for decapsulation. The handling of UDP packet MUST be accepted for decapsulation. The = handling of UDP
=
skipping = to change at page 19, line = 43 =C2=B6 = skipping to change at page 19, line = 27 =C2=B6
Copying the = Time to Live (TTL) serves two purposes: first, it Copying the Time to Live (TTL) serves two purposes: = first, it
preserves the = distance the host intended the packet to travel; preserves the distance the host intended the packet = to travel;
second, and = more importantly, it provides for suppression of looping = second, and more importantly, it provides = for suppression of looping
packets in the = event there is a loop of concatenated tunnels due to packets in the event there is a loop of concatenated = tunnels due to
= misconfiguration. See Section 18.3 for TTL exception handling = for misconfiguration. See Section = 18.3 for TTL exception handling for
traceroute = packets. traceroute = packets.
=
The Explicit = Congestion Notification ('ECN') field occupies bits 6 The Explicit Congestion Notification ('ECN') field = occupies bits 6
and 7 of both = the IPv4 'Type of Service' field and the IPv6 'Traffic and 7 of both the IPv4 'Type of Service' field and = the IPv6 'Traffic
Class' field = [RFC3168]. The 'ECN' field requires special treatment Class' field [RFC3168]. The 'ECN' field requires = special treatment
in order to = avoid discarding indications of congestion [RFC3168]. in order to avoid discarding indications of = congestion [RFC3168]. An
ITR encapsulation MUST copy the 2-bit 'ECN' = field from the inner ITR/PITR encapsulation MUST copy the 2-bit = 'ECN' field from the inner
header to the = outer header. Re-encapsulation MUST copy the 2-bit header to the outer header. Re-encapsulation MUST = copy the 2-bit
'ECN' field = from the stripped outer header to the new outer header. = 'ECN' field from the stripped outer header = to the new outer header.
If the 'ECN' = field contains a congestion indication codepoint (the If the 'ECN' field contains a congestion indication = codepoint (the
value is = '11', the Congestion Experienced (CE) codepoint), then ETR value = is '11', the Congestion Experienced (CE) codepoint), then ETR/
= decapsulation MUST copy the 2-bit 'ECN' field from the stripped = outer = PETR decapsulation MUST copy the 2-bit 'ECN' field from the = stripped
header to = the surviving inner header that is used to forward the outer header to the surviving inner header that is = used to forward
packet = beyond the ETR. These requirements preserve CE indications = the packet beyond the ETR. These = requirements preserve CE
when a = packet that uses ECN traverses a LISP tunnel and becomes = indications when a packet that uses ECN = traverses a LISP tunnel and
marked with = a CE indication due to congestion between the tunnel becomes marked with a CE indication due to = congestion between the
= endpoints. tunnel = endpoints.
=
6. LISP = EID-to-RLOC Map-Cache 6. LISP = EID-to-RLOC Map-Cache
=
ITRs and PITRs = maintain an on-demand cache, referred as LISP EID-to- ITRs and PITRs maintain an on-demand cache, referred = as LISP EID-to-
RLOC = Map-Cache, that contains mappings from EID-prefixes to locator = RLOC Map-Cache, that contains mappings from = EID-prefixes to locator
sets. The = cache is used to encapsulate packets from the EID space to = sets. The cache is used to encapsulate = packets from the EID space to
the = corresponding RLOC network attachment point. the corresponding RLOC network attachment = point.
=
When an = ITR/PITR receives a packet from inside of the LISP site to = When an ITR/PITR receives a packet from = inside of the LISP site to
destinations = outside of the site a longest-prefix match lookup of the = destinations outside of the site a = longest-prefix match lookup of the
=
skipping = to change at page 20, line = 40 =C2=B6 = skipping to change at page 20, line = 27 =C2=B6
information = about EIDs and RLOCs, and uses LISP reachability information about EIDs and RLOCs, and uses LISP = reachability
information = mechanisms to determine the reachability of RLOCs, see information mechanisms to determine the reachability = of RLOCs, see
Section 10 for = the specific mechanisms. Section 10 = for the specific mechanisms.
=
7. Dealing with = Large Encapsulated Packets 7. Dealing = with Large Encapsulated Packets
=
This section = proposes two mechanisms to deal with packets that exceed = This section proposes two mechanisms to deal = with packets that exceed
the path MTU = between the ITR and ETR. the path = MTU between the ITR and ETR.
=
It is left to = the implementor to decide if the stateless or stateful It is left to the implementor to decide if the = stateless or stateful
mechanism = should be implemented. Both or neither = can be used, since mechanism SHOULD be implemented. Both or neither can be = used, since
it is a local = decision in the ITR regarding how to deal with MTU it is a local decision in the ITR regarding how to = deal with MTU
issues, and = sites can interoperate with differing mechanisms. issues, and sites can interoperate with differing = mechanisms.
=
Both stateless = and stateful mechanisms also apply to Re-encapsulating Both stateless and stateful mechanisms also apply to = Re-encapsulating
and Recursive = Tunneling, so any actions below referring to an ITR and Recursive Tunneling, so any actions below = referring to an ITR
also apply to = a TE-ITR. also apply to a = TE-ITR.
=
7.1. A Stateless = Solution to MTU Handling 7.1. A = Stateless Solution to MTU Handling
=
An ITR = stateless solution to handle MTU issues is described as = An ITR stateless solution to handle MTU = issues is described as
=
skipping = to change at page 21, line = 19 =C2=B6 = skipping to change at page 20, line = 49 =C2=B6
=
1. Define H = to be the size, in octets, of the outer header an ITR 1. Define H to be the size, in octets, of the outer = header an ITR
prepends = to a packet. This includes the UDP and LISP header prepends to a packet. This includes the UDP and = LISP header
= lengths. lengths.
=
2. Define L = to be the size, in octets, of the maximum-sized packet 2. Define L to be the size, in octets, of the = maximum-sized packet
an ITR can = send to an ETR without the need for the ITR or any an ITR can send to an ETR without the need for = the ITR or any
= intermediate routers to fragment the packet. intermediate routers to fragment the = packet.
=
3. Define an = architectural constant S for the maximum size of a 3. Define an architectural constant S for the = maximum size of a
packet, = in octets, an ITR must receive from the = source so the packet, in = octets, an ITR MUST receive from the = source so the
effective = MTU can be met. That is, L =3D S + H. = effective MTU can be met. That is, L =3D S + H.
=
When an ITR = receives a packet from a site-facing interface and adds H = When an ITR receives a packet from a = site-facing interface and adds H
octets worth = of encapsulation to yield a packet size greater than L octets worth of encapsulation to yield a packet size = greater than L
octets = (meaning the received packet size was greater than S octets = octets (meaning the received packet size was = greater than S octets
from the = source), it resolves the MTU issue by first splitting the = from the source), it resolves the MTU issue = by first splitting the
original = packet into 2 equal-sized fragments. A LISP header is then = original packet into 2 equal-sized = fragments. A LISP header is then
prepended to = each fragment. The size of the encapsulated fragments prepended to each fragment. The size of the = encapsulated fragments
is then (S/2 + = H), which is less than the ITR's estimate of the path is then (S/2 + H), which is less than the ITR's = estimate of the path
MTU between = the ITR and its correspondent ETR. = MTU between the ITR and its correspondent ETR.
=
skipping = to change at page 23, line = 14 =C2=B6 = skipping to change at page 22, line = 43 =C2=B6
=
When an ETR = decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID = from the LISP
header is used = as a table identifier to locate the forwarding table header is used as a table identifier to locate the = forwarding table
to use for the = inner destination EID lookup. to = use for the inner destination EID lookup.
=
For example, = an 802.1Q VLAN tag or VPN identifier could be used as a = For example, an 802.1Q VLAN tag or VPN = identifier could be used as a
24-bit = Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case = 24-bit Instance ID. See [I-D.ietf-lisp-vpn] = for LISP VPN use-case
= details. details.
=
The Instance = ID that is stored in the mapping database when LISP-DDT = The Instance ID that is stored in the = mapping database when LISP-DDT
[I-D.ietf-lisp-ddt] is used is 32 bits in = length. That means the [RFC8111] is used is 32 bits in length. That = means the control-plane
= control-plane can store more instances than a given data-plane = can can store more instances than = a given data-plane can use. Multiple
use. = Multiple data-planes can use the same 32-bit space as long as = data-planes can use the same 32-bit space = as long as the low-order 24
the = low-order 24 bits don't overlap among xTRs. bits don't overlap among xTRs.
=
9. Routing = Locator Selection 9. Routing Locator = Selection
=
Both the = client-side and server-side may need = control over the Both the = client-side and server-side MAY need = control over the
selection of = RLOCs for conversations between them. This control is selection of RLOCs for conversations between them. = This control is
achieved by = manipulating the 'Priority' and 'Weight' fields in EID- = achieved by manipulating the 'Priority' and = 'Weight' fields in EID-
to-RLOC = Map-Reply messages. Alternatively, RLOC information MAY be = to-RLOC Map-Reply messages. Alternatively, = RLOC information MAY be
gleaned from = received tunneled packets or EID-to-RLOC Map-Request gleaned from received tunneled packets or EID-to-RLOC = Map-Request
= messages. messages.
=
The following = are different scenarios for choosing RLOCs and the The following are different scenarios for choosing = RLOCs and the
controls that = are available: controls that are = available:
=
o The = server-side returns one RLOC. The client-side can only use = o The server-side returns one RLOC. The = client-side can only use
=
skipping = to change at page 24, line = 48 =C2=B6 = skipping to change at page 24, line = 34 =C2=B6
stored in the = mapping database system provides reachability stored in the mapping database system provides = reachability
information = for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not = part of the
mapping system = and is determined using one or more of the Routing mapping system and is determined using one or more of = the Routing
Locator = reachability algorithms described in the next section. Locator reachability algorithms described in the next = section.
=
10. Routing = Locator Reachability 10. Routing = Locator Reachability
=
Several = mechanisms for determining RLOC reachability are currently = Several mechanisms for determining RLOC = reachability are currently
= defined: defined:
=
1. An ETR = may examine the Locator-Status-Bits in the = LISP header of 1. An ETR MAY examine the Locator-Status-Bits in the LISP = header of
an = encapsulated data packet received from an ITR. If the ETR is = an encapsulated data packet received = from an ITR. If the ETR is
also = acting as an ITR and has traffic to return to the original = also acting as an ITR and has traffic to = return to the original
ITR site, = it can use this status information to help select an ITR site, it can use this status information to = help select an
= RLOC. RLOC.
=
2. An ITR = may receive an ICMP Network Unreachable or = Host 2. An ITR MAY receive an ICMP Network Unreachable or = Host
= Unreachable message for an RLOC it is using. This indicates = that Unreachable message for an = RLOC it is using. This indicates that
the RLOC = is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP = messages may
not be = desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them = completely.
= Implementations are encouraged to follow current best practices = Implementations are encouraged to follow = current best practices
in = treating these conditions. in = treating these conditions.
=
3. An ITR = that participates in the global routing system can 3. An ITR that participates in the global routing = system can
determine = that an RLOC is down if no BGP Routing Information Base = determine that an RLOC is down if no BGP = Routing Information Base
(RIB) = route exists that matches the RLOC IP address. (RIB) route exists that matches the RLOC IP = address.
=
4. An ITR = may receive an ICMP Port Unreachable = message from a 4. An ITR MAY receive an ICMP Port Unreachable message = from a
= destination host. This occurs if an ITR attempts to use = destination host. This occurs if an ITR = attempts to use
= interworking [RFC6832] and LISP-encapsulated data is sent to a = interworking [RFC6832] and = LISP-encapsulated data is sent to a
= non-LISP-capable site. = non-LISP-capable site.
=
5. An ITR = may receive a Map-Reply from an ETR in = response to a 5. An ITR MAY receive a Map-Reply from an ETR in response = to a
previously = sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of = the Map-Reply is
likely up, = since the ETR was able to send the Map-Reply to the likely up, since the ETR was able to send the = Map-Reply to the
= ITR. ITR.
=
6. When an = ETR receives an encapsulated packet from an ITR, the 6. When an ETR receives an encapsulated packet from = an ITR, the
source = RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet = is likely up.
=
7. An ITR/ETR = pair can use the Locator reachability algorithms 7. An ITR/ETR pair can use the Locator reachability = algorithms
described = in this section, namely Echo-Noncing or RLOC-Probing. described in this section, namely Echo-Noncing or = RLOC-Probing.
=
=
skipping = to change at page 26, line = 17 =C2=B6 = skipping to change at page 26, line = 6 =C2=B6
=
When an ETR = decapsulates a packet, it will check for any change in When an ETR decapsulates a packet, it will check for = any change in
the = 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the = the 'Locator-Status-Bits' field. When a bit = goes from 1 to 0, the
ETR, if acting = also as an ITR, will refrain from encapsulating ETR, if acting also as an ITR, will refrain from = encapsulating
packets to an = RLOC that is indicated as down. It will only resume packets to an RLOC that is indicated as down. It = will only resume
using that = RLOC if the corresponding Locator-Status-Bit returns to a = using that RLOC if the corresponding = Locator-Status-Bit returns to a
value of 1. = Locator-Status-Bits are associated with a Locator-Set value of 1. Locator-Status-Bits are associated with = a Locator-Set
per = EID-Prefix. Therefore, when a Locator becomes unreachable, the = per EID-Prefix. Therefore, when a Locator = becomes unreachable, the
= Locator-Status-Bit that corresponds to that Locator's position in = the Locator-Status-Bit that = corresponds to that Locator's position in the
list returned = by the last Map-Reply will be set to zero for that list returned by the last Map-Reply will be set to = zero for that
particular = EID-Prefix. particular EID-Prefix. = Refer to Section 19 for security = related
= issues regarding = Locator-Status-Bits.
=
When ITRs at = the site are not deployed in CE routers, the IGP can When ITRs at the site are not deployed in CE routers, = the IGP can
still be used = to determine the reachability of Locators, provided still be used to determine the reachability of = Locators, provided
they are = injected into the IGP. This is typically done when a /32 = they are injected into the IGP. This is = typically done when a /32
address is = configured on a loopback interface. = address is configured on a loopback interface.
=
When ITRs = receive ICMP Network Unreachable or Host Unreachable When ITRs receive ICMP Network Unreachable or Host = Unreachable
messages as a = method to determine unreachability, they will refrain messages as a method to determine unreachability, = they will refrain
from using = Locators that are described in Locator lists of Map- from using Locators that are described in Locator = lists of Map-
Replies. = However, using this approach is unreliable because many = Replies. However, using this approach is = unreliable because many
=
skipping = to change at page 27, line = 45 =C2=B6 = skipping to change at page 27, line = 36 =C2=B6
E-bit cleared. = The ITR sees this "echoed nonce" and knows that the E-bit cleared. The ITR sees this "echoed nonce" and = knows that the
path to and = from the ETR is up. path to and = from the ETR is up.
=
The ITR will = set the E-bit and N-bit for every packet it sends while = The ITR will set the E-bit and N-bit for = every packet it sends while
in the = echo-nonce-request state. The time the ITR waits to process = in the echo-nonce-request state. The time = the ITR waits to process
the echoed = nonce before it determines the path is unreachable is the echoed nonce before it determines the path is = unreachable is
variable and = is a choice left for the implementation. variable and is a choice left for the = implementation.
=
If the ITR is = receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does = not see the
nonce echoed = while being in the echo-nonce-request state, then the nonce echoed while being in the echo-nonce-request = state, then the
path to the = ETR is unreachable. This decision may be = overridden by path to the ETR is = unreachable. This decision MAY be = overridden by
other Locator = reachability algorithms. Once the ITR determines that other Locator reachability algorithms. Once the ITR = determines that
the path to = the ETR is down, it can switch to another Locator for the path to the ETR is down, it can switch to another = Locator for
that = EID-Prefix. that = EID-Prefix.
=
Note that = "ITR" and "ETR" are relative terms here. Both devices MUST = Note that "ITR" and "ETR" are relative terms = here. Both devices MUST
be = implementing both ITR and ETR functionality for the echo nonce = be implementing both ITR and ETR = functionality for the echo nonce
mechanism to = operate. mechanism to = operate.
=
The ITR and = ETR may both go into the = echo-nonce-request state at the = The ITR and ETR MAY both go into the = echo-nonce-request state at the
same time. = The number of packets sent or the time during which echo = same time. The number of packets sent or = the time during which echo
nonce requests = are sent is an implementation-specific setting. nonce requests are sent is an implementation-specific = setting.
However, when = an ITR is in the echo-nonce-request state, it can echo However, when an ITR is in the echo-nonce-request = state, it can echo
the ETR's = nonce in the next set of packets that it encapsulates and = the ETR's nonce in the next set of packets = that it encapsulates and
subsequently = continue sending echo-nonce-request packets. subsequently continue sending echo-nonce-request = packets.
=
This mechanism = does not completely solve the forward path This mechanism does not completely solve the forward = path
reachability = problem, as traffic may be unidirectional. That is, the = reachability problem, as traffic may be = unidirectional. That is, the
ETR = receiving traffic at a site may not be the = same device as an ITR ETR = receiving traffic at a site MAY not be the = same device as an ITR
that transmits = traffic from that site, or the site-to-site traffic is that transmits traffic from that site, or the = site-to-site traffic is
unidirectional = so there is no ITR returning traffic. = unidirectional so there is no ITR returning traffic.
=
The echo-nonce = algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if = one side sets the
E-bit and the = other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for = echo-noncing, then the
echoing of the = nonce does not occur and the requesting side may echoing of the nonce does not occur and the = requesting side may
erroneously = consider the Locator unreachable. An ITR SHOULD only set = erroneously consider the Locator = unreachable. An ITR SHOULD only set
the E-bit in = an encapsulated data packet when it knows the ETR is the E-bit in an encapsulated data packet when it = knows the ETR is
enabled for = echo-noncing. This is conveyed by the E-bit in the RLOC- = enabled for echo-noncing. This is conveyed = by the E-bit in the RLOC-
probe = Map-Reply message. probe Map-Reply = message.
=
Note that other Locator reachability mechanisms are= being researched Note = other Locator Reachability mechanisms can = be used to compliment
and can be used to compliment or even = override the echo nonce or even = override the echo nonce algorithm. See the next section for
algorithm. = See the next section for an example of control-plane an example of control-plane probing.
= probing.
=
10.2. = RLOC-Probing Algorithm 10.2. = RLOC-Probing Algorithm
=
RLOC-Probing = is a method that an ITR or PITR can use to determine the = RLOC-Probing is a method that an ITR or PITR = can use to determine the
reachability = status of one or more Locators that it has cached in a reachability status of one or more Locators that it = has cached in a
Map-Cache = entry. The probe-bit of the Map-Request and Map-Reply Map-Cache entry. The probe-bit of the Map-Request = and Map-Reply
messages is = used for RLOC-Probing. messages is = used for RLOC-Probing.
=
RLOC-Probing = is done in the control plane on a timer basis, where an = RLOC-Probing is done in the control plane on = a timer basis, where an
ITR or PITR = will originate a Map-Request destined to a locator ITR or PITR will originate a Map-Request destined to = a locator
address from = one of its own locator addresses. A Map-Request used as = address from one of its own locator = addresses. A Map-Request used as
an RLOC-probe = is NOT encapsulated and NOT sent to a Map-Server or to an RLOC-probe is NOT encapsulated and NOT sent to a = Map-Server or to
the mapping = database system as one would when soliciting mapping the mapping database system as one would when = soliciting mapping
data. The EID = record encoded in the Map-Request is the EID-Prefix of data. The EID record encoded in the Map-Request is = the EID-Prefix of
the = Map-Cache entry cached by the ITR or PITR. The ITR may include a = the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a
mapping data = record for its own database mapping information that mapping data record for its own database mapping = information that
contains the = local EID-Prefixes and RLOCs for its site. RLOC-probes = contains the local EID-Prefixes and RLOCs = for its site. RLOC-probes
are sent = periodically using a jittered timer interval. are sent periodically using a jittered timer = interval.
=
When an ETR = receives a Map-Request message with the probe-bit set, it = When an ETR receives a Map-Request message = with the probe-bit set, it
returns a = Map-Reply with the probe-bit set. The source address of = returns a Map-Reply with the probe-bit set. = The source address of
the Map-Reply = is set according to the procedure described in the Map-Reply is set according to the procedure = described in
= [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain = mapping [I-D.ietf-lisp-rfc6833bis]. = The Map-Reply SHOULD contain mapping
data for the = EID-Prefix contained in the Map-Request. This provides = data for the EID-Prefix contained in the = Map-Request. This provides
the = opportunity for the ITR or PITR that sent the RLOC-probe to get = the opportunity for the ITR or PITR that = sent the RLOC-probe to get
=
skipping = to change at page 29, line = 27 =C2=B6 = skipping to change at page 29, line = 14 =C2=B6
reachable or = has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a = robust
mechanism for = switching to using another Locator from the cached mechanism for switching to using another Locator from = the cached
Locator. = RLOC-Probing can also provide rough Round-Trip Time (RTT) = Locator. RLOC-Probing can also provide = rough Round-Trip Time (RTT)
estimates = between a pair of Locators, which can be useful for network = estimates between a pair of Locators, which = can be useful for network
management = purposes as well as for selecting low delay paths. The = management purposes as well as for selecting = low delay paths. The
major = disadvantage of RLOC-Probing is in the number of control = major disadvantage of RLOC-Probing is in the = number of control
messages = required and the amount of bandwidth used to obtain those = messages required and the amount of = bandwidth used to obtain those
benefits, = especially if the requirement for failure detection times = benefits, especially if the requirement for = failure detection times
is very = small. is very small.
=
Continued research and testing will attempt to = characterize the
tradeoffs of failure detection times versus message = overhead.
= =
11. EID = Reachability within a LISP Site 11. = EID Reachability within a LISP Site
=
A site may be multihomed using two or more ETRs. The = hosts and A site MAY be multihomed using two or more ETRs. The = hosts and
infrastructure = within a site will be addressed using one or more EID- infrastructure within a site will be addressed using = one or more EID-
Prefixes that = are mapped to the RLOCs of the relevant ETRs in the Prefixes that are mapped to the RLOCs of the relevant = ETRs in the
mapping = system. One possible failure mode is for an ETR to lose = mapping system. One possible failure mode = is for an ETR to lose
reachability = to one or more of the EID-Prefixes within its own site. = reachability to one or more of the = EID-Prefixes within its own site.
When this = occurs when the ETR sends Map-Replies, it can clear the = When this occurs when the ETR sends = Map-Replies, it can clear the
R-bit = associated with its own Locator. And when the ETR is also an = R-bit associated with its own Locator. And = when the ETR is also an
ITR, it can = clear its Locator-Status-Bit in the encapsulation data ITR, it can clear its Locator-Status-Bit in the = encapsulation data
= header. header.
=
It is = recognized that there are no simple solutions to the site = It is recognized that there are no simple = solutions to the site
partitioning = problem because it is hard to know which part of the partitioning problem because it is hard to know which = part of the
EID-Prefix = range is partitioned and which Locators can reach any sub- = EID-Prefix range is partitioned and which = Locators can reach any sub-
ranges of = the EID-Prefixes. This problem is under = investigation with ranges = of the EID-Prefixes. Note that this is not a new problem
the expectation that experiments will tell us = more. Note that this = introduced by the LISP architecture. The problem exists today when = a
is not a new = problem introduced by the LISP architecture. The multihomed site uses BGP to advertise its = reachability upstream.
problem = exists today when a multihomed site uses BGP to advertise its =
reachability = upstream.
=
12. Routing = Locator Hashing 12. Routing Locator = Hashing
=
When an ETR = provides an EID-to-RLOC mapping in a Map-Reply message to When an = ETR provides an EID-to-RLOC mapping in a Map-Reply message
a requesting = ITR, the Locator-Set for the EID-Prefix may = contain that = is stored in the map-cache of a requesting ITR, the = Locator-Set
different = Priority values for each locator address. When more than = for the EID-Prefix MAY contain different Priority and Weight values
one best = Priority Locator exists, the ITR can decide how to load- for = each locator address. When more than one best Priority Locator
share traffic against the corresponding = Locators. exists, the ITR can = decide how to load-share traffic against = the
= corresponding Locators.
=
The = following hash algorithm may be used by an = ITR to select a The following hash = algorithm MAY be used by an ITR to select = a
Locator for a = packet destined to an EID for the EID-to-RLOC mapping: Locator for a packet destined to an EID for the = EID-to-RLOC mapping:
=
1. Either a = source and destination address hash or the traditional 1. Either a source and destination address hash or = the traditional
5-tuple = hash can be used. The traditional 5-tuple hash includes = 5-tuple hash can be used. The = traditional 5-tuple hash includes
the source = and destination addresses; source and destination TCP, the source and destination addresses; source and = destination TCP,
UDP, or = Stream Control Transmission Protocol (SCTP) port numbers; = UDP, or Stream Control Transmission = Protocol (SCTP) port numbers;
and the IP = protocol number field or IPv6 next-protocol fields of and the IP protocol number field or IPv6 = next-protocol fields of
a packet = that a host originates from within a LISP site. When a = a packet that a host originates from = within a LISP site. When a
packet is = not a TCP, UDP, or SCTP packet, the source and packet is not a TCP, UDP, or SCTP packet, the = source and
= destination addresses only from the header are used to compute = destination addresses only from the = header are used to compute
=
skipping = to change at page 34, line = 6 =C2=B6 = skipping to change at page 33, line = 30 =C2=B6
Replies. To = avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a = third party, a
sender of an = SMR-based Map-Request MUST be verified. If an ITR sender of an SMR-based Map-Request MUST be verified. = If an ITR
receives an = SMR-based Map-Request and the source is not in the receives an SMR-based Map-Request and the source is = not in the
Locator-Set = for the stored Map-Cache entry, then the responding Map- = Locator-Set for the stored Map-Cache entry, = then the responding Map-
Request MUST = be sent with an EID destination to the mapping database = Request MUST be sent with an EID destination = to the mapping database
system. Since = the mapping database system is a more secure way to system. Since the mapping database system is a more = secure way to
reach an = authoritative ETR, it will deliver the Map-Request to the = reach an authoritative ETR, it will deliver = the Map-Request to the
authoritative = source of the mapping data. = authoritative source of the mapping data.
=
When an ITR = receives an SMR-based Map-Request for which it does not = When an ITR receives an SMR-based = Map-Request for which it does not
have a = cached mapping for the EID in the SMR message, it MAY not send = have a cached mapping for the EID in the SMR message, it may not send
an SMR-invoked = Map-Request. This scenario can occur when an ETR an SMR-invoked Map-Request. This scenario can occur = when an ETR
sends SMR = messages to all Locators in the Locator-Set it has stored = sends SMR messages to all Locators in the = Locator-Set it has stored
in its = map-cache but the remote ITRs that receive the SMR may not be = in its map-cache but the remote ITRs that = receive the SMR may not be
sending = packets to the site. There is no point in updating the ITRs = sending packets to the site. There is no = point in updating the ITRs
until they = need to send, in which case they will send Map-Requests to = until they need to send, in which case they = will send Map-Requests to
obtain a = Map-Cache entry. obtain a Map-Cache = entry.
=
13.3. Database = Map-Versioning 13.3. Database = Map-Versioning
=
When there is = unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an = ITR and ETR, and
=
skipping = to change at page 35, line = 52 =C2=B6 = skipping to change at page 35, line = 26 =C2=B6
few = implementation techniques can be used to incrementally = implement few implementation = techniques can be used to incrementally implement
LISP: = LISP:
=
o When a = tunnel-encapsulated packet is received by an ETR, the outer = o When a tunnel-encapsulated packet is = received by an ETR, the outer
destination = address may not be the address of the router. This destination address may not be the address of the = router. This
makes it = challenging for the control plane to get packets from the = makes it challenging for the control = plane to get packets from the
hardware. = This may be mitigated by creating special Forwarding hardware. This may be mitigated by creating = special Forwarding
Information = Base (FIB) entries for the EID-Prefixes of EIDs served Information Base (FIB) entries for the = EID-Prefixes of EIDs served
by the ETR = (those for which the router provides an RLOC by the ETR (those for which the router provides an = RLOC
= translation). These FIB entries are marked with a flag = indicating translation). These = FIB entries are marked with a flag indicating
that = control-plane processing should be = performed. The forwarding that = control-plane processing SHOULD be = performed. The forwarding
logic of = testing for particular IP protocol number values is not = logic of testing for particular IP = protocol number values is not
necessary. = There are a few proven cases where no changes to necessary. There are a few proven cases where no = changes to
existing = deployed hardware were needed to support the LISP data- = existing deployed hardware were needed to = support the LISP data-
= plane. plane.
=
o On an ITR, = prepending a new IP header consists of adding more o On an ITR, prepending a new IP header consists of = adding more
octets to a = MAC rewrite string and prepending the string as part octets to a MAC rewrite string and prepending the = string as part
of the = outgoing encapsulation procedure. Routers that support = of the outgoing encapsulation procedure. = Routers that support
Generic = Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 = Generic Routing Encapsulation (GRE) = tunneling [RFC2784] or 6to4
tunneling = [RFC3056] may already support this action. tunneling [RFC3056] may already support this = action.
=
skipping = to change at page 38, line = 15 =C2=B6 = skipping to change at page 37, line = 40 =C2=B6
17. LISP xTR = Placement and Encapsulation Methods 17. = LISP xTR Placement and Encapsulation Methods
=
This section = will explore how and where ITRs and ETRs can be placed This section will explore how and where ITRs and ETRs = can be placed
in the network = and will discuss the pros and cons of each scenario. in the network and will discuss the pros and cons of = each scenario.
For a more = detailed networkd design deployment recommendation, refer = For a more detailed networkd design = deployment recommendation, refer
to = [RFC7215]. to [RFC7215].
=
There are two = basic deployment tradeoffs to consider: centralized There are two basic deployment tradeoffs to consider: = centralized
versus = distributed caches; and flat, Recursive, or Re-encapsulating = versus distributed caches; and flat, = Recursive, or Re-encapsulating
Tunneling. = When deciding on centralized versus distributed caching, = Tunneling. When deciding on centralized = versus distributed caching,
the = following issues should be = considered: the following issues = SHOULD be considered:
=
o Are the = xTRs spread out so that the caches are spread across all = o Are the xTRs spread out so that the = caches are spread across all
the = memories of each router? A centralized cache is when an ITR = the memories of each router? A = centralized cache is when an ITR
keeps a = cache for all the EIDs it is encapsulating to. The packet = keeps a cache for all the EIDs it is = encapsulating to. The packet
takes a = direct path to the destination Locator. A distributed takes a direct path to the destination Locator. A = distributed
cache is = when an ITR needs help from other Re-Encapsulating Tunnel = cache is when an ITR needs help from = other Re-Encapsulating Tunnel
Routers = (RTRs) because it does not store all the cache entries for = Routers (RTRs) because it does not store = all the cache entries for
the EIDs it = is encapsulating to. So, the packet takes a path the EIDs it is encapsulating to. So, the packet = takes a path
through = RTRs that have a different set of cache entries. through RTRs that have a different set of cache = entries.
=
o Should = management "touch points" be minimized by only choosing a = o Should management "touch points" be = minimized by only choosing a
few xTRs, = just enough for redundancy? few = xTRs, just enough for redundancy?
=
o In general, = using more ITRs doesn't increase management load, o In general, using more ITRs doesn't increase = management load,
since = caches are built and stored dynamically. On the other hand, = since caches are built and stored = dynamically. On the other hand,
using more = ETRs does require more management, since EID-Prefix-to- = using more ETRs does require more = management, since EID-Prefix-to-
RLOC = mappings need to be explicitly configured. RLOC mappings need to be explicitly = configured.
=
When deciding = on flat, Recursive, or Re-Encapsulating Tunneling, the When deciding on flat, Recursive, or Re-Encapsulating = Tunneling, the
following = issues should be considered: = following issues SHOULD be considered:
=
o Flat = tunneling implements a single encapsulation path between the = o Flat tunneling implements a single = encapsulation path between the
source site = and destination site. This generally offers better source site and destination site. This generally = offers better
paths = between sources and destinations with a single encapsulation = paths between sources and destinations = with a single encapsulation
= path. path.
=
o Recursive = Tunneling is when encapsulated traffic is again further = o Recursive Tunneling is when encapsulated = traffic is again further
= encapsulated in another tunnel, either to implement VPNs or to = encapsulated in another tunnel, either to = implement VPNs or to
perform = Traffic Engineering. When doing VPN-based tunneling, the = perform Traffic Engineering. When doing = VPN-based tunneling, the
site has = some control, since the site is prepending a new site has some control, since the site is = prepending a new
= encapsulation header. In the case of TE-based tunneling, the = site encapsulation header. In = the case of TE-based tunneling, the site
may have control if it is prepending a new = tunnel header, but if MAY have control if it is prepending a new = tunnel header, but if
the site's = ISP is doing the TE, then the site has no control. the site's ISP is doing the TE, then the site has = no control.
Recursive = Tunneling generally will result in suboptimal paths but = Recursive Tunneling generally will result = in suboptimal paths but
with the = benefit of steering traffic to parts of the network that = with the benefit of steering traffic to = parts of the network that
have more = resources available. have more = resources available.
=
o The = technique of Re-Encapsulation ensures that packets only = o The technique of Re-Encapsulation ensures = that packets only
require one = encapsulation header. So, if a packet needs to be re- require one encapsulation header. So, if a packet = needs to be re-
routed, it = is first decapsulated by the RTR and then Re- routed, it is first decapsulated by the RTR and = then Re-
= Encapsulated with a new encapsulation header using a new RLOC. = Encapsulated with a new encapsulation = header using a new RLOC.
=
=
skipping = to change at page 41, line = 12 =C2=B6 = skipping to change at page 40, line = 36 =C2=B6
addresses MUST = be used only in the outer IP header so the NAT device addresses MUST be used only in the outer IP header so = the NAT device
can translate = properly. Otherwise, EID addresses MUST be translated can translate properly. Otherwise, EID addresses = MUST be translated
before = encapsulation is performed when LISP VPNs are not in use. = before encapsulation is performed when LISP = VPNs are not in use.
Both NAT = translation and LISP encapsulation functions could be co- = Both NAT translation and LISP encapsulation = functions could be co-
located in the = same device. located in the same = device.
=
17.5. Packets = Egressing a LISP Site 17.5. Packets = Egressing a LISP Site
=
When a LISP = site is using two ITRs for redundancy, the failure of one = When a LISP site is using two ITRs for = redundancy, the failure of one
ITR will = likely shift outbound traffic to the second. This second = ITR will likely shift outbound traffic to = the second. This second
ITR's cache = may not be populated with the same = EID-to-RLOC mapping ITR's cache = MAY not be populated with the same = EID-to-RLOC mapping
entries as the = first. If this second ITR does not have these entries as the first. If this second ITR does not = have these
mappings, = traffic will be dropped while the mappings are retrieved = mappings, traffic will be dropped while the = mappings are retrieved
from the = mapping system. The retrieval of these messages may from the mapping system. The retrieval of these = messages may
increase the = load of requests being sent into the mapping system. increase the load of requests being sent into the = mapping system.
=
18. Traceroute = Considerations 18. Traceroute = Considerations
=
When a source = host in a LISP site initiates a traceroute to a When a source host in a LISP site initiates a = traceroute to a
destination = host in another LISP site, it is highly desirable for it = destination host in another LISP site, it is = highly desirable for it
to see the = entire path. Since packets are encapsulated from the ITR = to see the entire path. Since packets are = encapsulated from the ITR
=
skipping = to change at page 44, line = 16 =C2=B6 = skipping to change at page 43, line = 42 =C2=B6
=
Map-Versioning = is a data-plane mechanism used to signal a peering xTR Map-Versioning is a data-plane mechanism used to = signal a peering xTR
that a local = EID-to-RLOC mapping has been updated, so that the that a local EID-to-RLOC mapping has been updated, so = that the
peering xTR = uses LISP Control-Plane signaling message to retrieve a = peering xTR uses LISP Control-Plane = signaling message to retrieve a
fresh mapping. = This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to = forge the map-
versioning = field of a LISP encapsulated header and force an excessive = versioning field of a LISP encapsulated = header and force an excessive
amount of = signaling between xTRs that may overload them. amount of signaling between xTRs that may overload = them.
=
Most of the = attack vectors can be mitigated with careful deployment = Most of the attack vectors can be mitigated = with careful deployment
and = configuration, information learned opportunistically (such as = LSB and configuration, information = learned opportunistically (such as LSB
or gleaning) = should be verified with other reachability = mechanisms. or gleaning) SHOULD be verified with other reachability = mechanisms.
In addition, = systematic rate-limitation and filtering is an effective = In addition, systematic rate-limitation and = filtering is an effective
technique to = mitigate attacks that aim to overload the control-plane. = technique to mitigate attacks that aim to = overload the control-plane.
=
20. Network = Management Considerations 20. Network = Management Considerations
=
Considerations = for network management tools exist so the LISP Considerations for network management tools exist so = the LISP
protocol suite = can be operationally managed. These mechanisms can be protocol suite can be operationally managed. These = mechanisms can be
found in = [RFC7052] and [RFC6835]. found in = [RFC7052] and [RFC6835].
=
21. IANA = Considerations 21. IANA = Considerations
=
This section = provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet = Assigned Numbers
Authority = (IANA) regarding registration of values related to this = Authority (IANA) regarding registration of = values related to this
data-plane = LISP specification, in accordance with BCP 26 [RFC5226]. = data-plane LISP specification, in accordance with BCP 26 [RFC8126].
=
21.1. LISP UDP = Port Numbers 21.1. LISP UDP Port = Numbers
=
The IANA = registry has allocated UDP port numbers 4341 and 4342 for = The IANA registry has allocated UDP port = numbers 4341 and 4342 for
lisp-data and = lisp-control operation, respectively. IANA has updated = lisp-data and lisp-control operation, = respectively. IANA has updated
the = description for UDP ports 4341 and 4342 as follows: the description for UDP ports 4341 and 4342 as = follows:
=
lisp-data = 4341 udp LISP Data Packets = lisp-data 4341 udp LISP Data Packets
= lisp-control 4342 udp LISP Control Packets lisp-control 4342 udp LISP Control = Packets
=
22. = References 22. References
=
22.1. Normative = References 22.1. Normative = References
=
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
Smirnov, "LISP Delegated Database Tree", = draft-ietf-lisp-
ddt-09 (work in progress), January = 2017.
[I-D.ietf-lisp-introduction] =
Cabellos-Aparicio, A. and D. Saucez, "An = Architectural
Introduction to the Locator/ID Separation = Protocol
(LISP)", draft-ietf-lisp-introduction-13 = (work in
progress), April 2015. =
= =
= [I-D.ietf-lisp-rfc6833bis] = [I-D.ietf-lisp-rfc6833bis]
= Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. = Cabellos-Aparicio,
= "Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) = Control-Plane",
= draft-ietf-lisp-rfc6833bis-06 (work in progress), = October = draft-ietf-lisp-rfc6833bis-07 (work in progress), = December
= 2017. 2017.
=
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., = Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", = draft-ietf-lisp-sec-14
(work in progress), October = 2017.
= =
[RFC0768] = Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD = 6, RFC 768,
DOI = 10.17487/RFC0768, August 1980, = DOI 10.17487/RFC0768, August 1980,
= <https://www.rfc-editor.org/info/rfc768>. = <https://www.rfc-editor.org/info/rfc768>.
=
[RFC0791] = Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, = RFC 791,
DOI = 10.17487/RFC0791, September 1981, = DOI 10.17487/RFC0791, September 1981,
= <https://www.rfc-editor.org/info/rfc791>. = <https://www.rfc-editor.org/info/rfc791>.
=
[RFC1918] = Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., = [RFC1918] Rekhter, Y., Moskowitz, B., = Karrenberg, D., de Groot, G.,
and = E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for = Private Internets",
BCP = 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, = February 1996,
= <https://www.rfc-editor.org/info/rfc1918>. = <https://www.rfc-editor.org/info/rfc1918>.
=
[RFC2119] = Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate
= Requirement Levels", BCP 14, RFC 2119, = Requirement Levels", BCP 14, RFC 2119,
DOI = 10.17487/RFC2119, March 1997, = DOI 10.17487/RFC2119, March 1997,
= <https://www.rfc-editor.org/info/rfc2119>. = <https://www.rfc-editor.org/info/rfc2119>.
=
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2474] Nichols, K., = Blake, S., Baker, F., and D. = Black,
ESP and AH", RFC 2404, DOI = 10.17487/RFC2404, November = = "Definition of the Differentiated Services = Field (DS
= 1998, <https://www.rfc-editor.org/info/rfc2404>. = Field) in the IPv4 and IPv6 = Headers", RFC 2474,
= DOI 10.17487/RFC2474, December 1998,
= <https://www.rfc-editor.org/info/rfc2474>.
=
[RFC3168] = Ramakrishnan, K., Floyd, S., and D. Black, "The Addition = [RFC3168] Ramakrishnan, K., Floyd, S., and = D. Black, "The Addition
of = Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) = to IP",
RFC = 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September = 2001,
= <https://www.rfc-editor.org/info/rfc3168>. = <https://www.rfc-editor.org/info/rfc3168>.
=
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC = 1700 is Replaced
by an On-line Database", RFC 3232, DOI = 10.17487/RFC3232,
January 2002, = <https://www.rfc-editor.org/info/rfc3232>. =
= =
[RFC4086] = Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. = Crocker,
= "Randomness Requirements for Security", BCP 106, RFC 4086, = "Randomness Requirements for = Security", BCP 106, RFC 4086,
DOI = 10.17487/RFC4086, June 2005, = DOI 10.17487/RFC4086, June 2005,
= <https://www.rfc-editor.org/info/rfc4086>. = <https://www.rfc-editor.org/info/rfc4086>.
=
[RFC4632] = Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless = Inter-domain Routing
= (CIDR): The Internet Address Assignment and Aggregation = (CIDR): The Internet Address = Assignment and Aggregation
= Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI = 10.17487/RFC4632, August
= 2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, = <https://www.rfc-editor.org/info/rfc4632>.
=
[RFC4868] Kelly, S. and S. Frankel, "Using = HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC = 4868,
DOI 10.17487/RFC4868, May = 2007,
= <https://www.rfc-editor.org/info/rfc4868>. =
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines = for Writing an
IANA Considerations Section in RFCs", RFC = 5226,
DOI 10.17487/RFC5226, May = 2008,
= <https://www.rfc-editor.org/info/rfc5226>. =
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, = "The Reverse Path
Forwarding (RPF) Vector TLV", RFC = 5496,
DOI 10.17487/RFC5496, March = 2009,
= <https://www.rfc-editor.org/info/rfc5496>. =
= =
[RFC5944] = Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", = [RFC5944] Perkins, C., Ed., "IP Mobility = Support for IPv4, Revised",
RFC = 5944, DOI 10.17487/RFC5944, November 2010, RFC 5944, DOI 10.17487/RFC5944, November = 2010,
= <https://www.rfc-editor.org/info/rfc5944>. = <https://www.rfc-editor.org/info/rfc5944>.
=
[RFC6115] Li, T., Ed., "Recommendation for a Routing = Architecture",
RFC 6115, DOI 10.17487/RFC6115, February = 2011,
= <https://www.rfc-editor.org/info/rfc6115>. =
= =
[RFC6275] = Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. = Arkko, "Mobility
= Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI = 10.17487/RFC6275, July
= 2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, = <https://www.rfc-editor.org/info/rfc6275>.
=
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, = "Locator/ID
Separation Protocol (LISP) = Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January = 2013,
= <https://www.rfc-editor.org/info/rfc6834>. =
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and = D. Lewis,
"Locator/ID Separation Protocol = Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI = 10.17487/RFC6836,
January 2013, = <https://www.rfc-editor.org/info/rfc6836>. =
[RFC7052] Schudel, G., Jain, A., and V. Moreno, = "Locator/ID
Separation Protocol (LISP) MIB", RFC = 7052,
DOI 10.17487/RFC7052, October = 2013,
= <https://www.rfc-editor.org/info/rfc7052>. =
[RFC7214] Andersson, L. and C. Pignataro, "Moving = Generic Associated
Channel (G-ACh) IANA Registries to a New = Registry",
RFC 7214, DOI 10.17487/RFC7214, May = 2014,
= <https://www.rfc-editor.org/info/rfc7214>. =
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, = F., Domingo-
Pascual, J., and D. Lewis, = "Locator/Identifier Separation
Protocol (LISP) Network Element = Deployment
Considerations", RFC 7215, DOI = 10.17487/RFC7215, April
2014, = <https://www.rfc-editor.org/info/rfc7215>. =
= =
[RFC7833] = Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A [RFC7833] Howlett, J., Hartman, S., and A. = Perez-Mendez, Ed., "A
= RADIUS Attribute, Binding, Profiles, Name Identifier RADIUS Attribute, Binding, Profiles, Name = Identifier
= Format, and Confirmation Methods for the Security Format, and Confirmation Methods for the = Security
= Assertion Markup Language (SAML)", RFC 7833, Assertion Markup Language (SAML)", RFC = 7833,
DOI = 10.17487/RFC7833, May 2016, = DOI 10.17487/RFC7833, May 2016,
= <https://www.rfc-editor.org/info/rfc7833>. = <https://www.rfc-editor.org/info/rfc7833>.
=
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC8126] Cotton, M., Leiba, = B., and T. Narten, "Guidelines = for
Separation Protocol (LISP) Threat = Analysis", RFC 7835, = Writing = an IANA Considerations Section in RFCs", BCP 26,
= DOI 10.17487/RFC7835, April 2016, = RFC 8126, DOI 10.17487/RFC8126,= June 2017,
= <https://www.rfc-editor.org/info/rfc7835>. = <https://www.rfc-editor.org/info/rfc8126>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID = Separation Protocol
(LISP) Data-Plane Confidentiality", RFC = 8061,
DOI 10.17487/RFC8061, February = 2017,
= <https://www.rfc-editor.org/info/rfc8061>.
=
[RFC8200] = Deering, S. and R. Hinden, "Internet Protocol, Version 6 = [RFC8200] Deering, S. and R. Hinden, = "Internet Protocol, Version 6
= (IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC = 8200,
DOI = 10.17487/RFC8200, July 2017, = DOI 10.17487/RFC8200, July 2017,
= <https://www.rfc-editor.org/info/rfc8200>. = <https://www.rfc-editor.org/info/rfc8200>.
=
22.2. = Informative References 22.2. = Informative References
=
[AFN] = IANA, "Address Family Numbers", August 2016, [AFN] IANA, "Address Family Numbers", August = 2016,
= <http://www.iana.org/assignments/address-family-numbers>. = = <http://www.iana.org/assignments/address-family-numbers>.
=
[CHIAPPA] = Chiappa, J., "Endpoints and Endpoint names: A Proposed", = [CHIAPPA] Chiappa, J., "Endpoints and = Endpoint names: A Proposed",
= 1999, 1999,
= <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. = = <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
=
= [I-D.ietf-lisp-eid-mobility] = [I-D.ietf-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-ietf-lisp-eid-mobility-00 = Unified Control Plane", draft-ietf-lisp-eid-mobility-01
= (work in progress), May 2017. = (work in progress), November 2017.
= =
= [I-D.ietf-lisp-introduction]
= = Cabellos-Aparicio, A. and D. Saucez, "An Architectural
= = Introduction to the Locator/ID Separation Protocol
= (LISP)", = draft-ietf-lisp-introduction-13 (work in
= = progress), April 2015.
=
= [I-D.ietf-lisp-mn] = [I-D.ietf-lisp-mn]
= Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP = Farinacci, D., Lewis, D., Meyer, = D., and C. White, "LISP
= Mobile Node", draft-ietf-lisp-mn-01 (work in progress), = Mobile Node", = draft-ietf-lisp-mn-01 (work in progress),
= October 2017. October = 2017.
=
= [I-D.ietf-lisp-predictive-rlocs] = [I-D.ietf-lisp-predictive-rlocs]
= Farinacci, D. and P. Pillay-Esnault, "LISP Predictive Farinacci, D. and P. Pillay-Esnault, "LISP = Predictive
= RLOCs", draft-ietf-lisp-predictive-rlocs-00 = (work in RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work = in
= progress), June 2017. progress), November = 2017.
=
= = [I-D.ietf-lisp-sec]
= Maino, = F., Ermagan, V., Cabellos-Aparicio, A., and D.
= Saucez, = "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
= (work in = progress), October 2017.
=
= [I-D.ietf-lisp-signal-free-multicast] = [I-D.ietf-lisp-signal-free-multicast]
= Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", = Moreno, V. and D. Farinacci, = "Signal-Free LISP Multicast",
= draft-ietf-lisp-signal-free-multicast-06 = (work in draft-ietf-lisp-signal-free-multicast-07 (work = in
= progress), August 2017. progress), November 2017.
=
= [I-D.ietf-lisp-vpn] = [I-D.ietf-lisp-vpn]
= Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual = Private
= Networks (VPNs)", draft-ietf-lisp-vpn-00 = (work in Networks = (VPNs)", draft-ietf-lisp-vpn-01 (work = in
= progress), May 2017. progress), November 2017.
=
= [I-D.meyer-loc-id-implications] = [I-D.meyer-loc-id-implications]
= Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural = Implications of
= Locator/ID Separation", draft-meyer-loc-id-implications-01 = Locator/ID Separation", = draft-meyer-loc-id-implications-01
= (work in progress), January 2009. = (work in progress), January 2009.
=
[LISA96] = Lear, E., Tharp, D., Katinsky, J., and J. Coffin, [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. = Coffin,
= "Renumbering: Threat or Menace?", Usenix Tenth System "Renumbering: Threat or Menace?", Usenix = Tenth System
= Administration Conference (LISA 96), October 1996. Administration Conference (LISA 96), = October 1996.
=
=
skipping = to change at page 49, line = 9 =C2=B6 = skipping to change at page 47, line = 22 =C2=B6
=
[RFC2784] = Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, = D., and P.
= Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, = Traina, "Generic Routing = Encapsulation (GRE)", RFC 2784,
DOI = 10.17487/RFC2784, March 2000, = DOI 10.17487/RFC2784, March 2000,
= <https://www.rfc-editor.org/info/rfc2784>. = <https://www.rfc-editor.org/info/rfc2784>.
=
[RFC3056] = Carpenter, B. and K. Moore, "Connection of IPv6 Domains = [RFC3056] Carpenter, B. and K. Moore, = "Connection of IPv6 Domains
via = IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February via IPv4 Clouds", RFC 3056, DOI = 10.17487/RFC3056, February
= 2001, <https://www.rfc-editor.org/info/rfc3056>. 2001, = <https://www.rfc-editor.org/info/rfc3056>.
=
= [RFC3232] Reynolds, = J., Ed., "Assigned Numbers: RFC 1700 is Replaced
= by an = On-line Database", RFC 3232, DOI 10.17487/RFC3232,
= January = 2002, <https://www.rfc-editor.org/info/rfc3232>.
= =
[RFC3261] = Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, = [RFC3261] Rosenberg, J., Schulzrinne, H., = Camarillo, G., Johnston,
A., = Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., = and E.
= Schooler, "SIP: Session Initiation Protocol", RFC 3261, = Schooler, "SIP: Session = Initiation Protocol", RFC 3261,
DOI = 10.17487/RFC3261, June 2002, = DOI 10.17487/RFC3261, June 2002,
= <https://www.rfc-editor.org/info/rfc3261>. = <https://www.rfc-editor.org/info/rfc3261>.
=
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for = Cryptographic
Key Management", BCP 107, RFC 4107, DOI = 10.17487/RFC4107,
June 2005, = <https://www.rfc-editor.org/info/rfc4107>. =
= =
[RFC4192] = Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, = "Procedures for
= Renumbering an IPv6 Network without a Flag Day", RFC 4192, = Renumbering an IPv6 Network = without a Flag Day", RFC 4192,
DOI = 10.17487/RFC4192, September 2005, = DOI 10.17487/RFC4192, September 2005,
= <https://www.rfc-editor.org/info/rfc4192>. = <https://www.rfc-editor.org/info/rfc4192>.
=
[RFC4866] = Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, = "Enhanced Route
= Optimization for Mobile IPv6", RFC 4866, Optimization for Mobile IPv6", RFC = 4866,
DOI = 10.17487/RFC4866, May 2007, = DOI 10.17487/RFC4866, May 2007,
= <https://www.rfc-editor.org/info/rfc4866>. = <https://www.rfc-editor.org/info/rfc4866>.
=
[RFC4984] = Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report = [RFC4984] Meyer, D., Ed., Zhang, L., Ed., = and K. Fall, Ed., "Report
= from the IAB Workshop on Routing and Addressing", from the IAB Workshop on Routing and = Addressing",
RFC = 4984, DOI 10.17487/RFC4984, September 2007, RFC 4984, DOI 10.17487/RFC4984, September = 2007,
= <https://www.rfc-editor.org/info/rfc4984>. = <https://www.rfc-editor.org/info/rfc4984>.
=
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure = to Support
Secure Internet Routing", RFC 6480, DOI = 10.17487/RFC6480,
February 2012, = <https://www.rfc-editor.org/info/rfc6480>. =
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and = Authentication for
Routing Protocols (KARP) Design = Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February = 2012,
= <https://www.rfc-editor.org/info/rfc6518>. =
= =
[RFC6831] = Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The = [RFC6831] Farinacci, D., Meyer, D., = Zwiebel, J., and S. Venaas, "The
= Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for = Multicast
= Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI = 10.17487/RFC6831, January
= 2013, <https://www.rfc-editor.org/info/rfc6831>. 2013, = <https://www.rfc-editor.org/info/rfc6831>.
=
[RFC6832] = Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and = V. Fuller,
= "Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID = Separation Protocol
= (LISP) and Non-LISP Sites", RFC 6832, = (LISP) and Non-LISP Sites", RFC 6832,
DOI = 10.17487/RFC6832, January 2013, = DOI 10.17487/RFC6832, January 2013,
= <https://www.rfc-editor.org/info/rfc6832>. = <https://www.rfc-editor.org/info/rfc6832>.
=
= [RFC6834] Iannone, = L., Saucez, D., and O. Bonaventure, "Locator/ID
= = Separation Protocol (LISP) Map-Versioning", RFC 6834,
= DOI = 10.17487/RFC6834, January 2013,
= = <https://www.rfc-editor.org/info/rfc6834>.
= =
[RFC6835] = Farinacci, D. and D. Meyer, "The Locator/ID Separation [RFC6835] Farinacci, D. and D. Meyer, "The = Locator/ID Separation
= Protocol Internet Groper (LIG)", RFC 6835, Protocol Internet Groper (LIG)", RFC = 6835,
DOI = 10.17487/RFC6835, January 2013, = DOI 10.17487/RFC6835, January 2013,
= <https://www.rfc-editor.org/info/rfc6835>. = <https://www.rfc-editor.org/info/rfc6835>.
=
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID = (EID) to
Routing Locator (RLOC) Database", RFC = 6837,
DOI 10.17487/RFC6837, January = 2013,
= <https://www.rfc-editor.org/info/rfc6837>. =
= =
[RFC6935] = Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and = [RFC6935] Eubanks, M., Chimento, P., and M. = Westerlund, "IPv6 and
UDP = Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC = 6935,
DOI = 10.17487/RFC6935, April 2013, = DOI 10.17487/RFC6935, April 2013,
= <https://www.rfc-editor.org/info/rfc6935>. = <https://www.rfc-editor.org/info/rfc6935>.
=
[RFC6936] = Fairhurst, G. and M. Westerlund, "Applicability Statement = [RFC6936] Fairhurst, G. and M. Westerlund, = "Applicability Statement
for = the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with = Zero Checksums",
RFC = 6936, DOI 10.17487/RFC6936, April 2013, = RFC 6936, DOI 10.17487/RFC6936, April 2013,
= <https://www.rfc-editor.org/info/rfc6936>. = <https://www.rfc-editor.org/info/rfc6936>.
=
= [RFC7052] Schudel, = G., Jain, A., and V. Moreno, "Locator/ID
= = Separation Protocol (LISP) MIB", RFC 7052,
= DOI = 10.17487/RFC7052, October 2013,
= = <https://www.rfc-editor.org/info/rfc7052>.
=
= [RFC7215] Jakab, = L., Cabellos-Aparicio, A., Coras, F., Domingo-
= Pascual, = J., and D. Lewis, "Locator/Identifier Separation
= Protocol = (LISP) Network Element Deployment
= = Considerations", RFC 7215, DOI 10.17487/RFC7215, April
= 2014, = <https://www.rfc-editor.org/info/rfc7215>.
=
= [RFC7835] Saucez, = D., Iannone, L., and O. Bonaventure, "Locator/ID
= = Separation Protocol (LISP) Threat Analysis", RFC 7835,
= DOI = 10.17487/RFC7835, April 2016,
= = <https://www.rfc-editor.org/info/rfc7835>.
= =
[RFC8060] = Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical = [RFC8060] Farinacci, D., Meyer, D., and J. = Snijders, "LISP Canonical
= Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, = Address Format (LCAF)", RFC 8060, = DOI 10.17487/RFC8060,
= February 2017, <https://www.rfc-editor.org/info/rfc8060>. = February 2017, = <https://www.rfc-editor.org/info/rfc8060>.
=
= [RFC8061] = Farinacci, D. and B. Weis, "Locator/ID Separation = Protocol
= (LISP) = Data-Plane Confidentiality", RFC 8061,
= DOI = 10.17487/RFC8061, February 2017,
= = <https://www.rfc-editor.org/info/rfc8061>.
=
= [RFC8111] Fuller, = V., Lewis, D., Ermagan, V., Jain, A., and A.
= Smirnov, = "Locator/ID Separation Protocol Delegated
= Database = Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
= May 2017, = <https://www.rfc-editor.org/info/rfc8111>.
= =
Appendix A. = Acknowledgments Appendix A. = Acknowledgments
=
An initial = thank you goes to Dave Oran for planting the seeds for the = An initial thank you goes to Dave Oran for = planting the seeds for the
initial ideas = for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues = to provide value
to the LISP = authors. to the LISP = authors.
=
A special and = appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel = Chiappa for
providing = architectural impetus over the past decades on separation = providing architectural impetus over the = past decades on separation
of location = and identity, as well as detailed reviews of the LISP of location and identity, as well as detailed reviews = of the LISP
architecture = and documents, coupled with enthusiasm for making LISP a = architecture and documents, coupled with = enthusiasm for making LISP a
=
skipping = to change at page 52, line = 5 =C2=B6 = skipping to change at page 51, line = 5 =C2=B6
The LISP = working group would like to give a special thanks to Jari = The LISP working group would like to give a = special thanks to Jari
Arkko, the = Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set = of LISP
documents were = being prepared for IESG last call, and for his documents were being prepared for IESG last call, and = for his
meticulous = reviews and detailed commentaries on the 7 working group = meticulous reviews and detailed commentaries = on the 7 working group
last call = documents progressing toward standards-track RFCs. last call documents progressing toward = standards-track RFCs.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-rfc6830bis-06 = B.1. Changes to draft-ietf-lisp-rfc6830bis-08
=
= o Posted December = 2017.
=
= o Remove references = to research work for any protocol mechanisms.
=
= o Document scanned = to make sure it is RFC 2119 compliant.
=
= o Made changes to = reflect comments from document WG shepherd Luigi
= = Iannone.
=
= o Ran IDNITs on the = document.
=
= B.2. Changes to = draft-ietf-lisp-rfc6830bis-07
=
o Posted = November 2017. o Posted November = 2017.
=
o Rephrase = how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer = to [RFC1918]
= addresses. addresses.
=
B.2. Changes to = draft-ietf-lisp-rfc6830bis-06 B.3. Changes to = draft-ietf-lisp-rfc6830bis-06
=
o Posted = October 2017. o Posted October = 2017.
=
o Put RTR = definition before it is used. o = Put RTR definition before it is used.
=
o Rename = references that are now working group drafts. o Rename references that are now working group = drafts.
=
o Remove = "EIDs MUST NOT be used as used by a host to refer to other = o Remove "EIDs MUST NOT be used as used by = a host to refer to other
hosts. = Note that EID blocks MAY LISP RLOCs". = hosts. Note that EID blocks MAY LISP RLOCs".
=
=
skipping = to change at page 52, line = 35 =C2=B6 = skipping to change at page 51, line = 48 =C2=B6
o ETRs may, = rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send = Map-Replies.
=
o Recommend, = rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation = headers to 2.
=
o Reference = VPN draft when introducing Instance-ID. = o Reference VPN draft when introducing Instance-ID.
=
o Indicate = that SMRs can be sent when ITR/ETR are in the same node. = o Indicate that SMRs can be sent when = ITR/ETR are in the same node.
=
o Clarify = when private addreses can be used. = o Clarify when private addreses can be used.
=
B.3. Changes to = draft-ietf-lisp-rfc6830bis-05 B.4. Changes to = draft-ietf-lisp-rfc6830bis-05
=
o Posted = August 2017. o Posted August = 2017.
=
o Make it = clear that a Reencapsulating Tunnel Router is an RTR. o Make it clear that a Reencapsulating Tunnel Router = is an RTR.
=
B.4. Changes to = draft-ietf-lisp-rfc6830bis-04 B.5. Changes to = draft-ietf-lisp-rfc6830bis-04
=
o Posted July = 2017. o Posted July 2017.
=
o Changed = reference of IPv6 RFC2460 to RFC8200. = o Changed reference of IPv6 RFC2460 to RFC8200.
=
o Indicate = that the applicability statement for UDP zero checksums = o Indicate that the applicability statement = for UDP zero checksums
over IPv6 = adheres to RFC6936. over IPv6 = adheres to RFC6936.
=
B.5. Changes to = draft-ietf-lisp-rfc6830bis-03 B.6. Changes to = draft-ietf-lisp-rfc6830bis-03
=
o Posted May = 2017. o Posted May 2017.
=
o Move the = control-plane related codepoints in the IANA o Move the control-plane related codepoints in the = IANA
= Considerations section to RFC6833bis. = Considerations section to RFC6833bis.
=
B.6. Changes to = draft-ietf-lisp-rfc6830bis-02 B.7. Changes to = draft-ietf-lisp-rfc6830bis-02
=
o Posted = April 2017. o Posted April = 2017.
=
o Reflect = some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien = Sausez.
=
B.7. Changes to = draft-ietf-lisp-rfc6830bis-01 B.8. Changes to = draft-ietf-lisp-rfc6830bis-01
=
o Posted = March 2017. o Posted March = 2017.
=
o Include = references to new RFCs published. o = Include references to new RFCs published.
=
o Change = references from RFC6833 to RFC6833bis. = o Change references from RFC6833 to RFC6833bis.
=
o Clarified = LCAF text in the IANA section. o = Clarified LCAF text in the IANA section.
=
o Remove = references to "experimental". o = Remove references to "experimental".
=
B.8. Changes to = draft-ietf-lisp-rfc6830bis-00 B.9. Changes to = draft-ietf-lisp-rfc6830bis-00
=
o Posted = December 2016. o Posted December = 2016.
=
o Created = working group document from draft-farinacci-lisp o Created working group document from = draft-farinacci-lisp
-rfc6830-00 = individual submission. No other changes made. -rfc6830-00 individual submission. No other = changes made.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = farinacci@gmail.com EMail: = farinacci@gmail.com
= =
Vince = Fuller Vince Fuller
Cisco = Systems Cisco Systems
Tasman = Drive Tasman Drive
San Jose, CA = 95134 San Jose, CA 95134
USA = USA
=
EMail: = vince.fuller@gmail.com EMail: = vince.fuller@gmail.com
=
Dave = Meyer Dave Meyer
Cisco = Systems Cisco Systems
 End of changes. 107 change = blocks. 
395 lines changed or = deleted 339 lines changed or = added

This = html diff was produced by rfcdiff 1.46. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_8C1A4519-7E43-41B9-9800-E4BFA031930D Content-Disposition: attachment; filename=draft-ietf-lisp-rfc6830bis-08.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-rfc6830bis-08.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer Expires: July 1, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech December 28, 2017 The Locator/ID Separation Protocol (LISP) draft-ietf-lisp-rfc6830bis-08 Abstract This document describes the data-plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 1, 2018. Farinacci, et al. Expires July 1, 2018 [Page 1] =0C Internet-Draft LISP December 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 11 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 13 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 15. Router Performance Considerations . . . . . . . . . . . . . . 35 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 35 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 Farinacci, et al. Expires July 1, 2018 [Page 2] =0C Internet-Draft LISP December 2017 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39 17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 40 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 43 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 50 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 50 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 51 B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 51 B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 51 B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 51 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 B.6. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 B.7. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52 B.8. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52 B.9. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction This document describes the Locator/Identifier Separation Protocol (LISP). LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [CHIAPPA]. As a result LISP creates two namespaces: Endpoint Identifiers (EIDs), that are used to identify end-hosts (e.g., nodes or Virtual Machines) and routable Routing Locators (RLOCs), used to identify network attachment points. LISP then defines functions for mapping between the two namespaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. LISP encapsulation uses a dynamic form of tunneling where no static provisioning is required or necessary. LISP is an overlay protocol that separates control from data-plane, this document specifies the data-plane, how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the Farinacci, et al. Expires July 1, 2018 [Page 3] =0C Internet-Draft LISP December 2017 appropriate location. Tunnel routers are equipped with a cache, called map-cache, that contains EID-to-RLOC mappings. The map-cache is populated using the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. LISP does not require changes to either host protocol stack or to underlay routers. By separating the EID from the RLOC space, LISP offers native Traffic Engineering, multihoming and mobility, among other features. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]) This document specifies the LISP data-plane encapsulation and other LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] specifies the LISP control plane. LISP deployment guidelines can be found in [RFC7215] and [RFC6835] describes considerations for network operational management. Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet. An address family that pertains to the data-plane. See [AFN] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0. Anycast Address: Anycast Address is a term used in this document to refer to the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in each of their own address spaces. Client-side: Client-side is a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in forwarding a packet from the source EID. Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header Farinacci, et al. Expires July 1, 2018 [Page 4] =0C Internet-Draft LISP December 2017 destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host if the destination EID is in the EID-Prefix range configured on the ETR. Otherwise, the packet is discarded. A Data-Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. When using Data-Probes, by sending Map-Requests on the underlying routing system, EID-Prefixes must be advertised. Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. EID-to-RLOC Database: The EID-to-RLOC Database is a global distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own globally visible IP addresses. Note that there MAY be transient conditions when the EID-Prefix for the site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used. EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID- to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope. EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID- Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. End-System: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP Farinacci, et al. Expires July 1, 2018 [Page 5] =0C Internet-Draft LISP December 2017 header when communicating globally (i.e., outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example, through a Domain Name System (DNS) [RFC1034] lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. An EID is allocated to a host from an EID-Prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Note that EID blocks MAY be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site MAY have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called an "LEID". Throughout this document, any references to "EID" refer to an LEID. Ingress Tunnel Router (ITR): An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its routable RLOCs (in the RLOC space) in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC MAY be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating host's supplied EID). Farinacci, et al. Expires July 1, 2018 [Page 6] =0C Internet-Draft LISP December 2017 LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP- specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips. LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), or Proxy-ETR (PETR). LISP Site: LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network. Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 10. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well-defined actions that are encoded in a Negative Map-Reply. Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider to which a site connects. Typically, each block is a sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the underlay network. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. Provider-Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g., from a particular service provider) and are therefore not topologically aggregatable in the routing system. Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites. Farinacci, et al. Expires July 1, 2018 [Page 7] =0C Internet-Draft LISP December 2017 Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites. Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header. Re-Encapsulating Tunneling Router (RTR): An RTR acts like an ETR to remove a LISP header, then acts as an ITR to prepend a new LISP header. This is known as Re-encapsulating Tunneling. Doing this allows a packet to be re-routed by the RTR without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured. When using multiple mapping database systems, care must be taken to not create re- encapsulation loops through misconfiguration. Route-Returnability: Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message. Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from aggregatable blocks that are assigned to a site at each point to which it attaches to the underlay network; where the topology is defined by the connectivity of provider networks. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Server-side: Server-side is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID. TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. Farinacci, et al. Expires July 1, 2018 [Page 8] =0C Internet-Draft LISP December 2017 TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router. 4. Basic Overview One key concept of LISP is that end-systems operate the same way they do today. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. Another key LISP concept is the "Tunnel Router". A Tunnel Router prepends LISP headers on host-originated packets and strips them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips the new header. The ITR performs EID-to- RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems only send to addresses that are EIDs. They don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change. o EIDs are typically IP addresses assigned to hosts. Farinacci, et al. Expires July 1, 2018 [Page 9] =0C Internet-Draft LISP December 2017 o Other types of EID are supported by LISP, see [RFC8060] for further information. o LISP routers mostly deal with Routing Locator addresses. See details in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks. o When a router originates packets, it MAY use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure SHell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it MAY use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o Packets with EIDs in them are not expected to be delivered end-to- end in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication or to be encapsulated for inter-site communication. o EID-Prefixes are likely to be hierarchically assigned in a manner that is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. o EIDs MAY also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS). An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document recommends that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the Farinacci, et al. Expires July 1, 2018 [Page 10] =0C Internet-Draft LISP December 2017 first prepended header is used at a site for Location/Identity separation and the second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. Another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility. 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow, including also control-plane information as specified in [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following conditions: o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site. o A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. Map-Requests are sent to the mapping database system by using the LISP control-plane protocol documented in [I-D.ietf-lisp-rfc6833bis]. o Map-Replies are sent on the underlying routing system topology using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol. Client host1.abc.example.com wants to communicate with server host2.xyz.example.com: 1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This Farinacci, et al. Expires July 1, 2018 [Page 11] =0C Internet-Draft LISP December 2017 address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [I-D.ietf-lisp-rfc6833bis] for further information. 3. The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. 4. The mapping system helps forwarding the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. 6. The ITR receives the Map-Reply message, parses the message (to check for format validity), and stores the mapping information from the packet. This information is stored in the ITR's EID-to- RLOC map-cache. Note that the map-cache is an on-demand cache. An ITR will manage its map-cache in such a way that optimizes for its resource constraints. 7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host. 9. In order to defer the need for a mapping lookup in the reverse direction, an ETR can OPTIONALLY create a cache entry that maps the source EID (inner-header source IP address) to the source Farinacci, et al. Expires July 1, 2018 [Page 12] =0C Internet-Draft LISP December 2017 RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC. 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Unreachable/Fragmentation-Needed message is returned to the source. In the case when fragmentation is needed, this specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 7. Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported. Additional types of EIDs are defined in [RFC8060]. 5.1. LISP IPv4-in-IPv4 Header Format Farinacci, et al. Expires July 1, 2018 [Page 13] =0C Internet-Draft LISP December 2017 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL | DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL | DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IHL =3D IP-Header-Length 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | Farinacci, et al. Expires July 1, 2018 [Page 14] =0C Internet-Draft LISP December 2017 r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header (IH): The inner header is the header on the datagram received from the originating host [RFC0791] [RFC8200] [RFC2474]. The source and destination IP addresses are EIDs. Outer Header: (OH) The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress Farinacci, et al. Expires July 1, 2018 [Page 15] =0C Internet-Draft LISP December 2017 router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 7.1 and 7.2. UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 12 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341. UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP zero checksums over IPv6 for all tunneling protocols, including LISP, is subject to the applicability statement in [RFC6936]. UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers. N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a Nonce. See Section 10.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a Nonce value present. L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use. Farinacci, et al. Expires July 1, 2018 [Page 16] =0C Internet-Draft LISP December 2017 x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP- encapsulated packets when the ITR is also an ETR. See Section 10.1 for details. V: The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to Section 13.3 for more details. This bit indicates that the LISP header is encoded in this case as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: The I-bit is the Instance ID bit. See Section 8 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this: x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R: The R-bit is a Reserved bit for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt. KK: The KK-bits are a 2-bit field used when encapsualted packets are encrypted. The field is set to 00 when the packet is not encrypted. See [RFC8061] for further information. Farinacci, et al. Expires July 1, 2018 [Page 17] =0C Internet-Draft LISP December 2017 LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different destinations. However, the same nonce can be used for a period of time to the same destination. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 10.1 for more details. LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 10 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'. When doing ITR/PITR encapsulation: o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field. o The outer-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header 'Type of Service' field (with one exception; see below). When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header Farinacci, et al. Expires July 1, 2018 [Page 18] =0C Internet-Draft LISP December 2017 to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. o The inner-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header 'Type of Service' field (with one exception; see below). Note that if an ETR/PETR is also an ITR/PITR and chooses to re- encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 18.3 for TTL exception handling for traceroute packets. The Explicit Congestion Notification ('ECN') field occupies bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC3168]. The 'ECN' field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. An ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR/ PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. 6. LISP EID-to-RLOC Map-Cache ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- RLOC Map-Cache, that contains mappings from EID-prefixes to locator sets. The cache is used to encapsulate packets from the EID space to the corresponding RLOC network attachment point. When an ITR/PITR receives a packet from inside of the LISP site to destinations outside of the site a longest-prefix match lookup of the EID is done to the map-cache. Farinacci, et al. Expires July 1, 2018 [Page 19] =0C Internet-Draft LISP December 2017 When the lookup succeeds, the locator-set retrieved from the map- cache is used to send the packet to the EID's topological location. If the lookup fails, the ITR/PITR needs to retrieve the mapping using the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The mapping is then stored in the local map-cache to forward subsequent packets addressed to the same EID-prefix. The map-cache is a local cache of mappings, entries are expired based on the associated Time to live. In addition, entries can be updated with more current information, see Section 13 for further information on this. Finally, the map-cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. 7. Dealing with Large Encapsulated Packets This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism SHOULD be implemented. Both or neither can be used, since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Both stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below referring to an ITR also apply to a TE-ITR. 7.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: 1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths. 2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet. 3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR MUST receive from the source so the effective MTU can be met. That is, L =3D S + H. Farinacci, et al. Expires July 1, 2018 [Page 20] =0C Internet-Draft LISP December 2017 When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets (meaning the received packet size was greater than S octets from the source), it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMP Unreachable/ Fragmentation-Needed message to the source with a value of S, where S is (L - H). When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification RECOMMENDS that L be defined as 1500. 7.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR. 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Unreachable/Fragmentation-Needed message to the ITR. The ITR will parse the ICMP message to determine which Locator is Farinacci, et al. Expires July 1, 2018 [Page 21] =0C Internet-Draft LISP December 2017 affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Unreachable/ Fragmentation-Needed message back to the source. The packet size advertised by the ITR in the ICMP Unreachable/Fragmentation- Needed message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 8. Using Virtualization and Segmentation with LISP There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies or multi-tenant virtualization. For these and other scenarios where segregation is needed, Instance IDs are used. An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case details. The Instance ID that is stored in the mapping database when LISP-DDT [RFC8111] is used is 32 bits in length. That means the control-plane can store more instances than a given data-plane can use. Multiple data-planes can use the same 32-bit space as long as the low-order 24 bits don't overlap among xTRs. Farinacci, et al. Expires July 1, 2018 [Page 22] =0C Internet-Draft LISP December 2017 9. Routing Locator Selection Both the client-side and server-side MAY need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the 'Priority' and 'Weight' fields in EID- to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following are different scenarios for choosing RLOCs and the controls that are available: o The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection. o The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o The server-side sets a Weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server- side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable. o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer- header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding Farinacci, et al. Expires July 1, 2018 [Page 23] =0C Internet-Draft LISP December 2017 cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large. o A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map- Cache entry for the "gleaned" EID and is stored and used for the time indicated from the 'TTL' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry. This "gleaning" mechanism is OPTIONAL. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the Locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section. 10. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR MAY receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions. 3. An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address. Farinacci, et al. Expires July 1, 2018 [Page 24] =0C Internet-Draft LISP December 2017 4. An ITR MAY receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR MAY receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator reachability algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Farinacci, et al. Expires July 1, 2018 [Page 25] =0C Internet-Draft LISP December 2017 Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix. Refer to Section 19 for security related issues regarding Locator-Status-Bits. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map- Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages. If an ITR does receive an ICMP Network Unreachable or Host Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a Locator-Set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default- Free Zone (DFZ), it can decide to not use the Locator even though the Locator-Status-Bits indicate that the Locator is up. In this case, the path from the ITR to the ETR that is assigned the Locator is not available. More details are in [I-D.meyer-loc-id-implications]. Optionally, an ITR can send a Map-Request to a Locator, and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with Priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets, since that increases the risk of packet loss for end-to-end sessions. Farinacci, et al. Expires July 1, 2018 [Page 26] =0C Internet-Draft LISP December 2017 When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true, due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability. 10.1. Echo Nonce Algorithm When data flows bidirectionally between Locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the echo-nonce-request state, then the path to the ETR is unreachable. This decision MAY be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR MAY both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation-specific setting. However, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and subsequently continue sending echo-nonce-request packets. Farinacci, et al. Expires July 1, 2018 [Page 27] =0C Internet-Draft LISP December 2017 This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site MAY not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- probe Map-Reply message. Note other Locator Reachability mechanisms can be used to compliment or even override the echo nonce algorithm. See the next section for an example of control-plane probing. 10.2. RLOC-Probing Algorithm RLOC-Probing is a method that an ITR or PITR can use to determine the reachability status of one or more Locators that it has cached in a Map-Cache entry. The probe-bit of the Map-Request and Map-Reply messages is used for RLOC-Probing. RLOC-Probing is done in the control plane on a timer basis, where an ITR or PITR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-probes are sent periodically using a jittered timer interval. When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping data for the EID-Prefix contained in the Map-Request. This provides the opportunity for the ITR or PITR that sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC-Probing. The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is Farinacci, et al. Expires July 1, 2018 [Page 28] =0C Internet-Draft LISP December 2017 reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) estimates between a pair of Locators, which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC-Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times is very small. 11. EID Reachability within a LISP Site A site MAY be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID- Prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header. It is recognized that there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-Prefix range is partitioned and which Locators can reach any sub- ranges of the EID-Prefixes. Note that this is not a new problem introduced by the LISP architecture. The problem exists today when a multihomed site uses BGP to advertise its reachability upstream. 12. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache of a requesting ITR, the Locator-Set for the EID-Prefix MAY contain different Priority and Weight values for each locator address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators. The following hash algorithm MAY be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and Farinacci, et al. Expires July 1, 2018 [Page 29] =0C Internet-Draft LISP December 2017 destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping. 3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers that are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets that are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. 13. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, it is desirable to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When adding a new Locator record in lexicographic order to the end of a Locator-Set, it is easy to update mappings. We assume that new mappings will maintain the same Locator ordering as the old mapping but will just have new Locators appended to the end of the list. So, some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses Farinacci, et al. Expires July 1, 2018 [Page 30] =0C Internet-Draft LISP December 2017 that are lexicographically greater than the locator addresses in the existing Locator-Set. When a Locator record is inserted in the middle of a Locator-Set, to maintain lexicographic order, the SMR procedure in Section 13.2 is used to inform ITRs and PITRs of the new Locator-Status-Bit mappings. When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed. We propose here three approaches for Locator-Set compaction: one operational mechanism and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. 13.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, there is a 24-hour window to time out old mappings. The following clock sweep procedure is used: 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1-hour window, the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. Farinacci, et al. Expires July 1, 2018 [Page 31] =0C Internet-Draft LISP December 2017 4. At the end of the 1-hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So, any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a TTL equal to the TTL in the Map-Reply. 13.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data. This can only occur when both ITR and ETR functionality reside in the same router. An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches. 2. A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected, and the EID-Prefix used is the one copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request. 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map-Versioning as described in Section 13.3 is used, an SMR Farinacci, et al. Expires July 1, 2018 [Page 32] =0C Internet-Draft LISP December 2017 sender can detect if an ITR is using the most up-to-date database mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- limited. This is important to avoid Map-Reply implosion. 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map- Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it may not send an SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all Locators in the Locator-Set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case they will send Map-Requests to obtain a Map-Cache entry. 13.3. Database Map-Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 13.2 occurs. Farinacci, et al. Expires July 1, 2018 [Page 33] =0C Internet-Draft LISP December 2017 An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version Number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects that the Source Map- Version Number is greater than the last Map-Version Number sent in a Map-Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-Prefix, so values that are greater are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map- Version Number. See [RFC6834] for a more detailed analysis and description of Database Map-Versioning. 14. Multicast Considerations A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determine where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, can use the same group address as the destination Routing Locator, use a multicast or unicast Routing Locator obtained from a Mapping System lookup, or use other means to determine the group address mapping. With respect to the source Routing Locator address, the ITR prepends its own IP address as the source address of the outer IP header. Just like it would if the destination EID was a unicast address. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable. Farinacci, et al. Expires July 1, 2018 [Page 34] =0C Internet-Draft LISP December 2017 There are two approaches for LISP-Multicast, one that uses native multicast routing in the underlay with no support from the Mapping System and the other that uses only unicast routing in the underlay with support from the Mapping System. See [RFC6831] and [I-D.ietf-lisp-signal-free-multicast], respectively, for details. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832]. 15. Router Performance Considerations LISP is designed to be very "hardware-based forwarding friendly". A few implementation techniques can be used to incrementally implement LISP: o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control-plane processing SHOULD be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data- plane. o On an ITR, prepending a new IP header consists of adding more octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. For performance issues related to map-cache management, see Section 19. 16. Mobility Considerations There are several kinds of mobility, of which only some might be of concern to LISP. Essentially, they are as follows. Farinacci, et al. Expires July 1, 2018 [Page 35] =0C Internet-Draft LISP December 2017 16.1. Slow Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-to-RLOC mappings for sites are expected to be handled by configuration, outside of LISP. An individual endpoint wishes to move but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs [RFC4984]. 16.2. Fast Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP-layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and primarily where interactions with LISP need to be explored, such as the mechanisms in [I-D.ietf-lisp-eid-mobility] when the EID moves but the RLOC is in the network infrastructure. In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-to-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have an internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything that decreases the number of new EID- to-RLOC mappings needed when a node moves, or maintains the validity of an EID-to-RLOC mapping for a longer time, is useful. In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same, and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. Farinacci, et al. Expires July 1, 2018 [Page 36] =0C Internet-Draft LISP December 2017 If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. See [I-D.ietf-lisp-predictive-rlocs] for more recent mechanisms which can provide near-zero packet loss during handoffs. 16.3. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Refer to [I-D.ietf-lisp-mn] for more details for when the EID and RLOC are co-located in the roaming node. 17. LISP xTR Placement and Encapsulation Methods This section will explore how and where ITRs and ETRs can be placed in the network and will discuss the pros and cons of each scenario. For a more detailed networkd design deployment recommendation, refer to [RFC7215]. There are two basic deployment tradeoffs to consider: centralized versus distributed caches; and flat, Recursive, or Re-encapsulating Tunneling. When deciding on centralized versus distributed caching, the following issues SHOULD be considered: o Are the xTRs spread out so that the caches are spread across all the memories of each router? A centralized cache is when an ITR keeps a cache for all the EIDs it is encapsulating to. The packet takes a direct path to the destination Locator. A distributed cache is when an ITR needs help from other Re-Encapsulating Tunnel Routers (RTRs) because it does not store all the cache entries for the EIDs it is encapsulating to. So, the packet takes a path through RTRs that have a different set of cache entries. o Should management "touch points" be minimized by only choosing a few xTRs, just enough for redundancy? Farinacci, et al. Expires July 1, 2018 [Page 37] =0C Internet-Draft LISP December 2017 o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, using more ETRs does require more management, since EID-Prefix-to- RLOC mappings need to be explicitly configured. When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the following issues SHOULD be considered: o Flat tunneling implements a single encapsulation path between the source site and destination site. This generally offers better paths between sources and destinations with a single encapsulation path. o Recursive Tunneling is when encapsulated traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control, since the site is prepending a new encapsulation header. In the case of TE-based tunneling, the site MAY have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive Tunneling generally will result in suboptimal paths but with the benefit of steering traffic to parts of the network that have more resources available. o The technique of Re-Encapsulation ensures that packets only require one encapsulation header. So, if a packet needs to be re- routed, it is first decapsulated by the RTR and then Re- Encapsulated with a new encapsulation header using a new RLOC. The next sub-sections will examine where xTRs and RTRs can reside in the network. 17.1. First-Hop/Last-Hop xTRs By locating xTRs close to hosts, the EID-Prefix set is at the granularity of an IP subnet. So, at the expense of more EID-Prefix- to-RLOC sets for the site, the caches in each xTR can remain relatively small. But caches always depend on the number of non- aggregated EID destination flows active through these xTRs. With more xTRs doing encapsulation, the increase in control traffic grows as well: since the EID granularity is greater, more Map- Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios than their core router counterparts. Memory is typically less expensive in these devices, and fewer routes Farinacci, et al. Expires July 1, 2018 [Page 38] =0C Internet-Draft LISP December 2017 are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing states. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices. 17.2. Border/Edge xTRs Using Customer Edge (CE) routers for xTR placement allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE-based xTRs for that site. This offers the opposite benefit of the first-hop/last-hop xTR scenario: the number of mapping entries and network management touch points is reduced, allowing better scaling. One disadvantage is that fewer network resources are used to reach host endpoints, thereby centralizing the point-of-failure domain and creating network choke points at the CE xTR. Note that more than one CE xTR at a site can be configured with the same IP address. In this case, an RLOC is an anycast address. This allows resilience between the CE xTRs. That is, if a CE xTR fails, traffic is automatically routed to the other xTRs using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast Locators is the limited advertisement scope of /32 (or /128 for IPv6) routes. 17.3. ISP Provider Edge (PE) xTRs The use of ISP PE routers as xTRs is not the typical deployment scenario envisioned in this specification. This section attempts to capture some of the reasoning behind this preference for implementing LISP on CE routers. The use of ISP PE routers for xTR placement gives an ISP, rather than a site, control over the location of the ETRs. That is, the ISP can decide whether the xTRs are in the destination site (in either CE xTRs or last-hop xTRs within a site) or at other PE edges. The advantage of this case is that two encapsulation headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for a new encapsuluation path to the destination end site. Farinacci, et al. Expires July 1, 2018 [Page 39] =0C Internet-Draft LISP December 2017 An obvious disadvantage is that the end site has no control over where its packets flow or over the RLOCs used. Other disadvantages include difficulty in synchronizing path liveness updates between CE and PE routers. As mentioned in earlier sections, a combination of these scenarios is possible at the expense of extra packet header overhead; if both site and provider want control, then Recursive or Re-Encapsulating Tunnels are used. 17.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control message MUST be a routable address and therefore [RFC1918] addresses SHOULD only be presence when running in a local environment. When a LISP xTR is configured with private RLOC addresses and resides behind a NAT device and desires to communicate on the Internet, the private addresses MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed when LISP VPNs are not in use. Both NAT translation and LISP encapsulation functions could be co- located in the same device. 17.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache MAY not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. 18. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from the ITR to the ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Farinacci, et al. Expires July 1, 2018 [Page 40] =0C Internet-Draft LISP December 2017 Segment 1 (in source LISP site based on EIDs): source host ---> first hop ... next hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next hop ... next hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next hop ... last hop ---> destination host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal manner as they are today. The ITR performs a TTL decrement and tests for 0 before encapsulating. Therefore, the ITR's hop is seen by the traceroute source as having an EID address (the address of the site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destinations of the ICMP messages are the ITR RLOC address and the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client and also retain the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0, as the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 18.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above, since the entire traceroute data packet is included in the ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention to forwarding ICMP messages back to the traceroute source. Farinacci, et al. Expires July 1, 2018 [Page 41] =0C Internet-Draft LISP December 2017 18.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure, since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 octets that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended, followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source, is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload, thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value. 18.3. Traceroute Using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, one cannot get all 3 segments of the traceroute. Segment 2 of the traceroute cannot be conveyed to the traceroute source, since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. Farinacci, et al. Expires July 1, 2018 [Page 42] =0C Internet-Draft LISP December 2017 19. Security Considerations Security considerations for LISP are discussed in [RFC7833], in addition [I-D.ietf-lisp-sec] provides authentication and integrity to LISP mappings. A complete LISP threat analysis can be found in [RFC7835], in what follows we provide a summary. The optional mechanisms of gleaning is offered to directly obtain a mapping from the LISP encapsulated packets. Specifically, an xTR can learn the EID-to-RLOC mapping by inspecting the source RLOC and source EID of an encapsulated packet, and insert this new mapping into its map-cache. An off-path attacker can spoof the source EID address to divert the traffic sent to the victim's spoofed EID. If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim;s RLOC, potentially overloading it. The LISP Data-Plane defines several mechanisms to monitor RLOC data- plane reachability, in this context Locator-Status Bits, Nonce- Present and Echo-Nonce bits of the LISP encapsulation header can be manipulated by an attacker to mount a DoS attack. An off-path attacker able to spoof the RLOC of a victim's xTR can manipulate such mechanisms to declare a set of RLOCs unreachable. This can be used also, for instance, to declare only one RLOC reachable with the aim of overload it. Map-Versioning is a data-plane mechanism used to signal a peering xTR that a local EID-to-RLOC mapping has been updated, so that the peering xTR uses LISP Control-Plane signaling message to retrieve a fresh mapping. This can be used by an attacker to forge the map- versioning field of a LISP encapsulated header and force an excessive amount of signaling between xTRs that may overload them. Most of the attack vectors can be mitigated with careful deployment and configuration, information learned opportunistically (such as LSB or gleaning) SHOULD be verified with other reachability mechanisms. In addition, systematic rate-limitation and filtering is an effective technique to mitigate attacks that aim to overload the control-plane. 20. Network Management Considerations Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [RFC7052] and [RFC6835]. Farinacci, et al. Expires July 1, 2018 [Page 43] =0C Internet-Draft LISP December 2017 21. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this data-plane LISP specification, in accordance with BCP 26 [RFC8126]. 21.1. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for lisp-data and lisp-control operation, respectively. IANA has updated the description for UDP ports 4341 and 4342 as follows: lisp-data 4341 udp LISP Data Packets lisp-control 4342 udp LISP Control Packets 22. References 22.1. Normative References [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-07 (work in progress), December 2017. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . Farinacci, et al. Expires July 1, 2018 [Page 44] =0C Internet-Draft LISP December 2017 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 22.2. Informative References [AFN] IANA, "Address Family Numbers", August 2016, . [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, . Farinacci, et al. Expires July 1, 2018 [Page 45] =0C Internet-Draft LISP December 2017 [I-D.ietf-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-ietf-lisp-eid-mobility-01 (work in progress), November 2017. [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-lisp-mn] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", draft-ietf-lisp-mn-01 (work in progress), October 2017. [I-D.ietf-lisp-predictive-rlocs] Farinacci, D. and P. Pillay-Esnault, "LISP Predictive RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in progress), November 2017. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 (work in progress), October 2017. [I-D.ietf-lisp-signal-free-multicast] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", draft-ietf-lisp-signal-free-multicast-07 (work in progress), November 2017. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in progress), November 2017. [I-D.meyer-loc-id-implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01 (work in progress), January 2009. [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996. Farinacci, et al. Expires July 1, 2018 [Page 46] =0C Internet-Draft LISP December 2017 [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, DOI 10.17487/RFC4192, September 2005, . [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, DOI 10.17487/RFC4866, May 2007, . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, . Farinacci, et al. Expires July 1, 2018 [Page 47] =0C Internet-Draft LISP December 2017 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, . [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, . [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, DOI 10.17487/RFC7052, October 2013, . [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . Farinacci, et al. Expires July 1, 2018 [Page 48] =0C Internet-Draft LISP December 2017 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, . Farinacci, et al. Expires July 1, 2018 [Page 49] =0C Internet-Draft LISP December 2017 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, Alia Atlas, Florin Coras and Alberto Rodriguez. This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC. The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward standards-track RFCs. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] Farinacci, et al. Expires July 1, 2018 [Page 50] =0C Internet-Draft LISP December 2017 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 o Posted December 2017. o Remove references to research work for any protocol mechanisms. o Document scanned to make sure it is RFC 2119 compliant. o Made changes to reflect comments from document WG shepherd Luigi Iannone. o Ran IDNITs on the document. B.2. Changes to draft-ietf-lisp-rfc6830bis-07 o Posted November 2017. o Rephrase how Instance-IDs are used and don't refer to [RFC1918] addresses. B.3. Changes to draft-ietf-lisp-rfc6830bis-06 o Posted October 2017. o Put RTR definition before it is used. o Rename references that are now working group drafts. o Remove "EIDs MUST NOT be used as used by a host to refer to other hosts. Note that EID blocks MAY LISP RLOCs". o Indicate what address-family can appear in data packets. o ETRs may, rather than will, be the ones to send Map-Replies. o Recommend, rather than mandate, max encapsulation headers to 2. o Reference VPN draft when introducing Instance-ID. o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Clarify when private addreses can be used. B.4. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Reencapsulating Tunnel Router is an RTR. Farinacci, et al. Expires July 1, 2018 [Page 51] =0C Internet-Draft LISP December 2017 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 o Posted July 2017. o Changed reference of IPv6 RFC2460 to RFC8200. o Indicate that the applicability statement for UDP zero checksums over IPv6 adheres to RFC6936. B.6. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. B.7. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. B.8. Changes to draft-ietf-lisp-rfc6830bis-01 o Posted March 2017. o Include references to new RFCs published. o Change references from RFC6833 to RFC6833bis. o Clarified LCAF text in the IANA section. o Remove references to "experimental". B.9. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses Farinacci, et al. Expires July 1, 2018 [Page 52] =0C Internet-Draft LISP December 2017 Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: farinacci@gmail.com Vince Fuller Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: vince.fuller@gmail.com Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: dmm@1-4-5.net Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: darlewis@cisco.com Albert Cabellos UPC/BarcelonaTech Campus Nord, C. Jordi Girona 1-3 Barcelona, Catalunya Spain EMail: acabello@ac.upc.edu Farinacci, et al. Expires July 1, 2018 [Page 53] --Apple-Mail=_8C1A4519-7E43-41B9-9800-E4BFA031930D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 27, 2017, at 9:10 PM, Dino Farinacci = wrote: >=20 >> I would talk about that purely in terms of RLOCs being dervice from, = and assigned according to, the underlay. It is up to the underlay to = set it policies so that it scales well (or chooses not to care, as some = underlays do.) >=20 > > I can change =E2=80=9Cglobal Internet=E2=80=9D to =E2=80=9Ccore=E2=80=9D= and =E2=80=9Cprovider underlay networks=E2=80=9D. What do you think? >=20 > Dino >=20 >>=20 >> Yours, >> Joel >>=20 >> On 12/27/17 11:44 PM, Dino Farinacci wrote: >>>> Actually, I do not see why the LISP spec should talk at all about = the scalability of the underlay. The underlay is what it is. We are = not claiming to change that. >>> But if you assign non PA addresses to RLOCs, the underlay = scalability will be worse. It=E2=80=99s definitely worth mentioning how = EIDs are independent and can be opaque where RLOCs need to be = topologically aggregatable, or otherise you worsen the underlay. >>> Dino >>>> Working Group: Does anyone else have an opinion either way? This = document belongs to the WG, not to the chairs or the editors. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 12/27/17 11:18 PM, Dino Farinacci wrote: >>>>>>> Note, we still care about scalability of any underlay, = especially the Internet core, so we should leave this in. Note, we ARE = still solving the scalability problem. >>>>>>>=20 >>>>>>> I don=E2=80=99t know why any of you would think differently. >>>>>>=20 >>>>>> We are solving this issue and many others. But the point of the = document is specifying a data-plane, not the benefits of this = data-plane. >>>>> When you spec a protocol you must say why you are doing it and = ususally a requirements for the solution state that. So benefits is a = natural output of satisfying the requirements. And at the same time we = also indicate what the costs are. >>>>>>> I have planned to remove the sentence. >>>>>>>=20 >>>>>>> What do you think about defining an EID as an identifier of the = overlay and an RLOC as an identifier of the underlay? (Probably this = needs to be reworded, but you get my point). >>>>>>>=20 >>>>>>> In my view this definition is broader and accounts for many of = the LCAF uses. >>>>> We spent two years on the definition of an EID and RLOC. There = were so many people that contributed and discussed it. Why undo that = effort. There is nothing inherently wrong with the definitions. >>>>>>>=20 >>>>>> I had planned to take Luigi=E2=80=99s suggestion. I did not want = to rewrite this section. It was carefully written by David Black with = consolation from the ECN experts. I do not want to lose this technical = text. >>>>>>=20 >>>>>> I still think that Luigi's suggestion clarifies the text and that = my edit (hopefully) makes it easier for readers to understand. I just = moved some sentences . >>>>> I made some changes but it is never a good idea to repeat the same = exact text. Check the new wording. >>>>>>>> Actually we should merge this section with 'Routing Locator = Hashing=E2=80=99 >>>>>>>=20 >>>>>>> I disagree with you guys. Who do you think punts packets when = there is a map-cache miss? The data-plane. Note there are many users of = the control-plane, an SDN controller, many data-planes, and lig/rig. How = they each use the control-plane is documented in their own documents. >>>>>>>=20 >>>>>>> And please do not suggest that lig/rig usage of the control = plane move to 6833bis. >>>>>>>=20 >>>>>> As an example, if we keep the 'Routing Locator Hashing' text as = it is then it only works with Map-Reply messages: >>>>>>=20 >>>>>> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply = message that is stored in the map-cache of a requesting ITR=E2=80=9D >>>>>>=20 >>>>>> The point is to allow LISP data-plane to work with any = control-plane. >>>>> No that has never been a requirement. We have stated (in the = charter) that we can use any data-plane =E2=80=9Cwith the LISP = control-plane=E2=80=9D. We have never discussed and it was never a = requirement to do the converse. >>>>> Dino >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >=20 --Apple-Mail=_8C1A4519-7E43-41B9-9800-E4BFA031930D--