From internet-drafts@ietf.org Mon Oct 1 15:20:08 2012 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 D10F11F0D3F; Mon, 1 Oct 2012 15:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBIxEdP6SqTe; Mon, 1 Oct 2012 15:20:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B6D1F0D08; Mon, 1 Oct 2012 15:20:07 -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.34 Message-ID: <20121001222007.549.5184.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2012 15:20:07 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-mib-06.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, 01 Oct 2012 22:20:09 -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 MIB Author(s) : Gregg Schudel Amit Jain Victor Moreno Filename : draft-ietf-lisp-mib-06.txt Pages : 65 Date : 2012-10-01 Abstract: This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From terry.manderson@icann.org Mon Oct 1 22:22:11 2012 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 3CEED21F8B6B for ; Mon, 1 Oct 2012 22:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGAFlD811edr for ; Mon, 1 Oct 2012 22:22:10 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7B59B21F8B6A for ; Mon, 1 Oct 2012 22:22:10 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 1 Oct 2012 22:22:09 -0700 From: Terry Manderson To: LISP mailing list list Date: Mon, 1 Oct 2012 22:22:07 -0700 Thread-Topic: Important dates for IETF 85 Thread-Index: Ac2gXd1eUWcrL9M2/U2jY3gHbYFRyg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3432036127_5290080" MIME-Version: 1.0 Subject: [lisp] Important dates for IETF 85 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 Oct 2012 05:22:11 -0000 --B_3432036127_5290080 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi there WG, Firstly, some important dates you should be aware of: 2012-10-08 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. 2012-10-12 (Friday): Final agenda to be published. 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool. 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission Tool. 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool. 2012-10-26 (Friday): Early Bird registration and payment cut-off at UTC 24:00. 2012-10-29 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool. 2012-10-29 (Monday): Registration cancellation cut-off at UTC 24:00. 2012-11-02 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local meeting time. Secondly, while this is NOT a call for agenda items yet - please start to consider your drafts and their current status. Cheers Terry --B_3432036127_5290080 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU/vPylqjgniOh0MmJvfzzvia6FmUwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDAyMDUyMjA3WjANBgkqhkiG 9w0BAQEFAASCAQAx4B2J8vTVoDfBi8Xgmf0YW05qoObum1i/4hglpAr4i58N7fm2EUvEA1b4 g8CaXrxyk41AGlQ7djb79iIJczuMk5IPQke2kniTbuZGxEGMeWz01/ljBaJSM9I0elUPzfGa b45QdlJ8AMXV3fG/sAWCbjnNBL3re3pwlKA8ry+bxQ71Ebz5my3tl7tS55Egnu+161qFLXmh 94SDSQWSYV0rrxMP8xRm7zWYtc+bvV/V2EcqVvCQfUBQrBzI6/dIve0Ht78p70idYa55IVMU /iYEe5sHy85uakpQc34ccs9jOpYg9LTcUxxyvDIef0WZOouYEmEwl3H8TdeclsVUQ/bF --B_3432036127_5290080-- From jmh@joelhalpern.com Tue Oct 2 12:07:07 2012 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 EE25E21F855B for ; Tue, 2 Oct 2012 12:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.088 X-Spam-Level: X-Spam-Status: No, score=-102.088 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g21UhGUpElzN for ; Tue, 2 Oct 2012 12:07:06 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2C321F8527 for ; Tue, 2 Oct 2012 12:07:06 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id DE513A58BE for ; Tue, 2 Oct 2012 12:07:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D989CC064D for ; Tue, 2 Oct 2012 12:07:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-10.clppva.btas.verizon.net [71.161.51.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2438CC0650 for ; Tue, 2 Oct 2012 12:07:02 -0700 (PDT) Message-ID: <506B3B53.1050008@joelhalpern.com> Date: Tue, 02 Oct 2012 15:06:59 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "lisp@ietf.org" References: <20121002181316.GA81712@vaf-mac1.cisco.com> In-Reply-To: <20121002181316.GA81712@vaf-mac1.cisco.com> X-Forwarded-Message-Id: <20121002181316.GA81712@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 19:07:07 -0000 The draft below addresses a chartered work item for the working group. Is the working group interested in adopting this draft as the starting point towards our milestone "Submit an lternate mapping system design"? For clarity, as this was much discussed recently on the wg-chairs list, if the WG agrees to adopt this, the authors will resubmit this draft under the appropriate new name (draft-ietf-lisp-ddt would seem likely.) At that point, it will be a working group draft, and the authors will work with the working group on all changes. Adoption mans the WG thinks this is a good starting point to work from. it does not mean that the WG agrees with all content. The WG is likely to make changes after adoption. Please respod clearly and promptly. The discussion period is two weeks, after which te chairs will determine if there is support for and agreement to adopt this document as a WG document. Yours, Joel M. Halpern PS: Let me use this opportunity to note that final publication of this will be blocked by WG completion of several of our other documents. The chairs are looking for WG discussion of the documents to address the first 4 milestones in our charter (with the introduction and architecture drafts addressing the first milestone.) -------- Original Message -------- Subject: WG adoption of draft-fuller-lisp-ddt-04.txt Date: Tue, 2 Oct 2012 11:13:16 -0700 From: Vince Fuller To: Joel M. Halpern , Terry Manderson ... This document has been stable since prior to the Vancouver WG meeting, with only editorial changes since then. A discussion among the authors has led to consensus that it is ready for adoption as a working group document. Can one of you please make the necessary magic happen? Thanks, --Vince ----- Forwarded message from internet-drafts@ietf.org ----- Date: Fri, 28 Sep 2012 15:50:56 -0700 From: To: Subject: I-D Action: draft-fuller-lisp-ddt-04.txt ... A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LISP Delegated Database Tree Author(s) : Vince Fuller Darrel Lewis Vina Ermagan Amit Jain Filename : draft-fuller-lisp-ddt-04.txt Pages : 42 Date : 2012-09-28 Abstract: This draft describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fuller-lisp-ddt There's also a htmlized version available at: http://tools.ietf.org/html/draft-fuller-lisp-ddt-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-fuller-lisp-ddt-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From dino@cisco.com Tue Oct 2 12:12:38 2012 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 9E23A21F8594 for ; Tue, 2 Oct 2012 12:12:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJua4wjVGWfj for ; Tue, 2 Oct 2012 12:12:37 -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 08AE821F8593 for ; Tue, 2 Oct 2012 12:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4216; q=dns/txt; s=iport; t=1349205157; x=1350414757; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=jvBF2F1nLDNrhZ2RvtEN0tigaqLWIvKcfK8h7aoyieQ=; b=VhqatV+iyz5P8sqvqzc5/UR6yEn/b0z5MC+wHcJPgVFq62AWv/biGW6T qhqjKDXsgVzS5Lrbsovj6sE5ZHFRC89rPB+WpGhKbP1RzOlLi8mqO/enC QHym82fAloLVjeuBtqQRkKIlup8pPddJaahUi+YtSpcJ2RZiAFJCPayNu A=; X-Files: smime.p7s : 2585 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACc8a1CtJV2Z/2dsb2JhbABFvl+BCIIgAQEBAwESAQpcBQsLRgJVBjWHXQaYUo9WkFmQfWADiFiGFoZ7jkKBaYMH X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="p7s'?scan'208";a="127570062" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 02 Oct 2012 19:12:35 +0000 Received: from dhcp-161-44-59-7.cisco.com (dhcp-161-44-59-7.cisco.com [161.44.59.7]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q92JCY8j020697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Oct 2012 19:12:35 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_9268449C-F8C7-4965-82E2-B1F75C3DC2C1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Dino Farinacci In-Reply-To: <506B3B53.1050008@joelhalpern.com> Date: Tue, 2 Oct 2012 12:12:38 -0700 Message-Id: References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1486) Cc: "lisp@ietf.org" Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 19:12:38 -0000 --Apple-Mail=_9268449C-F8C7-4965-82E2-B1F75C3DC2C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Please respod clearly and promptly. The discussion period is two = weeks, after which te chairs will determine if there is support for and = agreement to adopt this document as a WG document. I support making this document a working group draft. Dino --Apple-Mail=_9268449C-F8C7-4965-82E2-B1F75C3DC2C1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFUDCCBUww ggQ0oAMCAQICEC1TBxluVeE64egyuL9kyAswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA0MjUwMDAwMDBaFw0x MzA0MjUyMzU5NTlaMIIBDzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5EaW5vIEZhcmluYWNjaTEdMBsGCSqGSIb3DQEJARYOZGlub0BjaXNjby5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9C2Rwk3CLn526Rfiko9M7MSu3hBqq CIS0awvIVS8L03TFgzWm6JjkWAcus5ZR15+GMI3zvtVWbFVl/7lk8ZX2p7uySe5uXpAYSICeVlx/ sw5YsM5+AeCa1DjpzHoVGsFJA3LS/sugZ14TnwhsKxzvcqoPIJNTmQE6jAvUkoA1XV+OyMKM41Pd HiWMTf1dm1BdN8F/fcNVE6ttv1IQnTb7j8EI9stRLuY7otrJljUHNYmzAMfYpWwDk6JkGyYK6fwp oTR5Ibj0DRZsUYE+YIwbnW6uwTLWyXLod5sGOqdEMlk3qD7vQvCP30F+XsDRb0ii2dtUzMqKY1Ul r6fik/EpAgMBAAGjgdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCow KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5k YzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAAoX+IDg7qDqyr5O1zZX82v3TevLknKVcuJ1cOsZadb23w7B1g2fD3Ou 6j+AoLSj83Vqdir4BSapmv4c7MuVfynKcazZhSGdIT/yXV4DG75/I72vP4aLVgNlvV5bh8RFtOpI Ce54TIFQOnTXIhxS8Jp4w0mGVrTMm6RlFUYZCbVNR09k/fx5SjIJhwRKtmRd1jicbknRC1vbKj5v ugx8fjwwxtS/Im3V9ocnYCMqvH69dUWq9kDcg67dskUdmm1Tqzn9QNdVDkRgwweYobo1VInSijkC /Shj6NLAMfyWdeFRIEyiSfCEBUHCwnU1Zh39PtKjO4edRGcZzPt7401CNpExggSLMIIEhwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAt UwcZblXhOuHoMri/ZMgLMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEyMTAwMjE5MTIzOVowIwYJKoZIhvcNAQkEMRYEFJqwRvwF6tCWoC+Y Fdye/swbeNv2MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEC1TBxluVeE64egyuL9kyAswggEFBgsqhkiG9w0B CRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhAtUwcZblXhOuHoMri/ZMgLMA0GCSqGSIb3DQEBAQUABIIBAFcCHZqGuFKnn2mHkXLg 1x94j3qZOcnur2uFo81Ojskn/njkwJhu+lDAQpMhvG4tbSos+h+tJvr7RfPkRMzWw0azUB0yfz2j 9LvVN00z/GquYo54tm/+5lH5r/X+x29H7MWNFroYgf1xVFMfEnlYh8bfU49kCCLe6tOlnjCImBmY sJHRB0XsyJjcopR53kTi9A+pVnlt+CqJN+7Ws72JF4vpESx0dHTtLooWXW1DouvbMmChPEKODxVQ dCmtSo288pdYWn2zTsWa1N2FI4ggXK3wGqOS71Ranl57FreWgeXFJYJg8pjhOy7JBpPw9gJ9sGjA pvALq/4jQ4exiSGoJX0AAAAAAAA= --Apple-Mail=_9268449C-F8C7-4965-82E2-B1F75C3DC2C1-- From damien.saucez@gmail.com Tue Oct 2 12:19:53 2012 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 9781821F853B for ; Tue, 2 Oct 2012 12:19:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUPbsyrSSIpX for ; Tue, 2 Oct 2012 12:19:52 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07D21F84D8 for ; Tue, 2 Oct 2012 12:19:52 -0700 (PDT) Received: by eekd4 with SMTP id d4so3636497eek.31 for ; Tue, 02 Oct 2012 12:19:51 -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=+3DJwx5iO9TVHEvC7XLa7baqAoEAffZMwXTLJDBWvzs=; b=ytqbP37JtqooVWhz3iur/YjlpGrtvnT1fTkuwEqq7LGEH4jAXZfoNoXehts/9zkGps UYnfv1oaKsLKceOvmdKWXTs2IvizEa52PQBP2Q75Md8GS9OcMb1/zyYThs3dY6Je1Aui NkOt3g3PEKbF3rbuaXG7nmoOzkOK4GhloasodUhbwRcrA6Sc0Qiu0dsCywt/L3epnXGG AupFzBcI6NvSru+HKWf2shjkUFLIGQBYEbcOZXaTN8WXsB9l2XtLfiXeo7h0FX6V1cba XXgJBbkfGvfvy4zcJHQDYwjrFrC44QyK3yzt6iAglgaRmkA/DDXI7qp9aT2ctzKz6fQW J1Lw== Received: by 10.14.200.134 with SMTP id z6mr21587502een.33.1349205591628; Tue, 02 Oct 2012 12:19:51 -0700 (PDT) Received: from [172.16.139.253] (25.82.69.86.rev.sfr.net. [86.69.82.25]) by mx.google.com with ESMTPS id 7sm6024860eej.13.2012.10.02.12.19.49 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 12:19:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Damien Saucez In-Reply-To: <506B3B53.1050008@joelhalpern.com> Date: Tue, 2 Oct 2012 21:19:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77BD66E1-71C6-4723-87E7-22E994458222@gmail.com> References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1498) Cc: "lisp@ietf.org" Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 19:19:53 -0000 I am in favour of making this WC document and I am willing to = contribute. Damien Saucez On 02 Oct 2012, at 21:06, "Joel M. Halpern" wrote: > The draft below addresses a chartered work item for the working group. > Is the working group interested in adopting this draft as the starting = point towards our milestone "Submit an lternate mapping system design"? >=20 > For clarity, as this was much discussed recently on the wg-chairs = list, if the WG agrees to adopt this, the authors will resubmit this = draft under the appropriate new name (draft-ietf-lisp-ddt would seem = likely.) At that point, it will be a working group draft, and the = authors will work with the working group on all changes. > Adoption mans the WG thinks this is a good starting point to work = from. it does not mean that the WG agrees with all content. The WG is = likely to make changes after adoption. >=20 > Please respod clearly and promptly. The discussion period is two = weeks, after which te chairs will determine if there is support for and = agreement to adopt this document as a WG document. >=20 > Yours, > Joel M. Halpern >=20 > PS: Let me use this opportunity to note that final publication of this = will be blocked by WG completion of several of our other documents. The = chairs are looking for WG discussion of the documents to address the = first 4 milestones in our charter (with the introduction and = architecture drafts addressing the first milestone.) >=20 > -------- Original Message -------- > Subject: WG adoption of draft-fuller-lisp-ddt-04.txt > Date: Tue, 2 Oct 2012 11:13:16 -0700 > From: Vince Fuller > To: Joel M. Halpern , Terry Manderson = > ... >=20 > This document has been stable since prior to the Vancouver WG meeting, = with > only editorial changes since then. A discussion among the authors has = led to > consensus that it is ready for adoption as a working group document. >=20 > Can one of you please make the necessary magic happen? >=20 > Thanks, > --Vince >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Fri, 28 Sep 2012 15:50:56 -0700 > From: > To: > Subject: I-D Action: draft-fuller-lisp-ddt-04.txt > ... >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP Delegated Database Tree > Author(s) : Vince Fuller > Darrel Lewis > Vina Ermagan > Amit Jain > Filename : draft-fuller-lisp-ddt-04.txt > Pages : 42 > Date : 2012-09-28 >=20 > Abstract: > This draft describes the LISP Delegated Database Tree (LISP-DDT), a > hierarchical, distributed database which embodies the delegation of > authority to provide mappings from LISP Endpoint Identifiers (EIDs) > to Routing Locators (RLOCs). It is a statically-defined = distribution > of the EID namespace among a set of LISP-speaking servers, called = DDT > nodes. Each DDT node is configured as "authoritative" for one or > more EID-prefixes, along with the set of RLOCs for Map Servers or > "child" DDT nodes to which more-specific EID-prefixes are delegated. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fuller-lisp-ddt >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-fuller-lisp-ddt-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-fuller-lisp-ddt-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > ----- End forwarded message ----- >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@gmail.com Tue Oct 2 12:39:51 2012 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 BBBD221F8527 for ; Tue, 2 Oct 2012 12:39:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvxPCg9aX5PQ for ; Tue, 2 Oct 2012 12:39:51 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A794621F8516 for ; Tue, 2 Oct 2012 12:39:50 -0700 (PDT) Received: by wibhr7 with SMTP id hr7so1089075wib.13 for ; Tue, 02 Oct 2012 12:39:49 -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=H31Ct7+bGcxRfhi7IoF7co04O0NafyWC6xZ+9QyRu1A=; b=gO3f5RaZigDExa3Yo0XxpCf29zPrKKhJ0wAaNIkcbjb3Z0GNWTDwS4wgEjZ03j/dWs +DR9FieEIfmL83krdqVVzgc1J2M5TTdwdM9ZfOftuEO1vNAZ1ZvhzhotKlwfCII2ARsd 4zNKBPpzWlrOnU5TLRjhM9snBBvj8BYGDf6+xF/1fTNyITrH4vYHhqrJNwvFepGHXhRX dqal8qpNV4jSHCNG6RBMM/U0eCsg6AXwp3onEnVjRQ6nA+natQeSSvnuG4ZJ5M30VXcm JTQZ1oSkdNEomNufj5bJcef8a7Syk8xxmxbND0sVKBzElDgN3/o7OHRxiEM+HeRUSkuS bb0A== Received: by 10.180.96.164 with SMTP id dt4mr24070281wib.10.1349206789404; Tue, 02 Oct 2012 12:39:49 -0700 (PDT) Received: from [172.16.139.253] (213.189.101.84.rev.sfr.net. [84.101.189.213]) by mx.google.com with ESMTPS id dt9sm20646542wib.1.2012.10.02.12.39.37 (version=SSLv3 cipher=OTHER); Tue, 02 Oct 2012 12:39:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Damien Saucez In-Reply-To: <506B3B53.1050008@joelhalpern.com> Date: Tue, 2 Oct 2012 21:39:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1498) Cc: "lisp@ietf.org" Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 19:39:51 -0000 I am in favour of making this WG document and I am willing to = contribute. Damien Saucez On 02 Oct 2012, at 21:06, "Joel M. Halpern" wrote: > The draft below addresses a chartered work item for the working group. > Is the working group interested in adopting this draft as the starting = point towards our milestone "Submit an lternate mapping system design"? >=20 > For clarity, as this was much discussed recently on the wg-chairs = list, if the WG agrees to adopt this, the authors will resubmit this = draft under the appropriate new name (draft-ietf-lisp-ddt would seem = likely.) At that point, it will be a working group draft, and the = authors will work with the working group on all changes. > Adoption mans the WG thinks this is a good starting point to work = from. it does not mean that the WG agrees with all content. The WG is = likely to make changes after adoption. >=20 > Please respod clearly and promptly. The discussion period is two = weeks, after which te chairs will determine if there is support for and = agreement to adopt this document as a WG document. >=20 > Yours, > Joel M. Halpern >=20 > PS: Let me use this opportunity to note that final publication of this = will be blocked by WG completion of several of our other documents. The = chairs are looking for WG discussion of the documents to address the = first 4 milestones in our charter (with the introduction and = architecture drafts addressing the first milestone.) >=20 > -------- Original Message -------- > Subject: WG adoption of draft-fuller-lisp-ddt-04.txt > Date: Tue, 2 Oct 2012 11:13:16 -0700 > From: Vince Fuller > To: Joel M. Halpern , Terry Manderson = > ... >=20 > This document has been stable since prior to the Vancouver WG meeting, = with > only editorial changes since then. A discussion among the authors has = led to > consensus that it is ready for adoption as a working group document. >=20 > Can one of you please make the necessary magic happen? >=20 > Thanks, > --Vince >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Fri, 28 Sep 2012 15:50:56 -0700 > From: > To: > Subject: I-D Action: draft-fuller-lisp-ddt-04.txt > ... >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP Delegated Database Tree > Author(s) : Vince Fuller > Darrel Lewis > Vina Ermagan > Amit Jain > Filename : draft-fuller-lisp-ddt-04.txt > Pages : 42 > Date : 2012-09-28 >=20 > Abstract: > This draft describes the LISP Delegated Database Tree (LISP-DDT), a > hierarchical, distributed database which embodies the delegation of > authority to provide mappings from LISP Endpoint Identifiers (EIDs) > to Routing Locators (RLOCs). It is a statically-defined = distribution > of the EID namespace among a set of LISP-speaking servers, called = DDT > nodes. Each DDT node is configured as "authoritative" for one or > more EID-prefixes, along with the set of RLOCs for Map Servers or > "child" DDT nodes to which more-specific EID-prefixes are delegated. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fuller-lisp-ddt >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-fuller-lisp-ddt-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-fuller-lisp-ddt-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > ----- End forwarded message ----- >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Tue Oct 2 12:45:54 2012 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 E782521F859A for ; Tue, 2 Oct 2012 12:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBz+AAXPEKbo for ; Tue, 2 Oct 2012 12:45:54 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 63F5A21F856C for ; Tue, 2 Oct 2012 12:45:54 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3073718C0D0; Tue, 2 Oct 2012 15:45:53 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121002194553.3073718C0D0@mercury.lcs.mit.edu> Date: Tue, 2 Oct 2012 15:45:53 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 19:45:55 -0000 > From: "Joel M. Halpern" > Is the working group interested in adopting this draft as the starting > point towards our milestone "Submit an lternate mapping system design"? I would say 'yes', definitely. Noel From fcoras@ac.upc.edu Tue Oct 2 13:12:24 2012 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 4C96721F8595 for ; Tue, 2 Oct 2012 13:12: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JPPocaZd4OT for ; Tue, 2 Oct 2012 13:12:23 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8483221F8567 for ; Tue, 2 Oct 2012 13:12:22 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id q92KCKWp007246; Tue, 2 Oct 2012 22:12:20 +0200 Received: from [10.8.0.18] (unknown [10.8.0.18]) by gw.ac.upc.edu (Postfix) with ESMTP id 2E1A36B00B3; Tue, 2 Oct 2012 22:12:19 +0200 (CEST) Message-ID: <506B4AA2.5010409@ac.upc.edu> Date: Tue, 02 Oct 2012 22:12:18 +0200 From: Florin Coras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: lisp@ietf.org References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> In-Reply-To: <506B3B53.1050008@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 20:12:24 -0000 > Please respod clearly and promptly. The discussion period is two > weeks, after which te chairs will determine if there is support for > and agreement to adopt this document as a WG document. I support making this document a WG draft. Florin From vaf@cisco.com Tue Oct 2 13:23:41 2012 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 E5B6321F849D for ; Tue, 2 Oct 2012 13:23:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDLSsw2kRemC for ; Tue, 2 Oct 2012 13:23:40 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4B08221F849C for ; Tue, 2 Oct 2012 13:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=381; q=dns/txt; s=iport; t=1349209420; x=1350419020; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=6ePy9hxzIhI4yl5ZdKjTbvtMeoN4puW5sIUpq3eXdUg=; b=iCTYOfOr071/V0nmJhcNkMzJ44jB/L7whET3sdoawqRf7PyrJuXgdseM gjGJNg1y4ryAS7CNPJHq4hu3tOaoy2ylYMsCeyZf60W2SmKldo9Z9rUuH dBgSkGF9alCqdpkNTaUcZb6ZlKDs7l95uzAbASy3yHS27nTFaxHzgCCEI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB5Ma1CrRDoG/2dsb2JhbABFvl+BCIIgAQEBAwESAQodPwULC0YUGDE1h10FAZgXj1aQVJB9YAOIWI0QjkOBaYMH X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="60244418" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 02 Oct 2012 20:23:38 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q92KNceY006692; Tue, 2 Oct 2012 20:23:38 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 2344129719BD; Tue, 2 Oct 2012 13:23:37 -0700 (PDT) Date: Tue, 2 Oct 2012 13:23:36 -0700 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20121002202336.GA83052@vaf-mac1.cisco.com> References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <506B3B53.1050008@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 20:23:41 -0000 > The draft below addresses a chartered work item for the working group. > Is the working group interested in adopting this draft as the starting > point towards our milestone "Submit an [a]lternate mapping system design"? Since I'm the principal author of this draft and submitted the request to Joel, I not surprisingly support its adoption as a WG document. --Vince From hoefling@informatik.uni-tuebingen.de Tue Oct 2 14:08:29 2012 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 4BE3221F84DC for ; Tue, 2 Oct 2012 14:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcIQd+J+Aenk for ; Tue, 2 Oct 2012 14:08:27 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 3C32321F84AE for ; Tue, 2 Oct 2012 14:08:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8B8E952E4; Tue, 2 Oct 2012 23:08:19 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjU7V52Wm-An; Tue, 2 Oct 2012 23:08:16 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 342A252D7; Tue, 2 Oct 2012 23:08:16 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0A5681DD2536; Tue, 2 Oct 2012 23:08:16 +0200 (CEST) Date: Tue, 2 Oct 2012 23:08:15 +0200 (CEST) From: Michael Hoefling To: "Joel M. Halpern" Message-ID: <5841414.2421349212095621.JavaMail.root@zcs-pu.informatik.uni-tuebingen.de> In-Reply-To: <506B3B53.1050008@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [134.2.9.172] X-Mailer: Zimbra 5.0.19_GA_3083.MACOSXx86_10.5 (ZimbraWebClient - SAF3 (Mac)/5.0.19_GA_3083.MACOSXx86_10.5) Cc: lisp@ietf.org Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 21:08:29 -0000 I support making this document a working group draft and I am willing to contribute. Regards, Michael ----- "Joel M. Halpern" schrieb: > Please respod clearly and promptly. The discussion period is two > weeks, after which te chairs will determine if there is support for > and > agreement to adopt this document as a WG document. -- 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@informatik.uni-tuebingen.de http://kn.inf.uni-tuebingen.de/staff/hoefling From darlewis@cisco.com Tue Oct 2 14:13:43 2012 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 1737D21F8546 for ; Tue, 2 Oct 2012 14:13:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebc7BbJ1dpbV for ; Tue, 2 Oct 2012 14:13:42 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 89FD721F853B for ; Tue, 2 Oct 2012 14:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=548; q=dns/txt; s=iport; t=1349212422; x=1350422022; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XUA2OUzfEmaLMLKx/T1LaHzkRclhDCwFmNEGX0BC2JQ=; b=TIv4rRm86IM37yHGe4CvX1iJI6whysZJd2gb8v04RFXAcEtyUOsat14g yRb16hFw8KwOLWYW/XkNKG1strplHTj9el1H78ZngqxwvpToaVZLNfqLh e6315TbLo5aDsiUVS+X6SWZM8t8c4bQ3/QV/rpROblJjYVljBX7RfMQIS g=; X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="60248602" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 02 Oct 2012 21:13:42 +0000 Received: from [10.154.212.161] ([10.154.212.161]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q92LDg75003170; Tue, 2 Oct 2012 21:13:42 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: <20121002202336.GA83052@vaf-mac1.cisco.com> Date: Tue, 2 Oct 2012 14:13:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> <20121002202336.GA83052@vaf-mac1.cisco.com> To: Vince Fuller X-Mailer: Apple Mail (2.1278) Cc: "lisp@ietf.org" Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 21:13:43 -0000 On Oct 2, 2012, at 1:23 PM, Vince Fuller wrote: >> The draft below addresses a chartered work item for the working = group. >> Is the working group interested in adopting this draft as the = starting=20 >> point towards our milestone "Submit an [a]lternate mapping system = design"? >=20 > Since I'm the principal author of this draft and submitted the request > to Joel, I not surprisingly support its adoption as a WG document. I happen to agree with Vince in supporting this document being adopted = by the WG. :-) -Darrel= From job@instituut.net Tue Oct 2 15:02:19 2012 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 EB38721F8620 for ; Tue, 2 Oct 2012 15:02:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TICe8uGGl7Ua for ; Tue, 2 Oct 2012 15:02:19 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C57FA21F861E for ; Tue, 2 Oct 2012 15:02:18 -0700 (PDT) Received: by weyu46 with SMTP id u46so4282581wey.31 for ; Tue, 02 Oct 2012 15:02:17 -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 :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=EMFuOBBdXRuJ0zLCo/tpwb2VyBToxx0K6U37M++u+nw=; b=InpEMuyiBS3TghOHt03VugtidwO25clh5e1uYEpdqrxVIn+O8EPG4+spakZvkg2kwi jeAQA9b0ePugNakDaIBMYAiaWdANjL1W5yvddXVO3zgFjTzrR1Ye65BCXwSjeiXk1URr XwIsAyH3uVTaae+gIjGrE5xbvGRxH7cvsdcRb5CtIRS6ivYlcHDAsIugUCo1noqAUCZs nTsByvzdm+s0J22996QAjoZ0zUi/G2UA9aprtjyD7kx+J2G+DKBvsvQjftHuQ+d6XPtn LVEGXND/N/VEKJmRsZ9FeGavqcYAz3WUYSEQPxG6Gu27GgtxCVp2HHBdax5gbFuQzoOX btig== Received: by 10.216.53.193 with SMTP id g43mr65798wec.67.1349215337646; Tue, 02 Oct 2012 15:02:17 -0700 (PDT) Received: from [10.3.244.172] ([212.38.132.66]) by mx.google.com with ESMTPS id cn6sm4658390wib.9.2012.10.02.15.02.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 15:02:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Job Snijders In-Reply-To: <506B3B53.1050008@joelhalpern.com> Date: Wed, 3 Oct 2012 01:02:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> To: lisp@ietf.org X-Mailer: Apple Mail (2.1498) X-Gm-Message-State: ALoCoQmm+QmWS1Nc6GeKnkOJV5tl0eK3VN+MJgBNOv2hENXr0hpBzkXCyMo9w2FkHMfDwWRo3v5I Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 22:02:20 -0000 Dear all, I support adopting this draft. I have contributed and will do so in the = future.=20 Kind regards, Job On Oct 2, 2012, at 10:06 PM, Joel M. Halpern = wrote: > The draft below addresses a chartered work item for the working group. > Is the working group interested in adopting this draft as the starting = point towards our milestone "Submit an lternate mapping system design"? >=20 > For clarity, as this was much discussed recently on the wg-chairs = list, if the WG agrees to adopt this, the authors will resubmit this = draft under the appropriate new name (draft-ietf-lisp-ddt would seem = likely.) At that point, it will be a working group draft, and the = authors will work with the working group on all changes. > Adoption mans the WG thinks this is a good starting point to work = from. it does not mean that the WG agrees with all content. The WG is = likely to make changes after adoption. >=20 > Please respod clearly and promptly. The discussion period is two = weeks, after which te chairs will determine if there is support for and = agreement to adopt this document as a WG document. >=20 > Yours, > Joel M. Halpern >=20 > PS: Let me use this opportunity to note that final publication of this = will be blocked by WG completion of several of our other documents. The = chairs are looking for WG discussion of the documents to address the = first 4 milestones in our charter (with the introduction and = architecture drafts addressing the first milestone.) >=20 > -------- Original Message -------- > Subject: WG adoption of draft-fuller-lisp-ddt-04.txt > Date: Tue, 2 Oct 2012 11:13:16 -0700 > From: Vince Fuller > To: Joel M. Halpern , Terry Manderson = > ... >=20 > This document has been stable since prior to the Vancouver WG meeting, = with > only editorial changes since then. A discussion among the authors has = led to > consensus that it is ready for adoption as a working group document. >=20 > Can one of you please make the necessary magic happen? >=20 > Thanks, > --Vince >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Fri, 28 Sep 2012 15:50:56 -0700 > From: > To: > Subject: I-D Action: draft-fuller-lisp-ddt-04.txt > ... >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP Delegated Database Tree > Author(s) : Vince Fuller > Darrel Lewis > Vina Ermagan > Amit Jain > Filename : draft-fuller-lisp-ddt-04.txt > Pages : 42 > Date : 2012-09-28 >=20 > Abstract: > This draft describes the LISP Delegated Database Tree (LISP-DDT), a > hierarchical, distributed database which embodies the delegation of > authority to provide mappings from LISP Endpoint Identifiers (EIDs) > to Routing Locators (RLOCs). It is a statically-defined = distribution > of the EID namespace among a set of LISP-speaking servers, called = DDT > nodes. Each DDT node is configured as "authoritative" for one or > more EID-prefixes, along with the set of RLOCs for Map Servers or > "child" DDT nodes to which more-specific EID-prefixes are delegated. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fuller-lisp-ddt >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-fuller-lisp-ddt-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-fuller-lisp-ddt-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > ----- End forwarded message ----- >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From sander@steffann.nl Tue Oct 2 15:40:30 2012 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 AE9C921F8617 for ; Tue, 2 Oct 2012 15:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIahYafZZdkG for ; Tue, 2 Oct 2012 15:40:30 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 4284E21F8567 for ; Tue, 2 Oct 2012 15:40:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A74FC2079; Wed, 3 Oct 2012 00:40:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu2O0I7W99R5; Wed, 3 Oct 2012 00:40:28 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id A44962007; Wed, 3 Oct 2012 00:40:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Sander Steffann In-Reply-To: <506B3B53.1050008@joelhalpern.com> Date: Wed, 3 Oct 2012 00:40:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BE3DA8A-E87C-40C9-B2F7-55E3BA0EC4B5@steffann.nl> References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1498) Cc: "lisp@ietf.org" Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 22:40:30 -0000 > The draft below addresses a chartered work item for the working group. > Is the working group interested in adopting this draft as the starting = point towards our milestone "Submit an alternate mapping system design"? Yes, I think this should become a working group draft. Sander From fmaino@cisco.com Tue Oct 2 16:27:27 2012 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 5476521F8619 for ; Tue, 2 Oct 2012 16:27:27 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1E40zcXJME4 for ; Tue, 2 Oct 2012 16:27:26 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8286021F8617 for ; Tue, 2 Oct 2012 16:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4254; q=dns/txt; s=iport; t=1349220446; x=1350430046; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=kk2GMXDFSu8gF7XFucHSdM6dOguld+C6Zl+m14rTlvg=; b=gJHP5AFXRJLYaapvt4mGJLtXIdSIpFWiQtjUV9IT7owpXZv9RCnxoEPh XJsswvLkwtFmpk1butgIWxCgbHbem+ku1XLGGrLgaRTQNuf86ESdDO+mX C9dB46XR/lxsC7ERY8IWjoMdbWt77BAldOzEE8JKw3N3wUZT2TIvoyxG1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADB3a1CrRDoH/2dsb2JhbABFvmaBCIIgAQEBBAEBAQ8BChs2FwQLEQECAQIBCSUPAhYiBggTBgIBAQUZh2IMl3WPVpBGiyOGOgOIWI0RgRWKDoMfgWmDBw X-IronPort-AV: E=Sophos;i="4.80,525,1344211200"; d="scan'208";a="57155220" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 02 Oct 2012 23:27:26 +0000 Received: from fmaino-mac-2.local ([10.154.215.205]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q92NRPME012760 for ; Tue, 2 Oct 2012 23:27:25 GMT Message-ID: <506B785D.60008@cisco.com> Date: Tue, 02 Oct 2012 16:27:25 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: lisp@ietf.org References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> In-Reply-To: <506B3B53.1050008@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 23:27:27 -0000 I support the adoption of this draft as WG item. Fabio On 10/2/12 12:06 PM, Joel M. Halpern wrote: > The draft below addresses a chartered work item for the working group. > Is the working group interested in adopting this draft as the starting > point towards our milestone "Submit an lternate mapping system design"? > > For clarity, as this was much discussed recently on the wg-chairs > list, if the WG agrees to adopt this, the authors will resubmit this > draft under the appropriate new name (draft-ietf-lisp-ddt would seem > likely.) At that point, it will be a working group draft, and the > authors will work with the working group on all changes. > Adoption mans the WG thinks this is a good starting point to work > from. it does not mean that the WG agrees with all content. The WG > is likely to make changes after adoption. > > Please respod clearly and promptly. The discussion period is two > weeks, after which te chairs will determine if there is support for > and agreement to adopt this document as a WG document. > > Yours, > Joel M. Halpern > > PS: Let me use this opportunity to note that final publication of this > will be blocked by WG completion of several of our other documents. > The chairs are looking for WG discussion of the documents to address > the first 4 milestones in our charter (with the introduction and > architecture drafts addressing the first milestone.) > > -------- Original Message -------- > Subject: WG adoption of draft-fuller-lisp-ddt-04.txt > Date: Tue, 2 Oct 2012 11:13:16 -0700 > From: Vince Fuller > To: Joel M. Halpern , Terry Manderson > > ... > > This document has been stable since prior to the Vancouver WG meeting, > with > only editorial changes since then. A discussion among the authors has > led to > consensus that it is ready for adoption as a working group document. > > Can one of you please make the necessary magic happen? > > Thanks, > --Vince > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Fri, 28 Sep 2012 15:50:56 -0700 > From: > To: > Subject: I-D Action: draft-fuller-lisp-ddt-04.txt > ... > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : LISP Delegated Database Tree > Author(s) : Vince Fuller > Darrel Lewis > Vina Ermagan > Amit Jain > Filename : draft-fuller-lisp-ddt-04.txt > Pages : 42 > Date : 2012-09-28 > > Abstract: > This draft describes the LISP Delegated Database Tree (LISP-DDT), a > hierarchical, distributed database which embodies the delegation of > authority to provide mappings from LISP Endpoint Identifiers (EIDs) > to Routing Locators (RLOCs). It is a statically-defined distribution > of the EID namespace among a set of LISP-speaking servers, called DDT > nodes. Each DDT node is configured as "authoritative" for one or > more EID-prefixes, along with the set of RLOCs for Map Servers or > "child" DDT nodes to which more-specific EID-prefixes are delegated. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fuller-lisp-ddt > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-fuller-lisp-ddt-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-fuller-lisp-ddt-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ----- End forwarded message ----- > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From gschudel@cisco.com Tue Oct 2 19:07:41 2012 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 A9DBD21F8615 for ; Tue, 2 Oct 2012 19:07:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys1nkOa+40t2 for ; Tue, 2 Oct 2012 19:07:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E69C821F860B for ; Tue, 2 Oct 2012 19:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1214; q=dns/txt; s=iport; t=1349230061; x=1350439661; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=AUYeQnJ4P2Gq/mG/KBZVLfwktj5lFPrCNIFOf1whIPg=; b=PIbiZGvRzwYLDA+kaT6k3jI9MY1DkbOXdwF3h1HrOlildDTq6TlQGDZD izWaN7ao0k0im7CVc+Vkh0oSae3Dc7y3dt9dpkmWwKKo+GAf2l7ZyHyRF JLuxlbwrt8tEwOoXeyUCQ+lJNC+nVl+JbdIOXvhdW3XeOhOhBbNZItw1Z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABqda1CtJXG9/2dsb2JhbABCA75wgQiCOQElNwkBPBYYAwIBAgFLDQEFAgEBHodjC5d8j1aQSI44gyUDiCM1jRGBFY0tgWmDB4FDNA X-IronPort-AV: E=Sophos;i="4.80,525,1344211200"; d="scan'208";a="127719207" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 03 Oct 2012 02:07:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9327c77025358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 02:07:38 GMT Received: from gschudel-mac-2.local (10.154.212.105) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 2 Oct 2012 21:07:37 -0500 Message-ID: <506B9DE8.5090607@cisco.com> Date: Tue, 2 Oct 2012 19:07:36 -0700 From: Gregg Schudel Organization: cisco.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: LISP mailing list list Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.154.212.105] X-TM-AS-Product-Ver: SMEX-10.2.0.1135-7.000.1014-19230.001 X-TM-AS-Result: No--10.414200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [lisp] LISP-MIB-06 Summary of Changes 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 Oct 2012 02:07:41 -0000 Hi All As noted on the LISP working group site, a new (and final hopefully) version of the LISP MIB is posted. http://tools.ietf.org/wg/lisp/draft-ietf-lisp-mib/ The changes included in this last revision were the result of some very detailed comments during the last-call period. Thank you to all who provided comments (and especially Dan Romascanu for the very thorough review and comments). In summary, the following changes were made: - added/updated all references in each mib table - specified bounds on all integer fields - added discontinuity entities to appropriate fields (to handle things like counter resets) - updated IANA MIB branch text (The MIB passes simlint and now should be compliant.) Thanks Gregg -- -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From ggx@gigix.net Wed Oct 3 00:28:49 2012 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 7597421F8476 for ; Wed, 3 Oct 2012 00:28:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B52bPEByVgc for ; Wed, 3 Oct 2012 00:28:48 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4A21F84C5 for ; Wed, 3 Oct 2012 00:28:48 -0700 (PDT) Received: by weyu46 with SMTP id u46so4523393wey.31 for ; Wed, 03 Oct 2012 00:28:47 -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=jT5y+wvitWgwZpLBd/yTVFDE9iIeMxzxmh3ejPqxqkQ=; b=N7eFGJIxgC3Kxt5KOGxubk76IDQ7Ndnr9GEYipLCEzlgo6YmXRQWsctEXkVogLEkvt rud0D6yZERdVoL+7fP7Q52Ye19dv7Kpb08TbmjIQnOjdgza6PppW9UDD4KNozJXzqmjc hUXDco7V3dYdGzOIWYzb5dUZhZmUI59NFdxRWu31qOahTmXY3etxt9pyHmGCumlq/89o 52kggWXZP3FzzxhtxqG0n46KiqqHPvFjkJxYpxyqXPhv+qP3z1NhPMPF6+1Nx2OJPvHL D7kf2ewxR4/QgjJ0ssbP5ot0X6XI+pbkSFl/3wSYwuxBR1v3h1YQp9UBMaALFkbT0UTi qbxw== Received: by 10.180.82.34 with SMTP id f2mr25750118wiy.17.1349249327133; Wed, 03 Oct 2012 00:28:47 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:498e:d844:1cab:6f9a? ([2001:660:330f:a4:498e:d844:1cab:6f9a]) by mx.google.com with ESMTPS id cl8sm25563552wib.10.2012.10.03.00.28.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Oct 2012 00:28:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Luigi Iannone In-Reply-To: <506B3B53.1050008@joelhalpern.com> Date: Wed, 3 Oct 2012 09:31:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B958F76-DC1A-4939-BE75-9A626C8ED772@gigix.net> References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1498) X-Gm-Message-State: ALoCoQkRp/cGdVXd2JPl6mFQtNqbvcivRfjvJj27Sc2eiJVl/nj1td4xWrewXeXJeDG8uzKGv17n Cc: "lisp@ietf.org" Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 07:28:49 -0000 Hi, I support the adoption of this draft as WG document.=20 Luigi On 2 Oct. 2012, at 21:06 , Joel M. Halpern wrote: > The draft below addresses a chartered work item for the working group. > Is the working group interested in adopting this draft as the starting = point towards our milestone "Submit an lternate mapping system design"? >=20 > For clarity, as this was much discussed recently on the wg-chairs = list, if the WG agrees to adopt this, the authors will resubmit this = draft under the appropriate new name (draft-ietf-lisp-ddt would seem = likely.) At that point, it will be a working group draft, and the = authors will work with the working group on all changes. > Adoption mans the WG thinks this is a good starting point to work = from. it does not mean that the WG agrees with all content. The WG is = likely to make changes after adoption. >=20 > Please respod clearly and promptly. The discussion period is two = weeks, after which te chairs will determine if there is support for and = agreement to adopt this document as a WG document. >=20 > Yours, > Joel M. Halpern >=20 > PS: Let me use this opportunity to note that final publication of this = will be blocked by WG completion of several of our other documents. The = chairs are looking for WG discussion of the documents to address the = first 4 milestones in our charter (with the introduction and = architecture drafts addressing the first milestone.) >=20 > -------- Original Message -------- > Subject: WG adoption of draft-fuller-lisp-ddt-04.txt > Date: Tue, 2 Oct 2012 11:13:16 -0700 > From: Vince Fuller > To: Joel M. Halpern , Terry Manderson = > ... >=20 > This document has been stable since prior to the Vancouver WG meeting, = with > only editorial changes since then. A discussion among the authors has = led to > consensus that it is ready for adoption as a working group document. >=20 > Can one of you please make the necessary magic happen? >=20 > Thanks, > --Vince >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Fri, 28 Sep 2012 15:50:56 -0700 > From: > To: > Subject: I-D Action: draft-fuller-lisp-ddt-04.txt > ... >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP Delegated Database Tree > Author(s) : Vince Fuller > Darrel Lewis > Vina Ermagan > Amit Jain > Filename : draft-fuller-lisp-ddt-04.txt > Pages : 42 > Date : 2012-09-28 >=20 > Abstract: > This draft describes the LISP Delegated Database Tree (LISP-DDT), a > hierarchical, distributed database which embodies the delegation of > authority to provide mappings from LISP Endpoint Identifiers (EIDs) > to Routing Locators (RLOCs). It is a statically-defined = distribution > of the EID namespace among a set of LISP-speaking servers, called = DDT > nodes. Each DDT node is configured as "authoritative" for one or > more EID-prefixes, along with the set of RLOCs for Map Servers or > "child" DDT nodes to which more-specific EID-prefixes are delegated. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fuller-lisp-ddt >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-fuller-lisp-ddt-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-fuller-lisp-ddt-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > ----- End forwarded message ----- >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ljakab@ac.upc.edu Thu Oct 4 15:38:47 2012 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 AD52421F850D for ; Thu, 4 Oct 2012 15:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSGckZcEEaNp for ; Thu, 4 Oct 2012 15:38:47 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id DB56121F84EE for ; Thu, 4 Oct 2012 15:38:46 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id q94MciVM002793; Fri, 5 Oct 2012 00:38:44 +0200 Received: from [192.168.1.110] (c-98-248-32-190.hsd1.ca.comcast.net [98.248.32.190]) by gw.ac.upc.edu (Postfix) with ESMTP id 581F76B006C; Fri, 5 Oct 2012 00:38:43 +0200 (CEST) Message-ID: <506E0FF0.9020308@ac.upc.edu> Date: Thu, 04 Oct 2012 15:38:40 -0700 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: "lisp@ietf.org" References: <20121002181316.GA81712@vaf-mac1.cisco.com> <506B3B53.1050008@joelhalpern.com> In-Reply-To: <506B3B53.1050008@joelhalpern.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Call for WG Document Adoption: draft-fuler-lisp-ddt-04 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 Oct 2012 22:38:47 -0000 On 10/02/12 12:06, Joel M. Halpern wrote: > The draft below addresses a chartered work item for the working group. > Is the working group interested in adopting this draft as the starting > point towards our milestone "Submit an lternate mapping system design"? Yes, I support adopting this document as a WG item. -Lori From terry.manderson@icann.org Mon Oct 8 16:38:32 2012 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 BEFAE21F84C4 for ; Mon, 8 Oct 2012 16:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gQuQ515bYHQ for ; Mon, 8 Oct 2012 16:38:30 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id B762921F8235 for ; Mon, 8 Oct 2012 16:38:30 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 8 Oct 2012 16:38:29 -0700 From: Terry Manderson To: LISP mailing list list Date: Mon, 8 Oct 2012 16:38:28 -0700 Thread-Topic: Agenda Items for LISP in IETF 85 Thread-Index: Ac2lrgRhdmNNpfVNc0yvPSEQSTr84Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3432620308_1736271" MIME-Version: 1.0 Subject: [lisp] Agenda Items for LISP in IETF 85 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 Oct 2012 23:38:32 -0000 --B_3432620308_1736271 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Folks, There is a smidge over two weeks until a WG draft agenda for IETF 85 is due. "2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00" Please email requests for agenda slots to this list by 2012-10-22 (Monday). If you have been watching, you will notice that an IETF agenda is up, and we have a 2 hour session on Tuesday (6th Nov) afternoon (1pm-3pm). Cheers Terry --B_3432620308_1736271 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU6H5tEDL5j17koRVhYB1v2+AvkxQwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDA4MjMzODI4WjANBgkqhkiG 9w0BAQEFAASCAQBHYSQ+KRtdJdqtBG2eYSOsYgUYy8i4k4wZP9s6aeE1v31fxJDrlHA8wZAE Ir3thjhX4WxeJIyk4aSR8hZ7WYezq/3IQHFaBWp1DbtvKKerTU6N7xyVMWOzPywmKDwLP4fj LGvI84XOu/Vy94SBvMwRT0Noc/rY30MQ5FNg3wibZt51V6nDvZk2Qsr5zVqt6REPNfpkUk1F vKtnUKsJlxOCI67YP26cJnKgbq9z6tqrFPp1KaNy21D/PnOE5yqmv6Y9IYPOoMdkO8fgROFc F1Lv3BLtWfvUi+twBwGauVVO5w1/yrOjDZsh0vWWC3FX/XCgowcX98ZJ3TlwGwHrKCRg --B_3432620308_1736271-- From dino@cisco.com Tue Oct 9 16:50:35 2012 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 ED4AF1F0C4C for ; Tue, 9 Oct 2012 16:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.335 X-Spam-Level: X-Spam-Status: No, score=-9.335 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwnUQkzWxGyy for ; Tue, 9 Oct 2012 16:50:34 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id DF9EC11E80E8 for ; Tue, 9 Oct 2012 16:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20659; q=dns/txt; s=iport; t=1349826633; x=1351036233; h=from:subject:message-id:date:to:mime-version; bh=K58JCckZdr5TsRgPtb6uygiK3Z0GGkyK2vyJKvHGIvg=; b=V/l7/jZRPrq0L4lghfdzYVUuwQZ02gqbMfcUklrl8h/r+wMYKUUL3rs7 6x2d7rVJzgNGsRqIDcwZXPQt9oZCilgP4kHTr8LtiPBnnPIz7aSBQxKo4 NUNRvgVyfkApFqqRUFXZmt28S7sCwkAeXIeTtNN6LgCH6uN6UdDt3RADm M=; X-Files: PastedGraphic-5.png, smime.p7s : 10944, 2585 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsGAMy3dFCrRDoI/2dsb2JhbABFgk0Cgnu5ZYEIghcVDQGBAgEBARkBAQEoFQEONxIBBhyHYpkHgSiPWJBLkHZgA4hYhhaBIYVcjkWBa4MN X-IronPort-AV: E=Sophos;i="4.80,562,1344211200"; d="p7s'?png'150?scan'150,208,217,150";a="58322116" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 09 Oct 2012 23:50:33 +0000 Received: from sjc-vpn7-1424.cisco.com (sjc-vpn7-1424.cisco.com [10.21.149.144]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q99NoUZu027055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Oct 2012 23:50:30 GMT From: Dino Farinacci Content-Type: multipart/signed; boundary="Apple-Mail=_D63CCE3C-31A5-44D2-AE26-B497F4A74723"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <83522620-E029-4689-8779-AB630B0E11D6@cisco.com> Date: Tue, 9 Oct 2012 16:50:32 -0700 To: "lisp@ietf.org list list" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [lisp] Can draft-farinacci-lisp-rig-01 be a WG document? 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 Oct 2012 23:50:35 -0000 --Apple-Mail=_D63CCE3C-31A5-44D2-AE26-B497F4A74723 Content-Type: multipart/alternative; boundary="Apple-Mail=_4C38A861-185F-46E8-BBE3-123B3B4B4EA7" --Apple-Mail=_4C38A861-185F-46E8-BBE3-123B3B4B4EA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii WG and chairs, I would like to request/suggest that the above draft be = made as a working group document since it is associated with = draft-ietf-lisp-ddt which just became a WG document. Comments? Thanks, Dino= --Apple-Mail=_4C38A861-185F-46E8-BBE3-123B3B4B4EA7 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_B6390633-46EF-474F-A187-1DB15174D933" --Apple-Mail=_B6390633-46EF-474F-A187-1DB15174D933 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

WG and chairs, I would like to request/suggest that the above draft be made as a working group document since it is associated with draft-ietf-lisp-ddt which just became a WG document.

Comments?

Thanks,
Dino
--Apple-Mail=_B6390633-46EF-474F-A187-1DB15174D933 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-5.png Content-Type: image/png; name="PastedGraphic-5.png" Content-Id: <6FC65CF6-5E3B-411F-8E8A-B90A9BADD222@cisco.com> iVBORw0KGgoAAAANSUhEUgAAAoAAAAAWCAYAAABQbS1UAAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAgOklEQVR4 Ae2dCZzOVRfHz+yDGUtImxppT0lZEpVSaFXRSyvxtpf29RUqbSgt3vZSvVGkon0hSpYiSihLpezK OmO253nmvud7xh3PPGZQZsj0v5/P43nm/7//c889dzm/+zv3/sU5TVJGaf78+TJ79mw588wzy0hi ICawQGCBLVmAcbfnnntKpUqVtpQ1uB9YILBAGVggMzNT/vjjD6lXr14ZSKu4In7//XcJhUKyxx57 VNxK7sQ1i9+JdQ9UDywQWCCwQGCBwAKBBQILBBb4CxYIAOBfMFrwSGCBwAKBBQILBBYILBBYYGe2 QAAAd+bWC3QPLBBYILBAYIHAAoEFAgv8BQsk/oVntvmRFb8XyLp1IvvV3zr8OXdegXz3fViaHJUo GfvESzgskhijeUGByOSvw7JkqZM2rROlatW4zeq5fIWT1asL5KADEzabb1turl3r5LdFBdLgkASJ i1Jnwa8FkpoaJzWqx8mPcyNy6MEJm9Tnr5TLbs5ZsyNSd694qVYtqsDNCMvMdDJ1WkTzixx5RHGj ov+q1U7qZWxdO22mmODWDrDAqlWrZMmSJdKgQYNipS9btkzWrl0rBx54oF3PysqSiRMnCvkzMjKk adOmEh8fL/n5+fLdd99JTk6OFOgAS0hIsD1Pe+21VzF5/LF48WL59ddf7Zk47ew1a9YsKhf533// vd1jyzF7FQ877DCpXLmyLF26VObMmaPjI06Sk5N1bIclEonI7rvvXqQf8rOzs2XGjBmSm5sryCB/ nTp15OCDD+Z2qWnevHny7bffylFHHSX77rtvqfm29gZ7vxYuXCiHHHJIsUfW6YS2YMECqzO2Ky1h U+pZHgm7YLvE2MlxQ2G0D7ZAhwMOOEAaNmxYHmpsUSb9Yfr06WbDuXPnSl5enrUpdtt7772L9tXN nDnT9rbWqFGjSOY333wjP/30k86fqXLkkUeK74sTJkywvrDLLrsU5d2RP2bNmmVjj/G0//77myq0 z9dff219mDEWvWeXez/++KP1ed9/fvjhB+tr++yzT7GxEF0vnmHsHXroobLbbrvZLfbcTZ482cbI 0UcfXWJ/YDyhC6lJkyZSpUoV+82ePcYZe/a2NLbsgW34B91pr1133bWYlOXLl1sb008Z59WrV5fD Dz/cfhfLqH9gZ+Yt+r1PyCR/SQnbcE6BuY8+VFoiX1JSUmm3K8517XhllnSydaNGjdqivFeG5rku V2ZtMR8ZMjMLXMMT17rWZ69zX3wZcj3vyXZz5kY2eXbqtJCr02S163BxlluydNP7sQ+8PCTXde6+ dTrEPru1f4+fEFK9M10oVPyJ62/PdgMH5bjfFkZc81PWOQWixTNsw18nd8h0n42LKbAUectXFLgW p61zrc5c5w4+bo2796Gcopzr1hW4Nh3Xudt7ZxddC378PS3AuNMJfRPl3nrrLdeiRQun4K3YvSee eMLpQS27pmDQHXPMMU4BmWvfvr3Tid917drV6eTrFOi49PR0p5OpO+6445w6XKeTtRs+fHgxefzR p08fp4DOHXvssU6djlNw5s4//3y3fv1699VXXzmdyJ06GteyZUunTtEpIHM6EbsPPvjAdOSeOj53 0EEHWZ4HHnigWBkKGJxOyCa/Xbt2rlWrVq5WrVpWbmz9/IOUfcQRR7gTTjjBffbZZ/7yNn1PmjTJ 5MWWOX78eLOTguVS5Y8dO9Y9+OCDpd7f1hu33nqrU6daohjaXAGCO/HEE91pp51m7XzHHXc4Bdwl 5i/Pi/fee6+788473bvvvusUDLvWrVu7tm3bWj+kTV955RUrvnnz5m7kyJH2W0Gj9ae6deta36U/ 0lfff/99u3///fe7q6++ujzVLiZbAb/7+eefi13zfzz00ENuv/32c6effrpTgOpeffVVu3XVVVdZ H2F8nHrqqTY2/DN33323jRsFMnbpsccec/Xr1zcZ1Pn555/3WYu+hw4danlOPvlkp4DGKRgymchm zDLWzjrrLIftohNjnnHK3IAufPRAi2MeUSDpkKeLJTd48ODox/7S7xUrVjgFqCU+i57PPvvsJveo O/0C/ekDuhi0Nlegt0le+gF2oj7kp07XXXfdJvn8BfRp1qyZ00WEv7TJN+3HWP0nJFZeZZa2BAC/ nRF2X08Nu+dfynXdr8lyzJWLFkfcjJlhA3X0/enfhd3n40Nu/k+FA+Hj0fkuo/ka99WUsOU9ovVa N+LtfJebu1Ht7OwCd8+D2QamFi8pfG7NmgI3cXLITZgUcn+sLHSAAJ6FiyJu8tchN3NW2M2aHXaU iQ7co9y58wqfRzogaNJXIfflxJBT1rKoQH4DRnk+Ov04J2zXly0vzAuw+2Z6WB1wdC7nbrwj2w14 LEfrUKD2COkk7EyPad+GHaDRlwVwRDd0prwlS2MEqVj105bnhx8jDvtOnRZ2qzYAypWrCkwetly6 LKKTQ/Hn+w3Mca3arzP9KLveMWusrHnzI65Zu3UurdEq16vvpsCieG2Cv3a0BUoDgG+//bYBt1iw 8t///tccA3rjbJUhNMDH3wAtAJqyD07ZQ5t8lTUyEKnsm7vlllvMYcTKxKHj8HBgunp2yt44ZXNc //79nbI2DiemK3u7ryyDO/fcc23SVvbHQAgTszIl7vPPP7c83hGiEwkZOFNk+AQQBQR4xwCgHDdu nMPBkT799FOn7IkDnPmk7IaVgcMj4cgXLVpk8gFPOCvkKGNpdaYeyOQaSZkVAyyx9VcGyjVq1EjH dK45YXTQ09lWNvUFaN11113unHPOKXKI1J3nAJXYjET9AN6U88svv5hjRgfyoatP6IxeyqDZJZ4B 7L7xxhumg8/HN/KrVavmWBD4pIyvU5bWTZs2zSkbbDaYMmWK6Yauyg65L7/8sgg8YC90Iw+f6PbB maKLMqAmHhugH3pjx+i8yviaA8Y+b775plMmtQiEkg8gRz2wB07dEwq9evUyR49NSdi/b9++tnCh vNWrV7vGjRtbv7UM5fxPaQAQOym7an0PFQBuLLCmTp1q40pZWPV7ObaYGjJkiNWzS5cuLi0tzQAM zyAbu7zzzjv86cgHoKO/+MSCTxlc99prr9mla6+91l166aVu2LBhBgZXrlxp/QBQ9OKLL/rH7PvJ J580oMQijw+giTw33XSTQxcSc4cygNY37MJf/GdzAPCMM85wzz333CaSBwwYYG1Pf6AfML9hjxtv vHGTvCwE6fMk+oT/YCuNLBTZDHvQP6kvfdsv1OifX3zxhfVXZNCPWDA++uijSj5lcskx/5HHzyt2 sYL8UzzmV47EZu/7cmXoh3myz67xMmdJRNq3TJY58yLStnumpCbGSdMDE6WSMrLT50Rkr9rxMuPX iAy8tbK883G+LM8pkIFP58pRhyXIr2sKZNDgXGnaOMFCnai8bLmTYR+FZMm6iLzwSp507pAsHS9f L7U0DJybr+GjPCefDkuXBx/JkSGj86VGpTjZb88EqVUjTp5+pIqcfnGWRDSEXFPz/6C6vXhvFWmo ZZ3RJUuqVY6TsLLLq9c7Gf16mixc5OSiG7Kkruo4f2mBXNExRW67MVX6DcyVF97Ok731+k/LCmT4 E2kaznJyW98c+eztdA2fFTcuURr0vurObBn7Zrrc2y9Xxn4VkurpcfKLPj/y2TTZc494ad05SxL1 2T1qxsnPev2lflWk5TEbm01BobTqnCm8yydDy6a+/XtWMtuc0TVLamkoeH2Ok0Vqt9cfTpPjWm58 duqMiJx+YrJS62L1rVM1XubNL5C0tDg5/8xkWbM2UXJyi+sd/FWxLFC7dm1RZy3qAKRNmzaizlcU MFkIV52ZhYLVOVn4JSUlRRQcirJpRWHYaGsQuvIfQlLqUEQZHFEHaNcJTXJfWR5RFkiU+bEQl67g LUzFPcIufJeUCAfpBG5hYn6rozS9eEZX7fLyyy9bCJEQ7TPPPCP/+9//LMSsDsVCQsq+iTpVC28p mJHXX39d1LnIJZdcolsgqlkeBXoWokN/9Prkk08sXEroFJ0V5JWkWtE1wrsKnEQBrtmKG4SNlQUy Wdgamyg7Kv/6179EWUp7TYYCVVEwLgpqRJ262Z8wMyFPwqLUlVCYglqTo87Q9FMWSnr37m0yFDCK Mn0WwucZn6gnbXv22Wf7S6LMiihoE8rlvrKBomyvdOrUyUL5hOcIUSoYFAVhpv/AgQPNFupMRVkU UfbGbI5dsRWvI1LHaSHP448/3tqUMLOCiaI2VdbP7E/4Htm0ozprC4ur87Z6stWA6yT6ggIBk6Es s5XDde7/5z//EWUzrc/QNwnzUxfy7ajEWFFAUrRFAD3p94S82Yrh26VVq1ai4NtemZahY4q+iz2x AaFJ+oAPwfrx4G1C3Qj7Yj/GEEnZe7nvvvtEmUfroz4UznhWwG593DLqPwq8RFl0s5viGCuTccU2 DWVRLRv6UR79lX64vRNlU28+1EkXAKKLAxv/sVsoCGezrQDbkbCfAke58MILRcGcjY+TTjpJOnbs KNdcc41cccUV1qfpl8x7hLupuzKqJl8XLrJmzRqhD2uEQnThZHMWY4K2JWReUVLJM20Z1+7nXwpk 8Ht58rqCok8V7LRskCR5ClS0/0q8NvSoZ9Kk/92VJE3B1ievpcsHwxSoNEiUSVNC8kCvSrJv9QQZ 1K+y3HhtqjSqq78fqFwE/lCVPWo3dUuVZvWT5K7bKskvuseu/QlJMkaB15svVpHsfKfAJmJgpsXB iTJxVFVpe3ySZK4XdWQiWblOru+aKmNHpsvZLZLlozEh+W1hgbRrmSRjR6XLyFfSLN/3swqk/6Bc Of3YZKvHMwoUf9F85H3qjTx59r4qdv38dskyc3ZYO6RIXqiwjJJMStn5aoMs1WPkuHzp0iFF3nk1 XXpcmCrrs/U5fShHQeRdV6fKJyPS5dyTkuX+x4ojMitDAeqTvSvLKNUzYUOLDnwyVxrUT7A6PTeg iuRpnqhtEqaOLpgkPa1QMx1nBj6VNdS9lgnS48oUSU2Js3qXpHtwrWJYQENv5jABUBpOsX1VY8eO NefPJMz+PyZfZf7MifANcPFOaXNWYOLGsfAh4Wx8AngCOAA2JH/Pf/t8/htQAGjT8JTtdwJw4BDu ueceex/b448/bqCPCVvDXnZPw2rmPAYPHiyAI76VTZEPP/xQlPUQDTObbuwxAwyRH33IB3ikTMDP e++9JxdccIEBr9L083ryDWDhWWQoo2mOVpkFc644ag0Fmq4Aw48//tjkshcOhwQYwmkpa2ff7M1C B3RmPyfOCT2RQV2VYbX2waHjmJTdLQIZXiee8/s9cYzKAJlTRCZAgvbBCWqoXpSptTLoA8p62B6t p556ysAG77wDEH/00UfCfcrv16+ftYGGYq2PAEZxnjhjbI1Tjd6TyN40wCMJ4E69+Ruww75E6goI xn7Ymj6ITXDyfi8doAQb8GHvKnYksa8OoL4jE0CU/WfUmbpqWN7air/9Pjv0Y98begMY+yhgBYjT b6gzdkEG34BEDWkaaOFvnwB/lOVtSx/mGgCTvkz/wRb03dg+y75J//7CG264QQD09Ev6AftySXyj LwuUv0PCPvQp+kJ0on+wEGilgBXAxgeQhu4shlgQKOtuAI4FKc/zYRyQ75RTThFloq0P0x66RcLG HYs9wDP9l0URi7bbb7/d+mF0+Tv77410UDnWZKEehKitrBKsmraXtG+bJJ9PDBsAzKgZb9cp/tij E+XKm9crYyUye1FYLj4lxbSK12cAOvgPnucDe3bJteslP+SkyeGJcoge5gDEkJo3TZQJk8Ny5vlZ kpnt5A/9JCrLqHhHWjZJlF2U+UstFG0y05URbHF0IUXX8NAEma0HM45QmZ+ODZkMGLRlWXQ+J4tX FMiNCo5IHDbhM1HLqpUeL8eo/qS+dxW+kHfcF2FJUrHU/+rbshX0OmmsNtAa2MRmmfWfNN1/C+jr /1KOPPVanrRpniQXdIrXTqrMX7V4Obl14cBvp9+Tvw3L/QNyZcyEkNmh+3kplqd5s0Q7+IFtAHoL tMxzTi18DrsfUTdRNMwtnbqtlz/08MsBGQkGwmE+SdgWW6Yo6PMJewWpYlsAYHLllVfKZZddJmw6 hyGDBYCl05CaVR7mCQcDaGOyBGzAPF1++eXmtJh0cdixiYMmpJLuadjOJuJopxb7fPTfTP5Vq1aV hx9+2BwjjhWw0q1bNxkzZoyBQJg+WCrqhAMDvFI2YBV2iuuABhKb3XkeBwfDgeNEJxwzQIqycA4A GurBwQMNp0WrVOpvHDEA1QMWwA3OPTqxeR3w1bVrV3Ns3PfAiXKwN7rDGsHmeJkaUjNWBqAEU4sz g/GgbuSPLYcyAQrRQBtml8/TTz9tIBz7wNRRd8Ai5dPmJJwfQA8bwbbBvvDScRhSmCUNi8lLL70k Gno058h96gHIwI6xG+1pE4A/CV05uADzhS0AIzCV9K9o0EK9cPSwPCTqjB1oO/oDLBgMLrI4EEBf 2ZoFigkrp38AyhdffLHA1GJDbE0b+oQdopmsktoNIAdTzDhjjI4YMcLAO7ZopYAH8OftRN8F1AB2 YLH//e9/mz1oB/IDImG5AJwscGgD2DDGDn0J2wEAvR7IQt9oHb3uZflNHegvLLCwCSwu7DA6RyfA GXWlL0Qnrt12222i20+KdGfuIrGwgPXWPYXGpDMOyI9s5PTo0cOYb4Agiy6AJIn73g60H2AQppDF J4vLipS2CwDksE22kgAAKIDYaj1d6oGHBxmc4L2uX7Y8cnNlaXJkggx8EpResqlZCFXX0OY13VIM GNbZVUO3cwq0cQvz9+2vAGlySAb0LGQKO14GPVx4049Bn5cn+O3LQi+Yr8eeypURn4Tk0V6VhZPH na/I0k6jq1a1GOCTtGaNkyHD86XR4QmyXuume8514oxTQBjR08gRqaPhboqtUSPedMUH7Fo7Toa/ HbKOiAy6ebYC3kMPipexQ6vKrB8ickc/vdBfpM/tqZKroAy5gFZOTwOE2yoQPGzDyeKauxCidgam fZ0YO9RhsZ6IJum4ksUrIzro4+TSi1L0b2cnkF8Zli/zfi5EgLnKgq7Q+mDLIFUcC3jnWVqNdF+a OUtWy5yq5ANzgbPAgRMGvP7664vAjJfDJItTYUIFEBAm8WyEzwMD5k/7MqlGn3okP9dY2W9Nohye h+WhbAAHABV2ims4DSZqgAsMEYCCuvMcH4AIzpBwJb8BsDgVgJOf7AEO5CXBGHZVcIZ9cA6wc4SA tiZ5B+KBCN8+eQeGDoRhAa0kmCwYMEBVNFCI1g05OGScOM6belMHTnNy6pr7OLnYhP49e/Y0Noq2 gtElESpHPmDJl4N8wKFP2JHy0BumyCfyYGvAKcxIPWUHuQ/4gH1BHiAiFgBiX18W+gLcsAMJ0KsH AwwE8k3ydQKAwm4C9gDX/AY4YDfykGAJqT/235EJ1o0FFezsRRddZKpwqp1+6RPMJyC6tESon/7H gkX39lk2xiZjkfrR3rBb2Jw2oD8D6gDGsNuAIsYL5dM2gHrCoIxR2hiAyPYHTk8D/ki0J/2eRPsC sCmnPBN9gcUai05+swhhYePHiS+buYSIgmco/XW+6Q8ZGRnRl+w3ixNksRB74YUXbG7zmVhEUG9Y 8AULFhgDePPNNxsrSB4/jnhzACCZNxUwhpgPdN+iF7PTf28XAHi4hnOrK7N8U88caXdikjzwQq60 bZJkYCZXWTGStocojjFg8v2siLz5Zb6ceXSydgoFMBvy6DwlK9c5eerFfANHp7UrZLh4fsZMDTVt AIxZCpgqJeNw4uSlIXny/e9hydTFIyAvtGERxr4+wtAkQNYGfGhACjmArpSkOO1wcTJUw7vTlxUy lm2OTZJeA3O0g4gMfTNfFum+vAs7pUkNZfFu7Z0tZ52aLNfrvr8rOyXL7rvF2/5DwqynKuvp06vD WV0VAk/Kpo49+qhtWiRJe2XtqmqZ6SqP+v6e5eSW3jlyge5r7P14rnTRvXlHNUqwD/IIr2cp+Nzg t3QPIHs6RLp2TpZLe2VLNd3XOGlqWOavVQZFAeCxLTY2eY6Cvq66B7HZiASZoACccmkrn8xeG2zq rwXfO48FcBQAORwRv3GUnsViAiSxH6hDhw7GquBcCR3x6hfCozhwnACONTbBkLHq9gl2AvACI0N+ wodMmqy+AVmADcLMgAnCmLAO5PVsEMAABsA7cy/Xf3MduT6cDFgC8BHWYYIGAAIGqQusHcwZAAmZ PAMbANBh8mYlTyibugMsYE9IlOF/8ww2wrniIHQzv+gJZbOJt53XLfZZHJmXwz3yc43yCZ8CsNmP BENEKJXrOHZsCPjD7iR+R5dFXWBhaUPsCpADCBPqg/kBDLD3sU+fPgasTIj+07lzZ9tTRngLx4+T BdCOU4YJFoT28OVgE0LEgwYNsrqzMIChA7DArsLQAPJoU5gtmC72/ekhBAu5oTPlR9ff68E3YARZ JGzi2xRQQv9DP8ATfcmzUOSlrWEG2bJAfSifEDMMMsCRBIPtGS+7sAP+4bVGsHaAEphjxh4LFthT dGbLAjqyNcAzTqjp+x59gXaEEaOtaRcWCQDl7t27F3uVEYsr+j8AEfvAirMg4FnaDwDEflRC6tjd J7ZLAKh4FhBJGdiV9gRwAlbZj0oYmq0B5ZUolzam7T3gpyxAG6+iod7kYU5ikQOwjk30MxhN2h4b Mo9g7/POO89YUxaYbFNgkcGHduAZ7IzNAIHsCWScMzeRuA+rzRwCkGbuoM/RBn6+itVjZ/07QQdr n7JSHvqd0Irfb+Llwtid0SZZxmvYd5oePOhwcpK00JBlAw23FqgfaqGhU1i2aglx8u7HIV3ZiXTT /XCwXs2bJklI/Q+sl/owqamh5G9nRuR4BTLp+tsn7u2iYOeoRolynB6SmDO3QD4bH5L9902Qto2T ZF/dJ1hH2TdCxfvsHW+yauihh2ZNEiRzlcjJumeQd/Ox8W7XWvFyadcUma8yxqiMvfeMl1MVjO6l hzIuPj/Z9Hl/dEhq68GMZx6poh0jTtrrvr/JU8IycUpEzj0lWa67KtUYwzgFei2bbwRV6BvW+f2A /RLkwAOUOdS6Ag5PUvA3bkJYvtRw8vFqm566lzESiZNXlWE8/IBEmTI9LOe0TZYbrin+7iJ0ztFI 2yltCu2TpSwe9mxwSKLUrZkg45UJbahs4UplAy/SAyu1VGef6tdLkPp1EmTEe/nGzA56qLLZ3N93 CiT31ncK7l+/OO3u7wfffw8LMO4AZLHhVEAMDM5vv/1WxIrhCFjVwg4wIbKq1tdAGChhkmVCxmkx 6TH5wrLgHLY08eF4yMu75mAhkIkcVt9MqOzfwyHBggDWAGmAFp+YuGEdCCczGccmgAVggRChZ5Vg RJCLoyR8CJgCDHKdaQ3HQujTy4QJg1nB+XIN5gobsdrnoAplkJ98OAaAEqCM8C8byrExsnE0gLBo pglbIQuQxTfgBjkkHDrOBMYH8ISNPTODAyYcTKiJfVh+/qRdsCl2x5bePvwmH21KuB5b4CgBFdSX fXzkwQn6RL8gFEZe7APgI/wNiKQeABNAFIwvzp9wMGExnDDADuc3evRoWwygH+3kD4TAKrHIgEmB XcTZ4kgJ12KLWFYYHQin6WlTszf3yYdDJtHvYKZw3DCJAE50os8QfqM/034wVQDCRx55xO7TJhyC APz4wxO+/uXxTRvTHz349GUQQueD/WHl6O/0K+xPH4P5xv4wSXrK2T9mfYZ8tAd9mnFE/0MGiyfG ELaOZsZaaRiYQ0IcymIxxr5Q7JSRkWGHdpDDGATIRSc9kWxghnZncYNNWdygI/2MtkcOz25p3EfL Lek3NqJtSpJDXwLEom90YtHp5xLmDPoj/aqkA1h+XsFGfLA35TF+sA37hJnv6O/0U2xOvVlsYE8Y ZBZlAHbmDPouQI+5kMUh/Ym+z4c9gYB2P/9E67yz/o7TBi+k4MqgBuyzYYLTd4wVk/bWqJABkUQF eNo2Box0frTQZYoydTBRcYpL+M195gL+5ncorEycXs/dwHLxm/vsp+O+TzqP6GnZwnwardBQ7cay yIMcDpxQ2ZCyboSiOTDBvjfCpV5ekrJ+WrTplqy/vb7IgDUMb9DH64lc6uLL99eRh57IoH7RiWtc QRZlUzevjy+P5zOVtXxrcr6cqwdTqil7hzxvBy+Pa9H2QR46TVDAWEXB4TFHJsoqQtWf50n7xslS I+oF0djYdFFlkONDyV62twU2uu6K1K1+cbd/PvjePhZg3OF8o0Os26fkoJR/igVglwC5gMZtSYAc gBwnr2FryyrBOOOcOVRTUpiwrMrxcgDnAOFoZs3fC743WgCQx4KnPJnEjaUFv/6sBYpTU3/26a3M X0/Zt/z8wqIAHZuDnFu6v5VFWraykFWajD97fWv1jpYLcMzJS5KmGvIlfLs5u8XKb6HM6cgP8+X9 L0LCIZeBPSqbDABmbIouM/ae/3tL/7OKzxd8BxYILFDxLBAdKt+W2sH46TsjLZwH4+SZv22RybMw OTC62wP8bauuwfOBBf4uFtguDODfpbL/RD1gJ2FEg1RxLRAwgBW3bStqzWACY8PD21LXspa3JV0C BnBLFiq8HzCAW2enHZVLA39BqsgWCMBfRW7doG6BBXZOC5Ql+MMCZS1v57RqoHVggT9ngQAA/jl7 BbkDC/wtLcC+1SAFFggssH0sEIy37WPnoJTytUCZ7gFkUIR1j1muhh0JPQYpsEBggfK1APs3eXdl tp4sL9DR/Gf2iZavZoH0wAIV0wKMuRx9uwO+jnEXjLmS2xk75WMnxQKBnUq20Y6+WqYAkMrgjPL1 49+3t6MrGJQfWKAiW4BJlndY5rHg2vBuyYpc36BugQV2tAUM2EByqJ+D7OB1WUHa1AJxvFlCbcOH +amkA4ibPhVc2Z4WKHMAiPLqk+yzPSsSlBVY4J9oAcYaKRhzhXYI/g0sUN4WiB5rfvyVd5k7o/xo 20TbbGesS0XVOdgDWFFbNqhXYIHAAoEFAgsEFggsEFigFAv8H27RX6XRf9xrAAAAAElFTkSuQmCC --Apple-Mail=_B6390633-46EF-474F-A187-1DB15174D933-- --Apple-Mail=_4C38A861-185F-46E8-BBE3-123B3B4B4EA7-- --Apple-Mail=_D63CCE3C-31A5-44D2-AE26-B497F4A74723 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFUDCCBUww ggQ0oAMCAQICEC1TBxluVeE64egyuL9kyAswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA0MjUwMDAwMDBaFw0x MzA0MjUyMzU5NTlaMIIBDzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5EaW5vIEZhcmluYWNjaTEdMBsGCSqGSIb3DQEJARYOZGlub0BjaXNjby5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9C2Rwk3CLn526Rfiko9M7MSu3hBqq CIS0awvIVS8L03TFgzWm6JjkWAcus5ZR15+GMI3zvtVWbFVl/7lk8ZX2p7uySe5uXpAYSICeVlx/ sw5YsM5+AeCa1DjpzHoVGsFJA3LS/sugZ14TnwhsKxzvcqoPIJNTmQE6jAvUkoA1XV+OyMKM41Pd HiWMTf1dm1BdN8F/fcNVE6ttv1IQnTb7j8EI9stRLuY7otrJljUHNYmzAMfYpWwDk6JkGyYK6fwp oTR5Ibj0DRZsUYE+YIwbnW6uwTLWyXLod5sGOqdEMlk3qD7vQvCP30F+XsDRb0ii2dtUzMqKY1Ul r6fik/EpAgMBAAGjgdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCow KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5k YzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAAoX+IDg7qDqyr5O1zZX82v3TevLknKVcuJ1cOsZadb23w7B1g2fD3Ou 6j+AoLSj83Vqdir4BSapmv4c7MuVfynKcazZhSGdIT/yXV4DG75/I72vP4aLVgNlvV5bh8RFtOpI Ce54TIFQOnTXIhxS8Jp4w0mGVrTMm6RlFUYZCbVNR09k/fx5SjIJhwRKtmRd1jicbknRC1vbKj5v ugx8fjwwxtS/Im3V9ocnYCMqvH69dUWq9kDcg67dskUdmm1Tqzn9QNdVDkRgwweYobo1VInSijkC /Shj6NLAMfyWdeFRIEyiSfCEBUHCwnU1Zh39PtKjO4edRGcZzPt7401CNpExggSLMIIEhwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAt UwcZblXhOuHoMri/ZMgLMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEyMTAwOTIzNTAzMlowIwYJKoZIhvcNAQkEMRYEFANvdaqH1dBQHoWH YtEit5DRCLGQMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEC1TBxluVeE64egyuL9kyAswggEFBgsqhkiG9w0B CRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhAtUwcZblXhOuHoMri/ZMgLMA0GCSqGSIb3DQEBAQUABIIBAG+dYNALz1xj9IUw7HlC TizBtAC1afRWK5Vo6LtpzEO1ei0Dz/bYxHykSYnyR5k/0grX1gydD7XoQJamxoU/tK9p++sc5NAV 5TFmucLeS8NvXSSwcxTOR2M2tqq9YTXA8gwWz7nezRtnrG384Uje9nzXS7WK4DgIPJRZzer9ew0Y 4z4hlqqRQqIvmv0AAZ8NVpmyzj79HsJa5jfMcN119nfzdZPi6+3DE4BNtdJ34vk3XntevvMig66x 8AT+9OJv43sQvyZmmpcR3CdpljgL3QdqGwggfV6QX3woXcYWAevwGYoFShFnlfnrzLOLXi+G5KYo /qclLbRmr6QgRy+OnCcAAAAAAAA= --Apple-Mail=_D63CCE3C-31A5-44D2-AE26-B497F4A74723-- From sander@steffann.nl Tue Oct 9 17:03:56 2012 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 B976B21F8540 for ; Tue, 9 Oct 2012 17:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PWrKFVBYSs7 for ; Tue, 9 Oct 2012 17:03:56 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id BECA321F84A6 for ; Tue, 9 Oct 2012 17:03:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id CA921205D; Wed, 10 Oct 2012 02:03:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUsq-6VXy5F6; Wed, 10 Oct 2012 02:03:46 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 3E71E205C; Wed, 10 Oct 2012 02:03:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <83522620-E029-4689-8779-AB630B0E11D6@cisco.com> Date: Wed, 10 Oct 2012 02:03:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AB7F2ED-DAC1-4C97-8F9E-DF7038F7F9A9@steffann.nl> References: <83522620-E029-4689-8779-AB630B0E11D6@cisco.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org list list" Subject: Re: [lisp] Can draft-farinacci-lisp-rig-01 be a WG document? 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 Oct 2012 00:03:56 -0000 Hi Dino, > >=20 > WG and chairs, I would like to request/suggest that the above draft be = made as a working group document since it is associated with = draft-ietf-lisp-ddt which just became a WG document. >=20 > Comments? Since draft-ietf-lisp-ddt is now a WG document I think = draft-farinacci-lisp-rig-01 should be a WG document as well. So: +1 Sander From jmh@joelhalpern.com Thu Oct 11 07:46:04 2012 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 9980421F8470 for ; Thu, 11 Oct 2012 07:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.506 X-Spam-Level: X-Spam-Status: No, score=-101.506 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x1mS5-MzuFl for ; Thu, 11 Oct 2012 07:46:04 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0715F21F86C6 for ; Thu, 11 Oct 2012 07:46:04 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 949DB55A72D for ; Thu, 11 Oct 2012 07:46:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 4FE0B1BD9169; Thu, 11 Oct 2012 07:46:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-61.clppva.btas.verizon.net [71.161.52.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8EE631BD9168; Thu, 11 Oct 2012 07:46:01 -0700 (PDT) Message-ID: <5076DB9C.2070708@joelhalpern.com> Date: Thu, 11 Oct 2012 10:45:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] LISP Document progression 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, 11 Oct 2012 14:46:04 -0000 Prompted by the request for WG adoption of the LISP RIG documents, the chairs and ADs have consulted. First, the bad news. No, we have concluded that the WG should not conduct a call fo support of adopting this document at this time. The reason is that our carter calls out very specific short term deliverables which are gating for any other work. We are not seeing reviews of any of those documents on the list. We need to finish those documents. As such, the chairs and ADs have agreed that no new activities can be accepted on the working group plate until those gating documents have been completed y the working group. In supported of this, for the Atlanta agenda, we will only provide time for items which have been accepted as working group items. As for the bit of good news, we did conclude that one the blocking documents are dealt with, there should be n problem with having the working group decide if it wants to accept the RIG document. Yours, Joel M. Halpern From dino@cisco.com Thu Oct 11 09:02:10 2012 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 7470F21F8740 for ; Thu, 11 Oct 2012 09:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyya-CAA3ILJ for ; Thu, 11 Oct 2012 09:02:10 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 11BF421F8734 for ; Thu, 11 Oct 2012 09:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4423; q=dns/txt; s=iport; t=1349971330; x=1351180930; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=eCenUkuKDkAosXfY6PVu9ll+k7GKqJe19wtCu3oF7mg=; b=WJr54m3hvZS1IghORVRYlb/fLtVCJufo1HSthZAB9rJU2S8MOECV2lkr RQP+nXvb3yRLPgtN7DW83jyp8zl4cq9jguW444sR9X6W2UsZh/a0QpVXr L2UmeEBIy3yHotf5QKZ1iDGfBhSb/hza8NktjNfYLg2DYHl9l1I2u7+bx 0=; X-Files: smime.p7s : 2585 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABHtdlCrRDoI/2dsb2JhbABEv0qBCIIgAQEBAwESAWYFCwtGAlUGLQiHXAWZeaAokQdgA4hYhheGfoViiGOBa4MN X-IronPort-AV: E=Sophos;i="4.80,572,1344211200"; d="p7s'?scan'208";a="61067623" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 11 Oct 2012 16:02:08 +0000 Received: from [10.154.200.154] ([10.154.200.154]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9BG27lm002310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Oct 2012 16:02:07 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_CB61EBAD-478A-4006-BE1B-72EFB6B1C0FB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Dino Farinacci In-Reply-To: <5076DB9C.2070708@joelhalpern.com> Date: Thu, 11 Oct 2012 09:02:10 -0700 Message-Id: References: <5076DB9C.2070708@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1486) Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP Document progression 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, 11 Oct 2012 16:02:10 -0000 --Apple-Mail=_CB61EBAD-478A-4006-BE1B-72EFB6B1C0FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > As for the bit of good news, we did conclude that one the blocking = documents are dealt with, there should be n problem with having the = working group decide if it wants to accept the RIG document. Can you retype this sentence so it is more clear what you are trying to = say? That is, is it "one document is dealt with" and which one or "once the = blocking documents ...". And "should be n problem ...". Does that mean "should be no problem"? Dino --Apple-Mail=_CB61EBAD-478A-4006-BE1B-72EFB6B1C0FB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFUDCCBUww ggQ0oAMCAQICEC1TBxluVeE64egyuL9kyAswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA0MjUwMDAwMDBaFw0x MzA0MjUyMzU5NTlaMIIBDzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5EaW5vIEZhcmluYWNjaTEdMBsGCSqGSIb3DQEJARYOZGlub0BjaXNjby5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9C2Rwk3CLn526Rfiko9M7MSu3hBqq CIS0awvIVS8L03TFgzWm6JjkWAcus5ZR15+GMI3zvtVWbFVl/7lk8ZX2p7uySe5uXpAYSICeVlx/ sw5YsM5+AeCa1DjpzHoVGsFJA3LS/sugZ14TnwhsKxzvcqoPIJNTmQE6jAvUkoA1XV+OyMKM41Pd HiWMTf1dm1BdN8F/fcNVE6ttv1IQnTb7j8EI9stRLuY7otrJljUHNYmzAMfYpWwDk6JkGyYK6fwp oTR5Ibj0DRZsUYE+YIwbnW6uwTLWyXLod5sGOqdEMlk3qD7vQvCP30F+XsDRb0ii2dtUzMqKY1Ul r6fik/EpAgMBAAGjgdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCow KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5k YzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAAoX+IDg7qDqyr5O1zZX82v3TevLknKVcuJ1cOsZadb23w7B1g2fD3Ou 6j+AoLSj83Vqdir4BSapmv4c7MuVfynKcazZhSGdIT/yXV4DG75/I72vP4aLVgNlvV5bh8RFtOpI Ce54TIFQOnTXIhxS8Jp4w0mGVrTMm6RlFUYZCbVNR09k/fx5SjIJhwRKtmRd1jicbknRC1vbKj5v ugx8fjwwxtS/Im3V9ocnYCMqvH69dUWq9kDcg67dskUdmm1Tqzn9QNdVDkRgwweYobo1VInSijkC /Shj6NLAMfyWdeFRIEyiSfCEBUHCwnU1Zh39PtKjO4edRGcZzPt7401CNpExggSLMIIEhwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhAt UwcZblXhOuHoMri/ZMgLMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEyMTAxMTE2MDIxMFowIwYJKoZIhvcNAQkEMRYEFG4RpoWhL8mzU5P4 8oenm8t6LxabMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEC1TBxluVeE64egyuL9kyAswggEFBgsqhkiG9w0B CRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhAtUwcZblXhOuHoMri/ZMgLMA0GCSqGSIb3DQEBAQUABIIBAJOe2mx+oY1UU9z4KjXE Ym9YxRV3558qaQD/xyqYect7Mz8iL2yJnSL0KufwapwaLe4vEEablhIYg28Vv1EIQcAselTRC2ZO xgNQgB5UEobwIjX68+379UXRIlQqcNc4OOJyjSKc3qbq0rTCZl4HO7h1vSVsy5i24ZHdabMzFrhn m2+s+XJijPoxRoSHTmbhB3p0hLgYyFV9RVUPx/Pb3Ye9T3ceTvI8eH/0Dgt4UypBKmbQA4faHK62 GiQA09AN3c3g7NungNtbOjMDRkUSsbyk7hQzSu0Zh+9srQ6vtMzuCkLKW+m3cZgju5EMcoq0mgv+ eDNzQPR32UnEAQDscUMAAAAAAAA= --Apple-Mail=_CB61EBAD-478A-4006-BE1B-72EFB6B1C0FB-- From jmh@joelhalpern.com Thu Oct 11 09:07:50 2012 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 0838521F8533 for ; Thu, 11 Oct 2012 09:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-ymC52lA2BA for ; Thu, 11 Oct 2012 09:07:49 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A077321F852B for ; Thu, 11 Oct 2012 09:07:49 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 7383058FCFC for ; Thu, 11 Oct 2012 09:07:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D05611C07E5; Thu, 11 Oct 2012 09:07:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-61.clppva.btas.verizon.net [71.161.52.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 463041C051A; Thu, 11 Oct 2012 09:07:48 -0700 (PDT) Message-ID: <5076EEC7.6000706@joelhalpern.com> Date: Thu, 11 Oct 2012 12:07:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Dino Farinacci References: <5076DB9C.2070708@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP Document progression 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, 11 Oct 2012 16:07:50 -0000 Sorry, that sentence is "once the blocking documents are dealt with there should be no problem with ..." Yours, Joel On 10/11/2012 12:02 PM, Dino Farinacci wrote: >> As for the bit of good news, we did conclude that one the blocking >> documents are dealt with, there should be n problem with having the >> working group decide if it wants to accept the RIG document. > > Can you retype this sentence so it is more clear what you are trying > to say? > > That is, is it "one document is dealt with" and which one or "once > the blocking documents ...". > > And "should be n problem ...". Does that mean "should be no > problem"? > > Dino > From terry.manderson@icann.org Thu Oct 11 22:16:17 2012 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 E322E21F8504 for ; Thu, 11 Oct 2012 22:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r4HzCm4zKPU for ; Thu, 11 Oct 2012 22:16:17 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 610DE21F8501 for ; Thu, 11 Oct 2012 22:16:17 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 11 Oct 2012 22:16:16 -0700 From: Terry Manderson To: LISP mailing list list Date: Thu, 11 Oct 2012 22:16:12 -0700 Thread-Topic: Agenda Items for LISP in IETF 85 Thread-Index: Ac2lrgRhdmNNpfVNc0yvPSEQSTr84QCiq2GH Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3432899772_987053" MIME-Version: 1.0 Subject: Re: [lisp] Agenda Items for LISP in IETF 85 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 Oct 2012 05:16:18 -0000 --B_3432899772_987053 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, This is where I get to re-state the request for agenda items based on the Chairs and AD agreement to focus on priority documents as required by the LISP charter. Only WG drafts will be allowed an agenda slot at IETF 85. WG draft authors - I would like to hear from you sooner, rather than later, if you intend to provide an update on your documents. The key items of work that I would like a status from are: The two recently adopted Intro and Architecture drafts (that is their WG version documents when they are uploaded!!!!!) and draft-ietf-lisp-deployment draft-ietf-lisp-lcaf draft-ietf-lisp-sec draft-ietf-lisp-threats WG. Given this effort to re-focus on the charter deliverables, I urge you all to read the above drafts and bring forth your review to this list. Cheers Terry On 9/10/12 9:38 AM, "Terry Manderson" wrote: > Folks, > > There is a smidge over two weeks until a WG draft agenda for IETF 85 is due. > > "2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00" > > Please email requests for agenda slots to this list by 2012-10-22 (Monday). > > If you have been watching, you will notice that an IETF agenda is up, and we > have a 2 hour session on Tuesday (6th Nov) afternoon (1pm-3pm). > > Cheers > Terry > --B_3432899772_987053 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUkKQxaSmdR21cVCVVAV9OYPFOWT8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDEyMDUxNjEyWjANBgkqhkiG 9w0BAQEFAASCAQCiSPSZ+w9zTp1ipecdHonQO0tch+4t2GtUMSEwc6WM3GAFPlF5j1HIpz10 y1OnBG079SgM2DOaDIYLKOaLNCAy+2EWTd4K0Ph5y5l4aAnQQYldkVRvJhbTAW9nmK+8zZsX GolW8y0/HK3ea71jFQTIWElDxR2n0XpC/vTbWJSCOOTu/b0UYtgguoCGktYX1+LligBtJ3jr 3Ivb/e7Z48aR2VuEKbBrf4uM81fp1nIiRwP3/zqKKZwT5kH6hrFoNGivQRwiXj5u/fxWIH7L 8KnwP2cbRSdOpqiz3L6y0rm/d65LC5S03GyxnAbU8icKJeFEhX0WsM/zYXaNf89sPHzb --B_3432899772_987053-- From internet-drafts@ietf.org Fri Oct 12 15:04:42 2012 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 7F97D21F86C4; Fri, 12 Oct 2012 15:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKqdvN2xdwB4; Fri, 12 Oct 2012 15:04:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF7121F8691; Fri, 12 Oct 2012 15:04:41 -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.34 Message-ID: <20121012220441.22608.49006.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 15:04:41 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-sec-04.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: Fri, 12 Oct 2012 22:04:42 -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-Security (LISP-SEC) Author(s) : Fabio Maino Vina Ermagan Albert Cabellos Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-sec-04.txt Pages : 20 Date : 2012-10-12 Abstract: This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-sec-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-sec-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From damien.saucez@inria.fr Sun Oct 14 02:56:43 2012 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 3F71221F84F1 for ; Sun, 14 Oct 2012 02:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.182 X-Spam-Level: X-Spam-Status: No, score=-8.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dWUJKHsqBL6 for ; Sun, 14 Oct 2012 02:56:42 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5C721F84EC for ; Sun, 14 Oct 2012 02:56:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,583,1344204000"; d="scan'208";a="177142230" Received: from 25.82.69.86.rev.sfr.net (HELO [172.16.139.253]) ([86.69.82.25]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 14 Oct 2012 11:56:39 +0200 From: Damien Saucez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Oct 2012 11:56:37 +0200 References: <20121014095554.29054.1947.idtracker@ietfa.amsl.com> To: LISP mailing list list Message-Id: <7FC610CC-E73D-48F6-BB43-BD2EEEDBABC1@inria.fr> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [lisp] Fwd: New Version Notification for draft-saucez-lisp-iesg-statement-00.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: Sun, 14 Oct 2012 09:56:43 -0000 FYI Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-saucez-lisp-iesg-statement-00.txt > Date: 14 Oct 2012 11:55:54 GMT+02:00 > To: damien.saucez@inria.fr >=20 >=20 > A new version of I-D, draft-saucez-lisp-iesg-statement-00.txt > has been successfully submitted by Damien Saucez and posted to the > IETF repository. >=20 > Filename: draft-saucez-lisp-iesg-statement > Revision: 00 > Title: LISP IESG Statement > Creation date: 2012-10-14 > WG ID: Individual Submission > Number of pages: 12 > URL: = http://www.ietf.org/internet-drafts/draft-saucez-lisp-iesg-statement-00.tx= t > Status: = http://datatracker.ietf.org/doc/draft-saucez-lisp-iesg-statement > Htmlized: = http://tools.ietf.org/html/draft-saucez-lisp-iesg-statement-00 >=20 >=20 > Abstract: > The Locator/Identifier Separation Protocol (LISP) relies on three > simple principles to scale the Internet: address role separation, > encapsulation, and mapping. In this document, based on > implementation, deployment, and theoretical studies, we discuss the > impact that a LISP deployment would have on the Internet and for the > users. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From damien.saucez@gmail.com Sun Oct 14 03:07:46 2012 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 3754C21F8504 for ; Sun, 14 Oct 2012 03:07:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T5SJGipt4Qf for ; Sun, 14 Oct 2012 03:07:45 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1119321F8503 for ; Sun, 14 Oct 2012 03:07:44 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so787172wib.13 for ; Sun, 14 Oct 2012 03:07: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=6Mc1OeFo/d5nCAeEsUckef4BG8Sw3TcTtYVB4ytJ7KI=; b=X/xHdMaoVq3oQ2OD6hc9RowOE6MAb9CnTN9Vx5cv7U39hY9EWh9IbklFER7cpd7zrN k1S8xgsf64Hdnk1LkCtrBerZtEx8xJXUHQIyc+iP4LmCcVKuqOZlCIRYCevq2n+/vgd7 XueYQuhcGiTDAxXIirpjgwfB/4ohLLF834CjSN+WRzoOvk3Yzlp7yd9Nf025rk0h3ATf iDxjfIqouVqjMi2rt2rSKvLVYau1t05xLmf18YsGk/LTK352SoutsKWhrBS3tZeg9JrW kREwv4HN/3wUPiGP83qSdqJFEVDq7+nQj4eGM/2dYISFWR+IIKLVQspGwsJRSwMWroH8 TKgA== Received: by 10.180.100.136 with SMTP id ey8mr16798993wib.1.1350209264186; Sun, 14 Oct 2012 03:07:44 -0700 (PDT) Received: from [172.16.139.253] (178.82.69.86.rev.sfr.net. [86.69.82.178]) by mx.google.com with ESMTPS id cn6sm8883009wib.9.2012.10.14.03.07.41 (version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 03:07:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: Date: Sun, 14 Oct 2012 12:07:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B02B7C0-863F-41BC-9F14-68A6C5920B9F@gmail.com> References: To: Terry Manderson X-Mailer: Apple Mail (2.1499) Cc: LISP mailing list list , Luigi Iannone Subject: Re: [lisp] Agenda Items for LISP in IETF 85 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 Oct 2012 10:07:46 -0000 Terry, Can we have a 10 min slot to present the implication document for the IESG. This document is important as it shows we are making progress on clearing the WG milestone associated with this document. > A new version of I-D, draft-saucez-lisp-iesg-statement-00.txt > has been successfully submitted by Damien Saucez and posted to the > IETF repository. >=20 > Filename: draft-saucez-lisp-iesg-statement > Revision: 00 > Title: LISP IESG Statement > Creation date: 2012-10-14 > WG ID: Individual Submission > Number of pages: 12 > URL: = http://www.ietf.org/internet-drafts/draft-saucez-lisp-iesg-statement-00.tx= t > Status: = http://datatracker.ietf.org/doc/draft-saucez-lisp-iesg-statement > Htmlized: = http://tools.ietf.org/html/draft-saucez-lisp-iesg-statement-00 >=20 >=20 > Abstract: > The Locator/Identifier Separation Protocol (LISP) relies on three > simple principles to scale the Internet: address role separation, > encapsulation, and mapping. In this document, based on > implementation, deployment, and theoretical studies, we discuss the > impact that a LISP deployment would have on the Internet and for the > users. Best regards, Damien Saucez On 12 Oct 2012, at 07:16, Terry Manderson = wrote: > Hi all,=20 >=20 > This is where I get to re-state the request for agenda items based on = the > Chairs and AD agreement to focus on priority documents as required by = the > LISP charter. >=20 > Only WG drafts will be allowed an agenda slot at IETF 85. >=20 > WG draft authors - I would like to hear from you sooner, rather than = later, > if you intend to provide an update on your documents. >=20 > The key items of work that I would like a status from are: >=20 > The two recently adopted Intro and Architecture drafts (that is = their WG > version documents when they are uploaded!!!!!) > and > draft-ietf-lisp-deployment > draft-ietf-lisp-lcaf > draft-ietf-lisp-sec > draft-ietf-lisp-threats >=20 > WG. Given this effort to re-focus on the charter deliverables, I urge = you > all to read the above drafts and bring forth your review to this list. >=20 > Cheers > Terry >=20 > On 9/10/12 9:38 AM, "Terry Manderson" = wrote: >=20 >> Folks, >>=20 >> There is a smidge over two weeks until a WG draft agenda for IETF 85 = is due. >>=20 >> "2012-10-24 (Wednesday): Draft Working Group agendas due by UTC = 24:00" >>=20 >> Please email requests for agenda slots to this list by 2012-10-22 = (Monday). >>=20 >> If you have been watching, you will notice that an IETF agenda is up, = and we >> have a 2 hour session on Tuesday (6th Nov) afternoon (1pm-3pm). >>=20 >> Cheers >> Terry >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Mon Oct 15 13:02:52 2012 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 1756721F89BD; Mon, 15 Oct 2012 13:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXGHnboABafy; Mon, 15 Oct 2012 13:02:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F96121F87CA; Mon, 15 Oct 2012 13:02: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.34 Message-ID: <20121015200251.17696.63821.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 13:02:51 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ddt-00.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 Oct 2012 20:02: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 Delegated Database Tree Author(s) : Vince Fuller Darrel Lewis Vina Ermagan Amit Jain Filename : draft-ietf-lisp-ddt-00.txt Pages : 42 Date : 2012-10-15 Abstract: This draft describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-ddt-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vaf@cisco.com Mon Oct 15 13:06:16 2012 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 88AFF21F898C for ; Mon, 15 Oct 2012 13:06:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeKxRsE2Cbpa for ; Mon, 15 Oct 2012 13:06:16 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 05D6D21F8868 for ; Mon, 15 Oct 2012 13:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=865; q=dns/txt; s=iport; t=1350331575; x=1351541175; h=date:from:to:subject:message-id:mime-version; bh=wPUZceBE42qPxSd/lNeqY0DGNnJawGk36hb6cyrnLf8=; b=D3Pyd7sIyNdkbCTjhEoVTlqu0Zfpz0QKILbSPaISMc6n04H+A8L+6ekj tNLCRSm7fWcw5UBXY18xtQexuAayYsqmIYvU+mea2iQ3Jq+eV25bboIju 8M09itWc2vpaY8fhlVuyzJIIG0m+4Y97siOd8UTcwo1HlbL1cj5vmCQuz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAFJsfFCrRDoJ/2dsb2JhbABFhUu6OoEIgiABAhYBJ2sDAQJDGCECISKHYQGbWYEooB+LWYMcgkFgA4hYjROORoFrgw0 X-IronPort-AV: E=Sophos;i="4.80,590,1344211200"; d="scan'208";a="58291518" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 15 Oct 2012 20:05:56 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9FK5uFn008201 for ; Mon, 15 Oct 2012 20:05:56 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 4040A2A29AB9; Mon, 15 Oct 2012 13:05:55 -0700 (PDT) Date: Mon, 15 Oct 2012 13:05:55 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20121015200554.GA62929@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-ddt-00.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 Oct 2012 20:06:16 -0000 This version contains no change to the text; it is just been renamed to reflect its new status as a working group document. --Vince ----- Forwarded message from internet-drafts@ietf.org ----- Date: Mon, 15 Oct 2012 13:02:51 -0700 From: To: CC: Subject: [lisp] I-D Action: draft-ietf-lisp-ddt-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Delegated Database Tree Author(s) : Vince Fuller Darrel Lewis Vina Ermagan Amit Jain Filename : draft-ietf-lisp-ddt-00.txt Pages : 42 Date : 2012-10-15 ... From internet-drafts@ietf.org Mon Oct 15 15:11:46 2012 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 400A921F8B13; Mon, 15 Oct 2012 15:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OftHwNU9XgzR; Mon, 15 Oct 2012 15:11:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB91021F8B0E; Mon, 15 Oct 2012 15:11:45 -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.34 Message-ID: <20121015221145.6270.14243.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 15:11:45 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-00.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 Oct 2012 22:11:46 -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 Introduction to the LISP Location-Identity Separation= System Author(s) : J. Noel Chiappa Filename : draft-ietf-lisp-introduction-00.txt Pages : 29 Date : 2012-10-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. It is intended to be both easy to follow, and also give a fairly detailed understanding of the entire system. 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 15 15:13:08 2012 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 394D821F8B25; Mon, 15 Oct 2012 15:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUqWjDf07NQB; Mon, 15 Oct 2012 15:13:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FB421F8B20; Mon, 15 Oct 2012 15:13:06 -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.34 Message-ID: <20121015221306.27003.56381.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 15:13:06 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-architecture-00.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 Oct 2012 22:13:08 -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 Architectural Perspective on the LISP Location-Identi= ty Separation System Author(s) : J. Noel Chiappa Filename : draft-ietf-lisp-architecture-00.txt Pages : 19 Date : 2012-10-15 Abstract: LISP upgrades the architecture of the IPvN internetworking system by separating location and identity, current 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. This document gives additional architectural insight into LISP, and considers a number of aspects of LISP from a high-level standpoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-architecture There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-architecture-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jnc@mercury.lcs.mit.edu Mon Oct 15 15:20:28 2012 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 3F24D21F8A10 for ; Mon, 15 Oct 2012 15:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpFCJSZQ5u9d for ; Mon, 15 Oct 2012 15:20: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 596CC21F8A0F for ; Mon, 15 Oct 2012 15:20:27 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 46A5A18C0C8; Mon, 15 Oct 2012 18:20:26 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> Date: Mon, 15 Oct 2012 18:20:26 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 22:20:28 -0000 Hi all, these two 'new' drafts: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title: An Introduction to the LISP Location-Identity Separation System > An Architectural Perspective on the LISP Location-Identity Separation System are identical the July -chiappa-01 versions, just renamed to reflect their status as official WG documents. I hope to have true new versions out shortly, incorporating both comments received here (more about those 'soon'), and some new material to fill in the blank sections. Noel From internet-drafts@ietf.org Mon Oct 15 17:26:43 2012 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 092DD21F8874; Mon, 15 Oct 2012 17:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n3CMNBbQM5s; Mon, 15 Oct 2012 17:26:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F821F8868; Mon, 15 Oct 2012 17:26:42 -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.34 Message-ID: <20121016002642.17758.41173.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 17:26:42 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-mib-07.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, 16 Oct 2012 00:26:43 -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 MIB Author(s) : Gregg Schudel Amit Jain Victor Moreno Filename : draft-ietf-lisp-mib-07.txt Pages : 65 Date : 2012-10-15 Abstract: This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From damien.saucez@inria.fr Mon Oct 15 22:56:13 2012 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 9205821F8909 for ; Mon, 15 Oct 2012 22:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.216 X-Spam-Level: X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWE6uy51-ZTH for ; Mon, 15 Oct 2012 22:56:12 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6691D21F890C for ; Mon, 15 Oct 2012 22:56:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,593,1344204000"; d="scan'208";a="159152287" Received: from 10.189.101.84.rev.sfr.net (HELO [172.16.139.253]) ([84.101.189.10]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 16 Oct 2012 07:56:09 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <7FC610CC-E73D-48F6-BB43-BD2EEEDBABC1@inria.fr> Date: Tue, 16 Oct 2012 07:56:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121014095554.29054.1947.idtracker@ietfa.amsl.com> <7FC610CC-E73D-48F6-BB43-BD2EEEDBABC1@inria.fr> To: LISP mailing list list X-Mailer: Apple Mail (2.1499) Subject: Re: [lisp] New Version Notification for draft-saucez-lisp-iesg-statement-00.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, 16 Oct 2012 05:56:13 -0000 After some discussions we decided to rename the document to avoid any confusion. This is not a document written by the IESG but a document to provide to the IESG, Now, it is called I-D.saucez-lisp-impact to be less controversial. > A new version of I-D, draft-saucez-lisp-impact-00.txt > has been successfully submitted by Damien Saucez and posted to the > IETF repository. >=20 > Filename: draft-saucez-lisp-impact > Revision: 00 > Title: LISP deployment impact > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 12 > URL: = http://www.ietf.org/internet-drafts/draft-saucez-lisp-impact-00.txt > Status: = http://datatracker.ietf.org/doc/draft-saucez-lisp-impact > Htmlized: = http://tools.ietf.org/html/draft-saucez-lisp-impact-00 >=20 >=20 > Abstract: > The Locator/Identifier Separation Protocol (LISP) relies on three > simple principles to scale the Internet: address role separation, > encapsulation, and mapping. In this document, based on > implementation, deployment, and theoretical studies, we discuss the > impact that a LISP deployment would have on the Internet and for the > users. >=20 >=20 >=20 >=20 > The IETF Secretariat Damien Saucez On 14 Oct 2012, at 11:56, Damien Saucez wrote: > FYI >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-saucez-lisp-iesg-statement-00.txt >> Date: 14 Oct 2012 11:55:54 GMT+02:00 >> To: damien.saucez@inria.fr >>=20 >>=20 >> A new version of I-D, draft-saucez-lisp-iesg-statement-00.txt >> has been successfully submitted by Damien Saucez and posted to the >> IETF repository. >>=20 >> Filename: draft-saucez-lisp-iesg-statement >> Revision: 00 >> Title: LISP IESG Statement >> Creation date: 2012-10-14 >> WG ID: Individual Submission >> Number of pages: 12 >> URL: = http://www.ietf.org/internet-drafts/draft-saucez-lisp-iesg-statement-00.tx= t >> Status: = http://datatracker.ietf.org/doc/draft-saucez-lisp-iesg-statement >> Htmlized: = http://tools.ietf.org/html/draft-saucez-lisp-iesg-statement-00 >>=20 >>=20 >> Abstract: >> The Locator/Identifier Separation Protocol (LISP) relies on three >> simple principles to scale the Internet: address role separation, >> encapsulation, and mapping. In this document, based on >> implementation, deployment, and theoretical studies, we discuss the >> impact that a LISP deployment would have on the Internet and for the >> users. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 From internet-drafts@ietf.org Tue Oct 16 05:09:46 2012 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 74DC421F86DB; Tue, 16 Oct 2012 05:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOAPWR2LOIT2; Tue, 16 Oct 2012 05:09:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDC121F86EC; Tue, 16 Oct 2012 05:09:45 -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.34 Message-ID: <20121016120945.3756.36209.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 05:09:45 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-threats-03.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, 16 Oct 2012 12:09:46 -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 Threats Analysis Author(s) : Damien Saucez Luigi Iannone Olivier Bonaventure Filename : draft-ietf-lisp-threats-03.txt Pages : 32 Date : 2012-10-16 Abstract: This document analyzes the threats against the security of the Locator/Identifier Separation Protocol (LISP) and proposes a set of recommendations to mitigate some of the identified security risks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-threats-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-threats-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gschudel@cisco.com Tue Oct 16 07:37:05 2012 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 47B5521F8700 for ; Tue, 16 Oct 2012 07:37:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QuKaYbnvX6v for ; Tue, 16 Oct 2012 07:37:04 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 66D7F21F868A for ; Tue, 16 Oct 2012 07:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1572; q=dns/txt; s=iport; t=1350398224; x=1351607824; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=rmRohLgaFHg8l+m4mDxwH+YndZtiPojViA8b8qq+obU=; b=ZmGlPGgwQwnwEUl+tsu1dy4FJa7jJjvAIIvUV57MK67IYM4uh6jGoRWf Uh7x9oLM53sUmUMu4XFJIpxFyhZQ5hC3fgxF9WbrhOvHtWOE0YPyon04l qXpEevfC9372qLdBOB2bptGlsC1KSUhrX2aZGN1rcccxwqw6MnAUf8Pyu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFJwfVCrRDoH/2dsb2JhbABCA8ABgQiCIAEBAQQSASU3CAERCxgJFg8JAwIBAgFFBg0GAgEBBRmHYQybK49ckEyOZoMmA4hYjROBFY0ygWuDDYFD X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="61464457" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 16 Oct 2012 14:37:04 +0000 Received: from sjc-vpn6-495.cisco.com (sjc-vpn6-495.cisco.com [10.21.121.239]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9GEb39i000820 for ; Tue, 16 Oct 2012 14:37:04 GMT Message-ID: <507D710F.4040204@cisco.com> Date: Tue, 16 Oct 2012 07:37:03 -0700 From: Gregg Schudel Organization: cisco.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: LISP References: <20121016002642.17758.98477.idtracker@ietfa.amsl.com> In-Reply-To: <20121016002642.17758.98477.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] New Version Notification for draft-ietf-lisp-mib-07.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, 16 Oct 2012 14:37:05 -0000 An updated version of draft-ietf-lisp-mib was posted. This version simply cleaned up "nits" from the review process. cheers gregg On 10/15/12 17:26 PM, internet-drafts@ietf.org wrote: > > A new version of I-D, draft-ietf-lisp-mib-07.txt > has been successfully submitted by Gregg Schudel and posted to the > IETF repository. > > Filename: draft-ietf-lisp-mib > Revision: 07 > Title: LISP MIB > Creation date: 2012-10-15 > WG ID: lisp > Number of pages: 65 > URL: http://www.ietf.org/internet-drafts/draft-ietf-lisp-mib-07.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-lisp-mib > Htmlized: http://tools.ietf.org/html/draft-ietf-lisp-mib-07 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-mib-07 > > Abstract: > This document defines managed objects for the Locator/ID Separation > Protocol (LISP). These objects provide information useful for > monitoring LISP devices, including basic configuration information, > LISP status, and operational statistics. > > > > > The IETF Secretariat > > -- -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From terry.manderson@icann.org Wed Oct 17 16:37:13 2012 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 C073221F857D for ; Wed, 17 Oct 2012 16:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PquoYNNdFYco for ; Wed, 17 Oct 2012 16:37:13 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1824A21F857A for ; Wed, 17 Oct 2012 16:37:13 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 17 Oct 2012 16:37:12 -0700 From: Terry Manderson To: Damien Saucez Date: Wed, 17 Oct 2012 16:37:11 -0700 Thread-Topic: [lisp] Agenda Items for LISP in IETF 85 Thread-Index: Ac2p886eGKae/+cFTX2xle+OPj3cGQCzIWVe Message-ID: In-Reply-To: <7B02B7C0-863F-41BC-9F14-68A6C5920B9F@gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3433397831_4611337" MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] Agenda Items for LISP in IETF 85 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 Oct 2012 23:37:13 -0000 --B_3433397831_4611337 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Damien, With the WG co-chair hat stapled on. Unfortunately this draft is not yet a WG item and pursuant to the agreement between the LISP chairs and the responsible AD, we will only focus on WG items until the priority, gating documents, are submitted to the IESG. Sorry, but I will not provide an agenda slot at IETF 85 for this item. I do (fully) expect that this document will become a WG item in the near future. In fact the LISP charter calls for it. However the line has been drawn in the sand - we MUST put the work into lisp-introduction and lisp-architecture first. If we have time remaining for an AOB session in Atlanta, and productive discussion is seen on the list about this draft before we all touchdown in ATL, Joel and I will be willing to allow microphone time (sans slides!) in AOB for a face to face discussion. Apologies for the tight hold on the reigns. I cannot stress this enough, we MUST get cracking on lisp-introduction and lisp-architecture! Cheers Terry On 14/10/12 8:07 PM, "Damien Saucez" wrote: > Terry, > > Can we have a 10 min slot to present the implication document for > the IESG. This document is important as it shows we are making > progress on clearing the WG milestone associated with this > document. > >> A new version of I-D, draft-saucez-lisp-iesg-statement-00.txt >> has been successfully submitted by Damien Saucez and posted to the >> IETF repository. >> >> Filename: draft-saucez-lisp-iesg-statement >> Revision: 00 >> Title: LISP IESG Statement >> Creation date: 2012-10-14 >> WG ID: Individual Submission >> Number of pages: 12 >> URL: >> http://www.ietf.org/internet-drafts/draft-saucez-lisp-iesg-statement-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-saucez-lisp-iesg-statement >> Htmlized: >> http://tools.ietf.org/html/draft-saucez-lisp-iesg-statement-00 >> >> >> Abstract: >> The Locator/Identifier Separation Protocol (LISP) relies on three >> simple principles to scale the Internet: address role separation, >> encapsulation, and mapping. In this document, based on >> implementation, deployment, and theoretical studies, we discuss the >> impact that a LISP deployment would have on the Internet and for the >> users. > > > Best regards, > > Damien Saucez > > On 12 Oct 2012, at 07:16, Terry Manderson wrote: > >> Hi all, >> >> This is where I get to re-state the request for agenda items based on the >> Chairs and AD agreement to focus on priority documents as required by the >> LISP charter. >> >> Only WG drafts will be allowed an agenda slot at IETF 85. >> >> WG draft authors - I would like to hear from you sooner, rather than later, >> if you intend to provide an update on your documents. >> >> The key items of work that I would like a status from are: >> >> The two recently adopted Intro and Architecture drafts (that is their WG >> version documents when they are uploaded!!!!!) >> and >> draft-ietf-lisp-deployment >> draft-ietf-lisp-lcaf >> draft-ietf-lisp-sec >> draft-ietf-lisp-threats >> >> WG. Given this effort to re-focus on the charter deliverables, I urge you >> all to read the above drafts and bring forth your review to this list. >> >> Cheers >> Terry >> >> On 9/10/12 9:38 AM, "Terry Manderson" wrote: >> >>> Folks, >>> >>> There is a smidge over two weeks until a WG draft agenda for IETF 85 is due. >>> >>> "2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00" >>> >>> Please email requests for agenda slots to this list by 2012-10-22 (Monday). >>> >>> If you have been watching, you will notice that an IETF agenda is up, and we >>> have a 2 hour session on Tuesday (6th Nov) afternoon (1pm-3pm). >>> >>> Cheers >>> Terry >>> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > --B_3433397831_4611337 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU3gsNAvpDYzSLbr0PCuX22s8hsYYwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE3MjMzNzExWjANBgkqhkiG 9w0BAQEFAASCAQCb65w73A5fzCRJBYyk1ZKYF2vKUJOYAS0dg/pMd6JiSMqNLmZu67oaP9IC usvW1TiNJK4YnSih/6dLumxH3ywlzOXb6AAz9pltM+Qi7I3g2TgdFLZW1YtpEuxRCYke3Ce3 Ywg7PkPS1QQUCe9eXBO3ZynSQ0hN4fV+WLGMTo9m91LdrgQeM214jCK5/5y73zrWf7YiheDf vANmCau2K/p6k/nnThc4XU5HquXG/AM8+qeF6GiDyoZSBFoxidgR45R2+FanJFoZ+AV6G0Yi gMVHrqCxTyZZG63pP3zyA9fjaaxY2pcQtodadpDYxQ921xganFf73oVvA2uZU7cqBFp1 --B_3433397831_4611337-- From vaf@cisco.com Wed Oct 17 16:59:51 2012 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 D162D21F861F for ; Wed, 17 Oct 2012 16:59:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6qWLv+1NaKU for ; Wed, 17 Oct 2012 16:59:51 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 318AA21F85B4 for ; Wed, 17 Oct 2012 16:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2091; q=dns/txt; s=iport; t=1350518391; x=1351727991; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=A2L3haK9Z4ui7brBC6Uo2Er874dobPcF8LJ5G6YVVWk=; b=Z2H3akUPrT9/P6s7BBQzH4j739v+6ZNdBZoLf84YffQ7jz0eoLVDqu6X ECYLG7jj2uE8jXZCN6U+9ZASurBCxzXqcsB8VTQl6k4fHtPg3yHaf/t9K POSILBLyI5cgATeRBPYeYBB7SU9NeglVl4JJnJDD14tIeEvRsLiGQ9BYM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP1Ff1CrRDoH/2dsb2JhbABFwDOBCIIgAQEBAwESASc/BQsLEjQUGB0UNYdcBQGbcaAxi2KFWGADiFiNEo5KgWuDDw X-IronPort-AV: E=Sophos;i="4.80,603,1344211200"; d="scan'208";a="61544963" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 17 Oct 2012 23:59:51 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9HNxoC3014501; Wed, 17 Oct 2012 23:59:50 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 0F3272A44E13; Wed, 17 Oct 2012 16:59:50 -0700 (PDT) Date: Wed, 17 Oct 2012 16:59:49 -0700 From: Vince Fuller To: Terry Manderson Message-ID: <20121017235949.GA83082@vaf-mac1.cisco.com> References: <7B02B7C0-863F-41BC-9F14-68A6C5920B9F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: LISP mailing list list Subject: Re: [lisp] Agenda Items for LISP in IETF 85 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 Oct 2012 23:59:51 -0000 (re: draft-saucez-lisp-impact-00.txt) > With the WG co-chair hat stapled on. > > Unfortunately this draft is not yet a WG item and pursuant to the agreement > between the LISP chairs and the responsible AD, we will only focus on WG > items until the priority, gating documents, are submitted to the IESG. > Sorry, but I will not provide an agenda slot at IETF 85 for this item. > > I do (fully) expect that this document will become a WG item in the near > future. In fact the LISP charter calls for it. However the line has been > drawn in the sand - we MUST put the work into lisp-introduction and > lisp-architecture first. > > If we have time remaining for an AOB session in Atlanta, and productive > discussion is seen on the list about this draft before we all touchdown in > ATL, Joel and I will be willing to allow microphone time (sans slides!) in > AOB for a face to face discussion. > > Apologies for the tight hold on the reigns. I cannot stress this enough, we > MUST get cracking on lisp-introduction and lisp-architecture! Hi Terry- I find this response a little confusing since I thought that the impact statement was explicitly listed as a gating item for the WG, despite it being a bit behind schedule for WG adoption; seems like something of a "Catch-22" not to be able to talk about it during the meeting. Is the LISP WG agenda really so tight that we can't afford a few minutes to mention the salient points of the impact statement document? Can you provide the current tentative agenda, or at least the set of items (and times assigned) accepted so far? Note that, at present, there is nothing new to present regarding either draft-ietf-lisp-introduction or draft-ietf-lisp-architecture; that *may* change prior to the -01 draft deadline next week (and I have volunteered to present the set of changes and lead a discussion if applicable) but there is no guarantee of that. I can't imagine how we will "get cracking" on these documents during the WG meeting if there is nothing to say about them. Thanks, --Vince From jnc@mercury.lcs.mit.edu Wed Oct 17 17:09:58 2012 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 DB2DE21F84FA for ; Wed, 17 Oct 2012 17:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFRWRLP1Q7Y3 for ; Wed, 17 Oct 2012 17:09:58 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 67D2821F84CE for ; Wed, 17 Oct 2012 17:09:58 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BD9A318C0CD; Wed, 17 Oct 2012 20:09:57 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121018000957.BD9A318C0CD@mercury.lcs.mit.edu> Date: Wed, 17 Oct 2012 20:09:57 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Agenda Items for LISP in IETF 85 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, 18 Oct 2012 00:09:59 -0000 > From: Terry Manderson > I do (fully) expect that this document will become a WG item in the > near future. In fact the LISP charter calls for it. However the line > has been drawn in the sand - we MUST put the work into > lisp-introduction and lisp-architecture first. But there is very little for the WG to do on these documents. They don't cover any _new_ ground, which the WG might need to discuss - all they are (effectively) are high-level descriptions of what's already been done. Yes, I need to get moving on them, but what exactly is it that the WG is going to do? Or, to put it another way, how is _not_ doing other things going to speed up in any way the architecture document set? Since this document is already called for by the charter, I would think looking at it would be an entirely plausible use of meeting time. Noel From terry.manderson@icann.org Wed Oct 17 17:16:03 2012 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 4D5D921F85EA for ; Wed, 17 Oct 2012 17:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx-R5BF-EQbb for ; Wed, 17 Oct 2012 17:16:02 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9C721F85E7 for ; Wed, 17 Oct 2012 17:16:02 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 17 Oct 2012 17:16:02 -0700 From: Terry Manderson To: Vince Fuller Date: Wed, 17 Oct 2012 17:16:00 -0700 Thread-Topic: [lisp] Agenda Items for LISP in IETF 85 Thread-Index: Ac2sw4uef+O6mHq8Qv6WNii88fzCPwAAjTFT Message-ID: In-Reply-To: <20121017235949.GA83082@vaf-mac1.cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3433400160_4782357" MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] Agenda Items for LISP in IETF 85 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, 18 Oct 2012 00:16:03 -0000 --B_3433400160_4782357 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Vince, On 18/10/12 9:59 AM, "Vince Fuller" wrote: > (re: draft-saucez-lisp-impact-00.txt) > > Hi Terry- > > I find this response a little confusing since I thought that the impact > statement was explicitly listed as a gating item for the WG, despite it > being a bit behind schedule for WG adoption; seems like something of a > "Catch-22" not to be able to talk about it during the meeting. I'm not saying that we can't talk about it - if there is time spare after we get through the current list of items and free time remains then we can certainly have an open-mic session about it, again provided we see on-list discussion about it. > > Is the LISP WG agenda really so tight that we can't afford a few minutes to > mention the salient points of the impact statement document? Can you provide > the current tentative agenda, or at least the set of items (and times > assigned) accepted so far? It's not about the time. I fully expect us to have time - but the IESG has asked us to get the existing WG items that are gating documents through to them before we take on more work. > > Note that, at present, there is nothing new to present regarding either > draft-ietf-lisp-introduction or draft-ietf-lisp-architecture; that *may* > change prior to the -01 draft deadline next week (and I have volunteered > to present the set of changes and lead a discussion if applicable) but > there is no guarantee of that. I can't imagine how we will "get cracking" > on these documents during the WG meeting if there is nothing to say about > them. > So the "get cracking" on the documents applies to more than just the authors/editors. It really now seems to focus on the work group as a whole - these documents need review. These documents need suggested text, should the work group see deficiencies. This is not a critique about the authors, but more about the review of the documents I have seen to date. As for the current agenda, I have so far: - LCAF Update, 15 Minutes Dino Farinacci http://tools.ietf.org/wg/lisp/draft-ietf-lisp-lcaf/ - Lisp-threats, 10 Minutes Luigi Iannone http://tools.ietf.org/wg/lisp/draft-ietf-lisp-threats/ - DDT - Implementation and deployment, 20 Minutes Fuller or Lewis http://tools.ietf.org/wg/lisp/draft-ietf-lisp-ddt/ - Lisp-deployment, 10 mins Albert Cabellos http://tools.ietf.org/wg/lisp/draft-ietf-lisp-deployment/ Cheers Terry --B_3433400160_4782357 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU508cZziQLZbQK4KTCdA+gDH2c3EwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE4MDAxNjAwWjANBgkqhkiG 9w0BAQEFAASCAQA+W/I63KZtNw4fffIyhjp0w4/fiTQJk2ihyzMbJuGjldSVegs0uBXLSHI8 67fvz7sBTy2pJ58VfCsPyEPbP1X/FKeptPFr8PZVB+9ZGWhaiJ8L9ExTRhB90ulBJpMvbtXx D+tf4nFDEjhXTfxP9qshLonZPBaMdEFoXxgThZDhePIUBDGPMgg8uJ+CEXLjBMfG9wjKiwjQ CO9Gmz1arHwSGrviBP/uFHjpjCYyWnhcXbrBPqbyYwpTk17lLFVzH6lHqILgk6igcrSoqtx3 478PdxYyDD4E7V39p+Qt1VJCeBnbUZXTj4daRuPEVPmHZ2X3pWK04bnxv5Pkw2NRdLsQ --B_3433400160_4782357-- From terry.manderson@icann.org Wed Oct 17 17:26:03 2012 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 F3F1321F8534 for ; Wed, 17 Oct 2012 17:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL2Z1JIpCCuV for ; Wed, 17 Oct 2012 17:26:02 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF1C21F8532 for ; Wed, 17 Oct 2012 17:26:02 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 17 Oct 2012 17:26:02 -0700 From: Terry Manderson To: Noel Chiappa , "lisp@ietf.org" Date: Wed, 17 Oct 2012 17:25:58 -0700 Thread-Topic: [lisp] Agenda Items for LISP in IETF 85 Thread-Index: Ac2sxPb4KiVONktrS2u+CMqnNYVRMgAAi3eQ Message-ID: In-Reply-To: <20121018000957.BD9A318C0CD@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3433400758_4779166" MIME-Version: 1.0 Subject: Re: [lisp] Agenda Items for LISP in IETF 85 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, 18 Oct 2012 00:26:03 -0000 --B_3433400758_4779166 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 18/10/12 10:09 AM, "Noel Chiappa" wrote: > > But there is very little for the WG to do on these documents. They don't > cover any _new_ ground, which the WG might need to discuss - all they are > (effectively) are high-level descriptions of what's already been done. They could certainly get review by the WG. Text could be offered by the WG on sections that are deemed unclear, or incomplete. eg section 5.4 (LCAF), 6.3 (state), parts of 6.4, 7.3.1, 7.4 etc etc of lisp-architecture. > > Yes, I need to get moving on them, but what exactly is it that the WG is I would like to see the WG get moving on them. As you say they are already high level descriptions of what has already been done. So there IS expertise in the WG that could easily provide you with text for you to massage into the document. > going to do? Or, to put it another way, how is _not_ doing other things going > to speed up in any way the architecture document set? There is _much_ to do on the architecture document. This is a (to use the vernacular) "stick" to get the WG to invest the time they said they would in adoption of this draft. I apologize that it isn't a popular approach, but given the IESG desire one that we have to live with for now. I will bring tim-tams to Atlanta as reward for action :-) (if that helps) > > Since this document is already called for by the charter, I would think > looking at it would be an entirely plausible use of meeting time. > Let's see some WG ML traffic on it first. Cheers Terry --B_3433400758_4779166 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUlzYb12RV2OATzsT/YXDYX4HV7/wwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDE4MDAyNTU4WjANBgkqhkiG 9w0BAQEFAASCAQCSGnsqFAPWgErTrYkL/77Doirt54nyjFvFiKgc75KrmfM/rAanCdXiG0DG fNbaRMGNHnKvT4hz7h91XjkNqMIrRWPvDLC0Hd7tTI8ND1QC5HT6aUCLlsm53gvH13rCXClr 3VandLYu2LlkzgQkLi+G7wyiD/49yUnpaB6Ui7qOryWesANKLJQWNGSqYpnNMRKXstnaCDP3 3E4xKTeLxcoLGnVcLBv5ot+LxNcJG4dD5VcEwHTAtAJhsBixhyDvVk6e0wyzlKH87heXQW3u M0YPSh7I++Q0FvmrI/sgkcLqm+YaIp+fpfdAYRhwNly8F7xv3/dJ/buu3P6TN1dIkziO --B_3433400758_4779166-- From jsaldana@unizar.es Fri Oct 19 09:04:32 2012 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 C4A7721F857A; Fri, 19 Oct 2012 09:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.292 X-Spam-Level: X-Spam-Status: No, score=-7.292 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrvLmk2lR+4t; Fri, 19 Oct 2012 09:04:30 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 76EAA21F87A4; Fri, 19 Oct 2012 09:04:29 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q9JG4KnY021903; Fri, 19 Oct 2012 18:04:20 +0200 From: "Jose Saldana" To: "'Luigi Iannone'" References: <000e01cd9d5a$0e3f2850$2abd78f0$@unizar.es> <201210091424.17349.mirja.kuehlewind@ikr.uni-stuttgart.de> <002001cda62b$f6e63920$e4b2ab60$@unizar.es> <201210091802.04459.mirja.kuehlewind@ikr.uni-stuttgart.de> <000d01cda6bd$07331370$15993a50$@unizar.es> <08DEAFED-C1BC-45E3-B2C9-C9879145FC4B@gigix.net> <002001cda6dd$1f30d690$5d9283b0$@unizar.es> In-Reply-To: Date: Fri, 19 Oct 2012 18:04:28 +0200 Organization: Universidad de Zaragoza Message-ID: <00d701cdae13$6b8b5f00$42a21d00$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01CDAE24.2F1603C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINPjcn7rEFviyXS5rdNqTB9c1OEQJyDP5sAiUuOIoBpXi1CgF1kAIEAY+uERsBeQryKgLri8P6ltRzMAA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org, lisp@ietf.org Subject: Re: [lisp] [tcmtf] TCMTF: two kinds of services 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, 19 Oct 2012 16:04:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D8_01CDAE24.2F1603C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Luigi, =20 What about this protocol stack for LISP within TCMTF? (to be seen in Courier letters) =20 TCP/IP UDP/IP RTP/UDP/IP \ | / \ | / ------------------------------ \ | / Nothing or ROHC or ECRTP or IPHC header compressing layer | | ------------------------------ | PPPMUX or other mux protocols multiplexing layer / | \ / | \ ------------------------------ / LISP \ / | \ GRE or L2TP UDP \ tunneling layer | | MPLS | | = ------------------------------ IP IP =20 =20 I don=92t know if LISP could be included into TCMTF draft. What do you = think? Should it be defined inside the LISP WG? =20 We have to talk about that LISP signaling which could be used in TCMTF, = as you say. =20 Thanks, =20 Jose =20 > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > Luigi Iannone > Enviado el: jueves, 11 de octubre de 2012 9:11 > Para: jsaldana@unizar.es > CC: tcmtf@ietf.org > Asunto: Re: [tcmtf] TCMTF: two kinds of services >=20 > Hi Jose, >=20 > I would put LISP in two different layers. >=20 > You can consider LISP as composed of two main parts: >=20 > 1. the encap/decap operations (i.e., the tunnelling) >=20 > 2. the mapping system (basically controlling which traffic is = tunnelled). >=20 > The first can be used at the tunnelling layer, beside GRE/MPLS/L2TP (having > multiple options is always a good thing ;-) ), to perform the = tunnelling. Some > parts of the LISP header might be exploited to carry TE information = (e.g., the > Instance ID can be used as QoS tag). >=20 > The second can be used at Mux/Demux layer. The LISP mapping system > might be extended to perform tcmtf negotiation by leveraging on a > particular form of mappings. The advantage is that there is already = quite a bit > of signalling machinery out there that can be easily re-used/extended. >=20 > Ciao >=20 > Luigi >=20 >=20 > On 10 Oct. 2012, at 13:48 , Jose Saldana < jsaldana@unizar.es> wrote: >=20 > > Luigi, > > > > Where would you include LISP here? With GRE/L2TP, or with MPLS? > > > > We are also thinking about including other tunneling schemes, as = VLAN, > etc. > > > > (to be seen in Courier letters) > > > > TCP/IP UDP/IP RTP/UDP/IP > > \ | / > > \ | / = ------------------------------ > > \ | / > > Nothing or ROHC or ECRTP or IPHC header compressing = layer > > | > > | = ------------------------------ > > | > > PPPMUX or other mux protocols multiplexing layer > > | > > / \ = ------------------------------ > > / \ > > / \ > > GRE or L2TP \ tunneling layer > > | MPLS > > | = ------------------------------ > > IP > > > > Thanks, > > > > Jose > > > >> -----Mensaje original----- > >> De: tcmtf-bounces@ietf.org [ mailto:tcmtf-bounces@ietf.org] En nombre > >> de Luigi Iannone Enviado el: mi=E9rcoles, 10 de octubre de 2012 = 10:23 > >> Para: jsaldana@unizar.es > >> CC: tcmtf@ietf.org > >> Asunto: Re: [tcmtf] TCMTF: two kinds of services > >> > >> Hi All, > >> > >> On 10 Oct. 2012, at 09:58 , Jose Saldana < = jsaldana@unizar.es> wrote: > >> > >>> - Tunneling will be used to send the multiplexed packets = end-to-end. > >>> The options in this layer are L2TP, GRE and MPLS. > >>> > >> > >> I was wondering if the group might be interested in exploring also > >> other > > form > >> of tunnelling, e.g., LISP. > >> > >> Obviously, since LISP is an experimental effort, it cannot be = tagged > >> as > > "best > >> current practice" and included in document (A). > >> > >> However, the group may have a slightly "larger" scope and include > >> alternative forms of tunnelling (and/or multiplexing and/or header > >> compression) (may be documented separately). > >> > >> Thoughts? > >> > >> ciao > >> > >> Luigi > >> > >> > >> > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf ------=_NextPart_000_00D8_01CDAE24.2F1603C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Luigi,

 

What about this = protocol stack for LISP within TCMTF?

(to be seen in Courier letters)

 

=A0=A0=A0 TCP/IP=A0=A0 = UDP/IP=A0 RTP/UDP/IP

=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0=A0=A0 |=A0=A0=A0=A0 = /

=A0=A0=A0=A0=A0=A0=A0=A0=A0 = \=A0=A0=A0 |=A0=A0=A0 = /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ------------------------------

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0 |=A0=A0 = /

Nothing or ROHC or ECRTP or = IPHC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 header compressing = layer

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ------------------------------

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |

=A0=A0 PPPMUX or other mux = protocols=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 multiplexing = layer

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = /=A0=A0 | =A0=A0=A0=A0\

=A0=A0=A0=A0=A0=A0=A0 =A0=A0/ =A0=A0=A0| = =A0=A0=A0=A0=A0\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0------------------------------

=A0=A0=A0=A0=A0=A0=A0=A0 /=A0 =A0=A0LISP = =A0=A0=A0=A0\

=A0=A0=A0=A0=A0=A0=A0 = /=A0 =A0=A0=A0=A0|=A0 =A0=A0=A0=A0=A0=A0\

GRE or L2TP=A0=A0 UDP = =A0=A0=A0=A0=A0=A0=A0\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0tunneling layer

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 | = =A0=A0=A0=A0=A0=A0=A0MPLS

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0-------------= -----------------

=A0=A0=A0=A0=A0=A0 = IP=A0=A0=A0=A0=A0 IP

 

 

I don’t know if = LISP could be included into TCMTF draft. What do you think? Should it be = defined inside the LISP WG?

 

We have to talk about = that LISP signaling which could be used in TCMTF, as you = say.

 

Thanks,

 

Jose

 

> -----Mensaje = original-----

> De: = tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de

> Luigi = Iannone

> Enviado el: = jueves, 11 de octubre de 2012 9:11

> = Para: jsaldana@unizar.es

> = CC: tcmtf@ietf.org

> = Asunto: Re: [tcmtf] TCMTF: two kinds of = services

>

> Hi = Jose,

>

> I = would put LISP in two different layers.

> =

> You can consider LISP as = composed of two main parts:

> =

> 1. the encap/decap operations = (i.e., the tunnelling)

> =

> 2. the mapping system = (basically controlling which traffic is = tunnelled).

>

> The = first can be used=A0 at the tunnelling layer, beside GRE/MPLS/L2TP = (having

> multiple options is always a = good thing ;-) ), to perform the tunnelling. = Some

> parts of the LISP header might = be exploited to carry TE information (e.g., the

> = Instance ID can be used as QoS tag).

> =

> The second can be used at = Mux/Demux layer. The LISP mapping system

> = might be extended to perform tcmtf negotiation by=A0 leveraging on = a

> particular form of mappings. = The advantage is that there is already quite a = bit

> of signalling machinery out = there that can be easily re-used/extended.

> =

> Ciao

> =

> Luigi

> =

>

> On = 10 Oct. 2012, at 13:48 , Jose Saldana <jsaldana@unizar.es= > wrote:

>

> > = Luigi,

> >

> > = Where would you include LISP here? With GRE/L2TP, or with = MPLS?

> >

> > = We are also thinking about including other tunneling schemes, as = VLAN,

> etc.

> = >

> > (to be seen in Courier = letters)

> >

> = >=A0=A0=A0 TCP/IP=A0=A0 UDP/IP=A0 RTP/UDP/IP

> = >=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0=A0=A0 |=A0=A0=A0=A0 = /

> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 = \=A0=A0=A0 |=A0=A0=A0 = /=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ------------------------------

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \=A0=A0 |=A0=A0 = /

> > Nothing or ROHC or ECRTP = or IPHC=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 header compressing = layer

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ------------------------------

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

> = >=A0=A0 PPPMUX or other mux = protocols=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 multiplexing = layer

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 / = \=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= ------------------------------

> = >=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0/=A0=A0 = \

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /=A0=A0=A0=A0 = \

> >=A0=A0 GRE or = L2TP=A0=A0=A0=A0 = \=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 tunneling layer

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 = MPLS

> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 = ------------------------------

> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP

> = >

> > = Thanks,

> >

> > = Jose

> >

> = >> -----Mensaje original-----

> = >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf= .org] En nombre

> = >> de Luigi Iannone Enviado el: mi=E9rcoles, 10 de octubre de 2012 = 10:23

> >> Para: jsaldana@unizar.es=

> >> CC: tcmtf@ietf.org=

> >> Asunto: Re: [tcmtf] = TCMTF: two kinds of services

> = >>

> >> Hi = All,

> = >>

> >> On 10 Oct. 2012, at = 09:58 , Jose Saldana <jsaldana@unizar.es= > wrote:

> = >>

> >>> - Tunneling will = be used to send the multiplexed packets = end-to-end.

> >>> The options in = this layer are L2TP, GRE and MPLS.

> = >>>

> = >>

> >> I was wondering if the = group might be interested in exploring also

> = >> other

> > = form

> >> of tunnelling, e.g., = LISP.

> = >>

> >> Obviously, since LISP = is an experimental effort, it cannot be tagged

> = >> as

> > = "best

> >> current practice" = and included in document (A).

> = >>

> >> However, the group may = have a slightly "larger" scope and = include

> >> alternative forms of = tunnelling (and/or multiplexing and/or header

> = >> compression) (may be documented = separately).

> = >>

> >> = Thoughts?

> = >>

> >> = ciao

> = >>

> >> = Luigi

> = >>

> = >>

> = >>

> >> = _______________________________________________

> = >> tcmtf mailing list

> = >> tcmtf@ietf.org=

> >> https://www.ietf.org/mail= man/listinfo/tcmtf

> = >

>

> = _______________________________________________

> = tcmtf mailing list

> tcmtf@ietf.org=

> https://www.ietf.org/mail= man/listinfo/tcmtf

------=_NextPart_000_00D8_01CDAE24.2F1603C0-- From internet-drafts@ietf.org Sat Oct 20 11:45:40 2012 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 DD17A21F858C; Sat, 20 Oct 2012 11:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seylQBdc+T46; Sat, 20 Oct 2012 11:45:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2160921F846C; Sat, 20 Oct 2012 11:45:40 -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.34 Message-ID: <20121020184540.31090.74878.idtracker@ietfa.amsl.com> Date: Sat, 20 Oct 2012 11:45:40 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-05.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: Sat, 20 Oct 2012 18:45:41 -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-05.txt Pages : 25 Date : 2012-10-20 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-deployment-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ljakab@ac.upc.edu Sat Oct 20 11:49:05 2012 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 1739F21F8467 for ; Sat, 20 Oct 2012 11:49:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0QhCpFbb6Yb for ; Sat, 20 Oct 2012 11:49:04 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28521F85B6 for ; Sat, 20 Oct 2012 11:49:04 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id q9KIn1L2011215 for ; Sat, 20 Oct 2012 20:49:02 +0200 Received: from [192.168.1.6] (unknown [89.123.120.252]) by gw.ac.upc.edu (Postfix) with ESMTP id 8B5C36B01C5 for ; Sat, 20 Oct 2012 20:49:01 +0200 (CEST) Message-ID: <5082F21C.6080908@ac.upc.edu> Date: Sat, 20 Oct 2012 21:49:00 +0300 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: lisp@ietf.org References: <20121020184540.31090.74878.idtracker@ietfa.amsl.com> In-Reply-To: <20121020184540.31090.74878.idtracker@ietfa.amsl.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-05.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: Sat, 20 Oct 2012 18:49:05 -0000 This revision only updates the references, as previsously discussed here. Regards, -Lori Jakab On 10/20/12 21:45, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Locator/ID Separation Protocol Working Group 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-05.txt > Pages : 25 > Date : 2012-10-20 > > 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-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-deployment-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Sun Oct 21 07:10:04 2012 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 0065B21F8491 for ; Sun, 21 Oct 2012 07:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5woRNFcXHqMa for ; Sun, 21 Oct 2012 07:10:02 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 330F921F846F for ; Sun, 21 Oct 2012 07:10:01 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1169817wey.31 for ; Sun, 21 Oct 2012 07:10:01 -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 :message-id:references:to:x-mailer:x-gm-message-state; bh=D9U4AZDQ7tEhqR05yfN4bgF/MsOIzbVqa//We61TRhw=; b=S+050hcqJ70m561Hr2WE01ZjYOGXyvHZ0Fi5+AHGI910bhcsCFSE1VqOPwOK639+Pt INvwHrg8Ar+5Pv4KXdm9q2+E2+KLsIRugctwLzTkGUQD4abArTleRRK+P4NOPR2sRy2O la08LRXvHT2O/s1mp8rHuvx7wiNngnX1KlV/u7ZO/CoZqyILPzVQ0UDcrXdydify50tf TsyqAy8sonRBnltl/RNnKW6w65wtxEu36xu7q9chP7tD4qKMEvzhdedY3ATUY0S/2bMZ Z/iE3sNeJZAeDveJKesBYvyRi11cb4Yi2Qj6XPkJUB3BJH93wmJNbMonAUyg9uy1pHab EdaQ== Received: by 10.180.24.4 with SMTP id q4mr30800827wif.19.1350828601152; Sun, 21 Oct 2012 07:10:01 -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 ESMTPS id k20sm46132043wiv.11.2012.10.21.07.09.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 07:10:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8FA303AD-9361-4812-BD0C-26583A84ACF8" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <00d701cdae13$6b8b5f00$42a21d00$@unizar.es> Date: Sun, 21 Oct 2012 16:13:41 +0200 Message-Id: <814C798C-6C32-4378-BA8D-9FA2EA8B8C39@gigix.net> References: <000e01cd9d5a$0e3f2850$2abd78f0$@unizar.es> <201210091424.17349.mirja.kuehlewind@ikr.uni-stuttgart.de> <002001cda62b$f6e63920$e4b2ab60$@unizar.es> <201210091802.04459.mirja.kuehlewind@ikr.uni-stuttgart.de> <000d01cda6bd$07331370$15993a50$@unizar.es> <08DEAFED-C1BC-45E3-B2C9-C9879145FC4B@gigix.net> <002001cda6dd$1f30d690$5d9283b0$@unizar.es> <00d701cdae13$6b8b5f00$42a21d00$@unizar.es> To: X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQl597Twabr65dl25BKM5xgAgRfQnIc+xWMxLZ/zE8cEQBm9ot0ecQic1LQRXkOiFsCXcpij Cc: tcmtf@ietf.org, lisp@ietf.org Subject: Re: [lisp] [tcmtf] TCMTF: two kinds of services 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, 21 Oct 2012 14:10:04 -0000 --Apple-Mail=_8FA303AD-9361-4812-BD0C-26583A84ACF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jose, comments inline. On 19 Oct. 2012, at 18:04 , Jose Saldana wrote: > Luigi, > =20 > What about this protocol stack for LISP within TCMTF? > (to be seen in Courier letters) > =20 > TCP/IP UDP/IP RTP/UDP/IP > \ | / > \ | / = ------------------------------ > \ | / > Nothing or ROHC or ECRTP or IPHC header compressing layer > | > | = ------------------------------ > | > PPPMUX or other mux protocols multiplexing layer > / | \ > / | \ = ------------------------------ > / LISP \ > / | \ > GRE or L2TP UDP \ tunneling layer > | | MPLS > | | = ------------------------------ > IP IP > =20 > =20 > I don=92t know if LISP could be included into TCMTF draft. What do you = think? The graph looks good to me. Concerning whether or not to include it in the draft, may be it is not = necessary to include details about LISP just mention that can be used. = The usage of LISP, because of its experimental nature compare to other = tunnelling options, can be documented in a different document, which, if = people are interested, I can (with your help) write. > Should it be defined inside the LISP WG? > =20 I`ll let the LISP WG chairs answer on this point. Nevertheless, IMHO, the LISP WG is chartered for the main spec. Other = usages of LISP can be discussed in other, more pertinent, WGs. Obviously = some form of collaboration will be necessary at least to make the LISP = WG aware of how other WGs plan to use LISP. > We have to talk about that LISP signaling which could be used in = TCMTF, as you say. As I said before, these details can be documented elsewhere. If LISP is = mentioned in the main draft, then it can also be stated that the re-use = of the LISP signalling machinery in the context of TCMTF is explored in = a different document. ciao L. > =20 > Thanks, > =20 > Jose > =20 > > -----Mensaje original----- > > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > > Luigi Iannone > > Enviado el: jueves, 11 de octubre de 2012 9:11 > > Para: jsaldana@unizar.es > > CC: tcmtf@ietf.org > > Asunto: Re: [tcmtf] TCMTF: two kinds of services > > > > Hi Jose, > > > > I would put LISP in two different layers. > > > > You can consider LISP as composed of two main parts: > > > > 1. the encap/decap operations (i.e., the tunnelling) > > > > 2. the mapping system (basically controlling which traffic is = tunnelled). > > > > The first can be used at the tunnelling layer, beside GRE/MPLS/L2TP = (having > > multiple options is always a good thing ;-) ), to perform the = tunnelling. Some > > parts of the LISP header might be exploited to carry TE information = (e.g., the > > Instance ID can be used as QoS tag). > > > > The second can be used at Mux/Demux layer. The LISP mapping system > > might be extended to perform tcmtf negotiation by leveraging on a > > particular form of mappings. The advantage is that there is already = quite a bit > > of signalling machinery out there that can be easily = re-used/extended. > > > > Ciao > > > > Luigi > > > > > > On 10 Oct. 2012, at 13:48 , Jose Saldana wrote: > > > > > Luigi, > > > > > > Where would you include LISP here? With GRE/L2TP, or with MPLS? > > > > > > We are also thinking about including other tunneling schemes, as = VLAN, > > etc. > > > > > > (to be seen in Courier letters) > > > > > > TCP/IP UDP/IP RTP/UDP/IP > > > \ | / > > > \ | / = ------------------------------ > > > \ | / > > > Nothing or ROHC or ECRTP or IPHC header compressing = layer > > > | > > > | = ------------------------------ > > > | > > > PPPMUX or other mux protocols multiplexing layer > > > | > > > / \ = ------------------------------ > > > / \ > > > / \ > > > GRE or L2TP \ tunneling layer > > > | MPLS > > > | = ------------------------------ > > > IP > > > > > > Thanks, > > > > > > Jose > > > > > >> -----Mensaje original----- > > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En = nombre > > >> de Luigi Iannone Enviado el: mi=E9rcoles, 10 de octubre de 2012 = 10:23 > > >> Para: jsaldana@unizar.es > > >> CC: tcmtf@ietf.org > > >> Asunto: Re: [tcmtf] TCMTF: two kinds of services > > >> > > >> Hi All, > > >> > > >> On 10 Oct. 2012, at 09:58 , Jose Saldana = wrote: > > >> > > >>> - Tunneling will be used to send the multiplexed packets = end-to-end. > > >>> The options in this layer are L2TP, GRE and MPLS. > > >>> > > >> > > >> I was wondering if the group might be interested in exploring = also > > >> other > > > form > > >> of tunnelling, e.g., LISP. > > >> > > >> Obviously, since LISP is an experimental effort, it cannot be = tagged > > >> as > > > "best > > >> current practice" and included in document (A). > > >> > > >> However, the group may have a slightly "larger" scope and include > > >> alternative forms of tunnelling (and/or multiplexing and/or = header > > >> compression) (may be documented separately). > > >> > > >> Thoughts? > > >> > > >> ciao > > >> > > >> Luigi > > >> > > >> > > >> > > >> _______________________________________________ > > >> tcmtf mailing list > > >> tcmtf@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tcmtf > > > > > > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf --Apple-Mail=_8FA303AD-9361-4812-BD0C-26583A84ACF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Jose,

comments = inline.


On 19 Oct. 2012, at 18:04 = , Jose Saldana <jsaldana@unizar.es> = wrote:

Luigi,
What about this protocol stack = for LISP within TCMTF?
(to be seen in = Courier letters)
    = TCP/IP   UDP/IP  RTP/UDP/IP
         = \     |     = /
Nothing or = ROHC or ECRTP or = IPHC           &nbs= p; header compressing layer
   = PPPMUX or other mux = protocols           = ;     multiplexing layer
        =   /    | =      \       &= nbsp;          =  ------------------------------
         = /    LISP =     \
GRE or L2TP   UDP =        \     &= nbsp;            =       tunneling = layer
       = |       = |       =             &n= bsp;       ----------------------------= --
 
 
I don=92t know if = LISP could be included into TCMTF draft. What do you = think?

The = graph looks good to me.

Concerning whether or = not to include it in the draft, may be it is not necessary to include = details about LISP just mention that can be used. The usage of LISP, = because of its experimental nature compare to other tunnelling options, = can be documented in a different document, which, if people are = interested, I can (with your help) = write.


Should it be defined inside the LISP = WG?
We have to talk about that LISP signaling which could = be used in TCMTF, as you = say.

As I said = before, these details can be documented elsewhere. If LISP is mentioned = in the main draft, then it can also be stated that the re-use of the = LISP signalling machinery in the context of TCMTF is explored in a = different = document.

ciao

L.
<= div>

 
 
Jose
> -----Mensaje = original-----> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de> Luigi Iannone
 Enviado el: jueves, 11 de octubre = de 2012 9:11> Para: jsaldana@unizar.es
> Asunto: Re: [tcmtf] TCMTF: two = kinds of services>
> = Hi Jose,
>
> = I would put LISP in two different layers.
> You can consider LISP as = composed of two main parts:
> 1. the encap/decap = operations (i.e., the tunnelling)
> 2. the mapping system = (basically controlling which traffic is = tunnelled).
>
> = The first can be used  at the tunnelling layer, beside = GRE/MPLS/L2TP (having
> multiple options is always a = good thing ;-) ), to perform the tunnelling. = Some
> parts of the LISP header = might be exploited to carry TE information (e.g., = the
> Instance ID can be used as = QoS tag).
>
> = The second can be used at Mux/Demux layer. The LISP mapping = system
> might be extended to perform = tcmtf negotiation by  leveraging on a
> = particular form of mappings. The advantage is that there is already = quite a bit
> of signalling machinery out = there that can be easily re-used/extended.
> = Ciao
>
> = Luigi
>
> On 10 Oct. 2012, at 13:48 , = Jose Saldana <jsaldana@unizar.es> = wrote:
>
> = > Luigi,
> = >
> > Where would you include = LISP here? With GRE/L2TP, or with MPLS?
> = >
> > We are also thinking = about including other tunneling schemes, as = VLAN,
> = etc.
> = >
> > (to be seen in Courier = letters)
> = >
> >    = TCP/IP   UDP/IP  RTP/UDP/IP
> = >         = \     |     = /
> = >          = \    |    = /            &= nbsp;        = ------------------------------
> = >           = \   |   /
> > Nothing or ROHC = or ECRTP or = IPHC           &nbs= p; header compressing layer
> = >           &nbs= p;   |
> = >           &nbs= p;   = |            &= nbsp;           &nb= sp; ------------------------------
> = >           &nbs= p;   |
> >   PPPMUX or = other mux = protocols           = ;     multiplexing layer
> = >           &nbs= p;   |
> = >           &nbs= p;  / = \            &= nbsp;            = ------------------------------
> = >   =           /   = \
> = >            = /     \
> >   GRE = or L2TP     = \            &= nbsp;           &nb= sp;     tunneling layer
> = >          = |        = MPLS
> = >          = |            &= nbsp;           &nb= sp;      = ------------------------------
> = >          = IP
> = >
> > = Thanks,
> = >
> > = Jose
> = >
> >> -----Mensaje = original-----
> >> de Luigi Iannone = Enviado el: mi=E9rcoles, 10 de octubre de 2012 = 10:23
> = >> tcmtf mailing list
> = tcmtf mailing list
> >  User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Luigi Iannone References: <000e01cd9d5a$0e3f2850$2abd78f0$@unizar.es> <201210091424.17349.mirja.kuehlewind@ikr.uni-stuttgart.de> <002001cda62b$f6e63920$e4b2ab60$@unizar.es> <201210091802.04459.mirja.kuehlewind@ikr.uni-stuttgart.de> <000d01cda6bd$07331370$15993a50$@unizar.es> <08DEAFED-C1BC-45E3-B2C9-C9879145FC4B@gigix.net> <002001cda6dd$1f30d690$5d9283b0$@unizar.es> <00d701cdae13$6b8b5f00$42a21d00$@unizar.es> <814C798C-6C32-4378-BA8D-9FA2EA8B8C39@gigix.net> In-Reply-To: <814C798C-6C32-4378-BA8D-9FA2EA8B8C39@gigix.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: tcmtf@ietf.org, lisp@ietf.org Subject: Re: [lisp] [tcmtf] TCMTF: two kinds of services 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, 21 Oct 2012 18:56:12 -0000 As a general comment from a chair, a document which references LISP does not need to be done in he LISP WG. (Telling us about it is appreciated.) A document which defines how to use LISP to do something needs to be coordinated with the LISP WG. Yours, Joel On 10/21/2012 10:13 AM, Luigi Iannone wrote: > Hi Jose, > > comments inline. > > > On 19 Oct. 2012, at 18:04 , Jose Saldana > wrote: > >> Luigi, >> What about this protocol stack for LISP within TCMTF? >> (to be seen in Courier letters) >> TCP/IP UDP/IP RTP/UDP/IP >> \ | / >> \ | / ------------------------------ >> \ | / >> Nothing or ROHC or ECRTP or IPHC header compressing layer >> | >> | ------------------------------ >> | >> PPPMUX or other mux protocols multiplexing layer >> / | \ >> / | \ ------------------------------ >> / LISP \ >> / | \ >> GRE or L2TP UDP \ tunneling layer >> | | MPLS >> | | ------------------------------ >> IP IP >> I don’t know if LISP could be included into TCMTF draft. What do you >> think? > > The graph looks good to me. > > Concerning whether or not to include it in the draft, may be it is not > necessary to include details about LISP just mention that can be used. > The usage of LISP, because of its experimental nature compare to other > tunnelling options, can be documented in a different document, which, if > people are interested, I can (with your help) write. > > >> Should it be defined inside the LISP WG? > > I`ll let the LISP WG chairs answer on this point. > Nevertheless, IMHO, the LISP WG is chartered for the main spec. Other > usages of LISP can be discussed in other, more pertinent, WGs. Obviously > some form of collaboration will be necessary at least to make the LISP > WG aware of how other WGs plan to use LISP. > >> We have to talk about that LISP signaling which could be used in >> TCMTF, as you say. > > As I said before, these details can be documented elsewhere. If LISP is > mentioned in the main draft, then it can also be stated that the re-use > of the LISP signalling machinery in the context of TCMTF is explored in > a different document. > > ciao > > L. > > >> Thanks, >> Jose >> >-----Mensaje original----- >> >De:tcmtf-bounces@ietf.org >> [mailto:tcmtf-bounces@ietf.org >> ] En nombre de >> >Luigi Iannone >> >Enviado el: jueves, 11 de octubre de 2012 9:11 >> >Para:jsaldana@unizar.es >> >CC:tcmtf@ietf.org >> >Asunto: Re: [tcmtf] TCMTF: two kinds of services >> > >> > Hi Jose, >> > >> > I would put LISP in two different layers. >> > >> > You can consider LISP as composed of two main parts: >> > >> > 1. the encap/decap operations (i.e., the tunnelling) >> > >> > 2. the mapping system (basically controlling which traffic is tunnelled). >> > >> > The first can be used at the tunnelling layer, beside GRE/MPLS/L2TP (having >> > multiple options is always a good thing ;-) ), to perform the tunnelling. Some >> > parts of the LISP header might be exploited to carry TE information (e.g., the >> > Instance ID can be used as QoS tag). >> > >> > The second can be used at Mux/Demux layer. The LISP mapping system >> > might be extended to perform tcmtf negotiation by leveraging on a >> > particular form of mappings. The advantage is that there is already quite a bit >> > of signalling machinery out there that can be easily re-used/extended. >> > >> > Ciao >> > >> > Luigi >> > >> > >> > On 10 Oct. 2012, at 13:48 , Jose Saldana > wrote: >> > >> > > Luigi, >> > > >> > > Where would you include LISP here? With GRE/L2TP, or with MPLS? >> > > >> > > We are also thinking about including other tunneling schemes, as VLAN, >> > etc. >> > > >> > > (to be seen in Courier letters) >> > > >> > > TCP/IP UDP/IP RTP/UDP/IP >> > > \ | / >> > > \ | / ------------------------------ >> > > \ | / >> > > Nothing or ROHC or ECRTP or IPHC header compressing layer >> > > | >> > > | ------------------------------ >> > > | >> > > PPPMUX or other mux protocols multiplexing layer >> > > | >> > > / \ ------------------------------ >> > > / \ >> > > / \ >> > > GRE or L2TP \ tunneling layer >> > > | MPLS >> > > | ------------------------------ >> > > IP >> > > >> > > Thanks, >> > > >> > > Jose >> > > >> > >> -----Mensaje original----- >> > >> De:tcmtf-bounces@ietf.org >> [mailto:tcmtf-bounces@ietf.org] En nombre >> > >> de Luigi Iannone Enviado el: miércoles, 10 de octubre de 2012 10:23 >> > >> Para:jsaldana@unizar.es >> > >> CC:tcmtf@ietf.org >> > >> Asunto: Re: [tcmtf] TCMTF: two kinds of services >> > >> >> > >> Hi All, >> > >> >> > >> On 10 Oct. 2012, at 09:58 , Jose Saldana > wrote: >> > >> >> > >>> - Tunneling will be used to send the multiplexed packets end-to-end. >> > >>> The options in this layer are L2TP, GRE and MPLS. >> > >>> >> > >> >> > >> I was wondering if the group might be interested in exploring also >> > >> other >> > > form >> > >> of tunnelling, e.g., LISP. >> > >> >> > >> Obviously, since LISP is an experimental effort, it cannot be tagged >> > >> as >> > > "best >> > >> current practice" and included in document (A). >> > >> >> > >> However, the group may have a slightly "larger" scope and include >> > >> alternative forms of tunnelling (and/or multiplexing and/or header >> > >> compression) (may be documented separately). >> > >> >> > >> Thoughts? >> > >> >> > >> ciao >> > >> >> > >> Luigi >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> tcmtf mailing list >> > >>tcmtf@ietf.org >> > >>https://www.ietf.org/mailman/listinfo/tcmtf >> > > >> > >> > _______________________________________________ >> > tcmtf mailing list >> >tcmtf@ietf.org >> >https://www.ietf.org/mailman/listinfo/tcmtf > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From pvinci@VinciConsulting.com Mon Oct 22 09:06:31 2012 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 1F16621F8523 for ; Mon, 22 Oct 2012 09:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.302 X-Spam-Level: * X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29QaFTKOxk+s for ; Mon, 22 Oct 2012 09:06:28 -0700 (PDT) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id AED5D21F8417 for ; Mon, 22 Oct 2012 09:06:27 -0700 (PDT) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 12:06:17 -0400 From: Paul Vinciguerra To: "lisp@ietf.org" Thread-Topic: Feedback on draft-ietf-lisp-introduction-00 Thread-Index: Ac2wbPXnc47ZT2HlS52E6CPay1gBTw== Date: Mon, 22 Oct 2012 16:06:16 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C9290F599@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.14] Content-Type: multipart/related; boundary="_004_6E5736BD68F770449C74FBAD975F807C9290F599NYDCEXCH01vinci_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [lisp] Feedback on draft-ietf-lisp-introduction-00 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, 22 Oct 2012 16:06:31 -0000 --_004_6E5736BD68F770449C74FBAD975F807C9290F599NYDCEXCH01vinci_ Content-Type: multipart/alternative; boundary="_000_6E5736BD68F770449C74FBAD975F807C9290F599NYDCEXCH01vinci_" --_000_6E5736BD68F770449C74FBAD975F807C9290F599NYDCEXCH01vinci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Noel, I reviewed both your documents over the weekend and I have to say, I think = you did a great job of breaking down and classifying all of the LISP compon= ents in terms of an overall systems view. Very comprehensive and well thoug= ht through. It was a good use of a few hours of my weekend. Another part = of me said: "What the hell? This LISP and my LISP are two totally different animals!" That may be because our backgrounds are different. I am a 10 Year CCIE who= runs a consulting practice in NY as well as a LISP service provider. Our = focus is solving problems for our customers, now. To that point, our entir= e business has been running on LISP for 18+ months and we have been providi= ng LISP services to our customers for 12+ months. All our datacenter custo= mers are accessed through our PxTRs - for voice, video, VPN's and web. We offer commercially supported gateways and mapping systems as well as mai= ntain one of the DDT Roots, vxnet-ddt.rloc.lisp4.net. We are outside of t= he LISP Beta-network, but connect to it through the DDT. We have customers= who have chosen not to be part of the DDT - yet. From my conversations, I= know of 10's if not 100's of thousands of EID's today. I'd like to say that your self-deployment concept is on the mark. People a= re deploying LISP because it gives them value today. The corollary to that= is that until you give these deployments a reason, that is, some value to = joining the DDT, the Internet at large doesn't gain much benefit. In a lot = of ways, it's like network summarization, it doesn't have to be done, but w= hen it is, it can save on resources. Islands of LISP are continuing to grow. This is not just because separating= location from identity lifts technical constraints on customers. Enhancem= ents within the protocol provide value on their own. In just comparing GRE= to LISP for a second, LISP's fragmentation of packets into equal sized p= ackets cuts down on the typical saw-tooth pattern to fragmentation and cuts= down on jitter. The choice to use UDP for tunneling allows for per-flow l= oad-balancing and better utilization of Etherchannels. LISP is better for multihoming than BGP. I'm not looking to start a flame = war, BGP belongs in the core connecting the providers RLOC's, not the edges= where the EID's are. Today, we have better tools thanks to LISP. Smaller= providers can focus on connectivity over announcability. "Broadband bondi= ng" (not my term) is possible with LISP. LISP is a tool to bring new capabilities to old MPLS clouds. All of these incremental benefits and more are the reasons that LISP is bei= ng deployed today. Unfortunately, none of this does anything to address scaling within the Int= ernet until we give these Islands of LISP a reason to add their IED's into = the DDT. I was fortunate enough to have the opportunity to address this at NANOG55. = The islands of LISP are going to continue to erode at ISP's transit costs = and will be the (financial) reason that drives the adoption of the DDT and = what brings the value to the Internet at large. If this is the wrong forum, I do apologize, fixing the Internet is above m= y pay-grade, but I'd like to do my part. All I can do is share with you al= l my experiences with LISP and share with you all what I see happening and = where things are going. Regards, Paul Vinciguerra PRESIDENT [cid:A37A812F-9283-4165-9459-FA9025300523] 120 W Park Avenue, Suite 308 Long Beach, NY 11561 P: 516-977-2095 * F: 516-977-2482 * TF: 866-998-4624 vinciconsulting.com --_000_6E5736BD68F770449C74FBAD975F807C9290F599NYDCEXCH01vinci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Noel,

 

I reviewed both your documents over the weekend and = I have to say, I think you did a great job of breaking down and classifying= all of the LISP components in terms of an overall systems view. Very compr= ehensive and well thought through.  It was a good use of a few hours of my weekend.  Another part o= f me said:

 

“What the hell?  This LISP and my LISP ar= e two totally different animals!”

 

That may be because our backgrounds are different.&n= bsp; I am a 10 Year CCIE who runs a consulting practice in NY as well as a = LISP service provider.  Our focus is solving problems for our customer= s, now.  To that point, our entire business has been running on LISP for 18+ months and we have been providing LIS= P services to our customers for 12+ months.  All our datacenter cu= stomers are accessed through our PxTRs – for voice, video, VPN’= s and web.

 

We offer commercially supported gateways and mapping= systems as well as maintain one of the DDT Roots,  vxnet-ddt.rloc.lis= p4.net.  We are outside of the LISP Beta-network, but connect to it th= rough the DDT.  We have customers who have chosen not to be part of the DDT – yet.  From my conversations, I know= of 10’s if not 100’s of thousands of EID’s today.

 

I’d like to say that your self-deployment conc= ept is on the mark.  People are deploying LISP because it gives them v= alue today.  The corollary to that is that until you give these deploy= ments a reason, that is, some value to joining the DDT, the Internet at large doesn’t gain much benefit. In a lot of wa= ys, it’s like network summarization, it doesn’t have to be done= , but when it is, it can save on resources. 

 

Islands of LISP are continuing to grow. This is not = just because separating location from identity lifts technical constraints = on customers.  Enhancements within the protocol provide value on their= own.  In just comparing GRE to LISP for a second,   LISP’s fragmentation of packets into equal siz= ed packets cuts down on the typical saw-tooth pattern to fragmentation and = cuts down on jitter.  The choice to use UDP for tunneling allows for p= er-flow load-balancing and better utilization of Etherchannels.<= /p>

 

LISP is better for multihoming than BGP.  IR= 17;m not looking to start a flame war, BGP belongs in the core connecting t= he providers RLOC’s, not the edges where the EID’s are.  T= oday, we have better tools thanks to LISP.  Smaller providers can focus on connectivity over announcability.  “Broadband bond= ing” (not my term) is possible with LISP.

 

LISP is a tool to bring new capabilities to old MPLS= clouds.

 

All of these incremental benefits and more are the r= easons that LISP is being deployed today. 

 

Unfortunately, none of this does anything to address= scaling within the Internet until we give these Islands of LISP a reason t= o add their IED’s into the DDT.

 

I was fortunate enough to have the opportunity to ad= dress this at NANOG55.  The islands of LISP are going to continue to e= rode at ISP’s transit costs and will be the (financial) reason that d= rives the adoption of the DDT and what brings the value to the Internet at large.

 

If this is the wrong forum, I do apologize,  fi= xing the Internet is above my pay-grade, but I’d like to do my part.&= nbsp; All I can do is share with you all my experiences with LISP and share= with you all what I see happening and where things are going.

 

Regards,

 

 

Pa= ul Vinciguerra=

PRESID= ENT

3D"cid:A37A812F-9283-4165-9459-FA9025300523"<= span style=3D"font-size:10.5pt;color:black">

120 W Pa= rk Avenue, Suite 308

Long Bea= ch, NY 11561=

P: 516-9= 77-2095  •  F: 516-977-2482  •  TF: 866-998= -4624=

vin= ciconsulting.com

 

 

 

 

 

 

--_000_6E5736BD68F770449C74FBAD975F807C9290F599NYDCEXCH01vinci_-- --_004_6E5736BD68F770449C74FBAD975F807C9290F599NYDCEXCH01vinci_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=14315; creation-date="Mon, 22 Oct 2012 16:06:16 GMT"; modification-date="Mon, 22 Oct 2012 16:06:16 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAL4AAABFCAIAAAB7Q8sQAAAKQ2lDQ1BJQ0MgUHJvZmlsZQAAeAGd lndUU1kTwO97L73QEkKREnoNTUoAkRJ6kV5FJSQBQgkYErBXRAVXFBVpiiKLIi64uhRZK6JYWBQU sC/IIqCsi6uIimVf9Bxl/9j9vrPzx5zfmztz79yZuec8ACi+gUJRJqwAQIZIIg7z8WDGxMYx8d0A BkSAA9YAcHnZWUHh3hEAFT8vDjMbdZKxTKDP+nX/F7jF8g1hMj+b/n+lyMsSS9CdQtCQuXxBNg/l PJTTcyVZMvskyvTENBnDGBmL0QRRVpVx8hc2/+zzhd1kzM8Q8VEfWc5Z/Ay+jDtQ3pIjFaCMBKKc nyMU5KJ8G2X9dGmGEOU3KNMzBNxsADAUmV0i4KWgbIUyRRwRxkF5HgAESvIsTpzFEsEyNE8AOJlZ y8XC5BQJ05hnwrR2dGQzfQW56QKJhBXC5aVxxXwmJzMjiytaDsCXO8uigJKstky0yPbWjvb2LBsL tPxf5V8Xv3r9O8h6+8XjZejnnkGMrm+2b7HfbJnVALCn0Nrs+GZLLAOgZRMAqve+2fQPACCfB0Dz jVn3YcjmJUUiyXKytMzNzbUQCngWsoJ+lf/p8NXzn2HWeRay877WjukpSOJK0yVMWVF5memZUjEz O4vLEzBZfxtidOv/HDgrrVl5mIcJkgRigQg9KgqdMqEoGW23iC+UCDNFTKHonzr8H8Nm5SDDL3ON Aq3mI6AvsQAKN+gA+b0LYGhkgMTvR1egr30LJEYB2cuL1h79Mvcoo+uf9d8UXIR+wtnCZKbMzAmL YPKk4hwZo29CprCABOQBHagBLaAHjAEL2AAH4AzcgBfwB8EgAsSCxYAHUkAGEINcsAqsB/mgEOwA e0A5qAI1oA40gBOgBZwGF8BlcB3cBH3gPhgEI+AZmASvwQwEQXiICtEgNUgbMoDMIBuIDc2HvKBA KAyKhRKgZEgESaFV0EaoECqGyqGDUB30I3QKugBdhXqgu9AQNA79Cb2DEZgC02FN2BC2hNmwOxwA R8CL4GR4KbwCzoO3w6VwNXwMboYvwNfhPngQfgZPIQAhIwxEB2EhbISDBCNxSBIiRtYgBUgJUo00 IG1IJ3ILGUQmkLcYHIaGYWJYGGeMLyYSw8MsxazBbMOUY45gmjEdmFuYIcwk5iOWitXAmmGdsH7Y GGwyNhebjy3B1mKbsJewfdgR7GscDsfAGeEccL64WFwqbiVuG24frhF3HteDG8ZN4fF4NbwZ3gUf jOfiJfh8fBn+GP4cvhc/gn9DIBO0CTYEb0IcQUTYQCghHCWcJfQSRgkzRAWiAdGJGEzkE5cTi4g1 xDbiDeIIcYakSDIiuZAiSKmk9aRSUgPpEukB6SWZTNYlO5JDyULyOnIp+Tj5CnmI/JaiRDGlcCjx FCllO+Uw5TzlLuUllUo1pLpR46gS6nZqHfUi9RH1jRxNzkLOT44vt1auQq5ZrlfuuTxR3kDeXX6x /Ar5EvmT8jfkJxSICoYKHAWuwhqFCoVTCgMKU4o0RWvFYMUMxW2KRxWvKo4p4ZUMlbyU+Ep5SoeU LioN0xCaHo1D49E20mpol2gjdBzdiO5HT6UX0n+gd9MnlZWUbZWjlJcpVyifUR5kIAxDhh8jnVHE OMHoZ7xT0VRxVxGobFVpUOlVmVado+qmKlAtUG1U7VN9p8ZU81JLU9up1qL2UB2jbqoeqp6rvl/9 kvrEHPoc5zm8OQVzTsy5pwFrmGqEaazUOKTRpTGlqaXpo5mlWaZ5UXNCi6HlppWqtVvrrNa4Nk17 vrZQe7f2Oe2nTGWmOzOdWcrsYE7qaOj46kh1Dup068zoGulG6m7QbdR9qEfSY+sl6e3Wa9eb1NfW D9JfpV+vf8+AaMA2SDHYa9BpMG1oZBhtuNmwxXDMSNXIz2iFUb3RA2OqsavxUuNq49smOBO2SZrJ PpObprCpnWmKaYXpDTPYzN5MaLbPrMcca+5oLjKvNh9gUVjurBxWPWvIgmERaLHBosXiuaW+ZZzl TstOy49WdlbpVjVW962VrP2tN1i3Wf9pY2rDs6mwuT2XOtd77tq5rXNf2JrZCmz3296xo9kF2W22 a7f7YO9gL7ZvsB930HdIcKh0GGDT2SHsbewrjlhHD8e1jqcd3zrZO0mcTjj94cxyTnM+6jw2z2ie YF7NvGEXXReuy0GXwfnM+QnzD8wfdNVx5bpWuz5203Pju9W6jbqbuKe6H3N/7mHlIfZo8pjmOHFW c857Ip4+ngWe3V5KXpFe5V6PvHW9k73rvSd97HxW+pz3xfoG+O70HfDT9OP51flN+jv4r/bvCKAE hAeUBzwONA0UB7YFwUH+QbuCHiwwWCBa0BIMgv2CdwU/DDEKWRrycyguNCS0IvRJmHXYqrDOcFr4 kvCj4a8jPCKKIu5HGkdKI9uj5KPio+qipqM9o4ujB2MsY1bHXI9VjxXGtsbh46LiauOmFnot3LNw JN4uPj++f5HRomWLri5WX5y++MwS+SXcJScTsAnRCUcT3nODudXcqUS/xMrESR6Ht5f3jO/G380f F7gIigWjSS5JxUljyS7Ju5LHU1xTSlImhBxhufBFqm9qVep0WnDa4bRP6dHpjRmEjISMUyIlUZqo I1Mrc1lmT5ZZVn7W4FKnpXuWTooDxLXZUPai7FYJHf2Z6pIaSzdJh3Lm51TkvMmNyj25THGZaFnX ctPlW5ePrvBe8f1KzEreyvZVOqvWrxpa7b764BpoTeKa9rV6a/PWjqzzWXdkPWl92vpfNlhtKN7w amP0xrY8zbx1ecObfDbV58vli/MHNjtvrtqC2SLc0r117tayrR8L+AXXCq0KSwrfb+Ntu/ad9Xel 333anrS9u8i+aP8O3A7Rjv6drjuPFCsWryge3hW0q3k3c3fB7ld7luy5WmJbUrWXtFe6d7A0sLS1 TL9sR9n78pTyvgqPisZKjcqtldP7+Pt697vtb6jSrCqsendAeODOQZ+DzdWG1SWHcIdyDj2piarp /J79fV2tem1h7YfDosODR8KOdNQ51NUd1ThaVA/XS+vHj8Ufu/mD5w+tDayGg42MxsLj4Lj0+NMf E37sPxFwov0k+2TDTwY/VTbRmgqaoeblzZMtKS2DrbGtPaf8T7W3Obc1/Wzx8+HTOqcrziifKTpL Opt39tO5Feemzmedn7iQfGG4fUn7/YsxF293hHZ0Xwq4dOWy9+WLne6d5664XDl91enqqWvsay3X 7a83d9l1Nf1i90tTt3138w2HG603HW+29czrOdvr2nvhluety7f9bl/vW9DX0x/Zf2cgfmDwDv/O 2N30uy/u5dybub/uAfZBwUOFhyWPNB5V/2rya+Og/eCZIc+hrsfhj+8P84af/Zb92/uRvCfUJyWj 2qN1YzZjp8e9x28+Xfh05FnWs5mJ/N8Vf698bvz8pz/c/uiajJkceSF+8enPbS/VXh5+ZfuqfSpk 6tHrjNcz0wVv1N4cect+2/ku+t3oTO57/PvSDyYf2j4GfHzwKePTp78AA5vz/OzO54oAAAAJcEhZ cwAAD2EAAA9hAag/p2kAACAASURBVHgB7X0HnN1Ftf+v3b69JdndJJvdbHpv8CghAoYqgVDliYLw B3nY8FlAfYgNBHmIDxAVRBAVjTRDr0HAgIH0sskmm8323vf2X/l/vzP33t1sdhOD+WgMO2zu/srM mTPnfOecM2fmLqrjOMqxWDAq1VEc1cZ/ioofxVHEtaYei8P9F4xJ+xf0+U/pErgBXFRFA3rQoeNY /ByFzZETvnHkSB1dlIgYIEV1VFWFZVUVndA5unj89+bmmLU6igLPBEel9US7m/oa4Lts21aFBfr3 1thRw/0xDB1bUe2YE33o/fuveubSNTWvaQoGS+c1Wo6IBI5d6DgazMwjH/zy7fq/GG7Xz9778Qct 7ynKMeugjwgaDovIMQsd+KoXqlavrnlSNWy/yxNxIvf87c663urDks5o5YNI4JiFzov7nntk88/8 qsvQNM023Lq7N9TdGmo+iCxGXx2WBI5C6NhcB/EflkjiH5fWiQtFvBwasjgKV96immy4vvG9xzbf 7yimqhmqYsS1qK45V8777IKxx4mKox9HQAJHIXSwMhKZGDE6DakZJGhEfoaIwUsslkR+Rq60LTwU K29bsVDVVuM7O3f/5IMfRu2o7kVkg2WV7ViR08vOWzH9cpA5AjIbJZFQzdEmCGlgZO5OfIpsHvGh OFQ8U8S8kWslO7Vu0hQduZzarqr7N36/Tw15dY/muGxdjSnBUyaede28z+vEjXm0Dfffl5+jbxbS MjB9R9jAsDjCpjgaXJKwNdxWEO/kh9htwAsASrE7Ip0/3XJnQ6jOr7kc1cTiXDEjCwpOuG7hjYqq 01o5pDxajogEjjro0OggyOHOGp2VjVQwgWHpcD38EYiSb2l35D4DUzh94d57N/6wpn+vYXg0TTEN NWQFy/NnfHnhTV7Dq2IjApnlBN6OiOg+6kSOOuio8ErQMLeglLhi4kbsRum4VBWLNghYEm8TcQtv VUQ2j+/5xa6u9Wm6x4ucsaabdqw0a/p1C76S5c11ADJUIhalm/uoa/2IjP/oS5HBr2hii9tWXIaB 4Hd7x2aYoTl5C1XFBa/laCbCYtgfrLkFjOiDVlX84t36V3OMdJOOCxiJ5XvGfHnBTRMCE/BARVXu QgA/R91UOSJa/JcQOfqgo0HXDpRN32I7GzrX/e/6H7hU7SvzbppbcCJA5Wg64IP38FIaoWC/vHfV 2voX0t1YUBl4ZzrxHG/mlTO/MiGtjCRIDzgDzOgJBd1/iaiPtU41EVWYMOkQLJ2EzThCFGnbTXmb fJh4N+wvqiYR2pIcaCWr8RYdpSqIN4kUjagjr2UroW48VZWtXZvv33CHbQUVM/rw1p/s7dlBgyTW 6lh2EWOK8teGl16o/l2aEfBrHt1QPZrpNvSLyz83J3cBN8+Z8KG5EZET3Z9kLDEc/BJXgrEUt4Ij 8SGEI6/wmRDFAIVk84EGH6UrjTEAogUKVSRUcEv4UKJc1Dg64greiPMuB5cMwxQoCg7CFtGroyVl iwsRoJCsgJfwG5IyEndi1R2HaaCK0VylLWyPtP5m2wN9Vm9ACwSwk2D2/XbrTxt7a/GKKRzyqW1p fuXV6kfTdLfPcHt0xc2W+ienXP8fhacriouBjU7g0OAgPWjr6Eks0zBSkmEALrAk8j2CJz4fKOiF QsADJIccgwwz3MYjQQEdMAfF9/gQc2Og7TF/hXjBclSGCxSvUDbzbkIxeMr5KqStos5gM3GAYIg2 KgT6YKwBvSJDxwcChgKgEDdWyHgHy2E7yMiwSygF+Rj8djk2ky64RpgLfXh1/1hfrldRPC7Nrelp bm9HuHbVznv6Y72aWGNXd215ruo3ihP36oyKDI2LsNNKLjt+/JnUJuCgJSGiQekGKBsEkrAuqMDg R9gw9op/wxcQJXzItuCWshLrPNlE4B2BlKKaGGOC+PCUjrWnPAZVsbfn7R3Nfo9h2YqOgNLSpk3K Xjw1B/IWsw0SkSjgDDtIrABSWPuE4/bbm1oa2vp0A5EHgQJ7ArKO4taRZ9FtK26fNCevvDiD9oVI URrbwnsb++vae4G7whzfjElZY7M9kHR7uO1n629uDjUFdLdm6G6xOC/JmnblrJtbgi1PVvxvb6zN p7ssxQ28huJdJxatXF52FfSHlI40N1B5JGr1hKONraGOkNXW1hfHMl+Pg1VD99omrRdW/mguTeYQ 9dqWkhZwXbh0oqNgEMar65pauiOI0xXH7dhqZkA5e8l4t5soJZ4GPoeQOTZv6Ro0j7H6vYaOjj6X C0sYJR63SsZl/vhzi4oL/MCKsOg6DTIlRPswUoEWMAk372q//fFN8RjWQ6pua6blTMjz1XWG6Dss +qZoTM3JUsuLMkHNtMxfvLj7z2tqATio3NJcumMaunrlGVOuWF6W68u/dv53Ht5yZ2e43u1gC5Mp vea+ij9uu9ulu8LxtjRXGpjB/lQsHllUcOrHSj4J+jB6Bn2VFo/HV6+tf3Nz/ba93WBDoNQFA4QZ ojLGiwMutBS0JwY8srwGCMQcwHPNNM38LP/KkyfC6MYsdfU7+zbt7gR1xzbiSry0wH/y3LF5bgqN REgWGPqoFMaaU4t8n1o2UTNctPC64fW7app7V63ZByGK3SGGLKIk3Hribugv2BUtHI4+8PxuK664 XLrbhg13inM8114wBcJ2QaO62+3SEY+4FI+0ZG9vbX385eqYZRouW3Np2DtAqBu11Qefr3z09V3A 6hj/hM/M+mKeO1vDFqau+1Wvz53eFNzT2LfV78nWsb2puXXLmZI9/+OTP+fWvVA40j9gzbSUO/+0 447fb9tU2a+oLpdb1dEzjB88i2JrNiAEFwacoRNgJobkImyP8LZ8whlDzysOqKomrRTa6prqUiEn WBo3nB8Cc4gGllUKKPl7qGCO0XsDEQk2dy46tWTd7q73tre4afs1BA6r39u3dF7Boql5dCuJWPJg MgBuYPoffbl6d0M/JIqiGL5gKHThsukzirMhdW5vc4EEesjMxKEyILGqod/SdReEzjCcXcEuBVQ1 olkPPLM3PyNwzpLiovSpF87+wrM7/8+y4sSK4tIMxCloBCxqYSdWnDH11LLrfEYAfYails8N+2a/ /H7j82vrfT5AFprHCDTL1Dzu2JiAr7gw07GiiuNiNEZT6dA1H1A4BsfJTDcwEoRfEIsGlMDmYB5Y WAjQSUFYGBHJYPj0WSgfFcNjIAyEcdE1/YbzJu+s7envj0A5iBSipvLQC3vmTMpyu6FYTEzhy0f2 VxDctpreZ9+thUMAOWAhHIotmz3ugqXjO3si0KXYnkRnpm7hNZWFZRhED1cBWw+PANqWHVcsI6bD 9hleRb37T1vSvMYpc8aWZy48c/JnX9vzmKrFDOhGdzHWwPLHsgp8Y5eVfjrTkwcyb29vraxuu+rs aTBef9vRAvfoMXTTMVXDE4tbJ8zIvXZFeWlhQMWyEZ3RSibGQ+QwUBsYHkCDZ3iCWuSVHg5rKyzT gBxL0VWEQRY21mwO1QaEuEalFxxEgzg6hgtXWJAgZFZWlHHZsgkxEwEhNwBcmr11T9fv39grVAzB cjJBhkz/UKwQKW7oGnjrKNGY/chLlW29EbgVy1RxmxVwXX76JBy1ikPKKA6XxoCpaTPuoJbE6g0Y QPABIpGYPSHPP6c8yzRjtukAUsGIc89TWzZWdaG76bknLyv5JE5sQVdeuAr4H8XJ8GcvK70mxzcB dCvqe3702ObWvpgOA6cq4XgM2SoYDKQQw1GrKNt1/YqyssIM4C6h3SRuBCNECS5SBbfyCWuJNwC3 ienjxE2sE4EZk8iBLROQE2ZZNBYi4nCEVBDY08tz5KKIRBONk6zGX4NKKiAQj1kNhe1S9Xkha0ki Yr+PdShCKoUS5oWw4eKZAw5RhKYSapOEBz7ZaqCAcqJrPJOv9q+QqIo540Knoql23tLJ86ZkB0MQ Fnolqp54s2FHbadUM4CSjJUhKU1EFAyfZSbn+Xfr3tnU6jU8AAeiAttSz1s6YX55nuwe+CBBTE8u h8ERrb1kwQakMIctCy/T033fuGzm9PGZ4YgZdRyPptY3Re/6w9a6jig8wpwxpy0qOsfFsAN2yeVz pR1f9J9j/JMhl5rG0Pce2dDSEYSZUWy4GDoUrBUdmyi041Z6mjc/N130Lbv9MJ+QIIeQKEwhoEiQ wWnJIo6dYZDwg0AaNt6Y00JUJXwjPrG2H+TRkq3YFkYwSYV2TsxVPGZDzgUBYF4MNKf9EwYcnhdt TXlDzwnfCpPOruECKGocHMAl7WwSGewC5HnLDoQ6ODJQ4k+iyPkjP5PPEr85qRgPClRm+dQrPz45 I2DAvDuWrrqV+vae371ajZCThX4I8YrF3lGY8QASMFytoT3y2Ev76PjtmKXFsFyaPjHwmY+PJwRF QTO8w1wQPQkOhQhwhYfEk6aaZjwajRdk+m65el7xGH80AmvleNyunft67n68oi8cw1AXjLlg9rgz HDWMldh/FF82MXMuKOxrjHzj5+t31ferOBKIe0iT849BDPqEqvDJaYclkLCVkqUP9ynJ8pPROHqg 8iHolM2Cr4RzjquWpho6upOqolXCxKM00AZspKCQYgNqFujAA2ha1OA7kEg9JxFaEiFVoV0XJgdu DYSSdP0w4KAep0oJB64ZmZwDc1xVok/aSYndJFl5y08SFM0SvLH3REkhKfmAvwHWOAGOnoTVOn5m wUUnTIyAIw0YcHweY82G1jc21rMu5M+kGqJq2Ik4BojGmBN488Az2+vbu+GqsJaxow5Cyf86f0bA 6091iZYDQsdNElJoizukV2h1GFgAfeb43PRbrliUn+0ORWKo4POqb26uvWvVNrSCPOYXXTSn4KyF hReOz5qHt+394Vt/u2F3Q5dP5Bls20WGFATS4JeLImiJ1zBDRFGKI1Y63JIcAkQFCwyJiSS8oCLp cvaie2KXA8N6gzdC/1Qi5IyhQ2ZcUeBSVE5cUW18gsJkadKbMqITAxJvQIRWhsATJJBO5ZDwg/94 gdALu8YgherIpolPfBDPeCSOK2EyAcTgkHAeXFBB8A8xiZkm3klUkNwBhXBLsMxfwKZy1dkzphVn hGMW5A7BR03zvqe29vRFWFF0BmevQENgEoOwHSTKXt3YZhhuEIfjiYStFSePXzwtHywIypxqtDgw ARx2okhOLHgTmB1QsZErBD3o14W5M68s80sXznLrCG/jWM14XM5T79Q/8FQlWqHveWNXlmWd4qgu 07F+/nTlloo2w+Mmdeao5TlADp7UhCVE77ABCtLN/1gBQcxe/HA4EI8Uh6Qpr6EgSpHryThDIdYU oKG5w0upUjwnnvGIT8WP/EgQkRRpXxIgo0+gGPEA/yTGxLUAqXjCNSCIEM10I+BUOBSpAnSCl/Dh kAk3ltE1uyc3LAMDIfvQK6oz7YBC4MorcTv4A4QAXB5yoLsU5jcQsK4/fxbIRuB9bCyCtZpW677V O5EroadExpnsC5Rpakd/9Ncv7wkBaDCKcbs/FplSlnXVWWUYKshh0SE7A3MoQuIW4EI/J8QkFiUM 6miKRRgBgXFiacryxUVfvGCqCLHBnserOA++tOuJN6shAtSGQYF8Yqbd2Bm2VG6mw8EyXpK+NeGk wACoUseMqGj7E/wMFsHff82ZkmSS45GaFlqXtgEd/Lzq0eVrLvvkm9df8/aNF795zf/tfAj0xQ6/ 0BDVS11AQ9ScdD2SDpilVJjaxg+HiUJJoxpAj6MCVI9AHCTA+cZBsVX8vu2/Xvry+d3RflSIKVEs LRlUYbmDE3DxvtpgbcQMMdLAEoEmh5QljNkFQUlcygIKxBYrsHf+8GqYAio49Y10BQckWMdvY+mc vIs/NiEC5MB/OECM9eza+rUVWOlgZ4ropr1BclhRHn+ldkNVswd7DLZpKpbPZVyxfEpBRgBUpdFF RciDChRGZQA07EwG/6zAQvRA54guBeuOcvnppZefMSGIBZKI9hAV3vWnTWs2NmMwqEieFcVvcDLB BIDRpP7AHVjDU/KPfgFWXHGuJZU9jCQO9QgyJAYxXwV6aOFQKNpEgT2KmdG1je9HzMi35n359kXf vGvR9y6dtNJyYlAhJzn+gQb9J40BSEGLoAi2SVjMeJgo5rjxnFpDG9bnBfvheDlveAkQIIGL+AE3 epfV1xLpw1W/2f+TbQ/+au9vWUtFmlu7Z+ev5j975oaOCjYBQohCUkI7Dgb/UZO0Mbxlp+yRIztU oTPGfoFAImiIZbogcMVpU9Zua9nTGAwgf6qoff3hXz+7Y17JCX4fljiwJhi/umVP1+/W7AwY2KOm GQzGoytPLjn3uEJ2Su/A7uXpKuIG6x5Gl5S45BJiApKAOdThcgCOG6wzmU9Hg4hKU1xfOH9ua4f1 4nt7kYd2qd5YNHrbbzblZyyaVca1G0bMeWcZ2CdA5TCmm/D7mF7MAGDyAjeEmTA+qEmNUNgfrlCi hCD0jiEMpQGBwP1i/mS7M2ZnzcDgBbZZDaw0hduAITQHcrI86ZnedDwNxcJdZq/fcGN9ENWwNW+M 82Xp/IqqFrRD/ZG+iBPFdZrqy/Nnx1WzNdiZ4U1P0wMYQ8gKdUS6CtzZHsOPGNNQ4x5d64h2/bXl 3XRXxjnFyyHTsZ4xZ4xbluPNnZRZBJY74p1wMiEzYtpx7Bz4DX+2Jw2H/8FhZ6Q7ZEaRqvUohsfl teJWpj/DBfBBiAQ1RDdUbowtE2PkVGeRei3K9332zLL/eXQLJjBsvc/lfntzx6o393zmzClihanE bOu+p7Z19sfSkYF2zL6YWTou7XMrpoACkcjsGQwP+oZpRQRDxLAD4apEF5St7M5EThIzwkKSlnyi gBfVxtF0y+tSv375rM6uvr/uaPV5gStXfUf/LY9uvefzSyYUBCgxC2YqbiM1jIIsDnqDBhEm0yjC 1iB0N0wnxh7JBUJIMgGBJEwU7JmciOx2mCKwJgYEMXCJggcmlhAi2knUl3jEhCLfGLpYFXMJQWGS /v9svP39tq2Z/kyfokfi4Q4r+JXp155VfNqLTWvurXhofFoxJidA1WK2lqdPvmfBLV2xvhs34DOY p6VFdLXUU/Cd+d/c0LHxtu33fnbSJSsnnYtetnVW3rDu69+d962zi06BBab/5pzWAYj6YNO3Prg9 YoVvX/TthmDdszV/Pil3Ub4r62vv39pnR9I1P3bvQvFgvx28vvTTK0rOfrv57bt3PIQMgt+bBjJ9 Vsireu48/nvF7gJMEov7L8NMOAmdYUQGEZ1/0qR1OzqffKva7/PApBpu59cv7v7YovET89MgrN88 V/nBtrY0PE2i4qozywtzsRuAAE34ZnHmASc6UFnCEZ/Sdwm1CZvMe0vDuoBxIzNCDHM4o+FxsCqg PcxPd9967eLP//id3U19OAgYcBsVeztve2z93dcv8vi8sDrQFT5hpnQrzsODyCbifAUySzQQABMC Vq6zaCwSuIFaJWq5fAVPEkbDSQEtOAMAA5GuAm9wkMAnGpFCwrKKK4ZoIIVQlD5dppapy/ZYx6bO LT6X51cn3JWupX3QueGiNVdXBfcqzqlhM7Kvt/7+JbfNypkZtWPX/vW/t7Vu7TMjVX31e3qrzh13 1rfn3QgJQH/wT32xUHOordcK00WAByfaFmwzrbCYnJZuuRl3YOnrmLNyyu8/7g60g415oub5it7q mBNC/FMXaZuWNumOhbfgm9RrWzd99f1vP9v06idKztzcvacuWPfNOTeunPgJ7CfeuuGH73duckzs RGIYdI047ERTuH+R49//mbijc1a0G1bMGJeXFYtFIUCciWnttH62qgLvdzWE//jGXuwe4wfmJBSJ nHfCxAtOKU2oAeoDJjhBZeGUopuCKUA2D4DAK6lHKlRk+7l0QaBtMs1FmyPMD6csq47P9X77yvlj M73MSVuWx6u9vr7+tj/siCARAH3ByqC5g2ALaThID/YMvYl0jhKLYfPKtgzsfqgecEWrQEdJxiSC D4KbBPeQHdrBljhRhOZwkkQPAAKtCsMpAMRO0bVqYy4BQcAcxgBPCT5Qy53uTkvX/Xg6xlvkgoux sReGCgq2iemhFdujurM8GUh1gjDOdbhtT7Yvk1JCNEDEw5/ZcEnYxRMPMWykIFycaYiT8RCjJpph 53WaXCAd/hwARxf4ahFWLarjV7m9h31ogG9q5qR8f3bMiuFgDCa3151W6C8GP4aGU7oQPtSE3BT7 he4spPbZ337lACwJgSbGrihFBYHPXzDlfx56D1A3bBMn8V5ZX/exd8evrWjY3dSb5fcB8rGYMyY3 7ZpzyhlRMCHGCSmcGgYDJmA/2Cv7pvlDAdqYQRZsAQx0/4QIZz/0iiuwDAChDQYBHem4wWr/pk/P vennfwtFFZ+qBDzep9+oCuguw3HDElhqVHc8QB2tjlAn8k4W4mduaGDL3GzoCdY0dc0oyZGjF0YH NVMl0Sp1P3AB4VNzwmwpLkKUeReMFLE7vqMjBifIsQnUi+/98Bbawy1CeEAIZ0CorQSgmDJL2DmA GCaRsZjsBc1pUNQMPeDWAi/Xv9kd7YY3L00vuqL0EuT9OBrIk9OJH7iBlcM1oIEeISt8iQi7gMgg c0ohP8D1MUJJrLZwMkVDjEGjSaNINeOGHKo474LUCPwxwnnybCpeRXdjOmoQKI60UG0QKhsNLsTV gQX6Ux2eh4KCzz+lZNn8IsRxoAT5maZz8y//+uw7tek+L+wN6mDOX/eJ0snFmaCD8YiVDLrEtQAt /A4nKAua8xdMD/a+ySYxw+mL1RDOCYFD+gK+AfLAOqsIGYj42f74osKvXTrfsbDHFY/DH7ncj63Z 9fa2Bh7YsN2I7EAPC3WQgdhwigbCgoqjNk4ra3XN4YdeqGpo7Y9GyBtVS/bI4QHTSbxPfgjc0ICA N+ztQXNgEVEPxpmsImYFnpBzxumoRmOAQoERa6oizgYBMJg+iN01hO/I+dqmpnlgHoRhIgrR3Obg ZmbNuHXxjddMvnRa1pStPRWP7v5jVXCfoXqhfyiUkw6C4vE5dEMGcUFPCnkRDZQaLRfW55Aq6ELK NJA8aQC7zHANd5CZ0C8kTPQBI6wD44T9ijhcPxUJzIEkXh+AG9QfxuqQDDtHWpbxJmrcsHL6tsq+ tr5+5AgpCSQIMETV8dhOf8z52PyxlyybxiaQlJh/QvFC7/weOM0mAAMgYD2LKuCJKyEyRalC3gxw iXC8thD5Y+Ji2KwAucOai8LkjaJcdvrEpq7+e57enqm5LRPzWw3GTARImI4GF+Mm12ugpTjnHj/+ pfdqYo6LkwCN3c5Tb+3ZVNk8ozgzPQPHViF+jl3wLDqS3YhP+RCfKJlpnps/NY+8ULiaY7osHUzD 5og1nMQd+gD7VBJSklhtCt4xRJoQwg6MojkQwzFzAkurAxBg5DQcMLUYvYCysNeOc2LecWoehK1V 9e17ufaNqBnG+DFCNxQC7SKtDEpi3lGxbI+OsDYBG5Q0exX/kE1BL/xiGq07gj4YNgICmEb3IEJ8 kCcIHGtgoBAT2w0SONZCZolT2AzUkDyzriwjQkfIige50cnMkryrzi3//iPrPDj2iQ5FiKhpOtSW laF9YeV0rJshZZkeYEPRSkiTuTpIECq1sTonrrmCZWqKc5Sc4RUdq4iNQASnaih4UqGlxBTCB+ca /C3mjKp86cLZTT2RP7xSKyIfEYNDADaiLhuJSUQDJKxZpy0af9XZMx9YvRWqcNNfq363q6YtWtnQ JNIBEA0BADWDHTK/f8FbPADX+dn+b14xlxOXZzywlMNy2TRs+FCgh15IsJpQANbJ+FpGc2/n49XP +FQ3ziAU+AumZpV6bL0hVPt8zctQW32oMY7UlQNfDz1Fo3ZQTEV2b5rRCGyWorfHu99tfh8ZPxy5 3ti+DUeaPJrXg6yNbb3W9G6GO8uvevrsYJTpVTZEyIKUEiSA3g3H2NZd/fS+F7H1u2DcPCAHATgG gv29uB2J2nEXwEBbgjAwFqfo4EH1vnjPa81r2mJdme5MW0WmIw7DIYCP2qwvfQivk2VE6LACFQ1t w1rZly4v3VzT9vTr+2JYqAPCihONx3PTXV/71MK5U3LZP/TFYTA0gVLQE6cGKejwcT290QhXBpwL oUg4EsWQaU76w1ZndxgBOHQQDNndQUAbSsFxX4EyhD40/jDCcPQcA47aAFnfvHRuc2vojQ+asPfl 0+HMmWFH3nDimIwzTywBYUx+tPzaZXMmF6b9/rU91a3hSH+8JxLFkRJOcToyCANwQrYTyUyYBzwE +UQBkiR0MMsZfOM1wGeq3cF4R0+Qp0rgWUyr149dEk5ZeiUUZN5147LJl8Z3//Glupdg6MJ2aFrG 1BPzF11cuuK5+teerH0OZHEG8tRxJy/On4EW+d68JflLfEiVo6hacdZEoC1dc+0NNz7d8AIcM8I0 LK4+Nf7c0oxJhYHCi0vO3tK16/GqVfm+cSvHnzE/a9bEjAJwPiFQtLhgHoxDnjv38tIVq2pefqL+ eUszS7PLigJjjx+zKM8PQCA0nlocYNYNMxBjnp49vTCQA6WcVnhCdW9NRc/eyp6amdk47YSACCpA JcwfRshEDqfSfkVYi/2eDLpJQQcXTrw7pqz+S9Vb21paW2L4du7E/IzTlxSdflwhv2ogzNqglgOX mF/dveZPntjgNTBT4QStiO1cfPyEedNyoZLX1je9taUBpgIuJRqLl431f+rj5W6c39y/CF0inKTZ 4e696jR3O0+u2bW+sru5ow+DzE73l4/1X3bm5KlFPFmBv6sDYArvoEVizp7azp21XbVt/X0RrnJH KAnPiLeDjZDfp371kjmQHtwozkDi6K2b4YBmxq2xGd7Lz5mG4wawwpgtcMLYu6axHLEk3iZRCvyK 6QloivQPZiCaHji/R6T3d7ygDtkfhCYmcqoJPSymI2MDPBNdEylwxN/dfOe65nUPnnxvcaAoYTqG G9eI0GF3JiBkVwAADUJJREFUAm4ABuwAUyVwG6BtK+3d/fABWWlIYuIpJiV8JOxb4nR3ireBC3o4 2huBXjFBGdgL+nycMG2yR7SSM36gubiiOgUNuLOUVcDhkNbeINI2GemegA8mWRbYRPILXkVN4csT rw6u2kQl/BpAD+ISGHeMHi41ERewmpQ1kwI0tmJ4eEprm+SCtfYr8Br0jzRpaILIAzGHkAo+ObhE pxi+vN2vcfJmgLHkE/l7WKGJVxACXkquxPChCHhbprwSJHYGq6r79rksGoGYYq6qeaaht/nRpXeP 8Rfi6yMJGEB7CSKJViM7LA6G/WFwDG+4UCI+IZyCnDRBjjECAnmMVEWWdsTJJvaWhL+BJ+EwSBJM Uj4YhBgTTL7AEoglGBv6i06BlTF1KHomEjUDX/QszsWXIsSslcQpd9AXCqVG0aPwnEJMnNAjdbB/ hwNikhNTSAOb9iDOsAcgoH/GSVPww0UMVr88vsLseVIh+xOEIBk+J4oAEAgklAqSeCU/QYAMJ2v+ w78F7iE7MCmGzxATk4FjgfXktw2UzW2bn6h5DgfopJbjlnnOxNOyXXkI6RBIw8hybhygYM7g4bnD Y+mGEhdQHEcuJA9O5ETkXMGYQRv778PSEZOMsqVo2AqVyTe4GVRfmCI+oW7wfEBzA5UYdfEV/kmW CTzCkEUiMek3EyaBOBWVRBXJurz8+z8FecZbWBfi2IsAOFQLLsjtwCgkG4KTkYhLUeCtEDk0id9o JpYFfJh4ItA9WDgj0fv7nkOizPFQ9CkG9mtJJhKCwug4iQkULGvAGLbZAWIxb/Zrw5sRoTMc9iEp /CQMFdRDJGLsUoUHkE4+EGiAsIWcIHK2kEMRNQQBXqUukg2H/U1tUchEEIpUnvyUT+Sz/Z4kRYaH KIepFTRCXyJsl23lEMCDdE1gO1EGuEo+GfQ7yQONCh5zCUFkozWHI0bP2sPNGT7/R0qyI9BIiS4h CihRRCPwSoAPFUotCMvAVS2+9ibkPBwYRpYjbSbIoaS4BnARQ4hv7bMD8oH1FDcFKYERCyRMv8Fq XJjDLCOlgNgoUQZd0CWNVDBIaUuEIFhLsCYW8JgsoqHgFcEHXibwIdlP2B5IBkM43ILMGVlERwKu CG44do4CrorM0FgIdOEpXNgIRcwd8kzBghPpN8AxyIMUZSSAxFFiMFK1I9A6rMcJasggSRWgsTTt AkYM7YX0xBDIDOoLodJKgV/2lXAFQ7od0eqIehiAkDUIwL1jdPxJFFAV4kNXUMghfLPkQPpLEuM/ QUe84JW4hdhknUQfg3+BF9ShS0LBsCFxWnzBEPmUT6TNEaMVShK15Sv6e1ZPDkq8Sn4M+1C8pMEH l5QDecRoCSIh7pR/FKsVypkvDlLYC+RIcyVIytHjpAZO3pCwaD0Chwche9BX5J/RCp0FMQDQo3sO JyHtxIjAC16LDBu1gDU5Topx6UMzSTsiRj2oq4PPQsoMHYj6CeMhR4snUkgIXxgBSHQOopu6ZMeI +1BfznjIh405F1AIciggAYhkHfFqyAeT9WwJhoUWiXnEHNJQJZ+QUzkiBMgDXEmFMoYgn7LCEPLD PhR1GLkzWJBFmgfcSVMkH9OQEFhSJImaQ39xxJJPMXwtHrWVij2tbT3Yu5TP1fbu0M6qDqZQk90N JfIh7jWnozta19BDSSVybegOkkrO0oTwMfcwFzFQLRJRd9b0xrAxKrqT8+TASTGyyGQzSkTEbbzA 2A+QDkFxsMlGsQrJivaSiiCUoA9EgockG+xj+HKANSI42HCgiTzGOdD8wNEe+GSg9sGvMEZRIfWZ upDteCsfcZoCoVh7pyiKeZKQnDy1BCy6opHod3+7bXNlC0ZBv+8o72xru/U3GyUMJRFSYlZX7JqR niQqCFKxyT4S13hOhNBviidiRmvrtrc8/MpuW8YIcurC+JFd0kEXFAttMoWJq+rW4E9WbW/pFcc5 aJMg6mRHqTGlYt5BT0Yv/yEJNHX2e1yulo5QZrp7XHYAx3N78dc1kC8xLeQR2rtCLV3R3Gz/WGQS La0vGK/rCDe3hbFZm51pxGN2Vx98C/Sk9YaidW2RDL9RnOdH877OELaHu8JmQY4HPq+9xxqT7Uvz 02XD/iF70tQaaQvH89Pchbk4XKXtbekPR+MTxwXS3FoQxxPDSn8s3tkeH5+v6YYTDTmdoVhhthcn 9dq6I+i6INMP4ETjdnt3756G3vZ+bHJgMgBIdKPAVXJyDwhn5LzOQJ3Rq8OQwI9+t7WhOer3mBFL /fzFM2cU537n4c31rd3HzR53/gnjv/GLDdkZHuxvfPGS6bMnZSFX9tsXd761sc6yjTuuX+JzqyKR rjV2hG95eH085sQs59PLS0+aM+Zbj22sq+/NSEdOXk0PeBo6woun5n/1kpkeJpKctVubfrxqR066 b2FZzg0Xlf/0yV2vrq/LywiMzU677f/Nd+sm/sBMd1/s2jvX/ODqJcfNyrtv9XYAZcmMvJ8/W+kR Wz/f/eyCghz33X/ctaWy3ZuGfR3TEJ4a5gmWSay7hgrhQDANrTF6f1gSwBfs3R7rnv8+ZXZJzu9f 2oejYTvq24+fXviZM8rvfXLHmFzv/V9cMndK/v1/2tUT4gn+T5xYesf1J2CH5snXq/lniJCfdpTH X6+ubur/0XVzT1uQ98hLe/oj+Hpr36KZY2/6z3nb9vTMnZr19U9OW7utsaEV33NghLKhsntvY/d1 K6Z/+uypu+sjv3u18sozJt913cKdDR1//ludYbiwqzwmy1M6Luv19U2hqP3u1rY5k/N/+efKgjzf HZ9bDCw+9Vb1WxtaHn1l581Xzvqvc2b4sWPMIBX+TCy0hlsGjULnsIBx6MpYKy2ZXpQdcC2YkdsT wjdYsZGoLT+pKDvTt6ex94KlE6Cnk2blBi0r2Gf6PPqUiWljMr3l4wId/WF8XZp/DVFRapq7m9p7 b3pw0182tvtwPBvBq62dNKugrDh9YnFg/sTc2SVjPG43Ng3Et62U5ccVLi4f+/1fb3jxvfrdjV1+ j/vipeV5OYEFk/NrG3vh4HDmH9/GPPekwncrmv+yoSEzzVte7G/oDm6paPn6g+vxlwIQ7nyws3Nx Wf78sgJYL2TqiRkuYmB8AM9hkg6j0Dk0Gg6rBs8mc0dPwcHtbPydDhcjXCVu+V1OTob3b9vbkFPf 2xD24U95uHAKAgt/Hd+13b2vryg/I8PrxiYAFJad7i3OT//hNQvvvfHEO69dFDBw+gXfXoPjQBjE 42w4lCOyvbAGMFLalOKsX9188tXnlj2+pioc4mJ6y752RCjYrMVWI84KNnUHI6Zy8uyxaV4Np53m Ts4tGZuGw5bzy8f89ItL7r3huC9cMDM329jX3t/fh639OI6X4PzQ7rr+6sZusD9s8mU01jksYBy6 MubrE2uqtlRhSz/6g6sX4KgDznvim9GQ//Urpn3nkc1X//DNxq7odStm5Oa5ojHrvme2P/xCJf6I 5tmLC3AiFhHJrQ9vPPvE4u17u255cD2+0HLq3HGnziuMAA88IYQ/2oddEeR5cXgoJrhh4uD+1RVr t7QiVzG7JGPlKRPWV7Z+9d514/IDYVO5eGnx1ur2TVUdtz647kfXL5k/Jf+Rl/aed+I48HPDhXPv /MOmb/1iA86gXXvWzAuXla35oPUzt7+VmenrCzH8/sFjm2aXZ371ojlihTXUyjA9cmh5jNb4uyVw 5e1vwfhfsbx0aklWUU4ANqGlvR/2JODhLK1r7d5a1VM8Nnt2Cf4AlV7bGq6obk/3ueaU5QQCMC34 om1/fVtwydS8YMz+oKINAfWc8vxxOe6GznCW1+X36bXNkTE5XpyJbGwLFuV7NB2n7BS02r67Iz3T t2hajteFlZq5vrINf9VoUVl2XrYX5372NEeC/bGF0/Jw1qu2rXcK/5Aj0iJ2TVN4857W3Bz33LKC gFcPhu3NlR3dkfiskpwJBb6W7lCa25Xmx5/rSmUeBgQxCp0BWRyRq/O//SoUfzMOFkI3YuUMsrxg zHmwBNhBeh88vYHLRCZm/waph6kL+V62HanV/jQO727UYR2evA5Z+0sXz8j2808awt7gk4kRnp1N nDBLKTJF50BNQ82pt/JCPpFt8SRVIdU29Wrw2yFEhtwObjL4VYr44IfDXo9anWHF8uEfiu0RJIQZ vXLlTPyIPaARSEoVjgSOVKPB1VIPUxeDcTBE96mGuMCrwZ+p5rhIURjSfHCdIdejVmeIQP7xW56r 50kwnOXHMW2mRpjgP0g5pLZS6h+WiEQDXqXUP7hairi8SH0OroyH8vnghoe8HoXOIUV0mBUws7lP hfUIz2kIp0X8SPAcCILBOht8neo1hYzUk2EvhlAetpWsI5sP7muk58N2lHo46rBSojhyFzzEjf99 gTQ23JCS21JHroOjgtLQxfpRwdS/OxNylz9hZ47oCYqjSTKj0Dni2uCSiuDhYhyJfHothszHXBl1 WMecSv9ZAzoGZ8M/S3Qf9X5GofNRR8CHHv8odD606D7qDUeh81FHwIce//8H6LJPDrZAfZoAAAAA SUVORK5CYII= --_004_6E5736BD68F770449C74FBAD975F807C9290F599NYDCEXCH01vinci_-- From damien.saucez@gmail.com Tue Oct 23 11:49:40 2012 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 A66B01F042A for ; Tue, 23 Oct 2012 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDzLo-dNDVtk for ; Tue, 23 Oct 2012 11:49:37 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 612F41F0C59 for ; Tue, 23 Oct 2012 11:49:36 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so1483806eaa.31 for ; Tue, 23 Oct 2012 11:49:35 -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=4AqJcWjG0eRL8dOgnStvFkR+a1U2hlzhxLUI7M8zlO0=; b=xpj1RjBoG5oLcb0e1kT42CJA7Qe4pqeeBogM08T4H3wJNZbOjU+v8BMPgW6J9tUDsp x3GziCQVZZf9HduUBIbOyEZ3x9Hzh7t9/cJg4xcPyjBMZpHsjXr15sHImqBgcMfJlpSr 11fxmFZF84WODmR9VAR7ATH7t2/FRbyhoFYKRmsU4WVeawJTebzZqoQDBOP4Aa1TUJjd WsIMebQXktH/muyda/PF3nKLyDHH/rG6ayWXhiekJW30yvYrMS18MFzo5yGS3sGrkAgc MLnwxi4M5mQk+bhh9McnxgQt/iSYQbcIM3D9ZSJZ/mA6n3BqnrTLLrL2hBncRat1fL5m Xr6g== Received: by 10.14.0.198 with SMTP id 46mr18360557eeb.21.1351018175502; Tue, 23 Oct 2012 11:49:35 -0700 (PDT) Received: from [172.16.139.253] (25.82.69.86.rev.sfr.net. [86.69.82.25]) by mx.google.com with ESMTPS id c6sm22233334eep.17.2012.10.23.11.49.31 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 11:49:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> Date: Tue, 23 Oct 2012 20:49:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> References: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> To: LISP mailing list list X-Mailer: Apple Mail (2.1499) Cc: Noel Chiappa Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 18:49:40 -0000 Hello, some brief comments follow on the intro draft. Later will come about = architecture. Damien Saucez >=20 > LISP Working Group J. N. = Chiappa > Internet-Draft Yorktown Museum of Asian = Art > Intended status: Informational July 16, = 2012 > Expires: January 17, 2013 >=20 >=20 > An Introduction to the LISP Location-Identity Separation System > draft-chiappa-lisp-introduction-01 [snip] > 3. LISP Overview >=20 > LISP is an incrementally deployable architectural upgrade to the > existing Internet infrastructure, one which provides separation of > location and identity. The separation is usually not perfect, for > reasons which are driven by the deployment philosophy (above), and > explored in a little more detail elsewhere (in [Architecture], > Section "Namespaces-EIDs-Residual"). >=20 > LISP separates the functions of location and identity, current > intermingled in IPvN addresses. (This document uses the meaning for > 'address' proposed in [Atkinson], i.e. a name with mixed location = and > identity semantics.) >=20 > 3.1. Basic Approach >=20 > In LISP, nodes have both a 'locator' (a name which says _where_ in > the network's connectivity structure the node is), called an 'RLOC', > and an 'identifier' (a name which serves only to provide a = persistent > handle for the node), called an 'EID'. A node may have more than one > RLOC, or its RLOC may change over time (e.g. if the node is mobile), > but it keeps the same EID. >=20 > Technically, one should probably say that ideally, the EID names the > node (or rather, its end-end communication stack, if one wants to be > as forward-looking as possible), and the RLOC(s) name interface(s). > (At the moment, in reality, the situation is somewhat more complex, > as will be explained elsewhere (in [Architecture], Section > "Namespaces-EIDs-Residual"). >=20 > This second distinction, of _what_ is named by the two classes of > name, is necessary both to enable some of the capabilities that LISP > provides (e.g the ability to seamlessly support multiple interfaces, > to different networks), and is also a further enhancement to the > architecture. Faailing failing > to clearly recognize both interfaces and > communication stacks as distinctly separate classes of things is > another failing of the existing Internet architecture (again, one > inherited from the previous generation of networking). >=20 > A novelty in LISP is that it uses existing IPvN addresses = (initially, > at least) for both of these kinds of names, thereby minimizing the > deployment cost, as well as providing the ability to easily interact > with unmodified hosts and routers. >=20 > 3.2. Basic Functionality >=20 > The basic operation of LISP, as it currently stands, is that LISP > augmented packet switches near the source and destination of packets > intercept traffic, and 'enhance' the packets. >=20 > The LISP device near the source looks up additional information = about > the destination, and then wraps the packet in an outer header, one > which contains some of that additional information. The LISP device > near the destination removes that header, leaving the original, > unmodified, packet to be processed by the destination node. >=20 > The LISP device near the source (the Ingress Tunnel Router, or = 'ITR') > uses the information originally in the packet about the identity of > its ultimate destination, i.e. the destination address, which one = can > view as the EID of the ultimate destination. It uses the destination > EID to look up the current location (the RLOC) of that EID. >=20 > The lookup is performed through a 'mapping system', which is the > heart of LISP: it is a distributed directory of bindings from EIDs = to > RLOCS. The destination RLOC will be (initially at least) the address > of the LISP device near the destination (the Egress Tunnel Router, = or > 'ETR'). >=20 > The ITR then generates a new outer header for the original packet, > with that header containing the destination's RLOC as the wrapped > packet's destination, and the ITR's own address (i.e. the RLOC of = the > original source) as the wrapped packet's source, and sends it off. >=20 > When the packet gets to the ETR, that outer header is stripped off, > and the original packet is forwarded to the original ultimate > destination for normal processing. >=20 > Return traffic is handled similarly, often (depending on the > network's configuration) with the original ITR and ETR switching > roles. The ETR and ITR functionality is usually co-located in a > single device; these are normally denominated as 'xTRs'. >=20 > 3.3. Mapping from EIDs to RLOCs >=20 > The mappings from EIDs to RLOCs are provided by a distributed (and > potentially replicated) database, the mapping database, which is the > heart of LISP. >=20 > Mappings are requested on need, not (generally) pre-loaded; in other > words, mapping are distributed via a 'pull' mechanism. Once obtained > by an ITR, they are cached, to limit the amount of control traffic = to > a practicable level. (The mapping system will be discussed in more > detail below, in Section 5.2 and Section 9) >=20 > Extensive studies, including large-scale simulations driven by > lengthy recordings of actual traffic at several major sites, have > been performed to verify that this 'pull and cache' approach is > viable, in practical engineering terms. [Iannone] (This subject will > be discussed in more detail in Section 9.5, below.) >=20 > 3.4. Interworking With Non-LISP-Capable Endpoints >=20 > The capability for 'easy' interoperation between nodes using LISP, > and existing non-LISP-using hosts or sites (often called 'legacy' > hosts), is clearly crucial. >=20 > To allow such interoperation, a number of mechanisms have been > designed. This multiplicity is in part because different mechanisms > have different advantages and disadvantages (so that no single > mechanism is optimal for all cases), but also because with limited > field experience, it is not clear which (if any) approach will be > preferable. >=20 > One approach uses proxy LISP devices, called PITRs (proxy ITRs) and > PETRs (proxy ETRs), to provide LISP functionality during interaction > with legacy sites. Another approach uses a device with combined LISP > and NAT ([RFC1631]) functionality, named a LISP-NAT. >=20 > 4. Initial Applications >=20 > As previously mentioned, it is felt that LISP will provide even the > earliest adopters with some useful capabilities, and that these > capabilities will drive early LISP deployment. >=20 > It is very imporant to note that even when used only for > interoperation with existing unmodified hosts, use of LISP can still > provide benefits for communications with the site which has deployed > it - and, perhaps even more importantly, can do so _to both sides_. > This characteristic acts to further enhance the utility for early > adopters of deploying LISP, thereby increasing the cost/benefit = ratio > needed to drive deployment, and increasing the 'self-deployment' > aspect of LISP. >=20 > Note also that this section only lists likely _early_ applications > and benefits - if and once deployment becomes more widespread, other > aspects will come into play (as described in [Architecture], in the > "Goals of LISP" section). >=20 > 4.1. Provider Independence >=20 > Provider independence (i.e. the ability to easily change one's > Internet Service Provider) was probably the first place where the > Internet engineering community finally really felt the utility of > separating location and identity. >=20 > The problem is simple: for the global routing to scale, addresses > need to be aggregated (i.e. things which are close in the overall > network's connectivity need to have closely related addresses), the > so-called "provider aggregated" addresses. [RFC4116] However, if > this principle is followed, it means that when an entity switches > providers (i.e. it moves to a different 'place' in the network), it > has to renumber, a painful undertaking. [RFC5887] >=20 > In theory, it ought to be possible to update the DNS entries, and > have everyone switch to the new addresses, but in practise, = addresses > are embedded in many places, such as firewall configurations at = other > sites. >=20 > Having separate namespaces for location and identity greatly reduces > the problems involved with renumbering; an organization which moves > retains its EIDs (which are how most other parties refer to its > nodes), but is allocated new RLOCs, and the mapping system can > quickly provide the updated binding from the EIDs to the new RLOCs. >=20 > 4.2. Multi-Homing >=20 > Multi-homing is another place where the value of separation of > location and identity became apparent. There are several different > sub-flavours of the multi-homing problem - e.g. depending on whether > one wants open connections to keep working, etc - and other axes as > well (e.g. site multi-homing versus host multi-homing). >=20 > In particular, for the 'keep open connections up' case, without > separation of location and identity, the only currently feasible > approach is to use provider-independent addressses - which moves the > problem into the global routing system, with attendant costs. This > approach is also not really feasible for host multi-homing. >=20 > Multi-homing was once somewhat esoteric, but a number of trends are > driving an increased desirability, e.g. the wish to have multiple = ISP > links to a site for robustness; the desire to have mobile handsets > connect up to multiple wireless systems; etc. >=20 > Again, separation of location and identity, and the existince of a > binding layer which can be updated fairly quickly, as provided by > LISP, is a very useful tool for all variants of this issue. >=20 > 4.3. Traffic Engineering >=20 > Traffic engineering (TE) [RFC3272], desirable though this capability > is in a global network, is currently somewhat problematic to provide > in the Internet. The problem, fundamentally, is that this capability > was not visualized when the Internet was designed, so support for it > is somewhat in the 'when the only tool you have is a hammer, > everything looks like nail' category. >=20 > TE is, fundamentally, a routing issue. However, the current Internet > routing architecture, which is basically the Baran design of fifty > years ago [Baran] (a single large, distributed computationa), is = ill- > suited to provide TE. The Internet seems a long way from adopting a > more-advanced routing architecture, although the basic concepts for > such have been known for some time. [RFC1992] >=20 > Although the identity-location binding layer is thus a poor place, > architecturally, to provide TE capabilities, it is still an > improvement over the current routing tools available for this = purpose > (e.g. injection of more-specific routes into the global routing > table). In addition, instead of the entire network incurring the > costs (through the routing system overhead), when using a binding > layer to provide TE, the overhead is limited to those who are > actually communicating with that particular destination. >=20 > LISP includes a number of features in the mapping system to support > TE. (Described in Section 5.2 below.) >=20 > 4.4. Mobility >=20 > Mobility is yet another place where separation of location and > identity is obviously a key part of a clean, efficient and high- > functionality solution. Considerable experimentation has been > completed on doing mobility with LISP. >=20 > 4.5. IP Version Reciprocal Traversal >=20 > Note that LISP 'automagically' allows intermixing of various IP > versions for packet carriage; IPv4 packets might well be carried in > IPv6, or vice versa, depending on the network's configuration. This > would allow an 'island' of operation of one type to be > 'automatically' tunneled over a stretch of infrastucture which only > supports the other type. >=20 > While the machinery of LISP may seem too heavyweight to be good for > such a mundane use, this is not intended as a 'sole use' case for > deployment of LISP. Rather, it is something which, if LISP is being > deployed anyway (for its other advantages), is an added benefit that > one gets 'for free'. >=20 > 4.6. Local Uses >=20 > LISP has a number of use cases which are within purely local > contexts, i.e. not in the larger Internet. These fall into two > categories: uses seen on the Internet (above), but here on a private > (and usually small scale) setting; and applications which do not = have > a direct analog in the larger Internet, and which apply only to = local > deployments. >=20 > Among the former are multi-homing, IP version traversal, and support > of VPN's for segmentation and multi-tenancy (i.e. a spatially > separated private VPN whose components are joined together using the > public Internet as a backbone). >=20 > Among the latter class, non-Internet applications which have no > analog on the Internet, are the following example applications: > virtual machine mobility in data centers; other non-IP EID types = such > as local network MAC addresses, or application specific data. >=20 > 5. Major Functional Subsystems >=20 > LISP has only two major functional subsystems - the collection of > LISP packet switches (the xTRs), and the mapping system, which > manages the mapping database. The purpose and operation of each is > described at a high level below, and then, later on, in a fair = amount > of detail, in separate sections on each (Sections Section 8 and > Section 9, respectively). >=20 > 5.1. xTRs >=20 > xTRs are fairly normal packet switches, enhanced with a little extra > functionality in both the data and control planes, to perform LISP > data and control functionality. >=20 > The data plane functions in ITRs include deciding which packets need > to be given LISP processing (since packets to non-LISP sites may be > sent 'vanilla'); looking up the mapping; encapsulating the packet; > and sending it to the ETR. This encapsulation is done using UDP > [RFC768] (for reasons to be explained below, in Section 8.2), along > with an additional IPvN header (to hold the asource and destination > RLOCs). To the extent that traffic engineering features are in use > for a particular EID, the ITRs implement them as well. >=20 > In the ETR, the data plane simply unwraps the packets, and forwards > the 'vanilla' packets to the ultimate destination. >=20 > Control plane functions in ITRs include: asking for {EID->RLOC} > mappings via Map-Request control messages; handling the returning > Map-Replies which contain the requested information; managing the > local cache of mappings; checking for the reachability and liveness > of their neighbour ETRs; and checking for outdated mappings and > requesting updates. >=20 > In the ETR, control plane functions include participating in the > neighbour reachability and liveness function (see Section 12.4); > interacting with the mapping indexing system (next section); and > answering requests for mappings (ditto). >=20 > 5.2. Mapping System >=20 > The mapping database is a distributed, and potentially replicated, > database which holds bindings between EIDs (identity) and RLOCs > (location). To be exact, it contains bindings between EID blocks and > RLOCs (the block size is given explicitly, as part of the syntax). >=20 > Support for blocks is both for minimizing the administrative > configuration overhead, as well as for operational efficiency; e.g. > when a group of EIDs are behind a single xTR. >=20 > However, the block may be (and often is) as small as a single EID. > Since mappings are only loaded upon demand, if smaller blocks become > predominant, then the increased size of the overall database is far > less problematic than if the routing table came to be dominated by > such small entries. >=20 > A particular node may have more than one RLOC, or may change its > RLOC(s), while keeping its singlar identity. >=20 > The binding contains not just the RLOC(s), but also (for each RLOC > for any given EID) priority and weight (to allow allocation of load > between several RLOCs at a given priority); this allows a certain > amount of traffic engineering to be accomplished with LISP. >=20 > 5.2.1. Mapping System Organization >=20 > The mapping system is actually split into two major functional sub- > systems. The actual bindings themselves are held by the ETRs, and an > ITR which needs a binding effectively gets it from the ETR. >=20 > This co-location of the authoritative version of the mappings, and > the forwarding functionality which it describes, is an instance of > fate-sharing. [Clark] >=20 > To find the appropriate ETR(s) to query for the mapping, the second > subsystem, an 'indexing system', itself also a distributed, > potentally replicated database, provides information on which ETR(s) > are authoritative sources of information about the bindings which = are > available. >=20 > 5.2.2. Interface to the Mapping System >=20 > The client interface to the mapping system from an ITR's point of > view is not with the indexing system directly; rather, it is through > devices called Map Resolvers (MRs). >=20 > ITRs send request control messages (Map-Request packets) to an MR. > (This interface is probably the most important standardized = interface > in LISP - it is the key to the entire system.) The MR uses the > indexing system to eventually forward the Map-Request to the > appropriate ETR. The ETR formulates reply control messages (Map- > Reply packets), which is conveyed to the ITR. The details of the > indexing system, etc, are thus hidden from the 'ordinary' ITRs. >=20 > Similarly, the client interface to the indexing system from an ETR's > point of view is through devices called Map Servers (MSs - = admittedly > a poorly chosen term, but it's too late to change it now). >=20 > ETRs send registration control messages (Map-Register packets) to an > MS, which makes the information about the mappings which the ETR > indicates it is authoritative for available to the indexing system. > The MS formulates a reply control message (the Map-Notify packet), > which confirms the registration, and is returned to the ETR. The > details of the indexing system are thus likewise hidden from the > 'ordinary' ETRs. >=20 > 5.2.3. Indexing Subsystem >=20 > The current indexing system is called the Delegated Database Tree > (DDT), which is very similar in operation to DNS. [DDT], [RFC1034] > However, unlike DNS, the actual mappings are not handled by DDT; DDT > merely identifies the ETRs which hold the mappings. >=20 > Again, extensive large-scale simulations driven by lengthy = recordings > of actual traffic at several major sites, have been performed to > verify the effectiveness of this particular indexing system. [Jakab] >=20 > 6. Examples of Operation >=20 > To aid in comprehension, a few examples are given of user packets > traversing the LISP system. The first shows the processing of a > typical user packet, i.e. what the vast majority of user packets = will > see. The second shows what happens when the first packet to a > previously-unseen destination (at a particular ITR) is to be > processed by LISP. >=20 > 6.1. An Ordinary Packet's Processing >=20 > This case follows the processing of a typical user packet (for > instance, a normal TCP data or acknowledgment packet associated with > an open HTTP connection) as it makes its way from the source host to > the destination. >=20 > {{Rest to be written.}} >=20 > 6.2. A Mapping Cache Miss >=20 > If a host sends a packet, and it gets to the ITR, and the ITR both = i) > determines that it needs to perform LISP processing on the user data > packet, but ii) does not yet have a mapping cache entry which covers > that destination EID, then more complex processing ensues. >=20 > {{Rest to be written.}} >=20 > 7. Design Approach >=20 > Before describing LISP's components in more detail below, it may be > worth saying a few words about the design philosophy used in = creating > them - this may make clearer the reasons for some engineering = choices > in the mechanisms given there. >=20 > 7.1. Quick Implement-Test Loop >=20 > LISP uses a philosophy similar to that used in the early days of the > Internet, which is to just build it, then try it and see what > happens, and move forward from there based on what actually happens. > The concept has been to get something up and running, and then = modify > it based on testing and experience. >=20 > 7.1.1. No Desk Fixes >=20 > Don't try and forsee all issues from desk analysis. (Which is not to > say that one should not spend _some_ time on trying to forsee > problems, but be aware that it is a 'diminishing returns' process.) > The performance of very large, complex, physically distributed > systems is hard to predict, so rather than try (which would > necessarily be an incomplete exercise anyway, testing would > inevitably be required eventually), at a certain point it's better > just to get on with it - and you will learn a host of other lessons > in the process, too. >=20 > 7.1.2. Code Before Documentation >=20 > This is often a corollary to the kind of style described above. > While it probably would not have been possible in a large, > inhomogenous group, the small, close nature of the LISP > implementation group did allow this approach. >=20 > 7.2. Only Fix Real Problems >=20 > Don't worry about anything unless experience show it's a real > problem. For instance, in the early stages, much was made out of the > problem of 'what does an ITR do if it gets a packet, but does not > (yet) have a mapping for the destination?' >=20 > In practise, simply dropping such packets has just not proved to be = a > problem; the higher level protocol will retransmit them after a > timeout, and the mapping is usually in place by then. So spending a > lot of time (and its companion, energy) and mechanism (and _its_ > extremely undesirable companion, complexity) on solving this > 'problem' would not have been the most efficient approach, overall. >=20 > 7.3. No Theoretical Perfection >=20 > Attack hard problems with a number of cheap and simple mechanisms > that co-operate and overlap. Trying to find a single mechanism that > is all of: >=20 > - Robust > - Efficient > - Fast >=20 > is often (usually?) a fool's errand. (The analogy to the aphorism > 'Fast, Cheap, Good - Pick Any Two' should be obvious.) However, a > collection of simple and cheap mechanisms may effectively be able to > meet all of these goals (see, for example, ETR = Liveness/Reachability, > Section 12.4). >=20 > Yes, this results in a system which is not provably correct in all > circumstances. The world, however, is full of such systems - and in > the real world, effective robustness is more likely to result from > having multiple, overlapping mechanisms than one single high-powered > (and inevitably complex) one. In the world of civil engineering, > redundancy is now accepted as a key design principle; the same = should > be true of information systems. [Salvadori] >=20 > 7.3.1. No Ocean Boiling >=20 > Don't boil the ocean to kill a single fish. This is a combination of > 7.2 (Only Fix Real Problems) and 7.3 (No Theoretical Perfection); it > just means that spending a lot of complexity and/or overhead to deal > with a problem that's not really a problem is not good engineering. >=20 > 7.4. Just Enough Security >=20 > How much security to have is a complex issue. It's relatively easy > for designers to add good security, but much harder to get the users > to jump over all the hoops necessary to use it. LISP has therefore > adopted a position where we add 'just enough' security. >=20 > The overall approach to security in LISP is fairly subtle, though, > and is covered in more detail elsewhere (in [Architecture], Section > "Security"). I don't agree with this approach. >=20 > 8. xTRs >=20 > As mentioned above (in Section 5.1), xTRs are the basic = data-handling > devices in LISP. This section explores some advanced topics related > to xTRs. >=20 > Careful rules have been specified for both TTL and ECN [RFC3168] to > ensure that passage through xTRs does not interfere with the > operation of these mechanisms. In addition, care has been taken to > ensure that 'traceroute' works when xTRs are involved. >=20 > 8.1. When to Encapsulate >=20 > An ITR knows that a destination is running LISP, and thus that it > should perform LISP processing on a packet (including potential > encapsulation) if it has an entry in its local mapping cache that > covers the destination EID. >=20 > Conversely, if the cache contains a 'negative' entry (indicating = that > the ITR has previously attempted to find a mapping that covers this > EID, and it has been informed by the mapping system that no such > mapping exists), it knows the destination is not running LISP, and > the packet can be forwarded normally. >=20 > (The ITR cannot simply depend on the appearance, or non-appearance, > of the destination in the DFZ routing tables, as a way to tell if a > destination is a LISP site or not, because mechanisms to allow > interoperation of LISP sites and 'legacy' sites necessarily involve > advertising LISP sites' EIDs into the DFZ.) >=20 > 8.2. UDP Encapsulation Details >=20 > The UDP encapsulation used by LISP for carrying traffic from ITR to > ETR, and many of the details of how the remove the > it works, were all chosen for > very practical reasons. >=20 > Use of UDP (instead of, say, a LISP-specific protocol number) was > driven by the fact that many devices filter out 'unknown' protocols, > so adopting a non-UDP encapsulation would have made the initial > deployment of LISP harder - and our goal (see Section 2.1) was to > make the deployment as easy as possible. >=20 > The UDP source port in the encapsulated packet is a hash of the > original source and destination; this is because many ISPs use > multiple parallel paths (so-called 'Equal Cost Multi-Path'), and > load-share across them. Using such a hash in the source-port in the > outer header both allows LISP traffic to be load-shared, and also > ensures that packets from individual connections are delivered in > order (since most ISPs try to ensure that packets for a particular > {source, source port, destination, destination port} tuple flow = along > a single path, and do not become disordered).. >=20 > The UDP checksum is zero because the inner packet usually already = has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > In most exising hardware, computing such a checksum (and checking it > at the other end) would also present an intolerable load, for no > benefit. >=20 > 8.3. Header Control Channel >=20 > LISP provides a multiplexed channel in the encapsulation header. It > is mostly (but not entirely) used for control purposes. (See > [Architecture], Section "Architecture-Piggyback" for a longer > discussion of the architectural implications of this.) >=20 > The general concept is that the header starts with an 8-bit 'flags' > field, and it also includes two data fields (one 24 bits, one 32), > the contents and meaning of which vary, depending on which flags are > set. This allows these fields to be 'multiplexed' among a number of > different low-duty-cycle functions, while minimizing the space > overhead of the LISP encapsulation header. >=20 > 8.3.1. Echo Nonces >=20 > One important use is for a mechanism known as the Nonce Echo, which > is used as an efficient method for ITRs to check the reachability of > correspondent ETRs. >=20 > Basically, an ITR which wishes to ensure that an ETR is up, and > reachable, sends a nonce to that ETR, carried in the encapsulation > header; when that ETR (acting as an ITR) sends some other user data > packet back to the ITR (acting in turn as an ETR), that nonce is > carried in the header of that packet, allowing the original ITR to > confirm that its packets are reaching that ETR. >=20 > Note that lack of a response is not necessarily _proof_ that > something has gone wrong - but it stronly suggests that something > has, so other actions (e.g. a switch to an alternative ETR, if one = is > listed; a direct probe; etc) are advised. >=20 > (See Section 12.5 for more about Echo Nonces.) >=20 > 8.3.2. Instances >=20 > Another use of these header fields is for 'Instances' - basically, > support for VPN's across backbones. [RFC4026] Since there is only > one destination UDP port used for carriage of user data packets, and > the source port is used for multiplexing (above), there is no other > way to differentiate among different destination address namespaces > (which are often overlapped in VPNs). >=20 > 8.4. Fragmentation >=20 > Several mechanisms have been proposed for dealing with packets which > are too large to transit the path from a particular ITR to a given > ETR. >=20 > One, called the 'stateful' approach, keeps a per-ETR record of the > maximum size allowed, and sends an ICMP Too Big message to the > original source host when a packet which is too large is seen. >=20 > In the other, referred to as the 'stateless' approach, for IPv4 > packets without the 'DF' bit set, too-large packets are fragmented, > and then the fragments are forwarded; all other packets are > discarded, and an ICMP Too Big message returned. >=20 > It is not clear at this point which approach is preferable. >=20 > 8.5. Mapping Gleaning in ETRs >=20 > As an optimization to the mapping acquisition process, ETRs are > allowed to 'glean' mappings from incoming user data packets, and = also > from incoming Map-Request control messages. This is not secure, and > so any such mapping must be 'verified' by sending a Map-Request to > get an authoritative mapping. (See further discussion of the > security implications of this in [Architecture], Section "Security- > xTRs".) >=20 > The value of gleaning is that most communications are two-way, and = so > if host A is sending packets to host B (therefore needing B's > EID->RLOC mapping), very likely B will soon be sending packets back > to A (and thus needing A's EID->RLOC mapping). Without gleaning, > this would sometimes result in a delay, and the dropping of the = first > return packet; this is felt to be very undesirable. >=20 > 9. The Mapping System >=20 > RFC 1034 ("DNS Concepts and Facilities") has this to say about the > DNS name to IP address mapping system: >=20 > "The sheer size of the database and frequency of updates suggest > that it must be maintained in a distributed manner, with local > caching to improve performance. Approaches that attempt to > collect a consistent copy of the entire database will become more > and more expensive and difficult, and hence should be avoided." >=20 > and this observation applies equally to the LISP mapping system. >=20 > As previously mentioned, the mapping system is split into an = indexing > subsystem, which keeps track of where all the mappings are kept, and > the mappings themsleves, the authoritative copies of which are = always > held by ETRs. >=20 > 9.1. The Indexing Subsystem >=20 > The indexing system in LISP is currently implemented by the DDT > system. LISP initially used (for ease of getting something > operational without having to write a lot of code) an indexing = system > called ALT, which used BGP running over virtual tunnels. [ALT] This > proved to have a number of issues, and has now been superseded by > DDT. >=20 > In DDT, the EID namespace(s) are instantiated as a tree of DDT = nodes. > Starting with the root node(s), which have 'reponsibility' for the > entire namespace, portions of the namespace are delegated to child > nodes, in a recursive process extending through as many levels as = are > needed. Eventually, leaf nodes in the DDT tree delegate namespace > blocks to ETRs. >=20 > MRs obtain information about delegations by interrogating DDT nodes, > and caching the results. a remove "a" > This allows them, when passed a request for > a mapping by an ITR, to forward the mapping request to the > appropriate ETR (perhaps after loading some missing delegation > entries into their delegation cache). >=20 > 9.2. The Mapping System Interface >=20 > As mentioned in Section 5.2.2, both of the inferfaces to the mapping > system (from ITRs, and ETRs) are standardized, so that the more > numerous xTRs do not have to be modified when the mapping indexing > system is changed. This precaution has already allowed the mapping > system to be upgraded during LISP's evolution, when ALT was replaced > by DDT. >=20 > This section describes the interfaces in a little more detail. >=20 > 9.2.1. Map-Request Messages >=20 > The Map-Request message contains a number of fields, the two most > important of which are the requested EID block identifier (remember > that individual mappings may cover a block of EIDs, not just a = single > EID), and the Address Family Identifier (AFI) for that EID block. > [AFI] The inclusion of the AFI allows the mapping system interface > (as embodied in these control packets) a great deal of flexibility. > (See [Architecture], Section "Namespaces" for more on this.) >=20 > Other important fields are the source EID (and its AFI), and one or > more RLOCs for the source EID, along with their AFIs. Multiple RLOCs > are included to ensure that at least one is in a form which will > allow the reply to be returned to the requesting ITR, and the source > EID is used for a variety of functions, including 'gleaning' (see > Section 8.5). >=20 > Finally, the message includes a long nonce, for simple, efficient > protection against offpath attackers (see [Architecture], Section > "Security-xTRs" for more), and a variety of other fields and control > flag bits. >=20 > 9.2.2. Map-Reply Maessages >=20 > The Map-Reply message looks similar, except it includes the mapping > entry for the requested EID(s), which contains one or more RLOCs and > their associated data. (Note that the reply may cover a larger block > of the EID namespace than the request; most requests will be for a > single EID, the one which prompted the query.) >=20 > For each RLOC in the entry, there is the RLOC, its AFI (of course), > priority and weight fields (see Section 5.2), and multicast priority > and weight fields. >=20 > 9.2.3. Map-Register and Map-Notify Messages >=20 > The Map-Register message contains authentication information, and a > number of mapping records, each with an individual Time-To-Live > (TTL). Each of the records contains an EID (potentially, a block of > EIDs) and its AFI, a version number for this mapping (see > Section 11.1), and a number of RLOCs and their AFIs. >=20 > Each RLOC entry also includes the same data as in the Map-Replies > (i.e. priority and weight); this is because in some circumstances it > is advantageous to allow the MS to proxy reply on the ETR's behalf = to > Map-Request messages. [Mobility] >=20 > Map-Notify messages have the exact same contents as Map-Register > messages; they are purely acknowledgements. >=20 > 9.2.4. Map-Referral Messages >=20 > Map-Referral messages look almost identical to Map-Reply messages > (which is felt to be an advantage by some people, although having a > more generic record-based format would probably be better in the = long > run, as ample experience with DNS has shown), except that the RLOCs > potentially name either i) other DDT nodes (children in the > delegation tree), or ii) terminal MSs. >=20 > There are also optional authentication fields; see [Architecture], > Section "Security-Mappings" for more. >=20 > 9.3. Reliability via Replication >=20 > Everywhere throughout the mapping system, robustness to operational > failures is obtained by replicating data in multiple instances of = any > particular node (of whatever type). Map-Resolvers, Map-Servers, DDT > nodes, ETRs - all of them can be replicated, and the protocol > supports this replication. >=20 > There are generally no mechanisms specified yet to ensure coherence > between multiple copies of any particular data item, etc - this is > currently a manual responsibility. If and when LISP protocol > adoption proceeds, an automated layer to perform this functionality > can 'easily' be layered on top of the existing mechanisms. >=20 > 9.4. Extended Tools >=20 > In addition to the priority and weight data items in mappings, LISP > offers other tools to enhance functionality, particularly in the > traffic engineering area. One are 'source-specific mappings', i.e. > the ETR may return different mappings to the enquiring ITR, = depending > on the identity of the ITR. This allows very fine-tuned traffic > engineering, far more powerful than routing-based TE. >=20 > 9.5. Expected Performance >=20 > {{To be written.}} >=20 > 10. Deployment Mechanisms >=20 > This section discusses several deployment issues in more detail. > With LISP's heavy emphasis on practicality, much work has gone into > making sure it works well in the real-world environments most people > have to deal with. >=20 > 10.1. Internetworking Mechanism >=20 interworking > One aspect which has received a lot of attention are the mechanisms > previously referred to (in Section 3.4) to allow interoperation of > LISP sites with so-called 'legacy' sites which are not running LISP > (yet). >=20 > To briefly refresh what was said there, there are two main = approaches > to such interworking: proxy nodes (PITRs and PETRs), and an > alternative mechanism using device with combined NAT and LISP > functionality; these are described in more detail here. >=20 > 10.2. Proxy Devices >=20 > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. PETRs (proxy ETRs) serve as ETRs for LISP traffic > _to_ legacy hosts (for cases where a LISP device cannot send packets > directly to such sites, without encapsulation). >=20 > Note that return traffic _to_ a legacy site from a LISP-using node > does not necessarily have to pass through an ITR/PETR pair - the > original packets can usually just be sent directly to the > destination. However, for some kinds of LISP operation (e.g. mobile > nodes), this is not possible; in these situations, the PETR is > needed. >=20 > 10.2.1. PITRs >=20 > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. To do that, they have to advertise into the > existing legacy backbone Internet routing the availability of > whatever ranges of EIDs (i.e. of nodes using LISP) they are proxying > for, so that legacy hosts will know where to send traffic to those > LISP nodes. >=20 > As mentioned previously (Section 8.1), an ITR at another LISP site > can avoid using a PITR (i.e. it can detect that a given destination > is not a legacy site, if a PITR is advertising it into the DFZ) by > checking to see if a LISP mapping exists for that destination. >=20 > This technique obviously has an impact on routing table in the DFZ, > but it is not clear yet exactly what that impact will be; it is very > dependent on the collected details of many individual deployment > decisions. >=20 > A PITR may cover a group of EID blocks with a single EID > advertisement, in order to reduce the number of routing table = entries > added. (In fact, at the moment, aggressive aggregation of EID > announcements is performed, precisely to to minimize the number of > new announced routes added by this technique.) >=20 > At the same time, it if > a site does traffic engineering with LISP > instead of fine-grained BGP announcement, that will help keep table > sizes down (and this is true even in the early stages of LISP > deployment). The same is true for multi-homing. >=20 > 10.2.2. PETRs >=20 > PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy hosts, > for cases where a LISP device cannot send packets to sites without > encapsulation. That typically happens for one of two reasons. >=20 > First, it will happen in places where some device is implementing > Unicast Reverse Path Forwarding (uRPF), to prevent a variety of > negative behaviour; originating packets with the source's EID in the > source address field will result in them being filtered out and > discarded. >=20 > Second, it will happen when a LISP site wishes to send packets to a > non-LISP site, and the path in between does not support the > particular IP protocol version used by the source along its entir entire > length. Use of a PETR on the other side of the 'gap' will allow the > LISP site's packet to 'hop over' the gap, by utilizing LISP's > built-in support for mixed protocol encapsulation. >=20 > PETRs are generally paired with specific ITRs, which have the > location of their PETRs configured into them. In other words, unlike > normal ETRS, PETRs do not have to register themselves in the mapping > database, on behalf of any legacy sites they serve. >=20 > Also, allowing an ITR to always send traffic leaving a site to a = PETR > does avoid having to chose whether or not to encapsulate packets; it > can just always encapsulate packets, sending them to the PETR if it > has no specific mapping for the destination. However, this is not > advised: as mentioned, it is easy to tell if something is a legacy > destination. >=20 > 10.3. LISP-NAT >=20 > A LISP-NAT device, as previously mentioned, combines LISP and NAT > functionality, in order to allow a LISP site which is internally > using addresses which cannot be globally routed to communicate with > non-LISP sites elsewhere in the Internet. (In other words, the > technique used by the PITR approach simply cannot be used in this > case.) >=20 > To do this, a LISP-NAT performs the usual NAT functionality, and > translates a host's source address(es) in packets passing through it > from an 'inner' value to an 'outer' value, and storing that > translation in a table, which it can use to similarly process > subsequent packets (both outgoing and incoming). [Interworking] >=20 > There are two main cases where this might apply: > - Sites using non-routable global addresses > - Sites using private addresses [RFC1918] >=20 > 10.4. LISP and DFZ Routing >=20 > {{To be written.}} >=20 > 10.5. Use Through NAT Devices >=20 > Like them or not (and NAT devices have many egregious issues - some > inherent in the nature of the process of mapping addresses; others, > such as the brittleness due to non-replicated critical state, caused > by the way NATs were introduced, as stand-alone 'invisible' boxes), > NATs are both ubiquitous, and here to stay for a long time to come. >=20 > Thus, in the actual Internet of today, having any new mechanisms > function well in the presence of NATs (i.e. with LISP xTRs behind a > NAT device) is absolutely necessary. LISP has produced a variety of > mechanisms to do this. >=20 > 10.5.1. First-Phase NAT Support >=20 > The first mechanism used by LISP to operate through a NAT device = only > worked with some NATs, those which were configurable to allow = inbound > packet traffic to reach a configured host. >=20 > A pair of new LISP control messages, LISP Echo-Request and Echo- > Reply, allowed the ETR to discover its temporary global address; the > Echo-Request was sent to the configured Map-Server, and it replied > with an Echo-Reply which included the source address from which the > Echo Request was received (i.e. the public global address assigned = to > the ETR by the NAT). The ETR could then insert that address in any > Map-Reply control messages which it sent to correspondent ITRs. >=20 > The fact that this mechanism did not support all NATs, and also > required manual configuration of the NAT, meant that this was not a > good solution; in addition, since LISP expects all incoming data > traffic to be on a specific port, it was not possible to have > multiple ETRs behind a single NAT (which normally would have only = one > global address to share, meaning port mapping would have to be used, > except that... ) >=20 > 10.5.2. Second-Phase NAT Support >=20 > For a more comprehensive approach to support of LISP xTR deployment > behind NAT devices, a fairly extensive supplement to LISP, LISP NAT > Traversal, has been designed. [NAT] >=20 > A new class of LISP device, the LISP Re-encapsulating Tunnel Router > (RTR), passes traffic through the NAT, both to and from the xTR. > (Inbound traffic has to go through the RTR as well, since otherwise > multiple xTRs could not operate behind a single NAT, for the > 'specified port' reason in the section above.) >=20 > (Had the Map-Reply included a port number, this could have been > avoided - although of course it would be possible to define a new > RLOC type which included protocol and port, to allow other > encapsulation techniques.) >=20 > Two new LISP control messages (Info-Request and Info-Reply) allow an > xTR to detect if it is behind a NAT device, and also discover the > global IP address and UDP port assigned by the NAT to the xTR. A > modification to LISP Map-Register control messages allows the xTR to > initialize mapping state in the NAT, in order to use the RTR. >=20 > This mechanism addresses cases where the xTR is behind a NAT, but = the > xTR's associated MS is on the public side of the NAT; this > limitation, that MS's must be in the 'public' part of the Internet, > seems reasonable. >=20 > 11. Current Improvements >=20 > In line with the philosophies laid out in Section 7, LISP is > something of a moving target. This section discusses some of the > contemporaneous improvements being made to LISP. >=20 > 11.1. Mapping Versioning >=20 > As mentioned, LISP has been under development for a considerable > time. One early addition to LISP (it is already part of the base > specification) is mapping versioning; i.e. the application of > identifying sequence numbers to different versions of a mappping. > [Versioning] This allows an ITR to easily discover when a cached > mapping has been updated by a more recent variant. >=20 > Version numbers are available in control messages (Map-Replies), but > the initial concept is that to limit control message overhead, the > versioning mechanism should primarily use the multiplex user data > header control channel (see Section 8.3). >=20 > Versioning can operate in both directions: an ITR can advise an ETR > what version of a mapping it is currently using (so the ETR can > notify it if there is a more recent version), and ETRs can let ITRs > know what the current mapping version is (so the ITRs can request an > update, if their copy is outdated). >=20 > At the moment version numbers are manually assigned, and ordered. > Some felt that this was non-optimal, and that a better approach = would > have been to have 'fingerprints' which were computed from the = current > mapping data (i.e. a hash). It is not clear that the ordering buys > much (if anything), and the potential for mishaps with manually > configured version numbers is self-evident. >=20 > 11.2. Replacement of ALT with DDT >=20 > As mentioned in Section 9.2, an interface is provided to allow > replacement of the indexing subsystem. LISP initially used an > indexing system called ALT. [ALT] ALT was relatively easy to > construct from existing tools (GRE, BGP, etc), but it had a number = of > issues that made it unsuitable for large-scale use. ALT is now being > superseded by DDT. >=20 > As indicated previously (Section 9.5), the basic structure and > operation of DDT is identical to that of TREE, so the extensive > simulation work done for TREE applies equally to DDT, as do the > conclusions drawn about TREE's superiority to ALT. [Jakab] >=20 > {{Briefly synopsize results}} DDT builds a hierarchy of nodes and, by default, every request has to traverse the entire hierarchy from the root to a leaf (i.e., a MS). = This is somehow similar to LISP+ALT where requests have to traverse the ALT topology to reach a MS and finally the ETR. However, an important distinction has to be made. Indeed, with ALT, the mapping does not follow the same logical path than the request. As a result, the MR has no way to discover the topology and is not able to cache mapping for subsequent ITR requests. On the contrary,=20 MR in DDT works in a recursive way: the MR first queries the root that gives a referral to one of its child and so on until the address of a MS is known. At this stage, the MR can cache the referral such that subsequent request do not have to traverse the full hierarchy. [Jackab] shows by the mean of simulations with real packet trace, that it is possible to construct the hierarchy such that most of the requests are sent close to the leaves in the hierarchy, significantly reducing the=20 mapping resolution time. >=20 > 11.2.1. Why Not Use DNS >=20 > One obvious question is 'Since DDT is so similar to DNS, why not > simply use DNS?' In particular, people are familiar with the DNS, > how to configure it, etc - would it not thus be preferable to use = it? > To completely answer this would take more space that available here, > but, briefly, there were two main reasons, and one lesser one. >=20 > First, the syntax of DNS names did not lend itself to looking up > names in other syntaxes (e.g. bit fields). This is a problem which > has been previously encountered, e.g. in reverse address lookups. > [RFC5855] >=20 > Second, as an existing system, the interfaces between DNS (should it > have been used as an indexing subsystem for LISP) would not be > 'tuneable' to be optimal for LISP. For instance, if it were desired > to have the leaf node in an indexing lookup directly contact the ETR > on behalf of the node doing the lookup (thereby avoiding a = round-trip > delay), that would not be easy without modifications to the DNS = code. > Obviously, with a 'custom' system, this issue does not arise. >=20 > Finally, DNS security, while robust, is fairly complex. Doing DDT > offered an opportunity to provide a more nuanced security model. > (See [Architecture], Section "Security" for more about this.) will see with time, but I am not sure that security will really be = easier with DDT. >=20 > 11.3. Mobile Device Support >=20 > Mobility is an obvious capability to provide with LISP. Doing so is > relatively simple, if the mobile host is prepared to act as its own > ETR. It obtains a local 'temporary use' address, and registers that > address as its RLOC. Packets to the mobile host are sent to its > temporary address, whereever wherever > that may be, and the mobile host first > unwraps them (acting as an ETR), and the processes them normally > (acting as a host). >=20 > (Doing mobility without having the mobile host act as its ETR is > difficult, even if ETRs are quite common. The reason is that if the > ETR and mobile host are not integrated, during the step from the ETR > to the mobile host, the packets must contain the mobile host's EID, > and this may not be workable. If there is a local router between the > ETR and mobile host, for instance, it is unlikely to know how to get > the packets to the mobile host.) >=20 > If the mobile host migrates to a site which is itself a LISP site, > things get a little more complicated. The 'temporary address' it > gets is itself an EID, requiring mapping, and wrapping for transit > across the rest of the Internet. A 'double encapsulation' is thus > required at the other end; the packets are first encapsulated with > the mobile node's temporary address as their RLOC, and then this has > to be looked up in a second lookup cycle (see Section 8.1), and then > wrapped again, with the site's RLOC as their destination. >=20 > This results in slight loss in maximum packet size, due to the > duplicated headers, but on the whole it is considerably simpler than > the alternative, which would be to re-wrap the packet at the site's > ETR, when it is discovered that the destination's EID was not > 'native' to the site. This would require that the mobile node's EID > effectively have two different mappings, depending on whether the > lookup was being performed outside the LISP site, or inside. >=20 > {{Also probably need to mention briefly how the other end is = notified > when mappings are updated, and about proxy-Map-Replies.}} [Mobility] >=20 > 11.4. Multicast Support >=20 > Multicast may seem an odd thing to support with LISP, since LISP is > all about separating identity from location, but although a = multicast > group in some sense has an identity, it certainly does not have _a_ > location. >=20 > However, multicast is important to some users of the network, for a > number of reasons: doing multiple unicast streams is inefficient; it > is easy to use up all the upstream bandwidth, and without multicast = a > server can also be saturated fairly easily in doing the unicast > replication. So it is important for LISP to 'play nicely' with > multicast; work on multicast support in LISP is fairly advanced, > although not far-ranging. >=20 > Briefly, destination group addresses are not mapped; only the source > address (when the source is inside a LISP site) needs to be mapped, > both during distribution tree setup, as well as actual traffic > delivery. In other words, LISP's mapping capability isa used: it is > just applied to the source, not the destination (as with most LISP > activity); the inner source is the EID, and the outer source is the > EID's RLOC. >=20 > Note that this does mean that if the group is using separate source- > specific trees for distribution, there isn't a separate distribution > tree outside the LISP site for each different source of traffic to > the group from inside the LISP site; they are all lumped together > under a single source, the RLOC. >=20 > The approach currently used by LISP requires no packet format = changes > to existing multicast protocols. See [Multicast] for more; > additional LISP multicast issues are discussed in [LISP], Section = 12. >=20 > 11.5. {{Any others?}} >=20 > 12. Fault Discovery/Handling >=20 > LISP is, in terms of its functionality, a fairly simple system: the > list of failure modes is thus not extensive. >=20 > 12.1. Handling Missing Mapp > ings >=20 > Handling of missing mappings is fairly simple: the ITR calls for the > mapping, and in the meantime can either discard traffic to the > destination (as many ARP implementations do) [RFC826], or, if > dropping the traffic is deemed undesirable, it can forward them via = a > 'default PITR'. >=20 > A number of PITRs advertise all EID blocks into the backbone = routing, > so that any ITRs which are temporarily missing a mapping can forward > the traffic to these default PITRs via normal transmission methods, > where they are encapsulated and passed on. >=20 > 12.2. Outdated Mappings >=20 > If a mapping changes once an ITR has retrieved it, that may result = in > traffic to the EIDs covered by that mapping failing. There are three > cases to consider: >=20 > - When the ETR traffic is being sent to is still a valid ETR for > that EID, but the mapping has been updated (e.g. to change the > priority of various ETRs) > - When the ETR traffic is being sent to is still an ETR, but no > longer a valid ETR for that EID > - When the ETR traffic is being sent to is no longer an ETR >=20 > 12.2.1. Outdated Mappings - Updated Mapping >=20 > A 'mapping versioning' system, whereby mappings have version = numbers, > and ITRs are notified when their mapping is out of date, has been > added to detect this, and the ITR responds by refreshing the = mapping. > [Versioning] >=20 > 12.2.2. Outdated Mappings - Wrong ETR >=20 > {{To be written.}} >=20 > 12.2.3. Outdated Mappings - No Longer an ETR >=20 > If the destination of traffic from an ITR is no longer an ETR, one > might get an ICMP Destination Unreachable error message. However, > one cannot depend on that. The following mechanism will work, > though. >=20 > Since the destination is not an ETR, the echoing reachability > detection mechanism (see Section 8.3.1) will detect a problem. At > that point, the backstop mechanism, Probing, will kick in. Since the > destination is still not an ETR, that will fail, too. >=20 > At that point, traffic will be switched to a different ETR, or, if > none are available, a re-map may be requested. >=20 > 12.3. Erroneous mappings >=20 > {{To be written.}} >=20 > 12.4. Neighbour Liveness >=20 > The ITR, like all packet switches, needs to detect, and react, when > its next-hop neighbour ceases operation. As LISP traffic is > effectively always unidirectional (from ITR to ETR), this could be > somewhat problematic. >=20 > Solving a related problem, neighbour reachability (below) subsumes > handling this fault mode, however. >=20 > Note that the two terms (liveness and reachability) are _not_ > synonmous (although a lot of LISP documentation confuses them). -> then change specs > Liveness is a property of a node - it is either up and functioning, > or it is not. Reachability is only a property of a particular _pair_ > of nodes. >=20 [snip]= From vaf@cisco.com Tue Oct 23 12:34:31 2012 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 AB0791F0C93 for ; Tue, 23 Oct 2012 12:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjW7hb3rZrFi for ; Tue, 23 Oct 2012 12:34:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8FF1F0C94 for ; Tue, 23 Oct 2012 12:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5678; q=dns/txt; s=iport; t=1351020869; x=1352230469; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=mSBH16gzjh/CglohFO0SL3ZK9z+CyoLIPyBlb2lrxt8=; b=FFaUAsNPphCwZQV8ojND7JM+WU8U2lOSa4/egq5M2dfU58NWA6uWmKIx bvhGUVDAZRndnBSIqdcfNv10hTLZpMLkKs3xy5SWqngdIilnysQoTJJxg 14TIV+WFmz950L2mB/EQV7L2DrM83pM3JAc09DV6Yh9DYGZgiaOpI4ypX o=; X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="58992827" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 23 Oct 2012 19:34:29 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9NJYTc5022267; Tue, 23 Oct 2012 19:34:29 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id E50102A90ABD; Tue, 23 Oct 2012 12:34:27 -0700 (PDT) Date: Tue, 23 Oct 2012 12:34:27 -0700 From: Vince Fuller To: Damien Saucez Message-ID: <20121023193427.GA33763@vaf-mac1.cisco.com> References: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: LISP mailing list list , Noel Chiappa Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 19:34:31 -0000 Hi Damien- Thanks for catching the typos. I few comments on your comments: > > 7.4. Just Enough Security > > > > How much security to have is a complex issue. It's relatively easy > > for designers to add good security, but much harder to get the users > > to jump over all the hoops necessary to use it. LISP has therefore > > adopted a position where we add 'just enough' security. > > > > The overall approach to security in LISP is fairly subtle, though, > > and is covered in more detail elsewhere (in [Architecture], Section > > "Security"). > > I don't agree with this approach. Can you be more specific about what you don't like and suggest an alternative? > > 10.1. Internetworking Mechanism > > > > interworking I might re-title this section "Interworking with non-LISP systems" > > 11.2. Replacement of ALT with DDT > > > > As mentioned in Section 9.2, an interface is provided to allow > > replacement of the indexing subsystem. LISP initially used an > > indexing system called ALT. [ALT] ALT was relatively easy to > > construct from existing tools (GRE, BGP, etc), but it had a number of > > issues that made it unsuitable for large-scale use. ALT is now being > > superseded by DDT. > > > > As indicated previously (Section 9.5), the basic structure and > > operation of DDT is identical to that of TREE, so the extensive > > simulation work done for TREE applies equally to DDT, as do the > > conclusions drawn about TREE's superiority to ALT. [Jakab] > > > > {{Briefly synopsize results}} > > DDT builds a hierarchy of nodes and, by default, every request has > to traverse the entire hierarchy from the root to a leaf (i.e., a MS). This is not entirely correct. Once a DDT Map Resolver's (MR's) referral cache has been populated, it does not need to send all requests to the root; any request for a sub-tree of the EID space which is known in the referral cache is sent directly to the MS's for that sub-tree. > This is somehow similar to LISP+ALT where requests have to traverse the > ALT topology to reach a MS and finally the ETR. However, an > important distinction has to be made. Indeed, with ALT, the mapping > does not follow the same logical path than the request. I don't understand these sentences. > As a result, the MR has no way to discover the topology and is not able > to cache mapping for subsequent ITR requests. This is not entirely correct. An MR does not cache EID-to-RLOC mappings themselves but it does cache referrals that list the DDT Map Servers for every part of the EID space that it queries. The MR thus discovers the EID space topology and stores that information in its referral cache. > On the contrary, MR in DDT works in a recursive way: the MR first queries > the root that gives a referral to one of its child and so on until the > address of a MS is known. At this stage, the MR can cache the referral > such that subsequent request do not have to traverse the full hierarchy. > [Jackab] shows by the mean of simulations with real packet trace, that it > is possible to construct the hierarchy such that most of the requests are > sent close to the leaves in the hierarchy, significantly reducing the > mapping resolution time. This is mostly correct but confusing, your use of the term "recursive" particularly so; a DDT MR explores the EID topology (DDT) using an interactive process. From the perspective of an ITR that sends a request to a a DDT MR, the process appears to be recursive (just as the iterative DNS resolution process appears recursive to a host that sends a DNS request to a caching resolver); that does not mean that the process is recursive. Your mentioning of DDT MR caching in this paragraph contracts the statements you made earlier about having to start at the root; again, quite confusing. > > 11.2.1. Why Not Use DNS > > > > One obvious question is 'Since DDT is so similar to DNS, why not > > simply use DNS?' In particular, people are familiar with the DNS, > > how to configure it, etc - would it not thus be preferable to use it? > > To completely answer this would take more space that available here, > > but, briefly, there were two main reasons, and one lesser one. > > > > First, the syntax of DNS names did not lend itself to looking up > > names in other syntaxes (e.g. bit fields). This is a problem which > > has been previously encountered, e.g. in reverse address lookups. > > [RFC5855] > > > > Second, as an existing system, the interfaces between DNS (should it > > have been used as an indexing subsystem for LISP) would not be > > 'tuneable' to be optimal for LISP. For instance, if it were desired > > to have the leaf node in an indexing lookup directly contact the ETR > > on behalf of the node doing the lookup (thereby avoiding a round-trip > > delay), that would not be easy without modifications to the DNS code. > > Obviously, with a 'custom' system, this issue does not arise. > > > > Finally, DNS security, while robust, is fairly complex. Doing DDT > > offered an opportunity to provide a more nuanced security model. > > (See [Architecture], Section "Security" for more about this.) > > will see with time, but I am not sure that security will really be > easier with DDT. Maybe "easier" is the wrong word, but given that ALT does not define any security mechanism (it simply assumes the use of whatever is available with BGP), the explicit description of how security works with DDT would seem to be "easier"/"better" to me. --Vince From damien.saucez@gmail.com Tue Oct 23 13:32:40 2012 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 AB95E1F0CA6 for ; Tue, 23 Oct 2012 13:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQWHBrKhqrCj for ; Tue, 23 Oct 2012 13:32:39 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 68A321F0C9B for ; Tue, 23 Oct 2012 13:32:32 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so3639705wib.1 for ; Tue, 23 Oct 2012 13:32:31 -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=GUN+I/hIICoEMuX/MKd8ySS2ougwVJKCcd/pEADhu8Q=; b=yz56ScNTTGJFCo+wMWZVBRzPy8OHwe4TBE1WKDy47XMU3usCN1BwmozaZr8dy0Mzyx +FUaW7YNjmkPIDXr6+YaEcahnGtEAWCESFKVem01QYnU7gdFHjp1mhKgXFIw85jfdhnC DbXJLFqbOA+QwnTp260nUP43VbyxMPJbic5FQimySSI2T34017YkDEcShBtPNEUaV6uH ac548klsxjnrkYwzymfE4oLWWiPjlNH8wJI5ZbCI4aaH0HWdrzc9aq3EBKbB/f7Ilj+S SC6mUHqRpNgZduM66MNvJWHWIXWZvA0x+WuEPvXL87y1F5/JpdvCpDE4gH5k8pFrGMaN AM2A== Received: by 10.216.217.195 with SMTP id i45mr8235082wep.14.1351024351423; Tue, 23 Oct 2012 13:32:31 -0700 (PDT) Received: from [172.16.139.253] (17.82.69.86.rev.sfr.net. [86.69.82.17]) by mx.google.com with ESMTPS id fp6sm571725wib.0.2012.10.23.13.32.28 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 13:32:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <20121023193427.GA33763@vaf-mac1.cisco.com> Date: Tue, 23 Oct 2012 22:32:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48D404AD-4680-4173-A91B-8AA03EDB4327@gmail.com> References: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> <20121023193427.GA33763@vaf-mac1.cisco.com> To: Vince Fuller X-Mailer: Apple Mail (2.1499) Cc: LISP mailing list list , Noel Chiappa Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 20:32:40 -0000 On 23 Oct 2012, at 21:34, Vince Fuller wrote: > Hi Damien- >=20 > Thanks for catching the typos. I few comments on your comments: >=20 >>> 7.4. Just Enough Security >>>=20 >>> How much security to have is a complex issue. It's relatively easy >>> for designers to add good security, but much harder to get the = users >>> to jump over all the hoops necessary to use it. LISP has therefore >>> adopted a position where we add 'just enough' security. >>>=20 >>> The overall approach to security in LISP is fairly subtle, though, >>> and is covered in more detail elsewhere (in [Architecture], Section >>> "Security"). >>=20 >> I don't agree with this approach. >=20 > Can you be more specific about what you don't like and suggest an = alternative? true, it was a bit short. Well, LISP is really design to be as operational as possible for today, in our world where infrastructure security is still not very critical = (see how weak is BGP but there is no major issue). I think however that bad people will become more and more aware of what they can do by attacking directly the infrastructure and then we will have troubles. So LISP has been designed with zero security in mind and security is seen as a patch over the system and hence the sentence "just enough security". But how do we consider it is just enough? Actually it is just enough because there is no targeted attack yet. I understand that there is many LISP use cases where security is a detail but I think that the "just enough security" and I would say "just in time security" approach followed during LISP development makes securing LISP hard. >=20 >>> 10.1. Internetworking Mechanism >>>=20 >>=20 >> interworking >=20 > I might re-title this section "Interworking with non-LISP systems" >=20 >>> 11.2. Replacement of ALT with DDT >>>=20 >>> As mentioned in Section 9.2, an interface is provided to allow >>> replacement of the indexing subsystem. LISP initially used an >>> indexing system called ALT. [ALT] ALT was relatively easy to >>> construct from existing tools (GRE, BGP, etc), but it had a number = of >>> issues that made it unsuitable for large-scale use. ALT is now = being >>> superseded by DDT. >>>=20 >>> As indicated previously (Section 9.5), the basic structure and >>> operation of DDT is identical to that of TREE, so the extensive >>> simulation work done for TREE applies equally to DDT, as do the >>> conclusions drawn about TREE's superiority to ALT. [Jakab] >>>=20 >>> {{Briefly synopsize results}} >>=20 >> DDT builds a hierarchy of nodes and, by default, every request has >> to traverse the entire hierarchy from the root to a leaf (i.e., a = MS). >=20 > This is not entirely correct. Once a DDT Map Resolver's (MR's) = referral > cache has been populated, it does not need to send all requests to the > root; any request for a sub-tree of the EID space which is known in = the > referral cache is sent directly to the MS's for that sub-tree. >> This is somehow similar to LISP+ALT where requests have to traverse = the >> ALT topology to reach a MS and finally the ETR. However, an >> important distinction has to be made. Indeed, with ALT, the mapping >> does not follow the same logical path than the request. >=20 > I don't understand these sentences. map-replies are seen by nobody but the ITR, so no caching. >=20 >> As a result, the MR has no way to discover the topology and is not = able >> to cache mapping for subsequent ITR requests. >=20 > This is not entirely correct. An MR does not cache EID-to-RLOC = mappings > themselves but it does cache referrals that list the DDT Map Servers = for > every part of the EID space that it queries. The MR thus discovers the > EID space topology and stores that information in its referral cache. >=20 >> On the contrary, MR in DDT works in a recursive way: the MR first = queries >> the root that gives a referral to one of its child and so on until = the >> address of a MS is known. At this stage, the MR can cache the = referral >> such that subsequent request do not have to traverse the full = hierarchy. >> [Jackab] shows by the mean of simulations with real packet trace, = that it >> is possible to construct the hierarchy such that most of the requests = are >> sent close to the leaves in the hierarchy, significantly reducing the=20= >> mapping resolution time. >=20 > This is mostly correct but confusing, your use of the term "recursive" > particularly so; a DDT MR explores the EID topology (DDT) using an > interactive process. =46rom the perspective of an ITR that sends a = request > to a a DDT MR, the process appears to be recursive (just as the = iterative > DNS resolution process appears recursive to a host that sends a DNS = request > to a caching resolver); that does not mean that the process is = recursive. >=20 > Your mentioning of DDT MR caching in this paragraph contracts the > statements you made earlier about having to start at the root; again, > quite confusing. another try for the full paragraph then: In LISP-DDT, the hierarchical nature of EID prefixes is leveraged to construct a hierarchical mapping resolution infrastructure. When an ITR has to obtain a mapping, it sends a Map-Request for that mapping to one of its assigned Map Resolver (MR). The MR then iteratively resolves = the DDT hierarchy until a referral for Map Servers (MS) responsible for the requested EID is obtained, then the MR sends a Map-Request to a MS on behalf of the ITR such that the ITR eventually receives the mapping. As opposed to LISP+ALT, mapping resolution can significantly be speeded up thanks to caching. Indeed, the MR can cache the results of its iterative walk in the hierarchy such that for latter request, the = entire hierarchy does not need to be traversed. >=20 >>> 11.2.1. Why Not Use DNS >>>=20 >>> One obvious question is 'Since DDT is so similar to DNS, why not >>> simply use DNS?' In particular, people are familiar with the DNS, >>> how to configure it, etc - would it not thus be preferable to use = it? >>> To completely answer this would take more space that available = here, >>> but, briefly, there were two main reasons, and one lesser one. >>>=20 >>> First, the syntax of DNS names did not lend itself to looking up >>> names in other syntaxes (e.g. bit fields). This is a problem which >>> has been previously encountered, e.g. in reverse address lookups. >>> [RFC5855] >>>=20 >>> Second, as an existing system, the interfaces between DNS (should = it >>> have been used as an indexing subsystem for LISP) would not be >>> 'tuneable' to be optimal for LISP. For instance, if it were desired >>> to have the leaf node in an indexing lookup directly contact the = ETR >>> on behalf of the node doing the lookup (thereby avoiding a = round-trip >>> delay), that would not be easy without modifications to the DNS = code. >>> Obviously, with a 'custom' system, this issue does not arise. >>>=20 >>> Finally, DNS security, while robust, is fairly complex. Doing DDT >>> offered an opportunity to provide a more nuanced security model. >>> (See [Architecture], Section "Security" for more about this.) >>=20 >> will see with time, but I am not sure that security will really be >> easier with DDT. >=20 > Maybe "easier" is the wrong word, but given that ALT does not define = any > security mechanism (it simply assumes the use of whatever is available > with BGP), the explicit description of how security works with DDT = would > seem to be "easier"/"better" to me. >=20 ok Damien Saucez > --Vince From damien.saucez@gmail.com Tue Oct 23 14:09:40 2012 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 7E9D911E80BF for ; Tue, 23 Oct 2012 14:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPM9hld1nhZP for ; Tue, 23 Oct 2012 14:09:39 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8565C1F0424 for ; Tue, 23 Oct 2012 14:09:38 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2601678wey.31 for ; Tue, 23 Oct 2012 14:09:37 -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=HGYfoL5ICW8ghqMinemBW1viQZqSEga0Mg/doa/Q/dw=; b=OAbA8pAEapJLS3FYvtWGRNpcBNYXGfGq8l8pslAa0WfrP4fqWTAvvMHVm1t2t0wV6K gUg0PdRGLQAaV/U3fSNOhksNBcyyn/dJbbgITcKNSbIdtbQMDI71WwZdv8GAXWwbVsh4 cju0kQkW7CYpL0baqsx9F3LFoDf0xv0YvfAvqzmuIqgQpbB2JLvVeDILHbsrSIA9qwBb oz+4lx0EZtZ6B2TzsMqZJ7OjkVu2rlImkeHsHVeF01et4pnAVCF1TMIXDluG6rd62RAO 19hRtdigTC/EAkdqxxDbV1ckHzcDb+W9rFMPxg256D9bkluep56kE4bZvEmTAmVmPPf/ WE6g== Received: by 10.180.106.9 with SMTP id gq9mr742812wib.12.1351026576976; Tue, 23 Oct 2012 14:09:36 -0700 (PDT) Received: from [172.16.139.253] (17.82.69.86.rev.sfr.net. [86.69.82.17]) by mx.google.com with ESMTPS id cu1sm700421wib.6.2012.10.23.14.09.32 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 14:09:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <48D404AD-4680-4173-A91B-8AA03EDB4327@gmail.com> Date: Tue, 23 Oct 2012 23:09:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> <20121023193427.GA33763@vaf-mac1.cisco.com> <48D404AD-4680-4173-A91B-8AA03EDB4327@gmail.com> To: Vince Fuller X-Mailer: Apple Mail (2.1499) Cc: LISP mailing list list , Noel Chiappa Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 21:09:40 -0000 On 23 Oct 2012, at 22:32, Damien Saucez wrote: >=20 > On 23 Oct 2012, at 21:34, Vince Fuller wrote: >=20 >> Hi Damien- >>=20 >> Thanks for catching the typos. I few comments on your comments: >>=20 >>>> 7.4. Just Enough Security >>>>=20 >>>> How much security to have is a complex issue. It's relatively easy >>>> for designers to add good security, but much harder to get the = users >>>> to jump over all the hoops necessary to use it. LISP has therefore >>>> adopted a position where we add 'just enough' security. >>>>=20 >>>> The overall approach to security in LISP is fairly subtle, though, >>>> and is covered in more detail elsewhere (in [Architecture], Section >>>> "Security"). >>>=20 >>> I don't agree with this approach. >>=20 >> Can you be more specific about what you don't like and suggest an = alternative? >=20 > true, it was a bit short. >=20 > Well, LISP is really design to be as operational as possible for = today, > in our world where infrastructure security is still not very critical = (see > how weak is BGP but there is no major issue). I think however that > bad people will become more and more aware of what they can do > by attacking directly the infrastructure and then we will have = troubles. > So LISP has been designed with zero security in mind and security Oops, one very important word stayed in the keyboard. s/zero security in mind/zero security SCENARIO in mind/ Let me explain this as it seems it is not clear. The way security was thought with LISP is relatively traditional and the approach is then traditional using rate limiting and filtering, and until recently, we did not really specified attack scenarios. However, there is a nice example of the power of scenarios on the protocol: a fake ITR trying to register a mapping. This scenario has influenced a lot the registration process (hmac + notify). The same with LISP-Sec which has been used to design DDT in a way it avoid overclaiming attack. These two example to show that we have to go a little bit beyond the traditional "just enough security" because I think in the future, stupid attacker will be replaced by smart attackers. Hope it clarifies. Damien Saucez > is seen as a patch over the system and hence the sentence "just > enough security". But how do we consider it is just enough? Actually > it is just enough because there is no targeted attack yet. > I understand that there is many LISP use cases where security is a > detail but I think that the "just enough security" and I would say = "just > in time security" approach followed during LISP development makes > securing LISP hard. >=20 >>=20 >>>> 10.1. Internetworking Mechanism >>>>=20 >>>=20 >>> interworking >>=20 >> I might re-title this section "Interworking with non-LISP systems" >>=20 >>>> 11.2. Replacement of ALT with DDT >>>>=20 >>>> As mentioned in Section 9.2, an interface is provided to allow >>>> replacement of the indexing subsystem. LISP initially used an >>>> indexing system called ALT. [ALT] ALT was relatively easy to >>>> construct from existing tools (GRE, BGP, etc), but it had a number = of >>>> issues that made it unsuitable for large-scale use. ALT is now = being >>>> superseded by DDT. >>>>=20 >>>> As indicated previously (Section 9.5), the basic structure and >>>> operation of DDT is identical to that of TREE, so the extensive >>>> simulation work done for TREE applies equally to DDT, as do the >>>> conclusions drawn about TREE's superiority to ALT. [Jakab] >>>>=20 >>>> {{Briefly synopsize results}} >>>=20 >>> DDT builds a hierarchy of nodes and, by default, every request has >>> to traverse the entire hierarchy from the root to a leaf (i.e., a = MS). >>=20 >> This is not entirely correct. Once a DDT Map Resolver's (MR's) = referral >> cache has been populated, it does not need to send all requests to = the >> root; any request for a sub-tree of the EID space which is known in = the >> referral cache is sent directly to the MS's for that sub-tree. >>> This is somehow similar to LISP+ALT where requests have to traverse = the >>> ALT topology to reach a MS and finally the ETR. However, an >>> important distinction has to be made. Indeed, with ALT, the mapping >>> does not follow the same logical path than the request. >>=20 >> I don't understand these sentences. > map-replies are seen by nobody but the ITR, so no caching. >>=20 >>> As a result, the MR has no way to discover the topology and is not = able >>> to cache mapping for subsequent ITR requests. >>=20 >> This is not entirely correct. An MR does not cache EID-to-RLOC = mappings >> themselves but it does cache referrals that list the DDT Map Servers = for >> every part of the EID space that it queries. The MR thus discovers = the >> EID space topology and stores that information in its referral cache. >>=20 >>> On the contrary, MR in DDT works in a recursive way: the MR first = queries >>> the root that gives a referral to one of its child and so on until = the >>> address of a MS is known. At this stage, the MR can cache the = referral >>> such that subsequent request do not have to traverse the full = hierarchy. >>> [Jackab] shows by the mean of simulations with real packet trace, = that it >>> is possible to construct the hierarchy such that most of the = requests are >>> sent close to the leaves in the hierarchy, significantly reducing = the=20 >>> mapping resolution time. >>=20 >> This is mostly correct but confusing, your use of the term = "recursive" >> particularly so; a DDT MR explores the EID topology (DDT) using an >> interactive process. =46rom the perspective of an ITR that sends a = request >> to a a DDT MR, the process appears to be recursive (just as the = iterative >> DNS resolution process appears recursive to a host that sends a DNS = request >> to a caching resolver); that does not mean that the process is = recursive. >>=20 >> Your mentioning of DDT MR caching in this paragraph contracts the >> statements you made earlier about having to start at the root; again, >> quite confusing. >=20 > another try for the full paragraph then: >=20 > In LISP-DDT, the hierarchical nature of EID prefixes is leveraged to > construct a hierarchical mapping resolution infrastructure. When an = ITR > has to obtain a mapping, it sends a Map-Request for that mapping to = one > of its assigned Map Resolver (MR). The MR then iteratively resolves = the > DDT hierarchy until a referral for Map Servers (MS) responsible for = the > requested EID is obtained, then the MR sends a Map-Request to a MS > on behalf of the ITR such that the ITR eventually receives the = mapping. > As opposed to LISP+ALT, mapping resolution can significantly be > speeded up thanks to caching. Indeed, the MR can cache the results > of its iterative walk in the hierarchy such that for latter request, = the entire > hierarchy does not need to be traversed. >=20 >=20 >>=20 >>>> 11.2.1. Why Not Use DNS >>>>=20 >>>> One obvious question is 'Since DDT is so similar to DNS, why not >>>> simply use DNS?' In particular, people are familiar with the DNS, >>>> how to configure it, etc - would it not thus be preferable to use = it? >>>> To completely answer this would take more space that available = here, >>>> but, briefly, there were two main reasons, and one lesser one. >>>>=20 >>>> First, the syntax of DNS names did not lend itself to looking up >>>> names in other syntaxes (e.g. bit fields). This is a problem which >>>> has been previously encountered, e.g. in reverse address lookups. >>>> [RFC5855] >>>>=20 >>>> Second, as an existing system, the interfaces between DNS (should = it >>>> have been used as an indexing subsystem for LISP) would not be >>>> 'tuneable' to be optimal for LISP. For instance, if it were desired >>>> to have the leaf node in an indexing lookup directly contact the = ETR >>>> on behalf of the node doing the lookup (thereby avoiding a = round-trip >>>> delay), that would not be easy without modifications to the DNS = code. >>>> Obviously, with a 'custom' system, this issue does not arise. >>>>=20 >>>> Finally, DNS security, while robust, is fairly complex. Doing DDT >>>> offered an opportunity to provide a more nuanced security model. >>>> (See [Architecture], Section "Security" for more about this.) >>>=20 >>> will see with time, but I am not sure that security will really be >>> easier with DDT. >>=20 >> Maybe "easier" is the wrong word, but given that ALT does not define = any >> security mechanism (it simply assumes the use of whatever is = available >> with BGP), the explicit description of how security works with DDT = would >> seem to be "easier"/"better" to me. >>=20 >=20 > ok >=20 > Damien Saucez >=20 >> --Vince >=20 From jmh@joelhalpern.com Tue Oct 23 14:30:04 2012 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 012DA21F8669 for ; Tue, 23 Oct 2012 14:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70CnD4Lno9Zj for ; Tue, 23 Oct 2012 14:30:03 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8F321F8666 for ; Tue, 23 Oct 2012 14:30:03 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 49826A6CA5 for ; Tue, 23 Oct 2012 14:30:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 42E94C1723; Tue, 23 Oct 2012 14:30:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-221.clppva.btas.verizon.net [71.161.51.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9C6C6C1721; Tue, 23 Oct 2012 14:30:00 -0700 (PDT) Message-ID: <50870C53.1040602@joelhalpern.com> Date: Tue, 23 Oct 2012 17:29:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Damien Saucez References: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> In-Reply-To: <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list , Noel Chiappa Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 21:30:04 -0000 If I understood, you expressed disagreement with the general description of LISP security. Can you suggest what approach you would like to see taken? Thank you, Joel From damien.saucez@gmail.com Tue Oct 23 14:50:43 2012 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 A169B1F0C42 for ; Tue, 23 Oct 2012 14:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vthz1kFczjZ for ; Tue, 23 Oct 2012 14:50:43 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED06C1F0C3A for ; Tue, 23 Oct 2012 14:50:42 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so3488870wib.13 for ; Tue, 23 Oct 2012 14:50: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=RRqmDC1DIxXwoHkJwPkiGsFC78NFysNqSvpuQ6zAYug=; b=Wj4hWQ2BkAWioX0rWnVSp1LYE6KsROy22caJGhIIDG+Sair+tcKteWF2t3qhvjsDYV qH7QZUCROjOybFB/t6pHmnDeTyrGcvuYyU+Ft2ulxTiHR3duOJSsXS2Ui2QhD9Uxs1MD cb1vvFUWj6V1H+6QqWVHSzguaLAUpjHaHEZnGHbleFIMjnC3wEFqIci10zljSwNtdbKy ief2EOBHaOlPy5Vk2nWtX0SbYcCqSU24euuQTX6fKRrs7MnQdJpanrmdyf19UF5P8+po iUg5q0MU+9KbW+Ip5OKxHstPcQjYkCngFkYYrYGBdDEyidli5e7ZdGeKRpfzJFCae1Ys LCJA== Received: by 10.216.198.198 with SMTP id v48mr6907776wen.192.1351029042024; Tue, 23 Oct 2012 14:50:42 -0700 (PDT) Received: from [172.16.139.253] (17.82.69.86.rev.sfr.net. [86.69.82.17]) by mx.google.com with ESMTPS id v3sm980920wiy.5.2012.10.23.14.50.39 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 14:50:41 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <50870C53.1040602@joelhalpern.com> Date: Tue, 23 Oct 2012 23:50:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> <50870C53.1040602@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1499) Cc: LISP mailing list list , Noel Chiappa Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 21:50:43 -0000 On 23 Oct 2012, at 23:29, "Joel M. Halpern" wrote: > If I understood, you expressed disagreement with the general = description of LISP security. > Can you suggest what approach you would like to see taken? >=20 Section 7.4 is perfectly fine in the document, it is simply that I think = the security in LISP is not "just enough" but "almost just enough". Saying just enough gives me the impression that the question is done, solved. But I think we have not explored yet all what we could have in term of security for LISP. For example, we have never really looked at cryptography, puzzling, third party verification... I remember the draft-saucez-lisp-mapping-security that did not get that much attention, fortunately, LISP-SEC came and solved partially the problem with a very pragmatic approach. My academic blood tells me that we should look at everything and try to find magical solutions to protect everything. On the other hand, the operations show that in security the best is really the enemy of the good. So we have to find a trade-off between best and good.=20 Damien Saucez > Thank you, > Joel From jmh@joelhalpern.com Tue Oct 23 14:54:56 2012 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 B01401F0C9C for ; Tue, 23 Oct 2012 14:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.153 X-Spam-Level: X-Spam-Status: No, score=-102.153 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P8mdlSgiaOW for ; Tue, 23 Oct 2012 14:54:55 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C1D231F0CA1 for ; Tue, 23 Oct 2012 14:54:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id A5B19558128 for ; Tue, 23 Oct 2012 14:54:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C28A41C046D; Tue, 23 Oct 2012 14:54:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-221.clppva.btas.verizon.net [71.161.51.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id DD1A21C0343; Tue, 23 Oct 2012 14:54:36 -0700 (PDT) Message-ID: <50871217.4080806@joelhalpern.com> Date: Tue, 23 Oct 2012 17:54:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Damien Saucez References: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> <50870C53.1040602@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list , Noel Chiappa Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 21:54:57 -0000 I had not gotten that distinction from your earlier note. Yours, Joel On 10/23/2012 5:50 PM, Damien Saucez wrote: > > On 23 Oct 2012, at 23:29, "Joel M. Halpern" wrote: > >> If I understood, you expressed disagreement with the general description of LISP security. >> Can you suggest what approach you would like to see taken? >> > > Section 7.4 is perfectly fine in the document, it is simply that I think the > security in LISP is not "just enough" but "almost just enough". Saying > just enough gives me the impression that the question is done, solved. > But I think we have not explored yet all what we could have in term of > security for LISP. For example, we have never really looked at > cryptography, puzzling, third party verification... > > I remember the draft-saucez-lisp-mapping-security that did not > get that much attention, fortunately, LISP-SEC came and solved > partially the problem with a very pragmatic approach. > > My academic blood tells me that we should look at everything > and try to find magical solutions to protect everything. On the > other hand, the operations show that in security the best is > really the enemy of the good. So we have to find a trade-off > between best and good. > > Damien Saucez > >> Thank you, >> Joel > From pvinci@VinciConsulting.com Wed Oct 24 03:52:40 2012 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 6A09B21F8BBB for ; Wed, 24 Oct 2012 03:52:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rhrd2398Nsc for ; Wed, 24 Oct 2012 03:52:39 -0700 (PDT) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 71BA321F8BB4 for ; Wed, 24 Oct 2012 03:52:39 -0700 (PDT) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 06:52:38 -0400 From: Paul Vinciguerra To: Damien Saucez , "Joel M. Halpern" Thread-Topic: LISP Security WAS: [lisp] intro & architecture drafts Thread-Index: AQHNsc+JOdAGfFytCkG26BivbDvpww== Date: Wed, 24 Oct 2012 10:52:37 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C9294F235@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.119.75.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list , Noel Chiappa Subject: [lisp] LISP Security WAS: intro & architecture drafts 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 Oct 2012 10:52:40 -0000 =0A= =0A= My academic blood tells me that we should look at everything=0A= and try to find magical solutions to protect everything. On the=0A= other hand, the operations show that in security the best is=0A= really the enemy of the good. So we have to find a trade-off=0A= between best and good.=0A= =0A= Damien Saucez=0A= =0A= Hi Damian,=0A= =0A= I read your security document after your emails yesterday, and was hoping I= could get you to address your thoughts on the best practical security meas= ures. Without offering an opinion as to the ease of the exploit and the sc= ope of the impact or failure, it becomes hard to determine resources need t= o allocated to any sort of mitigation.=0A= =0A= The single largest risk I took away from your document is the need to prote= ct against spoofing. The second risk, resource starvation, seemed to stem l= argely from spoofing as well.=0A= =0A= It seems to me that the largest problem in terms of addressing many of the = issues in your document is that the protocol relies on UDP for transport an= d while that is a plus for the protocol, it makes security more difficult. = This makes ACL's only marginally useful since UDP is by its nature, so eas= y to spoof.=0A= =0A= You offered up a new type of ACL based on the map cache, specifically for t= ransit through the PxTR. I agree that its value is to protect against prov= ider theft of service, but the value of ACL's seem to be of limited use bec= ause of the use of UDP. =0A= =0A= The only solution that seems to address the spoof-ability of the transport = is to provide some type of authentication within the packet. I also think = that if the nonce were not defined as a random packet, but as a key that is= generated based on the mapping system being a trusted third party, the spo= ofing risks could be minimized. Something similar and lighter that LISP-SE= C, but for xTR-xTR communication.=0A= =0A= But this would all be future work.=0A= =0A= I would be interested in your thoughts on specific configuration options av= ailable today and their impact on security. For example, you discuss glean= ing to an extent and the risk it bears. I am not aware of any option to di= sable it, so separation of xTR and iTR, for the time being could be step to= mitigate that risk. Enabling RLOC probing may be another tool.=0A= =0A= Thanks,=0A= =0A= Paul=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From damien.saucez@gmail.com Wed Oct 24 05:40:11 2012 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 D344B21F8B5B for ; Wed, 24 Oct 2012 05:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5pfIz29CtTI for ; Wed, 24 Oct 2012 05:40:11 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F07CD21F8B45 for ; Wed, 24 Oct 2012 05:40:10 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so210425eek.31 for ; Wed, 24 Oct 2012 05:40: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=WyNGk5q4UoaNtUN9MXOLlsfLR9eKtBV7Jgazv8ypM4Q=; b=F4a8+S8pPWgmdtdlik7b1+bnEfg5IH9ipMWkbd1BOFsKDQEA2RYJ/31swe/zcKUHMx r8kNwKCG/bsKOtdQdC8A/T7vRVK30JuUXSXSPQt/S/jwOZ4zQeJcNa/vZQq+ziY89KqV M6OnNbDX7OchuzNXCaOzuhJX+p+3fu8EasS3Z1+QvfPNNJSupbdpI2iwor9QOG3EmflQ awv2NK/m+Upi+YWGLeV1xYs8k+JY57j5SU/p0HD1D5unD0a0cH6iuF1xlgaotqW6EcGt rXvOf/rxcxy3HXnEqoa2VAvn2OyeDrtKJBo4OXS9U/TbBSdgPEK/Xr3utbH/GLLgchB1 uQfg== Received: by 10.14.193.134 with SMTP id k6mr21328345een.15.1351082410112; Wed, 24 Oct 2012 05:40:10 -0700 (PDT) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPS id d44sm25551340eeo.10.2012.10.24.05.40.08 (version=SSLv3 cipher=OTHER); Wed, 24 Oct 2012 05:40:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <6E5736BD68F770449C74FBAD975F807C9294F235@NYDC-EXCH01.vinci-consulting-corp.local> Date: Wed, 24 Oct 2012 14:40:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E5736BD68F770449C74FBAD975F807C9294F235@NYDC-EXCH01.vinci-consulting-corp.local> To: Paul Vinciguerra X-Mailer: Apple Mail (2.1499) Cc: LISP mailing list list , Noel Chiappa Subject: Re: [lisp] LISP Security WAS: intro & architecture drafts 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 Oct 2012 12:40:11 -0000 Hello, On 24 Oct 2012, at 12:52, Paul Vinciguerra = wrote: >=20 >=20 > My academic blood tells me that we should look at everything > and try to find magical solutions to protect everything. On the > other hand, the operations show that in security the best is > really the enemy of the good. So we have to find a trade-off > between best and good. >=20 > Damien Saucez >=20 > Hi Damian, >=20 > I read your security document after your emails yesterday, and was = hoping I could get you to address your thoughts on the best practical = security measures. Without offering an opinion as to the ease of the = exploit and the scope of the impact or failure, it becomes hard to = determine resources need to allocated to any sort of mitigation. >=20 > The single largest risk I took away from your document is the need to = protect against spoofing. The second risk, resource starvation, seemed = to stem largely from spoofing as well. you are right, protection against spoofing might help a lot. >=20 > It seems to me that the largest problem in terms of addressing many of = the issues in your document is that the protocol relies on UDP for = transport and while that is a plus for the protocol, it makes security = more difficult. This makes ACL's only marginally useful since UDP is by = its nature, so easy to spoof. yes, as opposed to TCP where we can do some pre-verification during the = 3 whs. >=20 > You offered up a new type of ACL based on the map cache, specifically = for transit through the PxTR. I agree that its value is to protect = against provider theft of service, but the value of ACL's seem to be of = limited use because of the use of UDP. =20 agree >=20 > The only solution that seems to address the spoof-ability of the = transport is to provide some type of authentication within the packet. = I also think that if the nonce were not defined as a random packet, but = as a key that is generated based on the mapping system being a trusted = third party, the spoofing risks could be minimized. Something similar = and lighter that LISP-SEC, but for xTR-xTR communication. >=20 I remember we looked at this for a while, but the nature of data plane = packet is such that it is probably hard to do it. Mainly for two reasons. First, because the = number of bits is limited so replay attacks are easy; second it is not sure that at very high rate = it is easy to do this kind of signature. There is some early discussion in = draft-saucez-lisp-mapping-security for the control-plane. I think that if we manage to secure the control plane, almost everything = is done. Indeed, the security issues from the data plane mostly come from optimisations (LSB, = echo-noncing, gleaning) that can be ignored in critical environments. > But this would all be future work. >=20 > I would be interested in your thoughts on specific configuration = options available today and their impact on security. For example, you = discuss gleaning to an extent and the risk it bears. I am not aware of = any option to disable it, so separation of xTR and iTR, for the time = being could be step to mitigate that risk. Enabling RLOC probing may be = another tool. Good question, the best is to wait the answer from the Cisco teams. In = OpenLISP, there is no such thing as gleaning. Damien Saucez >=20 > Thanks, >=20 > Paul >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From pvinci@VinciConsulting.com Thu Oct 25 07:55:14 2012 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 AD0DD21F8A01 for ; Thu, 25 Oct 2012 07:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=1.951, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx-6we3seOSg for ; Thu, 25 Oct 2012 07:55:14 -0700 (PDT) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id E183321F89F5 for ; Thu, 25 Oct 2012 07:55:13 -0700 (PDT) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 10:55:12 -0400 From: Paul Vinciguerra To: LISP mailing list list Thread-Topic: [lisp] intro & architecture drafts Thread-Index: AQHNsU8tW7tuXkmNjEmtSwPMVlgWXJfHi0OAgAKPnHA= Date: Thu, 25 Oct 2012 14:55:11 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C9295803D@NYDC-EXCH01.vinci-consulting-corp.local> References: <20121015222026.46A5A18C0C8@mercury.lcs.mit.edu> <1BEC896D-C43D-4CCB-9A94-1DA5D94C4170@gmail.com> <20121023193427.GA33763@vaf-mac1.cisco.com> In-Reply-To: <20121023193427.GA33763@vaf-mac1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Noel Chiappa Subject: Re: [lisp] intro & architecture drafts 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, 25 Oct 2012 14:55:14 -0000 What does the list think about replacing the term "node" with endpoint, whe= re examples of endpoints would be physical or virtual hosts, mobile phones,= service identifiers (like a VIP for a given service, HTTP, SIP, etc..) and= I'm sure many other endpoint types that have yet to be thought of. Also, I would like to suggest that the concept of a site needs to be added.= The definition in the deployment guide is: LISP site: A single host or a set of network elements in an edge network under the administrative control of a single organization, delimited from other networks by LISP Tunnel Router(s). Paul=20 From jnc@mercury.lcs.mit.edu Thu Oct 25 08:03:36 2012 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 6653D21F8F95 for ; Thu, 25 Oct 2012 08:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzRu1Vd+7FgX for ; Thu, 25 Oct 2012 08:03:36 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E67CC21F8F92 for ; Thu, 25 Oct 2012 08:03:35 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7933418C0AA; Thu, 25 Oct 2012 11:03:35 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121025150335.7933418C0AA@mercury.lcs.mit.edu> Date: Thu, 25 Oct 2012 11:03:35 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] intro & architecture drafts 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, 25 Oct 2012 15:03:36 -0000 > From: Paul Vinciguerra > What does the list think about replacing the term "node" with endpoint The problem is that the term "endpoint" already has a fairly specific definition (a fate-sharing region, one end of an end-end communication), and some of the things you listed are not 'endpoints'. 'Node' was picked precisely because it was a somewhat nebulous term, one which _can_ cover all the things you listed. Noel From jnc@mercury.lcs.mit.edu Thu Oct 25 08:17:59 2012 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 B4B1321F9031 for ; Thu, 25 Oct 2012 08:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y96bZw1LURkQ for ; Thu, 25 Oct 2012 08:17:59 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEE721F902E for ; Thu, 25 Oct 2012 08:17:59 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 87F2D18C0AA; Thu, 25 Oct 2012 11:17:58 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121025151758.87F2D18C0AA@mercury.lcs.mit.edu> Date: Thu, 25 Oct 2012 11:17:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] intro & architecture drafts 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, 25 Oct 2012 15:17:59 -0000 PS: > From: Paul Vinciguerra > Also, I would like to suggest that the concept of a site needs to be > added. That one might be useful. I'll keep it in mind when I start work on the next rev (any day now, sigh). Noel From jnc@mercury.lcs.mit.edu Thu Oct 25 12:24:43 2012 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 3217421F8498 for ; Thu, 25 Oct 2012 12:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWAX07TrLuoc for ; Thu, 25 Oct 2012 12:24:42 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8D33821F86B9 for ; Thu, 25 Oct 2012 12:24:41 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 19DB718C0B2; Thu, 25 Oct 2012 15:24:41 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121025192441.19DB718C0B2@mercury.lcs.mit.edu> Date: Thu, 25 Oct 2012 15:24:41 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] intro & architecture drafts 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, 25 Oct 2012 19:24:43 -0000 > From: Damien Saucez > it is simply that I think the security in LISP is not "just enough" but > "almost just enough". Saying just enough gives me the impression that > the question is done, solved. But I think we have not explored yet all > what we could have in term of security for LISP. > ... > My academic blood tells me that we should look at everything and try to > find magical solutions to protect everything. On the other hand, the > operations show that in security the best is really the enemy of the > good. So we have to find a trade-off between best and good. I think I get what you're talking about here, and yes, that section of the 'Introduction' document is not quite as well worded as it could be. I will see if I can clarify it; slightly wordsmith that section to make it clearer that LISP's basic security philosophy is not just 'we'll deal with it later'. Your comment about the balance between security and practicality, etc does bring up a topic, though. As it happens, I spent a couple of months about a year back thinking about how secure DDT, and as a part of that, worked out an overall security philosophy for LISP. (Not a 'security structure', that would include things like 'we use private keys to secure the bindings'. By 'security philosophy', I meant something much more general - along the lines of your 'balance between security and practicality' point.) As part of the DDT security effort, I produced a very rough draft about DDT security; however, the document talked about more than securing DDT, it started by talking about an overall philosophy of security in LISP - it tried to develop one, explaining and justifying why that one in particular was chosen, and only _then_ applying that to the particular task of securing DDT. (Briefly, it attempted to provide a path to very hard 'long term' security, while at the same time not adding a great deal of 'up front' burden. In other words, we should indeed to have a path, with packet hooks, etc in place for industrial grade security, when we need it - but for the moment to leave it out of implementations/deployment, until it is needed.) I did use some of the text/concepts in this draft in the 'Security' section of the 'Perspective' document, in the discussion of security in LISP. However it would probably be useful to assemble the 'LISP security philosophy' material from that rough DDT-Security draft into a note to the WG, which can then decide if that security philosophy sounds reasonable/desirable. (I will do that shortly.) That way, I can make sure that people buy into this concept of LISP's security philosophy is! :-) I think you'll find that what I meant by 'just in time' security is something different, and with better long-range adaptability (although, as I mentioned, it could probably be worded better). Noel From jnc@mercury.lcs.mit.edu Thu Oct 25 14:42:32 2012 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 EA6CC21F867C for ; Thu, 25 Oct 2012 14:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMot4-TiL1nd for ; Thu, 25 Oct 2012 14:42:31 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4852721F860F for ; Thu, 25 Oct 2012 14:42:31 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6A78E18C0B3; Thu, 25 Oct 2012 17:42:30 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121025214230.6A78E18C0B3@mercury.lcs.mit.edu> Date: Thu, 25 Oct 2012 17:42:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: [lisp] LISP security philosophy 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, 25 Oct 2012 21:42:33 -0000 Hi, all, here's the note on a security 'philosophy' for LISP. This is a bit rough and incomplete, for which I apologize in advance: it's clipped out of a much longer document. That document included a lot more actual detail on how this approach would work when used to create security mechanisms for one part of LISP (it applied the philosophy laid out here to securing DDT), which made it a little easier to grasp some of the (admittedly) very high-level things it talks about, with a concrete instantiation in hand. And now that I look at the 'Architectural Perspective' document, most of this is already in there (albeit in slightly re-arranged form). Sigh! Still, it might be useful for this chunk to be pulled out separately, for the WG to consider, to see if everyone is OK with these general guidelines for security for LISP. Noel ---- Notes on security for LISP Architectural Setting There are a small number of key principles that will guide the design: - Design lifetime - Threat level How long is the design intended to last? If LISP succeeds, I would guess a minimum of a 50-year lifetime (IPv4 is now 34, and will be around for at least a decade yet, if not longer; DNS is 28, and will probably last indefinitely). How serious are the threats it needs to meet? Well... The _good_ thing about the Internet is that it brings the world to your doorstep - masses of information from around the world are instantly available on your display. The _bad_ thing about the Internet is that it brings the world to your doorstep - legions of crackers, thieves, and general scum and villainy. Their sophistication level is rising all the time: as the easier holes are plugged, they go after others. This will inevitably eventually require the most powerful security mechanisms available to counteract their attacks. An illustration from another field may be useful here. The kind of complex and powerful security available in multi-level secure time-sharing systems like Multics appeared at one point to be a relic of another age, not useful in the age of personal machines. Complex and difficult, they appeared to be an expensive dead end. However, when active content first started to appear, it became apparent that allowing active content from the network was allowing almost anyone to share the computer with you - exactly the situation the security of multi-level secure time-sharing systems was designed to handle. Which is not to say that LISP needs to be maximally secure _right away_. The threat will develop and grow over a long time period. However, the basic design has to be capable of being _securable_ to the expanded degree that will eventually be necessary. _Eventually_ it will need to be as securable as, say, DNS - i.e. it _can_ be secured to the same level, although people may chose not to secure their branches as well as, say, the DNS root does. At the same time, two pitfalls must be avoided. First, if we make the security too complex, and always mandatory, it will dissuade people from implementing LISP - or make it much harder, if they do - because they won't be able to run LISP without building all sorts of complex security stuff (which, after all, does not add any _functionality_). Second, we need to pay a lot of attention to usabililty, particularly in the area of configuration. A lot of experience has shown that when high-grade security is 'too much hassle', people wind up not using it, because it's too much of a PITA to configure it, etc, etc. Design Approach While LISP has to have an 'ultimate' security mechanism which is as good as that of, say, DNS, such a system can be complex to implement and configure. However, we can attempt to make LISP have an 'easier' mode, one which will be both easier to configure, and less work to implement. This can be both an interim system (with the full powered system available for when it it needed), as well as the system used on branches where security is less critical. The challenge is to do this in a way that does not make the design yet more complex again (since it has to include both the 'full strength' mechanism and the 'easier to configure' mechanism). This is the fundamental tradeoff we struggle with: we can provide 'easier to configure' options, but that may make the overall design and implementation more complex. It's not that that a minimal design is insecure, or the basic approach is wrong - it's not. It's more of a question of some operational convenience/etc issues - e.g. 'how easy will it be to recover from a cryptosystem compromise'. E.g. if we have two ways to recover from a security compromise, one which is mostly manual and a lot of work, and another which is more automated but makes the protocol more complicated, if compromises really are very rare, maybe the smart call _is_ to go with the manual thing - as long as we have looked carefully at both options, and understood in some detail the costs and benefits of each. As far as making it hard to implement to begin with: we can make it 'easy' to deploy initially by simply not implementing/configuring the heavy-duty security early on. Provided, of course, that the packet formats, etc, are all included in the design to begin with, but that should not be a problem. We can even put off issuing detailed specifications for some complex operations, like automatic updates for root-key rollover, until later in the process - provided all the tools that will need, in terms of packet formats, etc are already there.) I know this is starting to sound like a lot of stuff, but, we need really good security in LISP - if it becomes a key part of the network infrastructure, people are just going to demand that it have securability _and_ ease of use equal to (or better than) that of DNS. It's good to be really very sensitive to making LISP security _too_ complicated without really good reason. But better we do a really good job on it ourselves, where we can keep to the goal of 'as simple as possible', than have someone else land us with a complicated ball of yarn... Saying to the IETF/customers 'security compromises are not a real issue' is not going to fly well - but saying 'we looked at the following mechanism to deal in a semi-automated way with compromises {give detail so it's clear we really did look at it in detail} and we decided the complexity cost/benefit is not high enough to make it worth adding, versus this more manual procedure {again, details}' is much more likely to be OK with them. That shows we've done our due diligence, and it's not just 'oh, we can't be bothered' or 'this doesn't fit with our ideology'. Design Principles Security in LISP faces many of the same challenges as security for other parts of the Internet: good security usually means work for the users, but without good security, things are vulnerable. The Internet has seen many very secure systems devised, only to see them fail to reach wide adoption; the reasons for that are complex, and vary, but being too much work to use is a common thread. In addition, at this stage of LISP's development/deployment, building in the eventual maximum security mechanisms presents a large (perhaps too large) barrier to implementation and deployment. It is for all these reasons that LISP attempts to provide 'just enough' security. A couple of principles can guide us in the design. - Prior experience DNSSEC offers a lot of lessons - its capabilities have been identified as a result of actual operational experience. The current architecture is the result of a decade of field experience, and changes based on that experience to make it easier to configure, maintain, etc: Most (all?) of the changes since 1997. are not because of protocol/security flaws, but because actual experience showed the system to be operationally 'non-optimal'. Another very useful source comes from the advice of people with professional experience in secure systems; typically the military, which has long and deep experience with the operation of large-scale secure systems. Their experience in particular should be given due weight, as they have long experience in operating widespread systems with "ordinary" personnel. In particular, it should be noted that historically many systems have been broken into, not through a weakness in the algorithms, etc, but because of poor operational mechanics. (The well-known 'Ultra' breakins of the Allies were mostly due to failures in operational procedure.) So operational capabilities intended to reduce the chance of human operational failure are just as important as strong algorithms; making things operationally robust is a key part of 'real' security. - Complexity Complexity is bad for several reasons, and should always be reduced to a minimum. There are three kinds of complexity cost: protocol complexity, implementation complexity, and configuration complexity. We can further subdivide protocol complexity into packet format complexity, and algorithm complexity. (There is some overlap of algorithm complexity, and implementation complexity.) We can, within some limits, trade off one kind of complexity for others: e.g. we can provide configuration _options_ which are simpler, at the cost of making the protocol and implementation complexity greater. And we can make initial (less capable) implementations simpler if we make the protocols slightly more complex (so that early implementations don't have to implement all the features of the full-blown protocol). From pvinci@VinciConsulting.com Thu Oct 25 17:12:22 2012 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 392D221F88D1 for ; Thu, 25 Oct 2012 17:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkLGLjuiBAJy for ; Thu, 25 Oct 2012 17:12:21 -0700 (PDT) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1107A21F88AE for ; Thu, 25 Oct 2012 17:12:21 -0700 (PDT) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 20:12:19 -0400 From: Paul Vinciguerra To: Noel Chiappa , "lisp@ietf.org" Thread-Topic: [lisp] intro & architecture drafts Thread-Index: AQHNssHnW7tuXkmNjEmtSwPMVlgWXJfKoQtQ Date: Fri, 26 Oct 2012 00:12:19 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C929599BB@NYDC-EXCH01.vinci-consulting-corp.local> References: <20121025150335.7933418C0AA@mercury.lcs.mit.edu> In-Reply-To: <20121025150335.7933418C0AA@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] intro & architecture drafts 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 Oct 2012 00:12:22 -0000 > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of > Noel Chiappa >=20 > > From: Paul Vinciguerra >=20 > > What does the list think about replacing the term "node" with endpo= int >=20 > The problem is that the term "endpoint" already has a fairly specific > definition (a fate-sharing region, one end of an end-end communication), > and some of the things you listed are not 'endpoints'. [PV] I don't understand. Maybe you can explain a little bit more. Let me = try to explain my point as well. A physical host is an endpoint. A virtual machine is an endpoint behind a hypervisors switch. A mobile phone is an endpoint (as well as a site with RLOC's) A VIP for a service is an older type of indirection to try to separate iden= tity from location, no? We have used load balancers and GSLB for these purposes. Two months ago, we used LISP to redirect traffic for lisp.cisco.com from Sa= n Jose to our datacenter. We rsync'd the content and put up the same addre= ss on our boxes and used dynamic EID detection to bring them to life. The next time we do this, we will use _different_ addresses for the host an= d assign the lisp.cisco.com address to the listening HTTP request. In this= case, only that granular service is the endpoint.=20 You can see what we did and how here:=20 http://vinciconsulting.com/blog/-/blogs/we-had-a-prestigious-guest-visit-ou= r-datacenter-today-lisp-cisco-com I also agree with you that node is proper, _but_ I also know that quite oft= en when I ask someone how many nodes are on their networks, they typically = reply with the number of physical devices. >=20 > 'Node' was picked precisely because it was a somewhat nebulous term, one > which _can_ cover all the things you listed. > [PV] You have done a great job in classifying the moving parts of LISP (and= there are more than a few), without a doubt. But I have to ask if, from = the readers point of view, does the net being so wide make it harder for th= e reader to grasp the benefits, especially in an introductory document? F= or example, if I did not know that LISP could deliver IPv6 over IPv4 and vi= ce versa, I don't know that I would make the immediate connection with sect= ion heading 4.5, IP Version Reciprocal Traversal. We have a DDT root in ou= r datacenter, but until I read section 5.2.3, Indexing Subsystem, I did not= make that immediate connection either. I will say that once I read the se= ction and put what I know into that grouping, I frequently found myself say= ing "wow, I never thought of it like that, but that's right." =20 So, accuracy wise, I do not think I could have classified things better. Maybe I should be asking a different question. Who is the intended audienc= e for these documents? If it is written for protocol developers and design= ers, that makes sense, but deployment engineers also spend time reading RFC= 's and drafts and with that audience there is an immediate gratification re= flex, an impatient "what's in it for me" for lack of better phrasing. Paul From pvinci@VinciConsulting.com Thu Oct 25 17:57:08 2012 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 BF14C21F85E6 for ; Thu, 25 Oct 2012 17:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc9VVg7IlLLF for ; Thu, 25 Oct 2012 17:57:08 -0700 (PDT) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id DB78A21F8508 for ; Thu, 25 Oct 2012 17:57:07 -0700 (PDT) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 20:57:03 -0400 From: Paul Vinciguerra To: "lisp@ietf.org" Thread-Topic: LISP and RFC6598 - Shared address space. Thread-Index: Ac2zD2OvpK1JgDaEQei+HLg/A3CsCw== Date: Fri, 26 Oct 2012 00:57:03 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C92959AE3@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.14] Content-Type: multipart/alternative; boundary="_000_6E5736BD68F770449C74FBAD975F807C92959AE3NYDCEXCH01vinci_" MIME-Version: 1.0 Subject: [lisp] LISP and RFC6598 - Shared address space. 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 Oct 2012 00:57:08 -0000 --_000_6E5736BD68F770449C74FBAD975F807C92959AE3NYDCEXCH01vinci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The NANOG list was talking about shared address space for a while and if th= e widespread deployment of this RFC were to take off, it seems to have some= consequences for LISP as with shared address space: * RLOCs could multiple identities, depending on which side of the C= GN on falls on, * as well as the possibility of overlapping identities across provi= ders. There must be some existing uses for LISP, maybe with LISP-mobile-node wher= e this need to deal with NAT been already been addressed. --_000_6E5736BD68F770449C74FBAD975F807C92959AE3NYDCEXCH01vinci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The NANOG list was talking about shared address spac= e for a while and if the widespread deployment of this RFC were to take off= , it seems to have some consequences for LISP as with shared address space:=

·         RLOCs could multiple identities, depending o= n which side of the CGN on falls on,

·         as well as the possibility of overlapping id= entities across providers.

 

There must be some existing uses for LISP, maybe wit= h LISP-mobile-node where this need to deal with NAT been already been addre= ssed.

 

 

 

--_000_6E5736BD68F770449C74FBAD975F807C92959AE3NYDCEXCH01vinci_-- From fmaino@cisco.com Fri Oct 26 10:34:49 2012 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 AE7BB21F8559; Fri, 26 Oct 2012 10:34:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdJC9ShrYi+V; Fri, 26 Oct 2012 10:34:48 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5421F854E; Fri, 26 Oct 2012 10:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5482; q=dns/txt; s=iport; t=1351272888; x=1352482488; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=sDF8bKmu3wuHCXHxwmo/EUAr8+/LfYbuYaEtOBpXCp8=; b=AWliO4RHJ0O1vd5tiAo5w69KQDGE/YnF8UIP6Uh/zRQzniJ5AWhwnvyl bgbiB04mEdaeUrL04JeG5bUoXMO4A2GK/KuCJikajXAeODcEMnoVtIon0 N/rs5KnGre1yEakE3uLt1UDLMpztGnVILG0vdxXngz2E6fwMV9C0RWWSW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4FADXIilCrRDoJ/2dsb2JhbABEhhiFX7ZIgQiCHgEBAQQSARBUAQ0EHAMBAgoWCwICCQMCAQIBOwIIBgEMBgIBAQUZh2MBC5xvjSySa4txhVuBEwOIWY0agReNPIFrgw8 X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208,217";a="62303091" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 26 Oct 2012 17:34:46 +0000 Received: from dhcp-128-107-166-48.cisco.com (dhcp-128-107-166-48.cisco.com [128.107.166.48]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9QHYkhN015343; Fri, 26 Oct 2012 17:34:46 GMT Message-ID: <508AC9B6.7040407@cisco.com> Date: Fri, 26 Oct 2012 10:34:46 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: nvo3@ietf.org, "lisp@ietf.org" References: <20121022195432.24426.46963.idtracker@ietfa.amsl.com> In-Reply-To: <20121022195432.24426.46963.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121022195432.24426.46963.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020302060303050106020908" Subject: [lisp] Fwd: New Version Notification for draft-maino-nvo3-lisp-cp-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: Fri, 26 Oct 2012 17:34:49 -0000 This is a multi-part message in MIME format. --------------020302060303050106020908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit We have added a section (3.5) that shows how LISP control plane deals with end systems mobility. Comments will be appreciated. Thanks, Fabio -------- Original Message -------- Subject: New Version Notification for draft-maino-nvo3-lisp-cp-02.txt Date: Mon, 22 Oct 2012 12:54:32 -0700 From: To: CC: , , A new version of I-D, draft-maino-nvo3-lisp-cp-02.txt has been successfully submitted by Fabio Maino and posted to the IETF repository. Filename: draft-maino-nvo3-lisp-cp Revision: 02 Title: LISP Control Plane for Network Virtualization Overlays Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-maino-nvo3-lisp-cp-02.txt Status: http://datatracker.ietf.org/doc/draft-maino-nvo3-lisp-cp Htmlized: http://tools.ietf.org/html/draft-maino-nvo3-lisp-cp-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-maino-nvo3-lisp-cp-02 Abstract: The purpose of this draft is to analyze the mapping between the Network Virtualization over L3 (NVO3) requirements and the capabilities of the Locator/ID Separation Protocol (LISP) control plane. This information is provided as input to the NVO3 analysis of the suitability of existing IETF protocols to the NVO3 requirements. The IETF Secretariat --------------020302060303050106020908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit We have added a section (3.5) that shows how LISP control plane deals with end systems mobility.

Comments will be appreciated.

Thanks,
Fabio


-------- Original Message --------
Subject: New Version Notification for draft-maino-nvo3-lisp-cp-02.txt
Date: Mon, 22 Oct 2012 12:54:32 -0700
From: <internet-drafts@ietf.org>
To: <fmaino@cisco.com>
CC: <michsmit@insiemenetworks.com>, <dino@cisco.com>, <vermagan@cisco.com> 


A new version of I-D, draft-maino-nvo3-lisp-cp-02.txt
has been successfully submitted by Fabio Maino and posted to the
IETF repository.

Filename:	 draft-maino-nvo3-lisp-cp
Revision:	 02
Title:		 LISP Control Plane for Network Virtualization Overlays
Creation date:	 2012-10-22
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-maino-nvo3-lisp-cp-02.txt
Status:          http://datatracker.ietf.org/doc/draft-maino-nvo3-lisp-cp
Htmlized:        http://tools.ietf.org/html/draft-maino-nvo3-lisp-cp-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-maino-nvo3-lisp-cp-02

Abstract:
   The purpose of this draft is to analyze the mapping between the
   Network Virtualization over L3 (NVO3) requirements and the
   capabilities of the Locator/ID Separation Protocol (LISP) control
   plane.  This information is provided as input to the NVO3 analysis of
   the suitability of existing IETF protocols to the NVO3 requirements.


                                                                                  


The IETF Secretariat



--------------020302060303050106020908-- From pvinci@VinciConsulting.com Sun Oct 28 07:35:55 2012 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 1D45021F85E3 for ; Sun, 28 Oct 2012 07:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kahli9PSsFCx for ; Sun, 28 Oct 2012 07:35:53 -0700 (PDT) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id B701521F851F for ; Sun, 28 Oct 2012 07:35:52 -0700 (PDT) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0318.001; Sun, 28 Oct 2012 10:35:51 -0400 From: Paul Vinciguerra To: "lisp@ietf.org" Thread-Topic: Comments regarding PETR's in the deployment document. Thread-Index: Ac21F0RKFcY0PhYQTramisssui+w7w== Date: Sun, 28 Oct 2012 14:35:50 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807C929624CE@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.232.102] Content-Type: multipart/alternative; boundary="_000_6E5736BD68F770449C74FBAD975F807C929624CENYDCEXCH01vinci_" MIME-Version: 1.0 Subject: [lisp] Comments regarding PETR's in the deployment document. 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, 28 Oct 2012 14:35:55 -0000 --_000_6E5736BD68F770449C74FBAD975F807C929624CENYDCEXCH01vinci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I read section 4.2, I'd like to point out two issues that could simplif= y/optimize deployment : P-ETRs can be deployed by ISPs wishing to offer value-added services to their customers. As is the case with P-ITRs, P-ETRs too may introduce path stretch. Because of this the ISP needs to consider the tradeoff of using several devices, close to the customers, to minimize it, or few devices, farther away from the customers, minimizing cost instead. We see this in practice as well. Much more of the traffic path winds up on= the EID side. (All the non-LISP prefixes are EID's to a PeTR, yes?) This = minimizes the amount of time that packets are encapsulated between RLOCS. = I see a need for traffic engineering where PeTR's could advertise prefixes = into the mapping system (with some kind of no-export tag into the DDT). Ou= r specific use would be to egress traffic at our peering points where we di= rectly connect to the endpoint. If the encapsulated path were longer, the intermediary providers would also= see empirical evidence of LISP running on their networks, as the packets w= ould be UDP/4342. Once the packet passes through the PeTR, it's just a regu= lar packet again. This process should happen as close to the endpoints as = possible. This suggests that as a best practice, anycast addresses should= not be used for PeTR addresses, because anycast addresses minimize the en= capsulated path. As a security measure, access to P-ETRs should be limited to legitimate users by enforcing ACLs. In practice, this is hard to do. It is hard to do with outer header source= addresses if you support DHCP based RLOCs. Likewise, ACL's on the inner header source addresses help against theft of = service, but packets with IP options set can move the fixed offset of the i= nner header source address and make using ACL's a challenge. With ACL's, limiting legitimate users would imply matching the proper pairi= ng of both inner and outer header source addresses at a minimum. An altern= ative approach would be valuable as suggested in the interworking document. A Proxy-ETR should verify the (inner) source EID of the packet at time of decapsulation in order to verify that this is from a configured LISP site. This is to prevent spoofed inner sources from being encapsulated through the Proxy-ETR. Paul --_000_6E5736BD68F770449C74FBAD975F807C929624CENYDCEXCH01vinci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As I read section 4.2,  I’d like to point= out two issues that could simplify/optimize deployment :

 

  = ; P-ETRs can be deployed by ISPs wishing to offer value-added services=

  = ; to their customers.  As is the case with P-ITRs, P-ETRs too may=

  = ; introduce path stretch.  Because of this the ISP needs to consider

  = ; the tradeoff of using several devices, close to the customers, to

  = ; minimize it, or few devices, farther away from the customers,<= /span>

  = ; minimizing cost instead.

 

We see this in practice as well.  Much more of = the traffic path winds up on the EID side. (All the non-LISP prefixes are E= ID’s to a PeTR, yes?)  This minimizes the amount of time that pa= ckets are encapsulated between RLOCS.  I see a need for traffic engineering where PeTR’s could advertise prefixes into t= he mapping system (with some kind of no-export tag into the DDT).  Our= specific use would be to egress traffic at our peering points where we dir= ectly connect to the endpoint.

 

If the encapsulated path were longer, the intermedia= ry providers would also see empirical evidence of LISP running on their net= works, as the packets would be UDP/4342. Once the packet passes through the= PeTR, it’s just a regular packet again.  This process should happen as close to the endpoints as possi= ble.   This suggests that as a best practice, anycast addresses s= hould not be used for PeTR addresses, because anycast addresses  minim= ize the encapsulated path.

 

 

   As a security measure, access to P-ETRs should be li=
mited to
   legitimate users by enforcing ACLs.
 
 
In practic=
e, this is hard to do.  It is hard to do with outer header source addr=
esses if you support DHCP based RLOCs.  
Likewise, =
ACL’s on the inner header source addresses help against theft of serv=
ice, but packets with IP options set can move the fixed offset of the inner=
 header source address and make using ACL’s a challenge.
With ACL&#=
8217;s, limiting legitimate users would imply matching the proper pairing o=
f both inner and outer header source addresses at a minimum.  An alter=
native approach would be valuable as suggested in the interworking document=
.
 =
;
   A Proxy-ETR should verify the (inner) source EID of =
the packet at
   time of decapsulation in order to verify that this i=
s from a
   configured LISP site.  This is to prevent spoof=
ed inner sources from
   being encapsulated through the Proxy-ETR.=

 =
;
Paul<=
/o:p>

 

--_000_6E5736BD68F770449C74FBAD975F807C929624CENYDCEXCH01vinci_-- From ggx@gigix.net Mon Oct 29 08:12:19 2012 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 C688521F86DD for ; Mon, 29 Oct 2012 08:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.667 X-Spam-Level: X-Spam-Status: No, score=0.667 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxJP2UxEuBSs for ; Mon, 29 Oct 2012 08:12:16 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61FAD21F8674 for ; Mon, 29 Oct 2012 08:12:15 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2764936wey.31 for ; Mon, 29 Oct 2012 08:12:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer:x-gm-message-state; bh=veg2lbAC3ZJweK5t7k7oogiykmXYH+2bIXrnJpWxqSM=; b=ScvRsaFqP6qU31/t2lveIVCr//I369eLneX+2wqKGS95b8zVCRIqVyX9qAklsNgWWy z6/sVsvCN64Z9T/725aT8C3a6MTGjFlNu37qMDPRBeX0Fu7xC3lbJRpQoYurFBxwftW1 oyJzAGyvmq3ANKNjlREcIw/spIe1DVYZsvN50K/wRNJUfpIK3p4zXIoPBTEhKq+XekH+ d2/Xu5O0/NqzOdBe4JXJUxfkvcajdnWhOMPgmcf1HsvSuN5WtTZrvFmKa6iDt9umn55H hiMSZ38MUE9YYlPd8fpMZmKZqTKtE6kJbH5sU0dx6Sxo3TYn9o3E9b6lqGbiQE24wPlp TSBw== Received: by 10.180.77.38 with SMTP id p6mr15781846wiw.1.1351523533968; Mon, 29 Oct 2012 08:12:13 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:da:b953:9db5:8564? ([2001:660:330f:a4:da:b953:9db5:8564]) by mx.google.com with ESMTPS id dm2sm10187414wib.4.2012.10.29.08.12.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 08:12:12 -0700 (PDT) From: Luigi Iannone Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Oct 2012 16:16:25 +0100 References: <33ECE5C3-6EC2-4A92-8E74-81D6322B1A17@telecom-paristech.fr> To: "" Message-Id: <12E9E3C4-3BDC-47A3-A54A-EBC28B70A986@gigix.net> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlSjtqMv7sfk67txAQdnm0Kt7ZagKoQF5f2tFnEGAYC5uPXlTqWRHo9nq+A8t/aeHmy5JYS Subject: [lisp] Comments on introduction-01 document 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, 29 Oct 2012 15:12:19 -0000 Hi All, hereafter my comments on the introduction-01 document.=20 ciao Luigi Observations valid for the whole document: The use of the term "nodes" is very ambiguous and not coherent with = other LISP documents.=20 Isn't an EID an End-point Identifier? So why starting using "nodes".=20 Further, the text kind of "suggests" that a "node" has one (never = changing) identifier,=20 which is not true in the lisp context. =20 (trivial counter example: a "node" with two interfaces in the same LISP = site=85). I guess this was the same point Paul Vinciguerra was raising in a = different thread. =46rom a communication technology point of view I think we should just = care about the=20 communication end-points that need to be identified and located. =09 There are several acronyms that are not explained, for instance EID and = RLOC. I am not saying we need to put the definition (since it is in the = main spec) but at least what the acronym stands for. This will get the = reader used with the terminology. =20 >=20 >=20 > LISP Working Group J. N. = Chiappa > Internet-Draft Yorktown Museum of Asian = Art > Intended status: Informational July 16, = 2012 > Expires: January 17, 2013 >=20 >=20 > An Introduction to the LISP Location-Identity Separation System > draft-chiappa-lisp-introduction-01 >=20 > Abstract >=20 > 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. Too many details for an abstract in the following text. > 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. >=20 > 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. >=20 I would put the following paragraph as the first in the abstract, so to = make clear right away what this document is all about. (the LISP acronym = should be in spelled out) > This document is an introduction to the entire LISP system, for = those > who are unfamiliar with it. It is intended to be both easy to > follow, and also give a fairly detailed understanding of the entire > system. >=20 [snip] >=20 > 1. Background >=20 > 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. >=20 > The 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] >=20 > 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.) >=20 > 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] >=20 > 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. >=20 > 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] >=20 > 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. [LISP] >=20 > 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. LISP at this point represents a moderately > mature system, having undergone a long organic series of changes and > updates. >=20 > 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). >=20 > 2. Deployment Philosophy >=20 > 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. >=20 > 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. >=20 > The extreme focus on a viable deployment scheme is one of the > novelties of LISP. >=20 Might be worth citing: http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2012.98 >=20 > 3.1. Basic Approach >=20 > In LISP, nodes have both a 'locator' (a name which says _where_ in > the network's connectivity structure the node is), called an 'RLOC', > and an 'identifier' (a name which serves only to provide a = persistent > handle for the node), called an 'EID'. A node may have more than one > RLOC, or its RLOC may change over time (e.g. if the node is mobile), > but it keeps the same EID. >=20 > Technically, one should probably say that ideally, the EID names the > node (or rather, its end-end communication stack, if one wants to be What is exactly an "end-end" communication stack? > as forward-looking as possible), and the RLOC(s) name interface(s). Why?=20 This is true for LISP-MN but not the general architecture. Further, this = can put a wrong understanding in the reader, who will have trouble later = to understand strs, PxTRs, etc. etc. > (At the moment, in reality, the situation is somewhat more complex, > as will be explained elsewhere (in [Architecture], Section > "Namespaces-EIDs-Residual"). >=20 > This second distinction, of _what_ is named by the two classes of > name, is necessary both to enable some of the capabilities that LISP > provides (e.g the ability to seamlessly support multiple interfaces, > to different networks), and is also a further enhancement to the > architecture. Faailing typos: Faailing =3D> Failing > to clearly recognize both interfaces and > communication stacks as distinctly separate classes of things is > another failing of the existing Internet architecture (again, one > inherited from the previous generation of networking). >=20 > A novelty in LISP is that it uses existing IPvN addresses = (initially, > at least) for both of these kinds of names, thereby minimizing the > deployment cost, as well as providing the ability to easily interact > with unmodified hosts and routers. >=20 > 3.2. Basic Functionality >=20 > The basic operation of LISP, as it currently stands, is that LISP > augmented packet switches near the source and destination of packets > intercept traffic, and 'enhance' the packets. >=20 I am not sure whether 'enhance' is the right word, what about = 'extends'?? > The LISP device near the source looks up additional information = about > the destination, and then wraps the packet in an outer header, one > which contains some of that additional information. The LISP device > near the destination removes that header, leaving the original, > unmodified, packet to be processed by the destination node. >=20 > The LISP device near the source (the Ingress Tunnel Router, or = 'ITR') > uses the information originally in the packet about the identity of > its ultimate destination, i.e. the destination address, which one = can > view as the EID of the ultimate destination. It uses the destination > EID to look up the current location (the RLOC) of that EID. >=20 > The lookup is performed through a 'mapping system', which is the > heart of LISP: it is a distributed directory of bindings from EIDs = to > RLOCS. The destination RLOC will be (initially at least) the address > of the LISP device near the destination (the Egress Tunnel Router, = or > 'ETR'). >=20 > The ITR then generates a new outer header for the original packet, > with that header containing the destination's RLOC as the wrapped > packet's destination, and the ITR's own address (i.e. the RLOC of = the > original source) Here it is introduced the concept that ITRs are locators for the source = IED but is not explicitly spelled out. Why not making it more clear? > as the wrapped packet's source, and sends it off. >=20 > When the packet gets to the ETR, that outer header is stripped off, > and the original packet is forwarded to the original ultimate > destination for normal processing. >=20 > Return traffic is handled similarly, often (depending on the > network's configuration) with the original ITR and ETR switching > roles. The ETR and ITR functionality is usually co-located in a > single device; these are normally denominated as 'xTRs'. >=20 [snip] >=20 > 4.1. Provider Independence >=20 > Provider independence (i.e. the ability to easily change one's > Internet Service Provider) was probably the first place where the > Internet engineering community finally really felt the utility of > separating location and identity. >=20 > The problem is simple: for the global routing to scale, addresses > need to be aggregated (i.e. things which are close in the overall > network's connectivity need to have closely related addresses), the > so-called "provider aggregated" addresses. [RFC4116] However, if I am not a native english speaker, but I find this citation format = (sentence period and then citation) a bit confusing.=20 I would prefer:=20 "provider aggregated" addresses = [RFC4116]. However, if =20 or: "provider aggregated" addresses = ([RFC4116]). However, if =85 but it is just style... > this principle is followed, it means that when an entity switches > providers (i.e. it moves to a different 'place' in the network), it > has to renumber, a painful undertaking. [RFC5887] >=20 > In theory, it ought to be possible to update the DNS entries, and > have everyone switch to the new addresses, but in practise, = addresses > are embedded in many places, such as firewall configurations at = other > sites. >=20 > Having separate namespaces for location and identity greatly reduces > the problems involved with renumbering; an organization which moves > retains its EIDs (which are how most other parties refer to its > nodes), but is allocated new RLOCs, and the mapping system can > quickly provide the updated binding from the EIDs to the new RLOCs. >=20 > 4.2. Multi-Homing >=20 > Multi-homing is another place where the value of separation of > location and identity became apparent. There are several different > sub-flavours of the multi-homing problem - e.g. depending on whether > one wants open connections to keep working, etc - and other axes as > well (e.g. site multi-homing versus host multi-homing). >=20 > In particular, for the 'keep open connections up' case, without > separation of location and identity, the only currently feasible > approach is to use provider-independent addressses - which moves the > problem into the global routing system, with attendant costs. This > approach is also not really feasible for host multi-homing. >=20 > Multi-homing was once somewhat esoteric, but a number of trends are > driving an increased desirability, e.g. the wish to have multiple = ISP > links to a site for robustness; the desire to have mobile handsets > connect up to multiple wireless systems; etc. >=20 > Again, separation of location and identity, and the existince of a > binding layer which can be updated fairly quickly, as provided by > LISP, is a very useful tool for all variants of this issue. >=20 > 4.3. Traffic Engineering >=20 > Traffic engineering (TE) [RFC3272], desirable though this capability > is in a global network, is currently somewhat problematic to provide > in the Internet. The problem, fundamentally, is that this capability > was not visualized when the Internet was designed, so support for it > is somewhat in the 'when the only tool you have is a hammer, > everything looks like nail' category. >=20 > TE is, fundamentally, a routing issue. However, the current Internet > routing architecture, which is basically the Baran design of fifty > years ago [Baran] (a single large, distributed computationa), is = ill- > suited to provide TE. The Internet seems a long way from adopting a > more-advanced routing architecture, although the basic concepts for > such have been known for some time. [RFC1992] >=20 > Although the identity-location binding layer is thus a poor place, > architecturally, to provide TE capabilities, it is still an > improvement over the current routing tools available for this = purpose > (e.g. injection of more-specific routes into the global routing > table). In addition, instead of the entire network incurring the > costs (through the routing system overhead), when using a binding > layer to provide TE, the overhead is limited to those who are > actually communicating with that particular destination. >=20 > LISP includes a number of features in the mapping system to support > TE. (Described in Section 5.2 below.) >=20 > 4.4. Mobility >=20 > Mobility is yet another place where separation of location and > identity is obviously a key part of a clean, efficient and high- > functionality solution. Considerable experimentation has been > completed on doing mobility with LISP. >=20 > 4.5. IP Version Reciprocal Traversal >=20 Wouldn't be better to make this section more general? With the LCAF doc = we can intermix more than v4 and v6. > Note that LISP 'automagically' allows intermixing of various IP > versions for packet carriage; IPv4 packets might well be carried in > IPv6, or vice versa, depending on the network's configuration. This > would allow an 'island' of operation of one type to be > 'automatically' tunneled over a stretch of infrastucture which only > supports the other type. >=20 > While the machinery of LISP may seem too heavyweight to be good for > such a mundane use, this is not intended as a 'sole use' case for > deployment of LISP. Rather, it is something which, if LISP is being > deployed anyway (for its other advantages), is an added benefit that > one gets 'for free'. >=20 > 4.6. Local Uses >=20 > LISP has a number of use cases which are within purely local > contexts, i.e. not in the larger Internet. These fall into two > categories: uses seen on the Internet (above), but here on a private > (and usually small scale) setting; and applications which do not = have > a direct analog in the larger Internet, and which apply only to = local > deployments. >=20 > Among the former are multi-homing, IP version traversal, and support > of VPN's for segmentation and multi-tenancy (i.e. a spatially > separated private VPN whose components are joined together using the > public Internet as a backbone). >=20 > Among the latter class, non-Internet applications which have no > analog on the Internet, are the following example applications: > virtual machine mobility in data centers; other non-IP EID types = such > as local network MAC addresses, or application specific data. >=20 > 5. Major Functional Subsystems >=20 > LISP has only two major functional subsystems - the collection of > LISP packet switches (the xTRs), and the mapping system, which > manages the mapping database. The purpose and operation of each is > described at a high level below, and then, later on, in a fair = amount > of detail, in separate sections on each (Sections Section 8 and > Section 9, respectively). >=20 > 5.1. xTRs >=20 > xTRs are fairly normal packet switches, enhanced with a little extra > functionality in both the data and control planes, to perform LISP > data and control functionality. >=20 > The data plane functions in ITRs include deciding which packets need > to be given LISP processing (since packets to non-LISP sites may be > sent 'vanilla'); looking up the mapping; encapsulating the packet; > and sending it to the ETR. This encapsulation is done using UDP > [RFC768] (for reasons to be explained below, in Section 8.2), along > with an additional IPvN header (to hold the asource typo: asource =3D> source > and destination > RLOCs). To the extent that traffic engineering features are in use > for a particular EID, the ITRs implement them as well. >=20 > In the ETR, the data plane simply unwraps the packets, and forwards > the 'vanilla' packets to the ultimate destination. >=20 > Control plane functions in ITRs include: asking for {EID->RLOC} > mappings via Map-Request control messages; handling the returning > Map-Replies which contain the requested information; managing the > local cache of mappings; checking for the reachability and liveness > of their neighbour ETRs; and checking for outdated mappings and > requesting updates. >=20 > In the ETR, control plane functions include participating in the > neighbour reachability and liveness function (see Section 12.4); > interacting with the mapping indexing system (next section); and > answering requests for mappings (ditto). >=20 > 5.2. Mapping System >=20 > The mapping database is a distributed, and potentially replicated, > database which holds bindings between EIDs (identity) and RLOCs > (location). To be exact, it contains bindings between EID blocks and > RLOCs (the block size is given explicitly, as part of the syntax). >=20 > Support for blocks is both for minimizing the administrative > configuration overhead, as well as for operational efficiency; e.g. > when a group of EIDs are behind a single xTR. >=20 > However, the block may be (and often is) Why often? Looking at the lisp4.net I do not see that many mappings for = /32 or /128 =85...=20 > as small as a single EID. > Since mappings are only loaded upon demand, if smaller blocks become > predominant, then the increased size of the overall database is far > less problematic than if the routing table came to be dominated by > such small entries. >=20 > A particular node may have more than one RLOC, or may change its > RLOC(s), while keeping its singlar typo: singlar =3D> singular > identity. >=20 > The binding contains not just the RLOC(s), but also (for each RLOC > for any given EID) priority and weight (to allow allocation of load > between several RLOCs at a given priority); this allows a certain > amount of traffic engineering to be accomplished with LISP. >=20 > 5.2.1. Mapping System Organization >=20 > The mapping system is actually split into two major functional sub- > systems. The actual bindings themselves are held by the ETRs, and an > ITR which needs a binding effectively gets it from the ETR. >=20 > This co-location of the authoritative version of the mappings, and > the forwarding functionality which it describes, is an instance of > fate-sharing. [Clark] >=20 > To find the appropriate ETR(s) to query for the mapping, the second > subsystem, an 'indexing system', itself also a distributed, > potentally replicated database, provides information on which ETR(s) > are authoritative sources of information about the bindings which = are > available. >=20 > 5.2.2. Interface to the Mapping System >=20 > The client interface to the mapping system from an ITR's point of > view is not with the indexing system directly; rather, it is through > devices called Map Resolvers (MRs). >=20 > ITRs send request control messages (Map-Request packets) to an MR. > (This interface is probably the most important standardized = interface > in LISP - it is the key to the entire system.) The MR uses the > indexing system to eventually forward the Map-Request to the > appropriate ETR. The ETR formulates reply control messages (Map- > Reply packets), which is conveyed to the ITR. The details of the > indexing system, etc, are thus hidden from the 'ordinary' ITRs. >=20 > Similarly, the client interface to the indexing system from an ETR's > point of view is through devices called Map Servers (MSs - = admittedly > a poorly chosen term, but it's too late to change it now). >=20 > ETRs send registration control messages (Map-Register packets) to an > MS, which makes the information about the mappings which the ETR > indicates it is authoritative for available to the indexing system. > The MS formulates a reply control message (the Map-Notify packet), > which confirms the registration, and is returned to the ETR. The > details of the indexing system are thus likewise hidden from the > 'ordinary' ETRs. >=20 > 5.2.3. Indexing Subsystem >=20 > The current indexing system There is always a current mapping system, what about putting "At the = time of this writing..."??? > is called the Delegated Database Tree > (DDT), which is very similar in operation to DNS. [DDT], [RFC1034] > However, unlike DNS, the actual mappings are not handled by DDT; DDT > merely identifies the ETRs which hold the mappings. >=20 > Again, extensive large-scale simulations driven by lengthy = recordings > of actual traffic at several major sites, have been performed to > verify the effectiveness of this particular indexing system. [Jakab] >=20 > 6. Examples of Operation >=20 > To aid in comprehension, a few examples are given of user packets > traversing the LISP system. The first shows the processing of a > typical user packet, i.e. what the vast majority of user packets = will > see. The second shows what happens when the first packet to a > previously-unseen destination (at a particular ITR) is to be > processed by LISP. >=20 > 6.1. An Ordinary Packet's Processing >=20 > This case follows the processing of a typical user packet (for > instance, a normal TCP data or acknowledgment packet associated with > an open HTTP connection) as it makes its way from the source host to > the destination. >=20 > {{Rest to be written.}} >=20 > 6.2. A Mapping Cache Miss >=20 Wouldn't be better to have a general section about LISP Cache = operations???? (Then the cache miss will be just a sub-section) > If a host sends a packet, and it gets to the ITR, and the ITR both = i) > determines that it needs to perform LISP processing on the user data > packet, but ii) does not yet have a mapping cache entry which covers > that destination EID, then more complex processing ensues. >=20 > {{Rest to be written.}} >=20 > 7. Design Approach >=20 > Before describing LISP's components in more detail below, it may be > worth saying a few words about the design philosophy used in = creating > them - this may make clearer the reasons for some engineering = choices > in the mechanisms given there. >=20 > 7.1. Quick Implement-Test Loop >=20 > LISP uses a philosophy similar to that used in the early days of the > Internet, which is to just build it, then try it and see what > happens, and move forward from there based on what actually happens. > The concept has been to get something up and running, and then = modify > it based on testing and experience. >=20 > 7.1.1. No Desk Fixes >=20 > Don't try and forsee all issues from desk analysis. (Which is not to > say that one should not spend _some_ time on trying to forsee > problems, but be aware that it is a 'diminishing returns' process.) > The performance of very large, complex, physically distributed > systems is hard to predict, so rather than try (which would > necessarily be an incomplete exercise anyway, testing would > inevitably be required eventually), at a certain point it's better > just to get on with it - and you will learn a host of other lessons > in the process, too. >=20 > 7.1.2. Code Before Documentation >=20 > This is often a corollary to the kind of style described above. > While it probably would not have been possible in a large, > inhomogenous group, the small, close Why close? Everybody can implement LISP and provide feedback=85. > nature of the LISP > implementation group did allow this approach. >=20 > 7.2. Only Fix Real Problems >=20 > Don't worry about anything unless experience show it's a real > problem. For instance, in the early stages, much was made out of the > problem of 'what does an ITR do if it gets a packet, but does not > (yet) have a mapping for the destination?' >=20 > In practise, simply dropping such packets has just not proved to be = a > problem; the higher level protocol will retransmit them after a > timeout, and the mapping is usually in place by then. So spending a > lot of time (and its companion, energy) and mechanism (and _its_ > extremely undesirable companion, complexity) on solving this > 'problem' would not have been the most efficient approach, overall. >=20 > 7.3. No Theoretical Perfection >=20 > Attack hard problems with a number of cheap and simple mechanisms > that co-operate and overlap. Trying to find a single mechanism that > is all of: >=20 > - Robust > - Efficient > - Fast >=20 > is often (usually?) a fool's errand. (The analogy to the aphorism > 'Fast, Cheap, Good - Pick Any Two' should be obvious.) However, a > collection of simple and cheap mechanisms may effectively be able to > meet all of these goals (see, for example, ETR = Liveness/Reachability, > Section 12.4). >=20 > Yes, this results in a system which is not provably correct in all > circumstances. The world, however, is full of such systems - and in > the real world, effective robustness is more likely to result from > having multiple, overlapping mechanisms than one single high-powered > (and inevitably complex) one. In the world of civil engineering, > redundancy is now accepted as a key design principle; the same = should > be true of information systems. [Salvadori] >=20 > 7.3.1. No Ocean Boiling >=20 > Don't boil the ocean to kill a single fish. This is a combination of > 7.2 (Only Fix Real Problems) and 7.3 (No Theoretical Perfection); it > just means that spending a lot of complexity and/or overhead to deal > with a problem that's not really a problem is not good engineering. >=20 Any direct reference to LISP? > 7.4. Just Enough Security >=20 > How much security to have is a complex issue. It's relatively easy > for designers to add good security, but much harder to get the users > to jump over all the hoops necessary to use it. LISP has therefore > adopted a position where we add 'just enough' security. >=20 > The overall approach to security in LISP is fairly subtle, though, > and is covered in more detail elsewhere While I agree on this sentence, I would add a paragraph just to give = some information on the security level of LISP, otherwise the section = summarises in: "is complicate so we talk about it elsewhere". Clearly = not really satisfactory. > (in [Architecture], Section > "Security"). >=20 > 8. xTRs >=20 > As mentioned above (in Section 5.1), xTRs are the basic = data-handling > devices in LISP. This section explores some advanced topics related > to xTRs. >=20 > Careful rules have been specified for both TTL and ECN [RFC3168] to > ensure that passage through xTRs does not interfere with the > operation of these mechanisms. In addition, care has been taken to > ensure that 'traceroute' works when xTRs are involved. >=20 > 8.1. When to Encapsulate >=20 > An ITR knows that a destination is running LISP, and thus that it > should perform LISP processing on a packet (including potential > encapsulation) if it has an entry in its local mapping cache that > covers the destination EID. >=20 > Conversely, if the cache contains a 'negative' entry (indicating = that > the ITR has previously attempted to find a mapping that covers this > EID, and it has been informed by the mapping system that no such > mapping exists), it knows the destination is not running LISP, and > the packet can be forwarded normally. >=20 Shouldn't be stated that is there is nothing in the cache then the ITR = knows nothing and has to query the mapping system. What to do with the = packet is implementation dependent (with current practice being = dropping). > (The ITR cannot simply depend on the appearance, or non-appearance, > of the destination in the DFZ routing tables, as a way to tell if a > destination is a LISP site or not, because mechanisms to allow > interoperation of LISP sites and 'legacy' sites necessarily involve > advertising LISP sites' EIDs into the DFZ.) >=20 > 8.2. UDP Encapsulation Details I would rename this section "UDP Encapsulation Rationale". There are no = details on the encapsulation itself, just explanation on why UDP=85. >=20 > The UDP encapsulation used by LISP for carrying traffic from ITR to > ETR, and many of the details of how the it works, were all chosen = for > very practical reasons. >=20 > Use of UDP (instead of, say, a LISP-specific protocol number) was > driven by the fact that many devices filter out 'unknown' protocols, > so adopting a non-UDP encapsulation would have made the initial > deployment of LISP harder - and our goal (see Section 2.1) was to > make the deployment as easy as possible. >=20 > The UDP source port in the encapsulated packet is a hash of the > original source and destination; this is because many ISPs use > multiple parallel paths (so-called 'Equal Cost Multi-Path'), and > load-share across them. Using such a hash in the source-port in the > outer header both allows LISP traffic to be load-shared, and also > ensures that packets from individual connections are delivered in > order (since most ISPs try to ensure that packets for a particular > {source, source port, destination, destination port} tuple flow = along > a single path, and do not become disordered).. >=20 > The UDP checksum is zero because the inner packet usually already = has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > In most exising hardware, computing such a checksum (and checking it > at the other end) would also present an intolerable load, for no > benefit. >=20 > 8.3. Header Control Channel >=20 > LISP provides a multiplexed channel in the encapsulation header. It > is mostly (but not entirely) used for control purposes. (See > [Architecture], Section "Architecture-Piggyback" for a longer > discussion of the architectural implications of this.) >=20 > The general concept is that the header starts with an 8-bit 'flags' > field, and it also includes two data fields (one 24 bits, one 32), > the contents and meaning of which vary, depending on which flags are > set. This allows these fields to be 'multiplexed' among a number of > different low-duty-cycle functions, while minimizing the space > overhead of the LISP encapsulation header. >=20 > 8.3.1. Echo Nonces >=20 > One important use is for a mechanism known as the Nonce Echo, which > is used as an efficient method for ITRs to check the reachability of > correspondent ETRs. >=20 > Basically, an ITR which wishes to ensure that an ETR is up, and > reachable, sends a nonce to that ETR, carried in the encapsulation > header; when that ETR (acting as an ITR) sends some other user data > packet back to the ITR (acting in turn as an ETR), that nonce is > carried in the header of that packet, allowing the original ITR to > confirm that its packets are reaching that ETR. >=20 > Note that lack of a response is not necessarily _proof_ that > something has gone wrong - but it stronly suggests that something > has, so other actions (e.g. a switch to an alternative ETR, if one = is > listed; a direct probe; etc) are advised. >=20 > (See Section 12.5 for more about Echo Nonces.) >=20 > 8.3.2. Instances >=20 > Another use of these header fields is for 'Instances' - basically, > support for VPN's across backbones. [RFC4026] Since there is only > one destination UDP port used for carriage of user data packets, and > the source port is used for multiplexing (above), there is no other > way to differentiate among different destination address namespaces > (which are often overlapped in VPNs). >=20 > 8.4. Fragmentation I would rename this section "Maximum Transmission Unit", and add some = clarification on why there is this issue in the first paragraph. >=20 > Several mechanisms have been proposed for dealing with packets which > are too large to transit the path from a particular ITR to a given > ETR. >=20 > One, called the 'stateful' approach, keeps a per-ETR record of the > maximum size allowed, and sends an ICMP Too Big message to the > original source host when a packet which is too large is seen. >=20 > In the other, referred to as the 'stateless' approach, for IPv4 > packets without the 'DF' bit set, too-large packets are fragmented, > and then the fragments are forwarded; all other packets are > discarded, and an ICMP Too Big message returned. >=20 > It is not clear at this point which approach is preferable. >=20 > 8.5. Mapping Gleaning in ETRs >=20 > As an optimization to the mapping acquisition process, ETRs are > allowed to 'glean' mappings from incoming user data packets, and = also > from incoming Map-Request control messages. Let's be pedantic and add how this is done! > This is not secure, and > so any such mapping must be 'verified' by sending a Map-Request to > get an authoritative mapping. (See further discussion of the > security implications of this in [Architecture], Section "Security- > xTRs".) >=20 > The value of gleaning is that most communications are two-way, and = so > if host A is sending packets to host B (therefore needing B's > EID->RLOC mapping), very likely B will soon be sending packets back > to A (and thus needing A's EID->RLOC mapping). Without gleaning, > this would sometimes result in a delay, and the dropping of the = first > return packet; this is felt to be very undesirable. IMHO this last sentence is not coherent with what was written a couple = of pages before where first packet drop was not an issue at all.=20 Gleaning is a (big) security issue so we have a trade off here: lower = performance but (much) higher security.=20 I would change the sentence. >=20 > 9. The Mapping System >=20 > RFC 1034 ("DNS Concepts and Facilities") has this to say about the > DNS name to IP address mapping system: >=20 > "The sheer size of the database and frequency of updates suggest > that it must be maintained in a distributed manner, with local > caching to improve performance. Approaches that attempt to > collect a consistent copy of the entire database will become more > and more expensive and difficult, and hence should be avoided." >=20 > and this observation applies equally to the LISP mapping system. >=20 > As previously mentioned, the mapping system is split into an = indexing > subsystem, which keeps track of where all the mappings are kept, and > the mappings themsleves, typo: themsleves =3D> themselves > the authoritative copies of which are always > held by ETRs. >=20 > 9.1. The Indexing Subsystem >=20 > The indexing system in LISP is currently implemented by the DDT > system. LISP initially used (for ease of getting something > operational without having to write a lot of code) an indexing = system > called ALT, which used BGP running over virtual tunnels. [ALT] This > proved to have a number of issues, and has now been superseded by > DDT. What do you thing about adding a small paragraph of why ALT had issues? >=20 > In DDT, the EID namespace(s) are instantiated as a tree of DDT = nodes. > Starting with the root node(s), which have 'reponsibility' for the > entire namespace, portions of the namespace are delegated to child > nodes, in a recursive process extending through as many levels as = are > needed. Eventually, leaf nodes in the DDT tree delegate namespace > blocks to ETRs. >=20 > MRs obtain information about delegations by interrogating DDT nodes, > and caching the results. aThis typo: aThis =3D> This > allows them, when passed a request for > a mapping by an ITR, to forward the mapping request to the > appropriate ETR (perhaps after loading some missing delegation > entries into their delegation cache). >=20 > 9.2. The Mapping System Interface >=20 > As mentioned in Section 5.2.2, both of the inferfaces to the mapping > system (from ITRs, and ETRs) are standardized, so that the more > numerous xTRs do not have to be modified when the mapping indexing > system is changed. This precaution has already allowed the mapping > system to be upgraded during LISP's evolution, when ALT was replaced > by DDT. >=20 > This section describes the interfaces in a little more detail. >=20 > 9.2.1. Map-Request Messages >=20 > The Map-Request message contains a number of fields, the two most > important of which are the requested EID block identifier (remember > that individual mappings may cover a block of EIDs, not just a = single > EID), and the Address Family Identifier (AFI) for that EID block. > [AFI] The inclusion of the AFI allows the mapping system interface > (as embodied in these control packets) a great deal of flexibility. > (See [Architecture], Section "Namespaces" for more on this.) >=20 > Other important fields are the source EID (and its AFI), and one or > more RLOCs for the source EID, along with their AFIs. Multiple RLOCs > are included to ensure that at least one is in a form which will > allow the reply to be returned to the requesting ITR, and the source > EID is used for a variety of functions, including 'gleaning' (see > Section 8.5). >=20 > Finally, the message includes a long nonce, for simple, efficient > protection against offpath attackers (see [Architecture], Section > "Security-xTRs" for more), and a variety of other fields and control > flag bits. >=20 > 9.2.2. Map-Reply Maessages typo: Maessages =3D> Messages >=20 > The Map-Reply message looks similar, except it includes the mapping > entry for the requested EID(s), which contains one or more RLOCs and > their associated data. (Note that the reply may cover a larger block > of the EID namespace than the request; most requests will be for a > single EID, the one which prompted the query.) >=20 > For each RLOC in the entry, there is the RLOC, its AFI (of course), > priority and weight fields (see Section 5.2), and multicast priority > and weight fields. >=20 > 9.2.3. Map-Register and Map-Notify Messages >=20 > The Map-Register message contains authentication information, and a > number of mapping records, each with an individual Time-To-Live > (TTL). Each of the records contains an EID (potentially, a block of > EIDs) and its AFI, a version number for this mapping (see > Section 11.1), and a number of RLOCs and their AFIs. >=20 > Each RLOC entry also includes the same data as in the Map-Replies > (i.e. priority and weight); this is because in some circumstances it > is advantageous to allow the MS to proxy reply on the ETR's behalf = to > Map-Request messages. [Mobility] >=20 > Map-Notify messages have the exact same contents as Map-Register > messages; they are purely acknowledgements. >=20 > 9.2.4. Map-Referral Messages >=20 > Map-Referral messages look almost identical to Map-Reply messages > (which is felt to be an advantage by some people, although having a > more generic record-based format would probably be better in the = long > run, as ample experience with DNS has shown), except that the RLOCs > potentially name either i) other DDT nodes (children in the > delegation tree), or ii) terminal MSs. >=20 > There are also optional authentication fields; see [Architecture], > Section "Security-Mappings" for more. >=20 > 9.3. Reliability via Replication >=20 > Everywhere throughout the mapping system, robustness to operational > failures is obtained by replicating data in multiple instances of = any > particular node (of whatever type). Map-Resolvers, Map-Servers, DDT > nodes, ETRs - all of them can be replicated, and the protocol > supports this replication. >=20 > There are generally no mechanisms specified yet to ensure coherence > between multiple copies of any particular data item, etc - this is > currently a manual responsibility. If and when LISP protocol > adoption proceeds, an automated layer to perform this functionality > can 'easily' be layered on top of the existing mechanisms. >=20 > 9.4. Extended Tools >=20 > In addition to the priority and weight data items in mappings, LISP > offers other tools to enhance functionality, particularly in the > traffic engineering area. One are 'source-specific mappings', i.e. > the ETR may return different mappings to the enquiring ITR, = depending > on the identity of the ITR. This allows very fine-tuned traffic > engineering, far more powerful than routing-based TE. >=20 > 9.5. Expected Performance >=20 > {{To be written.}} What will be exactly the content of this section? The performance of = DDT? If yes, this should be in the title. On the other side this is a = general introduction on LISP do we need to write about the DDT = performance specifically? >=20 > 10. Deployment Mechanisms >=20 > This section discusses several deployment issues in more detail. > With LISP's heavy emphasis on practicality, much work has gone into > making sure it works well in the real-world environments most people > have to deal with. >=20 > 10.1. Internetworking Mechanism >=20 > One aspect which has received a lot of attention are the mechanisms > previously referred to (in Section 3.4) to allow interoperation of > LISP sites with so-called 'legacy' sites which are not running LISP > (yet). >=20 > To briefly refresh what was said there, there are two main = approaches > to such interworking: proxy nodes (PITRs and PETRs), and an > alternative mechanism using device with combined NAT and LISP > functionality; these are described in more detail here. >=20 > 10.2. Proxy Devices >=20 > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. PETRs (proxy ETRs) serve as ETRs for LISP traffic > _to_ legacy hosts (for cases where a LISP device cannot send packets > directly to such sites, without encapsulation). >=20 > Note that return traffic _to_ a legacy site from a LISP-using node > does not necessarily have to pass through an ITR/PETR pair - the > original packets can usually just be sent directly to the > destination. However, for some kinds of LISP operation (e.g. mobile > nodes), this is not possible; in these situations, the PETR is > needed. >=20 > 10.2.1. PITRs >=20 > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. To do that, they have to advertise into the > existing legacy backbone Internet routing the availability of > whatever ranges of EIDs (i.e. of nodes using LISP) they are proxying > for, so that legacy hosts will know where to send traffic to those > LISP nodes. >=20 > As mentioned previously (Section 8.1), an ITR at another LISP site > can avoid using a PITR (i.e. it can detect that a given destination > is not a legacy site, if a PITR is advertising it into the DFZ) by > checking to see if a LISP mapping exists for that destination. >=20 > This technique obviously has an impact on routing table in the DFZ, > but it is not clear yet exactly what that impact will be; it is very > dependent on the collected details of many individual deployment > decisions. >=20 > A PITR may cover a group of EID blocks with a single EID > advertisement, in order to reduce the number of routing table = entries > added. (In fact, at the moment, aggressive aggregation of EID > announcements is performed, precisely to to minimize the number of > new announced routes added by this technique.) >=20 > At the same time, it a site typo: it =3D> if > does traffic engineering with LISP > instead of fine-grained BGP announcement, that will help keep table > sizes down (and this is true even in the early stages of LISP > deployment). May be cite (might be useful in section 10.4 as well): http://biblio.info.ucl.ac.be/2007/415406.pdf > The same is true for multi-homing. >=20 > 10.2.2. PETRs >=20 > PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy hosts, > for cases where a LISP device cannot send packets to sites without > encapsulation. That typically happens for one of two reasons. >=20 > First, it will happen in places where some device is implementing > Unicast Reverse Path Forwarding (uRPF), to prevent a variety of > negative behaviour; originating packets with the source's EID in the > source address field will result in them being filtered out and > discarded. >=20 > Second, it will happen when a LISP site wishes to send packets to a > non-LISP site, and the path in between does not support the > particular IP protocol version used by the source along its entir > length. Use of a PETR on the other side of the 'gap' will allow the > LISP site's packet to 'hop over' the gap, by utilizing LISP's > built-in support for mixed protocol encapsulation. >=20 > PETRs are generally paired with specific ITRs, which have the > location of their PETRs configured into them. In other words, unlike > normal ETRS, typo: ETRS =3D> ETRs > PETRs do not have to register themselves in the mapping > database, on behalf of any legacy sites they serve. >=20 > Also, allowing an ITR to always send traffic leaving a site to a = PETR > does avoid having to chose whether or not to encapsulate packets; it > can just always encapsulate packets, sending them to the PETR if it > has no specific mapping for the destination. However, this is not > advised: as mentioned, it is easy to tell if something is a legacy > destination. >=20 > 10.3. LISP-NAT >=20 > A LISP-NAT device, as previously mentioned, combines LISP and NAT > functionality, in order to allow a LISP site which is internally > using addresses which cannot be globally routed to communicate with > non-LISP sites elsewhere in the Internet. (In other words, the > technique used by the PITR approach simply cannot be used in this > case.) >=20 > To do this, a LISP-NAT performs the usual NAT functionality, and > translates a host's source address(es) in packets passing through it > from an 'inner' value to an 'outer' value, and storing that > translation in a table, which it can use to similarly process > subsequent packets (both outgoing and incoming). [Interworking] >=20 > There are two main cases where this might apply: > - Sites using non-routable global addresses > - Sites using private addresses [RFC1918] >=20 > 10.4. LISP and DFZ Routing >=20 > {{To be written.}} >=20 > 10.5. Use Through NAT Devices >=20 > Like them or not (and NAT devices have many egregious issues - some > inherent in the nature of the process of mapping addresses; others, > such as the brittleness due to non-replicated critical state, caused > by the way NATs were introduced, as stand-alone 'invisible' boxes), > NATs are both ubiquitous, and here to stay for a long time to come. >=20 > Thus, in the actual Internet of today, having any new mechanisms > function well in the presence of NATs (i.e. with LISP xTRs behind a > NAT device) is absolutely necessary. LISP has produced a variety of > mechanisms to do this. >=20 > 10.5.1. First-Phase NAT Support >=20 > The first mechanism used by LISP to operate through a NAT device = only > worked with some NATs, those which were configurable to allow = inbound > packet traffic to reach a configured host. >=20 > A pair of new LISP control messages, LISP Echo-Request and Echo- > Reply, allowed the ETR to discover its temporary global address; the > Echo-Request was sent to the configured Map-Server, and it replied > with an Echo-Reply which included the source address from which the > Echo Request was received (i.e. the public global address assigned = to > the ETR by the NAT). The ETR could then insert that address in any > Map-Reply control messages which it sent to correspondent ITRs. >=20 > The fact that this mechanism did not support all NATs, and also > required manual configuration of the NAT, meant that this was not a > good solution; in addition, since LISP expects all incoming data > traffic to be on a specific port, it was not possible to have > multiple ETRs behind a single NAT (which normally would have only = one > global address to share, meaning port mapping would have to be used, > except that=85 ) Is something missing here? >=20 > 10.5.2. Second-Phase NAT Support >=20 > For a more comprehensive approach to support of LISP xTR deployment > behind NAT devices, a fairly extensive supplement to LISP, LISP NAT > Traversal, has been designed. [NAT] >=20 > A new class of LISP device, the LISP Re-encapsulating Tunnel Router > (RTR), passes traffic through the NAT, both to and from the xTR. > (Inbound traffic has to go through the RTR as well, since otherwise > multiple xTRs could not operate behind a single NAT, for the > 'specified port' reason in the section above.) >=20 > (Had the Map-Reply included a port number, this could have been > avoided - although of course it would be possible to define a new > RLOC type which included protocol and port, to allow other > encapsulation techniques.) >=20 > Two new LISP control messages (Info-Request and Info-Reply) allow an > xTR to detect if it is behind a NAT device, and also discover the > global IP address and UDP port assigned by the NAT to the xTR. A > modification to LISP Map-Register control messages allows the xTR to > initialize mapping state in the NAT, in order to use the RTR. >=20 > This mechanism addresses cases where the xTR is behind a NAT, but = the > xTR's associated MS is on the public side of the NAT; this > limitation, that MS's must be in the 'public' part of the Internet, > seems reasonable. >=20 > 11. Current Improvements >=20 > In line with the philosophies laid out in Section 7, LISP is > something of a moving target. This section discusses some of the > contemporaneous improvements being made to LISP. >=20 > 11.1. Mapping Versioning >=20 > As mentioned, LISP has been under development for a considerable > time. One early addition to LISP (it is already part of the base > specification) is mapping versioning; i.e. the application of > identifying sequence numbers to different versions of a mappping. > [Versioning] This allows an ITR to easily discover when a cached > mapping has been updated by a more recent variant. >=20 > Version numbers are available in control messages (Map-Replies), but > the initial concept is that to limit control message overhead, the > versioning mechanism should primarily use the multiplex user data > header control channel (see Section 8.3). >=20 > Versioning can operate in both directions: an ITR can advise an ETR > what version of a mapping it is currently using (so the ETR can > notify it if there is a more recent version), and ETRs can let ITRs > know what the current mapping version is (so the ITRs can request an > update, if their copy is outdated). >=20 > At the moment version numbers are manually assigned, and ordered. > Some felt that this was non-optimal, and that a better approach = would > have been to have 'fingerprints' which were computed from the = current > mapping data (i.e. a hash). It is not clear that the ordering buys > much (if anything), and the potential for mishaps with manually > configured version numbers is self-evident. >=20 I remember the discussion. Fingerprint does not give you the notion of = "freshness". If you do not have an ordering in the version numbers = (whatever ordering) you cannot say whether a mapping is "newer" or = "older" you can just state "it's different" but for the you can already = use the nonce. > 11.2. Replacement of ALT with DDT >=20 > As mentioned in Section 9.2, an interface is provided to allow > replacement of the indexing subsystem. LISP initially used an > indexing system called ALT. [ALT] ALT was relatively easy to > construct from existing tools (GRE, BGP, etc), but it had a number = of > issues that made it unsuitable for large-scale use. ALT is now being > superseded by DDT. >=20 > As indicated previously (Section 9.5), the basic structure and > operation of DDT is identical to that of TREE, so the extensive > simulation work done for TREE applies equally to DDT, as do the > conclusions drawn about TREE's superiority to ALT. [Jakab] >=20 > {{Briefly synopsize results}} >=20 > 11.2.1. Why Not Use DNS >=20 > One obvious question is 'Since DDT is so similar to DNS, why not > simply use DNS?' In particular, people are familiar with the DNS, > how to configure it, etc - would it not thus be preferable to use = it? > To completely answer this would take more space that available here, > but, briefly, there were two main reasons, and one lesser one. >=20 > First, the syntax of DNS names did not lend itself to looking up > names in other syntaxes (e.g. bit fields). This is a problem which > has been previously encountered, e.g. in reverse address lookups. > [RFC5855] >=20 > Second, as an existing system, the interfaces between DNS (should it > have been used as an indexing subsystem for LISP) would not be > 'tuneable' to be optimal for LISP. For instance, if it were desired > to have the leaf node in an indexing lookup directly contact the ETR > on behalf of the node doing the lookup (thereby avoiding a = round-trip > delay), that would not be easy without modifications to the DNS = code. > Obviously, with a 'custom' system, this issue does not arise. >=20 > Finally, DNS security, while robust, is fairly complex. Doing DDT > offered an opportunity to provide a more nuanced security model. > (See [Architecture], Section "Security" for more about this.) >=20 > 11.3. Mobile Device Support >=20 > Mobility is an obvious capability to provide with LISP. Doing so is > relatively simple, if the mobile host is prepared to act as its own > ETR. Shouldn't be xTR? > It obtains a local 'temporary use' address, and registers that > address as its RLOC. Packets to the mobile host are sent to its > temporary address, whereever that may be, and the mobile host first > unwraps them (acting as an ETR), and the processes them normally > (acting as a host). >=20 > (Doing mobility without having the mobile host act as its ETR is > difficult, even if ETRs are quite common. The reason is that if the > ETR and mobile host are not integrated, during the step from the ETR > to the mobile host, the packets must contain the mobile host's EID, > and this may not be workable. If there is a local router between the > ETR and mobile host, for instance, it is unlikely to know how to get > the packets to the mobile host.) >=20 > If the mobile host migrates to a site which is itself a LISP site, > things get a little more complicated. The 'temporary address' it > gets is itself an EID, requiring mapping, and wrapping for transit > across the rest of the Internet. A 'double encapsulation' is thus > required at the other end; the packets are first encapsulated with > the mobile node's temporary address as their RLOC, and then this has > to be looked up in a second lookup cycle (see Section 8.1), and then > wrapped again, with the site's RLOC as their destination. >=20 > This results in slight loss in maximum packet size, due to the > duplicated headers, but on the whole it is considerably simpler than > the alternative, which would be to re-wrap the packet at the site's > ETR, when it is discovered that the destination's EID was not > 'native' to the site. This would require that the mobile node's EID > effectively have two different mappings, depending on whether the > lookup was being performed outside the LISP site, or inside. >=20 > {{Also probably need to mention briefly how the other end is = notified > when mappings are updated, and about proxy-Map-Replies.}} [Mobility] >=20 > 11.4. Multicast Support >=20 > Multicast may seem an odd thing to support with LISP, since LISP is > all about separating identity from location, but although a = multicast > group in some sense has an identity, it certainly does not have _a_ > location. >=20 > However, multicast is important to some users of the network, for a > number of reasons: doing multiple unicast streams is inefficient; it > is easy to use up all the upstream bandwidth, and without multicast = a > server can also be saturated fairly easily in doing the unicast > replication. So it is important for LISP to 'play nicely' with > multicast; work on multicast support in LISP is fairly advanced, > although not far-ranging. >=20 > Briefly, destination group addresses are not mapped; only the source > address (when the source is inside a LISP site) needs to be mapped, > both during distribution tree setup, as well as actual traffic > delivery. In other words, LISP's mapping capability isa typo: isa =3D> is > used: it is > just applied to the source, not the destination (as with most LISP > activity); the inner source is the EID, and the outer source is the > EID's RLOC. >=20 > Note that this does mean that if the group is using separate source- > specific trees for distribution, there isn't a separate distribution > tree outside the LISP site for each different source of traffic to > the group from inside the LISP site; they are all lumped together > under a single source, the RLOC. >=20 > The approach currently used by LISP requires no packet format = changes > to existing multicast protocols. See [Multicast] for more; > additional LISP multicast issues are discussed in [LISP], Section = 12. >=20 > 11.5. {{Any others?}} LCAF? >=20 > 12. Fault Discovery/Handling >=20 [snip] From ggx@gigix.net Tue Oct 30 05:14:43 2012 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 C0A5E21F8536 for ; Tue, 30 Oct 2012 05:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw3Zm7am2KCm for ; Tue, 30 Oct 2012 05:14:40 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0B821F855A for ; Tue, 30 Oct 2012 05:14:39 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so111303wey.31 for ; Tue, 30 Oct 2012 05:14:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer:x-gm-message-state; bh=P+yG+tvDIr9kxILO4Clc8sPcnPFSq/FZK3b9JuEFgvA=; b=JuarsVwQKs2ODiqr6bWUfnmyC9H0VsKOPyXF/GxflmRSeXJGEdzsfKFL7ObD7l5fhb GJ8hhgPSXfmOP0SMkMjc1Hk8mle0VPDIOBEuk6P6SiUoL7jYNwn5WWAZJ4xpQ2ZwF2/v dd4y7YgESJAUtupq9/DbYLGudPSyCSJ3zhbCH9LBlJcmCYkZrfKtvO0TjOkb2JZL1c/g Hz0V1dKJgOofBOfA80JBDmMOoH92+0Lo5axXQR7/oZED5dGzVjYxs5tXupmvGXQczD6J nbYpR5LGyE3Z4gkfs0agG0wfOU48rr1IiZJputPrVjpujzsYahX0YHXSUvYxf5bdHKTN U8tA== Received: by 10.180.91.71 with SMTP id cc7mr2488441wib.2.1351599273130; Tue, 30 Oct 2012 05:14:33 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:7df7:4bcf:85e3:b36e? ([2001:660:330f:a4:7df7:4bcf:85e3:b36e]) by mx.google.com with ESMTPS id m14sm13682591wie.8.2012.10.30.05.14.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 05:14:32 -0700 (PDT) From: Luigi Iannone Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <617C965F-F20A-4F5E-B8DB-9F8A0BB1583B@gigix.net> Date: Tue, 30 Oct 2012 13:18:47 +0100 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlKhFAsHq5JLDd2sXkrAUevpxIc6Q+pxahn0q2qMlLohUgXnqaxKYUOlyhEFIUFA/hCoDoz Subject: [lisp] Comments on lisp-architecture-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, 30 Oct 2012 12:14:43 -0000 Hi, hereafter my comments on the architectural document. ciao Luigi General comments on the document: - Currently, acronyms are used without their long version. Yes we all = know the acronyms but the document is meant for LISP beginners, hence = would be helpful to have the acronyms explained the first time that they = are used. - In order to make the document self-contained wouldn't be better to put = a section at the beginning giving a very high level overview of how LISP = works? This would help in understanding the architectural choices = described in the remaining of the document.=20 >=20 >=20 > LISP Working Group J. N. = Chiappa > Internet-Draft Yorktown Museum of Asian = Art > Intended status: Informational July 16, = 2012 > Expires: January 17, 2013 >=20 >=20 > An Architectural Perspective on the LISP > Location-Identity Separation System > draft-chiappa-lisp-architecture-01 >=20 > Abstract >=20 IMHO the following paragraph has too many details for an abstract. > LISP upgrades the architecture of the IPvN internetworking system = by > separating location and identity, current 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. >=20 The following paragraph should be the first so that the content and = purpose of the document is clear from the very beginning of the = abstract. > This document gives additional architectural insight into LISP, and > considers a number of aspects of LISP from a high-level standpoint. >=20 > [NOTE: This is still a somewhat rough draft version; a few sections > at the end are just rough frameworks, but almost all the key > sections, and all the front part of the document, are here, and in > something like reasonably complete form.] >=20 [snip] >=20 > 2. Goals of LISP >=20 > As previously stated in the abstract, broadly, the goal of LISP is = to > be a practically deployable architectural upgrade to IPvN which > performs separation of location and identity. But what is the value > of that? What will it allow us to do? >=20 > The answer to that obviously starts with the things mentioned in = the > "Initial Applications" For readability, I would put a list of these initial applications. The = interested reader can then go to the intro document for details. > section of [Introduction], but there are > other, longer-range (and broader) goals as well. >=20 > 2.1. Reduce DFZ Routing Table Size >=20 > One of the main design drivers for LISP, as well as other location- > identity separation proposals, is to decrease the overhead of = running > global routing system. In fact, it was this aspect that led the = IRTF > Routing RG to conclude that separation of location and identity was = a > key architectural underpinning needed to control the growth of the > global routing system. [RFC6115] >=20 > As noted in [Introduction], many of the practical needs of Internet > users are today met with techniques that increase the load on the > global routing system (Provider Independent addresses for the > provision of provider independence, multihoming, etc; more-specific > routes for TE; etc.) Provision of these capabilities by a = mechanism > which does not involve extra load on the global routing system is > therefore very desirable. >=20 > A number of factors, including the use of these techniques, has led > to a great increase in the fragmentation of the address space, at > least in terms of routing table entries. In particular, the growth > in demand for multi-homing has been forseen as driving a large > increase in the size of the global routing tables. >=20 > In addition, as the IPv4 address space becomes fuller and fuller, I don't think Vince has nothing to do with this=85 ;-) Ok bad joke. I would state "IPv4 address space becomes the more and more a scarce = resource," > there will be an inevitable tendency to find use in smaller and > smaller 'chunks' of that space. [RFC6127] Concerning the citation style see my comment on the Introduction = document. > This too would tend to > increase the size of the global routing table. I would put a ref to the potaroo web site. >=20 > LISP, if successful and widely deployed, offers an opportunity to = use > separation of location and identity to control the growth of the = size > of the global routing table. (A full examination of this topic is > beyond the scope of this document - see {{find reference}}.) >=20 May I suggest:=20 http://biblio.info.ucl.ac.be/2007/415406.pdf > 2.2. Deployment of New Namespaces >=20 > Once the mapping system is widely deployed and available, it should > make deployment of new namespaces (in the sense of new syntax, if = not > new semantics) easier. E.g. if someone wishes in the future to > devise a system which uses native MPLS [RFC3031] for a data = carriage > system joining together a large number of xTRs, it would easy = enough > to arrange to have the mappings for destinations attached to those > xTRs abe typo? abe =3D> have???? > some sort of MPLS-specific name. >=20 > More broadly, the existence of a binding layer, with support for > multiple namespace built into the interface on both sides (see > Section 5) is a tremendously powerful evolutionary tool; one can > introduce a new namespace (on one side) more easily, if it is = mapped > to something which is already deployed (on the other). Then, having > taken that step, one can invert the process, and deploy yet another > new namespace, but this time on the other. >=20 > 2.3. Future Development of LISP >=20 > Speculation about long-term future developments which are enabled = by > the deployment of LISP is not really proper for this document. > However, interested readers may wish to consult [Future] for one > person's thoughts on this topic. I did not yet read the document, but may the WG should consider to adopt = it so to have a fully fledged citation here. >=20 > 3. Architectual Perspectives >=20 > This section contains some high-level architectural perspectives > which have proven useful in a number of ways for thinking about = LISP. > For one, when trying to think of LISP as a complete system, they > provide a conceptual structure which can aid analysis of LISP. For > another, they can allow the application of past analysis of, and > experience with, similar designs. >=20 > 3.1. Another Packet-Switching Layer >=20 > When considering the overall structure of the LISP system at a high > level, it has proven most useful to think of it as another packet- > switching layer, run on top of the original internet layer - much = as > the Internet first ran on top of the ARPANET. >=20 > All the functions that a normal packet switch has to undertake - = such > as ensuring that it can reach its neighbours, and they they are typo: they they are =3D> that they are > still > up - the devices that make up the LISP overlay also have to do, = along > the 'tunnels' which connect them to other LISP devices. >=20 > There is, however, one big difference: the fanout of a typical LISP > ITR will be much larger than most classic physical packet switches. > (ITRs only need to be considered, as the LISP tunnels are all > effectively unidirectional, from ITR to ETR - an ETR needs to keep = no > per-tunnel state, etc.) >=20 Unless the ETR performs sanity check on the received LISP-encapsulated = packets. This is also stated in the main spec and should be added. > LISP is, fundamentally, a 'tunnel' based system. Tunnel system > designs do have their issues (e.g. the high inter-'switch' = fan-out), > but it's important to realize that they also can have advantages, > some of which are listed below. >=20 > 3.2. 'Double-Ended' Approach >=20 > LISP may be thought of as a 'double-ended' approach to enhancing = the > architecture, in that it uses pairs of devices, one at each end of = a > communication stream. In particular, to interact with the = population > of 'legacy' hosts (which will be, inevitably, the vast majority, in > the early stages of deployment) it requires a LISP device at both > ends of the 'tunnel'. >=20 > This is in distinction to, say, NAT systems ([RFC1631]), which only > need a device deployed at one end: the host at the other end = doesn't > need a matching device at its end to massage Ok to talk about happy packets =85 but to massage them ;-) typo???: massage =3D> message??? > the packets, but can > simply consume them on its own, as any packets it receives are = fully > normal packets. This allows any site which deploys such a 'single- > ended' device to get the full benefit, whilst acting entirely on = its > own. [Wasserman] >=20 > The issue is not that LISP uses tunnels. Designs like HIP > ([RFC4423]) and ILNP ([ILNP]), which do not involve tunnels, = inhabit > a similar space to tunnel-based designs like LISP, in that unless > both ends are upgraded - or there is a proxy at the un-upgraded end = - > one doen't typo: doen't =3D> dosn't > get any benefits. So it's really not the tunnel which is > the key aspect, it's the 'all at one end' part which is key. = Whether > the system is tunnel, versus non-tunnel, is not that important. >=20 > However, the double-ended approach of LISP does have advantages, as > well as costs. To put it simply, the 'feature' of the alternative > approach, that there's only a box at one end, has a 'bug': Instead of "bug" I would use "issue" or "drawback" or "limitation". > there's > only a box at one end. There are things which such a design cannot > accomplish, because of that. Like for instance? >=20 > To put it another way, does the fact that the packet thus = necessarily > has only a single 'name' in it for the entities at each end (i.e. = the > IPvN source and destination addresses), because it is a 'normal' > packet, present a limitation? Put that way, it would seem natural > that it should cause certain limits. >=20 > To compile a complete list of the things that can be done, when two > separate 'names' are in the packet, is beyond the scope of this > document. However, one example of the kind of thing that can be = done > is mobility with open connections, without needing to 'triangle > route' the packets through some sort of 'base station' at the > original location. Another is that is possible to automatically > tunnel IPv6 traffic over IPv4 infrastructure, or vice versa, > invisibly to the hosts on both ends. >=20 > In the longer term, having having typo: delete "having" > tunnel boxes will allow (and is > allowing) us to explore other kinds of wrappings. For example, we > can transport 'raw' local-network packets (such as Ethernet MAC > frames) across an IPvN infrastructure. >=20 > One could also wrap packets in non-IPvN formats: perhaps to take > direct advantage of the capabilities of underlying switching = fabrics > (e.g. MPLS [RFC3031]); perhaps to deploy new carriage protocols, > etc, where non-standard packet formats will allow extended = semantics. >=20 > 4. Architectual Aspects >=20 > LISP does take some novel architectural approaches in a number of > ways: e.g. its use of a separate mapping system, etc, etc. This > section contains some commentary on some of the high-level > architectural aspects of LISP. >=20 > 4.1. Critical State >=20 > LISP does have 'critical state' in the network (i.e. state which, = if > if lost, causes the communication to fail). However, because LISP = is > designed as an overall system, 'designing it in' allows for a > 'systems' approach to its state issues. In LISP, this state has = been > designed to be maintained in an 'architected' way, so it does not > produce systemic brittleness in the way that the state in NATs = does. >=20 > For instance, throughout the system, provisions have been made to > have redundant copies of state, in multiple devices, so that the = loss > of any one device does not necessarily cause a failure of an = ongoing > connection. >=20 > 4.2. Need for a Mapping System >=20 > LISP does need to have a mapping system, which brings design, > implementation, configuration and operational costs. Surely all > these costs are a bad thing? However, having a mapping system have typo?: Have =3D> has ?? > advantages, especially when there is a mapping layer which has = global > visibility (i.e. other entities know that it is there, and have an > interface designed to be able to interact with it). This is unlike, > say, the mappings in NAT, which are 'invisible' to the rest of the > network. >=20 > In fact, one could argue that the mapping layer is LISP's greatest > strength. Wheeler's Axiom* ('Any problem in computer science can be > solved with another level of indirection') indicates that the = binding > layer available with the LISP mapping system will be of great = value. > Again, it is not the job of this document to list them all - and in > any event, there is no way to forsee them all. >=20 > The author of this document has often opined that the hallmark of > great architecture is not how well it does the things it was = designed > to do, but how well it does things it was never expected to have to > handle. Providing such a powerful and generic binding layer is one > sure way to achieve the sort of lasting flexibility and power that > leads to that outcome. >=20 What about citing rfc 5218, which makes the same point? > [Footnote *: This Axiom is often mis-attributed to Butler Lampson, > but Lampson himself indicated that it came from David Wheeler.] >=20 > 4.3. Piggybacking of Control on User Data >=20 > LISP piggybacks control transactions on top of user data packets. > This is a technique that has a long history in data networking, = going > back to the early ARPANET. [McQuillan] It is now apparently = regarded > as a somewhat dubious technique, the feeling seemingly being that > control and user data should be strictly segregated. >=20 > It should be noted that _none_ of the piggybacking of control > functionality in LISP is _architecturally fundamental_ to LISP. All > of the functions in LISP which are performed with piggybacking = could > be performed almost equally well with separate control packets. >=20 > The "almost" is solely because it would cause more overhead (i.e. > control packets); neither the response time, robustness, etc would > necessarily be affected - although for some functions, to match the > response time observed using piggybacking on user data would need = as > much control traffic as user data traffic. >=20 > This technique is particularly important, however, because of the > issue identified at the start of this section - the very large = fanout > of the typical LISP switch. Unlike a typical router, which will = have > control interactions with only a few neighbours, a LISP switch = could > eventually have control interactions with hundreds, or perhaps even > thousands (for a large site) of neighbours. >=20 You can cite: http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf The number of mappings in the cache are a measure of the LISP switch = fanout. =20 > Explicit control traffic, especially if good response times are > desired, could amount to a very great deal of overhead in such a > case. >=20 > 5. Namespaces >=20 > One of the key elements in any architecture, or architectural > analysis, are the namespaces involved: what are their semantics and > syntax, what are the kinds of things they name, etc. >=20 > LISP has two key namespace, EIDs and RLOCs, but it must be = emphasized > that on an architectural level, neither the syntax, or, to a lesser > degree, the semantics, of either are absolutely fixed. There are > certain core semantics which are generaly unchanging (such as the > notion that EIDs provide only identity, whereas RLOCs provide > location), but as we will see, there is a certain amount of > flexibility available for the long-term. >=20 > In particular, all of LISP's key interfaces always include an = Address > Family Identifier (AFI) [AFI] for all names, so that new forms can = be > introduced at any time the need is felt. I would cite here as well the LCAF document. > Of course, in practise such > an introduction would not be a trivial exercise - but neither is is typo: delete "is" > impossibly painful, as is the case with IPv4's 32-bit addresses, > which are effectively impossible to upgrade. >=20 > 5.1. LISP EIDs >=20 > A 'classic' EID is defined as a subset of the possible namespaces = for > endpoints. [Chiappa] Like most 'proper' endpoint names, as proposed > there, they contain contain no information about the location of = the > endpoint. EIDs are the subset of possible endpoint names which are: > fixed length, 'reasonably' short', binary (i.e. not intended for > direct human use), globally unique (in theory), and allocated in a > top-down fashion (to achieve the former). >=20 > LISP EIDs are, in line with the general LISP deployment philosophy, = a > reuse of something already existing - i.e. IPvN addresses. For > those used as in LISP as EIDs, LISP removes much (or, in some = cases, > all) of the location-naming function of IPvN addresses. >=20 > In addition, the goal is to have EIDs name hosts (or, more = properly, > their end-end communication stacks), whereas the other LISP = namespace > group (RLOCs) names interfaces. The idea is not just to have two > namespaces (with different semantics), but also to use them to name > _different classes of things_ - classes which currently do not have > clearly differentiated names. This should produce even more > functionality. >=20 > 5.1.1. Residual Location Functionality in EIDs >=20 > LISP retains, especially in the early stages of the deployment, in > many cases some residual location-naming functionality in EIDs, = This > is to allow the packet to be correctly routed/forwarded to the > destination node, once it has been unwrapped by the ETR - and this = is > a direct result of LISP's deployment philosophy (see = [Introduction], > Section "Deployment"). >=20 > Clearly, if there are one or more unmodified routers between the = ETR > and the desination node, those routers will have to perform a = routing > step on the packet, for which it will need _some_ information as to > the location of the destination. >=20 > One can thus view such LISP EIDs, which retain 'stub' location > information, as 'addresses' (in the definition of the generic sense > of this term, as used here), but with the location information > restricted to a limited, local scope. >=20 > This retention of some location functionality in LISP EIDs, in some > cases, has led some people to argue that use of the name 'EID' is > improper. In response, it was suggested that LISP use the term > 'LEID', to distinguish LISP's 'bastardized' Don't like the term, what about "variant"??? > EIDs from 'true' EIDs, > but this usage has never caught on. >=20 > It has also been suggested that one usage mode for LISP EIDs, in > existing software loads, is to assign them as the address on an > internal virtual interface; all the real interfaces would have = RLOCs > only. [Templin] This would make such LISP EIDs functionally > equivalent to 'real' EIDs - they are names which are purely = identity, > have no location information of any kind in them, and cannot be = used > to make any routing decisions anywhere outside the host. >=20 > It is true that even in such cases, the EID is still not a 'pure' > EID, as it names an interface, not the end-end stack directly. > However, to do a perfect job here (or on separation of location and > identity) is impossible without modifying existing hosts (which = are, > inevitably, almost always one end of an end-end communication) - = and > that has been ruled out, for reasons of viable deployment. >=20 > The need for interoperation with existing unmodified hosts limits = the > semantic changes one can impose, On this point you can cite:=20 http://www.computer.org/csdl/mags/ic/preprint/mic2012990288-abs.html > much as one might like to provide a > cleaner separation. (Future evolution can bring us toward that > state, however: see [Future].) >=20 > 5.2. RLOCs >=20 > RLOCs are basically pure 'locators' [RFC1992], although their = syntax > and semantics is restricted at the moment, because in practise the > only forms of RLOCs supported are IPv4 and IPv6. >=20 Pretty short section. May be we can add something about implications of = different model, e.g., RLOC on the device interface like in LISP-MN vs. = RLOC at the border of stub networks vs. other=85. > 5.3. Overlapping Uses of Existing Namespaces >=20 > It is in theory possible to have a block of IPvN namespace used as > both EIDs and RLOCs. In other words, EIDs from that block might map > to some other RLOCs, and that block might also appear in the DFZ as > the locators of some other ETRs. >=20 > This is obviously potentially confusing - when a 'bare' IPvN = address > from one of these blocks, is it the RLOC, or the EID? Sometimes it > it typo: ti =3D> is > obvious from the context, but in general one could not simply have > a (hypothetical) table which assigns all of the address space to > either 'EID' or 'RLOC'. >=20 > In addition, such usage will not allow interoperation of the sites > named by those EIDs with legacy sites, using the PITR mechanism > ([Introduction], Section "Proxy Devices"), since that mechanisms > depends on advertizing the EIDs into the DFZ, although the LISP-NAT > mechanism should still work ([Introduction], Section "LISP-NAT"). >=20 > Nevertheless, as the IPv4 namespace becomes increasingly used up, > this may be an increasingly attractive way of getting the 'absolute > last drop' out of that space. >=20 > 5.4. LCAFs >=20 > {{To be written.}} >=20 > --- Key-ID > --- Instance-IDs >=20 > 6. Scalability >=20 > As with robustness, any global communication system must be = scalable, > and scalable up to almost any size. As previously mentioned (xref > target=3D"Perspectives-Packet"/), Broken reference. > the large fanouts to be seen with > LISP, due to its 'overlay' nature, present a special challenge. >=20 > One likely saving grace is that as the Internet grows, most sites > will likely only interact with a limited subset of the Internet; if > nothing else, the separation of the world into language blocks = means > that content in, say, Chinese, will not be of interest to most of = the > rest of the world. This tendency will help with a lot of things > which could be problematic if constant, full, N^2 connectivity were > likely on all nodes; for example the caching of mappings. >=20 You can cite: http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf [snip] >=20 > 6.4. Scalability of The Indexing Subsystem >=20 > LISP initially used an indexing subsystem called ALT. [ALT] ALT was > relatively easy to construct from existing tools (GRE, BGP, etc), = but > it had a number of issues that made it unsuitable for large-scale > use. ALT is now being superseded by DDT. [DDT] >=20 > The basic structure and operation of DDT is identical to that of > TREE, so the extensive simulation work done for TREE applies = equally > to DDT, as do the conclusions drawn about TREE's superiority to = ALT. > [Jakab] >=20 None of the above paragraphs sketches what is ALT, what is TREE, and = what is DDT. I think that to add a very short description will improve and ease the = reading of this section. > =46rom an architectural point of view, the main advantage of DDT is > that it enables client side caching of information about = intermediate > nodes in the resolution hierarchy, and also enables direct > communication with them. As a result, DDT has much better scaling > properties than ALT. >=20 > The most important result of this change is that it avoids a > concentration of resolution request traffic at the root of the > indexing tree, a problem which by itself made ALT unsuitable for a > global-scale system. The problem of root concentration (and thus > overload) is almost unavoidable in ALT (even if masses of 'bypass' > links are created). >=20 > ALT's scalability also depends on enforcing an intelligent > organization that aincreases aggregation. Unfortunately, the = current > backbone routing BGP system shows that there is a risk of an = organic > growth of ALT, one which does not achieve aggregation. DDT does not > display this weakness, since its organization is inherently > hierarchical (and thus inherently aggregable). >=20 > The hierarchical organization of DDT also reduces the possibility = for > a configuration error which interferes with the operation of the > network (unlike the situation with the current BGP DFZ). DDT > security mechanisms can also help produce a high degree of > robustness, both against misconfiguration, and deliberate attack. > The direct communication with intermediate nodes in DDT also helps = to > quickly locate problems when they occur, resulting in better > operational characteristics. >=20 > Next, since in ALT mapping requests must be transmitted through an > overlay network, a significant share of requests can see > substantially increased latencies. Simulation results in the TREE > work clearly showed, and quantified, this effect. >=20 > The simulations also showed that the nodes composing the ALT and = DDT > networks for a mapping database of full Internet size could have > thousands of neighbours. This is not an issue for DDT, but would > almost certainly have been problematic for ALT nodes, since = handling > that number of simultaneous BGP sessions would likely to be > difficult. >=20 > 7. Security >=20 > LISP does not yet have an overarching security architecture. Many > parts of the system have been hardened, but more on a case-by case > basis, rather than from an overall perspective. (This is in part = due > to the 'just enough' approach to security initially taken in LISP; > see [Introduction], Section "Just Enough Security".) >=20 > This section represents an attempt to produce a more broadly-based > view of security in LISP; it mostly resulted from an attempt to add > security to the DDT indexing system ([DDT]), but the analysis is is typo: delete is > general enough to apply to LISP broadly. >=20 > The _good_ thing about the Internet is that it brings the world to > your doorstep - masses of information from all around the world are > instantly available on your computing device. The _bad_ thing about > the Internet is that it brings the world to your doorstep - = including > legions of crackers, thieves, and general scum and villainy. Thus, > any node may be the target of fairly sophisticated attack - often > automated (thereby reducing the effort required of the attacker to > spread their attack as broadly as possible). >=20 > Security in LISP faces many of the same challenges as security for > other parts of the Internet: good security usually means work for = the > users, but without good security, things are vulnerable. >=20 > The Internet has seen many very secure systems devised, only to see > them fail to reach wide adoption; the reasons for that are complex, > and vary, but being too much work to use is a common thread. It is > for this reason that LISP attempts to provide 'just enough' = security > (see [Introduction], Section "Just Enough Security"). >=20 > 7.1. Basic Philosophy >=20 > To square this circle, of needing to have very good security, but = of > it being too difficult to use very good security, the general = concept > is for LISP to have a series of 'graded' security measures = available, > with the 'ultimate' security mechanisms being very high-grade = indeed. >=20 > The concept is to devise a plan in which LISP can simultaneously > attempt to have not just 'ultimate' security, but also one or more > 'easier' modes, ones which will be easier to configure and use. = This > 'easier' mode can be both an interim system (with the full powered > system available for when it it typo: it =3D> is > needed), as well as the system used > in sections of the network where security is less critical = (following > the general rule that the level of any security should generally be > matched to what is being protected). >=20 > The challenge is to do this in a way that does not make the design > more complex, since it has to include both the 'full strength' > mechanism(s), and the 'easier to configure' mechanism(s). This is > one of the fundamental tradeoffs to struggle with: it is easy to > provide 'easier to configure' options, but that may make the = overall > design more complex. >=20 > As far as making it hard to implement to begin with (also something > of a concern initially, although obviously not for the long term): = we > can make it 'easy' to deploy initially by simply not implementing/ > configuring the heavy-duty security early on. (Provided, of course, > that the packet formats, etc, needed to support such security are = all > included in the design to begin with.) >=20 [snip] > 7.3. Security Overview >=20 > First, there are two different classes of attack to be considered: > denial of service (DoS, i.e. the ability of an intruder to simply > cause traffic not to successfully flow) versus exploitation (i.e. = the > ability to cause traffic to be 'highjacked', i.e. traffic to be = sent > to the wrong location). >=20 > Second, one needs to look at all the places that may be attacked. > Again, LISP is a relatively simple system, so there are not that = many > parts to examine. The following are the things we need to secure: >=20 I guess here the threat analysis document can be cited. > - Lookups > - Indexing > - Mappings >=20 > 7.3.1. Securing Lookups >=20 > {{To be written.}} Nonces, [SecurityReq] >=20 > 7.3.2. Securing The Indexing Subsystem >=20 > It is envisioned that DDT will be highly securable, with all the > delegations cryptographiclly secured via public-private signatures, > very similar to the way DNS is ([RFC4033]). >=20 > The detailed mechanisms will be based on DNS's; this has the = obvious > benefit that all the lessons of DNS's years of practical experience > with deployment, operations, etc, as well as the improvements to = the > basic design of DNS Security to provide a secure but usable system > can be taken into account. However, DDT's security will also apply > the thinking above, about making a 'versio' =20 typo?? versio =3D> version??? > which is easier to use > available. >=20 > {{To be written.}} >=20 > 7.3.3. Securing Mappings >=20 > There are two approaches to securing the provision of mappings. The > first, which is of course not completely satisfactory, is to only > secure the channel between the ITR and the entities involved in > providing mappings for it. (See above, Section 7.3.1) >=20 > The second is to secure the mappings themselves, by signing them = 'at > birth' (much the same way in which DNS Security operates). > [RFC4033]. There was an attempt early on to suggest such a system > for LISP ([SecurityAuth]), but it was not adopted (although the > particular proposal was rather complex). >=20 > In the long run, the latter approach would obviously be superior, > since it would be almost immune to any compromises of the mapping > distribution system. {{Tie-in to space allocation security}} >=20 > 7.4. Securing the xTRs >=20 > --- Cache management > --- Unsoliticed Map-Replies are _very bad_ - must go through > mapping system to verify that the sender is authoritative for > that range of EIDs >=20 > 8. Robustness >=20 > -- Depends on deployment as well as design > -- Architected, visible replication of state/data > -- Overlapping mechanisms (ref redundancy as key for robustness) >=20 > 9. Fault Discovery/Handling >=20 > Any global communication system must be robust, and to be robust, = it > must be able to discover and handle problems. LISP's general > philosophy of robustness is usually to have overlapping, simple > mechanisms to discover and repair problems. >=20 > 10. Optimization >=20 >=20 > -- Philosophy > -- Piggybacking > -- 'Wiretapping' return mappings > --- Security is an issue on that >=20 > 11. Open Issues >=20 > Although much work has been done on LISP, and it operates > satisfactorily in a reasonably large initial deployment, there are = a > few potentially problematic issues which remain. It is not clear if > they will be issues which need to be dealt, since they have not > proven to be obstacles so far, but it is worth listing them. >=20 > We can divide them in _local_ issues, i.e. ones which can be solved > on a node-by-node basis, without requiring co-ordinated change, and > systemic issues, which are obviously more problematic, since they > could require co-ordinated changes to the protocols. >=20 > 11.1. Local Open Issues >=20 > 11.1.1. Missing Mapping Packet Queueing >=20 > Currently, some (all?) ITRs discard packets when they need a > mapping, but have not loaded one yet, thereby causing the = applicaton > to have to retransmit their opening packet. True, many ARP > implementations use the same strategy, but the average APR typo: APR =3D> ARP > cache will > only ever contain a few mappings, so it will not be so noticeable = as > with the mapping cache in an ITR, which will likely contain > thousands. >=20 > Obviously, they could queue the packets while waiting to load the > mapping, but this presents a number of subtle implementation = issues: > the ITR must make sure that it does not queue too many packets, = etc. >=20 > In particular, if such packets are queued, this presents a = potential > DoS attack vector, unless the code is carefully written with that > possibility in mind. >=20 > 11.1.2. Mapping Cache Management Algorithm >=20 > Relatively little work has been done on sophisticated mapping cache > management algorithms; in particular, the issue of which mapping(s) > to drop if the cache reaches some maximum allowed size. >=20 > This particular issue has also been identified as another potential > DoS attack vector. >=20 > 11.2. Systemic Open Issues >=20 > 11.2.1. Mapping Database Provider Lock-in >=20 > This refers to the fact that if one does not like the entity which = is > providing the indexing for the part of the address space which = one's > EIDs are allocated out of, there isn't typo: delete isn't > probably isn't any way to > switch to an alternative provider. >=20 > It is not clear that this is a real probem, though - the fact that > all DNS top-level zones only have a single registry has not been a > problem, nor has the fact that if one doesn't like the service the > registry offers, one can't take one's DNS name to another registry. >=20 > Doing anything about it would also be difficult. Although it is > _technically_ possible to duplicate any node in the delegation = tree, > and in theory such duplicates could be provided by different > providers, it is not clear that such an arrangement would make > _business_ sense. >=20 > For instance, if the holder of 10.1.1/24 decides they do not like = the > entity providing indexing for 10.1/16 (call them E1), and ask = another > entity (E2) to provide alternative service for 10.1/16, two = problems > arise. First, E1 is _still_ going to have to maintain the correct > data for 10.1.1/24, and response to queries asking about them. > Second, E2 will similarly have to maintain data for, and reply to > queries about, all the other space-holders in 10.1/16 - even though > they will likely not have any business relationship with them. >=20 > 11.2.2. Automated ETR Synchronization >=20 > LISP requires that all the ETRs which are authoritative for the > mappings for a particular address block return the same mapping = data. > In particular, their idea of the 'liveness' of all the ETRs should = be > identical, and correct. >=20 > At the moment, this is mostly a manual process, although liveness > information can be currently be gathered from some IGPs. >=20 > 11.2.3. EID Reachability >=20 > At the moment, LISP assumes that if an ETR is reachable from a = given > ITR, all destination EIDs behind that ETR are reachable from that > ETR. There is no way to detect if any are not, nor to switch to an > alternate ETR. >=20 > It is not clear that this is a problem that needs attention. The > same has been true for all border routers for many years now, and > there does not seem to be any general mechanism to deal with it > (Although some BGP implementations may advertize changes in > reachability status if what they are seeing from their IGP = changes.) >=20 > 11.2.4. Detect and Avoid Broken ETRs >=20 > {{To be written}} WHy not discuss as well ITR failures? In this case this paper might be useful: http://inl.info.ucl.ac.be/system/files/Networking12-CRV.pdf [snip] From luigi.iannone@telecom-paristech.fr Mon Oct 29 08:11:20 2012 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 21CEC21F86DB for ; Mon, 29 Oct 2012 08:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.017 X-Spam-Level: ** X-Spam-Status: No, score=2.017 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAZRw-4AMBPy for ; Mon, 29 Oct 2012 08:11:16 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.52.34]) by ietfa.amsl.com (Postfix) with ESMTP id ACBD921F8674 for ; Mon, 29 Oct 2012 08:11:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id 5C6672283D for ; Mon, 29 Oct 2012 16:11:14 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUnqLACMJOUa for ; Mon, 29 Oct 2012 16:11:11 +0100 (CET) Received: from dhcp164-04.enst.fr (dhcp164-04.enst.fr [137.194.165.4]) by zproxy120.enst.fr (Postfix) with ESMTPSA id E5B982281D for ; Mon, 29 Oct 2012 16:11:10 +0100 (CET) From: Luigi Iannone Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <33ECE5C3-6EC2-4A92-8E74-81D6322B1A17@telecom-paristech.fr> Date: Mon, 29 Oct 2012 16:15:24 +0100 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 30 Oct 2012 08:30:40 -0700 Subject: [lisp] Comments on introduction-01 document 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, 29 Oct 2012 15:11:20 -0000 Hi All, hereafter my comments on the introduction-01 document.=20 ciao Luigi Observations valid for the whole document: The use of the term "nodes" is very ambiguous and not coherent with = other LISP documents.=20 Isn't an EID an End-point Identifier? So why starting using "nodes".=20 Further, the text kind of "suggests" that a "node" has one (never = changing) identifier,=20 which is not true in the lisp context. =20 (trivial counter example: a "node" with two interfaces in the same LISP = site=85). I guess this was the same point Paul Vinciguerra was raising in a = different thread. =46rom a communication technology point of view I think we should just = care about the=20 communication end-points that need to be identified and located. =09 There are several acronyms that are not explained, for instance EID and = RLOC. I am not saying we need to put the definition (since it is in the = main spec) but at least what the acronym stands for. This will get the = reader used with the terminology. =20 >=20 >=20 > LISP Working Group J. N. = Chiappa > Internet-Draft Yorktown Museum of Asian = Art > Intended status: Informational July 16, = 2012 > Expires: January 17, 2013 >=20 >=20 > An Introduction to the LISP Location-Identity Separation System > draft-chiappa-lisp-introduction-01 >=20 > Abstract >=20 > 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. Too many details for an abstract in the following text. =20 > 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. >=20 > 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. >=20 I would put the following paragraph as the first in the abstract, so to = make clear right away what this document is all about. (the LISP acronym = should be in spelled out) > This document is an introduction to the entire LISP system, for = those > who are unfamiliar with it. It is intended to be both easy to > follow, and also give a fairly detailed understanding of the entire > system. >=20 [snip] >=20 > 1. Background >=20 > 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. >=20 > The 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] >=20 > 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.) >=20 > 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] >=20 > 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. >=20 > 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] >=20 > 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. [LISP] >=20 > 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. LISP at this point represents a moderately > mature system, having undergone a long organic series of changes = and > updates. >=20 > 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). >=20 > 2. Deployment Philosophy >=20 > 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. >=20 > 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. >=20 > The extreme focus on a viable deployment scheme is one of the > novelties of LISP. >=20 Might be worth citing: http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2012.98 >=20 > 3.1. Basic Approach >=20 > In LISP, nodes have both a 'locator' (a name which says _where_ in > the network's connectivity structure the node is), called an = 'RLOC', > and an 'identifier' (a name which serves only to provide a = persistent > handle for the node), called an 'EID'. A node may have more than = one > RLOC, or its RLOC may change over time (e.g. if the node is = mobile), > but it keeps the same EID. >=20 > Technically, one should probably say that ideally, the EID names = the > node (or rather, its end-end communication stack, if one wants to = be What is exactly an "end-end" communication stack? > as forward-looking as possible), and the RLOC(s) name interface(s). Why?=20 This is true for LISP-MN but not the general architecture. Further, this = can put a wrong understanding in the reader, who will have trouble later = to understand strs, PxTRs, etc. etc. > (At the moment, in reality, the situation is somewhat more complex, > as will be explained elsewhere (in [Architecture], Section > "Namespaces-EIDs-Residual"). >=20 > This second distinction, of _what_ is named by the two classes of > name, is necessary both to enable some of the capabilities that = LISP > provides (e.g the ability to seamlessly support multiple = interfaces, > to different networks), and is also a further enhancement to the > architecture. Faailing typos: Faailing =3D> Failing > to clearly recognize both interfaces and > communication stacks as distinctly separate classes of things is > another failing of the existing Internet architecture (again, one > inherited from the previous generation of networking). >=20 > A novelty in LISP is that it uses existing IPvN addresses = (initially, > at least) for both of these kinds of names, thereby minimizing the > deployment cost, as well as providing the ability to easily = interact > with unmodified hosts and routers. >=20 > 3.2. Basic Functionality >=20 > The basic operation of LISP, as it currently stands, is that LISP > augmented packet switches near the source and destination of = packets > intercept traffic, and 'enhance' the packets. >=20 I am not sure whether 'enhance' is the right word, what about = 'extends'?? > The LISP device near the source looks up additional information = about > the destination, and then wraps the packet in an outer header, one > which contains some of that additional information. The LISP device > near the destination removes that header, leaving the original, > unmodified, packet to be processed by the destination node. >=20 > The LISP device near the source (the Ingress Tunnel Router, or = 'ITR') > uses the information originally in the packet about the identity of > its ultimate destination, i.e. the destination address, which one = can > view as the EID of the ultimate destination. It uses the = destination > EID to look up the current location (the RLOC) of that EID. >=20 > The lookup is performed through a 'mapping system', which is the > heart of LISP: it is a distributed directory of bindings from EIDs = to > RLOCS. The destination RLOC will be (initially at least) the = address > of the LISP device near the destination (the Egress Tunnel Router, = or > 'ETR'). >=20 > The ITR then generates a new outer header for the original packet, > with that header containing the destination's RLOC as the wrapped > packet's destination, and the ITR's own address (i.e. the RLOC of = the > original source) Here it is introduced the concept that ITRs are locators for the source = IED but is not explicitly spelled out. Why not making it more clear? > as the wrapped packet's source, and sends it off. >=20 > When the packet gets to the ETR, that outer header is stripped off, > and the original packet is forwarded to the original ultimate > destination for normal processing. >=20 > Return traffic is handled similarly, often (depending on the > network's configuration) with the original ITR and ETR switching > roles. The ETR and ITR functionality is usually co-located in a > single device; these are normally denominated as 'xTRs'. >=20 [snip] >=20 > 4.1. Provider Independence >=20 > Provider independence (i.e. the ability to easily change one's > Internet Service Provider) was probably the first place where the > Internet engineering community finally really felt the utility of > separating location and identity. >=20 > The problem is simple: for the global routing to scale, addresses > need to be aggregated (i.e. things which are close in the overall > network's connectivity need to have closely related addresses), the > so-called "provider aggregated" addresses. [RFC4116] However, if I am not a native english speaker, but I find this citation format = (sentence period and then citation) a bit confusing.=20 I would prefer:=20 "provider aggregated" addresses = [RFC4116]. However, if =20 or: "provider aggregated" addresses = ([RFC4116]). However, if =85 but it is just style... > this principle is followed, it means that when an entity switches > providers (i.e. it moves to a different 'place' in the network), it > has to renumber, a painful undertaking. [RFC5887] >=20 > In theory, it ought to be possible to update the DNS entries, and > have everyone switch to the new addresses, but in practise, = addresses > are embedded in many places, such as firewall configurations at = other > sites. >=20 > Having separate namespaces for location and identity greatly = reduces > the problems involved with renumbering; an organization which moves > retains its EIDs (which are how most other parties refer to its > nodes), but is allocated new RLOCs, and the mapping system can > quickly provide the updated binding from the EIDs to the new RLOCs. >=20 > 4.2. Multi-Homing >=20 > Multi-homing is another place where the value of separation of > location and identity became apparent. There are several different > sub-flavours of the multi-homing problem - e.g. depending on = whether > one wants open connections to keep working, etc - and other axes as > well (e.g. site multi-homing versus host multi-homing). >=20 > In particular, for the 'keep open connections up' case, without > separation of location and identity, the only currently feasible > approach is to use provider-independent addressses - which moves = the > problem into the global routing system, with attendant costs. This > approach is also not really feasible for host multi-homing. >=20 > Multi-homing was once somewhat esoteric, but a number of trends are > driving an increased desirability, e.g. the wish to have multiple = ISP > links to a site for robustness; the desire to have mobile handsets > connect up to multiple wireless systems; etc. >=20 > Again, separation of location and identity, and the existince of a > binding layer which can be updated fairly quickly, as provided by > LISP, is a very useful tool for all variants of this issue. >=20 > 4.3. Traffic Engineering >=20 > Traffic engineering (TE) [RFC3272], desirable though this = capability > is in a global network, is currently somewhat problematic to = provide > in the Internet. The problem, fundamentally, is that this = capability > was not visualized when the Internet was designed, so support for = it > is somewhat in the 'when the only tool you have is a hammer, > everything looks like nail' category. >=20 > TE is, fundamentally, a routing issue. However, the current = Internet > routing architecture, which is basically the Baran design of fifty > years ago [Baran] (a single large, distributed computationa), is = ill- > suited to provide TE. The Internet seems a long way from adopting a > more-advanced routing architecture, although the basic concepts for > such have been known for some time. [RFC1992] >=20 > Although the identity-location binding layer is thus a poor place, > architecturally, to provide TE capabilities, it is still an > improvement over the current routing tools available for this = purpose > (e.g. injection of more-specific routes into the global routing > table). In addition, instead of the entire network incurring the > costs (through the routing system overhead), when using a binding > layer to provide TE, the overhead is limited to those who are > actually communicating with that particular destination. >=20 > LISP includes a number of features in the mapping system to support > TE. (Described in Section 5.2 below.) >=20 > 4.4. Mobility >=20 > Mobility is yet another place where separation of location and > identity is obviously a key part of a clean, efficient and high- > functionality solution. Considerable experimentation has been > completed on doing mobility with LISP. >=20 > 4.5. IP Version Reciprocal Traversal >=20 Wouldn't be better to make this section more general? With the LCAF doc = we can intermix more than v4 and v6. > Note that LISP 'automagically' allows intermixing of various IP > versions for packet carriage; IPv4 packets might well be carried in > IPv6, or vice versa, depending on the network's configuration. This > would allow an 'island' of operation of one type to be > 'automatically' tunneled over a stretch of infrastucture which only > supports the other type. >=20 > While the machinery of LISP may seem too heavyweight to be good for > such a mundane use, this is not intended as a 'sole use' case for > deployment of LISP. Rather, it is something which, if LISP is being > deployed anyway (for its other advantages), is an added benefit = that > one gets 'for free'. >=20 > 4.6. Local Uses >=20 > LISP has a number of use cases which are within purely local > contexts, i.e. not in the larger Internet. These fall into two > categories: uses seen on the Internet (above), but here on a = private > (and usually small scale) setting; and applications which do not = have > a direct analog in the larger Internet, and which apply only to = local > deployments. >=20 > Among the former are multi-homing, IP version traversal, and = support > of VPN's for segmentation and multi-tenancy (i.e. a spatially > separated private VPN whose components are joined together using = the > public Internet as a backbone). >=20 > Among the latter class, non-Internet applications which have no > analog on the Internet, are the following example applications: > virtual machine mobility in data centers; other non-IP EID types = such > as local network MAC addresses, or application specific data. >=20 > 5. Major Functional Subsystems >=20 > LISP has only two major functional subsystems - the collection of > LISP packet switches (the xTRs), and the mapping system, which > manages the mapping database. The purpose and operation of each is > described at a high level below, and then, later on, in a fair = amount > of detail, in separate sections on each (Sections Section 8 and > Section 9, respectively). >=20 > 5.1. xTRs >=20 > xTRs are fairly normal packet switches, enhanced with a little = extra > functionality in both the data and control planes, to perform LISP > data and control functionality. >=20 > The data plane functions in ITRs include deciding which packets = need > to be given LISP processing (since packets to non-LISP sites may be > sent 'vanilla'); looking up the mapping; encapsulating the packet; > and sending it to the ETR. This encapsulation is done using UDP > [RFC768] (for reasons to be explained below, in Section 8.2), along > with an additional IPvN header (to hold the asource typo: asource =3D> source > and destination > RLOCs). To the extent that traffic engineering features are in use > for a particular EID, the ITRs implement them as well. >=20 > In the ETR, the data plane simply unwraps the packets, and forwards > the 'vanilla' packets to the ultimate destination. >=20 > Control plane functions in ITRs include: asking for {EID->RLOC} > mappings via Map-Request control messages; handling the returning > Map-Replies which contain the requested information; managing the > local cache of mappings; checking for the reachability and liveness > of their neighbour ETRs; and checking for outdated mappings and > requesting updates. >=20 > In the ETR, control plane functions include participating in the > neighbour reachability and liveness function (see Section 12.4); > interacting with the mapping indexing system (next section); and > answering requests for mappings (ditto). >=20 > 5.2. Mapping System >=20 > The mapping database is a distributed, and potentially replicated, > database which holds bindings between EIDs (identity) and RLOCs > (location). To be exact, it contains bindings between EID blocks = and > RLOCs (the block size is given explicitly, as part of the syntax). >=20 > Support for blocks is both for minimizing the administrative > configuration overhead, as well as for operational efficiency; e.g. > when a group of EIDs are behind a single xTR. >=20 > However, the block may be (and often is) Why often? Looking at the lisp4.net I do not see that many mappings for = /32 or /128 =85...=20 > as small as a single EID. > Since mappings are only loaded upon demand, if smaller blocks = become > predominant, then the increased size of the overall database is far > less problematic than if the routing table came to be dominated by > such small entries. >=20 > A particular node may have more than one RLOC, or may change its > RLOC(s), while keeping its singlar typo: singlar =3D> singular > identity. >=20 > The binding contains not just the RLOC(s), but also (for each RLOC > for any given EID) priority and weight (to allow allocation of load > between several RLOCs at a given priority); this allows a certain > amount of traffic engineering to be accomplished with LISP. >=20 > 5.2.1. Mapping System Organization >=20 > The mapping system is actually split into two major functional sub- > systems. The actual bindings themselves are held by the ETRs, and = an > ITR which needs a binding effectively gets it from the ETR. >=20 > This co-location of the authoritative version of the mappings, and > the forwarding functionality which it describes, is an instance of > fate-sharing. [Clark] >=20 > To find the appropriate ETR(s) to query for the mapping, the second > subsystem, an 'indexing system', itself also a distributed, > potentally replicated database, provides information on which = ETR(s) > are authoritative sources of information about the bindings which = are > available. >=20 > 5.2.2. Interface to the Mapping System >=20 > The client interface to the mapping system from an ITR's point of > view is not with the indexing system directly; rather, it is = through > devices called Map Resolvers (MRs). >=20 > ITRs send request control messages (Map-Request packets) to an MR. > (This interface is probably the most important standardized = interface > in LISP - it is the key to the entire system.) The MR uses the > indexing system to eventually forward the Map-Request to the > appropriate ETR. The ETR formulates reply control messages (Map- > Reply packets), which is conveyed to the ITR. The details of the > indexing system, etc, are thus hidden from the 'ordinary' ITRs. >=20 > Similarly, the client interface to the indexing system from an = ETR's > point of view is through devices called Map Servers (MSs - = admittedly > a poorly chosen term, but it's too late to change it now). >=20 > ETRs send registration control messages (Map-Register packets) to = an > MS, which makes the information about the mappings which the ETR > indicates it is authoritative for available to the indexing system. > The MS formulates a reply control message (the Map-Notify packet), > which confirms the registration, and is returned to the ETR. The > details of the indexing system are thus likewise hidden from the > 'ordinary' ETRs. >=20 > 5.2.3. Indexing Subsystem >=20 > The current indexing system There is always a current mapping system, what about putting "At the = time of this writing..."??? > is called the Delegated Database Tree > (DDT), which is very similar in operation to DNS. [DDT], [RFC1034] > However, unlike DNS, the actual mappings are not handled by DDT; = DDT > merely identifies the ETRs which hold the mappings. >=20 > Again, extensive large-scale simulations driven by lengthy = recordings > of actual traffic at several major sites, have been performed to > verify the effectiveness of this particular indexing system. = [Jakab] >=20 > 6. Examples of Operation >=20 > To aid in comprehension, a few examples are given of user packets > traversing the LISP system. The first shows the processing of a > typical user packet, i.e. what the vast majority of user packets = will > see. The second shows what happens when the first packet to a > previously-unseen destination (at a particular ITR) is to be > processed by LISP. >=20 > 6.1. An Ordinary Packet's Processing >=20 > This case follows the processing of a typical user packet (for > instance, a normal TCP data or acknowledgment packet associated = with > an open HTTP connection) as it makes its way from the source host = to > the destination. >=20 > {{Rest to be written.}} >=20 > 6.2. A Mapping Cache Miss >=20 Wouldn't be better to have a general section about LISP Cache = operations???? (Then the cache miss will be just a sub-section) > If a host sends a packet, and it gets to the ITR, and the ITR both = i) > determines that it needs to perform LISP processing on the user = data > packet, but ii) does not yet have a mapping cache entry which = covers > that destination EID, then more complex processing ensues. >=20 > {{Rest to be written.}} >=20 > 7. Design Approach >=20 > Before describing LISP's components in more detail below, it may be > worth saying a few words about the design philosophy used in = creating > them - this may make clearer the reasons for some engineering = choices > in the mechanisms given there. >=20 > 7.1. Quick Implement-Test Loop >=20 > LISP uses a philosophy similar to that used in the early days of = the > Internet, which is to just build it, then try it and see what > happens, and move forward from there based on what actually = happens. > The concept has been to get something up and running, and then = modify > it based on testing and experience. >=20 > 7.1.1. No Desk Fixes >=20 > Don't try and forsee all issues from desk analysis. (Which is not = to > say that one should not spend _some_ time on trying to forsee > problems, but be aware that it is a 'diminishing returns' process.) > The performance of very large, complex, physically distributed > systems is hard to predict, so rather than try (which would > necessarily be an incomplete exercise anyway, testing would > inevitably be required eventually), at a certain point it's better > just to get on with it - and you will learn a host of other lessons > in the process, too. >=20 > 7.1.2. Code Before Documentation >=20 > This is often a corollary to the kind of style described above. > While it probably would not have been possible in a large, > inhomogenous group, the small, close Why close? Everybody can implement LISP and provide feedback=85. > nature of the LISP > implementation group did allow this approach. >=20 > 7.2. Only Fix Real Problems >=20 > Don't worry about anything unless experience show it's a real > problem. For instance, in the early stages, much was made out of = the > problem of 'what does an ITR do if it gets a packet, but does not > (yet) have a mapping for the destination?' >=20 > In practise, simply dropping such packets has just not proved to be = a > problem; the higher level protocol will retransmit them after a > timeout, and the mapping is usually in place by then. So spending a > lot of time (and its companion, energy) and mechanism (and _its_ > extremely undesirable companion, complexity) on solving this > 'problem' would not have been the most efficient approach, overall. >=20 > 7.3. No Theoretical Perfection >=20 > Attack hard problems with a number of cheap and simple mechanisms > that co-operate and overlap. Trying to find a single mechanism that > is all of: >=20 > - Robust > - Efficient > - Fast >=20 > is often (usually?) a fool's errand. (The analogy to the aphorism > 'Fast, Cheap, Good - Pick Any Two' should be obvious.) However, a > collection of simple and cheap mechanisms may effectively be able = to > meet all of these goals (see, for example, ETR = Liveness/Reachability, > Section 12.4). >=20 > Yes, this results in a system which is not provably correct in all > circumstances. The world, however, is full of such systems - and in > the real world, effective robustness is more likely to result from > having multiple, overlapping mechanisms than one single = high-powered > (and inevitably complex) one. In the world of civil engineering, > redundancy is now accepted as a key design principle; the same = should > be true of information systems. [Salvadori] >=20 > 7.3.1. No Ocean Boiling >=20 > Don't boil the ocean to kill a single fish. This is a combination = of > 7.2 (Only Fix Real Problems) and 7.3 (No Theoretical Perfection); = it > just means that spending a lot of complexity and/or overhead to = deal > with a problem that's not really a problem is not good engineering. >=20 Any direct reference to LISP? > 7.4. Just Enough Security >=20 > How much security to have is a complex issue. It's relatively easy > for designers to add good security, but much harder to get the = users > to jump over all the hoops necessary to use it. LISP has therefore > adopted a position where we add 'just enough' security. >=20 > The overall approach to security in LISP is fairly subtle, though, > and is covered in more detail elsewhere While I agree on this sentence, I would add a paragraph just to give = some information on the security level of LISP, otherwise the section = summarises in: "is complicate so we talk about it elsewhere". Clearly = not really satisfactory. > (in [Architecture], Section > "Security"). >=20 > 8. xTRs >=20 > As mentioned above (in Section 5.1), xTRs are the basic = data-handling > devices in LISP. This section explores some advanced topics related > to xTRs. >=20 > Careful rules have been specified for both TTL and ECN [RFC3168] to > ensure that passage through xTRs does not interfere with the > operation of these mechanisms. In addition, care has been taken to > ensure that 'traceroute' works when xTRs are involved. >=20 > 8.1. When to Encapsulate >=20 > An ITR knows that a destination is running LISP, and thus that it > should perform LISP processing on a packet (including potential > encapsulation) if it has an entry in its local mapping cache that > covers the destination EID. >=20 > Conversely, if the cache contains a 'negative' entry (indicating = that > the ITR has previously attempted to find a mapping that covers this > EID, and it has been informed by the mapping system that no such > mapping exists), it knows the destination is not running LISP, and > the packet can be forwarded normally. >=20 Shouldn't be stated that is there is nothing in the cache then the ITR = knows nothing and has to query the mapping system. What to do with the = packet is implementation dependent (with current practice being = dropping). > (The ITR cannot simply depend on the appearance, or non-appearance, > of the destination in the DFZ routing tables, as a way to tell if a > destination is a LISP site or not, because mechanisms to allow > interoperation of LISP sites and 'legacy' sites necessarily involve > advertising LISP sites' EIDs into the DFZ.) >=20 > 8.2. UDP Encapsulation Details I would rename this section "UDP Encapsulation Rationale". There are no = details on the encapsulation itself, just explanation on why UDP=85. >=20 > The UDP encapsulation used by LISP for carrying traffic from ITR to > ETR, and many of the details of how the it works, were all chosen = for > very practical reasons. >=20 > Use of UDP (instead of, say, a LISP-specific protocol number) was > driven by the fact that many devices filter out 'unknown' = protocols, > so adopting a non-UDP encapsulation would have made the initial > deployment of LISP harder - and our goal (see Section 2.1) was to > make the deployment as easy as possible. >=20 > The UDP source port in the encapsulated packet is a hash of the > original source and destination; this is because many ISPs use > multiple parallel paths (so-called 'Equal Cost Multi-Path'), and > load-share across them. Using such a hash in the source-port in the > outer header both allows LISP traffic to be load-shared, and also > ensures that packets from individual connections are delivered in > order (since most ISPs try to ensure that packets for a particular > {source, source port, destination, destination port} tuple flow = along > a single path, and do not become disordered).. >=20 > The UDP checksum is zero because the inner packet usually already = has > a end-end checksum, and the outer checksum adds no value. [Saltzer] > In most exising hardware, computing such a checksum (and checking = it > at the other end) would also present an intolerable load, for no > benefit. >=20 > 8.3. Header Control Channel >=20 > LISP provides a multiplexed channel in the encapsulation header. It > is mostly (but not entirely) used for control purposes. (See > [Architecture], Section "Architecture-Piggyback" for a longer > discussion of the architectural implications of this.) >=20 > The general concept is that the header starts with an 8-bit 'flags' > field, and it also includes two data fields (one 24 bits, one 32), > the contents and meaning of which vary, depending on which flags = are > set. This allows these fields to be 'multiplexed' among a number of > different low-duty-cycle functions, while minimizing the space > overhead of the LISP encapsulation header. >=20 > 8.3.1. Echo Nonces >=20 > One important use is for a mechanism known as the Nonce Echo, which > is used as an efficient method for ITRs to check the reachability = of > correspondent ETRs. >=20 > Basically, an ITR which wishes to ensure that an ETR is up, and > reachable, sends a nonce to that ETR, carried in the encapsulation > header; when that ETR (acting as an ITR) sends some other user data > packet back to the ITR (acting in turn as an ETR), that nonce is > carried in the header of that packet, allowing the original ITR to > confirm that its packets are reaching that ETR. >=20 > Note that lack of a response is not necessarily _proof_ that > something has gone wrong - but it stronly suggests that something > has, so other actions (e.g. a switch to an alternative ETR, if one = is > listed; a direct probe; etc) are advised. >=20 > (See Section 12.5 for more about Echo Nonces.) >=20 > 8.3.2. Instances >=20 > Another use of these header fields is for 'Instances' - basically, > support for VPN's across backbones. [RFC4026] Since there is only > one destination UDP port used for carriage of user data packets, = and > the source port is used for multiplexing (above), there is no other > way to differentiate among different destination address namespaces > (which are often overlapped in VPNs). >=20 > 8.4. Fragmentation I would rename this section "Maximum Transmission Unit", and add some = clarification on why there is this issue in the first paragraph. >=20 > Several mechanisms have been proposed for dealing with packets = which > are too large to transit the path from a particular ITR to a given > ETR. >=20 > One, called the 'stateful' approach, keeps a per-ETR record of the > maximum size allowed, and sends an ICMP Too Big message to the > original source host when a packet which is too large is seen. >=20 > In the other, referred to as the 'stateless' approach, for IPv4 > packets without the 'DF' bit set, too-large packets are fragmented, > and then the fragments are forwarded; all other packets are > discarded, and an ICMP Too Big message returned. >=20 > It is not clear at this point which approach is preferable. >=20 > 8.5. Mapping Gleaning in ETRs >=20 > As an optimization to the mapping acquisition process, ETRs are > allowed to 'glean' mappings from incoming user data packets, and = also > from incoming Map-Request control messages. Let's be pedantic and add how this is done! > This is not secure, and > so any such mapping must be 'verified' by sending a Map-Request to > get an authoritative mapping. (See further discussion of the > security implications of this in [Architecture], Section "Security- > xTRs".) >=20 > The value of gleaning is that most communications are two-way, and = so > if host A is sending packets to host B (therefore needing B's > EID->RLOC mapping), very likely B will soon be sending packets back > to A (and thus needing A's EID->RLOC mapping). Without gleaning, > this would sometimes result in a delay, and the dropping of the = first > return packet; this is felt to be very undesirable. IMHO this last sentence is not coherent with what was written a couple = of pages before where first packet drop was not an issue at all.=20 Gleaning is a (big) security issue so we have a trade off here: lower = performance but (much) higher security.=20 I would change the sentence. >=20 > 9. The Mapping System >=20 > RFC 1034 ("DNS Concepts and Facilities") has this to say about the > DNS name to IP address mapping system: >=20 > "The sheer size of the database and frequency of updates suggest > that it must be maintained in a distributed manner, with local > caching to improve performance. Approaches that attempt to > collect a consistent copy of the entire database will become more > and more expensive and difficult, and hence should be avoided." >=20 > and this observation applies equally to the LISP mapping system. >=20 > As previously mentioned, the mapping system is split into an = indexing > subsystem, which keeps track of where all the mappings are kept, = and > the mappings themsleves, typo: themsleves =3D> themselves > the authoritative copies of which are always > held by ETRs. >=20 > 9.1. The Indexing Subsystem >=20 > The indexing system in LISP is currently implemented by the DDT > system. LISP initially used (for ease of getting something > operational without having to write a lot of code) an indexing = system > called ALT, which used BGP running over virtual tunnels. [ALT] This > proved to have a number of issues, and has now been superseded by > DDT. What do you thing about adding a small paragraph of why ALT had issues? >=20 > In DDT, the EID namespace(s) are instantiated as a tree of DDT = nodes. > Starting with the root node(s), which have 'reponsibility' for the > entire namespace, portions of the namespace are delegated to child > nodes, in a recursive process extending through as many levels as = are > needed. Eventually, leaf nodes in the DDT tree delegate namespace > blocks to ETRs. >=20 > MRs obtain information about delegations by interrogating DDT = nodes, > and caching the results. aThis typo: aThis =3D> This > allows them, when passed a request for > a mapping by an ITR, to forward the mapping request to the > appropriate ETR (perhaps after loading some missing delegation > entries into their delegation cache). >=20 > 9.2. The Mapping System Interface >=20 > As mentioned in Section 5.2.2, both of the inferfaces to the = mapping > system (from ITRs, and ETRs) are standardized, so that the more > numerous xTRs do not have to be modified when the mapping indexing > system is changed. This precaution has already allowed the mapping > system to be upgraded during LISP's evolution, when ALT was = replaced > by DDT. >=20 > This section describes the interfaces in a little more detail. >=20 > 9.2.1. Map-Request Messages >=20 > The Map-Request message contains a number of fields, the two most > important of which are the requested EID block identifier (remember > that individual mappings may cover a block of EIDs, not just a = single > EID), and the Address Family Identifier (AFI) for that EID block. > [AFI] The inclusion of the AFI allows the mapping system interface > (as embodied in these control packets) a great deal of flexibility. > (See [Architecture], Section "Namespaces" for more on this.) >=20 > Other important fields are the source EID (and its AFI), and one or > more RLOCs for the source EID, along with their AFIs. Multiple = RLOCs > are included to ensure that at least one is in a form which will > allow the reply to be returned to the requesting ITR, and the = source > EID is used for a variety of functions, including 'gleaning' (see > Section 8.5). >=20 > Finally, the message includes a long nonce, for simple, efficient > protection against offpath attackers (see [Architecture], Section > "Security-xTRs" for more), and a variety of other fields and = control > flag bits. >=20 > 9.2.2. Map-Reply Maessages typo: Maessages =3D> Messages >=20 > The Map-Reply message looks similar, except it includes the mapping > entry for the requested EID(s), which contains one or more RLOCs = and > their associated data. (Note that the reply may cover a larger = block > of the EID namespace than the request; most requests will be for a > single EID, the one which prompted the query.) >=20 > For each RLOC in the entry, there is the RLOC, its AFI (of course), > priority and weight fields (see Section 5.2), and multicast = priority > and weight fields. >=20 > 9.2.3. Map-Register and Map-Notify Messages >=20 > The Map-Register message contains authentication information, and a > number of mapping records, each with an individual Time-To-Live > (TTL). Each of the records contains an EID (potentially, a block of > EIDs) and its AFI, a version number for this mapping (see > Section 11.1), and a number of RLOCs and their AFIs. >=20 > Each RLOC entry also includes the same data as in the Map-Replies > (i.e. priority and weight); this is because in some circumstances = it > is advantageous to allow the MS to proxy reply on the ETR's behalf = to > Map-Request messages. [Mobility] >=20 > Map-Notify messages have the exact same contents as Map-Register > messages; they are purely acknowledgements. >=20 > 9.2.4. Map-Referral Messages >=20 > Map-Referral messages look almost identical to Map-Reply messages > (which is felt to be an advantage by some people, although having a > more generic record-based format would probably be better in the = long > run, as ample experience with DNS has shown), except that the RLOCs > potentially name either i) other DDT nodes (children in the > delegation tree), or ii) terminal MSs. >=20 > There are also optional authentication fields; see [Architecture], > Section "Security-Mappings" for more. >=20 > 9.3. Reliability via Replication >=20 > Everywhere throughout the mapping system, robustness to operational > failures is obtained by replicating data in multiple instances of = any > particular node (of whatever type). Map-Resolvers, Map-Servers, DDT > nodes, ETRs - all of them can be replicated, and the protocol > supports this replication. >=20 > There are generally no mechanisms specified yet to ensure coherence > between multiple copies of any particular data item, etc - this is > currently a manual responsibility. If and when LISP protocol > adoption proceeds, an automated layer to perform this functionality > can 'easily' be layered on top of the existing mechanisms. >=20 > 9.4. Extended Tools >=20 > In addition to the priority and weight data items in mappings, LISP > offers other tools to enhance functionality, particularly in the > traffic engineering area. One are 'source-specific mappings', i.e. > the ETR may return different mappings to the enquiring ITR, = depending > on the identity of the ITR. This allows very fine-tuned traffic > engineering, far more powerful than routing-based TE. >=20 > 9.5. Expected Performance >=20 > {{To be written.}} What will be exactly the content of this section? The performance of = DDT? If yes, this should be in the title. On the other side this is a = general introduction on LISP do we need to write about the DDT = performance specifically? >=20 > 10. Deployment Mechanisms >=20 > This section discusses several deployment issues in more detail. > With LISP's heavy emphasis on practicality, much work has gone into > making sure it works well in the real-world environments most = people > have to deal with. >=20 > 10.1. Internetworking Mechanism >=20 > One aspect which has received a lot of attention are the mechanisms > previously referred to (in Section 3.4) to allow interoperation of > LISP sites with so-called 'legacy' sites which are not running LISP > (yet). >=20 > To briefly refresh what was said there, there are two main = approaches > to such interworking: proxy nodes (PITRs and PETRs), and an > alternative mechanism using device with combined NAT and LISP > functionality; these are described in more detail here. >=20 > 10.2. Proxy Devices >=20 > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. PETRs (proxy ETRs) serve as ETRs for LISP traffic > _to_ legacy hosts (for cases where a LISP device cannot send = packets > directly to such sites, without encapsulation). >=20 > Note that return traffic _to_ a legacy site from a LISP-using node > does not necessarily have to pass through an ITR/PETR pair - the > original packets can usually just be sent directly to the > destination. However, for some kinds of LISP operation (e.g. mobile > nodes), this is not possible; in these situations, the PETR is > needed. >=20 > 10.2.1. PITRs >=20 > PITRs (proxy ITRs) serve as ITRs for traffic _from_ legacy hosts to > nodes using LISP. To do that, they have to advertise into the > existing legacy backbone Internet routing the availability of > whatever ranges of EIDs (i.e. of nodes using LISP) they are = proxying > for, so that legacy hosts will know where to send traffic to those > LISP nodes. >=20 > As mentioned previously (Section 8.1), an ITR at another LISP site > can avoid using a PITR (i.e. it can detect that a given destination > is not a legacy site, if a PITR is advertising it into the DFZ) by > checking to see if a LISP mapping exists for that destination. >=20 > This technique obviously has an impact on routing table in the DFZ, > but it is not clear yet exactly what that impact will be; it is = very > dependent on the collected details of many individual deployment > decisions. >=20 > A PITR may cover a group of EID blocks with a single EID > advertisement, in order to reduce the number of routing table = entries > added. (In fact, at the moment, aggressive aggregation of EID > announcements is performed, precisely to to minimize the number of > new announced routes added by this technique.) >=20 > At the same time, it a site typo: it =3D> if > does traffic engineering with LISP > instead of fine-grained BGP announcement, that will help keep table > sizes down (and this is true even in the early stages of LISP > deployment). May be cite (might be useful in section 10.4 as well): http://biblio.info.ucl.ac.be/2007/415406.pdf > The same is true for multi-homing. >=20 > 10.2.2. PETRs >=20 > PETRs (proxy ETRs) serve as ETRs for LISP traffic _to_ legacy = hosts, > for cases where a LISP device cannot send packets to sites without > encapsulation. That typically happens for one of two reasons. >=20 > First, it will happen in places where some device is implementing > Unicast Reverse Path Forwarding (uRPF), to prevent a variety of > negative behaviour; originating packets with the source's EID in = the > source address field will result in them being filtered out and > discarded. >=20 > Second, it will happen when a LISP site wishes to send packets to a > non-LISP site, and the path in between does not support the > particular IP protocol version used by the source along its entir > length. Use of a PETR on the other side of the 'gap' will allow the > LISP site's packet to 'hop over' the gap, by utilizing LISP's > built-in support for mixed protocol encapsulation. >=20 > PETRs are generally paired with specific ITRs, which have the > location of their PETRs configured into them. In other words, = unlike > normal ETRS, typo: ETRS =3D> ETRs > PETRs do not have to register themselves in the mapping > database, on behalf of any legacy sites they serve. >=20 > Also, allowing an ITR to always send traffic leaving a site to a = PETR > does avoid having to chose whether or not to encapsulate packets; = it > can just always encapsulate packets, sending them to the PETR if it > has no specific mapping for the destination. However, this is not > advised: as mentioned, it is easy to tell if something is a legacy > destination. >=20 > 10.3. LISP-NAT >=20 > A LISP-NAT device, as previously mentioned, combines LISP and NAT > functionality, in order to allow a LISP site which is internally > using addresses which cannot be globally routed to communicate with > non-LISP sites elsewhere in the Internet. (In other words, the > technique used by the PITR approach simply cannot be used in this > case.) >=20 > To do this, a LISP-NAT performs the usual NAT functionality, and > translates a host's source address(es) in packets passing through = it > from an 'inner' value to an 'outer' value, and storing that > translation in a table, which it can use to similarly process > subsequent packets (both outgoing and incoming). [Interworking] >=20 > There are two main cases where this might apply: > - Sites using non-routable global addresses > - Sites using private addresses [RFC1918] >=20 > 10.4. LISP and DFZ Routing >=20 > {{To be written.}} >=20 > 10.5. Use Through NAT Devices >=20 > Like them or not (and NAT devices have many egregious issues - some > inherent in the nature of the process of mapping addresses; others, > such as the brittleness due to non-replicated critical state, = caused > by the way NATs were introduced, as stand-alone 'invisible' boxes), > NATs are both ubiquitous, and here to stay for a long time to come. >=20 > Thus, in the actual Internet of today, having any new mechanisms > function well in the presence of NATs (i.e. with LISP xTRs behind a > NAT device) is absolutely necessary. LISP has produced a variety of > mechanisms to do this. >=20 > 10.5.1. First-Phase NAT Support >=20 > The first mechanism used by LISP to operate through a NAT device = only > worked with some NATs, those which were configurable to allow = inbound > packet traffic to reach a configured host. >=20 > A pair of new LISP control messages, LISP Echo-Request and Echo- > Reply, allowed the ETR to discover its temporary global address; = the > Echo-Request was sent to the configured Map-Server, and it replied > with an Echo-Reply which included the source address from which the > Echo Request was received (i.e. the public global address assigned = to > the ETR by the NAT). The ETR could then insert that address in any > Map-Reply control messages which it sent to correspondent ITRs. >=20 > The fact that this mechanism did not support all NATs, and also > required manual configuration of the NAT, meant that this was not a > good solution; in addition, since LISP expects all incoming data > traffic to be on a specific port, it was not possible to have > multiple ETRs behind a single NAT (which normally would have only = one > global address to share, meaning port mapping would have to be = used, > except that=85 ) Is something missing here? >=20 > 10.5.2. Second-Phase NAT Support >=20 > For a more comprehensive approach to support of LISP xTR deployment > behind NAT devices, a fairly extensive supplement to LISP, LISP NAT > Traversal, has been designed. [NAT] >=20 > A new class of LISP device, the LISP Re-encapsulating Tunnel Router > (RTR), passes traffic through the NAT, both to and from the xTR. > (Inbound traffic has to go through the RTR as well, since otherwise > multiple xTRs could not operate behind a single NAT, for the > 'specified port' reason in the section above.) >=20 > (Had the Map-Reply included a port number, this could have been > avoided - although of course it would be possible to define a new > RLOC type which included protocol and port, to allow other > encapsulation techniques.) >=20 > Two new LISP control messages (Info-Request and Info-Reply) allow = an > xTR to detect if it is behind a NAT device, and also discover the > global IP address and UDP port assigned by the NAT to the xTR. A > modification to LISP Map-Register control messages allows the xTR = to > initialize mapping state in the NAT, in order to use the RTR. >=20 > This mechanism addresses cases where the xTR is behind a NAT, but = the > xTR's associated MS is on the public side of the NAT; this > limitation, that MS's must be in the 'public' part of the Internet, > seems reasonable. >=20 > 11. Current Improvements >=20 > In line with the philosophies laid out in Section 7, LISP is > something of a moving target. This section discusses some of the > contemporaneous improvements being made to LISP. >=20 > 11.1. Mapping Versioning >=20 > As mentioned, LISP has been under development for a considerable > time. One early addition to LISP (it is already part of the base > specification) is mapping versioning; i.e. the application of > identifying sequence numbers to different versions of a mappping. > [Versioning] This allows an ITR to easily discover when a cached > mapping has been updated by a more recent variant. >=20 > Version numbers are available in control messages (Map-Replies), = but > the initial concept is that to limit control message overhead, the > versioning mechanism should primarily use the multiplex user data > header control channel (see Section 8.3). >=20 > Versioning can operate in both directions: an ITR can advise an ETR > what version of a mapping it is currently using (so the ETR can > notify it if there is a more recent version), and ETRs can let ITRs > know what the current mapping version is (so the ITRs can request = an > update, if their copy is outdated). >=20 > At the moment version numbers are manually assigned, and ordered. > Some felt that this was non-optimal, and that a better approach = would > have been to have 'fingerprints' which were computed from the = current > mapping data (i.e. a hash). It is not clear that the ordering buys > much (if anything), and the potential for mishaps with manually > configured version numbers is self-evident. >=20 I remember the discussion. Fingerprint does not give you the notion of = "freshness". If you do not have an ordering in the version numbers = (whatever ordering) you cannot say whether a mapping is "newer" or = "older" you can just state "it's different" but for the you can already = use the nonce. > 11.2. Replacement of ALT with DDT >=20 > As mentioned in Section 9.2, an interface is provided to allow > replacement of the indexing subsystem. LISP initially used an > indexing system called ALT. [ALT] ALT was relatively easy to > construct from existing tools (GRE, BGP, etc), but it had a number = of > issues that made it unsuitable for large-scale use. ALT is now = being > superseded by DDT. >=20 > As indicated previously (Section 9.5), the basic structure and > operation of DDT is identical to that of TREE, so the extensive > simulation work done for TREE applies equally to DDT, as do the > conclusions drawn about TREE's superiority to ALT. [Jakab] >=20 > {{Briefly synopsize results}} >=20 > 11.2.1. Why Not Use DNS >=20 > One obvious question is 'Since DDT is so similar to DNS, why not > simply use DNS?' In particular, people are familiar with the DNS, > how to configure it, etc - would it not thus be preferable to use = it? > To completely answer this would take more space that available = here, > but, briefly, there were two main reasons, and one lesser one. >=20 > First, the syntax of DNS names did not lend itself to looking up > names in other syntaxes (e.g. bit fields). This is a problem which > has been previously encountered, e.g. in reverse address lookups. > [RFC5855] >=20 > Second, as an existing system, the interfaces between DNS (should = it > have been used as an indexing subsystem for LISP) would not be > 'tuneable' to be optimal for LISP. For instance, if it were desired > to have the leaf node in an indexing lookup directly contact the = ETR > on behalf of the node doing the lookup (thereby avoiding a = round-trip > delay), that would not be easy without modifications to the DNS = code. > Obviously, with a 'custom' system, this issue does not arise. >=20 > Finally, DNS security, while robust, is fairly complex. Doing DDT > offered an opportunity to provide a more nuanced security model. > (See [Architecture], Section "Security" for more about this.) >=20 > 11.3. Mobile Device Support >=20 > Mobility is an obvious capability to provide with LISP. Doing so is > relatively simple, if the mobile host is prepared to act as its own > ETR. Shouldn't be xTR? > It obtains a local 'temporary use' address, and registers that > address as its RLOC. Packets to the mobile host are sent to its > temporary address, whereever that may be, and the mobile host first > unwraps them (acting as an ETR), and the processes them normally > (acting as a host). >=20 > (Doing mobility without having the mobile host act as its ETR is > difficult, even if ETRs are quite common. The reason is that if the > ETR and mobile host are not integrated, during the step from the = ETR > to the mobile host, the packets must contain the mobile host's EID, > and this may not be workable. If there is a local router between = the > ETR and mobile host, for instance, it is unlikely to know how to = get > the packets to the mobile host.) >=20 > If the mobile host migrates to a site which is itself a LISP site, > things get a little more complicated. The 'temporary address' it > gets is itself an EID, requiring mapping, and wrapping for transit > across the rest of the Internet. A 'double encapsulation' is thus > required at the other end; the packets are first encapsulated with > the mobile node's temporary address as their RLOC, and then this = has > to be looked up in a second lookup cycle (see Section 8.1), and = then > wrapped again, with the site's RLOC as their destination. >=20 > This results in slight loss in maximum packet size, due to the > duplicated headers, but on the whole it is considerably simpler = than > the alternative, which would be to re-wrap the packet at the site's > ETR, when it is discovered that the destination's EID was not > 'native' to the site. This would require that the mobile node's EID > effectively have two different mappings, depending on whether the > lookup was being performed outside the LISP site, or inside. >=20 > {{Also probably need to mention briefly how the other end is = notified > when mappings are updated, and about proxy-Map-Replies.}} = [Mobility] >=20 > 11.4. Multicast Support >=20 > Multicast may seem an odd thing to support with LISP, since LISP is > all about separating identity from location, but although a = multicast > group in some sense has an identity, it certainly does not have _a_ > location. >=20 > However, multicast is important to some users of the network, for a > number of reasons: doing multiple unicast streams is inefficient; = it > is easy to use up all the upstream bandwidth, and without multicast = a > server can also be saturated fairly easily in doing the unicast > replication. So it is important for LISP to 'play nicely' with > multicast; work on multicast support in LISP is fairly advanced, > although not far-ranging. >=20 > Briefly, destination group addresses are not mapped; only the = source > address (when the source is inside a LISP site) needs to be mapped, > both during distribution tree setup, as well as actual traffic > delivery. In other words, LISP's mapping capability isa typo: isa =3D> is > used: it is > just applied to the source, not the destination (as with most LISP > activity); the inner source is the EID, and the outer source is the > EID's RLOC. >=20 > Note that this does mean that if the group is using separate = source- > specific trees for distribution, there isn't a separate = distribution > tree outside the LISP site for each different source of traffic to > the group from inside the LISP site; they are all lumped together > under a single source, the RLOC. >=20 > The approach currently used by LISP requires no packet format = changes > to existing multicast protocols. See [Multicast] for more; > additional LISP multicast issues are discussed in [LISP], Section = 12. >=20 > 11.5. {{Any others?}} LCAF? >=20 > 12. Fault Discovery/Handling >=20 [snip] From vaf@cisco.com Tue Oct 30 12:12:39 2012 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 233A321F84B5 for ; Tue, 30 Oct 2012 12:12:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogkiOOEhALMf for ; Tue, 30 Oct 2012 12:12:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F2B2C21F84A1 for ; Tue, 30 Oct 2012 12:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1027; q=dns/txt; s=iport; t=1351624358; x=1352833958; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=mjbUOXrYjNA/noXbAFZ0yIKqio1M+ZGxQ3lNqysCcvA=; b=Uno6e0PaTFWiB6RyN3m+O83du5779EtJ1eWO19mQ5iEAZS+z7Pzu/qRt GuN24JfDubBKareDGh63VcTIQ8geST0Sp4i4jLRIobINDCTxZCJP4lJqe vF6m+CbtjUKZfKk5l9RTH/q7z+HTiZW8Q8J967VQKJYu8M5o2zfYOQ31R I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALslkFCrRDoI/2dsb2JhbABEw2WBCIIeAQEBAgEBEgEnOgUQC0YUGDEcGYdeBQELnEyPZ5Api3eFfGEDiFmNG4EbjT2Ba4MP X-IronPort-AV: E=Sophos;i="4.80,682,1344211200"; d="scan'208";a="62705020" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 30 Oct 2012 19:12:35 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9UJCZI6002343; Tue, 30 Oct 2012 19:12:35 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 333EF2AE6256; Tue, 30 Oct 2012 12:12:35 -0700 (PDT) Date: Tue, 30 Oct 2012 12:12:35 -0700 From: Vince Fuller To: Luigi Iannone Message-ID: <20121030191235.GA93166@vaf-mac1.cisco.com> References: <33ECE5C3-6EC2-4A92-8E74-81D6322B1A17@telecom-paristech.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33ECE5C3-6EC2-4A92-8E74-81D6322B1A17@telecom-paristech.fr> User-Agent: Mutt/1.4.2.3i Cc: "" Subject: Re: [lisp] Comments on introduction-01 document 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, 30 Oct 2012 19:12:39 -0000 Hi Luigi- Quick follow-up questions/comments: > > 2. Deployment Philosophy ... > > The extreme focus on a viable deployment scheme is one of the > > novelties of LISP. > > > > Might be worth citing: > > http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2012.98 Is this a stable web page, suitable for citation? It is also worth noting that your reference is to a very poorly written abstract for an article that can only be read by paying $19; maybe not best thing to cite in a document that is intended to be an RFC. Is there a more direct reference to a document that discusses the same issues? > > does traffic engineering with LISP > > instead of fine-grained BGP announcement, that will help keep table > > sizes down (and this is true even in the early stages of LISP > > deployment). > > May be cite (might be useful in section 10.4 as well): > > http://biblio.info.ucl.ac.be/2007/415406.pdf Is this also a stable web page, suitable for citation? --Vince From vaf@cisco.com Tue Oct 30 12:22:36 2012 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 0270A21F85C0 for ; Tue, 30 Oct 2012 12:22:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7jzy-z29m9U for ; Tue, 30 Oct 2012 12:22:35 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3987C21F858F for ; Tue, 30 Oct 2012 12:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2787; q=dns/txt; s=iport; t=1351624955; x=1352834555; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=H7oaNjR0AigXiI0xBo/69Oi4JBU12WgAQ/YmCTSJhwo=; b=LZsoA+z7Y1Yp8eREVkAGpeCVgZtL6pFgnBEQGF5IA6HeOcWCLSDeNgQv X63I61Gu1ScPgP0sHYU2SWcXYDVBgNU/oZuzUbp21bBHAdWkz2zSuV2kb 9epuBrF7wlrDnQPEPFzCUYM70cgMEw85j6OW+a10oMg8UGb/RtdwizTwD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADkokFCrRDoH/2dsb2JhbABEw2WBCIIeAQEBAgEBEgEnPwULCw4ENBQYHRQcGYdeBQELnE+PZ5ApkXNhA4hZjRuBG409gWuDDw X-IronPort-AV: E=Sophos;i="4.80,682,1344211200"; d="scan'208";a="59601895" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 30 Oct 2012 19:22:31 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9UJMVUt019856; Tue, 30 Oct 2012 19:22:31 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 93F222AE6630; Tue, 30 Oct 2012 12:22:31 -0700 (PDT) Date: Tue, 30 Oct 2012 12:22:31 -0700 From: Vince Fuller To: Luigi Iannone Message-ID: <20121030192231.GB93166@vaf-mac1.cisco.com> References: <617C965F-F20A-4F5E-B8DB-9F8A0BB1583B@gigix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <617C965F-F20A-4F5E-B8DB-9F8A0BB1583B@gigix.net> User-Agent: Mutt/1.4.2.3i Cc: "" Subject: Re: [lisp] Comments on lisp-architecture-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, 30 Oct 2012 19:22:36 -0000 Hi Luigi- Same comments/concerns about the citations you offer here. Specifically: > May I suggest: > > http://biblio.info.ucl.ac.be/2007/415406.pdf want to make sure that this is a stable document to reference (i.e. it will be around on that web site for many years to come) > You can cite: > > http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf > http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf same comment as above. > On this point you can cite: > > http://www.computer.org/csdl/mags/ic/preprint/mic2012990288-abs.html This is the same reference you offered for "lisp-introduction-01". At a minimum, that abstract needs to be re-written so that it makes sense. Right now, it says: The Internet has been created for interconnecting few hundreds networks, but is now close to one billion hosts, grouped in 40,000 Autonomous Systems, using more than 400,000 prefixes. Such a situation raises scalability issues that have driven both academia and industry to review the current Internet Architecture in the light of the Locator/Identifier Split paradigm. In particular, the Internet Engineering Task Force (IETF) has adopted and is actively designing and developing the Locator/ID Separation Protocol (LISP). However, changing the routing and addressing architecture of the Internet in an incrementally deployable manner Several constraints impact such a design. We use LISP as reference to describe the different design choices necessary to achieve deployability, which is the ultimate goal of any new Future Internet architecture. Furthermore, we showcase several alternate usages of LISP, which go beyond improving the Internet scalability. I realize that you are not a native English speaker but this text, especially the sentence fragment that begins "However, changing the routing...", is so badly written as to be almost unreadable. I also reiterate my concern that a citation that points to this web page 1) may not be stable and 2) is to an abstract for a document that one needs to pay to download. > You can cite: > > http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf > http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf same question/comment as my first regarding stability. > In this case this paper might be useful: > > http://inl.info.ucl.ac.be/system/files/Networking12-CRV.pdf same question/comment as my first regarding stability. I don't doubt that the materials you have reference is valuable; I just want to make sure that they are likely to be accessible to potential readers when and long after the LISP intro and architecture documents are published. --Vince From damien.saucez@gmail.com Tue Oct 30 12:33:41 2012 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 F3A8621F861C for ; Tue, 30 Oct 2012 12:33:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHIuIsIlkDAK for ; Tue, 30 Oct 2012 12:33:40 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 172AA21F861B for ; Tue, 30 Oct 2012 12:33:39 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so333585wey.31 for ; Tue, 30 Oct 2012 12:33:39 -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=QQYB2lOm1BNNx3o1Iz0/GkR99qlCBbE3ZhJCwQQfp8E=; b=owc7Y84/Kw6NXhoRIg9N/wJ6UbFs1McZJn3fydW/vdiLpL0VXV9tTvKZ6/lJi+5EZ/ 2Lej1rJyddW7U/LB/acAA3ksyj/iBbODo2/Asndr4+pVBSyG08Hnq32L0G70SnuXFs6u vOQrnwXbxAOKsydQekzwmS5ztb51oO1k8dSUMvU/lhm911JVtBOgUMM1KgE2sMDsa8y0 7rtZ/cFQb1ani9Ruez+YG30SbyYxleoP0huNjaqlsrrOFJmTYLsoIsnz+K3salEwPhbm nneYENDignenzZLILaP6495gGDW65sw6csr1wZrvwyCm6SvKiWBI0gjvxoPJaHpDUoB4 FOGw== Received: by 10.216.197.133 with SMTP id t5mr16523122wen.176.1351625618864; Tue, 30 Oct 2012 12:33:38 -0700 (PDT) Received: from [172.16.139.253] (17.82.69.86.rev.sfr.net. [86.69.82.17]) by mx.google.com with ESMTPS id bi9sm2578540wib.11.2012.10.30.12.33.35 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 12:33:36 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <20121030191235.GA93166@vaf-mac1.cisco.com> Date: Tue, 30 Oct 2012 20:33:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C7258CD-A458-48AF-9C4C-BF74E0110E9A@gmail.com> References: <33ECE5C3-6EC2-4A92-8E74-81D6322B1A17@telecom-paristech.fr> <20121030191235.GA93166@vaf-mac1.cisco.com> To: Vince Fuller X-Mailer: Apple Mail (2.1499) Cc: Luigi Iannone , "" Subject: Re: [lisp] Comments on introduction-01 document 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, 30 Oct 2012 19:33:41 -0000 On 30 Oct 2012, at 20:12, Vince Fuller wrote: > Hi Luigi- >=20 > Quick follow-up questions/comments: >=20 >>> 2. Deployment Philosophy > ... >>> The extreme focus on a viable deployment scheme is one of the >>> novelties of LISP. >>>=20 >>=20 >> Might be worth citing: >>=20 >> http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2012.98 >=20 > Is this a stable web page, suitable for citation? yes, and reference like this: Damien Saucez, Luigi Iannone, Olivier = Bonaventure, Dino Farinacci, "Designing a Deployable Future Internet: = the Locator/Identifier Separation Protocol (LISP) case," IEEE Internet = Computing, vol. 99, no. PrePrints, p. 1, , 2012=20 note however that it is a pre-print and in a few weeks only the final = reference will be available with the correct paging. > It is also worth noting > that your reference is to a very poorly written abstract could you be more precise? > for an article > that can only be read by paying $19; maybe not best thing to cite in a > document that is intended to be an RFC. Is there a more direct = reference > to a document that discusses the same issues? Journals are by definition archives so it will last "forever". I understand that having to pay for an article is something odd but unfortunately for that we are dependent of IEEE (we don't get anything from that). In general, once the final publication is available, it arrives in google caches rapidly making the reading for free easy. >=20 >>> does traffic engineering with LISP >>> instead of fine-grained BGP announcement, that will help keep = table >>> sizes down (and this is true even in the early stages of LISP >>> deployment). >>=20 >> May be cite (might be useful in section 10.4 as well): >>=20 >> http://biblio.info.ucl.ac.be/2007/415406.pdf >=20 > Is this also a stable web page, suitable for citation? >=20 the best way to reference is Bruno Quoitin, Luigi Iannone, C=E9dric de Launois, and Olivier = Bonaventure. 2007. Evaluating the benefits of the locator/identifier = separation. In Proceedings of 2nd ACM/IEEE international workshop on = Mobility in the evolving internet architecture (MobiArch '07). ACM, New = York, NY, USA, , Article 5 , 6 pages. DOI=3D10.1145/1366919.1366926 = http://doi.acm.org/10.1145/1366919.1366926 > --Vince > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@gmail.com Tue Oct 30 12:46:13 2012 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 71A2921F8640 for ; Tue, 30 Oct 2012 12:46:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzfO9gYunuR3 for ; Tue, 30 Oct 2012 12:46:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E998821F861C for ; Tue, 30 Oct 2012 12:46:11 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so338896wey.31 for ; Tue, 30 Oct 2012 12:46: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=avuBrcO/Vrd4Y75RGB07quJpTQof1thoZ0Duf6yC2vE=; b=FQMXGcI+n2p2Nia87x3neOg8uXnpVbkBcCpaouq9D/HD6xVxhBcHa9Dr2A5qLk3ROf gU9OtcncRm7cuZ1UGKZM3Nl8lL4GKvuStcujQcSwnzCZKNuMoePZycY2sNrX/GS3seYh /wpJA/0NAGDK5tRPiRzLuZlKLmKUtMxMv+m4/u8aDM0MFLnj7i4p5Z1EwmHzPj/41XLS NsmcvtjfG5IOk9zQPvCJRlGnkcqja35kB9iTlJ9X+ud06qidHtiGaYq332Ni4ZH8DSPS Ycavk4ksizatO4BGnKChxLDYZwcLDf0uOpr73P/9m71JOHUIqTahKzwcFHxMdiVwuP4m XmhQ== Received: by 10.216.74.13 with SMTP id w13mr19217178wed.101.1351626370844; Tue, 30 Oct 2012 12:46:10 -0700 (PDT) Received: from [172.16.139.253] (44.189.101.84.rev.sfr.net. [84.101.189.44]) by mx.google.com with ESMTPS id eq2sm2658833wib.1.2012.10.30.12.46.09 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 12:46:10 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Damien Saucez In-Reply-To: <20121030192231.GB93166@vaf-mac1.cisco.com> Date: Tue, 30 Oct 2012 20:46:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <617C965F-F20A-4F5E-B8DB-9F8A0BB1583B@gigix.net> <20121030192231.GB93166@vaf-mac1.cisco.com> To: Vince Fuller X-Mailer: Apple Mail (2.1499) Cc: "" Subject: Re: [lisp] Comments on lisp-architecture-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, 30 Oct 2012 19:46:13 -0000 On 30 Oct 2012, at 20:22, Vince Fuller wrote: > Hi Luigi- >=20 > Same comments/concerns about the citations you offer here. = Specifically: >=20 >> May I suggest:=20 >>=20 >> http://biblio.info.ucl.ac.be/2007/415406.pdf >=20 > want to make sure that this is a stable document to reference (i.e. it > will be around on that web site for many years to come) >=20 Bruno Quoitin, Luigi Iannone, C=E9dric de Launois, and Olivier = Bonaventure. 2007. Evaluating the benefits of the locator/identifier = separation. In Proceedings of 2nd ACM/IEEE international workshop on = Mobility in the evolving internet architecture (MobiArch '07). ACM, New = York, NY, USA, , Article 5 , 6 pages. DOI=3D10.1145/1366919.1366926 = http://doi.acm.org/10.1145/1366919.1366926 >> You can cite: >>=20 >> http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf Luigi Iannone and Olivier Bonaventure. 2007. On the cost of caching = locator/ID mappings. InProceedings of the 2007 ACM CoNEXT conference = (CoNEXT '07). ACM, New York, NY, USA, , Article 7 , 12 pages. = DOI=3D10.1145/1364654.1364663 http://doi.acm.org/10.1145/1364654.1364663 >> http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf >=20 Juhoon Kim, Luigi Iannone, and Anja Feldmann. 2011. A deep dive into the = LISP cache and what ISPs should know about it. In Proceedings of the = 10th international IFIP TC 6 conference on Networking - Volume Part I = (NETWORKING'11), Jordi Domingo-Pascual, Pietro Manzoni, Ana Pont, Sergio = Palazzo, and Caterina Scoglio (Eds.), Vol. Part I. Springer-Verlag, = Berlin, Heidelberg, 367-378. > same comment as above. >=20 >> On this point you can cite:=20 >>=20 >> http://www.computer.org/csdl/mags/ic/preprint/mic2012990288-abs.html >=20 > This is the same reference you offered for "lisp-introduction-01". At = a > minimum, that abstract needs to be re-written so that it makes sense. > Right now, it says: >=20 > The Internet has been created for interconnecting few hundreds > networks, but is now close to one billion hosts, grouped in 40,000 > Autonomous Systems, using more than 400,000 prefixes. Such a = situation > raises scalability issues that have driven both academia and = industry > to review the current Internet Architecture in the light of the > Locator/Identifier Split paradigm. In particular, the Internet > Engineering Task Force (IETF) has adopted and is actively designing > and developing the Locator/ID Separation Protocol (LISP). However, > changing the routing and addressing architecture of the Internet in = an > incrementally deployable manner Several constraints impact such a > design. We use LISP as reference to describe the different design > choices necessary to achieve deployability, which is the ultimate = goal > of any new Future Internet architecture. Furthermore, we showcase > several alternate usages of LISP, which go beyond improving the > Internet scalability. >=20 > I realize that you are not a native English speaker but this text, > especially the sentence fragment that begins "However, changing the > routing...", is so badly written as to be almost unreadable. >=20 As you can see, IEEE website completely screwed up (also the strange characters in the title), the real abstract is The Internet has been created for interconnecting few hundreds networks, but is now close to one billion hosts, grouped in 40,000 Autonomous Systems, using more than 400,000 prefixes. Such situation raises scalability issues that have driven both academia and industry to review the current Internet architecture in the light of the Locator/Identifier Split paradigm. In particular, the Internet Engineering Task Force (IETF) has adopted and is actively designing and developing the Locator/ID Separation Protocol (LISP). However, changing the routing and addressing architecture of the Internet in an incrementally deployable manner imposes several constraints in the new design. For the sake of illustration, we use LISP as reference to describe the different design choices necessary to achieve deployability, which is the ultimate goal of any new Future Internet architecture. Furthermore, we showcase several alternate usages of LISP, which go beyond improving the Internet scalability. is that more readable? As I said in the previous mail, the reference is for a pre-print so we still have to wait to have the final reference. > I also reiterate my concern that a citation that points to this web = page > 1) may not be stable and 2) is to an abstract for a document that one = needs > to pay to download. >=20 >> You can cite: >>=20 >> http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf Luigi Iannone and Olivier Bonaventure. 2007. On the cost of caching = locator/ID mappings. InProceedings of the 2007 ACM CoNEXT conference = (CoNEXT '07). ACM, New York, NY, USA, , Article 7 , 12 pages. = DOI=3D10.1145/1364654.1364663 http://doi.acm.org/10.1145/1364654.1364663 >> http://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf >=20 Juhoon Kim, Luigi Iannone, and Anja Feldmann. 2011. A deep dive into the = LISP cache and what ISPs should know about it. In Proceedings of the = 10th international IFIP TC 6 conference on Networking - Volume Part I = (NETWORKING'11), Jordi Domingo-Pascual, Pietro Manzoni, Ana Pont, Sergio = Palazzo, and Caterina Scoglio (Eds.), Vol. Part I. Springer-Verlag, = Berlin, Heidelberg, 367-378. > same question/comment as my first regarding stability. >=20 >> In this case this paper might be useful: >>=20 >> http://inl.info.ucl.ac.be/system/files/Networking12-CRV.pdf >=20 Damien Saucez, Juhoon Kim, Luigi Iannone, Olivier Bonaventure, and = Clarence Filsfils. 2012. A local approach to fast failure recovery of = LISP ingress tunnel routers. In Proceedings of the 11th international = IFIP TC 6 conference on Networking - Volume Part I (IFIP'12), Robert = Bestak, Lukas Kencl, Li Erran Li, Joerg Widmer, and Hao Yin (Eds.), Vol. = Part I. Springer-Verlag, Berlin, Heidelberg, 397-408. = DOI=3D10.1007/978-3-642-30045-5_30 = http://dx.doi.org/10.1007/978-3-642-30045-5_30 > same question/comment as my first regarding stability. >=20 > I don't doubt that the materials you have reference is valuable; I = just want > to make sure that they are likely to be accessible to potential = readers when > and long after the LISP intro and architecture documents are = published. If you reference the ACM way, you are sure that it will last (assuming = ACM will of course). Damien Saucez >=20 > --Vince > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Tue Oct 30 14:52:33 2012 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 4D06D21F85E3 for ; Tue, 30 Oct 2012 14:52:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYFpDI3PqMPN for ; Tue, 30 Oct 2012 14:52:32 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4558B21F85DA for ; Tue, 30 Oct 2012 14:52:32 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C8FB318C09D; Tue, 30 Oct 2012 17:52:30 -0400 (EDT) To: lisp@ietf.org Message-Id: <20121030215230.C8FB318C09D@mercury.lcs.mit.edu> Date: Tue, 30 Oct 2012 17:52:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on lisp-architecture-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, 30 Oct 2012 21:52:33 -0000 > From: Damien Saucez I'm still catching up from the storm (not too bad where I was, but we lost several days getting ready, and during it), but I saw one thing that confused me: >> You can cite >> http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf > Luigi Iannone and Olivier Bonaventure. 2007. On the cost of caching > locator /ID mappings. In Proceedings of the 2007 ACM CoNEXT conference > (CoNEXT '07). ACM ??? This document already references that (in Section 6.3. "Amount of State")? As a general note: I don't intend to reference every single thing written about LISP. (That's for a 'LISP Bibliography' document.) I will follow standard practise and cite things which i) are the fundamental works on a topic, or ii) the author has relied upon, or iii) would be useful/informative to readers of the document at hand. I will take a look at the additional references you list (many of which are to very recent publications, BTW), and see if they fall under ii) or iii). (The Conext one fell under all of i), ii), and iii), which is why already it was already listed.) Noel From ggx@gigix.net Wed Oct 31 14:14:05 2012 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 533F421F87E3 for ; Wed, 31 Oct 2012 14:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=1.717, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKOwodKcSvM0 for ; Wed, 31 Oct 2012 14:14:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81521F8674 for ; Wed, 31 Oct 2012 14:14:04 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so898751wgb.13 for ; Wed, 31 Oct 2012 14:14:03 -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=UZd2GCmUWf4Nm18pdLwiIHSFQpGVbV5Z9CndYjFg3is=; b=nezaWMBMz+FGreHZqBL564UOoo3L5LY5UX4jePKLxwsa8tc9aL2wrN6kqBFqo/drB3 AsvcaMNHXGRRZfIOZGmL4X3jIL+o+INls7lwRqY2cswfds9gLrl7UEgLc0MiNkTB2EqL UWqfVdUk9VOXmDPFrdKzFZw6Mo7ZHfm1d36ljQAmS+oiJjShX4EVxo3ShTX/j46Uh5vv c2JF4+OGUnb5zgKm02FhjEdvxYF7yvASm2QH09SxHM+ZpcekWK7JMjFv9rVNsjMXKZuV J/+E3uae/wc18oqK8kRKGkolf3nyTBRPirXJkGhKD7kVok1ytigyr7Bobf68mkbv3fVo 47+Q== Received: by 10.216.206.152 with SMTP id l24mr18595903weo.66.1351718043421; Wed, 31 Oct 2012 14:14:03 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:745a:79bf:b230:5319? ([2a01:e35:1381:3430:745a:79bf:b230:5319]) by mx.google.com with ESMTPS id bi9sm7511850wib.11.2012.10.31.14.14.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 14:14:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <20121030215230.C8FB318C09D@mercury.lcs.mit.edu> Date: Wed, 31 Oct 2012 22:18:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DD3D1A8-2B3D-4B36-8863-C8C2021ABAEC@gigix.net> References: <20121030215230.C8FB318C09D@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnPArTWriePxd55VW7tvweQspgU9oqUnyYpXQ1agNmzjFoRnxTo1xUFW3JPSgZF16a40SYg Cc: lisp@ietf.org Subject: Re: [lisp] Comments on lisp-architecture-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, 31 Oct 2012 21:14:05 -0000 On 30 Oct. 2012, at 22:52 , Noel Chiappa = wrote: >> From: Damien Saucez >=20 > I'm still catching up from the storm (not too bad where I was, but we = lost > several days getting ready, and during it), but I saw one thing that = confused > me: >=20 >>> You can cite >>> http://www.net.t-labs.tu-berlin.de/papers/IB-CCLIM-07.pdf >=20 >> Luigi Iannone and Olivier Bonaventure. 2007. On the cost of caching >> locator /ID mappings. In Proceedings of the 2007 ACM CoNEXT = conference >> (CoNEXT '07). ACM >=20 > ??? This document already references that (in Section 6.3. "Amount of = State")? Yes indeed. My point is that you can cite it also elsewhere (where I = suggested?) because looks to me that is somehow related to the = text/discussion. >=20 >=20 > As a general note: I don't intend to reference every single thing = written > about LISP. Absolutely. > (That's for a 'LISP Bibliography' document.) I will follow > standard practise and cite things which i) are the fundamental works = on a > topic, or ii) the author has relied upon, or iii) would be = useful/informative > to readers of the document at hand. I was more on the iii) point. The two documents should (IMHO) take the = LISP rookie by hand and guide him/her through the LISP world. Offering = pointers to relevant literature is one way to do it, especially in the = arch document those papers can support the rationale of the different = design choices. But this is just my viewpoint and you may have different plans for the = documents. >=20 > I will take a look at the additional references you list (many of = which are to > very recent publications, BTW), and see if they fall under ii) or = iii). At least they are not very long papers... ;-) ciao Luigi > (The > Conext one fell under all of i), ii), and iii), which is why already = it was > already listed.) >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Wed Oct 31 20:32:54 2012 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 E73A321F8564; Wed, 31 Oct 2012 20:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VwqVV4nsgct; Wed, 31 Oct 2012 20:32:54 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1852321F8485; Wed, 31 Oct 2012 20:32:54 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 572D155883E; Wed, 31 Oct 2012 20:32:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3FFD71C5BC2; Wed, 31 Oct 2012 20:32:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-6.clppva.btas.verizon.net [71.161.52.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 523501C5B96; Wed, 31 Oct 2012 20:32:45 -0700 (PDT) Message-ID: <5091ED52.9080705@joelhalpern.com> Date: Wed, 31 Oct 2012 23:32:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" References: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> In-Reply-To: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: Help the NomCom: Community Feedback 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, 01 Nov 2012 03:32:55 -0000 Please provide input to help the nomcom. Thank you, Joel -------- Original Message -------- Subject: Help the NomCom: Community Feedback Date: Wed, 31 Oct 2012 20:13:18 -0700 From: NomCom Chair To: Working Group Chairs The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 4. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org