From iesg-secretary@ietf.org Mon Jul 1 09:03:10 2013 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 DD81E11E8280; Mon, 1 Jul 2013 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2Uc8AP-1Pfj; Mon, 1 Jul 2013 09:03:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5136B11E8215; Mon, 1 Jul 2013 09:03:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Sender: Message-ID: <20130701160310.22718.49133.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 09:03:10 -0700 Cc: lisp@ietf.org Subject: [lisp] Last Call: (LISP Network Element Deployment Considerations) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 01 Jul 2013 16:03:11 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Network Element Deployment Considerations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-07-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-deployment/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-deployment/ballot/ No IPR declarations have been submitted directly on this I-D. From Sharon@Contextream.com Tue Jul 2 07:15:37 2013 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 4051421F9EBF for ; Tue, 2 Jul 2013 07:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbEu4VfbskXk for ; Tue, 2 Jul 2013 07:15:31 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3C821F9E0B for ; Tue, 2 Jul 2013 07:15:29 -0700 (PDT) Received: from mail40-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE042.bigfish.com (10.174.4.105) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 14:15:15 +0000 Received: from mail40-db8 (localhost [127.0.0.1]) by mail40-db8-R.bigfish.com (Postfix) with ESMTP id BF97D1C03FD for ; Tue, 2 Jul 2013 14:15:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT005.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zf7Iz936eIc857hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1f8fizz8275ch1033IL17326ah18c673h8275bh182cceh8275dhz32i2a8h668h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail40-db8 (localhost.localdomain [127.0.0.1]) by mail40-db8 (MessageSwitch) id 1372774512316157_28402; Tue, 2 Jul 2013 14:15:12 +0000 (UTC) Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.230]) by mail40-db8.bigfish.com (Postfix) with ESMTP id 4438A2E0049 for ; Tue, 2 Jul 2013 14:15:12 +0000 (UTC) Received: from DB3PRD0610HT005.eurprd06.prod.outlook.com (157.56.252.53) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 2 Jul 2013 14:15:11 +0000 Received: from DB3PRD0610MB379.eurprd06.prod.outlook.com ([169.254.11.40]) by DB3PRD0610HT005.eurprd06.prod.outlook.com ([10.255.47.40]) with mapi id 14.16.0324.000; Tue, 2 Jul 2013 14:15:10 +0000 From: Sharon Barkai To: "lisp@ietf.org" Thread-Topic: New Version Notification for draft-barkai-lisp-nfv-02.txt Thread-Index: Ac53Lo/TiNShwgxIRoeVGk/l69fkGg== Date: Tue, 2 Jul 2013 14:15:10 +0000 Message-ID: <153FFA41-F38A-4BCC-A528-6641AA7AC343@Contextream.com> References: <20130702140937.24441.96071.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [84.95.88.100] Content-Type: multipart/alternative; boundary="_000_153FFA41F38A4BCCA5286641AA7AC343Contextreamcom_" MIME-Version: 1.0 X-OriginatorOrg: Contextream.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [lisp] Fwd: New Version Notification for draft-barkai-lisp-nfv-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2013 14:15:37 -0000 --_000_153FFA41F38A4BCCA5286641AA7AC343Contextreamcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGZvbGxvd2luZyB2ZXJzaW9uIGhhcyBmb3JtYXQgdXBkYXRlcyBieSBWaW5hLg0KVGhlIGdv YWwgaXMgc3luYyBMQ0FGcyB1c2VkIGZvciA1LXR1cGxlIChuZnYtZmxvdykgTWFwcGluZ3Mgd2l0 aCBsaXNwbW9iLA0KYW5kIHRvIGhhdmUgYW4gaW50ZXJvcGVyYWJsZSBvcGVuIHNvdXJjZSBpbXBs ZW1lbnRhdGlvbiBiYXNlZCBvbiB0aGUgZHJhZnQgaW4gT0RMLg0KVG54Lg0KDQotLXN6Yg0KDQpC ZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpEYXRlOiBKdWx5IDIsIDIwMTMsIDE3 OjA5OjM3IEdNVCswMzowMA0KVG86IFZpbmEgRXJtYWdhbiA8dmVybWFnYW5AY2lzY28uY29tPG1h aWx0bzp2ZXJtYWdhbkBjaXNjby5jb20+PiwgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFp bC5jb208bWFpbHRvOmZhcmluYWNjaUBnbWFpbC5jb20+PiwgU2hhcm9uIEJhcmthaSA8c2Jhcmth aUBnbWFpbC5jb208bWFpbHRvOnNiYXJrYWlAZ21haWwuY29tPj4sIEZhYmlvIE1haW5vIDxmbWFp bm9AY2lzY28uY29tPG1haWx0bzpmbWFpbm9AY2lzY28uY29tPj4sIERhdmlkIE1leWVyIDxkbW1A MS00LTUubmV0PG1haWx0bzpkbW1AMS00LTUubmV0Pj4sIHNiYXJrYWlAZ21haWwuY29tPG1haWx0 bzpzYmFya2FpQGdtYWlsLmNvbT4gPHNiYXJrYWlAZ21haWwuY29tPG1haWx0bzpzYmFya2FpQGdt YWlsLmNvbT4+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJh cmthaS1saXNwLW5mdi0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmFy a2FpLWxpc3AtbmZ2LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBT aGFyb24gQmFya2FpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVu YW1lOiAgICAgZHJhZnQtYmFya2FpLWxpc3AtbmZ2DQpSZXZpc2lvbjogICAgIDAyDQpUaXRsZTog ICAgICAgICBMSVNQIEJhc2VkIEZsb3dNYXBwaW5nIGZvciBTY2FsaW5nIE5GVg0KQ3JlYXRpb24g ZGF0ZTogICAgIDIwMTMtMDctMDINCkdyb3VwOiAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KTnVtYmVyIG9mIHBhZ2VzOiAxNQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iYXJrYWktbGlzcC1uZnYtMDIudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmFya2FpLWxp c3AtbmZ2DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJhcmthaS1saXNwLW5mdi0wMg0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1iYXJrYWktbGlzcC1uZnYtMDINCg0KQWJzdHJhY3Q6DQogIFRo aXMgZHJhZnQgZGVzY3JpYmVzIGFuIFJGQyA2ODMwIExvY2F0b3IgSUQgU2VwYXJhdGlvbiBQcm90 b2NvbA0KICAoTElTUCkgYmFzZWQgZGlzdHJpYnV0ZWQgZmxvdy1tYXBwaW5nLWZhYnJpYyBmb3Ig ZHluYW1pYyBzY2FsaW5nIG9mDQogIHZpcnR1YWxpemVkIG5ldHdvcmsgZnVuY3Rpb25zIChORlYp LiAgTmV0d29yayBmdW5jdGlvbnMgc3VjaCBhcw0KICBzdWJzY3JpYmVyLW1hbmFnZW1lbnQsIGNv bnRlbnQtb3B0aW1pemF0aW9uLCBzZWN1cml0eSBhbmQgcXVhbGl0eSBvZg0KICBzZXJ2aWNlLCBh cmUgdHlwaWNhbGx5IGRlbGl2ZXJlZCB1c2luZyBwcm9wcmlldGFyeSBoYXJkd2FyZQ0KICBhcHBs aWFuY2VzIGVtYmVkZGVkIGludG8gdGhlIG5ldHdvcmsgYXMgdHVybi1rZXkgc2VydmljZS1ub2Rl cyBvcg0KICBzZXJ2aWNlLWJsYWRlcyB3aXRoaW4gcm91dGVycy4gIE5leHQgZ2VuZXJhdGlvbiBu ZXR3b3JrIGZ1bmN0aW9ucyBhcmUNCiAgYmVpbmcgaW1wbGVtZW50ZWQgYXMgcHVyZSBzb2Z0d2Fy ZSBpbnN0YW5jZXMgcnVubmluZyBvbiBzdGFuZGFyZA0KICBzZXJ2ZXJzIC0gdW5idW5kbGVkIHZp cnR1YWxpemVkIGNvbXBvbmVudHMgb2YgY2FwYWNpdHkgYW5kDQogIGZ1bmN0aW9uYWxpdHkuICBM SVNQLVNETiBiYXNlZCBmbG93LW1hcHBpbmcsIGR5bmFtaWNhbGx5IGFzc2VtYmxlcw0KICB0aGVz ZSBjb21wb25lbnRzIHRvIHdob2xlIHNvbHV0aW9ucyBieSBzdGVlcmluZyB0aGUgcmlnaHQgdHJh ZmZpYyBpbg0KICB0aGUgcmlnaHQgc2VxdWVuY2UgdG8gdGhlIHJpZ2h0IHZpcnR1YWwgZnVuY3Rp b24gaW5zdGFuY2UuDQoNCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K --_000_153FFA41F38A4BCCA5286641AA7AC343Contextreamcom_ Content-Type: text/html; charset="utf-8" Content-ID: <8B9A772F64C8D14F94C6753B51BBEA84@Contextream.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PlRoZSBmb2xsb3dpbmcgdmVyc2lvbiBoYXMgZm9ybWF0IHVwZGF0ZXMgYnkgVmluYS48L2Rp dj4NCjxkaXY+VGhlIGdvYWwgaXMgc3luYyBMQ0FGcyB1c2VkIGZvciA1LXR1cGxlIChuZnYtZmxv dykgTWFwcGluZ3Mgd2l0aCBsaXNwbW9iLDwvZGl2Pg0KPGRpdj5hbmQgdG8gaGF2ZSBhbiBpbnRl cm9wZXJhYmxlIG9wZW4gc291cmNlIGltcGxlbWVudGF0aW9uIGJhc2VkIG9uIHRoZSBkcmFmdCBp biBPREwuPC9kaXY+DQo8ZGl2PlRueC48YnI+DQo8YnI+DQotLXN6YjwvZGl2Pg0KPGRpdj48YnI+ DQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGRpdj48Yj5Gcm9tOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxicj4NCjxiPkRh dGU6PC9iPiBKdWx5IDIsIDIwMTMsIDE3OjA5OjM3IEdNVCYjNDM7MDM6MDA8YnI+DQo8Yj5Ubzo8 L2I+IFZpbmEgRXJtYWdhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlcm1hZ2FuQGNpc2NvLmNvbSI+ dmVybWFnYW5AY2lzY28uY29tPC9hPiZndDssIERpbm8gRmFyaW5hY2NpICZsdDs8YSBocmVmPSJt YWlsdG86ZmFyaW5hY2NpQGdtYWlsLmNvbSI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwvYT4mZ3Q7LCBT aGFyb24gQmFya2FpICZsdDs8YSBocmVmPSJtYWlsdG86c2JhcmthaUBnbWFpbC5jb20iPnNiYXJr YWlAZ21haWwuY29tPC9hPiZndDssIEZhYmlvIE1haW5vICZsdDs8YSBocmVmPSJtYWlsdG86Zm1h aW5vQGNpc2NvLmNvbSI+Zm1haW5vQGNpc2NvLmNvbTwvYT4mZ3Q7LA0KIERhdmlkIE1leWVyICZs dDs8YSBocmVmPSJtYWlsdG86ZG1tQDEtNC01Lm5ldCI+ZG1tQDEtNC01Lm5ldDwvYT4mZ3Q7LCA8 YSBocmVmPSJtYWlsdG86c2JhcmthaUBnbWFpbC5jb20iPg0Kc2JhcmthaUBnbWFpbC5jb208L2E+ ICZsdDs8YSBocmVmPSJtYWlsdG86c2JhcmthaUBnbWFpbC5jb20iPnNiYXJrYWlAZ21haWwuY29t PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gPGI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1iYXJrYWktbGlzcC1uZnYtMDIudHh0PC9iPjxicj4NCjxicj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPjwvc3Bh bj48YnI+DQo8c3Bhbj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmFya2FpLWxpc3AtbmZ2 LTAyLnR4dDwvc3Bhbj48YnI+DQo8c3Bhbj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFNoYXJvbiBCYXJrYWkgYW5kIHBvc3RlZCB0byB0aGU8L3NwYW4+PGJyPg0KPHNwYW4+SUVU RiByZXBvc2l0b3J5Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+RmlsZW5h bWU6ICZuYnNwOyAmbmJzcDsgZHJhZnQtYmFya2FpLWxpc3AtbmZ2PC9zcGFuPjxicj4NCjxzcGFu PlJldmlzaW9uOiAmbmJzcDsgJm5ic3A7IDAyPC9zcGFuPjxicj4NCjxzcGFuPlRpdGxlOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTElTUCBCYXNlZCBGbG93TWFwcGluZyBmb3IgU2NhbGlu ZyBORlY8L3NwYW4+PGJyPg0KPHNwYW4+Q3JlYXRpb24gZGF0ZTogJm5ic3A7ICZuYnNwOyAyMDEz LTA3LTAyPC9zcGFuPjxicj4NCjxzcGFuPkdyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPC9zcGFuPjxicj4NCjxzcGFuPk51bWJlciBvZiBwYWdl czogMTU8L3NwYW4+PGJyPg0KPHNwYW4+VVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iYXJrYWktbGlzcC1uZnYtMDIu dHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iYXJrYWktbGlz cC1uZnYtMDIudHh0PC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj5TdGF0dXM6ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmFya2FpLWxpc3AtbmZ2Ij5odHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJhcmthaS1saXNwLW5mdjwvYT48L3NwYW4+PGJy Pg0KPHNwYW4+SHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhcmthaS1saXNw LW5mdi0wMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFya2FpLWxpc3AtbmZ2 LTAyPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj5EaWZmOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1iYXJrYWktbGlzcC1uZnYtMDIiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJhcmthaS1saXNwLW5mdi0wMjwvYT48 L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPkFic3RyYWN0Ojwvc3Bhbj48YnI+ DQo8c3Bhbj4mbmJzcDsmbmJzcDtUaGlzIGRyYWZ0IGRlc2NyaWJlcyBhbiBSRkMgNjgzMCBMb2Nh dG9yIElEIFNlcGFyYXRpb24gUHJvdG9jb2w8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7 KExJU1ApIGJhc2VkIGRpc3RyaWJ1dGVkIGZsb3ctbWFwcGluZy1mYWJyaWMgZm9yIGR5bmFtaWMg c2NhbGluZyBvZjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDt2aXJ0dWFsaXplZCBuZXR3 b3JrIGZ1bmN0aW9ucyAoTkZWKS4gJm5ic3A7TmV0d29yayBmdW5jdGlvbnMgc3VjaCBhczwvc3Bh bj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDtzdWJzY3JpYmVyLW1hbmFnZW1lbnQsIGNvbnRlbnQt b3B0aW1pemF0aW9uLCBzZWN1cml0eSBhbmQgcXVhbGl0eSBvZjwvc3Bhbj48YnI+DQo8c3Bhbj4m bmJzcDsmbmJzcDtzZXJ2aWNlLCBhcmUgdHlwaWNhbGx5IGRlbGl2ZXJlZCB1c2luZyBwcm9wcmll dGFyeSBoYXJkd2FyZTwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDthcHBsaWFuY2VzIGVt YmVkZGVkIGludG8gdGhlIG5ldHdvcmsgYXMgdHVybi1rZXkgc2VydmljZS1ub2RlcyBvcjwvc3Bh bj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDtzZXJ2aWNlLWJsYWRlcyB3aXRoaW4gcm91dGVycy4g Jm5ic3A7TmV4dCBnZW5lcmF0aW9uIG5ldHdvcmsgZnVuY3Rpb25zIGFyZTwvc3Bhbj48YnI+DQo8 c3Bhbj4mbmJzcDsmbmJzcDtiZWluZyBpbXBsZW1lbnRlZCBhcyBwdXJlIHNvZnR3YXJlIGluc3Rh bmNlcyBydW5uaW5nIG9uIHN0YW5kYXJkPC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwO3Nl cnZlcnMgLSB1bmJ1bmRsZWQgdmlydHVhbGl6ZWQgY29tcG9uZW50cyBvZiBjYXBhY2l0eSBhbmQ8 L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7ZnVuY3Rpb25hbGl0eS4gJm5ic3A7TElTUC1T RE4gYmFzZWQgZmxvdy1tYXBwaW5nLCBkeW5hbWljYWxseSBhc3NlbWJsZXM8L3NwYW4+PGJyPg0K PHNwYW4+Jm5ic3A7Jm5ic3A7dGhlc2UgY29tcG9uZW50cyB0byB3aG9sZSBzb2x1dGlvbnMgYnkg c3RlZXJpbmcgdGhlIHJpZ2h0IHRyYWZmaWMgaW48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5i c3A7dGhlIHJpZ2h0IHNlcXVlbmNlIHRvIHRoZSByaWdodCB2aXJ0dWFsIGZ1bmN0aW9uIGluc3Rh bmNlLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxz cGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxz cGFuPlRoZSBJRVRGIFNlY3JldGFyaWF0PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_153FFA41F38A4BCCA5286641AA7AC343Contextreamcom_-- From ggx@gigix.net Wed Jul 3 02:52:34 2013 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 7313611E818D for ; Wed, 3 Jul 2013 02:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkQ5dxUQd778 for ; Wed, 3 Jul 2013 02:52:30 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2BE11E8189 for ; Wed, 3 Jul 2013 02:52:29 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so5066257wes.4 for ; Wed, 03 Jul 2013 02:52:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=7C/ixmZvHeL1GXFvlRpTK588ahgj3Obz7cHnkw5OoOQ=; b=YCpqvIoxNiCuBJ8G+RKpPzHTuK1ztAVToG5BTHLI+wsomVeyzpEA9XMB7hVeZ6YSq7 Bt6v7zUWgsj6W4PZTuIyZkO8nXzLMZIu77+UxuxWqCVN0OPpXNLOQ9Tpak+li9Zm2ZFf HxD9K5KlmX111ptk5dIpUWHgUMMrBYEvzHOujDRaQNSxVLlE97i8l5J/DTsWuL2TNVs8 80jaxZXM8CP+4wqbRqepIHhs18yRCh04OcjiJdnAIpZuYuwgVRvg9f7T5cF+SlGOO01U krViKL0mmp+CrQdXYZIE6aX5mnsqJhCIPi+TynphTxkennaLtOoNxvfz+OnakWh8TuFC rsbQ== X-Received: by 10.180.38.37 with SMTP id d5mr17755143wik.37.1372845149209; Wed, 03 Jul 2013 02:52:29 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:714d:5670:e095:33d6? ([2001:660:330f:a4:714d:5670:e095:33d6]) by mx.google.com with ESMTPSA id u9sm27629849wif.6.2013.07.03.02.52.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 02:52:28 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luigi Iannone In-Reply-To: <225A8B96-A099-448D-8A24-D057FDDDF587@steffann.nl> Date: Wed, 3 Jul 2013 11:52:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C9A9BFB-A133-4840-9995-C8F92B2B2D33@gigix.net> References: <4576AF63-0544-4762-981F-427FFD010679@gmail.com> <225A8B96-A099-448D-8A24-D057FDDDF587@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQl2dbU6leZj3HSfalIxPZFNtTz6yoLnTj+IEkcF8fc5dx2JQQtKQxQTanal8300l+W/HN++ Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 09:52:34 -0000 Informal LISP get together? I am in =85. We could select one of the nearby beer garden :-) L. On 28 Jun. 2013, at 09:05 , Sander Steffann wrote: > Hi Dino, >=20 >> Would people be interested in participating? If so, I can facilitate.=20= >=20 > Sure, > Sander >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Wed Jul 3 03:08:42 2013 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 793CE21F9C69 for ; Wed, 3 Jul 2013 03:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcpyhoEGuvb1 for ; Wed, 3 Jul 2013 03:08:38 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC3521F9C50 for ; Wed, 3 Jul 2013 03:08:37 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k14so5515012wgh.17 for ; Wed, 03 Jul 2013 03:08:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jeM0Ozvrd8Vz5YlF8YeJMmVoIC59bGnK2KctjsGYFKo=; b=b5TXnzA6xxlxyiM42OrWVNoEVQoLhWUQlH5UVLKZN/FAcX98S8PRQQICyd5HgCIQcg BWVCgwzMGtpZNOFGTrhRZEpLB32Q6b9Lqy1MFFLuC4wa5FWiklG5t4ylcsCurzES7W7E 6VZ6N5HAsO4GBrtWOfj8uh37oCr2BQEj56VKnO+NLH+5ymQcXr/JrlFCz99f1gSAuQ+d MhICiLuUs2Nus3jgenzqzM8u/40SRb/O1Vd5LeO5+7OzKJoBusW5o1SPaZSvnBxfmYa0 gZi0L8iP9FXeXWjWaGE+5kk3nRosOZvG+xwm5H+CvaVCxRXkCY/FY9srzdUMrew8DNOE jYjA== X-Received: by 10.180.75.41 with SMTP id z9mr80752wiv.22.1372845633737; Wed, 03 Jul 2013 03:00:33 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:714d:5670:e095:33d6? ([2001:660:330f:a4:714d:5670:e095:33d6]) by mx.google.com with ESMTPSA id cd11sm27635914wib.10.2013.07.03.03.00.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 03:00:32 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luigi Iannone In-Reply-To: Date: Wed, 3 Jul 2013 12:00:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Terry Manderson X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQk80ApYNOH/+xAgoski6TnTgmK6Vk+9rp1zZEhmir6qppLXhI29AHmdEWAtOM+70sUBJwLU Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 10:08:42 -0000 Hi, I understand the rationale of this decision and I have no real = complains. Yet, I cannot stop thinking that Berlin would have been the right = opportunity to empty a bit the pipeline. Latest meetings had always a = full agenda.=20 There are a bunch of presentations that were scheduled in Orlando that = did not make it (I am part of the problem since I was pretty chatty in = my slot=85.). This was the opportunity to give them priority. The idea (suggested by Dino) of having an informal LISP+Beer event in = Berlin sounds good :-) Luigi On 28 Jun. 2013, at 04:03 , Terry Manderson = wrote: > Dear LISP Work Group, >=20 > We, the Co-Chairs, have been watching the workgroup closely for = activity > on the current set of documents that have been adopted. Apart from the > items which have been passed to the IESG we do not believe there has = been > significant progress, discussion, or review of these 'in-play' drafts = to > warrant having a meeting in Berlin. >=20 > We have communicated our observations with the responsible AD and = amongst > us there is full agreement to cancel the LISP session request for = Berlin. >=20 > Thus, we have done so. >=20 > To iterate, there will be NO MEETING FOR LISP at IETF87. >=20 > We do apologise if this note causes you concern. However, as chairs we > must consider the LISP workgroup outputs on their merit, and at this = stage > those outputs do not warrant using up agenda time. >=20 > If you would like to talk with us (the co-chairs) during IETF87, we = are > happy to > make hallway time to discuss ways of making progress on the WG = chartered > items. >=20 >=20 > LISP Co-Chairs > Joel and Terry > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From darlewis@cisco.com Wed Jul 3 07:51:33 2013 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 AA2C211E81C8 for ; Wed, 3 Jul 2013 07:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4nhMUtDfceP for ; Wed, 3 Jul 2013 07:51:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AE4A311E81B7 for ; Wed, 3 Jul 2013 07:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=799; q=dns/txt; s=iport; t=1372863088; x=1374072688; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JgAR4r4VUPEx10DLJZzHtS+utiDy02I3cZsYy21tMTA=; b=AUQ+fSgNG1NkKV5BTumL1Pp19DRn0ml12/aIbDmSXYMJp+AVUY/ng8CG 8qXETvAroLcWx8LhgcnquMz7WcVay7cjVlTH7s7ed8v4LH/BdqbDcGjue aD98dUlhJ4dsNTNxSpY0iP6EZFMz0SmPn+5sazXi6NKe5ZunwXrccxrQZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFALU51FGtJV2Z/2dsb2JhbABagwkySYJBvXGBAxZ0giMBAQEDAQEBAWsLBQsCAQgOCgokJwslAgQOBQiIAQYMuwIEjzoxB4MEaQOpDoMRgig X-IronPort-AV: E=Sophos;i="4.87,988,1363132800"; d="scan'208";a="230516117" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 03 Jul 2013 14:51:28 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r63EpSFq000956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 14:51:28 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 09:51:27 -0500 From: "Darrel Lewis (darlewis)" To: Luigi Iannone Thread-Topic: [lisp] No LISP meeting for Berlin Thread-Index: AQHOd/zLQvy8sWNMikOibAQ3O98DWQ== Date: Wed, 3 Jul 2013 14:51:27 +0000 Message-ID: References: <4576AF63-0544-4762-981F-427FFD010679@gmail.com> <225A8B96-A099-448D-8A24-D057FDDDF587@steffann.nl> <1C9A9BFB-A133-4840-9995-C8F92B2B2D33@gigix.net> In-Reply-To: <1C9A9BFB-A133-4840-9995-C8F92B2B2D33@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.80.19] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 14:51:33 -0000 Usually, I despise +1 emails, but in this case=85. On Jul 3, 2013, at 2:52 AM, Luigi Iannone wrote: > Informal LISP get together? >=20 > I am in =85. >=20 > We could select one of the nearby beer garden :-) >=20 +1 :-) -Darrel=20 > L. >=20 >=20 >=20 >=20 >=20 > On 28 Jun. 2013, at 09:05 , Sander Steffann wrote: >=20 >> Hi Dino, >>=20 >>> Would people be interested in participating? If so, I can facilitate.=20 >>=20 >> Sure, >> Sander >>=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 farinacci@gmail.com Wed Jul 3 09:25:21 2013 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 442A621F9CE7 for ; Wed, 3 Jul 2013 09:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLs2+NCJ9mOQ for ; Wed, 3 Jul 2013 09:25:20 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9A45C21F9CC8 for ; Wed, 3 Jul 2013 09:25:20 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so392478pad.30 for ; Wed, 03 Jul 2013 09:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=N9D1ncIOJ0nh224s1pZIq86khMgKYfwYaE5r8ELV8j0=; b=jL8bSbccTY1bqcCEKDcjaElSalbBkd0gxTd6+aE5ESTSl/TMZfBEzXn1vtiggbVtjl YKrIYIpkZ9JOjJGUh4bPE8q/02dajfRTJyLcCYwbfnVDuVGzeA2X1y/heU7uPxexcWcI KDW+FO1c3p8bFsG3iOYikST0bIFT+4WQyQb+ghCVAMf7GGmB0pYrMu0+rPb3v7jKZ1v8 E/dQemse0VWo16FcbR9kG3pAO5pTq3fDJ1NO5we9WcCT4MnNN8E1li1ionkU1D4rTtrH fhiZwFyNFrONoVXMxXJzXjauP/XPXnxcOg2iZvgJEWPfGQ27B8WKTjBaajpehQoUa2Du a2Ig== X-Received: by 10.66.189.225 with SMTP id gl1mr3235684pac.22.1372868719015; Wed, 03 Jul 2013 09:25:19 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id wg6sm5144534pbc.3.2013.07.03.09.25.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 09:25:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: Date: Wed, 3 Jul 2013 09:25:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <951171EC-A8EA-4842-92A1-22B2FD26267E@gmail.com> References: To: Luigi Iannone X-Mailer: Apple Mail (2.1503) Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 16:25:21 -0000 > Hi, >=20 > I understand the rationale of this decision and I have no real = complains. >=20 > Yet, I cannot stop thinking that Berlin would have been the right = opportunity to empty a bit the pipeline. Latest meetings had always a = full agenda.=20 I tend to agree. > There are a bunch of presentations that were scheduled in Orlando that = did not make it (I am part of the problem since I was pretty chatty in = my slot=85.). > This was the opportunity to give them priority. And there were a lot planned that I think people would have enjoyed. > The idea (suggested by Dino) of having an informal LISP+Beer event in = Berlin sounds good :-) >=20 > Luigi I think the venue needs to following requirements: (1) A quiet place so everyone can hear the presos. (2) A projector. Someone can volunteer one. (3) Allows enough time, I propose a 2.5 hour meeting. I can run the meeting and take agenda items. So there are no = limitations. Anyone want to talk about LISP, what they think it should = be, what they think they can do with it, anything, is open game. So you = university types, you deployers, you implementors, please all come and = send agenda items to me. I will post a week before IETF. Thanks everyone for being open minded. At the end of the day, it is = solely about the technology, and in my mind everything else is = secondary. Dino >=20 >=20 >=20 > On 28 Jun. 2013, at 04:03 , Terry Manderson = wrote: >=20 >> Dear LISP Work Group, >>=20 >> We, the Co-Chairs, have been watching the workgroup closely for = activity >> on the current set of documents that have been adopted. Apart from = the >> items which have been passed to the IESG we do not believe there has = been >> significant progress, discussion, or review of these 'in-play' drafts = to >> warrant having a meeting in Berlin. >>=20 >> We have communicated our observations with the responsible AD and = amongst >> us there is full agreement to cancel the LISP session request for = Berlin. >>=20 >> Thus, we have done so. >>=20 >> To iterate, there will be NO MEETING FOR LISP at IETF87. >>=20 >> We do apologise if this note causes you concern. However, as chairs = we >> must consider the LISP workgroup outputs on their merit, and at this = stage >> those outputs do not warrant using up agenda time. >>=20 >> If you would like to talk with us (the co-chairs) during IETF87, we = are >> happy to >> make hallway time to discuss ways of making progress on the WG = chartered >> items. >>=20 >>=20 >> LISP Co-Chairs >> Joel and Terry >> _______________________________________________ >> 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 cheng.li2@zte.com.cn Wed Jul 3 18:49:56 2013 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 7575D11E80A2; Wed, 3 Jul 2013 18:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.95 X-Spam-Level: X-Spam-Status: No, score=-92.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZe3volaGDn0; Wed, 3 Jul 2013 18:49:52 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D2C1B11E80E4; Wed, 3 Jul 2013 18:49:50 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id C80AD1252119; Thu, 4 Jul 2013 09:49:25 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 767B9CD9DA4; Thu, 4 Jul 2013 09:49:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r641nNVJ021674; Thu, 4 Jul 2013 09:49:23 +0800 (GMT-8) (envelope-from cheng.li2@zte.com.cn) In-Reply-To: <951171EC-A8EA-4842-92A1-22B2FD26267E@gmail.com> To: Dino Farinacci MIME-Version: 1.0 X-KeepSent: 2F1C1560:020C59E8-48257B9E:0009E694; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: cheng.li2@zte.com.cn Date: Thu, 4 Jul 2013 09:49:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-04 09:49:04, Serialize complete at 2013-07-04 09:49:04 Content-Type: multipart/alternative; boundary="=_alternative 000A0BD248257B9E_=" X-MAIL: mse01.zte.com.cn r641nNVJ021674 Cc: lisp-bounces@ietf.org, "lisp@ietf.org" Subject: [lisp] =?gb2312?b?tPC4tDogUmU6ICBObyBMSVNQIG1lZXRpbmcgZm9yIEJl?= =?gb2312?b?cmxpbg==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 01:49:56 -0000 This is a multipart message in MIME format. --=_alternative 000A0BD248257B9E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 R29vZCBpZGVhLCBkZWZpbml0ZWx5IHN1cHBvcnQuDQoNCkxpIENoZW5nDQoNCg0KbGlzcC1ib3Vu Y2VzQGlldGYub3JnINC009ogMjAxMy0wNy0wNCAwMDoyNToxNjoNCg0KPiA+IEhpLA0KPiA+IA0K PiA+IEkgdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIG9mIHRoaXMgZGVjaXNpb24gYW5kIEkgaGF2 ZSBubyByZWFsIA0KY29tcGxhaW5zLg0KPiA+IA0KPiA+IFlldCwgIEkgY2Fubm90IHN0b3AgdGhp bmtpbmcgdGhhdCBCZXJsaW4gd291bGQgaGF2ZSBiZWVuIHRoZSByaWdodA0KPiBvcHBvcnR1bml0 eSB0byBlbXB0eSBhIGJpdCB0aGUgcGlwZWxpbmUuIExhdGVzdCBtZWV0aW5ncyBoYWQgYWx3YXlz IA0KPiBhIGZ1bGwgYWdlbmRhLiANCj4gDQo+IEkgdGVuZCB0byBhZ3JlZS4NCj4gDQo+ID4gVGhl cmUgYXJlIGEgYnVuY2ggb2YgcHJlc2VudGF0aW9ucyB0aGF0IHdlcmUgc2NoZWR1bGVkIGluIE9y bGFuZG8gDQo+IHRoYXQgZGlkIG5vdCBtYWtlIGl0IChJIGFtIHBhcnQgb2YgdGhlIHByb2JsZW0g c2luY2UgSSB3YXMgcHJldHR5IA0KPiBjaGF0dHkgaW4gbXkgc2xvdKGtLikuDQo+ID4gVGhpcyB3 YXMgdGhlIG9wcG9ydHVuaXR5IHRvIGdpdmUgdGhlbSBwcmlvcml0eS4NCj4gDQo+IEFuZCB0aGVy ZSB3ZXJlIGEgbG90IHBsYW5uZWQgdGhhdCBJIHRoaW5rIHBlb3BsZSB3b3VsZCBoYXZlIGVuam95 ZWQuDQo+IA0KPiA+IFRoZSBpZGVhIChzdWdnZXN0ZWQgYnkgRGlubykgb2YgaGF2aW5nIGFuIGlu Zm9ybWFsIExJU1ArQmVlciBldmVudA0KPiBpbiBCZXJsaW4gc291bmRzIGdvb2QgOi0pDQo+ID4g DQo+ID4gTHVpZ2kNCj4gDQo+IEkgdGhpbmsgdGhlIHZlbnVlIG5lZWRzIHRvIGZvbGxvd2luZyBy ZXF1aXJlbWVudHM6DQo+IA0KPiAoMSkgQSBxdWlldCBwbGFjZSBzbyBldmVyeW9uZSBjYW4gaGVh ciB0aGUgcHJlc29zLg0KPiAoMikgQSBwcm9qZWN0b3IuIFNvbWVvbmUgY2FuIHZvbHVudGVlciBv bmUuDQo+ICgzKSBBbGxvd3MgZW5vdWdoIHRpbWUsIEkgcHJvcG9zZSBhIDIuNSBob3VyIG1lZXRp bmcuDQo+IA0KPiBJIGNhbiBydW4gdGhlIG1lZXRpbmcgYW5kIHRha2UgYWdlbmRhIGl0ZW1zLiBT byB0aGVyZSBhcmUgbm8gDQo+IGxpbWl0YXRpb25zLiBBbnlvbmUgd2FudCB0byB0YWxrIGFib3V0 IExJU1AsIHdoYXQgdGhleSB0aGluayBpdCANCj4gc2hvdWxkIGJlLCB3aGF0IHRoZXkgdGhpbmsg dGhleSBjYW4gZG8gd2l0aCBpdCwgYW55dGhpbmcsIGlzIG9wZW4gDQo+IGdhbWUuIFNvIHlvdSB1 bml2ZXJzaXR5IHR5cGVzLCB5b3UgZGVwbG95ZXJzLCB5b3UgaW1wbGVtZW50b3JzLCANCj4gcGxl YXNlIGFsbCBjb21lIGFuZCBzZW5kIGFnZW5kYSBpdGVtcyB0byBtZS4gSSB3aWxsIHBvc3QgYSB3 ZWVrIGJlZm9yZSANCklFVEYuDQo+IA0KPiBUaGFua3MgZXZlcnlvbmUgZm9yIGJlaW5nIG9wZW4g bWluZGVkLiBBdCB0aGUgZW5kIG9mIHRoZSBkYXksIGl0IGlzIA0KPiBzb2xlbHkgYWJvdXQgdGhl IHRlY2hub2xvZ3ksIGFuZCBpbiBteSBtaW5kIGV2ZXJ5dGhpbmcgZWxzZSBpcyANCnNlY29uZGFy eS4NCj4gDQo+IERpbm8NCj4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gT24gMjggSnVuLiAyMDEz LCBhdCAwNDowMyAsIFRlcnJ5IE1hbmRlcnNvbiA8dGVycnkuDQo+IG1hbmRlcnNvbkBpY2Fubi5v cmc+IHdyb3RlOg0KPiA+IA0KPiA+PiBEZWFyIExJU1AgV29yayBHcm91cCwNCj4gPj4gDQo+ID4+ IFdlLCB0aGUgQ28tQ2hhaXJzLCBoYXZlIGJlZW4gd2F0Y2hpbmcgdGhlIHdvcmtncm91cCBjbG9z ZWx5IGZvciANCmFjdGl2aXR5DQo+ID4+IG9uIHRoZSBjdXJyZW50IHNldCBvZiBkb2N1bWVudHMg dGhhdCBoYXZlIGJlZW4gYWRvcHRlZC4gQXBhcnQgZnJvbSANCnRoZQ0KPiA+PiBpdGVtcyB3aGlj aCBoYXZlIGJlZW4gcGFzc2VkIHRvIHRoZSBJRVNHIHdlIGRvIG5vdCBiZWxpZXZlIHRoZXJlIGhh cyANCmJlZW4NCj4gPj4gc2lnbmlmaWNhbnQgcHJvZ3Jlc3MsIGRpc2N1c3Npb24sIG9yIHJldmll dyBvZiB0aGVzZSAnaW4tcGxheScgZHJhZnRzIA0KdG8NCj4gPj4gd2FycmFudCBoYXZpbmcgYSBt ZWV0aW5nIGluIEJlcmxpbi4NCj4gPj4gDQo+ID4+IFdlIGhhdmUgY29tbXVuaWNhdGVkIG91ciBv YnNlcnZhdGlvbnMgd2l0aCB0aGUgcmVzcG9uc2libGUgQUQgYW5kIA0KYW1vbmdzdA0KPiA+PiB1 cyB0aGVyZSBpcyBmdWxsIGFncmVlbWVudCB0byBjYW5jZWwgdGhlIExJU1Agc2Vzc2lvbiByZXF1 ZXN0IGZvciANCkJlcmxpbi4NCj4gPj4gDQo+ID4+IFRodXMsIHdlIGhhdmUgZG9uZSBzby4NCj4g Pj4gDQo+ID4+IFRvIGl0ZXJhdGUsIHRoZXJlIHdpbGwgYmUgTk8gTUVFVElORyBGT1IgTElTUCBh dCBJRVRGODcuDQo+ID4+IA0KPiA+PiBXZSBkbyBhcG9sb2dpc2UgaWYgdGhpcyBub3RlIGNhdXNl cyB5b3UgY29uY2Vybi4gSG93ZXZlciwgYXMgY2hhaXJzIA0Kd2UNCj4gPj4gbXVzdCBjb25zaWRl ciB0aGUgTElTUCB3b3JrZ3JvdXAgb3V0cHV0cyBvbiB0aGVpciBtZXJpdCwgYW5kIGF0IHRoaXMg DQpzdGFnZQ0KPiA+PiB0aG9zZSBvdXRwdXRzIGRvIG5vdCB3YXJyYW50IHVzaW5nIHVwIGFnZW5k YSB0aW1lLg0KPiA+PiANCj4gPj4gSWYgeW91IHdvdWxkIGxpa2UgdG8gdGFsayB3aXRoIHVzICh0 aGUgY28tY2hhaXJzKSBkdXJpbmcgSUVURjg3LCB3ZSANCmFyZQ0KPiA+PiBoYXBweSB0bw0KPiA+ PiAgbWFrZSBoYWxsd2F5IHRpbWUgdG8gZGlzY3VzcyB3YXlzIG9mIG1ha2luZyBwcm9ncmVzcyBv biB0aGUgV0cgDQpjaGFydGVyZWQNCj4gPj4gIGl0ZW1zLg0KPiA+PiANCj4gPj4gDQo+ID4+IExJ U1AgQ28tQ2hhaXJzDQo+ID4+IEpvZWwgYW5kIFRlcnJ5DQo+ID4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IGxpc3AgbWFpbGluZyBsaXN0DQo+ ID4+IGxpc3BAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9saXNwDQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBsaXNwIG1haWxpbmcgbGlzdA0KPiA+IGxpc3BAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxpc3AgbWFpbGlu ZyBsaXN0DQo+IGxpc3BAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9saXNwDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5z bWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGlu dGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkg dXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBp bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlv dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVj dGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5 IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 000A0BD248257B9E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdvb2QgaWRlYSwgZGVmaW5pdGVs eSBzdXBwb3J0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+TGkgQ2hlbmc8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5saXNw LWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEzLTA3LTA0IDAwOjI1OjE2Ojxicj4NCjxicj4NCiZn dDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgdW5kZXJzdGFuZCB0 aGUgcmF0aW9uYWxlIG9mIHRoaXMgZGVjaXNpb24gYW5kIEkgaGF2ZSBubyByZWFsDQpjb21wbGFp bnMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBZZXQsICZuYnNwO0kgY2Fubm90IHN0 b3AgdGhpbmtpbmcgdGhhdCBCZXJsaW4gd291bGQgaGF2ZSBiZWVuDQp0aGUgcmlnaHQ8YnI+DQom Z3Q7IG9wcG9ydHVuaXR5IHRvIGVtcHR5IGEgYml0IHRoZSBwaXBlbGluZS4gTGF0ZXN0IG1lZXRp bmdzIGhhZCBhbHdheXMNCjxicj4NCiZndDsgYSBmdWxsIGFnZW5kYS4gPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEkgdGVuZCB0byBhZ3JlZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGVyZSBh cmUgYSBidW5jaCBvZiBwcmVzZW50YXRpb25zIHRoYXQgd2VyZSBzY2hlZHVsZWQgaW4gT3JsYW5k bw0KPGJyPg0KJmd0OyB0aGF0IGRpZCBub3QgbWFrZSBpdCAoSSBhbSBwYXJ0IG9mIHRoZSBwcm9i bGVtIHNpbmNlIEkgd2FzIHByZXR0eQ0KPGJyPg0KJmd0OyBjaGF0dHkgaW4gbXkgc2xvdKGtLiku PGJyPg0KJmd0OyAmZ3Q7IFRoaXMgd2FzIHRoZSBvcHBvcnR1bml0eSB0byBnaXZlIHRoZW0gcHJp b3JpdHkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFuZCB0aGVyZSB3ZXJlIGEgbG90IHBsYW5uZWQg dGhhdCBJIHRoaW5rIHBlb3BsZSB3b3VsZCBoYXZlIGVuam95ZWQuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZndDsgVGhlIGlkZWEgKHN1Z2dlc3RlZCBieSBEaW5vKSBvZiBoYXZpbmcgYW4gaW5mb3Jt YWwgTElTUCtCZWVyDQpldmVudDxicj4NCiZndDsgaW4gQmVybGluIHNvdW5kcyBnb29kIDotKTxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTHVpZ2k8YnI+DQomZ3Q7IDxicj4NCiZndDsg SSB0aGluayB0aGUgdmVudWUgbmVlZHMgdG8gZm9sbG93aW5nIHJlcXVpcmVtZW50czo8YnI+DQom Z3Q7IDxicj4NCiZndDsgKDEpIEEgcXVpZXQgcGxhY2Ugc28gZXZlcnlvbmUgY2FuIGhlYXIgdGhl IHByZXNvcy48YnI+DQomZ3Q7ICgyKSBBIHByb2plY3Rvci4gU29tZW9uZSBjYW4gdm9sdW50ZWVy IG9uZS48YnI+DQomZ3Q7ICgzKSBBbGxvd3MgZW5vdWdoIHRpbWUsIEkgcHJvcG9zZSBhIDIuNSBo b3VyIG1lZXRpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgY2FuIHJ1biB0aGUgbWVldGluZyBh bmQgdGFrZSBhZ2VuZGEgaXRlbXMuIFNvIHRoZXJlIGFyZSBubyA8YnI+DQomZ3Q7IGxpbWl0YXRp b25zLiBBbnlvbmUgd2FudCB0byB0YWxrIGFib3V0IExJU1AsIHdoYXQgdGhleSB0aGluayBpdCA8 YnI+DQomZ3Q7IHNob3VsZCBiZSwgd2hhdCB0aGV5IHRoaW5rIHRoZXkgY2FuIGRvIHdpdGggaXQs IGFueXRoaW5nLCBpcyBvcGVuDQo8YnI+DQomZ3Q7IGdhbWUuIFNvIHlvdSB1bml2ZXJzaXR5IHR5 cGVzLCB5b3UgZGVwbG95ZXJzLCB5b3UgaW1wbGVtZW50b3JzLCA8YnI+DQomZ3Q7IHBsZWFzZSBh bGwgY29tZSBhbmQgc2VuZCBhZ2VuZGEgaXRlbXMgdG8gbWUuIEkgd2lsbCBwb3N0IGEgd2VlayBi ZWZvcmUNCklFVEYuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyBldmVyeW9uZSBmb3IgYmVp bmcgb3BlbiBtaW5kZWQuIEF0IHRoZSBlbmQgb2YgdGhlIGRheSwgaXQgaXMNCjxicj4NCiZndDsg c29sZWx5IGFib3V0IHRoZSB0ZWNobm9sb2d5LCBhbmQgaW4gbXkgbWluZCBldmVyeXRoaW5nIGVs c2UgaXMgc2Vjb25kYXJ5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBEaW5vPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgT24gMjggSnVuLiAyMDEzLCBhdCAwNDowMyAsIFRlcnJ5IE1hbmRlcnNvbiAmbHQ7dGVycnku PGJyPg0KJmd0OyBtYW5kZXJzb25AaWNhbm4ub3JnJmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBEZWFyIExJU1AgV29yayBHcm91cCw8YnI+DQomZ3Q7ICZndDsm Z3Q7IDxicj4NCiZndDsgJmd0OyZndDsgV2UsIHRoZSBDby1DaGFpcnMsIGhhdmUgYmVlbiB3YXRj aGluZyB0aGUgd29ya2dyb3VwIGNsb3NlbHkNCmZvciBhY3Rpdml0eTxicj4NCiZndDsgJmd0OyZn dDsgb24gdGhlIGN1cnJlbnQgc2V0IG9mIGRvY3VtZW50cyB0aGF0IGhhdmUgYmVlbiBhZG9wdGVk LiBBcGFydA0KZnJvbSB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0ZW1zIHdoaWNoIGhhdmUgYmVl biBwYXNzZWQgdG8gdGhlIElFU0cgd2UgZG8gbm90IGJlbGlldmUNCnRoZXJlIGhhcyBiZWVuPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBzaWduaWZpY2FudCBwcm9ncmVzcywgZGlzY3Vzc2lvbiwgb3IgcmV2 aWV3IG9mIHRoZXNlICdpbi1wbGF5Jw0KZHJhZnRzIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB3YXJy YW50IGhhdmluZyBhIG1lZXRpbmcgaW4gQmVybGluLjxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBXZSBoYXZlIGNvbW11bmljYXRlZCBvdXIgb2JzZXJ2YXRpb25zIHdpdGgg dGhlIHJlc3BvbnNpYmxlDQpBRCBhbmQgYW1vbmdzdDxicj4NCiZndDsgJmd0OyZndDsgdXMgdGhl cmUgaXMgZnVsbCBhZ3JlZW1lbnQgdG8gY2FuY2VsIHRoZSBMSVNQIHNlc3Npb24gcmVxdWVzdA0K Zm9yIEJlcmxpbi48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgVGh1cywg d2UgaGF2ZSBkb25lIHNvLjxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBU byBpdGVyYXRlLCB0aGVyZSB3aWxsIGJlIE5PIE1FRVRJTkcgRk9SIExJU1AgYXQgSUVURjg3Ljxi cj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBXZSBkbyBhcG9sb2dpc2UgaWYg dGhpcyBub3RlIGNhdXNlcyB5b3UgY29uY2Vybi4gSG93ZXZlciwNCmFzIGNoYWlycyB3ZTxicj4N CiZndDsgJmd0OyZndDsgbXVzdCBjb25zaWRlciB0aGUgTElTUCB3b3JrZ3JvdXAgb3V0cHV0cyBv biB0aGVpciBtZXJpdCwNCmFuZCBhdCB0aGlzIHN0YWdlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aG9z ZSBvdXRwdXRzIGRvIG5vdCB3YXJyYW50IHVzaW5nIHVwIGFnZW5kYSB0aW1lLjxicj4NCiZndDsg Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJZiB5b3Ugd291bGQgbGlrZSB0byB0YWxrIHdp dGggdXMgKHRoZSBjby1jaGFpcnMpIGR1cmluZw0KSUVURjg3LCB3ZSBhcmU8YnI+DQomZ3Q7ICZn dDsmZ3Q7IGhhcHB5IHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDttYWtlIGhhbGx3YXkgdGlt ZSB0byBkaXNjdXNzIHdheXMgb2YgbWFraW5nIHByb2dyZXNzDQpvbiB0aGUgV0cgY2hhcnRlcmVk PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDtpdGVtcy48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBMSVNQIENvLUNoYWlyczxicj4NCiZn dDsgJmd0OyZndDsgSm9lbCBhbmQgVGVycnk8YnI+DQomZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBs aXNwIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsgbGlzcEBpZXRmLm9yZzxicj4NCiZn dDsgJmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBsaXNwIG1haWxpbmcgbGlzdDxicj4N CiZndDsgJmd0OyBsaXNwQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGlzcDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbGlzcCBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7IGxpc3BAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcDxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+PHBy ZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVu dCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFu ZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4g IElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJl cHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQg bm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0KDQo8YnI+PHByZT48 Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 000A0BD248257B9E_=-- From jsaldana@unizar.es Thu Jul 4 02:03:44 2013 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 DC71221F9F07 for ; Thu, 4 Jul 2013 02:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.773 X-Spam-Level: X-Spam-Status: No, score=-3.773 tagged_above=-999 required=5 tests=[AWL=-2.825, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHyWIkA92Kkh for ; Thu, 4 Jul 2013 02:03:39 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0C521F9F02 for ; Thu, 4 Jul 2013 02:03:38 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r6493Xc0019263; Thu, 4 Jul 2013 11:03:34 +0200 From: "Jose Saldana" To: Date: Thu, 4 Jul 2013 11:03:36 +0200 Organization: Universidad de Zaragoza Message-ID: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01CE78A6.21EFC8F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac54kvpmF1sVTVMpQ1+2DnMWrr/fTQ== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es 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, 04 Jul 2013 09:03:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EE_01CE78A6.21EFC8F0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Hi all, =20 I had talked with Luigi about the possibility of presenting our LISP+TCM optimization proposal in Berlin ( http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_presentation.p= df) . =20 Since there is no formal LISP meeting, I would also like to participate = in the =A1=B0informal LISP+Beer event=A1=B1 and tell you about the idea, if = you agree. I think that LISP and TCM can obtain mutual benefits. =20 Please keep me informed about that informal event! I will be in Berlin = for the TCM BOF, and also for an =A1=B0online games traffic session=A1=B1, = within the Transport Area Open meeting on Thursday. You are invited of course: http://www.youtube.com/watch?v=3D_G96ULX7Iak&feature=3Dem-upload_owner#ac= tion=3Dsh are =20 Thanks!, =20 Jose =20 De: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] En nombre de = cheng. li2@zte.com.cn Enviado el: jueves, 04 de julio de 2013 3:49 Para: Dino Farinacci CC: lisp-bounces@ietf.org; lisp@ietf.org Asunto: [lisp] =B4=F0=B8=B4: Re: No LISP meeting for Berlin =20 Good idea, definitely support.=20 Li Cheng lisp-bounces@ietf.org =D0=B4=D3=DA 2013-07-04 00:25:16: > > Hi, > >=20 > > I understand the rationale of this decision and I have no real complains. > >=20 > > Yet, I cannot stop thinking that Berlin would have been the right > opportunity to empty a bit the pipeline. Latest meetings had always=20 > a full agenda.=20 >=20 > I tend to agree. >=20 > > There are a bunch of presentations that were scheduled in Orlando=20 > that did not make it (I am part of the problem since I was pretty=20 > chatty in my slot=A1=AD.). > > This was the opportunity to give them priority. >=20 > And there were a lot planned that I think people would have enjoyed. >=20 > > The idea (suggested by Dino) of having an informal LISP+Beer event > in Berlin sounds good :-) > >=20 > > Luigi >=20 > I think the venue needs to following requirements: >=20 > (1) A quiet place so everyone can hear the presos. > (2) A projector. Someone can volunteer one. > (3) Allows enough time, I propose a 2.5 hour meeting. >=20 > I can run the meeting and take agenda items. So there are no=20 > limitations. Anyone want to talk about LISP, what they think it=20 > should be, what they think they can do with it, anything, is open=20 > game. So you university types, you deployers, you implementors,=20 > please all come and send agenda items to me. I will post a week before IETF. >=20 > Thanks everyone for being open minded. At the end of the day, it is=20 > solely about the technology, and in my mind everything else is = secondary. >=20 > Dino >=20 > >=20 > >=20 > >=20 > > On 28 Jun. 2013, at 04:03 , Terry Manderson manderson@icann.org> wrote: > >=20 > >> Dear LISP Work Group, > >>=20 > >> We, the Co-Chairs, have been watching the workgroup closely for activity > >> on the current set of documents that have been adopted. Apart from = the > >> items which have been passed to the IESG we do not believe there = has been > >> significant progress, discussion, or review of these 'in-play' = drafts to > >> warrant having a meeting in Berlin. > >>=20 > >> We have communicated our observations with the responsible AD and amongst > >> us there is full agreement to cancel the LISP session request for Berlin. > >>=20 > >> Thus, we have done so. > >>=20 > >> To iterate, there will be NO MEETING FOR LISP at IETF87. > >>=20 > >> We do apologise if this note causes you concern. However, as chairs = we > >> must consider the LISP workgroup outputs on their merit, and at = this stage > >> those outputs do not warrant using up agenda time. > >>=20 > >> If you would like to talk with us (the co-chairs) during IETF87, we = are > >> happy to > >> make hallway time to discuss ways of making progress on the WG chartered > >> items. > >>=20 > >>=20 > >> LISP Co-Chairs > >> Joel and Terry > >> _______________________________________________ > >> 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 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = (and any attachment transmitted herewith) is privileged and confidential and = is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly = prohibited. If you have received this mail in error, please delete it and notify us immediately. =20 =20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = (and any attachment transmitted herewith) is privileged and confidential and = is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly = prohibited. If you have received this mail in error, please delete it and notify us immediately. =20 =20 ------=_NextPart_000_00EE_01CE78A6.21EFC8F0 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I had talked with Luigi about the possibility of presenting our = LISP+TCM optimization proposal in Berlin (http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_p= resentation.pdf).

 

Since there is no formal LISP meeting, I would  also like to = participate in the =A1=B0informal LISP+Beer event=A1=B1 and tell you = about the idea, if you agree. I think that LISP and TCM can obtain = mutual benefits.

 

Please keep me informed about that informal event! I will be in = Berlin for the TCM BOF, and also for an =A1=B0online games traffic = session=A1=B1, within the Transport Area Open meeting on Thursday. You = are invited of course: http://www.youtube.com/watch?v=3D_G96ULX7Iak&feature=3De= m-upload_owner#action=3Dshare

 

Thanks!,

 

Jose

 

De: = lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] En nombre de = cheng.li2@zte.com.cn
Enviado el: jueves, 04 de julio de = 2013 3:49
Para: Dino Farinacci
CC: = lisp-bounces@ietf.org; lisp@ietf.org
Asunto: [lisp] = =B4=F0=B8=B4: Re: No = LISP meeting for Berlin

 


Good idea, = definitely support.

Li = Cheng


lisp-bounces@ietf.org =D0=B4=D3=DA 2013-07-04 00:25:16:

> > Hi,
> = >
> > I understand the rationale of this decision = and I have no real complains.
> >
> = > Yet,  I cannot stop thinking that Berlin would have been the = right
> opportunity to empty a bit the pipeline. Latest = meetings had always
> a full agenda.
> =
> I tend to agree.
>
> = > There are a bunch of presentations that were scheduled in Orlando =
> that did not make it (I am part of the problem since I = was pretty
> chatty in my slot=A1=AD.).
> = > This was the opportunity to give them priority.
> =
> And there were a lot planned that I think people would = have enjoyed.
>
> > The idea = (suggested by Dino) of having an informal LISP+Beer = event
> in Berlin sounds good :-)
> > =
> > Luigi
>
> I think = the venue needs to following requirements:
> =
> (1) A quiet place so everyone can hear the = presos.
> (2) A projector. Someone can volunteer = one.
> (3) Allows enough time, I propose a 2.5 hour = meeting.
>
> I can run the meeting and = take agenda items. So there are no
> limitations. Anyone = want to talk about LISP, what they think it
> should be, = what they think they can do with it, anything, is open
> = game. So you university types, you deployers, you implementors, =
> please all come and send agenda items to me. I will = post a week before IETF.
>
> Thanks = everyone for being open minded. At the end of the day, it is =
> solely about the technology, and in my mind everything = else is secondary.
>
> = Dino
>
> >
> > =
> >
> > On 28 Jun. 2013, at 04:03 = , Terry Manderson <terry.
> manderson@icann.org> = wrote:
> >
> >> Dear LISP Work = Group,
> >>
> >> We, the = Co-Chairs, have been watching the workgroup closely for = activity
> >> on the current set of documents that = have been adopted. Apart from the
> >> items which = have been passed to the IESG we do not believe there has = been
> >> significant progress, discussion, or = review of these 'in-play' drafts to
> >> warrant = having a meeting in Berlin.
> >>
> = >> We have communicated our observations with the responsible AD = and amongst
> >> us there is full agreement to = cancel the LISP session request for Berlin.
> >> =
> >> Thus, we have done so.
> = >>
> >> To iterate, there will be NO MEETING = FOR LISP at IETF87.
> >>
> >> = We do apologise if this note causes you concern. However, as chairs = we
> >> must consider the LISP workgroup outputs on = their merit, and at this stage
> >> those outputs = do not warrant using up agenda time.
> >> =
> >> If you would like to talk with us (the = co-chairs) during IETF87, we are
> >> happy = to
> >>  make hallway time to discuss ways of = making progress on the WG chartered
> >> =  items.
> >>
> >> =
> >> LISP Co-Chairs
> >> Joel = and Terry
> >> = _______________________________________________
> = >> 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

 
----------------------------------------------------=
----
ZTE =
Information Security Notice: The information contained in this mail (and =
any attachment transmitted herewith) is privileged and confidential and =
is intended for the exclusive use of the addressee(s).  If you are =
not an intended recipient, any disclosure, reproduction, distribution or =
other dissemination or use of the information contained is strictly =
prohibited.  If you have received this mail in error, please delete =
it and notify us immediately.
 

 

 
----------------------------------------------------=
----
ZTE =
Information Security Notice: The information contained in this mail (and =
any attachment transmitted herewith) is privileged and confidential and =
is intended for the exclusive use of the addressee(s).  If you are =
not an intended recipient, any disclosure, reproduction, distribution or =
other dissemination or use of the information contained is strictly =
prohibited.  If you have received this mail in error, please delete =
it and notify us immediately.
 

 

------=_NextPart_000_00EE_01CE78A6.21EFC8F0-- From zhengyli@cisco.com Wed Jul 3 23:09:46 2013 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 A0AF721F9E3B for ; Wed, 3 Jul 2013 23:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmawVuVpHfgX for ; Wed, 3 Jul 2013 23:09:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9086021F994B for ; Wed, 3 Jul 2013 23:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10816; q=dns/txt; s=iport; t=1372918180; x=1374127780; h=from:to:subject:date:message-id:mime-version; bh=WyPSqEHHrZEfX1I/aZwOXKwW3BQjITmyfZkW0vprTok=; b=NOLPg10mvs0kbgnPxuDV/DLtjLFNu03qTPE96M6w340+VXU8i3ER7Z+g 4nDqtbkd+tEwCABowNNJP788JZO2hlaPJWtUJVNDeKbKmhIKNQqk8V2Th IP3RLTeNc1NBYwzGRQ8YkePxZEJwfWnjA3OcE6a2Hdrs18IJxAA+Oifme o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACYQ1VGtJV2b/2dsb2JhbABagkVEe8A/gQsWdIIlAQRrIAEqVicEG4gHmhOgDo86gzxpA6kOgxGCKA X-IronPort-AV: E=Sophos;i="4.87,992,1363132800"; d="scan'208,217";a="230860693" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 04 Jul 2013 06:09:39 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6469cwo004841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Jul 2013 06:09:38 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.22]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 01:09:37 -0500 From: "Rockson Li (zhengyli)" To: "lisp@ietf.org" Thread-Topic: On piggyback map rec handling Thread-Index: AQHOeH0PF47Lcu3/f0uPySbFPN88oA== Date: Thu, 4 Jul 2013 06:09:06 +0000 Message-ID: <6FFCD2B684E3EE4A96850F334095D67707CA7D14@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.104.169.74] Content-Type: multipart/alternative; boundary="_000_6FFCD2B684E3EE4A96850F334095D67707CA7D14xmbalnx12ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 04 Jul 2013 09:24:21 -0700 Subject: [lisp] On piggyback map rec handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 06:09:46 -0000 --_000_6FFCD2B684E3EE4A96850F334095D67707CA7D14xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello experts, While going through piggyback map rec handling at sec 6.1.3 of RFC6830 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 "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. I find it describes three scenarios when ETR gets the piggybacked Map recor= ds. 1) it does not have this mapping in the map-cache originate a "verifying Map-Request", addressed to the map-requesting ITR Question: would the verifying Map-Request sent to the "piggybacked" EID or = directly to the ITRs using the one of RLOC in the Map records? It seems to me we need use EID, as this this is essentially the same as cas= e 3) below. 2) On "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. " 3) On "If the RLOC is not in the Locator-Set, then the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID." Question: for all the case 1),2),3), do we need to set the "A" bit for the = "verifying Map-Request" to avoid RLOC-spoofing? It seems to me we need do it for case 1) and 3), but not necessary for case= 2) Thanks Regards, -Rockson --_000_6FFCD2B684E3EE4A96850F334095D67707CA7D14xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello ex= perts,

While go= ing through piggyback map rec handling at sec 6.1.3 of RFC6830

<snip= >
   A= n ITR that is configured with mapping database information (i.e., it=
   i= s also an ETR) MAY optionally include those mappings in a
   M= ap-Request.  When an ETR configured to accept and verify such
   &= quot;piggybacked" mapping data receives such a Map-Request and it does=
   n= ot have this mapping in the map-cache, it MAY originate a "verifying
   M= ap-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
   &= quot;piggybacked" EID and the RLOC is in the Locator-Set for the entry= ,
   t= hen it may send the "verifying Map-Request" directly to the
   o= riginating Map-Request source.  If the RLOC is not in the
   L= ocator-Set, then the ETR MUST send the "verifying Map-Request" to=
   t= he "piggybacked" EID.  Doing this forces the "verifying= Map-Request"
   t= o go through the mapping database system to reach the authoritative<= /div>
   s= ource of information about that EID, guarding against RLOC-spoofing<= /div>
   i= n the "piggybacked" mapping data.
</snip>

I find it describes three scenarios when ET= R gets the piggybacked Map records.
1) it does not have this mapping in the map-cache
originate a "verify= ing Map-Request", addressed to the map-requesting ITR
Question: would t= he verifying Map-R= equest sent to the "piggybacked" EID or directly to the ITRs = using the one of RLOC in the Map records?
It seems to me we= need use EID, as this this is essentially the same as case 3) below.

2) On &q= uot;If the ETR has a Map-Cache entry that matches the
   "piggyba= cked" EID and the RLOC is in the Locator-Set for the entry,
   then it may s= end the "verifying Map-Request" directly to the
   originating Map-Request source. "
3) On &q= uot;If the RLOC is not in the
   Locator-Set, = then the ETR MUST send the "verifying Map-Request" to
   the "piggybacked" EID."

Question= : for all the case 1),2),3), do we need to set the "A" bit for th= e "verifying Map-Request" to avoid RLOC-spoofing? 
It seems= to me we need do it for case 1) and 3), but not necessary for case 2)

Thanks
Regards,=
-Rockson=

--_000_6FFCD2B684E3EE4A96850F334095D67707CA7D14xmbalnx12ciscoc_-- From farinacci@gmail.com Thu Jul 4 09:53:32 2013 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 D5D4221F9AEF for ; Thu, 4 Jul 2013 09:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.998 X-Spam-Level: * X-Spam-Status: No, score=1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvQSfvGxSej3 for ; Thu, 4 Jul 2013 09:53:31 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3769B21F90CC for ; Thu, 4 Jul 2013 09:53:31 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so1375631pbb.5 for ; Thu, 04 Jul 2013 09:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=n/HeEFHFjzKFCL/IhlTzCNTJscy6SC2ISC2ASgCMK0M=; b=06wAG8A0wYbmVZodp25NWUhipoSFRo3xT0zGBqt6P/cj4fjvyp8ErnQYWenZRhpn2i oOGy0Ej135qtualy7yUz6gKUHC8k+VydrPQx02jRDWxb48fb38BY5UAIHA/livRziRUq 0DIm4+0ZqL/BVz8CeMqdZbrNnjAO1DU/+eseePmiJ1cxb1oq2bQrWqJsuL4aSM6j+7Wj CvywgvfNogv0kOsLD0z7FgpEbiibX/gg8Rc1x9SUPJp4lrn4Yek99jeTJTXbijb22NSP VaE0mD6o2rGdxej67/kePgwD+5qymBwrAkHhSrJyFBjb1qGceLOziajU2UT75lA6i0ff ixqQ== X-Received: by 10.68.201.135 with SMTP id ka7mr1355138pbc.5.1372956810903; Thu, 04 Jul 2013 09:53:30 -0700 (PDT) Received: from [10.232.82.159] (mobile-166-137-184-062.mycingular.net. [166.137.184.62]) by mx.google.com with ESMTPSA id dg3sm3516414pbc.24.2013.07.04.09.53.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Jul 2013 09:53:29 -0700 (PDT) References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> Mime-Version: 1.0 (1.0) In-Reply-To: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> Content-Type: multipart/alternative; boundary=Apple-Mail-D8CF7227-1501-44DE-8DFE-D7F1AACC7BE1 Content-Transfer-Encoding: 7bit Message-Id: <9C515A09-1833-4905-BAF3-E557E3B41AFC@gmail.com> X-Mailer: iPhone Mail (10B350) From: Dino Farinacci Date: Thu, 4 Jul 2013 09:53:25 -0700 To: "jsaldana@unizar.es" Cc: "" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 16:53:32 -0000 --Apple-Mail-D8CF7227-1501-44DE-8DFE-D7F1AACC7BE1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jose - I will put you on the agenda. Thanks for offering.=20 To the rest of the list - I will post the agenda next week. A lot of people h= ave requested to present so I think we'll have a packed agenda.=20 I would like to poll the list to see if the time slot of Wed 5:00-8:00pm wor= ks for most people. And we can move to a beer garden or restaurant to contin= ue informal discussions afterwards.=20 We really want the LISP WG chairs to make it. Terry told me he is free and J= oel is working out if he can be free. So please send you opinions.=20 Joel and Terry, since this time slot is during the Admin Plenary do you thin= g we can just grab an open breakout room that has a projector?=20 Dino On Jul 4, 2013, at 2:03 AM, "Jose Saldana" wrote: > Hi all, > =20 > I had talked with Luigi about the possibility of presenting our LISP+TCM o= ptimization proposal in Berlin (http://diec.unizar.es/~jsaldana/personal/bud= apest_ICC_2013_presentation.pdf). > =20 > Since there is no formal LISP meeting, I would also like to participate i= n the =E2=80=9Cinformal LISP+Beer event=E2=80=9D and tell you about the idea= , if you agree. I think that LISP and TCM can obtain mutual benefits. > =20 > Please keep me informed about that informal event! I will be in Berlin for= the TCM BOF, and also for an =E2=80=9Conline games traffic session=E2=80=9D= , within the Transport Area Open meeting on Thursday. You are invited of cou= rse: http://www.youtube.com/watch?v=3D_G96ULX7Iak&feature=3Dem-upload_owner#= action=3Dshare > =20 > Thanks!, > =20 > Jose > =20 > De: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] En nombre de chen= g.li2@zte.com.cn > Enviado el: jueves, 04 de julio de 2013 3:49 > Para: Dino Farinacci > CC: lisp-bounces@ietf.org; lisp@ietf.org > Asunto: [lisp] =E7=AD=94=E5=A4=8D: Re: No LISP meeting for Berlin > =20 >=20 > Good idea, definitely support.=20 >=20 > Li Cheng >=20 >=20 > lisp-bounces@ietf.org =E5=86=99=E4=BA=8E 2013-07-04 00:25:16: >=20 > > > Hi, > > >=20 > > > I understand the rationale of this decision and I have no real complai= ns. > > >=20 > > > Yet, I cannot stop thinking that Berlin would have been the right > > opportunity to empty a bit the pipeline. Latest meetings had always=20 > > a full agenda.=20 > >=20 > > I tend to agree. > >=20 > > > There are a bunch of presentations that were scheduled in Orlando=20 > > that did not make it (I am part of the problem since I was pretty=20 > > chatty in my slot=E2=80=A6.). > > > This was the opportunity to give them priority. > >=20 > > And there were a lot planned that I think people would have enjoyed. > >=20 > > > The idea (suggested by Dino) of having an informal LISP+Beer event > > in Berlin sounds good :-) > > >=20 > > > Luigi > >=20 > > I think the venue needs to following requirements: > >=20 > > (1) A quiet place so everyone can hear the presos. > > (2) A projector. Someone can volunteer one. > > (3) Allows enough time, I propose a 2.5 hour meeting. > >=20 > > I can run the meeting and take agenda items. So there are no=20 > > limitations. Anyone want to talk about LISP, what they think it=20 > > should be, what they think they can do with it, anything, is open=20 > > game. So you university types, you deployers, you implementors,=20 > > please all come and send agenda items to me. I will post a week before I= ETF. > >=20 > > Thanks everyone for being open minded. At the end of the day, it is=20 > > solely about the technology, and in my mind everything else is secondary= . > >=20 > > Dino > >=20 > > >=20 > > >=20 > > >=20 > > > On 28 Jun. 2013, at 04:03 , Terry Manderson > manderson@icann.org> wrote: > > >=20 > > >> Dear LISP Work Group, > > >>=20 > > >> We, the Co-Chairs, have been watching the workgroup closely for activ= ity > > >> on the current set of documents that have been adopted. Apart from th= e > > >> items which have been passed to the IESG we do not believe there has b= een > > >> significant progress, discussion, or review of these 'in-play' drafts= to > > >> warrant having a meeting in Berlin. > > >>=20 > > >> We have communicated our observations with the responsible AD and amo= ngst > > >> us there is full agreement to cancel the LISP session request for Ber= lin. > > >>=20 > > >> Thus, we have done so. > > >>=20 > > >> To iterate, there will be NO MEETING FOR LISP at IETF87. > > >>=20 > > >> We do apologise if this note causes you concern. However, as chairs w= e > > >> must consider the LISP workgroup outputs on their merit, and at this s= tage > > >> those outputs do not warrant using up agenda time. > > >>=20 > > >> If you would like to talk with us (the co-chairs) during IETF87, we a= re > > >> happy to > > >> make hallway time to discuss ways of making progress on the WG chart= ered > > >> items. > > >>=20 > > >>=20 > > >> LISP Co-Chairs > > >> Joel and Terry > > >> _______________________________________________ > > >> 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 > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 > =20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (a= nd any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an int= ended recipient, any disclosure, reproduction, distribution or other dissemi= nation or use of the information contained is strictly prohibited. If you h= ave received this mail in error, please delete it and notify us immediately.= > =20 > =20 >=20 > =20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (a= nd any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an int= ended recipient, any disclosure, reproduction, distribution or other dissemi= nation or use of the information contained is strictly prohibited. If you h= ave received this mail in error, please delete it and notify us immediately.= > =20 > =20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-D8CF7227-1501-44DE-8DFE-D7F1AACC7BE1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Jose - I will put you on the agenda. T= hanks for offering. 

To the rest of the list -= I will post the agenda next week. A lot of people have requested to present= so I think we'll have a packed agenda. 

I wou= ld like to poll the list to see if the time slot of Wed 5:00-8:00pm works fo= r most people. And we can move to a beer garden or restaurant to continue in= formal discussions afterwards. 

We really want= the LISP WG chairs to make it. Terry told me he is free and Joel is working= out if he can be free. So please send you opinions. 

Joel and Terry, since this time slot is during the Admin Plenary do y= ou thing we can just grab an open breakout room that has a projector? <= /div>

Dino


On Jul 4, 2013, a= t 2:03 AM, "Jose Saldana" <jsaldana= @unizar.es> wrote:

Hi all,

 

I had talked with Luigi= about the possibility of presenting our LISP+TCM optimization proposal in B= erlin (http://diec.unizar.es/~jsalda= na/personal/budapest_ICC_2013_presentation.pdf).

 

 

Please keep me informed about that informal event! I= will be in Berlin for the TCM BOF, and also for an =E2=80=9Conline games tr= affic session=E2=80=9D, within the Transport Area Open meeting on Thursday. Y= ou are invited of course: http://www.youtube.com/watch?v=3D_G96ULX7Iak&feature=3Dem-upload_owne= r#action=3Dshare

Thanks!,

 

Jose

 = ;

De:= lisp-bounces= @ietf.org [mailto:lisp-bounces@= ietf.org] En nombre de ch= eng.li2@zte.com.cn
Enviado el: jueves, 04 de julio de 2013 3:4= 9
Para: Dino Farinacci
CC: lisp-bounces@ietf.org; lisp= @ietf.org
Asunto: [lisp] =E7=AD=94=E5=A4=8D: Re: No LISP meeting f= or Berlin

 = ;


Good idea, definitely support.

Li Cheng


lisp-bounces@ietf.org =E5=86=99=E4=BA=8E= 2013-07-04 00:25:16:
> > Hi,
> >
> > I unders= tand the rationale of this decision and I have no real complains.
> >
> > Yet,  I cannot stop thinking that Be= rlin would have been the right
> opportunity to empty a bit t= he pipeline. Latest meetings had always
> a full agenda.
>
> I tend to agree.
>
= > > There are a bunch of presentations that were scheduled in Orla= ndo
> that did not make it (I am part of the problem since I= was pretty
> chatty in my slot=E2=80=A6.).
>= > This was the opportunity to give them priority.
> =
> And there were a lot planned that I think people would have enj= oyed.
>
> > The idea (suggested by Dino) o= f having an informal LISP+Beer event
> in Berlin sounds good := -)
> >
> > Luigi
> =
> I think the venue needs to following requirements:
= >
> (1) A quiet place so everyone can hear the presos.
> (2) A projector. Someone can volunteer one.
> (= 3) Allows enough time, I propose a 2.5 hour meeting.
> <= br>> I can run the meeting and take agenda items. So there are no
> limitations. Anyone want to talk about LISP, what they think i= t
> should be, what they think they can do with it, anything= , is open
> game. So you university types, you deployers, yo= u implementors,
> please all come and send agenda items to m= e. I will post a week before IETF.
>
> Thanks= everyone for being open minded. At the end of the day, it is
&= gt; solely about the technology, and in my mind everything else is secondary= .
>
> Dino
>
>= >
> >
> >
> > O= n 28 Jun. 2013, at 04:03 , Terry Manderson <terry.
> manderson@icann.org> wrote:> >
> >> Dear LISP Work Group,
= > >>
> >> We, the Co-Chairs, have been watchi= ng the workgroup closely for activity
> >> on the curre= nt set of documents that have been adopted. Apart from the
> &= gt;> items which have been passed to the IESG we do not believe there has= been
> >> significant progress, discussion, or review o= f these 'in-play' drafts to
> >> warrant having a meeti= ng in Berlin.
> >>
> >> We have c= ommunicated our observations with the responsible AD and amongst
> >> us there is full agreement to cancel the LISP session request= for Berlin.
> >>
> >> Thus, we h= ave done so.
> >>
> >> To iterate= , there will be NO MEETING FOR LISP at IETF87.
> >>
> >> We do apologise if this note causes you concern. How= ever, as chairs we
> >> must consider the LISP workgrou= p outputs on their merit, and at this stage
> >> those o= utputs do not warrant using up agenda time.
> >> <= br>> >> If you would like to talk with us (the co-chairs) durin= g IETF87, we are
> >> happy to
> >>= ;  make hallway time to discuss ways of making progress on the WG chart= ered
> >>  items.
> >> <= br>> >>
> >> LISP Co-Chairs
&= gt; >> Joel and Terry
> >> ______________________= _________________________
> >> lisp mailing list> >> lisp@ietf.org<= br>> >> = 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

 
----------------------------------=
----------------------
ZTE Information Security Notice: The information contained in this mail (a=
nd any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not a=
n intended recipient, any disclosure, reproduction, distribution or other di=
ssemination or use of the information contained is strictly prohibited. =
; If you have received this mail in error, please delete it and notify us im=
mediately.
 =
;

 

 <=
/pre>
---------------------------------------=
-----------------
ZTE=
 Information Security Notice: The information contained in this mail (and an=
y attachment transmitted herewith) is privileged and confidential and is int=
ended for the exclusive use of the addressee(s).  If you are not an int=
ended recipient, any disclosure, reproduction, distribution or other dissemi=
nation or use of the information contained is strictly prohibited.  If y=
ou have received this mail in error, please delete it and notify us immediat=
ely.
 
 
=
__________________________= _____________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listi= nfo/lisp
= --Apple-Mail-D8CF7227-1501-44DE-8DFE-D7F1AACC7BE1-- From farinacci@gmail.com Thu Jul 4 10:58:04 2013 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 2989521F9F25 for ; Thu, 4 Jul 2013 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-YMDZ0IIwC9 for ; Thu, 4 Jul 2013 10:58:03 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B134C21F9E73 for ; Thu, 4 Jul 2013 10:58:03 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so1519847pad.0 for ; Thu, 04 Jul 2013 10:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=mop+eIujmZCt724mVWpAv/9tBSzlr5Khm32BlYoeZdw=; b=WH5dTVHI2iJShzfoeAKdsBQu4r/w/NWnZeiB9bykPmDaPagf0qHB3B+s6PZsjaraad qmuE3/lkEbuR5Pp/ZH2PRE1D8dDTmuiuB6cHyc71m6Zz8JCkxp80cYc6atNSHehxJKgG 3zy1YZ6Pwm9MwgJgAURYb8yUqYiNjz1rpud311Eks2zS1Q2r2pyQWgEPZAY3wr1CsXCt /S5sOxZtAhE1uqLbPvSmWP7Oj9vjK10WK/25rAnO46E9EPWjwEm+iqtLOZJQ7ckUNZAf Pk+rBsZVF9JOYKaN+d+t7p7hTmRJVYYDM0vLYfworYGvQMCyaTff+sAY9JJovdN2hQUu 46Qg== X-Received: by 10.68.179.194 with SMTP id di2mr6375886pbc.203.1372960683470; Thu, 04 Jul 2013 10:58:03 -0700 (PDT) Received: from [192.168.1.6] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id p2sm4295991pag.22.2013.07.04.10.58.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Jul 2013 10:58:02 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9748DA7C-98F7-41C4-B9FE-775002014E9A@gmail.com> Date: Thu, 4 Jul 2013 10:58:00 -0700 To: "lisp@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [lisp] All Things LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 17:58:04 -0000 Here is a rough agenda for the "All Things LISP" focus group we are = having in Berlin.=20 Just to be clear, this is not an IETF working group. It is not a = substitute for the LISP working group. It is just taking advantage of = having a common place where interested LISPers will be together. The agenda will keep changing to accommodate as many speakers that want = to say something about LISP. Yes, the agenda below is time planned for 3 = hours and currently is 200 minutes allocated. No worries, we will adjust = over time. Not all these slots have been approved by the presenters. It is just a = work in progress agenda which I would like to keep open and transparent. = If anyone not on agenda wants to be on it, please notify me. We are hoping that Wednesday of IETF week 5:00-8:00pm works for most = people. It would be good to get an RSVP so we can capacity plan a room. Thanks everyone! Dino = --------------------------------------------------------------------------= ----- Agenda - "All Things LISP" Intro: =09 Agenda ground rules Dino 5 Future of LISP Dino 10 Use-Cases: Signal-less LISP-Multicast Dino 15 LISP-NFV Sharon 15 Layer-2 LISP for NVO3 Fabio 15 LISP-RE Florin 15 Network in the Cloud Damien 15 VXLAN, P-bit, and LISP Darrel 5=20 Deployment Status: Vendor A Vendor V Other Vendor/Operator ciscoLIve Update Darrel 15 LISPMOB Update Albert 15 Research Status: LISP-Lab Luigi 10 LISP-Views Luigi 10 Global Mapping Database Terry 10 LISP TCM Jose 10 =20 IETF Things: Deployment Draft Update Darrel 10 Status on Arch & Intro Drafts Darrel 5 PIM changes for LISP-Multicast Isidor 10 SH-DHT Li/Mo 10 Homenet Multihoming Damien 10 Total: = 200-out-of-180 = --------------------------------------------------------------------------= ----- From jmh@joelhalpern.com Thu Jul 4 11:24:56 2013 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 E9ADB21F99D0 for ; Thu, 4 Jul 2013 11:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.953 X-Spam-Level: X-Spam-Status: No, score=-100.953 tagged_above=-999 required=5 tests=[AWL=-1.554, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjemdCHOmmq1 for ; Thu, 4 Jul 2013 11:24:51 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id E1CE121F9590 for ; Thu, 4 Jul 2013 11:24:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CA6961C9E3F; Thu, 4 Jul 2013 11:24:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-124.clppva.east.verizon.net [70.106.134.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C9A701C07AA; Thu, 4 Jul 2013 11:24:49 -0700 (PDT) Message-ID: <51D5BDEB.7000602@joelhalpern.com> Date: Thu, 04 Jul 2013 14:24:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dino Farinacci References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <9C515A09-1833-4905-BAF3-E557E3B41AFC@gmail.com> In-Reply-To: <9C515A09-1833-4905-BAF3-E557E3B41AFC@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 18:24:56 -0000 I do not know if I will be able to make it. (As the IAB liaison to the IESG, I really should be at the administrative plenary.) As for rooms, procedurally even during the plenary you are supposed to have secretariat approval for using a room for a meeting. And that will require AD signoff. Yours, Joel On 7/4/2013 12:53 PM, Dino Farinacci wrote: > Jose - I will put you on the agenda. Thanks for offering. > > To the rest of the list - I will post the agenda next week. A lot of > people have requested to present so I think we'll have a packed agenda. > > I would like to poll the list to see if the time slot of Wed 5:00-8:00pm > works for most people. And we can move to a beer garden or restaurant to > continue informal discussions afterwards. > > We really want the LISP WG chairs to make it. Terry told me he is free > and Joel is working out if he can be free. So please send you opinions. > > Joel and Terry, since this time slot is during the Admin Plenary do you > thing we can just grab an open breakout room that has a projector? > > Dino > > > On Jul 4, 2013, at 2:03 AM, "Jose Saldana" > wrote: > >> Hi all, >> >> I had talked with Luigi about the possibility of presenting our >> LISP+TCM optimization proposal in Berlin >> (http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_presentation.pdf). >> >> Since there is no formal LISP meeting, I would also like to >> participate in the “informal LISP+Beer event” and tell you about the >> idea, if you agree. I think that LISP and TCM can obtain mutual benefits. >> >> Please keep me informed about that informal event! I will be in Berlin >> for the TCM BOF, and also for an “online games traffic session”, >> within the Transport Area Open meeting on Thursday. You are invited of >> course: >> http://www.youtube.com/watch?v=_G96ULX7Iak&feature=em-upload_owner#action=share >> >> Thanks!, >> >> Jose >> >> *De:*lisp-bounces@ietf.org >> [mailto:lisp-bounces@ietf.org] *En nombre de *cheng.li2@zte.com.cn >> >> *Enviado el:* jueves, 04 de julio de 2013 3:49 >> *Para:* Dino Farinacci >> *CC:* lisp-bounces@ietf.org ; >> lisp@ietf.org >> *Asunto:* [lisp] 答复: Re: No LISP meeting for Berlin >> >> >> Good idea, definitely support. >> >> Li Cheng >> >> >> lisp-bounces@ietf.org 写于 2013-07-04 >> 00:25:16: >> >> > > Hi, >> > > >> > > I understand the rationale of this decision and I have no real complains. >> > > >> > > Yet, I cannot stop thinking that Berlin would have been the right >> > opportunity to empty a bit the pipeline. Latest meetings had always >> > a full agenda. >> > >> > I tend to agree. >> > >> > > There are a bunch of presentations that were scheduled in Orlando >> > that did not make it (I am part of the problem since I was pretty >> > chatty in my slot….). >> > > This was the opportunity to give them priority. >> > >> > And there were a lot planned that I think people would have enjoyed. >> > >> > > The idea (suggested by Dino) of having an informal LISP+Beer event >> > in Berlin sounds good :-) >> > > >> > > Luigi >> > >> > I think the venue needs to following requirements: >> > >> > (1) A quiet place so everyone can hear the presos. >> > (2) A projector. Someone can volunteer one. >> > (3) Allows enough time, I propose a 2.5 hour meeting. >> > >> > I can run the meeting and take agenda items. So there are no >> > limitations. Anyone want to talk about LISP, what they think it >> > should be, what they think they can do with it, anything, is open >> > game. So you university types, you deployers, you implementors, >> > please all come and send agenda items to me. I will post a week before IETF. >> > >> > Thanks everyone for being open minded. At the end of the day, it is >> > solely about the technology, and in my mind everything else is secondary. >> > >> > Dino >> > >> > > >> > > >> > > >> > > On 28 Jun. 2013, at 04:03 , Terry Manderson > >manderson@icann.org > wrote: >> > > >> > >> Dear LISP Work Group, >> > >> >> > >> We, the Co-Chairs, have been watching the workgroup closely for activity >> > >> on the current set of documents that have been adopted. Apart from the >> > >> items which have been passed to the IESG we do not believe there has been >> > >> significant progress, discussion, or review of these 'in-play' drafts to >> > >> warrant having a meeting in Berlin. >> > >> >> > >> We have communicated our observations with the responsible AD and amongst >> > >> us there is full agreement to cancel the LISP session request for Berlin. >> > >> >> > >> Thus, we have done so. >> > >> >> > >> To iterate, there will be NO MEETING FOR LISP at IETF87. >> > >> >> > >> We do apologise if this note causes you concern. However, as chairs we >> > >> must consider the LISP workgroup outputs on their merit, and at this stage >> > >> those outputs do not warrant using up agenda time. >> > >> >> > >> If you would like to talk with us (the co-chairs) during IETF87, we are >> > >> happy to >> > >> make hallway time to discuss ways of making progress on the WG chartered >> > >> items. >> > >> >> > >> >> > >> LISP Co-Chairs >> > >> Joel and Terry >> > >> _______________________________________________ >> > >> 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 >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. >> >> >> _______________________________________________ >> 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 elopez@fortinet.com Thu Jul 4 17:21:59 2013 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 A56A111E8105 for ; Thu, 4 Jul 2013 17:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvPh+X6HVM+T for ; Thu, 4 Jul 2013 17:21:55 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id 759BF21F99FA for ; Thu, 4 Jul 2013 17:21:55 -0700 (PDT) From: Edward Lopez To: Luigi Iannone Thread-Topic: [lisp] No LISP meeting for Berlin Thread-Index: Ac5zo7iY5mCoajswR++PaeEgPYCu6gAR5leAAAdLHoABAUzyAABB/QZg Date: Fri, 5 Jul 2013 00:21:53 +0000 Message-ID: <1944F894-614F-471B-8AA8-C15A22D252E4@fortinet.com> References: <4576AF63-0544-4762-981F-427FFD010679@gmail.com> <225A8B96-A099-448D-8A24-D057FDDDF587@steffann.nl>, <1C9A9BFB-A133-4840-9995-C8F92B2B2D33@gigix.net> In-Reply-To: <1C9A9BFB-A133-4840-9995-C8F92B2B2D33@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2013 00:21:59 -0000 I'm interested in attending this Ed Lopez - Fortinet VP, Technology 1090 Kifer Road Sunnyvale, CA 94086 +1 703 220 0988 Sent from my iPhone ... Sorry for any auto-correct errors On Jul 3, 2013, at 5:52 AM, "Luigi Iannone" wrote: > Informal LISP get together? > > I am in =85. > > We could select one of the nearby beer garden :-) > > L. > > > > > > On 28 Jun. 2013, at 09:05 , Sander Steffann wrote:= > >> Hi Dino, >> >>> Would people be interested in participating? If so, I can facilitate.= >> >> Sure, >> Sander >> >> _______________________________________________ >> 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 *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** From jsaldana@unizar.es Fri Jul 5 00:26:22 2013 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 8CF5A11E8260 for ; Fri, 5 Jul 2013 00:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[AWL=-1.398, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7HF4MrBHXGW for ; Fri, 5 Jul 2013 00:26:18 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 91B6711E825D for ; Fri, 5 Jul 2013 00:26:16 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r657QBvC012584; Fri, 5 Jul 2013 09:26:11 +0200 From: "Jose Saldana" To: "'Dino Farinacci'" References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <9C515A09-1833-4905-BAF3-E557E3B41AFC@gmail.com> In-Reply-To: <9C515A09-1833-4905-BAF3-E557E3B41AFC@gmail.com> Date: Fri, 5 Jul 2013 09:26:13 +0200 Organization: Universidad de Zaragoza Message-ID: <003601ce7950$ee41b030$cac51090$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01CE7961.B1CF6230" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLByKTFlclOZ5AVcAgmKHvNI5577gFZHuool2RHStA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es 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, 05 Jul 2013 07:26:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0037_01CE7961.B1CF6230 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ok. I will prepare the presentation. Is a 10 minutes presentation ok? =20 Jose =20 De: Dino Farinacci [mailto:farinacci@gmail.com]=20 Enviado el: jueves, 04 de julio de 2013 18:53 Para: jsaldana@unizar.es CC: Asunto: Re: [lisp] No LISP meeting for Berlin =20 Jose - I will put you on the agenda. Thanks for offering.=20 =20 To the rest of the list - I will post the agenda next week. A lot of = people have requested to present so I think we'll have a packed agenda.=20 =20 I would like to poll the list to see if the time slot of Wed 5:00-8:00pm = works for most people. And we can move to a beer garden or restaurant to = continue informal discussions afterwards.=20 =20 We really want the LISP WG chairs to make it. Terry told me he is free = and Joel is working out if he can be free. So please send you opinions.=20 =20 Joel and Terry, since this time slot is during the Admin Plenary do you = thing we can just grab an open breakout room that has a projector?=20 =20 Dino =20 On Jul 4, 2013, at 2:03 AM, "Jose Saldana" wrote: Hi all, =20 I had talked with Luigi about the possibility of presenting our LISP+TCM = optimization proposal in Berlin ( = = http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_presentation.p= df). =20 Since there is no formal LISP meeting, I would also like to participate = in the =E2=80=9Cinformal LISP+Beer event=E2=80=9D and tell you about the = idea, if you agree. I think that LISP and TCM can obtain mutual = benefits. =20 Please keep me informed about that informal event! I will be in Berlin = for the TCM BOF, and also for an =E2=80=9Conline games traffic = session=E2=80=9D, within the Transport Area Open meeting on Thursday. = You are invited of course: = = http://www.youtube.com/watch?v=3D_G96ULX7Iak&feature=3Dem-upload_owner#ac= tion=3Dshare =20 Thanks!, =20 Jose =20 De: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] En nombre de = cheng.li2@zte.com.cn Enviado el: jueves, 04 de julio de 2013 3:49 Para: Dino Farinacci CC: lisp-bounces@ietf.org; lisp@ietf.org Asunto: [lisp] =E7=AD=94=E5=A4=8D: Re: No LISP meeting for Berlin =20 Good idea, definitely support.=20 Li Cheng lisp-bounces@ietf.org =E5=86=99=E4=BA=8E 2013-07-04 00:25:16: > > Hi, > >=20 > > I understand the rationale of this decision and I have no real = complains. > >=20 > > Yet, I cannot stop thinking that Berlin would have been the right > opportunity to empty a bit the pipeline. Latest meetings had always=20 > a full agenda.=20 >=20 > I tend to agree. >=20 > > There are a bunch of presentations that were scheduled in Orlando=20 > that did not make it (I am part of the problem since I was pretty=20 > chatty in my slot=E2=80=A6.). > > This was the opportunity to give them priority. >=20 > And there were a lot planned that I think people would have enjoyed. >=20 > > The idea (suggested by Dino) of having an informal LISP+Beer event > in Berlin sounds good :-) > >=20 > > Luigi >=20 > I think the venue needs to following requirements: >=20 > (1) A quiet place so everyone can hear the presos. > (2) A projector. Someone can volunteer one. > (3) Allows enough time, I propose a 2.5 hour meeting. >=20 > I can run the meeting and take agenda items. So there are no=20 > limitations. Anyone want to talk about LISP, what they think it=20 > should be, what they think they can do with it, anything, is open=20 > game. So you university types, you deployers, you implementors,=20 > please all come and send agenda items to me. I will post a week before = IETF. >=20 > Thanks everyone for being open minded. At the end of the day, it is=20 > solely about the technology, and in my mind everything else is = secondary. >=20 > Dino >=20 > >=20 > >=20 > >=20 > > On 28 Jun. 2013, at 04:03 , Terry Manderson manderson@icann.org> wrote: > >=20 > >> Dear LISP Work Group, > >>=20 > >> We, the Co-Chairs, have been watching the workgroup closely for = activity > >> on the current set of documents that have been adopted. Apart from = the > >> items which have been passed to the IESG we do not believe there = has been > >> significant progress, discussion, or review of these 'in-play' = drafts to > >> warrant having a meeting in Berlin. > >>=20 > >> We have communicated our observations with the responsible AD and = amongst > >> us there is full agreement to cancel the LISP session request for = Berlin. > >>=20 > >> Thus, we have done so. > >>=20 > >> To iterate, there will be NO MEETING FOR LISP at IETF87. > >>=20 > >> We do apologise if this note causes you concern. However, as chairs = we > >> must consider the LISP workgroup outputs on their merit, and at = this stage > >> those outputs do not warrant using up agenda time. > >>=20 > >> If you would like to talk with us (the co-chairs) during IETF87, we = are > >> happy to > >> make hallway time to discuss ways of making progress on the WG = chartered > >> items. > >>=20 > >>=20 > >> LISP Co-Chairs > >> Joel and Terry > >> _______________________________________________ > >> 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 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = (and any attachment transmitted herewith) is privileged and confidential = and is intended for the exclusive use of the addressee(s). If you are = not an intended recipient, any disclosure, reproduction, distribution or = other dissemination or use of the information contained is strictly = prohibited. If you have received this mail in error, please delete it = and notify us immediately. =20 =20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = (and any attachment transmitted herewith) is privileged and confidential = and is intended for the exclusive use of the addressee(s). If you are = not an intended recipient, any disclosure, reproduction, distribution or = other dissemination or use of the information contained is strictly = prohibited. If you have received this mail in error, please delete it = and notify us immediately. =20 =20 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ------=_NextPart_000_0037_01CE7961.B1CF6230 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Ok. I will prepare the presentation. Is a 10 minutes presentation = ok?

 

Jose

 

De: Dino Farinacci [mailto:farinacci@gmail.com]
Enviado = el: jueves, 04 de julio de 2013 18:53
Para: = jsaldana@unizar.es
CC: <lisp@ietf.org>
Asunto: = Re: [lisp] No LISP meeting for = Berlin

 

Jose - = I will put you on the agenda. Thanks for = offering. 

 

To the rest of the list - I will post the agenda next = week. A lot of people have requested to present so I think we'll have a = packed agenda. 

 

I = would like to poll the list to see if the time slot of Wed 5:00-8:00pm = works for most people. And we can move to a beer garden or restaurant to = continue informal discussions = afterwards. 

 

We really want the LISP WG chairs to make it. Terry = told me he is free and Joel is working out if he can be free. So please = send you opinions. 

 

Joel and Terry, since this time slot is during the = Admin Plenary do you thing we can just grab an open breakout room that = has a projector? 

 

Dino

 


On Jul 4, 2013, at 2:03 AM, = "Jose Saldana" <jsaldana@unizar.es> = wrote:

Hi all,

 

I had talked with Luigi about the possibility of presenting our = LISP+TCM optimization proposal in Berlin (http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_p= resentation.pdf).

 

Since there is no formal LISP meeting, I would  also like to = participate in the =E2=80=9Cinformal LISP+Beer event=E2=80=9D and tell = you about the idea, if you agree. I think that LISP and TCM can obtain = mutual benefits.

 

Please keep me informed about that informal event! I will be in = Berlin for the TCM BOF, and also for an =E2=80=9Conline games traffic = session=E2=80=9D, within the Transport Area Open meeting on Thursday. = You are invited of course: http://www.youtube.com/watch?v=3D_G96ULX7Iak&feature=3De= m-upload_owner#action=3Dshare

 

Thanks!,

 

Jose

 

De: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] = En nombre de cheng.li2@zte.com.cn
Envia= do el: jueves, 04 de julio de 2013 3:49
Para: Dino = Farinacci
CC: lisp-bounces@ietf.org; lisp@ietf.org
Asunto: [lisp] = =E7=AD=94=E5=A4=8D: Re: No = LISP meeting for Berlin

 


Good idea, = definitely support.

Li = Cheng


lisp-bounces@ietf.org =E5=86=99=E4=BA=8E 2013-07-04 = 00:25:16:

> > Hi,
> >
> > I understand the rationale of this = decision and I have no real complains.
> >
> > Yet,  I cannot stop thinking = that Berlin would have been the right
> opportunity to empty a bit the pipeline. = Latest meetings had always
> a full agenda.
>
> I tend to agree.
>
> > There are a bunch of presentations = that were scheduled in Orlando
> that did not make it (I am part of the = problem since I was pretty
> chatty in my = slot=E2=80=A6.).
> > This was the opportunity to give = them priority.
>
> And there were a lot planned that I = think people would have enjoyed.
>
> > The idea (suggested by Dino) of = having an informal LISP+Beer event
> in Berlin sounds good = :-)
> >
> > Luigi
>
> I think the venue needs to following = requirements:
>
> (1) A quiet place so everyone can hear = the presos.
> (2) A projector. Someone can volunteer = one.
> (3) Allows enough time, I propose a 2.5 = hour meeting.
>
> I can run the meeting and take agenda = items. So there are no
> limitations. Anyone want to talk about = LISP, what they think it
> should be, what they think they can do = with it, anything, is open
> game. So you university types, you = deployers, you implementors,
> please all come and send agenda items to = me. I will post a week before IETF.
>
> Thanks everyone for being open minded. = At the end of the day, it is
> solely about the technology, and in my = mind everything else is secondary.
>
> Dino
>
> >
> >
> >
> > On 28 Jun. 2013, at 04:03 , Terry = Manderson <terry.
> manderson@icann.org> = wrote:
> >
> >> Dear LISP Work = Group,
> >>
> >> We, the Co-Chairs, have been = watching the workgroup closely for activity
> >> on the current set of documents = that have been adopted. Apart from the
> >> items which have been passed to = the IESG we do not believe there has been
> >> significant progress, = discussion, or review of these 'in-play' drafts to
> >> warrant having a meeting in = Berlin.
> >>
> >> We have communicated our = observations with the responsible AD and amongst
> >> us there is full agreement to = cancel the LISP session request for Berlin.
> >>
> >> Thus, we have done = so.
> >>
> >> To iterate, there will be NO = MEETING FOR LISP at IETF87.
> >>
> >> We do apologise if this note = causes you concern. However, as chairs we
> >> must consider the LISP = workgroup outputs on their merit, and at this stage
> >> those outputs do not warrant = using up agenda time.
> >>
> >> If you would like to talk with = us (the co-chairs) during IETF87, we are
> >> happy to
> >>  make hallway time to = discuss ways of making progress on the WG chartered
> >>  items.
> >>
> >>
> >> LISP Co-Chairs
> >> Joel and Terry
> >> = _______________________________________________
> >> 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

 
----------------------------------------------------=
----
ZTE =
Information Security Notice: The information contained in this mail (and =
any attachment transmitted herewith) is privileged and confidential and =
is intended for the exclusive use of the addressee(s).  If you are =
not an intended recipient, any disclosure, reproduction, distribution or =
other dissemination or use of the information contained is strictly =
prohibited.  If you have received this mail in error, please delete =
it and notify us immediately.
 

 

 
----------------------------------------------------=
----
ZTE =
Information Security Notice: The information contained in this mail (and =
any attachment transmitted herewith) is privileged and confidential and =
is intended for the exclusive use of the addressee(s).  If you are =
not an intended recipient, any disclosure, reproduction, distribution or =
other dissemination or use of the information contained is strictly =
prohibited.  If you have received this mail in error, please delete =
it and notify us immediately.
 

 

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

<= /div> ------=_NextPart_000_0037_01CE7961.B1CF6230-- From farinacci@gmail.com Fri Jul 5 10:48:56 2013 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 5136A11E80F3 for ; Fri, 5 Jul 2013 10:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On7gn0sl93aD for ; Fri, 5 Jul 2013 10:48:55 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B91B421F9DE1 for ; Fri, 5 Jul 2013 10:48:55 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so2348124pbc.32 for ; Fri, 05 Jul 2013 10:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xJ9rxYKKORo5dG/Y4MdsocG3GKuH0EDObDoxDOohMY8=; b=fdWs38KqDCi+i4ERmHe78XyPbnYxK08peWxD2wCy+Zqv4+0Nd6KJdLmnCaXiR10Usr F6st1wOg5/xpGh5+k4rBgFO1fPtsbDKFP73iAXV8UN+f38kXK0lde3JYsiDMYFMmgyYP GRdoqiBN9QXLWkPd9XzX2RBHbRkSZC3+FD42dNGNhuuoLEAavo5lPXwaCmHD12KuTYcd m19y95FeL5RtbKqPdScFccf8NX1jjX+Znf/szNadM1mZlebN1ttiSYWJMDpxM1u6rHVG jRptw92AYdLRm3lsjpj5NIeFFRislwKMJ7c3ul6UgeniaMQyaWFx7A5Vr/vpFCTerLDN AnHg== X-Received: by 10.66.122.99 with SMTP id lr3mr12417927pab.187.1373046535499; Fri, 05 Jul 2013 10:48:55 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id ie3sm8524704pbc.13.2013.07.05.10.48.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 10:48:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <6FFCD2B684E3EE4A96850F334095D67707CA7D14@xmb-aln-x12.cisco.com> Date: Fri, 5 Jul 2013 10:48:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DF7F724-6BEA-4CD8-B0A1-1B42CF020C20@gmail.com> References: <6FFCD2B684E3EE4A96850F334095D67707CA7D14@xmb-aln-x12.cisco.com> To: Rockson Li (zhengyli) X-Mailer: Apple Mail (2.1503) Cc: "lisp@ietf.org" Subject: Re: [lisp] On piggyback map rec handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2013 17:48:56 -0000 > Hello experts, >=20 > While going through piggyback map rec handling at sec 6.1.3 of RFC6830 >=20 > > 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 "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. > >=20 > I find it describes three scenarios when ETR gets the piggybacked Map = records. > 1) it does not have this mapping in the map-cache > originate a "verifying Map-Request", addressed to the map-requesting = ITR > Question: would the verifying Map-Request sent to the "piggybacked" = EID or directly to the ITRs using the one of RLOC in the Map records? It can yes. > It seems to me we need use EID, as this this is essentially the same = as case 3) below. >=20 > 2) On "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. " > 3) On "If the RLOC is not in the > Locator-Set, then the ETR MUST send the "verifying Map-Request" to > the "piggybacked" EID." >=20 > Question: for all the case 1),2),3), do we need to set the "A" bit for = the "verifying Map-Request" to avoid RLOC-spoofing?=20 > It seems to me we need do it for case 1) and 3), but not necessary for = case 2) The A-bit is just telling the receiver of the message that the ETR = itself is replying versus the mapping system which may send a = proxy-reply (i.e. a map-server sending the Map-Reply). The way you avoid RLOC spoofing is the same way you avoid any source = spoofing which is by use of uRPF operationally. Dino >=20 > Thanks > Regards, > -Rockson >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From heinerhummel@aol.com Sat Jul 6 03:10:18 2013 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 85C1621F9B1B for ; Sat, 6 Jul 2013 03:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEK4sGmYZtCw for ; Sat, 6 Jul 2013 03:10:12 -0700 (PDT) Received: from omr-d08.mx.aol.com (omr-d08.mx.aol.com [205.188.109.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9D81A21F9B10 for ; Sat, 6 Jul 2013 03:10:12 -0700 (PDT) Received: from mtaomg-da01.r1000.mx.aol.com (mtaomg-da01.r1000.mx.aol.com [172.29.51.137]) by omr-d08.mx.aol.com (Outbound Mail Relay) with ESMTP id 1F9C77005209E for ; Sat, 6 Jul 2013 05:58:27 -0400 (EDT) Received: from core-dqd005c.r1000.mail.aol.com (core-dqd005.r1000.mail.aol.com [172.29.162.17]) by mtaomg-da01.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id D458FE000082 for ; Sat, 6 Jul 2013 05:58:26 -0400 (EDT) References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> To: lisp@ietf.org In-Reply-To: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D048467E87CE5E_FB0_15A6CA_webmail-m135.sysops.aol.com" X-Mailer: Webmail 37834-STANDARD Received: from 178.26.195.50 by webmail-m135.sysops.aol.com (149.174.9.24) with HTTP (WebMailUI); Sat, 06 Jul 2013 05:58:26 -0400 Message-Id: <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Sat, 6 Jul 2013 05:58:26 -0400 (EDT) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1373104707; bh=li1+YE03VGR8+I8X3Y9be5mhtRTbCG9v6QPO2rVFKG0=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=BQ7bth5XW1A0NrbjY2JS/VsHtCpePZ3v9grB6dwt7EmiSQgZrOAr8j88F2spUY1OU w+jaa2IFBsGXeUfz8Azxx1xc1DIIKWSwdyYMluTGcz1NMaU9o+5KbPlxHyqcr1sx2B pHfn+IY4EWAoEMswcV4AK5FihZgR/KrMokqgcobs= X-AOL-SCOLL-SCORE: 0:2:356206400:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d338951d7ea425c2f Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2013 10:10:18 -0000 This is a multi-part message in MIME format. ----------MB_8D048467E87CE5E_FB0_15A6CA_webmail-m135.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" My "Mass" for the LISP beer garden meeting: The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse -=20 either by malicious hackers or by malicious owners, or the alliance of both= . Who is able to control these servers is able to control internet forward= ing. I can imagine that the RSA would like LISP very much. Heiner =20 ----------MB_8D048467E87CE5E_FB0_15A6CA_webmail-m135.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" My "Mass" for the LISP beer= garden meeting:

The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse  - 
either by malicious hackers or by malicious owners, or the alliance of= both. Who is able to control these servers is able to control  intern= et forwarding.
I can imagine that the RSA would like LISP very much.


Heiner
  

 ----------MB_8D048467E87CE5E_FB0_15A6CA_webmail-m135.sysops.aol.com-- From damien.saucez@gmail.com Sat Jul 6 04:21:59 2013 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 A84C221F9AE6 for ; Sat, 6 Jul 2013 04:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXsQgZlnRaTD for ; Sat, 6 Jul 2013 04:21:59 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id B359E21F9ADD for ; Sat, 6 Jul 2013 04:21:48 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c50so1845582eek.39 for ; Sat, 06 Jul 2013 04:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=tPVpAiPva23LTvD1uIWJxXpZQW0U9eahsxE98lzCiVQ=; b=WXfVM4TVO3m3h26hO1zjQ2K1nMAJsE2JbXM2SqHzWmXjwW9LDwJTiQDJKMn3xntaQ/ f56/xPkECx4D9vn6m8+5AI2MUjXiiDezvlFV2NVmA8GIuV7QHgC/4OydJawSL2ag3FR2 X/AlTqfRzRKr1iBpejFNTmJ8WAU6I4m8VVsre4PIIdnnNoXRjxy5zDfQTeKKPZffhBSG Izfmr8b9cuIbTvG0PbXGxKYn1+0aCm8xG8O6ltf1AsuLefMi4tA0EV41xog9c4phB3JG usCb5KY/9dQ74O6azZtDnIlvammtZ3bIfMSnVoER09/wwIRe/d2BEMjkEZ+F4b+ESWJa OOcQ== X-Received: by 10.14.224.201 with SMTP id x49mr16309636eep.6.1373109708020; Sat, 06 Jul 2013 04:21:48 -0700 (PDT) Received: from [192.168.1.221] (LVelizy-156-46-22-251.w80-11.abo.wanadoo.fr. [80.11.231.251]) by mx.google.com with ESMTPSA id b3sm22631336eev.10.2013.07.06.04.21.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 04:21:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6A5A30D4-AE5F-42F1-8E97-2A4C1B9FC5A8" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Damien Saucez In-Reply-To: <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> Date: Sat, 6 Jul 2013 13:21:45 +0200 Message-Id: References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> To: heinerhummel@aol.com X-Mailer: Apple Mail (2.1508) Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2013 11:21:59 -0000 --Apple-Mail=_6A5A30D4-AE5F-42F1-8E97-2A4C1B9FC5A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: > My "Mass" for the LISP beer garden meeting: >=20 > The LISP's dependency on special servers (DDT, formerly ALT) is a = perfect invitation for abuse -=20 > either by malicious hackers or by malicious owners, or the alliance of = both. Who is able to control these servers is able to control internet = forwarding. > I can imagine that the RSA would like LISP very much. >=20 Don't worry, before you traffic to be encapsulated by LISP you will use = DNS... Damien Saucez >=20 > Heiner > =20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_6A5A30D4-AE5F-42F1-8E97-2A4C1B9FC5A8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote:

My "Mass" for the LISP beer garden meeting:

The LISP's dependency on special servers (DDT, formerly ALT) is a perfect invitation for abuse  - 
either by malicious hackers or by malicious owners, or the alliance of both. Who is able to control these servers is able to control  internet forwarding.
I can imagine that the RSA would like LISP very much.


Don't worry, before you traffic to be encapsulated by LISP you will use DNS...

Damien Saucez


Heiner
  

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

--Apple-Mail=_6A5A30D4-AE5F-42F1-8E97-2A4C1B9FC5A8-- From farinacci@gmail.com Sat Jul 6 11:01:46 2013 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 6D49521F9B5C for ; Sat, 6 Jul 2013 11:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=2.600, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVR0uV0OT9lh for ; Sat, 6 Jul 2013 11:01:46 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id E5F9321F9A96 for ; Sat, 6 Jul 2013 11:01:45 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id t12so2831604pdi.35 for ; Sat, 06 Jul 2013 11:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=VEEZwXHrhazg9zvcJkLoumS8qfXvVZsSOJZUD5O1C9Q=; b=SkAqlMEunaX+aoT5JlaW8rayVLaF0k7si1wjK0joTrLwCpgtpgxSZPo5aWpR0jHlZs KLZga6V6dcw3DkMayObdc97lslBXeHwZgeVTBRAEsgu2mJPl2L4mzeotTsjmfS0EWZRx 8Lz0TszEtr6dZ5VeK+4McHuvWhvQt+kiMPdQhPiFmI7NM/iGFdCO1/v0C9jSXGA2eNAg lb85hRQKELkf3nv8x1bKG1GWu2S2zAZGoWPNd6k/cdH6/yGEWJ6d06UL4QW2F+PZDaI2 SZfH2wjusums4Kp+ITE3pfg+b9Wfb9EvEmc8woO6cSphKLozL3Qul6QG6va0CdvUdF05 7g8w== X-Received: by 10.66.149.131 with SMTP id ua3mr1924187pab.49.1373133705674; Sat, 06 Jul 2013 11:01:45 -0700 (PDT) Received: from [10.47.65.201] (mobile-166-137-186-092.mycingular.net. [166.137.186.92]) by mx.google.com with ESMTPSA id ie3sm13339559pbc.13.2013.07.06.11.01.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 11:01:44 -0700 (PDT) References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-8E7F560B-3CA9-4FAA-920F-E270A227E0B0 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B350) From: Dino Farinacci Date: Sat, 6 Jul 2013 11:01:32 -0700 To: Damien Saucez Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2013 18:01:46 -0000 --Apple-Mail-8E7F560B-3CA9-4FAA-920F-E270A227E0B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable There are servers everywhere. Even not on the Internet. We leave in a world o= f abuse. But I would like to think we live in a world where people help thin= gs that serve.=20 Dino=20 On Jul 6, 2013, at 4:21 AM, Damien Saucez wrote: >=20 > On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: >=20 >> My "Mass" for the LISP beer garden meeting: >>=20 >> The LISP's dependency on special servers (DDT, formerly ALT) is a perfect= invitation for abuse -=20 >> either by malicious hackers or by malicious owners, or the alliance of bo= th. Who is able to control these servers is able to control internet forwar= ding. >> I can imagine that the RSA would like LISP very much. >=20 > Don't worry, before you traffic to be encapsulated by LISP you will use DN= S... >=20 > Damien Saucez >=20 >>=20 >> Heiner >> =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 --Apple-Mail-8E7F560B-3CA9-4FAA-920F-E270A227E0B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
There are servers everywhere. Even not on the Internet. We leave in a world of abuse. But I would like to think we live in a world where people help things that serve. 

Dino 


On Jul 6, 2013, at 4:21 AM, Damien Saucez <damien.saucez@gmail.com> wrote:


On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote:

My "Mass" for the LISP beer garden meeting:

The LISP's dependency on special servers (DDT, formerly ALT) is a perfect invitation for abuse  - 
either by malicious hackers or by malicious owners, or the alliance of both. Who is able to control these servers is able to control  internet forwarding.
I can imagine that the RSA would like LISP very much.


Don't worry, before you traffic to be encapsulated by LISP you will use DNS...

Damien Saucez


Heiner
  

_______________________________________________
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
--Apple-Mail-8E7F560B-3CA9-4FAA-920F-E270A227E0B0-- From jnc@mercury.lcs.mit.edu Sun Jul 7 08:18:06 2013 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 1AA2121F9F87 for ; Sun, 7 Jul 2013 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOsIkUdguzIt for ; Sun, 7 Jul 2013 08:18:01 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4EE21F9F5C for ; Sun, 7 Jul 2013 08:18:00 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 350C518C100; Sun, 7 Jul 2013 11:17:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130707151758.350C518C100@mercury.lcs.mit.edu> Date: Sun, 7 Jul 2013 11:17:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] On piggyback map rec handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 07 Jul 2013 15:18:06 -0000 > From: Dino Farinacci > The way you avoid RLOC spoofing is the same way you avoid any source > spoofing which is by use of uRPF operationally. Yes, but if that's the primary defense, that means you have to rely on other people to filter out source-spoofed packets (since uRPF near the destination is nowhere near as good at filtering out source-spoofed packets as uRPF near their source). I would prefer not to out-source my cracker detection/prevention; the system ought to be robust even without other people doing source spoof filtering. If I'm understanding the question (and context) correctly, I think an Internet-connected xTR should never wholly trust a piggybacked mapping (it may be safe in local-only applications), and_always_ send a "verifying Map-Request" to ensure they it's not being spoofed. The request's nonce (and LISPSEC, if that's in use) will help make sure any mapping(s) in reply to that request are authentic. (And if any attempt at spoofing _is_ detected, it ought to ring an alarm bell, not just silently discard it; although of course the bell should be temporarily disable-able.) Noel From heinerhummel@aol.com Sun Jul 7 11:21:22 2013 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 D3C6111E80E9 for ; Sun, 7 Jul 2013 11:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+DHufaxF7vI for ; Sun, 7 Jul 2013 11:21:18 -0700 (PDT) Received: from omr-d02.mx.aol.com (omr-d02.mx.aol.com [205.188.109.194]) by ietfa.amsl.com (Postfix) with ESMTP id 44C5511E80F1 for ; Sun, 7 Jul 2013 11:21:16 -0700 (PDT) Received: from mtaomg-ma04.r1000.mx.aol.com (mtaomg-ma04.r1000.mx.aol.com [172.29.41.11]) by omr-d02.mx.aol.com (Outbound Mail Relay) with ESMTP id D8D7370096051; Sun, 7 Jul 2013 14:11:52 -0400 (EDT) Received: from core-dqd005c.r1000.mail.aol.com (core-dqd005.r1000.mail.aol.com [172.29.162.17]) by mtaomg-ma04.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id A1C04E000085; Sun, 7 Jul 2013 14:11:52 -0400 (EDT) References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> To: farinacci@gmail.com, damien.saucez@gmail.com In-Reply-To: X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-m257.sysops.aol.com (64.12.138.231) with HTTP (WebMailUI); Sun, 07 Jul 2013 14:11:52 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D04954975F9252_EF4_1E25E8_webmail-m257.sysops.aol.com" X-Mailer: Webmail 37834-STANDARD Message-Id: <8D049549753AB68-EF4-9703D@webmail-m257.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Sun, 7 Jul 2013 14:11:52 -0400 (EDT) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1373220712; bh=LWq+SWZFChnsaHIxSD8j7o87qTCBLyOF1nxmmo/3jDw=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=TM7b+SMYmYT34m5So2Rw/SJysxGU+ICtnQegkTS8LnMh7BuLVN+HthcEGKd5Y5fh1 g+Zpv8pEnJcS81bi5pH5M0V8DuD1XOCq0GyTmXmcG/PKwM6isQQc6uAx+3v5s4hBVn K5YUtGNx9C96ffoquBYRBjMQfEVNh5AEJWjx9o5w= X-AOL-SCOLL-SCORE: 0:2:412865024:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d290b51d9af682694 Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 07 Jul 2013 18:21:23 -0000 This is a multi-part message in MIME format. ----------MB_8D04954975F9252_EF4_1E25E8_webmail-m257.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" "...But I would like to think we live in a world where people help things t= hat serve. " Dino,really? By our last dispute a while ago I learnt that LISP does NOTHING to ease the= IPv4 adress depletion issue (well, it rather eats up some extra addresses)= . While by involving the user as well as the DNS (i.e. by mapping a FQDN to I= Pv4 address + Locator) the IPv4 address space could easily do for another t= housand years (all it takes is to ensure that any IPv4-address is unique pe= r associated locator) LISP-DDT prevents that for good, and you make us beli= eve that LISP would be of any service to IPv4 ?! The bad thing is that very very precious time goes by while (naive) people/= observers trust in LISP on this respect. Just like myself when I argued that LISP-DDT cannot work assuming that LISP= were after a 4+4 octet unicast address space extension. But you let all up to NAT. This is really not a serve. Sorry, Heiner (having nothing said about the dooming malicious/political problems yet) -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Dino Farinacci An: Damien Saucez Cc: heinerhummel ; lisp Verschickt: Sa, 6 Jul 2013 8:01 pm Betreff: Re: [lisp] No LISP meeting for Berlin There are servers everywhere. Even not on the Internet. We leave in a world= of abuse. But I would like to think we live in a world where people help t= hings that serve.=20 Dino=20 On Jul 6, 2013, at 4:21 AM, Damien Saucez wrote: On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: My "Mass" for the LISP beer garden meeting: The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse -=20 either by malicious hackers or by malicious owners, or the alliance of both= . Who is able to control these servers is able to control internet forward= ing. I can imagine that the RSA would like LISP very much. Don't worry, before you traffic to be encapsulated by LISP you will use DNS= ... Damien Saucez Heiner =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 ----------MB_8D04954975F9252_EF4_1E25E8_webmail-m257.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" "...But I would like to think we live in a world where = people help things that serve. "


Dino,really?

By our last dispute a while ago I lear= nt that LISP does NOTHING to ease the IPv4 adress depletion issue (well, it= rather eats up some extra addresses).
While by involving the user as well as= the DNS (i.e. by mapping a FQDN to IPv4 address + Locator) the IPv4 addres= s space could easily do for another thousand years (all it takes is to ensu= re that any IPv4-address is unique per associated locator) LISP-DDT prevent= s that for good, and you make us believe that LISP would be of any service = to IPv4 ?!

The bad thing is that very very precio= us time goes by while (naive) people/observers trust in LISP on this respec= t.
Just like myself when I argued that LI= SP-DDT cannot work assuming that LISP were after a 4+4 octet unicast addres= s space extension.

But you let all up to NAT. This is rea= lly not a serve.

Sorry,
Heiner
 (having nothing said about the d= ooming malicious/political problems yet)






There are servers everywhere. Even not on the Internet. We leave in a = world of abuse. But I would like to think we live in a world where people h= elp things that serve. 

Dino 


On Jul 6, 2013, at 4:21 AM, Damien Saucez <damien.saucez@gmail.com> wrot= e:


On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote:

My "Mass" for the LISP beer garden meeting:

The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse  - 
either by malicious hackers or by malicious owners, or the alliance of= both. Who is able to control these servers is able to control  intern= et forwarding.
I can imagine that the RSA would like LISP very much.


Don't worry, before you traffic to be encapsulated by LISP you will us= e DNS...

Damien Saucez


Heiner
  

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

_______________________________________________
lisp mailing list
lisp@ietf.o= rg
https://www.ietf.org/mailman/listinfo/lisp=
----------MB_8D04954975F9252_EF4_1E25E8_webmail-m257.sysops.aol.com-- From farinacci@gmail.com Sun Jul 7 11:59:41 2013 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 979C021F9B90 for ; Sun, 7 Jul 2013 11:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDbvFdfTkSE6 for ; Sun, 7 Jul 2013 11:59:40 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A321F9B8D for ; Sun, 7 Jul 2013 11:59:40 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w11so3341481pde.23 for ; Sun, 07 Jul 2013 11:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=UL57q4wZxeHK1FQM+e3HrNPC0mG5HgN4SZs6XUTDil8=; b=Y6YQb950dMmrqhwq60cr3A3BQ5mHdMwOZ0/pVIEsHyIF/E3eVXAOs0+nfvX5VICqB3 6LRj+uS8txJXULnU2+FonxTIGzSyhqANDZKgOIgPUNGzAgV07cbza61DtN6U0Ijvlhmv R7XvxFJHXSjsCTh1YNYnVYQQScW4XeRLe5hL+KQLVt+KSYdFBSw82KDKpzLkqLx/W1rK OAzO2ZfptznQNycciTMWt6g7HOamNHom7eo/TFrxHy9S4Kh3LqDvaaldmC8sgUhYe75Y 56FUbA09dHV0nx9hO511l9lHp1y7q1N/iU7YnHub5oW+nbI1MAYsOsBy6mN8Fmv1/sO5 1qfg== X-Received: by 10.66.246.66 with SMTP id xu2mr19886612pac.134.1373223580406; Sun, 07 Jul 2013 11:59:40 -0700 (PDT) Received: from [10.200.151.202] (mobile-166-137-187-115.mycingular.net. [166.137.187.115]) by mx.google.com with ESMTPSA id bs3sm18245059pbc.42.2013.07.07.11.59.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 11:59:39 -0700 (PDT) References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> <8D049549753AB68-EF4-9703D@webmail-m257.sysops.aol.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8D049549753AB68-EF4-9703D@webmail-m257.sysops.aol.com> Content-Type: multipart/alternative; boundary=Apple-Mail-32A9333E-9597-470C-AE9F-735CE994E72C Content-Transfer-Encoding: 7bit Message-Id: <83605EFB-A0B9-4E43-A6FA-5AB75A23A98F@gmail.com> X-Mailer: iPhone Mail (10B350) From: Dino Farinacci Date: Sun, 7 Jul 2013 11:59:38 -0700 To: "heinerhummel@aol.com" Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 07 Jul 2013 18:59:41 -0000 --Apple-Mail-32A9333E-9597-470C-AE9F-735CE994E72C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > "...But I would like to think we live in a world where people help things t= hat serve. " >=20 >=20 > Dino,really? Yes - really. When you post an email like you did (and you do it repeatedly w= ith little technical data), I have to respond that way.=20 > By our last dispute a while ago I learnt that LISP does NOTHING to ease th= e IPv4 And it never claimed to solve this problem. It you know what? It does help b= ecause you can use other address spaces to help the allocation of devices. S= o you can use IPv6 EIDs for site devices versus IPv4 addresses. Allowing mor= e IPv4 addresses to be used for RLOCs and therefore be able to address more s= ites.=20 > adress depletion issue (well, it rather eats up some extra addresses). > While by involving the user as well as the DNS (i.e. by mapping a FQDN to I= Pv4 How is LISP involving the user? > address + Locator) the IPv4 address space could easily do for another thou= sand years (all it takes is to ensure that any IPv4-address is unique per as= sociated locator) LISP-DDT prevents that for good, and you make us believe t= hat LISP would be of any service to IPv4 ?! LISP-DDT is a database to move Map-Request around. It says nothing about how= and how much address is allocated.=20 > The bad thing is that very very precious time goes by while (naive) people= /observers trust in LISP on this respect. Because it is becoming proven in their experience.=20 > Just like myself when I argued that LISP-DDT cannot work assuming that LIS= P were after a 4+4 octet unicast address space extension. >=20 > But you let all up to NAT. This is really not a serve. I cannot parse the above.=20 Dino >=20 > Sorry, > Heiner > (having nothing said about the dooming malicious/political problems yet) >=20 >=20 >=20 >=20 >=20 >=20 > -----Urspr=C3=BCngliche Mitteilung-----=20 > Von: Dino Farinacci > An: Damien Saucez > Cc: heinerhummel ; lisp > Verschickt: Sa, 6 Jul 2013 8:01 pm > Betreff: Re: [lisp] No LISP meeting for Berlin >=20 > There are servers everywhere. Even not on the Internet. We leave in a worl= d of abuse. But I would like to think we live in a world where people help t= hings that serve.=20 >=20 > Dino=20 >=20 >=20 > On Jul 6, 2013, at 4:21 AM, Damien Saucez wrote:= >=20 >>=20 >> On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: >>=20 >>> My "Mass" for the LISP beer garden meeting: >>>=20 >>> The LISP's dependency on special servers (DDT, formerly ALT) is a perfec= t invitation for abuse -=20 >>> either by malicious hackers or by malicious owners, or the alliance of b= oth. Who is able to control these servers is able to control internet forwa= rding. >>> I can imagine that the RSA would like LISP very much. >>>=20 >>=20 >> Don't worry, before you traffic to be encapsulated by LISP you will use D= NS... >>=20 >> Damien Saucez >>=20 >>>=20 >>> Heiner >>> =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 --Apple-Mail-32A9333E-9597-470C-AE9F-735CE994E72C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Dino,really?
<= /blockquote>

Yes - really. When you post an email like you did= (and you do it repeatedly with little technical data), I have to respond th= at way. 

By our last dispute a w= hile ago I learnt that LISP does NOTHING to ease the IPv4

And it never claimed to solve this probl= em.  It you know what? It does help because you can use other address s= paces to help the allocation of devices.  So you can use IPv6 EIDs for s= ite devices versus IPv4 addresses. Allowing more IPv4 addresses to be used f= or RLOCs and therefore be able to address more sites. 

adress depletion issue= (well, it rather eats up some extra addresses).
While by involving the user as well as t= he DNS (i.e. by mapping a FQDN to IPv4

How is LISP involving the user?

address + Locator) the IPv4 address space could e= asily do for another thousand years (all it takes is to ensure that any IPv4= -address is unique per associated locator) LISP-DDT prevents that for good, a= nd you make us believe that LISP would be of any service to IPv4 ?!

LISP-DDT is a database to move M= ap-Request around. It says nothing about how and how much address is allocat= ed. 

The bad thing is that v= ery very precious time goes by while (naive) people/observers trust in LISP o= n this respect.

Because= it is becoming proven in their experience. 

Just like myself when I argued that LIS= P-DDT cannot work assuming that LISP were after a 4+4 octet unicast address s= pace extension.

But you let all up to NAT. This is real= ly not a serve.

I canno= t parse the above. 

Dino


Sorry,
Heiner
 (having nothing said about the do= oming malicious/political problems yet)






-----Urspr=C3=BCngliche Mitteilung-----
Von: Dino Farinacci <farinacci@gma= il.com>
An: Damien Saucez <damien.sauc= ez@gmail.com>
Cc: heinerhummel <heinerhummel@ao= l.com>; lisp <lisp@ietf.org&g= t;
Verschickt: Sa, 6 Jul 2013 8:01 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

There are servers everywhere. Even not on the Internet. We leave in a w= orld of abuse. But I would like to think we live in a world where people hel= p things that serve. 

Dino 


On Jul 6, 2013, at 4:21 AM, Damien Saucez <damien.saucez@gmail.com> wrote:=


On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote:

My "Mass" for the LISP beer garden meeting:

The LISP's dependency on special servers (DDT, formerly ALT) is a perfect in= vitation for abuse  - 
either by malicious hackers or by malicious owners, or the alliance of b= oth. Who is able to control these servers is able to control  internet f= orwarding.
I can imagine that the RSA would like LISP very much.


Don't worry, before you traffic to be encapsulated by LISP you will use= DNS...

Damien Saucez


Heiner
  

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

_______________________________________________
lisp mailing list
lisp@ietf.or= g
https://www.ietf.org/mailman/listinfo/lisp
= --Apple-Mail-32A9333E-9597-470C-AE9F-735CE994E72C-- From zhengyli@cisco.com Sun Jul 7 18:11:30 2013 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 E30F911E8134 for ; Sun, 7 Jul 2013 18:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a-WtwS6G73K for ; Sun, 7 Jul 2013 18:11:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B352D21F9E47 for ; Sun, 7 Jul 2013 18:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=656; q=dns/txt; s=iport; t=1373245884; x=1374455484; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TN4qrNUpO172BoKUkTQxm8IhryPmHwpARodB9s4InLs=; b=WIpJXv3UlMfBsJv/kuy4iGYCeDt7ItzHBqJM1c83DoalRdlMqpLEDc2S dOfuutIPB31vWv+veWpfZKxq1oVT+L9Wwj0sFFqdsvorwvDTMffYCRTr6 +PVwnhbthf3hPr4PLxVHfpvOSIkboWDNzFxRSyGKT0G30nBS9sGepsCSr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAFIQ2lGtJXHA/2dsb2JhbABagwl8gkG+H4ELFnSCJQEBAzo/EgEIIhQxESUCBA4FCId1Aw+vOA2IUY0AgjoxB4MGaQOVbI4KhSWDEYIo X-IronPort-AV: E=Sophos;i="4.87,1016,1363132800"; d="scan'208";a="231885901" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 08 Jul 2013 01:11:19 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r681BJxc005615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 01:11:19 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.22]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Sun, 7 Jul 2013 20:11:19 -0500 From: "Rockson Li (zhengyli)" To: Dino Farinacci Thread-Topic: [lisp] On piggyback map rec handling Thread-Index: AQHOeH0PF47Lcu3/f0uPySbFPN88oJlWsquAgAQmTwA= Date: Mon, 8 Jul 2013 01:10:31 +0000 Message-ID: <6FFCD2B684E3EE4A96850F334095D67707CAABBA@xmb-aln-x12.cisco.com> In-Reply-To: <1DF7F724-6BEA-4CD8-B0A1-1B42CF020C20@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.104.169.74] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] On piggyback map rec handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 01:11:31 -0000 Dino, Are you saying the it's up to ETR to select the either way to go? I think this is confusing, the case 1) is very similar to case 3), Why the rfc says "then the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID. " but not for case 3) Thanks Regards, -Rockson On 7/6/13 1:48 AM, "Dino Farinacci" wrote: >>1) it does not have this mapping in the map-cache >>originate a "verifying Map-Request", addressed to the map-requesting ITR >>Question: would the verifying Map-Request sent to the "piggybacked" EID >>or directly to the ITRs using the one of RLOC in the Map records? > >It can yes. From heinerhummel@aol.com Mon Jul 8 03:10:55 2013 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 5232E11E81A5 for ; Mon, 8 Jul 2013 03:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.648 X-Spam-Level: X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=1.350, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4V9rmbvOQXb for ; Mon, 8 Jul 2013 03:10:50 -0700 (PDT) Received: from omr-m10.mx.aol.com (omr-m10.mx.aol.com [64.12.143.86]) by ietfa.amsl.com (Postfix) with ESMTP id 8609E21F8FBE for ; Mon, 8 Jul 2013 03:10:49 -0700 (PDT) Received: from mtaomg-ma01.r1000.mx.aol.com (mtaomg-ma01.r1000.mx.aol.com [172.29.41.8]) by omr-m10.mx.aol.com (Outbound Mail Relay) with ESMTP id 3570C700B9790; Mon, 8 Jul 2013 06:10:48 -0400 (EDT) Received: from core-dqd005c.r1000.mail.aol.com (core-dqd005.r1000.mail.aol.com [172.29.162.17]) by mtaomg-ma01.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id C631EE000082; Mon, 8 Jul 2013 06:10:47 -0400 (EDT) References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> <8D049549753AB68-EF4-9703D@webmail-m257.sysops.aol.com> <83605EFB-A0B9-4E43-A6FA-5AB75A23A98F@gmail.com> To: farinacci@gmail.com In-Reply-To: <83605EFB-A0B9-4E43-A6FA-5AB75A23A98F@gmail.com> X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-d178.sysops.aol.com (205.188.162.233) with HTTP (WebMailUI); Mon, 08 Jul 2013 06:10:47 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D049DA8CF914BA_A38_4D879_webmail-d178.sysops.aol.com" X-Mailer: AOL Webmail 37834-STANDARD Message-Id: <8D049DA8CF914BA-A38-14A46@webmail-d178.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Mon, 8 Jul 2013 06:10:47 -0400 (EDT) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1373278248; bh=9B9Gv6UIqtmtV9jLHNU5hVZgThLcWod2o8KQ6AV5TsE=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=ZWEO+cH3EFHabjp24+PMAu36EX2pOURnu4dpV2drk1hndCcGauuHQD4s4vOrvX3si 1EUVepH0+/RDAS2SCl3TXNwYL+49CC1g4stFjL71uThHmWUwRDApbX5uqBzfQqzxkz TaB5OPjnq+QKe/9tLtfGGqrOSMHUN7Ztmk4mrsqU= X-AOL-SCOLL-SCORE: 0:2:409276736:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d290851da90271517 Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 10:10:55 -0000 This is a multi-part message in MIME format. ----------MB_8D049DA8CF914BA_A38_4D879_webmail-d178.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" See my notes starting with HH inside. Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Dino Farinacci An: heinerhummel Cc: damien.saucez ; lisp Verschickt: So, 7 Jul 2013 8:59 pm Betreff: Re: [lisp] No LISP meeting for Berlin "...But I would like to think we live in a world where people help things t= hat serve. " Dino,really? Yes - really. When you post an email like you did (and you do it repeatedly= with little technical data), I have to respond that way.=20 HH: Here is all technical detail: http://www.igi-global.com/chapter/topol= ogy-aggregating-routing-architecture-tara/77501 By our last dispute a while ago I learnt that LISP does NOTHING to ease the= IPv4=20 And it never claimed to solve this problem. It you know what? It does help= because you can use other address spaces to help the allocation of devices= . So you can use IPv6 EIDs for site devices versus IPv4 addresses. Allowin= g more IPv4 addresses to be used for RLOCs and therefore be able to address= more sites.=20 HH: But anyone who sees that the IPv4-address is enhanced by another 4 octe= ts locator is tempted to assume that uniqueness is provided by some unique = combination of IPv4 address + locator. Just as if a postal letter is sent t= o some Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont. And btw, I am not= sure whether that wasn't an initial argument in favor of LISP, otherwise I= would have brought up this issue years earlier. adress depletion issue (well, it rather eats up some extra addresses). While by involving the user as well as the DNS (i.e. by mapping a FQDN to I= Pv4=20 How is LISP involving the user? HH: LISP is not involving the user, that is my reproach. If there were no I= Pv4 address depletion issue then it would be a pro-argument not to involve = the user. But a) we are used to getting WINDOW-updates every now and then, = and b) by expanding the IPv4 address space by O(2^32) that pro-argument is = overruled by far. (TARA would even provide an IPv4-address space extension = of O(2^40) !!! ) address + Locator) the IPv4 address space could easily do for another thous= and years (all it takes is to ensure that any IPv4-address is unique per as= sociated locator) LISP-DDT prevents that for good, and you make us believe = that LISP would be of any service to IPv4 ?! LISP-DDT is a database to move Map-Request around. It says nothing about ho= w and how much address is allocated.=20 HH: Right, sounds very innocently. But even LISP 2.0 (I guess) had once be= en better . The bad thing is that very very precious time goes by while (naive) people/= observers trust in LISP on this respect. Because it is becoming proven in their experience.=20 HH: I never doubted that LISP would just work as you have had it in your mi= nd, nor that you would be able to adjust it such that it suits all existing= forwarding mechanisms. =20 Just like myself when I argued that LISP-DDT cannot work assuming that LISP= were after a 4+4 octet unicast address space extension. But you let all up to NAT. This is really not a serve. I cannot parse the above.=20 Dino Sorry, Heiner (having nothing said about the dooming malicious/political problems yet) -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Dino Farinacci An: Damien Saucez Cc: heinerhummel ; lisp Verschickt: Sa, 6 Jul 2013 8:01 pm Betreff: Re: [lisp] No LISP meeting for Berlin There are servers everywhere. Even not on the Internet. We leave in a world= of abuse. But I would like to think we live in a world where people help t= hings that serve.=20 Dino=20 On Jul 6, 2013, at 4:21 AM, Damien Saucez wrote: On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: My "Mass" for the LISP beer garden meeting: The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse -=20 either by malicious hackers or by malicious owners, or the alliance of both= . Who is able to control these servers is able to control internet forward= ing. I can imagine that the RSA would like LISP very much. Don't worry, before you traffic to be encapsulated by LISP you will use DNS= ... Damien Saucez Heiner =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 ----------MB_8D049DA8CF914BA_A38_4D879_webmail-d178.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" See my notes starting with = HH inside.
Heiner


-----= Urspr=C3=BCngliche Mitteilung-----
Von: Dino Farinacci <farinacci@gmail.com>
An: heinerhummel <heinerhummel@aol.com>
Cc: damien.saucez <damien.saucez@gmail.com>; lisp <lisp@ietf.org&g= t;
Verschickt: So, 7 Jul 2013 8:59 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

"...But I would like to think we live in a world where peopl= e help things that serve. "


Dino,really?

Yes - really. When you post an email like you did (and you do it repeatedly= with little technical data), I have to respond that way. 

HH: Here is all technical detai= l:   http://ww= w.igi-global.com/chapter/topology-aggregating-routing-architecture-tara/775= 01
By our last dispute a = while ago I learnt that LISP does NOTHING to ease the IPv4

And it never claimed to solve this problem.  It you know what? It does= help because you can use other address spaces to help the allocation of de= vices.  So you can use IPv6 EIDs for site devices versus IPv4 addresse= s. Allowing more IPv4 addresses to be used for RLOCs and therefore be able = to address more sites. 

HH: But anyone who sees that the IPv4-address is enhanced by another 4= octets locator is tempted to assume that uniqueness is provided by some un= ique combination of IPv4 address + locator. Just as if a postal letter is s= ent to some Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont. And btw, I a= m not sure whether that wasn't an initial argument in favor of LISP, otherw= ise I would have brought up this issue years earlier.

adress depletion issue= (well, it rather eats up some extra addresses).
While by involving the user as well as= the DNS (i.e. by mapping a FQDN to IPv4

How is LISP involving the user?

HH: LISP is not involving the user, that is my reproach. If there were= no IPv4 address depletion issue then it would be a pro-argument not to inv= olve the user. But a) we are used to getting WINDOW-updates every now and t= hen, and b) by expanding the IPv4 address space by O(2^32) that pro-argumen= t is overruled by far. (TARA would even provide an IPv4-address space exten= sion of O(2^40) !!! )

address + Locator) the IPv4 address sp= ace could easily do for another thousand years (all it takes is to ensure t= hat any IPv4-address is unique per associated locator) LISP-DDT prevents th= at for good, and you make us believe that LISP would be of any service to I= Pv4 ?!

LISP-DDT is a database to move Map-Request around. It says nothing about ho= w and how much address is allocated. 

HH: Right,  sounds very innocently. But even LISP 2.0 (I guess) h= ad once been better .

The bad thing is that = very very precious time goes by while (naive) people/observers trust in LIS= P on this respect.

Because it is becoming proven in their experience. 
HH: I never doubted that LISP would just work as you have had it in yo= ur mind, nor that you would be able to adjust it such that it suits all exi= sting forwarding mechanisms.
       

Just like myself when I argued that LI= SP-DDT cannot work assuming that LISP were after a 4+4 octet unicast addres= s space extension.

But you let all up to NAT. This is rea= lly not a serve.

I cannot parse the above. 

Dino


Sorry,
Heiner
 (having nothing said about the d= ooming malicious/political problems yet)






farinacci@gmail.com>
An: Damien Saucez <damien.saucez@gmail.com>
Cc: heinerhummel <heinerhummel@aol.com>; lisp <lisp@ietf.org>
Verschickt: Sa, 6 Jul 2013 8:01 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

There are servers everywhere. Even not on the Internet. We leave in a = world of abuse. But I would like to think we live in a world where people h= elp things that serve. 

Dino 


On Jul 6, 2013, at 4:21 AM, Damien Saucez <damien.saucez@gmail.com> wrote:



My "Mass" for the LISP beer garden meeting:

The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse  - 
either by malicious hackers or by malicious owners, or the alliance of= both. Who is able to control these servers is able to control  intern= et forwarding.
I can imagine that the RSA would like LISP very much.


Don't worry, before you traffic to be encapsulated by LISP you will us= e DNS...

Damien Saucez


Heiner
  

_______________________________________________
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
----------MB_8D049DA8CF914BA_A38_4D879_webmail-d178.sysops.aol.com-- From Sharon@Contextream.com Mon Jul 8 04:14:38 2013 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 737E921F9D71 for ; Mon, 8 Jul 2013 04:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm4U5wZ9E7Uk for ; Mon, 8 Jul 2013 04:14:33 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id E728521F91B0 for ; Mon, 8 Jul 2013 04:14:30 -0700 (PDT) Received: from mail4-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 11:14:28 +0000 Received: from mail4-co9 (localhost [127.0.0.1]) by mail4-co9-R.bigfish.com (Postfix) with ESMTP id 9D35A1400D0; Mon, 8 Jul 2013 11:14:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT005.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz98dI9371Ic89bhc85dhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1f8fizz1033IL17326ah18c673h8275bh8275dhz32i2a8h668h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail4-co9 (localhost.localdomain [127.0.0.1]) by mail4-co9 (MessageSwitch) id 1373282065939163_8452; Mon, 8 Jul 2013 11:14:25 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.251]) by mail4-co9.bigfish.com (Postfix) with ESMTP id E1E1D80199; Mon, 8 Jul 2013 11:14:25 +0000 (UTC) Received: from DB3PRD0610HT005.eurprd06.prod.outlook.com (157.56.252.53) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 11:14:25 +0000 Received: from DB3PRD0610MB379.eurprd06.prod.outlook.com ([169.254.11.40]) by DB3PRD0610HT005.eurprd06.prod.outlook.com ([10.255.47.40]) with mapi id 14.16.0329.000; Mon, 8 Jul 2013 11:14:04 +0000 From: Sharon Barkai To: "heinerhummel@aol.com" Thread-Topic: [lisp] No LISP meeting for Berlin Thread-Index: Ac54kvpm5mCoajswR++PaeEgPYCu6gBnGFAAAALo6IAADfZYAAAypv0AAAGrEgAAH9JQgAACNbXj Date: Mon, 8 Jul 2013 11:14:03 +0000 Message-ID: References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> <8D049549753AB68-EF4-9703D@webmail-m257.sysops.aol.com> <83605EFB-A0B9-4E43-A6FA-5AB75A23A98F@gmail.com>, <8D049DA8CF914BA-A38-14A46@webmail-d178.sysops.aol.com> In-Reply-To: <8D049DA8CF914BA-A38-14A46@webmail-d178.sysops.aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.117.226.209] Content-Type: multipart/alternative; boundary="_000_ED1058B94F6F4CA4808820D616B47D45Contextreamcom_" MIME-Version: 1.0 X-OriginatorOrg: Contextream.com Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 11:14:38 -0000 --_000_ED1058B94F6F4CA4808820D616B47D45Contextreamcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable really don't want to interrupt this great dialog, just one comment. don't think is about a bigger address space for routing, but rather combining 2 completely different lookup schemes. Step1: you lookup the routing location of Mr. Smith, or Mr. Li, or Herr M= eier or Mr. Dupont in a huge ID "phone book" a (secure) distributed databas= e lookup problem, strictly overlay not a routing problem. Step 2: you insert the letter into an outer envelope with a postal-service = (routable) address, leverage whatever hop to hop routing lookup solution yo= u have at the moment scale, cost, efficiency wise. FedEx, ups etc. Lots of use cases and benefits. --szb On Jul 8, 2013, at 13:11, "heinerhummel@aol.com" > wrote: See my notes starting with HH inside. Heiner -----Urspr=FCngliche Mitteilung----- Von: Dino Farinacci > An: heinerhummel > Cc: damien.saucez >= ; lisp > Verschickt: So, 7 Jul 2013 8:59 pm Betreff: Re: [lisp] No LISP meeting for Berlin "...But I would like to think we live in a world where people help things t= hat serve. " Dino,really? Yes - really. When you post an email like you did (and you do it repeatedly= with little technical data), I have to respond that way. HH: Here is all technical detail: http://www.igi-global.com/chapter/topol= ogy-aggregating-routing-architecture-tara/77501 By our last dispute a while ago I learnt that LISP does NOTHING to ease the= IPv4 And it never claimed to solve this problem. It you know what? It does help= because you can use other address spaces to help the allocation of devices= . So you can use IPv6 EIDs for site devices versus IPv4 addresses. Allowin= g more IPv4 addresses to be used for RLOCs and therefore be able to address= more sites. HH: But anyone who sees that the IPv4-address is enhanced by another 4 octe= ts locator is tempted to assume that uniqueness is provided by some unique = combination of IPv4 address + locator. Just as if a postal letter is sent t= o some Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont. And btw, I am not= sure whether that wasn't an initial argument in favor of LISP, otherwise I= would have brought up this issue years earlier. adress depletion issue (well, it rather eats up some extra addresses). While by involving the user as well as the DNS (i.e. by mapping a FQDN to I= Pv4 How is LISP involving the user? HH: LISP is not involving the user, that is my reproach. If there were no I= Pv4 address depletion issue then it would be a pro-argument not to involve = the user. But a) we are used to getting WINDOW-updates every now and then, = and b) by expanding the IPv4 address space by O(2^32) that pro-argument is = overruled by far. (TARA would even provide an IPv4-address space extension = of O(2^40) !!! ) address + Locator) the IPv4 address space could easily do for another thous= and years (all it takes is to ensure that any IPv4-address is unique per as= sociated locator) LISP-DDT prevents that for good, and you make us believe = that LISP would be of any service to IPv4 ?! LISP-DDT is a database to move Map-Request around. It says nothing about ho= w and how much address is allocated. HH: Right, sounds very innocently. But even LISP 2.0 (I guess) had once be= en better . The bad thing is that very very precious time goes by while (naive) people/= observers trust in LISP on this respect. Because it is becoming proven in their experience. HH: I never doubted that LISP would just work as you have had it in your mi= nd, nor that you would be able to adjust it such that it suits all existing= forwarding mechanisms. Just like myself when I argued that LISP-DDT cannot work assuming that LISP= were after a 4+4 octet unicast address space extension. But you let all up to NAT. This is really not a serve. I cannot parse the above. Dino Sorry, Heiner (having nothing said about the dooming malicious/political problems yet) -----Urspr=FCngliche Mitteilung----- Von: Dino Farinacci An: Damien Saucez Cc: heinerhummel ; lisp Verschickt: Sa, 6 Jul 2013 8:01 pm Betreff: Re: [lisp] No LISP meeting for Berlin There are servers everywhere. Even not on the Internet. We leave in a world= of abuse. But I would like to think we live in a world where people help t= hings that serve. Dino On Jul 6, 2013, at 4:21 AM, Damien Saucez wrote: On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: My "Mass" for the LISP beer garden meeting: The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse - either by malicious hackers or by malicious owners, or the alliance of both= . Who is able to control these servers is able to control internet forward= ing. I can imagine that the RSA would like LISP very much. Don't worry, before you traffic to be encapsulated by LISP you will use DNS= ... Damien Saucez Heiner _______________________________________________ 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 --_000_ED1058B94F6F4CA4808820D616B47D45Contextreamcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
really don't want to interrupt this great dialog, just one comment.

don't think is about a bigger address space for routing,
but rather combining 2 completely different lookup schemes.

Step1: you lookup  the routing location  of Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont in a huge ID "phone boo= k" a (secure) distributed database lookup problem, strictly overlay not a routi= ng problem.

Step 2: you insert the letter into an outer envelope with a postal-service (routab= le) address, leverage whatever hop to hop routing lookup solution you have = at the moment scale, cost, efficiency wise.  FedEx, ups etc.

Lots of use cases and benefits.



--szb

On Jul 8, 2013, at 13:11, "hei= nerhummel@aol.com" <hei= nerhummel@aol.com> wrote:

See my notes starting = with HH inside.
Heiner


-----= Urspr=FCngliche Mitteilung-----
Von: Dino Farinacci <farinacci@gm= ail.com>
An: heinerhummel <heinerhummel@a= ol.com>
Cc: damien.saucez <damien.sau= cez@gmail.com>; lisp <lisp@ietf.= org>
Verschickt: So, 7 Jul 2013 8:59 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

<= span style=3D"font-family: arial, helvetica;">"...But I would like to = think we live in a world where people help things that serve. "


Dino,really?

Yes - really. When you post an email like you did (and you do it repeatedly= with little technical data), I have to respond that way. 

HH: Here is all technical detai= l:   http://ww= w.igi-global.com/chapter/topology-aggregating-routing-architecture-tara/775= 01
By our last dispute a = while ago I learnt that LISP does NOTHING to ease the IPv4

And it never claimed to solve this problem.  It you know what? It does= help because you can use other address spaces to help the allocation of de= vices.  So you can use IPv6 EIDs for site devices versus IPv4 addresse= s. Allowing more IPv4 addresses to be used for RLOCs and therefore be able to address more sites. 

HH: But anyone who sees that the IPv4-address is enhanced by another 4= octets locator is tempted to assume that uniqueness is provided by some un= ique combination of IPv4 address + locator. Just as if a postal letter = is sent to some Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont. And btw, I am not sure whether that wasn't an= initial argument in favor of LISP, otherwise I would have brought up this = issue years earlier.

adress depletion issue= (well, it rather eats up some extra addresses).
While by involving the user as well as= the DNS (i.e. by mapping a FQDN to IPv4

How is LISP involving the user?

HH: LISP is not involving the user, that is my reproach. If there were= no IPv4 address depletion issue then it would be a pro-argument not to inv= olve the user. But a) we are used to getting WINDOW-updates every now and t= hen, and b) by expanding the IPv4 address space by O(2^32) that pro-argument is overruled by far. (TARA woul= d even provide an IPv4-address space extension of O(2^40) !!! )

address + Locator) the IPv4 addres= s space could easily do for another thousand years (all it takes is to ensu= re that any IPv4-address is unique per associated locator) LISP-DDT prevent= s that for good, and you make us believe that LISP would be of any service to IPv4 ?!

LISP-DDT is a database to move Map-Request around. It says nothing about ho= w and how much address is allocated. 

HH: Right,  sounds very innocently. But even LISP 2.0 (I guess) h= ad once been better .

The bad thing is that = very very precious time goes by while (naive) people/observers trust in LIS= P on this respect.

Because it is becoming proven in their experience. 
HH: I never doubted that LISP would just work as you have had it in yo= ur mind, nor that you would be able to adjust it such that it suits all exi= sting forwarding mechanisms.
       

Just like myself when I argued that LI= SP-DDT cannot work assuming that LISP were after a 4+4 octet unicast ad= dress space extension.

But you let all up to NAT. This is rea= lly not a serve.

I cannot parse the above. 

Dino


Sorry,
Heiner
 (having nothing said about the d= ooming malicious/political problems yet)






farinacci@gmail.com>
An: Damien Saucez <damien.saucez@gmail.com>
Cc: heinerhummel <heinerhummel@aol.com>; lisp <lisp@ietf.org>
Verschickt: Sa, 6 Jul 2013 8:01 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

There are servers everywhere. Even not on the Internet. We leave in a = world of abuse. But I would like to think we live in a world where people h= elp things that serve. 

Dino 


On Jul 6, 2013, at 4:21 AM, Damien Saucez <damien.saucez@gmail.com> wrote:



My "Mass&quo= t; for the LISP beer garden meeting:

The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse  - 
either by malicious hackers or by malicious owners, or the alliance of= both. Who is able to control these servers is able to control  intern= et forwarding.
I can imagine that the RSA would like LISP very much.


Don't worry, before you traffic to be encapsulated by LISP you will us= e DNS...

Damien Saucez


Heiner
  

_______________________________________________
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.ie= tf.org/mailman/listinfo/lisp
--_000_ED1058B94F6F4CA4808820D616B47D45Contextreamcom_-- From jnc@mercury.lcs.mit.edu Mon Jul 8 06:03:55 2013 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 1DEAB21F9A63 for ; Mon, 8 Jul 2013 06:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4fW-Ml3K+Qe for ; Mon, 8 Jul 2013 06:03:50 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id C847D21F9262 for ; Mon, 8 Jul 2013 06:03:50 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BBCCD18C14F; Mon, 8 Jul 2013 09:03:47 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130708130347.BBCCD18C14F@mercury.lcs.mit.edu> Date: Mon, 8 Jul 2013 09:03:47 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 13:03:55 -0000 While working on the LISP architecture documents, I found that we did not have (as far as I could tell) an online LISP bibliography, listing the (increasingly) large number of papers on LISP (something I had a need for). I have put one together: http://www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html It does not yet contain all the I-D's - I will add them once I have time (i.e. after I get these documents out). Please let me know of any fixes/additions, and I'll make them. Noel From hoefling@informatik.uni-tuebingen.de Mon Jul 8 06:34:08 2013 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 579B321F9A2E for ; Mon, 8 Jul 2013 06:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIdtFn7i-F3F for ; Mon, 8 Jul 2013 06:34:04 -0700 (PDT) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD121F9A3B for ; Mon, 8 Jul 2013 06:34:02 -0700 (PDT) Received: from [134.2.11.130] (thanatos.Informatik.Uni-Tuebingen.De [134.2.11.130]) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id r68DY0Mu007680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Jul 2013 15:34:01 +0200 Message-ID: <51DABFD6.3050705@informatik.uni-tuebingen.de> Date: Mon, 08 Jul 2013 15:34:14 +0200 From: Michael Hoefling Organization: University of Tuebingen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: lisp@ietf.org References: <20130708130347.BBCCD18C14F@mercury.lcs.mit.edu> In-Reply-To: <20130708130347.BBCCD18C14F@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.26; spam filter version: 3.2.0/2.3; host: mx08) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.2.12.70; VDF: 7.11.89.80; host: mx08); id=2157-oKGdtG Subject: Re: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 13:34:08 -0000 Dear Noel, Thank you for providing the bibliography. It would be nice if you could add the following references to the bibliography: Section "Mapping Systems": Michael Hoefling, Michael Menth, and Matthias Hartmann: A Survey of Mapping Systems for Locator/Identifier Split Internet Routing, in IEEE Communications Surveys and Tutorials (COMST), accepted for publication, 2013, IEEE http://dx.doi.org/10.1109/SURV.2013.011413.00039 http://atlas2.informatik.uni-tuebingen.de/menth/papers/Menth13c.pdf Michael Menth, Matthias Hartmann, and Michael Hoefling: FIRMS: A Mapping System for Future Internet Routing, in IEEE Journal on Selected Areas in Communications (JSAC), Special Issue on "Internet Routing Scalability", vol. 28, no. 8, October 2010, IEEE http://dx.doi.org/10.1109/JSAC.2010.101010 http://atlas2.informatik.uni-tuebingen.de/menth/papers/Menth10p.pdf The COMST paper provides an extensive overview on mapping system for locator/identifier split routing. Section "Mobility": Dominik Klein, Matthias Hartmann, and Michael Menth: NAT Traversal for LISP Mobile Node, in Proceedings of the 10th ACM CoNEXT Workshop Re-Architecting the Internet Workshop (ReArch), Philadelphia, PA, USA, November 2010. http://doi.acm.org/10.1145/1921233.1921243 http://dl.acm.org/authorize?338859 Section "Simulators": Dominik Klein, Michael Hoefling, Matthias Hartmann, and Michael Menth: Integrating LISP and LISP-MN into INET, in Proceedings of the 5th International Workshop on OMNeT++, March 2012, Desenzano, Italy http://dl.acm.org/citation.cfm?id=2263066 Best regards, Michael Am 08.07.2013 15:03, schrieb Noel Chiappa: > While working on the LISP architecture documents, I found that we did not have > (as far as I could tell) an online LISP bibliography, listing the > (increasingly) large number of papers on LISP (something I had a need for). I > have put one together: > > http://www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html > > It does not yet contain all the I-D's - I will add them once I have time > (i.e. after I get these documents out). > > Please let me know of any fixes/additions, and I'll make them. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Dipl.-Inform. Michael Hoefling, M.Sc. University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70507, fax: (+49)-7071/29-5220 mailto: hoefling@uni-tuebingen.de http://kn.inf.uni-tuebingen.de/staff/hoefling From farinacci@gmail.com Mon Jul 8 09:22:10 2013 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 3B6DE21F9CA8 for ; Mon, 8 Jul 2013 09:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4-2mgNGUlH1 for ; Mon, 8 Jul 2013 09:22:09 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id E7C5E21F9CA2 for ; Mon, 8 Jul 2013 09:22:08 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so4450841pbc.11 for ; Mon, 08 Jul 2013 09:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=LcgsfuS21JUKzEAfbr/PuLieMYoDsJShB8uXevJsaLU=; b=Ku1vMWrX3KxBX8sY2hhMWoGZxXKKUiplzDTaVrhXwGfFcraELGKbZ++9HQudTwhMB+ vbRDDGgNDRQwAX6wbWLprSo2N0XBhncS/je41jhcbcCL5uzprhs59HO1V8WiIJg9dr4f 0LdC0WzVX1vlLgoSs89E2JWsqscutyhqrRD/9kGTJwMfFBaObD/k3Tx3NzcmmAZ1hbPs h5eVmkc2prMUIeJO/oLI5HZ5ZeSN3SxB5FXAJ9qxN+9BMaZBjt6TI7vRcNfvFJG0TjLL 8/Vu3uetdMdX+ZPVp3WaTWqT1qUvyC0p13hflR7+S6eupZCpgzxbXRxmavzc4mvzRzII kubw== X-Received: by 10.68.213.5 with SMTP id no5mr22092575pbc.185.1373300528640; Mon, 08 Jul 2013 09:22:08 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id xl3sm23287263pbb.17.2013.07.08.09.22.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 09:22:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <20130708130347.BBCCD18C14F@mercury.lcs.mit.edu> Date: Mon, 8 Jul 2013 09:22:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130708130347.BBCCD18C14F@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1503) Cc: lisp@ietf.org Subject: Re: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 16:22:10 -0000 It might be useful to put this link on the LISP wiki page. Thanks for = compiling the sources Noel! Dino On Jul 8, 2013, at 6:03 AM, jnc@mercury.lcs.mit.edu (Noel Chiappa) = wrote: > While working on the LISP architecture documents, I found that we did = not have > (as far as I could tell) an online LISP bibliography, listing the > (increasingly) large number of papers on LISP (something I had a need = for). I > have put one together: >=20 > http://www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html >=20 > It does not yet contain all the I-D's - I will add them once I have = time > (i.e. after I get these documents out). >=20 > Please let me know of any fixes/additions, and I'll make them. >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Mon Jul 8 09:42:02 2013 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 3ACB221F9D7F for ; Mon, 8 Jul 2013 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRVFz+Vncxhu for ; Mon, 8 Jul 2013 09:42:01 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 267E921F9D9E for ; Mon, 8 Jul 2013 09:41:43 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so4557514pac.26 for ; Mon, 08 Jul 2013 09:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HTb3mf95juf60lX5I8ebToxwGHN7uu9tEAnyNTQWUfE=; b=E8gvfHa4BW8Ptl6ysnPieiokby/7s+4shFi4JZxKlEunI7+xaQi2S3k6QOePDf4QOY GAYZ7AAMZtaMdYYnJsQjOv/uWPU6oGE0e2Y39xgYKZQ4u+undciqoS7Q9tywmyAt7/vs MlBb67hpAj0i671PB2tCIH9P+ruz5QFz43shwYbTo5mqLudWxLhbexnUj/946qToelXA NdvfnIU62mN+OE3PMaM5sGh6azjU4xe4o/1R+5Adn61gJ33wYhNfVCj+1NaFwrq0a995 kGoG/1/6BNZyxHZE8CRiB78NJtCPsBiYMqif3u9WROlKYNH7Bqq9P6wSMXl/7MXX2zBu rRRQ== X-Received: by 10.66.191.226 with SMTP id hb2mr24047803pac.76.1373301702209; Mon, 08 Jul 2013 09:41:42 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id nr8sm12318428pbc.6.2013.07.08.09.41.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 09:41:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <6FFCD2B684E3EE4A96850F334095D67707CAABBA@xmb-aln-x12.cisco.com> Date: Mon, 8 Jul 2013 09:41:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46754BAD-A07B-492E-B272-9EA5BF27DAB0@gmail.com> References: <6FFCD2B684E3EE4A96850F334095D67707CAABBA@xmb-aln-x12.cisco.com> To: "Rockson Li (zhengyli)" X-Mailer: Apple Mail (2.1503) Cc: "lisp@ietf.org" Subject: Re: [lisp] On piggyback map rec handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 16:42:02 -0000 > Dino, >=20 > Are you saying the it's up to ETR to select the either way to go? Well the ETR is getting information from an ITR. If it wants to believe = the information, it has the right to. But if it wants to verify the = information, it should be able to as well. > I think this is confusing, the case 1) is very similar to case 3), It is not confusing. Here is an example Rockson: (1) You are sending me an email. (2) I choose to believe it is from you. (3) This email could be from Darrel. I really don't know. But my policy is to be on the honor system. > Why the rfc says "then the ETR MUST send the "verifying Map-Request" = to > the "piggybacked" EID. " but not for case 3) We had to negotiate RFC language with the working group. Dino >=20 > Thanks > Regards, > -Rockson >=20 > On 7/6/13 1:48 AM, "Dino Farinacci" wrote: >=20 >>> 1) it does not have this mapping in the map-cache >>> originate a "verifying Map-Request", addressed to the map-requesting = ITR >>> Question: would the verifying Map-Request sent to the "piggybacked" = EID >>> or directly to the ITRs using the one of RLOC in the Map records? >>=20 >> It can yes. >=20 From farinacci@gmail.com Mon Jul 8 09:50:09 2013 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 54DA521F8F09 for ; Mon, 8 Jul 2013 09:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.939 X-Spam-Level: X-Spam-Status: No, score=-3.939 tagged_above=-999 required=5 tests=[AWL=1.460, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x98ROYsD3R53 for ; Mon, 8 Jul 2013 09:50:08 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 34EE521F8E37 for ; Mon, 8 Jul 2013 09:50:08 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so4515490pad.23 for ; Mon, 08 Jul 2013 09:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PtiWcUh9o9/j5T4dm2nCSCJb4Zz0my1UwtCSQFiah9w=; b=KPy4r7eVBYlszA1xcKL567U2YAfUjUmxmKaSQ7AhrgtXU8FWlzKm3BMymTmdm2qoEr 1fjfFyGc9ZY1hXMZgNXpVmpQbvSqc3HxTp6fXTCIBOIzKALoBxwJAZBx2RcdKdo4Ogiq oVFFv33loaAk+H49b/ZuBPIwdeARYJ9IAc3Pj6r/D/z363LMkRrD0+Q/QC/P2DKRVYDJ qEl+xwIopfYBzFHdmLvauYS1qq6wM3OIOFiMoyUVZt4iARFFhZNcWVHkClEv++AaD1WW 5u4lqwxS0g3ff0PLaCh1nRbuqQ/sZov0aUwfomXvK46JpkUs4Y5gVYiLHxVd20JVh0h3 ovbA== X-Received: by 10.68.239.164 with SMTP id vt4mr12277293pbc.115.1373302207900; Mon, 08 Jul 2013 09:50:07 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id vb8sm23408145pbc.11.2013.07.08.09.50.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 09:50:06 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <8D049DA8CF914BA-A38-14A46@webmail-d178.sysops.aol.com> Date: Mon, 8 Jul 2013 09:50:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F0DB152-CC65-44DF-8AC6-60A3A4256693@gmail.com> References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> <8D049549753AB68-EF4-9703D@webmail-m257.sysops.aol.com> <83605EFB-A0B9-4E43-A6FA-5AB75A23A98F@gmail.com> <8D049DA8CF914BA-A38-14A46@webmail-d178.sysops.aol.com> To: heinerhummel@aol.com X-Mailer: Apple Mail (2.1503) Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 16:50:09 -0000 > See my notes starting with HH inside. > Heiner >=20 >=20 > -----Urspr=FCngliche Mitteilung-----=20 > Von: Dino Farinacci > An: heinerhummel > Cc: damien.saucez ; lisp > Verschickt: So, 7 Jul 2013 8:59 pm > Betreff: Re: [lisp] No LISP meeting for Berlin >=20 >> "...But I would like to think we live in a world where people help = things that serve. " >>=20 >>=20 >> Dino,really? >=20 > Yes - really. When you post an email like you did (and you do it = repeatedly with little technical data), I have to respond that way.=20 >=20 > HH: Here is all technical detail: = http://www.igi-global.com/chapter/topology-aggregating-routing-architectur= e-tara/77501 >> By our last dispute a while ago I learnt that LISP does NOTHING to = ease the IPv4 >=20 > And it never claimed to solve this problem. It you know what? It does = help because you can use other address spaces to help the allocation of = devices. So you can use IPv6 EIDs for site devices versus IPv4 = addresses. Allowing more IPv4 addresses to be used for RLOCs and = therefore be able to address more sites.=20 >=20 > HH: But anyone who sees that the IPv4-address is enhanced by another 4 = octets locator is tempted to assume The other 4 octets is the RLOC. That is basically ephemeral and is the = "current location" of the IPv4 address. Where the IPv4 address is more = "static" and assigned to the layer-4 communicating entity. > that uniqueness is provided by some unique combination of IPv4 address = + locator. Just as if a postal letter is sent to some Mr. Smith, or Mr. = Li, or Herr Meier or Mr. Dupont. And btw, I am not sure whether that = wasn't an initial argument in favor of LISP, otherwise I would have = brought up this issue years earlier. Not true at the transport layer and for any application referrals to = addresses. The EID must be unique because that is the transport = architecture requirement. We have NATs so we can reuse addresses in a = local scope but still communicate globally. >> adress depletion issue (well, it rather eats up some extra = addresses). >> While by involving the user as well as the DNS (i.e. by mapping a = FQDN to IPv4 >=20 > How is LISP involving the user? >=20 > HH: LISP is not involving the user, that is my reproach. If there were = no IPv4 address depletion issue then it would be a pro-argument not to = involve the user. But a) we are used to getting WINDOW-updates every now = and then, and b) by expanding the IPv4 address space by O(2^32) that = pro-argument is overruled by far. (TARA would even provide an = IPv4-address space extension of O(2^40) !!! ) >=20 >> address + Locator) the IPv4 address space could easily do for another = thousand years (all it takes is to ensure that any IPv4-address is = unique per associated locator) LISP-DDT prevents that for good, and you = make us believe that LISP would be of any service to IPv4 ?! >=20 > LISP-DDT is a database to move Map-Request around. It says nothing = about how and how much address is allocated.=20 >=20 > HH: Right, sounds very innocently. But even LISP 2.0 (I guess) had = once been better . Heiner, please don't be stuck in one point of time. The LISP design has = evolved over the past 6.5 years. We don't have 1.0 or 2.0 anymore. We = have simply this: (1) A data-plane made up of ITRs, ETRs, RTRs, PxTRs. That do = map-and-encap. (2) A control-plane that defines an API for the components in (1) to = access the mapping database. That API is the use of Map-Requests, = Map-Replies, Map-Registers, and Map-Notify messages among mapping = database components which are Map-Resolvers and Map-Servers. (3) We connect all the Map-Resolvers and Map-Servers together with = LISP-DDT nodes using the DNS iterative model lookup approach. That is LISP today. That is what vendors are shipping and that is how it = is being deployed. The LISP-DDT in (3) is viewed or defined as a = "mapping database transport system", which is modular and can be pulled = out and another MDTS can be put. In some to mention are ALT, SH-DHT, or = NERD. Dino >> The bad thing is that very very precious time goes by while (naive) = people/observers trust in LISP on this respect. >=20 > Because it is becoming proven in their experience.=20 > HH: I never doubted that LISP would just work as you have had it in = your mind, nor that you would be able to adjust it such that it suits = all existing forwarding mechanisms. > =20 >=20 >> Just like myself when I argued that LISP-DDT cannot work assuming = that LISP were after a 4+4 octet unicast address space extension. >>=20 >> But you let all up to NAT. This is really not a serve. >=20 > I cannot parse the above.=20 >=20 > Dino >=20 >>=20 >> Sorry, >> Heiner >> (having nothing said about the dooming malicious/political problems = yet) >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Urspr=FCngliche Mitteilung-----=20 >> Von: Dino Farinacci >> An: Damien Saucez >> Cc: heinerhummel ; lisp >> Verschickt: Sa, 6 Jul 2013 8:01 pm >> Betreff: Re: [lisp] No LISP meeting for Berlin >>=20 >> There are servers everywhere. Even not on the Internet. We leave in a = world of abuse. But I would like to think we live in a world where = people help things that serve.=20 >>=20 >> Dino=20 >>=20 >>=20 >> On Jul 6, 2013, at 4:21 AM, Damien Saucez = wrote: >>=20 >>>=20 >>> On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: >>>=20 >>>> My "Mass" for the LISP beer garden meeting: >>>>=20 >>>> The LISP's dependency on special servers (DDT, formerly ALT) is a = perfect invitation for abuse -=20 >>>> either by malicious hackers or by malicious owners, or the alliance = of both. Who is able to control these servers is able to control = internet forwarding. >>>> I can imagine that the RSA would like LISP very much. >>>>=20 >>>=20 >>> Don't worry, before you traffic to be encapsulated by LISP you will = use DNS... >>>=20 >>> Damien Saucez >>>=20 >>>>=20 >>>> Heiner >>>> =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 gschudel@cisco.com Mon Jul 8 10:50:48 2013 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 6299821F9B9F for ; Mon, 8 Jul 2013 10:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcmPGdpi259H for ; Mon, 8 Jul 2013 10:50:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BD9DA21F9B26 for ; Mon, 8 Jul 2013 10:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=811; q=dns/txt; s=iport; t=1373305842; x=1374515442; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QfNYGOL/N985OpfbipuLpyCnJgydDjUakDEkxCWU3To=; b=IT/1Y4MuTMnMwuXw69rM+czADFT9bhrnXLxjrJ/uH6KDtRT1+gi0KOEh bLJzScJLEKncXgBbg5XcbK8S3H+bc2vZUJxKwqHdsFyecAuPwCxVonvq8 dB8i45wJLI88nSuxcHCarbijOl8fUH49j7JBrZGvvO3C0Pn+txgVc7b8g w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFACX72lGtJXG9/2dsb2JhbABXA4MJMk2CQb4sgRQWdIIjAQEBAwE6NQoFCwIBCCIUECERJQIEDgUIh3UDCQYMsFANiFGNAIEpgQ8CIRACBRGCdmkDlWyOCoUlgxGBcTc X-IronPort-AV: E=Sophos;i="4.87,1021,1363132800"; d="scan'208";a="232038704" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jul 2013 17:50:40 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r68HoFbI000993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 17:50:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 12:50:33 -0500 From: "Gregg Schudel (gschudel)" To: Dino Farinacci Thread-Topic: [lisp] LISP online bibliography Thread-Index: AQHOe9ucm9I56RxNnE61EtqICWIl5ZlbSrCAgAAYs4A= Date: Mon, 8 Jul 2013 17:50:33 +0000 Message-ID: References: <20130708130347.BBCCD18C14F@mercury.lcs.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.162] Content-Type: text/plain; charset="us-ascii" Content-ID: <27279F5A2EA7FC45ACF684FA4562B013@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Noel Chiappa , "" Subject: Re: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 17:50:48 -0000 On Jul 8, 2013, at 9:22 AM, Dino Farinacci wrote: > It might be useful to put this link on the LISP wiki page. Thanks for com= piling the sources Noel! >=20 > Dino this is a really fine resource Dino I'll add it to our sites and the LISP Beta site. Noel - thank you for putting this together ! Best regards, Gregg -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement:=20 http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From farinacci@gmail.com Mon Jul 8 11:24:56 2013 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 56BA521F9D0C for ; Mon, 8 Jul 2013 11:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaTZS-7tdetM for ; Mon, 8 Jul 2013 11:24:50 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0406C21F9D2D for ; Mon, 8 Jul 2013 11:24:44 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so4576036pbc.31 for ; Mon, 08 Jul 2013 11:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dZCFytx6wGHhAQni4rJszWeOXrNw1Di4oIvE4uDjdRs=; b=GCxjJWcocd9JGYoD9Khg1rqC2Oty98WaPC8aF3977niSBjQYk69qZ50cx1lqgSdSv1 SkU0sqZN0JJMN2a1dihCX4dw5aNgpWNNRDlYeeMaWYTs3i6kLbIN7xJ0XHEGgmPOz6kw 7abUt1La2SGpj1X5CmuSuBu6Z3dMFQP9jy0o1e+TMVNjOqwt7W5PVDwn7JPeD4CJg4vT uzD9UsNM+pBk8KleAWHlHDNJNKZ0rBuJkRFbqi9inAylbtF2Rq3ZDCf+fM0VqbkMFd+/ KQdTfciChsS7Hpr4syu4iUA979F5nUK8oLC1Uk0n0cymJKoMVnPSIdGxWqBYpRmyIa00 dVkw== X-Received: by 10.68.218.132 with SMTP id pg4mr611673pbc.200.1373307884702; Mon, 08 Jul 2013 11:24:44 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id dg3sm23733902pbc.24.2013.07.08.11.24.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 11:24:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: Date: Mon, 8 Jul 2013 11:24:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <722EC7AD-8F76-40D1-A131-D9A4C96703A1@gmail.com> References: <20130708130347.BBCCD18C14F@mercury.lcs.mit.edu> To: "Gregg Schudel (gschudel)" X-Mailer: Apple Mail (2.1503) Cc: Noel Chiappa , "" Subject: Re: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 18:24:57 -0000 That is good but I guess I could have been not clear. I meant the LISP = Wikipedia web page. Dino On Jul 8, 2013, at 10:50 AM, "Gregg Schudel (gschudel)" = wrote: >=20 > On Jul 8, 2013, at 9:22 AM, Dino Farinacci = wrote: >=20 >> It might be useful to put this link on the LISP wiki page. Thanks for = compiling the sources Noel! >>=20 >> Dino >=20 > this is a really fine resource Dino >=20 > I'll add it to our sites and the LISP Beta site. >=20 > Noel - thank you for putting this together ! >=20 >=20 > Best regards, > Gregg >=20 > -------------------------------------------------------------------- > .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr > cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com > -------------------------------------------------------------------- > cisco corporate legal statement:=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -------------------------------------------------------------------- >=20 >=20 >=20 >=20 >=20 From gschudel@cisco.com Mon Jul 8 11:27:25 2013 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 A52EA21F9D2D for ; Mon, 8 Jul 2013 11:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NezZac8EIUXA for ; Mon, 8 Jul 2013 11:27:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 071CE21F9C86 for ; Mon, 8 Jul 2013 11:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=689; q=dns/txt; s=iport; t=1373308029; x=1374517629; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0y3DyZkOHSMNuGaxvMLlAJPQAMH2f6HiCqrO3iRMwd4=; b=PZw/9Wrhiwt8ktoxddEVNzTnuip6XHDfThZrzEOVImoypjhdulxOyrnS KvPesuIL5F4de5DSh4JNAk9/Zn041OF8eXfJrEq8QYM4QInn7X/iTjFSa 4aWMNQmYyfKCZfoPoNOAkDVgmkgEp+keo56HS5VxKOG9b+h+BQyySy9pj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAPAC21GtJV2Z/2dsb2JhbABXA4MJMk2CQb4sgRYWdIIjAQEBAwE6NQoFCwIBCCIUECERJQIEDgUIh3UDCQYMsEYNiFGNAIEpgQ8CIRACBRGCdmkDlWyOCoUlgxGBcTc X-IronPort-AV: E=Sophos;i="4.87,1021,1363132800"; d="scan'208";a="232266034" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jul 2013 18:27:08 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r68IR7M9003003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 18:27:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 13:27:07 -0500 From: "Gregg Schudel (gschudel)" To: Dino Farinacci Thread-Topic: [lisp] LISP online bibliography Thread-Index: AQHOe9ucm9I56RxNnE61EtqICWIl5ZlbSrCA///OfX2AAFRtAA== Date: Mon, 8 Jul 2013 18:27:06 +0000 Message-ID: References: <20130708130347.BBCCD18C14F@mercury.lcs.mit.edu> <722EC7AD-8F76-40D1-A131-D9A4C96703A1@gmail.com> In-Reply-To: <722EC7AD-8F76-40D1-A131-D9A4C96703A1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.162] Content-Type: text/plain; charset="us-ascii" Content-ID: <85DE25F1E3526645A511D2EF7435702A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Noel Chiappa , "" Subject: Re: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 18:27:25 -0000 On Jul 8, 2013, at 11:24 AM, Dino Farinacci wrote: > That is good but I guess I could have been not clear. I meant the LISP Wi= kipedia web page. >=20 > Dino Ack - gotcha. Best regards, Gregg -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement:=20 http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From jnc@mercury.lcs.mit.edu Mon Jul 8 11:42:51 2013 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 BFCFD21F9D2A for ; Mon, 8 Jul 2013 11:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmx6uKe8RvRo for ; Mon, 8 Jul 2013 11:42:47 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6909521F9CF6 for ; Mon, 8 Jul 2013 11:42:45 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C532118C14C; Mon, 8 Jul 2013 14:42:42 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130708184242.C532118C14C@mercury.lcs.mit.edu> Date: Mon, 8 Jul 2013 14:42:42 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 18:42:51 -0000 > From: Dino Farinacci > I meant the LISP Wikipedia web page. Err, already done? "Add new online bibliography page" http://en.wikipedia.org/w/index.php?title=Locator/Identifier_Separation_Protocol&action=history Noel From farinacci@gmail.com Mon Jul 8 14:43:48 2013 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 74B3521F9E24 for ; Mon, 8 Jul 2013 14:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FRTixnjBa80 for ; Mon, 8 Jul 2013 14:43:47 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A700221F9E48 for ; Mon, 8 Jul 2013 14:43:47 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so4744261pbc.21 for ; Mon, 08 Jul 2013 14:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NPk5mYcpV6GLVrw2ha/B+zLUPcUw2Zjga+J7OBZ8rzQ=; b=iXG9u8hghw7k5+CdqrX5/rcbxhaCL5OVg4tdLwT0d3qkVuTMky0SIpYR21kqeyX9vB TtJOeH8q/5MN2FNLHBQwJm1irpj0/1+P7+D5lCaOKGdoPQ4xcug4dntojwUQuGQx7avw WZrbMcwC6XWcXydUQexwh3PXRFKLqhCk0HYijHt6dEKo9hqGRfQ/wm7xv2UTBqpxdbx/ A7thgWU2fGp08qxN1cy4k7l4Akcodzv0OOmanXWO5P0J1tpHAmabG8R/JmNW5Zai77z6 jbYtIKw4iVBxIF2ZOtOMRBXq9tz50mviNaPs5sNZEQFO8AyLxA32PUwuoefM8xKgjLHb FOYQ== X-Received: by 10.66.84.8 with SMTP id u8mr24630844pay.81.1373319827188; Mon, 08 Jul 2013 14:43:47 -0700 (PDT) Received: from [192.168.13.208] (c-98-210-178-243.hsd1.ca.comcast.net. [98.210.178.243]) by mx.google.com with ESMTPSA id nr8sm13308829pbc.6.2013.07.08.14.43.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 14:43:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <20130708184242.C532118C14C@mercury.lcs.mit.edu> Date: Mon, 8 Jul 2013 14:43:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0BD8188F-C7D7-4214-8F3B-2E1C5F4E275D@gmail.com> References: <20130708184242.C532118C14C@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1503) Cc: lisp@ietf.org Subject: Re: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 21:43:48 -0000 Thanks! Dino On Jul 8, 2013, at 11:42 AM, jnc@mercury.lcs.mit.edu (Noel Chiappa) = wrote: >> From: Dino Farinacci >=20 >> I meant the LISP Wikipedia web page. >=20 > Err, already done? >=20 > "Add new online bibliography page" > = http://en.wikipedia.org/w/index.php?title=3DLocator/Identifier_Separation_= Protocol&action=3Dhistory >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From heinerhummel@aol.com Tue Jul 9 02:46:50 2013 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 EF19721F9F9B for ; Tue, 9 Jul 2013 02:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-quRCOf6H2M for ; Tue, 9 Jul 2013 02:46:45 -0700 (PDT) Received: from omr-d04.mx.aol.com (omr-d04.mx.aol.com [205.188.109.201]) by ietfa.amsl.com (Postfix) with ESMTP id 19E1521F9F9A for ; Tue, 9 Jul 2013 02:46:45 -0700 (PDT) Received: from mtaomg-da04.r1000.mx.aol.com (mtaomg-da04.r1000.mx.aol.com [172.29.51.140]) by omr-d04.mx.aol.com (Outbound Mail Relay) with ESMTP id 077E170047BD9; Tue, 9 Jul 2013 05:46:44 -0400 (EDT) Received: from core-dqd005c.r1000.mail.aol.com (core-dqd005.r1000.mail.aol.com [172.29.162.17]) by mtaomg-da04.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id BED9BE000081; Tue, 9 Jul 2013 05:46:43 -0400 (EDT) References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> <8D049549753AB68-EF4-9703D@webmail-m257.sysops.aol.com> <83605EFB-A0B9-4E43-A6FA-5AB75A23A98F@gmail.com>, <8D049DA8CF914BA-A38-14A46@webmail-d178.sysops.aol.com> To: Sharon@Contextream.com In-Reply-To: X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-d279.sysops.aol.com (205.188.16.108) with HTTP (WebMailUI); Tue, 09 Jul 2013 05:46:43 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D04AA05AB3C58D_F50_20CE9A_webmail-d279.sysops.aol.com" X-Mailer: Webmail 37834-STANDARD Message-Id: <8D04AA05974CCC7-F50-A4A69@webmail-d279.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Tue, 9 Jul 2013 05:46:43 -0400 (EDT) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1373363203; bh=nBGq0OHCHxnkjHEa3Uoo1sRgnmNZb7Et+FMJFLUSa+E=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=x2WdkCKenHvDMHMiBz/0fL4wAjW5HvgfDex8X1vZ+c+5Hf0fZtEDJfgqa9/akGOLl Cgq5Mm+2NOt66sPbTUogrzsFeriFaQ0CoPYbCzo3ofKmIls5ygQVTE8eV9fj4EKoPN ZqmDHacloL7X3s6S46U8f+NJJYPRPQpIojo0xpZc= X-AOL-SCOLL-SCORE: 0:2:451068736:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d338c51dbdc037cc1 Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 09:46:50 -0000 This is a multi-part message in MIME format. ----------MB_8D04AA05AB3C58D_F50_20CE9A_webmail-d279.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Indeed, there are immensely many useful capabilities provided that address= ing would serve routing which is about the WHERE, WHERE-TO and WHERE-FROM. Consider E.164 : There are country codes and inside which ever country wher= e Siemens EWSD switches were deployed each rotary dialed digit did select l= ink after link electro-mechanically !!! down to the destination. Inside Ger= many the leading digit "3" was spared for the Eastern part while most the W= estern politician had given up hope for the reunion and all of the Eastern = part did everything to prevent it. Whereas IP addressing is as WHERE-agnostic as is MAC-addressing or AS numbe= ring. No WHERE-knowledge nowhere. Conex doesn't recognize areas of congesti= on, multi-homing is a "let's try the other link"-game as to await what migh= t happen. Columbus-Routing (knowing that the earth is a ball) is out of que= stion being against the holy DV-doctrine. DiffServ is proud to operate without any knowledge about what is beyond the= waiting queues for incoming packets. IPv6 defines an Anycast address space= without scopes that limited the area of being advertised. Examples: A Any= cast-destination "free parking lot" might only be disseminated inside the o= wn city i.e. not outside of it. A Anycast-destination "gas station" might o= nly be disseminated over some area whose radius corresponds with the remain= ing miles indicated by a warning display to the driver.Etc.Etc. But such sc= ope is not intended at all and wouldn't even help because IPv6 is as WHERE-agno= stic as is IPv4. With the upcoming of the loc-id-split paradigm I saw the chance for a chang= e and indeed TARA, being a loc-id-split solution, would end this WHERE-agno= sticism. LISP however keeps up with it. As well as IPv6 :-( Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Sharon Barkai An: heinerhummel Cc: farinacci ; lisp Verschickt: Mo, 8 Jul 2013 1:14 pm Betreff: Re: [lisp] No LISP meeting for Berlin really don't want to interrupt this great dialog, just one comment. don't think is about a bigger address space for routing, but rather combining 2 completely different lookup schemes. Step1: you lookup the routing location of Mr. Smith, or Mr. Li, or Herr M= eier or Mr. Dupont in a huge ID "phone book" a (secure) distributed databas= e lookup problem, strictly overlay not a routing problem. Step 2: you insert the letter into an outer envelope with a postal-service = (routable) address, leverage whatever hop to hop routing lookup solution yo= u have at the moment scale, cost, efficiency wise. FedEx, ups etc. Lots of use cases and benefits. --szb On Jul 8, 2013, at 13:11, "heinerhummel@aol.com" wro= te: See my notes starting with HH inside. Heiner -----Urspr=C3=BCngliche Mitteilung----- Von: Dino Farinacci An: heinerhummel Cc: damien.saucez ; lisp Verschickt: So, 7 Jul 2013 8:59 pm Betreff: Re: [lisp] No LISP meeting for Berlin "...But I would like to think we live in a world where people help things t= hat serve. " Dino,really? Yes - really. When you post an email like you did (and you do it repeatedly= with little technical data), I have to respond that way.=20 HH: Here is all technical detail: http://www.igi-global.com/chapter/topol= ogy-aggregating-routing-architecture-tara/77501 By our last dispute a while ago I learnt that LISP does NOTHING to ease the= IPv4 And it never claimed to solve this problem. It you know what? It does help= because you can use other address spaces to help the allocation of devices= . So you can use IPv6 EIDs for site devices versus IPv4 addresses. Allowin= g more IPv4 addresses to be used for RLOCs and therefore be able to address= more sites.=20 HH: But anyone who sees that the IPv4-address is enhanced by another 4 octe= ts locator is tempted to assume that uniqueness is provided by some unique = combination of IPv4 address + locator. Just as if a postal letter is sent t= o some Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont. And btw, I am not= sure whether that wasn't an initial argument in favor of LISP, otherwise I= would have brought up this issue years earlier. adress depletion issue (well, it rather eats up some extra addresses). While by involving the user as well as the DNS (i.e. by mapping a FQDN to I= Pv4 How is LISP involving the user? HH: LISP is not involving the user, that is my reproach. If there were no I= Pv4 address depletion issue then it would be a pro-argument not to involve = the user. But a) we are used to getting WINDOW-updates every now and then, = and b) by expanding the IPv4 address space by O(2^32) that pro-argument is = overruled by far. (TARA would even provide an IPv4-address space extension = of O(2^40) !!! ) address + Locator) the IPv4 address space could easily do for another thous= and years (all it takes is to ensure that any IPv4-address is unique per as= sociated locator) LISP-DDT prevents that for good, and you make us believe = that LISP would be of any service to IPv4 ?! LISP-DDT is a database to move Map-Request around. It says nothing about ho= w and how much address is allocated.=20 HH: Right, sounds very innocently. But even LISP 2.0 (I guess) had once be= en better . The bad thing is that very very precious time goes by while (naive) people/= observers trust in LISP on this respect. Because it is becoming proven in their experience.=20 HH: I never doubted that LISP would just work as you have had it in your mi= nd, nor that you would be able to adjust it such that it suits all existing= forwarding mechanisms. =20 Just like myself when I argued that LISP-DDT cannot work assuming that LISP= were after a 4+4 octet unicast address space extension. But you let all up to NAT. This is really not a serve. I cannot parse the above.=20 Dino Sorry, Heiner (having nothing said about the dooming malicious/political problems yet) -----Urspr=C3=BCngliche Mitteilung----- Von: Dino Farinacci An: Damien Saucez Cc: heinerhummel ; lisp Verschickt: Sa, 6 Jul 2013 8:01 pm Betreff: Re: [lisp] No LISP meeting for Berlin There are servers everywhere. Even not on the Internet. We leave in a world= of abuse. But I would like to think we live in a world where people help t= hings that serve.=20 Dino=20 On Jul 6, 2013, at 4:21 AM, Damien Saucez wrote: On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: My "Mass" for the LISP beer garden meeting: The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse -=20 either by malicious hackers or by malicious owners, or the alliance of both= . Who is able to control these servers is able to control internet forward= ing. I can imagine that the RSA would like LISP very much. Don't worry, before you traffic to be encapsulated by LISP you will use DNS= ... Damien Saucez Heiner =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 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ----------MB_8D04AA05AB3C58D_F50_20CE9A_webmail-d279.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Indeed, there are immensely= many useful capabilities provided that  addressing would serve routin= g which is about the WHERE, WHERE-TO and WHERE-FROM.
Consider E.164 : There are country codes and inside which ever country= where Siemens EWSD switches were deployed each rotary dialed digit did sel= ect link after link electro-mechanically !!! down to the destination. Insid= e Germany the leading digit "3" was spared for the Eastern part while most = the Western politician had given up hope for the reunion and all of the Eas= tern part did everything to prevent it.

Whereas IP addressing is as WHERE-agnostic as is MAC-addressing or AS = numbering. No WHERE-knowledge nowhere. Conex doesn't recognize areas of con= gestion, multi-homing is a "let's try the other link"-game as to await what= might happen. Columbus-Routing (knowing that the earth is a ball) is out o= f question being against the holy DV-doctrine.
DiffServ is proud to operate without any knowledge about what is beyon= d the waiting queues for incoming packets. IPv6 defines an Anycast address = space without scopes that  limited the area of being advertised. Examp= les: A Anycast-destination "free parking lot" might only be disseminated in= side the own city i.e. not outside of it. A Anycast-destination "gas statio= n" might only be disseminated over some area whose radius corresponds with = the remaining miles indicated by a warning display to the driver.Etc.Etc. B= ut such scope
is not intended at all and wouldn't even help because IPv6 is as WHERE= -agnostic as is IPv4.

With the upcoming of the loc-id-split paradigm I saw the chance for a = change and indeed TARA, being a loc-id-split solution, would end this WHERE= -agnosticism.
LISP however keeps up with it. As well as IPv6 :-(

Heiner


-----= Urspr=C3=BCngliche Mitteilung-----
Von: Sharon Barkai <Sharon@Contextream.com>
An: heinerhummel <heinerhummel@aol.com>
Cc: farinacci <farinacci@gmail.com>; lisp <lisp@ietf.org>
Verschickt: Mo, 8 Jul 2013 1:14 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

really don't want to interrupt this great dialog, just one comment.

don't think is about a bigger address space for routing,
but rather combining 2 completely different lookup schemes.

Step1: you lookup  the routing location  of Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont in a huge ID "phone book"&nb= sp;a (secure) distributed database lookup problem, strictly overlay not a routi= ng problem.

Step 2: you insert the letter into an outer envelope with a postal-service (routab= le) address, leverage whatever hop to hop routing lookup solution you have = at the moment scale, cost, efficiency wise.  FedEx, ups etc.

Lots of use cases and benefits.



--szb

On Jul 8, 2013, at 13:11, "heinerhummel@aol.com" <heinerhummel@aol.com> wrote:
See my notes starting = with HH inside.
Heiner


-----= Urspr=C3=BCngliche Mitteilung-----
Von: Dino Farinacci <farinacci@gmail.com>
An: heinerhummel <heinerhummel@aol.com>
Cc: damien.saucez <damien.saucez@gmail.com>; lisp <lisp@ietf.org>
Verschickt: So, 7 Jul 2013 8:59 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

<= span style=3D"font-family: arial, helvetica;">"...But I would like to think= we live in a world where people help things that serve. "


Dino,really?

Yes - really. When you post an email like you did (and you do it repeatedly= with little technical data), I have to respond that way. 

HH: Here is all technical detai= l:   http://www.igi-global.com/chapter/topolog= y-aggregating-routing-architecture-tara/77501
By our last dispute a = while ago I learnt that LISP does NOTHING to ease the IPv4

And it never claimed to solve this problem.  It you know what? It does= help because you can use other address spaces to help the allocation of de= vices.  So you can use IPv6 EIDs for site devices versus IPv4 addresse= s. Allowing more IPv4 addresses to be used for RLOCs and therefore be able to address more sites. 

HH: But anyone who sees that the IPv4-address is enhanced by another 4= octets locator is tempted to assume that uniqueness is provided by some un= ique combination of IPv4 address + locator. Just as if a postal letter is s= ent to some Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont. And btw, I am not sure whether that wasn't an= initial argument in favor of LISP, otherwise I would have brought up this = issue years earlier.

adress depletion issue= (well, it rather eats up some extra addresses).
While by involving the user as well as= the DNS (i.e. by mapping a FQDN to IPv4

How is LISP involving the user?

HH: LISP is not involving the user, that is my reproach. If there were= no IPv4 address depletion issue then it would be a pro-argument not to inv= olve the user. But a) we are used to getting WINDOW-updates every now and t= hen, and b) by expanding the IPv4 address space by O(2^32) that pro-argument is overruled by far. (TARA woul= d even provide an IPv4-address space extension of O(2^40) !!! )

address + Locator) the IPv4 address sp= ace could easily do for another thousand years (all it takes is to ensure t= hat any IPv4-address is unique per associated locator) LISP-DDT prevents th= at for good, and you make us believe that LISP would be of any service to IPv4 ?!

LISP-DDT is a database to move Map-Request around. It says nothing about ho= w and how much address is allocated. 

HH: Right,  sounds very innocently. But even LISP 2.0 (I guess) h= ad once been better .

The bad thing is that = very very precious time goes by while (naive) people/observers trust in LIS= P on this respect.

Because it is becoming proven in their experience. 
HH: I never doubted that LISP would just work as you have had it in yo= ur mind, nor that you would be able to adjust it such that it suits all exi= sting forwarding mechanisms.
       

Just like myself when I argued that LI= SP-DDT cannot work assuming that LISP were after a 4+4 octet unicast addres= s space extension.

But you let all up to NAT. This is rea= lly not a serve.

I cannot parse the above. 

Dino


Sorry,
Heiner
 (having nothing said about the d= ooming malicious/political problems yet)






There are servers everywhere. Even not on the Internet. We leave in a = world of abuse. But I would like to think we live in a world where people h= elp things that serve. 

Dino 


On Jul 6, 2013, at 4:21 AM, Damien Saucez <damien.saucez@gmail.com> wrote:



My "Mass" for the= LISP beer garden meeting:

The LISP's dependency on special servers (DDT, formerly ALT) is a perfect i= nvitation for abuse  - 
either by malicious hackers or by malicious owners, or the alliance of= both. Who is able to control these servers is able to control  intern= et forwarding.
I can imagine that the RSA would like LISP very much.


Don't worry, before you traffic to be encapsulated by LISP you will us= e DNS...

Damien Saucez


Heiner
  

_______________________________________________
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.o= rg
https://www.ietf.org/mailman/listinfo/lisp=
----------MB_8D04AA05AB3C58D_F50_20CE9A_webmail-d279.sysops.aol.com-- From farinacci@gmail.com Tue Jul 9 07:33:09 2013 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 50EF921F9EF5 for ; Tue, 9 Jul 2013 07:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE88WEy8L04d for ; Tue, 9 Jul 2013 07:33:08 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8A66D21F9EDF for ; Tue, 9 Jul 2013 07:33:08 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so5598162pad.5 for ; Tue, 09 Jul 2013 07:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=RYRcpI82wVZYeaoTVAXZttP/7JODGVEHUabTkCPj+bk=; b=zTCfPsL0AwSvYcBsu1N/92UOExOwT+IZUeixug4XYudrdhcBUvzfYs9A5VdMw05T/m O8Xa/okTlXuFU5/ENAQrCZjoy7REJ8LyIqNhErbAysmzxSc4jns/hZiC+oF6YjymRiLi ej+aXHT9y+T3ou8IVdJPBfzCT9m2ymen02eHtncR54Db0wXhCJvUI0XTYJREvYMyiP+a TZAu5bLPSjVNS/jbmE6uVNkouqZGLVW1fCXVirBUUIrwBBK5qZzSLfFMLo2tiFRHClWq 1W1/jXlGrY6D4KY6NppgyrLAE2IVAsac5kW5RMSNCZ4JsOwN4uL6UGzi0b5lWXvpOrP6 9zqQ== X-Received: by 10.66.171.231 with SMTP id ax7mr28062686pac.32.1373380388316; Tue, 09 Jul 2013 07:33:08 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id fp2sm28563203pbb.36.2013.07.09.07.33.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 07:33:07 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7257B6D3-EF3C-4DF5-93B8-0B0047979256@gmail.com> Date: Tue, 9 Jul 2013 07:33:04 -0700 To: "lisp@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 14:33:09 -0000 Please join https://www.facebook.com/groups/407716795982512/ if you want = to learn, contribute or lurk about LISP industry activity. The group is completely open and not vendor specific, contains blogs, = articles, and comments from LISP implementors and deployers. Thanks, Dino= From marc@sniff.de Tue Jul 9 08:31:59 2013 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 28C8221F9EDA for ; Tue, 9 Jul 2013 08:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKZD4QUklbaf for ; Tue, 9 Jul 2013 08:31:58 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E7D21F9F9D for ; Tue, 9 Jul 2013 08:31:54 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 0C1AF2AA0F; Tue, 9 Jul 2013 15:31:51 +0000 (GMT) Date: Tue, 9 Jul 2013 17:31:45 +0200 From: Marc Binderberger To: Dino Farinacci Message-ID: <20130709173145033572.0983e87b@sniff.de> In-Reply-To: <7257B6D3-EF3C-4DF5-93B8-0B0047979256@gmail.com> References: <7257B6D3-EF3C-4DF5-93B8-0B0047979256@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "lisp@ietf.org list" Subject: Re: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 15:31:59 -0000 Hello Dino, seriously? IETF mail list is not working? Besides, clicking on the link below I get a login window. "completely open"? Believe it or not but I had no need to join facebook so far. Nor had any of the various IETF work groups I'm subscribed to done such a move. Is there any real advantage coming with this? Regards, Marc On Tue, 9 Jul 2013 07:33:04 -0700, Dino Farinacci wrote: > Please join https://www.facebook.com/groups/407716795982512/ if you > want to learn, contribute or lurk about LISP industry activity. > > The group is completely open and not vendor specific, contains blogs, > articles, and comments from LISP implementors and deployers. > > Thanks, > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From farinacci@gmail.com Tue Jul 9 08:51:34 2013 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 7152D21F9CD1 for ; Tue, 9 Jul 2013 08:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPOT-vm8HeAD for ; Tue, 9 Jul 2013 08:51:33 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7FE21F9D09 for ; Tue, 9 Jul 2013 08:51:33 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bi5so5659461pad.18 for ; Tue, 09 Jul 2013 08:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tNVcT6bWMTg0X9MHMde61arfOSvKxBSXtrVobVAv+LE=; b=rko0Wd/Dpq5qM0Vb2Vhn6HyJ8mldE8HLOPHxa0k3wzfD9g7i1qK69nglQ6RLY8EOwF +NHByv2586r5l3AfrYbqM3Jrhpp4nAxl5U2SPXsK5pyu+wKkDgvhtuIHR/P1hZul5Xe9 /EEh90fU/NdqVpjsa9ghKCqYFzCJ5bRUlXWJWVtfh4cm9Z/bpA4OSMMNm/OzizYQt2xq JPwokwf85gFLXoxt81kiV2zxJo1x4cAMyf0q2p4VBbNAwbN3KaQmyHAWX1cg+pkZyycz a3kPoW2LpdZxui14kXfCf8krzEp5N/pK44rdN1fBYkbhOsYH6iRRe+se0w3LCRAXV2BD 4ecA== X-Received: by 10.68.162.97 with SMTP id xz1mr27320261pbb.166.1373385092784; Tue, 09 Jul 2013 08:51:32 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id fr1sm28913310pbb.26.2013.07.09.08.51.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 08:51:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <20130709173145033572.0983e87b@sniff.de> Date: Tue, 9 Jul 2013 08:51:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1206ABF6-DBCF-44C3-847E-26B96A31C701@gmail.com> References: <7257B6D3-EF3C-4DF5-93B8-0B0047979256@gmail.com> <20130709173145033572.0983e87b@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1503) Cc: "lisp@ietf.org list" Subject: Re: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 15:51:34 -0000 > Hello Dino, >=20 > seriously? IETF mail list is not working? This FB group is outside the scope of the working group. And I believe = the working group is doing just fine. > Besides, clicking on the link below I get a login window. "completely=20= > open"? Believe it or not but I had no need to join facebook so far. There is LinkedIn group as well if you prefer. > Nor had any of the various IETF work groups I'm subscribed to done = such=20 > a move. Is there any real advantage coming with this? There is no move. Just more information. There is no hidden agenda here. Dino >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Tue, 9 Jul 2013 07:33:04 -0700, Dino Farinacci wrote: >> Please join https://www.facebook.com/groups/407716795982512/ if you=20= >> want to learn, contribute or lurk about LISP industry activity. >>=20 >> The group is completely open and not vendor specific, contains blogs,=20= >> articles, and comments from LISP implementors and deployers. >>=20 >> Thanks, >> Dino >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 From jnc@mercury.lcs.mit.edu Tue Jul 9 10:29:11 2013 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 8386521F9F7D for ; Tue, 9 Jul 2013 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIYyj266SYZP for ; Tue, 9 Jul 2013 10:29:07 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E7D6621F9F7A for ; Tue, 9 Jul 2013 10:29:02 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 16C3518C172; Tue, 9 Jul 2013 13:29:00 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130709172900.16C3518C172@mercury.lcs.mit.edu> Date: Tue, 9 Jul 2013 13:29:00 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 17:29:11 -0000 > From: Marc Binderberger > Besides, clicking on the link below I get a login window. "completely > open"? Isn't there some way to set the group up so that you don't have to be a Facebook member to look at stuff? (I thought I remembered some other FB groups that had stuff the public could look at without logging in.) The IETF WG logs really are completely open: you can read anything in: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html without any need for a login. Noel From farinacci@gmail.com Tue Jul 9 11:15:00 2013 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 56EE721F9E6C for ; Tue, 9 Jul 2013 11:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3FTBvajhQ3Y for ; Tue, 9 Jul 2013 11:14:59 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C02BC21F9D9D for ; Tue, 9 Jul 2013 11:14:47 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so5495249pdd.6 for ; Tue, 09 Jul 2013 11:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Jz1tmzHWCp51+rRjSzcLc3NPG9F0QOU7pTLzsWHeJ9k=; b=nKqXx0jSUKt3aCBFCH5NlsVrvZNSQJcSaqMbGH9PEUI/xJhI1/bano4vVaj3LeXEd+ pYeaPn5wdabzpq2C0gljtI+sNIw0/nAedniNHg62dCRrAAUUPyLg2knQqf2wxnCyxUuL slKOtBCSgTXcQVwA6GM+H9WX68i9S1EoCV6JpkXFpuYhorZeJFBvUrQcZpCGmhHAZxvl FVdlYShNnt/iLlhM/hGMmfPy/yBTIYbadQxEpO/BVTBvo8XV4yQyBFefMmPQDcfNfqt7 EiLMDbBfneYUy/ehKLOfS87Um1Xc6sch4sqh+G3347JQAgodI0OUpbNgSiyaq84xJuEl vy5g== X-Received: by 10.66.224.73 with SMTP id ra9mr29432839pac.163.1373393687516; Tue, 09 Jul 2013 11:14:47 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id vi8sm20883397pbc.31.2013.07.09.11.14.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 11:14:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <20130709172900.16C3518C172@mercury.lcs.mit.edu> Date: Tue, 9 Jul 2013 11:14:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20130709172900.16C3518C172@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1503) Cc: "lisp@ietf.org list" , Donn Lee Subject: Re: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 18:15:00 -0000 I haven't found a way. I have cc'ed Donn. He may know or can ask Zuck. ;-) Dino On Jul 9, 2013, at 10:29 AM, jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote: >> From: Marc Binderberger > >> Besides, clicking on the link below I get a login window. "completely >> open"? > > Isn't there some way to set the group up so that you don't have to be a > Facebook member to look at stuff? (I thought I remembered some other FB > groups that had stuff the public could look at without logging in.) > > The IETF WG logs really are completely open: you can read anything in: > > http://www.ietf.org/mail-archive/web/lisp/current/maillist.html > > without any need for a login. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Tue Jul 9 11:33:52 2013 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 5F40621F9E5C; Tue, 9 Jul 2013 11:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk6DKV1MWli5; Tue, 9 Jul 2013 11:33:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2AB21F9E42; Tue, 9 Jul 2013 11:33:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709183351.7964.1897.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 11:33:51 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 18:33:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP Network Element Deployment Considerations Author(s) : Lorand Jakab Albert Cabellos-Aparicio Florin Coras Jordi Domingo-Pascual Darrel Lewis Filename : draft-ietf-lisp-deployment-09.txt Pages : 26 Date : 2013-07-09 Abstract: This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-deployment-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-deployment-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lojakab@cisco.com Tue Jul 9 11:45:15 2013 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 880CB21F9732; Tue, 9 Jul 2013 11:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tljGcqH6q9nS; Tue, 9 Jul 2013 11:45:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 821B721F9638; Tue, 9 Jul 2013 11:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1814; q=dns/txt; s=iport; t=1373395511; x=1374605111; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=df2P6mr99iblnNvx9koiqYA0q6ZFpG7b7LdGomNOOSY=; b=RBtNKp/AEgMt6r0suvhA//QGoPdHITYldijQZcLnwjazAPYoT4i5M+6A LKbuA1goSPBt+LzV+X5mDJiDtWXRd3Pio1DH5L3hi3gOhQYkih0ArohV6 MeZQCZ5AkYXu0rkLUaoDaUIsNPdctWbLP0iPBphw2AoyZL+Bx4c/73Gd0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQLAJJZ3FGtJXHA/2dsb2JhbABagwkyTcEUAgGBGRZ0giMBAQEEODYKARALGAkWBAsJAwIBAgE0EQYNAQUCAQGICwy6JY8eTQcWg1wDiG0yjjSBKYR6iyWBWIE8giU X-IronPort-AV: E=Sophos;i="4.87,1029,1363132800"; d="scan'208";a="229740678" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 09 Jul 2013 18:45:10 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r69Ij9TM027272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 18:45:09 GMT Received: from [10.21.126.39] (10.21.126.39) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 9 Jul 2013 13:45:08 -0500 Message-ID: <51DC5A2E.4040905@cisco.com> Date: Tue, 9 Jul 2013 21:45:02 +0300 From: Lori Jakab Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <20130701160310.22718.49133.idtracker@ietfa.amsl.com> In-Reply-To: <20130701160310.22718.49133.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.21.126.39] Cc: The IESG , lisp@ietf.org, IETF-Announce Subject: Re: [lisp] Last Call: (LISP Network Element Deployment Considerations) to Informational RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 18:45:15 -0000 It was pointed out to the document authors privately that a locally caching Map Server, as mentioned in the penultimate bullet of Section 2.3, is not something that we should recommend anymore. We, the authors agree, and want to note that the concept of a "locally caching Map Server" was introduced into the document at the time when DDT was still being in design phase, with many of its properties being inspired by DNS. As a result, we removed the sentence that read "To lower the impact, the site could use a local caching Map Resolver." in revision -09 of the document, which we just posted to the datatracker. On behalf of the authors, -Lorand Jakab On 7/1/13 7:03 PM, The IESG wrote: > > The IESG has received a request from the Locator/ID Separation Protocol > WG (lisp) to consider the following document: > - 'LISP Network Element Deployment Considerations' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-07-15. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document discusses the different scenarios for the deployment of > the new network elements introduced by the Locator/Identifier > Separation Protocol (LISP). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-lisp-deployment/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-lisp-deployment/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From farinacci@gmail.com Tue Jul 9 16:52:45 2013 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 A927221F9C47 for ; Tue, 9 Jul 2013 16:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdhcniTqatEl for ; Tue, 9 Jul 2013 16:52:45 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1454221F9C4D for ; Tue, 9 Jul 2013 16:52:45 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so6062999pbc.29 for ; Tue, 09 Jul 2013 16:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zqV2kBTm0VmJ45n6ZCFAeSI2wvichF8ATMIV267tQ04=; b=l7dsc/GXlJLWAAzXBPHAI5STrQ/oaC+9e7UzUhuUOjAMr+979nC9RpF/sPQUDvQqr1 +UlhntfP1+Qo/RLklv0fidY5rXUl1TcUR+ZSI4+VPHtOrd8WmiCRFxdCoyzocjtCcBq6 2bysXks1+kKoXzBrQ0TwyJQca2KKhUQ90UbPvLwTTMZMonw1J3EQOnMmyFN+Eb1lZMYz WRDv/LDI/WxwdVLTXJ8Tx7sDVooCWsXvkJIy2xK0S8io/+okhBA36sOIjRZ4Volau97o xEgxhaHTywvjksXQxac3vgdCum3g2QiOTRM0Fja77opyUphRGZzqTj97dyzBRDI9HTtk S99w== X-Received: by 10.68.170.97 with SMTP id al1mr29074790pbc.0.1373413964832; Tue, 09 Jul 2013 16:52:44 -0700 (PDT) Received: from ?IPv6:2602:306:3175:249:558a:7fa:f7f3:5721? ([2602:306:3175:249:558a:7fa:f7f3:5721]) by mx.google.com with ESMTPSA id i16sm32571699pag.18.2013.07.09.16.52.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 16:52:44 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: Date: Tue, 9 Jul 2013 16:52:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82A959C1-64C1-493C-86D9-757FF4E3FB5C@gmail.com> References: <20130709172900.16C3518C172@mercury.lcs.mit.edu> To: Donn Lee X-Mailer: Apple Mail (2.1503) Cc: Noel Chiappa , "lisp@ietf.org list" Subject: Re: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 23:52:45 -0000 The group is already open and when the documentation says "anyone can = join the group" I think it really means anyone with a Facebook account. = Please correct me if I'm wrong. Maybe we should go private to work this out and when we have a solution, = we can post to this list. Dino On Jul 9, 2013, at 4:47 PM, Donn Lee wrote: > Yep, create an 'Open' group and anyone on Facebook can see what = members post: > = https://www.facebook.com/help/220336891328465#What-are-the-privacy-options= -for-groups >=20 > On Tue, Jul 9, 2013 at 11:14 AM, Dino Farinacci = wrote: >> I haven't found a way. I have cc'ed Donn. He may know or can ask = Zuck. ;-) >>=20 >> Dino >>=20 >> On Jul 9, 2013, at 10:29 AM, jnc@mercury.lcs.mit.edu (Noel Chiappa) = wrote: >>=20 >>>> From: Marc Binderberger >>>=20 >>>> Besides, clicking on the link below I get a login window. = "completely >>>> open"? >>>=20 >>> Isn't there some way to set the group up so that you don't have to = be a >>> Facebook member to look at stuff? (I thought I remembered some other = FB >>> groups that had stuff the public could look at without logging in.) >>>=20 >>> The IETF WG logs really are completely open: you can read anything = in: >>>=20 >>> http://www.ietf.org/mail-archive/web/lisp/current/maillist.html >>>=20 >>> without any need for a login. >>>=20 >>> Noel >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 From marc@sniff.de Tue Jul 9 23:50:10 2013 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 2AC1E21F9AE0 for ; Tue, 9 Jul 2013 23:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7-05otvNZeD for ; Tue, 9 Jul 2013 23:50:09 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0863821F9F1B for ; Tue, 9 Jul 2013 23:50:08 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 31DE62AA0F; Wed, 10 Jul 2013 06:50:03 +0000 (GMT) Date: Wed, 10 Jul 2013 08:50:03 +0200 From: Marc Binderberger To: Dino Farinacci Message-ID: <20130710085003509432.40b68cb9@sniff.de> In-Reply-To: <1206ABF6-DBCF-44C3-847E-26B96A31C701@gmail.com> References: <7257B6D3-EF3C-4DF5-93B8-0B0047979256@gmail.com> <20130709173145033572.0983e87b@sniff.de> <1206ABF6-DBCF-44C3-847E-26B96A31C701@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Cc: "lisp@ietf.org list" Subject: Re: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 06:50:10 -0000 Hello Dino, > There is no move. Just more information. There is no hidden agenda here. ah okay. I was wondering. Thanks for the clarification. More information is good. Maybe it's because I'm relatively new to LISP but I wonder if there will be too many places for LISP information, scattering information and making it harder to find them (all) ? > There is LinkedIn group as well if you prefer. thanks for the pointer. And it's even open! ;-) Regards, Marc On Tue, 9 Jul 2013 08:51:29 -0700, Dino Farinacci wrote: >> Hello Dino, >> >> seriously? IETF mail list is not working? > > This FB group is outside the scope of the working group. And I > believe the working group is doing just fine. > >> Besides, clicking on the link below I get a login window. "completely >> open"? Believe it or not but I had no need to join facebook so far. > > There is LinkedIn group as well if you prefer. > >> Nor had any of the various IETF work groups I'm subscribed to done such >> a move. Is there any real advantage coming with this? > > There is no move. Just more information. There is no hidden agenda here. > > Dino > >> >> >> Regards, Marc >> >> >> >> >> On Tue, 9 Jul 2013 07:33:04 -0700, Dino Farinacci wrote: >>> Please join https://www.facebook.com/groups/407716795982512/ if you >>> want to learn, contribute or lurk about LISP industry activity. >>> >>> The group is completely open and not vendor specific, contains blogs, >>> articles, and comments from LISP implementors and deployers. >>> >>> Thanks, >>> Dino >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>> > From marc@sniff.de Wed Jul 10 01:24:12 2013 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 71C4C21F9E04 for ; Wed, 10 Jul 2013 01:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SEabejj8Ozr for ; Wed, 10 Jul 2013 01:24:10 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C58E821F9D49 for ; Wed, 10 Jul 2013 01:24:08 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 9298C2AA0F; Wed, 10 Jul 2013 08:23:57 +0000 (GMT) Date: Wed, 10 Jul 2013 10:23:56 +0200 From: Marc Binderberger To: heinerhummel@aol.com Message-ID: <20130710102356577708.ce36cc81@sniff.de> In-Reply-To: <8D04AA05974CCC7-F50-A4A69@webmail-d279.sysops.aol.com> References: <00ed01ce7895$5e6487f0$1b2d97d0$@unizar.es> <8D048467E74C356-FB0-5D1E1@webmail-m135.sysops.aol.com> <8D049549753AB68-EF4-9703D@webmail-m257.sysops.aol.com> <83605EFB-A0B9-4E43-A6FA-5AB75A23A98F@gmail.com> <8D049DA8CF914BA-A38-14A46@webmail-d178.sysops.aol.com> <8D04AA05974CCC7-F50-A4A69@webmail-d279.sysops.aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.15 Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 08:24:12 -0000 Hello Heiner, I have to say your emails are difficult to parse. Anyway, I get the impression you talk about two different things. If=20 you want a hierarchical address space for better scale or a global view=20 of your routing with respect to congestion etc. then LISP is not=20 solving this. LISP may help to decouple existing end point=20 infrastructure from your transport network though. This allows you to=20 introduce new schemes in the EID or RLOC space, including TARA if you=20 wish. If you feel disappointed that IPv6 is "more of the same" you are not=20 alone - but that's another story, not LISP. LISP is pragmatic, the=20 separation opens the door for a new transport if needed - no more, no=20 less. My $0.02 Regards, Marc On Tue, 9 Jul 2013 05:46:43 -0400 (EDT), heinerhummel@aol.com wrote: > Indeed, there are immensely many useful capabilities provided that =20 > addressing would serve routing which is about the WHERE, WHERE-TO and=20 > WHERE-FROM. > Consider E.164 : There are country codes and inside which ever=20 > country where Siemens EWSD switches were deployed each rotary dialed=20 > digit did select link after link electro-mechanically !!! down to the=20 > destination. Inside Germany the leading digit "3" was spared for the=20 > Eastern part while most the Western politician had given up hope for=20 > the reunion and all of the Eastern part did everything to prevent it. >=20 >=20 > Whereas IP addressing is as WHERE-agnostic as is MAC-addressing or AS=20 > numbering. No WHERE-knowledge nowhere. Conex doesn't recognize areas=20 > of congestion, multi-homing is a "let's try the other link"-game as=20 > to await what might happen. Columbus-Routing (knowing that the earth=20 > is a ball) is out of question being against the holy DV-doctrine. > DiffServ is proud to operate without any knowledge about what is=20 > beyond the waiting queues for incoming packets. IPv6 defines an=20 > Anycast address space without scopes that limited the area of being=20 > advertised. Examples: A Anycast-destination "free parking lot" might=20 > only be disseminated inside the own city i.e. not outside of it. A=20 > Anycast-destination "gas station" might only be disseminated over=20 > some area whose radius corresponds with the remaining miles indicated=20 > by a warning display to the driver.Etc.Etc. But such scope > is not intended at all and wouldn't even help because IPv6 is as=20 > WHERE-agnostic as is IPv4. >=20 >=20 > With the upcoming of the loc-id-split paradigm I saw the chance for a=20 > change and indeed TARA, being a loc-id-split solution, would end this=20 > WHERE-agnosticism. > LISP however keeps up with it. As well as IPv6 :-( >=20 >=20 > Heiner >=20 >=20 >=20 > -----Urspr=FCngliche Mitteilung-----=20 > Von: Sharon Barkai > An: heinerhummel > Cc: farinacci ; lisp > Verschickt: Mo, 8 Jul 2013 1:14 pm > Betreff: Re: [lisp] No LISP meeting for Berlin >=20 >=20 >=20 > really don't want to interrupt this great dialog, just one comment. >=20 >=20 > don't think is about a bigger address space for routing, > but rather combining 2 completely different lookup schemes. >=20 >=20 > Step1: you lookup the routing location of Mr. Smith, or Mr. Li, or=20 > Herr Meier or Mr. Dupont in a huge ID "phone book" a (secure)=20 > distributed database lookup problem, strictly overlay not a routing=20 > problem. >=20 >=20 > Step 2: you insert the letter into an outer envelope with a=20 > postal-service (routable) address, leverage whatever hop to hop=20 > routing lookup solution you have at the moment scale, cost,=20 > efficiency wise. FedEx, ups etc. >=20 >=20 > Lots of use cases and benefits. >=20 >=20 >=20 >=20 > --szb >=20 > On Jul 8, 2013, at 13:11, "heinerhummel@aol.com"=20 > wrote: >=20 >=20 >=20 > See my notes starting with HH inside. > Heiner >=20 >=20 >=20 > -----Urspr=FCngliche Mitteilung----- > Von: Dino Farinacci > An: heinerhummel > Cc: damien.saucez ; lisp > Verschickt: So, 7 Jul 2013 8:59 pm > Betreff: Re: [lisp] No LISP meeting for Berlin >=20 >=20 >=20 > "...But I would like to think we live in a world where people help=20 > things that serve. " >=20 >=20 >=20 >=20 > Dino,really? >=20 >=20 >=20 > Yes - really. When you post an email like you did (and you do it=20 > repeatedly with little technical data), I have to respond that way.=20 >=20 >=20 > HH: Here is all technical detail: =20 >=20 http://www.igi-global.com/chapter/topology-aggregating-routing-architecture= -tara/77501 >=20 > By our last dispute a while ago I learnt that LISP does NOTHING to=20 > ease the IPv4 >=20 >=20 >=20 > And it never claimed to solve this problem. It you know what? It=20 > does help because you can use other address spaces to help the=20 > allocation of devices. So you can use IPv6 EIDs for site devices=20 > versus IPv4 addresses. Allowing more IPv4 addresses to be used for=20 > RLOCs and therefore be able to address more sites.=20 >=20 >=20 > HH: But anyone who sees that the IPv4-address is enhanced by another=20 > 4 octets locator is tempted to assume that uniqueness is provided by=20 > some unique combination of IPv4 address + locator. Just as if a=20 > postal letter is sent to some Mr. Smith, or Mr. Li, or Herr Meier or=20 > Mr. Dupont. And btw, I am not sure whether that wasn't an initial=20 > argument in favor of LISP, otherwise I would have brought up this=20 > issue years earlier. >=20 >=20 >=20 > adress depletion issue (well, it rather eats up some extra addresses). > While by involving the user as well as the DNS (i.e. by mapping a=20 > FQDN to IPv4 >=20 >=20 >=20 > How is LISP involving the user? >=20 >=20 > HH: LISP is not involving the user, that is my reproach. If there=20 > were no IPv4 address depletion issue then it would be a pro-argument=20 > not to involve the user. But a) we are used to getting WINDOW-updates=20 > every now and then, and b) by expanding the IPv4 address space by=20 > O(2^32) that pro-argument is overruled by far. (TARA would even=20 > provide an IPv4-address space extension of O(2^40) !!! ) >=20 >=20 >=20 > address + Locator) the IPv4 address space could easily do for another=20 > thousand years (all it takes is to ensure that any IPv4-address is=20 > unique per associated locator) LISP-DDT prevents that for good, and=20 > you make us believe that LISP would be of any service to IPv4 ?! >=20 >=20 >=20 > LISP-DDT is a database to move Map-Request around. It says nothing=20 > about how and how much address is allocated.=20 >=20 >=20 > HH: Right, sounds very innocently. But even LISP 2.0 (I guess) had=20 > once been better . >=20 >=20 >=20 > The bad thing is that very very precious time goes by while (naive)=20 > people/observers trust in LISP on this respect. >=20 >=20 >=20 > Because it is becoming proven in their experience.=20 > HH: I never doubted that LISP would just work as you have had it in=20 > your mind, nor that you would be able to adjust it such that it suits=20 > all existing forwarding mechanisms. > =20 >=20 >=20 >=20 > Just like myself when I argued that LISP-DDT cannot work assuming=20 > that LISP were after a 4+4 octet unicast address space extension. >=20 >=20 > But you let all up to NAT. This is really not a serve. >=20 >=20 >=20 > I cannot parse the above.=20 >=20 >=20 > Dino >=20 >=20 >=20 >=20 >=20 > Sorry, > Heiner > (having nothing said about the dooming malicious/political problems yet) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Mitteilung----- > Von: Dino Farinacci > An: Damien Saucez > Cc: heinerhummel ; lisp > Verschickt: Sa, 6 Jul 2013 8:01 pm > Betreff: Re: [lisp] No LISP meeting for Berlin >=20 >=20 >=20 > There are servers everywhere. Even not on the Internet. We leave in a=20 > world of abuse. But I would like to think we live in a world where=20 > people help things that serve.=20 >=20 >=20 > Dino=20 >=20 >=20 >=20 > On Jul 6, 2013, at 4:21 AM, Damien Saucez wrote= : >=20 >=20 >=20 >=20 >=20 > On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: >=20 >=20 > My "Mass" for the LISP beer garden meeting: >=20 > The LISP's dependency on special servers (DDT, formerly ALT) is a=20 > perfect invitation for abuse -=20 > either by malicious hackers or by malicious owners, or the alliance=20 > of both. Who is able to control these servers is able to control =20 > internet forwarding. > I can imagine that the RSA would like LISP very much. >=20 >=20 >=20 >=20 >=20 > Don't worry, before you traffic to be encapsulated by LISP you will=20 > use DNS... >=20 >=20 > Damien Saucez >=20 >=20 >=20 >=20 >=20 > Heiner > =20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From donnlee@gmail.com Tue Jul 9 17:11:10 2013 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 329E211E80E7 for ; Tue, 9 Jul 2013 17:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hloZXKSOMBcJ for ; Tue, 9 Jul 2013 17:11:09 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5E64311E80E2 for ; Tue, 9 Jul 2013 17:11:09 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so4920543vbb.37 for ; Tue, 09 Jul 2013 17:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dIVCV0WX0Sufi1uQhNUOjXcqW3MCswvUZ5R+YzEbe3w=; b=Io02BRjhIwb386RWreeZgm/ZlqBpzdfb5n9gUPmPaqzvVfxWkvyDEp8CvBC9YV2YbQ gGibNOpv8fqTfxo3Bsw3cn1zPldl/2shYlDH7wW2seUDbp9soFGxDl6yWftt20CYvI95 ZSWWNrFEQSXSQUvC1aRHFD/crXnOeLQeVO6Xitywx398tZD/0ZxwkUYZc1XIrQleynaB 5q7un7kRBB1iL6cF3pbj+WkDGAVxTAwPrxhT8ibcEImaGg/PDQUwH5IRVCC1xgJjUskm fMonXiIh+AZzwgRk1FowAM5ykm3Fe+PdUQaJA91ESbc/B2/vUUxczIuINdpGFg7mzT8L NoHw== X-Received: by 10.58.182.103 with SMTP id ed7mr10069293vec.70.1373415068860; Tue, 09 Jul 2013 17:11:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.197.72 with HTTP; Tue, 9 Jul 2013 17:10:28 -0700 (PDT) In-Reply-To: <82A959C1-64C1-493C-86D9-757FF4E3FB5C@gmail.com> References: <20130709172900.16C3518C172@mercury.lcs.mit.edu> <82A959C1-64C1-493C-86D9-757FF4E3FB5C@gmail.com> From: Donn Lee Date: Tue, 9 Jul 2013 17:10:28 -0700 Message-ID: To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 10 Jul 2013 08:07:02 -0700 Cc: Noel Chiappa , "lisp@ietf.org list" Subject: Re: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 00:22:46 -0000 Yes, the user needs to have a FB acct On Tue, Jul 9, 2013 at 4:52 PM, Dino Farinacci wrote: > The group is already open and when the documentation says "anyone can join the group" I think it really means anyone with a Facebook account. Please correct me if I'm wrong. > > Maybe we should go private to work this out and when we have a solution, we can post to this list. > > Dino > > On Jul 9, 2013, at 4:47 PM, Donn Lee wrote: > >> Yep, create an 'Open' group and anyone on Facebook can see what members post: >> https://www.facebook.com/help/220336891328465#What-are-the-privacy-options-for-groups >> >> On Tue, Jul 9, 2013 at 11:14 AM, Dino Farinacci wrote: >>> I haven't found a way. I have cc'ed Donn. He may know or can ask Zuck. ;-) >>> >>> Dino >>> >>> On Jul 9, 2013, at 10:29 AM, jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote: >>> >>>>> From: Marc Binderberger >>>> >>>>> Besides, clicking on the link below I get a login window. "completely >>>>> open"? >>>> >>>> Isn't there some way to set the group up so that you don't have to be a >>>> Facebook member to look at stuff? (I thought I remembered some other FB >>>> groups that had stuff the public could look at without logging in.) >>>> >>>> The IETF WG logs really are completely open: you can read anything in: >>>> >>>> http://www.ietf.org/mail-archive/web/lisp/current/maillist.html >>>> >>>> without any need for a login. >>>> >>>> Noel >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> > From farinacci@gmail.com Wed Jul 10 10:15:30 2013 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 7655921F8934 for ; Wed, 10 Jul 2013 10:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6lesVsy2Hk1 for ; Wed, 10 Jul 2013 10:15:27 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id C3A1321F85E0 for ; Wed, 10 Jul 2013 10:15:27 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so6621984pdi.27 for ; Wed, 10 Jul 2013 10:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YE24ZUkCFoyrmS7rJ9A36+c17PrdD9S51Uqv1ZWZVY8=; b=jcl68qin3j68ebhLanfQGC4RfIcTar8bM1uoxlhaQ7JZeuS5ddpv1y/FMDaDY27wV8 zoeVuVJl5aqmMp2rTjQv0ZnGgMkpvm/dzjCE+s+8aRmBILTdtxoZTo1sg2n0nZAESFGd cw1h9Bz3EhLLN7odK0y2O3ATxAK0e2fnCYpICkyzxMIj4IVKfvF13Y614eK5qu/D8k8s dctZLqGe5nJYFj2LMPsW5OmDKCpZ6iz1opVxEz8iVv+jQ/BGYmUnoa+zIaOLKMMK4NDf aH/EpaTnNcM89gLI0J85OFg/HaE5c+xVKVGkuHmnOVFxe5qEGBtRJ4o3B0HdnMd4nib0 VBJw== X-Received: by 10.68.201.98 with SMTP id jz2mr28112765pbc.56.1373476527493; Wed, 10 Jul 2013 10:15:27 -0700 (PDT) Received: from [192.168.182.35] (dsl-63-249-108-8.static.cruzio.com. [63.249.108.8]) by mx.google.com with ESMTPSA id iq3sm24815488pbb.20.2013.07.10.10.15.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 10:15:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <20130710085003509432.40b68cb9@sniff.de> Date: Wed, 10 Jul 2013 10:15:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7257B6D3-EF3C-4DF5-93B8-0B0047979256@gmail.com> <20130709173145033572.0983e87b@sniff.de> <1206ABF6-DBCF-44C3-847E-26B96A31C701@gmail.com> <20130710085003509432.40b68cb9@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1503) Cc: "lisp@ietf.org list" Subject: Re: [lisp] Facebook group "lisp-routing" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 17:15:30 -0000 > More information is good. Maybe it's because I'm relatively new to = LISP=20 > but I wonder if there will be too many places for LISP information,=20 > scattering information and making it harder to find them (all) ? Here are the basic places you can find LISP information: (1) This IETF list and the IETF web pages in general (2) http://wwww.lisp4.net describes the pilot network and public domain = activities (3) http://en.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol (4) The Facebook and LinkedIn groups (5) Any LISP vendor products and services web sites Those are the high-level places to start with. Dino From heinerhummel@aol.com Fri Jul 12 00:09:37 2013 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 E561311E8210 for ; Fri, 12 Jul 2013 00:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.121 X-Spam-Level: X-Spam-Status: No, score=-4.121 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_05=-1.11, GB_I_INVITATION=-2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCexzKEL1z6m for ; Fri, 12 Jul 2013 00:09:31 -0700 (PDT) Received: from omr-m01.mx.aol.com (omr-m01.mx.aol.com [64.12.143.75]) by ietfa.amsl.com (Postfix) with ESMTP id CFC6A11E8213 for ; Fri, 12 Jul 2013 00:09:30 -0700 (PDT) Received: from mtaomg-da03.r1000.mx.aol.com (mtaomg-da03.r1000.mx.aol.com [172.29.51.139]) by omr-m01.mx.aol.com (Outbound Mail Relay) with ESMTP id 9288D700000AE; Fri, 12 Jul 2013 03:09:28 -0400 (EDT) Received: from core-dqb003a.r1000.mail.aol.com (core-dqb003.r1000.mail.aol.com [172.29.212.201]) by mtaomg-da03.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 4F594E000081; Fri, 12 Jul 2013 03:09:28 -0400 (EDT) To: marc@sniff.de X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-vn002.sysops.aol.com (207.200.83.129) with HTTP (WebMailUI); Fri, 12 Jul 2013 03:09:28 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D04CE5E1EC302A_143C_28135B_webmail-vn002.sysops.aol.com" X-Mailer: AOL Webmail 37834-STANDARD Message-Id: <8D04CE5E1752B38-143C-B6785@webmail-vn002.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Fri, 12 Jul 2013 03:09:28 -0400 (EDT) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1373612968; bh=fdYmyS8+PWsazZMrt1iVlNRqgtOOAtYHsAUaWmjlAQM=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=NAUgh+sKzJJAirNqM1bF/w8eK/kbbzJrvTpl54ud6f+4SD5dG+yK4UxKEqRo4JvSF 6LCHG1+9dEIW3sh1BTOcRgHJSNppLdOEm3jjNASKxzEq40YJQP74ShWksHHqt2yqTY Gr8Nn+mZLrWT7bZsJiI54v/WhsMO65YJ5D2AZeqE= X-AOL-SCOLL-SCORE: 0:2:479588544:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d338b51dfaba85d86 Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 07:09:38 -0000 This is a multi-part message in MIME format. ----------MB_8D04CE5E1EC302A_143C_28135B_webmail-vn002.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Marc, I am in favor of better routing which can only be accomplished if all holy = IETF-paradigms are allowed to be questioned. Almost ten years ago I showed the rtgwg group how to do better than "not vi= a"-routing, but my algorithm was completely ignored.=20 It not only would enable successful unicast routing as long as there exist= s a (though several times detouring) route, respectively recognize the dead= -end situation. It was in vain, instead the TTL-mechanism, which is embarrassingly poor, i= s still in place (and is adopted by LISP - of course), Or : Traffic congestion is a network layer issue, and not a TCP issue !!! = Traffic congestions can only be avoided ( resp. resolved) by proper balanci= ng the routes to be taken. Or take Multicast. Why is state-less multicast not an objective ? Imagine s= tate-less multicast whereby the sender is mobile, just like the receivers != Imagine a MIP such that all users can be mobile, i.e. without the need of = any immobile home-agent or care-of-address server! Or take Anycast. Defined by IPv6 without scoping (which in return can't be = provided anyway with the network layer being WHERE-agnostic). Why must intra- and inter-domain routing be such contraversal? Why DV, give= n that since Pythagoras (570 B.C.) the earth is known being a ball rather t= han a disc? Why collecting millions of routes, although millions of millions of routes = could be supported without storing a single one? You are right, this critic is not LISP-specific, instead it is IETF-specif= ic. Getting back to LISP: A while ago I was jealous on LISP because I had indid= epndently the same idea with the "default mapping" i.e. that a TARA-router = might advertise a prefix of length zero as to attract packets (just like Fu= ller proposed it for LISP). Hereby a TARA-router nearby the ingress would h= ave acted as a proxy i.e. enquired the DNS for being returned the destinati= ons's TARA-Locator. But meanswhile this mini-extra-feature is nothing compa= red with the immense IPv4-address space extension achieved by starting TARA= -forwarding at the source user, or at least there where the mapping of the = destination's FQDN to its IPv4 address+LOCATOR can be induced.=20 Meanwhile I think that the IPv4 deletion issue is even more challenging and= more severe than the scalability issue, isn't it ? Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Marc Binderberger An: heinerhummel Cc: Sharon ; lisp Verschickt: Mi, 10 Jul 2013 10:24 am Betreff: Re: [lisp] No LISP meeting for Berlin Hello Heiner, I have to say your emails are difficult to parse. Anyway, I get the impression you talk about two different things. If=20 you want a hierarchical address space for better scale or a global view=20 of your routing with respect to congestion etc. then LISP is not=20 solving this. LISP may help to decouple existing end point=20 infrastructure from your transport network though. This allows you to=20 introduce new schemes in the EID or RLOC space, including TARA if you=20 wish. If you feel disappointed that IPv6 is "more of the same" you are not=20 alone - but that's another story, not LISP. LISP is pragmatic, the=20 separation opens the door for a new transport if needed - no more, no=20 less. My $0.02 Regards, Marc On Tue, 9 Jul 2013 05:46:43 -0400 (EDT), heinerhummel@aol.com wrote: > Indeed, there are immensely many useful capabilities provided that =20 > addressing would serve routing which is about the WHERE, WHERE-TO and=20 > WHERE-FROM. > Consider E.164 : There are country codes and inside which ever=20 > country where Siemens EWSD switches were deployed each rotary dialed=20 > digit did select link after link electro-mechanically !!! down to the=20 > destination. Inside Germany the leading digit "3" was spared for the=20 > Eastern part while most the Western politician had given up hope for=20 > the reunion and all of the Eastern part did everything to prevent it. >=20 >=20 > Whereas IP addressing is as WHERE-agnostic as is MAC-addressing or AS=20 > numbering. No WHERE-knowledge nowhere. Conex doesn't recognize areas=20 > of congestion, multi-homing is a "let's try the other link"-game as=20 > to await what might happen. Columbus-Routing (knowing that the earth=20 > is a ball) is out of question being against the holy DV-doctrine. > DiffServ is proud to operate without any knowledge about what is=20 > beyond the waiting queues for incoming packets. IPv6 defines an=20 > Anycast address space without scopes that limited the area of being=20 > advertised. Examples: A Anycast-destination "free parking lot" might=20 > only be disseminated inside the own city i.e. not outside of it. A=20 > Anycast-destination "gas station" might only be disseminated over=20 > some area whose radius corresponds with the remaining miles indicated=20 > by a warning display to the driver.Etc.Etc. But such scope > is not intended at all and wouldn't even help because IPv6 is as=20 > WHERE-agnostic as is IPv4. >=20 >=20 > With the upcoming of the loc-id-split paradigm I saw the chance for a=20 > change and indeed TARA, being a loc-id-split solution, would end this=20 > WHERE-agnosticism. > LISP however keeps up with it. As well as IPv6 :-( >=20 >=20 > Heiner >=20 >=20 >=20 > -----Urspr=C3=BCngliche Mitteilung-----=20 > Von: Sharon Barkai > An: heinerhummel > Cc: farinacci ; lisp > Verschickt: Mo, 8 Jul 2013 1:14 pm > Betreff: Re: [lisp] No LISP meeting for Berlin >=20 >=20 >=20 > really don't want to interrupt this great dialog, just one comment. >=20 >=20 > don't think is about a bigger address space for routing, > but rather combining 2 completely different lookup schemes. >=20 >=20 > Step1: you lookup the routing location of Mr. Smith, or Mr. Li, or=20 > Herr Meier or Mr. Dupont in a huge ID "phone book" a (secure)=20 > distributed database lookup problem, strictly overlay not a routing=20 > problem. >=20 >=20 > Step 2: you insert the letter into an outer envelope with a=20 > postal-service (routable) address, leverage whatever hop to hop=20 > routing lookup solution you have at the moment scale, cost,=20 > efficiency wise. FedEx, ups etc. >=20 >=20 > Lots of use cases and benefits. >=20 >=20 >=20 >=20 > --szb >=20 > On Jul 8, 2013, at 13:11, "heinerhummel@aol.com"=20 > wrote: >=20 >=20 >=20 > See my notes starting with HH inside. > Heiner >=20 >=20 >=20 > -----Urspr=C3=BCngliche Mitteilung----- > Von: Dino Farinacci > An: heinerhummel > Cc: damien.saucez ; lisp > Verschickt: So, 7 Jul 2013 8:59 pm > Betreff: Re: [lisp] No LISP meeting for Berlin >=20 >=20 >=20 > "...But I would like to think we live in a world where people help=20 > things that serve. " >=20 >=20 >=20 >=20 > Dino,really? >=20 >=20 >=20 > Yes - really. When you post an email like you did (and you do it=20 > repeatedly with little technical data), I have to respond that way.=20 >=20 >=20 > HH: Here is all technical detail: =20 >=20 http://www.igi-global.com/chapter/topology-aggregating-routing-architecture= -tara/77501 >=20 > By our last dispute a while ago I learnt that LISP does NOTHING to=20 > ease the IPv4 >=20 >=20 >=20 > And it never claimed to solve this problem. It you know what? It=20 > does help because you can use other address spaces to help the=20 > allocation of devices. So you can use IPv6 EIDs for site devices=20 > versus IPv4 addresses. Allowing more IPv4 addresses to be used for=20 > RLOCs and therefore be able to address more sites.=20 >=20 >=20 > HH: But anyone who sees that the IPv4-address is enhanced by another=20 > 4 octets locator is tempted to assume that uniqueness is provided by=20 > some unique combination of IPv4 address + locator. Just as if a=20 > postal letter is sent to some Mr. Smith, or Mr. Li, or Herr Meier or=20 > Mr. Dupont. And btw, I am not sure whether that wasn't an initial=20 > argument in favor of LISP, otherwise I would have brought up this=20 > issue years earlier. >=20 >=20 >=20 > adress depletion issue (well, it rather eats up some extra addresses). > While by involving the user as well as the DNS (i.e. by mapping a=20 > FQDN to IPv4 >=20 >=20 >=20 > How is LISP involving the user? >=20 >=20 > HH: LISP is not involving the user, that is my reproach. If there=20 > were no IPv4 address depletion issue then it would be a pro-argument=20 > not to involve the user. But a) we are used to getting WINDOW-updates=20 > every now and then, and b) by expanding the IPv4 address space by=20 > O(2^32) that pro-argument is overruled by far. (TARA would even=20 > provide an IPv4-address space extension of O(2^40) !!! ) >=20 >=20 >=20 > address + Locator) the IPv4 address space could easily do for another=20 > thousand years (all it takes is to ensure that any IPv4-address is=20 > unique per associated locator) LISP-DDT prevents that for good, and=20 > you make us believe that LISP would be of any service to IPv4 ?! >=20 >=20 >=20 > LISP-DDT is a database to move Map-Request around. It says nothing=20 > about how and how much address is allocated.=20 >=20 >=20 > HH: Right, sounds very innocently. But even LISP 2.0 (I guess) had=20 > once been better . >=20 >=20 >=20 > The bad thing is that very very precious time goes by while (naive)=20 > people/observers trust in LISP on this respect. >=20 >=20 >=20 > Because it is becoming proven in their experience.=20 > HH: I never doubted that LISP would just work as you have had it in=20 > your mind, nor that you would be able to adjust it such that it suits=20 > all existing forwarding mechanisms. > =20 >=20 >=20 >=20 > Just like myself when I argued that LISP-DDT cannot work assuming=20 > that LISP were after a 4+4 octet unicast address space extension. >=20 >=20 > But you let all up to NAT. This is really not a serve. >=20 >=20 >=20 > I cannot parse the above.=20 >=20 >=20 > Dino >=20 >=20 >=20 >=20 >=20 > Sorry, > Heiner > (having nothing said about the dooming malicious/political problems yet) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Urspr=C3=BCngliche Mitteilung----- > Von: Dino Farinacci > An: Damien Saucez > Cc: heinerhummel ; lisp > Verschickt: Sa, 6 Jul 2013 8:01 pm > Betreff: Re: [lisp] No LISP meeting for Berlin >=20 >=20 >=20 > There are servers everywhere. Even not on the Internet. We leave in a=20 > world of abuse. But I would like to think we live in a world where=20 > people help things that serve.=20 >=20 >=20 > Dino=20 >=20 >=20 >=20 > On Jul 6, 2013, at 4:21 AM, Damien Saucez wrote= : >=20 >=20 >=20 >=20 >=20 > On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote: >=20 >=20 > My "Mass" for the LISP beer garden meeting: >=20 > The LISP's dependency on special servers (DDT, formerly ALT) is a=20 > perfect invitation for abuse -=20 > either by malicious hackers or by malicious owners, or the alliance=20 > of both. Who is able to control these servers is able to control =20 > internet forwarding. > I can imagine that the RSA would like LISP very much. >=20 >=20 >=20 >=20 >=20 > Don't worry, before you traffic to be encapsulated by LISP you will=20 > use DNS... >=20 >=20 > Damien Saucez >=20 >=20 >=20 >=20 >=20 > Heiner > =20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp =20 ----------MB_8D04CE5E1EC302A_143C_28135B_webmail-vn002.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Marc,<= /font>

I am in favor of better routing which ca= n only be accomplished if all holy IETF-paradigms are allowed to be questio= ned.
Almost ten years ago I showed the rtgwg = group how to do better than "not via"-routing, but my algorithm was c= ompletely ignored. 
 It not only would enable successf= ul unicast routing as long as there exists a (though several times detourin= g) route, respectively recognize the dead-end situation.
It was in vain, instead  the TTL-m= echanism, which is embarrassingly poor, is still in place (and is adopted b= y LISP - of course),

Or : Traffic congestion is a network layer issue, and not a TCP issue = !!!  Traffic congestions can only be avoided ( resp. resolved) by prop= er balancing the routes to be taken.

Or take Multicast. Why is state-less multicast not an objective ? Imag= ine state-less multicast whereby the sender is mobile, just like the receiv= ers ! Imagine a MIP such that all users can be mobile, i.e. without the nee= d of any immobile home-agent or care-of-address server!

Or take Anycast. Defined by IPv6 without scoping (which in return can'= t be provided anyway with the network layer being WHERE-agnostic).

Why must intra- and inter-domain routing be such contraversal? Why DV,= given that since Pythagoras (570 B.C.) the earth is known being a ball rat= her than a disc?

Why collecting millions of routes, although millions of millions of ro= utes could be supported without storing a single one?

You are right, this critic is not LISP-specific, instead  it= is IETF-specific.

Getting back to LISP: A while ago I was jealous on LISP because I had = indidepndently the same idea with the "default mapping" i.e. that a TARA-ro= uter might advertise a prefix of length zero as to attract packets (just li= ke Fuller proposed it for LISP). Hereby a TARA-router nearby the ingress wo= uld have acted as a proxy i.e. enquired the DNS for being returned the dest= inations's TARA-Locator. But meanswhile this mini-extra-feature is nothing = compared with the immense IPv4-address space extension achieved by starting= TARA-forwarding at the source user, or at least there where the mapping of= the destination's FQDN to its IPv4 address+LOCATOR can be induced. 

Meanwhile I think that the IPv4 deletion issue is even more challengin= g and more severe than the scalability issue, isn't it ?

Heiner



-----= Urspr=C3=BCngliche Mitteilung-----
Von: Marc Binderberger <marc@sniff.de>
An: heinerhummel <heinerhummel@aol.com>
Cc: Sharon <Sharon@Contextream.com>; lisp <lisp@ietf.org>
Verschickt: Mi, 10 Jul 2013 10:24 am
Betreff: Re: [lisp] No LISP meeting for Berlin

Hello Heiner,

I have to say your emails are difficult to parse.

Anyway, I get the impression you talk about two different things. If=20
you want a hierarchical address space for better scale or a global view=20
of your routing with respect to congestion etc. then LISP is not=20
solving this.  LISP may help to decouple existing end point=20
infrastructure from your transport network though. This allows you to=20
introduce new schemes in the EID or RLOC space, including TARA if you=20
wish.

If you feel disappointed that IPv6 is "more of the same" you are not=20
alone - but that's another story, not LISP. LISP is pragmatic, the=20
separation opens the door for a new transport if needed - no more, no=20
less.


My $0.02

Regards, Marc



On Tue, 9 Jul 2013 05:46:43 -0400 (EDT), heinerhummel@aol.com wrote:
> Indeed, there are immensely many useful capabilities provided that =20
> addressing would serve routing which is about the WHERE, WHERE-TO and=
=20
> WHERE-FROM.
> Consider E.164 : There are country codes and inside which ever=20
> country where Siemens EWSD switches were deployed each rotary dialed=
=20
> digit did select link after link electro-mechanically !!! down to the=
=20
> destination. Inside Germany the leading digit "3" was spared for the=
=20
> Eastern part while most the Western politician had given up hope for=
=20
> the reunion and all of the Eastern part did everything to prevent it.
>=20
>=20
> Whereas IP addressing is as WHERE-agnostic as is MAC-addressing or AS=
=20
> numbering. No WHERE-knowledge nowhere. Conex doesn't recognize areas=
=20
> of congestion, multi-homing is a "let's try the other link"-game as=20
> to await what might happen. Columbus-Routing (knowing that the earth=
=20
> is a ball) is out of question being against the holy DV-doctrine.
> DiffServ is proud to operate without any knowledge about what is=20
> beyond the waiting queues for incoming packets. IPv6 defines an=20
> Anycast address space without scopes that  limited the area of being=
=20
> advertised. Examples: A Anycast-destination "free parking lot" might=
=20
> only be disseminated inside the own city i.e. not outside of it. A=20
> Anycast-destination "gas station" might only be disseminated over=20
> some area whose radius corresponds with the remaining miles indicated=
=20
> by a warning display to the driver.Etc.Etc. But such scope
> is not intended at all and wouldn't even help because IPv6 is as=20
> WHERE-agnostic as is IPv4.
>=20
>=20
> With the upcoming of the loc-id-split paradigm I saw the chance for a=
=20
> change and indeed TARA, being a loc-id-split solution, would end this=
=20
> WHERE-agnosticism.
> LISP however keeps up with it. As well as IPv6 :-(
>=20
>=20
> Heiner
>=20
>=20
>=20
> -----Urspr=C3=BCngliche Mitteilung-----=20
> Von: Sharon Barkai <Sharon@Contextream.com>
> An: heinerhummel <heinerhummel@aol.com>
> Cc: farinacci <farinacci@gmail.com>; lisp <lisp@ietf.org>
> Verschickt: Mo, 8 Jul 2013 1:14 pm
> Betreff: Re: [lisp] No LISP meeting for Berlin
>=20
>=20
>=20
> really don't want to interrupt this great dialog, just one comment.
>=20
>=20
> don't think is about a bigger address space for routing,
> but rather combining 2 completely different lookup schemes.
>=20
>=20
> Step1: you lookup  the routing location  of Mr. Smith, or Mr. Li, or=
=20
> Herr Meier or Mr. Dupont in a huge ID "phone book" a (secure)=20
> distributed database lookup problem, strictly overlay not a routing=20
> problem.
>=20
>=20
> Step 2: you insert the letter into an outer envelope with a=20
> postal-service (routable) address, leverage whatever hop to hop=20
> routing lookup solution you have at the moment scale, cost,=20
> efficiency wise.  FedEx, ups etc.
>=20
>=20
> Lots of use cases and benefits.
>=20
>=20
>=20
>=20
> --szb
>=20
> On Jul 8, 2013, at 13:11, "heinerhummel@aol.com"=20
> <he=
inerhummel@aol.com> wrote:
>=20
>=20
>=20
> See my notes starting with HH inside.
> Heiner
>=20
>=20
>=20
> -----Urspr=C3=BCngliche Mitteilung-----
> Von: Dino Farinacci <farinacci@gmail.com>
> An: heinerhummel <heinerhummel@aol.com>
> Cc: damien.saucez <damien.saucez@gmail.com>; lisp <lisp@ietf.org>
> Verschickt: So, 7 Jul 2013 8:59 pm
> Betreff: Re: [lisp] No LISP meeting for Berlin
>=20
>=20
>=20
> "...But I would like to think we live in a world where people help=20
> things that serve. "
>=20
>=20
>=20
>=20
> Dino,really?
>=20
>=20
>=20
> Yes - really. When you post an email like you did (and you do it=20
> repeatedly with little technical data), I have to respond that way.=20
>=20
>=20
> HH: Here is all technical detail:  =20
>=20
http://ww=
w.igi-global.com/chapter/topology-aggregating-routing-architecture-tara/775=
01
>=20
> By our last dispute a while ago I learnt that LISP does NOTHING to=20
> ease the IPv4
>=20
>=20
>=20
> And it never claimed to solve this problem.  It you know what? It=20
> does help because you can use other address spaces to help the=20
> allocation of devices.  So you can use IPv6 EIDs for site devices=20
> versus IPv4 addresses. Allowing more IPv4 addresses to be used for=20
> RLOCs and therefore be able to address more sites.=20
>=20
>=20
> HH: But anyone who sees that the IPv4-address is enhanced by another=
=20
> 4 octets locator is tempted to assume that uniqueness is provided by=
=20
> some unique combination of IPv4 address + locator. Just as if a=20
> postal letter is sent to some Mr. Smith, or Mr. Li, or Herr Meier or=
=20
> Mr. Dupont. And btw, I am not sure whether that wasn't an initial=20
> argument in favor of LISP, otherwise I would have brought up this=20
> issue years earlier.
>=20
>=20
>=20
> adress depletion issue (well, it rather eats up some extra addresses).
> While by involving the user as well as the DNS (i.e. by mapping a=20
> FQDN to IPv4
>=20
>=20
>=20
> How is LISP involving the user?
>=20
>=20
> HH: LISP is not involving the user, that is my reproach. If there=20
> were no IPv4 address depletion issue then it would be a pro-argument=
=20
> not to involve the user. But a) we are used to getting WINDOW-updates=
=20
> every now and then, and b) by expanding the IPv4 address space by=20
> O(2^32) that pro-argument is overruled by far. (TARA would even=20
> provide an IPv4-address space extension of O(2^40) !!! )
>=20
>=20
>=20
> address + Locator) the IPv4 address space could easily do for another=
=20
> thousand years (all it takes is to ensure that any IPv4-address is=20
> unique per associated locator) LISP-DDT prevents that for good, and=20
> you make us believe that LISP would be of any service to IPv4 ?!
>=20
>=20
>=20
> LISP-DDT is a database to move Map-Request around. It says nothing=20
> about how and how much address is allocated.=20
>=20
>=20
> HH: Right,  sounds very innocently. But even LISP 2.0 (I guess) had=20
> once been better .
>=20
>=20
>=20
> The bad thing is that very very precious time goes by while (naive)=20
> people/observers trust in LISP on this respect.
>=20
>=20
>=20
> Because it is becoming proven in their experience.=20
> HH: I never doubted that LISP would just work as you have had it in=20
> your mind, nor that you would be able to adjust it such that it suits=
=20
> all existing forwarding mechanisms.
>       =20
>=20
>=20
>=20
> Just like myself when I argued that LISP-DDT cannot work assuming=20
> that LISP were after a 4+4 octet unicast address space extension.
>=20
>=20
> But you let all up to NAT. This is really not a serve.
>=20
>=20
>=20
> I cannot parse the above.=20
>=20
>=20
> Dino
>=20
>=20
>=20
>=20
>=20
> Sorry,
> Heiner
>  (having nothing said about the dooming malicious/political problems y=
et)
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -----Urspr=C3=BCngliche Mitteilung-----
> Von: Dino Farinacci <farinacci@gmail.com>
> An: Damien Saucez <damien.saucez@gmail.com>
> Cc: heinerhummel <heinerhummel@aol.com>; lisp <lisp@ietf.org>
> Verschickt: Sa, 6 Jul 2013 8:01 pm
> Betreff: Re: [lisp] No LISP meeting for Berlin
>=20
>=20
>=20
> There are servers everywhere. Even not on the Internet. We leave in a=
=20
> world of abuse. But I would like to think we live in a world where=20
> people help things that serve.=20
>=20
>=20
> Dino=20
>=20
>=20
>=20
> On Jul 6, 2013, at 4:21 AM, Damien Saucez <damien.saucez@gmail.com> =
wrote:
>=20
>=20
>=20
>=20
>=20
> On 06 Jul 2013, at 11:58, heinerhummel@aol.com wrote:
>=20
>=20
> My "Mass" for the LISP beer garden meeting:
>=20
> The LISP's dependency on special servers (DDT, formerly ALT) is a=20
> perfect invitation for abuse  -=20
> either by malicious hackers or by malicious owners, or the alliance=20
> of both. Who is able to control these servers is able to control =20
> internet forwarding.
> I can imagine that the RSA would like LISP very much.
>=20
>=20
>=20
>=20
>=20
> Don't worry, before you traffic to be encapsulated by LISP you will=20
> use DNS...
>=20
>=20
> Damien Saucez
>=20
>=20
>=20
>=20
>=20
> Heiner
>  =20
>=20
>=20
> _______________________________________________
> lisp mailing list
> lisp@ietf.org=

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

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

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

> https://www.ietf.org/mailman/listinfo/lisp
----------MB_8D04CE5E1EC302A_143C_28135B_webmail-vn002.sysops.aol.com-- From farinacci@gmail.com Fri Jul 12 09:29:24 2013 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 7982A21F9E5E for ; Fri, 12 Jul 2013 09:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryzG-rfkQCTs for ; Fri, 12 Jul 2013 09:29:24 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 12EF721F9E54 for ; Fri, 12 Jul 2013 09:29:23 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bi5so9140741pad.32 for ; Fri, 12 Jul 2013 09:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PQ6GW8y6oEKxfeioVpQGwN09GKDtYc5TWEU4CaR9DE0=; b=cWL4w3tjfxVlpq6M6TdYD7BfpsUlM+jH4gNvLrRoiSGsnvgy779GPp0LJ+RKG0JS0O ntTSqXyDPUcbDlA+0QIQy9TfgSEUObityR2w/aNJmoT4iy0UWzSMEB6FWAyolP65Z1f2 z4FjZfjiqs2BkZ4rODOnpku49YbqxZjwxltDi/TEUXJiPG9r4s08jHPqJbkbk+os4XBM srj4QqXMZ/RLed2/oNBTQfgS9nHJM5j1oKrn2rqmA0Xyz8HT9NL0cIE4VdM5KqORhuuf 2LcT1VQBz2ZVjST9SEhKPLDD0VtV6MsUAEwQ/UzUdmLrZeY7TS+qsRRnaw5Y/zn3DvWd ESbw== X-Received: by 10.68.163.195 with SMTP id yk3mr20298759pbb.142.1373646563557; Fri, 12 Jul 2013 09:29:23 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id bs3sm46147885pbc.42.2013.07.12.09.29.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 09:29:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <8D04CE5E1752B38-143C-B6785@webmail-vn002.sysops.aol.com> Date: Fri, 12 Jul 2013 09:29:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D04CE5E1752B38-143C-B6785@webmail-vn002.sysops.aol.com> To: heinerhummel@aol.com X-Mailer: Apple Mail (2.1503) Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 16:29:24 -0000 > It was in vain, instead the TTL-mechanism, which is embarrassingly = poor, is still in place (and is adopted by LISP - of course), Let me make a technical point. Let's say we have MAC addresses as EIDs. Let's say we have MAC addresses = that are also RLOCs. If an ITR receives a MAC frame from a host and = encapsulates to an RLOC, do you realize in this scenario LISP is in use = but there is no TTL decrement anywhere? Why is that? Because 802 frame does not have a TTL. If the EID space is using a protocol that has rules to be obeyed, LISP = will obey those rules. Hence, an IPv4 packet with a TTL is being = decremented because that is what IP routers do. After they do that and = LISP kicks in, LISP defines how encapsulation should be performed. So it is not true in either case above that LISP has adopted a = TTL-mechanism. Dino From jnc@mercury.lcs.mit.edu Fri Jul 12 15:18:31 2013 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 CF6DC21F9FC3 for ; Fri, 12 Jul 2013 15:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOqWKJIJXq1S for ; Fri, 12 Jul 2013 15:18:27 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id BB83C21E80A5 for ; Fri, 12 Jul 2013 15:18:18 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0694618C11B; Fri, 12 Jul 2013 18:18:16 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130712221816.0694618C11B@mercury.lcs.mit.edu> Date: Fri, 12 Jul 2013 18:18:16 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP online bibliography X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 22:18:31 -0000 > While working on the LISP architecture documents, I found that we did > not have (as far as I could tell) an online LISP bibliography, listing > the (increasingly) large number of papers on LISP (something I had a > need for). I have put one together: > > http://www.chiappa.net/~jnc/tech/lisp/LISPbiblio.html > ... > Please let me know of any fixes/additions, and I'll make them. I have added (I think) all the references that people sent me, as well as all the I-Ds I could find (both current and expired), and uploaded a new version. Again, if anything's missing (I am particularly interested in expired I-D's; I got as many as I could, but probably missed some), please send it along. Noel From heinerhummel@aol.com Sun Jul 14 02:10:06 2013 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 4E6E721F9ADE for ; Sun, 14 Jul 2013 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=-1.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6ewIMiLgq9b for ; Sun, 14 Jul 2013 02:10:00 -0700 (PDT) Received: from omr-d03.mx.aol.com (omr-d03.mx.aol.com [205.188.109.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5222721F9AAF for ; Sun, 14 Jul 2013 02:10:00 -0700 (PDT) Received: from mtaomg-da06.r1000.mx.aol.com (mtaomg-da06.r1000.mx.aol.com [172.29.51.142]) by omr-d03.mx.aol.com (Outbound Mail Relay) with ESMTP id 267F170000098; Sun, 14 Jul 2013 05:09:58 -0400 (EDT) Received: from core-dqb004c.r1000.mail.aol.com (core-dqb004.r1000.mail.aol.com [172.29.212.205]) by mtaomg-da06.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id D7A1BE000081; Sun, 14 Jul 2013 05:09:57 -0400 (EDT) References: <8D04CE5E1752B38-143C-B6785@webmail-vn002.sysops.aol.com> To: farinacci@gmail.com In-Reply-To: X-MB-Message-Source: WebUI Received: from 178.26.195.50 by webmail-d286.sysops.aol.com (205.188.93.225) with HTTP (WebMailUI); Sun, 14 Jul 2013 05:09:57 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8D04E890BEA1F87_998_2BC6FF_webmail-d286.sysops.aol.com" X-Mailer: AOL Webmail 37834-STANDARD Message-Id: <8D04E890BEA1F87-998-DD2F3@webmail-d286.sysops.aol.com> X-Originating-IP: [178.26.195.50] Date: Sun, 14 Jul 2013 05:09:57 -0400 (EDT) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1373792998; bh=JXLYwtLO11IG93M5Nxv4Uai3fvPZD0Xy9VWOWkkpQZs=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=yW+BFM+KpQ1177MziiNbbvEuqXXfQEcZwlWHPA9H5C1zjTkwtawyN07qewekTZcAD x7vrQOxbTuc4VptY7LyNkruZAExWMf5rcElWq941T8jg8UBXgouQiUFhK1MxNqWDyi AIJhgybf0ttO0XTqjOiWGrhsPKw3HOK+32gaxKxA= X-AOL-SCOLL-SCORE: 0:2:476240544:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d338e51e26ae575c3 Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 14 Jul 2013 09:10:06 -0000 This is a multi-part message in MIME format. ----------MB_8D04E890BEA1F87_998_2BC6FF_webmail-d286.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Certainly, LISP just tries to comply with what exists. I can understand thi= s, and yes, I would even have blamed LISP if it requested to look into the = inner (IP-) header and to decrement there the TTL-counter. The TTL-poorness is an rtgwg-issue and hereby an intra-domain issue. Correc= t me, if I am wrong saying that the TTL-counter is re-initialized when SP-b= orders are traversed :-( Its poorness stems from the belief that endless loops can occur. With TARA= however you can validate/use ALL adjacent links (for forwarding) i.e. incl= .the incoming link ( crank back link). Detouring routes are either imposed = with restricting rules, or, some links may be recognized as entrance to som= e dead-end area. In this case, as well as if the imposed restriction cannot= be complied with, the packet is discarded. Heiner =20 -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Dino Farinacci An: heinerhummel Cc: marc ; lisp Verschickt: Fr, 12 Jul 2013 6:29 pm Betreff: Re: [lisp] No LISP meeting for Berlin > It was in vain, instead the TTL-mechanism, which is embarrassingly poor,= is=20 still in place (and is adopted by LISP - of course), Let me make a technical point. Let's say we have MAC addresses as EIDs. Let's say we have MAC addresses th= at=20 are also RLOCs. If an ITR receives a MAC frame from a host and encapsulates= to=20 an RLOC, do you realize in this scenario LISP is in use but there is no TTL= =20 decrement anywhere? Why is that? Because 802 frame does not have a TTL. If the EID space is using a protocol that has rules to be obeyed, LISP will= obey=20 those rules. Hence, an IPv4 packet with a TTL is being decremented because = that=20 is what IP routers do. After they do that and LISP kicks in, LISP defines h= ow=20 encapsulation should be performed. So it is not true in either case above that LISP has adopted a TTL-mechanis= m. Dino =20 ----------MB_8D04E890BEA1F87_998_2BC6FF_webmail-d286.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Certainly, LISP just tries = to comply with what exists. I can understand this, and yes, I would even ha= ve blamed LISP if it requested to look into the inner (IP-) header and to d= ecrement there the TTL-counter.

The TTL-poorness is an rtgwg-issue and hereby an intra-domain issue. C= orrect me, if I am wrong saying that the TTL-counter is re-initialized when= SP-borders are traversed :-(

Its poorness stems from the belief that endless loops can occur.  = ;With TARA however you can validate/use ALL adjacent links (for forwarding)= i.e. incl.the incoming link ( crank back link). Detouring routes are eithe= r imposed with restricting rules, or, some links may be recognized as entra= nce to some dead-end area. In this case, as well as if the imposed restrict= ion cannot be complied with, the packet is discarded.

Heiner   


-----= Urspr=C3=BCngliche Mitteilung-----
Von: Dino Farinacci <farinacci@gmail.com>
An: heinerhummel <heinerhummel@aol.com>
Cc: marc <marc@sniff.de>; lisp <lisp@ietf.org>
Verschickt: Fr, 12 Jul 2013 6:29 pm
Betreff: Re: [lisp] No LISP meeting for Berlin

> It was in vain, instead  the TTL-me=
chanism, which is embarrassingly poor, is=20
still in place (and is adopted by LISP - of course),

Let me make a technical point.

Let's say we have MAC addresses as EIDs. Let's say we have MAC addresses th=
at=20
are also RLOCs. If an ITR receives a MAC frame from a host and encapsulates=
 to=20
an RLOC, do you realize in this scenario LISP is in use but there is no TTL=
=20
decrement anywhere?

Why is that? Because 802 frame does not have a TTL.

If the EID space is using a protocol that has rules to be obeyed, LISP will=
 obey=20
those rules. Hence, an IPv4 packet with a TTL is being decremented because =
that=20
is what IP routers do. After they do that and LISP kicks in, LISP defines h=
ow=20
encapsulation should be performed.

So it is not true in either case above that LISP has adopted a TTL-mechanis=
m.

Dino
----------MB_8D04E890BEA1F87_998_2BC6FF_webmail-d286.sysops.aol.com-- From farinacci@gmail.com Sun Jul 14 08:02:02 2013 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 08FF721F9A6D for ; Sun, 14 Jul 2013 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrbBibdT3cz0 for ; Sun, 14 Jul 2013 08:02:01 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2C95F21F93D4 for ; Sun, 14 Jul 2013 08:01:59 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so9960167pde.4 for ; Sun, 14 Jul 2013 08:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/xYLugoWYcxpeZ5qgsnztwI0pD2M9yxetIF9ZcompfA=; b=SGlTUO3XywjGCa12JzE4MLjOka4PHCirSJVgyxLZXjrlbV1kO2FtE0i42X0jeEhsHV KB6aQkGd5l7DssKx05Q7Vl4d+ExHEgHQlHhaTztDY1AKvaLwsVyLEqij7/5bYW1xZFzZ XlDiPaT3NNquUucYHdItLAm3+w98/1Ah93RysNVztSTeOKo7dae4jvdxz3HbDEbC5RRD FpwYWbKMZFdD4L5xyHxtjk+4IdrlH3Z9u/1VVV0JOnuLmJVBnF/eFx4n/jY+fqIIc43H Cq+kZnYoDfczVxXCWokqTqxolWSom6RgRnrTSOTzDhwZh1PsVR1fbVUvvtXupCRxW/pu B1sg== X-Received: by 10.66.136.237 with SMTP id qd13mr52234614pab.74.1373814118869; Sun, 14 Jul 2013 08:01:58 -0700 (PDT) Received: from [192.168.1.8] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id at1sm55935331pbc.10.2013.07.14.08.01.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 08:01:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <8D04E890BEA1F87-998-DD2F3@webmail-d286.sysops.aol.com> Date: Sun, 14 Jul 2013 08:01:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A786C88-7A30-405B-8740-4870CE3B3C48@gmail.com> References: <8D04CE5E1752B38-143C-B6785@webmail-vn002.sysops.aol.com> <8D04E890BEA1F87-998-DD2F3@webmail-d286.sysops.aol.com> To: heinerhummel@aol.com X-Mailer: Apple Mail (2.1503) Cc: lisp@ietf.org Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 14 Jul 2013 15:02:02 -0000 > The TTL-poorness is an rtgwg-issue and hereby an intra-domain issue. = Correct me, if I am wrong saying that the TTL-counter is re-initialized = when SP-borders are traversed :-( In ITR copies the inner header's TTL to the outer header's TTL if the = inner and outer headers have a TTL field. Dino From internet-drafts@ietf.org Mon Jul 15 15:51:15 2013 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 A4B5721E813A; Mon, 15 Jul 2013 15:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyigl7i2V8Hs; Mon, 15 Jul 2013 15:51:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA57511E81D5; Mon, 15 Jul 2013 15:51:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715225114.19296.75758.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 15:51:14 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 22:51:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : An Architecural Introduction to the LISP Location-Identi= ty Separation System Author(s) : J. Noel Chiappa Filename : draft-ietf-lisp-introduction-01.txt Pages : 38 Date : 2013-07-15 Abstract: LISP is an upgrade to the architecture of the IPvN internetworking system, one which separates location and identity (currently intermingled in IPvN addresses). This is a change which has been identified by the IRTF as a critically necessary evolutionary architectural step for the Internet. In LISP, nodes have both a 'locator' (a name which says _where_ in the network's connectivity structure the node is) and an 'identifier' (a name which serves only to provide a persistent handle for the node). A node may have more than one locator, or its locator may change over time (e.g. if the node is mobile), but it keeps the same identifier. One of the chief novelties of LISP, compared to other proposals for the separation of location and identity, is its approach to deploying this upgrade. (In general, it is comparatively easy to conceive of new network designs, but much harder to devise approaches which will actually get deployed throughout the global network.) LISP aims to achieve the near-ubiquitous deployment necessary for maximum exploitation of an architectural upgrade by i) minimizing the amount of change needed (existing hosts and routers can operate unmodified); and ii) by providing significant benefits to early adopters. This document is an introduction to the entire LISP system, for those who are unfamiliar with it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-introduction-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-introduction-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jnc@mercury.lcs.mit.edu Mon Jul 15 16:28:58 2013 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 D74FB11E825F for ; Mon, 15 Jul 2013 16:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvTqG2wLJP3E for ; Mon, 15 Jul 2013 16:28:49 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id A500611E81CC for ; Mon, 15 Jul 2013 16:28:49 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BFCB318C0AF; Mon, 15 Jul 2013 19:28:46 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130715232846.BFCB318C0AF@mercury.lcs.mit.edu> Date: Mon, 15 Jul 2013 19:28:46 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] I-D Action: draft-ietf-lisp-introduction-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 23:28:59 -0000 > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title: An Architecural Introduction to the LISP Location-Identity Separation System > Filename: draft-ietf-lisp-introduction-01.txt Hi, all, the new draft I just posted has a lot of new material and changes since the last one, but it's not quite ready for a fine-tooth comb review: I'm still folding in comments that people sent me last fall (thanks!), although many of those have already been dealt with in this version. I have instead focused on writing the 'to be written sections', and also adding a bunch of new sections that either i) people suggested to me, or ii) suggested themselves; I felt it was more important to do all that first. (So if you don't see a change you asked for - don't despair, I probably just haven't gotten to it yet. Any I don't agree with I will be taking up with people offline, to further consider.) Hopefully a new version will be out in two weeks (once the I-D system reopens) that is 'ready for prime time'. However, if people want to quickly scan through this version, and provide feedback on major points, like 'it should cover topic X', and things like that, that would be very much appreciated - that way those major fixes can be accomodated _before_ we get to the 'polished' version (ready for the F-T-C review). Here's a brief summary of most of the things that have changed: A number of sections previously marked 'to be written' have been written: - A number of 'Performance' sections, including i) ITR mapping caches, ii) the mapping system - The 'example packet handling' sections - A section on the possible/plausible impact, over time, on DFZ routing of LISP - Various fault handling sections A number of wholly new sections have been added: - A prefaratory note, explaining the overall structure and organizational rationale of the document pair - A number of 'Security' sections, including i) in the Overview, ii) about requesting a Mapping, iii) inside DDT - A section describing Probing - A section on mapping lifetimes - An explanation of SMRs - A section about what you have to do to deploy LISP (this can use some work, I know) There has been some internal re-organization: the material on Mapping Versioning has been moved up to the xTR section (now that is an RFC); Fault Handling has been moved in front of 'Improvements'. Much material has been moved to the 'Perspectives' document (especially Appendixes thereof), in order to keep the 'Introduction' document to a 'manageable' size, including the section on 'Design Approach', all material on ALT (including about its replacement with DDT), and the section about 'why DDT instead of DNS' (which isn't really an introduction topic anyway). My plan at this point is to separate the two documents, in terms of processing (as opposed to before, where I posted them at the same time), so I don't get e.g. comments jumbled in together, and have to sort them out. So, once the 'polished' version of this one is posted, we can be discussing this one in the foreground while I start in on writing the 'to-be-written' content for the 'Perspectives' document in the background. Noel From jnc@mercury.lcs.mit.edu Mon Jul 15 16:46:37 2013 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 3287511E824D for ; Mon, 15 Jul 2013 16:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPcdgvYdTPVP for ; Mon, 15 Jul 2013 16:46:33 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id B990611E8273 for ; Mon, 15 Jul 2013 16:46:30 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2181E18C091; Mon, 15 Jul 2013 19:46:30 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130715234630.2181E18C091@mercury.lcs.mit.edu> Date: Mon, 15 Jul 2013 19:46:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] I-D Action: draft-ietf-lisp-introduction-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 23:46:37 -0000 PS: I'm pretty impressed at how good a job the version diff tool: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-01 did here, given the magnitude of the changes. (The ability to detect changed line justification, separate from insertion/deletion of text, is particularly good.) Definitely an option for people who read the previous version, and just want to see what's changed. Noel From farinacci@gmail.com Wed Jul 17 11:56:45 2013 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 BB5D511E80E0 for ; Wed, 17 Jul 2013 11:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry1zzP3gnBqu for ; Wed, 17 Jul 2013 11:56:45 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 443B211E80C5 for ; Wed, 17 Jul 2013 11:56:45 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so2261674pac.40 for ; Wed, 17 Jul 2013 11:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=oyiMzxiKr2QbvtlYw4xzYZm0Hx5rrlW6Aw0H9ygBQYs=; b=I00fBWsVClvzzIXsL05kzvV6Mwn2Y4gUtQqj8wlu9M3EAyWvHrdl5eAIKKt5cIgZjS kd2TIIor3BLv/VeSAN+fdjoHR0KkGVL8txfxcY+ML+v1SrPqPqa7vFywhnF5BP9adIG9 8tCyE1GQqzuzcMqicWAfoAbBFL3wtAAEpqbzrIpFhRRm5lxDVvRo1RtHUgj1q0E0W4jM OpjT4HqVwxK8GVz1PwqOnFCAT8P4Vu03mAUE8lypNlCDklV/hZTJ06ytFG5/41zqTi9b KVmpoyK6KLZdwmxbNlY6U+St5JluvbVOYikKx+i/N17PGy7MyFJig2lZE7w9zcttYaFj PuJw== X-Received: by 10.66.141.4 with SMTP id rk4mr9199418pab.127.1374087404390; Wed, 17 Jul 2013 11:56:44 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id bs3sm9200351pbc.42.2013.07.17.11.56.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 11:56:43 -0700 (PDT) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jul 2013 11:56:40 -0700 Message-Id: To: "lisp@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "lisp-beta@external.cisco.com Beta" Subject: [lisp] Latest agenda for "All Things LISP" Meeting at Berlin IETF X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 18:56:45 -0000 We have reserved a room at the Intercontinental Berlin. Thanks goes to = Wilhelm, cisco, and Contextream for organizing and supporting. We have = capacity for 40 people. The day, time, and agenda is enclosed. As you can see we are = over-subscribed for the 3 hour period so if anyone wants to donate = minutes, it would be appreciated. Almost all the speakers below have confirmed. Thanks to all of them for = volunteering. Should be a fun session. Dino = --------------------------------------------------------------------------= ----- Agenda - "All Things LISP" - Wed Jul 31, 5:00-8:00pm, Intercontinental = Berlin Intro Agenda ground rules Dino 0-2 Future of LISP Dino 10 10 Use-Cases Signal-less LISP-Multicast Dino 10 LISP FLowMapping for NFV Sharon 15 Layer-2 LISP for DC Fabio 15 LISP-RE Dino 10 Network in Cloud Damien 10 VXLAN, P-bit, and LISP Darrel 5 65 Deployment Status: ciscoLive Update Darrel 15 LISPMob Update Alberto 10 25 Research Status; LISP-Lab Luigi 10 LISP-Views Luigi 10 Global Mapping Database Terry 10 LISP TCM Jose 10 40 IETF Things: Status on Arch/Intro Drafts Darrel 5 Deployment Draft Update Darrel 5 PIM changes for LISP-Mcast Isidor 10 SH-DHT Li 10 Homenet Multihoming Damien 10 lisp-nat-traversal-extensions Li 10 55 = 190-out-of-180 = --------------------------------------------------------------------------= ----- From damien.saucez@gmail.com Wed Jul 17 12:33:26 2013 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 F407D11E80E2 for ; Wed, 17 Jul 2013 12:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waNEqg8DZiX0 for ; Wed, 17 Jul 2013 12:33:25 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 129BD11E80E0 for ; Wed, 17 Jul 2013 12:33:24 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so2201828wes.3 for ; Wed, 17 Jul 2013 12:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=M3lFf/VL01tCm9fgxv04VS4HikGCoxiglE5V1IZf1H8=; b=dgmWlQsgDWjwY1szTvuuKwNfC8uxk7eVYVOay+lpJm3xOxVO8rBfjogasmrNSod3IN IgloGIhPDgYtzwtmpP5eZy4jdeArgilNtky6/0zjQZLH3pA4RF/3jT24ovvU7SJwXXiP N3GJ61DBSBfhqCuz0VT5UYQnuXK8nlWEql4l1GJ5ZHLZn+H960M6m7WD2Q+MjuVT9JOr 2HQwuDJwl0dpmJkRuKr7NiFT/Ae63vqE9dxss4jM99v9SgT3bcBq2cKycoCcv8GyU0gC scRzipBTT9eN685RUzQ1mdE4Y0GROtOLd+sxQGvhMFGRR1GKcFC4X7k+s36Y0jYk675r vuUQ== X-Received: by 10.180.187.47 with SMTP id fp15mr5700275wic.27.1374089603062; Wed, 17 Jul 2013 12:33:23 -0700 (PDT) Received: from [192.168.1.221] (LVelizy-156-46-22-251.w80-11.abo.wanadoo.fr. [80.11.231.251]) by mx.google.com with ESMTPSA id u7sm31476581wiw.9.2013.07.17.12.33.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 12:33:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Damien Saucez In-Reply-To: Date: Wed, 17 Jul 2013 21:33:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85D7DF76-22F0-48DC-8A88-2036874E04C9@gmail.com> References: To: Dino Farinacci X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org list" , "lisp-beta@external.cisco.com Beta" Subject: Re: [lisp] Latest agenda for "All Things LISP" Meeting at Berlin IETF X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 19:33:26 -0000 Hello, Thank you for the organisation, that seems pretty nice. If you want you can drop the homenet multihoming presentation to 5 = minutes. Damien Saucez On 17 Jul 2013, at 20:56, Dino Farinacci wrote: > We have reserved a room at the Intercontinental Berlin. Thanks goes to = Wilhelm, cisco, and Contextream for organizing and supporting. We have = capacity for 40 people. >=20 > The day, time, and agenda is enclosed. As you can see we are = over-subscribed for the 3 hour period so if anyone wants to donate = minutes, it would be appreciated. >=20 > Almost all the speakers below have confirmed. Thanks to all of them = for volunteering. Should be a fun session. >=20 > Dino >=20 > = --------------------------------------------------------------------------= ----- >=20 > Agenda - "All Things LISP" - Wed Jul 31, 5:00-8:00pm, Intercontinental = Berlin >=20 > Intro > Agenda ground rules Dino 0-2 > Future of LISP Dino 10 10 >=20 > Use-Cases > Signal-less LISP-Multicast Dino 10 > LISP FLowMapping for NFV Sharon 15 > Layer-2 LISP for DC Fabio 15 > LISP-RE Dino 10 > Network in Cloud Damien 10 > VXLAN, P-bit, and LISP Darrel 5 65 >=20 > Deployment Status: > ciscoLive Update Darrel 15 > LISPMob Update Alberto 10 25 >=20 > Research Status; > LISP-Lab Luigi 10 > LISP-Views Luigi 10 > Global Mapping Database Terry 10 > LISP TCM Jose 10 40 >=20 > IETF Things: > Status on Arch/Intro Drafts Darrel 5 > Deployment Draft Update Darrel 5 > PIM changes for LISP-Mcast Isidor 10 > SH-DHT Li 10 > Homenet Multihoming Damien 10 > lisp-nat-traversal-extensions Li 10 55 = 190-out-of-180 >=20 > = --------------------------------------------------------------------------= ----- >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Wed Jul 17 14:16:06 2013 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 71FD221F9D4F for ; Wed, 17 Jul 2013 14:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giwwcSxz8fF2 for ; Wed, 17 Jul 2013 14:16:05 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 242C021F9CA8 for ; Wed, 17 Jul 2013 14:16:05 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro2so2360594pbb.27 for ; Wed, 17 Jul 2013 14:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=O/yPepcdyuYyiL7/YPDUoKJ9h95kpFN9mC6j88ZeHgI=; b=N6sJlX9BHbSw+DnM+hsicLX/l26VExbFv3SiCrusdpMd+UW50Hw/fSp8YqcFK2bG4h u7Mr1XyWzQaYZDMi68ajLL4Gh/pQCk0TakwK0V4vdb3lKOd1dnGn9f19E9tCwrAtVA+o WErv+TeyMxq2Q3UM5Ac+8NKMmglebePIA3+Ehz2TaQc8dRwhu7yND1TGfUZDdPDPU5ue ToGPAMYH3BGufmnx8DiGBeo3RGYXziIMyV+cwSdO+NdgM/aajivXWRtuQHOtTMWI75OR lG5CVxTer2SwkFV+XyQ0n3AlszVsr/c/EZW5kqutn6RpKoQVRtFHt1M/VN8x0INkVzLt s09A== X-Received: by 10.66.149.198 with SMTP id uc6mr9874448pab.61.1374095764877; Wed, 17 Jul 2013 14:16:04 -0700 (PDT) Received: from [192.168.1.105] ([99.23.83.27]) by mx.google.com with ESMTPSA id zf3sm12437813pac.9.2013.07.17.14.16.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 14:16:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: Date: Wed, 17 Jul 2013 14:16:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10414570-42C5-4C62-B630-1E35738256D1@gmail.com> References: , <85D7DF76-22F0-48DC-8A88-2036874E04C9@gmail.com> To: "Shafi, Shahid" X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org list" Subject: Re: [lisp] Latest agenda for "All Things LISP" Meeting at Berlin IETF X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 21:16:06 -0000 > Are you guys recording this session by any chance?=20 We can try. I'll look into it.=20 Dino >=20 > thanks, > Shahid >=20 > ________________________________________ > From: Damien Saucez [damien.saucez@gmail.com] > Sent: Wednesday, July 17, 2013 12:33 PM > To: Dino Farinacci > Cc: lisp@ietf.org list; lisp-beta@external.cisco.com Beta > Subject: Re: [lisp] Latest agenda for "All Things LISP" Meeting at = Berlin IETF >=20 > Hello, >=20 > Thank you for the organisation, that seems pretty nice. >=20 > If you want you can drop the homenet multihoming presentation to 5 = minutes. >=20 > Damien Saucez >=20 > On 17 Jul 2013, at 20:56, Dino Farinacci wrote: >=20 >> We have reserved a room at the Intercontinental Berlin. Thanks goes = to Wilhelm, cisco, and Contextream for organizing and supporting. We = have capacity for 40 people. >>=20 >> The day, time, and agenda is enclosed. As you can see we are = over-subscribed for the 3 hour period so if anyone wants to donate = minutes, it would be appreciated. >>=20 >> Almost all the speakers below have confirmed. Thanks to all of them = for volunteering. Should be a fun session. >>=20 >> Dino >>=20 >> = --------------------------------------------------------------------------= ----- >>=20 >> Agenda - "All Things LISP" - Wed Jul 31, 5:00-8:00pm, = Intercontinental Berlin >>=20 >> Intro >> Agenda ground rules Dino 0-2 >> Future of LISP Dino 10 10 >>=20 >> Use-Cases >> Signal-less LISP-Multicast Dino 10 >> LISP FLowMapping for NFV Sharon 15 >> Layer-2 LISP for DC Fabio 15 >> LISP-RE Dino 10 >> Network in Cloud Damien 10 >> VXLAN, P-bit, and LISP Darrel 5 65 >>=20 >> Deployment Status: >> ciscoLive Update Darrel 15 >> LISPMob Update Alberto 10 25 >>=20 >> Research Status; >> LISP-Lab Luigi 10 >> LISP-Views Luigi 10 >> Global Mapping Database Terry 10 >> LISP TCM Jose 10 40 >>=20 >> IETF Things: >> Status on Arch/Intro Drafts Darrel 5 >> Deployment Draft Update Darrel 5 >> PIM changes for LISP-Mcast Isidor 10 >> SH-DHT Li 10 >> Homenet Multihoming Damien 10 >> lisp-nat-traversal-extensions Li 10 55 = 190-out-of-180 >>=20 >> = --------------------------------------------------------------------------= ----- >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From jnc@mercury.lcs.mit.edu Tue Jul 23 06:39:39 2013 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 7272C11E8146 for ; Tue, 23 Jul 2013 06:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gWKMx+eKg8g for ; Tue, 23 Jul 2013 06:39:34 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id A142A11E8108 for ; Tue, 23 Jul 2013 06:39:26 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E231718C0E5; Tue, 23 Jul 2013 09:39:23 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130723133923.E231718C0E5@mercury.lcs.mit.edu> Date: Tue, 23 Jul 2013 09:39:23 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: [lisp] Intro final content questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 13:39:39 -0000 So, I've been looking at the Intro draft, noticing a final few non-main-body things that need to be written: glossary, appendixes, etc. I have two questions for everyone related to that effort: First, there's a section for 'ongoing improvements'; i.e. stuff that is happening, but is not yet formalized. I have guessed that this will include i) mobility, and ii) better NAT support (since both of these have relatively mature ID's, and fill major needs). What all should I cover here, other than those two? Second, there's a suggestion for an appendix covering 'History of Loc/ID split'. Looking at the document, much of the material currently in the 'Background' section at the very start could be moved to that appendix, getting rid of a fair amount of stuff that is in the way in the main body of the text before the reader can get to the meat of the document - i.e. LISP itself. So unless people object, I'm going to move most of that to the appendix, leaving only the bare minimum on the general concept of L/ID. My current goal is to have a 'close-to-final' (i.e. only editorial issues like spelling, etc, left) ready to go when the I-D window re-opens in a week or so. So, if you have _content_ issues ('we need to talk about x', or 'talk about y before you talk about z'), please try and get them to me soon! Noel From damien.saucez@gmail.com Tue Jul 23 13:47:10 2013 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 27C0011E8100 for ; Tue, 23 Jul 2013 13:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTG-iJG8kK6V for ; Tue, 23 Jul 2013 13:47:09 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AC93911E8136 for ; Tue, 23 Jul 2013 13:47:08 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hi5so36483wib.7 for ; Tue, 23 Jul 2013 13:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zlRi5IlC+ZjSz19rQxvLtbEldAb/uq1GMA3XN+Qq9vU=; b=n8tDjDtQtOaTWbbCcdZWQWg0N6You6QtdeJDhGOvelNO5fauEZxoY0X9p1lI2fteJ/ eLXOkofHknHoUwEVIbnIvrQLLov3+KFP0lg/TLEXp0stVAyXIGqOtQxXq8ClJ3qs8BiK zAezX36USG8+qlIZ9yYOkt2nH3lN4fzsyf2+Z55GUgl9EpC4zHLMZW4tOLR5TQnZmzZP EhqqSw86L8Ron/+WsUTvj+fFBG0yM4+Wpvr/8ThhVTFDh6IKyHav6IYPTdIINh8e26pb +Fk6NxfRwLUKOX+Odz3dZM6fd9xkCeO2uGwBuJpT8M6XO44i8kwAM8DjpmUrQT2MpJKC mWFg== X-Received: by 10.180.189.37 with SMTP id gf5mr392423wic.9.1374612427631; Tue, 23 Jul 2013 13:47:07 -0700 (PDT) Received: from [192.168.1.221] (LVelizy-156-46-22-251.w80-11.abo.wanadoo.fr. [80.11.231.251]) by mx.google.com with ESMTPSA id s19sm882692wik.11.2013.07.23.13.47.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 13:47:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Damien Saucez In-Reply-To: <5187D023.8010406@joelhalpern.com> Date: Tue, 23 Jul 2013 22:47:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5187D023.8010406@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org" Subject: Re: [lisp] draft-ietf-lisp-threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 20:47:10 -0000 Dear Joel, Please first apologies four our silence. We are indeed very late with this draft. We have discussed with the = authors about the way of fixing the problems. However, we think that we need to = discussed f2f with people to propose a new draft version that corresponds to the best = consensus between needs of people. For example, we believe that assessing the = security level risk is important, however, putting a "rank" as we made is touchy as = from one to another, the feeling of danger can be very different. We thus think of = remove this "absolute" ranking and replace by some sentences that are more neutral. = For that, we still need to find a way to cover with precision the problems = and their solutions. Also, we want to add to the draft the example provided during = the discussion by mails. We hope to have valuable changes in the document at the term of this = IETF and propose a new version to the WG in the following of the meeting. So, we are not dead or silent, just that we want to be sure to provide the = best possible document as the topic is very serious. Respectfully yours, The authors, On 06 May 2013, at 17:45, Joel M. Halpern wrote: > My apologies for not getting to this issue soone. >=20 > The approach being taken in this version of the document seems to me = to be ineffective. As a simple example, section 5.2 says that = EID-to-RLOC cache Threats are Severity level 2, meaning that it can be = dealt with by turning off certain features in pubic deployments. > But it is then followed by a LISP of threats, and a set of points to = features in section 6 and 6.3. As a result I can not tell what features = would need to be turned off to address the threat of section 5.2. >=20 > I am very concerned by declaring that folks should turn off = echo-nonce. Echo-none was added, for use in public deployments, fo good = reasons. Changing the recommendations in this regard is fairly major. >=20 > This leads to a general issue about Severity Level 2. Across the = document, different features are recommended to be turned off. As a = reader, it is very easily to lose track of the collective effect. If we = are going to stick with this approach, I think we need to pull up the = list of problematic features to the front of the document. We need to = clearly state that based on the analysis below, features X, Y, and Z are = not recommended for public deployments of LISP. > And then the WG has to decide whether that is a recommendation we can = support. > (Yes, I think we would be well-served putting this in the front of the = document, rather than in the security considerations section.) >=20 > In the description of section 5.4.4 of Instance ID bits, I do not = understand how an ACL could help. I can not see folks configuring = firewalls for the set of EIDs permitted within the VPN. Such a = configuration would counter the very ease of deployment associated with = using LISP for VPNs. Outer have a similar problem, and would need to be = able to act on the instance ID, which current ACLs can not do. >=20 > Section 7 seems to call for Proxy-ITR deployers to deploy data plane = access control at "the border of the network, that is the edge of the = scope of the Proxy_ITR's announcement of the EID-Prefix." But in many = Proxy-ITR deployments, that edge is not under the control of the = Proxy-ITR deployer. >=20 > Proxy-ETR static configuration seems to be difficult to integrate with = the dynamics of LISP (section 7, Proxy-ETR. >=20 > The text in section 10 (Security Considerations) regers to "the = increasing deployment of spoofing prevention techniques such as = [rfc3704] or [SAVI]..." I have not seen any evidence of such increasing = deployment, and plenty of evidence (such as the recent spoofed DNS = reflection attack) that it is not increasing. >=20 > ---- >=20 > As a minor suggestion, when there are existing configuration = mechanisms that can address the threat, it would be helpful to point to = the specific document and section where that is described. For example, = section 5.3 could point to RFC 6830 section 10 (security = considerations). >=20 > The introduction of section 6 should not end with a Severity level as = each subsection has its ow Severity level indication. >=20 > Claiming that "correct deployment of anti-spoofing" means that a treat = is Severity level 1 is technically accurate, but probably misleading and = likely to raise problems. (Section 6.1 for example). (Rate limiting = reduces the scope of the attack, but does not prevent it.) >=20 > Yours, > Joel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Tue Jul 23 14:20:00 2013 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 AB4D411E8159 for ; Tue, 23 Jul 2013 14:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYEER06yxS-E for ; Tue, 23 Jul 2013 14:19:56 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9D511E8136 for ; Tue, 23 Jul 2013 14:19:56 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n12so907602wgh.9 for ; Tue, 23 Jul 2013 14:19:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ACNMKO6dmtIpa7S0ymrlE9VKNaEoq6Pr57I/mJ9WIhM=; b=ejzw2Q8vDE+LnbAYiCulTi+2gjAvsJoEx+hH5naStHQOB2Lkh4VOwo3Zg9v1wPjYp9 s2Ac1gcofnuOzI6yLmTWRLZf8B2Jf0ZpH8sl00dpDztGwkdBdkUw9p4f5LS7Q87q/pNu OuZg9LOzpEQ//RZoR6puaVxudviTZajxx6uiFS4btNUaSeHjntxISz7UQP2+KIkXucGl dJL59MUuh3N/lJErgwoXWC4ph0r9LFJUt+TAjk7xz1OzQdtYjiHMsB4nHlAHAFZnurlN ZFE7M0ZSt5BE3jAm2tun+Qo/CAXH4c8+gJRzoN5WQXvwa/Fzpq1iuTzTv8jSnnX+tVrV X33g== X-Received: by 10.180.74.162 with SMTP id u2mr399342wiv.36.1374614395102; Tue, 23 Jul 2013 14:19:55 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:b86e:f111:5ad8:8756? ([2a01:e35:1381:3430:b86e:f111:5ad8:8756]) by mx.google.com with ESMTPSA id li9sm1122898wic.2.2013.07.23.14.19.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 14:19:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luigi Iannone In-Reply-To: <20130723133923.E231718C0E5@mercury.lcs.mit.edu> Date: Tue, 23 Jul 2013 23:19:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3D4BB6CD-FB80-4C4F-B1E7-8AB13BC70B16@gigix.net> References: <20130723133923.E231718C0E5@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnSi0y8soNxsf3mAJxi+DXpnOPY+Tv1dhHzNPkWJVmpACbpMKMpCCAQYgIII9ObtQznERAI Cc: lisp@ietf.org Subject: Re: [lisp] Intro final content questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 21:20:00 -0000 Hi Noel, On 23 Jul. 2013, at 15:39 , Noel Chiappa = wrote: > So, I've been looking at the Intro draft, noticing a final few = non-main-body > things that need to be written: glossary, appendixes, etc. I have two > questions for everyone related to that effort: >=20 > First, there's a section for 'ongoing improvements'; i.e. stuff that = is > happening, but is not yet formalized. I have guessed that this will = include > i) mobility, and ii) better NAT support (since both of these have = relatively > mature ID's, and fill major needs). What all should I cover here, = other than > those two? Should we include anything about the request of an EID prefix? What if we give a slightly larger scope to this section? Including LISP = alternative use cases. LISP is being used (or at least is studied) to be used in scenarios for = which it has not been designed originally. Which, BTW includes mobility since it has never been in the charter. I am thinking at LISP in the context of data centers (NVO3 drafts), or = as multimedia traffic optimisation (check the TCMTF Bof next week). Luigi >=20 > Second, there's a suggestion for an appendix covering 'History of = Loc/ID > split'. Looking at the document, much of the material currently in the > 'Background' section at the very start could be moved to that = appendix, > getting rid of a fair amount of stuff that is in the way in the main = body of > the text before the reader can get to the meat of the document - i.e. = LISP > itself. So unless people object, I'm going to move most of that to the > appendix, leaving only the bare minimum on the general concept of = L/ID. >=20 >=20 > My current goal is to have a 'close-to-final' (i.e. only editorial = issues > like spelling, etc, left) ready to go when the I-D window re-opens in = a week > or so. So, if you have _content_ issues ('we need to talk about x', or = 'talk > about y before you talk about z'), please try and get them to me soon! >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mblokzij@cisco.com Tue Jul 23 14:47:44 2013 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 8137911E8149 for ; Tue, 23 Jul 2013 14:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAJ9WD51utVd for ; Tue, 23 Jul 2013 14:47:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E5A0511E82D6 for ; Tue, 23 Jul 2013 14:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47138; q=dns/txt; s=iport; t=1374616058; x=1375825658; h=from:to:subject:date:message-id:mime-version; bh=cX0E3kDrxEhfaraC2BVk4fBfI7H7yOLw/wGSwoOGb24=; b=EDcr4Hfyc8FNu9zsYhepyQvwpsTFteChTjTeYAHug+n/FkztmCtexlR7 FRbQqW3Z+N94iKhsJQesA19XHvcmNvtLkzq/U4Fy/x/TJsFaYlGE0ZnVl wHQx+7iVIDSN5i+U0yGdjUQSR31kHZgDO/xfbnd9p4j/EsapiGCymRKZS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAGj57lGtJXG9/2dsb2JhbABRAQMGgwY1ULgliDqBExZ0giYBBBoBUx0BGhAWAT8XEAQRCgyHfAyXZaBIjjARARV1g0puA5kIkCSDFECBag X-IronPort-AV: E=Sophos;i="4.89,730,1367971200"; d="scan'208,217";a="235515145" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 23 Jul 2013 21:47:36 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6NLla5i023393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Jul 2013 21:47:36 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.26]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 16:47:36 -0500 From: "Michiel Blokzijl (mblokzij)" To: "lisp@ietf.org" Thread-Topic: Comments on draft-ietf-lisp-introduction-01 Thread-Index: AQHOh+4+JnfowMmVZEGf14El+n6AWw== Date: Tue, 23 Jul 2013 21:47:35 +0000 Message-ID: <4ABB752A36221949A095CDE2C6DBB1C8084E4B4D@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.216.218] Content-Type: multipart/alternative; boundary="_000_4ABB752A36221949A095CDE2C6DBB1C8084E4B4Dxmbalnx12ciscoc_" MIME-Version: 1.0 Subject: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 21:47:44 -0000 --_000_4ABB752A36221949A095CDE2C6DBB1C8084E4B4Dxmbalnx12ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, First of all, let me briefly introduce myself, since this is the first time= I'm writing to this list. I'm Michiel, a software engineer at Cisco workin= g on LISP, primarily in IOS and IOS-XR. I joined the team a bit more than a= year ago; while I haven't been around for that long, I had at the time les= s than a handful of days to learn about LISP and to decide whether or not t= o join the team, and I still remember that it was.. let's say, "surprisingl= y difficult". And, I think that we as the LISP community can do better (at = the time I hadn't read the lisp introduction draft). I do think that LISP i= s a very cool technology that has a lot of potential! I understand that comments to this draft are time-critical, which is why I'= m releasing the first batch now, even though I've only covered the abstract= , ToC and the first three sections (and section 8). Despite me only having = covered those, I see that my email is rapidly approaching the limit= s (if it hasn't gone over already).. I'll finish going through the draft an= d provide comments on the rest, though it may take me a few more days.. Anyway, enough about me etc, here are my thoughts on the draft at hand. My = thoughts are my own, and may or may not coincide with Cisco's. Also, Noel, = please don't take my criticism personally, it's about the working group doc= ument, not about you. :-) High-level, birds-eye view: * I think this document is confused. It doesn't really know if it's an arch= itecture document, or an introductory text, or an introduction to the archi= tecture document. I think that an architecture document and an introductory= document serve different audiences and purposes, even though there may be = some overlap in topics. The exact scope of each is perhaps somewhat debatab= le, but I think the main purpose of the introduction is to provide the read= er an overview of LISP and familiarise him/her with the main concepts, emph= asising understanding, perhaps even over technical precision. An introducti= on probably also doesn't need to exhaustively list every detail and compone= nt of the system. We should avoid having two very similar texts. ** I think the title "Architectural Introduction" adds to the confusion her= e, and I think it would be better to just call this document "Introduction = to LISP", and aim for providing exactly that. * I think there's a lot of background material. I think we should aim for "= just enough" to understand the introduction to LISP, rather than a comprehe= nsive study of "LISP in the context of the history of the internet" * Looking at the contents=85 ** it looks like a VERY LONG introduction (37 pages if you print the HTML p= age). I think introductions should be a bit shorter, and less daunting. My = first impression (with my LISP newbie hat on) is "Oh my goodness, I need to= read all that just to get an idea about LISP?". I know that the prefatory = note says otherwise, but you don't see that when you open up the HTML page = and give it a quick scroll through. ** The design approach comes surprisingly late into the text (I'm not sure = this is even the right document for that) ** Here are some sections I don't think are necessary for the introduction = (again, just based on the table of contents; reading them may lead me to ch= ange my opinion), mostly because they sound like they're going into the nit= ty gritty detail that should be part of main protocol specs: 4.4. Interworking With Non-LISP-Capable Endpoints (maybe) 4.5. Security in LISP [or at least move it closer to the end] 9.2. UDP Encapsulation Details ("details") 9.3. Header Control Channel 9.3.1. Mapping Versioning 9.3.2. Echo Nonces 9.3.3. Instances 9.4. Probing 9.5. Mapping Lifetimes and Timeouts 9.6. Security of Mapping Lookups 9.7. Mapping Gleaning in ETRs 9.8. Fragmentation 10.1. The Mapping System Interface 10.1.1. Map-Request Messages 10.1.2. Map-Reply Messages 10.1.3. Map-Register and Map-Notify Messages 10.2.1. Map-Referral Messages 10.3. Reliability via Replication 10.4. Security of the DDT Indexing Sub-system 10.5. Extended Tools 10.6. Performance of the Mapping System 11.3. Proxy Devices 11.3.1. PITRs 11.3.2. PETRs 11.4. LISP-NAT 11.5. Use Through NAT Devices 11.5.1. First-Phase NAT Support 11.5.2. Second-Phase NAT Support 11.6. LISP and DFZ Routing 11.6.1. Long-term Possibilities 12. Fault Discovery/Handling (maybe) 12.1. Handling Missing Mappings 12.2. Outdated Mappings 12.2.1. Outdated Mappings - Updated Mapping 12.2.2. Outdated Mappings - Wrong ETR 12.2.3. Outdated Mappings - No Longer an ETR 12.3. Erroneous Mappings 12.4. Neighbour Liveness 12.5. Neighbour Reachability 13. Current Improvements 13.1. Improved NAT Support 13.2. Mobile Device Support 13.3. Multicast Support 13.4. {{Any others?}} B.1. Old LISP 'Models' (maybe) =3D> I'm not saying none of these should be mentioned, but I don't think ea= ch of them warrant a section of their own in an "introduction" document. I = think things can be summarised a bit more to convey the main points. * There is lots of stuff in brackets, which looks like it might be too impo= rtant to be ignored, so perhaps it's not all suitable to be in brackets? * It's good to define the intended audience: This document is an introduction to the entire LISP system, for those who are unfamiliar with it. Abstract: LISP is an upgrade to the architecture of the IPvN internetworking system, one which separates location and identity (currently intermingled in IPvN addresses). * I would be inclined to say "IPv4 and IPv6 internetwork", I think that, wh= ile technically correct, IPvN is a less often used term. Or at least I don'= t see it being used often. You could also just say "IP". I'd also drop the = 'system', as I think an internetwork is a system already? * What do you mean with 'currently intermingled in IPvN addresses'? Do you = mean that location and identity are currently both expressed in IP addresse= s when using LISP? Or do you mean that in the current IP world, both locati= on and identity is expressed with 1 IP address? I guess the latter, but I d= on't think it's particularly clear. * This is a change which has been identified by the IRTF as a critically necessary evolutionary architectural step for the Internet. =3D> If this was wikipedia or an academic paper, I'd tag that with "citatio= n needed". 1. Prefaratory Note * Spello: "prefatory" is suggested by Google. * Re 'Architectural Introduction' =3D> see high level items above * It is intended to both be easy to follow, and also to give the reader a choice as to how much they wish to know about LISP. Reading only the first part(s) of the document will give a good high- level view of the system; reading the complete document should provide a fairly detailed understanding of the entire system. =3D> Being easy to follow is good. I think it's also fine to provide a good= high-level overview of the system in the first parts of the document. I do= n't think it's necessary to provide a very detailed understanding of the en= tire system as part of the introduction though, I think this is outside the= scope of an introduction - after all, that's what all the other documents = are there for, and I think a huge intro will just scare people off. This goal explains why the document has a somewhat unusual structure. It is not a reference document, where all the content on a particular topic is grouped in one place. (That role is filled by the various protocol specifications.) It starts with a very high-level view of the entire system, to provide readers with a mental framework to help understand the more detailed material which follows. A second pass over the whole system then goes into more detail; finally, individual sub-systems are covered in still deeper detail. * Sounds like there's way too much detail for an introduction, and I'm not = sure it's necessary to cover one component thing three times in an introduc= tion. * I'm not sure an unusual structure helps understanding. Have you given thi= s to someone new to LISP and asked them how much they understood? I tried t= hat when I attempted to formulate a "LISP in 5 sentences" description (samp= le size of 1). The result was that the experiment worked, but my 5 sentence= s didn't. Note: This document is a descriptive document, not a protocol specification. Should it differ in any detail from any of the LISP protocol specification documents, they take precedence for the actual operation of the protocol. * Excellent. 2. Background * See high-level comment, I think the aim should be to provide "just enough= " * Now, having said that, I'm not sure that the "just enough" aim is actuall= y fulfilled. I think that, apart from the first paragraph, the background s= ection doesn't actually further the understanding of the document, as the b= its in it are not necessary to understand LISP. You don't need to know when= it was formed, how the history influenced it or when it became an RFC. I'd= put those details into a 'history' appendix. [Todo: come back to this afte= r I've finished reading the document and see what else would need to be add= ed beyond the first paragraph] * It has gradually been realized in the networking community that networks (especially large networks) should deal quite separately with the identity and location of a node (basically, 'who' a node is, and 'where' it is). At the moment, in both IPv4 and IPv6, addresses indicate both where the named device is, as well as identify it for purposes of end-end communication. * Ok, this can be accepted as fact. I think however that it would be more u= seful to briefly introduce the location/id split by looking at an example: Today, network nodes (routers, hosts, etc) typically have one or more IP ad= dresses assigned to them. These IP addresses encode two bits of information= : the location of a node, namely /which network/ the node is on, as well as= a "host identifier". For example, the IP address 192.168.3.14, together wi= th the subnet mask 255.255.255.0, refers to "host 14" on the network "192.1= 68.3.0/24". Of course there are many other ways to express location, and I guess this i= s just one example, but I think it's quite accessible (to pretty much anyon= e who's configured a static IP address). I hope it's correct enough and dem= onstrates some aspects of location and identity. If not, maybe we should fi= nd another example. * The distinction was more than a little hazy at first: the early Internet [RFC791], like the ARPANET b= efore it [Heart] [NIC8246], co- mingled the two, although there was recognition in the early Internet work that there were two different things going on. [IEN19] =3D> I'd file this in the "LISP in the context of the history of the intern= et" (LicothoI) category, which I think is best documented in it's own draft= . I'd summarise it in one sentence saying something like "The location/iden= tity separation is not a newly discovered concept, it was recognised alread= y in the early days of the internet [citation]", but at the moment I'm not = sure where to best put it. * This likely resulted not just from lack of insight, but also the fact that extra mechanism is needed to support this separation (and in the early days there were no resources to spare), as well as the lack of need for it in the smaller networks of the time. (It is a truism of system design that small systems can get away with doing two things with one mechanism, in a way that usually will not work when the system gets much larger.) =3D> "LicothoI" =3D> Can be replaced with a one-sentence summary =3D> I don't think that the truism adds any value, and thus can be removed. * The ISO protocol architecture took steps in this direction [NSAP], but to the Internet community the necessity of a clear separation was definitively shown by Saltzer. [RFC1498] Later work expanded on Saltzer's, and tied his separation concepts into the fate-sharing concepts of Clark. [Clark], [Chiappa] =3D> Licothol * The separation of location and identity is a step which has recently been identified by the IRTF as a critically necessary evolutionary architectural step for the Internet. However, it has taken some time for this requirement to be generally accepted by the Internet engineering community at large, although it seems that this may finally be happening. [RFC6115] Please could you point out exactly which bit of RFC6115 supports the above = statement, especially the first sentence? Maybe I missed it. (I'm not comme= nting on whether or not I agree with the statement, after all I'm not part = of the IRTF anyway, just on the reference) * The LISP system for separation of location and identity resulted from the discussions of this topic at the Amsterdam IAB Routing and Addressing Workshop, which took place in October 2006. [RFC4984] A small group of like-minded personnel from various scattered locations within Cisco, spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop. The first Internet-Draft on LISP appeared in January, 2007, along with a LISP mailing list at the IETF. [LISP0] Trial implementations started at that time, with initial trial deployments underway since June 2007; the results of early experience have been fed back into the design in a continuous, ongoing process over several years. I think the above is useful background info, even in an intro, but belongs = into a 'history' section, maybe in the appendix. * LISP at this point represents a moderately mature system, having undergone a long organic series of changes and updates. I think this statement would require regular updating as LISP matures, so I= 'm not sure it's suitable for a static RFC. * LISP transitioned from an IRTF activity to an IETF WG in March 2009, and after numerous revisions, the basic specifications moved to becoming RFCs in 2012 (although work to expand and improve it continues, and undoubtly will for a long time to come). Perhaps slightly less useful background info, but probably OK for a history= section. * I think the History section should go into an appendix. We want to make i= t as easy as possible for newbies to pick up and understand LISP, and havin= g less text between them and LISP means newbies are less likely to loose in= terest. 3. Deployment Philosophy It may seem odd to cover 'deployment philosophy' at this point in such a document. However the deployment philosophy was a major driver for much of the design (to some degree the architecture, and to a very large measure, the engineering). So, as such an important motivator, it is very desirable for readers to have this material in hand as they examine the design, so that design choices that may seem questionable at first glance can be better understood. =3D> I think this paragraph doesn't add much value. It's 7 lines explaining= why the next 8 lines are there=85 Experience over the last several decades has shown that having a viable 'deployment model' for a new design is absolutely key to the success of that design. A new design may be fantastic - but if it can not or will not be successfully deployed (for whatever factors), it is useless. This absolute primacy of a viable deployment model is what has lead to some painful compromises in the design. This further motivates why we should care about a successful deployment mod= el The extreme focus on a viable deployment scheme is one of the novelties of LISP. So that sentence there the real content of this whole section? Considering = the fact that there are more sections dealing with deployment, I think some= merging and cutting needs to happen.. I'm thinking about 3.1-3.3., and 8. = Design Approach (though I'll have more comments on those later). I think it= 's fine to say something like, "Given that the ease of deployment greatly i= nfluences the adoption of new technologies, one of the design goals of LISP= stated that it should support incremental deployments, which provide benef= its to the users from day one", or something along those lines. I think tha= t would sufficiently summarise the whole section here, including 3.1.( Econ= omics). I think sections 3.2 and 3.3 can similarly be summarised in one par= agraph: N.N Design Philosophy [this is just a sketch of the argument I'm trying to = make, not a final wording suggestion] =85 Another important design goal of LISP stated that it should be easily deplo= yable. This was motivated by the pragmatic insight that this would be key t= o widespread adoption. This was realised in three ways. Firstly, the cost o= f implementing LISP should be low in terms of complexity and number of node= s that need changing, and secondly the benefit in terms of added value (in = the form of services or features) should be high. Furthermore, LISP should = support and interoperate with and support existing protocols (e.g. IPv4, IP= v6, TCP and UDP), and transition mechanisms should be provided. I'd cut the section "3.3. 'Self-Deployment'"; I understand that a snowball= effect is very desirable, but I'm not sure it furthers any argument at thi= s point in time. 8. D= esign Approach Before describing LISP's components in more detail below, it it worth pointing out that what may seem, in some cases, like odd (or poor) design approaches do in fact result from the application of a thought-through, and consistent, design philosophy used in creating them. This design philosophy is covered in detail in in [Perspective], Section "Design"), and readers who are interested in the 'why' of various mechanisms should consult that; reading it may make clearer the reasons for some engineering choices in the mechanisms given here. =3D> This whole section is basically useless. It's only piece of real conte= nt is the reference to [Perspective]. To be continued=85 Best regards! Michiel --_000_4ABB752A36221949A095CDE2C6DBB1C8084E4B4Dxmbalnx12ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi all,

First of all, let me briefly introduce myself, since this is the first= time I'm writing to this list. I'm Michiel, a software engineer at Cisco w= orking on LISP, primarily in IOS and IOS-XR. I joined the team a bit more t= han a year ago; while I haven't been around for that long, I had at the time less than a handful of days t= o learn about LISP and to decide whether or not to join the team, and I sti= ll remember that it was.. let's say, "surprisingly difficult". An= d, I think that we as the LISP community can do better (at the time I hadn't read the lisp introduction draft). I do th= ink that LISP is a very cool technology that has a lot of potential!

I understand that comments to this draft are time-critical, which is w= hy I'm releasing the first batch now, even though I've only covered the abs= tract, ToC and the first three sections (and section 8). Despite me only ha= ving covered those, I see that my email is rapidly approaching the <tl/dr> limits (if it hasn't gone o= ver already).. I'll finish going through the draft and provide comments on = the rest, though it may take me a few more days..

Anyway, enough about me etc, here are my thoughts on the draft at hand= . My thoughts are my own, and may or may not coincide with Cisco's. Also, N= oel, please don't take my criticism personally, it's about the working grou= p document, not about you. :-)

High-level, birds-eye view:
* I think this document is confused. It doesn't really know if it's an= architecture document, or an introductory text, or an introduction to the = architecture document. I think that an architecture document and an introdu= ctory document serve different audiences and purposes, even though there may be some overlap in topics. The exact s= cope of each is perhaps somewhat debatable, but I think the main purpose of= the introduction is to provide the reader an overview of LISP and familiar= ise him/her with the main concepts, emphasising understanding, perhaps even over technical precision. An intro= duction probably also doesn't need to exhaustively list every detail and co= mponent of the system. We should avoid having two very similar texts.
** I think the title "Architectu= ral Introduction" adds to the confusion here, and I think it would be = better to just call this document "Introduction to LISP", and aim= for providing exactly that.

* I think there's a lot of background= material. I think we should aim for "just enough" to understand = the introduction to LISP, rather than a comprehensive study of "LISP i= n the context of the history of the internet"

* Looking at the contents=85
** it looks like a VERY LONG introduction (37 pages if you print the H= TML page). I think introductions should be a bit shorter, and less daunting= . My first impression (with my LISP newbie hat on) is "Oh my goodness,= I need to read all that just to get an idea about LISP?". I know that the prefatory note says otherwise, = but you don't see that when you open up the HTML page and give it a quick s= croll through.
** The design approach comes surprisingly late into the text (I'm not = sure this is even the right document for that)
** Here are some sections I don't think are necessary for the introduc= tion (again, just based on the table of contents; reading them may lead me to change = my opinion), mostly because they sound like they're going into the nitt= y gritty detail that should be part of main protocol specs:
     4=
.4.  Interworking With Non-LISP-Capable Endpoints (maybe)
     4=
.5.  Security in LISP [or at least move it closer to the end]
     9.2.  U=
DP Encapsulation Details ("details")
     9.3.  Header Contro=
l Channel
       9.3.1.  Mapping Versioning
       9.3.2.  Echo Nonces
       9.3.3.  Instances

     9.4.  Probing
     9.5.  Mapping Lifetimes and Timeouts
     9.6.  Security of Mapping Lookups
     9.7.  Mapping Gleaning in ETRs
     9.8.  Fragmentation
     1=
0.1. The Mapping System Interface
       10.1.1. Map-Request Messages
       10.1.2. Map-Reply Messages
       10.1.3. Map-Register and Map-Notify Messages
      =
 10.2.1. Map-Referral Messages
     10.3. Reliability via Replication
     10.4. Security of the DDT Indexing Sub-system
     10.5. Extended Tools
     10.6. Performance of the Mapping System
     1=
1.3. Proxy Devices
       11.3.1. PITRs
       11.3.2. PETRs
     11.4. LISP-NAT
     11.5. Use Through NAT Devices
       11.5.1. First-Phase NAT Support
       11.5.2. Second-Phase NAT Support
     11.6. LISP and DFZ Routing
       11.6.1. Long-term Possibilities
   12. Fault Discovery/Handling (maybe)
     12.1. Handling Missing Mappings
     12.2. Outdated Mappings
       12.2.1. Outdated Mappings - Updated Mapping
       12.2.2. Outdated Mappings - Wrong ETR
       12.2.3. Outdated Mappings - No Longer an ETR
     12.3. Erroneous Mappings
     12.4. Neighbour Liveness
     12.5. Neighbour Reachability
   13. Current Improvements
     13.1. Improved NAT Support
     13.2. Mobile Device Support
     13.3. Multicast Support
     13.4. {{Any others?}}

     B=
.1.  Old LISP 'Models' (maybe)

=3D> I'm not saying none of these should be mentioned, but I don't = think each of them warrant a section of their own in an "introduction&= quot; document. I think things can be summarised a bit more to convey the m= ain points.

* There is lots of stuff in brackets, which looks like it might be too= important to be ignored, so perhaps it's not all suitable to be in bracket= s?
* It's good to define the intended audience:
   Thi=
s document is an introduction to the entire LISP system, for those
   who are unfamiliar with it.


Abstract:

   LIS=
P is an upgrade to the architecture of the IPvN internetworking
   system, one which separates location and identity (currently
   intermingled in IPvN addresses).

* I would be inclined to say "IPv4 and IPv6 internetwork", I= think that, while technically correct, IPvN is a less often used term. Or = at least I don't see it being used often. You could also just say "IP&= quot;. I'd also drop the 'system', as I think an internetwork is a system already?
* What do you mean with 'currently intermingled in IPvN addresses'? Do= you mean that location and identity are currently both expressed in IP add= resses when using LISP? Or do you mean that in the current IP world, both l= ocation and identity is expressed with 1 IP address? I guess the latter, but I don't think it's particularly= clear.

*  Thi=
s is a change which has been
   identified by the IRTF as a critically necessary evolutionary
   architectural step for the Internet.

=3D> If this was wikipedia or an academic paper, I'd tag that with = "citation needed".


1. Prefaratory Note
* Spello: "prefatory" is suggested by Google.
* Re 'Architectural Introduction' =3D> see high level items above

* It is intended to both be easy to f= ollow, and also to give
   the=
 reader a choice as to how much they wish to know about LISP.
   Reading only the first part(s) of the document will give a good high-
   level view of the system; reading the complete document should
   provide a fairly detailed understanding of the entire system.

=3D> Being easy to follow is good. I think it's also fine to provid= e a good high-level overview of the system in the first parts of the docume= nt. I don't think it's necessary to provide a very detailed understanding o= f the entire system as part of the introduction though, I think this is outside the scope of an introduction - after all, = that's what all the other documents are there for, and I think a huge intro= will just scare people off.

   Thi=
s goal explains why the document has a somewhat unusual structure.
   It is not a reference document, where all the content on a particular
   topic is grouped in one place.  (That role is filled by the various
   protocol specifications.)  It starts with a very high-level view of
   the entire system, to provide readers with a mental framework to help
   understand the more detailed material which follows.  A second pass
   over the whole system then goes into more detail; finally, individual
   sub-systems are covered in still deeper detail.

* Sounds like there's way too much detail for an introduction, and I'm= not sure it's necessary to cover one component thing three times in an int= roduction.

* I'm not sure an unusual structure helps understanding. Have you give= n this to someone new to LISP and asked them how much they understood? I tr= ied that when I attempted to formulate a "LISP in 5 sentences" de= scription (sample size of 1). The result was that the experiment worked, but my 5 sentences didn't.

   Not=
e: This document is a descriptive document, not a protocol
   specification.  Should it differ in any detail from any of the LISP
   protocol specification documents, they take precedence for the actual
   operation of the protocol.

* Excellent.

2. Background

* See high-level comment, I think the aim should be to provide "j= ust enough"

* Now, having said that, I'm not sure that the "just enough"= aim is actually fulfilled. I think that, apart from the first paragraph, t= he background section doesn't actually further the understanding of the doc= ument, as the bits in it are not necessary to understand LISP. You don't need to know when it was formed, how the his= tory influenced it or when it became an RFC. I'd put those details into a '= history' appendix. [Todo: come back to this after I've finished reading the= document and see what else would need to be added beyond the first paragraph]

*   It=
 has gradually been realized in the networking community that
   networks (especially large networks) should deal quite separately
   with the identity and location of a node (basically, 'who' a node is,
   and 'where' it is).  At the moment, in both IPv4 and IPv6, addresses
   indicate both where the named device is, as well as identify it for
   purposes of end-end communication.

* Ok, this can be accepted as fact. I think however that it would be m= ore useful to briefly introduce the location/id split by looking at an exam= ple:

Today, network nodes (routers, hosts, etc) = typically have one or more IP addresses assigned to them. These IP addresse= s encode two bits of information: the location of a node, namely /which network/ the node is on, as well as a "host identifier". = For example, the IP address 192.168.3.14, together with the subnet mask 255= .255.255.0, refers to "host 14" on the network "192.168.3.0/= 24".

Of course there are many other ways to express location, and I guess t= his is just one example, but I think it's quite accessible (to pretty much = anyone who's configured a static IP address). I hope it's correct enough an= d demonstrates some aspects of location and identity. If not, maybe we should find another example.

*   Th=
e distinction was more than a little hazy at first: the early
   Internet [RFC791], like the ARPANET before it [Heart] [NIC8246], co-
   mingled the two, although there was recognition in the early Internet
   work that there were two different things going on.  [IEN19]

=3D> I'd file this in the "LISP in the context of the history = of the internet" (LicothoI) category, which I think is best docum= ented in it's own draft. I'd summarise it in one sentence saying something = like "The location/identity separation is not a newly discovered concept, it was recognised already in the early days of the int= ernet [citation]", but at the moment I'm not sure where to best put it= .

*  This likely resulted not just= from lack of insight, but also the fact
   tha=
t extra mechanism is needed to support this separation (and in the
   early days there were no resources to spare), as well as the lack of
   need for it in the smaller networks of the time.  (It is a truism of
   system design that small systems can get away with doing two things
   with one mechanism, in a way that usually will not work when the
   system gets much larger.)

=3D> "LicothoI"
=3D> Can be replaced with a one-sentence summary
=3D> I don't think that the truism adds any value, and thus can be = removed.

*   Th=
e ISO protocol architecture took steps in this direction [NSAP],
   but to the Internet community the necessity of a clear separation was
   definitively shown by Saltzer.  [RFC1498] Later work expanded on
   Saltzer's, and tied his separation concepts into the fate-sharing
   concepts of Clark.  [Clark], [Chiappa]

=3D> Licothol

*   Th=
e separation of location and identity is a step which has recently
   been identified by the IRTF as a critically necessary evolutionary
   architectural step for the Internet.  However, it has taken some time
   for this requirement to be generally accepted by the Internet
   engineering community at large, although it seems that this may
   finally be happening.  [RFC6115]

Please could you point out exactly which bit of RFC6115 supports the a= bove statement, especially the first sentence? Maybe I missed it. (I'm not = commenting on whether or not I agree with the statement, after all I'm not = part of the IRTF anyway, just on the reference)

*   Th=
e LISP system for separation of location and identity resulted from
   the discussions of this topic at the Amsterdam IAB Routing and
   Addressing Workshop, which took place in October 2006.  [RFC4984]


   A s=
mall group of like-minded personnel from various scattered
   locations within Cisco, spontaneously formed immediately after that
   workshop, to work on an idea that came out of informal discussions at
   the workshop.  The first Internet-Draft on LISP appeared in January,
   2007, along with a LISP mailing list at the IETF.  [LISP0]


   Tri=
al implementations started at that time, with initial trial
   deployments underway since June 2007; the results of early experience
   have been fed back into the design in a continuous, ongoing process
   over several years.
I think the above is useful background info, even in an intro, but bel= ongs into a 'history' section, maybe in the appendix.

* LISP=
 at this point represents a moderately
   mature system, having undergone a long organic series of changes and
   updates.

I think this statement would require regular updating as LISP matures,= so I'm not sure it's suitable for a static RFC.



*   LI=
SP transitioned from an IRTF activity to an IETF WG in March 2009,
   and after numerous revisions, the basic specifications moved to
   becoming RFCs in 2012 (although work to expand and improve it
   continues, and undoubtly will for a long time to come).
Perhaps slightly less useful background info, but probably OK for a hi= story section.

* I think the History section should go into an appendix. We want to m= ake it as easy as possible for newbies to pick up and understand LISP, and = having less text between them and LISP means newbies are less likely to loo= se interest.

3. Deployment Philosophy

   It =
may seem odd to cover 'deployment philosophy' at this point in
   such a document.  However the deployment philosophy was a major
   driver for much of the design (to some degree the architecture, and
   to a very large measure, the engineering).  So, as such an important
   motivator, it is very desirable for readers to have this material in
   hand as they examine the design, so that design choices that may seem
   questionable at first glance can be better understood.

=3D> I think this paragraph doesn't add much value. It's 7 lines ex= plaining why the next 8 lines are there=85

   Exp=
erience over the last several decades has shown that having a
   viable 'deployment model' for a new design is absolutely key to the
   success of that design.  A new design may be fantastic - but if it
   can not or will not be successfully deployed (for whatever factors),
   it is useless.  This absolute primacy of a viable deployment model is
   what has lead to some painful compromises in the design.

This further motivates why we should care about a successful deploymen= t model

   The=
 extreme focus on a viable deployment scheme is one of the
   novelties of LISP.

So that sentence there the real content of this whole section? Conside= ring the fact that there are more sections dealing with deployment, I think= some merging and cutting needs to happen.. I'm thinking about 3.1-3.3., and 8. Design Approach (though I'll have more comments on those later). I think i= t's fine to say something like, "Given that the ease of deployment gre= atly influences the adoption of new technologies, one of the design goals o= f LISP stated that it should support incremental deployments, which provide benefits to the users from day one&= quot;, or something along those lines. I think that would sufficiently summ= arise the whole section here, including 3.1.( Economics). I think sections = 3.2 and 3.3 can similarly be summarised in one paragraph:

N.N Design Philosophy [this is just a sketc= h of the argument I'm trying to make, not a final wording suggestion]
=85
Another important design goal of LISP state= d that it should be easily deployable. This was motivated by the pragmatic = insight that this would be key to widespread adoption. This was realised in= three ways. Firstly, the cost of implementing LISP should be low in terms of complexity and number of nodes= that need changing, and secondly the benefit in terms of added value (in t= he form of services or features) should be high. Furthermore, LISP should s= upport and interoperate with and support existing protocols (e.g. IPv4, IPv6, TCP and UDP), and transition = mechanisms should be provided.

I'd cut the section "3.3.  'Self-Deployment'"; I unders= tand that a snowball effect is very desirable, but I'm not sure it furthers= any argument at this point in time.




8.  Design Approach


   Before describing LISP's components in more detail below, it it worth
   pointing out that what may seem, in some cases, like odd (or poor)
   design approaches do in fact result from the application of a
   thought-through, and consistent, design philosophy used in creating
   them.

   This design philosophy is covered in detail in in [Perspective],
   Section "Design"), and readers who are interested in the 'why'=
 of
   various mechanisms should consult that; reading it may make clearer
   the reasons for some engineering choices in the mechanisms given
   here.

=3D> This whole section is basically useless. It's only piece of re= al content is the reference to [Perspective].

To be continued=85

Best regards!

Michiel
--_000_4ABB752A36221949A095CDE2C6DBB1C8084E4B4Dxmbalnx12ciscoc_-- From jnc@mercury.lcs.mit.edu Tue Jul 23 15:46:44 2013 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 6E0E011E816D for ; Tue, 23 Jul 2013 15:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcBJb7lu-mv3 for ; Tue, 23 Jul 2013 15:46:39 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5004711E8150 for ; Tue, 23 Jul 2013 15:46:39 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6783818C137; Tue, 23 Jul 2013 18:46:38 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130723224638.6783818C137@mercury.lcs.mit.edu> Date: Tue, 23 Jul 2013 18:46:38 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Intro final content questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 22:46:44 -0000 > From: Luigi Iannone Hi, thanks for the feedback! > Should we include anything about the request of an EID prefix? Sorry, I'm not sure I understood that? Do you mean 'getting a prefix allocated from some authority'? If so, I suppose I could put in a sentence or two about it, but it's not really something I'd want to cover in any detail in this document. > What if we give a slightly larger scope to this section? Including LISP > alternative use cases. In this section ("Current Improvements") I'm more trying to focus on coming changes in the _protocol itself_, not on new things people are doing with it. (If you think about it, a binding layer of this sort is going to be used in all sorts of ways - including some that are rather ugly hacks! What people call Lampson's Law [it's actually Wheeler's, IIRC] - "all problems in computer science can be solved with another layer of indirection" - pretty much guarantees that. Look at the tricks people play with ARP, for example. And given that LISP, unlike ARP, has names with global scope on _both_ sides of the mapping, that increases its power, and thus the things it will be used for...) So I think 'listing all the nifty things we can do with LISP' is really out of scope for this document - I listed what I thought would be the most important ones in the "Initial Applications" section just to give people an idea of what good it was. (If there is some major application I should be listing there that I haven't, please let me know.) > LISP is being used (or at least is studied) to be used in scenarios for > which it has not been designed originally. Of course! See Wheeler's Law... :-) (And also my aphorism about 'the sign of great architecture'... :-) > Which, BTW includes mobility since it has never been in the charter. A few protocol tweaks were added for mobility (e.g. proxy Map-Replying), which is why I wanted to mention that one specifically. > I am thinking at LISP in the context of data centers (NVO3 drafts), or > as multimedia traffic optimisation (check the TCMTF Bof next week). If any of these a) need protocol changes, and b) those changes are likely to happen, they would be candidates. Alas, I haven't had time to read them yet - can someone fill me in on whether they involve LISP protocol changes? Noel From farinacci@gmail.com Tue Jul 23 16:15:46 2013 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 ACED611E8176 for ; Tue, 23 Jul 2013 16:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87fjrMMjgrWU for ; Tue, 23 Jul 2013 16:15:46 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 15F2C11E8163 for ; Tue, 23 Jul 2013 16:15:45 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so9021337pbc.37 for ; Tue, 23 Jul 2013 16:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Ddh00xBm78uRF9IeMGZHMhlMxVY+qFf19vwMZcVmzWQ=; b=CWriS4QDDU/81981WIIJo6XjGKXRi8ZKVpFq3reVsExiINYpc8Sk5mS3HMtYyGZmD+ 7w0VgUhmO/ijjPLCWev1QmSFpyOYSQufMvkTYntAkLFqLGkwJwlUgEzKSlX5FqR6/I8w JV3R27e2U41oXfKj8OXecn9ZLzu5AduUSvW2EYWX+dCYdkv3fVZu6mymcmHF4/mPU4Mt +XDy2BdaHhRXFOIOD0dWF3rUs0LGX+Q1dC1IpDDK8QQlt0ti+CcZI1xEtdQAUtNCN/Am IwIWWaQMiBB21+h6mYrBokPIv6mpJJ/Aa+kExbAonC6G57KV66xRF8WhB4bq7Qkt58zS LPrg== X-Received: by 10.68.217.137 with SMTP id oy9mr39018328pbc.130.1374621345701; Tue, 23 Jul 2013 16:15:45 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id ss8sm28296120pab.6.2013.07.23.16.15.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 16:15:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <20130723224638.6783818C137@mercury.lcs.mit.edu> Date: Tue, 23 Jul 2013 16:15:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82C06053-8EF4-454A-84D5-76CDE4ECAC95@gmail.com> References: <20130723224638.6783818C137@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1508) Cc: lisp@ietf.org Subject: Re: [lisp] Intro final content questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 23:15:46 -0000 > So I think 'listing all the nifty things we can do with LISP' is = really out > of scope for this document - I listed what I thought would be the most > important ones in the "Initial Applications" section just to give = people an > idea of what good it was. (If there is some major application I should = be > listing there that I haven't, please let me know.) I tend to agree. We want the intro spec to be short, to the point, so = people can get the concept with a single read through the document. We can always write more documents for the various use-cases that come = up. Dino From jnc@mercury.lcs.mit.edu Tue Jul 23 18:21:59 2013 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 15A7A11E81AD for ; Tue, 23 Jul 2013 18:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb1etPf52fOG for ; Tue, 23 Jul 2013 18:21:53 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 575C311E81A6 for ; Tue, 23 Jul 2013 18:21:47 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 81EA718C145; Tue, 23 Jul 2013 21:21:44 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130724012144.81EA718C145@mercury.lcs.mit.edu> Date: Tue, 23 Jul 2013 21:21:44 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 01:21:59 -0000 > From: "Michiel Blokzijl (mblokzij)" > I had at the time less than a handful of days to learn about LISP > ... and I still remember that it was.. let's say, "surprisingly > difficult". And, I think that we as the LISP community can do better (at > the time I hadn't read the lisp introduction draft). Had you had this document available, would that have significantly improved the situation? > I understand that comments to this draft are time-critical Appreciated... > Despite me only having covered those, I see that my email is rapidly > approaching the limits Well, doing it in chunks will also keep the the reply size, etc down, so good call on several fronts to go ahead as-is. > please don't take my criticism personally, it's about the working group > document, not about you. None taken. In return, please understand that I won't always agree with you - although I will think carefully about your comments, and indicate _why_ I don't agree, if I don't. (Anything I don't comment on, assume I agree with.) > I think this document is confused. It doesn't really know if it's an > architecture document, or an introductory text, or an introduction to > the architecture document. Perhaps it would make things a little clearer if I explained that this document is what used to be the first half of the 'LISP architecture document'. (the other part now being the 'Architectural Perspective' document). It got too long, so I chopped it in two along what I hoped was a reasonable boundary. As to the content of this one: to me, an architecture document has to _start_ by giving the reader a clear understanding of what the main pieces of the system are, what they do, and how they interact. Oddly enough, the same is true (IMO) of an Introduction. So, since I had to cover that ground _anyway_... > I think that an architecture document and an introductory document serve > different audiences and purposes, even though there may be some overlap > in topics. Which is why I chopped where I did: the 'Architectural Perspective' document covers the stuff that's more 'architectury' (e.g. more about the properties of the various abstract namespaces), and the stuff that could serve two purposes (an introductory document, and the architecture overview part of an architecture document) wound up in this one. > the main purpose of the introduction is to provide the reader an > overview of LISP and familiarise him/her with the main concepts, > emphasising understanding, perhaps even over technical precision. Exactly; that's what the specs are for. > We should avoid having two very similar texts. I can't imagine we'd ever with an 'Introduction to LISP', with this document in existence - it would be 92% the same, and, as you impute, a waste of energy. > ** I think the title "Architectural Introduction" adds to the confusion > here, and I think it would be better to just call this document > "Introduction to LISP", and aim for providing exactly that. The names ("Architectural Introduction" and "Architectural Perspective") were to indicate that they were two parts of a pairing. I'm not totally stuck on the "Architectural Introduction", though, and if the WG would prefer to call it just plain "Introduction to LISP", that would be OK with me. But there is, I think, a good reason to retain the longer one - to tie the two together. > I think there's a lot of background material. I think we should aim for > "just enough" to understand the introduction to LISP, rather than a > comprehensive study of "LISP in the context of the history of the internet" You're behind the curve! (See message from this morning, "Intro final content questions".) That's getting moved to an appendix, so we can get straight to the meat of LISP. > it looks like a VERY LONG introduction (37 pages if you print the HTML > page). I think introductions should be a bit shorter, and less > daunting. My first impression (with my LISP newbie hat on) is "Oh my > goodness, I need to read all that just to get an idea about LISP?". I don't know how to fix that, except to make three documents (i.e. split this one up), and I don't see any good/natural dividing line to do so. > I know that the prefatory note says otherwise, but you don't see that > when you open up the HTML page and give it a quick scroll through. I don't know how I could make it more prominent? > The design approach comes surprisingly late into the text (I'm not sure > this is even the right document for that) My thinking in putting it there was that it's just before we get to the 'detailed look at LISP operations' content - and it's only when you get to that content that you really need it. Actually, it used to be a much longer section, almost all of which I moved to the other document to keep the size down on this one, and because it's not absolutely necessary to have it here. > Here are some sections I don't think are necessary for the introduction > ... mostly because they sound like they're going into the nitty gritty > detail that should be part of main protocol specs: There are no packet formats, no detailed algorithms - just coverage, at a _high level_, of more stuff than just the brief descriptions in section 6. > 4.4. Interworking With Non-LISP-Capable Endpoints (maybe) That's a critical thing about LISP - that it _can_ interoperate usefully with non-LISP sites. 3 short paragraphs is appropriate to talk about that. 4.5. Security in LISP [or at least move it closer to the end] I think saying something about security in LISP is important in a "LISP Overview". That section was just written, so it probably can use some polishing, but again, 4 short paragraphs don't sound like an inappropriate treatment. (The section in the 'Perspectives' document which talks at more length about LISP's security philosophy, and more about how it applies in various places, takes up ~30 paragraphs - and it's not fully written.) 9.2. UDP Encapsulation Details ("details") Again, 4 paragraphs. No formats, no specs, just a short, high-level discussion of how it works. (Maybe you should have read these before creating this list?) > I'm not saying none of these should be mentioned, but I don't think each > of them warrant a section of their own in an "introduction" document. I > think things can be summarised a bit more to convey the main points. Look, if you want a 10-page 'Brief Introduction' document, one which differs significantly from Sections 3-6, since it's intended that people who want a brief introduction can read just those, and stop), please feel free to write it. I'm producing an "Architectural Introduction", and I feel the modest level of detail in all those sections you mention is needed. Most of them are really short - a couple of short paragraphs, almost all of them. And the content in all of them is very high-level. The number of them is because that's how it's all organized in my brain - broken down like that. I'm trying to convey that understanding on paper. > There is lots of stuff in brackets, which looks like it might be too > important to be ignored, so perhaps it's not all suitable to be in > brackets? That's always been an artifact of my writing style. Everything in my brain is connected to everything else, and those parenthetical asides are how I attempt to convey those connections... If you have specific suggestions on how to re-word some, I will take a look at them. > I would be inclined to say "IPv4 and IPv6 internetwork", I think that, > while technically correct, IPvN is a less often used term. ... You could > also just say "IP". Given that the abstract is _already_ too long, the former isn't really in the cards. But "IP" works for me. > I'd also drop the * 'system', as I think an internetwork is a system > already? You may understand that, but I'm not sure everyone does... :-) Hmmm... if I drop it, it feels stilted (unless I re-word, and then it's even longer). > What do you mean with 'currently intermingled in IPvN addresses'? Do > you mean that location and identity are currently both expressed in IP > addresses when using LISP? Or do you mean that in the current IP world, > both location and identity is expressed with 1 IP address? I guess the > latter, but I don't think it's particularly clear. I have changed "currently" to "previously" - that should make clear that that statement doesn't refer to LISP. > If this was wikipedia or an academic paper, I'd tag that with "citation > needed". It's the _abstract_. No cites in most abstracts... :-) > Spello: "prefatory" is suggested by Google. And I should care what Google thinks...? But I admit "prefaratory" is a bit old-fashioned, so we'll go with "prefatory". > I don't think it's necessary to provide a very detailed understanding of > the entire system as part of the introduction though You're confused. The 'details' here aren't that detailed. Try reading, e.g. section 9.6, "Security of Mapping Lookups". That covers most of a 20-page spec in three, count them, three paragraphs. If you think that's "detailed", you have a very strange definition of "detailed". > after all, that's what all the other documents are there for See above. Speaking of "other documents", here's an exercise for you. List all the documents which have a significant amount of content which is covered here. My list looks like this: RFC 6830 - The Locator/ID Separation Protocol (LISP) RFC 6831 - The Locator/ID Separation Protocol (LISP) for Multicast Environments RFC 6832 - Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites RFC 6833 - Locator/ID Separation Protocol (LISP) Map-Server Interface RFC 6834 - Locator/ID Separation Protocol (LISP) Map-Versioning ID.draft-ermagan-lisp-nat-traversal ID.draft-ietf-lisp-ddt ID.draft-ietf-lisp-deployment ID.draft-ietf-lisp-sec ID.draft-meyer-lisp-mn ID.draft-saucez-lisp-impact-01 [Iannone] [Kim] [CorasCache] [Jakab] [Saucez] Now, add up the lengths of all those documents. Next, what %-age of that is this document? My guess is that it's about 6%, at most. So instead of people having to read hundreds upon hundreds of pages to get a moderately detailed understanding of LISP (although admittedly if they read them all, they'd have an extremely detailed understanding of LISP), they have to read 30-odd. (Less than that if they only want a brief intro, in which case they can stop at Section 7, as discussed in the preface.) I think that's not bad. > I think a huge intro will just scare people off. Again, if you think there's some use/benefit for a 'Brief Introduction to LISP' (briefer than only reading down through section 6 - maybe 7, if they want to see some simple examples), please write one. > I'm not sure an unusual structure helps understanding. In a Deep Purple live recording ("Made in Japan", if anyone cares), there is a classic line: "Can I have everything louder than everything else." (He's talking about the monitors on the stage.) Similarly, I would _like_ to 'talk about everything before everything else'. But I can't. So I have two choices. 1. I can pick a piece, and talk about it first, in great detail, before I talk about anything else. (This is what protocol specs usually do.) To me, at least, that is unlikely to lead quickly to a good overall grasp of what the systems major functional units are, what they do, and how they interact. (Which is, after all, what I said I'd like to see in an architecture document.) How can the reader understand well the interaction with some other subsystem, when they haven't read anything at all about that subsystem yet? 2. Describe the entire system _very briefly_ at a very high level; then, when I next talk about some piece in a little more detail, the reader has a mental framework/model of the 'big picture' into which they can slot the details of that particular piece. Repeat. Given those two choices, I went with 2. > Have you given this to someone new to LISP and asked them how much they > understood? A while ago. Not with recent versions. > I think that, apart from the first paragraph, the background section > doesn't actually further the understanding of the document, as the bits > in it are not necessary to understand LISP. Which is why I had previously decided to exile most of it to an Appendix (see reference to previous message, above). > I think however that it would be more useful to briefly introduce the > location/id split by looking at an example: In general, I personally hate examples, but I guess for most people they ar useful, so I will add one when I refactor that section and exile most of it. > Please could you point out exactly which bit of RFC6115 supports the > above statement, especially the first sentence? Maybe I missed it. It's in Section "1.2. Areas of Group Consensus", point 9: "The Research Group has rough consensus that separating identity from location is desirable and technically feasible." Do I need to go to that level of detail in the cite? IETF RFC's generally don't do page number citations. > I think this statement would require regular updating as LISP matures, > so I'm not sure it's suitable for a static RFC. I actually am very sympathetic to the 'long lifetime' goal for documents like this, and I have tried to attain that with this one (and that's why e.g. there are no packet formats here). But I'm not sure this particular statement is problematic: it says LISP is "a moderately mature system" - from where it can only go forward, not backward, right? So it can only become "very mature", and I don't see that as that big a difference. And put against that the value of the point I wish to make: that LISP is not a paper exercise, but something with real experience behind it. (Although that may be a less critical point to make now than it was, say, 2 years ago.) > I think the History section should go into an appendix. We want to make > it as easy as possible for newbies to pick up and understand LISP, and > having less text between them and LISP means newbies are less likely to > loose interest. Couldn't agree more, etc, etc. > I think this paragraph doesn't add much value. > It's 7 lines explaining why the next 8 lines are there Exactly. I'm trying to explain to the average reader WTF a document called "Introduction to LISP" _starts_ by talking about "Deployment Philosophy". Which might seem like a bizarre, nay, dumb, choice, to the average reader. I'm trying to show them why it's there, to give them some sense that the writer is not hopelessly confused. > So that sentence there the real content of this whole section? There are some very major IETF failures^H^H^H^Hefforts that didn't appear to have considered that important. Which is a good part of why I wanted to say it so forcefully. > Considering the fact that there are more sections dealing with > deployment, I think some merging and cutting needs to happen.. I'm thinking > about 3.1-3.3., and 8. Design Approach Maybe you should have read section 8 first? There's almost nothing there, just a reference to the other document. And I've already explained why 8's down there, not further up. (If I moved it up, it would be in the way of getting to the initial description of LISP. That would not be good, right?) > I think it's fine to say something like ... > ... [this is just a sketch of the argument I'm trying to make, not a > final wording suggestion] I'll have to ponder this when I'm fresher. Perhaps I can improve that section some. > I'd cut the section "3.3. 'Self-Deployment'"; I understand that a > snowball effect is very desirable, but I'm not sure it furthers any > argument at this point in time. Again, a number of other major IETF design efforts have clearly missed this point, so I think it's worth stating it. > This whole section is basically useless. It's only piece of real content > is the reference to [Perspective]. I'll see if I can trim it a bit more. I don't think it's appropriate to just say 'The design philosophy is covered in detail in in [Perspective], Section "Design".' Noel From jnc@mercury.lcs.mit.edu Wed Jul 24 05:24:52 2013 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 E308911E8210 for ; Wed, 24 Jul 2013 05:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxK1Ayf+nmb7 for ; Wed, 24 Jul 2013 05:24:47 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id D1F6411E819E for ; Wed, 24 Jul 2013 05:24:47 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 68B4118C147; Wed, 24 Jul 2013 08:24:44 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130724122444.68B4118C147@mercury.lcs.mit.edu> Date: Wed, 24 Jul 2013 08:24:44 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 12:24:53 -0000 > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) >> it looks like a VERY LONG introduction (37 pages if you print the HTML >> page). I think introductions should be a bit shorter, and less >> daunting. My first impression (with my LISP newbie hat on) is "Oh my >> goodness, I need to read all that just to get an idea about LISP?". >> I know that the prefatory note says otherwise, but you don't see that >> when you open up the HTML page and give it a quick scroll through. > I don't know how I could make it more prominent? Now that I think about it, the way to hopefully help (I'm not sure I'd say 'fix totally' - you can't make _anything_ perfectly fool-proof) is to add one sentence to the end of the abstract, saying as concisely as possible that a subset of the document, readable as a separate unit, forms a 'brief intoduction to LISP', and is considerably shorter than the document as a whole. Of course, this will make the abstract one sentence longer, and it's _already_ long. But I see a not-very-necessary sentence I can delete, to avoid making it even longer. All, does this sound like a good thing to do? Noel From mblokzij@cisco.com Wed Jul 24 05:49:24 2013 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 6AD0211E80F0 for ; Wed, 24 Jul 2013 05:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljHk6lB8vVRM for ; Wed, 24 Jul 2013 05:49:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E79D811E80E0 for ; Wed, 24 Jul 2013 05:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19498; q=dns/txt; s=iport; t=1374670158; x=1375879758; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=7I49vNPRecJ13m4LdiLNwqKmGW2qNMBJIu9R8SNzgRM=; b=nDooRAJPBjG0tDthH5ZBp57wBNRgb7pDcRbYLVfk1hBZVEZYMHGSdk1l wq9uFvM626FrgXAX/bw7Zwy7DAqCEw7xRd5lUztCJ/8MMz6EgRbGkCDQq CDbe4rQdrzrcW/EDebMyqnNLcXoOAXZu18QotYT6pWper2Ciul9cfeKSP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFbM71GtJXG//2dsb2JhbABSAwYOgniBBcEBgRUWdIIkAQEBAwE6OhcBCA4EAw0UQhcOAgQBEAIIDAeHbwa5J45CFXI4gxJuA6ksglY+QIFq X-IronPort-AV: E=Sophos;i="4.89,735,1367971200"; d="scan'208";a="238745219" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jul 2013 12:49:15 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6OCnFYL024825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 12:49:15 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.26]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 07:49:14 -0500 From: "Michiel Blokzijl (mblokzij)" To: Noel Chiappa , "lisp@ietf.org" Thread-Topic: [lisp] Comments on draft-ietf-lisp-introduction-01 Thread-Index: AQHOiAwoJnfowMmVZEGf14El+n6AW5l0LOSA Date: Wed, 24 Jul 2013 12:49:14 +0000 Message-ID: <4ABB752A36221949A095CDE2C6DBB1C8084E7042@xmb-aln-x12.cisco.com> In-Reply-To: <20130724012144.81EA718C145@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [64.103.80.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <077F9E901E4D1241AFFB29DC465CDB80@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 12:49:24 -0000 Hi Noel, First of all, thank you for taking the time to read through my long set of comments! Reading your reply, I think that we just have very different expectations of the introduction document. I'll finish going through your draft since I've started it now. Here are some of the main points I picked up from your reply: - document split & titles, extending the abstract, sections 3-6, potential derived/new 'brief introduction to LISP' =3D> I'll get back to this when I've gone through those sections - the [necessary] level of detail: I think the document currently provides a reasonably comprehensive but high-level overview of LISP, rather than an introduction, if that makes sense. I'll get back to this too. I'll add some more comments inline ([M]), but I think it's best if I finish going through the document before we get into too many detailed discussions :-) Best regards, Michiel On 24/07/2013 02:21, "Noel Chiappa" wrote: > > From: "Michiel Blokzijl (mblokzij)" > > > I had at the time less than a handful of days to learn about LISP > > ... and I still remember that it was.. let's say, "surprisingly > > difficult". And, I think that we as the LISP community can do >better (at > > the time I hadn't read the lisp introduction draft). > >Had you had this document available, would that have significantly >improved >the situation? > > > I understand that comments to this draft are time-critical > >Appreciated... > > > Despite me only having covered those, I see that my email is rapidly > > approaching the limits > >Well, doing it in chunks will also keep the the reply size, etc down, so >good call on several fronts to go ahead as-is. > > > please don't take my criticism personally, it's about the working >group > > document, not about you. > >None taken. > >In return, please understand that I won't always agree with you - >although I >will think carefully about your comments, and indicate _why_ I don't >agree, if >I don't. (Anything I don't comment on, assume I agree with.) [M]: sounds good, thanks! > > > > I think this document is confused. It doesn't really know if it's an > > architecture document, or an introductory text, or an introduction >to > > the architecture document. > >Perhaps it would make things a little clearer if I explained that this >document is what used to be the first half of the 'LISP architecture >document'. (the other part now being the 'Architectural Perspective' >document). It got too long, so I chopped it in two along what I hoped >was a >reasonable boundary. > >As to the content of this one: to me, an architecture document has to >_start_ >by giving the reader a clear understanding of what the main pieces of the >system are, what they do, and how they interact. Oddly enough, the same is >true (IMO) of an Introduction. So, since I had to cover that ground >_anyway_... > > > I think that an architecture document and an introductory document >serve > > different audiences and purposes, even though there may be some >overlap > > in topics. > >Which is why I chopped where I did: the 'Architectural Perspective' >document >covers the stuff that's more 'architectury' (e.g. more about the >properties of >the various abstract namespaces), and the stuff that could serve two >purposes >(an introductory document, and the architecture overview part of an >architecture document) wound up in this one. > > > the main purpose of the introduction is to provide the reader an > > overview of LISP and familiarise him/her with the main concepts, > > emphasising understanding, perhaps even over technical precision. > >Exactly; that's what the specs are for. > > > We should avoid having two very similar texts. > >I can't imagine we'd ever with an 'Introduction to LISP', with this >document >in existence - it would be 92% the same, and, as you impute, a waste of >energy. > > > > ** I think the title "Architectural Introduction" adds to the >confusion > > here, and I think it would be better to just call this document > > "Introduction to LISP", and aim for providing exactly that. > >The names ("Architectural Introduction" and "Architectural Perspective") >were >to indicate that they were two parts of a pairing. I'm not totally stuck >on >the "Architectural Introduction", though, and if the WG would prefer to >call >it just plain "Introduction to LISP", that would be OK with me. But there >is, >I think, a good reason to retain the longer one - to tie the two together. > > > I think there's a lot of background material. I think we should aim >for > > "just enough" to understand the introduction to LISP, rather than a > > comprehensive study of "LISP in the context of the history of the >internet" > >You're behind the curve! (See message from this morning, "Intro final >content >questions".) That's getting moved to an appendix, so we can get straight >to >the meat of LISP. [M] Sorry about that! I'm glad you came to the same conclusion. > > > > it looks like a VERY LONG introduction (37 pages if you print the >HTML > > page). I think introductions should be a bit shorter, and less > > daunting. My first impression (with my LISP newbie hat on) is "Oh my > > goodness, I need to read all that just to get an idea about LISP?". > >I don't know how to fix that, except to make three documents (i.e. split >this >one up), and I don't see any good/natural dividing line to do so. > > > I know that the prefatory note says otherwise, but you don't see >that > > when you open up the HTML page and give it a quick scroll through. > >I don't know how I could make it more prominent? [M] By having a shorter document.. :) > > > > The design approach comes surprisingly late into the text (I'm not >sure > > this is even the right document for that) > >My thinking in putting it there was that it's just before we get to the >'detailed look at LISP operations' content - and it's only when you get to >that content that you really need it. [M] I see. > >Actually, it used to be a much longer section, almost all of which I >moved to >the other document to keep the size down on this one, and because it's not >absolutely necessary to have it here. [M] Ok. I think as it stands it doesn't actually add much, but let's discuss that later. > > > > Here are some sections I don't think are necessary for the >introduction > > ... mostly because they sound like they're going into the nitty >gritty > > detail that should be part of main protocol specs: > >There are no packet formats, no detailed algorithms - just coverage, at a >_high level_, of more stuff than just the brief descriptions in section 6. > > > 4.4. Interworking With Non-LISP-Capable Endpoints (maybe) > >That's a critical thing about LISP - that it _can_ interoperate usefully >with >non-LISP sites. 3 short paragraphs is appropriate to talk about that. > > 4.5. Security in LISP [or at least move it closer to the end] > >I think saying something about security in LISP is important in a "LISP >Overview". That section was just written, so it probably can use some >polishing, but again, 4 short paragraphs don't sound like an inappropriate >treatment. (The section in the 'Perspectives' document which talks at more >length about LISP's security philosophy, and more about how it applies in >various places, takes up ~30 paragraphs - and it's not fully written.) > > 9.2. UDP Encapsulation Details ("details") > >Again, 4 paragraphs. No formats, no specs, just a short, high-level >discussion >of how it works. (Maybe you should have read these before creating this >list?) > > > > I'm not saying none of these should be mentioned, but I don't think >each > > of them warrant a section of their own in an "introduction" >document. I > > think things can be summarised a bit more to convey the main points. > >Look, if you want a 10-page 'Brief Introduction' document, one which >differs >significantly from Sections 3-6, since it's intended that people who want >a >brief introduction can read just those, and stop), please feel free to >write >it. > >I'm producing an "Architectural Introduction", and I feel the modest >level of >detail in all those sections you mention is needed. Most of them are >really >short - a couple of short paragraphs, almost all of them. And the content >in >all of them is very high-level. The number of them is because that's how >it's >all organized in my brain - broken down like that. I'm trying to convey >that >understanding on paper. > > > > There is lots of stuff in brackets, which looks like it might be too > > important to be ignored, so perhaps it's not all suitable to be in > > brackets? > >That's always been an artifact of my writing style. Everything in my >brain is >connected to everything else, and those parenthetical asides are how I >attempt >to convey those connections... If you have specific suggestions on how to >re-word some, I will take a look at them. > > > > I would be inclined to say "IPv4 and IPv6 internetwork", I think >that, > > while technically correct, IPvN is a less often used term. ... You >could > > also just say "IP". > >Given that the abstract is _already_ too long, the former isn't really in >the >cards. But "IP" works for me. > > > I'd also drop the * 'system', as I think an internetwork is a system > > already? > >You may understand that, but I'm not sure everyone does... :-) Hmmm... if >I >drop it, it feels stilted (unless I re-word, and then it's even longer). > > > What do you mean with 'currently intermingled in IPvN addresses'? >Do > > you mean that location and identity are currently both expressed in >IP > > addresses when using LISP? Or do you mean that in the current IP >world, > > both location and identity is expressed with 1 IP address? I guess >the > > latter, but I don't think it's particularly clear. > >I have changed "currently" to "previously" - that should make clear that >that >statement doesn't refer to LISP. > > > If this was wikipedia or an academic paper, I'd tag that with >"citation > > needed". > >It's the _abstract_. No cites in most abstracts... :-) > > > Spello: "prefatory" is suggested by Google. > >And I should care what Google thinks...? But I admit "prefaratory" is a >bit >old-fashioned, so we'll go with "prefatory". > > > > I don't think it's necessary to provide a very detailed >understanding of > > the entire system as part of the introduction though > >You're confused. The 'details' here aren't that detailed. Try reading, >e.g. section 9.6, "Security of Mapping Lookups". That covers most of a >20-page >spec in three, count them, three paragraphs. > >If you think that's "detailed", you have a very strange definition of >"detailed". > > > after all, that's what all the other documents are there for > >See above. > >Speaking of "other documents", here's an exercise for you. > >List all the documents which have a significant amount of content which is >covered here. My list looks like this: > > RFC 6830 - The Locator/ID Separation Protocol (LISP) > RFC 6831 - The Locator/ID Separation Protocol (LISP) for Multicast >Environments > RFC 6832 - Interworking between Locator/ID Separation Protocol (LISP) >and Non-LISP Sites > RFC 6833 - Locator/ID Separation Protocol (LISP) Map-Server Interface > RFC 6834 - Locator/ID Separation Protocol (LISP) Map-Versioning > ID.draft-ermagan-lisp-nat-traversal > ID.draft-ietf-lisp-ddt > ID.draft-ietf-lisp-deployment > ID.draft-ietf-lisp-sec > ID.draft-meyer-lisp-mn > ID.draft-saucez-lisp-impact-01 > [Iannone] > [Kim] > [CorasCache] > [Jakab] > [Saucez] > >Now, add up the lengths of all those documents. Next, what %-age of that >is >this document? My guess is that it's about 6%, at most. So instead of >people >having to read hundreds upon hundreds of pages to get a moderately >detailed >understanding of LISP (although admittedly if they read them all, they'd >have >an extremely detailed understanding of LISP), they have to read 30-odd. >(Less >than that if they only want a brief intro, in which case they can stop at >Section 7, as discussed in the preface.) I think that's not bad. > > > I think a huge intro will just scare people off. > >Again, if you think there's some use/benefit for a 'Brief Introduction to >LISP' (briefer than only reading down through section 6 - maybe 7, if they >want to see some simple examples), please write one. > > > > I'm not sure an unusual structure helps understanding. > >In a Deep Purple live recording ("Made in Japan", if anyone cares), there >is a >classic line: "Can I have everything louder than everything else." (He's >talking about the monitors on the stage.) Similarly, I would _like_ to >'talk >about everything before everything else'. But I can't. So I have two >choices. > >1. I can pick a piece, and talk about it first, in great detail, before I >talk >about anything else. (This is what protocol specs usually do.) To me, at >least, that is unlikely to lead quickly to a good overall grasp of what >the >systems major functional units are, what they do, and how they >interact. (Which is, after all, what I said I'd like to see in an >architecture >document.) How can the reader understand well the interaction with some >other >subsystem, when they haven't read anything at all about that subsystem >yet? > >2. Describe the entire system _very briefly_ at a very high level; then, >when >I next talk about some piece in a little more detail, the reader has a >mental >framework/model of the 'big picture' into which they can slot the details >of >that particular piece. Repeat. > >Given those two choices, I went with 2. [M] I don't think there's anything fundamentally wrong with approach 2, assuming you don't recurse ad inifinitum. However, I >=20 > > > Have you given this to someone new to LISP and asked them how much >they > > understood? > >A while ago. Not with recent versions. [M] Now you've made us all curious, what did they say? :) > > > > I think that, apart from the first paragraph, the background section > > doesn't actually further the understanding of the document, as the >bits > > in it are not necessary to understand LISP. > >Which is why I had previously decided to exile most of it to an Appendix >(see >reference to previous message, above). > > > I think however that it would be more useful to briefly introduce >the > > location/id split by looking at an example: > >In general, I personally hate examples, but I guess for most people they >ar >useful, so I will add one when I refactor that section and exile most of >it. > > > Please could you point out exactly which bit of RFC6115 supports the > > above statement, especially the first sentence? Maybe I missed it. > >It's in Section "1.2. Areas of Group Consensus", point 9: > > "The Research Group has rough consensus that separating identity > from location is desirable and technically feasible." > >Do I need to go to that level of detail in the cite? IETF RFC's generally >don't do page number citations. [M] Ok, that's fine, thanks for clarifying this! > > > I think this statement would require regular updating as LISP >matures, > > so I'm not sure it's suitable for a static RFC. > >I actually am very sympathetic to the 'long lifetime' goal for documents >like >this, and I have tried to attain that with this one (and that's why e.g. >there >are no packet formats here). > >But I'm not sure this particular statement is problematic: it says LISP >is "a >moderately mature system" - from where it can only go forward, not >backward, >right? So it can only become "very mature", and I don't see that as that >big a >difference. [M] I wouldn't say that the statement is 'problematic'. Maybe it's worth tying this statement to "the time of writing", and say it's constantly maturing - just to avoid people in the future dismissing LISP as a solution to a problem requiring a "mature" solution. > >And put against that the value of the point I wish to make: that LISP is >not a >paper exercise, but something with real experience behind it. (Although >that >may be a less critical point to make now than it was, say, 2 years ago.) > [M] It's a good point. > > > I think the History section should go into an appendix. We want to >make > > it as easy as possible for newbies to pick up and understand LISP, >and > > having less text between them and LISP means newbies are less >likely to > > loose interest. > >Couldn't agree more, etc, etc. > > > I think this paragraph doesn't add much value. > > It's 7 lines explaining why the next 8 lines are there > >Exactly. > >I'm trying to explain to the average reader WTF a document called >"Introduction to LISP" _starts_ by talking about "Deployment Philosophy". >Which might seem like a bizarre, nay, dumb, choice, to the average >reader. I'm >trying to show them why it's there, to give them some sense that the >writer is >not hopelessly confused. [M] I understand.. But when you start having more justifying text than actual content you start to wonder whether it might be easier to just "say it"? :) > > > So that sentence there the real content of this whole section? > >There are some very major IETF failures^H^H^H^Hefforts that didn't appear >to >have considered that important. Which is a good part of why I wanted to >say it >so forcefully. > > > Considering the fact that there are more sections dealing with > > deployment, I think some merging and cutting needs to happen.. I'm >thinking > > about 3.1-3.3., and 8. Design Approach > >Maybe you should have read section 8 first? There's almost nothing there, >just >a reference to the other document. > >And I've already explained why 8's down there, not further up. (If I >moved it >up, it would be in the way of getting to the initial description of LISP. >That >would not be good, right?) > > > > I think it's fine to say something like ... > > ... [this is just a sketch of the argument I'm trying to make, not a > > final wording suggestion] > >I'll have to ponder this when I'm fresher. Perhaps I can improve that >section >some. > > > I'd cut the section "3.3. 'Self-Deployment'"; I understand that a > > snowball effect is very desirable, but I'm not sure it furthers any > > argument at this point in time. > >Again, a number of other major IETF design efforts have clearly missed >this >point, so I think it's worth stating it. > > > This whole section is basically useless. It's only piece of real >content > > is the reference to [Perspective]. > >I'll see if I can trim it a bit more. I don't think it's appropriate to >just >say 'The design philosophy is covered in detail in in [Perspective], >Section >"Design".' > > Noel From jnc@mercury.lcs.mit.edu Wed Jul 24 06:51:42 2013 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 6294111E80AE for ; Wed, 24 Jul 2013 06:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBQBf+lXg-o1 for ; Wed, 24 Jul 2013 06:51:37 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E7CA211E8104 for ; Wed, 24 Jul 2013 06:51:36 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 119B118C151; Wed, 24 Jul 2013 09:51:13 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130724135113.119B118C151@mercury.lcs.mit.edu> Date: Wed, 24 Jul 2013 09:51:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 13:51:42 -0000 > From: "Michiel Blokzijl (mblokzij)" > Reading your reply, I think that we just have very different > expectations of the introduction document. Perhaps.. :-) > I think the document currently provides a reasonably comprehensive but > high-level overview of LISP, rather than an introduction, if that makes > sense. That's a very good point: it _is_ as much an overview as it is an introduction. (It's also the second, because it specifically caters to readers who know nothing of LISP to start with.) Should we rename it to "Architectural Overview", to better describe it? I'd be OK with that. Although, since it is written as an introduction (i.e. a first document to read), it's probably most accurate to call it an "Introductory Overview"! :-) Although that's kind of clunky. I'm basically happy with any of the three: it's up to the WG which to pick: "Introduction", "Overview", "Introductory Overview". (But I'm not changing the file name! That is something of a PITA, as I learned from the Perspective document... :-) >> I don't know how I could make it more prominent? > By having a shorter document.. :) Did you have any opinion about the idea of a one-sentence addition to the abstract (see previous WG list email)? > I don't think there's anything fundamentally wrong with approach 2, > assuming you don't recurse ad inifinitum. However, I I think we lost some text here? >>> Have you given this to someone new to LISP and asked them how much >>> they understood? >> A while ago. Not with recent versions. > Now you've made us all curious, what did they say? :) I honestly don't recall - it's been over a year. But I'll try the exercise again (I have a test subject in mind :-), and see what they say. > Maybe it's worth tying this statement to "the time of writing", and say > it's constantly maturing - just to avoid people in the future dismissing > LISP as a solution to a problem requiring a "mature" solution. Well, it does currently say "at this point", which I assumed was basically synonomous with "time of writing", but I think your overall concern is viable, let me see if I can tweak the text there to meet that potential issue. > But when you start having more justifying text than actual content you > start to wonder whether it might be easier to just "say it"? :) Your point about the ratio of text lengths is a good one. Let me look at that, and see if I can shorten the first part. Noel From farinacci@gmail.com Wed Jul 24 09:51:30 2013 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 E9A3E11E8258 for ; Wed, 24 Jul 2013 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE-x3QlV8lKg for ; Wed, 24 Jul 2013 09:51:29 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8620811E8246 for ; Wed, 24 Jul 2013 09:51:10 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so597835pdi.11 for ; Wed, 24 Jul 2013 09:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fIxlG+mQccL7uiigVoN6ptu6sPzQqH6TrcjRcqKSVqw=; b=Rv5pKDlJvNu2LDCSTJ8I43Rre4TNb2KR9ASG+mfKaFe+5dC+H2+5mqYnXC9Z9on7B4 Yncuk5avEDBtLsc2hRQsSt4+2hUv9htH7oWpfNWM8mezjIx/EhHy5D7qm0qsqYA7nDZt 7Hnp6xU9TumjxbSO+bz3I9MBNGVz0mUUapAWi2OBByZYGpRts9JlTBf5NfFhvxsLxvTm Ha1aacLjj2YjLfeBlxIa5Qu+XsNsSCpHwn55D/B/XaHxZlMelUQCqsHMZT3vn9jSiO5Q AVTleC/7nha88xre8mQxOrNj0q4KdP0u7Jn/Ad2tZ0T/za8PBvOroxD2vBSa7JF1TU5U TQaA== X-Received: by 10.68.247.226 with SMTP id yh2mr42789540pbc.164.1374684670230; Wed, 24 Jul 2013 09:51:10 -0700 (PDT) Received: from [192.168.1.62] ([207.145.253.66]) by mx.google.com with ESMTPSA id iq6sm48950884pbc.1.2013.07.24.09.51.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 09:51:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <20130724012144.81EA718C145@mercury.lcs.mit.edu> Date: Wed, 24 Jul 2013 09:51:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <45096266-2FB0-4343-85CB-C58A7AC61AD2@gmail.com> References: <20130724012144.81EA718C145@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1508) Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 16:51:30 -0000 > The names ("Architectural Introduction" and "Architectural = Perspective") were > to indicate that they were two parts of a pairing. I'm not totally = stuck on > the "Architectural Introduction", though, and if the WG would prefer = to call > it just plain "Introduction to LISP", that would be OK with me. But = there is, > I think, a good reason to retain the longer one - to tie the two = together. I would vote for "Introduction to LISP". But if that is decided, the = document needs to be brief, to the point, and reference other documents = (the RFCs and the Architecture Perspective document). But all in all, I have always been in favor of less documents. Because = once you start with details, it is easy to go real deep and that is what = the protocol documents are for. Dino From jmh@joelhalpern.com Wed Jul 24 12:09:23 2013 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 3CB6111E8132 for ; Wed, 24 Jul 2013 12:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zrt+v1EY0E9M for ; Wed, 24 Jul 2013 12:09:11 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB7F11E812C for ; Wed, 24 Jul 2013 12:09:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 244A21D89C0; Wed, 24 Jul 2013 12:09:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45F881D89B3; Wed, 24 Jul 2013 12:09:09 -0700 (PDT) Message-ID: <51F02653.6050207@joelhalpern.com> Date: Wed, 24 Jul 2013 15:09:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Iannone References: <20130723133923.E231718C0E5@mercury.lcs.mit.edu> <3D4BB6CD-FB80-4C4F-B1E7-8AB13BC70B16@gigix.net> In-Reply-To: <3D4BB6CD-FB80-4C4F-B1E7-8AB13BC70B16@gigix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Intro final content questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 19:09:23 -0000 As far as I can tell, this allocation request document is dead in the water. Yours, Joel On 7/23/13 5:19 PM, Luigi Iannone wrote: ... > > Should we include anything about the request of an EID prefix? ... From jnc@mercury.lcs.mit.edu Wed Jul 24 12:12:44 2013 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 262FD11E8132 for ; Wed, 24 Jul 2013 12:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.224 X-Spam-Level: X-Spam-Status: No, score=-5.224 tagged_above=-999 required=5 tests=[AWL=-1.375, BAYES_00=-2.599, FB_GET_MEDS=2.75, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY7dhG+I-bfp for ; Wed, 24 Jul 2013 12:12:39 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 47FA821F88DB for ; Wed, 24 Jul 2013 12:12:37 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D1E3E18C163; Wed, 24 Jul 2013 15:12:34 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130724191234.D1E3E18C163@mercury.lcs.mit.edu> Date: Wed, 24 Jul 2013 15:12:34 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 19:12:44 -0000 > From: Dino Farinacci > But if that is decided, the document needs to ... reference other > documents (the RFCs and the Architecture Perspective document). Huh? The document already _extensively_ references the other LISP documents (both RFCs and IDs), as appropriate: E.g. the "Indexing Sub-system" section references DDT, the "Mapping Versioning" section references RFC-6834; "Probing" refers to RFC-6830, Section 6.3.2. (the section call-out is because that's a large document); "Security of Mapping Lookups" references the LISP-SEC ID; a mention of MS's proxy replying is accompanied by a ref to the LISP-Mobility I-D; the section on "LISP and DFZ Routing" references the Deployment I-D; the section on "Improved NAT Support" references the NAT I-D; etc, etc. And of course all the places that discuss the results in academic papers (e.g. sections on the performance of the mapping cache, DDT, etc) contain references to those papers too. So maybe there are some places where a reference can profitably be added. But to act like the document _doesn't_ _already_ _copiously_ reference other documents is just... way past confusing. > Because once you start with details, it is easy to go real deep and > that is what the protocol documents are for. Huh? Once again I am left utterly lost. I keep hearing this 'too much detail' mantra, but I am really starting to be irritated by it, because I cannot see how it relates to the actual document. Here are some more randomly picked examples, in addition to the LISP-SEC example I already mentioned (3 _short_ paragraphs, in "Security of Mapping Lookups", to cover 20 pages of the LISP-SEC I-D): in "Improved NAT Support", the contents of the NAT I-D (another 20-page document) are covered in 5 short paragraphs; in "Mapping Cache Performance", the caching performance work from [Ianonne], a fairly dense 12-page paper, gets 3 medium-sized paragraphs; in "Mapping Versioning", 20-page RFC-6834 in 4 paragraphs. Etc, etc, etc. How on Earth is a couple of paragraphs to succintly cover the main concepts in a 20-page document 'too much detail'? I don't believe it can be boiled down much more than that, and have a useful level of comprehension remaining. (In addition to which the Intro I-D has _not_ _one_ packet format in it, not one detailed algorithm, etc, etc.) If you could point out a couple of places where the Intro document has 'too much detail', that would be useful. Noel From farinacci@gmail.com Wed Jul 24 12:27:30 2013 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 615A611E8255 for ; Wed, 24 Jul 2013 12:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_GET_MEDS=2.75] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE1j9ho1wXUw for ; Wed, 24 Jul 2013 12:27:28 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8523811E812A for ; Wed, 24 Jul 2013 12:27:27 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq8so1626067pbb.19 for ; Wed, 24 Jul 2013 12:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=qKquySDP1T/dweOXYRIskDHNArkTlwpBRZeJ29C1u/E=; b=WnnUdmP40pTG9+6IbfAJX8ZwctrswUirmL/aa+q+3Xwa4kquv5CiKPFtLSfjluFlmM 0KQvJr640rhEFYlLz589rd6ohuuL8Wlv8OWykl+omjGLh6K5sIvhnLocAcB4CD7lJxZz UEP6SYi10JMQDxlWeQVCdtoK1iUWBvIW9xOuL5Na2dgKLc6K+vAt3mq+AGhlgIWIk/+m dAPRzUCh6BPA7dVkC6DygqXfVHLAIPNrtv41JikyGoudVHJVrmZaBsjjkZvAeDckSZvo AvmCJ44cuE867tOcAVH7AZ1pkZYJZlYGyhrJigv52V2SOX3zqJHMs68JkYLlPuqmsuG9 7ACQ== X-Received: by 10.66.162.102 with SMTP id xz6mr45901588pab.0.1374694047241; Wed, 24 Jul 2013 12:27:27 -0700 (PDT) Received: from [192.168.1.8] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id ep4sm49434229pbd.35.2013.07.24.12.27.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 12:27:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dino Farinacci In-Reply-To: <20130724191234.D1E3E18C163@mercury.lcs.mit.edu> Date: Wed, 24 Jul 2013 12:27:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85725099-4CA8-4F1B-83C0-7A3599870F41@gmail.com> References: <20130724191234.D1E3E18C163@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1508) Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 19:27:30 -0000 >> From: Dino Farinacci >=20 >> But if that is decided, the document needs to ... reference other >> documents (the RFCs and the Architecture Perspective document). >=20 > Huh? The document already _extensively_ references the other LISP = documents > (both RFCs and IDs), as appropriate: >=20 > E.g. the "Indexing Sub-system" section references DDT, the "Mapping > Versioning" section references RFC-6834; "Probing" refers to RFC-6830, > Section 6.3.2. (the section call-out is because that's a large = document); > "Security of Mapping Lookups" references the LISP-SEC ID; a mention of = MS's > proxy replying is accompanied by a ref to the LISP-Mobility I-D; the = section > on "LISP and DFZ Routing" references the Deployment I-D; the section = on > "Improved NAT Support" references the NAT I-D; etc, etc. Right, this is all goodness. Thanks. > And of course all the places that discuss the results in academic = papers > (e.g. sections on the performance of the mapping cache, DDT, etc) = contain > references to those papers too. >=20 > So maybe there are some places where a reference can profitably be = added. > But to act like the document _doesn't_ _already_ _copiously_ reference = other > documents is just... way past confusing. >=20 >=20 >> Because once you start with details, it is easy to go real deep and >> that is what the protocol documents are for. >=20 > Huh? Once again I am left utterly lost. I keep hearing this 'too much = detail' > mantra, but I am really starting to be irritated by it, because I = cannot see > how it relates to the actual document. No worries Noel. Many of us are currently reviewing the draft. We can = give detail comments. > Here are some more randomly picked examples, in addition to the = LISP-SEC > example I already mentioned (3 _short_ paragraphs, in "Security of = Mapping > Lookups", to cover 20 pages of the LISP-SEC I-D): in "Improved NAT = Support", > the contents of the NAT I-D (another 20-page document) are covered in = 5 short > paragraphs; in "Mapping Cache Performance", the caching performance = work from > [Ianonne], a fairly dense 12-page paper, gets 3 medium-sized = paragraphs; in > "Mapping Versioning", 20-page RFC-6834 in 4 paragraphs. Etc, etc, etc. Perfect. Thanks. > How on Earth is a couple of paragraphs to succintly cover the main = concepts > in a 20-page document 'too much detail'? I don't believe it can be = boiled > down much more than that, and have a useful level of comprehension = remaining. >=20 > (In addition to which the Intro I-D has _not_ _one_ packet format in = it, not > one detailed algorithm, etc, etc.) >=20 > If you could point out a couple of places where the Intro document has = 'too > much detail', that would be useful. Will do. Don't sweat it. Dino >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Wed Jul 24 13:14:58 2013 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 A095811E821A for ; Wed, 24 Jul 2013 13:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtRDQU7prKqD for ; Wed, 24 Jul 2013 13:14:52 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2834411E821B for ; Wed, 24 Jul 2013 13:14:51 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so858460wgh.29 for ; Wed, 24 Jul 2013 13:14:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=zeezHWRMi8HkQ6A6gYew3Dg9UAAfASA9F1M/WXNAjM8=; b=Evv6FYd0W393pjrSsQK6RV524ITmGXciSfukauroXY4OBZ1Womlk9X8UZTMNeTEIJK 7xJz/G1zWcv6SNUiARVFnFliNs11KaevjL7iw8tViscfBUsBeTfpfPNDNgoYHxd1QWzN IDM1etKLksWwTKDdr3Et+9v1Uc+OM7KWXSEDJ3Mz52ETmoiDCJSAmLYbw+jZR3Q5a43d o4MaAo7/pOwo+iREz9iqOrWXzk/Dc+oDZhKB9JN60x6m9WvOQOMF6Yx6OSDEO5UojvFw QsmTJdBxg43aMdqP8cHGrFa6f6ZwdigbTsLETr5DagkXDedoIAoQCFgU3k/nBxJ2sfDI qP0w== X-Received: by 10.194.123.69 with SMTP id ly5mr28175085wjb.29.1374696891177; Wed, 24 Jul 2013 13:14:51 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:6907:1d04:b942:5248? ([2a01:e35:1381:3430:6907:1d04:b942:5248]) by mx.google.com with ESMTPSA id fb2sm7771864wic.4.2013.07.24.13.14.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 13:14:50 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luigi Iannone In-Reply-To: <51F02653.6050207@joelhalpern.com> Date: Wed, 24 Jul 2013 22:14:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130723133923.E231718C0E5@mercury.lcs.mit.edu> <3D4BB6CD-FB80-4C4F-B1E7-8AB13BC70B16@gigix.net> <51F02653.6050207@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmmwnmahxOVqU55lYqpMsN6K9P8g+V8N2xIw+OXeBwy3mUqAKwClh+XDmO2jF3ttf/Z415z Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Intro final content questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 20:14:58 -0000 On 24 Jul. 2013, at 21:09 , Joel M. Halpern wrote: > As far as I can tell, this allocation request document is dead in the = water. May I dare to ask why? Agreed that no update has been submitted (actually because no WG meeting = will be held), but why stating that is dead? ciao Luigi > Yours, > Joel >=20 > On 7/23/13 5:19 PM, Luigi Iannone wrote: > ... >>=20 >> Should we include anything about the request of an EID prefix? > ... From ggx@gigix.net Wed Jul 24 13:16:03 2013 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 3906C11E8113 for ; Wed, 24 Jul 2013 13:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nlgmp3K7Unvd for ; Wed, 24 Jul 2013 13:15:59 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 490F011E825A for ; Wed, 24 Jul 2013 13:15:58 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so4766341wiv.2 for ; Wed, 24 Jul 2013 13:15:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=onDz6VVdBnp0W4oYmzn/BeTuiK04aeHs+PNl1RzT5CA=; b=R05bHGuREvXAhVraKDOcvtdpus0bzEgwo67VEs6Zb/M3nFF5zGaxsWyiSjG5QHftu4 /TIO/82s2AohcY+7DWCRWnjAZpfhyFTnJBaJ9kTejMJHUFFGJeVJTH1VUuEe0lck4F1H rPR5Bw/aHXamnQf97szW+YBG09uQQtiSLitd//poMlZNEoKHrFO7ral7ObIxMppYtszD CErXP4AABlOfdqi5Cd4mb0NxrCOj+CWGL08JW44wGoFk6ejOacRIMusRbS+v8Gd6STQ2 O2tH5YCdPt9ZhKNTRtM5G7RzKbCgr3fSu2ifZEb2GRAaSvuCIb4GF35I6cumH9Eq47Jm qdcA== X-Received: by 10.180.95.201 with SMTP id dm9mr3949778wib.21.1374696956198; Wed, 24 Jul 2013 13:15:56 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:6907:1d04:b942:5248? ([2a01:e35:1381:3430:6907:1d04:b942:5248]) by mx.google.com with ESMTPSA id s19sm7731225wik.11.2013.07.24.13.15.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 13:15:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luigi Iannone In-Reply-To: <82C06053-8EF4-454A-84D5-76CDE4ECAC95@gmail.com> Date: Wed, 24 Jul 2013 22:15:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130723224638.6783818C137@mercury.lcs.mit.edu> <82C06053-8EF4-454A-84D5-76CDE4ECAC95@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnPMttTfcSSdSAgloOjkB0EK8ICCYzm0PprGup5rIeBSVV2dZ3M+Itzl4TnwNnu9O5vx+De Cc: Noel Chiappa , lisp@ietf.org Subject: Re: [lisp] Intro final content questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 20:16:03 -0000 On 24 Jul. 2013, at 01:15 , Dino Farinacci wrote: >> So I think 'listing all the nifty things we can do with LISP' is = really out >> of scope for this document - I listed what I thought would be the = most >> important ones in the "Initial Applications" section just to give = people an >> idea of what good it was. (If there is some major application I = should be >> listing there that I haven't, please let me know.) >=20 > I tend to agree. We want the intro spec to be short, to the point, so = people can get the concept with a single read through the document. Yes, sound reasonable. >=20 > We can always write more documents for the various use-cases that come = up. >=20 True. Any volunteer? ;-) L. > Dino >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Wed Jul 24 13:18:42 2013 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 14FA611E8240 for ; Wed, 24 Jul 2013 13:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d-6K6Li+oX5 for ; Wed, 24 Jul 2013 13:18:35 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8389411E80D2 for ; Wed, 24 Jul 2013 13:18:35 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so839132wgh.13 for ; Wed, 24 Jul 2013 13:18:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=1WEAUMEBtvZzn17vZBIDoerIgVs9IsAIV/yF+dgudbI=; b=TszZKpbUoYcMGN4Hc/vNVY5ci8odww2tJtS/nJtsWKsBZZLbEZX+1J4NauLfwe74ww NMr369B0dAZQiGh9p8BeX32AClz1bE4572uZxoi009dFXpuc+UgeONrpyAVVDfCpdSEo bOYZLgTaTBLrcolk7TKsAH3ERQNKiVU7ZWzUGXJq/0508tTKYHyNLs4+kAwyK+p6jX8z 46qMKSXK76IVvDXmNuQdp0QF8yD28EyNLcOduIlIGkelOr6e1lEXWlQs+eRTTv6FiK2m CAchN84lZ1OykHrTmLQb5tnNHPOzrcbNg+d2zvXqpuXBmT1dq6GOXGUASVn/TR3FdoSw ZvyA== X-Received: by 10.194.249.231 with SMTP id yx7mr28491770wjc.13.1374697114640; Wed, 24 Jul 2013 13:18:34 -0700 (PDT) Received: from [192.168.0.43] (bny92-2-81-56-19-67.fbx.proxad.net. [81.56.19.67]) by mx.google.com with ESMTPSA id hb2sm288623wib.0.2013.07.24.13.18.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 13:18:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Luigi Iannone In-Reply-To: <20130723224638.6783818C137@mercury.lcs.mit.edu> Date: Wed, 24 Jul 2013 22:18:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34E97ADF-0EAA-4782-B930-392A0303AA67@gigix.net> References: <20130723224638.6783818C137@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQm4B1WF0rLDsUC/iY8Ei6VNuUUPT93OuARWFEdKCVBKQoyP7x1OeCKGD7ENJkFRMp5Fb47U Cc: lisp@ietf.org Subject: Re: [lisp] Intro final content questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 20:18:42 -0000 Hi Noel, thanks for the answer, I completely agree with your vision of the = document. Just a quick note: On 24 Jul. 2013, at 00:46 , Noel Chiappa = wrote: [snip] >> I am thinking at LISP in the context of data centers (NVO3 drafts), = or >> as multimedia traffic optimisation (check the TCMTF Bof next week). >=20 > If any of these a) need protocol changes, and b) those changes are = likely to > happen, they would be candidates. Alas, I haven't had time to read = them yet -=20 > can someone fill me in on whether they involve LISP protocol changes? >=20 AFAICT they do not need protocol changes, so it is not necessary to = cite them. ciao Luigi=20 > Noel From lakafosi@cisco.com Thu Jul 25 17:19:15 2013 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 853D021F8C8E for ; Thu, 25 Jul 2013 17:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.147 X-Spam-Level: X-Spam-Status: No, score=-10.147 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N24EhC3IPvsI for ; Thu, 25 Jul 2013 17:19:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BAB9921F8C93 for ; Thu, 25 Jul 2013 17:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11994; q=dns/txt; s=iport; t=1374797949; x=1376007549; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Pw29J/iaRsTQPZFwFFDo7p41+YegY8Jdz5dlFJyyhYs=; b=QUv0+QsvRQoviLM/AXSbTNhotveZ9PA4MiRVth++IpyhXSkgY6rnq+q9 xIkyclJ02562HmmmPZD/2dhdTAcrtksP4F9q7XdDUwhKj6zctJC2pGw5s vLNdx4kebTrHQ49yy2o6om30dDpBrTLgcKZPUGJB4zzY1kkk3A3RHIDH9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAEbA8VGtJV2Y/2dsb2JhbABaDoI0RIEFvWSBFBZ0giUBAQQnUhACAQgOFCQyJQIEDg0Th3W5FI4+gQ4xB4MSbgOpLIJWPoFxOQ X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208,217";a="239731236" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2013 00:19:09 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6Q0J9Pq012204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 00:19:09 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 19:19:08 -0500 From: "Vasileios Lakafosis (lakafosi)" To: Noel Chiappa Thread-Topic: [lisp] Comments on draft-ietf-lisp-introduction-01 Thread-Index: AQHOiZW+2UheUA0LQE2HlI2HF3OTPQ== Date: Fri, 26 Jul 2013 00:19:08 +0000 Message-ID: References: <7AE2F934-6F04-4C3D-AF38-27BDBC8450F5@cisco.com> In-Reply-To: <7AE2F934-6F04-4C3D-AF38-27BDBC8450F5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.164.178] Content-Type: multipart/alternative; boundary="_000_FDA71A56FB96334C81303986B527D6CA0506D87Bxmbalnx10ciscoc_" MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 00:19:15 -0000 --_000_FDA71A56FB96334C81303986B527D6CA0506D87Bxmbalnx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Noel, overall, I believe there have been significant improvements in this version= . Below please find a few comments of mine. General [whole document] - You tend to use the verb "switch" for xTRs. Is that correct/intended sens= u stricto? Lato sensu I can understand=85 - (you already have a question about this in the doc) You tend to use "bind= ing" and "mapping" interchangeably. Do you see any benefit in sticking with= just the second term perhaps? - please choose between "user interface" or "client interface". I would go = with the second one, as the first one can bring wrong associations to a tot= ally new-comer. [4.5] and [12.4] You do include solutions/contributions offered when describing a LISP featu= re and it's real nice (given you are skipping technical details because of = brevity of doc). This is _not_ the case, though, for sections: - [4.5] Security - [12.4] Liveness Here you only discuss the necessity, rather than what they at least offer o= r intend to offer. [5.7] What do you mean by "application-specific data"? [6.1] "now-normal" I would put this in double quotes. [6.2.3] This section should not be so much tied to DDT. It should be highlighted th= at _any_ database that meets the requirements could be used. And there are = plenty of examples. And this gives versatility to LISP. [6.2.3.1] 5th paragraph This seems wrong. The DDT leaf nodes _are_ MSs and, thus, do not "assign EI= D namespace blocks to MS's". [6.2.3.1] 2nd paragraph "necessarily smaller" Redundant as it cannot be larger anyways as only parts can be delegated to = children. [7.1] It would be helpful to add a paragraph about the reason of/benefits from th= e existence of the LISP header. [7.2] You could add "as previously explained in Section XX" [9.1] - 2nd paragraph: "normally" -> "natively" better? - 3rd paragraph: did you intend to say "despite the fact" or "although" ins= tead of "because"? [10.1.2] What about negative ones? [10.1.3] and elsewhere "and its AFI" Why keep mentioning AFIs? Doesn't it go without saying? [10.2] - 3rd paragraph: You may want to use "DDT nodes" everywhere (as in the draf= t) instead of the term "servers". Just a suggestion. - 6th paragraph: "{{I think this case has been mentioned already; check.}}"= yes, it has been. So, I would remove the next paragraph "Delegations are= =85" [13.2] The way 13.2 is written (with all these problems outlined and no solutions = provided) gives the impression to the new-comer that mobility does not work= in LISP today, which is absolutely wrong (either physically "LISP-MN" or i= n a DC environment). At least, this is how I felt when I read it. [13.4] " {{Any others?}}" Since these "improvements" sections are so short anyways, what about adding= a few words about LISP+SDN (LISP-enabled Openflow, opportunities in Openst= ack, [whole document] No need to introduce new paragraphs at: - [6.2.2] between second and third paragraph - [12.4] between 3rd and 4th paragraph [4.2] 1st paragraph no verb in the secondary "that" clause or confusing subject ("packets") if = "switches" is the verb [3.2] 3rd paragraph Discussed this with you in my previous email (related to version "00"). For brevity reasons, I would still remove: [3.1] " One might have the world=92s best =92clean-slate=92 design, but if = it does not have a deployment plan which is economically feasible, it=92s n= ot good for much." Structure-related comments [5.5] and [13.2] Mobility - Mobility (although indeed in different enough degree of instantiations) h= as been around since almost the early days of LISP itself. As such I wold r= emove it from improvements and move the [13.2] text into [5.5]. - No reference(s) provided in current [5.5] [6.1.1] - Shouldn't this section follow mapping [6.2]? And be a subsection of that = one? - 3rd paragraph -- Description of first effort seems too long (also compare= d to the rest ones). Feel free to drop out some details if possible. [9] first paragraph if [9.x] are "advanced topics" then it "automatically" makes them candidate= s for removal given the prior email discussion about keeping the _Intro_ do= cument short. But I believe [9.1], [9.8], a few details in [9.2] are indeed= (fundamental) helpful to be included in this document. Just pointing out i= n case you were looking to somehow cut down the size of the document. [10] 1st paragraph Here you refer to only "indexing subsystem" and the "mappings" although you= mentioned _3_ subsections above [in 6.2.1]. [11.2] Shouldn't [11.3], [11.4], [11.5] and [11.6] be subsections of [11.2]? Thanks, Vasileios --_000_FDA71A56FB96334C81303986B527D6CA0506D87Bxmbalnx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9619E8A9470137429AFED2B0925D9E35@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Noel,
overall, I believe there have been significant improvements in this version= . 
Below please find a few comments of mine.

General

[whole document] 
- You tend to use the verb "switch" for xTRs. Is t= hat correct/intended sensu stricto? Lato sensu I can understand=85
- (you already have a question about this in the doc) You tend to use = "binding" and "mapping" interchangeably. Do you see any= benefit in sticking with just the second term perhaps?
- please choose between "user interface" or "client int= erface". I would go with the second one, as the first one can bring wr= ong associations to a totally new-comer.

[4.5] and [12.4] 
You do include solutions/contributions offered when describing a LISP = feature and it's real nice (given you are skipping technical details becaus= e of brevity of doc). This is _not_ the case, though, for sections:
- [4.5] Security
- [12.4] Liveness
Here you only discuss the necessity, rather than what they at least of= fer or intend to offer.

[5.7]
What do you mean by "application-specific data"?

[6.1] "now-normal"
I would put this in double quotes.

[6.2.3]
This section should not be so much tied to DDT. It should be highlight= ed that _any_ database that meets the requirements could be used. And there= are plenty of examples. And this gives versatility to LISP.

[6.2.3.1] 5th paragraph
This seems wrong. The DDT leaf nodes _are_ MSs and, thus, do not = "assign EID namespace blocks to MS's".

[6.2.3.1] 2nd paragraph "necessarily smaller"
Redundant as it cannot be larger anyways as only parts can be delegate= d to children.

[7.1]
It would be helpful to add a paragraph about the reason of/benefits fr= om the existence of the LISP header.

[7.2]
You could add "as previously explained in Section XX" <= /div>

[9.1] 
- 2nd paragraph: "normally" -> "natively" = better?
- 3rd paragraph: did you intend to say "despite the fact" or= "although" instead of "because"?

[10.1.2]
What about negative ones?

[10.1.3] and elsewhere "and its AFI"
Why keep mentioning AFIs? Doesn't it go without saying?

[10.2] 
- 3rd paragraph: You may want to use "DDT nodes" everyw= here (as in the draft) instead of the term "servers". Just a sugg= estion.
- 6th paragraph: "{{I think this case has been mentioned alr= eady; check.}}" yes, it has been. So, I would remove the next paragrap= h "Delegations are=85"

[13.2]
The way 13.2 is written (with all these problems outlined and no solut= ions provided) gives the impression to the new-comer that mobility does not= work in LISP today, which is absolutely wrong (either physically &quo= t;LISP-MN" or in a DC environment). At least, this is how I felt when I read it.

[13.4] " {{Any others?}}"
Since these "improvements" sections are so short anyways, wh= at about adding a few words about LISP+SDN (LISP-enabled Openflow, oppo= rtunities in Openstack,

[whole document] 
No need to introduce new paragraphs at:
- [6.2.2] between second and third paragraph
- [12.4] between 3rd and 4th paragraph

[4.2] 1st paragraph
no verb in the secondary "that" clause or confusing subject = ("packets") if "switches" is the verb

[3.2] 3rd paragraph
Discussed this with you in my previous email (related to version "= ;00").

For brevity reasons, I would still remove:
[3.1] " One might have the world=92s best =92clean-slate=92&= nbsp;design, but if it does not have a deployment plan which is econom= ically feasible, it=92s not good for much."


Structure-related comments

[5.5] and [13.2] Mobility
- Mobility (although indeed in different enough degree of instant= iations) has been around since almost the early days of LISP itself. As suc= h I wold remove it from improvements and move the [13.2] text into [5.= 5]. 
- No reference(s) provided in current [5.5]

[6.1.1]
- Shouldn't this section follow mapping [6.2]? And be a subsection of = that one?
- 3rd paragraph -- Description of first effort seems too long (also co= mpared to the rest ones). Feel free to drop out some details if possible.

[9] first paragraph
if [9.x] are "advanced topics" then it "automatically&q= uot; makes them candidates for removal given the prior email discussion abo= ut keeping the _Intro_ document short. But I believe [9.1], [9.8], a few de= tails in [9.2] are indeed (fundamental) helpful to be included in this document. Just pointing out in case you were looking to s= omehow cut down the size of the document.

[10] 1st paragraph
Here you refer to only "indexing subsystem" and the "ma= ppings" although you mentioned _3_ subsections above [in 6.2.1]. =

[11.2]
Shouldn't [11.3], [11.4], [11.5] and [11.6] be subsections of [11.2]?<= /div>


Thanks,
Vasileios
--_000_FDA71A56FB96334C81303986B527D6CA0506D87Bxmbalnx10ciscoc_-- From lakafosi@cisco.com Thu Jul 25 17:01:27 2013 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 CB69421F8925 for ; Thu, 25 Jul 2013 17:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwYSGAbE5bYA for ; Thu, 25 Jul 2013 17:01:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C3A5321F84BB for ; Thu, 25 Jul 2013 17:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12036; q=dns/txt; s=iport; t=1374796882; x=1376006482; h=from:to:cc:subject:date:message-id:mime-version; bh=R4Yhif4lhXY6UYWKSPgiYB/Q5CG3Sbc6mroOM1IIJEk=; b=D9pQu63W6dyzn3C+7m8CdX1PN2iGpQEckTEdigBu5gw5qT5oeKvnjqhD V4d/Vwel+Q3JDbWLIIW32eZU7mvEINXEF2MftVeOv+R8xFesW5dSXp81A UiieiYiHAg05XLauAp4bNc1DkbBLaLGqn3SU9B1ZIviC3TzibG5tlzW4c Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFANe78VGtJXG8/2dsb2JhbABaDoI0RIEFvWSBFBZ0giYBBCdSEgEIDhRWJwQODROHdbkUjj6BDjGDGW4DqSyCVj6BcTk X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208,217";a="239630957" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jul 2013 00:01:20 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6Q01K42001086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 00:01:20 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 19:01:20 -0500 From: "Vasileios Lakafosis (lakafosi)" To: Noel Chiappa Thread-Topic: [lisp] Comments on draft-ietf-lisp-introduction-01 Thread-Index: AQHOiZNB2UheUA0LQE2HlI2HF3OTPQ== Date: Fri, 26 Jul 2013 00:01:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.164.178] Content-Type: multipart/alternative; boundary="_000_FDA71A56FB96334C81303986B527D6CA0506D6F2xmbalnx10ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 26 Jul 2013 08:24:06 -0700 Cc: "lisp@ietf.org" Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 00:02:51 -0000 --_000_FDA71A56FB96334C81303986B527D6CA0506D6F2xmbalnx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Noel, overall, I believe there have been significant improvements in this version= . Below please find a few comments of mine. General [whole document] - You tend to use the verb "switch" for xTRs. Is that correct/intended sens= u stricto? Lato sensu I can understand=85 - (you already have a question about this in the doc) You tend to use "bind= ing" and "mapping" interchangeably. Do you see any benefit in sticking with= just the second term perhaps? - please choose between "user interface" or "client interface". I would go = with the second one, as the first one can bring wrong associations to a tot= ally new-comer. [4.5] and [12.4] You do include solutions/contributions offered when describing a LISP featu= re and it's real nice (given you are skipping technical details because of = brevity of doc). This is _not_ the case, though, for sections: - [4.5] Security - [12.4] Liveness Here you only discuss the necessity, rather than what they at least offer o= r intend to offer. [5.7] What do you mean by "application-specific data"? [6.1] "now-normal" I would put this in double quotes. [6.2.3] This section should not be so much tied to DDT. It should be highlighted th= at _any_ database that meets the requirements could be used. And there are = plenty of examples. And this gives versatility to LISP. [6.2.3.1] 5th paragraph This seems wrong. The DDT leaf nodes _are_ MSs and, thus, do not "assign EI= D namespace blocks to MS's". [6.2.3.1] 2nd paragraph "necessarily smaller" Redundant as it cannot be larger anyways as only parts can be delegated to = children. [7.1] It would be helpful to add a paragraph about the reason of/benefits from th= e existence of the LISP header. [7.2] You could add "as previously explained in Section XX" [9.1] - 2nd paragraph: "normally" -> "natively" better? - 3rd paragraph: did you intend to say "despite the fact" or "although" ins= tead of "because"? [10.1.2] What about negative ones? [10.1.3] and elsewhere "and its AFI" Why keep mentioning AFIs? Doesn't it go without saying? [10.2] - 3rd paragraph: You may want to use "DDT nodes" everywhere (as in the draf= t) instead of the term "servers". Just a suggestion. - 6th paragraph: "{{I think this case has been mentioned already; check.}}"= yes, it has been. So, I would remove the next paragraph "Delegations are= =85" [13.2] The way 13.2 is written (with all these problems outlined and no solutions = provided) gives the impression to the new-comer that mobility does not work= in LISP today, which is absolutely wrong (either physically "LISP-MN" or i= n a DC environment). At least, this is how I felt when I read it. [13.4] " {{Any others?}}" Since these "improvements" sections are so short anyways, what about adding= a few words about LISP+SDN (LISP-enabled Openflow, opportunities in Openst= ack, [whole document] No need to introduce new paragraphs at: - [6.2.2] between second and third paragraph - [12.4] between 3rd and 4th paragraph [4.2] 1st paragraph no verb in the secondary "that" clause or confusing subject ("packets") if = "switches" is the verb [3.2] 3rd paragraph Discussed this with you in my previous email (related to version "00"). For brevity reasons, I would still remove: [3.1] " One might have the world=92s best =92clean-slate=92 design, but if = it does not have a deployment plan which is economically feasible, it=92s n= ot good for much." Structure-related comments [5.5] and [13.2] Mobility - Mobility (although indeed in different enough degree of instantiations) h= as been around since almost the early days of LISP itself. As such I wold r= emove it from improvements and move the [13.2] text into [5.5]. - No reference(s) provided in current [5.5] [6.1.1] - Shouldn't this section follow mapping [6.2]? And be a subsection of that = one? - 3rd paragraph -- Description of first effort seems too long (also compare= d to the rest ones). Feel free to drop out some details if possible. [9] first paragraph if [9.x] are "advanced topics" then it "automatically" makes them candidate= s for removal given the prior email discussion about keeping the _Intro_ do= cument short. But I believe [9.1], [9.8], a few details in [9.2] are indeed= (fundamental) helpful to be included in this document. Just pointing out i= n case you were looking to somehow cut down the size of the document. [10] 1st paragraph Here you refer to only "indexing subsystem" and the "mappings" although you= mentioned _3_ subsections above [in 6.2.1]. [11.2] Shouldn't [11.3], [11.4], [11.5] and [11.6] be subsections of [11.2]? Thanks, Vasileios --_000_FDA71A56FB96334C81303986B527D6CA0506D6F2xmbalnx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8F3CE4EF04C8C241AC1E0CE3097E7D21@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Noel,
overall, I believe there have been significant improvements in this version= . 
Below please find a few comments of mine.

General

[whole document] 
- You tend to use the verb "switch" for xTRs. Is t= hat correct/intended sensu stricto? Lato sensu I can understand=85
- (you already have a question about this in the doc) You tend to use = "binding" and "mapping" interchangeably. Do you see any= benefit in sticking with just the second term perhaps?
- please choose between "user interface" or "client int= erface". I would go with the second one, as the first one can bring wr= ong associations to a totally new-comer.

[4.5] and [12.4] 
You do include solutions/contributions offered when describing a LISP = feature and it's real nice (given you are skipping technical details becaus= e of brevity of doc). This is _not_ the case, though, for sections:
- [4.5] Security
- [12.4] Liveness
Here you only discuss the necessity, rather than what they at least of= fer or intend to offer.

[5.7]
What do you mean by "application-specific data"?

[6.1] "now-normal"
I would put this in double quotes.

[6.2.3]
This section should not be so much tied to DDT. It should be highlight= ed that _any_ database that meets the requirements could be used. And there= are plenty of examples. And this gives versatility to LISP.

[6.2.3.1] 5th paragraph
This seems wrong. The DDT leaf nodes _are_ MSs and, thus, do not = "assign EID namespace blocks to MS's".

[6.2.3.1] 2nd paragraph "necessarily smaller"
Redundant as it cannot be larger anyways as only parts can be delegate= d to children.

[7.1]
It would be helpful to add a paragraph about the reason of/benefits fr= om the existence of the LISP header.

[7.2]
You could add "as previously explained in Section XX" <= /div>

[9.1] 
- 2nd paragraph: "normally" -> "natively" = better?
- 3rd paragraph: did you intend to say "despite the fact" or= "although" instead of "because"?

[10.1.2]
What about negative ones?

[10.1.3] and elsewhere "and its AFI"
Why keep mentioning AFIs? Doesn't it go without saying?

[10.2] 
- 3rd paragraph: You may want to use "DDT nodes" everyw= here (as in the draft) instead of the term "servers". Just a sugg= estion.
- 6th paragraph: "{{I think this case has been mentioned alr= eady; check.}}" yes, it has been. So, I would remove the next paragrap= h "Delegations are=85"

[13.2]
The way 13.2 is written (with all these problems outlined and no solut= ions provided) gives the impression to the new-comer that mobility does not= work in LISP today, which is absolutely wrong (either physically &quo= t;LISP-MN" or in a DC environment). At least, this is how I felt when I read it.

[13.4] " {{Any others?}}"
Since these "improvements" sections are so short anyways, wh= at about adding a few words about LISP+SDN (LISP-enabled Openflow, oppo= rtunities in Openstack,

[whole document] 
No need to introduce new paragraphs at:
- [6.2.2] between second and third paragraph
- [12.4] between 3rd and 4th paragraph

[4.2] 1st paragraph
no verb in the secondary "that" clause or confusing subject = ("packets") if "switches" is the verb

[3.2] 3rd paragraph
Discussed this with you in my previous email (related to version "= ;00").

For brevity reasons, I would still remove:
[3.1] " One might have the world=92s best =92clean-slate=92&= nbsp;design, but if it does not have a deployment plan which is econom= ically feasible, it=92s not good for much."


Structure-related comments

[5.5] and [13.2] Mobility
- Mobility (although indeed in different enough degree of instant= iations) has been around since almost the early days of LISP itself. As suc= h I wold remove it from improvements and move the [13.2] text into [5.= 5]. 
- No reference(s) provided in current [5.5]

[6.1.1]
- Shouldn't this section follow mapping [6.2]? And be a subsection of = that one?
- 3rd paragraph -- Description of first effort seems too long (also co= mpared to the rest ones). Feel free to drop out some details if possible.

[9] first paragraph
if [9.x] are "advanced topics" then it "automatically&q= uot; makes them candidates for removal given the prior email discussion abo= ut keeping the _Intro_ document short. But I believe [9.1], [9.8], a few de= tails in [9.2] are indeed (fundamental) helpful to be included in this document. Just pointing out in case you were looking to s= omehow cut down the size of the document.

[10] 1st paragraph
Here you refer to only "indexing subsystem" and the "ma= ppings" although you mentioned _3_ subsections above [in 6.2.1]. =

[11.2]
Shouldn't [11.3], [11.4], [11.5] and [11.6] be subsections of [11.2]?<= /div>


Thanks,
Vasileios


--_000_FDA71A56FB96334C81303986B527D6CA0506D6F2xmbalnx10ciscoc_-- From jnc@mercury.lcs.mit.edu Fri Jul 26 13:35:56 2013 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 D2AB811E816E for ; Fri, 26 Jul 2013 13:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD88DuwXRQq0 for ; Fri, 26 Jul 2013 13:35:51 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id BC8DA11E8167 for ; Fri, 26 Jul 2013 13:35:51 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0A9AB18C12B; Fri, 26 Jul 2013 16:35:49 -0400 (EDT) To: lisp@ietf.org Message-Id: <20130726203549.0A9AB18C12B@mercury.lcs.mit.edu> Date: Fri, 26 Jul 2013 16:35:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-ietf-lisp-introduction-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 20:35:56 -0000 > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) > Now that I think about it, the way to hopefully help (I'm not sure I'd > say 'fix totally' ... ) is to add one sentence to the end of the > abstract, saying as concisely as possible that a subset of the > document, readable as a separate unit, forms a 'brief intoduction to > LISP', and is considerably shorter than the document as a whole. > ... > All, does this sound like a good thing to do? Not having heard any disagreement, I will do this. (I'm not sure it will make Michiel totally happy, but if the abstract clearly says the document includes a stand-alone brief intro, there's not much more I can do if people ignore that.. :-) Noel