From jmh@joelhalpern.com Mon Feb 4 12:36:28 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAD321F8947 for ; Mon, 4 Feb 2013 12:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.004, 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 5Jkf7LgVt3BQ for ; Mon, 4 Feb 2013 12:36:28 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 642DB21F8A47 for ; Mon, 4 Feb 2013 12:36:26 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 42C98559303 for ; Mon, 4 Feb 2013 12:36:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6E8271E0BEF for ; Mon, 4 Feb 2013 12:36:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 13B081E0BEE for ; Mon, 4 Feb 2013 12:36:23 -0800 (PST) Message-ID: <51101BAE.1060603@joelhalpern.com> Date: Mon, 04 Feb 2013 15:35:58 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 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 architecture index scalability (section 6.4) 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, 04 Feb 2013 20:36:28 -0000 I was discussing the architecture document and it was poited out (and I agree) that section 6.4 came out badly. I think that the first step towards a solution (which may be sufficient) is to include a one paragraph description of DDT. Yours, Joel From internet-drafts@ietf.org Mon Feb 4 13:05:58 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56E921F8B0B; Mon, 4 Feb 2013 13:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 pF1Hopu+UMHa; Mon, 4 Feb 2013 13:05:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5F21F8B0E; Mon, 4 Feb 2013 13:05:58 -0800 (PST) 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.37 Message-ID: <20130204210558.26035.11744.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2013 13:05:58 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-mib-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 21:05:58 -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-09.txt Pages : 66 Date : 2013-02-04 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jnc@mercury.lcs.mit.edu Mon Feb 4 13:48:30 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACF821F8AF2 for ; Mon, 4 Feb 2013 13:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 f2HIblZOof7Q for ; Mon, 4 Feb 2013 13:48:29 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3C821F85D2 for ; Mon, 4 Feb 2013 13:48:29 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9F8B118C0C2; Mon, 4 Feb 2013 16:48:28 -0500 (EST) To: lisp@ietf.org Message-Id: <20130204214828.9F8B118C0C2@mercury.lcs.mit.edu> Date: Mon, 4 Feb 2013 16:48:28 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] lisp architecture index scalability (section 6.4) 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, 04 Feb 2013 21:48:30 -0000 > From: "Joel M. Halpern" > I was discussing the architecture document and it was poited out (and I > agree) that section 6.4 came out badly. It does have a certain 'useful if you are already fairly conversant with the points being made' quality about it... I mean, 'DDT doesn't have potential hot-spots like ALT' is really only useful if you know why ALT might have them, and where... :-) > I think that the first step towards a solution (which may be > sufficient) is to include a one paragraph description of DDT. Actually, that should go in Section 5.2.3. "Indexing Subsystem" in the architecture introduction document. The problem, as always, is that I can think of many interesting things to say, but the problem is how to keep the document to a reasonable length. In this regard, I note that the two documents were written at a time when DDT was just coming into view, and were in fact somewhat 'forward looking' on this matter. Now, I think, things have changed, and perhaps we can just drop most discussion of ALT, including the long discussion about 'why DDT is better than ALT'. That would allow the space to be dedicated to a bit longer description of DDT than 'just like DNS'... ;-) Noel From jnc@mercury.lcs.mit.edu Mon Feb 4 13:55:01 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5E121F8B33 for ; Mon, 4 Feb 2013 13:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 rBvUnBRE9u-t for ; Mon, 4 Feb 2013 13:55:01 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 29BEC21F8506 for ; Mon, 4 Feb 2013 13:55:01 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DAB2A18C0BE; Mon, 4 Feb 2013 16:55:00 -0500 (EST) To: lisp@ietf.org Message-Id: <20130204215500.DAB2A18C0BE@mercury.lcs.mit.edu> Date: Mon, 4 Feb 2013 16:55:00 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] lisp architecture index scalability (section 6.4) 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, 04 Feb 2013 21:55:01 -0000 > that should go in .. the architecture introduction document. BTW, I have realize that the two documents _together_ are 'the architecture description', so I am now referring to them as the 'introduction document' and the 'perspective document' (and so I find references to 'the architecture document' a bit confusing at this point :-). I have renamed them both in my draft versions to make this perfectly clear, and will be updating the file names when I next submit new versions to help everyone get used to this. Noel From terry.manderson@icann.org Thu Feb 7 15:50:10 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031E621F89B5 for ; Thu, 7 Feb 2013 15:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 vjHrodYHZ8aH for ; Thu, 7 Feb 2013 15:50:05 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1385521F89B3 for ; Thu, 7 Feb 2013 15:50:05 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 7 Feb 2013 15:50:04 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 7 Feb 2013 15:50:02 -0800 Thread-Topic: Meeting in Orlando Thread-Index: Ac4FjdllXmq5VK+tQ1a2qC6kCDsZDg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3443161802_59971732" MIME-Version: 1.0 Subject: [lisp] Meeting in Orlando 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, 07 Feb 2013 23:50:10 -0000 --B_3443161802_59971732 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit WG, The Orlando meeting time is fast approaching. The draft agenda has us meeting at 0900-1100 (Morning Session I) in Caribbean 6 on Friday March 15, 2013. Please keep in mind the following important dates. * 2013-02-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. * 2013-02-15 (Friday): Final agenda to be published. * 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, * 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC 24:00, * 2013-02-27 (Wednesday): Draft Working Group agendas due by UTC 24:00, Please send your requests for agenda items to lisp-chairs@tools,ietf.org by the 25th February. Thanks Terry --B_3443161802_59971732 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ 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+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFCuuqT7vaa0vDfl7DeMdzYKR3fPuMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMDIwNzIzNTAwMlowDQYJKoZIhvcNAQEBBQAEggEAinW7f8RF +BKFZfWBRLqQQi2GAvoyHtV4x8QXmwU1jH3Ke/yW2bUIqAw6ZXMa7r2yjUUnSFKon9TAL1L5 OUrZa9mm3heKKR6ujFlUhKtQ8gxlusDNnxE3cD7fI274znFa+CFnOjlsTBPq4Ox2x2iOPlJx 8xo01+dIHT8qa8YbBDPPb6tiP0z9fOhrhbeDFEfyFJabeAAQYa6PsbjyY/5u0CKBiS4h7wec gm0JtjWJvABoFJ5P4T8fOBQEQPO9dnKLJ1NYxRdVc5sDQAj29f+tAJSMwaVw0cKcGeK39Hpu Q9LlmaKY2fZTCUIuE3ndZLPvh92kwzrxC7cPNosHVEldJA== --B_3443161802_59971732-- From Fred.L.Templin@boeing.com Mon Feb 11 08:31:56 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3721F8891 for ; Mon, 11 Feb 2013 08:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 XbtECn-0vwgU for ; Mon, 11 Feb 2013 08:31:56 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2259F21F8884 for ; Mon, 11 Feb 2013 08:31:56 -0800 (PST) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1BGVt9p032656 for ; Mon, 11 Feb 2013 10:31:55 -0600 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1BGVsbn032653 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 11 Feb 2013 10:31:55 -0600 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 11 Feb 2013 08:31:55 -0800 From: "Templin, Fred L" To: "lisp@ietf.org" Date: Mon, 11 Feb 2013 08:31:53 -0800 Thread-Topic: RFC6830 comment Thread-Index: Ac4FjdllXmq5VK+tQ1a2qC6kCDsZDgC5tYKA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [lisp] RFC6830 comment 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, 11 Feb 2013 16:31:56 -0000 Hi, In RFC6830, Section 5.4.1, it says: "the ITR will drop the packet when the size is greater than L and send an ICMP Too Big message to the source with a value of S, where S is (L - H)." Shouldn't it be: "when the size is greater than (L - H)" ? Thanks - Fred fred.l.templin@boeing.com From farinacci@gmail.com Tue Feb 12 09:05:36 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52A921F8F84 for ; Tue, 12 Feb 2013 09:05:36 -0800 (PST) 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 huScNILkTaDB for ; Tue, 12 Feb 2013 09:05:36 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id F38EC21F8F82 for ; Tue, 12 Feb 2013 09:05:25 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so113775dal.15 for ; Tue, 12 Feb 2013 09:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=H/shoEC5i8A6agdCYLPM1B3nuLAtKXYJ2a7P5t15wNk=; b=cwQwaf73yLzqVwbB83/MT5ZciTILcV+And3Tcd2VDWvUmiwRWX8r1TvLp86pBTF2L3 5ayf9vSTHVRxQBZDZJMa8uQY0YMN2moxfn3GGE3h1p2R1pQHPbWIM6J5tdVx0L8eMNwg PliGi+RYITnTJ2NBGVKCD6KyCwVbHRfjDhauOZDuk4U1ssjyqKWT3r/IpFh03LM5C4to /2mBj/k8Gfg4rEK/rXsgfAo4cP5lg79mJsjT82EZvnqsDYy/4PXsKU7hsAkWAkea1BNp 7HSgeESEyiNJbu3Cy2F4WSSSVH78OFp++EsOhpGDonx7dQ32CeFkUA1s0Pme/wS+FPFv jNMQ== X-Received: by 10.66.186.164 with SMTP id fl4mr10899113pac.51.1360688724458; Tue, 12 Feb 2013 09:05:24 -0800 (PST) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPS id m3sm76406496pav.4.2013.02.12.09.05.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 09:05:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: Date: Tue, 12 Feb 2013 09:05:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> References: To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 17:05:36 -0000 > Hi, >=20 > In RFC6830, Section 5.4.1, it says: >=20 > "the ITR will drop the packet > when the size is greater than L and send an ICMP Too Big message to > the source with a value of S, where S is (L - H)." >=20 > Shouldn't it be: "when the size is greater than (L - H)" ? L is the size of the packet that will leave the ITR so it won't be = fragmented by the ITR or any intermediate routers. S is the size of the = packet that must be received by the ITR to avoid fragmentation. L-H is S. So if S + H (calculated by the ITR is L) is greater than the = effective MTU, that is when the packet is dropped. That is what the text = says. You can explain this in terms of S, of (L-H), or in terms of L. We chose = to describe it by how the packet leaves the ITR, in terms of L. Dino From Fred.L.Templin@boeing.com Tue Feb 12 09:39:29 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8921F8F5E for ; Tue, 12 Feb 2013 09:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 JaNSp1oJskBP for ; Tue, 12 Feb 2013 09:39:28 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id DDDB021F8EB5 for ; Tue, 12 Feb 2013 09:39:28 -0800 (PST) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1CHdSxG031064 for ; Tue, 12 Feb 2013 09:39:28 -0800 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1CHdRRJ031059 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Feb 2013 09:39:28 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 12 Feb 2013 09:39:27 -0800 From: "Templin, Fred L" To: Dino Farinacci Date: Tue, 12 Feb 2013 09:39:26 -0800 Thread-Topic: [lisp] RFC6830 comment Thread-Index: Ac4JQywvB2EKrjupRq+4QPqCAd1uuAAAp4cA Message-ID: References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> In-Reply-To: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 17:39:29 -0000 Hi Dino, > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Tuesday, February 12, 2013 9:05 AM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] RFC6830 comment >=20 > > Hi, > > > > In RFC6830, Section 5.4.1, it says: > > > > "the ITR will drop the packet > > when the size is greater than L and send an ICMP Too Big message to > > the source with a value of S, where S is (L - H)." > > > > Shouldn't it be: "when the size is greater than (L - H)" ? >=20 > L is the size of the packet that will leave the ITR so it won't be > fragmented by the ITR or any intermediate routers. S is the size of the > packet that must be received by the ITR to avoid fragmentation. >=20 > L-H is S. So if S + H (calculated by the ITR is L) is greater than the > effective MTU, that is when the packet is dropped. That is what the text > says. >=20 > You can explain this in terms of S, of (L-H), or in terms of L. We chose > to describe it by how the packet leaves the ITR, in terms of L. OK, I went back and looked again and it looks clear enough. However, what should the ITR do if it gets an ICMP packet too big (PTB) message after sending an encapsulated packet to the ETR. Drop it? Cache the MTU size? Send a translated PTB message back to the original source? Section 5.4.1 of the document doesn't currently say. Thanks - Fred fred.l.templin@boeing.com > Dino >=20 From farinacci@gmail.com Tue Feb 12 10:57:06 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E74621F90C2 for ; Tue, 12 Feb 2013 10:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.175, 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 bsK7hipCeKrb for ; Tue, 12 Feb 2013 10:56:57 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0A15E21F90C1 for ; Tue, 12 Feb 2013 10:56:56 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id t11so158100daj.36 for ; Tue, 12 Feb 2013 10:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ZhaayXYSUGtAX3aGPnNbGfUfKyQeducTV4MMGJh553w=; b=OME1HI7FgK7rjypc62JKKQmewZ0wkYC/wN53zmQjeVDrnWwW2jtiH/St1SBsp68Dq1 6LIj2C/EpvZ3Xm3jKwDWuBldbPyNOKqcmS4IgC0VcLyqahUTpZA0tNxHwcIT2ZTpjIG7 cq+4Y5aj1ILJdrZIO1t2xz/PSi+wBbhhbJVrAd/LKhUumSjMdOlCzW4S1JSG8x03ARYE gaJbrgaH+VsIj1lV0pFbsFmfnKTeqc9lgjQN5haGHUkiMCHQPKk/O/w+dq8hrENf+Rqr zI1vCdvAnyhRZiEPmMWOQjPRgPrsDrsGdcDnm1OxwVwQYt2XlJBFLNTvpG5KbRw5Qbu0 j3kQ== X-Received: by 10.66.86.201 with SMTP id r9mr55101568paz.14.1360695416407; Tue, 12 Feb 2013 10:56:56 -0800 (PST) Received: from [192.168.1.11] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id d1sm40575876paz.17.2013.02.12.10.56.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:56:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: Date: Tue, 12 Feb 2013 10:56:53 -0800 Content-Transfer-Encoding: 7bit Message-Id: <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 18:57:06 -0000 > However, what should the ITR do if it gets an ICMP packet too > big (PTB) message after sending an encapsulated packet to the > ETR. Drop it? Cache the MTU size? Send a translated PTB message > back to the original source? Section 5.4.1 of the document > doesn't currently say. Read the stateful section. Dino From Fred.L.Templin@boeing.com Tue Feb 12 11:12:50 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D9521F8FFA for ; Tue, 12 Feb 2013 11:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 5ZyJkFiYgvmd for ; Tue, 12 Feb 2013 11:12:49 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id C36D221F8FF7 for ; Tue, 12 Feb 2013 11:12:49 -0800 (PST) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1CJCm8d006234 for ; Tue, 12 Feb 2013 13:12:48 -0600 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1CJCEb4005308 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Feb 2013 13:12:48 -0600 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Tue, 12 Feb 2013 11:12:29 -0800 From: "Templin, Fred L" To: Dino Farinacci Date: Tue, 12 Feb 2013 11:12:27 -0800 Thread-Topic: [lisp] RFC6830 comment Thread-Index: Ac4JUr2mxt3OIFPiRsOSAr2F7QvMIQAAYrlQ Message-ID: References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> In-Reply-To: <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 19:12:50 -0000 > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Tuesday, February 12, 2013 10:57 AM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] RFC6830 comment >=20 > > However, what should the ITR do if it gets an ICMP packet too > > big (PTB) message after sending an encapsulated packet to the > > ETR. Drop it? Cache the MTU size? Send a translated PTB message > > back to the original source? Section 5.4.1 of the document > > doesn't currently say. >=20 > Read the stateful section. I did. It's just that the stateless method defaults to stateful if PTBs arrive. So, purely stateless may not be possible in all cases. But, it doesn't say that. Thanks - Fred fred.l.templin@boeing.com From farinacci@gmail.com Tue Feb 12 11:13:47 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2428221F90E9 for ; Tue, 12 Feb 2013 11:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 gkOI1uof+lCR for ; Tue, 12 Feb 2013 11:13:46 -0800 (PST) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3E21F90ED for ; Tue, 12 Feb 2013 11:13:46 -0800 (PST) Received: by mail-da0-f45.google.com with SMTP id w4so164896dam.4 for ; Tue, 12 Feb 2013 11:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=u9loj/p90nD3hj8TV7z1pixfPMA3D3A21NV84Rbdjr0=; b=CayElFdrXIQ1H1jy6X+5YfFLePQ67+a5G666BofkAoBwhNFFQ3i1uDLMGMb5cppyYb m9TIpGc+UUjNrFR/nR8/sNU/s6MQ8xd7i+gVh+aoDHevp+5K3Uv+qybF2ODGufFWuulC 0YzGDRtq1IVf8yBnAQQKwGGWFMk4k8PW/BAlhJabMSdAPke6zX7IpETAPhA7WVFJgl7c KTp2viHnciryBApHG9hK4e0t6LRI/Fj7FVDywdnRpfK0yA6pG9NO4qysmwXGFNPcc8CZ 1hSjsJrai5YkcagHNPDrtaH/2ZcmbscHeDmceWuZEUUxjxsQsiSQTkmh9k5nZyHiTxFV MMGA== X-Received: by 10.66.80.162 with SMTP id s2mr55081117pax.61.1360696425802; Tue, 12 Feb 2013 11:13:45 -0800 (PST) Received: from [192.168.1.11] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id q4sm77134100paz.20.2013.02.12.11.13.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 11:13:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: Date: Tue, 12 Feb 2013 11:13:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 19:13:47 -0000 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Tuesday, February 12, 2013 10:57 AM >> To: Templin, Fred L >> Cc: lisp@ietf.org >> Subject: Re: [lisp] RFC6830 comment >>=20 >>> However, what should the ITR do if it gets an ICMP packet too >>> big (PTB) message after sending an encapsulated packet to the >>> ETR. Drop it? Cache the MTU size? Send a translated PTB message >>> back to the original source? Section 5.4.1 of the document >>> doesn't currently say. >>=20 >> Read the stateful section. >=20 > I did. It's just that the stateless method defaults to stateful if > PTBs arrive. So, purely stateless may not be possible in all cases. > But, it doesn't say that. Stateful means to store the learned effective MTU with the locator for = the map-cache entry Dino >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 From Fred.L.Templin@boeing.com Tue Feb 12 11:27:00 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E008D21F9105 for ; Tue, 12 Feb 2013 11:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 kv-xnM-UfG6L for ; Tue, 12 Feb 2013 11:26:59 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id EEB1421F9104 for ; Tue, 12 Feb 2013 11:26:54 -0800 (PST) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1CJQsPc016822 for ; Tue, 12 Feb 2013 11:26:54 -0800 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1CJQslx016813 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Feb 2013 11:26:54 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Tue, 12 Feb 2013 11:26:54 -0800 From: "Templin, Fred L" To: Dino Farinacci Date: Tue, 12 Feb 2013 11:26:52 -0800 Thread-Topic: [lisp] RFC6830 comment Thread-Index: Ac4JVRuS5eQQ0wvSR+K7bzqHtZ6PJAAAUjDA Message-ID: References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 19:27:00 -0000 > >> Read the stateful section. > > > > I did. It's just that the stateless method defaults to stateful if > > PTBs arrive. So, purely stateless may not be possible in all cases. > > But, it doesn't say that. >=20 > Stateful means to store the learned effective MTU with the locator for th= e > map-cache entry Yes, I understand that. My point is that stateless is not possible if a learned effective MTU has to be stored. The stateless section should therefore describe the conditions under which it must default to stateful. Thanks - Fred fred.l.templin@boeing.com From farinacci@gmail.com Tue Feb 12 13:35:10 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECD321F8C4B for ; Tue, 12 Feb 2013 13:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8bAlK6fxUbN for ; Tue, 12 Feb 2013 13:35:09 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4E21A21F8C84 for ; Tue, 12 Feb 2013 13:35:06 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so323807pab.5 for ; Tue, 12 Feb 2013 13:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=kMppusC2e9IuJAE/zz8/lV8QC5UHWdouN/tS8PacjCw=; b=N+0pf7gfLGfKA8j4Tk5o4pfF61OETN3N5yINhXooH/Im2TBfpWbZZPJ/RZ7flJ8Ocg EQh0eYQlCPtYrYPJttdjclx1FceYuRgtOX8Uu4X5zLDwIG6rmL9ZJfbpJlqI0nY9Ha7i oDeyoFdU41lBSsBDmq+REaSKbTiP74XvJA8FylXv9XzvMM87V6/57t54Mgf2Skb25gCz y7/Klf45BEYnMdhFUCfe0BCLeZtPxbG6s+PCjeBW7jChiDR0aoVysqzx6LIl4jkmHSBV ricf2LY4vRIVE9vQKTSfSBvJUTLNEmTsTlltTp6dN7Shyb3dimaxjib/GMUTi/fR3zA+ nnpQ== X-Received: by 10.66.80.65 with SMTP id p1mr55960945pax.20.1360704905839; Tue, 12 Feb 2013 13:35:05 -0800 (PST) Received: from [10.169.113.83] (68.65.72.19.static-ip.telepacific.net. [68.65.72.19]) by mx.google.com with ESMTPS id l5sm77879206pax.10.2013.02.12.13.34.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 13:35:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: Date: Tue, 12 Feb 2013 13:34:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <39B29290-E095-4088-9996-9D269CEEF540@gmail.com> References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 21:35:10 -0000 >>>> Read the stateful section. >>>=20 >>> I did. It's just that the stateless method defaults to stateful if >>> PTBs arrive. So, purely stateless may not be possible in all cases. >>> But, it doesn't say that. >>=20 >> Stateful means to store the learned effective MTU with the locator = for the >> map-cache entry >=20 > Yes, I understand that. My point is that stateless is not possible > if a learned effective MTU has to be stored. The stateless section > should therefore describe the conditions under which it must default > to stateful. Fred, there is stateless and the counter which is stateful. An = implementation can do one or the other or both if depending on the cost = you want to put towards the solution. We are not making a recommendation. It is up to the implementor to = decide. Dino >=20 > Thanks - Fred > fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Tue Feb 12 14:07:35 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E5F21F8754 for ; Tue, 12 Feb 2013 14:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eHF5OgCbWns for ; Tue, 12 Feb 2013 14:07:35 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3555B21F8740 for ; Tue, 12 Feb 2013 14:07:35 -0800 (PST) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1CM7Yxa004747 for ; Tue, 12 Feb 2013 16:07:34 -0600 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1CM7XtI004730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Feb 2013 16:07:34 -0600 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Tue, 12 Feb 2013 14:07:33 -0800 From: "Templin, Fred L" To: Dino Farinacci Date: Tue, 12 Feb 2013 14:07:32 -0800 Thread-Topic: [lisp] RFC6830 comment Thread-Index: Ac4JaN9A1AxQZXYLQNKBHNfzrc1keQAA80RQ Message-ID: References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> <39B29290-E095-4088-9996-9D269CEEF540@gmail.com> In-Reply-To: <39B29290-E095-4088-9996-9D269CEEF540@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 22:07:35 -0000 Hi Dino, > > Yes, I understand that. My point is that stateless is not possible > > if a learned effective MTU has to be stored. The stateless section > > should therefore describe the conditions under which it must default > > to stateful. >=20 > Fred, there is stateless and the counter which is stateful. An The ITR is only stateless until which time the network returns a packet too big - then, it is obliged to either do stateful or risk black-holing. > implementation can do one or the other or both if depending on the cost > you want to put towards the solution. >=20 > We are not making a recommendation. It is up to the implementor to decide= . Not my point, but a fully stateless solution may not always be possible (my point). Thanks - Fred fred.l.templin@boeing.com From farinacci@gmail.com Tue Feb 12 14:15:59 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9966E21F8AB2 for ; Tue, 12 Feb 2013 14:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+G242GUA+pA for ; Tue, 12 Feb 2013 14:15:59 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 22C1121F8A93 for ; Tue, 12 Feb 2013 14:15:59 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kp6so346031pab.36 for ; Tue, 12 Feb 2013 14:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=wPDf93N/Ni4bewEAOv66XVzwVwe3ip8DEp8v8Ivg518=; b=ypZ7joG6CGeTskCg2K5zmTwbS/VjKZokZ/vw3cM2JKH3KXS9k8ZznnpihsTukOYHFd Q5Vc+nbfasTVeY8adMY+3pD8iK1zw3m7kXbHOSQzYfyrwZAM9bjChWbEANBLcWChW1uy k++g2gDeUkH2R2IB5LeuXdFZmQR9CSO2qtbS7oFdbimPLFzkGdVmgQgJdTrJiqW9Lh7M t7DEuAZT/aKc/tXr7VwwAoZJ7YuluTmsy/+7Mn8hMI7DKgFkgDtyiJ78rjd+ENyj1knl NnWHSQbcoiVdBcsP6mBymEZzUt6OtFSMOvd8fzKIXNAtpcJsFFMQLWQMcdxj4M5tx0Mg 6/Sw== X-Received: by 10.66.83.6 with SMTP id m6mr56597755pay.52.1360707358499; Tue, 12 Feb 2013 14:15:58 -0800 (PST) Received: from [10.169.113.83] (68.65.72.19.static-ip.telepacific.net. [68.65.72.19]) by mx.google.com with ESMTPS id bi8sm78097067pab.15.2013.02.12.14.15.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 14:15:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: Date: Tue, 12 Feb 2013 14:15:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> <39B29290-E095-4088-9996-9D269CEEF540@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 22:15:59 -0000 >>> Yes, I understand that. My point is that stateless is not possible >>> if a learned effective MTU has to be stored. The stateless section >>> should therefore describe the conditions under which it must default >>> to stateful. >>=20 >> Fred, there is stateless and the counter which is stateful. An >=20 > The ITR is only stateless until which time the network returns > a packet too big - then, it is obliged to either do stateful or > risk black-holing. And who says it is obliged? The specification was written in the way it = was for a reason. You want to change it to something else.=20 What is your point? And can we get to it with less emails please? Dino From Fred.L.Templin@boeing.com Tue Feb 12 14:30:00 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6670C21F8B8B for ; Tue, 12 Feb 2013 14:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnbGLsB0nhEc for ; Tue, 12 Feb 2013 14:29:59 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7A98A21F8795 for ; Tue, 12 Feb 2013 14:29:59 -0800 (PST) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1CMTw0I023282 for ; Tue, 12 Feb 2013 16:29:59 -0600 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1CMTwn4023279 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Feb 2013 16:29:58 -0600 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 12 Feb 2013 14:29:58 -0800 From: "Templin, Fred L" To: Dino Farinacci Date: Tue, 12 Feb 2013 14:29:56 -0800 Thread-Topic: [lisp] RFC6830 comment Thread-Index: Ac4JbooovF56tFUCRIeZ7ActkaM6vQAAEFNQ Message-ID: References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> <39B29290-E095-4088-9996-9D269CEEF540@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 22:30:00 -0000 Hi Dino, > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Tuesday, February 12, 2013 2:16 PM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] RFC6830 comment >=20 > >>> Yes, I understand that. My point is that stateless is not possible > >>> if a learned effective MTU has to be stored. The stateless section > >>> should therefore describe the conditions under which it must default > >>> to stateful. > >> > >> Fred, there is stateless and the counter which is stateful. An > > > > The ITR is only stateless until which time the network returns > > a packet too big - then, it is obliged to either do stateful or > > risk black-holing. >=20 > And who says it is obliged? The specification was written in the way it > was for a reason. You want to change it to something else. It's really very simple; modify the next to last paragraph of section 5.4.1 such as: "When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY either set the DF bit in such headers to 0 or adopt the stateful solution in Section 5.4.2 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR." This also brings home the point that stateless vs stateful can be on a per-ETR basis rather than all one way or the other. Thanks - Fred fred.l.templin@boeing.com From jnc@mercury.lcs.mit.edu Tue Feb 12 14:38:08 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B952421F89FD for ; Tue, 12 Feb 2013 14:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5tLdOXx5Fhv for ; Tue, 12 Feb 2013 14:38:08 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4392921F89CE for ; Tue, 12 Feb 2013 14:38:08 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 895D118C0F6; Tue, 12 Feb 2013 17:38:07 -0500 (EST) To: lisp@ietf.org Message-Id: <20130212223807.895D118C0F6@mercury.lcs.mit.edu> Date: Tue, 12 Feb 2013 17:38:07 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 22:38:08 -0000 > From: "Templin, Fred L" > It's really very simple; modify the next to last paragraph of section > 5.4.1 It's already an RFC. If and when the WG gets around to doing a new rev of the spec, this would be an appropriate comment then. Noel From Fred.L.Templin@boeing.com Tue Feb 12 14:56:37 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039AF21F88A8 for ; Tue, 12 Feb 2013 14:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZdYHHdIUPOV for ; Tue, 12 Feb 2013 14:56:36 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4721F877A for ; Tue, 12 Feb 2013 14:56:36 -0800 (PST) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1CMuaep028142 for ; Tue, 12 Feb 2013 14:56:36 -0800 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1CMuZkD028137 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Feb 2013 14:56:35 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 12 Feb 2013 14:56:35 -0800 From: "Templin, Fred L" To: Noel Chiappa , "lisp@ietf.org" Date: Tue, 12 Feb 2013 14:56:34 -0800 Thread-Topic: [lisp] RFC6830 comment Thread-Index: Ac4JcaUdMKkwsRxjRkSZhhy4ZVzxSAAAKj2A Message-ID: References: <20130212223807.895D118C0F6@mercury.lcs.mit.edu> In-Reply-To: <20130212223807.895D118C0F6@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 22:56:37 -0000 > > It's really very simple; modify the next to last paragraph of > section > > 5.4.1 >=20 > It's already an RFC. If and when the WG gets around to doing a new rev of > the > spec, this would be an appropriate comment then. It's a request for comments, and this is a comment. I also believe there are other mechanisms for updating documents rather than wait for a second edition. But, the section on MTU has IMHO always been under-specified and prone to a certain "brittleness" depending on the operational scenarios in which xTRs are deployed. I.e., it may work well in some scenarios and poorly in others. Maybe there is an open document on LISP deployment scenarios where this should be mentioned? Thanks - Fred =20 From farinacci@gmail.com Tue Feb 12 14:58:44 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DDF21F88A8 for ; Tue, 12 Feb 2013 14:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3EgUbs1pW9q for ; Tue, 12 Feb 2013 14:58:43 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 23E3E21F85BD for ; Tue, 12 Feb 2013 14:58:43 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so255614dan.23 for ; Tue, 12 Feb 2013 14:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=b08zeOJTcoy27dDJs8KuUURpgl/rEBMZnbdYjJp4IZo=; b=IDm64H8eyNxmu45fhkCFTVVXob+YncLRRIWv+++07FHJ0NO3cUaqVn2BADcGO/LYgO nsNjt/dSdGsBWinoM4VwQ1YXbRoh3QgXqn1u3NoGOyj5yPiGeCtwHElRx7XbLEwbuKPp /jjW2iWE0P+epvu7eXBcDYASS/N06/WEOnmQe2qlybP0XX918mnakIPAJ5dNI/53Ofs5 xp/ELgO2Cy4jCcAw6N2GWF4actUZlklq7CiWLdoHuD23TiYiHL9zMMfhOiiJ25g1e5dx gG4lBo3D+KgG10vIFsUCJtKMvrA31eEN7W+YdGznTjTgjpIMn6rMU4HKc3B3guILY7Ld 5elA== X-Received: by 10.66.184.208 with SMTP id ew16mr56579413pac.19.1360709922676; Tue, 12 Feb 2013 14:58:42 -0800 (PST) Received: from [10.169.113.83] (68.65.72.19.static-ip.telepacific.net. [68.65.72.19]) by mx.google.com with ESMTPS id d8sm78353223pax.23.2013.02.12.14.58.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 14:58:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: Date: Tue, 12 Feb 2013 14:58:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <75BF63B6-FDFD-4687-A416-CFB2F58D78AA@gmail.com> References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> <39B29290-E095-4088-9996-9D269CEEF540@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1499) Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 22:58:44 -0000 The whole point of the text, the way it was written is to NOT DO MTU = DISCOVERY between the ITR and ETR. That will lead to more packet loss. = Avoid it up front by having hosts configure smaller MTUs or do MTUD = inside of the site. The point was to have less mechanism rather than more. We have been = telling you this for years Fred.=20 Dino On Feb 12, 2013, at 2:29 PM, "Templin, Fred L" = wrote: > Hi Dino, >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Tuesday, February 12, 2013 2:16 PM >> To: Templin, Fred L >> Cc: lisp@ietf.org >> Subject: Re: [lisp] RFC6830 comment >>=20 >>>>> Yes, I understand that. My point is that stateless is not possible >>>>> if a learned effective MTU has to be stored. The stateless section >>>>> should therefore describe the conditions under which it must = default >>>>> to stateful. >>>>=20 >>>> Fred, there is stateless and the counter which is stateful. An >>>=20 >>> The ITR is only stateless until which time the network returns >>> a packet too big - then, it is obliged to either do stateful or >>> risk black-holing. >>=20 >> And who says it is obliged? The specification was written in the way = it >> was for a reason. You want to change it to something else. >=20 > It's really very simple; modify the next to last paragraph of > section 5.4.1 such as: >=20 > "When the outer-header encapsulation uses an IPv4 header, an > implementation SHOULD set the DF bit to 1 so ETR fragment reassembly > can be avoided. An implementation MAY either set the DF bit in such > headers to 0 or adopt the stateful solution in Section 5.4.2 if it = has > good reason to believe there are unresolvable path MTU issues = between > the sending ITR and the receiving ETR." >=20 > This also brings home the point that stateless vs stateful can > be on a per-ETR basis rather than all one way or the other. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 From Fred.L.Templin@boeing.com Tue Feb 12 15:09:06 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36F821F8A6F for ; Tue, 12 Feb 2013 15:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI2elW0B9luc for ; Tue, 12 Feb 2013 15:09:06 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B421F8A6C for ; Tue, 12 Feb 2013 15:09:06 -0800 (PST) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1CN95R6013598 for ; Tue, 12 Feb 2013 15:09:05 -0800 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1CN95gJ013595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Feb 2013 15:09:05 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 12 Feb 2013 15:09:05 -0800 From: "Templin, Fred L" To: Dino Farinacci Date: Tue, 12 Feb 2013 15:09:04 -0800 Thread-Topic: [lisp] RFC6830 comment Thread-Index: Ac4JdIZJuY1k7nXoRS6nnxPj4Pl64gAAJxEQ Message-ID: References: <573F3CA7-57CD-4716-A568-C3C2511CC843@gmail.com> <10B9E0A4-3259-404D-B9F8-B2B09E7D8B46@gmail.com> <39B29290-E095-4088-9996-9D269CEEF540@gmail.com> <75BF63B6-FDFD-4687-A416-CFB2F58D78AA@gmail.com> In-Reply-To: <75BF63B6-FDFD-4687-A416-CFB2F58D78AA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "lisp@ietf.org" Subject: Re: [lisp] RFC6830 comment 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, 12 Feb 2013 23:09:06 -0000 Hi Dino, > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Tuesday, February 12, 2013 2:59 PM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] RFC6830 comment >=20 > The whole point of the text, the way it was written is to NOT DO MTU > DISCOVERY between the ITR and ETR. That will lead to more packet loss. > Avoid it up front by having hosts configure smaller MTUs or do MTUD insid= e > of the site. >=20 > The point was to have less mechanism rather than more. We have been > telling you this for years Fred. Telling me all you want doesn't make the spec bullet-proof in all deployment scenarios. For example, I just noticed the deployment scenario document 'draft-ietf-lisp-deployment' where there seems to be a fair amount of concern for MTU implications based on placement of the xTRs. But, I haven't followed the LISP developments closely enough to know how far this document is along in the process. Thanks - Fred fred.l.templin@boeing.com > Dino >=20 > On Feb 12, 2013, at 2:29 PM, "Templin, Fred L" > wrote: >=20 > > Hi Dino, > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:farinacci@gmail.com] > >> Sent: Tuesday, February 12, 2013 2:16 PM > >> To: Templin, Fred L > >> Cc: lisp@ietf.org > >> Subject: Re: [lisp] RFC6830 comment > >> > >>>>> Yes, I understand that. My point is that stateless is not possible > >>>>> if a learned effective MTU has to be stored. The stateless section > >>>>> should therefore describe the conditions under which it must defaul= t > >>>>> to stateful. > >>>> > >>>> Fred, there is stateless and the counter which is stateful. An > >>> > >>> The ITR is only stateless until which time the network returns > >>> a packet too big - then, it is obliged to either do stateful or > >>> risk black-holing. > >> > >> And who says it is obliged? The specification was written in the way i= t > >> was for a reason. You want to change it to something else. > > > > It's really very simple; modify the next to last paragraph of > > section 5.4.1 such as: > > > > "When the outer-header encapsulation uses an IPv4 header, an > > implementation SHOULD set the DF bit to 1 so ETR fragment reassembly > > can be avoided. An implementation MAY either set the DF bit in such > > headers to 0 or adopt the stateful solution in Section 5.4.2 if it ha= s > > good reason to believe there are unresolvable path MTU issues between > > the sending ITR and the receiving ETR." > > > > This also brings home the point that stateless vs stateful can > > be on a per-ETR basis rather than all one way or the other. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > From sander@steffann.nl Wed Feb 13 04:04:11 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4791021F8826 for ; Wed, 13 Feb 2013 04:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrXbTCJepEwP for ; Wed, 13 Feb 2013 04:04:10 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB2C21F8821 for ; Wed, 13 Feb 2013 04:04:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A23162036; Wed, 13 Feb 2013 13:04:09 +0100 (CET) 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 6wvO7ppumkbz; Wed, 13 Feb 2013 13:04:05 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id DB7F62034; Wed, 13 Feb 2013 13:04:04 +0100 (CET) From: Sander Steffann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 13 Feb 2013 13:04:03 +0100 To: mailer list , "lisp@ietf.org list list" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [lisp] Unidentified bit in Map-Register messages 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, 13 Feb 2013 12:04:11 -0000 Hi all, In a tcpdump of some Map-Register messages I see a bit two bits before = the Want-Map-Notify bit set to 1. So in hex the Map-Register now starts = with 32 00 05. The 3 is the type code for Map-Register, the 2 is the I = bit and the 5 at the end is the Want-Map-Notify bit and some other bit. What does that bit mean? Which draft am I missing this time? ;-) Thanks! Sander From farinacci@gmail.com Wed Feb 13 14:54:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3ED121E80A3 for ; Wed, 13 Feb 2013 14:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 Nv6u1mkb0y7a for ; Wed, 13 Feb 2013 14:54:51 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 81A6821E809B for ; Wed, 13 Feb 2013 14:54:51 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id bh2so958555pad.2 for ; Wed, 13 Feb 2013 14:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=UAHQKmBaBt34+PZTKIDeGC3UQYHxdZN3OHLAv+X2hbo=; b=Oo+rmNi6eb2t/OakXw+PAqpaKiR8zya1MGKAOjiFIkJx7DmVWpbt1H8cBsH7rTE2ck Ir8UwbPGXX4ubyDedXMbcKIt9LyiJfKERyHZnLZ02yuNFOSO5E8NMgubM9D8NPyZWqBf yAEAcxtylqXFF137wi0ULApDJRVEoxlj+0EhOHVZG4b32+DBY3zdlAQQV0BzYAQX0kkl 9GKGfidZy2NzZ8d1oKcZxKX3bsrj5vxSTcCd+9pGyY4+7chrZmnDyTj8DTKQTNSQIk44 kmQKkHgREXVW1GIQsWTa45ut7lO/5+gLkAK2FFFPkAqizqEk1QhYKoHmrWn0lp1HocPn ojjg== X-Received: by 10.66.89.132 with SMTP id bo4mr68450371pab.62.1360796066927; Wed, 13 Feb 2013 14:54:26 -0800 (PST) Received: from [192.168.1.11] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id bi2sm86822395pab.18.2013.02.13.14.54.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 14:54:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: Date: Wed, 13 Feb 2013 14:54:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <895445E9-CABC-49AA-A951-7C6EC2DD33E1@gmail.com> References: To: Sander Steffann X-Mailer: Apple Mail (2.1499) Cc: mailer list , "lisp@ietf.org list list" Subject: Re: [lisp] Unidentified bit in Map-Register messages 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, 13 Feb 2013 22:54:52 -0000 > In a tcpdump of some Map-Register messages I see a bit two bits before = the Want-Map-Notify bit set to 1. So in hex the Map-Register now starts = with 32 00 05. The 3 is the type code for Map-Register, the 2 is the I = bit and the 5 at the end is the Want-Map-Notify bit and some other bit. If you are talking to a cisco operating system, the format of the first = 32-bits of a Map-Register is: 0 1 2 3 = =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 |Type=3D3 |P|S|I| Reserved |T|a|m|M| Record Count = | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 compared to RFC 6830: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D3 |P| Reserved |M| Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > What does that bit mean? Which draft am I missing this time? ;-) The S-bit is for LISP-SEC, see the lisp-sec draft for details. The I-bit is the xTR-ID, see the lisp-nat-traversal draft for details. The m-bit is set when a LISP-MN registers, see the lisp-mn draft for = details. The a-bit is for requesting merge semantics (versus replacement = semantics) for a register, see the lisp-nat-traversal draft for details. The T-bit is used by cisco for experimenting with faster Map-Register = timeouts. So when set, the TTL from the Map-Register is used to time out = the registration. This is not documented anywhere. Dino= From sander@steffann.nl Thu Feb 14 00:07:34 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5521F8886 for ; Thu, 14 Feb 2013 00:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-2.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.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 hF4-0aTurn5G for ; Thu, 14 Feb 2013 00:07:28 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 7520411E80A2 for ; Thu, 14 Feb 2013 00:07:28 -0800 (PST) Received: from [100.104.139.98] (unknown [188.207.81.20]) by mail.sintact.nl (Postfix) with ESMTP id C7813202F; Thu, 14 Feb 2013 09:07:24 +0100 (CET) References: <895445E9-CABC-49AA-A951-7C6EC2DD33E1@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <895445E9-CABC-49AA-A951-7C6EC2DD33E1@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B142) From: Sander Steffann Date: Thu, 14 Feb 2013 09:07:20 +0100 To: Dino Farinacci Cc: mailer list , "lisp@ietf.org list list" Subject: Re: [lisp] Unidentified bit in Map-Register messages 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, 14 Feb 2013 08:07:34 -0000 Thanks Dino! Met vriendelijke groet, Sander Steffann Op 13 feb. 2013 om 23:54 heeft Dino Farinacci het volg= ende geschreven: >> In a tcpdump of some Map-Register messages I see a bit two bits before th= e Want-Map-Notify bit set to 1. So in hex the Map-Register now starts with 3= 2 00 05. The 3 is the type code for Map-Register, the 2 is the I bit and the= 5 at the end is the Want-Map-Notify bit and some other bit. >=20 > If you are talking to a cisco operating system, the format of the first 32= -bits of a Map-Register is: >=20 > 0 1 2 3 = =20 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 > |Type=3D3 |P|S|I| Reserved |T|a|m|M| Record Count | = =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 >=20 > compared to RFC 6830: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Type=3D3 |P| Reserved |M| Record Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >> What does that bit mean? Which draft am I missing this time? ;-) >=20 > The S-bit is for LISP-SEC, see the lisp-sec draft for details. > The I-bit is the xTR-ID, see the lisp-nat-traversal draft for details. > The m-bit is set when a LISP-MN registers, see the lisp-mn draft for detai= ls. > The a-bit is for requesting merge semantics (versus replacement semantics)= for a register, see the lisp-nat-traversal draft for details. >=20 > The T-bit is used by cisco for experimenting with faster Map-Register time= outs. So when set, the TTL from the Map-Register is used to time out the reg= istration. This is not documented anywhere. >=20 > Dino From ggx@gigix.net Mon Feb 18 03:23:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A42E21F881C for ; Mon, 18 Feb 2013 03:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 FGKF0skw+fiY for ; Mon, 18 Feb 2013 03:23:08 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 099E021F887F for ; Mon, 18 Feb 2013 03:23:07 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so3323338wib.3 for ; Mon, 18 Feb 2013 03:23:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:subject:date:references:to:message-id :mime-version:x-mailer:x-gm-message-state; bh=sNWV3HimJFt7qmkhGNNEehcvMBsD1g4lzqfogXyaTQ8=; b=icO3ggQjJ6vzNwFydNDjDxzBse5+6M6xWP7olmeRPYkDdqdUY3Vh9VZ0eRutnofH9h znfq9hVcrNGsSjocd2qu7nGt26Em4ic47lqFcOryIC/s0aFY+8cmqERWP0HGe0gakDoj ny3l+uWk7yLZPv0/JP0baXppfHeoON8pSYyLcCZOY4FfXEQwMbvWQP2TCzWcUwfKI+Rf 2neD/aL6ub4kfj/UnDnhCz2svQ7KIl7ZlfFI/SJi74nkfA/V17RMRGSTRM577Ra4oAD2 gVyylrkE/R9PjQ7jrKXbDv1TcTu1WoNMM2NcUto4FBvh017pmFhA9GGpe3j/0jJJCuQh Vosg== X-Received: by 10.180.86.166 with SMTP id q6mr17812689wiz.15.1361186584359; Mon, 18 Feb 2013 03:23:04 -0800 (PST) Received: from dhcp164-03.enst.fr (dhcp164-03.enst.fr. [137.194.165.3]) by mx.google.com with ESMTPS id bj9sm19310035wib.4.2013.02.18.03.23.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 03:23:03 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_D285E8B1-B520-4BCC-8767-15E33FBA3760" Date: Mon, 18 Feb 2013 12:23:13 +0100 References: <20130218111808.20638.80709.idtracker@ietfa.amsl.com> To: "lisp@ietf.org list list" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnZFxQCrAgUsnRzEbQZI/uJ7uLK2FmmD24ANpYttzEl1orJ6hzpt4XpAoGYvA6FXMLqK6d3 Subject: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-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, 18 Feb 2013 11:23:09 -0000 --Apple-Mail=_D285E8B1-B520-4BCC-8767-15E33FBA3760 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, I just submitted a new draft concerning management of the EID Block. As a quick reminder: the IETF review of the document requesting the EID = Block to IANA raised concerns with respect of the allocation and = management of the space. This document is a first attempt to trigger discussion on this specific = point. Any comment is welcome (especially from RIRs ;-) ). An updated version of the EID Block document will follow in few days. ciao Luigi=20 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-iannone-lisp-eid-block-mgmnt-00.txt > Date: 18 February 2013 12:18:08 GMT+01:00 > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP EID Block Management Guidelines > Author(s) : Luigi Iannone > Filename : draft-iannone-lisp-eid-block-mgmnt-00.txt > Pages : 9 > Date : 2013-02-18 >=20 > Abstract: > This document proposes an allocation framework for the management of > the LISP EID address prefix (requested in a separate document). = Such > framework relies on hierarchical distribution of the address space = to > RIRs (Regional Internet Registries), who will allocate on a = temporary > basis sub-prefixes to requesting organizations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-00 >=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 --Apple-Mail=_D285E8B1-B520-4BCC-8767-15E33FBA3760 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

I just submitted a new draft concerning = management of the EID Block.

As a quick = reminder: the IETF review of the document requesting the EID Block to = IANA raised concerns with respect of the allocation and management of = the space.

This document is a first attempt to = trigger discussion on this specific point.

Any = comment is welcome (especially from RIRs ;-) = ).

An updated version of the EID Block document = will follow in few = days.

ciao

Luigi 


Begin forwarded message:

Subject: I-D Action: = draft-iannone-lisp-eid-block-mgmnt-00.txt
Date: 18 February 2013 = 12:18:08 GMT+01:00
Reply-To: = internet-drafts@ietf.org
<= /span>


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


Title =           : LISP EID = Block Management Guidelines
Author(s) =       : Luigi Iannone
Filename =        : = draft-iannone-lisp-eid-block-mgmnt-00.txt
Pages =           : 9
Date =            : = 2013-02-18

Abstract:
  This document proposes an = allocation framework for the management of
  the LISP EID = address prefix (requested in a separate document).  Such
=   framework relies on hierarchical distribution of the address = space to
  RIRs (Regional Internet Registries), who will = allocate on a temporary
  basis sub-prefixes to requesting = organizations.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt=

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-00

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

=
= --Apple-Mail=_D285E8B1-B520-4BCC-8767-15E33FBA3760-- From internet-drafts@ietf.org Mon Feb 18 14:05:46 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD8E21F8943; Mon, 18 Feb 2013 14:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 RuX6go07yU8A; Mon, 18 Feb 2013 14:05:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED2721F88A8; Mon, 18 Feb 2013 14:05:46 -0800 (PST) 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.40 Message-ID: <20130218220546.3925.98505.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 14:05:46 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-perspective-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, 18 Feb 2013 22:05:47 -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-perspective-00.txt Pages : 21 Date : 2013-02-18 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. [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.] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-perspective There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-perspective-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jnc@mercury.lcs.mit.edu Mon Feb 18 14:12:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD3A21F8D03 for ; Mon, 18 Feb 2013 14:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 nAa4-gra7bJe for ; Mon, 18 Feb 2013 14:12:22 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id F02C521F8D05 for ; Mon, 18 Feb 2013 14:12:21 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3EB8B18C141; Mon, 18 Feb 2013 17:12:21 -0500 (EST) To: lisp@ietf.org Message-Id: <20130218221221.3EB8B18C141@mercury.lcs.mit.edu> Date: Mon, 18 Feb 2013 17:12:21 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] I-D Action: draft-ietf-lisp-perspective-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, 18 Feb 2013 22:12:23 -0000 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Locator/ID Separation > Protocol Working Group of the IETF. Hi, all, this isn't actually a new version - it's just that I don't think you can rename I-D's in the I-D system, so to change the filename (which inevitably gets used a shorthand, in this case, confusingly) of the Architectural Perspective document (as distinct from the Architectural Introduction document) from draft-ietf-lisp-architecture to draft-ietf-lisp-perspective, I had to resubmit it. I'm working on new version of both the Introduction and Perspective documents now (you'll see traffic about prior comments soon). Noel From farinacci@gmail.com Tue Feb 19 09:12:16 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A672F21F8E51; Tue, 19 Feb 2013 09:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, 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 hJU7xiWNghw4; Tue, 19 Feb 2013 09:12:15 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8621F8E4D; Tue, 19 Feb 2013 09:12:15 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so3028067dak.2 for ; Tue, 19 Feb 2013 09:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=o6iW554eLUEcxZMQcTbR8gs5S3LSPazHGYvdFamiAl4=; b=AO/tnfO+5NY4ARvuGkFxmvYmpFdUawB5E5jh6wwTDJv6btxSsghAD50lqcLEoxAMTB OzIpel/q8C+9u3zqGA+8/kV8rf++STX4MIqj8+ycd/Thl/cv84xrrA3ONv1ImGoEGpr7 09E4Wxo8dsHu+TMe8ezWXbh/vUjDIA5dUPDJnsAg1mV/HRAxwwMnO+VwUUBu859xyAes xigOQvHXAaz63kXAqDaFTSyqLXeXggrAmfuOK4afEJfXLXsUZS+OACQk2FOqUlSKFWFL Gpd+2SJJpUMd8haqZ7FUjE0crxbgTcsMxqT4BDfVHdKMpEOJVJUfDpjo2YzkFbIb1upP 5quw== X-Received: by 10.68.42.9 with SMTP id j9mr42541794pbl.142.1361293935233; Tue, 19 Feb 2013 09:12:15 -0800 (PST) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPS id d1sm108027787pav.6.2013.02.19.09.12.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 09:12:14 -0800 (PST) From: Dino Farinacci Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Feb 2013 09:12:11 -0800 Message-Id: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> To: "Martin J. Levy" , mpounsett@afilias.info Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org, "lisp@ietf.org list list" Subject: [lisp] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 19 Feb 2013 17:12:16 -0000 Sorry I am late on this thread. I just joined the list and read the = discussion on this draft. Here are my comments from a LISP perspective. = I am cross posting to the LISP WG mailing list. Your draft text comes first indented and my comments follow. > Network Working Group M. = Levy > Internet-Draft Hurricane = Electric > Intended status: Informational M. = Pounsett > Expires: July 28, 2013 = Afilias > January 24, = 2013 >=20 >=20 > A mechanism to allocate IPv6 blocks for BGP networks based on the > networks AS Number > draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt We have been discussing in the LISP WG the allocation of a coarse IPv6 = prefix for the use of Provider Independent EID prefixes. > Abstract >=20 > This document provides a methodology for automatically allocating > IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] = and > are either single-homed or multi-homed [BARBER2011]. The automatic > allocation is taken from a specific /16 block assigned by IANA for > this purpose. >=20 > Networks that require more than this single /48 can still request > additional allocations via the existing RIR process. Networks are > not forced to use this allocation and can ignore this completely. > Availability of the /48 assignment via this mechanism does not = change > existing mechanisms for obtaining IPv6 assignments through the > existing RIR (Regional Internet Registry) or LIR (Local Internet > Registry) mechanisms. This is a good idea PROVIDED these prefixes are not injected into the = core routing system. > 1. Introduction >=20 > IPv6's massive address space provides a wonderful opportunity to > radically change the process of IP address allocation. Presently > IPv6 allocation is the same process as used by the IPv4 world. The > RIRs allocate IPv6 address blocks based on member requests and = their > space requirements. A minimum allocation of a /48 is believed to = be > sufficient to start any enterprise in the world of IPv6. Or a small set of devices that plan to be mobile. Where they do not want = to reallocate addresses when they move. > 2. Defining the /48 address >=20 > The /48 address is allocated using a fixed pattern. >=20 >=20 > ASN-based address assignment > +----------+--------------------+-----------------/ /------------+ > | IANA /16 | 32 bit ASN | 80 bits for IPv6 /48 space | > +----------+--------------------+-----------------/ /------------+ This is similar in concept to the GLOP space we allocated for IPv4 = multicast addresses. What we said is that anyone could join a group with = a ASN-based address. That is, they did not have to own it. Can the authors tell me if someone who owns such a prefix, will they be = allowed to use and reallocate for any general purpose to other = entities/organizations? > The sum of the bits in the IANA allocated /16 prefix plus the 32 = bits > of the ASN plus the /48 of user defined usage adds up to 128 bits. >=20 > +------+----------------------+ > | Bits | Usage | > +------+----------------------+ > | 16 | IANA provided prefix | > | 32 | ASN | > | 80 | User defined | > | 128 | TOTAL | > +------+----------------------+ >=20 > Table 1: Address space math Can there be some ASN values assigned to signify "no one owns the /48"? = So we can have even more independent assignments. For the purposes of = LISP, we don't care if these address don't perfect aggregate because = these addresses will go into the LISP mapping database system which may = not need to aggregate since the RLOCs associated with the prefixes will = be different anyways (and therefore can't aggregate or compress). > The end network can allocate out of the assigned /48 as needed. It > is assumed that the end network will use this allocation for global > routing; however the network may choose to not announce this > allocation. Okay, so lets use an example to see how this can be used. Let's say a = /80 comes out of Verizon's space: (1) Does Verizon allocate say a /64 to each of BMW, Mercedes, and Ford = so they can use Vehicle ID Numbers for the rest of the allocation for = their automobile EID assignments? (2) Or do the RIRs believe they need to assign a /48 with distinct ASNs = to each of BMW, Mercedes and Ford so they have more bits to embed VIN = numbers? (3) What if these auto manufactures don't want to allocate ASN numbers = because they will never have any intent to run BGP either in the cars, = POPs, data centers? > If any route is announced from this allocation, any prefixes more > specific than the allocated /48 must not be propagated in to the > global IPv6 routing table. This is to prevent the IPv6 routing = table This is fine authors, but if you are multi-home, it will require each = system at the site to possess multiple addresses one from each attached = ASN if they do not have their own prefix but get it out of their = provider. If you say that this prefix will never be associated with a provider's = attachment point, then I'm okay with that and agree. > from becoming too large. Therefore, a site which uses this > allocation MUST NOT advertise a more specific than the allocated = /48 > routing prefix. All native IPv6 network operators MUST filter out >=20 >=20 >=20 > Levy & Pounsett Expires July 28, 2013 [Page = 3] > Internet-Draft Auto allocation mechanism for IPv6 blocks January = 2013 >=20 >=20 > and discard any routing prefix advertisements longer than /48 from > within this /16 allocation. Can you explicitly state then that this prefix for use as a PROVIDER = INDEPENDENT prefix. Thanks. > 3. IANA allocated /16 >=20 > IANA is to allocate a /16 in a similar manner to the 2002::/16 > allocation for 6to4 [RFC3068] which is used by the 6to4 > protocol[RFC3056].. No IPv4 allocation by IANA is required. But in this case there is no implicit assumption about mapping to = anything else with a bit-by-bit algorithm but rather an advertisement or = another network-based mapping data structure. Correct? > ASNs are normally expressed as human-readable decimal numbers; yet > for this allocation the number should be converted into a = hexadecimal > notation. All IPv6 addresses are written in hexadecimal. (NNNN > represents the /16 allocation by IANA) >=20 > +----------------+--------------------+---------------------+ > | ASN in decemal | ASN in hexadecimal | Sample IP block | > +----------------+--------------------+---------------------+ > | AS1 | 1 | NNNN:0000:0001::/48 | > | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | > | AS29001 | 7149 | NNNN:0000:0001::/48 | > | AS393220 | 60004 | NNNN:0006:0004::/48 | > +----------------+--------------------+---------------------+ What we had found in the old days of NSAP deployment (OSI) that encoding = IPv4 addresses in BCD format in a hexadecimal longer address was = extremely useful for management. And as we have seen for IPv6, even = embedding IPv4 dotted decimal format was extremely useful. Rather than having to build tools and make vendors do UI work, can we = have some form of BCD format for AS number. I know this will be = difficult for a 32-bit number but we could make it work for the ASNs = that are <=3D 65535. Just a thought. But even 10 million ASNS would only = take up to 8 nibbles. And since we won't and can't aggregate ASNs there = is no point in making the encoding a power-of-2 value. > 5. ASN allocation >=20 > ASNs are allocated by RIRs and this RFC does not handle that arena. >=20 > ASNs defined as private ASNs MUST NOT use this scheme. The special > 16-bit ASN 23456 MUST NOT use this scheme. I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. > 6. BGP Filtering and Validation >=20 > Filtering would be a simple case of mapping the final ASN in a path > to the prefix in an exact bit-order match. >=20 > For example; the prefix NNNN:0000:1B1B::/48 should only be seen as > announced from AS6939 (6939 equals 0x1B1B in hex). Networks would > have their upstream transit providers add this /48 prefix to their > existing inbound BGP route filters. IMO, these addresses should stay out of underlying routing. If you want = to build a mobile Internet for IPv6, these sort of addresses are = identity addresses and not topological. Let's not perpetuate the non-sense of the past. > 10. Routing Table Impact >=20 > This mechanism is not expected to have any impact to the global > Internet routing table since existing policies in the RIR system > already readily provide for the allocation of provider-independent > IPv6 prefixes. Additionally, AS number holders are likely to be > multihomed entities which were going to be independently routed in > any case. Service Providers are, as always, not obligated to route > these IPv6 assignments and/or may establish conditions of service > which offset any additional routing cost. I would say it would have the same impact as PI prefixes do today. > 14.2. Informative References You may, not sure, but may want to add these as possible informative = references: draft-ietf-lisp-eid-block draft-iannone-lisp-eid-block-mgmnt > Martin J. Levy > Matthew Pounsett Thanks for coming out with this, Dino From farinacci@gmail.com Tue Feb 19 15:02:39 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542A221F8942; Tue, 19 Feb 2013 15:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.001 X-Spam-Level: **** X-Spam-Status: No, score=4.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_SUMOF=5, 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 MyYm8wnNI6gT; Tue, 19 Feb 2013 15:02:38 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 706D921F893D; Tue, 19 Feb 2013 15:02:38 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so2487241pbc.24 for ; Tue, 19 Feb 2013 15:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=GqmU1V+EzYe9PISJOF7Uze+OwHcWGvwl4GMlqMNJg18=; b=vzsT7En1K9Vh4yKyTH9P8u6wcBhvq0RGwUqsynHFgZ6WnIaX8j2fSfMK8ctXdpBflj hkudR0ajbjn1b0CMvpzg+6DT+J+oDnT8bxxtzhiR4ys1YZjE3RFaGdPEn48wUcRmEGq0 ogULFefqOYDV+lVhdxGWk6VVZWiDU0l0cxFIjAHfSVwGtLc/bUS78K3so22GeJjLjn/U VzaKErEh7ERzWDvDM49dSLhiJ1k902OZUDV8vEOKgMYmNXkGaEVaWCi/yIqaQWercZU6 g9efVCuc+ey02RivBov6jJ8g24sqiMt4EhrD0uLS+X1gSRZLzN9GYaj81EeAcNHayl5u Dnyw== X-Received: by 10.68.48.227 with SMTP id p3mr44822952pbn.34.1361314958182; Tue, 19 Feb 2013 15:02:38 -0800 (PST) Received: from [192.168.13.208] (c-67-180-20-82.hsd1.ca.comcast.net. [67.180.20.82]) by mx.google.com with ESMTPS id q4sm108839772paz.20.2013.02.19.15.02.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 15:02:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dino Farinacci In-Reply-To: <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> Date: Tue, 19 Feb 2013 15:02:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1499) Cc: "Martin J. Levy" , mpounsett@afilias.info, v6ops@ietf.org, "lisp@ietf.org list list" Subject: Re: [lisp] [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 19 Feb 2013 23:02:39 -0000 >>> The sum of the bits in the IANA allocated /16 prefix plus the 32 = bits >>> of the ASN plus the /48 of user defined usage adds up to 128 bits. >>>=20 >>> +------+----------------------+ >>> | Bits | Usage | >>> +------+----------------------+ >>> | 16 | IANA provided prefix | >>> | 32 | ASN | >>> | 80 | User defined | >>> | 128 | TOTAL | >>> +------+----------------------+ >>>=20 >>> Table 1: Address space math >>=20 >> Can there be some ASN values assigned to signify "no one owns the = /48"? So we can have even more independent assignments. For the purposes = of LISP, we don't care if these address don't perfect aggregate because = these addresses will go into the LISP mapping database system which may = not need to aggregate since the RLOCs associated with the prefixes will = be different anyways (and therefore can't aggregate or compress). >=20 > Wouldn't the private ASN range already effectively do this? I'm asking the intent of the authors. >>> The end network can allocate out of the assigned /48 as needed. It >>> is assumed that the end network will use this allocation for global >>> routing; however the network may choose to not announce this >>> allocation. >>=20 >> Okay, so lets use an example to see how this can be used. Let's say a = /80 comes out of Verizon's space: >>=20 >> (1) Does Verizon allocate say a /64 to each of BMW, Mercedes, and = Ford so they can use Vehicle ID Numbers for the rest of the allocation = for their automobile EID assignments? >>=20 >=20 > First of all, you can't pull a /64 out of a /80 so I think you mean a = /48 assigned to $PROVIDER. Yes, I mistyped. > I think permanently assigned addresses related to VINS are, in = general, a bad idea. I don't see any advantage to tying the semantics of = the two systems to each other. If anything, the development of LISP is = the result of failing to separate the semantics of end-point addressing = from the semantics of topological location. Combining the semantics of = end-point addressing and VINs seems even more far-fetched to me. An EID is opaque and not used by the protocol stack just by humans if = they choose to look at them.=20 >> (3) What if these auto manufactures don't want to allocate ASN = numbers because they will never have any intent to run BGP either in the = cars, POPs, data centers? >>=20 >=20 > I don't see anything in this draft that would preclude them from using = a different source of addressing. >=20 > I confess, to some extent, I wonder if this is a solution in search of = a problem. I know there are customers that want to reduce the number of total = databases they have to manage at all layers of the stack. >>> If any route is announced from this allocation, any prefixes more >>> specific than the allocated /48 must not be propagated in to the >>> global IPv6 routing table. This is to prevent the IPv6 routing = table >>=20 >> This is fine authors, but if you are multi-home, it will require each = system at the site to possess multiple addresses one from each attached = ASN if they do not have their own prefix but get it out of their = provider. >>=20 >> If you say that this prefix will never be associated with a = provider's attachment point, then I'm okay with that and agree. >>=20 >=20 > Either I misunderstand what you are saying, or, you have erred. I'm = not sure which. >=20 > If a site uses a /64 from within this /48 to attach to each upstream, = the more specific does not need to propagate beyond the immediate = upstream router, so it still wouldn't be announced into the global = routing table. There is still PI flat routing on the scale of number of sites that use = this prefix. That is the point, there is no attempt to improve the route = table scaling problem. I'm not saying this draft should, just speaking = generally. >>> from becoming too large. Therefore, a site which uses this >>> allocation MUST NOT advertise a more specific than the allocated = /48 >>> routing prefix. All native IPv6 network operators MUST filter out >>>=20 >>>=20 >>>=20 >>> Levy & Pounsett Expires July 28, 2013 = [Page 3] >>> Internet-Draft Auto allocation mechanism for IPv6 blocks January = 2013 >>>=20 >>>=20 >>> and discard any routing prefix advertisements longer than /48 from >>> within this /16 allocation. >>=20 >> Can you explicitly state then that this prefix for use as a PROVIDER = INDEPENDENT prefix. Thanks. >>=20 >=20 > I think that is inherent in the definition of the prefix. Can you = clarify why you think this > statement is necessary? I want it explicit so there is no layers of ownership of the prefix. >>> ASNs are normally expressed as human-readable decimal numbers; yet >>> for this allocation the number should be converted into a = hexadecimal >>> notation. All IPv6 addresses are written in hexadecimal. (NNNN >>> represents the /16 allocation by IANA) >>>=20 >>> +----------------+--------------------+---------------------+ >>> | ASN in decemal | ASN in hexadecimal | Sample IP block | >>> +----------------+--------------------+---------------------+ >>> | AS1 | 1 | NNNN:0000:0001::/48 | >>> | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | >>> | AS29001 | 7149 | NNNN:0000:0001::/48 | >>> | AS393220 | 60004 | NNNN:0006:0004::/48 | >>> +----------------+--------------------+---------------------+ >>=20 >> What we had found in the old days of NSAP deployment (OSI) that = encoding IPv4 addresses in BCD format in a hexadecimal longer address = was extremely useful for management. And as we have seen for IPv6, even = embedding IPv4 dotted decimal format was extremely useful. >>=20 >> Rather than having to build tools and make vendors do UI work, can we = have some form of BCD format for AS number. I know this will be = difficult for a 32-bit number but we could make it work for the ASNs = that are <=3D 65535. Just a thought. But even 10 million ASNS would only = take up to 8 nibbles. And since we won't and can't aggregate ASNs there = is no point in making the encoding a power-of-2 value. >=20 > I would oppose doing this. If we are going to do this (and I'm not = entirely convinced that we should, but also not opposed), we should = support the full ASN space and doing so as a bit field is fine. I don't = think any UI work is required. Tools to convert 32-bit numbers from = decimal to hex are already widely available and the process is well = understood. It's not like anyone will have to do this conversion on a = daily basis. >=20 > perl -e 'printf "%08x\n", ' will solve the = problem, for example. Multiply by 1000 products coming out over different delivery times. = Don't underestimate the slowness of vendors. >>> 5. ASN allocation >>>=20 >>> ASNs are allocated by RIRs and this RFC does not handle that arena. >>>=20 >>> ASNs defined as private ASNs MUST NOT use this scheme. The special >>> 16-bit ASN 23456 MUST NOT use this scheme. >>=20 >> I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. >=20 > What local/global bit? Add one is the suggestion. >>> This mechanism is not expected to have any impact to the global >>> Internet routing table since existing policies in the RIR system >>> already readily provide for the allocation of provider-independent >>> IPv6 prefixes. Additionally, AS number holders are likely to be >>> multihomed entities which were going to be independently routed in >>> any case. Service Providers are, as always, not obligated to route >>> these IPv6 assignments and/or may establish conditions of service >>> which offset any additional routing cost. >>=20 >> I would say it would have the same impact as PI prefixes do today. >>=20 >=20 > Which means that this has no impact because it doesn't change the = impact vs. the current PI impact. You miss the point. The problem needs to be solved. Saying this draft = doesn't worsen it is not panacea. Dino From farinacci@gmail.com Tue Feb 19 18:16:45 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBA721F8802; Tue, 19 Feb 2013 18:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-2.198, BAYES_50=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, 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 m0yfqlgMAJpW; Tue, 19 Feb 2013 18:16:44 -0800 (PST) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id D69A321F8840; Tue, 19 Feb 2013 18:16:43 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id ma3so2584399pbc.39 for ; Tue, 19 Feb 2013 18:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=tLk6xPBNIkDvLe4uuPm3Ga9qJIxDmw6KIAK7Kd0ZpXc=; b=gsmkOhqNF4eFmWO5QE1qlwoFmj0it3/kTTIw2OLXSJrCaklmJffNKe1POhJbNEciGo PZ0R5x55e1edzMNqTayToMzGoifW7euTE33Ckm3cngBIeIpvhErnMiXvcB3Ngi974Ij4 q2D2OhbjfrHF7B859pIgFK0Mj7i2Ekz7gpwyONs/2vKZ2+GYpR54XEoyofNd4U4CKH8d uMjnw3f+LZF/wuwEc7ogRROQRk9BFewvDyCj0gEO1SZeUGyF86Vf1V6kzhsj5KxPbS7X gV54kTlf/xo8K2dHPlqCHddhEHi0Dq2BZxiX/FfBVYsdCuRdrFIkUU3bdYZfK9G1vrpQ 3Apg== X-Received: by 10.68.130.35 with SMTP id ob3mr59646pbb.92.1361326603515; Tue, 19 Feb 2013 18:16:43 -0800 (PST) Received: from [192.168.1.9] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id gg7sm19847416pbc.45.2013.02.19.18.16.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 18:16:42 -0800 (PST) References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B143) From: Dino Farinacci Date: Tue, 19 Feb 2013 18:16:41 -0800 To: Owen DeLong Cc: "Martin J. Levy" , "mpounsett@afilias.info" , "v6ops@ietf.org" , "lisp@ietf.org list list" Subject: Re: [lisp] [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 20 Feb 2013 02:16:45 -0000 On Feb 19, 2013, at 5:09 PM, Owen DeLong wrote: >>> I think permanently assigned addresses related to VINS are, in general, a= bad idea. I don't see any advantage to tying the semantics of the two syste= ms to each other. If anything, the development of LISP is the result of fail= ing to separate the semantics of end-point addressing from the semantics of t= opological location. Combining the semantics of end-point addressing and VIN= s seems even more far-fetched to me. >>=20 >> An EID is opaque and not used by the protocol stack just by humans if the= y choose to look at them.=20 >>=20 >=20 > One of us is misunderstanding the other. My point is that using IPv6 addre= ss space to number things that are not IPv6 hosts is, IMHO, a bad idea. The automobiles are IPv6 hosts.=20 >=20 >>>> (3) What if these auto manufactures don't want to allocate ASN numbers b= ecause they will never have any intent to run BGP either in the cars, POPs, d= ata centers? >>>>=20 >>>=20 >>> I don't see anything in this draft that would preclude them from using a= different source of addressing. >>>=20 >>> I confess, to some extent, I wonder if this is a solution in search of a= problem. >>=20 >> I know there are customers that want to reduce the number of total databa= ses they have to manage at all layers of the stack. >>=20 >=20 > All well and good, but I do not support turning IPv6 addresses into the pr= imary key for everything in world anyone wants to identify in any namespace.= If that's not what your sentence above means, then I'm afraid I misundersta= nd your meaning. It is none of your business how sites use their addresses. That is the whole= point of ID/Locator separation.=20 The EID is opaque to the network but may have meaning to the sites who commu= nicate with each other within that EID-prefix.=20 > Again, I do not support the idea of using IPv6 numbers as a mechanism for i= dentifying anything that isn't an IPv6 host and I do not support tying seman= tics other than the host end-system identifier for packet delivery to IPv6 a= ddresses. I think that past experience has demonstrated that both of these p= ractices create more problems than they solve. See above. Tell me if you still disagree and if so we will have to disagree.= This is where IPv6 could be useful. What does IPv6 have that IPv4 doesn't? R= eally only longer addresses.=20 >=20 >>>>> If any route is announced from this allocation, any prefixes more >>>>> specific than the allocated /48 must not be propagated in to the >>>>> global IPv6 routing table. This is to prevent the IPv6 routing table >>>>=20 >>>> This is fine authors, but if you are multi-home, it will require each s= ystem at the site to possess multiple addresses one from each attached ASN i= f they do not have their own prefix but get it out of their provider. >>>>=20 >>>> If you say that this prefix will never be associated with a provider's a= ttachment point, then I'm okay with that and agree. >>>>=20 >>>=20 >>> Either I misunderstand what you are saying, or, you have erred. I'm not s= ure which. >>>=20 >>> If a site uses a /64 from within this /48 to attach to each upstream, th= e more specific does not need to propagate beyond the immediate upstream rou= ter, so it still wouldn't be announced into the global routing table. >>=20 >> There is still PI flat routing on the scale of number of sites that use t= his prefix. That is the point, there is no attempt to improve the route tabl= e scaling problem. I'm not saying this draft should, just speaking generally= . >=20 > I think that concern is entirely orthogonal to this draft. My point is tha= t for every PI > prefix that gets advertised from this space, it should represent a PI pref= ix from RIR > space that does not get advertised, so it is a net equivalence in terms of= the > routing table. Thus, I would anticipate that this draft has no impact on t= he routing > table. Okay fine.=20 > OTOH, the whole way we do IDR is broken and we should have fixed it as par= t > of the IPv6 development process. Unfortunately, we (IETF) chose to punt on= that and > go down all kinds of other less important roads. However, this issue is re= ally > not part of the discussion of this draft. If locator/ID separation is used then this is helped and you make multi-homi= ng easier at the same time as making address management in every host.=20 Look how complicated the home networking proposals are? >=20 >>>>> from becoming too large. Therefore, a site which uses this >>>>> allocation MUST NOT advertise a more specific than the allocated /48 >>>>> routing prefix. All native IPv6 network operators MUST filter out >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Levy & Pounsett Expires July 28, 2013 [Page 3= ] >>>>> Internet-Draft Auto allocation mechanism for IPv6 blocks January 20= 13 >>>>>=20 >>>>>=20 >>>>> and discard any routing prefix advertisements longer than /48 from >>>>> within this /16 allocation. >>>>=20 >>>> Can you explicitly state then that this prefix for use as a PROVIDER IN= DEPENDENT prefix. Thanks. >>>>=20 >>>=20 >>> I think that is inherent in the definition of the prefix. Can you clarif= y why you think this >>> statement is necessary? >>=20 >> I want it explicit so there is no layers of ownership of the prefix. >>=20 >=20 > I'm not sure how stating that this prefix is PROVIDER INDEPENDENT conveys a= ny ownership or lack thereof. Never mind - bit worth arguing the point.=20 >=20 >>>>> ASNs are normally expressed as human-readable decimal numbers; yet >>>>> for this allocation the number should be converted into a hexadecimal >>>>> notation. All IPv6 addresses are written in hexadecimal. (NNNN >>>>> represents the /16 allocation by IANA) >>>>>=20 >>>>> +----------------+--------------------+---------------------+ >>>>> | ASN in decemal | ASN in hexadecimal | Sample IP block | >>>>> +----------------+--------------------+---------------------+ >>>>> | AS1 | 1 | NNNN:0000:0001::/48 | >>>>> | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | >>>>> | AS29001 | 7149 | NNNN:0000:0001::/48 | >>>>> | AS393220 | 60004 | NNNN:0006:0004::/48 | >>>>> +----------------+--------------------+---------------------+ >>>>=20 >>>> What we had found in the old days of NSAP deployment (OSI) that encodin= g IPv4 addresses in BCD format in a hexadecimal longer address was extremely= useful for management. And as we have seen for IPv6, even embedding IPv4 do= tted decimal format was extremely useful. >>>>=20 >>>> Rather than having to build tools and make vendors do UI work, can we h= ave some form of BCD format for AS number. I know this will be difficult for= a 32-bit number but we could make it work for the ASNs that are <=3D 65535.= Just a thought. But even 10 million ASNS would only take up to 8 nibbles. A= nd since we won't and can't aggregate ASNs there is no point in making the e= ncoding a power-of-2 value. >>>=20 >>> I would oppose doing this. If we are going to do this (and I'm not entir= ely convinced that we should, but also not opposed), we should support the f= ull ASN space and doing so as a bit field is fine. I don't think any UI work= is required. Tools to convert 32-bit numbers from decimal to hex are alread= y widely available and the process is well understood. It's not like anyone w= ill have to do this conversion on a daily basis. >>>=20 >>> perl -e 'printf "%08x\n", ' will solve the problem= , for example. >>=20 >> Multiply by 1000 products coming out over different delivery times. Don't= underestimate the slowness of vendors. >>=20 >=20 > I'm not sure what you mean by this. Why would products coming out receive A= S Numbers? I think you are pursuing a use case that is not intended under my= interpretation of this draft and taking it to extremes that are beyond my c= omprehension. I mean each product would have to build a hex to decimal conversion capabili= ty in their UI.=20 >=20 >>>>> 5. ASN allocation >>>>>=20 >>>>> ASNs are allocated by RIRs and this RFC does not handle that arena. >>>>>=20 >>>>> ASNs defined as private ASNs MUST NOT use this scheme. The special >>>>> 16-bit ASN 23456 MUST NOT use this scheme. >>>>=20 >>>> I would let users do this with private ASes if they want to. Set a loca= l/global bit in your encoding so they can use it. If you don't they will ste= al ASN numbers which they should not do but will. >>>=20 >>> What local/global bit? >>=20 >> Add one is the suggestion. >>=20 >=20 > I expected that's where you were going. I think 16 bits is already a rathe= r short prefix for this use case. I don't believe that there is a sufficient= use case for a local/global bit. If you do, you need to make a better case f= or it than the above. Well explicitly encoding that the intent of the address is local is a good t= hing IMO.=20 >=20 > I would propose modifying section 5 of the draft to state, instead of "ASN= s MUST NOT use..." that "ASNs MUST NOT advertise..." and that any prefixes w= ithin the prefix allocated for this purpose must be considered "LOCAL addres= ses and given similar semantics to RFC-1918". Sounds good.=20 >=20 > I would not give the the semantics of ULA because of the likelihood of ove= rlap. >=20 >>>>> This mechanism is not expected to have any impact to the global >>>>> Internet routing table since existing policies in the RIR system >>>>> already readily provide for the allocation of provider-independent >>>>> IPv6 prefixes. Additionally, AS number holders are likely to be >>>>> multihomed entities which were going to be independently routed in >>>>> any case. Service Providers are, as always, not obligated to route >>>>> these IPv6 assignments and/or may establish conditions of service >>>>> which offset any additional routing cost. >>>>=20 >>>> I would say it would have the same impact as PI prefixes do today. >>>>=20 >>>=20 >>> Which means that this has no impact because it doesn't change the impact= vs. the current PI impact. >>=20 >> You miss the point. The problem needs to be solved. Saying this draft doe= sn't worsen it is not panacea. >>=20 >=20 > You miss the point. This draft is not intending to solve that problem and m= akes no claim in that respect. I understand that and I'm not saying the spec should fix it. I was replying t= o your comment only.=20 >=20 > I agree the problem needs to be solved. However, Solving the problem isn't= even within the purview of the v6ops working group. Raising it as an I realize that. But not let's process get in the way of having an open dial= ogue.=20 > issue in the discussion of this draft is only relevant to the extent that t= his draft makes the problem worse or prevents any proposed solution to the p= roblem from being effective. Since neither of those applies, there are no ro= uting table considerations applicable to this draft IMHO. >=20 > Owen Fine. Thanks for listening.=20 Dino= From farinacci@gmail.com Tue Feb 19 19:20:47 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9679621F887F; Tue, 19 Feb 2013 19:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 QrEe1ZfvL+b9; Tue, 19 Feb 2013 19:20:45 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0700621F8810; Tue, 19 Feb 2013 19:20:40 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so2614760pbc.30 for ; Tue, 19 Feb 2013 19:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=N4hwWzaV6pdkj4kRL75CYppYYpByKNuGnL/PrpGoX9A=; b=Nh3DnlR/5ZVk+i2WWUc/YOz1oGApiy1mHYdE2Dre8+7QQCaoe82A3Wc7imUw0QZ4Ug 7sJ60iVsyzG29UcaXeEmqPaEBHBv6mgbrBFNJjZdLk4M4My5L/6ekDHHgWgH1V74jMT+ l3dM5OmNWBwCGuiFgyf99Vx2TywWNh2j+qQsmYMCFjazE45dKwHouTIuSssD9V4m3H/R sporNgwXpkhy+73jWDbIjaSSQaS/lVuuppiRt3Aq/FiFLZ+aPz/lpl36MMmJSdyAbAlU scyiYzKkJ5jd9UIPk3/jW2ofBynkITJhOzm5h7Xkkw2jXvfmbbU4qP9mkArEt41I5aQA qc1w== X-Received: by 10.68.10.227 with SMTP id l3mr16809485pbb.100.1361330440728; Tue, 19 Feb 2013 19:20:40 -0800 (PST) Received: from [192.168.1.9] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPS id e6sm109514760paw.16.2013.02.19.19.20.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 19:20:39 -0800 (PST) References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2AC77963-D39E-4026-A0A7-01CCCE2026D9@gmail.com> X-Mailer: iPhone Mail (10B143) From: Dino Farinacci Date: Tue, 19 Feb 2013 19:20:37 -0800 To: Owen DeLong Cc: "Martin J. Levy" , "mpounsett@afilias.info" , "v6ops@ietf.org" , "lisp@ietf.org list list" Subject: Re: [lisp] [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 20 Feb 2013 03:20:47 -0000 > A better solution (IMHO) would be to have a 32 bit field added to the prot= ocol to contain the destination ASN embedded in the packet header. Unfortuna= tely, this is a major change to every system and would basically be the next= protocol version (though at least IPv6 and IPv{N} would be interchangeably c= ompatible with each other except for the MTU issues). Right - a non-starter.=20 LISP is certainly not a non-starter. More specifically, it is a incremental-= starter.=20 If you want to find out, get on the LISP pilot network. See www.lisp4.net, e= rr I mean www.lisp6.net for you. :-) Dino From nick@inex.ie Tue Feb 19 10:07:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F9321F8E59; Tue, 19 Feb 2013 10:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-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 5He936JEkJE4; Tue, 19 Feb 2013 10:07:06 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5267821F8E4C; Tue, 19 Feb 2013 10:07:04 -0800 (PST) X-Envelope-To: lisp@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1JI4IIM036666 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 19 Feb 2013 18:04:18 GMT (envelope-from nick@inex.ie) Message-ID: <5123BF44.9020302@inex.ie> Date: Tue, 19 Feb 2013 18:07:00 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dino Farinacci References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> In-Reply-To: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Feb 2013 09:12:21 -0800 Cc: v6ops@ietf.org, "lisp@ietf.org list list" Subject: Re: [lisp] [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 19 Feb 2013 18:07:14 -0000 On 19/02/2013 17:12, Dino Farinacci wrote: >> not forced to use this allocation and can ignore this completely. >> Availability of the /48 assignment via this mechanism does not change >> existing mechanisms for obtaining IPv6 assignments through the >> existing RIR (Regional Internet Registry) or LIR (Local Internet >> Registry) mechanisms. > > This is a good idea PROVIDED these prefixes are not injected into the > core routing system. I don't think that this is a realistic expectation. If people get blocks of this form, they will turn up in the dfz for sure. Nick From owen@delong.com Tue Feb 19 12:36:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD6221F87B6; Tue, 19 Feb 2013 12:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.795 X-Spam-Level: * X-Spam-Status: No, score=1.795 tagged_above=-999 required=5 tests=[AWL=-3.206, BAYES_50=0.001, GB_SUMOF=5] 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 lAHgGT4blDuV; Tue, 19 Feb 2013 12:36:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B349421F8860; Tue, 19 Feb 2013 12:36:05 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1JKYwuM019292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2013 12:34:58 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1JKYwuM019292 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361306099; bh=HoH4sGiMxvkVaMjcNSSfZefX+fI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iUCtZwR+7XEcdZM4VNalRwEYY0BRtjpmS8xiNWZViSq7vpUFE35Uk4cQfKX94Rxlt kIjD1i489hEcZvnG22/1CKG6NY+MwEjsdTl/on3UI4bAj1xy0Ko5azF0J0/Q1aZhXy zqtCAlSlpWdJHmRx/t6lv2uKbZQssPOfROqfichQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> Date: Tue, 19 Feb 2013 12:34:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Tue, 19 Feb 2013 12:34:59 -0800 (PST) X-Mailman-Approved-At: Wed, 20 Feb 2013 09:12:21 -0800 Cc: "Martin J. Levy" , mpounsett@afilias.info, v6ops@ietf.org, "lisp@ietf.org list list" Subject: Re: [lisp] [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 19 Feb 2013 20:36:09 -0000 >> Abstract >>=20 >> This document provides a methodology for automatically allocating >> IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] = and >> are either single-homed or multi-homed [BARBER2011]. The automatic >> allocation is taken from a specific /16 block assigned by IANA for >> this purpose. >>=20 >> Networks that require more than this single /48 can still request >> additional allocations via the existing RIR process. Networks are >> not forced to use this allocation and can ignore this completely. >> Availability of the /48 assignment via this mechanism does not = change >> existing mechanisms for obtaining IPv6 assignments through the >> existing RIR (Regional Internet Registry) or LIR (Local Internet >> Registry) mechanisms. >=20 > This is a good idea PROVIDED these prefixes are not injected into the = core routing system. >=20 The prefixes should not be automatically injected, but I think = prohibiting such injection would decrease the utility of this addressing and that there = is no good reason to have such a prohibition. >> The sum of the bits in the IANA allocated /16 prefix plus the 32 = bits >> of the ASN plus the /48 of user defined usage adds up to 128 bits. >>=20 >> +------+----------------------+ >> | Bits | Usage | >> +------+----------------------+ >> | 16 | IANA provided prefix | >> | 32 | ASN | >> | 80 | User defined | >> | 128 | TOTAL | >> +------+----------------------+ >>=20 >> Table 1: Address space math >=20 > Can there be some ASN values assigned to signify "no one owns the = /48"? So we can have even more independent assignments. For the purposes = of LISP, we don't care if these address don't perfect aggregate because = these addresses will go into the LISP mapping database system which may = not need to aggregate since the RLOCs associated with the prefixes will = be different anyways (and therefore can't aggregate or compress). Wouldn't the private ASN range already effectively do this? >> The end network can allocate out of the assigned /48 as needed. It >> is assumed that the end network will use this allocation for global >> routing; however the network may choose to not announce this >> allocation. >=20 > Okay, so lets use an example to see how this can be used. Let's say a = /80 comes out of Verizon's space: >=20 > (1) Does Verizon allocate say a /64 to each of BMW, Mercedes, and Ford = so they can use Vehicle ID Numbers for the rest of the allocation for = their automobile EID assignments? >=20 First of all, you can't pull a /64 out of a /80 so I think you mean a = /48 assigned to $PROVIDER. In that case, I see no reason $AUTO_MAKER1, $AUTO_MAKER2, etc. could not = receive /64s from $PROVIDER for that purpose, but, I would propose that = such use is not a very good idea from the auto maker's perspective. Once = you embed one of these addresses into an automobile and sell it, you are = locked into a contract with Verizon until you can readdress all such = cars. > (2) Or do the RIRs believe they need to assign a /48 with distinct = ASNs to each of BMW, Mercedes and Ford so they have more bits to embed = VIN numbers? I don't believe that the RIRs are involved in the addresses contemplated = under this draft. I think permanently assigned addresses related to VINS are, in general, = a bad idea. I don't see any advantage to tying the semantics of the two = systems to each other. If anything, the development of LISP is the = result of failing to separate the semantics of end-point addressing from = the semantics of topological location. Combining the semantics of = end-point addressing and VINs seems even more far-fetched to me. > (3) What if these auto manufactures don't want to allocate ASN numbers = because they will never have any intent to run BGP either in the cars, = POPs, data centers? >=20 I don't see anything in this draft that would preclude them from using a = different source of addressing. I confess, to some extent, I wonder if this is a solution in search of a = problem. >> If any route is announced from this allocation, any prefixes more >> specific than the allocated /48 must not be propagated in to the >> global IPv6 routing table. This is to prevent the IPv6 routing = table >=20 > This is fine authors, but if you are multi-home, it will require each = system at the site to possess multiple addresses one from each attached = ASN if they do not have their own prefix but get it out of their = provider. >=20 > If you say that this prefix will never be associated with a provider's = attachment point, then I'm okay with that and agree. >=20 Either I misunderstand what you are saying, or, you have erred. I'm not = sure which. If a site uses a /64 from within this /48 to attach to each upstream, = the more specific does not need to propagate beyond the immediate = upstream router, so it still wouldn't be announced into the global = routing table. >> from becoming too large. Therefore, a site which uses this >> allocation MUST NOT advertise a more specific than the allocated = /48 >> routing prefix. All native IPv6 network operators MUST filter out >>=20 >>=20 >>=20 >> Levy & Pounsett Expires July 28, 2013 [Page = 3] >> Internet-Draft Auto allocation mechanism for IPv6 blocks January = 2013 >>=20 >>=20 >> and discard any routing prefix advertisements longer than /48 from >> within this /16 allocation. >=20 > Can you explicitly state then that this prefix for use as a PROVIDER = INDEPENDENT prefix. Thanks. >=20 I think that is inherent in the definition of the prefix. Can you = clarify why you think this statement is necessary? >> ASNs are normally expressed as human-readable decimal numbers; yet >> for this allocation the number should be converted into a = hexadecimal >> notation. All IPv6 addresses are written in hexadecimal. (NNNN >> represents the /16 allocation by IANA) >>=20 >> +----------------+--------------------+---------------------+ >> | ASN in decemal | ASN in hexadecimal | Sample IP block | >> +----------------+--------------------+---------------------+ >> | AS1 | 1 | NNNN:0000:0001::/48 | >> | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | >> | AS29001 | 7149 | NNNN:0000:0001::/48 | >> | AS393220 | 60004 | NNNN:0006:0004::/48 | >> +----------------+--------------------+---------------------+ >=20 > What we had found in the old days of NSAP deployment (OSI) that = encoding IPv4 addresses in BCD format in a hexadecimal longer address = was extremely useful for management. And as we have seen for IPv6, even = embedding IPv4 dotted decimal format was extremely useful. >=20 > Rather than having to build tools and make vendors do UI work, can we = have some form of BCD format for AS number. I know this will be = difficult for a 32-bit number but we could make it work for the ASNs = that are <=3D 65535. Just a thought. But even 10 million ASNS would only = take up to 8 nibbles. And since we won't and can't aggregate ASNs there = is no point in making the encoding a power-of-2 value. I would oppose doing this. If we are going to do this (and I'm not = entirely convinced that we should, but also not opposed), we should = support the full ASN space and doing so as a bit field is fine. I don't = think any UI work is required. Tools to convert 32-bit numbers from = decimal to hex are already widely available and the process is well = understood. It's not like anyone will have to do this conversion on a = daily basis. perl -e 'printf "%08x\n", ' will solve the = problem, for example. >=20 >> 5. ASN allocation >>=20 >> ASNs are allocated by RIRs and this RFC does not handle that arena. >>=20 >> ASNs defined as private ASNs MUST NOT use this scheme. The special >> 16-bit ASN 23456 MUST NOT use this scheme. >=20 > I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. What local/global bit? Institution of a local/global bit would require a /15 instead of a /16. = I'm not convinced that this is worthy of 1/65536 of the IPv6 address = space, let alone 1/32768. >> 6. BGP Filtering and Validation >>=20 >> Filtering would be a simple case of mapping the final ASN in a path >> to the prefix in an exact bit-order match. >>=20 >> For example; the prefix NNNN:0000:1B1B::/48 should only be seen as >> announced from AS6939 (6939 equals 0x1B1B in hex). Networks would >> have their upstream transit providers add this /48 prefix to their >> existing inbound BGP route filters. >=20 > IMO, these addresses should stay out of underlying routing. If you = want to build a mobile Internet for IPv6, these sort of addresses are = identity addresses and not topological. >=20 > Let's not perpetuate the non-sense of the past. >=20 I don't see any reason to limit these addresses to that single use case. For example, assume an SMB organization that just wants to use these = addresses for general multi homed connectivity. In this case, they would = only need to obtain an ASN. They would not need to apply for a prefix, = they could simply advertise this one. >> 10. Routing Table Impact >>=20 >> This mechanism is not expected to have any impact to the global >> Internet routing table since existing policies in the RIR system >> already readily provide for the allocation of provider-independent >> IPv6 prefixes. Additionally, AS number holders are likely to be >> multihomed entities which were going to be independently routed in >> any case. Service Providers are, as always, not obligated to route >> these IPv6 assignments and/or may establish conditions of service >> which offset any additional routing cost. >=20 > I would say it would have the same impact as PI prefixes do today. >=20 Which means that this has no impact because it doesn't change the impact = vs. the current PI impact. Owen From owen@delong.com Tue Feb 19 17:10:54 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEF421F8758; Tue, 19 Feb 2013 17:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-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 8brDuEZQUBwH; Tue, 19 Feb 2013 17:10:53 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1D21F874E; Tue, 19 Feb 2013 17:10:52 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1K19sM9001429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2013 17:09:54 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1K19sM9001429 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361322595; bh=8enGPfNjgb3v1TM3JqHrfQwdGYM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TPWk+Cod54ZRln4IfH14AeyTMBzgBnGAzPR3TKpzWX6RpXbZRYsRbgj1vgG7D/i+0 Tk1qVJ9J1A2Fzy6IX02sjUFdfZiLN+y6Fij1ruKA6SmS55BZvNAFSB/J9FubZP+0lH D6++dFiaMd1ZowVefXdqnfXtIvjCCU6O9sRjCJNM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> Date: Tue, 19 Feb 2013 17:09:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 19 Feb 2013 17:09:55 -0800 (PST) X-Mailman-Approved-At: Wed, 20 Feb 2013 09:12:21 -0800 Cc: "Martin J. Levy" , mpounsett@afilias.info, v6ops@ietf.org, "lisp@ietf.org list list" Subject: Re: [lisp] [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 20 Feb 2013 01:10:54 -0000 >> I think permanently assigned addresses related to VINS are, in = general, a bad idea. I don't see any advantage to tying the semantics of = the two systems to each other. If anything, the development of LISP is = the result of failing to separate the semantics of end-point addressing = from the semantics of topological location. Combining the semantics of = end-point addressing and VINs seems even more far-fetched to me. >=20 > An EID is opaque and not used by the protocol stack just by humans if = they choose to look at them.=20 >=20 One of us is misunderstanding the other. My point is that using IPv6 = address space to number things that are not IPv6 hosts is, IMHO, a bad = idea. >>> (3) What if these auto manufactures don't want to allocate ASN = numbers because they will never have any intent to run BGP either in the = cars, POPs, data centers? >>>=20 >>=20 >> I don't see anything in this draft that would preclude them from = using a different source of addressing. >>=20 >> I confess, to some extent, I wonder if this is a solution in search = of a problem. >=20 > I know there are customers that want to reduce the number of total = databases they have to manage at all layers of the stack. >=20 All well and good, but I do not support turning IPv6 addresses into the = primary key for everything in world anyone wants to identify in any = namespace. If that's not what your sentence above means, then I'm afraid = I misunderstand your meaning. Again, I do not support the idea of using IPv6 numbers as a mechanism = for identifying anything that isn't an IPv6 host and I do not support = tying semantics other than the host end-system identifier for packet = delivery to IPv6 addresses. I think that past experience has = demonstrated that both of these practices create more problems than they = solve. >>>> If any route is announced from this allocation, any prefixes more >>>> specific than the allocated /48 must not be propagated in to the >>>> global IPv6 routing table. This is to prevent the IPv6 routing = table >>>=20 >>> This is fine authors, but if you are multi-home, it will require = each system at the site to possess multiple addresses one from each = attached ASN if they do not have their own prefix but get it out of = their provider. >>>=20 >>> If you say that this prefix will never be associated with a = provider's attachment point, then I'm okay with that and agree. >>>=20 >>=20 >> Either I misunderstand what you are saying, or, you have erred. I'm = not sure which. >>=20 >> If a site uses a /64 from within this /48 to attach to each upstream, = the more specific does not need to propagate beyond the immediate = upstream router, so it still wouldn't be announced into the global = routing table. >=20 > There is still PI flat routing on the scale of number of sites that = use this prefix. That is the point, there is no attempt to improve the = route table scaling problem. I'm not saying this draft should, just = speaking generally. I think that concern is entirely orthogonal to this draft. My point is = that for every PI prefix that gets advertised from this space, it should represent a PI = prefix from RIR space that does not get advertised, so it is a net equivalence in terms = of the routing table. Thus, I would anticipate that this draft has no impact on = the routing table. OTOH, the whole way we do IDR is broken and we should have fixed it as = part of the IPv6 development process. Unfortunately, we (IETF) chose to punt = on that and go down all kinds of other less important roads. However, this issue is = really not part of the discussion of this draft. >>>> from becoming too large. Therefore, a site which uses this >>>> allocation MUST NOT advertise a more specific than the allocated = /48 >>>> routing prefix. All native IPv6 network operators MUST filter out >>>>=20 >>>>=20 >>>>=20 >>>> Levy & Pounsett Expires July 28, 2013 = [Page 3] >>>> Internet-Draft Auto allocation mechanism for IPv6 blocks January = 2013 >>>>=20 >>>>=20 >>>> and discard any routing prefix advertisements longer than /48 from >>>> within this /16 allocation. >>>=20 >>> Can you explicitly state then that this prefix for use as a PROVIDER = INDEPENDENT prefix. Thanks. >>>=20 >>=20 >> I think that is inherent in the definition of the prefix. Can you = clarify why you think this >> statement is necessary? >=20 > I want it explicit so there is no layers of ownership of the prefix. >=20 I'm not sure how stating that this prefix is PROVIDER INDEPENDENT = conveys any ownership or lack thereof. >>>> ASNs are normally expressed as human-readable decimal numbers; yet >>>> for this allocation the number should be converted into a = hexadecimal >>>> notation. All IPv6 addresses are written in hexadecimal. (NNNN >>>> represents the /16 allocation by IANA) >>>>=20 >>>> +----------------+--------------------+---------------------+ >>>> | ASN in decemal | ASN in hexadecimal | Sample IP block | >>>> +----------------+--------------------+---------------------+ >>>> | AS1 | 1 | NNNN:0000:0001::/48 | >>>> | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | >>>> | AS29001 | 7149 | NNNN:0000:0001::/48 | >>>> | AS393220 | 60004 | NNNN:0006:0004::/48 | >>>> +----------------+--------------------+---------------------+ >>>=20 >>> What we had found in the old days of NSAP deployment (OSI) that = encoding IPv4 addresses in BCD format in a hexadecimal longer address = was extremely useful for management. And as we have seen for IPv6, even = embedding IPv4 dotted decimal format was extremely useful. >>>=20 >>> Rather than having to build tools and make vendors do UI work, can = we have some form of BCD format for AS number. I know this will be = difficult for a 32-bit number but we could make it work for the ASNs = that are <=3D 65535. Just a thought. But even 10 million ASNS would only = take up to 8 nibbles. And since we won't and can't aggregate ASNs there = is no point in making the encoding a power-of-2 value. >>=20 >> I would oppose doing this. If we are going to do this (and I'm not = entirely convinced that we should, but also not opposed), we should = support the full ASN space and doing so as a bit field is fine. I don't = think any UI work is required. Tools to convert 32-bit numbers from = decimal to hex are already widely available and the process is well = understood. It's not like anyone will have to do this conversion on a = daily basis. >>=20 >> perl -e 'printf "%08x\n", ' will solve the = problem, for example. >=20 > Multiply by 1000 products coming out over different delivery times. = Don't underestimate the slowness of vendors. >=20 I'm not sure what you mean by this. Why would products coming out = receive AS Numbers? I think you are pursuing a use case that is not = intended under my interpretation of this draft and taking it to extremes = that are beyond my comprehension. >>>> 5. ASN allocation >>>>=20 >>>> ASNs are allocated by RIRs and this RFC does not handle that arena. >>>>=20 >>>> ASNs defined as private ASNs MUST NOT use this scheme. The special >>>> 16-bit ASN 23456 MUST NOT use this scheme. >>>=20 >>> I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. >>=20 >> What local/global bit? >=20 > Add one is the suggestion. >=20 I expected that's where you were going. I think 16 bits is already a = rather short prefix for this use case. I don't believe that there is a = sufficient use case for a local/global bit. If you do, you need to make = a better case for it than the above. I would propose modifying section 5 of the draft to state, instead of = "ASNs MUST NOT use..." that "ASNs MUST NOT advertise..." and that any = prefixes within the prefix allocated for this purpose must be considered = "LOCAL addresses and given similar semantics to RFC-1918". I would not give the the semantics of ULA because of the likelihood of = overlap. >>>> This mechanism is not expected to have any impact to the global >>>> Internet routing table since existing policies in the RIR system >>>> already readily provide for the allocation of provider-independent >>>> IPv6 prefixes. Additionally, AS number holders are likely to be >>>> multihomed entities which were going to be independently routed in >>>> any case. Service Providers are, as always, not obligated to route >>>> these IPv6 assignments and/or may establish conditions of service >>>> which offset any additional routing cost. >>>=20 >>> I would say it would have the same impact as PI prefixes do today. >>>=20 >>=20 >> Which means that this has no impact because it doesn't change the = impact vs. the current PI impact. >=20 > You miss the point. The problem needs to be solved. Saying this draft = doesn't worsen it is not panacea. >=20 You miss the point. This draft is not intending to solve that problem = and makes no claim in that respect. I agree the problem needs to be solved. However, Solving the problem = isn't even within the purview of the v6ops working group. Raising it as = an issue in the discussion of this draft is only relevant to the extent = that this draft makes the problem worse or prevents any proposed = solution to the problem from being effective. Since neither of those = applies, there are no routing table considerations applicable to this = draft IMHO. Owen From owen@delong.com Tue Feb 19 18:50:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31EB21F87FF; Tue, 19 Feb 2013 18:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.207 X-Spam-Level: X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_40=-0.185, NO_RELAYS=-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 wkPfr0sDkoe8; Tue, 19 Feb 2013 18:50:51 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57421F86EA; Tue, 19 Feb 2013 18:50:50 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1K2o6L8004216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Feb 2013 18:50:06 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1K2o6L8004216 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361328606; bh=yOer/efuQUNmH+jE1iAcXmaoucc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ilHwoigobpVbCipl1Z2khxS4lfT035NucMgSpjgmlvie0d5yNqOBTVaDqvyKiES0k vGMTsoTzi+QVR47EH28aJzaTORXTlVJYSyNWrRTsCZpqg8v8x4BcDbcSm7fds+pR+L ssn3u0xfFxjywGdYfpq8XuTeNkkLDo4LDWtMzkS0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Owen DeLong In-Reply-To: Date: Tue, 19 Feb 2013 18:50:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 19 Feb 2013 18:50:06 -0800 (PST) X-Mailman-Approved-At: Wed, 20 Feb 2013 09:12:21 -0800 Cc: "Martin J. Levy" , "mpounsett@afilias.info" , "v6ops@ietf.org" , "lisp@ietf.org list list" Subject: Re: [lisp] [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 20 Feb 2013 02:50:53 -0000 On Feb 19, 2013, at 18:16 , Dino Farinacci wrote: > On Feb 19, 2013, at 5:09 PM, Owen DeLong wrote: >=20 >>>> I think permanently assigned addresses related to VINS are, in = general, a bad idea. I don't see any advantage to tying the semantics of = the two systems to each other. If anything, the development of LISP is = the result of failing to separate the semantics of end-point addressing = from the semantics of topological location. Combining the semantics of = end-point addressing and VINs seems even more far-fetched to me. >>>=20 >>> An EID is opaque and not used by the protocol stack just by humans = if they choose to look at them.=20 >>>=20 >>=20 >> One of us is misunderstanding the other. My point is that using IPv6 = address space to number things that are not IPv6 hosts is, IMHO, a bad = idea. >=20 > The automobiles are IPv6 hosts.=20 It is unlikely that any network will ever be {all vehicles with VIN is a = member of [RANGE]} other than possibly a brief factory test. Thus, I do not believe it is appropriate to permanently associate a = prefix with a collection of vehicles based on their VIN. >=20 >>=20 >>>>> (3) What if these auto manufactures don't want to allocate ASN = numbers because they will never have any intent to run BGP either in the = cars, POPs, data centers? >>>>>=20 >>>>=20 >>>> I don't see anything in this draft that would preclude them from = using a different source of addressing. >>>>=20 >>>> I confess, to some extent, I wonder if this is a solution in search = of a problem. >>>=20 >>> I know there are customers that want to reduce the number of total = databases they have to manage at all layers of the stack. >>>=20 >>=20 >> All well and good, but I do not support turning IPv6 addresses into = the primary key for everything in world anyone wants to identify in any = namespace. If that's not what your sentence above means, then I'm afraid = I misunderstand your meaning. >=20 > It is none of your business how sites use their addresses. That is the = whole point of ID/Locator separation.=20 >=20 > The EID is opaque to the network but may have meaning to the sites who = communicate with each other within that EID-prefix.=20 >=20 I do not support allocating globally unique prefixes for things that are = not networks. Perhaps that will better explain my position. I think that overloading the IPv6 prefix space with semantics for = arbitrary collections of things is a really bad idea that has tremendous = potential to consume vast amounts of addresses while yielding no network = benefit in return. Will it exhaust the IPv6 space immediately, probably not. Could we = easily exhaust the ASN space if we start promoting the idea of claiming = ASNs to support this? Yeah, we could probably burn 4 billion ASNs that = way without too much trouble. >> Again, I do not support the idea of using IPv6 numbers as a mechanism = for identifying anything that isn't an IPv6 host and I do not support = tying semantics other than the host end-system identifier for packet = delivery to IPv6 addresses. I think that past experience has = demonstrated that both of these practices create more problems than they = solve. >=20 > See above. Tell me if you still disagree and if so we will have to = disagree. This is where IPv6 could be useful. What does IPv6 have that = IPv4 doesn't? Really only longer addresses.=20 >=20 I disagree, but at least I now fully understand what you're trying to = inflict on the world. As to the answer to your other question: SLAAC 6-lowpan Improved header structure Extension headers Cleaner IPSEC implementation I'm sure there's more, but I don't want to get too far down yet another = orthogonal discussion. >>=20 >>>>>> If any route is announced from this allocation, any prefixes more >>>>>> specific than the allocated /48 must not be propagated in to the >>>>>> global IPv6 routing table. This is to prevent the IPv6 routing = table >>>>>=20 >>>>> This is fine authors, but if you are multi-home, it will require = each system at the site to possess multiple addresses one from each = attached ASN if they do not have their own prefix but get it out of = their provider. >>>>>=20 >>>>> If you say that this prefix will never be associated with a = provider's attachment point, then I'm okay with that and agree. >>>>>=20 >>>>=20 >>>> Either I misunderstand what you are saying, or, you have erred. I'm = not sure which. >>>>=20 >>>> If a site uses a /64 from within this /48 to attach to each = upstream, the more specific does not need to propagate beyond the = immediate upstream router, so it still wouldn't be announced into the = global routing table. >>>=20 >>> There is still PI flat routing on the scale of number of sites that = use this prefix. That is the point, there is no attempt to improve the = route table scaling problem. I'm not saying this draft should, just = speaking generally. >>=20 >> I think that concern is entirely orthogonal to this draft. My point = is that for every PI >> prefix that gets advertised from this space, it should represent a PI = prefix from RIR >> space that does not get advertised, so it is a net equivalence in = terms of the >> routing table. Thus, I would anticipate that this draft has no impact = on the routing >> table. >=20 > Okay fine.=20 >=20 >> OTOH, the whole way we do IDR is broken and we should have fixed it = as part >> of the IPv6 development process. Unfortunately, we (IETF) chose to = punt on that and >> go down all kinds of other less important roads. However, this issue = is really >> not part of the discussion of this draft. >=20 > If locator/ID separation is used then this is helped and you make = multi-homing easier at the same time as making address management in = every host.=20 >=20 At the price of converting every connection into a tunnel with = associated MTU penalties. A better solution (IMHO) would be to have a 32 bit field added to the = protocol to contain the destination ASN embedded in the packet header. = Unfortunately, this is a major change to every system and would = basically be the next protocol version (though at least IPv6 and IPv{N} = would be interchangeably compatible with each other except for the MTU = issues). > Look how complicated the home networking proposals are? Agreed, it's ridiculous. We should, instead, recognize that we dropped = the ball in IPv6 design and do something slightly different before the = routing table explodes. We have several years beyond IPv6 deployment to = address that issue, IMHO. For now, I'd rather focus on actual = operational issues related to IPv6 deployment and revisit solving the = routing table problem later. >> I'm not sure what you mean by this. Why would products coming out = receive AS Numbers? I think you are pursuing a use case that is not = intended under my interpretation of this draft and taking it to extremes = that are beyond my comprehension. >=20 > I mean each product would have to build a hex to decimal conversion = capability in their UI.=20 1. Libraries already contain these and nobody is hand-coding = systems in assembly language any more. 2. This is seriously not difficult and most products duplicate = enough UI components from other products that it would rapidly become a boilerplate component in the = developer tool kit at each organization if it hasn't already. >=20 >>=20 >>>>>> 5. ASN allocation >>>>>>=20 >>>>>> ASNs are allocated by RIRs and this RFC does not handle that = arena. >>>>>>=20 >>>>>> ASNs defined as private ASNs MUST NOT use this scheme. The = special >>>>>> 16-bit ASN 23456 MUST NOT use this scheme. >>>>>=20 >>>>> I would let users do this with private ASes if they want to. Set a = local/global bit in your encoding so they can use it. If you don't they = will steal ASN numbers which they should not do but will. >>>>=20 >>>> What local/global bit? >>>=20 >>> Add one is the suggestion. >>>=20 >>=20 >> I expected that's where you were going. I think 16 bits is already a = rather short prefix for this use case. I don't believe that there is a = sufficient use case for a local/global bit. If you do, you need to make = a better case for it than the above. >=20 > Well explicitly encoding that the intent of the address is local is a = good thing IMO.=20 >=20 Which I believe my suggestion below would cover... >>=20 >> I would propose modifying section 5 of the draft to state, instead of = "ASNs MUST NOT use..." that "ASNs MUST NOT advertise..." and that any = prefixes within the prefix allocated for this purpose must be considered = "LOCAL addresses and given similar semantics to RFC-1918". >=20 > Sounds good.=20 >=20 Zero bit cost here.=20 Owen From damien.saucez@gmail.com Wed Feb 20 13:05:47 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BC621E803F for ; Wed, 20 Feb 2013 13:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pepN+JF3EWgy for ; Wed, 20 Feb 2013 13:05:46 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id D72D321E803A for ; Wed, 20 Feb 2013 13:05:45 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hi8so6744350wib.1 for ; Wed, 20 Feb 2013 13:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=bRzU/TxaA6XUAfTi+J0gMjDQwxOC8niOoeILolhud5c=; b=IIg3BN5bepnt6Pa0uBvDCikyldOyNh8U4F0UWkBMMzRFVBD03h799K3/fPLsYxkgIE mYQCnnYkRYICFuTy/D8bGyKeJw8hpIupki1wfIMke8yigoHTIepQhtQF9zQNhb11n9FP 67VMIE83yi5u5asLrqGaeg3gQOorAXWjc0z7VPCWt/6rbzuJJ4Oj+jFa6g53EV8nZfvF YxDsyTrQBK+eEoI11xwvosTWT24dy12/5zili7MlzvfGKXds1TABOV3m+0yQ/+WRf76v m6cdDf1pPtBR2vQ3AyMwTQGNJIe5AqQhdwr3ocToT3a6yWnzNxllGwNMY1xm/aP67aTA uKdw== X-Received: by 10.180.92.129 with SMTP id cm1mr37524854wib.10.1361394343663; Wed, 20 Feb 2013 13:05:43 -0800 (PST) Received: from [172.16.139.253] (42.146.77.86.rev.sfr.net. [86.77.146.42]) by mx.google.com with ESMTPS id ay10sm10631324wib.3.2013.02.20.13.05.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 13:05:42 -0800 (PST) From: Damien Saucez Content-Type: multipart/alternative; boundary="Apple-Mail=_CBD434B3-1550-41FB-B2A7-E8AA9AE41522" Date: Wed, 20 Feb 2013 22:05:41 +0100 References: <20130220204745.27254.43192.idtracker@ietfa.amsl.com> To: LISP mailing list list Message-Id: 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-impact-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:05:47 -0000 --Apple-Mail=_CBD434B3-1550-41FB-B2A7-E8AA9AE41522 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-saucez-lisp-impact-01.txt > Date: 20 Feb 2013 21:47:45 GMT+01:00 > To: damien.saucez@inria.fr > Cc: fcoras@ac.upc.edu, luigi.iannone@telecom-paristech.fr >=20 >=20 > A new version of I-D, draft-saucez-lisp-impact-01.txt > has been successfully submitted by Damien Saucez and posted to the > IETF repository. >=20 > Filename: draft-saucez-lisp-impact > Revision: 01 > Title: LISP Impact > Creation date: 2013-02-20 > Group: Individual Submission > Number of pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-saucez-lisp-impact-01.txt > Status: = http://datatracker.ietf.org/doc/draft-saucez-lisp-impact > Htmlized: = http://tools.ietf.org/html/draft-saucez-lisp-impact-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-saucez-lisp-impact-01 >=20 > Abstract: > The Locator/Identifier Separation Protocol (LISP) aims at improving > the Internet scalability properties leveraging on three simple > principles: address role separation, encapsulation, and mapping. In > this document, based on implementation, deployment, and theoretical > studies, we discuss the impact that deployment of LISP has on both > the Internet in general and for the end-users in particular. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_CBD434B3-1550-41FB-B2A7-E8AA9AE41522 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: New Version Notification for = draft-saucez-lisp-impact-01.txt
Date: 20 Feb 2013 = 21:47:45 GMT+01:00


A new version of I-D, = draft-saucez-lisp-impact-01.txt
has been successfully submitted by = Damien Saucez and posted to the
IETF = repository.

Filename: = draft-saucez-lisp-impact
Revision: 01
Title: LISP = Impact
Creation date: 2013-02-20
Group: = Individual Submission
Number of pages: 14
URL: =             http://www.ietf.org/internet-drafts/draft-saucez-lisp-impact-01.txt=
Status:          http://d= atatracker.ietf.org/doc/draft-saucez-lisp-impact
Htmlized: =        http://too= ls.ietf.org/html/draft-saucez-lisp-impact-01
Diff: =            ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-saucez-lisp-impact-01

Ab= stract:
  The Locator/Identifier Separation Protocol = (LISP) aims at improving
  the Internet scalability = properties leveraging on three simple
  principles: = address role separation, encapsulation, and mapping.  In
=   this document, based on implementation, deployment, and = theoretical
  studies, we discuss the impact that = deployment of LISP has on both
  the Internet in general = and for the end-users in particular.




The IETF = Secretariat


= --Apple-Mail=_CBD434B3-1550-41FB-B2A7-E8AA9AE41522-- From cheng.li2@zte.com.cn Fri Feb 22 01:34:37 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7268221F8E65 for ; Fri, 22 Feb 2013 01:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.795 X-Spam-Level: X-Spam-Status: No, score=-97.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 tmQXoZkt-t6D for ; Fri, 22 Feb 2013 01:34:36 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 121FD21F8DCA for ; Fri, 22 Feb 2013 01:34:36 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 785C312AC795 for ; Fri, 22 Feb 2013 17:28:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r1M9Y6Qh018619 for ; Fri, 22 Feb 2013 17:34:06 +0800 (GMT-8) (envelope-from cheng.li2@zte.com.cn) To: LISP mailing list list MIME-Version: 1.0 X-KeepSent: B0085846:FF9A4966-48257B1A:0033F2A9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: cheng.li2@zte.com.cn Date: Fri, 22 Feb 2013 17:33:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-02-22 17:34:01, Serialize complete at 2013-02-22 17:34:01 Content-Type: multipart/alternative; boundary="=_alternative 00349FC948257B1A_=" X-MAIL: mse02.zte.com.cn r1M9Y6Qh018619 Subject: [lisp] Commen Requests for draft-cheng-lisp-shdht-03 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, 22 Feb 2013 09:34:37 -0000 This is a multipart message in MIME format. --=_alternative 00349FC948257B1A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQWxsLCANCg0KSSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWNoZW5n LWxpc3Atc2hkaHQuDQoNClRoaXMgZHJhZnQgc3BlY2lmaWVzIGhvdyB0byBidWlsZCBhIGRpc3Ry aWJ1dGVkIG1hcHBpbmcgZGF0YWJhc2UgYmFzZWQgb24gDQpzaW5nbGUtaG9wIA0KREhUIGZvciBM SVNQLWxpa2UgYXJjaGl0ZWN0dXJlLg0KDQpXZSBkaWQgYSBwcmVzZW50YXRpb24gb24gODR0aCBJ RVRGIG1lZXRpbmcsIGFuZCBnb3QgbWFueSB2YWx1YWJsZSANCnN1Z2dlc3Rpb25zLg0KDQpJbiB0 aGlzIG5ldyB2ZXJzaW9uLCB3ZSBzcGVjaWZpZWQgdGhhdCBNYXAtUmVzb2x2ZXIgYW5kIE1hcC1T ZXJ2ZXIgY291bGQgDQpiZSBjb2xsb2NhdGVkIA0Kb250byBTSERIVCBOb2RlcywgW0xJU1AtU0hE SFRdIGFyZSBub3QgY29uZmxpY3RlZCB3aXRoIFtMSVNQLU1TXSAoU2VjdGlvbiANCjQpLiANCkZ1 cnRoZXJtb3JlLCB3ZSBzcGVjaWZpZWQgaG93IHRvIGRlcGxveW1lbnQgYSBkb21haW4gTElTUCBT SERIVCBvdmVybGF5LCANCndoaWNoIHdpbGwgDQptYWtlIHRoZSB3aG9sZSBkYXRhYmFzZSBwZXJm b3JtIGJldHRlciBzY2FsYWJpbGl0eSBhdHRyaWJ1dGVzIChTZWN0aW9uIDUpLg0KDQpBbnkgQ29t bWVudCBpcyB3ZWxjb21lLiA6LSkNCg0KQmVzdCByZWdhcmRzIA0KTGkgQ2hlbmcNCg0KaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnINC009ogMjAxMy0wMi0yMiAxNDoxODoyNDoNCg0KPiANCj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNoZW5nLWxpc3Atc2hkaHQtMDMudHh0DQo+IGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGkgQ2hlbmcgYW5kIHBvc3RlZCB0byB0aGUN Cj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6ICAgIGRyYWZ0LWNoZW5nLWxpc3At c2hkaHQNCj4gUmV2aXNpb246ICAgIDAzDQo+IFRpdGxlOiAgICAgICBMSVNQIFNpbmdsZS1Ib3Ag REhUIE1hcHBpbmcgT3ZlcmxheQ0KPiBDcmVhdGlvbiBkYXRlOiAgICAyMDEzLTAyLTIxDQo+IEdy b3VwOiAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAyMg0K PiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWNoZW5nLQ0KPiBsaXNwLXNoZGh0LTAzLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbmctbGlzcC1zaGRodA0KPiBIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW5nLWxpc3At c2hkaHQtMDMNCj4gRGlmZjogaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt Y2hlbmctbGlzcC1zaGRodC0wMw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZHJhZnQgc3Bl Y2lmaWVzIHRoZSBMSVNQIFNpbmdsZS1Ib3AgRGlzdHJpYnV0ZWQgSGFzaCBUYWJsZQ0KPiAgICBN YXBwaW5nIE92ZXJsYXkgKExJU1AtU0hESFQpLCBhIGRpc3RyaWJ1dGVkIG1hcHBpbmcgZGF0YWJh c2Ugd2hpY2gNCj4gICAgZW1ib2RpZXMgU0hESFQgTm9kZXMgdG8gbWFpbnRhaW4gKEtleSwgdmFs dWUpIHBhaXJzIGZvciBMSVNQDQo+ICAgIChMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wp LWxpa2UgYXJjaGl0ZWN0dXJlLCB3aGVyZWluIGV2ZXJ5DQo+ICAgIChrZXkgdmFsdWUpIHBhaXIg Y29ycmVzcG9uZHMgdG8gYW4gRUlEKEVuZHBvaW50IElEKS10by1STE9DKFJvdXRpbmcNCj4gICAg TG9jYXRvcikgbWFwcGluZyBpbmZvcm1hdGlvbiBlbnRyeS4gIEFjY29yZGluZyB0byB0aGlzIHN0 cmF0ZWd5LCBFSUQNCj4gICAgaXMgaGFzaGVkIHRvIGJlIGEgdW5pcXVlIFJlc291cmNlIElEIHdo aWNoIGlzIHVzZWQgZm9yIGxvY2F0aW5nDQo+ICAgIGRlc3RpbmF0aW9uIERIVCBOb2RlIHdobyBt YWludGFpbnMgbWFwcGluZyBlbnRyeSBmb3IgdGhlIHBhcnRpY3VsYXINCj4gICAgRUlELiAgRnVy dGhlcm1vcmUsIGFkYXB0aXZlIGhhc2ggc3BhY2UgcGFydGl0aW9uIG1ldGhvZCBpcyBhZG9wdGVk IHRvDQo+ICAgIHNvbHZlIHRoZSBsb2FkIGJhbGFuY2UgcHJvYmxlbSBvbiBTSERIVCBOb2RlcyB3 aGljaCBpcyBjb21tb24gb24NCj4gICAgdHJhZGl0aW9uYWwgREhUIHBsYW5lcy4NCj4gDQo+ICAN Cj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 00349FC948257B1A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8ZGl2Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGkgQWxsLCA8L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkganVzdCBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBk cmFmdC1jaGVuZy1saXNwLXNoZGh0LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+VGhpcyBkcmFmdCBzcGVjaWZpZXMgaG93IHRvIGJ1aWxkIGEgZGlzdHJpYnV0ZWQgbWFw cGluZw0KZGF0YWJhc2UgYmFzZWQgb24gc2luZ2xlLWhvcCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPkRIVCBmb3IgTElTUC1saWtlIGFyY2hpdGVjdHVyZS48L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPldlIGRpZCBhIHByZXNlbnRhdGlvbiBvbiA4NHRo IElFVEYgbWVldGluZywgYW5kIGdvdA0KbWFueSB2YWx1YWJsZSBzdWdnZXN0aW9ucy48L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkluIHRoaXMgbmV3IHZlcnNpb24sIHdl IHNwZWNpZmllZCB0aGF0IE1hcC1SZXNvbHZlcg0KYW5kIE1hcC1TZXJ2ZXIgY291bGQgYmUgY29s bG9jYXRlZCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPm9udG8gU0hESFQgTm9k ZXMsIFtMSVNQLVNIREhUXSBhcmUgbm90IGNvbmZsaWN0ZWQNCndpdGggW0xJU1AtTVNdIChTZWN0 aW9uIDQpLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkZ1cnRoZXJtb3JlLCB3 ZSBzcGVjaWZpZWQgaG93IHRvIGRlcGxveW1lbnQgYSBkb21haW4NCkxJU1AgU0hESFQgb3Zlcmxh eSwgd2hpY2ggd2lsbCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPm1ha2UgdGhl IHdob2xlIGRhdGFiYXNlIHBlcmZvcm0gYmV0dGVyIHNjYWxhYmlsaXR5DQphdHRyaWJ1dGVzIChT ZWN0aW9uIDUpLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QW55IENv bW1lbnQgaXMgd2VsY29tZS4gOi0pPC9mb250PjwvdHQ+DQo8YnI+DQo8ZGl2Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+QmVzdCByZWdhcmRzIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+TGkgQ2hlbmc8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyDQtNPaIDIwMTMtMDItMjIgMTQ6MTg6MjQ6PGJyPg0KPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jaGVuZy1saXNwLXNo ZGh0LTAzLnR4dDxicj4NCiZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBM aSBDaGVuZyBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCiZndDsgSUVURiByZXBvc2l0b3J5Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBGaWxlbmFtZTogJm5ic3A7ICZuYnNwO2RyYWZ0LWNoZW5nLWxpc3At c2hkaHQ8YnI+DQomZ3Q7IFJldmlzaW9uOiAmbmJzcDsgJm5ic3A7MDM8YnI+DQomZ3Q7IFRpdGxl OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBMSVNQIFNpbmdsZS1Ib3AgREhUIE1hcHBpbmcgT3Zlcmxh eTxicj4NCiZndDsgQ3JlYXRpb24gZGF0ZTogJm5ic3A7ICZuYnNwOzIwMTMtMDItMjE8YnI+DQom Z3Q7IEdyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+ DQomZ3Q7IE51bWJlciBvZiBwYWdlczogMjI8YnI+DQomZ3Q7IFVSTDogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtY2hlbmctPGJyPg0KJmd0OyBsaXNwLXNoZGh0LTAzLnR4dDxicj4NCiZndDsg U3RhdHVzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuZy1saXNwLXNoZGh0PGJyPg0KJmd0OyBIdG1saXpl ZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2hlbmctbGlzcC1zaGRodC0wMzxicj4NCiZndDsgRGlmZjogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1jaGVuZy1saXNwLXNoZGh0LTAzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0 Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1RoaXMgZHJhZnQgc3BlY2lmaWVzIHRoZSBMSVNQIFNp bmdsZS1Ib3AgRGlzdHJpYnV0ZWQNCkhhc2ggVGFibGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtN YXBwaW5nIE92ZXJsYXkgKExJU1AtU0hESFQpLCBhIGRpc3RyaWJ1dGVkIG1hcHBpbmcgZGF0YWJh c2UNCndoaWNoPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ZW1ib2RpZXMgU0hESFQgTm9kZXMgdG8g bWFpbnRhaW4gKEtleSwgdmFsdWUpIHBhaXJzIGZvcg0KTElTUDxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyhMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wpLWxpa2UgYXJjaGl0ZWN0dXJlLCB3 aGVyZWluDQpldmVyeTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyhrZXkgdmFsdWUpIHBhaXIgY29y cmVzcG9uZHMgdG8gYW4gRUlEKEVuZHBvaW50IElEKS10by1STE9DKFJvdXRpbmc8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDtMb2NhdG9yKSBtYXBwaW5nIGluZm9ybWF0aW9uIGVudHJ5LiAmbmJzcDtB Y2NvcmRpbmcgdG8NCnRoaXMgc3RyYXRlZ3ksIEVJRDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2lz IGhhc2hlZCB0byBiZSBhIHVuaXF1ZSBSZXNvdXJjZSBJRCB3aGljaCBpcyB1c2VkIGZvcg0KbG9j YXRpbmc8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtkZXN0aW5hdGlvbiBESFQgTm9kZSB3aG8gbWFp bnRhaW5zIG1hcHBpbmcgZW50cnkgZm9yDQp0aGUgcGFydGljdWxhcjxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO0VJRC4gJm5ic3A7RnVydGhlcm1vcmUsIGFkYXB0aXZlIGhhc2ggc3BhY2UgcGFydGl0 aW9uDQptZXRob2QgaXMgYWRvcHRlZCB0bzxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3NvbHZlIHRo ZSBsb2FkIGJhbGFuY2UgcHJvYmxlbSBvbiBTSERIVCBOb2RlcyB3aGljaCBpcw0KY29tbW9uIG9u PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dHJhZGl0aW9uYWwgREhUIHBsYW5lcy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxi cj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+PC9kaXY+PC9kaXY+DQoNCjxicj48cHJlPjxmb250 IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5z bWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGlu dGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkg dXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 00349FC948257B1A_=-- From sm@resistor.net Sat Feb 23 23:44:08 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ABB21F8FF2; Sat, 23 Feb 2013 23:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 qiiHg1EE0Q0C; Sat, 23 Feb 2013 23:44:06 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0921F8FF1; Sat, 23 Feb 2013 23:44:06 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1O7hM7j004864; Sat, 23 Feb 2013 23:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361691810; bh=bHaSNyrKmxDYJTLOcMkzcZ+4JXwTLMDfkKP1H/D7Cpo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wD5LWX9/3vJBvhgB7CY29Gzsc/bbutnodi0T3xVvHtQgsuaOyUswXD2NEjqqy7Cg4 qRS7eKag5ISb3sxlyBOUNVxcqoaMmnOEFQ9c/3g9gdjQ1l43Ctcgv2/WybY5RKbgIY +WqDfh3ZlyUZuWxTolCy1Vr4zqsS6YZdq+Gg3udI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361691810; i=@resistor.net; bh=bHaSNyrKmxDYJTLOcMkzcZ+4JXwTLMDfkKP1H/D7Cpo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OoUANnU9gY55jlkl5IEP6L8YZHkkN/OSfAeEU2SDPp49gq8NKHmvuQhYsICHkUWCc D6P9CVt8oJnt5/BdG+CteVvMbbeOGnqmoegG9v8B/wzNtD4cz4gYqF74faHyn8u5ju 680f7YBOIivQtuwLbmp/FseInHdh/C27LF0sMLm0= Message-Id: <6.2.5.6.2.20130223222210.0ade7d68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 23 Feb 2013 22:31:40 -0800 To: Owen DeLong , Dino Farinacci From: SM In-Reply-To: References: <4E8BC25E-79FF-4CF9-9E95-40904DE1D4D6@gmail.com> <7466F234-1BBE-4985-BBFC-B56A38D8F5F3@delong.com> <9D60BB7D-2325-489C-9225-22213DD6155A@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Martin J. Levy" , mpounsett@afilias.info, v6ops@ietf.org, lisp@ietf.org Subject: Re: [lisp] [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn 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, 24 Feb 2013 07:44:08 -0000 At 17:09 19-02-2013, Owen DeLong wrote: >One of us is misunderstanding the other. My point is that using IPv6 >address space to number things that are not IPv6 hosts is, IMHO, a bad idea. It's not the first time that the idea came up. It's not because there is a seemingly infinite source of integers that they should be assigned to any thing. Regards, -sm From jnc@mercury.lcs.mit.edu Sun Feb 24 11:28:13 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0E421F90A7 for ; Sun, 24 Feb 2013 11:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 kmiij0SNgBQy for ; Sun, 24 Feb 2013 11:28:13 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id CCDBD21F90A5 for ; Sun, 24 Feb 2013 11:28:11 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BE7D118C0DE; Sun, 24 Feb 2013 14:28:10 -0500 (EST) To: lisp@ietf.org Message-Id: <20130224192810.BE7D118C0DE@mercury.lcs.mit.edu> Date: Sun, 24 Feb 2013 14:28:10 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] draft-ietf-lisp-architecture: Demand Loading of Mappings 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, 24 Feb 2013 19:28:13 -0000 > From: Ronald Bonica > In Section 6.1, you say: Hi, sorry this reply is so slow. I wasn't able to reply then, and it's taken me a while to get back to it. Anyway... > "Push as a mechanism is also fundamentally less desirable than pull, > since the control plane overhea d consumed to load and maintain > information about unused destinations is entirely wasted. The only > potential downside to the pull option is the delay required for the > demand-loading of information." > Another downside of the pull option is that the XTR must ensure the > freshness of information that it pulls to itself. In order to ensure > freshness, the XTR relies on LISP-specific protocol machinery ... With > that additional machinery comes additional operational complexity and > security considerations. ... > what we really have before us is an architectural trade-off. > In the push paradigm, "control plane overhead ...". > In the pull paradigm, "the XTR must ensure the freshness ..." I've been pondering this for a couple of days, but I think I don't agree (although I don't have any axes to grind/defend, either way). I guess I'm not convinced that pull is necessarily architecturally more complicated than pull. I can start with examples like ISPF and IS-IS, which are certainly fairly complicated. Yes, I know, they have very hard constraints, because unless everyone is perfectly synched, loops can result. But still, they show that push is not trivial either. This makes sense, because many of the fundamental issues they face (e.g. making sure that the other side has correct, up-to-date, data) are in fact quite similar. In fact, I can make some hand-wavy arguments that, in some aspects at least, pull can actually be _simpler_. Take, for example, time-outs. Push _has_ to have timeouts, to ensure that the other party got updated information. But, in the simple cases at least, you can slide on them in pull. E.g. if an ITR sends a Map-Request, and it (or the reply) is lost, it doesn't _have_ to do anything - because _if there is no further traffic_, one doesn't care if one don't have the mapping. And if there is _more_ traffic, then one can use that to trigger more enquiries. And in LISP, with its very large fan-outs, a push relationship means a _lot_ of state and state-keeping, etc, at the source end of the pairing. Etc, etc. So I do think the actual key tradeoff is the one I already had in the text: response time (for push) versus less control overhead (pull). > "With that additional machinery comes additional ... security > considerations." Again, it's not clear to me that security is worse in pull than in push. Take a look, for instance, at BGPSEC (although that's more painful than routing security necessarily _has_ to be, because of the distributed computation nature of destination-vector routing architectures, so it's not the fairest example). But on all of these points, I do have an open mind, so if you think I've read it wrong, by all means please show me where I've gone off the rails! :-) > I wonder if this text could be crafted to reflect that architectural > trade-off? Assuming my read (above) is correct, would it be worth saying something about that briefly? It might be that a lot of people have the initial assumption that you did, that pull is more complex, so it might be worth a sentence or two to briefly allude to the reading above. (If we decide I read it wrong, and that the tradeoff is in fact more complicated than just efficiency/response-time, of course I will say something on that topic.) Noel From jnc@mercury.lcs.mit.edu Sun Feb 24 11:30:04 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8889821F90B8 for ; Sun, 24 Feb 2013 11:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 siyuvIbymjcz for ; Sun, 24 Feb 2013 11:30:04 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5A92721F90BE for ; Sun, 24 Feb 2013 11:30:03 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CA0D718C0DE; Sun, 24 Feb 2013 14:29:59 -0500 (EST) To: lisp@ietf.org Message-Id: <20130224192959.CA0D718C0DE@mercury.lcs.mit.edu> Date: Sun, 24 Feb 2013 14:29:59 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] draft-ietf-lisp-architecture: Demand Loading of Mappings 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, 24 Feb 2013 19:30:04 -0000 > From: jnc@mercury.lcs.mit.edu (Noel Chiappa) > I guess I'm not convinced that pull is necessarily architecturally more > complicated than pu[sh]. Ooops. (Sorry! :-) Noel From internet-drafts@ietf.org Mon Feb 25 10:02:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C492B1F0D0D; Mon, 25 Feb 2013 10:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 IccVBWx4riAC; Mon, 25 Feb 2013 10:02:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336141F0D0C; Mon, 25 Feb 2013 10:02:18 -0800 (PST) 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.40 Message-ID: <20130225180218.31450.57812.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 10:02:18 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-threats-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: Mon, 25 Feb 2013 18:02:24 -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-04.txt Pages : 34 Date : 2013-02-25 Abstract: This document analyzes the potential threats against the security of the Locator/Identifier Separation Protocol (LISP) if deployed in the Internet. This document proposes a set of recommendations to mitigate the identified security risks and keep a security level equivalent to what is observed in the Internet today (i.e., without LISP). By following the recommendations of this draft a LISP deployment can achieve a security level that is comparable to the existing Internet architecture. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-threats-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmh@joelhalpern.com Mon Feb 25 12:13:49 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9FC21F92E1 for ; Mon, 25 Feb 2013 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.002, 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 0CN+gZN7EwNf for ; Mon, 25 Feb 2013 12:13:49 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 194AF21F9316 for ; Mon, 25 Feb 2013 12:13:11 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 644ECA3AB9 for ; Mon, 25 Feb 2013 12:13:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5857D1CC9B6 for ; Mon, 25 Feb 2013 12:13:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-91.clppva.east.verizon.net [70.106.135.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BD0461CC9E3 for ; Mon, 25 Feb 2013 12:13:06 -0800 (PST) Message-ID: <512BC5C4.6090406@joelhalpern.com> Date: Mon, 25 Feb 2013 15:12:52 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "lisp@ietf.org" References: <20130225180218.31450.57812.idtracker@ietfa.amsl.com> In-Reply-To: <20130225180218.31450.57812.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130225180218.31450.57812.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-threats-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: Mon, 25 Feb 2013 20:13:50 -0000 The authors have submitted a major revision of this documet. Please read it (the diff tool will show you have much they have changed. We need to be confident that the working group is happy with the changes the authors hae made. We will discuss this in orlando. Email comments before then would be appreciated. Thank you, Joel -------- Original Message -------- Subject: I-D Action: draft-ietf-lisp-threats-04.txt Date: Mon, 25 Feb 2013 10:02:18 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: lisp@ietf.org 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 Threats Analysis Author(s) : Damien Saucez Luigi Iannone Olivier Bonaventure Filename : draft-ietf-lisp-threats-04.txt Pages : 34 Date : 2013-02-25 Abstract: This document analyzes the potential threats against the security of the Locator/Identifier Separation Protocol (LISP) if deployed in the Internet. This document proposes a set of recommendations to mitigate the identified security risks and keep a security level equivalent to what is observed in the Internet today (i.e., without LISP). By following the recommendations of this draft a LISP deployment can achieve a security level that is comparable to the existing Internet architecture. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-threats-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 From internet-drafts@ietf.org Mon Feb 25 13:01:48 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528AA21E80D7; Mon, 25 Feb 2013 13:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 5eyJpfRSyvDJ; Mon, 25 Feb 2013 13:01:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60AB21E808F; Mon, 25 Feb 2013 13:01:47 -0800 (PST) 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.40 Message-ID: <20130225210147.16242.80454.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 13:01:47 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-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: Mon, 25 Feb 2013 21:01:48 -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 EID Block Author(s) : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-04.txt Pages : 13 Date : 2013-02-25 Abstract: This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-eid-block-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ggx@gigix.net Mon Feb 25 13:59:25 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA28721E80DE for ; Mon, 25 Feb 2013 13:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 7ONcwMt3ZtZi for ; Mon, 25 Feb 2013 13:59:25 -0800 (PST) Received: from mail-we0-x22c.google.com (unknown [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 81D7021E8096 for ; Mon, 25 Feb 2013 13:59:24 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so2986433wey.3 for ; Mon, 25 Feb 2013 13:59:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:message-id:mime-version:subject:date :references:cc:to:x-mailer:x-gm-message-state; bh=tKzSuQvU5GHXX/po7aq/7ZQ45Y3opyqRYCldpAv6/pc=; b=ZC8bN3/B2I0OtAsfpTlC9saMYQfS9NQTe4ikCOgviy2uM3C667hf+H8DBda/q9jqS7 wKgBtvDg+g1eJkOeBvgt15QUOL7y2fHsghpIvbdgWBtHnFsRfZdx+vedqOKhuK340U3B s0aOM0FY2iDfXAihDlTmb+GE9W4pwHcexmx60QQbMiHqjAKB+00dUPvzK/DWoH7Q/goe O1jINt1DmNLtezCD3PAvwRJTdKEm1b0Gic7ALIWB8hNUON+betE/XHNnbRwL2bkO2yZI S2KAvNL2qEuuaAHUSMtnzoze3/96eY3QNwUh1WNZLwTvFIxw0qP0pWN4BylMCSwPd6va B3Yw== X-Received: by 10.194.235.196 with SMTP id uo4mr22135662wjc.30.1361829563336; Mon, 25 Feb 2013 13:59:23 -0800 (PST) Received: from ?IPv6:2a01:e35:1381:3430:4b5:e6a9:8c0d:ad08? ([2a01:e35:1381:3430:4b5:e6a9:8c0d:ad08]) by mx.google.com with ESMTPS id ej8sm17606985wib.9.2013.02.25.13.59.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 13:59:22 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_8E057C93-CC15-481F-A195-66924D259813" Message-Id: <12CDCFB9-3E1F-4333-B195-3443884E9A9E@gigix.net> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Mon, 25 Feb 2013 22:59:20 +0100 References: <20130225204729.16254.15387.idtracker@ietfa.amsl.com> To: "lisp@ietf.org list list" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmU0EBW5mLA7/RF2yDoaXXvIqhYQmYpGgBJRLUuDdofJdCA2VvNdWO6w10zHhspWdVv0zFi Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= Subject: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:59:25 -0000 --Apple-Mail=_8E057C93-CC15-481F-A195-66924D259813 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI a new version is available. Comments still welcome ;-) L. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt > Date: 25 February 2013 21:47:29 GMT+01:00 > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : LISP EID Block Management Guidelines > Author(s) : Luigi Iannone > Roger Jorgensen > Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt > Pages : 9 > Date : 2013-02-25 >=20 > Abstract: > This document proposes an allocation framework for the management of > the LISP EID address prefix (requested in a separate document). = Such > framework relies on hierarchical distribution of the address space = to > RIRs (Regional Internet Registries), who will allocate on a = temporary > basis sub-prefixes to requesting organizations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-iannone-lisp-eid-block-mgmnt-01= >=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 --Apple-Mail=_8E057C93-CC15-481F-A195-66924D259813 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI a = new version is available.

Comments still welcome = ;-)

L.

Begin forwarded = message:

Subject: I-D Action: = draft-iannone-lisp-eid-block-mgmnt-01.txt
Date: 25 February 2013 = 21:47:29 GMT+01:00
Reply-To: = internet-drafts@ietf.org
<= /span>


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


Title =           : LISP EID = Block Management Guidelines
Author(s) =       : Luigi Iannone
=             &n= bsp;           &nbs= p;Roger Jorgensen
Filename =        : = draft-iannone-lisp-eid-block-mgmnt-01.txt
Pages =           : 9
Date =            : = 2013-02-25

Abstract:
  This document proposes an = allocation framework for the management of
  the LISP EID = address prefix (requested in a separate document).  Such
=   framework relies on hierarchical distribution of the address = space to
  RIRs (Regional Internet Registries), who will = allocate on a temporary
  basis sub-prefixes to requesting = organizations.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt=

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01
A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-iannone-lisp-eid-block-mgm= nt-01


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

=
= --Apple-Mail=_8E057C93-CC15-481F-A195-66924D259813-- From Fred.L.Templin@boeing.com Mon Feb 25 14:55:22 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED5C21F9211 for ; Mon, 25 Feb 2013 14:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 Wa8f7KyuRxfK for ; Mon, 25 Feb 2013 14:55:21 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4F221E8131 for ; Mon, 25 Feb 2013 14:55:21 -0800 (PST) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1PMth9n027538 for ; Mon, 25 Feb 2013 14:55:43 -0800 Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1PMthdp027535 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 25 Feb 2013 14:55:43 -0800 Received: from XCH-BLV-501.nw.nos.boeing.com (130.247.25.190) by XCH-NWHT-09.nw.nos.boeing.com (130.247.25.115) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 25 Feb 2013 14:55:15 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.245]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.240]) with mapi id 14.02.0328.011; Mon, 25 Feb 2013 14:55:15 -0800 From: "Templin, Fred L" To: "lisp@ietf.org" Thread-Topic: comments on 'draft-ietf-lisp-deployment-06' Thread-Index: AQHOE5UwxrOwotnRS0uuN2hVwZFA8ZiLFxxg Date: Mon, 25 Feb 2013 22:55:15 +0000 Message-ID: <2134F8430051B64F815C691A62D9831801146A@XCH-BLV-504.nw.nos.boeing.com> References: <20130225180218.31450.57812.idtracker@ietfa.amsl.com> <512BC5C4.6090406@joelhalpern.com> In-Reply-To: <512BC5C4.6090406@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [lisp] comments on 'draft-ietf-lisp-deployment-06' 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, 25 Feb 2013 22:55:22 -0000 Hi, I am reading this document for the first time and had a few comments to share below. Thanks - Fred fred.l.templin@boeing.com 1) Section 2.5 ("Tunnel Routers Behind NAT"), this seems to show a limitation in that there can be only one xTR behind a NAT. I would like to address the case when there may be many xTRs behind the NAT - can LISP do that? 2) Section 2.6, I don't understand why it says "MTU/PMTUD issues minimized" for the recursive scenario? 3) Section 6.1, number 4, should say "request increase in MTU to 1556 *or greater* on service provider connections". However, controlling just the first-hop interface MTU does not assure MTU mitigations across the entire path. Similarly, "care must be taken that ICMP is not being filtered" cannot be assured along the entire path. And, studies have shown that ICMP filtering does impact MTU handling in current operational practices: http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thes= is.pdf Additionally, I have a use case that I'm not sure is well addressed by the document. I would like to address the use case of mobile networks configured as stub sites that connect to ISPs via a mobile router. Each mobile router may have multiple ISP connections, and can change its ISP addresses dynamically as it moves around. Some of the ISP addresses may be global and others may be private, such as behind a carrier-grade NAT. Many such mobile routers may be located behind the same NAT. I want to give each mobile router an EID prefix that it can use to number interfaces within the mobile network. The mobile network may contain just one interface, a few interfaces, or it may contain many interfaces. I now want that the mobile network can remain reachable from the outside world by the same EID prefix addresses even as the mobile router travels around dynamically. The mobile router will need an xTR so that its ISPs will not filter its packets that use EID source addresses. I also want the mobile router to be able to traffic engineer in both the outgoing *and* incoming directions. For this, there needs to be some sort of server sitting outside of any NATs that the mobile router can "register" itself with. The mobile router should be able to change between different servers as it moves around, e.g., to reduce path stretch or in the event of a server failure. The servers in turn associate with proxy xTRs so that outgoing packets destined to EIDs located in distant networks can be routed appropriately. This is the way IRON sets things up. Can it also be done with LISP? From terry.manderson@icann.org Mon Feb 25 17:15:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD31621E80B6 for ; Mon, 25 Feb 2013 17:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 ZPEtzi5GQ0xd for ; Mon, 25 Feb 2013 17:15:23 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC1E21E8127 for ; Mon, 25 Feb 2013 17:15:23 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 25 Feb 2013 17:15:22 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 25 Feb 2013 17:15:20 -0800 Thread-Topic: Draft Agenda for LISP IETF-86 Thread-Index: Ac4TvsAJ6adP1V+aRniBxfey8520tQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3444722121_98431759" MIME-Version: 1.0 Subject: [lisp] Draft Agenda for LISP IETF-86 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, 26 Feb 2013 01:15:23 -0000 --B_3444722121_98431759 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, I have posted a _DRAFT_ agenda at: http://www.ietf.org/proceedings/86/agenda/agenda-86-lisp Please review it and if you see that your requested slot is not there, AND you have not received an email from me saying it won't be on the agenda - please email me again. As with the last meeting The Intro and Architecture documents remain a gate to any further WG documents being adopted. Please review these documents and send comments to the list so that we can have these submitted to the IESG. You should note that the WG Goals and Milestones now feature as a part of the Agenda to remind us about the work we have (as a WG) committed to. Cheers Terry --B_3444722121_98431759 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ 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+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFLqXRgI5hrIAoxF1hxQCbAvj/En9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMDIyNjAxMTUyMFowDQYJKoZIhvcNAQEBBQAEggEAMCcmd+C1 lI+XVLTyPYWkAkT9to34BViCta2SYx/IyRMRbkUgALJ9hly20uwulg2NZvhoPeCRDq7/G/s8 ELrNBsjNdRoB9Blq1Vg6yj3GzVsJRk5MTavY4QrKv3xXQMvK+zCld++bPZ8y+GSrSwaUW9t7 QFxHnRpETqK+5xHM6pfudYrkAipr+nIu4NizAYttviRqH7HpflRhwM0vmycZwCymPQ5BrN8j KKiIsj7g9fg+jnCPoNlSy4gKium2IMvXo8Vkf/K4RoD2Wmx0lqOy9xl9pMwUumaFvcY6vU3S xKOZSoZaP+ncId5E1IKE/NSnTI8+zMKAOhGr5zYv742fEQ== --B_3444722121_98431759-- From sbarkai@gmail.com Mon Feb 25 18:38:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BB121E8127 for ; Mon, 25 Feb 2013 18:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, MANGLED_PILL=2.3, MIME_QP_LONG_LINE=1.396, 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 mvBxc4HRMspl for ; Mon, 25 Feb 2013 18:38:51 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id EFAE621E8143 for ; Mon, 25 Feb 2013 18:38:50 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i18so4433858oag.1 for ; Mon, 25 Feb 2013 18:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=gNf1fCmpy09GYdzHmFcfFLEClpozx5hvB8ILUgTe1VQ=; b=SorJQvUA/Ag/9hMA6Ud4guIhbPxi+cR+BkO8hxYzimwxsFIP+D3g4wF1MUN52cgF6h LH2IMzS+Fp9/TT7oHyP9S9lqcrVhAbKZZehQlCiP9DRFiQJfE6GLjJuDT3S1lmP7GtFS LhyqsA+jJn/RG1+PCKRa14oxshwNy2B/vTfUN5nb5NF5uFjRbBmNuACW/c0m7rVk8JZN t7CKlrqavWNwhJMXJHFISQ+7CIzOAQa/+HxY+YB/05/g6X6RnPXYLDoMZvGFByN5KK51 8H8Ck78wkZM7VO5xXEDryEk9EJDxYP/oQLoK0Ts1hKuYOCv/50tLdno9xUHvLsHetcMN YshQ== X-Received: by 10.60.24.72 with SMTP id s8mr25887oef.68.1361846330325; Mon, 25 Feb 2013 18:38:50 -0800 (PST) Received: from [192.168.1.73] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPS id d10sm17301951obk.1.2013.02.25.18.38.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 18:38:49 -0800 (PST) References: Mime-Version: 1.0 (1.0) Content-Type: multipart/mixed; boundary=Apple-Mail-D911E428-0C17-4E53-811E-C9023A4D1780 Message-Id: <2675C5DB-EBA2-4899-81E3-F714A0496FF1@gmail.com> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (10B146) From: Sharon Date: Mon, 25 Feb 2013 18:38:45 -0800 To: Terry Manderson Cc: "lisp@ietf.org" Subject: Re: [lisp] Draft Agenda for LISP IETF-86 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, 26 Feb 2013 02:38:52 -0000 --Apple-Mail-D911E428-0C17-4E53-811E-C9023A4D1780 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit LISP FlowMapping for NFV draft will be posted as soon as 00 window reopens. Sorry for missing the deadline. Meanwhile attached. Thanks. Sharon On Feb 25, 2013, at 17:15, Terry Manderson wrote: > All, > > I have posted a _DRAFT_ agenda at: > > http://www.ietf.org/proceedings/86/agenda/agenda-86-lisp > > Please review it and if you see that your requested slot is not there, AND > you have not received an email from me saying it won't be on the agenda - > please email me again. > > As with the last meeting The Intro and Architecture documents remain a > gate to any further WG documents being adopted. Please review these > documents and send comments to the list so that we can have these > submitted to the IESG. > > You should note that the WG Goals and Milestones now feature as a part of > the Agenda to remind us about the work we have (as a WG) committed to. > > Cheers > Terry > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --Apple-Mail-D911E428-0C17-4E53-811E-C9023A4D1780 Content-Type: text/plain; name=draft-barkai-lisp-nfv-00-3.2.txt Content-Disposition: attachment; filename=draft-barkai-lisp-nfv-00-3.2.txt Content-Transfer-Encoding: quoted-printable LISP Working Group S. Barkai Internet-Draft ConteXtream Inc. Intended status: Experimental D. Farinacci Expires: August 29, 2013 D. Meyer F. Maino V. Ermagan Cisco Systems February 25, 2013 LISP Based FlowMapping for Scaling NFV draft-barkai-lisp-nfv-00 Abstract This draft describes a flow-mapping method for scaling of virtualized network functions (NFV) based on RFC 6830 Locator ID Separation Protocol (LISP). Network functions such as subscriber mobility- security-quality management are typically delivered using proprietary appliances topologically embedded into the network. NGN virtualized network functions run as software instances on standard servers and are unbundled building blocks of capacity and functionality. LISP based flow-mapping wires VNF instances and assembles them into the data-path, resulting in a scalable, dynamically programmable, and elastic solution based on subscriber-profiles and subscriber-demand of network functions. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Barkai, et al. Expires August 29, 2013 [Page 1] =0C Internet-Draft LISP Based FlowMapping for Scaling NFV February 2013 This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Barkai, et al. Expires August 29, 2013 [Page 2] =0C Internet-Draft LISP Based FlowMapping for Scaling NFV February 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Connectivity Models Used . . . . . . . . . . . . . . . . . . . 4 3. XTR FlowMapping Reference Architecture . . . . . . . . . . . . 7 3.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Intra-Provider Mappings . . . . . . . . . . . . . . . . . . . . 8 5. Mapping Subscription . . . . . . . . . . . . . . . . . . . . . 8 6. Inter-Provider Mappings . . . . . . . . . . . . . . . . . . . . 8 7. QOS and Echo Measurements . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Barkai, et al. Expires August 29, 2013 [Page 3] =0C Internet-Draft LISP Based FlowMapping for Scaling NFV February 2013 1. Introduction This draft describes a flow-mapping method for scaling virtualized network functions (NFV) based on the Locator ID Separation Protocol (LISP).[RFC6830]Network functions such as subscriber mobility- security-quality.. management are typically delivered using proprietary appliances topologically embedded into the network as service nodes or service blades. This monolithic delivery model increases the complexity of roll-out and capacity planning, complicates basic connectivity, as well as limits and inhibits functional choices and service innovation. Virtualized network functions on the other hand, run as software instances on standard servers forming unbundled building blocks of capacity and functionality. This componentized method of function instantiation presents the network, or rather the virtual network, with the task of assembling these components into whole solutions by forwarding the right traffic to the right NFV instance at the right sequence and the right time. While it is possible to some extent to use traditional virtual networking mechanisms such as virtual-LANs (VLAN) and virtual- private-networks (VPN) for this task, these mechanisms are relatively static and are bound to the topological network interfaces adding complex line configuration. Next generation software-defined and flow-based models on the other hand are much more programmable and dynamic, and present a better fit to the next generation service- provider data-center applications. LISP based flow-mapping wires VNF instances into the data-path in a dynamically programmable and elastic manner based on subscriber-profiles and subscriber-demand. 2. Connectivity Models Used LISP implements an identity grid forwarding grid for NFVs. Unlike topological forwarding which is based on source Subnet - routed hop by hop to - destination Subnet, NFV grids are based on subscriber flow-identity "patched" to VNF instance-identity. This is done using the standard LISP distributed-overlay and network-database mechanisms. In order to describe how LISP based NFV flow-mapping works we will refer to 3 connectivity models that are applied conjointly: o The topological network or the "location" connectivity is based on standard bridging and routing enabling both the physical capacity and physical availability of connectivity. Typically spine-leafs switching architecture that can cluster hundreds or computer racks, and core-edge routing architecture inter-connecting these Barkai, et al. Expires August 29, 2013 [Page 4] =0C Internet-Draft LISP Based FlowMapping for Scaling NFV February 2013 computer clusters across points of presence, as well as connecting to the access networks and to the public Internet. o The functional network or the "identity" grid is there to map identified subscriber flows carrying an application thread to the right function task or instance, enabling the logical scalability and compute concurrency of NFV. This mapping is based on global definitions of the business service and application, as well global knowledge of capacity and availability of each functional task or instance. o The virtualized network or the location-identity overlay enables the implementation of the functional network on the physical in- place bridge-routed network. The network virtualization ring or overlay is based on the encap/decap functionality of LISP XTR working in conjunction with the LISP mmap services. POP3 POP4 \ / \ / EdgeR -- EdgeRouter | | Access ... | Core | ... Internet | | EdgeR -- EdgeR / \ / \ ^ Spine1 Spine2 ... Spine5 | / \ / \ __/ / .. | | | \/ | __/ / | P | /\ || / | O Leaf1 Leaf2 ... Leaf300 P |-PC1 |-PC1 1 |-PC2 |-PC2 | |.. |.. | |-PC40 |-PC40 v Topological Location Network Barkai, et al. Expires August 29, 2013 [Page 5] =0C Internet-Draft LISP Based FlowMapping for Scaling NFV February 2013 v << FunctionA FunctionB .. FunctionN v Recursion Instance1..i Instance1..j Instance1..k v | | | | | | | | | | | | v | | | | | | | | | | | | Subscriber1-o o o o - - -+ o o o - - -o o o o | | | | | | | | | | | | Subscriber2-o + o o - - -o o o o - - -o o o o | | | | | | | | | | | | . ... ... ... . ... ... ... . ... ... ... | | | | | | | | | | | | SubscriberM-o o o o - - -o o o o - - -+ o o o | | | | | | | | | | | | Functional Identity Grid AoF AoF AoF Access or Functions AoF AoF AoF \ | / \ | / \ | / BoR BoR BoR | | | XTR XTR XTR || || || =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D || || B _|| ||_ B o -XTR_ | | _XTR- o R || Bridges or Routers || R _|| ||_ B -XTR_ | | _XTR- B o || || o R || || R =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D || || || XTR XTR XTR | | | BoR BoR BoR / | \ / | \ / | \ Identity-Location Virtualization Ring Barkai, et al. Expires August 29, 2013 [Page 6] =0C Internet-Draft LISP Based FlowMapping for Scaling NFV February 2013 3. XTR FlowMapping Reference Architecture In order to map subscriber flows to virtualized function instances and essentially to overlay identity grid onto topology based bridge- routed network we use the following XTR 3-tier reference architecture: 1. Flow Switching, or the ability to process consistently and encapsulate sequences of packets belonging to the same subscriber-application threads using identity pattern masks. This tier can be based on, but not limited to ONF OpenFlow 2. Flow Handlers, or the ability to have distinct software for processing different protocol families and to further provision flow-switching per specific subscriber-application threads encapsulated based on application identity elements. 3. Global Mapping, or the ability to associate any globally significant key to a set of globally assigned values and attributes. For example mapping a functional VIP to function instances, or mapping function instances to locations, accessibility, and load. Orchestration Authorization OSS/BSS Mappings Mappings Mappings v v v (NFVMs etc.) (3A etc.) (Subs. etc) v v v _________________________________ | | | LISP-MMAP | |_________________________________| ^ ^ ^ Runtime Mappings(location, affinity, load, etc.) ^ ^ ^ ^ ------- ------- ------- | |MMapper| |MMapper| |MMapper| | |-------| |-------| |-------| X |H H H H| |H H H H| |H H H H| T |n n n n| |n n n n| |n n n n| R |d d d d| |d d d d| |d d d d| | |l l l l| |l l l l| |l l l l| | |-------| |-------| |-------| v | FlowX | | FlowX | | FlowX | ------- ------- ------- Barkai, et al. Expires August 29, 2013 [Page 7] =0C Internet-Draft LISP Based FlowMapping for Scaling NFV February 2013 FlowMapping XTR Architecture 3.1. 4. Intra-Provider Mappings 5. Mapping Subscription 6. Inter-Provider Mappings 7. QOS and Echo Measurements 8. Security Considerations There are no security considerations related with this memo. 9. IANA Considerations There are no IANA considerations related with this memo. 10. Acknowledgements 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. Barkai, et al. Expires August 29, 2013 [Page 8] =0C Internet-Draft LISP Based FlowMapping for Scaling NFV February 2013 Authors' Addresses Sharon Barkai ConteXtream Inc. California USA Email: Sharon@Contextream.com Dino Farinacci California USA Email: farinacci@gmail.com David Meyer California USA Email: dmm@1-4-5.net Fabio Maino Cisco Systems California USA Email: fmaino@cisco.com Vina Ermagan Cisco Systems California USA Email: vermagan@cisco.com Barkai, et al. Expires August 29, 2013 [Page 9] =0C --Apple-Mail-D911E428-0C17-4E53-811E-C9023A4D1780-- From brian.e.carpenter@gmail.com Tue Feb 26 06:07:05 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BDF21F898B for ; Tue, 26 Feb 2013 06:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.876 X-Spam-Level: X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, 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 RhZY+3D8bsGW for ; Tue, 26 Feb 2013 06:07:04 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id ACDC721F8991 for ; Tue, 26 Feb 2013 06:06:59 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so3601864wey.14 for ; Tue, 26 Feb 2013 06:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V2nThlMMMwnwPkTjR9kY56wO7oqoPEhFd66LRktEQL8=; b=JaS8zCgKNj+emcFKsdbwUjD+X6Hh8/ZpMWjzy6zk5hSSZdgySc297Tu0dZuzRtUZ0Q krfYeA5I6wP2by7n+alUVrpgs+QXFlJSY/HqYljqfQlZty+VfPbPhD4kC1sJOasjHYnu Ix6zltBVMNIDmVj3tT0wwTsFInrtM3c9TfVSIxuWA6LINsc4kIQOCS30qHl9Ex4P7Jtj 8lv3IABgMsN0NYqjR9xpXSk39pYo6NfRJR3JUekVL3X8pJcplvqZlhWzugfz7iPGDlaj pdexj9k5Ja9LnNc6UNLmsy3BaB/VKH069zD/nNnMruLFDlUUfdVBTciaTPVOlx4GiczW uZqg== X-Received: by 10.194.171.74 with SMTP id as10mr6107532wjc.0.1361887618933; Tue, 26 Feb 2013 06:06:58 -0800 (PST) Received: from [128.232.110.102] (c102.al.cl.cam.ac.uk. [128.232.110.102]) by mx.google.com with ESMTPS id ex15sm21308146wid.5.2013.02.26.06.06.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 06:06:57 -0800 (PST) Message-ID: <512CC187.1020107@gmail.com> Date: Tue, 26 Feb 2013 14:07:03 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: lisp@ietf.org References: <20130225210147.16242.80454.idtracker@ietfa.amsl.com> In-Reply-To: <20130225210147.16242.80454.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-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: Tue, 26 Feb 2013 14:07:05 -0000 I find this more convincing than the previous version. The "Routing Considerations" section still doesn't make it clear why non-LISP operators will be happy to propagate routes under the EID Block prefix. You can say "Why wouldn't they?", but then you need to explain why some people have been reluctant to propagate 2002::/16, perhaps because of fear that it might become a traffic magnet. Regards Brian From terry.manderson@icann.org Tue Feb 26 16:26:24 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774A21F86B2 for ; Tue, 26 Feb 2013 16:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 W5FB0J6Hashs for ; Tue, 26 Feb 2013 16:26:23 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1921F86A8 for ; Tue, 26 Feb 2013 16:26:22 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 26 Feb 2013 16:26:22 -0800 From: Terry Manderson To: Luigi Iannone , "lisp@ietf.org list list" Date: Tue, 26 Feb 2013 16:26:19 -0800 Thread-Topic: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Thread-Index: Ac4UgRFNPSVCvLSlR0igOwFlSHkTIw== Message-ID: In-Reply-To: <12CDCFB9-3E1F-4333-B195-3443884E9A9E@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3444805579_101168596" MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= Subject: Re: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:26:25 -0000 --B_3444805579_101168596 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Speaking just as a WG participant. I would rather a document like this focus purely on the allocation criteria that needs to be applied to: 1) An experimental EID block 2) ongoing LISP allocations beyond the life of the experiment Given the expected (numbering) requirements of a LISP site. Simply, while it is temping to use the RIRs, and name them, it is not appropriate in my opinion to assign work to the RIRs. That is the job of their membership. Similarly, what policies the RIRs have now are all subject to change within their own policy development processes. Please don't re-codify them here. I would also prefer to see this document take the approach of defining what is best for LISP, not how can we use the RIRs as an allocation framework. The concern I have is that if LISP ends up requiring something very different to how the RIRs do it - we would be doing a disservice to both LISP and the RIRs by pushing it that way. The definition of terms is well stated elsewhere, perhaps you can point to those locations? Cheers Terry On 26/02/13 7:59 AM, "Luigi Iannone" wrote: > > > >FYI a new version is available. > > >Comments still welcome ;-) > > >L. > >Begin forwarded message: > > >From: >internet-drafts@ietf.org > >Subject: >I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt > >Date: >25 February 2013 21:47:29 GMT+01:00 > >To: >i-d-announce@ietf.org > >Reply-To: >internet-drafts@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > >Title : LISP EID Block Management Guidelines >Author(s) : Luigi Iannone > Roger Jorgensen >Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >Pages : 9 >Date : 2013-02-25 > >Abstract: > This document proposes an allocation framework for the management of > the LISP EID address prefix (requested in a separate document). Such > framework relies on hierarchical distribution of the address space to > RIRs (Regional Internet Registries), who will allocate on a temporary > basis sub-prefixes to requesting organizations. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 > > >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 > > > > > > --B_3444805579_101168596 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ 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+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFGD0PGQk2+MLT9AoaKu6Wi6Z7wyMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMDIyNzAwMjYxOVowDQYJKoZIhvcNAQEBBQAEggEABLyDimOs DSHNJSXa3ROihiQ/L5wKalOOKhFWuW4CadccR5G+IBL8FmvqwI9y/WM2s+y2fPa39d0h9lxV vaqEMGFHwWNTeVE18TgPb7R4ykf2ys3Tr1X42CVix3AEUPFhGofDshzCztCLOdyzEeW0nQlR Ukg9/QK8CtJNPW0zfxbqxIeu4k+3EQCeAhdXRtoAjXeqvKFZxbe8s4Yt0QJx7rQcfoqLgELx /T2u1RTjIRBWs4dwfebWad8OQX1ARbVMDNKvcsai4Ol7buOX6etLbxP7D9DL+PSKi53YaCmW Es++JFjc8eINljhhQdL4Pn9Ehl7HW4tjV1V6HHzLrt5pjg== --B_3444805579_101168596-- From jmh@joelhalpern.com Tue Feb 26 16:46:56 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E934E21F86FB for ; Tue, 26 Feb 2013 16:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 HPyLCen9Gihr for ; Tue, 26 Feb 2013 16:46:55 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1826F21F86FA for ; Tue, 26 Feb 2013 16:46:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 06FD638014A; Tue, 26 Feb 2013 16:46:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-134.clppva.east.verizon.net [70.106.134.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id F1CEC380149; Tue, 26 Feb 2013 16:46:53 -0800 (PST) Message-ID: <512D576B.6030009@joelhalpern.com> Date: Tue, 26 Feb 2013 19:46:35 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:46:56 -0000 As a participant, I have an even stronger pinion on the RIR references than terry. I think that the block management needs to define o who the root is o what policy we require for allocating blocks to allocators (the root is not an allocator o What the behavioral requirements are for an allocator o are there any special requirements for re-delegating to another allocator? o What policies allocators should respect for end site allocation Once we have this defined, then organizations that wish to participate can do so. If the RIRs want to come play, they may. If not, then they don't. (Repeated for clarity, the above is a personal opinion, not a WG chair position, nor associated with any other hats I may have.) Yours, Joel On 2/26/2013 7:26 PM, Terry Manderson wrote: > Speaking just as a WG participant. > > I would rather a document like this focus purely on the allocation > criteria that needs to be applied to: > 1) An experimental EID block > 2) ongoing LISP allocations beyond the life of the experiment > > Given the expected (numbering) requirements of a LISP site. > > Simply, while it is temping to use the RIRs, and name them, it is not > appropriate in my opinion to assign work to the RIRs. That is the job of > their membership. > > Similarly, what policies the RIRs have now are all subject to change > within their own policy development processes. Please don't re-codify them > here. I would also prefer to see this document take the approach of > defining what is best for LISP, not how can we use the RIRs as an > allocation framework. The concern I have is that if LISP ends up requiring > something very different to how the RIRs do it - we would be doing a > disservice to both LISP and the RIRs by pushing it that way. > > The definition of terms is well stated elsewhere, perhaps you can point to > those locations? > > Cheers > Terry > > On 26/02/13 7:59 AM, "Luigi Iannone" wrote: > >> >> >> >> FYI a new version is available. >> >> >> Comments still welcome ;-) >> >> >> L. >> >> Begin forwarded message: >> >> >> From: >> internet-drafts@ietf.org >> >> Subject: >> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >> >> Date: >> 25 February 2013 21:47:29 GMT+01:00 >> >> To: >> i-d-announce@ietf.org >> >> Reply-To: >> internet-drafts@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : LISP EID Block Management Guidelines >> Author(s) : Luigi Iannone >> Roger Jorgensen >> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >> Pages : 9 >> Date : 2013-02-25 >> >> Abstract: >> This document proposes an allocation framework for the management of >> the LISP EID address prefix (requested in a separate document). Such >> framework relies on hierarchical distribution of the address space to >> RIRs (Regional Internet Registries), who will allocate on a temporary >> basis sub-prefixes to requesting organizations. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> >> >> >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Wed Feb 27 03:50:27 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642BE21F853C for ; Wed, 27 Feb 2013 03:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 twFpehFJwvc6 for ; Wed, 27 Feb 2013 03:50:26 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1C18321F854C for ; Wed, 27 Feb 2013 03:50:25 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so376969wey.21 for ; Wed, 27 Feb 2013 03:50:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=Hh8GCMbRkK8zeQ1jSonXQIu2XOlXOF/eqogClIqj3gY=; b=iJoCDDKPjI688XwKhD8RL2BiSg020VAHXCvwxobIavelIp0le1f+xXm0crXmUvg2kp irzUs1y5kGoFc+5834ZELE42t4mvTCN2RnMmHzXKpbjxw13EsMdFvN9DtxHz1kq5y+MF ydbkF3ZLfY3hd8DWWVN4xDjTqEVZPhj/VcXiyPan3uCYrNpdL/YP0rX+JF5MQMW1oVj7 0w34a2np8HH51hsSRN4Uf3DFPZGkzBNx7lcJiageSOgQmSpTWh7ghXjWdiK6F2AtU4I5 9By2P2WrQvxvA64Do+SO9ahBjpdWhVC39qSdThOYiiL7ELRw6ZPNio91yD99iEEcWAQ/ HP+g== X-Received: by 10.194.158.198 with SMTP id ww6mr3274538wjb.44.1361965825188; Wed, 27 Feb 2013 03:50:25 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:3c79:c727:50b7:beb5? ([2001:660:330f:a4:3c79:c727:50b7:beb5]) by mx.google.com with ESMTPS id n10sm8211340wia.0.2013.02.27.03.50.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 03:50:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: Date: Wed, 27 Feb 2013 12:50:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E126D54-B9FF-4A50-9B5F-F8C71B862CCB@gigix.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkPBuKZbr3xYSOwnCWVgmx2HM6nmVa7HdLJB3R/TqaD4csiWL/hooGIj0EDYpXTevt9VRom Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 11:50:27 -0000 Hi, On 27 Feb. 2013, at 01:26 , Terry Manderson = wrote: > Speaking just as a WG participant. >=20 > I would rather a document like this focus purely on the allocation > criteria that needs to be applied to: > 1) An experimental EID block > 2) ongoing LISP allocations beyond the life of the experiment >=20 > Given the expected (numbering) requirements of a LISP site. >=20 > Simply, while it is temping to use the RIRs, and name them, it is not > appropriate in my opinion to assign work to the RIRs. That is the job = of > their membership. >=20 > Similarly, what policies the RIRs have now are all subject to change > within their own policy development processes. Please don't re-codify = them > here. I would also prefer to see this document take the approach of > defining what is best for LISP, not how can we use the RIRs as an > allocation framework. The concern I have is that if LISP ends up = requiring > something very different to how the RIRs do it - we would be doing a > disservice to both LISP and the RIRs by pushing it that way. The idea was not to impose anything to RIRs , but rather to use the = document as starting point to discuss with them. Having said that, I've got the point: "let's document EID allocation = requirements and framework without referring to a specific entity". Is that correct? >=20 > The definition of terms is well stated elsewhere, perhaps you can = point to > those locations? There is a pointer for each term. The terms are "duplicated" here just = to offer an handy reading. There is no harm in keeping them. ciao Luigi >=20 > Cheers > Terry >=20 > On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >=20 >>=20 >>=20 >>=20 >> FYI a new version is available. >>=20 >>=20 >> Comments still welcome ;-) >>=20 >>=20 >> L. >>=20 >> Begin forwarded message: >>=20 >>=20 >> From: >> internet-drafts@ietf.org >>=20 >> Subject: >> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>=20 >> Date: >> 25 February 2013 21:47:29 GMT+01:00 >>=20 >> To: >> i-d-announce@ietf.org >>=20 >> Reply-To: >> internet-drafts@ietf.org >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : LISP EID Block Management Guidelines >> Author(s) : Luigi Iannone >> Roger Jorgensen >> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >> Pages : 9 >> Date : 2013-02-25 >>=20 >> Abstract: >> This document proposes an allocation framework for the management of >> the LISP EID address prefix (requested in a separate document). Such >> framework relies on hierarchical distribution of the address space to >> RIRs (Regional Internet Registries), who will allocate on a temporary >> basis sub-prefixes to requesting organizations. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-iannone-lisp-eid-block-mgmnt-01 >>=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 >>=20 >>=20 >>=20 >>=20 >>=20 From ggx@gigix.net Wed Feb 27 03:59:55 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6961B21F845D for ; Wed, 27 Feb 2013 03:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 d46VYuFYeXqO for ; Wed, 27 Feb 2013 03:59:51 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6321F841B for ; Wed, 27 Feb 2013 03:59:51 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so375425wgb.21 for ; Wed, 27 Feb 2013 03:59:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=k5E50IdYDpo08NCAxyhUHzD0JmEcl8o/gIpn082y0sc=; b=QZIt+CNGQhxZ08gW7xAxswI4QYJhvVEwVtEd+5XHlKLuch3jFWanXifeAhCLFgb19g pGTNZQhUE71/MhKzA4xIOkjfpNeNmx+ZfrHWVDWpERVzZagvOgvTWKLI7L7bWZOM1AmH JRZSIHEI9vqKwFMd+dPtthXhsULaedvHpzg+tF6+ek/T6E4V5twPDpF0cnD/Fd0ItQdf MjpIXp6kHTiMmCuqPQRQ6ZYuF6cLe/I8lWMG43GQmQIgMK4qqrFNpSQ4WDCRpb7qlFjO iSDU/gIT+xcF2CrvubeNf65nZaYKomNB+4V63Mgqx4jmdSE1mEIaeF4Hyl4OOzsVWnRQ 2jeg== X-Received: by 10.194.176.165 with SMTP id cj5mr3352496wjc.37.1361966390296; Wed, 27 Feb 2013 03:59:50 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:3c79:c727:50b7:beb5? ([2001:660:330f:a4:3c79:c727:50b7:beb5]) by mx.google.com with ESMTPS id ex15sm26832402wid.5.2013.02.27.03.59.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 03:59:49 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <512D576B.6030009@joelhalpern.com> Date: Wed, 27 Feb 2013 12:59:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> References: <512D576B.6030009@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlZLZuR7zN+424DTSN/RJ7Uz2nIM2SbA9vGFdPwEs4UZFeTm4PckdGbSfmgasSzz5IMhUVJ Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 11:59:55 -0000 Hi, On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote: > As a participant, I have an even stronger pinion on the RIR references = than terry. >=20 > I think that the block management needs to define > o who the root is > o what policy we require for allocating blocks to allocators (the root = is not an allocator > o What the behavioral requirements are for an allocator > o are there any special requirements for re-delegating to another = allocator? > o What policies allocators should respect for end site allocation >=20 > Once we have this defined, then organizations that wish to participate = can do so. If the RIRs want to come play, they may. If not, then they = don't. >=20 Got it, is what I've also understood from Terry's point. Again, there was no intention to put work on RIRs back, rather to show = that we can come up with a framework that involves RIRs and is = compatible with current RIRs' policies. (apparently the message was not = clear ;-) ). It comes to my mind the question of what we are going to do with the EID = block if in 10 years the IETF decides that LISP is the best thing ever = and we need to assign the EID block permanently? Ideas are welcome :-) ciao L. > (Repeated for clarity, the above is a personal opinion, not a WG chair = position, nor associated with any other hats I may have.) >=20 > Yours, > Joel >=20 > On 2/26/2013 7:26 PM, Terry Manderson wrote: >> Speaking just as a WG participant. >>=20 >> I would rather a document like this focus purely on the allocation >> criteria that needs to be applied to: >> 1) An experimental EID block >> 2) ongoing LISP allocations beyond the life of the experiment >>=20 >> Given the expected (numbering) requirements of a LISP site. >>=20 >> Simply, while it is temping to use the RIRs, and name them, it is not >> appropriate in my opinion to assign work to the RIRs. That is the job = of >> their membership. >>=20 >> Similarly, what policies the RIRs have now are all subject to change >> within their own policy development processes. Please don't re-codify = them >> here. I would also prefer to see this document take the approach of >> defining what is best for LISP, not how can we use the RIRs as an >> allocation framework. The concern I have is that if LISP ends up = requiring >> something very different to how the RIRs do it - we would be doing a >> disservice to both LISP and the RIRs by pushing it that way. >>=20 >> The definition of terms is well stated elsewhere, perhaps you can = point to >> those locations? >>=20 >> Cheers >> Terry >>=20 >> On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> FYI a new version is available. >>>=20 >>>=20 >>> Comments still welcome ;-) >>>=20 >>>=20 >>> L. >>>=20 >>> Begin forwarded message: >>>=20 >>>=20 >>> From: >>> internet-drafts@ietf.org >>>=20 >>> Subject: >>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>>=20 >>> Date: >>> 25 February 2013 21:47:29 GMT+01:00 >>>=20 >>> To: >>> i-d-announce@ietf.org >>>=20 >>> Reply-To: >>> internet-drafts@ietf.org >>>=20 >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>=20 >>>=20 >>> Title : LISP EID Block Management Guidelines >>> Author(s) : Luigi Iannone >>> Roger Jorgensen >>> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >>> Pages : 9 >>> Date : 2013-02-25 >>>=20 >>> Abstract: >>> This document proposes an allocation framework for the management = of >>> the LISP EID address prefix (requested in a separate document). = Such >>> framework relies on hierarchical distribution of the address space = to >>> RIRs (Regional Internet Registries), who will allocate on a = temporary >>> basis sub-prefixes to requesting organizations. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>>=20 >>> A diff from the previous version is available at: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-iannone-lisp-eid-block-mgmnt-01 >>>=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 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Wed Feb 27 08:21:26 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F1421F8667 for ; Wed, 27 Feb 2013 08:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 N8GFwOnwN0pD for ; Wed, 27 Feb 2013 08:21:25 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id D647E21F868B for ; Wed, 27 Feb 2013 08:21:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C2B111C0858; Wed, 27 Feb 2013 08:21:25 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-134.clppva.east.verizon.net [70.106.134.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1F7891C050E; Wed, 27 Feb 2013 08:21:00 -0800 (PST) Message-ID: <512E3248.1020003@joelhalpern.com> Date: Wed, 27 Feb 2013 11:20:24 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Luigi Iannone References: <512D576B.6030009@joelhalpern.com> <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> In-Reply-To: <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:21:26 -0000 Actually Luigi, in my personal opinion: 1) It is not our job or our requirement to involve the RIRs. It is our job to come up with what we think LISP and the Internet need for EID allocation. 2) I would be really surprised if EID allocation policies were at all related to current RIR address allocation policies. The behaviors are VERY different, as are the assignment implications. Yours, Joel On 2/27/2013 6:59 AM, Luigi Iannone wrote: > Hi, > > > On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote: > >> As a participant, I have an even stronger pinion on the RIR references than terry. >> >> I think that the block management needs to define >> o who the root is >> o what policy we require for allocating blocks to allocators (the root is not an allocator >> o What the behavioral requirements are for an allocator >> o are there any special requirements for re-delegating to another allocator? >> o What policies allocators should respect for end site allocation >> >> Once we have this defined, then organizations that wish to participate can do so. If the RIRs want to come play, they may. If not, then they don't. >> > > Got it, is what I've also understood from Terry's point. > > Again, there was no intention to put work on RIRs back, rather to show that we can come up with a framework that involves RIRs and is compatible with current RIRs' policies. (apparently the message was not clear ;-) ). > > It comes to my mind the question of what we are going to do with the EID block if in 10 years the IETF decides that LISP is the best thing ever and we need to assign the EID block permanently? > > Ideas are welcome :-) > > ciao > > L. > > >> (Repeated for clarity, the above is a personal opinion, not a WG chair position, nor associated with any other hats I may have.) >> >> Yours, >> Joel >> >> On 2/26/2013 7:26 PM, Terry Manderson wrote: >>> Speaking just as a WG participant. >>> >>> I would rather a document like this focus purely on the allocation >>> criteria that needs to be applied to: >>> 1) An experimental EID block >>> 2) ongoing LISP allocations beyond the life of the experiment >>> >>> Given the expected (numbering) requirements of a LISP site. >>> >>> Simply, while it is temping to use the RIRs, and name them, it is not >>> appropriate in my opinion to assign work to the RIRs. That is the job of >>> their membership. >>> >>> Similarly, what policies the RIRs have now are all subject to change >>> within their own policy development processes. Please don't re-codify them >>> here. I would also prefer to see this document take the approach of >>> defining what is best for LISP, not how can we use the RIRs as an >>> allocation framework. The concern I have is that if LISP ends up requiring >>> something very different to how the RIRs do it - we would be doing a >>> disservice to both LISP and the RIRs by pushing it that way. >>> >>> The definition of terms is well stated elsewhere, perhaps you can point to >>> those locations? >>> >>> Cheers >>> Terry >>> >>> On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >>> >>>> >>>> >>>> >>>> FYI a new version is available. >>>> >>>> >>>> Comments still welcome ;-) >>>> >>>> >>>> L. >>>> >>>> Begin forwarded message: >>>> >>>> >>>> From: >>>> internet-drafts@ietf.org >>>> >>>> Subject: >>>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>>> >>>> Date: >>>> 25 February 2013 21:47:29 GMT+01:00 >>>> >>>> To: >>>> i-d-announce@ietf.org >>>> >>>> Reply-To: >>>> internet-drafts@ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : LISP EID Block Management Guidelines >>>> Author(s) : Luigi Iannone >>>> Roger Jorgensen >>>> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >>>> Pages : 9 >>>> Date : 2013-02-25 >>>> >>>> Abstract: >>>> This document proposes an allocation framework for the management of >>>> the LISP EID address prefix (requested in a separate document). Such >>>> framework relies on hierarchical distribution of the address space to >>>> RIRs (Regional Internet Registries), who will allocate on a temporary >>>> basis sub-prefixes to requesting organizations. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp > From ljakab@ac.upc.edu Wed Feb 27 08:30:27 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1121F86B8 for ; Wed, 27 Feb 2013 08:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 QnD+t7VoWuvY for ; Wed, 27 Feb 2013 08:30:26 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id E6E4721F847A for ; Wed, 27 Feb 2013 08:30:25 -0800 (PST) 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 r1RGUIQu004790; Wed, 27 Feb 2013 17:30:18 +0100 Received: from [192.168.1.6] (unknown [89.123.104.156]) by gw.ac.upc.edu (Postfix) with ESMTP id 5F4416B01A4; Wed, 27 Feb 2013 17:30:17 +0100 (CET) Message-ID: <512E3492.9010405@ac.upc.edu> Date: Wed, 27 Feb 2013 18:30:10 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: "Templin, Fred L" References: <20130225180218.31450.57812.idtracker@ietfa.amsl.com> <512BC5C4.6090406@joelhalpern.com> <2134F8430051B64F815C691A62D9831801146A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831801146A@XCH-BLV-504.nw.nos.boeing.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 Cc: "lisp@ietf.org" Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06' 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, 27 Feb 2013 16:30:27 -0000 Hi Fred, Thank you very much for the feedback. See responses in-line below: On 02/26/13 00:55, Templin, Fred L wrote: > Hi, > > I am reading this document for the first time and had a few > comments to share below. > > Thanks - Fred > fred.l.templin@boeing.com > > 1) Section 2.5 ("Tunnel Routers Behind NAT"), this seems to > show a limitation in that there can be only one xTR behind > a NAT. I would like to address the case when there may be > many xTRs behind the NAT - can LISP do that? There is specification being worked on that will enable many xTRs behind NAT. It will, however require a Re-encapsulating Tunnel Router (RTR) to proxy all data packets for it to work. See https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal > > 2) Section 2.6, I don't understand why it says "MTU/PMTUD > issues minimized" for the recursive scenario? It's a typo, thanks for catching this! > > 3) Section 6.1, number 4, should say "request increase in MTU > to 1556 *or greater* on service provider connections". Indeed, will fix. > However, controlling just the first-hop interface MTU > does not assure MTU mitigations across the entire path. > Similarly, "care must be taken that ICMP is not being > filtered" cannot be assured along the entire path. And, > studies have shown that ICMP filtering does impact MTU > handling in current operational practices: > > http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf True, we are citing RFC 4459 at the end of section 2.1 with regard to this issue. Would it help if we referenced it in this section as well? > > Additionally, I have a use case that I'm not sure is well addressed by > the document. I would like to address the use case of mobile networks > configured as stub sites that connect to ISPs via a mobile router. Each > mobile router may have multiple ISP connections, and can change its ISP > addresses dynamically as it moves around. Some of the ISP addresses may > be global and others may be private, such as behind a carrier-grade NAT. > Many such mobile routers may be located behind the same NAT. > > I want to give each mobile router an EID prefix that it can use to number > interfaces within the mobile network. The mobile network may contain just > one interface, a few interfaces, or it may contain many interfaces. > > I now want that the mobile network can remain reachable from the outside > world by the same EID prefix addresses even as the mobile router travels > around dynamically. The mobile router will need an xTR so that its ISPs > will not filter its packets that use EID source addresses. I also want > the mobile router to be able to traffic engineer in both the outgoing > *and* incoming directions. For this, there needs to be some sort of > server sitting outside of any NATs that the mobile router can "register" > itself with. The mobile router should be able to change between different > servers as it moves around, e.g., to reduce path stretch or in the > event of a server failure. The servers in turn associate with proxy > xTRs so that outgoing packets destined to EIDs located in distant > networks can be routed appropriately. > > This is the way IRON sets things up. Can it also be done with LISP? Yes, using the NAT traversal specification I mentioned above. The mobile router should be an xTR itself, and will receive a list of RTRs (what you call servers above) it can use for traversing the NAT (for the connections where a NAT is detected). Path stretch optimizations are certainly possible, they depend on the implementation of the Map-Server. Incoming traffic engineering is possible with LISP, however, outgoing traffic engineering is not LISP specific, it should be done with existing mechanisms. Would you like this scenario added to the document? Best regards, -Lori From farinacci@gmail.com Wed Feb 27 10:47:10 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338EF21F8A0C for ; Wed, 27 Feb 2013 10:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=-1.424, BAYES_00=-2.599, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001, MANGLED_LIPS=2.3, MANGLED_SAVELE=2.3, 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 AQa+0nwjJdaK for ; Wed, 27 Feb 2013 10:47:04 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 68DFE21F89A4 for ; Wed, 27 Feb 2013 10:47:04 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id um15so543144pbc.28 for ; Wed, 27 Feb 2013 10:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer; bh=qDA7k+2xufvmSzWaF0N0BMTgUM729QNWo/F9tv0lD60=; b=Nfh3k35TkMbfRmC8rl1E2yzj+1DoLr2RYFWgRjnoyzZywQOdgGUquZJlBN9bMeS2j6 f2V17V74x4MNiDFHHI6qLCXQ3DeUVLJ8PKm3VtTikezWnVJqogM8MRsqUHs9TigC7jIb 54A8cPmafuf1Hp9NfRikiVT1csB1R4SdJMeLpXYxQAMXBz5l4HUB+5dOTB2fLmDgV+8F 1UIiU6I86jTPQnH5wRsaS9kJ3/cAGgeiJu2gPfH9iO1L/bhJPgJ1u7dpWnpHlOho/rg9 PUlWqWD2jFF86zVoWrlQ7ApMGsPguR3Ft1tvPELU/HgolaEA2xnNpRmebLM9qK+y6j7s bVew== X-Received: by 10.68.127.202 with SMTP id ni10mr4874979pbb.124.1361990824183; Wed, 27 Feb 2013 10:47:04 -0800 (PST) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPS id qb10sm5449779pbb.43.2013.02.27.10.47.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 10:47:03 -0800 (PST) From: Dino Farinacci Content-Type: multipart/mixed; boundary="Apple-Mail=_8A75D041-7E4D-45A0-B151-88ED444EDAE7" Message-Id: <88780A72-AB8F-4BB9-BE45-E531790B3CD1@gmail.com> Date: Wed, 27 Feb 2013 10:47:01 -0800 To: "lisp@ietf.org list list" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [lisp] Proposed changes to draft-ietf-lisp-lcaf 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, 27 Feb 2013 18:47:10 -0000 --Apple-Mail=_8A75D041-7E4D-45A0-B151-88ED444EDAE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, after conferring with the LCAF and LSIP-RE authors, we decided = these changes are required to be compatible with draft-codas-lisp-re-02. = Please comment. I will try to post Friday but if not allowed, I will do = so IETF week. B.1. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. I plan to present and on the agenda for LISP-RE in Orlando. Thanks, Dino/Dave/Job/Albert/Florin/Domingo --Apple-Mail=_8A75D041-7E4D-45A0-B151-88ED444EDAE7 Content-Disposition: attachment; filename=rfcdiff-lisp-lcaf-01-to-02.html Content-Type: text/html; name="rfcdiff-lisp-lcaf-01-to-02.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-lcaf-01.txt draft-ietf-lisp-lcaf-02.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                              cisco Systems
Expires: July 11, August 30, 2013                                     J. Snijders
                                                            InTouch N.V.
                                                         January 7,
                                                       February 26, 2013

                  LISP Canonical Address Format (LCAF)
                        draft-ietf-lisp-lcaf-01
                        draft-ietf-lisp-lcaf-02

Abstract

   This draft defines a canonical address format encoding used in LISP
   control messages and in the encoding of lookup keys for the LISP
   Mapping Database System.

Status of this Memo

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

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

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

   This Internet-Draft will expire on July 11, August 30, 2013.

Copyright Notice

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

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  LISP Canonical Address Format Encodings  . . . . . . . . . . .  5
   4.  LISP Canonical Address Applications  . . . . . . . . . . . . .  7
     4.1.  Segmentation using LISP  . . . . . . . . . . . . . . . . .  7
     4.2.  Carrying AS Numbers in the Mapping Database  . . . . . . .  8
     4.3.  Convey Application Specific Data . . . . . . . . . . . . .  9
     4.4.  Assigning Geo Coordinates to Locator Addresses . . . . . . 10
     4.5.  Generic Database Mapping Lookups . . . . . . . . . . . . . 11 12
     4.6.  NAT Traversal Scenarios  . . . . . . . . . . . . . . . . . 13
     4.7.  PETR Admission Control Functionality . . . . . . . . . . . 14 15
     4.8.  Multicast Group Membership Information . . . . . . . . . . 16
     4.9.  Traffic Engineering using Re-encapsulating Tunnels . . . . 17 18
     4.10. Storing Security Data in the Mapping Database  . . . . . . 19
     4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20
     4.12. Replication List Entries for Multicast Forwarding  . . . . 21
     4.13. Applications for AFI List Type . . . . . . . . . . . . . . 21
       4.12.1. 22
       4.13.1.  Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 21
       4.12.2. 22
       4.13.2.  Layer-2 VPNs  . . . . . . . . . . . . . . . . . . . . 22
       4.12.3. 23
       4.13.3.  ASCII Names in the Mapping Database . . . . . . . . . 22
       4.12.4. 23
       4.13.4.  Using Recursive LISP Canonical Address Encodings  . . 23
       4.12.5. 24
       4.13.5.  Compatibility Mode Use Case . . . . . . . . . . . . . 24 25
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25 26
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26 27
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 28
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 27 28
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 27 28
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 29 30
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 30 31
     B.1.  Changes to draft-ietf-lisp-01.txt draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . . . 30 31
     B.2.  Changes to draft-ietf-lisp-00.txt draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 31
     B.3.  Changes to draft-ietf-lisp-lcaf-00.txt . . 30 . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 32

1.  Introduction

   The LISP architecture and protocols [LISP] [RFC6830] introduces two new
   numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
   (RLOCs) which are intended to replace most use of IP addresses on the
   Internet.  To provide flexibility for current and future
   applications, these values can be encoded in LISP control messages
   using a general syntax that includes Address Family Identifier (AFI),
   length, and value fields.

   Currently defined AFIs include IPv4 and IPv6 addresses, which are
   formatted according to code-points assigned in [AFI] as follows:

   IPv4 Encoded Address:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Encoded Address:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 2            |       IPv6 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv6 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This document describes the currently-defined AFIs the LISP protocol
   uses along with their encodings and introduces the LISP Canonical
   Address Format (LCAF) that can be used to define the LISP-specific
   encodings for arbitrary AFI values.

2.  Definition of Terms

   Address Family Identifier (AFI):  a term used to describe an address
      encoding in a packet.  An address family currently defined for
      IPv4 or IPv6 addresses.  See [AFI] and [RFC1700] for details.  The
      reserved AFI value of 0 is used in this specification to indicate
      an unspecified encoded address where the the length of the address
      is 0 bytes following the 16-bit AFI value of 0.

   Unspecified Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 0            |    <nothing follows AFI=0>    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source and destination address fields of the first
      (most inner) LISP header of a packet.  The host obtains a
      destination EID the same way it obtains a destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an egress
      tunnel router (ETR).  It is the output of a EID-to-RLOC mapping
      lookup.  An EID maps to one or more RLOCs.  Typically, RLOCs are
      numbered from topologically aggregatable blocks that are assigned
      to a site at each point to which it attaches to the global
      Internet; where the topology is defined by the connectivity of
      provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

3.  LISP Canonical Address Format Encodings

   IANA has assigned AFI value 16387 (0x4003) to the LISP architecture
   and protocols.  This specification defines the encoding format of the
   LISP Canonical Address (LCA).

   The first 4 bytes of an LISP Canonical Address are followed by a
   variable length of fields:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type       |     Rsvd2     |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Rsvd1:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

   Flags:  this 8-bit field is for future definition and use.  For now,
      set to zero on transmission and ignored on receipt.

   Type:  this 8-bit field is specific to the LISP Canonical Address
      formatted encodings, values are:

     Type 0:  Null Body Type

     Type 1:  AFI List Type

     Type 2:  Instance ID Type

     Type 3:  AS Number Type

     Type 4:  Application Data Type

     Type 5:  Geo Coordinates Type

     Type 6:  Opaque Key Type

     Type 7:  NAT-Traversal Type

     Type 8:  Nonce Locator Type

     Type 9:  Multicast Info Type
     Type 10:  Explicit Locator Path Type

     Type 11:  Security Key Type

     Type 12:  Source/Dest Key Type

     Type 13:  Replication List Entry Type

   Rsvd2:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

   Length:  this 16-bit field is in units of bytes and covers all of the
      LISP Canonical Address payload, starting and including the byte
      after the Length field.  So any LCAF encoded address will have a
      minimum length of 8 bytes when the Length field is 0.  The 8 bytes
      include the AFI, Flags, Type, Reserved, and Length fields.  When
      the AFI is not next to encoded address in a control message, then
      the encoded address will have a minimum length of 6 bytes when the
      Length field is 0.  The 6 bytes include the Flags, Type, Reserved,
      and Length fields.

4.  LISP Canonical Address Applications

4.1.  Segmentation using LISP

   When multiple organizations inside of a LISP site are using private
   addresses [RFC1918] as EID-prefixes, their address spaces must remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.

   Another use for the Instance ID LISP Canonical Address Format is when
   creating multiple segmented VPNs inside of a LISP site where keeping
   EID-prefix based subnets is desirable.

   Instance ID LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 2    | IID mask-len  |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Instance ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IID mask-len:  if the AFI is set to 0, then this format is not
      encoding an extended EID-prefix but rather an instance-ID range
      where the 'IID mask-len' indicates the number of high-order bits
      used in the Instance ID field for the range.

   Length value n:  length in bytes of the AFI address that follows the
      Instance ID field including the AFI field itself.

   Instance ID:  the low-order 24-bits that can go into a LISP data
      header when the I-bit is set.  See [LISP] [RFC6830] for details.

   AFI = x:  x can be any AFI value from [AFI].

   This LISP Canonical Address Type can be used to encode either EID or
   RLOC addresses.

4.2.  Carrying AS Numbers in the Mapping Database

   When an AS number is stored in the LISP Mapping Database System for
   either policy or documentation reasons, it can be encoded in a LISP
   Canonical Address.

   AS Number LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 3    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           AS Number                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      AS Number field including the AFI field itself.

   AS Number:  the 32-bit AS number of the autonomous system that has
      been assigned either the EID or RLOC that follows.

   AFI = x:  x can be any AFI value from [AFI].

   The AS Number Canonical Address Type can be used to encode either EID
   or RLOC addresses.  The former is used to describe the LISP-ALT AS
   number the EID-prefix for the site is being carried for.  The latter
   is used to describe the AS that is carrying RLOC based prefixes in
   the underlying routing system.

4.3.  Convey Application Specific Data

   When a locator-set needs to be conveyed based on the type of
   application or the Per-Hop Behavior (PHB) of a packet, the
   Application Data Type can be used.

   Application Data LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 4    |     Rsvd2     |             8 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       IP TOS, IPv6 TC, or Flow Label          |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Local Port          |         Remote Port           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      8-byte Application Data fields including the AFI field itself.

   IP TOS, IPv6 TC, or Flow Label:  this field stores the 8-bit IPv4 TOS
      field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow
      Label used in an IPv6 header.

   Local Port/Remote Port:  these fields are from the TCP, UDP, or SCTP
      transport header.

   AFI = x:  x can be any AFI value from [AFI].

   The Application Data Canonical Address Type is used for an EID
   encoding when an ITR wants a locator-set for a specific application.
   When used for an RLOC encoding, the ETR is supplying a locator-set
   for each specific application is has been configured to advertise.

4.4.  Assigning Geo Coordinates to Locator Addresses

   If an ETR desires to send a Map-Reply describing the Geo Coordinates
   for each locator in its locator-set, it can use the Geo Coordinate
   Type to convey physical location information.

   Coordinates are specified using the WGS-84 (World Geodetic System)
   reference coordinate system [WGS-84].

   Geo Coordinate LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 5    |     Rsvd2     |            12 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|     Latitude Degrees        |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|     Longitude Degrees       |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Altitude                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      8-byte Longitude and Latitude fields including the AFI field
      itself.

   N: When set to 1 means North, otherwise South.

   Latitude Degrees:  Valid values range from 0 to 90 degrees above or
      below the equator (northern or southern hemisphere, respectively).

   Latitude Minutes:  Valid values range from 0 to 59.

   Latitude Seconds:  Valid values range from 0 to 59.

   E: When set to 1 means East, otherwise West.

   Longitude Degrees:  Value values are from 0 to 180 degrees right or
      left of the Prime Meridian.

   Longitude Minutes:  Valid values range from 0 to 59.

   Longitude Seconds:  Valid values range from 0 to 59.

   Altitude:  Height relative to sea level in meters.  This is a signed
      integer meaning that the altitude could be below sea level.  A
      value of 0x7fffffff indicates no Altitude value is encoded.

   AFI = x:  x can be any AFI value from [AFI].

   The Geo Coordinates Canonical Address Type can be used to encode
   either EID or RLOC addresses.  When used for EID encodings, you can
   determine the physical location of an EID along with the topological
   location by observing the locator-set.

4.5.  Generic Database Mapping Lookups

   When the LISP Mapping Database system holds information accessed by a
   generic formatted key (where the key is not the usual IPv4 or IPv6
   address), an opaque key may be desirable.

   Opaque Key LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 6    |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Key Field Num |      Key Wildcard Fields      |   Key . . .   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       . . . Key                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the type's payload.  The value n
      is the number of bytes that follow this Length field.

   Key Field Num:  the number of fields (minus 1) the key can be broken
      up into.  The width of the fields are fixed length.  So for a key
      size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2
      bytes in length.  Valid values for this field range from 0 to 15
      supporting a maximum of 16 field separations.

   Key Wildcard Fields:  describes which fields in the key are not used
      as part of the key lookup.  This wildcard encoding is a bitfield.
      Each bit is a don't-care bit for a corresponding field in the key.
      Bit 0 (the low-order bit) in this bitfield corresponds the first
      field, right-justified in the key, bit 1 the second field, and so
      on.  When a bit is set in the bitfield it is a don't-care bit and
      should not be considered as part of the database lookup.  When the
      entire 16-bits is set to 0, then all bits of the key are used for
      the database lookup.

   Key:  the variable length key used to do a LISP Database Mapping
      lookup.  The length of the key is the value n (shown above) minus
      3.

4.6.  NAT Traversal Scenarios

   When a LISP system is conveying global address and mapped port
   information when traversing through a NAT device, the NAT-Traversal
   LCAF Type is used.  See [LISP-NATT] for details.

   NAT-Traversal Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 7    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       MS UDP Port Number      |      ETR UDP Port Number      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |  Global ETR RLOC Address  ... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       MS RLOC Address  ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          | Private ETR RLOC Address  ... |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |      RTR RLOC Address 1 ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |      RTR RLOC Address k ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI addresses that follows
      the UDP Port Number field including the AFI fields themselves.

   MS UDP Port Number:  this is the UDP port number of the Map-Server
      and is set to 4342.

   ETR UDP Port Number:  this is the port number returned to a LISP
      system which was copied from the source port from a packet that
      has flowed through a NAT device.

   AFI = x:  x can be any AFI value from [AFI].

   Global ETR RLOC Address:  this is an address known to be globally
      unique built by NAT-traversal functionality in a LISP router.

   MS RLOC Address:  this is the address of the Map-Server used in the
      destination RLOC of a packet that has flowed through a NAT device.

   Private ETR RLOC Address:  this is an address known to be a private
      address inserted in this LCAF format by a LISP router that resides
      on the private side of a NAT device.

   RTR RLOC Address:  this is an encapsulation address used by an ITR or
      PITR which resides behind a NAT device.  This address is known to
      have state in a NAT device so packets can flow from it to the LISP
      ETR behind the NAT.  There can be one or more NTR addresses
      supplied in these set of fields.  The number of NTRs encoded is
      determined by the LCAF length field.  When there are no NTRs
      supplied, the NTR fields can be omitted and reflected by the LCAF
      length field or an AFI of 0 can be used to indicate zero NTRs
      encoded.

4.7.  PETR Admission Control Functionality

   When a public PETR device wants to verify who is encapsulating to it,
   it can check for a specific nonce value in the LISP encapsulated
   packet.  To convey the nonce to admitted ITRs or PITRs, this LCAF
   format is used in a Map-Register or Map-Reply locator-record.

   Nonce Locator Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 8    |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Reserved    |                  Nonce                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Address  ...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of the AFI address that follows the
      Nonce field including the AFI field itself.

   Reserved:  must be set to zero and ignore on receipt.

   Nonce:  this is a nonce value returned by an ETR in a Map-Reply
      locator-record to be used by an ITR or PITR when encapsulating to
      the locator address encoded in the AFI field of this LCAF type.

   AFI = x:  x can be any AFI value from [AFI].

4.8.  Multicast Group Membership Information

   Multicast group information can be published in the mapping database
   so a lookup on an EID based group address can return a replication
   list of group addresses or a unicast addresses for single replication
   or multiple head-end replications.  The intent of this type of
   unicast replication is to deliver packets to multiple ETRs at
   receiver LISP multicast sites.  The locator-set encoding for this EID
   record type can be a list of ETRs when they each regsiter with "Merge
   Semantics".  The encoding can be a typical AFI encoded locator
   address.  When an RTR list is being registered (with multiple levels
   acccording to [LISP-RE]), the Replication List Entry LCAF type is
   used for locator encoding.

   This LCAF encoding can be used to send broadcast packets to all
   members of a subnet when each EIDs are away from their home subnet
   location.

   Multicast Info Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 9    |  Rsvd2  |R|L|J|             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved           | Source MaskLen| Group MaskLen |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |   Source/Subnet Address  ...  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Group Address  ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Reserved:  must be set to zero and ignore on receipt.

   R-bit:  this is the RP-bit that represents PIM (S,G,RP-bit) multicast
      state.  This bit can be set for Joins (when the J-bit is set) or
      for Leaves (when the L-bit is set).  See [LISP-MRSIG] for more
      usage details.

   L-bit:  this is the Leave-Request bit and is used when this LCAF type
      is present in the destination EID-prefix field of a Map-Request.
      See [LISP-MRSIG] for details.

   J-bit:  this is the Join-Request bit and is used when this LCAF type
      is present in the destination EID-prefix field of a Map-Request.
      See [LISP-MRSIG] for details.  The J-bit MUST not be set when the
      L-bit is also set in the same LCAF block.  A receiver should not
      take any specific Join or Leave action when both bits are set.

   Source MaskLen:  the mask length of the source prefix that follows.

   Group MaskLen:  the mask length of the group prefix that follows.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

4.9.  Traffic Engineering using Re-encapsulating Tunnels

   For a given EID lookup into the mapping database, this LCAF format
   can be returned to provide a list of locators in an explicit re-
   encapsulation path.  See [LISP-TE] for details.

   Explicit Locator Path (ELP) Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 10   |     Rsvd2     |               n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           Rsvd3         |L|P|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reencap Hop 1  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           Rsvd3         |L|P|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Reencap Hop k  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

   Lookup bit (L):  this is the Lookup bit used to indicate to the user
      of the ELP to not use this address for encapsulation but to look
      it up in the mapping database system to obtain an encapsulating
      RLOC address.

   RLOC-Probe bit (P):  this is the RLOC-probe bit which means the
      Reencap Hop allows RLOC-probe messages to be sent to it.  When the
      R-bit is set to 0, RLOC-probes must not be sent.  When a Reencap
      Hop is an anycast address then multiple physical Reencap Hops are
      using the same RLOC address.  In this case, RLOC-probes are not
      needed because when the closest RLOC address is not reachable
      another RLOC address can reachable.

   Strict bit (S):  this the strict bit which means the associated
      Rencap Hop is required to be used.  If this bit is 0, the
      reencapsulator can skip this Reencap Hop and go to the next one in
      the list.

4.10.  Storing Security Data in the Mapping Database

   When a locator in a locator-set has a security key associated with
   it, this LCAF format will be used to encode key material.  See
   [LISP-DDT] for details.

   Security Key Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 11   |      Rsvd2    |             6 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Key Count   |      Rsvd3    | Key Algorithm |   Rsvd4     |R|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Key Length          |       Key Material ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        ... Key Material                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |       Locator Address ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that start with the Key
      Material field.

   Key Count:  the Key Count field declares the number of Key sections
      included in this LCAF.

   Key Algorithm:  the Algorithm field identifies the key's
      cryptographic algorithm and specifies the format of the Public Key
      field.

   R bit:  this is the revoke bit and, if set, it specifies that this
      Key is being Revoked.

   Key Length:  this field determines the length in bytes of the Key
      Material field.

   Key Material:  the Key Material field stores the key material.  The
      format of the key material stored depends on the Key Algorithm
      field.

   AFI = x:  x can be any AFI value from [AFI].This is the locator
      address that owns the encoded security key.

4.11.  Source/Destination 2-Tuple Lookups

   When both a source and destination address of a flow needs
   consideration for different locator-sets, this 2-tuple key is used in
   EID fields in LISP control messages.  When the Source/Dest key is
   registered to the mapping database, it can be encoded as a source-
   prefix and destination-prefix.  When the Source/Dest is used as a key
   for a mapping database lookup the source and destination come from a
   data packet.

   Source/Dest Key Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 12   |     Rsvd2     |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved           |   Source-ML   |    Dest-ML    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |         Source-Prefix ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |     Destination-Prefix ...    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Reserved:  must be set to zero and ignore on receipt.

   Source-ML:  the mask length of the source prefix that follows.

   Dest-ML:  the mask length of the destination prefix that follows.

   AFI = x:  x can be any AFI value from [AFI].  When a specific AFI has
      its own encoding of a multicast address, this field must be either
      a group address or a broadcast address.

   Refer to [LISP-TE] for usage details.

4.12.  Replication List Entries for Multicast Forwarding

   The Replication List Entry LCAF type is an encoding for a locator
   being used for unicast replication according to the specification in
   [LISP-RE].  This locator encoding is pointed to by a Multicast Info
   LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs)
   that are participating in an overlay distribution tree.  Each RTR
   will register its locator address and its configured level in the
   distribution tree.

   Replication List Entry Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 13   |    Rsvd2      |             4 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Rsvd3            |     Rsvd4     |  Level Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           RTR/ETR #1 ...      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Rsvd3            |     Rsvd4     |  Level Value  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = x          |           RTR/ETR  #n ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes of fields that follow.

   Rsvd{1,2,3,4}:  must be set to zero and ignore on receipt.

   Level Value:  this value is associated with the level of hierarchy
      the RTR resides in an overlay distribution tree.  The level
      numbers are ordered from lowest value being close to the ITR
      (meaning that ITRs replicate to level-0 RTRs) and higher levels
      are further downstream on the distribution tree closer to ETRs of
      multicast receiver sites.

   AFI = x:  x can be any AFI value from [AFI].  A specific AFI has its
      own encoding of either a unicast or multicast locator address.
      All RTR/ETR entries for the same level should be combined together
      by a Map-Server to avoid searching through the entire multi-level
      list of locator entries in a Map-Reply message.

4.13.  Applications for AFI List Type

4.12.1.

4.13.1.  Binding IPv4 and IPv6 Addresses

   When header translation between IPv4 and IPv6 is desirable a LISP
   Canonical Address can use the AFI List Type to carry multiple AFIs in
   one LCA AFI.

   Bounded Address LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |         2 + 4 + 2 + 16        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |            AFI = 2            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          IPv6 Address ...                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address  ...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ...  IPv6 Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 24 when IPv4 and IPv6 AFI
      encoded addresses are used.

   This type of address format can be included in a Map-Request when the
   address is being used as an EID, but the Mapping Database System
   lookup destination can use only the IPv4 address.  This is so a
   Mapping Database Service Transport System, such as LISP-ALT [ALT],
   [RFC6836], can use the Map-Request destination address to route the
   control message to the desired LISP site.

4.12.2.

4.13.2.  Layer-2 VPNs

   When MAC addresses are stored in the LISP Mapping Database System,
   the AFI List Type can be used to carry AFI 6.

   MAC Address LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |             2 + 6             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             AFI = 6           |    Layer-2 MAC Address  ...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    ... Layer-2 MAC Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 8 when MAC address AFI encoded
      addresses are used.

   This address format can be used to connect layer-2 domains together
   using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN.
   In this use-case, a MAC address is being used as an EID, and the
   locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or
   even another MAC address being used as an RLOC.

4.12.3.

4.13.3.  ASCII Names in the Mapping Database

   If DNS names or URIs are stored in the LISP Mapping Database System,
   the AFI List Type can be used to carry an ASCII string where it is
   delimited by length 'n' of the LCAF Length encoding.

   ASCII LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |             2 + n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             AFI = 17          |      DNS Name or URI  ...     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length value n:  length in bytes AFI=17 field and the null-terminated
      ASCII string (the last byte of 0 is included).

4.12.4.

4.13.4.  Using Recursive LISP Canonical Address Encodings

   When any combination of above is desirable, the AFI List Type value
   can be used to carry within the LCA AFI another LCA AFI.

   Recursive LISP Canonical Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |         4 + 8 + 2 + 4         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 4    |     Rsvd2     |              12               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   IP TOS, IPv6 QQS or Flow Label              |    Protocol   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Local Port          |         Remote Port           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            AFI = 1            |       IPv4 Address ...        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     ...  IPv4 Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  length in bytes is fixed at 18 when an AFI=1 IPv4 address is
      included.

   This format could be used by a Mapping Database Transport System,
   such as LISP-ALT [ALT], [RFC6836], where the AFI=1 IPv4 address is used as
   an EID and placed in the Map-Request destination address by the
   sending LISP system.  The ALT system can deliver the Map-Request to
   the LISP destination site independent of the Application Data Type
   AFI payload values.  When this AFI is processed by the destination
   LISP site, it can return different locator-sets based on the type of
   application or level of service that is being requested.

4.12.5.

4.13.5.  Compatibility Mode Use Case

   A LISP system should use the AFI List Type format when sending to
   LISP systems that do not support a particular LCAF Type used to
   encode locators.  This allows the receiving system to be able to
   parse a locator address for encapsulation purposes.  The list of AFIs
   in an AFI List LCAF Type has no semantic ordering and a receiver
   should parse each AFI element no matter what the ordering.

   Compatibility Mode Address Format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 1    |     Rsvd2     |            22 + 6             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           AFI = 16387         |     Rsvd1     |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 5    |     Rsvd2     |            12 + 2             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|     Latitude Degrees        |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |E|     Longitude Degrees       |    Minutes    |    Seconds    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Altitude                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              AFI = 0          |           AFI = 1             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          IPv4 Address                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If a system does not recognized the Geo Coordinate LCAF Type that is
   accompanying a locator address, an encoder can include the Geo
   Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI
   in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in
   the list is encoded with a valid AFI value to identify the locator
   address.

   A LISP system is required to support the AFI List LCAF Type to use
   this procedure.  It would skip over 10 bytes of the Geo Coordinate
   LCAF Type to get to the locator address encoding (an IPv4 locator
   address).  A LISP system that does support the Geo Coordinate LCAF
   Type can support parsing the locator address within the Geo
   Coordinate LCAF encoding or in the locator encoding that follows in
   the AFI List LCAF.

5.  Security Considerations

   There are no security considerations for this specification.  The
   security considerations are documented for the protocols that use
   LISP Canonical Addressing.  Refer to the those relevant
   specifications.

6.  IANA Considerations

   The Address Family AFI definitions from [AFI] only allocate code-
   points for the AFI value itself.  The length of the address or entity
   that follows is not defined and is implied based on conventional
   experience.  Where the LISP protocol uses LISP Canonical Addresses
   specifically, the address length definitions will be in this
   specification and take precedent over any other specification.

   An IANA Registry for LCAF Type values will be created.  The values
   that are considered for use by the main LISP specification [LISP] [RFC6830]
   will be in the IANA Registry.  Other Type values used for
   experimentation will be defined and described in this document.

7.  References

7.1.  Normative References

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

7.2.  Informative References

   [AFI]      IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [ALT]      Fuller, V.,

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)",
              draft-ietf-lisp-alt-06.txt (work in progress), March 2011.

   [LISP]     Farinacci, D., "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-12.txt (work in progress), April 2011. Alternative Logical
              Topology (LISP+ALT)", RFC 6836, January 2013.

7.2.  Informative References

   [AFI]      IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, Febuary 2007.

   [LISP-DDT]
              Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated
              Database Tree", draft-fuller-lisp-ddt-01.txt (work in
              progress).

   [LISP-MRSIG]
              Farinacci, D. and M. Napierala, "LISP Control-Plane
              Multicast Signaling",
              draft-farinacci-lisp-mr-signaling-00.txt (work in
              progress).

   [LISP-NATT]
              Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
              F., and C. White, "NAT traversal for LISP",
              draft-ermagan-lisp-nat-traversal-00.txt (work in
              progress).

   [LISP-RE]  Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
              Maino, F., and D. Farinacci, "LISP Replication
              Engineering", draft-coras-lisp-re-02.txt (work in
              progress).

   [LISP-TE]  Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic
              Engineering Use-Cases", draft-farinacci-lisp-te-01.txt
              (work in progress).

   [WGS-84]   Geodesy and Geophysics Department, DoD., "World Geodetic
              System 1984", NIMA TR8350.2, January 2000, <http://
              earth-info.nga.mil/GandG/publications/tr8350.2/
              wgs84fin.pdf>.

Appendix A.  Acknowledgments

   The authors would like to thank Vince Fuller, Gregg Schudel, Jesper
   Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for
   their technical and editorial commentary.

   The authors would like to thank Victor Moreno for discussions that
   lead to the definition of the Multicast Info LCAF type.

   The authors would like to thank Parantap Lahiri and Michael Kowal for
   discussions that lead to the definition of the Explicit Locator Path
   (ELP) LCAF type.

   The authors would like to thank Fabio Maino and Vina Ermagan for
   discussions that lead to the definition of the Security Key LCAF
   type.

   Thanks also goes to Terry Manderson for assistance obtaining a LISP
   AFI value from IANA.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-01.txt draft-ietf-lisp-lcaf-02.txt

   o  Submitted March 2013.

   o  Added new LCAF Type "Replication List Entry" to support LISP
      replication engineering use-cases.

   o  Changed references to new LISP RFCs.

B.2.  Changes to draft-ietf-lisp-lcaf-01.txt

   o  Submitted January 2013.

   o  Change longitude range from 0-90 to 0-180 in section 4.4.

   o  Added reference to WGS-84 in section 4.4.

B.2.

B.3.  Changes to draft-ietf-lisp-00.txt draft-ietf-lisp-lcaf-00.txt

   o  Posted first working group draft August 2012.

   o  This draft was renamed from draft-farinacci-lisp-lcaf-10.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: farinacci@gmail.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   Job Snijders
   InTouch N.V.
   Middenweg 76
   1097 BS Amsterdam
   The Netherlands

   Email: job@instituut.net
--Apple-Mail=_8A75D041-7E4D-45A0-B151-88ED444EDAE7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_8A75D041-7E4D-45A0-B151-88ED444EDAE7 Content-Disposition: attachment; filename=draft-ietf-lisp-lcaf-02.txt Content-Type: text/plain; name="draft-ietf-lisp-lcaf-02.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental cisco Systems Expires: August 30, 2013 J. Snijders InTouch N.V. February 26, 2013 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-02 Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 30, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Farinacci, et al. Expires August 30, 2013 [Page 1] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8 4.3. Convey Application Specific Data . . . . . . . . . . . . . 9 4.4. Assigning Geo Coordinates to Locator Addresses . . . . . . 10 4.5. Generic Database Mapping Lookups . . . . . . . . . . . . . 12 4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13 4.7. PETR Admission Control Functionality . . . . . . . . . . . 15 4.8. Multicast Group Membership Information . . . . . . . . . . 16 4.9. Traffic Engineering using Re-encapsulating Tunnels . . . . 18 4.10. Storing Security Data in the Mapping Database . . . . . . 19 4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20 4.12. Replication List Entries for Multicast Forwarding . . . . 21 4.13. Applications for AFI List Type . . . . . . . . . . . . . . 22 4.13.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 22 4.13.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 4.13.3. ASCII Names in the Mapping Database . . . . . . . . . 23 4.13.4. Using Recursive LISP Canonical Address Encodings . . 24 4.13.5. Compatibility Mode Use Case . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 7.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 31 B.1. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 31 B.2. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 31 B.3. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Farinacci, et al. Expires August 30, 2013 [Page 2] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) which are intended to replace most use of IP addresses on the Internet. To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. Farinacci, et al. Expires August 30, 2013 [Page 3] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family currently defined for IPv4 or IPv6 addresses. See [AFI] and [RFC1700] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the the length of the address is 0 bytes following the 16-bit AFI value of 0. Unspecified Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Farinacci, et al. Expires August 30, 2013 [Page 4] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). The first 4 bytes of an LISP Canonical Address are followed by a variable length of fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings, values are: Type 0: Null Body Type Type 1: AFI List Type Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Farinacci, et al. Expires August 30, 2013 [Page 5] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Type 13: Replication List Entry Type Rsvd2: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. Farinacci, et al. Expires August 30, 2013 [Page 6] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4. LISP Canonical Address Applications 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Instance ID LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | IID mask-len | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Farinacci, et al. Expires August 30, 2013 [Page 7] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. AS Number LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the AS Number field including the AFI field itself. AS Number: the 32-bit AS number of the autonomous system that has been assigned either the EID or RLOC that follows. AFI =3D x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Farinacci, et al. Expires August 30, 2013 [Page 8] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.3. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port | Remote Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Application Data fields including the AFI field itself. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port: these fields are from the TCP, UDP, or SCTP transport header. AFI =3D x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Farinacci, et al. Expires August 30, 2013 [Page 9] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.4. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Longitude and Latitude fields including the AFI field itself. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Value values are from 0 to 180 degrees right or left of the Prime Meridian. Farinacci, et al. Expires August 30, 2013 [Page 10] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Altitude: Height relative to sea level in meters. This is a signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI =3D x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Farinacci, et al. Expires August 30, 2013 [Page 11] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.5. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 6 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the type's payload. The value n is the number of bytes that follow this Length field. Key Field Num: the number of fields (minus 1) the key can be broken up into. The width of the fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 bytes in length. Valid values for this field range from 0 to 15 supporting a maximum of 16 field separations. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, right-justified in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (shown above) minus 3. Farinacci, et al. Expires August 30, 2013 [Page 12] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.6. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [LISP-NATT] for details. NAT-Traversal Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI addresses that follows the UDP Port Number field including the AFI fields themselves. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI =3D x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires August 30, 2013 [Page 13] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF format by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NTR addresses supplied in these set of fields. The number of NTRs encoded is determined by the LCAF length field. When there are no NTRs supplied, the NTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero NTRs encoded. Farinacci, et al. Expires August 30, 2013 [Page 14] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.7. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF format is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Nonce field including the AFI field itself. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. AFI =3D x: x can be any AFI value from [AFI]. Farinacci, et al. Expires August 30, 2013 [Page 15] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.8. Multicast Group Membership Information Multicast group information can be published in the mapping database so a lookup on an EID based group address can return a replication list of group addresses or a unicast addresses for single replication or multiple head-end replications. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each regsiter with "Merge Semantics". The encoding can be a typical AFI encoded locator address. When an RTR list is being registered (with multiple levels acccording to [LISP-RE]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when each EIDs are away from their home subnet location. Multicast Info Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Rsvd2 |R|L|J| 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. R-bit: this is the RP-bit that represents PIM (S,G,RP-bit) multicast state. This bit can be set for Joins (when the J-bit is set) or for Leaves (when the L-bit is set). See [LISP-MRSIG] for more usage details. L-bit: this is the Leave-Request bit and is used when this LCAF type is present in the destination EID-prefix field of a Map-Request. See [LISP-MRSIG] for details. Farinacci, et al. Expires August 30, 2013 [Page 16] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 J-bit: this is the Join-Request bit and is used when this LCAF type is present in the destination EID-prefix field of a Map-Request. See [LISP-MRSIG] for details. The J-bit MUST not be set when the L-bit is also set in the same LCAF block. A receiver should not take any specific Join or Leave action when both bits are set. Source MaskLen: the mask length of the source prefix that follows. Group MaskLen: the mask length of the group prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Farinacci, et al. Expires August 30, 2013 [Page 17] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.9. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF format can be returned to provide a list of locators in an explicit re- encapsulation path. See [LISP-TE] for details. Explicit Locator Path (ELP) Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 10 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Rsvd3 |L|P|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Rsvd3 |L|P|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can reachable. Strict bit (S): this the strict bit which means the associated Rencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. Farinacci, et al. Expires August 30, 2013 [Page 18] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.10. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF format will be used to encode key material. See [LISP-DDT] for details. Security Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that start with the Key Material field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI =3D x: x can be any AFI value from [AFI].This is the locator address that owns the encoded security key. Farinacci, et al. Expires August 30, 2013 [Page 19] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.11. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow needs consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Source/Dest Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 12 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. Dest-ML: the mask length of the destination prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Refer to [LISP-TE] for usage details. Farinacci, et al. Expires August 30, 2013 [Page 20] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.12. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [LISP-RE]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 13 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Level Value: this value is associated with the level of hierarchy the RTR resides in an overlay distribution tree. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Farinacci, et al. Expires August 30, 2013 [Page 21] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.13. Applications for AFI List Type 4.13.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry multiple AFIs in one LCA AFI. Bounded Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 4 + 2 + 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI encoded addresses are used. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Farinacci, et al. Expires August 30, 2013 [Page 22] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.13.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use-case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. 4.13.3. ASCII Names in the Mapping Database If DNS names or URIs are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string where it is delimited by length 'n' of the LCAF Length encoding. ASCII LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires August 30, 2013 [Page 23] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 Length value n: length in bytes AFI=3D17 field and the = null-terminated ASCII string (the last byte of 0 is included). 4.13.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCA AFI another LCA AFI. Recursive LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 4 + 8 + 2 + 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 QQS or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port | Remote Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 18 when an AFI=3D1 IPv4 address = is included. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=3D1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires August 30, 2013 [Page 24] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 4.13.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 22 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | AFI =3D 1 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. Farinacci, et al. Expires August 30, 2013 [Page 25] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 5. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. Refer to the those relevant specifications. Farinacci, et al. Expires August 30, 2013 [Page 26] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 6. IANA Considerations The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification. An IANA Registry for LCAF Type values will be created. The values that are considered for use by the main LISP specification [RFC6830] will be in the IANA Registry. Other Type values used for experimentation will be defined and described in this document. Farinacci, et al. Expires August 30, 2013 [Page 27] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 7. References 7.1. Normative References [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013. 7.2. Informative References [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [LISP-DDT] Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated Database Tree", draft-fuller-lisp-ddt-01.txt (work in progress). [LISP-MRSIG] Farinacci, D. and M. Napierala, "LISP Control-Plane Multicast Signaling", draft-farinacci-lisp-mr-signaling-00.txt (work in progress). [LISP-NATT] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan-lisp-nat-traversal-00.txt (work in progress). [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-02.txt (work in progress). [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-01.txt Farinacci, et al. Expires August 30, 2013 [Page 28] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 (work in progress). [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Farinacci, et al. Expires August 30, 2013 [Page 29] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. Farinacci, et al. Expires August 30, 2013 [Page 30] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. B.2. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.3. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Farinacci, et al. Expires August 30, 2013 [Page 31] =0C Internet-Draft LISP Canonical Address Format (LCAF) February 2013 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: farinacci@gmail.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Job Snijders InTouch N.V. Middenweg 76 1097 BS Amsterdam The Netherlands Email: job@instituut.net Farinacci, et al. Expires August 30, 2013 [Page 32] =0C --Apple-Mail=_8A75D041-7E4D-45A0-B151-88ED444EDAE7-- From rogerj@gmail.com Wed Feb 27 11:38:34 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EDF21F875C for ; Wed, 27 Feb 2013 11:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 oU7hoYpcj7jt for ; Wed, 27 Feb 2013 11:38:32 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id E7E7A21F896B for ; Wed, 27 Feb 2013 11:38:28 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so1972739oag.40 for ; Wed, 27 Feb 2013 11:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RHri8AaLDPlK3yg8x0NLX2hMzy9UsP89DcKMB8xtJGg=; b=lCGWf+HCLTpOYVEHfmvfggO+yghJslFFJyx5DyAX6QSDUrtXYzUEZG5qwf2XjSsKtM wuxRry4jATQaIEe4S+7UdllBrYTiMr+tIVUG7CPt/lCJNmTJHC3sk0nR+FTJxBa5tSzE rz+1CA4Y3cZKliJOVRJxFrHMfeG24DHxiQZt6X5hgalekGMcNwnWfanCqP8UtfpTFnIS TSk1SAzddkoeo7ebMy6hi8ELRpNUfd4XNAO3scUBSX8sEjIoFYob2MwbN6Uqk5THtHx+ ts14GgSK0nuz1TddbV21kWx4qEtrKldzSrh8aYx6IvBSwcNG4yNu4SRjqEt+9WhXL+/7 0tJA== MIME-Version: 1.0 X-Received: by 10.60.24.162 with SMTP id v2mr3428115oef.96.1361993908454; Wed, 27 Feb 2013 11:38:28 -0800 (PST) Received: by 10.76.167.106 with HTTP; Wed, 27 Feb 2013 11:38:28 -0800 (PST) In-Reply-To: <512E3248.1020003@joelhalpern.com> References: <512D576B.6030009@joelhalpern.com> <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> <512E3248.1020003@joelhalpern.com> Date: Wed, 27 Feb 2013 20:38:28 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:38:34 -0000 On Wed, Feb 27, 2013 at 5:20 PM, Joel M. Halpern wrote: > Actually Luigi, in my personal opinion: > 1) It is not our job or our requirement to involve the RIRs. It is our job > to come up with what we think LISP and the Internet need for EID allocation. > 2) I would be really surprised if EID allocation policies were at all > related to current RIR address allocation policies. The behaviors are VERY > different, as are the assignment implications. Are you thinking something more along these lines http://www.ietf.org/mail-archive/web/lisp/current/msg04155.html ? In there I mention the RIR simple because they have the _infrastructure_ to support the operational side of any delegation, whois+dns+++... If we can get it to work any other way, maybe something along domain names, that is also another option. --- Roger J --- > Yours, > Joel > > > On 2/27/2013 6:59 AM, Luigi Iannone wrote: >> >> Hi, >> >> >> On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote: >> >>> As a participant, I have an even stronger pinion on the RIR references >>> than terry. >>> >>> I think that the block management needs to define >>> o who the root is >>> o what policy we require for allocating blocks to allocators (the root is >>> not an allocator >>> o What the behavioral requirements are for an allocator >>> o are there any special requirements for re-delegating to another >>> allocator? >>> o What policies allocators should respect for end site allocation >>> >>> Once we have this defined, then organizations that wish to participate >>> can do so. If the RIRs want to come play, they may. If not, then they >>> don't. >>> >> >> Got it, is what I've also understood from Terry's point. >> >> Again, there was no intention to put work on RIRs back, rather to show >> that we can come up with a framework that involves RIRs and is compatible >> with current RIRs' policies. (apparently the message was not clear ;-) ). >> >> It comes to my mind the question of what we are going to do with the EID >> block if in 10 years the IETF decides that LISP is the best thing ever and >> we need to assign the EID block permanently? >> >> Ideas are welcome :-) >> >> ciao >> >> L. >> >> >>> (Repeated for clarity, the above is a personal opinion, not a WG chair >>> position, nor associated with any other hats I may have.) >>> >>> Yours, >>> Joel >>> >>> On 2/26/2013 7:26 PM, Terry Manderson wrote: >>>> >>>> Speaking just as a WG participant. >>>> >>>> I would rather a document like this focus purely on the allocation >>>> criteria that needs to be applied to: >>>> 1) An experimental EID block >>>> 2) ongoing LISP allocations beyond the life of the experiment >>>> >>>> Given the expected (numbering) requirements of a LISP site. >>>> >>>> Simply, while it is temping to use the RIRs, and name them, it is not >>>> appropriate in my opinion to assign work to the RIRs. That is the job of >>>> their membership. >>>> >>>> Similarly, what policies the RIRs have now are all subject to change >>>> within their own policy development processes. Please don't re-codify >>>> them >>>> here. I would also prefer to see this document take the approach of >>>> defining what is best for LISP, not how can we use the RIRs as an >>>> allocation framework. The concern I have is that if LISP ends up >>>> requiring >>>> something very different to how the RIRs do it - we would be doing a >>>> disservice to both LISP and the RIRs by pushing it that way. >>>> >>>> The definition of terms is well stated elsewhere, perhaps you can point >>>> to >>>> those locations? >>>> >>>> Cheers >>>> Terry >>>> >>>> On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >>>> >>>>> >>>>> >>>>> >>>>> FYI a new version is available. >>>>> >>>>> >>>>> Comments still welcome ;-) >>>>> >>>>> >>>>> L. >>>>> >>>>> Begin forwarded message: >>>>> >>>>> >>>>> From: >>>>> internet-drafts@ietf.org >>>>> >>>>> Subject: >>>>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>>>> >>>>> Date: >>>>> 25 February 2013 21:47:29 GMT+01:00 >>>>> >>>>> To: >>>>> i-d-announce@ietf.org >>>>> >>>>> Reply-To: >>>>> internet-drafts@ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : LISP EID Block Management Guidelines >>>>> Author(s) : Luigi Iannone >>>>> Roger Jorgensen >>>>> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >>>>> Pages : 9 >>>>> Date : 2013-02-25 >>>>> >>>>> Abstract: >>>>> This document proposes an allocation framework for the management of >>>>> the LISP EID address prefix (requested in a separate document). Such >>>>> framework relies on hierarchical distribution of the address space to >>>>> RIRs (Regional Internet Registries), who will allocate on a temporary >>>>> basis sub-prefixes to requesting organizations. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >> >> > -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From jmh@joelhalpern.com Wed Feb 27 11:44:59 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D028A21F8B83 for ; Wed, 27 Feb 2013 11:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 XbyBO8-inUz4 for ; Wed, 27 Feb 2013 11:44:59 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 116A421F8923 for ; Wed, 27 Feb 2013 11:44:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0674F1CCC8A; Wed, 27 Feb 2013 11:44:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-134.clppva.east.verizon.net [70.106.134.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B5CCC1CCC88; Wed, 27 Feb 2013 11:44:57 -0800 (PST) Message-ID: <512E6226.707@joelhalpern.com> Date: Wed, 27 Feb 2013 14:44:38 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= References: <512D576B.6030009@joelhalpern.com> <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> <512E3248.1020003@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:44:59 -0000 That similar. My point is specifically to stay out fo "who" except for the root. Yours, Joel On 2/27/2013 2:38 PM, Roger Jørgensen wrote: > On Wed, Feb 27, 2013 at 5:20 PM, Joel M. Halpern wrote: >> Actually Luigi, in my personal opinion: >> 1) It is not our job or our requirement to involve the RIRs. It is our job >> to come up with what we think LISP and the Internet need for EID allocation. >> 2) I would be really surprised if EID allocation policies were at all >> related to current RIR address allocation policies. The behaviors are VERY >> different, as are the assignment implications. > > Are you thinking something more along these lines > http://www.ietf.org/mail-archive/web/lisp/current/msg04155.html ? > > > In there I mention the RIR simple because they have the > _infrastructure_ to support the operational side of any delegation, > whois+dns+++... > If we can get it to work any other way, maybe something along domain > names, that is also another option. > > > > --- Roger J --- > >> Yours, >> Joel >> >> >> On 2/27/2013 6:59 AM, Luigi Iannone wrote: >>> >>> Hi, >>> >>> >>> On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote: >>> >>>> As a participant, I have an even stronger pinion on the RIR references >>>> than terry. >>>> >>>> I think that the block management needs to define >>>> o who the root is >>>> o what policy we require for allocating blocks to allocators (the root is >>>> not an allocator >>>> o What the behavioral requirements are for an allocator >>>> o are there any special requirements for re-delegating to another >>>> allocator? >>>> o What policies allocators should respect for end site allocation >>>> >>>> Once we have this defined, then organizations that wish to participate >>>> can do so. If the RIRs want to come play, they may. If not, then they >>>> don't. >>>> >>> >>> Got it, is what I've also understood from Terry's point. >>> >>> Again, there was no intention to put work on RIRs back, rather to show >>> that we can come up with a framework that involves RIRs and is compatible >>> with current RIRs' policies. (apparently the message was not clear ;-) ). >>> >>> It comes to my mind the question of what we are going to do with the EID >>> block if in 10 years the IETF decides that LISP is the best thing ever and >>> we need to assign the EID block permanently? >>> >>> Ideas are welcome :-) >>> >>> ciao >>> >>> L. >>> >>> >>>> (Repeated for clarity, the above is a personal opinion, not a WG chair >>>> position, nor associated with any other hats I may have.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/26/2013 7:26 PM, Terry Manderson wrote: >>>>> >>>>> Speaking just as a WG participant. >>>>> >>>>> I would rather a document like this focus purely on the allocation >>>>> criteria that needs to be applied to: >>>>> 1) An experimental EID block >>>>> 2) ongoing LISP allocations beyond the life of the experiment >>>>> >>>>> Given the expected (numbering) requirements of a LISP site. >>>>> >>>>> Simply, while it is temping to use the RIRs, and name them, it is not >>>>> appropriate in my opinion to assign work to the RIRs. That is the job of >>>>> their membership. >>>>> >>>>> Similarly, what policies the RIRs have now are all subject to change >>>>> within their own policy development processes. Please don't re-codify >>>>> them >>>>> here. I would also prefer to see this document take the approach of >>>>> defining what is best for LISP, not how can we use the RIRs as an >>>>> allocation framework. The concern I have is that if LISP ends up >>>>> requiring >>>>> something very different to how the RIRs do it - we would be doing a >>>>> disservice to both LISP and the RIRs by pushing it that way. >>>>> >>>>> The definition of terms is well stated elsewhere, perhaps you can point >>>>> to >>>>> those locations? >>>>> >>>>> Cheers >>>>> Terry >>>>> >>>>> On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> FYI a new version is available. >>>>>> >>>>>> >>>>>> Comments still welcome ;-) >>>>>> >>>>>> >>>>>> L. >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> >>>>>> From: >>>>>> internet-drafts@ietf.org >>>>>> >>>>>> Subject: >>>>>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>>>>> >>>>>> Date: >>>>>> 25 February 2013 21:47:29 GMT+01:00 >>>>>> >>>>>> To: >>>>>> i-d-announce@ietf.org >>>>>> >>>>>> Reply-To: >>>>>> internet-drafts@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> >>>>>> >>>>>> Title : LISP EID Block Management Guidelines >>>>>> Author(s) : Luigi Iannone >>>>>> Roger Jorgensen >>>>>> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >>>>>> Pages : 9 >>>>>> Date : 2013-02-25 >>>>>> >>>>>> Abstract: >>>>>> This document proposes an allocation framework for the management of >>>>>> the LISP EID address prefix (requested in a separate document). Such >>>>>> framework relies on hierarchical distribution of the address space to >>>>>> RIRs (Regional Internet Registries), who will allocate on a temporary >>>>>> basis sub-prefixes to requesting organizations. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> >> > > > From rogerj@gmail.com Wed Feb 27 11:52:28 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5735221F8A1C for ; Wed, 27 Feb 2013 11:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 V3TkUn2+qHCR for ; Wed, 27 Feb 2013 11:52:27 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 90C8021F8AA6 for ; Wed, 27 Feb 2013 11:52:27 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n12so2024257oag.27 for ; Wed, 27 Feb 2013 11:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=776Ul6X+4zJrpXTk5cy84FsdlN3GBfvHmP0Bm/ISjmg=; b=SaLy0FosldEB4YINy8i0Hvv3YT55GGGdvdyljidN+2WSb+y2cve3XsUtK0muTgwFXZ X6ijP80XkeuQAyH+qIXQ3scD2Tv4CQwrE1QG7VwLzmgw/S8ZZ9bNq0j2nC9KBNqOEGNJ XcPArmc+B9qAQO/2HHP4WgznEjvbqVV/jjnGT3pa1XlGa0BvUZuKzNZ6AcuFqL5m0UOe WxK8kChG/8Hi1aFpqFmpTfzEONDd4o98y+rniQhFJ9ZxkcRLUoy820cbqfJh0UDnBGzs lIbgsdODtOao7AWbNtqqQedhDWA8H09cLf8+veZ5KTE61xwFM0X5yGLJgbun4vmy2605 7U3Q== MIME-Version: 1.0 X-Received: by 10.182.39.69 with SMTP id n5mr3513491obk.72.1361994746961; Wed, 27 Feb 2013 11:52:26 -0800 (PST) Received: by 10.76.167.106 with HTTP; Wed, 27 Feb 2013 11:52:26 -0800 (PST) In-Reply-To: <512E6226.707@joelhalpern.com> References: <512D576B.6030009@joelhalpern.com> <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> <512E3248.1020003@joelhalpern.com> <512E6226.707@joelhalpern.com> Date: Wed, 27 Feb 2013 20:52:26 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "Joel M. Halpern" , "lisp@ietf.org list list" Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:52:28 -0000 On Wed, Feb 27, 2013 at 8:44 PM, Joel M. Halpern wrote: > That similar. My point is specifically to stay out fo "who" except for the > root. excellent, think we can agree on that really, and that's one direction to think. I would really like to hear if any other have other possible direction we can consider, either with or without existing RIR system. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From Fred.L.Templin@boeing.com Wed Feb 27 13:57:02 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBD221F87B9 for ; Wed, 27 Feb 2013 13:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yICdyU1WoJq for ; Wed, 27 Feb 2013 13:57:01 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 240AF21F8751 for ; Wed, 27 Feb 2013 13:57:01 -0800 (PST) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r1RLv0PM009235 for ; Wed, 27 Feb 2013 13:57:00 -0800 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r1RLuxdq009210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 27 Feb 2013 13:56:59 -0800 Received: from XCH-BLV-106.nw.nos.boeing.com (130.247.25.122) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 27 Feb 2013 13:56:59 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.245]) by XCH-BLV-106.nw.nos.boeing.com ([fe80::1481:d5b8:bff:313f%15]) with mapi id 14.02.0328.011; Wed, 27 Feb 2013 13:56:57 -0800 From: "Templin, Fred L" To: Lori Jakab Thread-Topic: [lisp] comments on 'draft-ietf-lisp-deployment-06' Thread-Index: AQHOFQfLuwShS716HkOC8irOe1RlS5iOMw8A Date: Wed, 27 Feb 2013 21:56:56 +0000 Message-ID: <2134F8430051B64F815C691A62D98318013D19@XCH-BLV-504.nw.nos.boeing.com> References: <20130225180218.31450.57812.idtracker@ietfa.amsl.com> <512BC5C4.6090406@joelhalpern.com> <2134F8430051B64F815C691A62D9831801146A@XCH-BLV-504.nw.nos.boeing.com> <512E3492.9010405@ac.upc.edu> In-Reply-To: <512E3492.9010405@ac.upc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "lisp@ietf.org" Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06' 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, 27 Feb 2013 21:57:02 -0000 Hi Lori, > -----Original Message----- > From: Lori Jakab [mailto:ljakab@ac.upc.edu] > Sent: Wednesday, February 27, 2013 8:30 AM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06' >=20 > Hi Fred, >=20 > Thank you very much for the feedback. See responses in-line below: >=20 > On 02/26/13 00:55, Templin, Fred L wrote: > > Hi, > > > > I am reading this document for the first time and had a few > > comments to share below. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > 1) Section 2.5 ("Tunnel Routers Behind NAT"), this seems to > > show a limitation in that there can be only one xTR behind > > a NAT. I would like to address the case when there may be > > many xTRs behind the NAT - can LISP do that? >=20 > There is specification being worked on that will enable many xTRs behind > NAT. It will, however require a Re-encapsulating Tunnel Router (RTR) to > proxy all data packets for it to work. See > https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal Thanks - I too noticed this draft after having sent the message. > > 2) Section 2.6, I don't understand why it says "MTU/PMTUD > > issues minimized" for the recursive scenario? >=20 > It's a typo, thanks for catching this! OK. > > 3) Section 6.1, number 4, should say "request increase in MTU > > to 1556 *or greater* on service provider connections". >=20 > Indeed, will fix. OK. I leave the exact language up to you, but I think we agree on the point. > > However, controlling just the first-hop interface MTU > > does not assure MTU mitigations across the entire path. > > Similarly, "care must be taken that ICMP is not being > > filtered" cannot be assured along the entire path. And, > > studies have shown that ICMP filtering does impact MTU > > handling in current operational practices: > > > > http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc- > thesis.pdf >=20 > True, we are citing RFC 4459 at the end of section 2.1 with regard to > this issue. Would it help if we referenced it in this section as well? The "Verify MTU Handling" recommendations only apply to the first-hop service provider connection. There is no way to control any further hops beyond that. Maybe just add a trailing sentence such as: "However, even with these mitigations path MTU issues are still possible [RFC4459]." > > Additionally, I have a use case that I'm not sure is well addressed by > > the document. I would like to address the use case of mobile networks > > configured as stub sites that connect to ISPs via a mobile router. Each > > mobile router may have multiple ISP connections, and can change its ISP > > addresses dynamically as it moves around. Some of the ISP addresses may > > be global and others may be private, such as behind a carrier-grade NAT= . > > Many such mobile routers may be located behind the same NAT. > > > > I want to give each mobile router an EID prefix that it can use to > number > > interfaces within the mobile network. The mobile network may contain > just > > one interface, a few interfaces, or it may contain many interfaces. > > > > I now want that the mobile network can remain reachable from the outsid= e > > world by the same EID prefix addresses even as the mobile router travel= s > > around dynamically. The mobile router will need an xTR so that its ISPs > > will not filter its packets that use EID source addresses. I also want > > the mobile router to be able to traffic engineer in both the outgoing > > *and* incoming directions. For this, there needs to be some sort of > > server sitting outside of any NATs that the mobile router can "register= " > > itself with. The mobile router should be able to change between > different > > servers as it moves around, e.g., to reduce path stretch or in the > > event of a server failure. The servers in turn associate with proxy > > xTRs so that outgoing packets destined to EIDs located in distant > > networks can be routed appropriately. > > > > This is the way IRON sets things up. Can it also be done with LISP? >=20 > Yes, using the NAT traversal specification I mentioned above. OK. > The mobile router should be an xTR itself, OK. That matches with the "IRON Client" [RFC6179]. > and will receive a list of RTRs > (what you call servers above) it can use for traversing the NAT Right. that matches with the "IRON Server". > (for the connections where a NAT is detected). It is also OK to just use the same function even for RLOCs that are not behind a NAT. > Path stretch optimizations are certainly possible, Right - that matches with AERO [RFC6706]. > they depend on the implementation of the Map-Server. OK. > Incoming traffic engineering is possible with LISP, How does the LISP mobile node tell the network how it wants its inbound traffic to be delivered? IRON Clients provide their Servers with a set of "handles" that represent their ISP connections. The Client then informs the server as to how it would like its inbound traffic to be delivered across those handles - for example, some flows could be delivered via the Client's WiFi interface and others delivered via the Client's 4G interface, etc. Here, a handle is used instead of an ISP address because the ISP address can change even while the handle remains the same.=20 > however, outgoing traffic engineering is not LISP specific, it should be > done with existing mechanisms. Right - the same for IRON. > Would you like this scenario added to the document? You might want to take a look at "RANGER Scenarios" [RFC6139] for this and other scenarios which might also be applicable to LISP. >From what you are saying, it sounds like addressing this scenario is somewhat of a work-in-progress for LISP, where IRON already has it pretty much worked out. It might be worth a comparative study between the two approaches to see which pieces look the most promising - and, the study could possibly indicate that a combination of some features from both approaches would make the most sense. The IRON-related documents are here: http://www.rfc-editor.org/rfc/rfc5320.txt http://www.rfc-editor.org/rfc/rfc5558.txt http://www.rfc-editor.org/rfc/rfc5720.txt http://www.rfc-editor.org/rfc/rfc6139.txt http://www.rfc-editor.org/rfc/rfc6179.txt http://www.rfc-editor.org/rfc/rfc6706.txt https://datatracker.ietf.org/doc/draft-templin-intarea-seal/ https://datatracker.ietf.org/doc/draft-templin-intarea-vet/ https://datatracker.ietf.org/doc/draft-templin-ironbis/ Thanks - Fred fred.l.templin@boeing.com > Best regards, > -Lori From brian.e.carpenter@gmail.com Wed Feb 27 16:43:38 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852BA21F96B1 for ; Wed, 27 Feb 2013 16:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJnvETllfZVA for ; Wed, 27 Feb 2013 16:43:36 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id 1F9D821F8D09 for ; Wed, 27 Feb 2013 15:59:27 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Wed, 27 Feb 2013 18:37:22 -0500 Received: from co9outboundpool.messaging.microsoft.com ([207.46.163.24]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Feb 2013 09:07:39 -0500 Received: from mail131-co9-R.bigfish.com (10.236.132.230) by CO9EHSOBE019.bigfish.com (10.236.130.82) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Feb 2013 14:07:35 +0000 Received: from mail131-co9 (localhost [127.0.0.1]) by mail131-co9-R.bigfish.com (Postfix) with ESMTP id 6974E3C01CB; Tue, 26 Feb 2013 14:07:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.229; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0611HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zzc85fhzz1f42h1ee6h1202h1e76h1d1ah1cabh1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail131-co9: domain of CINTAS1.onmicrosoft.com designates 157.56.240.229 as permitted sender) client-ip=157.56.240.229; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=BL2PRD0611HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail131-co9 (localhost.localdomain [127.0.0.1]) by mail131-co9 (MessageSwitch) id 1361887653752768_6560; Tue, 26 Feb 2013 14:07:33 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.251]) by mail131-co9.bigfish.com (Postfix) with ESMTP id B49CF34005E; Tue, 26 Feb 2013 14:07:33 +0000 (UTC) Received: from BL2PRD0611HT005.namprd06.prod.outlook.com (157.56.240.229) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Feb 2013 14:07:31 +0000 Content-Type: multipart/mixed; boundary="_6d210013-7b28-433a-b05a-98a2cb9f421b_" To: From: Brian E Carpenter MIME-Version: 1.0 Sender: Message-ID: Date: Tue, 26 Feb 2013 14:07:11 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 26 Feb 2013 14:07:43.0950 (UTC) FILETIME=[A594D6E0:01CE142A] Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-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: Thu, 28 Feb 2013 00:43:39 -0000 --_6d210013-7b28-433a-b05a-98a2cb9f421b_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: brian.e.carpenter@gmail.com Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-04.txt Message-Id: <512CC187.1020107@gmail.com> Recipient: buxtonb@cintas.com --_6d210013-7b28-433a-b05a-98a2cb9f421b_ Content-Type: message/rfc822 Received: from mail102-db3-R.bigfish.com (213.199.154.137) by BL2PRD0611HT005.namprd06.prod.outlook.com (10.255.105.168) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 26 Feb 2013 14:07:11 +0000 Received: from mail102-db3 (localhost [127.0.0.1]) by mail102-db3-R.bigfish.com (Postfix) with ESMTP id ED10B20104 for ; Tue, 26 Feb 2013 14:07:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -14 X-BigFish: ps-14(zzzz1f42h1ee6h1202h1e76h1d1ah1cabh1d2ahzz1033IL8275dhz2fhfI11Ieh5fh668h839h944hd25he5bh1220h1288h12a5h12a9h137ah13b6h13eah1441h1504h1537h153bh15a8h162dh1631h174dh1758h1765h17eeh1946h19c3h1664i850o1155h) Received-SPF: pass (mail102-db3: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail102-db3 (localhost.localdomain [127.0.0.1]) by mail102-db3 (MessageSwitch) id 1361887628208224_31864; Tue, 26 Feb 2013 14:07:08 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.235]) by mail102-db3.bigfish.com (Postfix) with ESMTP id 262CA420089 for ; Tue, 26 Feb 2013 14:07:08 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Feb 2013 14:07:07 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA4121F8995; Tue, 26 Feb 2013 06:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361887626; bh=7Zg18u01eAnlV6DxeijhUbKOG6Eugu1Mzpz1aNG3hO4=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=SAE0p74m0WjH7B37ek+vy275jUgLDYBwRRRRIoweit0UYz9SBVkLcp4gVm8Am6MET eMKvKjxKEQWpmX1g9Asjs8f6mOStSdE8eW8V2FWKZr3RX94r+oX0wePx70Rwcwbve3 bTCIg+/sTmLcSOs3S8ZYa14Iozk05hFXfVVX9g2U= 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 66BDF21F898B for ; Tue, 26 Feb 2013 06:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.876 X-Spam-Level: X-Spam-Status: No, score=-101.876 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, 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 RhZY+3D8bsGW for ; Tue, 26 Feb 2013 06:07:04 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id ACDC721F8991 for ; Tue, 26 Feb 2013 06:06:59 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so3601864wey.14 for ; Tue, 26 Feb 2013 06:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V2nThlMMMwnwPkTjR9kY56wO7oqoPEhFd66LRktEQL8=; b=JaS8zCgKNj+emcFKsdbwUjD+X6Hh8/ZpMWjzy6zk5hSSZdgySc297Tu0dZuzRtUZ0Q krfYeA5I6wP2by7n+alUVrpgs+QXFlJSY/HqYljqfQlZty+VfPbPhD4kC1sJOasjHYnu Ix6zltBVMNIDmVj3tT0wwTsFInrtM3c9TfVSIxuWA6LINsc4kIQOCS30qHl9Ex4P7Jtj 8lv3IABgMsN0NYqjR9xpXSk39pYo6NfRJR3JUekVL3X8pJcplvqZlhWzugfz7iPGDlaj pdexj9k5Ja9LnNc6UNLmsy3BaB/VKH069zD/nNnMruLFDlUUfdVBTciaTPVOlx4GiczW uZqg== X-Received: by 10.194.171.74 with SMTP id as10mr6107532wjc.0.1361887618933; Tue, 26 Feb 2013 06:06:58 -0800 (PST) Received: from [128.232.110.102] (c102.al.cl.cam.ac.uk. [128.232.110.102]) by mx.google.com with ESMTPS id ex15sm21308146wid.5.2013.02.26.06.06.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 06:06:57 -0800 (PST) Message-ID: <512CC187.1020107@gmail.com> Date: Tue, 26 Feb 2013 14:07:03 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: References: <20130225210147.16242.80454.idtracker@ietfa.amsl.com> In-Reply-To: <20130225210147.16242.80454.idtracker@ietfa.amsl.com> Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 26 Feb 2013 14:07:08.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: BL2PRD0611HT005.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 10.3.81.235 X-MS-Exchange-Organization-OriginalServerIPAddress: 127.0.0.1 X-MS-Exchange-Organization-AuthSource: BL2PRD0611HT005.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: BL2PRD0611HT005.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 5710 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=mail102-db3:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail102-db3:TOTAL=1 X-MS-Exchange-Organization-MessageLatency: SRV=mail102-db3-R.bigfish.com:TOTAL=2 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: BL2PRD0611HT005.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: BL2PRD0611HT005 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent I find this more convincing than the previous version. The "Routing Considerations" section still doesn't make it clear why non-LISP operators will be happy to propagate routes under the EID Block prefix. You can say "Why wouldn't they?", but then you need to explain why some people have been reluctant to propagate 2002::/16, perhaps because of fear that it might become a traffic magnet. Regards Brian _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_6d210013-7b28-433a-b05a-98a2cb9f421b_-- From rogerj@gmail.com Wed Feb 27 21:35:59 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D8721F8AFE for ; Wed, 27 Feb 2013 21:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=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 RgdxVKhi2qzK for ; Wed, 27 Feb 2013 21:35:56 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id AEE9821F84D5 for ; Wed, 27 Feb 2013 21:35:42 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Thu, 28 Feb 2013 00:35:41 -0500 Received: from va3outboundpool.messaging.microsoft.com ([216.32.180.31]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 15:50:03 -0500 Received: from mail169-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 19:52:48 +0000 Received: from mail169-va3 (localhost [127.0.0.1]) by mail169-va3-R.bigfish.com (Postfix) with ESMTP id 3D1F24405DE; Wed, 27 Feb 2013 19:52:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT002.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371Ic85fhc85dhzz1f42h1ee6h1202h1e76h1d1ah1cabh1d2ahzz8275ch1033IL17326ah8275dh1954cbh8275bhz2fh2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail169-va3: domain of CINTAS1.onmicrosoft.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=BL2PRD0610HT002.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail169-va3 (localhost.localdomain [127.0.0.1]) by mail169-va3 (MessageSwitch) id 1361994765416452_32337; Wed, 27 Feb 2013 19:52:45 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.229]) by mail169-va3.bigfish.com (Postfix) with ESMTP id 53ECD36007A; Wed, 27 Feb 2013 19:52:45 +0000 (UTC) Received: from BL2PRD0610HT002.namprd06.prod.outlook.com (157.56.240.117) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 19:52:44 +0000 Content-Type: multipart/mixed; boundary="_3291dc1f-b7d5-4bae-b546-1f9d9b808334_" To: "Joel M. Halpern" , "lisp@ietf.org list list" From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= MIME-Version: 1.0 Sender: Message-ID: <02a5a42d-316c-4af1-a096-5b49d12138fe@journal.report.generator> Date: Wed, 27 Feb 2013 19:52:43 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 27 Feb 2013 20:50:03.0657 (UTC) FILETIME=[04618F90:01CE152C] Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:36:00 -0000 --_3291dc1f-b7d5-4bae-b546-1f9d9b808334_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: rogerj@gmail.com Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Message-Id: Recipient: buxtonb@cintas.com --_3291dc1f-b7d5-4bae-b546-1f9d9b808334_ Content-Type: message/rfc822 Received: from mail90-co9-R.bigfish.com (207.46.163.20) by BL2PRD0610HT002.namprd06.prod.outlook.com (10.255.101.37) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 27 Feb 2013 19:52:43 +0000 Received: from mail90-co9 (localhost [127.0.0.1]) by mail90-co9-R.bigfish.com (Postfix) with ESMTP id 6DEEA9E02A1 for ; Wed, 27 Feb 2013 19:52:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -23 X-BigFish: ps-23(zz98dI9371Izz1f42h1ee6h1202h1e76h1d1ah1cabh1d2ahzz1033IL17326ah8275dh1954cbh8275bhz2fhfI11Ieh5fh668h839h944h107ah1220h1288h12a5h12a9h137ah13b6h13eah1441h1504h1537h153bh15a8h162dh1631h1741h1758h17eeh1946h19b5h1664i1155h) Received-SPF: pass (mail90-co9: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail90-co9 (localhost.localdomain [127.0.0.1]) by mail90-co9 (MessageSwitch) id 1361994760152744_29172; Wed, 27 Feb 2013 19:52:40 +0000 (UTC) Received: from CO9EHSMHS008.bigfish.com (unknown [10.236.132.239]) by mail90-co9.bigfish.com (Postfix) with ESMTP id 139C96C005B for ; Wed, 27 Feb 2013 19:52:40 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by CO9EHSMHS008.bigfish.com (10.236.130.18) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 19:52:39 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2A021F8B04; Wed, 27 Feb 2013 11:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361994751; bh=H9N9MaXOV3upUasRaPGLkYdqcKaekJ8o6Hf6R6KPRbc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ofraQnvwaWdqWZbvdcBAXffI8i6yuFWfexqDmi2faLfKBUnPKsYqrFZUvmJhqX6fO 5htO06CqOxoFHG1HSz9BQyvJoUSw2RIaSWK3/O+jTde60UGkX3VU9LDQKGg3c7wPnR gVSbQzdZ3NzyVpjhY8/3ipYxDAaicoLcTWoM84Dg= 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 5735221F8A1C for ; Wed, 27 Feb 2013 11:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 V3TkUn2+qHCR for ; Wed, 27 Feb 2013 11:52:27 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 90C8021F8AA6 for ; Wed, 27 Feb 2013 11:52:27 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n12so2024257oag.27 for ; Wed, 27 Feb 2013 11:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=776Ul6X+4zJrpXTk5cy84FsdlN3GBfvHmP0Bm/ISjmg=; b=SaLy0FosldEB4YINy8i0Hvv3YT55GGGdvdyljidN+2WSb+y2cve3XsUtK0muTgwFXZ X6ijP80XkeuQAyH+qIXQ3scD2Tv4CQwrE1QG7VwLzmgw/S8ZZ9bNq0j2nC9KBNqOEGNJ XcPArmc+B9qAQO/2HHP4WgznEjvbqVV/jjnGT3pa1XlGa0BvUZuKzNZ6AcuFqL5m0UOe WxK8kChG/8Hi1aFpqFmpTfzEONDd4o98y+rniQhFJ9ZxkcRLUoy820cbqfJh0UDnBGzs lIbgsdODtOao7AWbNtqqQedhDWA8H09cLf8+veZ5KTE61xwFM0X5yGLJgbun4vmy2605 7U3Q== MIME-Version: 1.0 X-Received: by 10.182.39.69 with SMTP id n5mr3513491obk.72.1361994746961; Wed, 27 Feb 2013 11:52:26 -0800 (PST) Received: by 10.76.167.106 with HTTP; Wed, 27 Feb 2013 11:52:26 -0800 (PST) In-Reply-To: <512E6226.707@joelhalpern.com> References: <512D576B.6030009@joelhalpern.com> <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> <512E3248.1020003@joelhalpern.com> <512E6226.707@joelhalpern.com> Date: Wed, 27 Feb 2013 20:52:26 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "Joel M. Halpern" , "lisp@ietf.org list list" CC: =?ISO-8859-1?Q?Roger_J=F8rgensen?= Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 27 Feb 2013 19:52:40.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: BL2PRD0610HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 10.236.132.239 X-MS-Exchange-Organization-OriginalServerIPAddress: 127.0.0.1 X-MS-Exchange-Organization-AuthSource: BL2PRD0610HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: BL2PRD0610HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 5883 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=mail90-co9:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail90-co9:TOTAL=2 X-MS-Exchange-Organization-MessageLatency: SRV=mail90-co9-R.bigfish.com:TOTAL=1 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: BL2PRD0610HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: BL2PRD0610HT002 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent On Wed, Feb 27, 2013 at 8:44 PM, Joel M. Halpern wrote: > That similar. My point is specifically to stay out fo "who" except for the > root. excellent, think we can agree on that really, and that's one direction to think. I would really like to hear if any other have other possible direction we can consider, either with or without existing RIR system. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_3291dc1f-b7d5-4bae-b546-1f9d9b808334_-- From jmh@joelhalpern.com Thu Feb 28 01:53:34 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89C521F8AE7 for ; Thu, 28 Feb 2013 01:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 iVww3bDiTdOy for ; Thu, 28 Feb 2013 01:53:31 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id CF4C021F882A for ; Thu, 28 Feb 2013 01:53:28 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Thu, 28 Feb 2013 01:09:20 -0500 Received: from ch1outboundpool.messaging.microsoft.com ([216.32.181.185]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 16:04:22 -0500 Received: from mail214-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 19:45:08 +0000 Received: from mail214-ch1 (localhost [127.0.0.1]) by mail214-ch1-R.bigfish.com (Postfix) with ESMTP id 4EF272E0136; Wed, 27 Feb 2013 19:45:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.149; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0611HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371Ic89bh936eI1b0bIc430Ic85dh1432I1418I9a6kzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahz8dhz8275ch1033IL17326ah8275dh8275bhz2fh2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail214-ch1: domain of CINTAS1.onmicrosoft.com designates 157.56.244.149 as permitted sender) client-ip=157.56.244.149; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=CH1PRD0611HT004.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail214-ch1 (localhost.localdomain [127.0.0.1]) by mail214-ch1 (MessageSwitch) id 1361994306615428_28216; Wed, 27 Feb 2013 19:45:06 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail214-ch1.bigfish.com (Postfix) with ESMTP id 84BFB1C01F5; Wed, 27 Feb 2013 19:45:06 +0000 (UTC) Received: from CH1PRD0611HT004.namprd06.prod.outlook.com (157.56.244.149) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 19:45:06 +0000 Content-Type: multipart/mixed; boundary="_9517e7c7-f108-4619-b3ac-fb4ca5704fa0_" To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= From: "Joel M. Halpern" MIME-Version: 1.0 Sender: Message-ID: Date: Wed, 27 Feb 2013 19:45:05 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 27 Feb 2013 21:04:23.0131 (UTC) FILETIME=[04AAE2B0:01CE152E] Cc: "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 09:53:34 -0000 --_9517e7c7-f108-4619-b3ac-fb4ca5704fa0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: jmh@joelhalpern.com Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Message-Id: <512E6226.707@joelhalpern.com> Recipient: buxtonb@cintas.com --_9517e7c7-f108-4619-b3ac-fb4ca5704fa0_ Content-Type: message/rfc822 Received: from mail252-va3-R.bigfish.com (216.32.180.112) by CH1PRD0611HT004.namprd06.prod.outlook.com (10.255.148.167) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 27 Feb 2013 19:45:05 +0000 Received: from mail252-va3 (localhost [127.0.0.1]) by mail252-va3-R.bigfish.com (Postfix) with ESMTP id 36F0412408C1 for ; Wed, 27 Feb 2013 19:45:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -26 X-BigFish: ps-26(zzbb2dI98dI9371Ic89bh936eI1b0bIc430I1432I1418I9a6kzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahz8dhz8275ch1033IL17326ah8275dh8275bhz2fhfI11Ieh5fh668h839h947hd25he5bh1288h12a5h12a9h137ah13b6h13eah1441h1504h1537h153bh162dh1631h1758h18e1h190ch1946h19b4h19c3h1664i1155h) Received-SPF: pass (mail252-va3: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail252-va3 (localhost.localdomain [127.0.0.1]) by mail252-va3 (MessageSwitch) id 1361994303347614_21347; Wed, 27 Feb 2013 19:45:03 +0000 (UTC) Received: from VA3EHSMHS037.bigfish.com (unknown [10.7.14.231]) by mail252-va3.bigfish.com (Postfix) with ESMTP id 4EDF41DC0049 for ; Wed, 27 Feb 2013 19:45:03 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by VA3EHSMHS037.bigfish.com (10.7.99.47) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 19:45:02 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CE721F8923; Wed, 27 Feb 2013 11:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361994302; bh=YhEFnaC8DZB9W5iAYyZpYpoLJZB2LMTghZqwUtOS//Y=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=V7MhMDYSKBVEqhzpHpxBx4HRawhplIbp6yx1RwqTeO9OTGp6Him72mO6NXypGaILB +fosWkn8llx6dFWj2e2MVnHIgQrzsyP+XEQnBYIoDJSIYpeonP+dJU49MT5GNDy67I khobOQ8xaObFn1GFKvuu+z17sW/29zqASnhu+Md0= 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 D028A21F8B83 for ; Wed, 27 Feb 2013 11:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 XbyBO8-inUz4 for ; Wed, 27 Feb 2013 11:44:59 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 116A421F8923 for ; Wed, 27 Feb 2013 11:44:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0674F1CCC8A; Wed, 27 Feb 2013 11:44:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-134.clppva.east.verizon.net [70.106.134.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B5CCC1CCC88; Wed, 27 Feb 2013 11:44:57 -0800 (PST) Message-ID: <512E6226.707@joelhalpern.com> Date: Wed, 27 Feb 2013 14:44:38 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= References: <512D576B.6030009@joelhalpern.com> <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> <512E3248.1020003@joelhalpern.com> In-Reply-To: CC: "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 27 Feb 2013 19:45:02.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: CH1PRD0611HT004.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 64.170.98.30 X-MS-Exchange-Organization-OriginalServerIPAddress: 10.7.14.231 X-MS-Exchange-Organization-AuthSource: CH1PRD0611HT004.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: CH1PRD0611HT004.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 11595 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=VA3EHSMHS037.bigfish.com:TOTAL=1 X-MS-Exchange-Organization-MessageLatency: SRV=mail252-va3:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail252-va3:TOTAL=2 X-MS-Exchange-Organization-MessageLatency: SRV=mail252-va3-R.bigfish.com:TOTAL=0 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: CH1PRD0611HT004.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: CH1PRD0611HT004 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent That similar. My point is specifically to stay out fo "who" except for = the root. Yours, Joel On 2/27/2013 2:38 PM, Roger J=F8rgensen wrote: > On Wed, Feb 27, 2013 at 5:20 PM, Joel M. Halpern wr= ote: >> Actually Luigi, in my personal opinion: >> 1) It is not our job or our requirement to involve the RIRs. It is our = job >> to come up with what we think LISP and the Internet need for EID allocat= ion. >> 2) I would be really surprised if EID allocation policies were at all >> related to current RIR address allocation policies. The behaviors are V= ERY >> different, as are the assignment implications. > > Are you thinking something more along these lines > http://www.ietf.org/mail-archive/web/lisp/current/msg04155.html ? > > > In there I mention the RIR simple because they have the > _infrastructure_ to support the operational side of any delegation, > whois+dns+++... > If we can get it to work any other way, maybe something along domain > names, that is also another option. > > > > --- Roger J --- > >> Yours, >> Joel >> >> >> On 2/27/2013 6:59 AM, Luigi Iannone wrote: >>> >>> Hi, >>> >>> >>> On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote: >>> >>>> As a participant, I have an even stronger pinion on the RIR references >>>> than terry. >>>> >>>> I think that the block management needs to define >>>> o who the root is >>>> o what policy we require for allocating blocks to allocators (the root= is >>>> not an allocator >>>> o What the behavioral requirements are for an allocator >>>> o are there any special requirements for re-delegating to another >>>> allocator? >>>> o What policies allocators should respect for end site allocation >>>> >>>> Once we have this defined, then organizations that wish to participate >>>> can do so. If the RIRs want to come play, they may. If not, then they >>>> don't. >>>> >>> >>> Got it, is what I've also understood from Terry's point. >>> >>> Again, there was no intention to put work on RIRs back, rather to show >>> that we can come up with a framework that involves RIRs and is compatib= le >>> with current RIRs' policies. (apparently the message was not clear ;-) = ). >>> >>> It comes to my mind the question of what we are going to do with the EID >>> block if in 10 years the IETF decides that LISP is the best thing ever = and >>> we need to assign the EID block permanently? >>> >>> Ideas are welcome :-) >>> >>> ciao >>> >>> L. >>> >>> >>>> (Repeated for clarity, the above is a personal opinion, not a WG chair >>>> position, nor associated with any other hats I may have.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/26/2013 7:26 PM, Terry Manderson wrote: >>>>> >>>>> Speaking just as a WG participant. >>>>> >>>>> I would rather a document like this focus purely on the allocation >>>>> criteria that needs to be applied to: >>>>> 1) An experimental EID block >>>>> 2) ongoing LISP allocations beyond the life of the experiment >>>>> >>>>> Given the expected (numbering) requirements of a LISP site. >>>>> >>>>> Simply, while it is temping to use the RIRs, and name them, it is not >>>>> appropriate in my opinion to assign work to the RIRs. That is the job= of >>>>> their membership. >>>>> >>>>> Similarly, what policies the RIRs have now are all subject to change >>>>> within their own policy development processes. Please don't re-codify >>>>> them >>>>> here. I would also prefer to see this document take the approach of >>>>> defining what is best for LISP, not how can we use the RIRs as an >>>>> allocation framework. The concern I have is that if LISP ends up >>>>> requiring >>>>> something very different to how the RIRs do it - we would be doing a >>>>> disservice to both LISP and the RIRs by pushing it that way. >>>>> >>>>> The definition of terms is well stated elsewhere, perhaps you can poi= nt >>>>> to >>>>> those locations? >>>>> >>>>> Cheers >>>>> Terry >>>>> >>>>> On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> FYI a new version is available. >>>>>> >>>>>> >>>>>> Comments still welcome ;-) >>>>>> >>>>>> >>>>>> L. >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> >>>>>> From: >>>>>> internet-drafts@ietf.org >>>>>> >>>>>> Subject: >>>>>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>>>>> >>>>>> Date: >>>>>> 25 February 2013 21:47:29 GMT+01:00 >>>>>> >>>>>> To: >>>>>> i-d-announce@ietf.org >>>>>> >>>>>> Reply-To: >>>>>> internet-drafts@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> >>>>>> >>>>>> Title : LISP EID Block Management Guidelines >>>>>> Author(s) : Luigi Iannone >>>>>> Roger Jorgensen >>>>>> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >>>>>> Pages : 9 >>>>>> Date : 2013-02-25 >>>>>> >>>>>> Abstract: >>>>>> This document proposes an allocation framework for the management= of >>>>>> the LISP EID address prefix (requested in a separate document). = Such >>>>>> framework relies on hierarchical distribution of the address spac= e to >>>>>> RIRs (Regional Internet Registries), who will allocate on a tempo= rary >>>>>> basis sub-prefixes to requesting organizations. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-iannone-lisp-eid-block-mgmn= t-01 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> >> > > > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_9517e7c7-f108-4619-b3ac-fb4ca5704fa0_-- From jsaldana@unizar.es Thu Feb 28 02:48:28 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513E521F8B98; Thu, 28 Feb 2013 02:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, 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 fXfc2Hu4qhDs; Thu, 28 Feb 2013 02:48:27 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 742EF21F855A; Thu, 28 Feb 2013 02:48:26 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r1SAmJQi021774; Thu, 28 Feb 2013 11:48:19 +0100 From: "Jose Saldana" To: , Date: Thu, 28 Feb 2013 11:48:23 +0100 Organization: Universidad de Zaragoza Message-ID: <007201ce15a1$23a92a50$6afb7ef0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01CE15A9.856E2E90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4Vny90JVbG7h9lQ1272fWL6EWZ2A== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: =?iso-8859-1?Q?Jos=E9_Ruiz_Mas?= , DIEGO LOPEZ GARCIA , Luigi Iannone , =?iso-8859-1?Q?Juli=E1n_Fern=E1ndez_Navajas?= Subject: [lisp] Interesting results of the combination of LISP and TCMTF X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 10:48:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0073_01CE15A9.856E2E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. =20 Some months ago, Luigi Iannone suggested the idea of =93putting = together=94 TCMTF and LISP. TCMTF uses Tunneling, Multiplexing and header = Compression of Traffic Flows (TCMTF) in order to save bandwidth and to reduce the = amount of packets per time unit. (http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/) =20 We have done some simulations, and we have just got accepted a paper to = be presented in IEEE ICC 2013 conference in Budapest in June. A draft = version is here: = http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_in_proc.pdf =20 Taking into account that encapsulation is necessary in LISP, bandwidth = can be drastically reduced in flows using small packets, which are typical = of many real-time services, like online games, VoIP, etc. by means of = header compression and multiplexing of a number of packets. =20 The headers added by LISP are 36 bytes (20 IP + 8 UDP + 8 LISP), and = this would be significant for small packets (e.g., a VoIP packet can be 60 = bytes long). So multiplexing together a number of packets traveling between = the same pair of networks can save a lot of bandwidth. We have obtained = these results: =20 - VoIP: 70% saving - First Person Shooter games: 54% saving - MMORPG games: up to 80% saving - Grouping TCP ACKs: 45% saving =20 We have also studied the ability of the LISP framework to manage the signaling of TCMTF options. =20 We think these results are interesting, so we wanted to share them here. Feel free to read the paper and discuss about it. =20 Thanks a lot, =20 Jose Saldana =20 ------=_NextPart_000_0073_01CE15A9.856E2E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = all.

 

Some months ago, Luigi Iannone = suggested the idea of “putting together” TCMTF and LISP. = TCMTF uses Tunneling, Multiplexing and header Compression of Traffic = Flows (TCMTF) in order to save bandwidth and to reduce the amount of = packets per time unit. (http:= //datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/)

 

We have done some simulations, and we have just got = accepted a paper to be presented in IEEE ICC 2013 conference in Budapest = in June. A draft version is here:

http://diec.unizar.es/~jsaldana/personal/budapest_ICC_2013_i= n_proc.pdf

 

Taking into account that encapsulation is necessary in = LISP, bandwidth can be drastically reduced in flows using small packets, = which are typical of many real-time services, like online games, VoIP, = etc. by means of header compression and multiplexing of a number of = packets.

 

The headers added by LISP=A0 are 36 bytes (20 IP + 8 UDP + = 8 LISP), and this would be significant for small packets (e.g., a VoIP = packet can be 60 bytes long). So multiplexing together a number of = packets traveling between the same pair of networks can save a lot of = bandwidth. We have obtained these results:

 

- VoIP: 70% = saving

- = First Person Shooter games: 54% saving

- MMORPG games: up to 80% = saving

- = Grouping TCP ACKs: 45% saving

 

We have also studied the ability of = the LISP framework to manage the signaling of TCMTF = options.

 

We think these results are interesting, so we wanted to = share them here. Feel free to read the paper and discuss about = it.

 

Thanks a lot,

 

Jose Saldana

 

------=_NextPart_000_0073_01CE15A9.856E2E90-- From terry.manderson@icann.org Thu Feb 28 03:00:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DE321F84B7 for ; Thu, 28 Feb 2013 03:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yk1vgI9XjJX for ; Thu, 28 Feb 2013 03:00:08 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id B6E9C21F84B6 for ; Thu, 28 Feb 2013 03:00:07 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Wed, 27 Feb 2013 22:47:21 -0500 Received: from ch1outboundpool.messaging.microsoft.com ([216.32.181.182]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Feb 2013 20:57:05 -0500 Received: from mail115-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 00:26:45 +0000 Received: from mail115-ch1 (localhost [127.0.0.1]) by mail115-ch1-R.bigfish.com (Postfix) with ESMTP id 622C23600BE; Wed, 27 Feb 2013 00:26:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.37; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0612HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zf7Izbb2dI98dI9371I936eIc85fh1b0bIc430Ic85dh1432I9a6kzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail115-ch1: domain of CINTAS1.onmicrosoft.com designates 157.56.238.37 as permitted sender) client-ip=157.56.238.37; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=BY2PRD0612HT004.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail115-ch1 (localhost.localdomain [127.0.0.1]) by mail115-ch1 (MessageSwitch) id 1361924802986185_28100; Wed, 27 Feb 2013 00:26:42 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail115-ch1.bigfish.com (Postfix) with ESMTP id E47CC3006CE; Wed, 27 Feb 2013 00:26:42 +0000 (UTC) Received: from BY2PRD0612HT004.namprd06.prod.outlook.com (157.56.238.37) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 00:26:42 +0000 Content-Type: multipart/mixed; boundary="_ced841f3-d830-46d3-9934-3d0befe35faa_" To: Luigi Iannone , "lisp@ietf.org list list" From: Terry Manderson MIME-Version: 1.0 Sender: Message-ID: <9fc20374-6469-446e-839e-f43058db0c16@journal.report.generator> Date: Wed, 27 Feb 2013 00:26:33 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 27 Feb 2013 01:57:06.0548 (UTC) FILETIME=[BEDDE340:01CE148D] Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= Subject: Re: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 11:00:09 -0000 --_ced841f3-d830-46d3-9934-3d0befe35faa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: terry.manderson@icann.org Subject: Re: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Message-Id: Recipient: buxtonb@cintas.com --_ced841f3-d830-46d3-9934-3d0befe35faa_ Content-Type: message/rfc822 Received: from mail42-db3-R.bigfish.com (213.199.154.136) by BY2PRD0612HT004.namprd06.prod.outlook.com (10.255.245.37) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 27 Feb 2013 00:26:32 +0000 Received: from mail42-db3 (localhost [127.0.0.1]) by mail42-db3-R.bigfish.com (Postfix) with ESMTP id 1F61AA025B for ; Wed, 27 Feb 2013 00:26:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -26 X-BigFish: ps-26(zf7Izbb2dI98dI9371I936eIc85fh1b0bIc430I1432I9a6kzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275dhz2fhfI11Ieh5fh668h839he5bh1288h12a5h137ah13eah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1664i34h1155h) Received-SPF: pass (mail42-db3: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail42-db3 (localhost.localdomain [127.0.0.1]) by mail42-db3 (MessageSwitch) id 1361924789682385_23041; Wed, 27 Feb 2013 00:26:29 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.234]) by mail42-db3.bigfish.com (Postfix) with ESMTP id A35E714004E for ; Wed, 27 Feb 2013 00:26:29 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 00:26:28 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3EF21F86BB; Tue, 26 Feb 2013 16:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361924787; bh=bZMAJupXcFVGbqtGDp+Z1bmbGLsN5a1KO5Xovo+Kioo=; h=From:To:Date:Message-ID:In-Reply-To:MIME-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=CACgjd98Mxt1SIuHFEtfEnxoe37fy59XvEUVsKBF2sQ9wg2I99RASr7tqpABB8o5B RE1ZwFG4UszdF8epfaCOrIv11phWoh2acrNUIB/tlsUEI/dEaELWYiJiGsmt5qQAAe u0yGNk+we4TnVnsMOEw0+dCv8ccbFGeKcIrbRVbY= 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 9774A21F86B2 for ; Tue, 26 Feb 2013 16:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 W5FB0J6Hashs for ; Tue, 26 Feb 2013 16:26:23 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1921F86A8 for ; Tue, 26 Feb 2013 16:26:22 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 26 Feb 2013 16:26:22 -0800 From: Terry Manderson To: Luigi Iannone , "lisp@ietf.org list list" Date: Tue, 26 Feb 2013 16:26:19 -0800 Thread-Topic: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Thread-Index: Ac4UgRFNPSVCvLSlR0igOwFlSHkTIw== Message-ID: In-Reply-To: <12CDCFB9-3E1F-4333-B195-3443884E9A9E@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 acceptlanguage: en-US MIME-Version: 1.0 CC: =?iso-8859-1?Q?Roger_J=F8rgensen?= Subject: Re: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="_28db2153-7c99-44d8-8ba4-50a9d36ff91f_" Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 27 Feb 2013 00:26:29.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: BY2PRD0612HT004.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 10.3.81.234 X-MS-Exchange-Organization-OriginalServerIPAddress: 127.0.0.1 X-MS-Exchange-Organization-AuthSource: BY2PRD0612HT004.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: BY2PRD0612HT004.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 15144 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=mail42-db3:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail42-db3:TOTAL=2 X-MS-Exchange-Organization-MessageLatency: SRV=mail42-db3-R.bigfish.com:TOTAL=1 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: BY2PRD0612HT004.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: BY2PRD0612HT004 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent --_28db2153-7c99-44d8-8ba4-50a9d36ff91f_ Content-Language: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="_71ad2e27-558c-4ef3-8ac6-ab391580f974_" --_71ad2e27-558c-4ef3-8ac6-ab391580f974_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Speaking just as a WG participant. I would rather a document like this focus purely on the allocation criteria that needs to be applied to: 1) An experimental EID block 2) ongoing LISP allocations beyond the life of the experiment Given the expected (numbering) requirements of a LISP site. Simply, while it is temping to use the RIRs, and name them, it is not appropriate in my opinion to assign work to the RIRs. That is the job of their membership. Similarly, what policies the RIRs have now are all subject to change within their own policy development processes. Please don't re-codify them here. I would also prefer to see this document take the approach of defining what is best for LISP, not how can we use the RIRs as an allocation framework. The concern I have is that if LISP ends up requiring something very different to how the RIRs do it - we would be doing a disservice to both LISP and the RIRs by pushing it that way. The definition of terms is well stated elsewhere, perhaps you can point to those locations? Cheers Terry On 26/02/13 7:59 AM, "Luigi Iannone" wrote: > > > >FYI a new version is available. > > >Comments still welcome ;-) > > >L. > >Begin forwarded message: > > >From: >internet-drafts@ietf.org > >Subject: >I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt > >Date: >25 February 2013 21:47:29 GMT+01:00 > >To: >i-d-announce@ietf.org > >Reply-To: >internet-drafts@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > >Title : LISP EID Block Management Guidelines >Author(s) : Luigi Iannone > Roger Jorgensen >Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >Pages : 9 >Date : 2013-02-25 > >Abstract: > This document proposes an allocation framework for the management of > the LISP EID address prefix (requested in a separate document). Such > framework relies on hierarchical distribution of the address space to > RIRs (Regional Internet Registries), who will allocate on a temporary > basis sub-prefixes to requesting organizations. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 > > >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 > > > > > > --_71ad2e27-558c-4ef3-8ac6-ab391580f974_ Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ 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+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFGD0PGQk2+MLT9AoaKu6Wi6Z7wyMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMDIyNzAwMjYxOVowDQYJKoZIhvcNAQEBBQAEggEABLyDimOs DSHNJSXa3ROihiQ/L5wKalOOKhFWuW4CadccR5G+IBL8FmvqwI9y/WM2s+y2fPa39d0h9lxV vaqEMGFHwWNTeVE18TgPb7R4ykf2ys3Tr1X42CVix3AEUPFhGofDshzCztCLOdyzEeW0nQlR Ukg9/QK8CtJNPW0zfxbqxIeu4k+3EQCeAhdXRtoAjXeqvKFZxbe8s4Yt0QJx7rQcfoqLgELx /T2u1RTjIRBWs4dwfebWad8OQX1ARbVMDNKvcsai4Ol7buOX6etLbxP7D9DL+PSKi53YaCmW Es++JFjc8eINljhhQdL4Pn9Ehl7HW4tjV1V6HHzLrt5pjg== --_71ad2e27-558c-4ef3-8ac6-ab391580f974_-- --_28db2153-7c99-44d8-8ba4-50a9d36ff91f_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_28db2153-7c99-44d8-8ba4-50a9d36ff91f_-- --_ced841f3-d830-46d3-9934-3d0befe35faa_-- From rogerj@gmail.com Thu Feb 28 03:00:13 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AD721F8569 for ; Thu, 28 Feb 2013 03:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=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 Kd2zIBZE950Q for ; Thu, 28 Feb 2013 03:00:12 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id 7A23D21F84C1 for ; Thu, 28 Feb 2013 03:00:11 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Wed, 27 Feb 2013 23:15:57 -0500 Received: from va3outboundpool.messaging.microsoft.com ([216.32.180.16]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 15:57:56 -0500 Received: from mail230-va3-R.bigfish.com (10.7.14.231) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 19:42:30 +0000 Received: from mail230-va3 (localhost [127.0.0.1]) by mail230-va3-R.bigfish.com (Postfix) with ESMTP id 7CEAF700779; Wed, 27 Feb 2013 19:42:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I936eIc85fh1b0bIc430I1432I1418I9a6kzz1f42h1ee6h1202h1e76h1d1ah1cabh1d2ahzz8275ch1033IL17326ah8275dh1954cbh8275bhz2fh2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail230-va3: domain of CINTAS1.onmicrosoft.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=BL2PRD0610HT003.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail230-va3 (localhost.localdomain [127.0.0.1]) by mail230-va3 (MessageSwitch) id 1361994147628985_7212; Wed, 27 Feb 2013 19:42:27 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.225]) by mail230-va3.bigfish.com (Postfix) with ESMTP id 9563D3A022E; Wed, 27 Feb 2013 19:42:27 +0000 (UTC) Received: from BL2PRD0610HT003.namprd06.prod.outlook.com (157.56.240.117) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 19:42:26 +0000 Content-Type: multipart/mixed; boundary="_eefed57b-1c81-4090-aa2a-a4a437c8d5a4_" To: "Joel M. Halpern" From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= MIME-Version: 1.0 Sender: Message-ID: <1e8b8e10-d8ac-416f-914d-9917664dcbfb@journal.report.generator> Date: Wed, 27 Feb 2013 19:42:24 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 27 Feb 2013 20:57:56.0518 (UTC) FILETIME=[1E3A6C60:01CE152D] Cc: "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 11:00:13 -0000 --_eefed57b-1c81-4090-aa2a-a4a437c8d5a4_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: rogerj@gmail.com Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Message-Id: Recipient: buxtonb@cintas.com --_eefed57b-1c81-4090-aa2a-a4a437c8d5a4_ Content-Type: message/rfc822 Received: from mail136-va3-R.bigfish.com (216.32.180.117) by BL2PRD0610HT003.namprd06.prod.outlook.com (10.255.101.38) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 27 Feb 2013 19:42:24 +0000 Received: from mail136-va3 (localhost [127.0.0.1]) by mail136-va3-R.bigfish.com (Postfix) with ESMTP id B3BFE4A0614 for ; Wed, 27 Feb 2013 19:42:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -26 X-BigFish: ps-26(zzbb2dI98dI9371I936eI1b0bIc430I1432I1418I9a6kzz1f42h1ee6h1202h1e76h1d1ah1cabh1d2ahzz8275ch1033IL17326ah8275dh1954cbh8275bhz2fhfI11Ieh5fh668h839h944h107ah1220h1288h12a5h12a9h137ah13b6h13eah1441h1504h1537h153bh15a8h162dh1631h1741h1758h17eeh1946h19b5h1664i1155h) Received-SPF: pass (mail136-va3: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail136-va3 (localhost.localdomain [127.0.0.1]) by mail136-va3 (MessageSwitch) id 1361994141567005_17005; Wed, 27 Feb 2013 19:42:21 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.232]) by mail136-va3.bigfish.com (Postfix) with ESMTP id 755743A00B6 for ; Wed, 27 Feb 2013 19:42:21 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 19:42:16 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF41221F8999; Wed, 27 Feb 2013 11:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361993915; bh=P7UnD/hpGP/74ua1dHKawoYikYijWxvL62R+5wx4jqQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=XygYeCw6wNMoVBpvvtujkvuFMTXbsMYVsx4/gNyv6PEoCJmJ+NJ0EPkamvO/uf+ey Xzv0JXkmzUKd2V6LB+Tjsin9LDM73k/9NF3RAjAqG6glhWprZFXaxi4xWoqPiHpZxV xZUlo3emkWZVXSv7VroBfihi4QLNjrPH+rrc/dZc= 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 48EDF21F875C for ; Wed, 27 Feb 2013 11:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 oU7hoYpcj7jt for ; Wed, 27 Feb 2013 11:38:32 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id E7E7A21F896B for ; Wed, 27 Feb 2013 11:38:28 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so1972739oag.40 for ; Wed, 27 Feb 2013 11:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RHri8AaLDPlK3yg8x0NLX2hMzy9UsP89DcKMB8xtJGg=; b=lCGWf+HCLTpOYVEHfmvfggO+yghJslFFJyx5DyAX6QSDUrtXYzUEZG5qwf2XjSsKtM wuxRry4jATQaIEe4S+7UdllBrYTiMr+tIVUG7CPt/lCJNmTJHC3sk0nR+FTJxBa5tSzE rz+1CA4Y3cZKliJOVRJxFrHMfeG24DHxiQZt6X5hgalekGMcNwnWfanCqP8UtfpTFnIS TSk1SAzddkoeo7ebMy6hi8ELRpNUfd4XNAO3scUBSX8sEjIoFYob2MwbN6Uqk5THtHx+ ts14GgSK0nuz1TddbV21kWx4qEtrKldzSrh8aYx6IvBSwcNG4yNu4SRjqEt+9WhXL+/7 0tJA== MIME-Version: 1.0 X-Received: by 10.60.24.162 with SMTP id v2mr3428115oef.96.1361993908454; Wed, 27 Feb 2013 11:38:28 -0800 (PST) Received: by 10.76.167.106 with HTTP; Wed, 27 Feb 2013 11:38:28 -0800 (PST) In-Reply-To: <512E3248.1020003@joelhalpern.com> References: <512D576B.6030009@joelhalpern.com> <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> <512E3248.1020003@joelhalpern.com> Date: Wed, 27 Feb 2013 20:38:28 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "Joel M. Halpern" CC: "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 27 Feb 2013 19:42:16.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 64.170.98.30 X-MS-Exchange-Organization-OriginalServerIPAddress: 10.7.14.232 X-MS-Exchange-Organization-AuthSource: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 11553 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=VA3EHSMHS008.bigfish.com:TOTAL=5 X-MS-Exchange-Organization-MessageLatency: SRV=mail136-va3:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail136-va3:TOTAL=2 X-MS-Exchange-Organization-MessageLatency: SRV=mail136-va3-R.bigfish.com:TOTAL=1 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: BL2PRD0610HT003 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent On Wed, Feb 27, 2013 at 5:20 PM, Joel M. Halpern wrote: > Actually Luigi, in my personal opinion: > 1) It is not our job or our requirement to involve the RIRs. It is our job > to come up with what we think LISP and the Internet need for EID allocation. > 2) I would be really surprised if EID allocation policies were at all > related to current RIR address allocation policies. The behaviors are VERY > different, as are the assignment implications. Are you thinking something more along these lines http://www.ietf.org/mail-archive/web/lisp/current/msg04155.html ? In there I mention the RIR simple because they have the _infrastructure_ to support the operational side of any delegation, whois+dns+++... If we can get it to work any other way, maybe something along domain names, that is also another option. --- Roger J --- > Yours, > Joel > > > On 2/27/2013 6:59 AM, Luigi Iannone wrote: >> >> Hi, >> >> >> On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote: >> >>> As a participant, I have an even stronger pinion on the RIR references >>> than terry. >>> >>> I think that the block management needs to define >>> o who the root is >>> o what policy we require for allocating blocks to allocators (the root is >>> not an allocator >>> o What the behavioral requirements are for an allocator >>> o are there any special requirements for re-delegating to another >>> allocator? >>> o What policies allocators should respect for end site allocation >>> >>> Once we have this defined, then organizations that wish to participate >>> can do so. If the RIRs want to come play, they may. If not, then they >>> don't. >>> >> >> Got it, is what I've also understood from Terry's point. >> >> Again, there was no intention to put work on RIRs back, rather to show >> that we can come up with a framework that involves RIRs and is compatible >> with current RIRs' policies. (apparently the message was not clear ;-) ). >> >> It comes to my mind the question of what we are going to do with the EID >> block if in 10 years the IETF decides that LISP is the best thing ever and >> we need to assign the EID block permanently? >> >> Ideas are welcome :-) >> >> ciao >> >> L. >> >> >>> (Repeated for clarity, the above is a personal opinion, not a WG chair >>> position, nor associated with any other hats I may have.) >>> >>> Yours, >>> Joel >>> >>> On 2/26/2013 7:26 PM, Terry Manderson wrote: >>>> >>>> Speaking just as a WG participant. >>>> >>>> I would rather a document like this focus purely on the allocation >>>> criteria that needs to be applied to: >>>> 1) An experimental EID block >>>> 2) ongoing LISP allocations beyond the life of the experiment >>>> >>>> Given the expected (numbering) requirements of a LISP site. >>>> >>>> Simply, while it is temping to use the RIRs, and name them, it is not >>>> appropriate in my opinion to assign work to the RIRs. That is the job of >>>> their membership. >>>> >>>> Similarly, what policies the RIRs have now are all subject to change >>>> within their own policy development processes. Please don't re-codify >>>> them >>>> here. I would also prefer to see this document take the approach of >>>> defining what is best for LISP, not how can we use the RIRs as an >>>> allocation framework. The concern I have is that if LISP ends up >>>> requiring >>>> something very different to how the RIRs do it - we would be doing a >>>> disservice to both LISP and the RIRs by pushing it that way. >>>> >>>> The definition of terms is well stated elsewhere, perhaps you can point >>>> to >>>> those locations? >>>> >>>> Cheers >>>> Terry >>>> >>>> On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >>>> >>>>> >>>>> >>>>> >>>>> FYI a new version is available. >>>>> >>>>> >>>>> Comments still welcome ;-) >>>>> >>>>> >>>>> L. >>>>> >>>>> Begin forwarded message: >>>>> >>>>> >>>>> From: >>>>> internet-drafts@ietf.org >>>>> >>>>> Subject: >>>>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>>>> >>>>> Date: >>>>> 25 February 2013 21:47:29 GMT+01:00 >>>>> >>>>> To: >>>>> i-d-announce@ietf.org >>>>> >>>>> Reply-To: >>>>> internet-drafts@ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> >>>>> Title : LISP EID Block Management Guidelines >>>>> Author(s) : Luigi Iannone >>>>> Roger Jorgensen >>>>> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >>>>> Pages : 9 >>>>> Date : 2013-02-25 >>>>> >>>>> Abstract: >>>>> This document proposes an allocation framework for the management of >>>>> the LISP EID address prefix (requested in a separate document). Such >>>>> framework relies on hierarchical distribution of the address space to >>>>> RIRs (Regional Internet Registries), who will allocate on a temporary >>>>> basis sub-prefixes to requesting organizations. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >> >> > -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_eefed57b-1c81-4090-aa2a-a4a437c8d5a4_-- From jmh@joelhalpern.com Thu Feb 28 03:00:27 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0843421F8AF2 for ; Thu, 28 Feb 2013 03:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 gQabCM172VZP for ; Thu, 28 Feb 2013 03:00:25 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id 766D021F87AD for ; Thu, 28 Feb 2013 03:00:21 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Thu, 28 Feb 2013 04:56:19 -0500 Received: from tx2outboundpool.messaging.microsoft.com ([65.55.88.15]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 13:23:00 -0500 Received: from mail20-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 16:21:53 +0000 Received: from mail20-tx2 (localhost [127.0.0.1]) by mail20-tx2-R.bigfish.com (Postfix) with ESMTP id 10FD5360140; Wed, 27 Feb 2013 16:21:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: PS-30(zzbb2dI98dI9371I936eIc85fh1b0bIc430Ic85dh1432I1418I9a6kzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275dh186M8275bhz2fh2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail20-tx2: domain of CINTAS1.onmicrosoft.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=BL2PRD0610HT003.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail20-tx2 (localhost.localdomain [127.0.0.1]) by mail20-tx2 (MessageSwitch) id 1361982111318763_8638; Wed, 27 Feb 2013 16:21:51 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.250]) by mail20-tx2.bigfish.com (Postfix) with ESMTP id 4A18C20004E; Wed, 27 Feb 2013 16:21:51 +0000 (UTC) Received: from BL2PRD0610HT003.namprd06.prod.outlook.com (157.56.240.117) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 16:21:48 +0000 Content-Type: multipart/mixed; boundary="_0e1632c8-6d98-4a2d-9d90-e58da687c164_" To: Luigi Iannone From: "Joel M. Halpern" MIME-Version: 1.0 Sender: Message-ID: <1fe23b0f-1fea-43b8-9620-18eb54a70ddb@journal.report.generator> Date: Wed, 27 Feb 2013 16:21:41 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 27 Feb 2013 18:23:01.0824 (UTC) FILETIME=[7A28AC00:01CE1517] Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 11:00:27 -0000 --_0e1632c8-6d98-4a2d-9d90-e58da687c164_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: jmh@joelhalpern.com Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Message-Id: <512E3248.1020003@joelhalpern.com> Recipient: buxtonb@cintas.com --_0e1632c8-6d98-4a2d-9d90-e58da687c164_ Content-Type: message/rfc822 Received: from mail92-ch1-R.bigfish.com (216.32.181.170) by BL2PRD0610HT003.namprd06.prod.outlook.com (10.255.101.38) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 27 Feb 2013 16:21:41 +0000 Received: from mail92-ch1 (localhost [127.0.0.1]) by mail92-ch1-R.bigfish.com (Postfix) with ESMTP id 090632000CA for ; Wed, 27 Feb 2013 16:21:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -26 X-BigFish: ps-26(zzbb2dI98dI9371I936eI1b0bIc430I1432I1418I9a6kzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275dh8275bhz2fhfI11Ieh5fh668h839h944hd25he5bh1288h12a5h12a9h137ah13b6h13eah1441h1504h1537h153bh162dh1631h1758h1765h18e1h190ch1946h19b4h19c3h1664i1155h) Received-SPF: pass (mail92-ch1: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail92-ch1 (localhost.localdomain [127.0.0.1]) by mail92-ch1 (MessageSwitch) id 1361982099121406_3658; Wed, 27 Feb 2013 16:21:39 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail92-ch1.bigfish.com (Postfix) with ESMTP id 1B5B34C0084 for ; Wed, 27 Feb 2013 16:21:39 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 16:21:29 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB921F86B8; Wed, 27 Feb 2013 08:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361982087; bh=Lsfw9UrLIDpcW4Kg2XiEqWLpXxEMxTQYg5UYfMuRm1A=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=cM+vOWhbUjQogI38MF7Vxl+qTbEiN/Vrrx31N9D4F2M+cli2pfmKeKIkHzJ4FkFPV e3SaypQVl5RkE8Yt/KKLjoI2AR04fOO/yB5vUv4lPrnuYomIZqgequukeR9QfrUU6Z dEraIPbGs2aIeJQNrempSU4c61+JieRxssDd2cV0= 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 91F1421F8667 for ; Wed, 27 Feb 2013 08:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 N8GFwOnwN0pD for ; Wed, 27 Feb 2013 08:21:25 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id D647E21F868B for ; Wed, 27 Feb 2013 08:21:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C2B111C0858; Wed, 27 Feb 2013 08:21:25 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-134.clppva.east.verizon.net [70.106.134.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1F7891C050E; Wed, 27 Feb 2013 08:21:00 -0800 (PST) Message-ID: <512E3248.1020003@joelhalpern.com> Date: Wed, 27 Feb 2013 11:20:24 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Luigi Iannone References: <512D576B.6030009@joelhalpern.com> <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> In-Reply-To: <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> CC: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 27 Feb 2013 16:21:39.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 10.43.68.226 X-MS-Exchange-Organization-OriginalServerIPAddress: 127.0.0.1 X-MS-Exchange-Organization-AuthSource: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 10332 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=mail92-ch1:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail92-ch1:TOTAL=2 X-MS-Exchange-Organization-MessageLatency: SRV=mail92-ch1-R.bigfish.com:TOTAL=0 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: BL2PRD0610HT003 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent Actually Luigi, in my personal opinion: 1) It is not our job or our requirement to involve the RIRs. It is our job to come up with what we think LISP and the Internet need for EID allocation. 2) I would be really surprised if EID allocation policies were at all related to current RIR address allocation policies. The behaviors are VERY different, as are the assignment implications. Yours, Joel On 2/27/2013 6:59 AM, Luigi Iannone wrote: > Hi, > > > On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote: > >> As a participant, I have an even stronger pinion on the RIR references than terry. >> >> I think that the block management needs to define >> o who the root is >> o what policy we require for allocating blocks to allocators (the root is not an allocator >> o What the behavioral requirements are for an allocator >> o are there any special requirements for re-delegating to another allocator? >> o What policies allocators should respect for end site allocation >> >> Once we have this defined, then organizations that wish to participate can do so. If the RIRs want to come play, they may. If not, then they don't. >> > > Got it, is what I've also understood from Terry's point. > > Again, there was no intention to put work on RIRs back, rather to show that we can come up with a framework that involves RIRs and is compatible with current RIRs' policies. (apparently the message was not clear ;-) ). > > It comes to my mind the question of what we are going to do with the EID block if in 10 years the IETF decides that LISP is the best thing ever and we need to assign the EID block permanently? > > Ideas are welcome :-) > > ciao > > L. > > >> (Repeated for clarity, the above is a personal opinion, not a WG chair position, nor associated with any other hats I may have.) >> >> Yours, >> Joel >> >> On 2/26/2013 7:26 PM, Terry Manderson wrote: >>> Speaking just as a WG participant. >>> >>> I would rather a document like this focus purely on the allocation >>> criteria that needs to be applied to: >>> 1) An experimental EID block >>> 2) ongoing LISP allocations beyond the life of the experiment >>> >>> Given the expected (numbering) requirements of a LISP site. >>> >>> Simply, while it is temping to use the RIRs, and name them, it is not >>> appropriate in my opinion to assign work to the RIRs. That is the job of >>> their membership. >>> >>> Similarly, what policies the RIRs have now are all subject to change >>> within their own policy development processes. Please don't re-codify them >>> here. I would also prefer to see this document take the approach of >>> defining what is best for LISP, not how can we use the RIRs as an >>> allocation framework. The concern I have is that if LISP ends up requiring >>> something very different to how the RIRs do it - we would be doing a >>> disservice to both LISP and the RIRs by pushing it that way. >>> >>> The definition of terms is well stated elsewhere, perhaps you can point to >>> those locations? >>> >>> Cheers >>> Terry >>> >>> On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >>> >>>> >>>> >>>> >>>> FYI a new version is available. >>>> >>>> >>>> Comments still welcome ;-) >>>> >>>> >>>> L. >>>> >>>> Begin forwarded message: >>>> >>>> >>>> From: >>>> internet-drafts@ietf.org >>>> >>>> Subject: >>>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>>> >>>> Date: >>>> 25 February 2013 21:47:29 GMT+01:00 >>>> >>>> To: >>>> i-d-announce@ietf.org >>>> >>>> Reply-To: >>>> internet-drafts@ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : LISP EID Block Management Guidelines >>>> Author(s) : Luigi Iannone >>>> Roger Jorgensen >>>> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >>>> Pages : 9 >>>> Date : 2013-02-25 >>>> >>>> Abstract: >>>> This document proposes an allocation framework for the management of >>>> the LISP EID address prefix (requested in a separate document). Such >>>> framework relies on hierarchical distribution of the address space to >>>> RIRs (Regional Internet Registries), who will allocate on a temporary >>>> basis sub-prefixes to requesting organizations. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_0e1632c8-6d98-4a2d-9d90-e58da687c164_-- From ggx@gigix.net Thu Feb 28 04:10:10 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569D321F84C9 for ; Thu, 28 Feb 2013 04:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 0rLrSVkcNyzl for ; Thu, 28 Feb 2013 04:10:09 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id 6A45621F84C1 for ; Thu, 28 Feb 2013 04:10:09 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Thu, 28 Feb 2013 07:09:18 -0500 Received: from co1outboundpool.messaging.microsoft.com ([216.32.180.184]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 11:38:30 -0500 Received: from mail13-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 11:50:41 +0000 Received: from mail13-co1 (localhost [127.0.0.1]) by mail13-co1-R.bigfish.com (Postfix) with ESMTP id 66D2390013F; Wed, 27 Feb 2013 11:50:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.181; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0612HT002.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zzbb2dI98dI9371I936eIc85fh1b0bIc430Ic85dh1432I9a6kzz1f42h1ee6h1202h1e76h1d1ah1d2ah1082kzz8275ch1033IL17326ah8275dh8275bhz31h2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: softfail (mail13-co1: transitioning domain of CINTAS1.onmicrosoft.com does not designate 132.245.1.181 as permitted sender) client-ip=132.245.1.181; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=BLUPRD0612HT002.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail13-co1 (localhost.localdomain [127.0.0.1]) by mail13-co1 (MessageSwitch) id 1361965839592937_5251; Wed, 27 Feb 2013 11:50:39 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.247]) by mail13-co1.bigfish.com (Postfix) with ESMTP id 83B06D80048; Wed, 27 Feb 2013 11:50:39 +0000 (UTC) Received: from BLUPRD0612HT002.namprd06.prod.outlook.com (132.245.1.181) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 11:50:39 +0000 Content-Type: multipart/mixed; boundary="_ccdc11e1-ae29-45af-bb3d-f0f8b95ceb6f_" To: Terry Manderson From: Luigi Iannone MIME-Version: 1.0 Sender: Message-ID: Date: Wed, 27 Feb 2013 11:50:37 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 27 Feb 2013 16:38:36.0556 (UTC) FILETIME=[E3C4A4C0:01CE1508] Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 12:10:10 -0000 --_ccdc11e1-ae29-45af-bb3d-f0f8b95ceb6f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: ggx@gigix.net Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Message-Id: <1E126D54-B9FF-4A50-9B5F-F8C71B862CCB@gigix.net> Recipient: buxtonb@cintas.com --_ccdc11e1-ae29-45af-bb3d-f0f8b95ceb6f_ Content-Type: message/rfc822 Received: from mail54-db3-R.bigfish.com (213.199.154.138) by BLUPRD0612HT002.namprd06.prod.outlook.com (10.255.217.163) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 27 Feb 2013 11:50:37 +0000 Received: from mail54-db3 (localhost [127.0.0.1]) by mail54-db3-R.bigfish.com (Postfix) with ESMTP id AC50F34012D for ; Wed, 27 Feb 2013 11:50:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -22 X-BigFish: ps-22(zzbb2dI98dI9371I936eI1b0bIc430I1432I9a6kzz1f42h1ee6h1202h1e76h1d1ah1d2ah1082kzz8275ch1033IL17326ah8275dhz2fhfI11Ieh5fh668h839h944hd25he5bh1220h1288h12a5h12a9h137ah139eh13b6h13eah1441h1504h1537h162dh1631h1662h1728h1758h1898h1946h19b5h1664i1155h) Received-SPF: pass (mail54-db3: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3 (MessageSwitch) id 1361965833990206_17382; Wed, 27 Feb 2013 11:50:33 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.251]) by mail54-db3.bigfish.com (Postfix) with ESMTP id EE8F1220062 for ; Wed, 27 Feb 2013 11:50:33 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 11:50:33 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C8421F854C; Wed, 27 Feb 2013 03:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361965831; bh=kdiwedhw7NyG0woDOenVj4gkHwiyowh4NUuKNENvGUw=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Ilz20bcaLqeV1fgYQnbHxWH/WE0edkhTRBpjJSI8kt01pAHtw0/swfxW4wV6ZjxSw c5cEG21VdKb5J40EZozo20r7se4v7Y1xEhleRaYpNsp6IfB43NuqR5H8aAPDGWdVIG 3CaFG9dBUE+7rd9SRIQ4jVDhNyjaXTE1rhTjLpTQ= 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 642BE21F853C for ; Wed, 27 Feb 2013 03:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 twFpehFJwvc6 for ; Wed, 27 Feb 2013 03:50:26 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1C18321F854C for ; Wed, 27 Feb 2013 03:50:25 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so376969wey.21 for ; Wed, 27 Feb 2013 03:50:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=Hh8GCMbRkK8zeQ1jSonXQIu2XOlXOF/eqogClIqj3gY=; b=iJoCDDKPjI688XwKhD8RL2BiSg020VAHXCvwxobIavelIp0le1f+xXm0crXmUvg2kp irzUs1y5kGoFc+5834ZELE42t4mvTCN2RnMmHzXKpbjxw13EsMdFvN9DtxHz1kq5y+MF ydbkF3ZLfY3hd8DWWVN4xDjTqEVZPhj/VcXiyPan3uCYrNpdL/YP0rX+JF5MQMW1oVj7 0w34a2np8HH51hsSRN4Uf3DFPZGkzBNx7lcJiageSOgQmSpTWh7ghXjWdiK6F2AtU4I5 9By2P2WrQvxvA64Do+SO9ahBjpdWhVC39qSdThOYiiL7ELRw6ZPNio91yD99iEEcWAQ/ HP+g== X-Received: by 10.194.158.198 with SMTP id ww6mr3274538wjb.44.1361965825188; Wed, 27 Feb 2013 03:50:25 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:3c79:c727:50b7:beb5? ([2001:660:330f:a4:3c79:c727:50b7:beb5]) by mx.google.com with ESMTPS id n10sm8211340wia.0.2013.02.27.03.50.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 03:50:23 -0800 (PST) MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: Date: Wed, 27 Feb 2013 12:50:25 +0100 Message-ID: <1E126D54-B9FF-4A50-9B5F-F8C71B862CCB@gigix.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkPBuKZbr3xYSOwnCWVgmx2HM6nmVa7HdLJB3R/TqaD4csiWL/hooGIj0EDYpXTevt9VRom CC: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 27 Feb 2013 11:50:33.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: BLUPRD0612HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 10.3.81.251 X-MS-Exchange-Organization-OriginalServerIPAddress: 127.0.0.1 X-MS-Exchange-Organization-AuthSource: BLUPRD0612HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: BLUPRD0612HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 9220 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=mail54-db3:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail54-db3:TOTAL=3 X-MS-Exchange-Organization-MessageLatency: SRV=mail54-db3-R.bigfish.com:TOTAL=1 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: BLUPRD0612HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: BLUPRD0612HT002 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent Hi, On 27 Feb. 2013, at 01:26 , Terry Manderson wrote: > Speaking just as a WG participant. > > I would rather a document like this focus purely on the allocation > criteria that needs to be applied to: > 1) An experimental EID block > 2) ongoing LISP allocations beyond the life of the experiment > > Given the expected (numbering) requirements of a LISP site. > > Simply, while it is temping to use the RIRs, and name them, it is not > appropriate in my opinion to assign work to the RIRs. That is the job of > their membership. > > Similarly, what policies the RIRs have now are all subject to change > within their own policy development processes. Please don't re-codify them > here. I would also prefer to see this document take the approach of > defining what is best for LISP, not how can we use the RIRs as an > allocation framework. The concern I have is that if LISP ends up requiring > something very different to how the RIRs do it - we would be doing a > disservice to both LISP and the RIRs by pushing it that way. The idea was not to impose anything to RIRs , but rather to use the document as starting point to discuss with them. Having said that, I've got the point: "let's document EID allocation requirements and framework without referring to a specific entity". Is that correct? > > The definition of terms is well stated elsewhere, perhaps you can point to > those locations? There is a pointer for each term. The terms are "duplicated" here just to offer an handy reading. There is no harm in keeping them. ciao Luigi > > Cheers > Terry > > On 26/02/13 7:59 AM, "Luigi Iannone" wrote: > >> >> >> >> FYI a new version is available. >> >> >> Comments still welcome ;-) >> >> >> L. >> >> Begin forwarded message: >> >> >> From: >> internet-drafts@ietf.org >> >> Subject: >> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >> >> Date: >> 25 February 2013 21:47:29 GMT+01:00 >> >> To: >> i-d-announce@ietf.org >> >> Reply-To: >> internet-drafts@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : LISP EID Block Management Guidelines >> Author(s) : Luigi Iannone >> Roger Jorgensen >> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >> Pages : 9 >> Date : 2013-02-25 >> >> Abstract: >> This document proposes an allocation framework for the management of >> the LISP EID address prefix (requested in a separate document). Such >> framework relies on hierarchical distribution of the address space to >> RIRs (Regional Internet Registries), who will allocate on a temporary >> basis sub-prefixes to requesting organizations. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> >> >> _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_ccdc11e1-ae29-45af-bb3d-f0f8b95ceb6f_-- From ggx@gigix.net Thu Feb 28 04:12:37 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25D321F84D5 for ; Thu, 28 Feb 2013 04:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 s92CJEy9TVoj for ; Thu, 28 Feb 2013 04:12:36 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id 94C0921F84C9 for ; Thu, 28 Feb 2013 04:12:36 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Thu, 28 Feb 2013 07:12:35 -0500 Received: from va3outboundpool.messaging.microsoft.com ([216.32.180.14]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 13:24:01 -0500 Received: from mail59-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 12:00:10 +0000 Received: from mail59-va3 (localhost [127.0.0.1]) by mail59-va3-R.bigfish.com (Postfix) with ESMTP id 859954C061D; Wed, 27 Feb 2013 12:00:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.133; KIP:(null); UIP:(null); IPV:NLI; H:SN2PRD0610HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zzbb2dI98dI9371I936eIc85fh1b0bIc430Ic85dh1432I1418I9a6kzz1f42h1ee6h1202h1e76h1d1ah1d2ah1082kzz8275ch1033IL17326ah8275dh8275bhz2fh2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail59-va3: domain of CINTAS1.onmicrosoft.com designates 157.56.234.133 as permitted sender) client-ip=157.56.234.133; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=SN2PRD0610HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail59-va3 (localhost.localdomain [127.0.0.1]) by mail59-va3 (MessageSwitch) id 1361966408332069_26145; Wed, 27 Feb 2013 12:00:08 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.247]) by mail59-va3.bigfish.com (Postfix) with ESMTP id 4B0AD4A05E2; Wed, 27 Feb 2013 12:00:08 +0000 (UTC) Received: from SN2PRD0610HT005.namprd06.prod.outlook.com (157.56.234.133) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 12:00:04 +0000 Content-Type: multipart/mixed; boundary="_47f1f30a-a5b6-43ca-a15f-b516c5cb6fb5_" To: Joel M.Halpern From: Luigi Iannone MIME-Version: 1.0 Sender: Message-ID: <668b9c92-63a2-4a42-a37a-47354e9d13f2@journal.report.generator> Date: Wed, 27 Feb 2013 12:00:04 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 27 Feb 2013 18:24:01.0070 (UTC) FILETIME=[9D78E4E0:01CE1517] Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 12:12:37 -0000 --_47f1f30a-a5b6-43ca-a15f-b516c5cb6fb5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: ggx@gigix.net Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt Message-Id: <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> Recipient: buxtonb@cintas.com --_47f1f30a-a5b6-43ca-a15f-b516c5cb6fb5_ Content-Type: message/rfc822 Received: from mail19-tx2-R.bigfish.com (65.55.88.115) by SN2PRD0610HT005.namprd06.prod.outlook.com (10.255.117.40) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 27 Feb 2013 12:00:03 +0000 Received: from mail19-tx2 (localhost [127.0.0.1]) by mail19-tx2-R.bigfish.com (Postfix) with ESMTP id A25E84013F for ; Wed, 27 Feb 2013 12:00:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -23 X-BigFish: ps-23(zzbb2dI98dI9371I936eI1b0bIc430I1432I1418I9a6kzz1f42h1ee6h1202h1e76h1d1ah1d2ah1082kzz8275ch1033IL17326ah8275dh8275bhz2fhfI11Ieh5fh668h839h944hd25he5bh1220h1288h12a5h12a9h137ah139eh13b6h13eah1441h1504h1537h162dh1631h1662h1728h1758h1898h1946h19b5h1664i1155h) Received-SPF: pass (mail19-tx2: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail19-tx2 (localhost.localdomain [127.0.0.1]) by mail19-tx2 (MessageSwitch) id 1361966401414745_31840; Wed, 27 Feb 2013 12:00:01 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.238]) by mail19-tx2.bigfish.com (Postfix) with ESMTP id 5C6CFE0063 for ; Wed, 27 Feb 2013 12:00:01 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 11:59:58 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B270421F848A; Wed, 27 Feb 2013 03:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361966397; bh=CY2S7R7WsHNaYAXBj3Paw3nEYsAt3z5nkSYmcBWwpfE=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=NbGZp9rkNjiuA0MKvEctGTtRW0xNGl0bm8/A5FG8uhQHRPUuS8pSCShz4Vh+/wVnV NsO/I7arTEyRxutdXG4HVrBk+k8RuaQZgU5X+rzuaHKQG/pnfi519CGXw8hJj96hE6 e/EHqsYaAg151aXo+X7R2Azr/tD7OAa/yqNaKN4I= 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 6961B21F845D for ; Wed, 27 Feb 2013 03:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 d46VYuFYeXqO for ; Wed, 27 Feb 2013 03:59:51 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6321F841B for ; Wed, 27 Feb 2013 03:59:51 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so375425wgb.21 for ; Wed, 27 Feb 2013 03:59:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=k5E50IdYDpo08NCAxyhUHzD0JmEcl8o/gIpn082y0sc=; b=QZIt+CNGQhxZ08gW7xAxswI4QYJhvVEwVtEd+5XHlKLuch3jFWanXifeAhCLFgb19g pGTNZQhUE71/MhKzA4xIOkjfpNeNmx+ZfrHWVDWpERVzZagvOgvTWKLI7L7bWZOM1AmH JRZSIHEI9vqKwFMd+dPtthXhsULaedvHpzg+tF6+ek/T6E4V5twPDpF0cnD/Fd0ItQdf MjpIXp6kHTiMmCuqPQRQ6ZYuF6cLe/I8lWMG43GQmQIgMK4qqrFNpSQ4WDCRpb7qlFjO iSDU/gIT+xcF2CrvubeNf65nZaYKomNB+4V63Mgqx4jmdSE1mEIaeF4Hyl4OOzsVWnRQ 2jeg== X-Received: by 10.194.176.165 with SMTP id cj5mr3352496wjc.37.1361966390296; Wed, 27 Feb 2013 03:59:50 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:3c79:c727:50b7:beb5? ([2001:660:330f:a4:3c79:c727:50b7:beb5]) by mx.google.com with ESMTPS id ex15sm26832402wid.5.2013.02.27.03.59.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 03:59:49 -0800 (PST) MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luigi Iannone In-Reply-To: <512D576B.6030009@joelhalpern.com> Date: Wed, 27 Feb 2013 12:59:51 +0100 Message-ID: <1D6E5F64-1F8E-471A-B404-E5E30F7FDCB9@gigix.net> References: <512D576B.6030009@joelhalpern.com> To: Joel M.Halpern X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlZLZuR7zN+424DTSN/RJ7Uz2nIM2SbA9vGFdPwEs4UZFeTm4PckdGbSfmgasSzz5IMhUVJ CC: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org list list" Subject: Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 27 Feb 2013 11:59:58.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: SN2PRD0610HT005.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 64.170.98.30 X-MS-Exchange-Organization-OriginalServerIPAddress: 10.9.14.238 X-MS-Exchange-Organization-AuthSource: SN2PRD0610HT005.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: SN2PRD0610HT005.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 10411 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=TX2EHSMHS009.bigfish.com:TOTAL=3 X-MS-Exchange-Organization-MessageLatency: SRV=mail19-tx2:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail19-tx2:TOTAL=2 X-MS-Exchange-Organization-MessageLatency: SRV=mail19-tx2-R.bigfish.com:TOTAL=0 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: SN2PRD0610HT005.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: SN2PRD0610HT005 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent Hi, On 27 Feb. 2013, at 01:46 , Joel M. Halpern wrote: > As a participant, I have an even stronger pinion on the RIR references than terry. > > I think that the block management needs to define > o who the root is > o what policy we require for allocating blocks to allocators (the root is not an allocator > o What the behavioral requirements are for an allocator > o are there any special requirements for re-delegating to another allocator? > o What policies allocators should respect for end site allocation > > Once we have this defined, then organizations that wish to participate can do so. If the RIRs want to come play, they may. If not, then they don't. > Got it, is what I've also understood from Terry's point. Again, there was no intention to put work on RIRs back, rather to show that we can come up with a framework that involves RIRs and is compatible with current RIRs' policies. (apparently the message was not clear ;-) ). It comes to my mind the question of what we are going to do with the EID block if in 10 years the IETF decides that LISP is the best thing ever and we need to assign the EID block permanently? Ideas are welcome :-) ciao L. > (Repeated for clarity, the above is a personal opinion, not a WG chair position, nor associated with any other hats I may have.) > > Yours, > Joel > > On 2/26/2013 7:26 PM, Terry Manderson wrote: >> Speaking just as a WG participant. >> >> I would rather a document like this focus purely on the allocation >> criteria that needs to be applied to: >> 1) An experimental EID block >> 2) ongoing LISP allocations beyond the life of the experiment >> >> Given the expected (numbering) requirements of a LISP site. >> >> Simply, while it is temping to use the RIRs, and name them, it is not >> appropriate in my opinion to assign work to the RIRs. That is the job of >> their membership. >> >> Similarly, what policies the RIRs have now are all subject to change >> within their own policy development processes. Please don't re-codify them >> here. I would also prefer to see this document take the approach of >> defining what is best for LISP, not how can we use the RIRs as an >> allocation framework. The concern I have is that if LISP ends up requiring >> something very different to how the RIRs do it - we would be doing a >> disservice to both LISP and the RIRs by pushing it that way. >> >> The definition of terms is well stated elsewhere, perhaps you can point to >> those locations? >> >> Cheers >> Terry >> >> On 26/02/13 7:59 AM, "Luigi Iannone" wrote: >> >>> >>> >>> >>> FYI a new version is available. >>> >>> >>> Comments still welcome ;-) >>> >>> >>> L. >>> >>> Begin forwarded message: >>> >>> >>> From: >>> internet-drafts@ietf.org >>> >>> Subject: >>> I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt >>> >>> Date: >>> 25 February 2013 21:47:29 GMT+01:00 >>> >>> To: >>> i-d-announce@ietf.org >>> >>> Reply-To: >>> internet-drafts@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : LISP EID Block Management Guidelines >>> Author(s) : Luigi Iannone >>> Roger Jorgensen >>> Filename : draft-iannone-lisp-eid-block-mgmnt-01.txt >>> Pages : 9 >>> Date : 2013-02-25 >>> >>> Abstract: >>> This document proposes an allocation framework for the management of >>> the LISP EID address prefix (requested in a separate document). Such >>> framework relies on hierarchical distribution of the address space to >>> RIRs (Regional Internet Registries), who will allocate on a temporary >>> basis sub-prefixes to requesting organizations. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-iannone-lisp-eid-block-mgmnt-01 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_47f1f30a-a5b6-43ca-a15f-b516c5cb6fb5_-- From ljakab@ac.upc.edu Thu Feb 28 04:13:19 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5D21F84D5 for ; Thu, 28 Feb 2013 04:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 5u0J2fu7YHne for ; Thu, 28 Feb 2013 04:13:18 -0800 (PST) Received: from CPMASEBH01.na.cintas.com (cpmasebh01.na.cintas.com [198.177.158.75]) by ietfa.amsl.com (Postfix) with SMTP id 92E9221F84C9 for ; Thu, 28 Feb 2013 04:13:17 -0800 (PST) Received: from mail pickup service by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC; Thu, 28 Feb 2013 07:13:16 -0500 Received: from tx2outboundpool.messaging.microsoft.com ([65.55.88.13]) by CPMASEBH01.na.cintas.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 13:24:36 -0500 Received: from mail113-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 16:30:46 +0000 Received: from mail113-tx2 (localhost [127.0.0.1]) by mail113-tx2-R.bigfish.com (Postfix) with ESMTP id C4BFB100110; Wed, 27 Feb 2013 16:30:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.117; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0610HT002.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: PS-33(zzbb2dI98dIc85fh148cI1432I11f6Nzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh5eeeK8275bhz2fh2a8h668h839ha12hc60hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail113-tx2: domain of CINTAS1.onmicrosoft.com designates 157.56.236.117 as permitted sender) client-ip=157.56.236.117; envelope-from=MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@CINTAS1.onmicrosoft.com; helo=BY2PRD0610HT002.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2 (MessageSwitch) id 1361982644720377_27263; Wed, 27 Feb 2013 16:30:44 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.237]) by mail113-tx2.bigfish.com (Postfix) with ESMTP id AB7CE18004C; Wed, 27 Feb 2013 16:30:44 +0000 (UTC) Received: from BY2PRD0610HT002.namprd06.prod.outlook.com (157.56.236.117) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 16:30:44 +0000 Content-Type: multipart/mixed; boundary="_79ee6eb5-0bc5-49a6-a26e-33b61eafb45a_" To: "Templin, Fred L" From: Lori Jakab MIME-Version: 1.0 Sender: Message-ID: Date: Wed, 27 Feb 2013 16:30:40 +0000 X-MS-Journal-Report: X-OriginatorOrg: CINTAS1.onmicrosoft.com X-OriginalArrivalTime: 27 Feb 2013 18:24:36.0630 (UTC) FILETIME=[B2AAEB60:01CE1517] Cc: "lisp@ietf.org" Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06' 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, 28 Feb 2013 12:13:19 -0000 --_79ee6eb5-0bc5-49a6-a26e-33b61eafb45a_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org On-Behalf-Of: ljakab@ac.upc.edu Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06' Message-Id: <512E3492.9010405@ac.upc.edu> Recipient: buxtonb@cintas.com --_79ee6eb5-0bc5-49a6-a26e-33b61eafb45a_ Content-Type: message/rfc822 Received: from mail119-db3-R.bigfish.com (213.199.154.137) by BY2PRD0610HT002.namprd06.prod.outlook.com (10.255.85.37) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 27 Feb 2013 16:30:39 +0000 Received: from mail119-db3 (localhost [127.0.0.1]) by mail119-db3-R.bigfish.com (Postfix) with ESMTP id 5914D20018D for ; Wed, 27 Feb 2013 16:30:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -34 X-BigFish: ps-34(zzbb2dI98dI148cI1432I11f6Nzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh5eeeK8275bhz2fhfI11Ieh5fh668h839h944hd25h1220h1288h12a5h12a9h137ah13b6h13eah1441h1504h1537h153bh162dh1631h1758h1765h18e1h1946h1664i1155h) Received-SPF: pass (mail119-db3: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=lisp-bounces@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail119-db3 (localhost.localdomain [127.0.0.1]) by mail119-db3 (MessageSwitch) id 1361982634980971_23134; Wed, 27 Feb 2013 16:30:34 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.253]) by mail119-db3.bigfish.com (Postfix) with ESMTP id E27AF38004A for ; Wed, 27 Feb 2013 16:30:34 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 16:30:30 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6640C21F877A; Wed, 27 Feb 2013 08:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361982629; bh=kqcxqYoVEoB7vJyIaJxmaci1DYLh/IrK5AwxoDXKytc=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=g+NUnV36NpzkY38dQEnVJmOQjZm0irzNufdXYnr2E76TsAGGzA7R8dH+v+SPayn3P eHCd90V3eu5qK/4qkICvYVwvFljxqgc6YmZzsD2VqREgPlOg7U2Phpq6ub87qGkl7P bk4D1k1GzC2qT2HgSgSre1nN0UdL2G9aie+eQbvQ= 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 2CB1121F86B8 for ; Wed, 27 Feb 2013 08:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 QnD+t7VoWuvY for ; Wed, 27 Feb 2013 08:30:26 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id E6E4721F847A for ; Wed, 27 Feb 2013 08:30:25 -0800 (PST) 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 r1RGUIQu004790; Wed, 27 Feb 2013 17:30:18 +0100 Received: from [192.168.1.6] (unknown [89.123.104.156]) by gw.ac.upc.edu (Postfix) with ESMTP id 5F4416B01A4; Wed, 27 Feb 2013 17:30:17 +0100 (CET) Message-ID: <512E3492.9010405@ac.upc.edu> Date: Wed, 27 Feb 2013 18:30:10 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: "Templin, Fred L" References: <20130225180218.31450.57812.idtracker@ietfa.amsl.com> <512BC5C4.6090406@joelhalpern.com> <2134F8430051B64F815C691A62D9831801146A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831801146A@XCH-BLV-504.nw.nos.boeing.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc CC: "lisp@ietf.org" Subject: Re: [lisp] comments on 'draft-ietf-lisp-deployment-06' 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: lisp-bounces@ietf.org Return-Path: lisp-bounces@ietf.org X-MS-Exchange-Organization-OriginalArrivalTime: 27 Feb 2013 16:30:34.0000 (UTC) X-MS-Exchange-Forest-ArrivalHubServer: BY2PRD0610HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-OriginalClientIPAddress: 10.3.81.253 X-MS-Exchange-Organization-OriginalServerIPAddress: 127.0.0.1 X-MS-Exchange-Organization-AuthSource: BY2PRD0610HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-MessageDirectionality: Incoming X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: BY2PRD0610HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-OriginalSize: 8555 X-MS-Exchange-Organization-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Forest-MessageScope: 3c2c92ef-b025-4317-b7dd-409f295cfdc6 X-MS-Exchange-Organization-HygienePolicy: Premium X-MS-Exchange-Organization-MessageLatency: SRV=mail119-db3:TOTAL=0 X-MS-Exchange-Organization-MessageLatency: SRV=mail119-db3:TOTAL=4 X-MS-Exchange-Organization-MessageLatency: SRV=mail119-db3-R.bigfish.com:TOTAL=1 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-Recipient-Limit-Verified: True X-MS-Exchange-Organization-Prioritization: 1 X-MS-Exchange-Forest-RoutedForHighAvailability: BY2PRD0610HT002.namprd06.prod.outlook.com X-MS-Exchange-Organization-Rules-Execution-History: Legal Disclaimer X-MS-Exchange-Forest-RulesExecuted: BY2PRD0610HT002 X-MS-Exchange-Organization-Processed-By-Gcc-Journaling: Journal Agent Hi Fred, Thank you very much for the feedback. See responses in-line below: On 02/26/13 00:55, Templin, Fred L wrote: > Hi, > > I am reading this document for the first time and had a few > comments to share below. > > Thanks - Fred > fred.l.templin@boeing.com > > 1) Section 2.5 ("Tunnel Routers Behind NAT"), this seems to > show a limitation in that there can be only one xTR behind > a NAT. I would like to address the case when there may be > many xTRs behind the NAT - can LISP do that? There is specification being worked on that will enable many xTRs behind NAT. It will, however require a Re-encapsulating Tunnel Router (RTR) to proxy all data packets for it to work. See https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal > > 2) Section 2.6, I don't understand why it says "MTU/PMTUD > issues minimized" for the recursive scenario? It's a typo, thanks for catching this! > > 3) Section 6.1, number 4, should say "request increase in MTU > to 1556 *or greater* on service provider connections". Indeed, will fix. > However, controlling just the first-hop interface MTU > does not assure MTU mitigations across the entire path. > Similarly, "care must be taken that ICMP is not being > filtered" cannot be assured along the entire path. And, > studies have shown that ICMP filtering does impact MTU > handling in current operational practices: > > http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf True, we are citing RFC 4459 at the end of section 2.1 with regard to this issue. Would it help if we referenced it in this section as well? > > Additionally, I have a use case that I'm not sure is well addressed by > the document. I would like to address the use case of mobile networks > configured as stub sites that connect to ISPs via a mobile router. Each > mobile router may have multiple ISP connections, and can change its ISP > addresses dynamically as it moves around. Some of the ISP addresses may > be global and others may be private, such as behind a carrier-grade NAT. > Many such mobile routers may be located behind the same NAT. > > I want to give each mobile router an EID prefix that it can use to number > interfaces within the mobile network. The mobile network may contain just > one interface, a few interfaces, or it may contain many interfaces. > > I now want that the mobile network can remain reachable from the outside > world by the same EID prefix addresses even as the mobile router travels > around dynamically. The mobile router will need an xTR so that its ISPs > will not filter its packets that use EID source addresses. I also want > the mobile router to be able to traffic engineer in both the outgoing > *and* incoming directions. For this, there needs to be some sort of > server sitting outside of any NATs that the mobile router can "register" > itself with. The mobile router should be able to change between different > servers as it moves around, e.g., to reduce path stretch or in the > event of a server failure. The servers in turn associate with proxy > xTRs so that outgoing packets destined to EIDs located in distant > networks can be routed appropriately. > > This is the way IRON sets things up. Can it also be done with LISP? Yes, using the NAT traversal specification I mentioned above. The mobile router should be an xTR itself, and will receive a list of RTRs (what you call servers above) it can use for traversing the NAT (for the connections where a NAT is detected). Path stretch optimizations are certainly possible, they depend on the implementation of the Map-Server. Incoming traffic engineering is possible with LISP, however, outgoing traffic engineering is not LISP specific, it should be done with existing mechanisms. Would you like this scenario added to the document? Best regards, -Lori _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_79ee6eb5-0bc5-49a6-a26e-33b61eafb45a_--